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
<exam...@outlook.com>", not "Exam Ple <exam...@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
_______________________________________________
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy
