What does it mean by “An executed Subscriber Agreement or Terms of Use”

261 views
Skip to first unread message

Yuki Yuki

unread,
Jun 11, 2021, 11:45:49 AM6/11/21
to dev-secur...@mozilla.org

Hello, 

 

The Baseline Requirements 4.1.2 says: 

 

“Prior to the issuance of a Certificate, the CA SHALL obtain the following documentation from the Applicant: 

  1. A certificate request, which may be electronic; and 
  2. An executed Subscriber Agreement or Terms of Use, which may be electronic.” 

 

As I understand, an executed Subscriber Agreement or Terms of Use or contract is a legal document that has been signed off by the people necessary for it to become effective, which means a signature from the Subscriber must be presented on the Agreement, be it an electronic signature or a handwritten one.  

 

That being said, I recently obtained a Domain Validated certificate from Let’s Encrypt through Cloudflare, and no subscriber agreement popped out and there was no way to sign such agreement electronically during the certificate issuance process. 

 

I'd like to ask if this conforms to section 4.1.2 of the Baseline Requirements, as well as section 5.5.2 which requires a minimum seven-year retention period of the documents in relation to the certificate issuance, and I assume an “executed subscriber agreement” is part of such documents. 

 

Apologies in advance if I misinterpreted these requirements or missed any previous discussions. 

 

Thank you. 


Matthias Merkel

unread,
Jun 11, 2021, 12:20:41 PM6/11/21
to Yuki Yuki, dev-secur...@mozilla.org
Hi Yuki,

the ACME client should ask you to confirm the terms of service, which count as a legal agreement. The ACME client then transmit your confirmation to Let's Encrypt. 

Matthias Merkel

--
You received this message because you are subscribed to the Google Groups "dev-secur...@mozilla.org" group.
To unsubscribe from this group and stop receiving emails from it, send an email to dev-security-po...@mozilla.org.
To view this discussion on the web visit https://groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/SL2PR03MB4427A1D05FF38A4DA5705096D4349%40SL2PR03MB4427.apcprd03.prod.outlook.com.

Jacob Hoffman-Andrews

unread,
Jun 11, 2021, 12:59:25 PM6/11/21
to Yuki Yuki, dev-secur...@mozilla.org
Hi Yuki,

On Fri, Jun 11, 2021 at 8:45 AM Yuki Yuki <yuki...@outlook.com> wrote:

That being said, I recently obtained a Domain Validated certificate from Let’s Encrypt through Cloudflare, and no subscriber agreement popped out and there was no way to sign such agreement electronically during the certificate issuance process.


In this situation, Cloudflare is the Subscriber and has agreed to Let's Encrypt's Subscriber Agreement (via the ACME API).

If you want to ensure that CDNs or other hosting providers can only successfully request issuance from CAs that you specifically list, you can configure a CAA record in your DNS: https://letsencrypt.org/docs/caa/.

Thanks,
Jacob

Ryan Sleevi

unread,
Jun 12, 2021, 11:15:47 AM6/12/21
to Jacob Hoffman-Andrews, Yuki Yuki, dev-secur...@mozilla.org
Hi Yuki,

I think others have covered the question of "who is the Subscriber" and "How does ACME ensure this" (which is dependent on jurisdiction, naturally). To your question, though, the answer you're seeking is answered in Section 9.6.3 of the Baseline Requirements, namely

The CA SHALL implement a process to ensure that each Subscriber Agreement or Terms of Use is legally enforceable against the Applicant. In either case, the Agreement MUST apply to the Certificate to be issued pursuant to the certificate request. The CA MAY use an electronic or “click‐through” Agreement provided that the CA has determined that such agreements are legally enforceable.

--
You received this message because you are subscribed to the Google Groups "dev-secur...@mozilla.org" group.
To unsubscribe from this group and stop receiving emails from it, send an email to dev-security-po...@mozilla.org.

Yuki Yuki

unread,
Jun 15, 2021, 11:11:45 AM6/15/21
to Jacob Hoffman-Andrews, ry...@sleevi.com, dev-secur...@mozilla.org

