Subject: Re: What's in a Name?

From: Jeffrey Hutzelman <[email-masked]>
Date: Tue, 12 Jul 2005 01:14:20 -0400

> My main concern is that it is hard for me to tell who was arguing for or
> against what changes, which makes it nigh impossible to figure out
> whether we have consensus for any of these changes, let alone all of
> them.  To that end, I'd like to get comments from members of the working
> group on several questions:

There hasn't been anything resembling consensus on this, and we really do 
need to resolve this before we can go forward.  I'm going to postulate some 
answers to my own questions, based in part on recent discussions and in 
part on some of my own experiences (some of which are fairly recent).

First, I think I phrased this slightly wrong.  In the first three 
questions, I should not have asked about "SEQUENCE OF TrustedCA", but 
instead about "SEQUENCE OF <what pkinit-25 defined as TrustedCA>".  And I 
shouldn't have asked question (d) at all -- the answer depends entirely on 
the answers to the other three.  So, here goes...

First, it is necessary to note that a Name does _not_ uniquely identify a 
certificate, because a CA may issue more than one cert with the same DN. 
One common example of this is what happens when a certificate is renewed. 
On the other hand, a Name _is_ supposed to uniquely identify a particular 
entity; CA's are not supposed to issue certificates to more than one entity 
with the same Name.

However, IssuerAndSerialNumber _is_ supposed to uniquely identify a 
certificate.  This is based on the assumptions that no two entities, 
including CA's, have the same Name, and that no CA will issue two 
certificates with the same serial number, whether or not they are signed by 
the same key.

> (a) What should InitialVerifiedCAs be?
>     SEQUENCE OF OCTET STRING wrapping Name?
>     SEQUENCE OF TrustedCA?
>     Something else?
>     This is ticket #836

This is used to allow applications to do their own check that the trust 
path is acceptable to them.  To do this, applications will need to know the 
names of the CA's along the certification path; I agree with Martin that 
the Name is essential in this usage.

Nico has suggested that in this case we may additionally want an 
IssuerAndSerialNumber, which would potentially provide applications with 
enough information to obtain the certificates involved and validate the 
certificates on their own.  This is slightly extreme, but does fit with 
Kerberos's end-to-end authorization model, allowing applications to do as 
much checking as possible.

> (b) What should TD-INVALID-CERTIFICATES be?
>     SEQUENCE OF OCTET STRING wrapping IssuerAndSerialNumber?
>     SEQUENCE OF TrustedCA?
>     Something else?
>     This is ticket #864

This is used to tell the client which certificate(s) failed validation. 
Brian suggests that perhaps all we need here is a Name, because the client 
already has the certificates.  However, a Name is not sufficient to 
uniquely identify a certificate, and it is even moderately likely that you 
will see multiple certificates with the same Name in a single chain.  PKIX 
explicitly allows for a model which eases the transition when a CA changes 
keys or has its certificate renewed, by allowing the CA to issue a new 
certificate signed by the old one.  This allows verifiers which trust the 
old certificate to verify leaf certs signed by the new certificate.  In 
this case, the special rollover certificate must have the same issuer and 
subject DN's, which means the chain will have more than one cert with the 
same Name.

So, I think we definitely need to report an IssuerAndSerialNumber here, so 
that a client can correctly identify the invalid certificate.  However, I 
also agree with Martin's comment that we need a Name here, to provide the 
client with a DN for the offending certificate which it can present to the 
user (note that the client might _not_ have the offending certificate, 
especially by the time it reports a problem).

> (c) What should TD-TRUSTED-CERTIFIERS be a SEQUENCE of?
>     SEQUENCE OF OCTET STRING wrapping Name?
>     SEQUENCE OF TrustedCA?
>     Something else?
>     This is ticket #865

Chaskiel points out that in this case, you absolutely need something better 
than just a Name.  This is a list of trust anchors, and for a certificate 
to work, it must have the right key, not just the right name.

Brian suggests that some form of IssuerAndSerialNumber is right for this 
purpose.  I don't think he's said it yet, but I assume that Martin will 
argue that a Name is also useful here, as it allows a client to tell the 
user who he needs to go get a certificate from.

