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:[email protected]] *On Behalf Of *Ryan
Sleevi via Public
*Sent:* Friday, May 18, 2018 9:18 AM
*To:* Dimitris Zacharopoulos <[email protected]>; CA/Browser Forum
Public Discussion List <[email protected]>
*Subject:* Re: [cabfpub] For Discussion: S/MIME Working Group Charter
On Fri, May 18, 2018 at 12:57 AM, Dimitris Zacharopoulos via Public
<[email protected] <mailto:[email protected]>> 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
[email protected]
https://cabforum.org/mailman/listinfo/public
_______________________________________________
Public mailing list
[email protected]
https://cabforum.org/mailman/listinfo/public
