Bonjour, Reading the Certificate Policy Specification v1.1 brings some questions.
« Hotspot 2.0 »-devices will probably include some specific root CA certificates (3 of them exist, DigiCert's is trusted by Microsoft since April 2016), this ballot is about allowing issuance of TLS certificates containing the Hotspot-FriendlyName SAN, so I guess there is some kind of bridge being made between « Hotspot 2.0 » and the WebPKI. - Hotspot 2.0 Root Certificates don’t follow CABF BR in the subject field; HS2.0 require « C=US, O=WFA Hotspot 2.0, CN=Hotspot 2.0 Trust Root CA - <ID#> », where CABF BR clause 7.1.2.1 has different expectations on C and O - HS2.0 Intermediate Certificates again don’t follow CABF BR for the NameConstraints extension; HS2.0 states that this extension shall not be critical, when CABF BR states that it SHOULD be critical; please keep in mind that RFC5280 says it MUST be critical, CABF has reduced this requirement to a SHOULD to accommodate Apple devices; now that recent versions of MacOS and iOS support the NC extension, is it really a good sign to lower again the requirements on this extension? - HS2.0 Intermediate Certificates let the CRLDP extension to be optional, when it’s mandatory for CABF BR - there has been some effort to standardize the SRVName name form (RFC4985), with (incomplete) Name Constraints matching rules. I don’t see any comparable effort for this hotspot-friendlyName name form. Since technically-constrained CAs is a preferred model for enterprises (and browsers), I think it’s preferable to describe the expected behaviour of a relying party facing such combinations before blindly allowing them, even more with the « shall not be critical » describe above, which will surely transform someday into a « I won’t implement it, it’s not critical anyway » and will bite us in the future. Cordialement, Erwann Abalea Le 3 janv. 2017 à 22:07, Jeremy Rowley via Public <[email protected]<mailto:[email protected]>> a écrit : Agreed, but this line of reasoning always leads to simply not supporting third party projects because the projects may cause issues with the CAB Forum update. IMO, if a group wants to use publicly trusted certs, then that group inherits all the baggage that goes with it. We really control all the cards on this one as the interoperability is one-way. What would you propose to make sure we can update requirements in the future? A statement like “CAB Forum can do whatever it wants without notice” is superfluous as this is already the case. Jeremy From: Ryan Sleevi [mailto:[email protected]] Sent: Tuesday, January 3, 2017 1:54 PM To: Jeremy Rowley <[email protected]<mailto:[email protected]>> Cc: CA/Browser Forum Public Discussion List <[email protected]<mailto:[email protected]>>; Peter Bowen <[email protected]<mailto:[email protected]>> Subject: Re: [cabfpub] Proposed Ballot 183 - Allowing 822 Names and (limited) otherNames On Tue, Jan 3, 2017 at 12:46 PM, Jeremy Rowley <[email protected]<mailto:[email protected]>> wrote: There is a public file (in the link I provided), but it requires filling out information to access. It’s the HotSpot 2.0 Technical documentation, which includes the Certificate Policy (“Hostspot 2-0 (R2) OSU Certificate Policy Specification”). The documentation is already free to anyone who wants to enter information and agree to the terms of use. Ah, the many meanings of free ;) I suppose it wasn't clear that I was talking more about freedom than beer there :) We essentially already have a liaison member from the WFA (DigiCert, Microsoft, Apple, and Google are all members). I wouldn't put Google in that list - none of Google's CA/B Forum participants participate in HotSpot 2.0 nor communicate developments on either side of that profile to the other party. I would suggest, to date, only DigiCert does, and only to the extent you've shared anything to the Forum. Obviously, the context was that we shouldn't be introducing this to the Web PKI unless we're sure we're not going to repeat all the same mistakes we're currently going through the SHA-1 exception process - or at least trying to learn from them. It would be foolish to ignore the feedback we've received from those affected by SHA-1 when considering expanding that scope. _______________________________________________ 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
