[cabfpub] Proposed new ballot on IP Addresses in SANs

Fri Apr 22 22:21:28 UTC 2016

+1. Here's my proposed ballot language (incorporating SRV names as well):

Revise 7.1.4.2.1 as follows:
Certificate Field: extensions:subjectAltName 
Required/Optional: Required 
Contents: This extension MUST contain at least one entry. Each entry MUST be a dNSName, iPAddress, or otherName of type SRVName as defined in RFC 4985. Each dNSName MUST include either a Full-Qualified Domain Name verified under Section 3.2.2.4 or an IP address verified under Section 3.2.2.5.  Each iPAddress MUST contain the IP address of a server. Each IP adderss included in a dNSName entry MUST also be included iPAddress entry.  As exceptions to RFC5280 and X.509, wildcard characters (as limited under Section 3.2.2.6) and underscore characters ("_") are permitted in dNSName.  Underscore characters are permitted in Domain Names in any location where the hyphen character ("-") is allowed. Wildcard characters are not permitted in otherName entries. If a name constrained CA has a dNSName constraint but does not have a constraint for SRVNames, the CA MUST NOT issue certificates containing SRVNames where the Name portion is in an excluded dNSName subtree.  Such a CA also MUST NOT issue certificates containing SRVNames where the Name portion is not in a permitted dNSName subtree if at least one permitted dNSName subtree exists. Certificates MUST not include a subjectAlternativeName extension or Subject commonName field that contains a Reserved IP Address or Internal Name other than as permitted in Appendix F."

In section 7.1.4.2.2(a), append the following sentences to "Contents": 
'If the value from the subjectAltName extension contains at least one label that starts with "xn--" (an "A-label"), this field may contain the Unicode encoding of the A-labels (an "U-label"), provided that all A-labels in the value are converted to U-labels. There MUST NOT be more than one commonName attribute in the Subject Distinguished Name.’

Jeremy

-----Original Message-----
From: public-bounces at cabforum.org [mailto:public-bounces at cabforum.org] On Behalf Of Peter Bowen
Sent: Friday, April 22, 2016 1:45 PM
To: Ryan Sleevi <sleevi at google.com>
Cc: Rick Andrews <Rick_Andrews at symantec.com>; public at cabforum.org
Subject: Re: [cabfpub] Proposed new ballot on IP Addresses in SANs

> On Apr 21, 2016, at 1:09 PM, Ryan Sleevi <sleevi at google.com> wrote:
> 
> 
> 
> On Thu, Apr 21, 2016 at 1:06 PM, Doug Beattie <doug.beattie at globalsign.com> wrote:
> 
> 
> Ryan – This sounds like a possible solution.  Would you support a ballot that allows the issuance of BR compliant certificates containing IP addresses in the dNSName if and only if the same value is also in an iPAddress SAN field?  This comment was within the contest of Name Constraints, so I could be misinterpreting your suggestion.
> 
> 
> 
> 
> No, we will not support any such ballot without Forum members who feel there is a need for it, and who can provide demonstration, evidence, and discussion as to why the conforming solution proposed 8 months ago is not viable.

Ryan,

It is clear that Microsoft SChannel/CryptoAPI on versions of Windows other than Windows 10 does not handle iPAddress entries in the Subject Alternative Name extension.  The “conforming solution” proposed 8 months ago was to place the string-ified IP address commonName attributes.  However as recently discussed on another thread on this mailing list, multiple commonNames in a certificate cause a different set of issues and commonName is also deprecated.  So it would seem that this solution might not be the best option.

The best solution would be for clients to be updated to follow RFC 2818 and check iPAddress entries in the SAN.  Failing that, it is unclear why placing the string-ified IP in common name is any better than placing it in the dnsname.  RFC 2818 does not provide for either option — it says the URIs with IP addresses instead of hostnames must be checked against IPaddress entries in the SAN and does not provide a fallback to common name.

To me, it seems that allowing string-ified IP address in dNSName entries in the SAN when the same IP address is included as an iPAddress entry in the SAN is a reasonable tradeoff.  It is no worse than including the same in the common name.  As you have pointed out, a string-ified IP address can never match a hostname, so there is no chance of confusion  If you have a client that properly conforms to RFC 2818, then this is a no-op for you — you will look at the IPaddress entry and never try to match on DNSname.  You had expressed concern that Mozilla would need to update its code, but Gerv had indicated back in August that this was not necessary (https://cabforum.org/pipermail/public/2015-August/005850.html).

I appreciate that conformance is a great goal, but not causing customer pain is also a laudable goal.  In this case it seems the risk is low and the customer value is high.

Thanks,
Peter
_______________________________________________
Public mailing list
Public at cabforum.org
https://cabforum.org/mailman/listinfo/public
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4964 bytes
Desc: not available
URL: <http://lists.cabforum.org/pipermail/public/attachments/20160422/2d89c041/attachment-0001.p7s>