<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
</head>
<body text="#000000" bgcolor="#FFFFFF">
<font face="Cambria">Just to be clear, by S/MIME I mean ***message
format***, whereas clientAuth is a ***process*** (at least as we
accept it under eIDAS). </font><font face="Cambria"><font
face="Cambria">BTW, eIDAS is completely technology neutral -
clientAuth is not an eIDAS term.<br>
<br>
</font>With that said, I was looking for some criteria/rules that
help us to identify the WG task.<br>
<br>
Thanks,<br>
M.D. </font><br>
<br>
<div class="moz-cite-prefix">On 5/24/2018 8:04 AM, Dimitris
Zacharopoulos wrote:<br>
</div>
<blockquote type="cite"
cite="mid:978839b2-53eb-fefb-fb78-945202adb0b4@it.auth.gr">
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
<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>
</blockquote>
<br>
</body>
</html>