Subject: Re: What's in a Name?

From: Jeffrey Hutzelman <[email-masked]>
Date: Mon, 18 Apr 2005 14:45:06 -0400

On Monday, March 14, 2005 07:53:26 PM -0500 Jeffrey Hutzelman 
<[email-masked]> 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
>
>
> Some comments on these questions would be nice, so we can close out this
> fairly messy issue.

Waaaah..  No one is answering my questions.  That's really having a poor 
effect on our ability to make progress on this document.  I would like to 
see comments or discussion on the issues I described at the start of this 
thread.  If I don't see any, then I will let the pkinit-25 text stand and 
we'll see what happens during WGLC.

-- Jeff

---

From: Chaskiel M Grundman <[email-masked]>
Date: Mon, 18 Apr 2005 15:00:11 -0400

The questions are just as messy as the original issue.

I think that we need to be clear on what the names are actually for in each 
case in order toi come up with clear answers to the questions.  Are we 
trying to identify certificates or certificate holders in these cases?

Overall, I am happier with the -25 text than the older text, since the Name 
is always present.

>>     SEQUENCE OF OCTET STRING wrapping Name?
Do the interpreters of InitialVerifiedCAs need more than the Name? might 
they be re-checking crl's or rejecting certificates using criteria other 
than there names? if the answer is 'no', then I think that only the Name 
should be sent.

>>     SEQUENCE OF OCTET STRING wrapping Name?
This is the case where something other than Name seems to have the most 
value (the certificate the kdc uses must actually be verifiable by the 
client, being issued by a certificate with the same name as the one the 
client has isn't good enough. it must actually be the same certificate (or 
key)

---

From: Nicolas Williams <[email-masked]>
Date: Mon, 18 Apr 2005 14:17:43 -0500

> >    SEQUENCE OF OCTET STRING wrapping Name?

Can we simplify the TrustedCA type?  Do we need subjectKeyIdentifier?
Can we get by with IssuerAndSerial instead?  If so then TrustedCA may be
the best choice so that in the future we can let apps validate certs for
an entire x-realm path including PKINIT cert path too.

Or should we give up on InitialVerifiedCAs and replace it with the
actual cert used by the PKINIT client?

> >    SEQUENCE OF OCTET STRING wrapping IssuerAndSerialNumber?

Again, if TrustedCA could include IssuerAndSerialNumber instead of
serial and/or subject key id...

> >    SEQUENCE OF OCTET STRING wrapping Name?

See above.  Here IssuerAndSerialNumber seem less necessary though.

> >Some comments on these questions would be nice, so we can close out this

See above.

> we'll see what happens during WGLC.

Sorry.

Nico
--

---

From: Brian Tung <[email-masked]>
Date: Mon, 18 Apr 2005 14:45:21 -0700

On Mon, Apr 18, 2005 at 02:39:12PM -0700, Brian Tung wrote:
> (d) Is the definition of TrustedCA in pkinit-25 acceptable?

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]>

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Mon, 18 Apr 2005 18:02:22 -0400

On Monday, March 14, 2005 07:53:26 PM -0500 Jeffrey Hutzelman 
<[email-masked]> wrote:

>     In pkinit-22, TD-CERTIFICATE-INDEX was an IssuerAndSerialNumber
>     In pkinit-24, TD-INVALID-CERTIFICATES was a SEQUENCE OF OCTET STRING
>     wrapping IssuerAndSerialNumber
>     Martin commented that he thought that was a bad idea.
>     In pkinit-25 it is a SEQUENCE of TrustedCA.

Brian points out that my description here is incorrect.  The definition of 
TD-INVALID-CERTIFICATES in pkinit-25 is unchanged from pkinit-24.

> Note that I'm glossing over some things here; there was a fair bit of
> discussion involved before we reached the current state of having
> everything be a SEQUENCE OF TrustedCA.  In addition to those changes, the
> definition of TrustedCA itself has changed somewhat:

I'd suggest that before rehashing old issues, folks actually go and review 
that discussion.  There was a fair bit of negotiation and people explaining 
positions there, and while I don't think we had reached consensus, it would 
be good to not forget the existing context.

-- Jeff