Subject: Pkinit-23 comments: InitialVerifiedCAs

From: "Liqiang(Larry) Zhu" <[email-masked]>
Date: Tue, 1 Feb 2005 09:22:51 -0800

Issues: 1)  contains a field with no description
        2) it is not clear how InitialVerifiedCAs is computed.

Proposal:

Contacted Nico who proposed the original text, and he did not object to
change it to:

    InitialVerifiedCAs ::= SEQUENCE OF SEQUENCE {
       ca                      [0] IMPLICIT OCTET STRING,
                -- Each OCTET STRING contains a CMS type 
                -- IssuerAndSerialNumber encoded according to 
                -- [RFC3852].
                -- Identifies the certification path based on which 
                -- the client certificate was validated.
       ...
    }

---

From: Nicolas Williams <[email-masked]>
Date: Tue, 1 Feb 2005 11:37:19 -0600

> Issues: 1)  contains a field with no description

I remember now.  The "validated" field was supposed to indicate whether
the KDC validated that part of the CA path, so that if the KDC trusted a
leaf cert to begin with it might not validate the CA path but include it
here anyways.  I think this is best removed.

>         2) it is not clear how InitialVerifiedCAs is computed.

Yes it is: each Name is the name of a CA in the path to the root CA.

>                 -- the client certificate was validated.

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.

Nico
--

---

From: Martin Rex <[email-masked]>
Date: Tue, 1 Feb 2005 23:25:22 +0100 (MET)

Just curious:

What does PKCross do in this case for the "transited field"?
Does it list names of CAs or "IssuerAndSerialNumber"?

---

From: Brian Tung <[email-masked]>
Date: Tue, 1 Feb 2005 14:31:29 -0800

> Does it list names of CAs or "IssuerAndSerialNumber"?

Isn't the answer to this question currently undefined?  My impression
is that at last record it listed names of CAs, but I don't recall that
it was completely specified.

b

---

From: Nicolas Williams <[email-masked]>
Date: Tue, 1 Feb 2005 16:44:06 -0600

> Does it list names of CAs or "IssuerAndSerialNumber"?

There is no remotely current PKCROSS proposal to look at, or at least
none that I'm aware of.

PKCROSS will need Kerberos V extensions not yet available.  We should
cross that bridge when we come to it.

Nico
--

---

From: Martin Rex <[email-masked]>
Date: Thu, 3 Feb 2005 00:44:56 +0100 (MET)

> the place -- maybe we should decide which types to wrap generally and do

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