[cabfpub] rfc822Names and otherNames

[Jeremy Rowley]

I see. I was thinking we’d allow whatever otherName was wanted, provided the CA understood the meaning (similar to how we deal with unknown extensions). If we’re going to limit the otherName to clearly identified OID, then I’d like to include:

 

id-wfa-hotspot-friendlyName OBJECT IDENTIFIER ::= { 1.3.6.1.4.1.40808.1.1.1 }

 

I’m not aware of any other otherNames at this time.

 

Thanks,

Jeremy

 

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

 

Jeremy,

 

I'm not sure it was clear. otherName is a wide-open type, as defined in https://tools.ietf.org/html/rfc5280#section-4.2.1.6

 

More accurately, it's

   OtherName ::= SEQUENCE {

        type-id    OBJECT IDENTIFIER,

        value      [0] EXPLICIT ANY DEFINED BY type-id }

 

I'm trying to suggest/request that otherNames only be permitted for defined type-ids, or some other appropriate rule/guidance to mitigate any collisions (e.g. only issued by an enterprise OID arc operated by the CA), to avoid name confusion.

 

For example, you wouldn't want CAs using Kerberos 5 identities in otherName, especially if that could cause issues/security problems with PKINIT-based systems.

 

On Wed, Dec 14, 2016 at 8:44 AM, Jeremy Rowley <jeremy.rowley at digicert.com <mailto:jeremy.rowley at digicert.com> > wrote:

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

 

Jeremy

 

From: Ryan Sleevi [mailto:sleevi at google.com <mailto:sleevi at google.com> ] 
Sent: Wednesday, December 14, 2016 9:14 AM
To: CA/Browser Forum Public Discussion List <public at cabforum.org <mailto:public at cabforum.org> >
Cc: Jeremy Rowley <jeremy.rowley at digicert.com <mailto: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/6fb603a7/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/6fb603a7/attachment-0001.p7s>