Subject: RE: Pkinit-23 comments: InitialVerifiedCAs

From: "Liqiang(Larry) Zhu" <[email-masked]>
Date: Tue, 8 Feb 2005 11:30:40 -0800

The entities we discuss here in the PKINIT should be keys, not
certificates. The knowledge of the DN of a particular CA does not mean
must.

Improvent:
 
       TrustedCA ::= CHOICE {
          caName                  [1] IMPLICIT OCTET STRING,
                   -- Contains a PKIX type Name encoded according to
                   -- [RFC3280].
                   -- Identifies a CA.

<< please note here >>
                   -- Prefer the sid field below if that is available.

          sid                     [2] IMPLICIT OCTET STRING,
                   -- Contains a CMS type SignerIdentifier encoded
                   -- according to [RFC3852].
                   -- Identifies the trusted CA's certificate (and
                   -- thereby the public key).
          ...
       }

RFC3852 prefers ski if SignerIdentifier is used.

-- Larry

-----Original Message-----
From: Martin Rex [mailto:[email-masked]] 
Sent: Tuesday, February 08, 2005 11:02 AM
To: Liqiang(Larry) Zhu
Cc: [email-masked]; [email-masked]; [email-masked]
Subject: Re: Pkinit-23 comments: InitialVerifiedCAs

If the sequence of TrustedCAs is supposed to be used for policy
decisions, then there should a single, mandatory to implement format for
interoperability reasons.

As has been indicated on the list, not only KDCs, but also (specific)
applications are expected to apply policy decisions to that trust path,
so we should really be concerned about interoperability.

I question the usefulness of both issuerAndSerial and
subjectKeyIdentifier, since that information is probably not what admins
will maintain, simply because that purely technical information.  On top
of that, issuerAndSerial may have cause problems for certificate
roll-over of a CA.

I wouldn't mind if the above was a SEQUENCE rather than a CHOICE with
caName always required and issuerAndSerial and subjectKeyIdentifier
optional.  *I* don't see any need for issuerAndSerial and
subjectKeyIdentifier, but I'm not a die-hard PKI freak.
I'm just a little worried because it will require additional code and
may waste resources (network bandwith,memory) if it is there.

-Martin

Liqiang\ wrote:
> 
>  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?

---

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

Sorry, but I seem to be completely lost.

From what Jeff just recently wrote about the agree-upon purpose of
AD-INITIAL-VERIFIED-CAS I assumed that (specific) application servers
are supposed to check the supplied list of CAs Names against their policies,
similar to what is done with Kerberos Realm name (as I understand it).

Unless the PKINIT spec wants to make PKI and CMS mandatory to implement
for *ALL* kerberized applications through the back door, it should stick
to a list of plain and simple DNames for the list of TrustedCAs, which is
something that Applications may be able to handle with a fairly
small amount of changes, in case they do handle transited realms today.

I can not see how a kerberized application could handle issuerAndSerial
or subjectKeyIdentifier without getting intimate with PKI/CMS.

I think it would be best to restrict the PKI/CMS impact of PKINIT
on the entire Kerberos procotol as small as possible.  Trying to
support every bell and whistle of CMS will result in just the opposite.

-Martin

---

From: Sam Hartman <[email-masked]>
Date: Wed, 09 Feb 2005 15:26:34 -0500

>>>>> "Martin" == Martin Rex <[email-masked]> writes:

    Martin> Unless the PKINIT spec wants to make PKI and CMS mandatory
    Martin> to implement for *ALL* kerberized applications through the
    Martin> back door, it should stick to a list of plain and simple
    Martin> DNames for the list of TrustedCAs, which is something that
    Martin> Applications may be able to handle with a fairly small
    Martin> amount of changes, in case they do handle transited realms
    Martin> today.

    Martin> I can not see how a kerberized application could handle
    Martin> issuerAndSerial or subjectKeyIdentifier without getting
    Martin> intimate with PKI/CMS.

I find this argument compelling.

Also keep in mind that it is the named entity that is being trusted,
not some particular key.

--Sam

---

From: Nicolas Williams <[email-masked]>
Date: Wed, 9 Feb 2005 14:43:14 -0600

> Also keep in mind that it is the named entity that is being trusted,

I agree.  Applications shouldn't go to such lengths as revalidating
client certs -- the PKINIT equivalent of RFC1510 transited field
processing is to simply check the names of the transited CAs and, for
example, reject clients whose CA paths include untrusted CAs.

All apps need here is a SEQUENCE OF Name.

Nico
--

---

From: Martin Rex <[email-masked]>
Date: Fri, 11 Feb 2005 01:35:46 +0100 (MET)

Coming back to my first/other related concern about the contents
of TD-INVALID-CERTIFICATES.

I would like to see a requirement to include the subjectDName of
the offending certificate (or each certificate if the KDC complains
about more than one).  I don't mind if there are additional
identifiers for a certificate included.

The purpose of the subjectDName is for visualization to human users
in case the PKINIT client does not manage a successful retry.

I do not expect the error to happen frequently, but if it happens,
I assume that the error will often be persistent, even if the
client does implement a retry logic for some specific failures
that might result in a successful retry.

