<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
</head>
<body dir="auto">
<div>Clarification, a user will receive an error if name constraints and policy constraints are both marked critical. <br>
<br>
<p class="MsoNormal" style="margin: 0in 0in 0.0001pt;"><b style="background-color: rgba(255, 255, 255, 0);">Kenneth Myers<o:p></o:p></b></p>
<p class="MsoNormal" style="margin: 0in 0in 0.0001pt;"><span style="background-color: rgba(255, 255, 255, 0);">Protiviti | Government Solutions | Manager<o:p></o:p></span></p>
<p class="MsoNormal" style="margin: 0in 0in 0.0001pt;"><span style="background-color: rgba(255, 255, 255, 0);">Alexandria | <a dir="ltr" href="tel:+1%20571-366-6120" x-apple-data-detectors="true" x-apple-data-detectors-type="telephone" x-apple-data-detectors-result="2/1">+1
571-366-6120</a> | <a href="mailto:Kenneth.Myers@Protiviti.com">Kenneth.Myers@Protiviti.com</a><br>
Connect: <a href="https://www.linkedin.com/in/kennethmy">LinkedIn</a> | Thought Leadership: <a href="http://www.protiviti.it/en-US/Pages/Insights.aspx">Protiviti.com</a></span></p>
</div>
<div><br>
On Jan 10, 2017, at 07:35, Myers, Kenneth (10421) <<a href="mailto:kenneth.myers@protiviti.com">kenneth.myers@protiviti.com</a>> wrote:<br>
<br>
</div>
<blockquote type="cite">
<div>
<div>Apple currently does not support critical name constraints based on testing in US Federal PKI. <br>
<br>
<p class="MsoNormal" style="margin: 0in 0in 0.0001pt;"><b style="background-color: rgba(255, 255, 255, 0);">Kenneth Myers<o:p></o:p></b></p>
<p class="MsoNormal" style="margin: 0in 0in 0.0001pt;"><span style="background-color: rgba(255, 255, 255, 0);">Protiviti | Government Solutions | Manager<o:p></o:p></span></p>
<p class="MsoNormal" style="margin: 0in 0in 0.0001pt;"><span style="background-color: rgba(255, 255, 255, 0);">Alexandria | <a dir="ltr" href="tel:+1%20571-366-6120" x-apple-data-detectors="true" x-apple-data-detectors-type="telephone" x-apple-data-detectors-result="2/1">+1
571-366-6120</a> | <a href="mailto:Kenneth.Myers@Protiviti.com">Kenneth.Myers@Protiviti.com</a><br>
Connect: <a href="https://urldefense.proofpoint.com/v2/url?u=https-3A__www.linkedin.com_in_kennethmy&d=DgMGaQ&c=19TEyCb-E0do3cLmFgm9ItTXlbGQ5gmhRAlAtE256go&r=v6QfMBgWaMWhsB_PpBwwzxPtUwSffCWXSAR0gp0RFbY&m=akQTnjHinpVPTr5BT3_hKCtWnu7TGUjvBWDb8OmAOmc&s=w_yjW3m_aQPgKkLA4bWiZzaQ8Mr-mScAYJeRL2sbzuc&e=">LinkedIn</a> |
Thought Leadership: <a href="http://www.protiviti.it/en-US/Pages/Insights.aspx">Protiviti.com</a></span></p>
</div>
<div><br>
On Jan 9, 2017, at 12:43, Jeremy Rowley <<a href="mailto:jeremy.rowley@digicert.com">jeremy.rowley@digicert.com</a>> wrote:<br>
<br>
</div>
<blockquote type="cite">
<div>
<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 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 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 href="mailto:public@cabforum.org">public@cabforum.org</a><br>
<b>Cc:</b> Rich Smith <<a 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 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 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 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 href="mailto:public@cabforum.org">public@cabforum.org</a>>; Peter Bowen <<a 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 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 href="mailto:Public@cabforum.org">Public@cabforum.org</a><br>
<a href="https://urldefense.proofpoint.com/v2/url?u=https-3A__cabforum.org_mailman_listinfo_public&d=DgMGaQ&c=19TEyCb-E0do3cLmFgm9ItTXlbGQ5gmhRAlAtE256go&r=v6QfMBgWaMWhsB_PpBwwzxPtUwSffCWXSAR0gp0RFbY&m=akQTnjHinpVPTr5BT3_hKCtWnu7TGUjvBWDb8OmAOmc&s=szSj-YnuB_tJLsg9ksCfYPQFxpQrb8OeZSU9YUNdSFc&e=">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 href="mailto:Public@cabforum.org">Public@cabforum.org</a><o:p></o:p></pre>
<pre><a href="https://urldefense.proofpoint.com/v2/url?u=https-3A__cabforum.org_mailman_listinfo_public&d=DgMGaQ&c=19TEyCb-E0do3cLmFgm9ItTXlbGQ5gmhRAlAtE256go&r=v6QfMBgWaMWhsB_PpBwwzxPtUwSffCWXSAR0gp0RFbY&m=akQTnjHinpVPTr5BT3_hKCtWnu7TGUjvBWDb8OmAOmc&s=szSj-YnuB_tJLsg9ksCfYPQFxpQrb8OeZSU9YUNdSFc&e=">https://cabforum.org/mailman/listinfo/public</a><o:p></o:p></pre>
</blockquote>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
</div>
</blockquote>
NOTICE: Protiviti is a global consulting and internal audit firm composed of experts specializing in risk and advisory services. Protiviti is not licensed or registered as a public accounting firm and does not issue opinions on financial statements or offer
attestation services. This electronic mail message is intended exclusively for the individual or entity to which it is addressed. This message, together with any attachment, may contain confidential and privileged information. Any views, opinions or conclusions
expressed in this message are those of the individual sender and do not necessarily reflect the views of Protiviti Inc. or its affiliates. Any unauthorized review, use, printing, copying, retention, disclosure or distribution is strictly prohibited. If you
have received this message in error, please immediately advise the sender by reply email message to the sender and delete all copies of this message. Thank you.
</div>
</blockquote>
</body>
</html>