[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