info
Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
Validation of Domains for secure email certificates
115 views
Skip to first unread message
Doug Beattie
Jul 20, 2017, 8:05:30 AM7/20/17
to mozilla-dev-s...@lists.mozilla.org, Gervase Markham
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 <certificate management portal or API>. This approval would last until this customer notified the CA otherwise <or closed their account>:
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 <CA name such as globalsign.com>. 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 <hosting company name such as microsoft.com, yahoo.com, gmail.com>. 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
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 <certificate management portal or API>. This approval would last until this customer notified the CA otherwise <or closed their account>:
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 <CA name such as globalsign.com>. 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 <hosting company name such as microsoft.com, yahoo.com, gmail.com>. 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
Gervase Markham
Jul 20, 2017, 10:58:57 AM7/20/17
to mozilla-dev-s...@lists.mozilla.org
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
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:
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
Jakob Bohm
Jul 20, 2017, 11:14:33 AM7/20/17
to mozilla-dev-s...@lists.mozilla.org
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 <certificate management portal or API>. This approval would last until this customer notified the CA otherwise <or closed their account>:
>
> 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 <CA name such as globalsign.com>. 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 <hosting company name such as microsoft.com, yahoo.com, gmail.com>. 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-mail account by an
identity tied method (e.g. credit card) and has marked that account as
being their own (i.e. not a gift/sponsorship payment, e.g. as a gift
to a friend or as part of a payment/salary package). This of cause
combined with strong identity verification, e.g. government photo ID.
Example: If mail is hosted by a major telecoms operation such as BT
in the UK, then BT may provide a BT associated CA with confirmation
(not actual data sharing) that an e-mail account is associated with
a telephone bill which is authenticated to a specific individual at a
specific street address, allowing the CA to do final confirmation via
a robocall/fax to that phone or by snail mail to that street address.
C. Evidence that this is not an e-mail hoster combined with domain
validation at the first level below public suffixes (e.g. domain
validation for "example.com", not "smtp.example.com" (which may be
outsourced to a spam filtering service or similar).
Note, if a mail service provider wants certificates in the names of its
customers, it will have to ask them individually, and not as part of
"terms of service", "signup" etc. And such certificates should be
required (by policy / CA subscriber contract) to include an "on behalf
of" text visible to any relying party in most existing S/MIME e-mail
clients. For example "Microsoft on behalf of Exam Ple
<exa...@outlook.com>", not "Exam Ple <exa...@outlook.com>".
You may also want to look at the BRs for EV code signing certificates
(which may include e-mail addresses) for inspiration.
Enjoy
Jakob
--
Jakob Bohm, CIO, Partner, WiseMo A/S. https://www.wisemo.com
Transformervej 29, 2860 Søborg, Denmark. Direct +45 31 13 16 10
This public discussion message is non-binding and may contain errors.
WiseMo - Remote Service Management for PCs, Phones and Embedded
> 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.
>
>
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
>
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 <certificate management portal or API>. This approval would last until this customer notified the CA otherwise <or closed their account>:
>
> 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
>
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.
>
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 <CA name such as globalsign.com>. Details in CA CPS.
>
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 <hosting company name such as microsoft.com, yahoo.com, gmail.com>. 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.
>
>
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-mail account by an
identity tied method (e.g. credit card) and has marked that account as
being their own (i.e. not a gift/sponsorship payment, e.g. as a gift
to a friend or as part of a payment/salary package). This of cause
combined with strong identity verification, e.g. government photo ID.
Example: If mail is hosted by a major telecoms operation such as BT
in the UK, then BT may provide a BT associated CA with confirmation
(not actual data sharing) that an e-mail account is associated with
a telephone bill which is authenticated to a specific individual at a
specific street address, allowing the CA to do final confirmation via
a robocall/fax to that phone or by snail mail to that street address.
C. Evidence that this is not an e-mail hoster combined with domain
validation at the first level below public suffixes (e.g. domain
validation for "example.com", not "smtp.example.com" (which may be
outsourced to a spam filtering service or similar).
Note, if a mail service provider wants certificates in the names of its
customers, it will have to ask them individually, and not as part of
"terms of service", "signup" etc. And such certificates should be
required (by policy / CA subscriber contract) to include an "on behalf
of" text visible to any relying party in most existing S/MIME e-mail
clients. For example "Microsoft on behalf of Exam Ple
<exa...@outlook.com>", not "Exam Ple <exa...@outlook.com>".
You may also want to look at the BRs for EV code signing certificates
(which may include e-mail addresses) for inspiration.
Enjoy
Jakob
--
Jakob Bohm, CIO, Partner, WiseMo A/S. https://www.wisemo.com
Transformervej 29, 2860 Søborg, Denmark. Direct +45 31 13 16 10
This public discussion message is non-binding and may contain errors.
WiseMo - Remote Service Management for PCs, Phones and Embedded
Doug Beattie
Jul 20, 2017, 1:30:50 PM7/20/17
to Gervase Markham, mozilla-dev-s...@lists.mozilla.org
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=globals...@lists.mozilla.org] On Behalf Of
> Gervase Markham via dev-security-policy
> Sent: Thursday, July 20, 2017 10:58 AM
> To: mozilla-dev-s...@lists.mozilla.org
> Subject: Re: Validation of Domains for secure email certificates
>
> Hi Doug,
>
> On 20/07/17 13:04, Doug Beattie wrote:
> dev-security-policy mailing list
> dev-secur...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-security-policy
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=globals...@lists.mozilla.org] On Behalf Of
> Gervase Markham via dev-security-policy
> Sent: Thursday, July 20, 2017 10:58 AM
> To: mozilla-dev-s...@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:
>
> 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
> _______________________________________________
> 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-secur...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-security-policy
0 new messages