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 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> 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> > On Behalf Of Wayne Thayer via dev-security-policy > Sent: Friday, October 4, 2019 2:38 PM > To: Kathleen Wilson <kwil...@mozilla.com> > Cc: 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 > > 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> 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 > > 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 > > _______________________________________________ > 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
