<html>
  <head>
    <meta content="text/html; charset=ISO-8859-1"
      http-equiv="Content-Type">
  </head>
  <body text="#000000" bgcolor="#FFFFFF">
    <div class="moz-cite-prefix">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 class="moz-txt-link-freetext" 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:<br>
    </div>
    <blockquote cite="mid:03f001ce8ed2$d4f6e630$7ee4b290$@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;}
@font-face
        {font-family:"Courier New \;color\:black";
        panose-1:0 0 0 0 0 0 0 0 0 0;}
/* 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-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">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.  <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">
                <a class="moz-txt-link-abbreviated" href="mailto:public-bounces@cabforum.org">public-bounces@cabforum.org</a>
                [<a class="moz-txt-link-freetext" 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<o:p></o:p></span></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
              ;color:black","serif"">   Certificate using</span><o:p></o:p></p>
          <p class="MsoNormal"><span
              style="font-size:10.0pt;font-family:"Courier New
              ;color:black","serif"">   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
              ;color:black","serif"">   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
              ;color:black","serif"">   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
              ;color:black","serif"">   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
              ;color:black","serif"">   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
              ;color:black","serif"">   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
              ;color:black","serif"">   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
              ;color:black","serif"">   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
              ;color:black","serif"">   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
              ;color:black","serif"">   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
              ;color:black","serif"">  
              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
              ;color:black","serif"">   -- TLS WWW server
              authentication</span><o:p></o:p></p>
          <p class="MsoNormal"><span
              style="font-size:10.0pt;font-family:"Courier New
              ;color:black","serif"">   -- 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
              ;color:black","serif"">   --
              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>
            <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>