So, based on this, I think it is desirable in all three cases to be able to 
include both a Name and an IssuerAndSerialNumber.  In the case of 
InitialVerifiedCAs, the Name is the key piece of information that 
applications are expected to want; in the others, the IssuerAndSerialNumber 
is critical and the Name merely informational.  I don't see any need for a 
subjectKeyIdentifier in any of these cases, and I haven't even heard anyone 
argue for keeping a raw serial number.  Finally, I think it is a good idea 
to allow for future changes in the protocol, in case we turn out to be 
wrong.

So, now I think I'm ready to answer my own questions, all at once.  I 
believe that all three of these cases should be able to use a common type, 
defined as follows:

TrustedCA ::= SEQUENCE {
  caName          [0] IMPLICIT OCTET STRING OPTIONAL,
                      -- wraps Name
  issuerAndSerial [1] IMPLICIT OCTET STRING OPTIONAL,
                      -- wraps IssuerAndSerial
  ...
}

For InitialVerifiedCAs, the caName field MUST be provided and the 
issuerAndSerial field MAY be provided.

For TD-INVALID-CERTIFICATES and TD-TRUSTED-CERTIFIERS, the caName field 
SHOULD be provided and the issuerAndSerial field MUST be provided.

Modifying pkinit-26 to meet this proposal would require changing the 
TrustedCA type to the one shown above (but with better comments), and 
adding requirements language in each of the three places where it is 
referenced.

Comments on this proposal?

-- Jeff

---

From: Martin Rex <[email-masked]>
Date: Tue, 12 Jul 2005 18:58:14 +0200 (MET DST)

> certificates with the same serial number, whether or not they are signed by 

A quick resume why I think that the subject DName is very important:

Who or what will normally have to "process" the information and
act upon it?

1) non-PKI-aware kerberized apps
   InitialVerifiedCAs is expected to be processed by a kerberized
   application servers that care about this information, but these
   servers may not know anything about PKI or PKINIT (keep in mind
   that the base Kerberos spec doesn't mandate available of a full
   blown PKI).

2) fully PKI-aware PKINIT servers or clients
   TD-TRUSTED-CERTIFIERS are expected to be processed programmatically
   by a fully PKI-aware PKINIT client or PKINIT server (=KDC).

3) human (end) users and admins
   TD-INVALID-CERTIFICATES will almost always result in an error
   which an end user or admin will have to fix. (An implementation
   that can programmatically overcome this error is broken, because
   it should have been able to prevent it from happening.)

If you look around at the UIs of common implementations of PKI-Software,
you'll see that "issuer and serial" is among the hidden details,
and in particular long serial numbers (like those in VeriSign RootCAs)
can not be easily recognized memorized by a human user.

It is common practice to list Certificates by either their Subject DName
or by an alias derived or related to their subject DName -- and not
by their Issuer or serial number.  Given enough certificates, it is
a royal PITA to locate a certificate based on Issuer and serial number.

RootCAs have the same isser and subject DName, so they're easier to
locate by issuer&serial, but they're also less likely to be invalid
(expired, revoked, whathaveyou) than end-entity or intermediate-CA
certificates ...

I don't know whether your PKI-aware software, admins and end users
knows pretty well how to obtain a VeriSign End-entity certificate
for which you're given Issuer&serial -- for all of my company it's 3x NO.

And everywhere where an Admin configures trust or ACLs or looks up
a certificate manually, he refers to and recognizes the certificate
by it's subject name, NOT by issuer&serial.  The software may internally
use issuer&serial for certain functions, including certificate validation,
but that's hidden from the admin and end user.

Ultimately, the most universal approach would be to use the
plain name(s), for visualizing error messages and for processing
by software with limited ASN.1 and not PKI-capabilities, plus
the certificate(s) for processing by PKI-aware software and
for less confusion in case of PKI-related errors (invalid certs,
lack of trust, policy issues, whathaveyou).  ;-)

And a final STRONG word of caution about issuer&serial, because
it will create serious problems with many kinds of certificate roll-over,
both end-entity and CA-certificate rollover, where one side has the
new certificate and the other side has it not yet.  When identifying trust
anchors by name rather than by issuer&serial then certificate rollover
is transparent.  The actual certificate path validation uses a real
certificate/key and a real signature verification, so there's no
security problem with calling a trust anchor by its name.

Some PKI-fanciers see it as a big advantage that you can revoke
and existing certificate and re-issue a new one without having to
update your infrastructure configuration when a user's PKI credentials
need to be replaced (lost, defective or stolen hardware token),
so one should be really careful not to use issuer&serial information
in all the wrong places.

-Martin