[cabfpub] Proposed Ballot 183 - Allowing 822 Names and (limited) otherNames

Jeremy Rowley jeremy.rowley at digicert.com
Mon Jan 9 10:50:29 MST 2017


Arguing that DigiCert (or another CA) *might* do something gin the future is
an odd argument but seems to occur over and over again. Better vote against
short-lived certificates as DigiCert already offers short-lived certs and it
might give them an incentive to continue issuing them. CAA invented by
Comodo? There’s something sinister there  – better not adopt it. Better not
adopt CT as DigiCert already operates a CT log and it potentially forces
other CAs use their log. All CAs have incentives behind their votes (whether
it is the good of the community, increased security, or simply profits), and
voting for or against something just to mess with the CA or because one CA
seems to like the idea seems counter-productive.

 

From: Public [mailto:public-bounces at cabforum.org] On Behalf Of Rich Smith
via Public
Sent: Monday, January 9, 2017 10:40 AM
To: public at cabforum.org
Cc: Rich Smith <richard.smith at comodo.com>
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 <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.

 

Jeremy

 

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 <
<mailto:jeremy.rowley at digicert.com> jeremy.rowley at digicert.com> 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
Public at cabforum.org <mailto:Public at cabforum.org> 
https://cabforum.org/mailman/listinfo/public

 






_______________________________________________
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://cabforum.org/pipermail/public/attachments/20170109/0386776c/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4964 bytes
Desc: not available
URL: <http://cabforum.org/pipermail/public/attachments/20170109/0386776c/attachment-0001.bin>


More information about the Public mailing list