Subject: RE: Pkinit-23 comments: InitialVerifiedCAs

From: "Liqiang(Larry) Zhu" <[email-masked]>
Date: Wed, 2 Feb 2005 22:31:15 -0800

Martin,

 you have a valid concern about the distinction between the public key
and the certificate (which is a binding between the key and its
subject).

I propose:

       TD-TRUSTED-CERTIFIERS ::= SEQUENCE OF TrustedCA
                   -- Identifies a list of trust anchors selected by
                   -- the KDC.
                   -- Each TrustedCA identifies a CA or a CA
                   -- certificate.

And I would add one arm to trustedCA, the keyID:

       TrustedCA ::= CHOICE {
          caName                  [1] IMPLICIT OCTET STRING,
                   -- Contains a PKIX type Name encoded according to
                   -- [RFC3280].
                   -- Identifies a CA.
          issuerAndSerial         [2] IMPLICIT OCTET STRING,
                   -- Contains a CMS type IssuerAndSerialNumber encoded
                   -- according to [RFC3852].
                   -- Identifies a CA certificate.
          subjectKeyIdentifier    [3] IMPLICIT OCTET STRING,
                   -- Identifies a trust anchor.
                   -- The subjectKeyIdentifier field identifies the
                   -- CA's certificate by a key identifier.  When an
                   -- X.509 certificate is referenced, the key
                   -- identifier matches the X.509 subjectKeyIdentifier
                   -- extension value.
          ...
       }

Would this work for you?

-- Larry

-----Original Message-----
From: Martin Rex [mailto:[email-masked]] 
Sent: Wednesday, February 02, 2005 3:45 PM
To: Nicolas Williams
Cc: Liqiang(Larry) Zhu; [email-masked]
Subject: Re: Pkinit-23 comments: InitialVerifiedCAs

Nicolas Williams wrote:
> 
> What Larry is saying is that he wants to replace Name with 
> IssuerAndSerialNumber and he wants it wrapped in an OCTET STRING.
> 
> I don't mind changing Name to IssuerAndSerialNumber here, but as to 
> the octet string wrapping, PKINIT already uses Name w/o wrapping all 
> over the place -- maybe we should decide which types to wrap generally

> and do so consistently.

Thinking about it, I think that replacing the Name with
IssuerAndSerialNumber is a bad idea.  I similarily think it is a bad
idea to use IssuerAndSerialNumber in TD-INVALID-CERTIFICATES.

Let me explain why:

Although IssuerAndSerialNumber is necessary for some protocols (e.g.
CRLs, or Directory Lookup) to uniquely identify a certificate, this
information is extremely confusing and misleading to the average human
user when trying to identify a certificate.

If you're in the middle of checking/verifying a certification path, then
returning either IssuerAndSerialNumber or SubjectName is about the same
effort (unless maybe we have an empty SubjectName ...).

But if you have a bag of certificates and receive IssuerAndSerialNumber
and now what to tell a human user which certificate it refers to, then
it takes some serious ASN.1 wrangling to find the correct cert and
retrieve its SubjectName to visualize it to the user.

In case of TD-INVALID-CERTIFICATES, that a client desperately needs
IssuerAndSerialNumber, and that *this* information will enable the
client to retry without error.  All scenarios that I can conceive will
require human intervention to fix the problem, and for that
IssuerAndSerialNumber is quite counterproductive, because Humans don't
recognize them and most UIs for PKI configuration don't use them either
(everyone keys from the subject name, including all of Microsoft's UIs).
To convert from IssuerAndSerialNumber on the client requires some
significant ASN.1-wrangling and is therefore hostile to small footprint
clients.

The issue is slightly different for InitialVerifiedCAs.
I don't know exactly what the intended purpose of this information is,
but I could conceive that one might want to bind "policy" or trust level
to particular CAs, and in that case again, the Humans will key of the
subject name of a CA for which they configure policy/trust, Not the
IssuerAndSerialName.  The additional problem with policy/trust and
intermediate CA certs would be, that IssuerAndSerialName binds to one
particular certificate and this is going to become a problem when the
certificate of the intermediate CA is renewed/replaced for whatever
reason.

So we should ask ourselves for what purpose that information is actually
transferred within the PKINIT protocol, and is the SubjectName or
IssuerAndSerialName better suited for that purpose.

-Martin

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Mon, 07 Feb 2005 20:01:06 -0500

This is ticket #836

> and the certificate (which is a binding between the key and its

I agree that Martin's concern is valid, and I think Larry's proposal is on 
the right track.  However, it seems like a KDC might actually want to send 
more than one identifier for the same certificate, depending on the 
situation.  So instead of Larry's CHOICE, it might be useful to consider a 
SEQUENCE, containing all of the arm's of Larry's CHOICE, but with each 
marked OPTIONAL.  That way, a KDC can provide whatever information it wants 
about each CA in the path -- or none at all, if we choose to allow that.

I'm not adamant about this; I just wanted to throw it out as a suggestion.
I'm also fine with adopting Larry's proposal as-is.

In any case, I would like to see this issue resolved so the document can be 
updated accordingly, and that can't happen if no one comments.  So, 
comments either supporting or opposing either of these proposals would be 
nice.

-- Jeff