[Smcwg-public] Subject DN validation requirements

[Doug Beattie]

The discussion on CommonName validation is taking on a life of its own and I wonder if we can take a step back.

 

The Charter is here:  <https://cabforum.org/smcwg-charter/> https://cabforum.org/smcwg-charter/

 

And it says the following:

The primary use case under consideration for the working group is a model whereby senders and recipients of email messages receive “reasonable assurance” that the other party to the communication identified in the certificate has control of the domain or email address being asserted. A variation of this primary use case is where an individual or organization digitally signs email to establish its authenticity and source of origin.

Therefore, in order to provide reasonable assurance, it is crucial to establish a standard method to validate an email address and the subject’s identity (if present) prior to binding them to the public key. “Reasonable assurance” is to be determined and defined by this SMCWG through studying the existing methods that exist in the industry, as well as identity management frameworks and any applicable legislation.

What did we mean by reasonable assurance?  The charter says the WG would do this by studying existing methods, and yes, tons of existing methods have been studied

 

I wonder if we’re taking the specification of subject DN validation a bit further than necessary, especially as it relates to CN, OU and pseudonyms.  I think every CA that uses an enterprise RA permits them to enter those 3 fields without formal CA control or auditing.  Wendy brings up a good point for OU where it’s important/necessary to specify where within the US government this entity sits. 

 

Remember, these are just email certificates and users will most likely rely on the email from and reply to headers way more that digging into the details of the subject DN.  These are not intended to be used for signing legal documents or taking our loans and mortgages, they are for securing email.  If there is a usecase for high assurance email certificaes, then let’s let those industries define them on top of the secure mail specification we’re working on.

 

In order to move the spec along and get it relased with the email validation rules, the most important thing imo, can we relax the validation of those 3 fields and permit them to be entered by the Enteprise RA without CA auditing requirements?  If not, then I propose we specify a legacy profile that does and that we defer on this more strict set of rules and see if there is a need for that level of validaiton at all.  

 

We really need to define the permiggdc domain/email validation methods and lock that down without impacting the way S/MIME certificates are used today.  There was a lot of discussions when the charter was created about it’s scope where some thought email validaiton was the only important thing, others wanted it first, and others wanted to address the whole problem (email and subject DN).  In the end the charter covers everything, but maybe it’s time to refocus a little and get a draft spec out for balloting without overspecifying subject DN validation rules?

 

Doug

 

 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cabforum.org/pipermail/smcwg-public/attachments/20220310/75c94e5a/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 8404 bytes
Desc: not available
URL: <http://lists.cabforum.org/pipermail/smcwg-public/attachments/20220310/75c94e5a/attachment-0001.p7s>