RE: Validation of Domains for secure email certificates
Hi Gerv, OK, I see your point. We'll come up with what we think are reasonable methods and document that in the CPS. That should work better than Gerv's vacation thoughts! Doug > -Original Message- > From: dev-security-policy [mailto:dev-security-policy- > bounces+doug.beattie=globalsign@lists.mozilla.org] On Behalf Of > Gervase Markham via dev-security-policy > Sent: Thursday, July 20, 2017 10:58 AM > To: mozilla-dev-security-pol...@lists.mozilla.org > Subject: Re: Validation of Domains for secure email certificates > > Hi Doug, > > On 20/07/17 13:04, Doug Beattie wrote: > > Since there is no BR equivalent for issuance of S/MIME certificates (yet), > this is all CAs have to go on. I was curious if you agree that all of these > methods meet the above requirement: > > As you might imagine, this question puts me in a difficult position. If I say > that a certain method does meet the requirement, I am making Mozilla policy > up on the fly (and while on holiday ;-). If I say it does not, I would perhaps > panic a load of CAs into having to update their issuance systems for fear of > being dinged for misissuance. > > It is unfortunate that there is no BR equivalent for email. However, I'm not > convinced that the best way forward is for Mozilla to attempt to write one by > degrees in response to questioning from CAs :-) I think the best thing for you > to do is to look at your issuance processes and ask yourself whether you > would be willing to stand up in a court of law and assert that they were > "reasonable measures". When thinking about that, you could perhaps ask > yourself whether you were doing any things which had been specifically > outlawed or deprecated in an SSL context by the recent improvements in > domain validation on that side of the house. > > Gerv > ___ > dev-security-policy mailing list > dev-security-policy@lists.mozilla.org > https://lists.mozilla.org/listinfo/dev-security-policy ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Validation of Domains for secure email certificates
On 20/07/2017 14:04, Doug Beattie wrote: Gerv, In general, it is common to have an S/MIME certificate for an e-mail account that does *not* belong to the domain owner. This is especially true if the domain is a public/shared/ISP e-mail domain and is set up to allow some way for the e-mail user to access the raw RFCxx22 messages (e.g. IMAP, POP3, SMTP, darkmail, proprietary protocols). In such cases, issuing the S/MIME cert to the domain owner would be *inappropriate*, possibly even misissuance. Mozilla Policy 2.5 states this: For a certificate capable of being used for digitally signing or encrypting email messages, the CA takes reasonable measures to verify that the entity submitting the request controls the email account associated with the email address referenced in the certificate or has been authorized by the email account holder to act on the account holder's behalf. Notice how the above language refers exclusively to the e-mail account, not the domain. Since there is no BR equivalent for issuance of S/MIME certificates (yet), this is all CAs have to go on. I was curious if you agree that all of these methods meet the above requirement: 1. On a per request basis (noting that some of these are overkill for issuance of a single certificate): a. 3.2.2.4.1 Validating the Applicant as a Domain Contact b. 3.2.2.4.2 Email, Fax, SMS, or Postal Mail to Domain Contact c. 3.2.2.4.3 Phone Contact with Domain Contact d. 3.2.2.4.4 Email to Constructed Address e. 3.2.2.4.5 Domain Authorization Document f.3.2.2.4.6 Agreed-Upon Change to Website g. 3.2.2.4.7 DNS Change None of the above validate ownership of the e-mail account, instead they validate control of the (middlebox) e-mail server. 2. On a per Domain basis. One approval is sufficient to approve issuance for certificates in this domain space since these represent administrator actions provided subsequent requests are all performed via authenticated channel to the CA . This approval would last until this customer notified the CA otherwise : a. 3.2.2.4.1 Validating the Applicant as a Domain Contact b. 3.2.2.4.2 Email, Fax, SMS, or Postal Mail to Domain Contact c. 3.2.2.4.3 Phone Contact with Domain Contact d. 3.2.2.4.4 Email to Constructed Address e. 3.2.2.4.5 Domain Authorization Document f.3.2.2.4.6 Agreed-Upon Change to Website g. 3.2.2.4.7 DNS Change These would only be appropriate if there is some evidence that the domain owner is actually authorized to act on behalf of their users. At a minimum, the domain must not contain words such as "mail" in their second level name (e.g. hotmail.com would be out, mail.example.com would not). There are probably other automated tests that detect likely e-mail hosters, and which can be mandated as requiring individual account validation even if the domain happens to not be an e-mail hoster, (e.g. envelopesandmail.example being a company dealing only with snail mail of others and handling only their own e-mails, but would be required by policy to validate each of their e-mail accounts separately because their domain name matches a rule that has been made rigid for the common good). 3. Assuming issuance to a service provider (email hosting entity like Microsoft, Yahoo or Google) that hosts email for many domains, CA verifies that the Email domain DNS MX record points to the hosting company which indicates the company has delegated email control to the hosting company. In contrast, issuance to such must be *rejected* as man-in-the middle attacks. 4. A DNS TXT record for the domain indicating approval to issue email certificates, or perhaps a CAA record with a new tag like issuesmime which permits the CA to issue certificates to this domain . Details in CA CPS. That could make sense, also in the rare cases where the account holders at a private (not e-mail hoster) domain wants to (unwisely) outsource mail signing and encryption to someone. However delegating e-mail signing is essentially a wide-ranging power of attorney, not something you would grant to a random technology provider (unlike an *actual* attorney). 5. A DNS TXT record for the domain indicating approval to issue email certificates, or perhaps a CAA record with a new tag like issuesmime which permits the email hosting company to issue certificates to this domain . Details in CA CPS Definitely bad. Are there any other methods that you had in mind when writing this requirement? Since issuance needs to be WT audited, there should be some level of "agreement" on acceptable validation methods. May I suggest: A. E-mail with an activation code to the *actual* account named in the certificate (similar to mailing list confirmed signup). B. Evidence from a trusted (by the CA) e-mail hoster that a physical person or legal entity is paying for that e-m
Re: Validation of Domains for secure email certificates
Hi Doug, On 20/07/17 13:04, Doug Beattie wrote: > Since there is no BR equivalent for issuance of S/MIME certificates (yet), > this is all CAs have to go on. I was curious if you agree that all of these > methods meet the above requirement: As you might imagine, this question puts me in a difficult position. If I say that a certain method does meet the requirement, I am making Mozilla policy up on the fly (and while on holiday ;-). If I say it does not, I would perhaps panic a load of CAs into having to update their issuance systems for fear of being dinged for misissuance. It is unfortunate that there is no BR equivalent for email. However, I'm not convinced that the best way forward is for Mozilla to attempt to write one by degrees in response to questioning from CAs :-) I think the best thing for you to do is to look at your issuance processes and ask yourself whether you would be willing to stand up in a court of law and assert that they were "reasonable measures". When thinking about that, you could perhaps ask yourself whether you were doing any things which had been specifically outlawed or deprecated in an SSL context by the recent improvements in domain validation on that side of the house. Gerv ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Validation of Domains for secure email certificates
Gerv, Mozilla Policy 2.5 states this: For a certificate capable of being used for digitally signing or encrypting email messages, the CA takes reasonable measures to verify that the entity submitting the request controls the email account associated with the email address referenced in the certificate or has been authorized by the email account holder to act on the account holder's behalf. Since there is no BR equivalent for issuance of S/MIME certificates (yet), this is all CAs have to go on. I was curious if you agree that all of these methods meet the above requirement: 1. On a per request basis (noting that some of these are overkill for issuance of a single certificate): a. 3.2.2.4.1 Validating the Applicant as a Domain Contact b. 3.2.2.4.2 Email, Fax, SMS, or Postal Mail to Domain Contact c. 3.2.2.4.3 Phone Contact with Domain Contact d. 3.2.2.4.4 Email to Constructed Address e. 3.2.2.4.5 Domain Authorization Document f.3.2.2.4.6 Agreed-Upon Change to Website g. 3.2.2.4.7 DNS Change 2. On a per Domain basis. One approval is sufficient to approve issuance for certificates in this domain space since these represent administrator actions provided subsequent requests are all performed via authenticated channel to the CA . This approval would last until this customer notified the CA otherwise : a. 3.2.2.4.1 Validating the Applicant as a Domain Contact b. 3.2.2.4.2 Email, Fax, SMS, or Postal Mail to Domain Contact c. 3.2.2.4.3 Phone Contact with Domain Contact d. 3.2.2.4.4 Email to Constructed Address e. 3.2.2.4.5 Domain Authorization Document f.3.2.2.4.6 Agreed-Upon Change to Website g. 3.2.2.4.7 DNS Change 3. Assuming issuance to a service provider (email hosting entity like Microsoft, Yahoo or Google) that hosts email for many domains, CA verifies that the Email domain DNS MX record points to the hosting company which indicates the company has delegated email control to the hosting company. 4. A DNS TXT record for the domain indicating approval to issue email certificates, or perhaps a CAA record with a new tag like issuesmime which permits the CA to issue certificates to this domain . Details in CA CPS. 5. A DNS TXT record for the domain indicating approval to issue email certificates, or perhaps a CAA record with a new tag like issuesmime which permits the email hosting company to issue certificates to this domain . Details in CA CPS Are there any other methods that you had in mind when writing this requirement? Since issuance needs to be WT audited, there should be some level of "agreement" on acceptable validation methods. Doug ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
