<html xmlns:v="urn:schemas-microsoft-com:vml" xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns="http://www.w3.org/TR/REC-html40"><head><meta http-equiv=Content-Type content="text/html; charset=utf-8"><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";}
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";}
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";}
pre
{mso-style-priority:99;
mso-style-link:"HTML Preformatted Char";
margin:0in;
margin-bottom:.0001pt;
font-size:12.0pt;
font-family:"Courier New";}
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";}
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";}
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-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";}
p.htmlpreformatted, li.htmlpreformatted, div.htmlpreformatted
{mso-style-name:htmlpreformatted;
margin:0in;
margin-bottom:.0001pt;
font-size:12.0pt;
font-family:"Times New Roman","serif";}
p.balloontext, li.balloontext, div.balloontext
{mso-style-name:balloontext;
margin:0in;
margin-bottom:.0001pt;
font-size:12.0pt;
font-family:"Times New Roman","serif";}
p.plaintext, li.plaintext, div.plaintext
{mso-style-name:plaintext;
margin:0in;
margin-bottom:.0001pt;
font-size:12.0pt;
font-family:"Times New Roman","serif";}
p.htmlpreformatted0, li.htmlpreformatted0, div.htmlpreformatted0
{mso-style-name:htmlpreformatted0;
margin:0in;
margin-bottom:.0001pt;
font-size:12.0pt;
font-family:"Times New Roman","serif";}
p.plaintext0, li.plaintext0, div.plaintext0
{mso-style-name:plaintext0;
margin:0in;
margin-bottom:.0001pt;
font-size:12.0pt;
font-family:"Times New Roman","serif";}
p.balloontext0, li.balloontext0, div.balloontext0
{mso-style-name:balloontext0;
margin:0in;
margin-bottom:.0001pt;
font-size:12.0pt;
font-family:"Times New Roman","serif";}
p.htmlpreformatted1, li.htmlpreformatted1, div.htmlpreformatted1
{mso-style-name:htmlpreformatted1;
margin:0in;
margin-bottom:.0001pt;
font-size:12.0pt;
font-family:"Times New Roman","serif";}
p.plaintext1, li.plaintext1, div.plaintext1
{mso-style-name:plaintext1;
margin:0in;
margin-bottom:.0001pt;
font-size:12.0pt;
font-family:"Times New Roman","serif";}
p.balloontext1, li.balloontext1, div.balloontext1
{mso-style-name:balloontext1;
margin:0in;
margin-bottom:.0001pt;
font-size:12.0pt;
font-family:"Times New Roman","serif";}
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-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]--></head><body lang=EN-US link=blue vlink=purple><div class=WordSection1><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:<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:10.0pt;font-family:"Courier New";color:black'> Certificate using<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:10.0pt;font-family:"Courier New";color:black'> applications MAY require that the extended key usage extension be<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:10.0pt;font-family:"Courier New";color:black'> present and that a particular purpose be indicated in order for the<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:10.0pt;font-family:"Courier New";color:black'> certificate to be acceptable to that application.<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'>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.<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:10.0pt;font-family:"Courier New";color:black'> If the extension is present, then the certificate MUST only be used<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:10.0pt;font-family:"Courier New";color:black'> for one of the purposes indicated. If multiple purposes are<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:10.0pt;font-family:"Courier New";color:black'> indicated the application need not recognize all purposes indicated,<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:10.0pt;font-family:"Courier New";color:black'> as long as the intended purpose is present.<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'>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.<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'>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:<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:10.0pt;font-family:"Courier New";color:black'> This extension indicates one or more purposes for which the certified<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:10.0pt;font-family:"Courier New";color:black'> public key may be used, in addition to or in place of the basic<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:10.0pt;font-family:"Courier New";color:black'> purposes indicated in the key usage extension.<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'>And the specification of the EKU of server authentication includes a set of specific KUs that are consistent with the extension:<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:10.0pt;font-family:"Courier New";color:black'> id-kp-serverAuth OBJECT IDENTIFIER ::= { id-kp 1 }<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:10.0pt;font-family:"Courier New";color:black'> -- TLS WWW server authentication<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:10.0pt;font-family:"Courier New";color:black'> -- Key usage bits that may be consistent: digitalSignature,<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:10.0pt;font-family:"Courier New";color:black'> -- keyEncipherment or keyAgreement<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'>Given these facts I do not think it makes sense to include KU as part of the definition of scope.<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'>Ryan<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"'>From:</span></b><span style='font-size:10.0pt;font-family:"Tahoma","sans-serif"'> public-bounces@cabforum.org [mailto:public-bounces@cabforum.org] <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> jeremy.rowley@digicert.com; 'Steve Roylance'<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><span style='font-size:10.0pt;font-family:"Verdana","sans-serif";color:black'>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><span lang=NL><o:p></o:p></span></p><p class=MsoNormal><span style='font-size:10.0pt;font-family:"Verdana","sans-serif";color:black'> </span><span lang=NL><o:p></o:p></span></p><p class=MsoNormal><span style='font-size:10.0pt;font-family:"Verdana","sans-serif";color:black'>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 lang=EN style='font-size:10.0pt;font-family:"Verdana","sans-serif";color:black'>keyAgreement</span><span lang=EN style='font-size:10.0pt;color:black'> </span><span style='font-size:10.0pt;font-family:"Verdana","sans-serif";color:black'>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><span lang=NL><o:p></o:p></span></p><p class=MsoNormal><span style='font-size:10.0pt;font-family:"Verdana","sans-serif";color:black'> </span><span lang=NL><o:p></o:p></span></p><p class=MsoNormal><span style='font-size:10.0pt;font-family:"Verdana","sans-serif";color:black'>If the proposed definition is accepted all certificates with noEKU or </span><span lang=EN-GB style='font-size:10.0pt;font-family:"Verdana","sans-serif";color:black'>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><span lang=NL><o:p></o:p></span></p><p class=MsoNormal><span style='font-size:10.0pt;font-family:"Verdana","sans-serif";color:black'> </span><span lang=NL><o:p></o:p></span></p><p class=MsoNormal><span style='font-size:10.0pt;font-family:"Verdana","sans-serif";color:black'>Regards,</span><span lang=NL><o:p></o:p></span></p><p class=MsoNormal><span style='font-size:10.0pt;font-family:"Verdana","sans-serif";color:black'>Robert </span><span lang=NL><o:p></o:p></span></p><p class=MsoNormal><span lang=NL style='font-size:10.0pt;font-family:"Verdana","sans-serif";color:#1F497D'> </span><span lang=NL><o:p></o:p></span></p><p class=MsoNormal><span lang=NL style='font-size:10.0pt;font-family:"Verdana","sans-serif";color:#1F497D'> </span><span lang=NL><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 lang=NL style='font-size:10.0pt;font-family:"Tahoma","sans-serif"'>Van:</span></b><span lang=NL style='font-size:10.0pt;font-family:"Tahoma","sans-serif"'> Jeremy Rowley [<a 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><span lang=NL><o:p></o:p></span></p></div></div><p class=MsoNormal><span lang=NL> <o:p></o:p></span></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><span lang=NL><o:p></o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'> </span><span lang=NL><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"'>From:</span></b><span style='font-size:10.0pt;font-family:"Tahoma","sans-serif"'> <a href="mailto:public-bounces@cabforum.org">public-bounces@cabforum.org</a> [<a 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><span lang=NL><o:p></o:p></span></p></div></div><p class=MsoNormal> <span lang=NL><o:p></o:p></span></p><div><p class=MsoNormal>Hi Robert.<span lang=NL><o:p></o:p></span></p></div><div><p class=MsoNormal> <span lang=NL><o:p></o:p></span></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.<span lang=NL><o:p></o:p></span></p></div><div><p class=MsoNormal> <span lang=NL><o:p></o:p></span></p></div><div><p class=MsoNormal>Regards Steve<span lang=NL><o:p></o:p></span></p></div><div><p class=MsoNormal><br>Sent from my iPhone<span lang=NL><o:p></o:p></span></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 href="mailto:robert.vande.rijt@logius.nl">robert.vande.rijt@logius.nl</a>> wrote:<span lang=NL><o:p></o:p></span></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><span lang=NL><o:p></o:p></span></p><p class=MsoNormal><span style='font-size:10.0pt;font-family:"Verdana","sans-serif";color:#1F497D'> </span><span lang=NL><o:p></o:p></span></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><span lang=NL><o:p></o:p></span></p><p class=MsoNormal><span style='font-size:10.0pt;font-family:"Verdana","sans-serif";color:#1F497D'> </span><span lang=NL><o:p></o:p></span></p><p class=MsoNormal><span style='font-size:10.0pt;font-family:"Verdana","sans-serif";color:#1F497D'>Robert</span><span lang=NL><o:p></o:p></span></p><p class=MsoNormal><span style='font-size:10.0pt;font-family:"Verdana","sans-serif";color:#1F497D'> </span><span lang=NL><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"'>Van:</span></b><span style='font-size:10.0pt;font-family:"Tahoma","sans-serif"'> Jeremy Rowley [<a 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><span lang=NL><o:p></o:p></span></p></div></div><p class=MsoNormal> <span lang=NL><o:p></o:p></span></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><span lang=NL><o:p></o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'> </span><span lang=NL><o:p></o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>Jeremy</span><span lang=NL><o:p></o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'> </span><span lang=NL><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"'>From:</span></b><span style='font-size:10.0pt;font-family:"Tahoma","sans-serif"'> Rijt, R.A. van de (Robert) - Logius [<a 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 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><span lang=NL><o:p></o:p></span></p></div></div><p class=MsoNormal> <span lang=NL><o:p></o:p></span></p><div><p class=MsoNormal> <span lang=NL><o:p></o:p></span></p><p class=MsoNormal><span style='font-size:10.0pt;font-family:"Verdana","sans-serif";color:black'>Thanks for your reply, Jeremy. I conclude that with this new definition: </span><span lang=NL><o:p></o:p></span></p><p class=MsoNormal><span style='font-size:10.0pt;font-family:"Verdana","sans-serif";color:black'> </span><span lang=NL><o:p></o:p></span></p><p class=MsoNormal><span style='font-size:10.0pt;font-family:"Verdana","sans-serif";color:black'>1. We are forcing everyone with public certificates to use the EKU;</span><span lang=NL><o:p></o:p></span></p><p class=MsoNormal><span style='font-size:10.0pt;font-family:"Verdana","sans-serif";color:black'>2. We are forcing everyone with public certificates not to use the </span><span lang=EN-GB style='font-size:10.0pt;font-family:"Verdana","sans-serif";color:black'>anyExtendedKeyUsage unless it is a SSL certificate; </span><span lang=NL><o:p></o:p></span></p><p class=MsoNormal><span lang=EN-GB style='font-size:10.0pt;font-family:"Verdana","sans-serif";color:black'>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 lang=EN-GB style='font-size:10.0pt;font-family:"Verdana","sans-serif";color:#1F497D'>,</span><span lang=EN-GB style='font-size:10.0pt;font-family:"Verdana","sans-serif";color:black'> so the certificate cannot be used for the function intended. That is why the anyExtendedKeyUsage is often used as a safetynet.</span><span lang=NL><o:p></o:p></span></p><p class=MsoNormal><span lang=EN-GB style='font-size:10.0pt;font-family:"Verdana","sans-serif";color:black'> </span><span lang=NL><o:p></o:p></span></p><p class=MsoNormal><span lang=EN-GB style='font-size:10.0pt;font-family:"Verdana","sans-serif";color:black'>Robert</span><span lang=NL><o:p></o:p></span></p><p class=MsoNormal><span style='font-size:10.0pt;font-family:"Verdana","sans-serif";color:#1F497D'> </span><span lang=NL><o:p></o:p></span></p><p class=MsoNormal><span style='font-size:10.0pt;font-family:"Verdana","sans-serif";color:#1F497D'> </span><span lang=NL><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"'>Van:</span></b><span style='font-size:10.0pt;font-family:"Tahoma","sans-serif"'> Ryan Hurst [<a 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 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><span lang=NL><o:p></o:p></span></p></div></div><p class=MsoNormal> <span lang=NL><o:p></o:p></span></p><div><p class=MsoNormal>I concur with Jeremy's analysis.<br><br>Ryan Hurst<span lang=NL><o:p></o:p></span></p><div><div><p class=MsoNormal>Chief Technology Officer<span lang=NL><o:p></o:p></span></p></div><div><p class=MsoNormal>GMO Globalsign<span lang=NL><o:p></o:p></span></p></div><div><p class=MsoNormal> <span lang=NL><o:p></o:p></span></p></div><div><p class=MsoNormal>twitter: @rmhrisk<span lang=NL><o:p></o:p></span></p></div><div><p class=MsoNormal>email: <a href="mailto:ryan.hurst@globalsign.com">ryan.hurst@globalsign.com</a><span lang=NL><o:p></o:p></span></p></div><div><p class=MsoNormal>phone: 206-650-7926<span lang=NL><o:p></o:p></span></p></div><div><p class=MsoNormal> <span lang=NL><o:p></o:p></span></p></div><div><p class=MsoNormal>Sent from my phone, please forgive the brevity.<span lang=NL><o:p></o:p></span></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 href="mailto:jeremy.rowley@digicert.com">jeremy.rowley@digicert.com</a>> wrote:<span lang=NL><o:p></o:p></span></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><span lang=NL><o:p></o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif"'> </span><span lang=NL><o:p></o:p></span></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><span lang=NL><o:p></o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif"'> </span><span lang=NL><o:p></o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif"'>Here’s my logic:</span><span lang=NL><o:p></o:p></span></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><span lang=NL><o:p></o:p></span></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><span lang=NL><o:p></o:p></span></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><span lang=NL><o:p></o:p></span></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><span lang=NL><o:p></o:p></span></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><span lang=NL><o:p></o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif"'> </span><span lang=NL><o:p></o:p></span></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><span lang=NL><o:p></o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif"'> </span><span lang=NL><o:p></o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif"'>Jeremy</span><span lang=NL><o:p></o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'> </span><span lang=NL><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"'>From:</span></b><span style='font-size:10.0pt;font-family:"Tahoma","sans-serif"'> <a href="mailto:public-bounces@cabforum.org">public-bounces@cabforum.org</a> [<a 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><span lang=NL><o:p></o:p></span></p></div></div><p class=MsoNormal> <span lang=NL><o:p></o:p></span></p><div><p class=MsoNormal><span lang=EN-GB style='font-size:10.0pt;font-family:"Verdana","sans-serif";color:black'>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><span lang=NL><o:p></o:p></span></p><p class=MsoNormal><span lang=EN-GB style='font-size:10.0pt;font-family:"Verdana","sans-serif";color:black'> </span><span lang=NL><o:p></o:p></span></p><p class=MsoNormal><span lang=EN-GB style='font-size:10.0pt;font-family:"Verdana","sans-serif";color:black'>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><span lang=NL><o:p></o:p></span></p><p class=MsoNormal><span lang=EN-GB style='font-size:10.0pt;font-family:"Verdana","sans-serif";color:black'> </span><span lang=NL><o:p></o:p></span></p><p class=MsoNormal><span style='font-size:10.0pt;font-family:"Verdana","sans-serif";color:black'>Regards, </span><span lang=NL><o:p></o:p></span></p><p class=MsoNormal><span style='color:black'>Robert</span><span lang=NL><o:p></o:p></span></p><p class=MsoNormal> <span lang=NL><o:p></o:p></span></p><p class=MsoNormal> <span lang=NL><o:p></o:p></span></p><p class=MsoNormal><span lang=EN style='font-size:10.0pt;font-family:"Verdana","sans-serif";color:#1F497D'> </span><span lang=NL><o:p></o:p></span></p><p class=MsoNormal><span lang=EN style='font-size:10.0pt;font-family:"Verdana","sans-serif";color:#1F497D'> </span><span lang=NL><o:p></o:p></span></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 href="mailto:public-bounces@cabforum.org">public-bounces@cabforum.org</a> [<a 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><span lang=NL><o:p></o:p></span></p></div><p class=MsoNormal> <span lang=NL><o:p></o:p></span></p><p>They're still respected (for better or worse) by Apple, NSS, and Android.<span lang=NL><o:p></o:p></span></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.<span lang=NL><o:p></o:p></span></p><div><p class=MsoNormal>On Jul 29, 2013 1:52 PM, "Kelvin Yiu" <<a href="mailto:kelviny@exchange.microsoft.com">kelviny@exchange.microsoft.com</a>> wrote:<span lang=NL><o:p></o:p></span></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 href="mailto:public-bounces@cabforum.org">public-bounces@cabforum.org</a> [mailto:<a 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 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 href="mailto:Public@cabforum.org">Public@cabforum.org</a><br>> <a href="https://cabforum.org/mailman/listinfo/public" target="_blank">https://cabforum.org/mailman/listinfo/public</a><br>><br>_______________________________________________<br>Public mailing list<br><a href="mailto:Public@cabforum.org">Public@cabforum.org</a><br><a href="https://cabforum.org/mailman/listinfo/public" target="_blank">https://cabforum.org/mailman/listinfo/public</a><span lang=NL><o:p></o:p></span></p></div></div><p class=MsoNormal> <span lang=NL><o:p></o:p></span></p><div class=MsoNormal align=center style='text-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><span lang=NL><o:p></o:p></span></p></div></blockquote><blockquote style='margin-top:5.0pt;margin-bottom:5.0pt'><div><p class=MsoNormal>_______________________________________________<br>Public mailing list<br><a href="mailto:Public@cabforum.org">Public@cabforum.org</a><br><a href="https://cabforum.org/mailman/listinfo/public">https://cabforum.org/mailman/listinfo/public</a><span lang=NL><o:p></o:p></span></p></div></blockquote></div><p class=MsoNormal> <span lang=NL><o:p></o:p></span></p><div class=MsoNormal align=center style='text-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><span lang=NL><o:p></o:p></span></p></div><p class=MsoNormal> <span lang=NL><o:p></o:p></span></p><div class=MsoNormal align=center style='text-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><span lang=NL><o:p></o:p></span></p></div></blockquote><blockquote style='margin-top:5.0pt;margin-bottom:5.0pt'><div><p class=MsoNormal>_______________________________________________<br>Public mailing list<br><a href="mailto:Public@cabforum.org">Public@cabforum.org</a><br><a href="https://cabforum.org/mailman/listinfo/public">https://cabforum.org/mailman/listinfo/public</a><span lang=NL><o:p></o:p></span></p></div></blockquote></div><p class=MsoNormal><span lang=NL><o:p> </o:p></span></p><div class=MsoNormal align=center style='text-align:center'><span lang=NL><hr size=3 width="100%" align=center></span></div><p class=MsoNormal><span lang=NL 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><span lang=NL><o:p></o:p></span></p></div></body></html>