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 <r...@sleevi.com>
Sent: Friday, October 4, 2019 10:56 PM
To: Jeremy Rowley <jeremy.row...@digicert.com>
Cc: Kathleen Wilson <kwil...@mozilla.com>; Wayne Thayer <wtha...@mozilla.com>;
mozilla-dev-security-policy <mozilla-dev-security-pol...@lists.mozilla.org>
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<mailto:*@foo.example>. Then Foo says
“oh, hey, we have a contractor at user@bar.example<mailto: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 verification, but that it uses Root CAs APIs and systems
under the hood. I‘m fairly certain DigiCert has experience doing this for their
customers, such as for white label CAs.
So that’s why I’m struggling to understand the use case, or the challenges,
with at least requiring domain-part validation by the CA.
On Fri, Oct 4, 2019 at 8:09 PM Jeremy Rowley via dev-security-policy
<dev-security-policy@lists.mozilla.org<mailto:dev-security-policy@lists.mozilla.org>>
wrote:
Will this permit either verification of the email address or the domain part?
For example, some organizations may verify their entire domain space and then
confirm contractors using a random value sent to the email address itself. They
don't need the entire domain space in those cases, but they do need to issue
certificates for a few email addresses outside of their domain control.
Verification of email control using a random value seems like it affords
controls that are equivalent to the challenge-response mechanisms in the BRs.
-----Original Message-----
From: dev-security-policy
<dev-security-policy-boun...@lists.mozilla.org<mailto:dev-security-policy-boun...@lists.mozilla.org>>
On Behalf Of Wayne Thayer via dev-security-policy
Sent: Friday, October 4, 2019 2:38 PM
To: Kathleen Wilson <kwil...@mozilla.com<mailto:kwil...@mozilla.com>>
Cc: mozilla-dev-security-policy
<mozilla-dev-security-pol...@lists.mozilla.org<mailto:mozilla-dev-security-pol...@lists.mozilla.org>>
Subject: Re: Policy 2.7 Proposal: Forbid Delegation of Email Validation for
S/MIME Certificates
I'd like to revive this discussion. So far we've established that the existing
"required practice" [1] is too stringent for email address validation and needs
to be changed. We can do that by removing email addresses from the scope of the
requirement as Kathleen proposed, or by exempting the local part of the email address as
I proposed earlier:
"CAs MUST NOT delegate validation of the domain name part of an email address to a
3rd party."
We have a fairly detailed explanation from Ryan Hurst of why and how removing
the requirement entirely is beneficial, but no one else has spoken in favor of
this need. Kathleen did however point out that this requirement doesn't appear
to be the result of a thorough analysis. We have Ryan Sleevi arguing that the
process described by Ryan Hurst is insecure and thus a reason to forbid
delegation of validation of the domain name part. Pedro Fuentes also wrote in
favor of this outcome.
One thing that might help to resolve this is a more detailed description of the
weaknesses that are present in the process described by Ryan Hurst. If we can
all agree that the process is vulnerable, then it seems that we'd have a strong
argument for banning it.
- Wayne
[1]
https://wiki.mozilla.org/CA/Forbidden_or_Problematic_Practices#Delegation_of_Domain_.2F_Email_Validation_to_Third_Parties
On Thu, May 23, 2019 at 12:22 PM Kathleen Wilson via dev-security-policy <
dev-security-policy@lists.mozilla.org<mailto:dev-security-policy@lists.mozilla.org>>
wrote:
On 5/13/19 10:24 AM, Wayne Thayer wrote:
The BRs forbid delegation of domain and IP address validation to
third parties. However, the BRs don't forbid delegation of email
address validation nor do they apply to S/MIME certificates.
Delegation of email address validation is already addressed by
Mozilla's Forbidden Practices [1] state:
"Domain and Email validation are core requirements of the Mozilla's
Root Store Policy and should always be incorporated into the issuing
CA's procedures. Delegating this function to 3rd parties is not permitted."
I propose that we move this statement (changing "the Mozilla's Root
Store Policy" to "this policy") into policy section 2.2 "Validation Practices".
This is https://github.com/mozilla/pkipolicy/issues/175
I will appreciate everyone's input on this proposal.
- Wayne
[1]
https://wiki.mozilla.org/CA/Forbidden_or_Problematic_Practices#Delegat
ion_of_Domain_.2F_Email_Validation_to_Third_Parties
All,
As the person who filed the Github issue for this, I would like to
provide some background and my opinion.
Currently the 'Delegation of Domain / Email Validation to Third Parties'
section of the 'Forbidden Practices' page says:
"This is forbidden by the Baseline Requirements, section 1.3.2.
Domain and Email validation are core requirements of the Mozilla's
Root Store Policy and should always be incorporated into the issuing
CA's procedures. Delegating this function to 3rd parties is not permitted."
Based on the way that section is written, it appears that domain
validation (and the BRs) was the primary consideration, and that the
Email part of it was an afterthought, or added later. Historically, my
attention has been focused on TLS certs, so it is possible that the
ramifications of adding Email validation to this section was not fully
thought through.
I don't remember who added this email validation text or when, but I
can tell you that when I review root inclusion requests I have only
been concerned about making sure that domain validation is not being
delegated to 3rd parties. It wasn't until a representative of a CA
brought this to my attention that I realized that there has been a
difference in text on this wiki page versus the rules I have been
trying to enforce. That is when I filed the github issue.
I propose that we can resolve this discrepancy for now by removing "/
Email Validation" from the title of the section and removing "and Email"
from the contents of the section.
Unless we believe there are significant security reasons to add our
own S/MIME required/forbidden practices at this time, my preference is
to wait for the CA/Browser Forum to create the S/MIME Working Group,
and for that group to identify the S/MIME baseline requirements. Then
we can add policy and required/forbidden practices based on the S/MIME
BRs provided by that group.
I do realize that my proposal is unfair to CAs who have been
diligently following this section of this wiki page. Your diligence is
appreciated, and your contributions to this discussion will also be appreciated.
Thanks,
Kathleen
_______________________________________________
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org<mailto: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<mailto: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<mailto: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
