[cabfpub] For Discussion: S/MIME Working Group Charter

Wed May 23 23:34:05 UTC 2018

All three (clentAuth and S/MIME) use scenarios are essentially different.

Validation requirements for issuing signing/encryption certificates are 
mostly similar, clientAuth (as we understand it under eIDAS*) is different.

Thanks,
M.D.

* Article 3
(5) ‘/*authentication*’ 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/.

(1) ‘/*electronic identification*’ 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/.

(2) ‘/*electronic identification means*’ means a material and/or 
immaterial unit containing person identification data and which is used 
for authentication for an online service/.

On 5/24/2018 12:16 AM, Brown, Wendy (10421) via Public wrote:
>
> 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..
>
> *From:*Public [mailto:public-bounces at cabforum.org] *On Behalf Of *Ryan 
> Sleevi via Public
> *Sent:* Friday, May 18, 2018 9:18 AM
> *To:* Dimitris Zacharopoulos <jimmy at it.auth.gr>; CA/Browser Forum 
> Public Discussion List <public at cabforum.org>
> *Subject:* Re: [cabfpub] For Discussion: S/MIME Working Group Charter
>
> On Fri, May 18, 2018 at 12:57 AM, Dimitris Zacharopoulos via Public 
> <public at cabforum.org <mailto:public at cabforum.org>> wrote:
>
>     On 18/5/2018 2:51 πμ, Ryan Sleevi via Public wrote:
>
>         I don't think it's a cross-EKU situation, though, but I'm glad
>         we're in agreement.
>
>         An email server certificate is an id-kp-serverAuth EKU. That's
>         already covered by another WG
>
>
>     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.
>
>     If people agree, how about using the name "Client and S/MIME
>     Certificate WG" which seems aligned with the "Server Certificate WG"?
>
> 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.
>
> 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.
>
> 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.
>
> 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'.
>
> 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.
>
> 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.
>
> 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.
>
>
> _______________________________________________
> Public mailing list
> Public at cabforum.org
> https://cabforum.org/mailman/listinfo/public

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cabforum.org/pipermail/public/attachments/20180524/87b86263/attachment-0003.html>