[cabfpub] Proposed new ballot on IP Addresses in SANs

Rich Smith richard.smith at comodo.com
Sat Apr 23 03:08:05 UTC 2016

I pointed you to the deprecation schedule for Windows 8: January 10, 2023

On 4/22/2016 6:08 PM, Jeremy Rowley wrote:
> I think this depends on when Microsoft deprecates Windows 8.
> *From:*Rich Smith [mailto:richard.smith at comodo.com]
> *Sent:* Friday, April 22, 2016 4:30 PM
> *To:* Jeremy Rowley <jeremy.rowley at digicert.com>
> *Cc:* public at cabforum.org
> *Subject:* Re: [cabfpub] Proposed new ballot on IP Addresses in SANs
> OK, what's the phase out period, because anything less than 7 years is 
> going to REQUIRE Microsoft to agree to start back porting critical 
> fixes to their older operating systems, and since it's been made 
> abundantly clear on numerous occasions that this Forum has no power to 
> enforce, or even set, requirements for PKI trust stores/browser 
> vendors what teeth do we possibly have to make sure that happens?
> -Rich
> On 4/22/2016 4:23 PM, Jeremy Rowley wrote:
>     That's exactly why we should endorse with a phase out period.
>     *From:*public-bounces at cabforum.org
>     <mailto: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 <mailto: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:
>     http://windows.microsoft.com/en-us/windows/lifecycle
>     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.
>     -Rich
>     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
>             (https://cabforum.org/pipermail/public/2015-August/005850.html).
>         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>
>         https://cabforum.org/mailman/listinfo/public

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cabforum.org/pipermail/public/attachments/20160422/0c4b3571/attachment-0003.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4035 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://lists.cabforum.org/pipermail/public/attachments/20160422/0c4b3571/attachment-0001.p7s>

More information about the Public mailing list