<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
</head>
<body text="#000000" bgcolor="#FFFFFF">
<br>
Moudrick, I don't think we are describing just use scenarios. This
is about subject validation and as you are very well familiar, eIDAS
is also setting requirements for how you validate natural persons
and legal entities. Then, you can use this validated information for
different trust services (authenticate, sign, encrypt, etc).<br>
<br>
We already have identity validation requirements for the server
certificate Working Group, described in DV/OV/EV Policies for
certificates with id-kp-serverAuth EKU. Why shouldn't we include
identity validation requirements for this new Working Group for
certificates with id-kp-clientAuth and id-kp-emailProtection EKU?
The overlap in subject validation requirements between these two
cases is pretty obvious.<br>
<br>
Even though I'd like the clientAuth to be included in the WG's
initial charter, I understand Ryan's argument for gradually building
a standard with minimum expectations at the beginning (thus limiting
the scope for S/MIME only) and expand the scope later. <br>
<br>
So, until then, the clientAuth Certificates will remain kind-of
"unregulated" by lacking a policy standard. I suppose we will have
to live with that :)<br>
<br>
<br>
<br>
Dimitris.<br>
<br>
<div class="moz-cite-prefix">On 24/5/2018 2:34 πμ, Moudrick M.
Dadashov wrote:<br>
</div>
<blockquote type="cite"
cite="mid:77fbe7ff-d4e4-96d8-3c86-b548243f2980@ssc.lt">
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
<font face="Cambria">All three (clentAuth and S/MIME) use
scenarios are </font><font face="Cambria">essentially
different.<br>
<br>
Validation requirements for issuing signing/encryption
certificates are mostly similar, clientAuth (as we understand it
under eIDAS*) is different.<br>
<br>
Thanks,<br>
M.D. <br>
<br>
* Article 3<br>
(5) ‘<i><b>authentication</b>’ means an electronic process that
enables the electronic identification of a natural or legal
person, or the origin and integrity of data in electronic form
to be confirmed</i>.<br>
<br>
(1) ‘<i><b>electronic identification</b>’ means the process of
using person identification data in electronic form uniquely
representing either a natural or legal person, or a natural
person representing a legal person</i>.<br>
<br>
(2) ‘<i><b>electronic identification means</b>’ means a material
and/or immaterial unit containing person identification data
and which is used for authentication for an online service</i>.<br>
<br>
</font><br>
<br>
<div class="moz-cite-prefix">On 5/24/2018 12:16 AM, Brown, Wendy
(10421) via Public wrote:<br>
</div>
<blockquote type="cite"
cite="mid:BN6PR03MB304450C8EAF8EB178305B171EE6B0@BN6PR03MB3044.namprd03.prod.outlook.com">
<meta http-equiv="Content-Type" content="text/html;
charset=utf-8">
<meta name="Generator" content="Microsoft Word 15 (filtered
medium)">
<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;}
/* 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;}
span.gmail-
{mso-style-name:gmail-;}
span.EmailStyle18
{mso-style-type:personal-reply;
font-family:"Calibri",sans-serif;
color:#1F497D;}
.MsoChpDefault
{mso-style-type:export-only;
font-family:"Calibri",sans-serif;}
@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">I
second the opinion that clientAuth and S/Mime are likely
to have a great overlap in validation requirements at
least when issuing to persons and PKIs may want to issue
both types of certs from the same CA if they are for the
same validated individual..<o:p></o:p></span></p>
<p class="MsoNormal"><a name="_MailEndCompose"
moz-do-not-send="true"><span
style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D"><o:p> </o:p></span></a></p>
<p class="MsoNormal"><b><span
style="font-size:11.0pt;font-family:"Calibri",sans-serif">From:</span></b><span
style="font-size:11.0pt;font-family:"Calibri",sans-serif">
Public [<a class="moz-txt-link-freetext"
href="mailto:public-bounces@cabforum.org"
moz-do-not-send="true">mailto:public-bounces@cabforum.org</a>]
<b>On Behalf Of </b>Ryan Sleevi via Public<br>
<b>Sent:</b> Friday, May 18, 2018 9:18 AM<br>
<b>To:</b> Dimitris Zacharopoulos <a
class="moz-txt-link-rfc2396E"
href="mailto:jimmy@it.auth.gr" moz-do-not-send="true"><jimmy@it.auth.gr></a>;
CA/Browser Forum Public Discussion List <a
class="moz-txt-link-rfc2396E"
href="mailto:public@cabforum.org" moz-do-not-send="true"><public@cabforum.org></a><br>
<b>Subject:</b> Re: [cabfpub] For Discussion: S/MIME
Working Group Charter<o:p></o:p></span></p>
<p class="MsoNormal"><o:p> </o:p></p>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
<div>
<p class="MsoNormal">On Fri, May 18, 2018 at 12:57 AM,
Dimitris Zacharopoulos via Public <<a
href="mailto:public@cabforum.org" target="_blank"
moz-do-not-send="true">public@cabforum.org</a>>
wrote:<o:p></o:p></p>
<blockquote style="border:none;border-left:solid #CCCCCC
1.0pt;padding:0in 0in 0in
6.0pt;margin-left:4.8pt;margin-right:0in">
<div>
<p class="MsoNormal" style="margin-bottom:12.0pt"><span
class="gmail-"><o:p> </o:p></span></p>
<div>
<p class="MsoNormal">On 18/5/2018 2:51 πμ, Ryan
Sleevi via Public wrote:<o:p></o:p></p>
</div>
<blockquote
style="margin-top:5.0pt;margin-bottom:5.0pt">
<div>
<p class="MsoNormal">I don't think it's a
cross-EKU situation, though, but I'm glad
we're in agreement. <o:p></o:p></p>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">An email server
certificate is an id-kp-serverAuth EKU.
That's already covered by another WG<o:p></o:p></p>
</div>
</div>
</blockquote>
<p class="MsoNormal"><br>
I sincerely hope that id-kp-clientAuth EKU will
also be covered by this WG since there will be
common validation requirements for Subject
information, as with S/MIME. It seems too much
overhead to spawn an entirely different WG to deal
just with clientAuth.<br>
<br>
If people agree, how about using the name "Client
and S/MIME Certificate WG" which seems aligned
with the "Server Certificate WG"?<o:p></o:p></p>
</div>
</blockquote>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">As I've mentioned several times,
it would be good to actually focus on a constrained,
defined problem, before you proverbially try to boil
the ocean.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">It is not obvious that there will
be common validation requirements, because the
id-kp-clientAuth situation has a vast dimension of
possible uses and spectrum. It's not actually
reflective of the deployed reality that the
validation requirements are the same. It also is
based on an entirely separate notion of identity.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">So no, I don't agree, because
they really are substantially different in deployed
reality - and an S/MIME WG is, in itself, a sizable
undertaking just to get S/MIME BRs, due to the broad
spectrum of client capabilities and CA
past-practices - and the lifetime of extant
certificates that presents unique challenges to
defining a sensible and realistic profile.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">A good charter - one that leads
to productive engagement from a broad set of
participants while actually delivering meaningful
improvements - is one that keeps itself narrowly
focused on the task at hand, produces results, and
then looks to recharter based on the things you knew
were out there, but agreed not to discuss until you
actually completed the work. That allows you to keep
momentum, focus, and participation. Just look at the
challenges each of our (legacy) WG has faced with a
broad remit, in that the set of topics has made it
difficult both to engage participation of the
broader Forum and to actually make forward progress,
because it's constantly having to deal with 'all
these things' or trying to do 'all these things'.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">When we see narrowly focused
ballots and efforts that try to solve a specific set
of problems, then we make progress. The validation
WG's effort at 3.2.2.4 is a prime example of that -
a prolonged effort that directly benefited from
being focused on that problem, and ruling some
things (like 3.2.2.5) out of scope of the discussion
in order to make progress on the narrow set.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">The same too is in the charter.
Let's not try to encompass pet marketing projects
(EV for S/MIME), "things we might need but we don't
know why" (network security), or "things that are
kinda related, but only in some domains"
(id-kp-clientAuth). Let's focus on the problem at
hand - S/MIME authentication - keeping the WG scoped
narrowly and on task, and deliver something that can
help users have faith in the Web PKI to deliver
tangible benefits in that space, rather than the
reality we have today.<o:p></o:p></p>
</div>
</div>
</div>
</div>
</div>
NOTICE: Protiviti is a global consulting and internal audit firm
composed of experts specializing in risk and advisory services.
Protiviti is not licensed or registered as a public accounting
firm and does not issue opinions on financial statements or
offer attestation services. This electronic mail message is
intended exclusively for the individual or entity to which it is
addressed. This message, together with any attachment, may
contain confidential and privileged information. Any views,
opinions or conclusions expressed in this message are those of
the individual sender and do not necessarily reflect the views
of Protiviti Inc. or its affiliates. Any unauthorized review,
use, printing, copying, retention, disclosure or distribution is
strictly prohibited. If you have received this message in error,
please immediately advise the sender by reply email message to
the sender and delete all copies of this message. Thank you. <br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
<pre wrap="">_______________________________________________
Public mailing list
<a class="moz-txt-link-abbreviated" href="mailto:Public@cabforum.org" moz-do-not-send="true">Public@cabforum.org</a>
<a class="moz-txt-link-freetext" href="https://cabforum.org/mailman/listinfo/public" moz-do-not-send="true">https://cabforum.org/mailman/listinfo/public</a>
</pre>
</blockquote>
<br>
</blockquote>
<br>
</body>
</html>