Re: Which fields containing email addresses need to be validated?
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:
Re: Which fields containing email addresses need to be validated?
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
Re: Which fields containing email addresses need to be validated?
(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? 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? 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. ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Which fields containing email addresses need to be validated?
On Thu, Feb 06, 2020 at 09:31:40PM +, Doug Beattie via dev-security-policy wrote: > I don't agree that the CA MUST validate EVERY field. CAs leverage > enterprise RAs to validate some information in SMIME certificates, e.g., the > subscribers name in the CN field because the CA can't readily validate that. I don't care who does the validation, just that it's validated. Kurt ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
RE: Which fields containing email addresses need to be validated?
I don't agree that the CA MUST validate EVERY field. CAs leverage enterprise RAs to validate some information in SMIME certificates, e.g., the subscribers name in the CN field because the CA can't readily validate that. I believe the same is true for some other fields like the UPN which is the active directly account, but I thought I'd start a discussion to see what people thought. Doug -Original Message- From: Kurt Roeckx Sent: Thursday, February 6, 2020 4:06 PM To: Doug Beattie Cc: mozilla-dev-security-policy Subject: Re: Which fields containing email addresses need to be validated? On Thu, Feb 06, 2020 at 08:54:04PM +, Doug Beattie via dev-security-policy wrote: > It's not against Mozilla policy to > issue certificates with unvalidated email addresses in any field as > long as the Secure Mail EKU is not included, so the intent should be > to validate only those that are used for Secure Mail. Any field in the certificate should be validated. If it contains an email address, it should be validated. If it's not validated, it should get removed. Kurt smime.p7s Description: S/MIME cryptographic signature ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Which fields containing email addresses need to be validated?
On Thu, Feb 06, 2020 at 08:54:04PM +, Doug Beattie via dev-security-policy wrote: > It's not against Mozilla policy to > issue certificates with unvalidated email addresses in any field as long as > the Secure Mail EKU is not included, so the intent should be to validate > only those that are used for Secure Mail. Any field in the certificate should be validated. If it contains an email address, it should be validated. If it's not validated, it should get removed. Kurt ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Which fields containing email addresses need to be validated?
The Mozilla policy section 2.2 says: * . the CA takes reasonable measures to verify that the entity submitting the request controls the email account associated with the email address referenced in the certificate. Since the Mozilla policy only applies to certificates with the EKU of Secure Mail (ignoring TLS in this discussion), it would seem to imply that only email addresses that could be used for sending or receiving signed or encrypted emails would be in scope. It's not against Mozilla policy to issue certificates with unvalidated email addresses in any field as long as the Secure Mail EKU is not included, so the intent should be to validate only those that are used for Secure Mail. As far as I know, the only fields that could be used by S/MIME applications are the CN, Email, and RFC822 SAN fields. 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. 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 smime.p7s Description: S/MIME cryptographic signature ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
