[cabfpub] Proposed Ballot 183 - Allowing 822 Names and (limited) otherNames
Jeremy Rowley
jeremy.rowley at digicert.com
Tue Jan 3 14:15:02 MST 2017
Ah - good point.
The omission of email validation was not intentional. I had it the previous version but omitted the language when combining the SRV text. I'll re-add the language once we've agreed on the friendly name portion. Thanks Rob!
Jeremy
-----Original Message-----
From: Rob Stradling [mailto:rob.stradling at comodo.com]
Sent: Tuesday, January 3, 2017 2:10 PM
To: Jeremy Rowley <jeremy.rowley at digicert.com>
Cc: CA/Browser Forum Public Discussion List <public at cabforum.org>; Ryan Sleevi <sleevi at google.com>
Subject: Re: [cabfpub] Proposed Ballot 183 - Allowing 822 Names and (limited) otherNames
"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 at 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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4964 bytes
Desc: not available
URL: <http://cabforum.org/pipermail/public/attachments/20170103/467a88f5/attachment-0001.bin>
More information about the Public
mailing list