<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body text="#000000" bgcolor="#FFFFFF">
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.<br>
<br>
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.<br>
<br>
-Rich<br>
<br>
<div class="moz-cite-prefix">On 1/9/2017 11:43 AM, Jeremy Rowley
wrote:<br>
</div>
<blockquote
cite="mid:b58d55739fd043429c29ab7963ea1743@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;}
@font-face
{font-family:Consolas;
panose-1:2 11 6 9 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;
color:black;}
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;}
pre
{mso-style-priority:99;
mso-style-link:"HTML Preformatted Char";
margin:0in;
margin-bottom:.0001pt;
font-size:10.0pt;
font-family:"Courier New";
color:black;}
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;
color:black;}
span.apple-converted-space
{mso-style-name:apple-converted-space;}
span.EmailStyle19
{mso-style-type:personal;
font-family:"Calibri",sans-serif;
color:windowtext;}
span.HTMLPreformattedChar
{mso-style-name:"HTML Preformatted Char";
mso-style-priority:99;
mso-style-link:"HTML Preformatted";
font-family:Consolas;
color:black;}
span.EmailStyle22
{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"><span
style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:windowtext">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. <o:p></o:p></span></p>
<p class="MsoNormal"><a moz-do-not-send="true"
name="_MailEndCompose"><span
style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:windowtext"><o:p> </o:p></span></a></p>
<span style="mso-bookmark:_MailEndCompose"></span>
<div>
<div style="border:none;border-top:solid #E1E1E1
1.0pt;padding:3.0pt 0in 0in 0in">
<p class="MsoNormal"><b><span
style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:windowtext">From:</span></b><span
style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:windowtext">
Public [<a class="moz-txt-link-freetext" href="mailto:public-bounces@cabforum.org">mailto:public-bounces@cabforum.org</a>] <b>On
Behalf Of </b>Rich Smith via Public<br>
<b>Sent:</b> Monday, January 9, 2017 10:40 AM<br>
<b>To:</b> <a class="moz-txt-link-abbreviated" href="mailto:public@cabforum.org">public@cabforum.org</a><br>
<b>Cc:</b> Rich Smith <a class="moz-txt-link-rfc2396E" href="mailto:richard.smith@comodo.com"><richard.smith@comodo.com></a><br>
<b>Subject:</b> Re: [cabfpub] Proposed Ballot 183 -
Allowing 822 Names and (limited) otherNames<o:p></o:p></span></p>
</div>
</div>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal"
style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"> -
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>
<p class="MsoNormal" style="margin-bottom:12.0pt">[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<o:p></o:p></p>
<div>
<p class="MsoNormal">On 1/4/2017 11:44 AM, Jeremy Rowley via
Public wrote:<o:p></o:p></p>
</div>
<blockquote style="margin-top:5.0pt;margin-bottom:5.0pt">
<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"> </span><o:p></o:p></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"> </span><o:p></o:p></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"> </span><o:p></o:p></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"> </span><o:p></o:p></p>
<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"> <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>
<p class="MsoNormal"><br>
<br>
<br>
<o:p></o:p></p>
<pre>_______________________________________________<o:p></o:p></pre>
<pre>Public mailing list<o:p></o:p></pre>
<pre><a moz-do-not-send="true" href="mailto:Public@cabforum.org">Public@cabforum.org</a><o:p></o:p></pre>
<pre><a moz-do-not-send="true" href="https://cabforum.org/mailman/listinfo/public">https://cabforum.org/mailman/listinfo/public</a><o:p></o:p></pre>
</blockquote>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
</blockquote>
<br>
</body>
</html>