Subject: RE: Logotypes in certificates

From: "Tom Gindin" <[email-masked]>
Date: Wed, 21 Mar 2001 12:47:14 -0500

Wouldn't Logotypes most easily be implemented as an OTHER-NAME within
one of the alternate name fields (probably SubjectAltName)?  If so, how
would they affect NameConstraints and the like?  IMHO, they would have
little effect on them since logos are not hierarchical names and thus
couldn't easily be governed by NameConstraints.
     Since they are naming (or at least identifying) information about the
subject or issuer, I don't see why they should be in a different extension.
IMO, the standard way of displaying these should be to display the logo
along with the text of the highest-precedence ID for that entity anyway.
Binding them together in the same extension would encourage that.

          Tom Gindin

Ambarish Malpani <[email-masked]> on 03/21/2001 12:06:35 PM

To:   "'Stephen Kent'" <[email-masked]>, Dean Povey <[email-masked]>
cc:   [email-masked]
Subject:  RE: Logotypes in certificates

Steve,
    This is the same argument as a CA issuing a cert to a
subordinate, who issues incorrect certificates with it - e.g.
issues a certificate for the domain www.amazon.com to say BN.

Either a CA controls/audits subordinate CAs, or has enough
reason to trust them, or the value of that hierarchy is
pretty useless.

I don't think logos in certificates affect this either way.

Regards,
Ambarish

---------------------------------------------------------------------
Ambarish Malpani
Architect                                                650.567.5457
ValiCert, Inc.                                  [email-masked]
339 N. Bernardo Ave.                          http://www.valicert.com
Mountain View, CA 94043

> -----Original Message-----
> From: Stephen Kent [mailto:[email-masked]]
> Sent: Tuesday, March 20, 2001 8:57 PM
> To: Dean Povey
> Cc: [email-masked]
> Subject: Re: Logotypes in certificates
>
>
> Dean and Stefan,
>
> As a security kinda' guy, I always approach this from the "what will
> the bad giy do" perspective.  From that perspective, I worry that a
> TTP CA will cerfity company X, putting the company X logo in the
> cert. Then company X will issue a cert to a subordinate CA, and put
> in that cert an inappropriate logo. It is not realistic for an app to
> display a chain of logos, and expect a user to pay attention, any
> more that if one displayed a chain of DNs.  I still maintain that we
> can agree on what would be a reasonable set of circumstances in which
> the logo extension would be useful and safe, but I don't see a
> technical means of enforcing these circumstances without changes to
> the path validation algorithm. I am open to suggestions that provide
> the necessary controls and don't have this unfortunate side effect,
> but I have yet to see an example of such.
>
> Steve
>

---

From: Stephen Kent <[email-masked]>
Date: Wed, 21 Mar 2001 18:03:54 -0500

Tom,

>Binding them together in the same extension would encourage that.

I think the answer to your first question is no, but we need to hear 
from Stefan about what he envisioned. I was assuming a new extension. 
If logos were stuffed into an OtherName, the best we could do is to 
prohibit them by ruling out use of that name type in the subject alt 
name field via nameConstraints. Now maybe we're getting some handle 
on control that works with the current path validation algorithm, but 
it's not much.

We need to see a more concrete proposal before we can proceed with a 
reasoned, technical evaluation of the potential for this proposed 
field.

Steve

---

From: Dean Povey <[email-masked]>
Date: Thu, 22 Mar 2001 14:38:55 +1000

While I tend to dislike things like name constraints or actually any top
down asserted constraints (they are things that can be easily controlled by
external policy controls and they make automated path building a right pain
in the butt), I can understand Stephen's concerns, and we need to come up
with a sensible approach to this.

As far as I can see there is no other sensible way to constrain logos other
than to specificaly disallow them in some future certificate(s) in the path
chain.  Everything else will have to rely on sufficient due-dilligence of
the CA to verify they are correct.  Let's face it they don't do this
already for the things they are supposed to do we are stuffed, regardless
of how many constraints a higher level CA imposes.

