Von: Ryan Sleevi <r...@sleevi.com> > On Fri, Oct 25, 2019 at 6:44 PM Buschart, Rufus > <mailto:rufus.busch...@siemens.com> wrote: >> And while writing this email, I think I found one more problem: You are >> using the term "email account holder" >> which isn't defined anywhere. Who is the "email account holder" for >> john.doe@mycompany.example? >> Is it John Doe or is it "mycompany"? And in the case of >> john.doe@public-mail-provider.example? Is it John Doe >> or the "public mail provider"? I think we need a definition, ideally based >> on the terms "Subject" and >> "Subscriber". Or we replace "email account holder" with one of the two terms? > > Isn't it handled within that same sentence? > > "the entity submitting the request controls the email account associated with > the email address referenced > in the certificate" seems like it should be clear that the "email account > holder" (the following clause) is "the > entity that controls the email account associated with the email address" > (since it's handling the situation where > the applicant is not that entity)
> The clunkier reword (not a fan, but seeing how you feel about this, Rufus) > would be "the entity submitting > the request is *either* the entity that controls the email account associated > with the email address referenced > in the certificate *or* has been authorized by the entity that controls the > email address referenced within the > certificate" > > That avoids introducing the backreference term, but is a mouthful. I'm > assuming you meant Applicant and not > Subscriber, since we're talking pre-issuance validation ;) Maybe the following could be a reasonable rewording of the paragraph that makes the intention of the discussion clear, but isn't to 'clunky': For a certificate capable of being used for digitally signing or encrypting email messages, the CA SHALL validate that the Applicant Representative (as defined in the BRGs) of the request controls the email account associated with the email address referenced in the certificate, except when the CA and the owner of the domain are Affiliates (as defined in the BRGs). The CA SHALL NOT delegate the validation of an email address. The CA's CP/CPS must clearly specify the procedure(s) that the CA employs to perform this validation. With this wording we would reach: 1) The request can be initiated by the Applicant or Applicant Representative - due to the definition of Applicant Representative in the BRGs 2) Every CA can continue to issue S/MIME certificates as long as they perform a validation of the control of the email address 3) The CA cannot delegate the validation process 4) If the operator of the mail server operates its own CA, he doesn't have to perform error prone email address validations 5) We don't mix the words validation and verification for the same activity > As to which is it - is it the MX admin/domain admin or the individual meat > person - it seems that the answer is > either/or/both, at least from the perspective of RFC 822. The meat-person may > control the account, or the admin > of the account may themselves control the account, or the admin of the domain > may control the MX that controls > the account. In all cases, they control the email account associated. In the upcoming S/MIME WG I see a lot of discussions around this topic arising. With best regards, Rufus Buschart Siemens AG Siemens Operations Information Technology Value Center Core Services SOP IT IN COR Freyeslebenstr. 1 91058 Erlangen, Germany Tel.: +49 1522 2894134 mailto:rufus.busch...@siemens.com http://www.twitter.com/siemens https://siemens.com/ingenuityforlife Siemens Aktiengesellschaft: Chairman of the Supervisory Board: Jim Hagemann Snabe; Managing Board: Joe Kaeser, Chairman, President and Chief Executive Officer; Roland Busch, Lisa Davis, Klaus Helmrich, Janina Kugel, Cedrik Neike, Michael Sen, Ralf P. Thomas; Registered offices: Berlin and Munich, Germany; Commercial registries: Berlin Charlottenburg, HRB 12300, Munich, HRB 6684; WEEE-Reg.-No. DE 23691322
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
