<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">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:<br>
</div>
<blockquote
cite="mid:087f01ce8ec3$5f928d90$1eb7a8b0$@globalsign.com"
type="cite">
<meta http-equiv="Content-Type" content="text/html;
charset=ISO-8859-1">
<meta name="Generator" content="Microsoft Word 14 (filtered
medium)">
<!--[if !mso]><style>v\:* {behavior:url(#default#VML);}
o\:* {behavior:url(#default#VML);}
w\:* {behavior:url(#default#VML);}
.shape {behavior:url(#default#VML);}
</style><![endif]-->
<style><!--
/* Font Definitions */
@font-face
{font-family:"Cambria Math";
panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
{font-family:Calibri;
panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
{font-family:Tahoma;
panose-1:2 11 6 4 3 5 4 4 2 4;}
@font-face
{font-family:Consolas;
panose-1:2 11 6 9 2 2 4 3 2 4;}
@font-face
{font-family:Verdana;
panose-1:2 11 6 4 3 5 4 4 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0in;
margin-bottom:.0001pt;
font-size:12.0pt;
font-family:"Times New Roman","serif";}
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]-->
<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"">
<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>Rijt,
R.A. van de (Robert) - Logius<br>
<b>Sent:</b> Thursday, August 01, 2013 5:09 PM<br>
<b>To:</b> <a class="moz-txt-link-abbreviated" 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<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
style="font-size:10.0pt;font-family:"Verdana","sans-serif";color:black"
lang="EN">keyAgreement</span><span
style="font-size:10.0pt;color:black" lang="EN"> </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
style="font-size:10.0pt;font-family:"Verdana","sans-serif";color:black"
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><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
style="font-size:10.0pt;font-family:"Verdana","sans-serif";color:#1F497D"
lang="NL"> </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"
lang="NL"> </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""
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><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 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><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 moz-do-not-send="true"
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 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><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
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><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
style="font-size:10.0pt;font-family:"Verdana","sans-serif";color:black"
lang="EN-GB">anyExtendedKeyUsage unless it is a
SSL certificate; </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"
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";color:black"
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><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"
lang="EN-GB"> </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"
lang="EN-GB">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 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><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
moz-do-not-send="true"
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
moz-do-not-send="true"
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 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><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
style="font-size:10.0pt;font-family:"Verdana","sans-serif";color:black"
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><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"
lang="EN-GB"> </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"
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><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"
lang="EN-GB"> </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
style="font-size:10.0pt;font-family:"Verdana","sans-serif";color:#1F497D"
lang="EN"> </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"
lang="EN"> </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 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><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 moz-do-not-send="true"
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 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><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" 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><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 moz-do-not-send="true"
href="mailto:Public@cabforum.org">Public@cabforum.org</a><br>
<a moz-do-not-send="true"
href="https://cabforum.org/mailman/listinfo/public">https://cabforum.org/mailman/listinfo/public</a><span
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" 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><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" 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><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 moz-do-not-send="true"
href="mailto:Public@cabforum.org">Public@cabforum.org</a><br>
<a moz-do-not-send="true"
href="https://cabforum.org/mailman/listinfo/public">https://cabforum.org/mailman/listinfo/public</a><span
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" 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><span
lang="NL"><o:p></o:p></span></p>
</div>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
<pre wrap="">_______________________________________________
Public mailing list
<a class="moz-txt-link-abbreviated" href="mailto:Public@cabforum.org">Public@cabforum.org</a>
<a class="moz-txt-link-freetext" href="https://cabforum.org/mailman/listinfo/public">https://cabforum.org/mailman/listinfo/public</a>
</pre>
</blockquote>
<br>
</body>
</html>