On Fri, Feb 7, 2020 at 7:55 AM douglas.beattie--- via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote:
> 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? Ideally, no, for the same reason we don’t have S/MIME certificates that are TLS certificates. Doesn’t Microsoft policy explicitly forbid this? Certainly, a future Mozilla policy would ideally forbid this. 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. I don’t agree with this. While not processed by clients, the inclusion of this information still represents a risk of different certificate profiles being used causing incompatibilities (e.g. revoking for S/MIME non-compliance will almost certainly be delayed due to it impacting the smart-card sign-on scenario), and will almost certainly mislead users who look to examine other identity information that may be present (e.g. in the Subject) To solve that, either we: 1) Guarantee the certificate is never displayed to the user so they are never mislead, thus defeating the goal of CAs in including such information in the Subject Or 2) Forbid the inclusion of these fields 3) Is including an email within a private extension not permitted, perhaps > for a special usecase outside of S/MIME? Today, the CA is required to validate that, which caused ambiguities as you note. As proposed, it would be forbidden, which handily resolves this and other issues. 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? As worded, yes. Can you clarify what interpretation would state this is acceptable? 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? If it contains the EKU, I think such fields other than those three should be prohibited. And I’m not even convinced it should be allowed in the subject, given the issues it poses to nameConstraints and ambiguities for clients. If it does not contain the EKU, or contains an unrelated EKU in addition, then it should not be coming from a trusted hierarchy. That is the only sensible end-state that looks to learn from the past twenty years of the Web PKI. I posted my proposed change to the Mozilla policy here: > https://github.com/mozilla/pkipolicy/issues/200 Yup, thanks! I am not supportive of this change, as I think it moves S/MIME closer to the 1993 Web PKI, not the 2020 Web PKI. Maybe this will be addressed as part of the S/MIME Certificate working > group and we can wait until then. I think you raise an important issue, and my hope is that as with most security related things, root policy will both clarify and set the baseline, using security as the basis for decision making. Under such a model, I definitely believe the email address in other fields should be forbidden for S/MIME, as should including any other EKUs. The inclusion of other EKUs is an attempt to combine trust frameworks, audit requirements, and certificate profiles, and we see time and time again that brings nothing but new risk with no value to clients. _______________________________________________ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
