Re: Policy 2.5 Proposal: Remove BR duplication: reasons for revocation
On 20/04/17 14:46, Gervase Markham wrote: > So, proposed new text: > > "CAs MUST revoke Certificates that they have issued upon the > occurrence of any event listed in the appropriate subsection of section > 4.9.1 of the Baseline Requirements (for email certificates, not > including those events specific to the inclusion of Domain Names)." Edit made as follows: "CAs MUST revoke Certificates that they have issued upon the occurrence of any event listed in the appropriate subsection of section 4.9.1 of the Baseline Requirements, according to the timeline defined therein." I added the note about timeline because it's possible that the Forum may be updating those rules soon to be a bit more flexible, and I wouldn't want it to seem like the Mozilla policy requires immediate revocation. Gerv ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Policy 2.5 Proposal: Remove BR duplication: reasons for revocation
On 21/04/2017 00:36, Ryan Sleevi wrote: On Thu, Apr 20, 2017 at 6:15 PM, Jakob Bohm via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: Technically, the part after the @ could also be a bang!path, though this is rare these days. No, technically, it could not. RFC 5280, Section 4.2.1.6. Subject Alternative Name When the subjectAltName extension contains an Internet mail address, the address MUST be stored in the rfc822Name. The format of an rfc822Name is a "Mailbox" as defined in Section 4.1.2 of [RFC2821]. A Mailbox has the form "Local-part@Domain". Note that a Mailbox has no phrase (such as a common name) before it, has no comment (text surrounded in parentheses) after it, and is not surrounded by "<" and ">". Rules for encoding Internet mail addresses that include internationalized domain names are specified in Section 7.5. Note that RFC 2821 was OBSOLETEd by RFC 5321. RFC 5321 Section 4.1.2 states Mailbox= Local-part "@" ( Domain / address-literal ) address-literal = "[" ( IPv4-address-literal / IPv6-address-literal / General-address-literal ) "]" ; See Section 4.1.3 Domain = sub-domain *("." sub-domain) sub-domain = Let-dig [Ldh-str] Let-dig= ALPHA / DIGIT Ldh-str= *( ALPHA / DIGIT / "-" ) Let-dig Section 4.1.3 states IPv4-address-literal = Snum 3("." Snum) IPv6-address-literal = "IPv6:" IPv6-addr General-address-literal = Standardized-tag ":" 1*dcontent Standardized-tag = Ldh-str ; Standardized-tag MUST be specified in a ; Standards-Track RFC and registered with IANA To confirm, I also checked the IANA registry established, which is https://www.iana.org/assignments/address-literal-tags/address-literal-tags.xhtml The only address literal defined is IPv6. Could you indicate where you believe RFC 5280 supports the conclusion that a "bang!path" is permitted and relevant to Mozilla products? The older RFC 2459 allowed the full RFC 822 syntax (minus comments), which included bang paths. While RFC 2459 and RFC 822 are obsolete, it is still possible, sans explicit policy to the contrary, for a CA to issue valid certificates for this older address type, perhaps as a service to someone running historic system configurations. Even them, I think wording is still needed to state that the "domain"/"address-literal" part of the RFC5321 syntax is the part to which the "domain name" revocation BRs apply. Plus there is the additional situation of an e-mail domain operator/owner telling a CA that an e-mail cert should be revoked for various reasons (misissued cert, misissued e-mail address, e-mail address removed from cert holder, possibly others). Enjoy Jakob -- Jakob Bohm, CIO, Partner, WiseMo A/S. https://www.wisemo.com Transformervej 29, 2860 Søborg, Denmark. Direct +45 31 13 16 10 This public discussion message is non-binding and may contain errors. WiseMo - Remote Service Management for PCs, Phones and Embedded ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Policy 2.5 Proposal: Remove BR duplication: reasons for revocation
On Thu, Apr 20, 2017 at 6:15 PM, Jakob Bohm via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > > Technically, the part after the @ could also be a bang!path, though > this is rare these days. > No, technically, it could not. RFC 5280, Section 4.2.1.6. Subject Alternative Name When the subjectAltName extension contains an Internet mail address, the address MUST be stored in the rfc822Name. The format of an rfc822Name is a "Mailbox" as defined in Section 4.1.2 of [RFC2821]. A Mailbox has the form "Local-part@Domain". Note that a Mailbox has no phrase (such as a common name) before it, has no comment (text surrounded in parentheses) after it, and is not surrounded by "<" and ">". Rules for encoding Internet mail addresses that include internationalized domain names are specified in Section 7.5. Note that RFC 2821 was OBSOLETEd by RFC 5321. RFC 5321 Section 4.1.2 states Mailbox= Local-part "@" ( Domain / address-literal ) address-literal = "[" ( IPv4-address-literal / IPv6-address-literal / General-address-literal ) "]" ; See Section 4.1.3 Domain = sub-domain *("." sub-domain) sub-domain = Let-dig [Ldh-str] Let-dig= ALPHA / DIGIT Ldh-str= *( ALPHA / DIGIT / "-" ) Let-dig Section 4.1.3 states IPv4-address-literal = Snum 3("." Snum) IPv6-address-literal = "IPv6:" IPv6-addr General-address-literal = Standardized-tag ":" 1*dcontent Standardized-tag = Ldh-str ; Standardized-tag MUST be specified in a ; Standards-Track RFC and registered with IANA To confirm, I also checked the IANA registry established, which is https://www.iana.org/assignments/address-literal-tags/address-literal-tags.xhtml The only address literal defined is IPv6. Could you indicate where you believe RFC 5280 supports the conclusion that a "bang!path" is permitted and relevant to Mozilla products? ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Policy 2.5 Proposal: Remove BR duplication: reasons for revocation
On 20/04/2017 21:15, Ryan Sleevi wrote: Gerv, I must admit, I'm not sure I understand what you consider irrelevant reasons for 4.9.1 in the context of e-mail addresses. The only one I can think of is "7. The CA is made aware that a Wildcard Certificate has been used to authenticate a fraudulently misleading subordinate Fully-Qualified Domain Name;" But that's because such e-mail CAs are effectively wildcards (e.g. they can issue for subdomains, unless a nameconstraint includes a leading . to indicate for host not domain) I believe this is about end certificates, not constrained Intermediary CA certificates. But given that e-mail addresses include Domain portions (after all, that is the definition, localpart@domain), and Fully-Qualified Domain Name doesn't imply a sAN of type dNSName, this all seems... ok as is? Technically, the part after the @ could also be a bang!path, though this is rare these days. So maybe some wording in the Mozilla e-mail end cert requirements for how the phrase "Domain Name" in the TLS cert BRs maps to rfc822-names. Enjoy Jakob -- Jakob Bohm, CIO, Partner, WiseMo A/S. https://www.wisemo.com Transformervej 29, 2860 Søborg, Denmark. Direct +45 31 13 16 10 This public discussion message is non-binding and may contain errors. WiseMo - Remote Service Management for PCs, Phones and Embedded ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Policy 2.5 Proposal: Remove BR duplication: reasons for revocation
Gerv, I must admit, I'm not sure I understand what you consider irrelevant reasons for 4.9.1 in the context of e-mail addresses. The only one I can think of is "7. The CA is made aware that a Wildcard Certificate has been used to authenticate a fraudulently misleading subordinate Fully-Qualified Domain Name;" But that's because such e-mail CAs are effectively wildcards (e.g. they can issue for subdomains, unless a nameconstraint includes a leading . to indicate for host not domain) But given that e-mail addresses include Domain portions (after all, that is the definition, localpart@domain), and Fully-Qualified Domain Name doesn't imply a sAN of type dNSName, this all seems... ok as is? ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Policy 2.5 Proposal: Remove BR duplication: reasons for revocation
On 20/04/17 15:10, Jakob Bohm wrote: > Note that some reasons applicable to domain names would be equally > applicable to the domain name part of e-mail addresses. So can you read section 4.9.1 of the BRs and help me to define wording which excludes the irrelevant items while including all the relevant ones? I was particularly thinking of, if memory serves, 4.9.1.1 bullets 4 and 5, both of which use the defined term "Domain Name". Gerv ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy