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

From: Sharon Boeyen <[email-masked]>
Date: Wed, 7 Mar 2001 14:32:55 -0500

Re the X.509 language - The main reason you see terms  like 'authority' and 
CRL issuer instead of CA is that CRLs can also be issued for attribute
certificates.
These CRLs would be signed by Attribute Authorities (AA) not by CAs. As
editor, 
one my editing tasks for the 2000 509 was to replace "CA" with "authority"
wherever both CA and AA 
were intended. That is the main reason you see these terms. There really
hasn't been any 
discussion in 509 on non CA, AA issued CRLs that I can remember. Taking this
to the next 
step, the definition of "authority" in X.509 (clause 3.3.6) is: "An entity,
responsible for the issuance of certificates. Two types are defined in this
Specification; certification authority which issues public-key certificates
and attribute authority which issues attribute certificates." So, at least
from the X.509 perspective an authority is either a CA or an AA.

Sharon

> -----Original Message-----
> From: Stephen Kent [mailto:[email-masked]]
> Sent: Wednesday, March 07, 2001 11:41 AM
> To: Ambarish Malpani
> Cc: [email-masked]
> Subject: RE: Open Issue in Part1: path length constraints
> 
> 
> Ambarish,
> 
> >Hi Steve,
> >     While the term "VA" might not be part of the IETF standards,
> >it is the entity that can do the following:
> >
> >a. Sign OCSP responses - where you directly trust the responder
> >b. Sign Indirect CRLs (I suppose this is a circular argument)!
> >c. Do the Delegated Path Validation protocol.
> >
> >Agreed?
> 
> Since you made the term up, I suppose a VA can do anything :-).
> 
> On a more serious note, we made an explicit provision for non-CA 
> signing of OCSP responses when OCSP was created. You are an author, 
> so you know this. But, you didn't seem to feel a need to create a 
> name for such entities at the time, which is OK too.  CRL signing 
> was, prior to v3, strictly the province of a CA. What it seems we 
> have in our docs, and to a lesser extent in the X.509 docs, is a 
> failure to clearly describe the intent to allow non-CA entities to 
> sign CRLs. I say this based on the mix of terms in 2459, and some 
> selected examples of text from X.509 that refer to an "authority" 
> without naming any sort of authority other than CAs (and AAs?).
> 
> So, going forward, if we want to allow non-CAs to perform this 
> function, let's just get the text to be clear on this point, and if 
> necessary, let's create a name for these entities, to minimize 
> confusion.
> 
> As for DPV, it is clear that it can be performed by a non-CA entity.
> 
> Steve
>

---

From: Stephen Kent <[email-masked]>
Date: Wed, 7 Mar 2001 17:18:54 -0500

Sharon,

>CRL issuer instead of CA is that CRLs can also be issued for 
>attribute certificates.
>These CRLs would be signed by Attribute Authorities (AA) not by CAs. 
>As editor,
>one my editing tasks for the 2000 509 was to replace "CA" with 
>"authority" wherever both CA and AA
>were intended. That is the main reason you see these terms. There 
>really hasn't been any
>discussion in 509 on non CA, AA issued CRLs that I can remember. 
>Taking this to the next
>step, the definition of "authority" in X.509 (clause 3.3.6) is: "An 
>entity, responsible for the issuance of certificates. Two types are 
>defined in this Specification; certification authority which issues 
>public-key certificates and attribute authority which issues 
>attribute certificates." So, at least from the X.509 perspective an 
>authority is either a CA or an AA.

Thanks for the clarification; it reaffirms my recent comments about 
the scope of the term "authority." That says that there is no 
explicit provision for non CA/AA issuance of CRLs in X.509. So, not 
only does PKIX have to decide if it wants to create the notion of a 
new sort of authority for CRL issuance, but then we have to see if 
X.509 will follow this approach as well.

Steve

---

From: Denis Pinkas <[email-masked]>
Date: Thu, 08 Mar 2001 08:55:39 +0100

Sharon,

I read your explanations below. We do not have any problem about the
concepts, but there is a vocbulary problem here. It would be unfortunate to
say that an Authority may only be a CA or an AA. An Authority needs to be
qualified by a term: C-A (C= Certification) or A-A (A = Attribute). There
are and will be other Authorities in a PKIX. As an example: TS-A (TS = Time
Stamping).

I do know that, for ISO documents, definitions only apply for the given
document where the definition is, but rewording clause 3.3.6 from X.509
along the following would need to be considered:

Authority: "An entity, trusted by some other entities for a security related
service. Two types of authorities are defined in this Specification;
certification authority which issues public-key certificates and attribute
authority which issues attribute certificates. Other types might be defined
in the future."

Denis

---

