[cabfpub] rfc822Names and otherNames

[Jeremy Rowley]

Agreed. The only types I want to permit are otherNames and rfc822Names.

 

Jeremy

 

From: Ryan Sleevi [mailto:sleevi at google.com] 
Sent: Wednesday, December 14, 2016 9:14 AM
To: CA/Browser Forum Public Discussion List <public at cabforum.org>
Cc: Jeremy Rowley <jeremy.rowley at digicert.com>
Subject: Re: [cabfpub] rfc822Names and otherNames

 

 

 

On Tue, Dec 13, 2016 at 10:13 PM, Jeremy Rowley via Public <public at cabforum.org <mailto:public at cabforum.org> > wrote:

Therefore, I’d like to modify the baseline requirements to permit other name types. Does anyone else see a need for this? Are there risks in permitting the additional names that I’m not aware of?

 

In general, permitting specific name types, with specific documentation on the information they contain, should be an OK thing.

 

However, letting CAs decide entirely will forever salt the earth there for being able to use those name types, and may result in additional security risk - much like the issues with validation and "any equivalent method"

 

So, to the extent possible, I'd like to treat it as a validation method - that is, there's (generally) no harm in adding additional name types (provided they don't cause compat issues), so long as the industry can agree on the nature and structure of the data. Or make sure they're not technically capable of being used as TLS certs due to their issuing intermediate being technically restricted via EKU :) 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cabforum.org/pipermail/public/attachments/20161214/76b63c5f/attachment-0003.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4964 bytes
Desc: not available
URL: <http://lists.cabforum.org/pipermail/public/attachments/20161214/76b63c5f/attachment-0001.p7s>