On Thursday, February 6, 2020 at 6:05:20 PM UTC-5, Ryan Sleevi wrote: > (Replying from the correct e-mail) > > On Thu, Feb 6, 2020 at 3:55 PM Doug Beattie via dev-security-policy < > dev-security-policy@lists.mozilla.org> wrote: > > > We should clarify the Mozilla policy to more clearly define list of fields > > containing email address (those 3 listed above) must be validated in > > section > > 2.2 so that this is clear and concise. > > > > Doug, > > Is the proposal that, similar to how TLS defines that domain names MUST > appear within the SAN:dNSName, that emailAddresses MUST appear within one > of those three fields (that is: subject:commonName, subject:emailAddress, > subjectAltName:rfc822Name), that any value in the subject MUST also appear > in the subjectAltName, and an emailAddress MUST NOT appear in any other > field?
I agree with your description of where S/MIME email addresses must go, but I don't agree with your last statement that an email address "MUST NOT appear in any other field". More below. > That would address the concern, correct? > > Wayne opened this issue in December and I just replied with a comment > > related to the validation requirements of SAN/Other Name/UPN: > > > > https://github.com/mozilla/pkipolicy/issues/200 > > > I'm not sure I understand your question on this issue, and was hoping you > could expand. As you note, it's not used within S/MIME, so presumably, it's > not necessary for an S/MIME certificate, and thus MUST NOT be included. > That would resolve the ambiguity, correct? While it's not necessary for S/MIME, it's common to use an S/MIME certificate for both secure mail and client authentication (and even other things like ipSEC, file encryption etc). 1) Many/most CAs include both secure mail and client auth EKUs to permit such use. Is including the client auth EKU not permitted because it's not needed for S/MIME? 2) When using this S/MIME certificate for client authentication to a corporate system, the subjectAltName:UPN may be needed. The UPN typically contains an email address which may be the same, or may be different from the one in subjectAltName:rfc822Name. Since the UPN is not used for S/MIME, then its value should be opaque to S/MIME clients and the validation of this field should not need to follow the Mozilla policy for email validation. 3) Is including an email within a private extension not permitted, perhaps for a special usecase outside of S/MIME? 4) Is including an email address in any other subject field (there is a long list of subject fields in https://tools.ietf.org/html/rfc4519) not validated in accordance with the policy prohibited in S/MIME certificates? Since S/MIME applications use the email address only in the 3 fields you listed, is including it elsewhere an issue? Given there are no standards for the validation or use of an email address in any field (including the 3 used for S/MIME) when the secure mail EKU is NOT included, is there an issue when including email addresses in fields outside of those 3 when the certificate contains the secure mail EKU? I posted my proposed change to the Mozilla policy here: https://github.com/mozilla/pkipolicy/issues/200 Maybe this will be addressed as part of the S/MIME Certificate working group and we can wait until then. > Are you aware of any system that requires a single certificate contain both > in order to be used for S/MIME? If I understood your question right, it's > not required. No, not for S/MIME. Yes for when an S/MIME certificate is used for S/MIME and other purposes. _______________________________________________ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