The path validation algorithm is complex as it is, so I would favour an 
approach that had as little effect on it as possible.  I also think that 
by and large these type of constraints don't get used very often, so I 
think we also need to consider making the most common case usage the 
easiest.

I can see three options (well actually the fourth one is to say that
it is up to the CA policy to enforce constraints):

1. Using an OtherName in subjectAlt has a certain logic to it.  I had also 
   envisioned subject only logos but there is nothing to stop issuer's 
   putting theirs in as well.  The constraints problem would logically be 
   punted to the NameConstraints extension.  

   Unfortunately X.509/RFC2459/Son-of-RFC2459 doesn't describe any
   semantics for name constraints with OtherName so vendors will have to
   fix their path validation anyway.  They may also have to fix their 
   implementations to handle the new OID -> type mapping.

2. An uglier but perhaps more pragmatic approach is to create a logo
   attribute and shove it in a DN (preferably in altName) with either 
   PKCS9String or IA5String type.  

   Unfortunately, unless I have misunderstood the way name constraints
   works for DNs the only way that I can that a CA could stop a 
   subordinate CA from issuing certificates with a logo is to require
   that CA to include a logo attribute with a known NULL value, as I can't
   think of another way of excluding a given attribute from the DN 
   namespace.

   This would probably work without changing any/much existing code. 
   However given this working groups general aversion to putting stuff in
   the DN, I can't see this being very popular.

3. Possibly the most elegant approach, but one which unfortunately has the
   most impact on current standards is to fix the general problem of
   enforcing constraints on user certs.  While logo type has been singled out,
   the scenario Stephen describes applies to any extension 
   outside a small subset which the path validation explicitly handles.

   Fixing this is relatively easy.  We define can define an 
   ExtensionsConstraints extension which looks something like:
   
   extensionsConstraints EXTENSION ::= {
        SYNTAX          ExtensionConstraintSyntax
        IDENTIFIED BY   id-ce-extensionConstraint }

   ExtensionsConstraintsSyntax ::= SEQUENCE {
     permittedExtensions     SEQUENCE OF ExtensionConstraint (1..MAX) OPTIONAL,
     excludedExtensions  [0] SEQUENCE OF ExtensionConstraint (1..MAX) OPTIONAL,
     requiredExtensions  [1] SEQUENCE OF ExtensionConstraint (1..MAX) OPTIONAL
   }
     
   ExtensionConstraint ::= SEQUENCE {
     constrainedExtensions SEQUENCE OF OBJECT IDENTIFIER (1..MAX),
     skipCerts             SkipCerts
   }

   permittedExtensions lists those extensions which are explicitly allowed
   to appear after some later point in the certificate path.

   excludedExtensions lists those extensions which explicitly disallowed
   to appear after some later point in the certificate path.

   requiredExtensions lists those extensions which MUST appear at some 
   later point in the certificate path.

   Each of these lists contains one more ExtensionConstraint which lists 
   the OIDs for which the constraint applies and the number of Certificates
   to skip before applying the constraint (ala PolicyConstraints).
   
   We then define the logo indicator as a simple extension as indicated
   earlier and then the CA is free to exclude it (or any other extension
   they don't trust a subordinate CA with).

   If you wanted to go further you could deprecate PolicyConstraints as 
   this new extension fully supports it.

   I like this approach best as it is simple, general and fixes this 
   problem for most simple cases.  It also allows some more explicit 
   expression of policy in the Certificate in a machine interpretable way.
   The big downside of course is that this means creating a path validation
   process incompatible with X.509 and changing a bunch of implementations
   which is never fun.

Anyway just tossing ideas around.

Cheers.
-- 
Dean Povey,         | e-m: [email-masked] | JCSI:  Java Crypto Toolkit 
Research Scientist  | ph:  +61 7 3864 5120   | uPKI:  C PKI toolkit for embedded
Security Unit, DSTC | fax: +61 7 3864 1282   |        systems
Brisbane, Australia | www: security.dstc.com | Oscar: C++ PKI toolkit