Subject: PKINIT Open Issue: AD-INITIAL-VERIFIED-CAs

From: "Eric Rosenfeld" <[email-masked]>
Date: Wed, 21 Apr 2004 10:40:34 -0600

OK, Jeff asked that I send an email regarding my objections to requiring
inclusion of the AD-INITIAL-VERIFIED-CAs.

Jeff's email asked me to indicate why I don't think security is impacted
by not including the VERIFIED-CAs field. I am new to this WG, so perhaps
I am missing something. But I don't understand why not including this
field is considered a fundamental security flaw to begin with. The
VERIFIED-CAs field can be left empty (i.e. the KDC doesn't have to tell
the client what CAs were used), so how is this different than not
including the field to begin with?

So I guess is what I'm saying is that I'll drop my objections if someone
can explain to me what the fundamental security flaw is, and why
mandatory inclusion of this field (even if it is empty) addresses that
security flaw.

Unfortunately, I will be out of town from April 26 - May 21, and will
not have any access to email. Doc Evans has agreed to carry the torch in
my absense (Thanks Doc!).

Thanks,
Eric

Eric S. Rosenfeld
Project Director, PacketCable Security
CableLabs
858 Coal Creek Circle
Louisville, CO  80027-9750

Email: [email-masked]
Phone: 303-661-3841
Fax: 303-661-9199

---

From: Sam Hartman <[email-masked]>
Date: Wed, 21 Apr 2004 14:46:24 -0400

Hi, Eric.  I tried to answer your question but ran into a significant
problem of my own.

I don't understand what the fields in the ad-initial-verified-cas
sequence mean and when a particular CA name must be included.

Nico, would you mind explaining this?  I'll probably ask you to
provide additional text for the document once we understand this
issue.

---

From: Nicolas Williams <[email-masked]>
Date: Wed, 21 Apr 2004 14:19:43 -0500

> sequence mean and when a particular CA name must be included.

Heh.

> provide additional text for the document once we understand this

Sigh, I left this out of the text I sent to Brian.

AD-INITIAL-VERIFIED-CAs contains the sequence of CA names from a
certificate chain of the cert used by the client, or a subset thereof,
and in the same order, such that the "root" of the
AD-INITIAL-VERIFIED-CAs Name sequence (that is, the last Name in
AD-INITIAL-VERIFIED-CAs) is for a CA whose cert the KDC knew a priori
and accepted as valid.

This is the PK equivalent of transited realms.

We're saying that acceptors may want to know what CAs, downlevel from a
CA that the KDC accepted as valid, were part of the cert chain accepted
by the KDC of the cert used ultimately to get this ticket.

For pre-shared certs, where the KDC does no cert chain validation or
where the cert is self-signed, the list of CA names is empty, but
AD-INITIAL-VERIFIED-CAs MUST still be included because its presence
indicates the use of PKINIT.

I need to think about how to word this properly for inclusion in the
draft.

Nico
--

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Wed, 21 Apr 2004 16:01:55 -0400

> AD-INITIAL-VERIFIED-CAs) is for a CA whose cert the KDC knew a priori

OK, but what does the 'Validated' flag mean?
Also, I'm pretty sure it is not legal for this name to start with an 
uppercase letter.

Before this document can be sent to the IESG, we will need an ASN.1 module 
that actually compiles.  Otherwise they _will_ bounce it back to us.

-- Jeff

---

From: Nicolas Williams <[email-masked]>
Date: Wed, 21 Apr 2004 15:20:30 -0500

> Also, I'm pretty sure it is not legal for this name to start with an 

The text I had sent to Brian had this:

INITIAL-Verified-CAs ::= SEQUENCE OF SEQUENCE {                                                               
    ca              [0] Name,                                                                                 
    ocsp-validated  [0] BOOLEAN                                                                               
                        -- or "NULL OPTIONAL" so we can thus optimize                                         
                        -- for either case (OCSP-verified or not)?                                            
    ...                                                                                                       
}                                                                                                             

That should clarify it, no?  :)

> that actually compiles.  Otherwise they _will_ bounce it back to us.

Yes.

What I sent was valid ASN.1.

Nico
--