Subject: RE: What's in a Name?

From: "Liqiang(Larry) Zhu" <[email-masked]>
Date: Fri, 13 May 2005 19:37:45 -0700

Brian, 
Before I publish -26. 

Do we need to make any changes into -25

-- Larry

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]] On Behalf Of Brian Tung
Sent: Monday, April 18, 2005 2:45 PM
To: [email-masked]
Subject: Re: What's in a Name?

On Mon, Apr 18, 2005 at 02:39:12PM -0700, Brian Tung wrote:
Jeffrey Hutzelman wrote:
> (a) What should InitialVerifiedCAs be?
>     SEQUENCE OF OCTET STRING wrapping Name?
>     SEQUENCE OF TrustedCA?
>     Something else?
>     This is ticket #836
> 
> (b) What should TD-INVALID-CERTIFICATES be?
>     SEQUENCE OF OCTET STRING wrapping IssuerAndSerialNumber?
>     SEQUENCE OF TrustedCA?
>     Something else?
>     This is ticket #864
>  
> (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
> 
> I'd also like to ask one additional question:
> 
> (d) Is the definition of TrustedCA in pkinit-25 acceptable?
>     This is ticket #866

TD-TRUSTED-CERTIFIERS is used in the event that no certification path
can be built at all; it lists the trust anchors that the KDC will
accept.  In the case of TD-INVALID-CERTIFICATES, a certification path
was built, but one or more of the certificates has an invalid signature;
the field identifies those certificates.  AD-INITIAL-VERIFIED-CAS is
PKINIT's version of the transited field; it gives the certification
path used by the KDC to verify the user's cert.

With TD-INVALID-CERTIFICATES, the client already has the certificates;
it only needs to know which ones have invalid signatures.  Presumably,
all that is required is Name, although IssuerAndSerial would work, too.

The other two, in my opinion, require further information.  In order
for the client to pick a valid sequence of certificates, or for a
service to make an informed authorization decision, they must have
access to the actual certificate.  I think that some formatting of
IssuerAndSerial is right for this purpose.

If we want to funnel all of these uses down to the same structure,
IssuerAndSerial seems reasonable.  Name could be included for those
future uses where we need something a bit less restrictive than
IssuerAndSerial (and it can be used for TD-INVALID-CERTIFICATES), but
I don't see that at present.

Brian Tung <[email-masked]>