<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body>
<div class="moz-cite-prefix">Jeremy, my comment was about Key Usage
not EKU, sorry for the confuse..<br>
<br>
If the proposed change requires EKU for non EE certificates, then
there is one more issue: <br>
<br>
RFC 5280:<br>
<a class="selflink" name="section-4.2.1.12"
href="http://tools.ietf.org/html/rfc5280#section-4.2.1.12">4.2.1.12</a>.
Extended Key Usage
<pre class="newpage"><span class="h5"></span>
This extension indicates one or more purposes for which the certified
public key may be used, in addition to or in place of the basic
purposes indicated in the key usage extension. In general, this
extension will appear only in end entity certificates.</pre>
<br>
Thanks,<br>
M.D.<br>
<br>
On 8/1/2013 11:52 PM, Jeremy Rowley wrote:<br>
</div>
<blockquote cite="mid:054901ce8ef9$14713f10$3d53bd30$@digicert.com"
type="cite">
<meta http-equiv="Content-Type" content="text/html;
charset=ISO-8859-1">
<meta name="Generator" content="Microsoft Word 14 (filtered
medium)">
<!--[if !mso]><style>v\:* {behavior:url(#default#VML);}
o\:* {behavior:url(#default#VML);}
w\:* {behavior:url(#default#VML);}
.shape {behavior:url(#default#VML);}
</style><![endif]-->
<style><!--
/* Font Definitions */
@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:Tahoma;
panose-1:2 11 6 4 3 5 4 4 2 4;}
@font-face
{font-family:Consolas;
panose-1:2 11 6 9 2 2 4 3 2 4;}
@font-face
{font-family:Verdana;
panose-1:2 11 6 4 3 5 4 4 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;}
p.MsoPlainText, li.MsoPlainText, div.MsoPlainText
{mso-style-priority:99;
mso-style-link:"Plain Text Char";
margin:0in;
margin-bottom:.0001pt;
font-size:11.0pt;
font-family:"Calibri","sans-serif";
color:black;}
p
{mso-style-priority:99;
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;}
pre
{mso-style-priority:99;
mso-style-link:"HTML Preformatted Char";
margin:0in;
margin-bottom:.0001pt;
font-size:12.0pt;
font-family:"Courier New";
color:black;}
p.MsoAcetate, li.MsoAcetate, div.MsoAcetate
{mso-style-priority:99;
mso-style-link:"Balloon Text Char";
margin:0in;
margin-bottom:.0001pt;
font-size:8.0pt;
font-family:"Tahoma","sans-serif";
color:black;}
p.MsoListParagraph, li.MsoListParagraph, div.MsoListParagraph
{mso-style-priority:34;
margin-top:0in;
margin-right:0in;
margin-bottom:0in;
margin-left:.5in;
margin-bottom:.0001pt;
font-size:12.0pt;
font-family:"Times New Roman","serif";
color:black;}
span.HTMLPreformattedChar
{mso-style-name:"HTML Preformatted Char";
mso-style-priority:99;
mso-style-link:"HTML Preformatted";
font-family:Consolas;}
span.PlainTextChar
{mso-style-name:"Plain Text Char";
mso-style-priority:99;
mso-style-link:"Plain Text";
font-family:Consolas;}
span.BalloonTextChar
{mso-style-name:"Balloon Text Char";
mso-style-priority:99;
mso-style-link:"Balloon Text";
font-family:"Tahoma","sans-serif";}
p.msochpdefault, li.msochpdefault, div.msochpdefault
{mso-style-name:msochpdefault;
mso-style-priority:99;
mso-margin-top-alt:auto;
margin-right:0in;
mso-margin-bottom-alt:auto;
margin-left:0in;
font-size:10.0pt;
font-family:"Times New Roman","serif";
color:black;}
p.htmlpreformatted, li.htmlpreformatted, div.htmlpreformatted
{mso-style-name:htmlpreformatted;
mso-style-priority:99;
margin:0in;
margin-bottom:.0001pt;
font-size:12.0pt;
font-family:"Times New Roman","serif";
color:black;}
p.balloontext, li.balloontext, div.balloontext
{mso-style-name:balloontext;
mso-style-priority:99;
margin:0in;
margin-bottom:.0001pt;
font-size:12.0pt;
font-family:"Times New Roman","serif";
color:black;}
p.plaintext, li.plaintext, div.plaintext
{mso-style-name:plaintext;
mso-style-priority:99;
margin:0in;
margin-bottom:.0001pt;
font-size:12.0pt;
font-family:"Times New Roman","serif";
color:black;}
p.htmlpreformatted0, li.htmlpreformatted0, div.htmlpreformatted0
{mso-style-name:htmlpreformatted0;
mso-style-priority:99;
margin:0in;
margin-bottom:.0001pt;
font-size:12.0pt;
font-family:"Times New Roman","serif";
color:black;}
p.plaintext0, li.plaintext0, div.plaintext0
{mso-style-name:plaintext0;
mso-style-priority:99;
margin:0in;
margin-bottom:.0001pt;
font-size:12.0pt;
font-family:"Times New Roman","serif";
color:black;}
p.balloontext0, li.balloontext0, div.balloontext0
{mso-style-name:balloontext0;
mso-style-priority:99;
margin:0in;
margin-bottom:.0001pt;
font-size:12.0pt;
font-family:"Times New Roman","serif";
color:black;}
p.htmlpreformatted1, li.htmlpreformatted1, div.htmlpreformatted1
{mso-style-name:htmlpreformatted1;
mso-style-priority:99;
margin:0in;
margin-bottom:.0001pt;
font-size:12.0pt;
font-family:"Times New Roman","serif";
color:black;}
p.plaintext1, li.plaintext1, div.plaintext1
{mso-style-name:plaintext1;
mso-style-priority:99;
margin:0in;
margin-bottom:.0001pt;
font-size:12.0pt;
font-family:"Times New Roman","serif";
color:black;}
p.balloontext1, li.balloontext1, div.balloontext1
{mso-style-name:balloontext1;
mso-style-priority:99;
margin:0in;
margin-bottom:.0001pt;
font-size:12.0pt;
font-family:"Times New Roman","serif";
color:black;}
span.html-voorafopgemaaktchar
{mso-style-name:html-voorafopgemaaktchar;
font-family:Consolas;}
span.tekstzonderopmaakchar
{mso-style-name:tekstzonderopmaakchar;
font-family:Consolas;}
span.ballontekstchar
{mso-style-name:ballontekstchar;
font-family:"Tahoma","sans-serif";}
span.htmlpreformattedchar0
{mso-style-name:htmlpreformattedchar;
font-family:Consolas;}
span.plaintextchar0
{mso-style-name:plaintextchar;
font-family:Consolas;}
span.balloontextchar0
{mso-style-name:balloontextchar;
font-family:"Tahoma","sans-serif";}
span.html-voorafopgemaaktchar0
{mso-style-name:html-voorafopgemaaktchar0;
font-family:Consolas;}
span.tekstzonderopmaakchar0
{mso-style-name:tekstzonderopmaakchar0;
font-family:Consolas;}
span.ballontekstchar0
{mso-style-name:ballontekstchar0;
font-family:"Tahoma","sans-serif";}
span.htmlpreformattedchar00
{mso-style-name:htmlpreformattedchar0;
font-family:Consolas;}
span.plaintextchar00
{mso-style-name:plaintextchar0;
font-family:Consolas;}
span.balloontextchar00
{mso-style-name:balloontextchar0;
font-family:"Tahoma","sans-serif";}
span.html-voorafopgemaaktchar00
{mso-style-name:html-voorafopgemaaktchar00;
font-family:Consolas;}
span.tekstzonderopmaakchar00
{mso-style-name:tekstzonderopmaakchar00;
font-family:Consolas;}
span.ballontekstchar00
{mso-style-name:ballontekstchar00;
font-family:"Tahoma","sans-serif";}
span.htmlpreformattedchar000
{mso-style-name:htmlpreformattedchar00;
font-family:Consolas;}
span.balloontextchar000
{mso-style-name:balloontextchar00;
font-family:"Tahoma","sans-serif";}
span.html-voorafopgemaaktchar000
{mso-style-name:html-voorafopgemaaktchar000;
font-family:"Courier New";}
span.ballontekstchar000
{mso-style-name:ballontekstchar000;
font-family:"Tahoma","sans-serif";}
span.e-mailstijl22
{mso-style-name:e-mailstijl22;
font-family:"Verdana","sans-serif";
color:#1F497D;}
span.e-mailstijl23
{mso-style-name:e-mailstijl23;
font-family:"Verdana","sans-serif";
color:#1F497D;}
span.e-mailstijl24
{mso-style-name:e-mailstijl24;
font-family:"Verdana","sans-serif";
color:#1F497D;}
span.e-mailstijl35
{mso-style-name:e-mailstijl35;
font-family:"Calibri","sans-serif";
color:#1F497D;}
span.plaintextchar000
{mso-style-name:plaintextchar00;
font-family:"Calibri","sans-serif";}
span.e-mailstijl38
{mso-style-name:e-mailstijl38;
font-family:"Verdana","sans-serif";
color:#1F497D;}
span.e-mailstijl48
{mso-style-name:e-mailstijl48;
font-family:"Calibri","sans-serif";
color:#1F497D;}
span.e-mailstijl49
{mso-style-name:e-mailstijl49;
font-family:"Verdana","sans-serif";
color:#1F497D;}
span.e-mailstijl59
{mso-style-name:e-mailstijl59;
font-family:"Calibri","sans-serif";
color:#1F497D;}
span.e-mailstijl60
{mso-style-name:e-mailstijl60;
font-family:"Verdana","sans-serif";
color:#1F497D;}
span.EmailStyle64
{mso-style-type:personal;
font-family:"Calibri","sans-serif";
color:#1F497D;}
span.EmailStyle65
{mso-style-type:personal;
font-family:"Calibri","sans-serif";
color:#1F497D;}
span.EmailStyle66
{mso-style-type:personal-reply;
font-family:"Calibri","sans-serif";
color:#1F497D;}
.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:#1F497D">Thanks
Moudrick. <o:p></o:p></span></p>
<p class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">None
of those documents require a certificate to include the
anyEKU or no EKU. Is there any software that actually
requires the anyEKU or no EKU or is this just something that
has happened over time with CAs? If there isn’t an actual
reason to put this in Qualified certs (other than CAs have
included it in the past) then there isn’t a conflict, and we
can move forward with the ballot. Issuers of qualified
certs will just need to start inserting the correct EKUs.
The problem (and related danger) is real enough that certs
with anyEKU or no EKU should be covered by the BRs.<o:p></o:p></span></p>
<p class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">Jeremy<o:p></o:p></span></p>
<p class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"><o:p> </o:p></span></p>
<div>
<div style="border:none;border-top:solid #B5C4DF
1.0pt;padding:3.0pt 0in 0in 0in">
<p class="MsoNormal"><b><span
style="font-size:10.0pt;font-family:"Tahoma","sans-serif";color:windowtext">From:</span></b><span
style="font-size:10.0pt;font-family:"Tahoma","sans-serif";color:windowtext">
Moudrick M. Dadashov [<a class="moz-txt-link-freetext" href="mailto:md@ssc.lt">mailto:md@ssc.lt</a>] <br>
<b>Sent:</b> Thursday, August 01, 2013 11:39 AM<br>
<b>To:</b> <a class="moz-txt-link-abbreviated" href="mailto:jeremy.rowley@digicert.com">jeremy.rowley@digicert.com</a><br>
<b>Cc:</b> 'Ryan Hurst'; 'CABFPub'<br>
<b>Subject:</b> Re: [cabfpub] Ballot 108: Clarifying the
scope of the baseline requirements<o:p></o:p></span></p>
</div>
</div>
<p class="MsoNormal"><o:p> </o:p></p>
<div>
<p class="MsoNormal">Jeremy,<br>
<br>
1. ETSI TS 101 862 V1.3.3 (2006-01) Qualified Certificate
profile<br>
2. ETSI EN 319 412-5 V1.1.1 (2013-01) Electronic Signatures
and Infrastructures (ESI); Profiles for Trust Service
Providers issuing certificates; Part 5: Extension for
Qualified Certificate profile<br>
<br>
also have a look: <br>
<br>
ETSI TS 119 412-2 V1.1.1 (2012-04) Electronic Signatures and
Infrastructures (ESI); Profiles for Trust Service Providers
issuing certificates; Part 2: Certificate Profile for
certificates issued to natural persons.<br>
<br>
Search and download here:<br>
<br>
<a moz-do-not-send="true"
href="http://pda.etsi.org/pda/queryform.asp">http://pda.etsi.org/pda/queryform.asp</a><br>
<br>
need to register, its free.<br>
<br>
Thanks.<br>
M.D.<br>
<br>
On 8/1/2013 7:18 PM, Jeremy Rowley wrote:<o:p></o:p></p>
</div>
<blockquote style="margin-top:5.0pt;margin-bottom:5.0pt">
<p class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">Do
you have a link for the profile? None of the qualified
cert profile recommendations or requirements I am aware of
require the anyEKU or omission of the EKU. They all say
EKUS MUST be set in accordance with 5280. </span><o:p></o:p></p>
<p class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"> </span><o:p></o:p></p>
<p class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">Jeremy</span><o:p></o:p></p>
<p class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"> </span><o:p></o:p></p>
<div>
<div style="border:none;border-top:solid #B5C4DF
1.0pt;padding:3.0pt 0in 0in 0in">
<p class="MsoNormal"><b><span
style="font-size:10.0pt;font-family:"Tahoma","sans-serif";color:windowtext">From:</span></b><span
style="font-size:10.0pt;font-family:"Tahoma","sans-serif";color:windowtext">
<a moz-do-not-send="true"
href="mailto:public-bounces@cabforum.org">public-bounces@cabforum.org</a>
[<a moz-do-not-send="true"
href="mailto:public-bounces@cabforum.org">mailto:public-bounces@cabforum.org</a>]
<b>On Behalf Of </b>Moudrick M. Dadashov<br>
<b>Sent:</b> Thursday, August 01, 2013 9:25 AM<br>
<b>To:</b> Ryan Hurst<br>
<b>Cc:</b> 'CABFPub'<br>
<b>Subject:</b> Re: [cabfpub] Ballot 108: Clarifying
the scope of the baseline requirements</span><o:p></o:p></p>
</div>
</div>
<p class="MsoNormal"> <o:p></o:p></p>
<div>
<p class="MsoNormal">I see potential problem for ETSI
Qualified SSL certificates, if key usage requirements
remain mandatory as it is now with the Qualified el.
signature certs. <br>
<br>
Thanks,<br>
M.D.<br>
<br>
On 8/1/2013 5:28 PM, Ryan Hurst wrote:<o:p></o:p></p>
</div>
<blockquote style="margin-top:5.0pt;margin-bottom:5.0pt">
<p class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">There
is nothing in the RFC that requires applications to
treat the presence of the EKU as mandatory:</span><o:p></o:p></p>
<p class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"> </span><o:p></o:p></p>
<p class="MsoNormal"><span
style="font-size:10.0pt;font-family:"Courier
New""> Certificate using</span><o:p></o:p></p>
<p class="MsoNormal"><span
style="font-size:10.0pt;font-family:"Courier
New""> applications MAY require that the extended
key usage extension be</span><o:p></o:p></p>
<p class="MsoNormal"><span
style="font-size:10.0pt;font-family:"Courier
New""> present and that a particular purpose be
indicated in order for the</span><o:p></o:p></p>
<p class="MsoNormal"><span
style="font-size:10.0pt;font-family:"Courier
New""> certificate to be acceptable to that
application.</span><o:p></o:p></p>
<p class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"> </span><o:p></o:p></p>
<p class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">In
fact the processing semantics defined in the RFC result
in the behavior you see in all browsers today. That is
if extended key usage is present the certificate is good
for all usages, that if any key usage is present the
certificate is only good for the specified usages.</span><o:p></o:p></p>
<p class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"> </span><o:p></o:p></p>
<p class="MsoNormal"><span
style="font-size:10.0pt;font-family:"Courier
New""> If the extension is present, then the
certificate MUST only be used</span><o:p></o:p></p>
<p class="MsoNormal"><span
style="font-size:10.0pt;font-family:"Courier
New""> for one of the purposes indicated. If
multiple purposes are</span><o:p></o:p></p>
<p class="MsoNormal"><span
style="font-size:10.0pt;font-family:"Courier
New""> indicated the application need not
recognize all purposes indicated,</span><o:p></o:p></p>
<p class="MsoNormal"><span
style="font-size:10.0pt;font-family:"Courier
New""> as long as the intended purpose is
present.</span><o:p></o:p></p>
<p class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"> </span><o:p></o:p></p>
<p class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">While
this behavior does require CAs to be mindful of what
applications require to understand the implications of
their certificate profiles it is both standards
compliant and the way things have been since the
introduction of this extension.</span><o:p></o:p></p>
<p class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"> </span><o:p></o:p></p>
<p class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">As
for key usage; most libraries (certainly CryptoAPI)
don’t pay attention to the key usage extension; that is
with the exception of keyCertSign. Additionally its
perfectly legitimate for an application to ignore the
Key Usage field:</span><o:p></o:p></p>
<p class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"> </span><o:p></o:p></p>
<p class="MsoNormal"><span
style="font-size:10.0pt;font-family:"Courier
New""> This extension indicates one or more
purposes for which the certified</span><o:p></o:p></p>
<p class="MsoNormal"><span
style="font-size:10.0pt;font-family:"Courier
New""> public key may be used, in addition to or
in place of the basic</span><o:p></o:p></p>
<p class="MsoNormal"><span
style="font-size:10.0pt;font-family:"Courier
New""> purposes indicated in the key usage
extension.</span><o:p></o:p></p>
<p class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"> </span><o:p></o:p></p>
<p class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">And
the specification of the EKU of server authentication
includes a set of specific KUs that are consistent with
the extension:</span><o:p></o:p></p>
<p class="MsoNormal"><span
style="font-size:10.0pt;font-family:"Courier
New""> id-kp-serverAuth OBJECT
IDENTIFIER ::= { id-kp 1 }</span><o:p></o:p></p>
<p class="MsoNormal"><span
style="font-size:10.0pt;font-family:"Courier
New""> -- TLS WWW server authentication</span><o:p></o:p></p>
<p class="MsoNormal"><span
style="font-size:10.0pt;font-family:"Courier
New""> -- Key usage bits that may be consistent:
digitalSignature,</span><o:p></o:p></p>
<p class="MsoNormal"><span
style="font-size:10.0pt;font-family:"Courier
New""> -- keyEncipherment or keyAgreement</span><o:p></o:p></p>
<p class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"> </span><o:p></o:p></p>
<p class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">Given
these facts I do not think it makes sense to include KU
as part of the definition of scope.</span><o:p></o:p></p>
<p class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"> </span><o:p></o:p></p>
<p class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">Ryan</span><o:p></o:p></p>
<div>
<div style="border:none;border-top:solid #B5C4DF
1.0pt;padding:3.0pt 0in 0in 0in">
<p class="MsoNormal"><b><span
style="font-size:10.0pt;font-family:"Tahoma","sans-serif"">From:</span></b><span
style="font-size:10.0pt;font-family:"Tahoma","sans-serif"">
<a moz-do-not-send="true"
href="mailto:public-bounces@cabforum.org">public-bounces@cabforum.org</a>
[<a moz-do-not-send="true"
href="mailto:public-bounces@cabforum.org">mailto:public-bounces@cabforum.org</a>]
<b>On Behalf Of </b>Rijt, R.A. van de (Robert) -
Logius<br>
<b>Sent:</b> Thursday, August 01, 2013 5:09 PM<br>
<b>To:</b> <a moz-do-not-send="true"
href="mailto:jeremy.rowley@digicert.com">jeremy.rowley@digicert.com</a>;
'Steve Roylance'<br>
<b>Cc:</b> 'CABFPub'<br>
<b>Subject:</b> Re: [cabfpub] Ballot 108: Clarifying
the scope of the baseline requirements</span><o:p></o:p></p>
</div>
</div>
<p class="MsoNormal"> <o:p></o:p></p>
<div>
<p class="MsoNormal"><span
style="font-size:10.0pt;font-family:"Verdana","sans-serif"">Ideally,
only certificates that explicitly contain an EKU with
serverauth would be considered SSL certs. All other
certs should be dismissed. That would be in line with
the RFC, but I realize this proposal might even be
more impractical.</span><o:p></o:p></p>
<p class="MsoNormal"><span
style="font-size:10.0pt;font-family:"Verdana","sans-serif""> </span><o:p></o:p></p>
<p class="MsoNormal"><span
style="font-size:10.0pt;font-family:"Verdana","sans-serif"">I
would suggest though to add to the current definition
that only certificates that contain a KeyUsage with
the digitalsignature and keyEncipherment and / or </span><span
style="font-size:10.0pt;font-family:"Verdana","sans-serif""
lang="EN">keyAgreement</span><span
style="font-size:10.0pt" lang="EN"> </span><span
style="font-size:10.0pt;font-family:"Verdana","sans-serif"">bits
set, would be considered SSL certificates. It just
does not make sense to mandate that a personal
certificate on a SSCD with KeyUsage non-repudation and
no EKU would be considered an SSL certificate. That is
not how I have interpreted RFC 5280.</span><o:p></o:p></p>
<p class="MsoNormal"><span
style="font-size:10.0pt;font-family:"Verdana","sans-serif""> </span><o:p></o:p></p>
<p class="MsoNormal"><span
style="font-size:10.0pt;font-family:"Verdana","sans-serif"">If
the proposed definition is accepted all certificates
with noEKU or </span><span
style="font-size:10.0pt;font-family:"Verdana","sans-serif""
lang="EN-GB">anyEKU bits set will be governed by the
BR. That means that all client certificates with those
bits set, SSL or otherwise, will be governed by the
rules of the BR. This in turn means that a client
certificate must contain a FQDN, which it obviously
cannot. In my view, adopting the proposed definition
would lead to a situation where no client certificates
can be issued under the roots present in the root
programs, unless the burden of change is placed on
those CAs issuing client certificates, forcing them to
add keyusage bits to their certificates that are not
compulsory through the RFCs. Furthermore, in many
cases the anyEKU is relied on by software using client
certificates.</span><o:p></o:p></p>
<p class="MsoNormal"><span
style="font-size:10.0pt;font-family:"Verdana","sans-serif""> </span><o:p></o:p></p>
<p class="MsoNormal"><span
style="font-size:10.0pt;font-family:"Verdana","sans-serif"">Regards,</span><o:p></o:p></p>
<p class="MsoNormal"><span
style="font-size:10.0pt;font-family:"Verdana","sans-serif"">Robert
</span><o:p></o:p></p>
<p class="MsoNormal"><span
style="font-size:10.0pt;font-family:"Verdana","sans-serif";color:#1F497D"
lang="NL"> </span><o:p></o:p></p>
<p class="MsoNormal"><span
style="font-size:10.0pt;font-family:"Verdana","sans-serif";color:#1F497D"
lang="NL"> </span><o:p></o:p></p>
<div>
<div style="border:none;border-top:solid #B5C4DF
1.0pt;padding:3.0pt 0in 0in 0in">
<p class="MsoNormal"><b><span
style="font-size:10.0pt;font-family:"Tahoma","sans-serif""
lang="NL">Van:</span></b><span
style="font-size:10.0pt;font-family:"Tahoma","sans-serif""
lang="NL"> Jeremy Rowley [<a
moz-do-not-send="true"
href="mailto:jeremy.rowley@digicert.com">mailto:jeremy.rowley@digicert.com</a>]
<br>
<b>Verzonden:</b> donderdag 1 augustus 2013 14:06<br>
<b>Aan:</b> 'Steve Roylance'; Rijt, R.A. van de
(Robert) - Logius<br>
<b>CC:</b> 'CABFPub'<br>
<b>Onderwerp:</b> RE: [cabfpub] Ballot 108:
Clarifying the scope of the baseline requirements</span><o:p></o:p></p>
</div>
</div>
<p class="MsoNormal"><span lang="NL"> </span><o:p></o:p></p>
<p class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">That
is likely the way forward. Mozilla can enable roots
for “Web, code, or client” . I assume the other
browsers probably have a similar designation. If the
root is disabled for “web” then the cert could not
perform SSL and would not be considered enabled in the
browser’s trust store (for SSL/TLS). The tweak to the
proposed language would be nominal.</span><o:p></o:p></p>
<p class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"> </span><o:p></o:p></p>
<div>
<div style="border:none;border-top:solid #B5C4DF
1.0pt;padding:3.0pt 0in 0in 0in">
<p class="MsoNormal"><b><span
style="font-size:10.0pt;font-family:"Tahoma","sans-serif"">From:</span></b><span
style="font-size:10.0pt;font-family:"Tahoma","sans-serif"">
<a moz-do-not-send="true"
href="mailto:public-bounces@cabforum.org">public-bounces@cabforum.org</a>
[<a moz-do-not-send="true"
href="mailto:public-bounces@cabforum.org">mailto:public-bounces@cabforum.org</a>]
<b>On Behalf Of </b>Steve Roylance<br>
<b>Sent:</b> Thursday, August 01, 2013 5:25 AM<br>
<b>To:</b> Rijt, R.A. van de (Robert) - Logius<br>
<b>Cc:</b> CABFPub<br>
<b>Subject:</b> Re: [cabfpub] Ballot 108:
Clarifying the scope of the baseline requirements</span><o:p></o:p></p>
</div>
</div>
<p class="MsoNormal"> <o:p></o:p></p>
<div>
<p class="MsoNormal">Hi Robert.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"> <o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">Root program's have the ability to
mark specific roots for specific uses therefore you
can still offer public trust but for a specific need.
Maybe that's a way forward? As with Name Constraints
it makes roots (or Subordinate CAs) less attractive as
targets as their value to an attacker is decreased.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"> <o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">Regards Steve<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><br>
Sent from my iPhone<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="margin-bottom:12.0pt"><br>
On 1 Aug 2013, at 12:04, "Rijt, R.A. van de (Robert) -
Logius" <<a moz-do-not-send="true"
href="mailto:robert.vande.rijt@logius.nl">robert.vande.rijt@logius.nl</a>>
wrote:<o:p></o:p></p>
</div>
<blockquote style="margin-top:5.0pt;margin-bottom:5.0pt">
<div>
<div>
<p class="MsoNormal"><span
style="font-size:10.0pt;font-family:"Verdana","sans-serif";color:#1F497D">For
qualified certificates under ETSI that need to
be publicly trusted, a private root would not be
an option. Moreover, developing a private,
not-publicly trusted root and rolling out
end-entity certificates takes time. I am talking
about a year at least.</span><o:p></o:p></p>
<p class="MsoNormal"><span
style="font-size:10.0pt;font-family:"Verdana","sans-serif";color:#1F497D"> </span><o:p></o:p></p>
<p class="MsoNormal"><span
style="font-size:10.0pt;font-family:"Verdana","sans-serif";color:#1F497D">I
wonder if everyone else is realizing the impact
on “non-SSL” certificates. Especially the CA’s
not participating in the CABforum because they
do not issue SSL certs (or thought they did
not), but do have a publicly trusted root. </span><o:p></o:p></p>
<p class="MsoNormal"><span
style="font-size:10.0pt;font-family:"Verdana","sans-serif";color:#1F497D"> </span><o:p></o:p></p>
<p class="MsoNormal"><span
style="font-size:10.0pt;font-family:"Verdana","sans-serif";color:#1F497D">Robert</span><o:p></o:p></p>
<p class="MsoNormal"><span
style="font-size:10.0pt;font-family:"Verdana","sans-serif";color:#1F497D"> </span><o:p></o:p></p>
<div>
<div style="border:none;border-top:solid #B5C4DF
1.0pt;padding:3.0pt 0in 0in 0in">
<p class="MsoNormal"><b><span
style="font-size:10.0pt;font-family:"Tahoma","sans-serif"">Van:</span></b><span
style="font-size:10.0pt;font-family:"Tahoma","sans-serif"">
Jeremy Rowley [<a moz-do-not-send="true"
href="mailto:jeremy.rowley@digicert.com">mailto:jeremy.rowley@digicert.com</a>]
<br>
<b>Verzonden:</b> donderdag 1 augustus 2013
12:56<br>
<b>Aan:</b> Rijt, R.A. van de (Robert) -
Logius; 'Ryan Hurst'<br>
<b>CC:</b> 'CABFPub'<br>
<b>Onderwerp:</b> RE: [cabfpub] Ballot 108:
Clarifying the scope of the baseline
requirements</span><o:p></o:p></p>
</div>
</div>
<p class="MsoNormal"> <o:p></o:p></p>
<p class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">Which
is why you will now have to issue these off a
root not trusted by a participating browser. The
safetynet is the problem since makes them an SSL
cert. I don’t think you can both have a
safetynet like this and issue the cert from a
trusted root.</span><o:p></o:p></p>
<p class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"> </span><o:p></o:p></p>
<p class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">Jeremy</span><o:p></o:p></p>
<p class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"> </span><o:p></o:p></p>
<div>
<div style="border:none;border-top:solid #B5C4DF
1.0pt;padding:3.0pt 0in 0in 0in">
<p class="MsoNormal"><b><span
style="font-size:10.0pt;font-family:"Tahoma","sans-serif"">From:</span></b><span
style="font-size:10.0pt;font-family:"Tahoma","sans-serif"">
Rijt, R.A. van de (Robert) - Logius [<a
moz-do-not-send="true"
href="mailto:robert.vande.rijt@logius.nl">mailto:robert.vande.rijt@logius.nl</a>]
<br>
<b>Sent:</b> Thursday, August 01, 2013 4:53
AM<br>
<b>To:</b> Ryan Hurst; <a
moz-do-not-send="true"
href="mailto:jeremy.rowley@digicert.com">jeremy.rowley@digicert.com</a><br>
<b>Cc:</b> CABFPub<br>
<b>Subject:</b> RE: [cabfpub] Ballot 108:
Clarifying the scope of the baseline
requirements</span><o:p></o:p></p>
</div>
</div>
<p class="MsoNormal"> <o:p></o:p></p>
<div>
<p class="MsoNormal"> <o:p></o:p></p>
<p class="MsoNormal"><span
style="font-size:10.0pt;font-family:"Verdana","sans-serif"">Thanks
for your reply, Jeremy. I conclude that with
this new definition: </span><o:p></o:p></p>
<p class="MsoNormal"><span
style="font-size:10.0pt;font-family:"Verdana","sans-serif""> </span><o:p></o:p></p>
<p class="MsoNormal"><span
style="font-size:10.0pt;font-family:"Verdana","sans-serif"">1.
We are forcing everyone with public
certificates to use the EKU;</span><o:p></o:p></p>
<p class="MsoNormal"><span
style="font-size:10.0pt;font-family:"Verdana","sans-serif"">2.
We are forcing everyone with public
certificates not to use the </span><span
style="font-size:10.0pt;font-family:"Verdana","sans-serif""
lang="EN-GB">anyExtendedKeyUsage unless it is
a SSL certificate; </span><o:p></o:p></p>
<p class="MsoNormal"><span
style="font-size:10.0pt;font-family:"Verdana","sans-serif""
lang="EN-GB">3. thereby forcing everyone to
spell out all the applicable EKUs one–by-one.
My experience is that a lot of software cannot
handle this</span><span
style="font-size:10.0pt;font-family:"Verdana","sans-serif";color:#1F497D"
lang="EN-GB">,</span><span
style="font-size:10.0pt;font-family:"Verdana","sans-serif""
lang="EN-GB"> so the certificate cannot be
used for the function intended. That is why
the anyExtendedKeyUsage is often used as a
safetynet.</span><o:p></o:p></p>
<p class="MsoNormal"><span
style="font-size:10.0pt;font-family:"Verdana","sans-serif""
lang="EN-GB"> </span><o:p></o:p></p>
<p class="MsoNormal"><span
style="font-size:10.0pt;font-family:"Verdana","sans-serif""
lang="EN-GB">Robert</span><o:p></o:p></p>
<p class="MsoNormal"><span
style="font-size:10.0pt;font-family:"Verdana","sans-serif";color:#1F497D"> </span><o:p></o:p></p>
<p class="MsoNormal"><span
style="font-size:10.0pt;font-family:"Verdana","sans-serif";color:#1F497D"> </span><o:p></o:p></p>
<div>
<div style="border:none;border-top:solid #B5C4DF
1.0pt;padding:3.0pt 0in 0in 0in">
<p class="MsoNormal"><b><span
style="font-size:10.0pt;font-family:"Tahoma","sans-serif"">Van:</span></b><span
style="font-size:10.0pt;font-family:"Tahoma","sans-serif"">
Ryan Hurst [<a moz-do-not-send="true"
href="mailto:ryan.hurst@globalsign.com">mailto:ryan.hurst@globalsign.com</a>]
<br>
<b>Verzonden:</b> donderdag 1 augustus
2013 12:45<br>
<b>Aan:</b> <a moz-do-not-send="true"
href="mailto:jeremy.rowley@digicert.com">jeremy.rowley@digicert.com</a><br>
<b>CC:</b> Rijt, R.A. van de (Robert) -
Logius; CABFPub<br>
<b>Onderwerp:</b> Re: [cabfpub] Ballot
108: Clarifying the scope of the baseline
requirements</span><o:p></o:p></p>
</div>
</div>
<p class="MsoNormal"> <o:p></o:p></p>
<div>
<p class="MsoNormal">I concur with Jeremy's
analysis.<br>
<br>
Ryan Hurst<o:p></o:p></p>
<div>
<div>
<p class="MsoNormal">Chief Technology
Officer<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">GMO Globalsign<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"> <o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">twitter: @rmhrisk<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">email: <a
moz-do-not-send="true"
href="mailto:ryan.hurst@globalsign.com">ryan.hurst@globalsign.com</a><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">phone: 206-650-7926<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"> <o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">Sent from my phone,
please forgive the brevity.<o:p></o:p></p>
</div>
</div>
</div>
<div>
<p class="MsoNormal"
style="margin-bottom:12.0pt"><br>
On Aug 1, 2013, at 1:12 PM, "Jeremy Rowley"
<<a moz-do-not-send="true"
href="mailto:jeremy.rowley@digicert.com">jeremy.rowley@digicert.com</a>>
wrote:<o:p></o:p></p>
</div>
<blockquote
style="margin-top:5.0pt;margin-bottom:5.0pt">
<div>
<p class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Calibri","sans-serif"">HI
Rijt, </span><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"">I
think the certificates you mentioned will
(and should) qualify under the BRs if are
issued from a root that is included in one
of the adopting browser’s trust stores.</span><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"">Here’s
my logic:</span><o:p></o:p></p>
<p class="MsoListParagraph"
style="text-indent:-.25in">1)<span
style="font-size:7.0pt"> </span><span
style="font-size:11.0pt;font-family:"Calibri","sans-serif"">Certs
that don’t have an EKU or that include the
anyEKU can be used as SSL certs,
regardless of their intended purposes and
should (arguably) be under the BRs. </span><o:p></o:p></p>
<p class="MsoListParagraph"
style="text-indent:-.25in">2)<span
style="font-size:7.0pt"> </span><span
style="font-size:11.0pt;font-family:"Calibri","sans-serif"">However,
as you mentioned, many certificates assert
the anyEKU, have noEKU, or even contain
the server authentication EKU that are
never intended to be used on a server. </span><o:p></o:p></p>
<p class="MsoListParagraph"
style="text-indent:-.25in">3)<span
style="font-size:7.0pt"> </span><span
style="font-size:11.0pt;font-family:"Calibri","sans-serif"">I
believe the certificates referenced
typically lack an FQDN. Including these
certificates under the BR umbrella is
problematic because the certificates can’t
function in the intended manner and comply
with the BRs. The CN is an identifier for
the equipment, which violates Section
9.2.2 of the BRs.</span><o:p></o:p></p>
<p class="MsoListParagraph"
style="text-indent:-.25in">4)<span
style="font-size:7.0pt"> </span><span
style="font-size:11.0pt;font-family:"Calibri","sans-serif"">Requiring
an FQDN for inclusion in the BRs is not a
way forward since that would make the
sections on internal server names out of
scope of the BRs. In fact, the identifier
in these certificates is indistinguishable
from and qualifies as an internal name,
meaning the certificate presents all of
the concerns previously expressed by
PayPal. Continuing to trust these
certificates would be the same as not
deprecating internal server name
certificates</span><o:p></o:p></p>
<p class="MsoListParagraph"
style="text-indent:-.25in">5)<span
style="font-size:7.0pt"> </span><span
style="font-size:11.0pt;font-family:"Calibri","sans-serif"">Therefore,
these certificates must either be included
in the BRs, and include an FQDN, or need
to be issued off of a non-publicly trusted
root certificate. </span><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"">The
position you expressed is why I wanted to
raise the issue and why I think we need to
resolve what the BRs actually cover. </span><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>
<p class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"> </span><o:p></o:p></p>
<div>
<div style="border:none;border-top:solid
#B5C4DF 1.0pt;padding:3.0pt 0in 0in 0in">
<p class="MsoNormal"><b><span
style="font-size:10.0pt;font-family:"Tahoma","sans-serif"">From:</span></b><span
style="font-size:10.0pt;font-family:"Tahoma","sans-serif"">
<a moz-do-not-send="true"
href="mailto:public-bounces@cabforum.org">public-bounces@cabforum.org</a>
[<a moz-do-not-send="true"
href="mailto:public-bounces@cabforum.org">mailto:public-bounces@cabforum.org</a>]
<b>On Behalf Of </b>Rijt, R.A. van de
(Robert) - Logius<br>
<b>Sent:</b> Thursday, August 01, 2013
3:05 AM<br>
<b>To:</b> 'CABFPub'<br>
<b>Subject:</b> Re: [cabfpub] Ballot
108: Clarifying the scope of the
baseline requirements</span><o:p></o:p></p>
</div>
</div>
<p class="MsoNormal"> <o:p></o:p></p>
<div>
<p class="MsoNormal"><span
style="font-size:10.0pt;font-family:"Verdana","sans-serif""
lang="EN-GB">Although I understand the
need for tightening the definition and I
can follow the reasoning below to a
certain point I feel that, instead of
tightening it, the new definition seems
to have broadened the scope. The vast
majority of certificates issued under
the Logius PKIoverheid root are not
intended for the identification of SSL
servers. However, roughly 90% of these
certificates will now fall under this
new definition. In the present version,
the scope made clear that the BR only
addressed certificates meant for
servers.</span><o:p></o:p></p>
<p class="MsoNormal"><span
style="font-size:10.0pt;font-family:"Verdana","sans-serif""
lang="EN-GB"> </span><o:p></o:p></p>
<p class="MsoNormal"><span
style="font-size:10.0pt;font-family:"Verdana","sans-serif""
lang="EN-GB">What about personal
certificates on a SSCD that have no EKU
or have an anyExtendedKeyUsage as a
safetynet? Would these certificates
suddenly by seen as SSL certificates
although they are obviously not intended
for servers? What about certificates
issued to autonomous devices such as
onboard computers in taxicabs or
domestic gas meters, to name but two?
Would these be considered SSL
certificates if they have no EKU or the
clientauth EKU in combination with
anyExtendedKeyUsage? </span><o:p></o:p></p>
<p class="MsoNormal"><span
style="font-size:10.0pt;font-family:"Verdana","sans-serif""
lang="EN-GB"> </span><o:p></o:p></p>
<p class="MsoNormal"><span
style="font-size:10.0pt;font-family:"Verdana","sans-serif"">Regards,
</span><o:p></o:p></p>
<p class="MsoNormal">Robert<o:p></o:p></p>
<p class="MsoNormal"> <o:p></o:p></p>
<p class="MsoNormal"> <o:p></o:p></p>
<p class="MsoNormal"><span
style="font-size:10.0pt;font-family:"Verdana","sans-serif";color:#1F497D"
lang="EN"> </span><o:p></o:p></p>
<p class="MsoNormal"><span
style="font-size:10.0pt;font-family:"Verdana","sans-serif";color:#1F497D"
lang="EN"> </span><o:p></o:p></p>
<div style="border:none;border-top:solid
#B5C4DF 1.0pt;padding:3.0pt 0in 0in 0in">
<p class="MsoNormal"><b><span
style="font-size:10.0pt;font-family:"Tahoma","sans-serif"">Van:</span></b><span
style="font-size:10.0pt;font-family:"Tahoma","sans-serif"">
<a moz-do-not-send="true"
href="mailto:public-bounces@cabforum.org">public-bounces@cabforum.org</a>
[<a moz-do-not-send="true"
href="mailto:public-bounces@cabforum.org">mailto:public-bounces@cabforum.org</a>]
<b>Namens </b>Ryan Sleevi<br>
<b>Verzonden:</b> maandag 29 juli 2013
22:57<br>
<b>Aan:</b> Kelvin Yiu<br>
<b>CC:</b> CABFPub<br>
<b>Onderwerp:</b> Re: [cabfpub] Ballot
108: Clarifying the scope of the
baseline requirements</span><o:p></o:p></p>
</div>
<p class="MsoNormal"> <o:p></o:p></p>
<p>They're still respected (for better or
worse) by Apple, NSS, and Android.<o:p></o:p></p>
<p>Even if that changed tomorrow, the fact
that a significant portion of the deployed
user base for those products may not
upgrade immediately suggests it would be
wise to keep them in scope - especially
given that even few products implement
Microsoft's EKU chaining behaviour for
intermediates.<o:p></o:p></p>
<div>
<p class="MsoNormal">On Jul 29, 2013 1:52
PM, "Kelvin Yiu" <<a
moz-do-not-send="true"
href="mailto:kelviny@exchange.microsoft.com">kelviny@exchange.microsoft.com</a>>
wrote:<o:p></o:p></p>
<p class="MsoNormal"
style="margin-bottom:12.0pt">I prefer to
drop any mention of the MS or Netscape
SGC OIDs. These OIDs have been obsolete
for over a decade and have ceased to
have any meaning on MS platforms since
Windows 2000.<br>
<br>
Kelvin<br>
<br>
-----Original Message-----<br>
From: <a moz-do-not-send="true"
href="mailto:public-bounces@cabforum.org">public-bounces@cabforum.org</a>
[mailto:<a moz-do-not-send="true"
href="mailto:public-bounces@cabforum.org">public-bounces@cabforum.org</a>]
On Behalf Of Ryan Sleevi<br>
Sent: Friday, July 26, 2013 12:35 PM<br>
To: jeremy rowley<br>
Cc: CABFPub<br>
Subject: Re: [cabfpub] Ballot 108:
Clarifying the scope of the baseline
requirements<br>
<br>
Jeremy,<br>
<br>
If I might suggest a slight modification
to the wording, which still leaves
things a little ambiguous. "All root and
intermediate certificates included in a
browser's trust store" - AIUI, none of
the browsers are really accepting
intermediates to the trust store at this
point.<br>
<br>
This was a sticky point when working on
Mozilla's wording on this policy to.
Luckily, the terminology for "Root CA"
and "Subordinate CA"<br>
may be sufficient here to help clarify.<br>
<br>
"All root certificates included in a
browser's trust store, all subordinate
CA certificates signed by one of these
root certificates, and all end-entity
certificates that either lack any
Extended Key Usage extension or contain
an Extended Key Usage extension that
contains one of the following:<br>
- Server Authentication
(1.3.6.1.5.5.7.3.1)<br>
- anyExtendedKeyUsage (2.5.29.37.0)<br>
- Netscape Server Gated Cryptography
(2.16.840.1.113730.4.1)<br>
- Microsoft Server Gated Cryptography
(1.3.6.1.4.1.311.10.3.3) are expressly
covered by these requirements."<br>
<br>
Note that Appendix B, 3.F lists other
values as SHOULD NOT. However, that
presumably only applies when a
certificate is 'in scope' of the BRs,
hence the restatement of potential EKUs
that are relevant.<br>
<br>
<br>
<br>
On Fri, Jul 26, 2013 at 12:22 PM, Jeremy
Rowley <<a moz-do-not-send="true"
href="mailto:jeremy.rowley@digicert.com">jeremy.rowley@digicert.com</a>>
wrote:<br>
> Hi everyone,<br>
><br>
><br>
><br>
> As mentioned on the phone call last
week, CAs have claimed exemption<br>
> from the BRs because the definition
of a publicly-trusted SSL certificate is
not<br>
> clear. I would like to clarify
the scope of the BRs to avoid confusion
on<br>
> what particular certificate
contents are necessary to require<br>
> compliance. I am looking for on
endorser (Stephen Davidson has already
endorsed).<br>
><br>
><br>
><br>
> The third paragraph of Section 1 of
the baseline requirements is:<br>
><br>
> "This version of the Requirements
only addresses Certificates intended<br>
> to be used for authenticating
servers accessible through the<br>
> Internet. Similar requirements for
code signing, S/MIME,<br>
> time-stamping, VoIP, IM, Web
services, etc. may be covered in future
versions."<br>
><br>
><br>
><br>
> I'd like to replace the above text
with the following:<br>
><br>
> "This version of the Baseline
Requirements addresses all root,<br>
> intermediate, and end entity
certificates that can be used in<br>
> publicly-trusted SSL handshakes.
All root and intermediate<br>
> certificates included in a
browser's trust store and all end entity<br>
> certificates containing an extended
key usage extension of Server<br>
> Authentication (1.3.6.1.5.5.7.3.1)
are expressly covered by these<br>
> requirements. Similar requirements
for code signing, S/MIME,<br>
> time-stamping, VoIP, IM, Web
services, etc. may be covered in future
versions."<br>
><br>
><br>
><br>
> I look forward to your comments.<br>
><br>
><br>
><br>
> Jeremy<br>
><br>
><br>
>
_______________________________________________<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"
target="_blank">https://cabforum.org/mailman/listinfo/public</a><br>
><br>
_______________________________________________<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"
target="_blank">https://cabforum.org/mailman/listinfo/public</a><o:p></o:p></p>
</div>
</div>
<p class="MsoNormal"> <o:p></o:p></p>
<div class="MsoNormal"
style="text-align:center" align="center">
<hr size="2" width="100%" align="center"></div>
<p class="MsoNormal"><span
style="font-size:7.5pt;font-family:"Arial","sans-serif";color:gray"><br>
Dit bericht kan informatie bevatten die
niet voor u is bestemd. Indien u niet de
geadresseerde bent of dit bericht
abusievelijk aan u is toegezonden, wordt u
verzocht dat aan de afzender te melden en
het bericht te verwijderen. De Staat
aanvaardt geen aansprakelijkheid voor
schade, van welke aard ook, die verband
houdt met risico's verbonden aan het
elektronisch verzenden van berichten.<br>
This message may contain information that
is not intended for you. If you are not
the addressee or if this message was sent
to you by mistake, you are requested to
inform the sender and delete the message.
The State accepts no liability for damage
of any kind resulting from the risks
inherent in the electronic transmission of
messages. .</span><o:p></o:p></p>
</div>
</blockquote>
<blockquote
style="margin-top:5.0pt;margin-bottom:5.0pt">
<div>
<p class="MsoNormal">_______________________________________________<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><o:p></o:p></p>
</div>
</blockquote>
</div>
<p class="MsoNormal"> <o:p></o:p></p>
<div class="MsoNormal" style="text-align:center"
align="center">
<hr size="2" width="100%" align="center"></div>
<p class="MsoNormal"><span
style="font-size:7.5pt;font-family:"Arial","sans-serif";color:gray"><br>
Dit bericht kan informatie bevatten die niet
voor u is bestemd. Indien u niet de
geadresseerde bent of dit bericht abusievelijk
aan u is toegezonden, wordt u verzocht dat aan
de afzender te melden en het bericht te
verwijderen. De Staat aanvaardt geen
aansprakelijkheid voor schade, van welke aard
ook, die verband houdt met risico's verbonden
aan het elektronisch verzenden van berichten.<br>
This message may contain information that is not
intended for you. If you are not the addressee
or if this message was sent to you by mistake,
you are requested to inform the sender and
delete the message. The State accepts no
liability for damage of any kind resulting from
the risks inherent in the electronic
transmission of messages. .</span><o:p></o:p></p>
</div>
<p class="MsoNormal"> <o:p></o:p></p>
<div class="MsoNormal" style="text-align:center"
align="center">
<hr size="2" width="100%" align="center"></div>
<p class="MsoNormal"><span
style="font-size:7.5pt;font-family:"Arial","sans-serif";color:gray"><br>
Dit bericht kan informatie bevatten die niet voor
u is bestemd. Indien u niet de geadresseerde bent
of dit bericht abusievelijk aan u is toegezonden,
wordt u verzocht dat aan de afzender te melden en
het bericht te verwijderen. De Staat aanvaardt
geen aansprakelijkheid voor schade, van welke aard
ook, die verband houdt met risico's verbonden aan
het elektronisch verzenden van berichten.<br>
This message may contain information that is not
intended for you. If you are not the addressee or
if this message was sent to you by mistake, you
are requested to inform the sender and delete the
message. The State accepts no liability for damage
of any kind resulting from the risks inherent in
the electronic transmission of messages. .</span><o:p></o:p></p>
</div>
</blockquote>
<blockquote style="margin-top:5.0pt;margin-bottom:5.0pt">
<div>
<p class="MsoNormal">_______________________________________________<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><o:p></o:p></p>
</div>
</blockquote>
</div>
<p class="MsoNormal"><span lang="NL"> </span><o:p></o:p></p>
<div class="MsoNormal" style="text-align:center"
align="center"><span lang="NL">
<hr size="3" width="100%" align="center"></span></div>
<p class="MsoNormal"><span
style="font-size:7.5pt;font-family:"Arial","sans-serif";color:gray"
lang="NL"><br>
Dit bericht kan informatie bevatten die niet voor u is
bestemd. Indien u niet de geadresseerde bent of dit
bericht abusievelijk aan u is toegezonden, wordt u
verzocht dat aan de afzender te melden en het bericht te
verwijderen. De Staat aanvaardt geen aansprakelijkheid
voor schade, van welke aard ook, die verband houdt met
risico's verbonden aan het elektronisch verzenden van
berichten.<br>
This message may contain information that is not
intended for you. If you are not the addressee or if
this message was sent to you by mistake, you are
requested to inform the sender and delete the message.
The State accepts no liability for damage of any kind
resulting from the risks inherent in the electronic
transmission of messages. .</span><o:p></o:p></p>
<p class="MsoNormal"><br>
<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>
</blockquote>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
</blockquote>
<br>
</body>
</html>