Re: Policy 2.7 Proposal: Forbid Delegation of Email Validation for S/MIME Certificates

[Ryan Sleevi via dev-security-policy]

Thanks Jeremy, Dimitris,

It does help clarify. I think we're all on the same page: namely, in all
cases, the CA does the validation of (at minimum) the domain portion.

I think it might be useful to think of this like the split between
Authorization Domain Name and Fully Qualified Domain Name. A CA isn't
/required/ to only use the ADN, they could validate just the FQDN and
always at the FQDN level. But, in both cases, they have to at least
validate (a portion of) the domain name.

For S/MIME, the idea here is:
- If the CA had validated the domain portion, they could delegate the
validation of the local part to the RA. This is the same as the concept of
Enterprise RA, which allows the RA to handle the O/OU and other attributes,
as long as the CA validated the domain.
- Alternatively, the CA could validate the entire e-mail address (e.g.
using a random value)

But in both cases, the CA is involved in any domain-part validation.

Perhaps said differently:
The CA MUST verify all e-mail addresses using a process that is
substantially similar to the process used to verify domain names, as
described in the Baseline Requirements.
The CA SHALL NOT delegate validation of the domain part of an e-mail
address.
The CA SHALL NOT delegate validation of the local part of an e-mail address
except when delegating to an Enteprise RA, provided that the domain part of
the e-mail address is within the Enteprise RA's verified Domain Namespace.

I tried a couple variations of this (e.g. MAY delegate), but that could be
read as a loophole of allowing other forms of local-part delegation (i.e.
the "MAY" reads as "MAY use an Enterprise RA, or MAY use whatever else you
want", instead of "MAY" only if Enterprise RA)
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Policy 2.7 Proposal: Forbid Delegation of Email Validation for S/MIME Certificates

[Dimitris Zacharopoulos via dev-security-policy]

Jeremy,

As I'm sure you know, there are several federated services, at least in 
the Education and Research area, where schemes like https://edugain.org/ 
are used. In that scenario, Identity Providers under a certain policy 
(https://technical.edugain.org/documents) provide signed assertions that 
contain the full name and email address of the Subject, along with other 
signed attributes. Identity providers under this scheme usually have 
even stricter policies. Unfortunately these entities are not under a 
strict audit scheme but has been working pretty well for decades.


If any of these Identity Providers want to enable their users to get an 
S/MIME Certificate trusted by NSS, I think it would be acceptable for 
the CA to validate control of the Domain part and then let the federated 
login take care of the local part. Does that seem reasonable?



Dimitris.

On 2019-10-05 9:45 π.μ., Jeremy Rowley via dev-security-policy wrote:

I’m thinking more in terms of the potential rule in the Mozilla policy. If the 
rule is “the CA MUST verify the domain component of the email address” then the 
rule potentially prohibits the scenario where the CA verifies the entire email 
address, not the domain component, by sending a random value to each email 
address and requiring the email address holder to approve issuance. I actually 
liked the previous requirement prohibiting delegation of email address 
verification, although the rule lacked clarity on what email address 
verification entailed. I figure that will be defined in the s/MIME working 
group.

Describing the actors is a good way to look at it though. Besides those three 
buckets of issuers, you have the RAs, the email holders, and the organization 
controlling the domain portion of the email address. These entities may not be 
the same as the CA. More often than not, the RA ends up being the organization 
contracting with the CA for the s/MIME services. The RAs are the risky party 
that I think should be restricted on what they can verify since that’s where 
the lack of transparency starts to come in. With the prohibition against 
delegation of email control eliminated, we’re again placing domain/email 
control responsibilities on a party that has some incentive to misuse it (to 
read email of a third party) without audit, technical, or policy controls that 
limit their authority.  Because there are a lack of controls over the RAs, they 
become a hidden layer in the process that can issue certificates without anyone 
looking at how they are verifying the email address or domain name and whether 
these processes are equivalent to the controls found int eh BR.  Similar to 
TLS, the unaudited party should not be the one providing or verifying 
acceptance of the tokens used to approve issuance.

In short, I’m agreeing with the “at least” verifying the domain control 
portion. However, I know we verify a lot of email addresses directly with the 
email owner that doesn’t have control over the domain name. So the rule should 
be something that permits verification by the root CA of either the full email 
address or the domain name but at least eliminates delegation to non-audited 
third parties. For phrasing, “the CA MUST verify either the domain component of 
the email address or the entire email address using a process that is 
substantially similar to the process used to verify domain names as described 
in the Baseline Requirements”, with the understanding that we will rip out the 
language and replace it with the s/MIME requirements once those are complete at 
the CAB Forum.

Jeremy

From: Ryan Sleevi 
Sent: Friday, October 4, 2019 10:56 PM
To: Jeremy Rowley 
Cc: Kathleen Wilson ; Wayne Thayer ; 
mozilla-dev-security-policy 
Subject: Re: Policy 2.7 Proposal: Forbid Delegation of Email Validation for 
S/MIME Certificates

Jeremy:

Could you describe a bit more who the actors are?

Basically, it seems that the actual issuance is going to fall into one of 
several buckets:
1) Root CA controls Issuing CAs key
2) Issuing CA controls its own key, but is technically constrained
3) Issuing CA controls its own key, and is not technically constrained

We know #1 is covered by Root CA’s audit, and we know #3 is covered by Issuing 
CA’s audit, and #2 is technically constrained and thus the domain part is 
apriori validated.

So when you say “some organizations”, I’m trying to understand which of the three cases 
here they fall under. If I understand correctly, the idea is that Customer Foo approaches 
Root CA (Case #1). Root CA knows Foo’s namespace is foo.example through prior verification, 
and Root CA allows Foo to issue to *@foo.example. Then Foo says 
“oh, hey, we have a contractor at user@bar.example, we’d 
like a cert for them too”.

Why can’t Root CA verify themselves? Why would or should Root CA trust Foo to 
do it correctly? I can imagine plenty of verification protocols where Foo can 
be the “face” of the verif