[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-0002.html>
More information about the Public
mailing list