Subject: RE: Open Issue in Part1: path length constraints

From: "David P. Kemp" <[email-masked]>
Date: Thu, 08 Mar 2001 11:10:10 -0500

> From: "Michael Myers" <[email-masked]>
> 
> Dave,
> 
> Does your observation of a "trusted" responder interpret case 1.b below or
> were you intending to speak to some broader notion?

Michael,

I was indeed considering case 1.b, based on the text in RFC 2560
section 2.2:

  The key used to sign the response MUST belong to one of the following:
  
    -- the CA who issued the certificate in question
    -- a Trusted Responder whose whose public key is trusted by the
        requestor
    -- a CA Designated Responder (Authorized Responder) who holds a
        specially marked certificate issued directly by the CA

I admit to not making a distinction between 1.a and 1.b, because if the
CA is going to implicitly designate a trusted responder key, why in the
world would it not take the extra step of explicitly designating that
key
by issuing the special certificate.  The hard work for the CA is
deciding
who to designate, not signing the cert.  I'm not from Missouri, but if a
Trusted Responder claimed to be CA-delegated, I'd say "show me the
cert".

Dave

---

From: "Carlin Covey" <[email-masked]>
Date: Thu, 8 Mar 2001 19:04:40 -0700

In section 2.6 of draft-ietf-pkix-impersonation-00.txt the
following words appear:

   "To discourage mistakes in this area, this Impersonation Certificate 
   profile defines that the IC subject (actually its subjectAltName) is 
   just a pseudo-randomly generated string."

[Carlin's comments/questions]:
If the IC subject name is a pseudo-randomly generated string, how is the 
IC found in an X.500 or LDAP Directory?  Must it always be passed by the 
application to the RP rather than being found in a directory?  

- Carlin Covey
  Cylink Corporation

---

From: Steve Tuecke <[email-masked]>
Date: Fri, 09 Mar 2001 14:33:09 -0600

In the Globus Toolkit, we use ICs to authenticate a TLS channel, and we 
always pass the entire IC/EEC certificate chain during the authentication 
handshake.  And whenever we delegate an IC, we pass the whole chain to the RP.

I would be interested to hear a scenario where it is not practical or 
desirable to pass the IC/EEC chain to the RP, or in the authentication 
handshake.  And if you have any suggestions for changes that could be made 
to support path discovery from a directory (or any other way), I'd love to 
hear it.

I'll be in Minneapolis next week if you want to talk more about this in 
person...

-Steve

---

From: "Carlin Covey" <[email-masked]>
Date: Fri, 9 Mar 2001 15:49:08 -0700

Steve,

"... not practical or desirable to pass the IC/EEC chain to the RP..."

Well, I don't have any specific scenario in mind, but there is the
wireless/low-bandwidth case that always seems to be lurking around the
corner, but never quite getting here.

I'll be at the IETF in Minneapolis.  I'd like to talk with you.

Regards,
Carlin
_______________________________________
Carlin Covey
Cylink Corporation

-----Original Message-----
From: Steve Tuecke [mailto:[email-masked]]
Sent: Friday, March 09, 2001 1:33 PM
To: Carlin Covey
Cc: [email-masked]
Subject: Re: Impersonation Certificates - finding IC's

In the Globus Toolkit, we use ICs to authenticate a TLS channel, and we
always pass the entire IC/EEC certificate chain during the authentication
handshake.  And whenever we delegate an IC, we pass the whole chain to the
RP.

-Steve