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 <wtha...@mozilla.com> wrote:

> 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

Reply via email to