On Sun, Oct 27, 2019 at 3:46 PM Buschart, Rufus <rufus.busch...@siemens.com> 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: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 > > _______________________________________________ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
