OK, but this scenario is a clear illustration of the concerns that Ryan
has raised. The WFA would have to agree to do so, and even assuming
they did, given that the certs for their purposes, unless I'm
misunderstanding the case, are largely for devices which once in the
hands of the end users, are not easy to force an upgrade on, and which
could then be 'broken' w/out such an upgrade if they encounter a cert
with name constraints marked critical, because the designers followed
WFAs current spec and coded it to expect non critical. It really
doesn't seem at all dissimilar to the SHA-1 problem with payment
processors at all. So how long would the CA/B Forum then have to wait
to move. Another industry with their own agenda asking the CA/B Forum
to slow down or make exceptions. Up to now that is something that most
of the Forum has largely been in agreement should be discouraged.
This can be gotten around, but I think I'm in agreement w/Ryan that it
requires WFA participation in the CA/B Forum which is not possible until
we sort out the governance questions. IMO, in order to move forward
with this proposal, the WFA needs to join the Forum as a trust store
operator and make their PKI subservient to BR compliance.
-Rich
On 1/9/2017 11:43 AM, Jeremy Rowley wrote:
More likely I'll ask the WFA change their name constraints to
"Required". Their rationale against name constraints was the same as
the CAB Forum -- that Apple didn't support it at the time.
*From:*Public [mailto:[email protected]] *On Behalf Of *Rich
Smith via Public
*Sent:* Monday, January 9, 2017 10:40 AM
*To:* [email protected]
*Cc:* Rich Smith <[email protected]>
*Subject:* Re: [cabfpub] Proposed Ballot 183 - Allowing 822 Names and
(limited) otherNames
- 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.
No, it doesn't lower the requirement, but it does give Digicert
incentive to argue against increasing the requirement when the time
comes to do so. If memory serves our intent when we made the decision
to make the criticality of name constraints a SHOULD rather than a
MUST, thereby bucking the RFC5280 requirement, we did so both
reluctantly, and with the intent that we would update this to a MUST
as soon as it was feasible to do so w/out adversely affecting a
massive number of relying parties. I think the discrepancy in
policies here is far more serious than you are allowing for, and lends
credence to Ryan's arguments against this proposal.
Scenario:
We ignore this and Ryan's arguments against, and we pass this proposal.
Next month we decide that the various browsers all now have enough
support for critical name constraints to update the BRs to MUST, but
because it will break your newly authorized dual-use certs Digicert is
now arguing against bringing the BRs back into full compliance w/RFC5280.
-Rich
On 1/4/2017 11:44 AM, Jeremy Rowley via Public wrote:
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 7.1.2.1 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.
- 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.
- 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.
- 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.
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.
Jeremy
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] <mailto:[email protected]>
https://cabforum.org/mailman/listinfo/public
_______________________________________________
Public mailing list
[email protected]
https://cabforum.org/mailman/listinfo/public