Hello All, 

 

Thanks for the explanation. 

 

I was feeling confusing because, by the definitions of the Baseline Requirements, a certificate Applicant becomes a Subscriber once the Certificate is issued, if Cloudflare is the Subscriber in this case, then it will also be the corresponding Applicant, I thought as a legal person who owns a domain, I was the Applicant, and Cloudflare served as the Registration Authority who validated the domain ownership and then submitted the validated information for the CA to issue a certificate. 

 

Thank you.



发件人: Ryan Sleevi <ry...@sleevi.com>
发送时间: 2021年6月12日 23:15
收件人: Jacob Hoffman-Andrews <js...@letsencrypt.org>
抄送: Yuki Yuki <yuki...@outlook.com>; dev-secur...@mozilla.org <dev-secur...@mozilla.org>
主题: Re: What does it mean by “An executed Subscriber Agreement or Terms of Use”
 

Ryan Sleevi

unread,
Jun 19, 2021, 2:32:41 PM6/19/21
to Yuki Yuki, Jacob Hoffman-Andrews, ry...@sleevi.com, dev-secur...@mozilla.org
This is understandably confusing!

It sounds like you got sorted out, but it's worth noting, there's no strict binding between the domain holder and the Applicant/Subscriber. The Applicant/Subscriber is just the entity who requests the certificates _and_ can demonstrate authorization from the domain holder.

There's no permitted delegation of domain ownership (i.e. no RA vetting of domains) in the Web PKI, and the Web PKI doesn't guarantee that the entity in the Subject (if present) is the domain holder. The only guarantee is that the Applicant/Subscriber was authorized by the domain holder, by one of the "blessed methods" (3.2.2.4) which rely on some technical demonstration of control, authorization, or delegation.

Ryan Sleevi

unread,
Jun 20, 2021, 12:07:49 AM6/20/21
to Moudrick M. Dadashov, Jacob Hoffman-Andrews, Yuki Yuki, dev-secur...@mozilla.org, ry...@sleevi.com
Could you explain why? It’s unclear if you were trying to say the misunderstanding the misunderstanding is close to the eIDAS Regulation’s statement?

Given that the eIDAS Regulation fundamentally misunderstands how TLS and the Web work, that might make sense.
https://www.ccadb.org/documents/Qualified_Website_Authentication_Certificates_Interoperability.pdf discusses precisely how TLS does not, and cannot, provide such an assurance about the domain holder in a way thats not harmful to user security.

But your message is a bit unclear, and I’m hoping you can share more.

On Sat, Jun 19, 2021 at 4:39 PM Moudrick M. Dadashov <m...@ssc.lt> wrote:
Sounds quite close to this definition:

(38)

‘certificate for website authentication’ means an attestation that makes it possible to authenticate a website and links the website to the natural or legal person to whom the certificate is issued;


Thanks,
M.D.



Sent from my Galaxy

Moudrick M. Dadashov

unread,
Jun 21, 2021, 6:29:21 PM6/21/21
to ry...@sleevi.com, Jacob Hoffman-Andrews, Yuki Yuki, dev-secur...@mozilla.org
Thanks Ryan,

By "quite close" I meant the similarity (non contradictory) of these:

"The Applicant/Subscriber is just the entity who requests the certificates _and_ can demonstrate authorization from the domain holder."

‘certificate for website authentication’ means an attestation that makes it possible to authenticate a website and links the website to the natural or legal person to whom the certificate is issued;


Whereas "‘authentication’ means an electronic process that enables the electronic identification of a natural or legal person, or the origin and integrity of data in electronic form to be confirmed;".


Unfortunately eIDAS has no definition for website and that, taking into account GDPR, is a huge problem (millions of non compliant QESCs in circulation today).

But after reading the document you shared (thank you for that, Ryan!), I understand I was overly optimistic thinking that the  Commission and browsers have reached some sort of consensus*.


Whoever led eIDAS negotiators, the executive summary shows the team has gone too far and wrong direction. But that's another story. :)


Thanks,

M.D.


Reply all
Reply to author
Forward
0 new messages