I've opened issue #196 [1] to track Rufus' suggested clarification for a future policy update. I'll consider this issue (#175) resolved unless further comments are received.
- Wayne [1] https://github.com/mozilla/pkipolicy/issues/196 On Mon, Oct 28, 2019 at 4:41 PM Wayne Thayer <[email protected]> wrote: > On Sun, Oct 27, 2019 at 3:46 PM Buschart, Rufus < > [email protected]> wrote: > >> 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. >> >> > Thank you for the proposal. Proposals are always helpful! However, this > seems significantly less clear to me. > > 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 >> > > The existing language does the same without adding more BR references. > > 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 >> > > Did you intentionally omit the language that allows the CA to delegate > validation of the local portion of the email address? > > 4) If the operator of the mail server operates its own CA, he doesn't have >> to perform error prone email address validations >> > > The existing language already permits this via "*or* has been authorized > by the email account holder to act on the account holder's behalf." > > Do you believe that this is forbidden by the current version of Mozilla > policy? > > >> 5) We don't mix the words validation and verification for the same >> activity >> >> > I have no issue with changing "verification" to "validation", but this is > also unchanged from the current version of the policy. > > In other words, these proposed changes address what might be another > potential issue with the existing policy, but don't appear to be essential > to the issue being discussed in this thread. > > > 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:[email protected] >> 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 >> >> _______________________________________________ dev-security-policy mailing list [email protected] https://lists.mozilla.org/listinfo/dev-security-policy
