[cabfpub] Proposed Ballot 183 - Allowing 822 Names and (limited) otherNames
Erwann.Abalea at docusign.com
Wed Jan 4 19:48:14 UTC 2017
See my comments below.
Le 4 janv. 2017 à 18:44, Jeremy Rowley <jeremy.rowley at digicert.com<mailto:jeremy.rowley at digicert.com>> a écrit :
Thanks Erwann for looking at this.
- 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 18.104.22.168 has different expectations on C and O
[JR] I disagree. C the O both accurately represent the CA in this case (the WFA). Although DigiCert operates a root on behalf of the WFA, I believe the CA in this case is the WFA.
For Microsoft, it seems that the CA (organization) behind the CA (PKIX) named « C=US,O=WFA Hotspot 2.0,CN=Hotspot 2.0 Trust Root CA - 03 » is DigiCert, not the WFA.
- 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?
[JR] This is complaint with the current BRs. It doesn’t lower the requirements on the extension as no change to the BRs is required for the root to issue publicly trusted certs.
I was hoping for a SHOULD->MUST change for this extension in a near future. Clause 22.214.171.124 contains a footnote about that.
- HS2.0 Intermediate Certificates let the CRLDP extension to be optional, when it’s mandatory for CABF BR
[JR] This is not inconsistent. Anyone wanting to issue publicly trusted Hotspot certs would be required to have a CRLDP extension in the intermediate.
Granted. Since it’s optional, it can be included.
- 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.
[JR] I4985 has been around since 2007. The WFA friendly name has only existed since 2015. I can bring up technically constrained Sub CAs with the WFA (they’d be open to it), but I do not think the lack of a standardized version of technical constraints creates an inconsistency between the BRs and the WFA CP. Until name constraints are fully defined for friendly names, the cert would never qualify as technically constrained, meaning an audit would be required for each publicly trusted intermediate, etc.
Technically-constrained CA certificates is already an option. Table 3 of the Hotspot 2.0 CP specs contains:
nameConstraints Shall not be critical. The field may include one or more « dNSName » values that provide the domain range of certificates issued. Note - the SP Friendly Name and the Icon hash are included in intermediate certs issued to service providers and serve the function of constraining the certificate usage.
But how this constraint is supposed to be applied is not defined.
The only change in the BRs I’m asking for is to permit WFA otherNames. As browsers don’t currently use the otherName, they won’t be affected by the modification, especially the certs themselves would be completely compliant with the BR requirements.
BR define technically-constrained CA certificates as containing an EKU without anyExtendedKeyUsage, plus the NameConstraints extension with specific requirements on dNSName, iPAddress, and DirectoryName. A CA certificate containing these extensions (EKU+NC) without any otherName:hotspot-friendlyName is still considered a technically-constrained certificate, not subject to a full audit in line with BR clause 8, but still capable of issuing certificates bypassing any technical constraints that should have applied (since they’re not defined).
Regarding the validation of the friendlyName, the WIPO ROMARIN is listed as a valid source, but looking at this source for trademarks listed on www.wi-fi.org<http://www.wi-fi.org> shows that only the WiGig CERTIFIED and associated logo are detained by the Wi-Fi Alliance. Strange.
Le 3 janv. 2017 à 22:07, Jeremy Rowley via Public <public at cabforum.org<mailto:public at cabforum.org>> 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.
From: Ryan Sleevi [mailto:sleevi at google.com]
Sent: Tuesday, January 3, 2017 1:54 PM
To: Jeremy Rowley <jeremy.rowley at digicert.com<mailto:jeremy.rowley at digicert.com>>
Cc: CA/Browser Forum Public Discussion List <public at cabforum.org<mailto:public at cabforum.org>>; Peter Bowen <pzb at amzn.com<mailto:pzb at amzn.com>>
Subject: Re: [cabfpub] Proposed Ballot 183 - Allowing 822 Names and (limited) otherNames
On Tue, Jan 3, 2017 at 12:46 PM, Jeremy Rowley <jeremy.rowley at digicert.com<mailto:jeremy.rowley at digicert.com>> wrote:
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
Public at cabforum.org<mailto:Public at cabforum.org>
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Public