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

Reply via email to