From: "Carlin Covey" <[email-masked]>
Date: Thu, 8 Mar 2001 16:54:22 -0700

Gentlepersons,

draft-ietf-pkix-impersonation-00.txt describes a mechanism for 
delegating authority from entity A (who is not a CA) to entity B 
by issuing an "Impersonation Certificate" (IC) to entity B that 
is signed using entity A's PKC.  

Below step 5 of section 2.4. the following text appears:

   "The process of creating an IC is as follows: 
    
   1. A new public and private key pair is generated. 
       
   2. An unsigned IC request is created, conforming to the profile 
      described in this document. 
       
   3. The IC request is signed by the private key of the EEC, or by 
      another IC.  During this process, the unsigned IC is verified to 
      ensure that it is valid (e.g. it is not an EEC, the IC fields are 
      appropriately set, etc). 
    
   When an IC is created as part of a delegation from entity A to 
   entity B, this process is modified by performing steps #1 and #2 
   within entity B, then passing the IC request from entity B to entity 
   A over an integrity checked channel, then entity A performs step #3. "

[Carlin's comments/questions]:
I'm trying to understand some of the security aspects.
I don't see any discussion of proofing the IC requester.  How 
does the EE authenticate the identity of the IC requester?  
A CA or RA normally has some sort of proofing facilities 
available that are used to authenticate the identity of a 
human being (e.g. a database of employee information, some 
expertise in recognizing legitimate paper identity documents, 
etc.)  An EE is probably not well-equipped to do this sort 
of human identity proofing.  Moreover, in the example in 
section 2.3 the IC requester appears to be some automated 
process.  How does the EE authenticate the identity of this 
process?  Even if the EE can authenticate the source of the 
IC request, how are man-in-the-middle attacks prevented 
during the IC request process?  

- Carlin Covey
  Cylink Corporation

---

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

Carlin,

Some examples of when ICs are generally created (in our experience with 
GSI) might help answer your questions:

   1) Creation of a local IC for single sign-on purposes: In this case, the 
creation of the IC is driven entirely by the holder of the EEC.  So there 
is no requester of the IC.  Or I suppose you could say that the requester 
is already holding the EEC and its private key, so proofing is not an issue.

   2) Delegation of an IC to a remote party, for example when starting a 
remote process: This is usually done over a mutually authenticated channel 
with, for example, the remote process starter service, so the issuer knows 
the identity of the starter to whom it is delegating the IC.  In this case, 
the issuer will be checking the identity of the party to whom it is issuing 
the IC for reasons aside from (or in addition to) proofing the IC 
requester. In addition, the IC delegation is usually done as one step of 
some well defined exchange between the parties, so the issuer knows in 
advance that it wants to issue the IC, and it just need to make sure that 
it is issuing it to the right party.  In other words, the issuance of the 
IC is again mostly driven by the issuer (i.e. the holder of the EEC, or of 
an existing IC), and as part of a larger protocol exchange between the 
parties.  So proofing the IC is really just a matter of checking the 
identity coming from the authentication (which you would do anyway), and 
verifying that the IC request does not have anything unexpected in 
it.  Standard message integrity checking on the mutually authenticated 
channel between the parties will prevent man-in-the-middle attacks.

   3) Certificate repository: Suppose that the EEC and its private key are 
held in some sort of certificate/key repository, which will issue an IC 
upon request from a client.  So the questions are, how does the client 
authenticate with the repository, what authorization checks does the 
repository perform before issuing the IC, and how is a man-in-the-middle 
attack prevented?  Client authentication may be handled in a variety of 
ways.  For example, the client can connect to the server and perform server 
only authentication (i.e. it knows the identity of the repository in 
advance).  It can then provide a name/password, one-time-password, or 
something else over the confidential channel.  This password is used to 
authorize the IC issuance, and the IC is delegated back to the client over 
the integrity checked channel to avoid man-in-the-middle.

So I think the answer to your question is that unlike a traditional CA, in 
the situations where we have used ICs effectively, previously issued EECs 
provide for the automatic authentication necessary to allow for automatic 
proofing of the request.

-Steve

---

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

Thanks, Steve.  That does clarify things.

So impersonation certificates are not intended to be used for
delegating signature authority from one human being to another?

Regards,

Carlin

_____________________________________________
- Carlin Covey
  Cylink Corporation

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

Carlin,

-Steve

---

From: Steve Tuecke <[email-masked]>
Date: Fri, 09 Mar 2001 20:11:36 -0600

Our intended use of ICs in the Globus Project has not been for delegating 
signature authority from one human being to another.  Instead, it has been 
used to allow a human to delegate signature authority to his or her various 
processes running throughout a distributed computing system (aka. a "Grid").

-Steve