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

Moudrick M. Dadashov md at ssc.lt
Thu May 24 15:48:29 UTC 2018


Just to be clear, by S/MIME I mean ***message format***, whereas 
clientAuth is a ***process*** (at least as we accept it under eIDAS). 
BTW, eIDAS is completely technology neutral - clientAuth is not an eIDAS 
term.

With that said, I was looking for some criteria/rules that help us to 
identify the WG task.

Thanks,
M.D.

On 5/24/2018 8:04 AM, Dimitris Zacharopoulos wrote:
>
> 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).
>
> 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.
>
> 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.
>
> 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 :)
>
>
>
> Dimitris.
>
> On 24/5/2018 2:34 πμ, Moudrick M. Dadashov wrote:
>> 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/1c40de01/attachment-0003.html>


More information about the Public mailing list