I’m not sure why we want an email address for a SAN either. If there is a case 
for an email address, would it be an alternative put it in the subject name 
instead of the SAN? I think that this can be done per BR 7.1.4.2.2.j.

Bruce.

From: Public [mailto:[email protected]] On Behalf Of Ryan Sleevi via 
Public
Sent: Wednesday, January 4, 2017 8:20 PM
To: CA/Browser Forum Public Discussion List <[email protected]>
Cc: Ryan Sleevi <[email protected]>
Subject: Re: [cabfpub] Ballot 184: rfc822Names and otherNames

How tied are you to allowing rfc822Name? "Reasonable measures" feels very much 
like the "any equivalent method", and it also feels very much like it will open 
up the gates of S/MIME, for which the GovReform is still working through.

For example, can you incorporate language such as 3.2.2.4.2 / 3.2.2.4.4 to 
specify more explicitly what 'reasonable' means? Can you remove it entirely?

I'm still very uncertain about the value proposition of 7.1.4.2.1.3 / 
7.1.4.2.1.5 and why it's desirable, at all, to use BR-compliant CAs for that. 
I'm hoping you can make a compelling case here.

On Wed, Jan 4, 2017 at 5:03 PM, Jeremy Rowley via Public 
<[email protected]<mailto:[email protected]>> wrote:
Thank you everyone for the feedback so far. Attached is an updated draft based 
on the comments provided. Apologies for the lack of redlining, but I 
reformatted the entire section into various permitted entries (thanks Gerv) 
which made the entire thing more readable. Let me know what you think.
Jeremy
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 where each included 
entry is one of the following:
7.1.4.2.1.1. dNSName

The subjectAltName extension MAY include one or more dNSName entries provided 
each entry is either a Fully‐Qualified Domain Name or a Wildcard Domain Name. 
The CA MUST verify each Fully-Qualified Domain Name and Wildcard Domain Name 
entry in accordance with Section 3.2.2.4.

Except where the entry is an Internal Name using onion as the right‐most label 
in an entry in the subjectAltName Extension or commonName field in accordance 
with Appendix F of the EV Guidelines, a dNSName entry MUST NOT contain an 
Internal Name.
7.1.4.2.1.2. iPAddress

The subjectAltName MAY include one or more iPAddress entries provided each 
entry is an IP address verified in accordance with Section 3.2.2.5. The entry 
MUST NOT contain a Reserved IP Address.
7.1.4.2.1.3. rfc822Name

The subjectAltName MAY include one or more rfc822Name entries provided each 
entry is an email address compliant with RFC5280. Prior to including an email 
address, the CA MUST take reasonable measures to verify that the entity 
submitting the request controls the email account associated with the email 
address referenced in the certificate or has been authorized by the email 
account holder to act on the account holder’s behalf.
7.1.4.2.1.4. otherName with SRVName { 1.3.6.1.5.5.7.0.18.8.7 } type-id

The subjectAltName MAY include one or more SRVNames (as defined in RFC4986) as 
an otherName entry with the SRVName type-id. The CA MUST verify the name 
portion of the entry in accordance with Section 3.2.2.4. SRVName entries MUST 
NOT contain Wildcard Domain Names. If a Technically Constrained Subordinate CA 
Certificate includes a dNSName constraint but does not have a technical 
constraint for SRVNames, the CA MUST NOT issue certificates containing SRVNames 
from the Technically Constrained Subordinate CA Certificate. A Technically 
Constrained Subordinate CA Certificate that includes a technical constraint for 
SRVNames MUST include permitted name subtrees and MAY include excluded name 
subtrees.
7.1.4.2.1.5. otherName with id-wfa-hotspot-friendlyName { 
1.3.6.1.4.1.40808.1.1.1 } type-id

The subjectAltName MAY include one or more entries of the 
id-wfa-hotspot-friendlyName type-id. The CA MAY only include 
id-wfa-hotpost-friendlyName entries compliant with the Hotspot OSU Certificate 
Policy as officially published by the Wi-Fi Alliance at 
https://www.wi-fi.org<https://www.wi-fi.org/discover-wi-fi/wi-fi-certified-passpoint>.
 Prior to including a id-wfa-hotpost-friendlyName  entry, the CA MUST:

A)      Authenticate the authority of the certificate requester in accordance 
with Section 3.2.5;

B)      Authenticate the Subject Identity information in accordance with 
Section 3.2.2.1; and

C)      Conduct a trademark search for the entry with the U.S. Patent and 
Trademark Office and equivalent international trademark office such as the WIPO 
ROMARIN.




_______________________________________________
Public mailing list
[email protected]<mailto:[email protected]>
https://cabforum.org/mailman/listinfo/public

_______________________________________________
Public mailing list
[email protected]
https://cabforum.org/mailman/listinfo/public

Reply via email to