Although a PKINIT client will usually have sufficient PKI/CMS code
to recognize and handle isserAndSerialNumber or subjectKeyIdentifier,
it may not actually have the offending certs locally if we permit
clients to not know their cert chain, and it may not have directory
access prior to a successful PKINIT authentication, and considering
Microsofts motivation for IAKERB, a PKINIT client may not even have
network connectivity before a successful PKINIT authentication.

So if there is no subjectDName in the TD-INVALID-CERTIFICATES,
a PKINIT client may not be able to produce an easily human-recognizable
error message based on other certificate identifiers because of
this hen-and-egg problem.

And even if the client was in the position to map from a cert
identifier that is seldom recognized by humans into a subjectDName
to visualize an error message, the additional code and potential
complexity of such a transformation may cause implementors to
not do it and ship code that produces cryptic error messages.

But if the subjectDName was always there, it would be straightforward
to include that name in the visualization of an error message, that even
implementors under strong time constraints should be able to do it (*).

-Martin

(*) At least I hope so.

    When I launched "Windows Update" on my WinXPsp2 corporate installation
    (behind proxy) I ran into a brick wall, getting only the cryptic error
    message 0x80244019 and only entirely useless suggestions what to
    try on the part of windowsudate.

    An article in the German c't magazine gave the important hints
    about "proxycfg -u" and "wuauclt /detectnow" commands which
    launched automatic update to retrieve the new security patches,
    however manual Windows Update (v5) didn't work until after the
    next reboot...  as in "your mouse pointer has moved, please reboot
    for changes to take effect" 
    probably a defective service thats only reads proxy settings from the
    registry upon machine startup.

---

From: Sam Hartman <[email-masked]>
Date: Thu, 10 Feb 2005 20:49:17 -0500

>>>>> "Martin" == Martin Rex <[email-masked]> writes:

    Martin> Coming back to my first/other related concern about the
    Martin> contents of TD-INVALID-CERTIFICATES.

    Martin> I would like to see a requirement to include the
    Martin> subjectDName of the offending certificate (or each
    Martin> certificate if the KDC complains about more than one).  I
    Martin> don't mind if there are additional identifiers for a
    Martin> certificate included.

I have no objection to this provided that we give advice for what to
do if there is no SubjectDName.

---

From: Martin Rex <[email-masked]>
Date: Fri, 11 Feb 2005 16:17:13 +0100 (MET)

> do if there is no SubjectDName.

You mean if it is an End Entity ("Leaf") certificate that has an
empty SubjectDName?

Since I'm looking for a means to produce a human comprehensible error
message, I think that the altSubjectName extension that best matches
this purpose would be the answer.

But if the pupose is for human consumption, then it might be best
to require the producer of the error message (here the KDC) to
convert the most suitable altSubjectName extension into a flat
UTF8String and send that (to facilitate error reporting on the
client, and in particular not-so-fat clients.)

The KDC will probably do something to that effect for logging purposes
anyway, and it shouldn't hurt when the identifer that the KDC writes
into his (textual) logs matches that from the error message that pops
up on the client...

-Martin

---

From: Nicolas Williams <[email-masked]>
Date: Fri, 11 Feb 2005 10:44:02 -0600

> You mean if it is an End Entity ("Leaf") certificate that has an

It shouldn't be necessary to name the EE cert -- the client has it, and
knows best how to tell the user that the cert was rejected.

I see Martin's concern as applicable to other certs in the client cert's
cert chain.  Requiring that the client send the full cert chain would
obviate this concern, but we haven't settled that yet, have we?

> client, and in particular not-so-fat clients.)

If the KDC were to want to add any explanatory text then we'd quickly
get into L10N issues.  We could just leave it to extensions to deal with
L10N, or we could avoid the need altogether.

Nico
--

---

From: Martin Rex <[email-masked]>
Date: Fri, 11 Feb 2005 18:23:14 +0100 (MET)

> knows best how to tell the user that the cert was rejected.

This is about easy and consistent processing of the TD-INVALID-CERTIFICATES
error, and that includes the EE cert, independent of whether the client
has it or not.

It is really extremely beneficial if the error reporting here is consistent,
across clients and for KDC and client in order to relate error messages.
You'll quickly realize that if you have to support vital productive
24/7 AppServers of several thousand customers around the globe from
your office. 

> obviate this concern, but we haven't settled that yet, have we?

If I understand the "flexibility" of PKI/CMS correctly, then there may
be certs reported which the client might not know even if he has
all certs available that make up a traditional certification path.

Where the client has a self-signed "root authority" key (which it must
not send according to the proposed spec), a KDC may have an intermediate
cross-cert instead (if I understand that part of arbitrary cert hierarchies
correctly).

> L10N, or we could avoid the need altogether.

I disagree.  This is not about an error message, but about an
identifier for the certificate that is rejected.  So it ought to be
an attribute/identifer like the subjectDName or a recognized altSubjectName
that is actually in the certificate and that is commonly visualized at
administrative UIs -- because to overcome the error it is that
certificate that will need to get replaced, so being able to easily
identify that cert is a good idea.

-Martin

---

From: Sam Hartman <[email-masked]>
Date: Fri, 11 Feb 2005 14:49:02 -0500

>>  I have no objection to this provided that we give advice for
    >> what to do if there is no SubjectDName.

    Martin> You mean if it is an End Entity ("Leaf") certificate that
    Martin> has an empty SubjectDName?

Ah, good point.  IT would not tend to be an end entity cert.