[cabfpub] rfc822Names and otherNames

[Ryan Sleevi]

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>
wrote:

> 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> 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/7913e131/attachment-0003.html>