Re: Logotypes in certificates

[Dean Povey <[e-mail]>]

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: [e-mail] | JCSI:  Java Crypto Toolkit 
Research Scientist  | ph:  [phone]   | uPKI:  C PKI toolkit for embedded
Security Unit, DSTC | fax: [phone]   |        systems
Brisbane, Australia | www: security.dstc.com | Oscar: C++ PKI toolkit