<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body text="#000000" bgcolor="#FFFFFF">
<p class="MsoNormal"> - 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?<o:p></o:p></p>
[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.<br>
<br>
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.<br>
Scenario:<br>
We ignore this and Ryan's arguments against, and we pass this
proposal. <br>
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.<br>
<br>
-Rich<br>
<br>
<div class="moz-cite-prefix">On 1/4/2017 11:44 AM, Jeremy Rowley via
Public wrote:<br>
</div>
<blockquote
cite="mid:27c9857a5f9b4bc4a87ebb9600598346@EX1.corp.digicert.com"
type="cite">
<meta http-equiv="Content-Type" content="text/html;
charset=ISO-8859-1">
<meta name="Generator" content="Microsoft Word 15 (filtered
medium)">
<style><!--
/* Font Definitions */
@font-face
{font-family:Helvetica;
panose-1:2 11 6 4 2 2 2 2 2 4;}
@font-face
{font-family:"Cambria Math";
panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
{font-family:Calibri;
panose-1:2 15 5 2 2 2 4 3 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0in;
margin-bottom:.0001pt;
font-size:12.0pt;
font-family:"Times New Roman",serif;}
a:link, span.MsoHyperlink
{mso-style-priority:99;
color:blue;
text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
{mso-style-priority:99;
color:purple;
text-decoration:underline;}
p.msonormal0, li.msonormal0, div.msonormal0
{mso-style-name:msonormal;
mso-margin-top-alt:auto;
margin-right:0in;
mso-margin-bottom-alt:auto;
margin-left:0in;
font-size:12.0pt;
font-family:"Times New Roman",serif;}
span.apple-converted-space
{mso-style-name:apple-converted-space;}
span.EmailStyle19
{mso-style-type:personal-reply;
font-family:"Calibri",sans-serif;
color:windowtext;}
.MsoChpDefault
{mso-style-type:export-only;
font-size:10.0pt;}
@page WordSection1
{size:8.5in 11.0in;
margin:1.0in 1.0in 1.0in 1.0in;}
div.WordSection1
{page:WordSection1;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext="edit">
<o:idmap v:ext="edit" data="1" />
</o:shapelayout></xml><![endif]-->
<div class="WordSection1">
<p class="MsoNormal">Thanks Erwann for looking at this.<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal"> - 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<o:p></o:p></p>
<div>
<p class="MsoNormal">[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. <o:p></o:p></p>
<p class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Calibri",sans-serif"><o:p> </o:p></span></p>
<p class="MsoNormal"> - 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?<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">[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.<o:p></o:p></p>
<p class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Calibri",sans-serif"><o:p> </o:p></span></p>
<p class="MsoNormal"> - HS2.0 Intermediate Certificates let
the CRLDP extension to be optional, when it’s mandatory for
CABF BR<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">[JR] This is not inconsistent. Anyone
wanting to issue publicly trusted Hotspot certs would be
required to have a CRLDP extension in the intermediate. <o:p></o:p></p>
<p class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Calibri",sans-serif"><o:p> </o:p></span></p>
<p class="MsoNormal"> - 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.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">[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. <o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">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. <o:p></o:p></p>
<p class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Calibri",sans-serif"><o:p> </o:p></span></p>
<p class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Calibri",sans-serif">Jeremy<o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<div>
<blockquote style="margin-top:5.0pt;margin-bottom:5.0pt">
<div>
<p class="MsoNormal">Le 3 janv. 2017 à 22:07, Jeremy
Rowley via Public <<a moz-do-not-send="true"
href="mailto:public@cabforum.org">public@cabforum.org</a>>
a écrit :<o:p></o:p></p>
</div>
<p class="MsoNormal"><o:p> </o:p></p>
<div>
<div>
<p class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Calibri",sans-serif">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.</span><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Calibri",sans-serif"> </span><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Calibri",sans-serif">Jeremy</span><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Calibri",sans-serif"> </span><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><b><span
style="font-size:11.0pt;font-family:"Calibri",sans-serif">From:</span></b><span
class="apple-converted-space"><span
style="font-size:11.0pt;font-family:"Calibri",sans-serif"> </span></span><span
style="font-size:11.0pt;font-family:"Calibri",sans-serif">Ryan
Sleevi [<a moz-do-not-send="true"
href="mailto:sleevi@google.com">mailto:sleevi@google.com</a>]<span
class="apple-converted-space"> </span><br>
<b>Sent:</b><span class="apple-converted-space"> </span>Tuesday,
January 3, 2017 1:54 PM<br>
<b>To:</b><span class="apple-converted-space"> </span>Jeremy
Rowley <<a moz-do-not-send="true"
href="mailto:jeremy.rowley@digicert.com">jeremy.rowley@digicert.com</a>><br>
<b>Cc:</b><span class="apple-converted-space"> </span>CA/Browser
Forum Public Discussion List <<a
moz-do-not-send="true"
href="mailto:public@cabforum.org">public@cabforum.org</a>>;
Peter Bowen <<a moz-do-not-send="true"
href="mailto:pzb@amzn.com">pzb@amzn.com</a>><br>
<b>Subject:</b><span class="apple-converted-space"> </span>Re:
[cabfpub] Proposed Ballot 183 - Allowing 822 Names
and (limited) otherNames</span><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"> <o:p></o:p></p>
</div>
<div>
<div>
<p class="MsoNormal"> <o:p></o:p></p>
</div>
<div>
<div>
<p class="MsoNormal"> <o:p></o:p></p>
</div>
<div>
<div>
<p class="MsoNormal">On Tue, Jan 3, 2017 at
12:46 PM, Jeremy Rowley <<a
moz-do-not-send="true"
href="mailto:jeremy.rowley@digicert.com"
target="_blank"><span style="color:purple">jeremy.rowley@digicert.com</span></a>>
wrote:<o:p></o:p></p>
</div>
<blockquote style="border:none;border-left:solid
#CCCCCC 1.0pt;padding:0in 0in 0in
6.0pt;margin-left:4.8pt;margin-top:5.0pt;margin-right:0in;margin-bottom:5.0pt">
<div>
<div>
<div>
<p class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Calibri",sans-serif">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. </span><o:p></o:p></p>
</div>
</div>
</div>
</blockquote>
<div>
<div>
<p class="MsoNormal"> <o:p></o:p></p>
</div>
</div>
<div>
<div>
<p class="MsoNormal">Ah, the many meanings of
free ;) I suppose it wasn't clear that I was
talking more about freedom than beer there
:)<o:p></o:p></p>
</div>
</div>
<div>
<div>
<p class="MsoNormal"> <span
style="font-size:11.0pt;font-family:"Calibri",sans-serif"> </span><o:p></o:p></p>
</div>
</div>
<blockquote style="border:none;border-left:solid
#CCCCCC 1.0pt;padding:0in 0in 0in
6.0pt;margin-left:4.8pt;margin-top:5.0pt;margin-right:0in;margin-bottom:5.0pt">
<div>
<div>
<div>
<p class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Calibri",sans-serif">We
essentially already have a liaison
member from the WFA (DigiCert,
Microsoft, Apple, and Google are all
members).</span><o:p></o:p></p>
</div>
</div>
</div>
</blockquote>
<div>
<div>
<p class="MsoNormal"> <o:p></o:p></p>
</div>
</div>
<div>
<div>
<p class="MsoNormal">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.<o:p></o:p></p>
</div>
</div>
<div>
<div>
<p class="MsoNormal"> <o:p></o:p></p>
</div>
</div>
<div>
<div>
<p class="MsoNormal">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. <o:p></o:p></p>
</div>
</div>
</div>
</div>
</div>
<p class="MsoNormal"><span
style="font-size:9.0pt;font-family:"Helvetica",sans-serif">_______________________________________________<br>
Public mailing list<br>
<a moz-do-not-send="true"
href="mailto:Public@cabforum.org">Public@cabforum.org</a><br>
<a moz-do-not-send="true"
href="https://cabforum.org/mailman/listinfo/public">https://cabforum.org/mailman/listinfo/public</a></span><o:p></o:p></p>
</div>
</blockquote>
</div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
</div>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
<pre wrap="">_______________________________________________
Public mailing list
<a class="moz-txt-link-abbreviated" href="mailto:Public@cabforum.org">Public@cabforum.org</a>
<a class="moz-txt-link-freetext" href="https://cabforum.org/mailman/listinfo/public">https://cabforum.org/mailman/listinfo/public</a>
</pre>
</blockquote>
<br>
</body>
</html>