[cabfpub] Proposed new ballot on IP Addresses in SANs

Jeremy Rowley jeremy.rowley at digicert.com
Fri Apr 22 22:23:00 UTC 2016

That's exactly why we should endorse with a phase out period.


From: public-bounces at cabforum.org [mailto:public-bounces at cabforum.org] On
Behalf Of Rich Smith
Sent: Friday, April 22, 2016 4:13 PM
To: public at cabforum.org
Subject: Re: [cabfpub] Proposed new ballot on IP Addresses in SANs


I'd just like to also point out that given Microsoft's apparent lack of
interest in back porting any of these changes to their PKI handling to
anything older than Windows 10, and based upon this:
Any exception made will be with us until at least January 10, 2023.  I don't
really see that as something this group should endorse.


On 4/22/2016 3:44 PM, Ryan Sleevi wrote:



On Fri, Apr 22, 2016 at 12:45 PM, Peter Bowen <pzb at amzn.com
<mailto:pzb at amzn.com> > wrote:

So it would seem that this solution might not be the best option.


"Not the best" isn't the goal. It's "Don't violate RFC5280" that should be
the goal.


Multiple SANs is a complete red-herring as to the issue. There's no
requirement that such certificates have them.


Common name deprecation is equally a red-herring. If it offers a viable path
for these clients, without the attendant security issues and *fundamental
violation of RFC5280*, it's worth exploring.


That there's been no further explanation other than "Meh" is,
unquestionably, not a position we can endorse, but even moreso, a policy of
"Oh well, we'll violate them anyways" is just grossly irresponsible.


The best solution would be for clients to be updated to follow RFC 2818 and
check iPAddress entries in the SAN.


Indeed, and Microsoft can solve this very easily, without the same risks and
compatibility issues of nameConstraints.


We considered the RFC5280 non-criticality of nameConstraints because it
offered significant positive security value for a majority of clients,
without compatibility risks. The iPAddresses provide no positive security
value - other than allowing CAs to sell to users with buggy software that
their vendor doesn't want to fix - and come with significant compatibility
and security risks.


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 


I've already explained to you why this is incorrect. It's unfortunate that
you continue to suggest this line of thinking. A string-ified IP address is
not a valid hostname.


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


That's not what is in the ballot. What is in the ballot can and will cause
compatibility issues. It also suggests that Chrome would need to adopt
Firefox's peculiar behaviour (only validating presented identifiers as
they're encountered, rather than at parse time). That's not something we are
comfortable with implementing, and especially not foisting upon the
ecosystem to know about the "special" rules the CA/B Forum embraces. There's
already enough magic in the WebPKI - we shouldn't knowingly introduce more.


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.


There has yet to be a demonstration of the customer value compared to the
solution posed 8 months ago.  There's clearly a demonstration of CA value -
they do less work - and of browser value - Microsoft does less work - but
there has yet to be an articulation of why the solution is non-viable. The
closest comment is Jeremy saying they've investigated, it's not practical -
but provided zero evidence or technical detail that would allow a reasoned
weighing of the risk versus reward. Instead, we see CAs eager to violate
RFC5280, easy to cause compatibility issues with clients, and w/o apparent
care for the long-term damage to the ecosystem they would be doing.

Public mailing list
Public at cabforum.org <mailto:Public at cabforum.org> 


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cabforum.org/pipermail/public/attachments/20160422/0d3296a5/attachment-0003.html>
-------------- 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/0d3296a5/attachment-0001.p7s>

More information about the Public mailing list