"3) a rfc822Name containing an RFC 5322 email address"
Hi Jeremy. I see why you've written that (5322 obsoleted 2822, which
obsoleted 822, and "822" appears in the string "rfc822Name"). However,
I think it would be better to defer to 5280, since that is the document
that defines the rfc822Name field. RFC5280 section 4.2.1.6 says:
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.
(Neither 5280 nor 2821 have been updated by any newer RFCs)
BTW, I don't see any requirement in this ballot to validate the email
address in any way before putting it into an rfc822Name field. Is that
intentional?
On 03/01/17 20:32, Jeremy Rowley via Public wrote:
They don’t publish a lot of information publicly. The documentation for
how they use friendly-names is here:
https://www.wi-fi.org/discover-wi-fi/wi-fi-certified-passpoint. As WFA
is an actual organization, a single mebmer saying something okay is not
the same as the entity approving something, but I see your point.
Perhaps something that specifies it must be ratified and published (_For
each id-wfa-hotspot-friendlyName entry, the CA MUST only include entries
after receiving permission from the WiFi Alliance to utilize the
id-wfa-hotspot-friendlyName type and MUST verify each entry in
accordance with the requirements ratified and published by the WiFi
Alliance. )?_
*7.1.4.2.1. Subject Alternative Name Extension *
Certificate Field: extensions:subjectAltName
Required/Optional: Required
Contents: This extension MUST contain at least one entry. Each entry
MUST be _one of the following entries: 1) _either a dNSName
containing the Fully‐Qualified Domain Name_or a Wildcard Domain
Name, 2) _ or an iPAddress containing the IP address of a server,_3)
a rfc822Name containing an RFC 5322 email address, 4) an otherName
with a id-wfa-hotspot-friendlyName type { 1.3.6.1.4.1.40808.1.1.1 }
or 5) an otherName of type SRVName as defined in RFC4986. _ _T_he CA
MUST confirm _each entry as follows:_
A) _For each dNSName entry, the CA MUST verify the entry in
accordance with Section 3.2.2.4;_
B) _For each SRVName entry, the CA MUST verify the Name portion
of the entry in accordance with Section 3.2.2.4;_
C) _For each iPAddress entry, the CA MUST verify the entry in
accordance with Section 3.2.2.5;_
D) _For each id-wfa-hotspot-friendlyName entry, the CA MUST
only include entries after receiving permission from the WiFi
Alliance to utilize the id-wfa-hotspot-friendlyName type and MUST
verify each entry in accordance with the requirements ratified and
published by the WiFi Alliance. _
_As an exception to RFC5280 and X.509, dNSName entries MAY contain
Wildcard Domain Names. SRVName entries MUST NOT contain Wildcard
Domain Names. If a name constrained CA has a dNSNAme constrain but
does not have a constraint for SRVNames, the CA MUST NOT issue
certificates containing SRVNames._
that the Applicant controls the Fully‐Qualified Domain Name or IP
address or has been granted the right to use it by the Domain Name
Registrant or IP address assignee, as appropriate. Wildcard FQDNs
are permitted.
_For dNSNames, SRVNames, and iPAddress entries: _
As of the Effective Date of these Requirements, prior to the
issuance of a Certificate with a subjectAlternativeName extension or
Subject commonName field containing a Reserved IP Address or
Internal Name, the CA SHALL notify the Applicant that the use of
such Certificates has been deprecated by the CA / Browser Forum and
that the practice will be eliminated by October 2016. Also as of the
Effective Date, the CA SHALL NOT issue a certificate with an Expiry
Date later than 1 November 2015 with a subjectAlternativeName
extension or Subject commonName field containing a Reserved IP
Address or Internal Name. Effective 1 October 2016, CAs SHALL revoke
all unexpired Certificates whose subjectAlternativeName extension or
Subject commonName field contains a Reserved IP Address or Internal
Name. Effective May 1, 2015, each CA SHALL revoke all unexpired
Certificates with an Internal Name using onion as the right‐most
label in an entry in the subjectAltName Extension or commonName
field unless such Certificate was issued in accordance with Appendix
F of the EV Guidelines.
--
Rob Stradling
Senior Research & Development Scientist
COMODO - Creating Trust Online
_______________________________________________
Public mailing list
[email protected]
https://cabforum.org/mailman/listinfo/public
