[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