Re: draft-ietf-pkix-dsv-dpv-dpd-req-00.txt

[Peter Sylvester <[e-mail]>]

Russ, I don't fully agree with what you are saying but almost. 

Anyway: Your remarks do not correspond to what Paul seems to demand 
as a service options for DPV.

Storing or not the result is independant of the content of the
result. A client may just operate in a way that it shows to the
user whatever the DPV server has answered and then accepts the
result (or maybe the user refuses to continue).

Even storing just a yes, no answer with an identification etc may
be absolutely sufficient for recording purposes. 

It is not clear whether or not it is desirable that the client application
actually has to inform explicitely the server about these two options by
explicitely setting some boolean or a flag in a bitstring. 
And, would the client also specify the means of authentication of the
response. For example, if the communication is already SSL/TLS authenticated,
then it may not be necessary to sign at all, and the server may not
even need to have that functionality of signing.

I would see at least such parameters as part of the configuration
options in a policy definition in a server. 

I don't know whether it is necessary that the client explicity should be
able to say that it wants a signed response with a full path, and then
risk that the server says: "Sorry, I can't", instead of just checking
whether the response is signed and whether there is a path. An application
can just simply check the content of the response to see whether this
matches his needs, maybe accessible by some standard option in an API.

> Peter:
> 
> > > Probably an application would only want one type of answer
> > > consistently, but I suspect that someone could think up a situation
> > > where one application would want different types of answers at
> > > different times.
> >
> >The question would be: Why is a DVP client in position to make
> >such a decision?
> 
> No, this is not the question.  I visualize two types of application using 
> DPV.  The first type wants a yes/no response, and after validating the 
> signature on the response will take an action immediately.  There is no 
> need to record the reason, so the whole path is not needed in the 
> response.  The second type of application wants to record the rationale for 
> its action.  Such an application will want the whole path back.  The 
> application designer will determine the application type.
> 
> Russ
> 



Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id f9VHwdB07256 for ietf-pkix-bks; Wed, 31 Oct 2001 09:58:39 -0800 (PST)
Received: from edelweb.fr (edelweb.fr [212.234.46.16]) by above.proper.com (8.11.6/8.11.3) with ESMTP id f9VHwb807250; Wed, 31 Oct 2001 09:58:37 -0800 (PST)
Received: from champagne.edelweb.fr (localhost.edelweb.fr [127.0.0.1]) by edelweb.fr with ESMTP id SAA00934; Wed, 31 Oct 2001 18:58:30 +0100 (MET)
Received: from champagne.edelweb.fr (champagne.edelweb.fr [193.51.14.161]) by edelweb.fr (nospam/1.3); Wed, 31 Oct 2001 18:58:30 +0100 (MET)
Received: from emeriau.edelweb.fr (emeriau.edelweb.fr [193.51.14.5]) by champagne.edelweb.fr (8.7.6/8.6.6) with ESMTP id SAA19941; Wed, 31 Oct 2001 18:58:29 +0100 (MET)
From: Peter Sylvester <[e-mail]>
Received: (sylvest@localhost) by emeriau.edelweb.fr (8.7.6/8.6.6) id SAA05886; Wed, 31 Oct 2001 18:58:29 +0100 (MET)
Date: Wed, 31 Oct 2001 18:58:29 +0100 (MET)
Message-Id: <[e-mail]>
To: [e-mail], [e-mail]
Subject: Re: draft-ietf-pkix-dsv-dpv-dpd-req-00.txt
Cc: [e-mail], [e-mail]
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-pkix.imc.org>

Russ, I don't fully agree with what you are saying but almost. 

Anyway: Your remarks do not correspond to what Paul seems to demand 
as a service options for DPV.

Storing or not the result is independant of the content of the
result. A client may just operate in a way that it shows to the
user whatever the DPV server has answered and then accepts the
result (or maybe the user refuses to continue).

Even storing just a yes, no answer with an identification etc may
be absolutely sufficient for recording purposes. 

It is not clear whether or not it is desirable that the client application
actually has to inform explicitely the server about these two options by
explicitely setting some boolean or a flag in a bitstring. 
And, would the client also specify the means of authentication of the
response. For example, if the communication is already SSL/TLS authenticated,
then it may not be necessary to sign at all, and the server may not
even need to have that functionality of signing.

I would see at least such parameters as part of the configuration
options in a policy definition in a server. 

I don't know whether it is necessary that the client explicity should be
able to say that it wants a signed response with a full path, and then
risk that the server says: "Sorry, I can't", instead of just checking
whether the response is signed and whether there is a path. An application
can just simply check the content of the response to see whether this
matches his needs, maybe accessible by some standard option in an API.

> Peter:
> 
> > > Probably an application would only want one type of answer
> > > consistently, but I suspect that someone could think up a situation
> > > where one application would want different types of answers at
> > > different times.
> >
> >The question would be: Why is a DVP client in position to make
> >such a decision?
> 
> No, this is not the question.  I visualize two types of application using 
> DPV.  The first type wants a yes/no response, and after validating the 
> signature on the response will take an action immediately.  There is no 
> need to record the reason, so the whole path is not needed in the 
> response.  The second type of application wants to record the rationale for 
> its action.  Such an application will want the whole path back.  The 
> application designer will determine the application type.
> 
> Russ
> 


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id f9VGg2l02683 for ietf-pkix-bks; Wed, 31 Oct 2001 08:42:02 -0800 (PST)
Received: from tholian.securitydynamics.com (mail.rsasecurity.com [204.167.112.129]) by above.proper.com (8.11.6/8.11.3) with SMTP id f9VGft802675 for <[e-mail]>; Wed, 31 Oct 2001 08:41:56 -0800 (PST)
Received: from sdtihq24.securid.com by tholian.securitydynamics.com via smtpd (for mail.imc.org [208.184.76.43]) with SMTP; 31 Oct 2001 16:38:17 UT
Received: from ebola.securitydynamics.com (ebola.securid.com [192.168.7.4]) by sdtihq24.securid.com (Pro-8.9.3/Pro-8.9.3) with ESMTP id LAA04698 for <[e-mail]>; Wed, 31 Oct 2001 11:41:53 -0500 (EST)
Received: from exna00.securitydynamics.com (localhost [127.0.0.1]) by ebola.securitydynamics.com (8.9.3+Sun/8.9.1) with ESMTP id LAA15031 for <[e-mail]>; Wed, 31 Oct 2001 11:41:52 -0500 (EST)
Received: by exna00.securitydynamics.com with Internet Mail Service (5.5.2653.19) id <T1DQ9VDK>; Wed, 31 Oct 2001 11:41:40 -0500
Received: from HOUSLEY-LAP.rsasecurity.com (HOUSLEY-LAP [10.3.1.82]) by exna00.securitydynamics.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id T1DQ9VDJ; Wed, 31 Oct 2001 11:41:36 -0500
From: "Housley, Russ" <[e-mail]>
To: Peter Sylvester <[e-mail]>
Cc: [e-mail]
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Version 5.0.1
Date: Wed, 31 Oct 2001 11:41:40 -0500
Subject: Re: draft-ietf-pkix-dsv-dpv-dpd-req-00.txt
In-Reply-To: <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-pkix.imc.org>

Peter:

> > Probably an application would only want one type of answer
> > consistently, but I suspect that someone could think up a situation
> > where one application would want different types of answers at
> > different times.
>
>The question would be: Why is a DVP client in position to make
>such a decision?

No, this is not the question.  I visualize two types of application using 
DPV.  The first type wants a yes/no response, and after validating the 
signature on the response will take an action immediately.  There is no 
need to record the reason, so the whole path is not needed in the 
response.  The second type of application wants to record the rationale for 
its action.  Such an application will want the whole path back.  The 
application designer will determine the application type.

Russ


Received: by above.proper.com (8.11.6/8.11.3) id f9VCEHX12084 for ietf-pkix-bks; Wed, 31 Oct 2001 04:14:17 -0800 (PST)
Received: from edelweb.fr (edelweb.fr [212.234.46.16]) by above.proper.com (8.11.6/8.11.3) with ESMTP id f9VCEE812075; Wed, 31 Oct 2001 04:14:14 -0800 (PST)
Received: from champagne.edelweb.fr (localhost.edelweb.fr [127.0.0.1]) by edelweb.fr with ESMTP id NAA28056; Wed, 31 Oct 2001 13:14:12 +0100 (MET)
Received: from champagne.edelweb.fr (champagne.edelweb.fr [193.51.14.161]) by edelweb.fr (nospam/1.3); Wed, 31 Oct 2001 13:14:13 +0100 (MET)
Received: from emeriau.edelweb.fr (emeriau.edelweb.fr [193.51.14.5]) by champagne.edelweb.fr (8.7.6/8.6.6) with ESMTP id NAA18773; Wed, 31 Oct 2001 13:14:11 +0100 (MET)
From: Peter Sylvester <[e-mail]>
Received: (sylvest@localhost) by emeriau.edelweb.fr (8.7.6/8.6.6) id NAA05772; Wed, 31 Oct 2001 13:14:10 +0100 (MET)
Date: Wed, 31 Oct 2001 13:14:10 +0100 (MET)
Message-Id: <[e-mail]>
To: [e-mail], [e-mail], [e-mail], [e-mail]
Subject: Re: draft-ietf-pkix-dsv-dpv-dpd-req-00.txt
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-pkix.imc.org>

> 
> Probably an application would only want one type of answer 
> consistently, but I suspect that someone could think up a situation 
> where one application would want different types of answers at 
> different times.

The question would be: Why is a DVP client in position to make
such a decision? 

> 
> >  > >You text described three options for DPV ?
> >>  >
> >>  >- please tell yes or no.
> >>  >- please only return THE path used for validation without telling
> >>  >   whether it is good;
> >>  >- both of the previous ones?
> >>
> >>  Correct. You might want both so you can act immediately on a yes but
> >                           ????
> >>  store the chain for later use, such as if you are online now but you
> >>  know you won't be later.
> >>
> >
> >Are you sure that you have THREE options, in particular does one
> >really need the second one, asking for a path without saying whether
> >it is good or not?
> 
> Yes, we want each one. The yes/no answer must be signed, which takes 
> non-trivial system resources on the part of the server. The path does 
> not need to be signed. The third option (both yes/no and path) is 
> still valuable for the reason I gave.
Why does a yes/no answer need to be signed? The DPV client
only needs to be able to authenticate the response in whatever way in
some cases.

'signed responses' is an optional requirement, this is only one means to 
determine the authenticity of a response which may allow reverification
even after the connection. I would formulate two requirements: 

- the authenticity of a response should be verifiable on receipt
- the authenticity of a response should be verifiable later on (eventually
  by someone eles than the requestor)

Why does 'the path not need to be signed' in DPV? 
I don't understand You statement for a DPV (attention not DPD) concerning 
a path not being signed, not authenticable. This seems contrary to what
DPV is doing. The DPV client does not perform path validation.  

What did I misunderstand here? 

I could imagine 4 different types of a DPV request parameterisation (policy).

  show always path.
  never show path.
  show path if answer is no.
  show path if answer is yes.

Regards



Received: by above.proper.com (8.11.6/8.11.3) id f9V1Yo824119 for ietf-pkix-bks; Tue, 30 Oct 2001 17:34:50 -0800 (PST)
Received: from [165.227.249.20] (165-227-249-20.client.dsl.net [165.227.249.20]) by above.proper.com (8.11.6/8.11.3) with ESMTP id f9V1Yh824113; Tue, 30 Oct 2001 17:34:43 -0800 (PST)
Mime-Version: 1.0
X-Sender: [e-mail] (Unverified)
Message-Id: <p05101001b80503f20211@[165.227.249.20]>
In-Reply-To: <[e-mail]>
References: <[e-mail]>
Date: Tue, 30 Oct 2001 17:34:41 -0800
To: Peter Sylvester <[e-mail]>, [e-mail], [e-mail]
From: Paul Hoffman / IMC <[e-mail]>
Subject: Re: draft-ietf-pkix-dsv-dpv-dpd-req-00.txt
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-pkix.imc.org>

At 7:48 PM +0100 10/30/01, Peter Sylvester wrote:
>  > >
>>  >Are You talking about ONE client that sometimes may want just yes no,
>>  >and sometimes it wants more, or about two different types of usage
>>  >scenarios, or of different clients, or ..
>>
>>  I am talking about one "client", but not one application. A client
>>  could (should!) be an OS function, and that client has applications
>>  that ask it for either yes/no or a good chain.
>
>Ok, then: replace client by application in my previous question.

Probably an application would only want one type of answer 
consistently, but I suspect that someone could think up a situation 
where one application would want different types of answers at 
different times.

>  > >You text described three options for DPV ?
>>  >
>>  >- please tell yes or no.
>>  >- please only return THE path used for validation without telling
>>  >   whether it is good;
>>  >- both of the previous ones?
>>
>>  Correct. You might want both so you can act immediately on a yes but
>                           ????
>>  store the chain for later use, such as if you are online now but you
>>  know you won't be later.
>>
>
>Are you sure that you have THREE options, in particular does one
>really need the second one, asking for a path without saying whether
>it is good or not?

Yes, we want each one. The yes/no answer must be signed, which takes 
non-trivial system resources on the part of the server. The path does 
not need to be signed. The third option (both yes/no and path) is 
still valuable for the reason I gave.

--Paul Hoffman, Director
--Internet Mail Consortium


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id f9UIm4v12606 for ietf-pkix-bks; Tue, 30 Oct 2001 10:48:04 -0800 (PST)
Received: from edelweb.fr (edelweb.fr [212.234.46.16]) by above.proper.com (8.11.6/8.11.3) with ESMTP id f9UIm1812591; Tue, 30 Oct 2001 10:48:02 -0800 (PST)
Received: from champagne.edelweb.fr (localhost.edelweb.fr [127.0.0.1]) by edelweb.fr with ESMTP id TAA23886; Tue, 30 Oct 2001 19:48:01 +0100 (MET)
Received: from champagne.edelweb.fr (champagne.edelweb.fr [193.51.14.161]) by edelweb.fr (nospam/1.3); Tue, 30 Oct 2001 19:48:01 +0100 (MET)
Received: from emeriau.edelweb.fr (emeriau.edelweb.fr [193.51.14.5]) by champagne.edelweb.fr (8.7.6/8.6.6) with ESMTP id TAA16644; Tue, 30 Oct 2001 19:48:00 +0100 (MET)
From: Peter Sylvester <[e-mail]>
Received: (sylvest@localhost) by emeriau.edelweb.fr (8.7.6/8.6.6) id TAA05481; Tue, 30 Oct 2001 19:48:00 +0100 (MET)
Date: Tue, 30 Oct 2001 19:48:00 +0100 (MET)
Message-Id: <[e-mail]>
To: [e-mail], [e-mail], [e-mail], [e-mail]
Subject: Re: draft-ietf-pkix-dsv-dpv-dpd-req-00.txt
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-pkix.imc.org>

> >
> >Are You talking about ONE client that sometimes may want just yes no,
> >and sometimes it wants more, or about two different types of usage
> >scenarios, or of different clients, or ..
> 
> I am talking about one "client", but not one application. A client 
> could (should!) be an OS function, and that client has applications 
> that ask it for either yes/no or a good chain.

Ok, then: replace client by application in my previous question.
 
> 
> >You text described three options for DPV ?
> >
> >- please tell yes or no.
> >- please only return THE path used for validation without telling
> >   whether it is good;
> >- both of the previous ones?
> 
> Correct. You might want both so you can act immediately on a yes but 
                          ????
> store the chain for later use, such as if you are online now but you 
> know you won't be later.
> 

Are you sure that you have THREE options, in particular does one
really need the second one, asking for a path without saying whether
it is good or not? 


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id f9UIK7M10907 for ietf-pkix-bks; Tue, 30 Oct 2001 10:20:07 -0800 (PST)
Received: from ext-mail.valicert.com (ns1.valicert.com [63.65.221.10]) by above.proper.com (8.11.6/8.11.3) with ESMTP id f9UIK6810903 for <[e-mail]>; Tue, 30 Oct 2001 10:20:06 -0800 (PST)
Received: from CONVERSION-DAEMON by ext-mail.valicert.com (PMDF V5.2-33 #46613) id <[e-mail]> for [e-mail]; Tue, 30 Oct 2001 10:20:07 -0800 (PST)
Received: from polaris.valicert.com ([192.168.2.34]) by ext-mail.valicert.com (PMDF V5.2-33 #46613) with ESMTP id <[e-mail]> for [e-mail]; Tue, 30 Oct 2001 10:20:07 -0800 (PST)
Received: by exchange.valicert.com with Internet Mail Service (5.5.2650.21) id <40D1C7JM>; Tue, 30 Oct 2001 10:19:07 -0800
Content-return: allowed
Date: Tue, 30 Oct 2001 10:19:06 -0800
From: Ambarish Malpani <[e-mail]>
Subject: RE: draft-ietf-pkix-dsv-dpv-dpd-req-00.txt
To: [e-mail]
Message-id: <[e-mail]>
MIME-version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-type: text/plain;	charset="iso-8859-1"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-pkix.imc.org>

Denis, as you already know, I agree with Russ and Paul. I would
prefer to see DSV as a separate effort. I think it is likely
to detail the DPV-DPD effort significantly.

After DSV gets stable, we can revisit this decision and see if it
makes sense to pull it back into the DPV-DPD effort.

Regards,
Ambarish

---------------------------------------------------------------------
Ambarish Malpani
Architect                                                650.567.5457
ValiCert, Inc.                                  [e-mail]
339 N. Bernardo Ave.                          http://www.valicert.com
Mountain View, CA 94043


> -----Original Message-----
> From: Paul Hoffman / IMC [mailto:[e-mail]]
> Sent: Tuesday, October 30, 2001 8:53 AM
> To: [e-mail]; [e-mail]
> Subject: Re: draft-ietf-pkix-dsv-dpv-dpd-req-00.txt
> 
> 
> 
> On reflection, I agree with Russ about the removal of the signature 
> policy material. It may be appropriate for this WG, but not in this 
> document. Recent history with this group shows that there is a wide 
> divergence of opinion about the requirements and applicability of 
> signature mechanisms.
> 
> At 7:41 PM +0000 10/25/01, Denis Pinkas wrote:
> >Validation of Digitally Signed Documents is required in the 
> context of a
> >non-repudiation service and requires either the use of 
> Time-stamp tokens or
> >of Time-marks.
> 
> Quite true. This is a good reason to move it to a separate document. 
> Many uses of PKI have nothing to do with digitally signed documents, 
> but instead simple things like authentication mechanisms.
> 
> >Validation of Public Key Certificates is fine for real-time 
> use only, but
> >not for non repudiation purposes, otherwise clients would 
> not be "thin" and
> >would have to do more processing.
> 
> Non-repudiation is important to only a subset of PKI users. Further, 
> it is not clear that if you specify the DSV requirements in a 
> different document that this will cause clients that use the eventual 
> protocol to be less "thin".
> 
> >Instead of removing this material, I believe that additional 
> explanations
> >should be given in the document.
> 
> I disagree. Adding additional explanation will drag out the 
> requirements process.
> 
> >>The client always wan the path and the related revocation 
> information
> >>returned, so it is not necessary to say why. It is primarly not for
> >>archiving purposes but for real time use. Nevertheless, if 
> you really want
> >>this to be mentioned, please make a proposal for an insertion.
> >
> >At 6:47 PM -0400 10/25/01, Housley, Russ wrote:
> >No, this was not my point.  In DPV, sometimes the client simply want 
> >a Yes/No.  Other times the client wants Yes/No and the supporting 
> >data.  The request should allow the client to say which should be 
> >returned.  Only sent the supporting info if the client wants it.
> 
> Russ is right: the client doesn't always want the supporting data. 
> Proposal for insertion at the end of the section:
> 
> The client may request that the server indicate a valid or not valid 
> response, that the server return the path of certificates used to 
> determine a valid response, or that the server return both.
> 
> --Paul Hoffman, Director
> --Internet Mail Consortium
> 


Received: by above.proper.com (8.11.6/8.11.3) id f9UIAga09665 for ietf-pkix-bks; Tue, 30 Oct 2001 10:10:42 -0800 (PST)
Received: from [165.227.249.20] (165-227-249-20.client.dsl.net [165.227.249.20]) by above.proper.com (8.11.6/8.11.3) with ESMTP id f9UIAZ809651; Tue, 30 Oct 2001 10:10:35 -0800 (PST)
Mime-Version: 1.0
X-Sender: [e-mail]
Message-Id: <p0510100db8049ccf33c7@[165.227.249.20]>
In-Reply-To: <[e-mail]>
References: <[e-mail]>
Date: Tue, 30 Oct 2001 10:10:27 -0800
To: Peter Sylvester <[e-mail]>, [e-mail], [e-mail]
From: Paul Hoffman / IMC <[e-mail]>
Subject: Re: draft-ietf-pkix-dsv-dpv-dpd-req-00.txt
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-pkix.imc.org>

At 7:03 PM +0100 10/30/01, Peter Sylvester wrote:
>  >
>>  Russ is right: the client doesn't always want the supporting data.
>>  Proposal for insertion at the end of the section:
>>
>>  The client may request that the server indicate a valid or not valid
>>  response, that the server return the path of certificates used to
>>  determine a valid response, or that the server return both.
>
>To Paul: Two questions for clarification:
>
>Are You talking about ONE client that sometimes may want just yes no,
>and sometimes it wants more, or about two different types of usage
>scenarios, or of different clients, or ..

I am talking about one "client", but not one application. A client 
could (should!) be an OS function, and that client has applications 
that ask it for either yes/no or a good chain.

>You text described three options for DPV ?
>
>- please tell yes or no.
>- please only return THE path used for validation without telling
>   whether it is good;
>- both of the previous ones?

Correct. You might want both so you can act immediately on a yes but 
store the chain for later use, such as if you are online now but you 
know you won't be later.

--Paul Hoffman, Director
--Internet Mail Consortium


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id f9UI36C09462 for ietf-pkix-bks; Tue, 30 Oct 2001 10:03:06 -0800 (PST)
Received: from edelweb.fr (edelweb.fr [212.234.46.16]) by above.proper.com (8.11.6/8.11.3) with ESMTP id f9UI33809455; Tue, 30 Oct 2001 10:03:04 -0800 (PST)
Received: from champagne.edelweb.fr (localhost.edelweb.fr [127.0.0.1]) by edelweb.fr with ESMTP id TAA23631; Tue, 30 Oct 2001 19:03:03 +0100 (MET)
Received: from champagne.edelweb.fr (champagne.edelweb.fr [193.51.14.161]) by edelweb.fr (nospam/1.3); Tue, 30 Oct 2001 19:03:03 +0100 (MET)
Received: from emeriau.edelweb.fr (emeriau.edelweb.fr [193.51.14.5]) by champagne.edelweb.fr (8.7.6/8.6.6) with ESMTP id TAA16544; Tue, 30 Oct 2001 19:03:02 +0100 (MET)
From: Peter Sylvester <[e-mail]>
Received: (sylvest@localhost) by emeriau.edelweb.fr (8.7.6/8.6.6) id TAA05470; Tue, 30 Oct 2001 19:03:02 +0100 (MET)
Date: Tue, 30 Oct 2001 19:03:02 +0100 (MET)
Message-Id: <[e-mail]>
To: [e-mail], [e-mail], [e-mail]
Subject: Re: draft-ietf-pkix-dsv-dpv-dpd-req-00.txt
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-pkix.imc.org>

> 
> Russ is right: the client doesn't always want the supporting data. 
> Proposal for insertion at the end of the section:
> 
> The client may request that the server indicate a valid or not valid 
> response, that the server return the path of certificates used to 
> determine a valid response, or that the server return both.

To Paul: Two questions for clarification:

Are You talking about ONE client that sometimes may want just yes no,
and sometimes it wants more, or about two different types of usage
scenarios, or of different clients, or ..

You text described three options for DPV ?

- please tell yes or no.
- please only return THE path used for validation without telling
  whether it is good;
- both of the previous ones? 

-------------

To Denis: Regarding the policy issues: 

I suggest to go even futher and split out the policy definition 
and management protocol stuff in order to be able to have a
framework for a basic service as fast as possible without getting
lost in difficulties for policy definitions. In particular, I
would see that the policies for the two services are different
things, for example for DPD a strategy of how to look for
paths, either top down or bottom up, DPV contains all kinds of
information about which certs need to be validated.

Regards
Peter


Received: by above.proper.com (8.11.6/8.11.3) id f9UHVWa08668 for ietf-pkix-bks; Tue, 30 Oct 2001 09:31:32 -0800 (PST)
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by above.proper.com (8.11.6/8.11.3) with ESMTP id f9UHVU808663 for <[e-mail]>; Tue, 30 Oct 2001 09:31:30 -0800 (PST)
Received: from ireserver.Ireland.Sun.COM ([129.156.220.7]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id JAA21496 for <[e-mail]>; Tue, 30 Oct 2001 09:31:31 -0800 (PST)
Received: from sun.com (boston [129.156.220.153]) by ireserver.Ireland.Sun.COM (8.8.8+Sun/8.8.8/ENSMAIL,v2.1p1) with ESMTP id RAA27666; Tue, 30 Oct 2001 17:31:23 GMT
Message-ID: <[e-mail]>
Date: Tue, 30 Oct 2001 17:31:23 +0000
From: Sean Mullan <[e-mail]>
Organization: Sun Microsystems
X-Mailer: Mozilla 4.76C-CCK-MCD Netscape [en] (X11; U; SunOS 5.7 sun4u)
X-Accept-Language: en
MIME-Version: 1.0
To: [e-mail]
Subject: PKIX roadmap
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-pkix.imc.org>

I see that the PKIX Roadmap Internet Draft (draft-ietf-pkix-roadmap)
has expired. Does anyone happen to have saved a copy that they 
can send to me or the list?

Are there any plans to revive/keep this draft moving forward?

Thanks,
Sean


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id f9UGr3K06828 for ietf-pkix-bks; Tue, 30 Oct 2001 08:53:03 -0800 (PST)
Received: from [165.227.249.20] (165-227-249-20.client.dsl.net [165.227.249.20]) by above.proper.com (8.11.6/8.11.3) with ESMTP id f9UGqx806815; Tue, 30 Oct 2001 08:52:59 -0800 (PST)
Mime-Version: 1.0
X-Sender: [e-mail]
Message-Id: <p05101008b8048b5b1c66@[165.227.249.20]>
Date: Tue, 30 Oct 2001 08:52:54 -0800
To: [e-mail] (Denis Pinkas), [e-mail]
From: Paul Hoffman / IMC <[e-mail]>
Subject: Re: draft-ietf-pkix-dsv-dpv-dpd-req-00.txt
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-pkix.imc.org>

On reflection, I agree with Russ about the removal of the signature 
policy material. It may be appropriate for this WG, but not in this 
document. Recent history with this group shows that there is a wide 
divergence of opinion about the requirements and applicability of 
signature mechanisms.

At 7:41 PM +0000 10/25/01, Denis Pinkas wrote:
>Validation of Digitally Signed Documents is required in the context of a
>non-repudiation service and requires either the use of Time-stamp tokens or
>of Time-marks.

Quite true. This is a good reason to move it to a separate document. 
Many uses of PKI have nothing to do with digitally signed documents, 
but instead simple things like authentication mechanisms.

>Validation of Public Key Certificates is fine for real-time use only, but
>not for non repudiation purposes, otherwise clients would not be "thin" and
>would have to do more processing.

Non-repudiation is important to only a subset of PKI users. Further, 
it is not clear that if you specify the DSV requirements in a 
different document that this will cause clients that use the eventual 
protocol to be less "thin".

>Instead of removing this material, I believe that additional explanations
>should be given in the document.

I disagree. Adding additional explanation will drag out the 
requirements process.

>>The client always wan the path and the related revocation information
>>returned, so it is not necessary to say why. It is primarly not for
>>archiving purposes but for real time use. Nevertheless, if you really want
>>this to be mentioned, please make a proposal for an insertion.
>
>At 6:47 PM -0400 10/25/01, Housley, Russ wrote:
>No, this was not my point.  In DPV, sometimes the client simply want 
>a Yes/No.  Other times the client wants Yes/No and the supporting 
>data.  The request should allow the client to say which should be 
>returned.  Only sent the supporting info if the client wants it.

Russ is right: the client doesn't always want the supporting data. 
Proposal for insertion at the end of the section:

The client may request that the server indicate a valid or not valid 
response, that the server return the path of certificates used to 
determine a valid response, or that the server return both.

--Paul Hoffman, Director
--Internet Mail Consortium


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id f9UFRdp22044 for ietf-pkix-bks; Tue, 30 Oct 2001 07:27:39 -0800 (PST)
Received: from server.ica.cz (server.ica.cz [195.47.13.11]) by above.proper.com (8.11.6/8.11.3) with ESMTP id f9UFRa822038 for <[e-mail]>; Tue, 30 Oct 2001 07:27:36 -0800 (PST)
Received: from mec (com.ica.cz [195.47.13.10]) by server.ica.cz (8.9.2/8.8.7) with SMTP id QAA05279 for <[e-mail]>; Tue, 30 Oct 2001 16:27:31 +0100 (CET)
Message-ID: <04d301c16157$647fca30$212911ac@mec>
From: "Martin Szotkowski" <[e-mail]>
To: <[e-mail]>
Subject: maybe problem in RFC2459 with keyIdentifier
Date: Tue, 30 Oct 2001 16:27:31 +0100
Organization: PVT, a.s.
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-2"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2462.0000
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2462.0000
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-pkix.imc.org>

Hi all,
I looked into RFC 2459 and last draft-ietf-pkix-new-part1-11 in both is same
mistake. (I think. Because my knowledge ASN.1 and BER is no so good)

Problem is in encode KeyIdentifier from ASN.1 to BER. KeyIdentifier is
defined as a OCTED STRING this should be 04 length data.
In SubjestKeyIdentifier is it OK:
80 20 SHA1_data
, but in AuthorityKeyIdentifier is not 04 encapsulated 80  (content
specific), but only 80.
wrong is: 80 20  SHA1_data
I think right should be: 80 22 04 20 SHA1_data

extract from last draft:
SubjectKeyIdentifier ::= KeyIdentifier

AuthorityKeyIdentifier ::= SEQUENCE {
      keyIdentifier             [0] KeyIdentifier           OPTIONAL,
      authorityCertIssuer       [1] GeneralNames            OPTIONAL,
      authorityCertSerialNumber [2] CertificateSerialNumber OPTIONAL  }

KeyIdentifier ::= OCTET STRING

example C.1 (correct):
 595 30   29:         SEQUENCE {
 597 06    3:           OBJECT IDENTIFIER
            :             subjectKeyIdentifier (2 5 29 14)
 602 04   22:           OCTET STRING, encapsulates {
 604 04   20:               OCTET STRING
            :                 86 CA A5 22 81 62 EF AD 0A 89 BC AD 72 41
            :                 2C 29 49 F4 86 56
            :               }
            :           }

example C.2 (incorrect):
 640 30   31:         SEQUENCE {
 642 06    3:           OBJECT IDENTIFIER
            :             authorityKeyIdentifier (2 5 29 35)
 647 04   24:           OCTET STRING, encapsulates {
 649 30   22:               SEQUENCE {
 651 80   20:                 [0]
            :                   86 CA A5 22 81 62 EF AD 0A 89 BC AD 72
            :                   41 2C 29 49 F4 86 56
            :                 }
            :               }
            :           }
            :         }

regards,
Martin




Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id f9U8gaw17779 for ietf-pkix-bks; Tue, 30 Oct 2001 00:42:36 -0800 (PST)
Received: from rom.antech.de (dns.antech.de [194.45.12.2]) by above.proper.com (8.11.6/8.11.3) with ESMTP id f9U8gY817770 for <[e-mail]>; Tue, 30 Oct 2001 00:42:35 -0800 (PST)
Received: from Serbius.secorvo.de (kasiski.secorvo.de [194.45.12.203]) by rom.antech.de (8.9.3/8.9.3) with ESMTP id IAA31804; Tue, 30 Oct 2001 08:55:40 +0100
Message-Id: <[e-mail]>
From: "Stefan Kelm" <[e-mail]>
Organization: Secorvo Security Consulting GmbH
To: "Kronenberg, Peter" <[e-mail]>, "'[e-mail]'" <[e-mail]>
Date: Tue, 30 Oct 2001 09:42:52 +0100
MIME-Version: 1.0
Content-type: text/plain; charset=US-ASCII
Content-transfer-encoding: 7BIT
Subject: Re: Software for PKI
Reply-to: [e-mail]
In-reply-to: <[e-mail]>
X-mailer: Pegasus Mail for Win32 (v3.12b)
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-pkix.imc.org>

Peter,

> I am student and make a work about PKI. I have to test the interoperability
> of an IP-router with IPSEC-Implementation for the use with a PKI. I am
> looking for different PKI-softwares (PKIX) for Linux and Windows. I will use
> the software only for testing purpose. Do you know any good Software to test
> the interoperability with PKIX (with a certification-authority, LDAP, CRL
> and so on) ?

have a look at the tools section of my PKI page:

  http://www.pki-page.info/#TOOLS

Cheers,

	Stefan.

-------------------------------------------------------
Dipl.-Inform. Stefan Kelm
Security Consultant

Secorvo Security Consulting GmbH
Albert-Nestler-Strasse 9, D-76131 Karlsruhe

Tel. [phone], Fax [phone]
E-Mail [e-mail], http://www.secorvo.de
-------------------------------------------------------
PGP Fingerprint 87AE E858 CCBC C3A2 E633 D139 B0D9 212B


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id f9TN4bb19413 for ietf-pkix-bks; Mon, 29 Oct 2001 15:04:37 -0800 (PST)
Received: from mail.hackmasters.net ([217.133.235.193]) by above.proper.com (8.11.6/8.11.3) with ESMTP id f9TN4X819408 for <[e-mail]>; Mon, 29 Oct 2001 15:04:33 -0800 (PST)
Received: from hackmasters.net (galadriel.mpnet.hackmasters.net [10.5.122.180]) by mail.hackmasters.net (Postfix) with ESMTP id C45733D00 for <[e-mail]>; Tue, 30 Oct 2001 00:11:17 +0100 (CET)
Message-ID: <[e-mail]>
Date: Tue, 30 Oct 2001 00:11:06 +0100
From: Massimiliano Pala <[e-mail]>
Organization: OpenCA
X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.2.19 i686)
X-Accept-Language: en
MIME-Version: 1.0
Cc: [e-mail]
Subject: Re: Software for PKI
References: <[e-mail]>
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------msAE87A5BA7C82CB9CAD23C904"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-pkix.imc.org>

This is a cryptographically signed message in MIME format.

--------------msAE87A5BA7C82CB9CAD23C904
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Peter Gutmann wrote:

> There are several open-source apps you can use, eg OpenCA (www.openca.org,
> although the last time I looked it still seemed a bit of a work in progress) or
> cryptlib (www.cs.auckland.ac.nz/~pgut001/cryptlib).

Of course it is work in progress :-D

If you need it, we are about to release the v0.8.0, it should be a metter
of couple of days, now.

-- 

C'you,

	Massimiliano Pala

--o-------------------------------------------------------------------------
Massimiliano Pala [OpenCA Project Manager]                  [e-mail]
                                                          [e-mail]
                                                     [e-mail]
http://www.openca.org                            Tel.:   [phone]
http://openca.sourceforge.net                    Mobile: [phone]
--------------msAE87A5BA7C82CB9CAD23C904
Content-Type: application/x-pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature

MIIF+gYJKoZIhvcNAQcCoIIF6zCCBecCAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC
BFowggRWMIIDPqADAgECAgIDITANBgkqhkiG9w0BAQQFADBAMSAwHgYDVQQDExdDZXJ0aWZp
Y2F0aW9uIEF1dGhvcml0eTEPMA0GA1UEChMGT3BlbkNBMQswCQYDVQQGEwJJVDAeFw0wMTAy
MjcxMzQ0NTRaFw0wMjAyMjcxMzQ0NTRaMIGFMSYwJAYJKoZIhvcNAQkBFhdtYWR3b2xmQGhh
Y2ttYXN0ZXJzLm5ldDEaMBgGA1UEAxMRTWFzc2ltaWxpYW5vIFBhbGExFDASBgNVBAsTC09w
ZW5DQSBVc2VyMRwwGgYDVQQKExNPcGVuQ0EgT3JnYW5pemF0aW9uMQswCQYDVQQGEwJJVDCB
nzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAs7c/i7zt8oRbF/MO3/Xq1bWb2h3y5VdRsm0E
MT22pFX7yjaKp4pSF36NDPJb4ss6aqqGLSiyyI/Wy+7124JDOzXhY4S0XPbZ6MmLUy4vp3Ze
+jmgJNyO2j+BtRQarUaEno+JIUizU4pcEtUO4BaPkxRqaL02raR61i3+foCQb/MCAwEAAaOC
AZYwggGSMAkGA1UdEwQCMAAwEQYJYIZIAYb4QgEBBAQDAgWgMAsGA1UdDwQEAwIF4DAmBglg
hkgBhvhCAQ0EGRYXT3BlbkNBIFVzZXIgQ2VydGlmaWNhdGUwHQYDVR0OBBYEFPtjrGNl7QbD
nNY0rT2UFmtDF8doMGgGA1UdIwRhMF+AFAtL08ix9MbKXM950at8v/yRSMd7oUSkQjBAMSAw
HgYDVQQDExdDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTEPMA0GA1UEChMGT3BlbkNBMQswCQYD
VQQGEwJJVIIBADAJBgNVHREEAjAAMAkGA1UdEgQCMAAwNAYJYIZIAYb4QgEEBCcWJWh0dHBz
Oi8vd3d3Lm9wZW5jYS5vcmcvY2dpLWJpbi9nZXRjcmwwNAYJYIZIAYb4QgEDBCcWJWh0dHBz
Oi8vd3d3Lm9wZW5jYS5vcmcvY2dpLWJpbi9nZXRjcmwwMgYJYIZIAYb4QgEHBCUWI2h0dHBz
Oi8vd3d3Lm9wZW5jYS5vcmc6NDQ0My9yZW5ld2FsMA0GCSqGSIb3DQEBBAUAA4IBAQBbbzeN
MZcl2K68tfAzCD72PB+hnwBuFBebVwVg5vWNJh/Zu0y2HAzy5pv9EcqLwS/2d5lqhwzG6a2H
W0HrrPbKxaLdQ4bZzDLG6zUohXzlCH0l2sq4BVuQF/dLVY/Gj2T9azYE0Yf2pOVG1VCC7zCR
9EtXsM51MbHzgxvOpUZD9sti2Y7UHmwxpr8vYodNLGQgR0B4tyWgCo5/LWyRk+u+4S0fFLsl
FISFpqNsTtDQxRWvmDD8BZhH5OFMHgCN73Wsngq2Hopo7QeKR2Ghwc+cIZHtk2Huoaj059Nz
/WXixzezZm5j3G1JWAzHfLo17n+nDdbF+OBODEhhuSIIBMI+MYIBaDCCAWQCAQEwRjBAMSAw
HgYDVQQDExdDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTEPMA0GA1UEChMGT3BlbkNBMQswCQYD
VQQGEwJJVAICAyEwCQYFKw4DAhoFAKB6MBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwGwYJ
KoZIhvcNAQkPMQ4wDDAKBggqhkiG9w0DBzAcBgkqhkiG9w0BCQUxDxcNMDExMDI5MjMxMTA2
WjAjBgkqhkiG9w0BCQQxFgQU6++XQkX8tZqngJDqiD9RKw06arEwDQYJKoZIhvcNAQEBBQAE
gYAraO0aVsNMwN/c3yJlUzmd++kerjLYnMCs1ApyBZIXolzic7x6Vxn/VpwWMu84pPmWgb4q
/T1gHxwILaPG3o/2qRmh8z+n/93L/UYuZFq/UKRuphYXEOKwxa4EITqO8K/+VlNr8KQlwpZs
84bN7s4R16Tfsp6InbQvQq0J3qYBNQ==
--------------msAE87A5BA7C82CB9CAD23C904--



Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id f9THoNR06583 for ietf-pkix-bks; Mon, 29 Oct 2001 09:50:23 -0800 (PST)
Received: from druss.secaron.de (druss.secaron.de [195.145.99.123]) by above.proper.com (8.11.6/8.11.3) with ESMTP id f9THoJ806579 for <[e-mail]>; Mon, 29 Oct 2001 09:50:19 -0800 (PST)
Received: by druss.secaron.de (Postfix, from userid 0) id 4FF9051F23; Mon, 29 Oct 2001 18:50:15 +0100 (MET)
Received: from marvin.munich.secaron.de (localhost [127.0.0.1]) by druss.secaron.de (Postfix) with ESMTP id C75B632551 for <[e-mail]>; Mon, 29 Oct 2001 18:50:14 +0100 (MET)
Subject: Re: Software for PKI
To: "'[e-mail]'" <[e-mail]>
X-Mailer: Lotus Notes Release 5.0.8  June 18, 2001
Message-ID: <[e-mail]>
From: "Bernhard Weber" <[e-mail]>
Date: Mon, 29 Oct 2001 18:50:13 +0100
X-MIMETrack: Serialize by Router on Marvin/Secaron(Release 5.0.8 |June 18, 2001) at 10/29/2001 06:50:14 PM
MIME-Version: 1.0
Content-type: text/plain; charset=us-ascii
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-pkix.imc.org>

Hi Peter,

PKI is really a wide range. If you need some information
about CRLs and OCSP (Online Certificate Status Protocol),
you should visit http://www.openvalidation.org .

Openvalidation.org provides some free of charge services:
  - general PKI information and OCSP-related marketoverview
  - OCSP application test with a professional OCSP-responder
  - OCSP responder service chaining to individual locations

check it out,

Bernhard

--------------------------------------------------------------


Hi

I am student and make a work about PKI. I have to test the interoperability
of an IP-router with IPSEC-Implementation for the use with a PKI. I am
looking for different PKI-softwares (PKIX) for Linux and Windows. I will
use
the software only for testing purpose. Do you know any good Software to
test
the interoperability with PKIX (with a certification-authority, LDAP, CRL
and so on) ?

Thanks for any remarks
Peter







Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id f9R15q205214 for ietf-pkix-bks; Fri, 26 Oct 2001 18:05:52 -0700 (PDT)
Received: from kakapo.cs.auckland.ac.nz (kakapo.cs.auckland.ac.nz [130.216.34.10]) by above.proper.com (8.11.6/8.11.3) with ESMTP id f9R15o805210 for <[e-mail]>; Fri, 26 Oct 2001 18:05:50 -0700 (PDT)
Received: from ruru.cs.auckland.ac.nz (firebird.cs.auckland.ac.nz [130.216.34.12]) by kakapo.cs.auckland.ac.nz (8.8.6/8.8.6/cs-master) with ESMTP id OAA21531; Sat, 27 Oct 2001 14:05:44 +1300 (NZDT) (sender [e-mail])
Received: (from pgut001@localhost) by ruru.cs.auckland.ac.nz (8.9.3/8.8.6/cs-slave) id OAA85397; Sat, 27 Oct 2001 14:05:44 +1300 (NZDT) (sender [e-mail])
Date: Sat, 27 Oct 2001 14:05:44 +1300 (NZDT)
Message-ID: <[e-mail]>
From: [e-mail] (Peter Gutmann)
To: [e-mail], [e-mail]
Subject: Re:  Software for PKI
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-pkix.imc.org>

"Kronenberg, Peter" <[e-mail]> writes:
>I am student and make a work about PKI. I have to test the interoperability of
>an IP-router with IPSEC-Implementation for the use with a PKI. I am looking
>for different PKI-softwares (PKIX) for Linux and Windows. I will use the
>software only for testing purpose. Do you know any good Software to test the
>interoperability with PKIX (with a certification-authority, LDAP, CRL and so
>on) ?

There are several open-source apps you can use, eg OpenCA (www.openca.org,
although the last time I looked it still seemed a bit of a work in progress) or
cryptlib (www.cs.auckland.ac.nz/~pgut001/cryptlib).

Peter.


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id f9QGpKe23453 for ietf-pkix-bks; Fri, 26 Oct 2001 09:51:20 -0700 (PDT)
Received: from STEALTH.mvpn.net ([216.41.112.6]) by above.proper.com (8.11.6/8.11.3) with ESMTP id f9QGpI823449 for <[e-mail]>; Fri, 26 Oct 2001 09:51:18 -0700 (PDT)
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Subject: RE: Software for PKI
X-MimeOLE: Produced By Microsoft Exchange V6.0.4418.65
Date: Fri, 26 Oct 2001 12:51:05 -0400
Message-ID: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: Software for PKI
Thread-Index: AcFeOLX78DsA2on+QIi454LYIkAk9gABO61A
From: "Michael J. Rowan" <[e-mail]>
To: "Kronenberg, Peter" <[e-mail]>, <[e-mail]>
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id f9QGpJ823450
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-pkix.imc.org>

 
-----BEGIN PGP SIGNED MESSAGE-----

Peter:

Our company mPKI has a product which is entirely web based and a test
environment could be setup for your use in minutes.  The product is CDS
(Certificate Deployment Server) and is designed to be a middleware
application which interoperates with multiple CA's.  The immediate dev
area which could be setup would be talking to a CyberTrust CA.  You
would have the ability to generate client and device certificates as
well as perform CRL testing against a test directory server via LDAP.
If you are interested please contact our implementation Engineer here:
[e-mail] (Robert Anderson).  Please explain to Robert that we
have spoken, this will push your setup.  Also, a bit more detail on your
testing would be great.  Thanks.

Michael J. Rowan
Chief Technology Officer
mPKI
401.736.0000 x101
401.736.0077 (corporate fax)
401.679.0323 (direct fax)

http://mpki.com

mPKI
Warwick Executive Office Park
250 Centerville Road.
Warwick, RI  02886


Confidentiality Note

This e-mail and any files transmitted with it are the property of mPKI
and/or its affiliates, are confidential, and are intended solely for the
use of the individual or entity to whom this e-mail is addressed. If you
are not one of the named recipient(s) or otherwise have reason to
believe that you have received this message in error, please notify the
sender at 401-736-0000 and delete this message immediately from your
computer. Any other use, retention, dissemination forwarding, printing
or copying of this e-mail is strictly prohibited.



- -----Original Message-----
From: Kronenberg, Peter [mailto:[e-mail]]
Sent: Friday, October 26, 2001 10:24 AM
To: '[e-mail]'
Subject: Software for PKI



Hi

I am student and make a work about PKI. I have to test the
interoperability
of an IP-router with IPSEC-Implementation for the use with a PKI. I am
looking for different PKI-softwares (PKIX) for Linux and Windows. I will
use
the software only for testing purpose. Do you know any good Software to
test
the interoperability with PKIX (with a certification-authority, LDAP,
CRL
and so on) ?

Thanks for any remarks
Peter

-----BEGIN PGP SIGNATURE-----
Version: PGP 7.1

iQCVAwUBO9mUeEbA3L8a+/YhAQHOpAQA0dxTg1hHC7oVgEcz+eGq6FaPIatpAU/T
7ax1VMMW08bMLGodsA8x9QbgJO2bjqT7TrQDggH2EZOjP1nfO3IE1xw5YgFez+Mj
MgD+DmnDHUFUQKssXmZzicrhxX5eH8pVTMv5//K/3Mm950Pj4zL2VPAqVI2w+AJX
Qhk+RpOQSYo=
=CL6E
-----END PGP SIGNATURE-----



Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id f9QFR7B16115 for ietf-pkix-bks; Fri, 26 Oct 2001 08:27:07 -0700 (PDT)
Received: from tholian.securitydynamics.com (mail.rsasecurity.com [204.167.112.129]) by above.proper.com (8.11.6/8.11.3) with SMTP id f9QFR5816109 for <[e-mail]>; Fri, 26 Oct 2001 08:27:05 -0700 (PDT)
Received: from sdtihq24.securid.com by tholian.securitydynamics.com via smtpd (for mail.imc.org [208.184.76.43]) with SMTP; 26 Oct 2001 15:23:36 UT
Received: from ebola.securitydynamics.com (ebola.securid.com [192.168.7.4]) by sdtihq24.securid.com (Pro-8.9.3/Pro-8.9.3) with ESMTP id LAA17204 for <[e-mail]>; Fri, 26 Oct 2001 11:27:06 -0400 (EDT)
Received: from exna00.securitydynamics.com (localhost [127.0.0.1]) by ebola.securitydynamics.com (8.9.3+Sun/8.9.1) with ESMTP id LAA19671 for <[e-mail]>; Fri, 26 Oct 2001 11:27:05 -0400 (EDT)
Received: by exna00.securitydynamics.com with Internet Mail Service (5.5.2653.19) id <T1DQ8A8X>; Fri, 26 Oct 2001 11:26:54 -0400
Received: from HOUSLEY-LAP.rsasecurity.com (HOUSLEY-LAP [10.3.1.23]) by exna00.securitydynamics.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id T1DQ8A8R; Fri, 26 Oct 2001 11:26:50 -0400
From: "Housley, Russ" <[e-mail]>
To: Denis Pinkas <[e-mail]>
Cc: [e-mail]
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Version 5.0.1
Date: Thu, 25 Oct 2001 18:47:07 -0400
Subject: Re: draft-ietf-pkix-dsv-dpv-dpd-req-00.txt
In-Reply-To: <[e-mail]>
References: <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-pkix.imc.org>

Denis:

> > MAJOR
>
> > Please remove the signature policy material.  I believe that this should be
> > handled separately, if at all.  I do not want discussions of this new topic
> > to further delay DPV and DPD.  If the signature topic has a constituency,
> > it may not be the same as that of DPV/DPD.
>
>RFC 3029, i.e. Data Validation and Certification Server Protocols (DVCS)
>makes the difference between:
>
>    - Validation of Digitally Signed Document (vsd), and
>    - Validation of Public Key Certificates (vpkc).
>
>   ... and I believe that this is fine.
>
>Validation of Digitally Signed Documents is required in the context of a
>non-repudiation service and requires either the use of Time-stamp tokens or
>of Time-marks.
>
>Validation of Public Key Certificates is fine for real-time use only, but
>not for non repudiation purposes, otherwise clients would not be "thin" and
>would have to do more processing.
>
>Instead of removing this material, I believe that additional explanations
>should be given in the document.

Your comments do not address my concern.  If there is a constituency for 
DSV, then that work can proceed in a separate document.  Please do not 
further delay the DPV and DPD document progression while the working group 
debates the merits and details of DSV.

> > In section 3, the assertion that "client ... policy definition may be quite
> > complex and only simple forms of policies can be defined in this way" needs
> > clarification and justification.  What sorts of elements are anticipated
> > within the policy definitions?  What will fall within the
> > standard-supported scope as opposed to a server-side local matter?  I would
> > strive for an approach that minimizes (or eliminates) the latter.
>
>You are right. It is hard to draw a line. Instead of saying exactly what
>falls inside and outside the line, I have attempted to characterize the way
>the limit should be drawn:
>
>"Alternatively, clients may also define policies. However, such policy
>definition may be quite complex and only simple forms of policies should be
>defined in this way, otherwise testing all the possible variations would
>lead to non-interoperable implementations or would delay the time to make
>sure that two implementations are really interoperable."

At first blush, this seems okay.  I want to think about it some more...

> > MINOR
>
> > In section 5, the client may want the path and related revocation
> > information returned for archive purposes.  Please make this an option.
>
>The client always wan the path and the related revocation information
>returned, so it is not necessary to say why. It is primarly not for
>archiving purposes but for real time use. Nevertheless, if you really want
>this to be mentioned, please make a proposal for an insertion.

No, this was not my point.  In DPV, sometimes the client simply want a 
Yes/No.  Other times the client wants Yes/No and the supporting data.  The 
request should allow the client to say which should be returned.  Only sent 
the supporting info if the client wants it.

> > In section 10, first paragraph, I do not understand the reference to "its
> > dual."  Please clarify.
>
>The support of these is request/response pairs is optional. These
>request/response pairs allow either to define a policy, i.e. a signature
>policy, a validation policy and/or a path discovery policy, and to receive
>back a reference for that policy or to provide a reference to a previously
>defined policy and to receive back the definition of that policy.

The syntax may be different for each policy type.

Russ


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id f9QEahI10149 for ietf-pkix-bks; Fri, 26 Oct 2001 07:36:43 -0700 (PDT)
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by above.proper.com (8.11.6/8.11.3) with ESMTP id f9QEag810145 for <[e-mail]>; Fri, 26 Oct 2001 07:36:42 -0700 (PDT)
Received: from ireserver.Ireland.Sun.COM ([129.156.220.7]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id HAA07896; Fri, 26 Oct 2001 07:36:40 -0700 (PDT)
Received: from sun.com (boston [129.156.220.153]) by ireserver.Ireland.Sun.COM (8.8.8+Sun/8.8.8/ENSMAIL,v2.1p1) with ESMTP id PAA26893; Fri, 26 Oct 2001 15:36:37 +0100 (BST)
Message-ID: <[e-mail]>
Date: Fri, 26 Oct 2001 15:36:36 +0100
From: Sean Mullan <[e-mail]>
Organization: Sun Microsystems
X-Mailer: Mozilla 4.76 [en] (X11; U; SunOS 5.7 sun4u)
X-Accept-Language: en
MIME-Version: 1.0
To: "Kronenberg, Peter" <[e-mail]>
CC: "'[e-mail]'" <[e-mail]>
Subject: Re: Software for PKI
References: <[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-pkix.imc.org>

You might want to have a look at the Java Certification Path API,
which supports building and validating chains of certificates. This
API is targeted for inclusion in the Java 2 Standard Edition v. 1.4 
and includes a reference implementation that supports the PKIX certpath 
validation algorithm as well as retrieval of certificates and CRLs using 
the LDAP protocol.

J2SE 1.4 is currently in beta. See http://java.sun.com/j2se/1.4/ for
more info. See http://java.sun.com/j2se/1.4/docs/guide/security/certpath/CertPathProgGuide.html
for information on programming with the CertPath API.

--Sean

"Kronenberg, Peter" wrote:
> 
> Hi
> 
> I am student and make a work about PKI. I have to test the interoperability
> of an IP-router with IPSEC-Implementation for the use with a PKI. I am
> looking for different PKI-softwares (PKIX) for Linux and Windows. I will use
> the software only for testing purpose. Do you know any good Software to test
> the interoperability with PKIX (with a certification-authority, LDAP, CRL
> and so on) ?
> 
> Thanks for any remarks
> Peter


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id f9QDLr304573 for ietf-pkix-bks; Fri, 26 Oct 2001 06:21:53 -0700 (PDT)
Received: from VIRUSWALL.omnisec.ch ([195.89.23.162]) by above.proper.com (8.11.6/8.11.3) with SMTP id f9QDLp804569 for <[e-mail]>; Fri, 26 Oct 2001 06:21:51 -0700 (PDT)
Received: by mailserver.omnisec.ch with Internet Mail Service (5.5.2653.19) id <TWBS4XZD>; Fri, 26 Oct 2001 15:24:13 +0100
Message-ID: <[e-mail]>
From: "Kronenberg, Peter" <[e-mail]>
To: "'[e-mail]'" <[e-mail]>
Subject: Software for PKI
Date: Fri, 26 Oct 2001 15:24:09 +0100
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-pkix.imc.org>

Hi

I am student and make a work about PKI. I have to test the interoperability
of an IP-router with IPSEC-Implementation for the use with a PKI. I am
looking for different PKI-softwares (PKIX) for Linux and Windows. I will use
the software only for testing purpose. Do you know any good Software to test
the interoperability with PKIX (with a certification-authority, LDAP, CRL
and so on) ?

Thanks for any remarks
Peter


Received: by above.proper.com (8.11.6/8.11.3) id f9QB3iT23360 for ietf-pkix-bks; Fri, 26 Oct 2001 04:03:44 -0700 (PDT)
Received: from ietf.org (odin.ietf.org [132.151.1.176]) by above.proper.com (8.11.6/8.11.3) with ESMTP id f9QB3h823355 for <[e-mail]>; Fri, 26 Oct 2001 04:03:43 -0700 (PDT)
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA26971; Fri, 26 Oct 2001 07:03:41 -0400 (EDT)
Message-Id: <[e-mail]>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Cc: [e-mail]
From: [e-mail]
Reply-to: [e-mail]
Subject: I-D ACTION:draft-ietf-pkix-new-part1-11.txt
Date: Fri, 26 Oct 2001 07:03:41 -0400
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-pkix.imc.org>

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Public-Key Infrastructure (X.509) Working Group of the IETF.

	Title		: Internet X.509 Public Key Infrastructure Certificate 
                          and CRL Profile
	Author(s)	: R. Housley, W. Ford, W. Polk, D. Solo
	Filename	: draft-ietf-pkix-new-part1-11.txt
	Pages		: 129
	Date		: 25-Oct-01
	
When complete, this specification will obsolete RFC 2459.
Please send comments on this document to the [e-mail] mail
list.
This memo profiles the X.509 v3 certificate and X.509 v2 CRL for use
in the Internet.  An overview of the approach and model are provided
as an introduction.  The X.509 v3 certificate format is described in
detail, with additional information regarding the format and
semantics of Internet name forms (e.g., IP addresses).

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-pkix-new-part1-11.txt

To remove yourself from the IETF Announcement list, send a message to 
ietf-announce-request with the word unsubscribe in the body of the message.

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-pkix-new-part1-11.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt


Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[e-mail].
In the body type:
	"FILE /internet-drafts/draft-ietf-pkix-new-part1-11.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.
		
		
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body;
	access-type="mail-server";
	server="[e-mail]"

Content-Type: text/plain
Content-ID:	<[e-mail]>

ENCODING mime
FILE /internet-drafts/draft-ietf-pkix-new-part1-11.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-pkix-new-part1-11.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:	<[e-mail]>

--OtherAccess--

--NextPart--




Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id f9QB3d223353 for ietf-pkix-bks; Fri, 26 Oct 2001 04:03:39 -0700 (PDT)
Received: from ietf.org (odin.ietf.org [132.151.1.176]) by above.proper.com (8.11.6/8.11.3) with ESMTP id f9QB3b823349 for <[e-mail]>; Fri, 26 Oct 2001 04:03:37 -0700 (PDT)
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA26955; Fri, 26 Oct 2001 07:03:35 -0400 (EDT)
Message-Id: <[e-mail]>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Cc: [e-mail]
From: [e-mail]
Reply-to: [e-mail]
Subject: I-D ACTION:draft-ietf-pkix-ipki-pkalgs-05.txt
Date: Fri, 26 Oct 2001 07:03:35 -0400
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-pkix.imc.org>

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Public-Key Infrastructure (X.509) Working Group of the IETF.

	Title		: Algorithms and Identifiers for the Internet X.509 
                          Public Key Infrastructure Certificate and CRI Profile
	Author(s)	: L. Bassham, R. Housley, W. Polk
	Filename	: draft-ietf-pkix-ipki-pkalgs-05.txt
	Pages		: 27
	Date		: 25-Oct-01
	
This document specifies algorithm identifiers and ASN.1 encoding
formats for digital signatures and subject public keys used in the
Internet X.509 Public Key Infrastructure (PKI).  Digital signatures
are used to sign certificates and certificate revocation lists
(CRLs).  Certificates include the public key of the named subject.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-pkix-ipki-pkalgs-05.txt

To remove yourself from the IETF Announcement list, send a message to 
ietf-announce-request with the word unsubscribe in the body of the message.

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-pkix-ipki-pkalgs-05.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt


Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[e-mail].
In the body type:
	"FILE /internet-drafts/draft-ietf-pkix-ipki-pkalgs-05.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.
		
		
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body;
	access-type="mail-server";
	server="[e-mail]"

Content-Type: text/plain
Content-ID:	<[e-mail]>

ENCODING mime
FILE /internet-drafts/draft-ietf-pkix-ipki-pkalgs-05.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-pkix-ipki-pkalgs-05.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:	<[e-mail]>

--OtherAccess--

--NextPart--




Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id f9PJu6c28799 for ietf-pkix-bks; Thu, 25 Oct 2001 12:56:06 -0700 (PDT)
Received: from apollon.greg.rim.or.jp ([e-mail] [61.121.89.152]) by above.proper.com (8.11.6/8.11.3) with ESMTP id f9PJu4828790 for <[e-mail]>; Thu, 25 Oct 2001 12:56:05 -0700 (PDT)
Received: (from news@localhost) by apollon.greg.rim.or.jp (8.11.3/3.7W) id f9PJfCg63992 for [e-mail]; Fri, 26 Oct 2001 04:41:12 +0900 (JST)
From: [e-mail] (Denis Pinkas)
X-Newsgroups: greg.ml.ietf-pkix
Subject: Re: draft-ietf-pkix-dsv-dpv-dpd-req-00.txt
Date: Thu, 25 Oct 2001 19:41:10 +0000 (UTC)
Organization: Integris. A Bull Company
Lines: 121
Distribution: greg
Message-ID: <[e-mail]>
References: <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
X-Complaints-To: [e-mail]
X-Received: (from uucp@localhost) by apollon.greg.rim.or.jp (8.11.3/3.7W) with UUCP id f9PJf8f63983 for [e-mail]; Fri, 26 Oct 2001 04:41:08 +0900 (JST)
X-Received: from above.proper.com (above.proper.com [208.184.76.39]) by rayearth.rim.or.jp (8.8.8/3.5Wpl2-uucp1/RIMNET) with ESMTP id EAA23448 for <[e-mail]>; Fri, 26 Oct 2001 04:33:17 +0900 (JST)
X-Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id f9PGuRb21220 for ietf-pkix-bks; Thu, 25 Oct 2001 09:56:27 -0700 (PDT)
X-Received: from odin2.bull.net (odin2.bull.net [192.90.70.84]) by above.proper.com (8.11.6/8.11.3) with ESMTP id f9PGuQ821216 for <[e-mail]>; Thu, 25 Oct 2001 09:56:26 -0700 (PDT)
X-Received: from lvt-mail.frlv.bull.fr (lvt-mail.frlv.bull.fr [129.184.62.223]) by odin2.bull.net (8.9.3/8.9.3) with ESMTP id SAA35652; Thu, 25 Oct 2001 18:59:17 +0200
X-Received: from bull.net (frlva3786.frlv.bull.fr [129.184.37.97]) by lvt-mail.frlv.bull.fr (8.9.2/8.9.1) with ESMTP id SAA14862; Thu, 25 Oct 2001 18:55:52 +0200
X-Mailer: Mozilla 4.7 [fr] (Win98; I)
X-Accept-Language: fr
X-To: "Housley, Russ" <[e-mail]>
X-CC: [e-mail]
X-Precedence: bulk
X-List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
X-List-ID: <ietf-pkix.imc.org>
X-List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
X-List-ID: <ietf-pkix.imc.org>
To: [e-mail]
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-pkix.imc.org>

Russ,

Thank you for your detailed review and comments.

> Denis:
 
> Thank you for putting together this document.  I really appreciate your
> efforts to progress the DPV and DPD standards development.  Of course, I
> have several comments.  I have divided them into MAJOR concerns, MINOR
> concerns, and EDITORIAL comments.
 
> MAJOR
 
> Please remove the signature policy material.  I believe that this should be
> handled separately, if at all.  I do not want discussions of this new topic
> to further delay DPV and DPD.  If the signature topic has a constituency,
> it may not be the same as that of DPV/DPD.

RFC 3029, i.e. Data Validation and Certification Server Protocols (DVCS)
makes the difference between:

   - Validation of Digitally Signed Document (vsd), and
   - Validation of Public Key Certificates (vpkc).

  ... and I believe that this is fine.
 
Validation of Digitally Signed Documents is required in the context of a
non-repudiation service and requires either the use of Time-stamp tokens or
of Time-marks.

Validation of Public Key Certificates is fine for real-time use only, but
not for non repudiation purposes, otherwise clients would not be "thin" and
would have to do more processing.
 
Instead of removing this material, I believe that additional explanations
should be given in the document.

> Please review your use of "shall."  I believe that it should be changed to
> "MUST" or "SHALL" in every case.  Similarly, there are several cases where
> "may" ought to be changed to "MAY."

You are quite right. I will make that review.
 
> In section 3, the assertion that "client ... policy definition may be quite
> complex and only simple forms of policies can be defined in this way" needs
> clarification and justification.  What sorts of elements are anticipated
> within the policy definitions?  What will fall within the
> standard-supported scope as opposed to a server-side local matter?  I would
> strive for an approach that minimizes (or eliminates) the latter.

You are right. It is hard to draw a line. Instead of saying exactly what
falls inside and outside the line, I have attempted to characterize the way
the limit should be drawn:

"Alternatively, clients may also define policies. However, such policy
definition may be quite complex and only simple forms of policies should be
defined in this way, otherwise testing all the possible variations would
lead to non-interoperable implementations or would delay the time to make
sure that two implementations are really interoperable."
 
> MINOR
 
> In section 5, the client may want the path and related revocation
> information returned for archive purposes.  Please make this an option.

The client always wan the path and the related revocation information
returned, so it is not necessary to say why. It is primarly not for
archiving purposes but for real time use. Nevertheless, if you really want
this to be mentioned, please make a proposal for an insertion.
 
> In section 7.2, should a DPV response from another server be considered as
> another candidate source of revocation status information?

I do not think so. The two only sources of information are CRLs (including
delta-CRLs) and OCSP responses.

> In section 10, first paragraph, I do not understand the reference to "its
> dual."  Please clarify.

The support of these is request/response pairs is optional. These
request/response pairs allow either to define a policy, i.e. a signature
policy, a validation policy and/or a path discovery policy, and to receive
back a reference for that policy or to provide a reference to a previously
defined policy and to receive back the definition of that policy.
 
> EDITORIAL
> 
> Please introduce the term "path."  At a minimum, the first use should be
> "certification path" and reference [PKIX-1].

In section 2.2. I will add:

In order to validate a certificate, a chain of multiple certificates, called
a certification path, may be needed, comprising a certificate of the public
key owner (the end entity) signed by one CA, and zero or more additional
certificates of CAs signed by other CAs.

> Please change "certificate path" to "certification path" everywhere that it
> occurs (mostly at the end of the document).

Done.

> In section 5, please change "copy and paste" to "provide."

Done in section 5 as well.
 
> In section 5, please change "additional protocol" to "additional protocol
> exchange."

Done.

> In section 6, last paragraph, please change "client will only require" to
> "client MAY require."

Done.

Denis

> Russ



Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id f9PGuRb21220 for ietf-pkix-bks; Thu, 25 Oct 2001 09:56:27 -0700 (PDT)
Received: from odin2.bull.net (odin2.bull.net [192.90.70.84]) by above.proper.com (8.11.6/8.11.3) with ESMTP id f9PGuQ821216 for <[e-mail]>; Thu, 25 Oct 2001 09:56:26 -0700 (PDT)
Received: from lvt-mail.frlv.bull.fr (lvt-mail.frlv.bull.fr [129.184.62.223]) by odin2.bull.net (8.9.3/8.9.3) with ESMTP id SAA35652; Thu, 25 Oct 2001 18:59:17 +0200
Received: from bull.net (frlva3786.frlv.bull.fr [129.184.37.97]) by lvt-mail.frlv.bull.fr (8.9.2/8.9.1) with ESMTP id SAA14862; Thu, 25 Oct 2001 18:55:52 +0200
Message-ID: <[e-mail]>
Date: Thu, 25 Oct 2001 18:55:54 +0200
From: Denis Pinkas <[e-mail]>
Organization: Integris. A Bull Company
X-Mailer: Mozilla 4.7 [fr] (Win98; I)
X-Accept-Language: fr
MIME-Version: 1.0
To: "Housley, Russ" <[e-mail]>
CC: [e-mail]
Subject: Re: draft-ietf-pkix-dsv-dpv-dpd-req-00.txt
References: <[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-pkix.imc.org>

Russ,

Thank you for your detailed review and comments.

> Denis:
 
> Thank you for putting together this document.  I really appreciate your
> efforts to progress the DPV and DPD standards development.  Of course, I
> have several comments.  I have divided them into MAJOR concerns, MINOR
> concerns, and EDITORIAL comments.
 
> MAJOR
 
> Please remove the signature policy material.  I believe that this should be
> handled separately, if at all.  I do not want discussions of this new topic
> to further delay DPV and DPD.  If the signature topic has a constituency,
> it may not be the same as that of DPV/DPD.

RFC 3029, i.e. Data Validation and Certification Server Protocols (DVCS)
makes the difference between:

   - Validation of Digitally Signed Document (vsd), and
   - Validation of Public Key Certificates (vpkc).

  ... and I believe that this is fine.
 
Validation of Digitally Signed Documents is required in the context of a
non-repudiation service and requires either the use of Time-stamp tokens or
of Time-marks.

Validation of Public Key Certificates is fine for real-time use only, but
not for non repudiation purposes, otherwise clients would not be "thin" and
would have to do more processing.
 
Instead of removing this material, I believe that additional explanations
should be given in the document.

> Please review your use of "shall."  I believe that it should be changed to
> "MUST" or "SHALL" in every case.  Similarly, there are several cases where
> "may" ought to be changed to "MAY."

You are quite right. I will make that review.
 
> In section 3, the assertion that "client ... policy definition may be quite
> complex and only simple forms of policies can be defined in this way" needs
> clarification and justification.  What sorts of elements are anticipated
> within the policy definitions?  What will fall within the
> standard-supported scope as opposed to a server-side local matter?  I would
> strive for an approach that minimizes (or eliminates) the latter.

You are right. It is hard to draw a line. Instead of saying exactly what
falls inside and outside the line, I have attempted to characterize the way
the limit should be drawn:

"Alternatively, clients may also define policies. However, such policy
definition may be quite complex and only simple forms of policies should be
defined in this way, otherwise testing all the possible variations would
lead to non-interoperable implementations or would delay the time to make
sure that two implementations are really interoperable."
 
> MINOR
 
> In section 5, the client may want the path and related revocation
> information returned for archive purposes.  Please make this an option.

The client always wan the path and the related revocation information
returned, so it is not necessary to say why. It is primarly not for
archiving purposes but for real time use. Nevertheless, if you really want
this to be mentioned, please make a proposal for an insertion.
 
> In section 7.2, should a DPV response from another server be considered as
> another candidate source of revocation status information?

I do not think so. The two only sources of information are CRLs (including
delta-CRLs) and OCSP responses.

> In section 10, first paragraph, I do not understand the reference to "its
> dual."  Please clarify.

The support of these is request/response pairs is optional. These
request/response pairs allow either to define a policy, i.e. a signature
policy, a validation policy and/or a path discovery policy, and to receive
back a reference for that policy or to provide a reference to a previously
defined policy and to receive back the definition of that policy.
 
> EDITORIAL
> 
> Please introduce the term "path."  At a minimum, the first use should be
> "certification path" and reference [PKIX-1].

In section 2.2. I will add:

In order to validate a certificate, a chain of multiple certificates, called
a certification path, may be needed, comprising a certificate of the public
key owner (the end entity) signed by one CA, and zero or more additional
certificates of CAs signed by other CAs.

> Please change "certificate path" to "certification path" everywhere that it
> occurs (mostly at the end of the document).

Done.

> In section 5, please change "copy and paste" to "provide."

Done in section 5 as well.
 
> In section 5, please change "additional protocol" to "additional protocol
> exchange."

Done.

> In section 6, last paragraph, please change "client will only require" to
> "client MAY require."

Done.

Denis

> Russ


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id f9OKQAm13721 for ietf-pkix-bks; Wed, 24 Oct 2001 13:26:10 -0700 (PDT)
Received: from apollon.greg.rim.or.jp ([e-mail] [61.121.89.152]) by above.proper.com (8.11.6/8.11.3) with ESMTP id f9OKQ8813716 for <[e-mail]>; Wed, 24 Oct 2001 13:26:08 -0700 (PDT)
Received: (from news@localhost) by apollon.greg.rim.or.jp (8.11.3/3.7W) id f9OKLHr76234 for [e-mail]; Thu, 25 Oct 2001 05:21:17 +0900 (JST)
From: [e-mail] ("Housley, Russ")
X-Newsgroups: greg.ml.ietf-pkix
Subject: draft-ietf-pkix-dsv-dpv-dpd-req-00.txt
Date: Wed, 24 Oct 2001 20:21:14 +0000 (UTC)
Organization: Greg's Private Site
Lines: 55
Distribution: greg
Message-ID: <[e-mail]>
References: <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
X-Complaints-To: [e-mail]
X-Received: (from uucp@localhost) by apollon.greg.rim.or.jp (8.11.3/3.7W) with UUCP id f9OKL8676225 for [e-mail]; Thu, 25 Oct 2001 05:21:08 +0900 (JST)
X-Received: from above.proper.com (above.proper.com [208.184.76.39]) by rayearth.rim.or.jp (8.8.8/3.5Wpl2-uucp1/RIMNET) with ESMTP id FAA16985 for <[e-mail]>; Thu, 25 Oct 2001 05:13:01 +0900 (JST)
X-Received: by above.proper.com (8.11.6/8.11.3) id f9OH9ZS04483 for ietf-pkix-bks; Wed, 24 Oct 2001 10:09:35 -0700 (PDT)
X-Received: from tholian.securitydynamics.com (mail.rsasecurity.com [204.167.112.129]) by above.proper.com (8.11.6/8.11.3) with SMTP id f9OH9X804477 for <[e-mail]>; Wed, 24 Oct 2001 10:09:33 -0700 (PDT)
X-Received: from sdtihq24.securid.com by tholian.securitydynamics.com via smtpd (for mail.imc.org [208.184.76.43]) with SMTP; 24 Oct 2001 17:06:06 UT
X-Received: from ebola.securitydynamics.com (ebola.securid.com [192.168.7.4]) by sdtihq24.securid.com (Pro-8.9.3/Pro-8.9.3) with ESMTP id NAA29094 for <[e-mail]>; Wed, 24 Oct 2001 13:09:25 -0400 (EDT)
X-Received: from exno02.dynas.se (localhost [127.0.0.1]) by ebola.securitydynamics.com (8.9.3+Sun/8.9.1) with ESMTP id NAA07687 for <[e-mail]>; Wed, 24 Oct 2001 13:09:22 -0400 (EDT)
X-Received: by exno02.dynas.se with Internet Mail Service (5.5.2653.19) id <4WCBZ9H5>; Wed, 24 Oct 2001 19:09:08 +0200
X-Received: from HOUSLEY-LAP.rsasecurity.com (housley-lap.securitydynamics.com [10.100.23.218]) by exna00.securitydynamics.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id T1DQ7B2Y; Wed, 24 Oct 2001 13:09:05 -0400
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Version 5.0.1
X-To: [e-mail]
X-In-Reply-To: <[e-mail]>
X-Precedence: bulk
X-List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
X-List-ID: <ietf-pkix.imc.org>
X-List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
X-List-ID: <ietf-pkix.imc.org>
To: [e-mail]
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-pkix.imc.org>

Denis:

Thank you for putting together this document.  I really appreciate your 
efforts to progress the DPV and DPD standards development.  Of course, I 
have several comments.  I have divided them into MAJOR concerns, MINOR 
concerns, and EDITORIAL comments.

MAJOR

Please remove the signature policy material.  I believe that this should be 
handled separately, if at all.  I do not want discussions of this new topic 
to further delay DPV and DPD.  If the signature topic has a constituency, 
it may not be the same as that of DPV/DPD.

Please review your use of "shall."  I believe that it should be changed to 
"MUST" or "SHALL" in every case.  Similarly, there are several cases where 
"may" ought to be changed to "MAY."

In section 3, the assertion that "client ... policy definition may be quite 
complex and only simple forms of policies can be defined in this way" needs 
clarification and justification.  What sorts of elements are anticipated 
within the policy definitions?  What will fall within the 
standard-supported scope as opposed to a server-side local matter?  I would 
strive for an approach that minimizes (or eliminates) the latter.

MINOR

In section 5, the client may want the path and related revocation 
information returned for archive purposes.  Please make this an option.

In section 7.2, should a DPV response from another server be considered as 
another candidate source of revocation status information?

In section 10, first paragraph, I do not understand the reference to "its 
dual."  Please clarify.

EDITORIAL

Please introduce the term "path."  At a minimum, the first use should be 
"certification path" and reference [PKIX-1].

Please change "certificate path" to "certification path" everywhere that it 
occurs (mostly at the end of the document).

In section 5, please change "copy and paste" to "provide."

In section 5, please change "additional protocol" to "additional protocol 
exchange."

In section 6, last paragraph, please change "client will only require" to 
"client MAY require."

Russ



Received: by above.proper.com (8.11.6/8.11.3) id f9OH9ZS04483 for ietf-pkix-bks; Wed, 24 Oct 2001 10:09:35 -0700 (PDT)
Received: from tholian.securitydynamics.com (mail.rsasecurity.com [204.167.112.129]) by above.proper.com (8.11.6/8.11.3) with SMTP id f9OH9X804477 for <[e-mail]>; Wed, 24 Oct 2001 10:09:33 -0700 (PDT)
Received: from sdtihq24.securid.com by tholian.securitydynamics.com via smtpd (for mail.imc.org [208.184.76.43]) with SMTP; 24 Oct 2001 17:06:06 UT
Received: from ebola.securitydynamics.com (ebola.securid.com [192.168.7.4]) by sdtihq24.securid.com (Pro-8.9.3/Pro-8.9.3) with ESMTP id NAA29094 for <[e-mail]>; Wed, 24 Oct 2001 13:09:25 -0400 (EDT)
Received: from exno02.dynas.se (localhost [127.0.0.1]) by ebola.securitydynamics.com (8.9.3+Sun/8.9.1) with ESMTP id NAA07687 for <[e-mail]>; Wed, 24 Oct 2001 13:09:22 -0400 (EDT)
Received: by exno02.dynas.se with Internet Mail Service (5.5.2653.19) id <4WCBZ9H5>; Wed, 24 Oct 2001 19:09:08 +0200
Received: from HOUSLEY-LAP.rsasecurity.com (housley-lap.securitydynamics.com [10.100.23.218]) by exna00.securitydynamics.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id T1DQ7B2Y; Wed, 24 Oct 2001 13:09:05 -0400
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Version 5.0.1
Date: Wed, 24 Oct 2001 09:01:24 -0400
To: [e-mail]
From: "Housley, Russ" <[e-mail]>
Subject: draft-ietf-pkix-dsv-dpv-dpd-req-00.txt
In-Reply-To: <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-pkix.imc.org>

Denis:

Thank you for putting together this document.  I really appreciate your 
efforts to progress the DPV and DPD standards development.  Of course, I 
have several comments.  I have divided them into MAJOR concerns, MINOR 
concerns, and EDITORIAL comments.

MAJOR

Please remove the signature policy material.  I believe that this should be 
handled separately, if at all.  I do not want discussions of this new topic 
to further delay DPV and DPD.  If the signature topic has a constituency, 
it may not be the same as that of DPV/DPD.

Please review your use of "shall."  I believe that it should be changed to 
"MUST" or "SHALL" in every case.  Similarly, there are several cases where 
"may" ought to be changed to "MAY."

In section 3, the assertion that "client ... policy definition may be quite 
complex and only simple forms of policies can be defined in this way" needs 
clarification and justification.  What sorts of elements are anticipated 
within the policy definitions?  What will fall within the 
standard-supported scope as opposed to a server-side local matter?  I would 
strive for an approach that minimizes (or eliminates) the latter.

MINOR

In section 5, the client may want the path and related revocation 
information returned for archive purposes.  Please make this an option.

In section 7.2, should a DPV response from another server be considered as 
another candidate source of revocation status information?

In section 10, first paragraph, I do not understand the reference to "its 
dual."  Please clarify.

EDITORIAL

Please introduce the term "path."  At a minimum, the first use should be 
"certification path" and reference [PKIX-1].

Please change "certificate path" to "certification path" everywhere that it 
occurs (mostly at the end of the document).

In section 5, please change "copy and paste" to "provide."

In section 5, please change "additional protocol" to "additional protocol 
exchange."

In section 6, last paragraph, please change "client will only require" to 
"client MAY require."

Russ


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id f9MFCgM17692 for ietf-pkix-bks; Mon, 22 Oct 2001 08:12:42 -0700 (PDT)
Received: from SOTTMXS01.entrust.com ([216.191.251.35]) by above.proper.com (8.11.6/8.11.3) with ESMTP id f9MFCd817683 for <[e-mail]>; Mon, 22 Oct 2001 08:12:40 -0700 (PDT)
Received: by SOTTMXS01.entrust.com with Internet Mail Service (5.5.2653.19) id <VNB4WB3N>; Mon, 22 Oct 2001 11:12:35 -0400
Message-ID: <[e-mail]>
From: Santosh Chokhani <[e-mail]>
To: "Housley, Russ" <[e-mail]>, Santosh Chokhani <[e-mail]>
Cc: [e-mail]
Subject: RE: AW: I-D ACTION:draft-ietf-pkix-new-part1-09.txt
Date: Mon, 22 Oct 2001 11:13:23 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C15B0C.17ABE140"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-pkix.imc.org>

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01C15B0C.17ABE140
Content-Type: text/plain

Agreed.

-----Original Message-----
From: Housley, Russ [mailto:[e-mail]]
Sent: Monday, October 22, 2001 11:07 AM
To: Santosh Chokhani
Cc: [e-mail]
Subject: RE: AW: I-D ACTION:draft-ietf-pkix-new-part1-09.txt


Santosh:

I would prefer to be silent.  The collection of certificates stored in this
attribute should assist in path construction.  I do not think anything more
is needed.

Russ


At 09:41 AM 10/22/2001 -0400, Santosh Chokhani wrote:


Russ:
 
In that case, would we ask for the component explicitly, provide a rule that
if the DN = issuer DN, it must be (or likely to be) issuedToThisCA component
and if the DN do not match, it must be (or likely to be) issuedByThisCA
component.
 
Alternatively, we could be silent on the matter. 


-----Original Message----- 

From: Housley, Russ [ mailto:[e-mail]
<mailto:[e-mail]> ] 

Sent: Monday, October 22, 2001 9:20 AM 

To: Sharon Boeyen 

Cc: Santosh Chokhani; [e-mail] 

Subject: RE: AW: I-D ACTION:draft-ietf-pkix-new-part1-09.txt



Sharon:



You convinced me that we want the DN to imply the crossCertificatePair
attribute.



Russ





At 04:18 PM 10/19/2001 -0400, Sharon Boeyen wrote: 



Santosh is right about the schemas. There have been at least 3 defect
reports against X.509 in this area over the past 2-3 years. 509 and PKIX
LDAP schema 

both aligned in this area with the very first defect report (DR 185) . Also
with DR 257, also approved, we no longer have "forward" and "reverse" but
rather "issuedToThisCA and "issuedByThisCA". All certs issued to a CA,
except self-issued certs, shall be stored in the issuedToThisCA element of
the crossCertificatePair. In addition to that, certificates issued to the
same CA, that were issued by other CAs in the same realm (where definition
of realm is a local policy matter) are ALSO stored in caCertificates
attribute. There are NO inbound certificates for a CA, that can be stored in
caCertificates without also being stored in crossCertificatePair. Since the
issuers of the certificates you are discussing may/may not be in the same
"realm" the certs would need to at least go into the crossCertificatePair
attribute and could also be present in the caCertificates attribute if
issued by a CA in ! the same realm. 



Wouldn't it be nice if we had a clean sheet - one attribute for self-issued
certs, one attribute for certs "issued by this CA" and one attribute for
certs "issued to this CA" - unfortunately we don't have that luxury. 



Oh yes, just for completeness on the crossCertificatePair attribute, don't
forget the recent approved defect (256) that requires all certificates
issued BY a CA to other CAs to be stored in the "issuedByThisCA" component
of the crossCertificatePair attribute, except certificates issued to a
subordinate CA by its superior CA in a hierarchy. 



Cheers, 



Sharon 



 -----Original Message----- 

From: Santosh Chokhani [ mailto:[e-mail]
<mailto:[e-mail]> ] 

Sent: Friday, October 19, 2001 11:25 AM 

To: Housley, Russ; Santosh Chokhani 

Cc: [e-mail] 

Subject: RE: AW: I-D ACTION:draft-ietf-pkix-new-part1-09.txt 

Russ: 



I agree with you that you understand my concern.  I also do not have
objection to using caCertificate attribute.  Actually, I prefer that. 

However, it may break ldap v3 schema.  It seems that ldap states that all
certificates must be published in crossCertificatePair attribute and ONLY
the domain certificates appear in caCertificate attribute. 

-----Original Message----- 

From: Housley, Russ [ mailto:[e-mail]
<mailto:[e-mail]> ] 

Sent: Friday, October 19, 2001 10:28 AM 

To: Santosh Chokhani 

Cc: [e-mail] 

Subject: RE: AW: I-D ACTION:draft-ietf-pkix-new-part1-09.txt 

Santosh: 



>I am ok with what you wrote for the URI.  My question relates to when the 

>DN is specified as the caIssuers.  We need either a mandate that a 

>particular attribute (caCertificate, crossCertificatePair) will be used or 

>we need the syntax to permit to specify either one of the attributes. 

> 

>Also, we as a community need to decide, for crossCertiifcatePair) whether 

>the client will have to determine the element or will the pointer specify 

>the element, i.e., forward or reverse. 



I am sorry that I misunderstood your original point.  Let me make sure that 

I got it right this time. 



The accessMethod is a GeneralName.  When the GeneralName has the form of a 

URI, you are happy with the LDAP situation described in RFC 2255.  However, 

when the GeneralName has the form of an X.500 Distinguished Name, you are 

still unhappy because the text does not say which directory attribute is 

expected to be populated.  You have proposed two alternatives: 

caCertificate and crossCertificatePair.  Both of these attributes can hold 

more than one value. 



My preference would be caCertificate.  Does anyone have an issue with this 

approach? 



Russ 


------_=_NextPart_001_01C15B0C.17ABE140
Content-Type: text/html

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=US-ASCII">


<META content="MSHTML 5.50.4522.1800" name=GENERATOR></HEAD>
<BODY>
<DIV><SPAN class=752321315-22102001><FONT face=Arial color=#0000ff 
size=2>Agreed.</FONT></SPAN></DIV>
<BLOCKQUOTE dir=ltr style="MARGIN-RIGHT: 0px">
  <DIV class=OutlookMessageHeader dir=ltr align=left><FONT face=Tahoma 
  size=2>-----Original Message-----<BR><B>From:</B> Housley, Russ 
  [mailto:[e-mail]]<BR><B>Sent:</B> Monday, October 22, 2001 
  11:07 AM<BR><B>To:</B> Santosh Chokhani<BR><B>Cc:</B> 
  [e-mail]<BR><B>Subject:</B> RE: AW: I-D 
  ACTION:draft-ietf-pkix-new-part1-09.txt<BR><BR></FONT></DIV>Santosh:<BR><BR>I 
  would prefer to be silent.&nbsp; The collection of certificates stored in this 
  attribute should assist in path construction.&nbsp; I do not think anything 
  more is needed.<BR><BR>Russ<BR><BR><BR>At 09:41 AM 10/22/2001 -0400, Santosh 
  Chokhani wrote:<BR>
  <BLOCKQUOTE class=cite cite type="cite"><FONT face=arial color=#0000ff 
    size=2>Russ:</FONT><BR>&nbsp;<BR><FONT face=arial color=#0000ff size=2>In 
    that case, would we ask for the component explicitly, provide a rule that if 
    the DN = issuer DN, it must be (or likely to be) issuedToThisCA component 
    and if the DN do not match, it must be (or likely to be) issuedByThisCA 
    component.</FONT><BR>&nbsp;<BR><FONT face=arial color=#0000ff 
    size=2>Alternatively, we could be silent on the matter.</FONT> 
    <DL><FONT face=tahoma size=2>
      <DD>-----Original Message----- 
      <DD>From:</B> Housley, Russ [<A href="mailto:[e-mail]" 
      eudora="autourl">mailto:[e-mail]</A>] 
      <DD>Sent:</B> Monday, October 22, 2001 9:20 AM 
      <DD>To:</B> Sharon Boeyen 
      <DD>Cc:</B> Santosh Chokhani; [e-mail] 
      <DD>Subject:</B> RE: AW: I-D 
      ACTION:draft-ietf-pkix-new-part1-09.txt<BR><BR></FONT>
      <DD>Sharon:<BR><BR>
      <DD>You convinced me that we want the DN to imply the <FONT face=arial 
      size=2>crossCertificatePair</FONT><FONT face=arial> 
      attribute.<BR><BR></FONT>
      <DD>Russ<BR><BR><BR><BR>
      <DD>At 04:18 PM 10/19/2001 -0400, Sharon Boeyen wrote:
      <BLOCKQUOTE class=cite cite type="cite"><FONT face=arial color=#0000ff 
        size=2>
        <DD>Santosh is right about the schemas. There have been at least 3 
        defect reports against X.509 in this area over the past 2-3 years. 509 
        and PKIX LDAP schema </FONT><FONT face=arial color=#0000ff size=2>
        <DD>both aligned in this area with the very first defect report (DR 185) 
        . Also with DR 257, also approved, we no longer have "forward" and 
        "reverse" but rather "issuedToThisCA and "issuedByThisCA". All certs 
        issued to a CA, except self-issued certs, shall be stored in the 
        issuedToThisCA element of the crossCertificatePair. In addition to that, 
        certificates issued to the same CA, that were issued by other CAs in the 
        same realm (where definition of realm is a local policy matter) are ALSO 
        stored in caCertificates attribute. There are NO inbound certificates 
        for a CA, that can be stored in caCertificates without also being stored 
        in crossCertificatePair. Since the issuers of the certificates you are 
        discussing may/may not be in the same "realm" the certs would need to at 
        least go into the crossCertificatePair attribute and could also be 
        present in the caCertificates attribute if issued by a CA in ! the same 
        realm.</FONT> 
        <DD><FONT face=arial color=#0000ff size=2> 
        <DD>Wouldn't it be nice if we had a clean sheet - one attribute for 
        self-issued certs, one attribute for certs "issued by this CA" and one 
        attribute for certs "issued to this CA" - unfortunately we don't have 
        that luxury.</FONT> 
        <DD><FONT face=arial color=#0000ff size=2> 
        <DD>Oh yes, just for completeness on the crossCertificatePair attribute, 
        don't forget the recent approved defect (256) that requires all 
        certificates issued BY a CA to other CAs to be stored in the 
        "issuedByThisCA" component of the crossCertificatePair attribute, except 
        certificates issued to a subordinate CA by its superior CA in a 
        hierarchy.</FONT> 
        <DD><FONT face=arial color=#0000ff size=2> 
        <DD>Cheers,</FONT> 
        <DD><FONT face=arial color=#0000ff size=2> 
        <DD>Sharon</FONT><FONT face=arial color=#0000ff size=2> 
        <DD></FONT><FONT face=tahoma size=2> 
        <DD>&nbsp;-----Original Message----- 
        <DD>From:</B> Santosh Chokhani [<A href="mailto:[e-mail]" 
        eudora="autourl">mailto:[e-mail]</A>] 
        <DD>Sent:</B> Friday, October 19, 2001 11:25 AM 
        <DD>To:</B> Housley, Russ; Santosh Chokhani 
        <DD>Cc:</B> [e-mail] 
        <DD>Subject:</B> RE: AW: I-D 
        ACTION:draft-ietf-pkix-new-part1-09.txt</FONT> 
        <DD>Russ: <BR><BR><FONT size=2>
        <DD>I agree with you that you understand my concern.&nbsp; I also do not 
        have objection to using caCertificate attribute.&nbsp; Actually, I 
        prefer that. 
        <DD>However, it may break ldap v3 schema.&nbsp; It seems that ldap 
        states that all certificates must be published in crossCertificatePair 
        attribute and ONLY the domain certificates appear in caCertificate 
        attribute. 
        <DD>-----Original Message-----</FONT> <FONT size=2>
        <DD>From: Housley, Russ [<A 
        href="mailto:[e-mail]">mailto:[e-mail]</A>]</FONT> 
        <FONT size=2>
        <DD>Sent: Friday, October 19, 2001 10:28 AM</FONT> <FONT size=2>
        <DD>To: Santosh Chokhani</FONT> <FONT size=2>
        <DD>Cc: [e-mail]</FONT> <FONT size=2>
        <DD>Subject: RE: AW: I-D ACTION:draft-ietf-pkix-new-part1-09.txt</FONT> 
        <FONT size=2>
        <DD>Santosh:</FONT> <BR><BR><FONT size=2>
        <DD>&gt;I am ok with what you wrote for the URI.&nbsp; My question 
        relates to when the 
        <DD>&gt;DN is specified as the caIssuers.&nbsp; We need either a mandate 
        that a 
        <DD>&gt;particular attribute (caCertificate, crossCertificatePair) will 
        be used or 
        <DD>&gt;we need the syntax to permit to specify either one of the 
        attributes.</FONT> <FONT size=2>
        <DD>&gt;</FONT> <FONT size=2>
        <DD>&gt;Also, we as a community need to decide, for 
        crossCertiifcatePair) whether 
        <DD>&gt;the client will have to determine the element or will the 
        pointer specify 
        <DD>&gt;the element, i.e., forward or reverse.</FONT> <BR><BR><FONT 
        size=2>
        <DD>I am sorry that I misunderstood your original point.&nbsp; Let me 
        make sure that 
        <DD>I got it right this time.</FONT> <BR><BR><FONT size=2>
        <DD>The accessMethod is a GeneralName.&nbsp; When the GeneralName has 
        the form of a 
        <DD>URI, you are happy with the LDAP situation described in RFC 
        2255.&nbsp; However, 
        <DD>when the GeneralName has the form of an X.500 Distinguished Name, 
        you are 
        <DD>still unhappy because the text does not say which directory 
        attribute is 
        <DD>expected to be populated.&nbsp; You have proposed two alternatives: 
        <DD>caCertificate and crossCertificatePair.&nbsp; Both of these 
        attributes can hold 
        <DD>more than one value.</FONT> <BR><BR><FONT size=2>
        <DD>My preference would be caCertificate.&nbsp; Does anyone have an 
        issue with this 
        <DD>approach?</FONT> <BR><BR><FONT size=2>
        <DD>Russ</FONT> </DD></BLOCKQUOTE></DD></DL></BLOCKQUOTE>
  <BLOCKQUOTE></BLOCKQUOTE></BLOCKQUOTE></BODY></HTML>

------_=_NextPart_001_01C15B0C.17ABE140--


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id f9MF8tR17012 for ietf-pkix-bks; Mon, 22 Oct 2001 08:08:55 -0700 (PDT)
Received: from tholian.securitydynamics.com (mail.rsasecurity.com [204.167.112.129]) by above.proper.com (8.11.6/8.11.3) with SMTP id f9MF8r817003 for <[e-mail]>; Mon, 22 Oct 2001 08:08:53 -0700 (PDT)
Received: from sdtihq24.securitydynamics.com by tholian.securitydynamics.com via smtpd (for mail.imc.org [208.184.76.43]) with SMTP; 22 Oct 2001 15:05:28 UT
Received: from ebola.securitydynamics.com (ebola.securid.com [192.168.7.4]) by sdtihq24.securid.com (Pro-8.9.3/Pro-8.9.3) with ESMTP id LAA04347 for <[e-mail]>; Mon, 22 Oct 2001 11:08:54 -0400 (EDT)
Received: from exna00.securitydynamics.com (localhost [127.0.0.1]) by ebola.securitydynamics.com (8.9.3+Sun/8.9.1) with ESMTP id LAA22967 for <[e-mail]>; Mon, 22 Oct 2001 11:08:53 -0400 (EDT)
Received: by exna00.securitydynamics.com with Internet Mail Service (5.5.2653.19) id <T1DQ6BW3>; Mon, 22 Oct 2001 11:08:44 -0400
Received: from HOUSLEY-LAP.rsasecurity.com (HOUSLEY-LAP [10.3.1.59]) by exna00.securitydynamics.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id T1DQ6BWJ; Mon, 22 Oct 2001 11:08:38 -0400
From: "Housley, Russ" <[e-mail]>
To: Santosh Chokhani <[e-mail]>
Cc: [e-mail]
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Version 5.0.1
Date: Mon, 22 Oct 2001 11:06:44 -0400
Subject: RE: AW: I-D ACTION:draft-ietf-pkix-new-part1-09.txt
In-Reply-To: <[e-mail]. com>
Mime-Version: 1.0
Content-Type: text/html; charset="us-ascii"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-pkix.imc.org>

<html>
Santosh:<br>
<br>
I would prefer to be silent.&nbsp; The collection of certificates stored
in this attribute should assist in path construction.&nbsp; I do not
think anything more is needed.<br>
<br>
Russ<br>
<br>
<br>
At 09:41 AM 10/22/2001 -0400, Santosh Chokhani wrote:<br>
<blockquote type=cite class=cite cite><font face="arial" size=2 color="#0000FF">Russ:</font><br>
&nbsp;<br>
<font face="arial" size=2 color="#0000FF">In that case, would we ask for
the component explicitly, provide a rule that if the DN = issuer DN, it
must be (or likely to be) issuedToThisCA component and if the DN do not
match, it must be (or likely to be) issuedByThisCA 
component.</font><br>
&nbsp;<br>
<font face="arial" size=2 color="#0000FF">Alternatively, we could be
silent on the matter.</font>
<dl><font face="tahoma" size=2>
<dd>-----Original Message-----
<dd>From:</b> Housley, Russ
[<a href="mailto:[e-mail]" eudora="autourl">mailto:[e-mail]</a>]
<dd>Sent:</b> Monday, October 22, 2001 9:20 AM
<dd>To:</b> Sharon Boeyen
<dd>Cc:</b> Santosh Chokhani; [e-mail]
<dd>Subject:</b> RE: AW: I-D 
ACTION:draft-ietf-pkix-new-part1-09.txt<br>
<br>
</font>
<dd>Sharon:<br>
<br>

<dd>You convinced me that we want the DN to imply the
<font face="arial" size=2>crossCertificatePair</font><font face="arial">
attribute.<br>
<br>
</font>
<dd>Russ<br>
<br>
<br>
<br>

<dd>At 04:18 PM 10/19/2001 -0400, Sharon Boeyen wrote:<blockquote type=cite class=cite cite><font face="arial" size=2 color="#0000FF">
<dd>Santosh is right about the schemas. There have been at least 3 defect reports against X.509 in this area over the past 2-3 years. 509 and PKIX LDAP schema </font><font face="arial" size=2 color="#0000FF">
<dd>both aligned in this area with the very first defect report (DR 185) . Also with DR 257, also approved, we no longer have &quot;forward&quot; and &quot;reverse&quot; but rather &quot;issuedToThisCA and &quot;issuedByThisCA&quot;. All certs issued to a CA, except self-issued certs, shall be stored in the issuedToThisCA element of the crossCertificatePair. In addition to that, certificates issued to the same CA, that were issued by other CAs in the same realm (where definition of realm is a local policy matter) are ALSO stored in caCertificates attribute. There are NO inbound certificates for a CA, that can be stored in caCertificates without also being stored in crossCertificatePair. Since the issuers of the certificates you are discussing may/may not be in the same &quot;realm&quot; the certs would need to at least go into the crossCertificatePair attribute and could also be present in the caCertificates attribute if issued by a CA in ! the same realm.</font>
<dd>&nbsp;<font face="arial" size=2 color="#0000FF">
<dd>Wouldn't it be nice if we had a clean sheet - one attribute for self-issued certs, one attribute for certs &quot;issued by this CA&quot; and one attribute for certs &quot;issued to this CA&quot; - unfortunately we don't have that luxury.</font>
<dd>&nbsp;<font face="arial" size=2 color="#0000FF">
<dd>Oh yes, just for completeness on the crossCertificatePair attribute, don't forget the recent approved defect (256) that requires all certificates issued BY a CA to other CAs to be stored in the &quot;issuedByThisCA&quot; component of the crossCertificatePair attribute, except certificates issued to a subordinate CA by its superior CA in a hierarchy.</font>
<dd>&nbsp;<font face="arial" size=2 color="#0000FF">
<dd>Cheers,</font>
<dd>&nbsp;<font face="arial" size=2 color="#0000FF">
<dd>Sharon</font><font face="arial" size=2 color="#0000FF">
<dd>&nbsp;</font><font face="tahoma" size=2>
<dd>&nbsp;-----Original Message-----
<dd>From:</b> Santosh Chokhani [<a href="mailto:[e-mail]" eudora="autourl">mailto:[e-mail]</a>]
<dd>Sent:</b> Friday, October 19, 2001 11:25 AM
<dd>To:</b> Housley, Russ; Santosh Chokhani
<dd>Cc:</b> [e-mail]
<dd>Subject:</b> RE: AW: I-D ACTION:draft-ietf-pkix-new-part1-09.txt</font>
<dd>Russ: <br>
<br>
<font size=2>
<dd>I agree with you that you understand my concern.&nbsp; I also do not have objection to using caCertificate attribute.&nbsp; Actually, I prefer that. 
<dd>However, it may break ldap v3 schema.&nbsp; It seems that ldap states that all certificates must be published in crossCertificatePair attribute and ONLY the domain certificates appear in caCertificate attribute. 
<dd>-----Original Message-----</font> <font size=2>
<dd>From: Housley, Russ [<a href="mailto:[e-mail]">mailto:[e-mail]</a>]</font> <font size=2>
<dd>Sent: Friday, October 19, 2001 10:28 AM</font> <font size=2>
<dd>To: Santosh Chokhani</font> <font size=2>
<dd>Cc: [e-mail]</font> <font size=2>
<dd>Subject: RE: AW: I-D ACTION:draft-ietf-pkix-new-part1-09.txt</font> <font size=2>
<dd>Santosh:</font> <br>
<br>
<font size=2>
<dd>&gt;I am ok with what you wrote for the URI.&nbsp; My question relates to when the 
<dd>&gt;DN is specified as the caIssuers.&nbsp; We need either a mandate that a 
<dd>&gt;particular attribute (caCertificate, crossCertificatePair) will be used or 
<dd>&gt;we need the syntax to permit to specify either one of the attributes.</font> <font size=2>
<dd>&gt;</font> <font size=2>
<dd>&gt;Also, we as a community need to decide, for crossCertiifcatePair) whether 
<dd>&gt;the client will have to determine the element or will the pointer specify 
<dd>&gt;the element, i.e., forward or reverse.</font> <br>
<br>
<font size=2>
<dd>I am sorry that I misunderstood your original point.&nbsp; Let me make sure that 
<dd>I got it right this time.</font> <br>
<br>
<font size=2>
<dd>The accessMethod is a GeneralName.&nbsp; When the GeneralName has the form of a 
<dd>URI, you are happy with the LDAP situation described in RFC 2255.&nbsp; However, 
<dd>when the GeneralName has the form of an X.500 Distinguished Name, you are 
<dd>still unhappy because the text does not say which directory attribute is 
<dd>expected to be populated.&nbsp; You have proposed two alternatives: 
<dd>caCertificate and crossCertificatePair.&nbsp; Both of these attributes can hold 
<dd>more than one value.</font> <br>
<br>
<font size=2>
<dd>My preference would be caCertificate.&nbsp; Does anyone have an issue with this 
<dd>approach?</font> <br>
<br>
<font size=2>
<dd>Russ</font> 
</dl></blockquote></blockquote></html>


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id f9MDeqT11020 for ietf-pkix-bks; Mon, 22 Oct 2001 06:40:52 -0700 (PDT)
Received: from SOTTMXS01.entrust.com ([216.191.251.35]) by above.proper.com (8.11.6/8.11.3) with ESMTP id f9MDep811016 for <[e-mail]>; Mon, 22 Oct 2001 06:40:51 -0700 (PDT)
Received: by SOTTMXS01.entrust.com with Internet Mail Service (5.5.2653.19) id <VNB4V09D>; Mon, 22 Oct 2001 09:40:46 -0400
Message-ID: <[e-mail]>
From: Santosh Chokhani <[e-mail]>
To: "Housley, Russ" <[e-mail]>, Sharon Boeyen <[e-mail]>
Cc: Santosh Chokhani <[e-mail]>, [e-mail]
Subject: RE: AW: I-D ACTION:draft-ietf-pkix-new-part1-09.txt
Date: Mon, 22 Oct 2001 09:41:35 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C15AFF.447D57B0"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-pkix.imc.org>

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01C15AFF.447D57B0
Content-Type: text/plain;
	charset="iso-8859-1"

Russ:
 
In that case, would we ask for the component explicitly, provide a rule that
if the DN = issuer DN, it must be (or likely to be) issuedToThisCA component
and if the DN do not match, it must be (or likely to be) issuedByThisCA
component.
 
Alternatively, we could be silent on the matter.

-----Original Message-----
From: Housley, Russ [mailto:[e-mail]]
Sent: Monday, October 22, 2001 9:20 AM
To: Sharon Boeyen
Cc: Santosh Chokhani; [e-mail]
Subject: RE: AW: I-D ACTION:draft-ietf-pkix-new-part1-09.txt


Sharon:

You convinced me that we want the DN to imply the crossCertificatePair
attribute.

Russ


At 04:18 PM 10/19/2001 -0400, Sharon Boeyen wrote:


Santosh is right about the schemas. There have been at least 3 defect
reports against X.509 in this area over the past 2-3 years. 509 and PKIX
LDAP schema 
both aligned in this area with the very first defect report (DR 185) . Also
with DR 257, also approved, we no longer have "forward" and "reverse" but
rather "issuedToThisCA and "issuedByThisCA". All certs issued to a CA,
except self-issued certs, shall be stored in the issuedToThisCA element of
the crossCertificatePair. In addition to that, certificates issued to the
same CA, that were issued by other CAs in the same realm (where definition
of realm is a local policy matter) are ALSO stored in caCertificates
attribute. There are NO inbound certificates for a CA, that can be stored in
caCertificates without also being stored in crossCertificatePair. Since the
issuers of the certificates you are discussing may/may not be in the same
"realm" the certs would need to at least go into the crossCertificatePair
attribute and could also be present in the caCertificates attribute if
issued by a CA in ! the same realm.
 
Wouldn't it be nice if we had a clean sheet - one attribute for self-issued
certs, one attribute for certs "issued by this CA" and one attribute for
certs "issued to this CA" - unfortunately we don't have that luxury.
 
Oh yes, just for completeness on the crossCertificatePair attribute, don't
forget the recent approved defect (256) that requires all certificates
issued BY a CA to other CAs to be stored in the "issuedByThisCA" component
of the crossCertificatePair attribute, except certificates issued to a
subordinate CA by its superior CA in a hierarchy.
 
Cheers,
 
Sharon
 
 -----Original Message-----
From: Santosh Chokhani [ mailto:[e-mail]
<mailto:[e-mail]> ]
Sent: Friday, October 19, 2001 11:25 AM
To: Housley, Russ; Santosh Chokhani
Cc: [e-mail]
Subject: RE: AW: I-D ACTION:draft-ietf-pkix-new-part1-09.txt


Russ: 



I agree with you that you understand my concern.  I also do not have
objection to using caCertificate attribute.  Actually, I prefer that. 

However, it may break ldap v3 schema.  It seems that ldap states that all
certificates must be published in crossCertificatePair attribute and ONLY
the domain certificates appear in caCertificate attribute. 

-----Original Message----- 

From: Housley, Russ [ mailto:[e-mail]
<mailto:[e-mail]> ] 

Sent: Friday, October 19, 2001 10:28 AM 

To: Santosh Chokhani 

Cc: [e-mail] 

Subject: RE: AW: I-D ACTION:draft-ietf-pkix-new-part1-09.txt 



Santosh: 



>I am ok with what you wrote for the URI.  My question relates to when the 

>DN is specified as the caIssuers.  We need either a mandate that a 

>particular attribute (caCertificate, crossCertificatePair) will be used or 

>we need the syntax to permit to specify either one of the attributes. 

> 

>Also, we as a community need to decide, for crossCertiifcatePair) whether 

>the client will have to determine the element or will the pointer specify 

>the element, i.e., forward or reverse. 



I am sorry that I misunderstood your original point.  Let me make sure that 

I got it right this time. 



The accessMethod is a GeneralName.  When the GeneralName has the form of a 

URI, you are happy with the LDAP situation described in RFC 2255.  However, 

when the GeneralName has the form of an X.500 Distinguished Name, you are 

still unhappy because the text does not say which directory attribute is 

expected to be populated.  You have proposed two alternatives: 

caCertificate and crossCertificatePair.  Both of these attributes can hold 

more than one value. 



My preference would be caCertificate.  Does anyone have an issue with this 

approach? 



Russ 


------_=_NextPart_001_01C15AFF.447D57B0
Content-Type: text/html;
	charset="iso-8859-1"

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1">


<META content="MSHTML 5.50.4522.1800" name=GENERATOR></HEAD>
<BODY>
<DIV><SPAN class=817283913-22102001><FONT face=Arial color=#0000ff 
size=2>Russ:</FONT></SPAN></DIV>
<DIV><SPAN class=817283913-22102001><FONT face=Arial color=#0000ff 
size=2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=817283913-22102001><FONT face=Arial color=#0000ff size=2>In 
that case, would we ask for the component explicitly, provide a rule that if the 
DN = issuer DN, it must be (or likely to be) issuedToThisCA component and if the 
DN do not match, it&nbsp;must be (or likely to be) issuedByThisCA 
component.</FONT></SPAN></DIV>
<DIV><SPAN class=817283913-22102001><FONT face=Arial color=#0000ff 
size=2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=817283913-22102001><FONT face=Arial color=#0000ff 
size=2>Alternatively, we could be silent on the matter.</FONT></SPAN></DIV>
<BLOCKQUOTE dir=ltr style="MARGIN-RIGHT: 0px">
  <DIV class=OutlookMessageHeader dir=ltr align=left><FONT face=Tahoma 
  size=2>-----Original Message-----<BR><B>From:</B> Housley, Russ 
  [mailto:[e-mail]]<BR><B>Sent:</B> Monday, October 22, 2001 
  9:20 AM<BR><B>To:</B> Sharon Boeyen<BR><B>Cc:</B> Santosh Chokhani; 
  [e-mail]<BR><B>Subject:</B> RE: AW: I-D 
  ACTION:draft-ietf-pkix-new-part1-09.txt<BR><BR></FONT></DIV>Sharon:<BR><BR>You 
  convinced me that we want the DN to imply the <FONT face=arial 
  size=2>crossCertificatePair</FONT><FONT face=arial> 
  attribute.<BR><BR></FONT>Russ<BR><BR><BR>At 04:18 PM 10/19/2001 -0400, Sharon 
  Boeyen wrote:<BR>
  <BLOCKQUOTE class=cite cite type="cite"><FONT face=arial color=#0000ff 
    size=2>Santosh is right about the schemas. There have been at least 3 defect 
    reports against X.509 in this area over the past 2-3 years. 509 and PKIX 
    LDAP schema </FONT><BR><FONT face=arial color=#0000ff size=2>both aligned in 
    this area with the very first defect report (DR 185) . Also with DR 257, 
    also approved, we no longer have "forward" and "reverse" but rather 
    "issuedToThisCA and "issuedByThisCA". All certs issued to a CA, except 
    self-issued certs, shall be stored in the issuedToThisCA element of the 
    crossCertificatePair. In addition to that, certificates issued to the same 
    CA, that were issued by other CAs in the same realm (where definition of 
    realm is a local policy matter) are ALSO stored in caCertificates attribute. 
    There are NO inbound certificates for a CA, that can be stored in 
    caCertificates without also being stored in crossCertificatePair. Since the 
    issuers of the certificates you are discussing may/may not be in the same 
    "realm" the certs would need to at least go into the crossCertificatePair 
    attribute and could also be present in the caCertificates attribute if 
    issued by a CA in ! the same realm.</FONT><BR>&nbsp;<BR><FONT face=arial 
    color=#0000ff size=2>Wouldn't it be nice if we had a clean sheet - one 
    attribute for self-issued certs, one attribute for certs "issued by this CA" 
    and one attribute for certs "issued to this CA" - unfortunately we don't 
    have that luxury.</FONT><BR>&nbsp;<BR><FONT face=arial color=#0000ff 
    size=2>Oh yes, just for completeness on the crossCertificatePair attribute, 
    don't forget the recent approved defect (256) that requires all certificates 
    issued BY a CA to other CAs to be stored in the "issuedByThisCA" component 
    of the crossCertificatePair attribute, except certificates issued to a 
    subordinate CA by its superior CA in a hierarchy.</FONT><BR>&nbsp;<BR><FONT 
    face=arial color=#0000ff size=2>Cheers,</FONT><BR>&nbsp;<BR><FONT face=arial 
    color=#0000ff size=2>Sharon</FONT><BR><FONT face=arial color=#0000ff 
    size=2>&nbsp;</FONT><BR><FONT face=tahoma size=2>&nbsp;-----Original 
    Message-----<BR><B>From:</B> Santosh Chokhani [<A 
    href="mailto:[e-mail]" 
    eudora="autourl">mailto:[e-mail]</A>]<BR><B>Sent:</B> Friday, 
    October 19, 2001 11:25 AM<BR><B>To:</B> Housley, Russ; Santosh 
    Chokhani<BR><B>Cc:</B> [e-mail]<BR><B>Subject:</B> RE: AW: I-D 
    ACTION:draft-ietf-pkix-new-part1-09.txt<BR></FONT>
    <DL>
      <DD>Russ: <BR><BR><FONT size=2>
      <DD>I agree with you that you understand my concern.&nbsp; I also do not 
      have objection to using caCertificate attribute.&nbsp; Actually, I prefer 
      that.</FONT><FONT size=2> 
      <DD>However, it may break ldap v3 schema.&nbsp; It seems that ldap states 
      that all certificates must be published in crossCertificatePair attribute 
      and ONLY the domain certificates appear in caCertificate 
      attribute.</FONT><FONT size=2> 
      <DD>-----Original Message-----</FONT> <FONT size=2>
      <DD>From: Housley, Russ [<A 
      href="mailto:[e-mail]">mailto:[e-mail]</A>]</FONT> 
      <FONT size=2>
      <DD>Sent: Friday, October 19, 2001 10:28 AM</FONT> <FONT size=2>
      <DD>To: Santosh Chokhani</FONT> <FONT size=2>
      <DD>Cc: [e-mail]</FONT> <FONT size=2>
      <DD>Subject: RE: AW: I-D ACTION:draft-ietf-pkix-new-part1-09.txt</FONT> 
      <BR><BR><FONT size=2>
      <DD>Santosh:</FONT> <BR><BR><FONT size=2>
      <DD>&gt;I am ok with what you wrote for the URI.&nbsp; My question relates 
      to when the </FONT><FONT size=2>
      <DD>&gt;DN is specified as the caIssuers.&nbsp; We need either a mandate 
      that a </FONT><FONT size=2>
      <DD>&gt;particular attribute (caCertificate, crossCertificatePair) will be 
      used or </FONT><FONT size=2>
      <DD>&gt;we need the syntax to permit to specify either one of the 
      attributes.</FONT> <FONT size=2>
      <DD>&gt;</FONT> <FONT size=2>
      <DD>&gt;Also, we as a community need to decide, for crossCertiifcatePair) 
      whether </FONT><FONT size=2>
      <DD>&gt;the client will have to determine the element or will the pointer 
      specify </FONT><FONT size=2>
      <DD>&gt;the element, i.e., forward or reverse.</FONT> <BR><BR><FONT 
size=2>
      <DD>I am sorry that I misunderstood your original point.&nbsp; Let me make 
      sure that </FONT><FONT size=2>
      <DD>I got it right this time.</FONT> <BR><BR><FONT size=2>
      <DD>The accessMethod is a GeneralName.&nbsp; When the GeneralName has the 
      form of a </FONT><FONT size=2>
      <DD>URI, you are happy with the LDAP situation described in RFC 
      2255.&nbsp; However, </FONT><FONT size=2>
      <DD>when the GeneralName has the form of an X.500 Distinguished Name, you 
      are </FONT><FONT size=2>
      <DD>still unhappy because the text does not say which directory attribute 
      is </FONT><FONT size=2>
      <DD>expected to be populated.&nbsp; You have proposed two alternatives: 
      </FONT><FONT size=2>
      <DD>caCertificate and crossCertificatePair.&nbsp; Both of these attributes 
      can hold </FONT><FONT size=2>
      <DD>more than one value.</FONT> <BR><BR><FONT size=2>
      <DD>My preference would be caCertificate.&nbsp; Does anyone have an issue 
      with this </FONT><FONT size=2>
      <DD>approach?</FONT> <BR><BR><FONT size=2>
      <DD>Russ</FONT> </DD></DL></BLOCKQUOTE></BLOCKQUOTE></BODY></HTML>

------_=_NextPart_001_01C15AFF.447D57B0--


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id f9MDNIA09157 for ietf-pkix-bks; Mon, 22 Oct 2001 06:23:18 -0700 (PDT)
Received: from tholian.securitydynamics.com (mail.rsasecurity.com [204.167.112.129]) by above.proper.com (8.11.6/8.11.3) with SMTP id f9MDNB809143 for <[e-mail]>; Mon, 22 Oct 2001 06:23:11 -0700 (PDT)
Received: from sdtihq24.securitydynamics.com by tholian.securitydynamics.com via smtpd (for mail.imc.org [208.184.76.43]) with SMTP; 22 Oct 2001 13:19:46 UT
Received: from ebola.securitydynamics.com (ebola.securid.com [192.168.7.4]) by sdtihq24.securid.com (Pro-8.9.3/Pro-8.9.3) with ESMTP id JAA22408; Mon, 22 Oct 2001 09:23:12 -0400 (EDT)
Received: from exna00.securitydynamics.com (localhost [127.0.0.1]) by ebola.securitydynamics.com (8.9.3+Sun/8.9.1) with ESMTP id JAA10478; Mon, 22 Oct 2001 09:23:09 -0400 (EDT)
Received: by exna00.securitydynamics.com with Internet Mail Service (5.5.2653.19) id <T1DQ50RA>; Mon, 22 Oct 2001 09:22:59 -0400
Received: from HOUSLEY-LAP.rsasecurity.com (HOUSLEY-LAP [10.3.1.9]) by exna00.securitydynamics.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id T1DQ50Q8; Mon, 22 Oct 2001 09:22:57 -0400
From: "Housley, Russ" <[e-mail]>
To: Sharon Boeyen <[e-mail]>
Cc: Santosh Chokhani <[e-mail]>, [e-mail]
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Version 5.0.1
Date: Mon, 22 Oct 2001 09:19:56 -0400
Subject: RE: AW: I-D ACTION:draft-ietf-pkix-new-part1-09.txt
In-Reply-To: <[e-mail] .com>
Mime-Version: 1.0
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: 8bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-pkix.imc.org>

<html>
Sharon:<br>
<br>
You convinced me that we want the DN to imply the
<font face="arial" size=2>crossCertificatePair</font><font face="arial">
attribute.<br>
<br>
</font>Russ<br>
<br>
<br>
At 04:18 PM 10/19/2001 -0400, Sharon Boeyen wrote:<br>
<blockquote type=cite class=cite cite><font face="arial" size=2 color="#0000FF">Santosh is right about the schemas. There have been at least 3 defect reports against X.509 in this area over the past 2-3 years. 509 and PKIX LDAP schema </font><br>
<font face="arial" size=2 color="#0000FF">both aligned in this area with the very first defect report (DR 185) . Also with DR 257, also approved, we no longer have &quot;forward&quot; and &quot;reverse&quot; but rather &quot;issuedToThisCA and &quot;issuedByThisCA&quot;. All certs issued to a CA, except self-issued certs, shall be stored in the issuedToThisCA element of the crossCertificatePair. In addition to that, certificates issued to the same CA, that were issued by other CAs in the same realm (where definition of realm is a local policy matter) are ALSO stored in caCertificates attribute. There are NO inbound certificates for a CA, that can be stored in caCertificates without also being stored in crossCertificatePair. Since the issuers of the certificates you are discussing may/may not be in the same &quot;realm&quot; the certs would need to at least go into the crossCertificatePair attribute and could also be present in the caCertificates attribute if issued by a CA in !
the 
same realm.</font><br>
&nbsp;<br>
<font face="arial" size=2 color="#0000FF">Wouldn't it be nice if we had a clean sheet - one attribute for self-issued certs, one attribute for certs &quot;issued by this CA&quot; and one attribute for certs &quot;issued to this CA&quot; - unfortunately we don't have that luxury.</font><br>
&nbsp;<br>
<font face="arial" size=2 color="#0000FF">Oh yes, just for completeness on the crossCertificatePair attribute, don't forget the recent approved defect (256) that requires all certificates issued BY a CA to other CAs to be stored in the &quot;issuedByThisCA&quot; component of the crossCertificatePair attribute, except certificates issued to a subordinate CA by its superior CA in a hierarchy.</font><br>
&nbsp;<br>
<font face="arial" size=2 color="#0000FF">Cheers,</font><br>
&nbsp;<br>
<font face="arial" size=2 color="#0000FF">Sharon</font><br>
<font face="arial" size=2 color="#0000FF">&nbsp;</font><br>
<font face="tahoma" size=2>&nbsp;-----Original Message-----<br>
<b>From:</b> Santosh Chokhani [<a href="mailto:[e-mail]" eudora="autourl">mailto:[e-mail]</a>]<br>
<b>Sent:</b> Friday, October 19, 2001 11:25 AM<br>
<b>To:</b> Housley, Russ; Santosh Chokhani<br>
<b>Cc:</b> [e-mail]<br>
<b>Subject:</b> RE: AW: I-D ACTION:draft-ietf-pkix-new-part1-09.txt<br>
</font>
<dl>
<dd>Russ: <br>
<br>
<font size=2>
<dd>I agree with you that you understand my concern.&nbsp; I also do not have objection to using caCertificate attribute.&nbsp; Actually, I prefer that.</font><font size=2>
<dd>However, it may break ldap v3 schema.&nbsp; It seems that ldap states that all certificates must be published in crossCertificatePair attribute and ONLY the domain certificates appear in caCertificate attribute.</font><font size=2>
<dd>-----Original Message-----</font> <font size=2>
<dd>From: Housley, Russ [<a href="mailto:[e-mail]">mailto:[e-mail]</a>]</font> <font size=2>
<dd>Sent: Friday, October 19, 2001 10:28 AM</font> <font size=2>
<dd>To: Santosh Chokhani</font> <font size=2>
<dd>Cc: [e-mail]</font> <font size=2>
<dd>Subject: RE: AW: I-D ACTION:draft-ietf-pkix-new-part1-09.txt</font> <br>
<br>
<font size=2>
<dd>Santosh:</font> <br>
<br>
<font size=2>
<dd>&gt;I am ok with what you wrote for the URI.&nbsp; My question relates to when the </font><font size=2>
<dd>&gt;DN is specified as the caIssuers.&nbsp; We need either a mandate that a </font><font size=2>
<dd>&gt;particular attribute (caCertificate, crossCertificatePair) will be used or </font><font size=2>
<dd>&gt;we need the syntax to permit to specify either one of the attributes.</font> <font size=2>
<dd>&gt;</font> <font size=2>
<dd>&gt;Also, we as a community need to decide, for crossCertiifcatePair) whether </font><font size=2>
<dd>&gt;the client will have to determine the element or will the pointer specify </font><font size=2>
<dd>&gt;the element, i.e., forward or reverse.</font> <br>
<br>
<font size=2>
<dd>I am sorry that I misunderstood your original point.&nbsp; Let me make sure that </font><font size=2>
<dd>I got it right this time.</font> <br>
<br>
<font size=2>
<dd>The accessMethod is a GeneralName.&nbsp; When the GeneralName has the form of a </font><font size=2>
<dd>URI, you are happy with the LDAP situation described in RFC 2255.&nbsp; However, </font><font size=2>
<dd>when the GeneralName has the form of an X.500 Distinguished Name, you are </font><font size=2>
<dd>still unhappy because the text does not say which directory attribute is </font><font size=2>
<dd>expected to be populated.&nbsp; You have proposed two alternatives: </font><font size=2>
<dd>caCertificate and crossCertificatePair.&nbsp; Both of these attributes can hold </font><font size=2>
<dd>more than one value.</font> <br>
<br>
<font size=2>
<dd>My preference would be caCertificate.&nbsp; Does anyone have an issue with this </font><font size=2>
<dd>approach?</font> <br>
<br>
<font size=2>
<dd>Russ</font> 
</dl></blockquote></html>


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id f9MB3Vh01155 for ietf-pkix-bks; Mon, 22 Oct 2001 04:03:31 -0700 (PDT)
Received: from ietf.org (odin.ietf.org [132.151.1.176]) by above.proper.com (8.11.6/8.11.3) with ESMTP id f9MB3T801150 for <[e-mail]>; Mon, 22 Oct 2001 04:03:29 -0700 (PDT)
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA10423; Mon, 22 Oct 2001 07:03:26 -0400 (EDT)
Message-Id: <[e-mail]>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Cc: [e-mail]
From: [e-mail]
Reply-to: [e-mail]
Subject: I-D ACTION:draft-ietf-pkix-dsv-dpv-dpd-req-00.txt
Date: Mon, 22 Oct 2001 07:03:26 -0400
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-pkix.imc.org>

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Public-Key Infrastructure (X.509) Working Group of the IETF.

	Title		: Delegated Signature Validation Delegated Path 
                          Validation and Delegated Path Discovery Protocol      
                          Requirements
	Author(s)	: D. Pinkas
	Filename	: draft-ietf-pkix-dsv-dpv-dpd-req-00.txt
	Pages		: 16
	Date		: 19-Oct-01
	
This document specifies requirements for three main request/response 
pairs. 
The first one, called Delegated Signature Validation (DSV), can be used 
to fully delegate signature validation processing to an DSV server, 
according to a set of rules, called a signature policy.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-pkix-dsv-dpv-dpd-req-00.txt

To remove yourself from the IETF Announcement list, send a message to 
ietf-announce-request with the word unsubscribe in the body of the message.

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-pkix-dsv-dpv-dpd-req-00.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt


Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[e-mail].
In the body type:
	"FILE /internet-drafts/draft-ietf-pkix-dsv-dpv-dpd-req-00.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.
		
		
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body;
	access-type="mail-server";
	server="[e-mail]"

Content-Type: text/plain
Content-ID:	<[e-mail]>

ENCODING mime
FILE /internet-drafts/draft-ietf-pkix-dsv-dpv-dpd-req-00.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-pkix-dsv-dpv-dpd-req-00.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:	<[e-mail]>

--OtherAccess--

--NextPart--




Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id f9LC1vY13973 for ietf-pkix-bks; Sun, 21 Oct 2001 05:01:57 -0700 (PDT)
Received: from SOTTMXS01.entrust.com ([216.191.251.35]) by above.proper.com (8.11.6/8.11.3) with ESMTP id f9LC1u813969 for <[e-mail]>; Sun, 21 Oct 2001 05:01:56 -0700 (PDT)
Received: by SOTTMXS01.entrust.com with Internet Mail Service (5.5.2653.19) id <VK65M9DQ>; Sun, 21 Oct 2001 08:00:46 -0400
Message-ID: <[e-mail]>
From: Santosh Chokhani <[e-mail]>
To: Sharon Boeyen <[e-mail]>, "'Housley, Russ'" <[e-mail]>
Cc: "'[e-mail]'" <[e-mail]>
Subject: RE: AW: I-D ACTION:draft-ietf-pkix-new-part1-09.txt
Date: Sat, 20 Oct 2001 16:28:09 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C159A5.BBAD3090"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-pkix.imc.org>

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01C159A5.BBAD3090
Content-Type: text/plain

Russ:
 
I would go along for defining the attribute for the DN or for not defining
any attribute and the text saying that the "conformant clients may need to
look at the caCertificate and/or crossCertificatePai attributes".

-----Original Message-----
From: Sharon Boeyen 
Sent: Friday, October 19, 2001 4:19 PM
To: Santosh Chokhani; Housley, Russ
Cc: [e-mail]
Subject: RE: AW: I-D ACTION:draft-ietf-pkix-new-part1-09.txt


Santosh is right about the schemas. There have been at least 3 defect
reports against X.509 in this area over the past 2-3 years. 509 and PKIX
LDAP schema 
both aligned in this area with the very first defect report (DR 185) . Also
with DR 257, also approved, we no longer have "forward" and "reverse" but
rather "issuedToThisCA and "issuedByThisCA". All certs issued to a CA,
except self-issued certs, shall be stored in the issuedToThisCA element of
the crossCertificatePair. In addition to that, certificates issued to the
same CA, that were issued by other CAs in the same realm (where definition
of realm is a local policy matter) are ALSO stored in caCertificates
attribute. There are NO inbound certificates for a CA, that can be stored in
caCertificates without also being stored in crossCertificatePair. Since the
issuers of the certificates you are discussing may/may not be in the same
"realm" the certs would need to at least go into the crossCertificatePair
attribute and could also be present in the caCertificates attribute if
issued by a CA in the same realm.
 
Wouldn't it be nice if we had a clean sheet - one attribute for self-issued
certs, one attribute for certs "issued by this CA" and one attribute for
certs "issued to this CA" - unfortunately we don't have that luxury.
 
Oh yes, just for completeness on the crossCertificatePair attribute, don't
forget the recent approved defect (256) that requires all certificates
issued BY a CA to other CAs to be stored in the "issuedByThisCA" component
of the crossCertificatePair attribute, except certificates issued to a
subordinate CA by its superior CA in a hierarchy.
 
Cheers,
 
Sharon
 
 -----Original Message-----
From: Santosh Chokhani [mailto:[e-mail]]
Sent: Friday, October 19, 2001 11:25 AM
To: Housley, Russ; Santosh Chokhani
Cc: [e-mail]
Subject: RE: AW: I-D ACTION:draft-ietf-pkix-new-part1-09.txt



Russ: 

I agree with you that you understand my concern.  I also do not have
objection to using caCertificate attribute.  Actually, I prefer that.

However, it may break ldap v3 schema.  It seems that ldap states that all
certificates must be published in crossCertificatePair attribute and ONLY
the domain certificates appear in caCertificate attribute.

-----Original Message----- 
From: Housley, Russ [ mailto:[e-mail]
<mailto:[e-mail]> ] 
Sent: Friday, October 19, 2001 10:28 AM 
To: Santosh Chokhani 
Cc: [e-mail] 
Subject: RE: AW: I-D ACTION:draft-ietf-pkix-new-part1-09.txt 


Santosh: 

>I am ok with what you wrote for the URI.  My question relates to when the 
>DN is specified as the caIssuers.  We need either a mandate that a 
>particular attribute (caCertificate, crossCertificatePair) will be used or 
>we need the syntax to permit to specify either one of the attributes. 
> 
>Also, we as a community need to decide, for crossCertiifcatePair) whether 
>the client will have to determine the element or will the pointer specify 
>the element, i.e., forward or reverse. 

I am sorry that I misunderstood your original point.  Let me make sure that 
I got it right this time. 

The accessMethod is a GeneralName.  When the GeneralName has the form of a 
URI, you are happy with the LDAP situation described in RFC 2255.  However, 
when the GeneralName has the form of an X.500 Distinguished Name, you are 
still unhappy because the text does not say which directory attribute is 
expected to be populated.  You have proposed two alternatives: 
caCertificate and crossCertificatePair.  Both of these attributes can hold 
more than one value. 

My preference would be caCertificate.  Does anyone have an issue with this 
approach? 

Russ 


------_=_NextPart_001_01C159A5.BBAD3090
Content-Type: text/html

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=US-ASCII">
<TITLE>RE: AW: I-D ACTION:draft-ietf-pkix-new-part1-09.txt</TITLE>

<META content="MSHTML 5.50.4522.1800" name=GENERATOR></HEAD>
<BODY>
<DIV><SPAN class=682103714-20102001><FONT face=Arial color=#0000ff 
size=2>Russ:</FONT></SPAN></DIV>
<DIV><SPAN class=682103714-20102001><FONT face=Arial color=#0000ff 
size=2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=682103714-20102001><FONT face=Arial color=#0000ff size=2>I 
would go along&nbsp;for defining the attribute for the DN or for not defining 
any attribute and the text saying that the "conformant clients may need to look 
at the caCertificate and/or crossCertificatePai attributes".</FONT></SPAN></DIV>
<BLOCKQUOTE dir=ltr style="MARGIN-RIGHT: 0px">
  <DIV class=OutlookMessageHeader dir=ltr align=left><FONT face=Tahoma 
  size=2>-----Original Message-----<BR><B>From:</B> Sharon Boeyen 
  <BR><B>Sent:</B> Friday, October 19, 2001 4:19 PM<BR><B>To:</B> Santosh 
  Chokhani; Housley, Russ<BR><B>Cc:</B> [e-mail]<BR><B>Subject:</B> RE: 
  AW: I-D ACTION:draft-ietf-pkix-new-part1-09.txt<BR><BR></FONT></DIV>
  <DIV><SPAN class=385420219-19102001><FONT face=Arial color=#0000ff 
  size=2>Santosh is right about the schemas. There have been at least 3 defect 
  reports against X.509 in this area over the past 2-3 years. 509 and PKIX LDAP 
  schema </FONT></SPAN></DIV>
  <DIV><SPAN class=385420219-19102001><FONT face=Arial color=#0000ff size=2>both 
  aligned in this area with the very first defect report (DR 185)&nbsp;. Also 
  with DR 257, also approved, we no longer have "forward" and "reverse" but 
  rather "issuedToThisCA and "issuedByThisCA". All certs </FONT></SPAN><SPAN 
  class=385420219-19102001><FONT face=Arial color=#0000ff size=2>issued to a CA, 
  except self-issued certs, shall be stored in the issuedToThisCA element of the 
  crossCertificatePair. In addition to that, certificates issued to the same CA, 
  that were issued by other CAs in the same realm (where definition of realm is 
  a local policy matter) are ALSO stored in caCertificates attribute. There 
  </FONT></SPAN><SPAN class=385420219-19102001><FONT face=Arial color=#0000ff 
  size=2>are NO inbound certificates for a CA, that can be stored in 
  caCertificates without also being stored in crossCertificatePair. Since the 
  issuers of the certificates you are discussing may/may not be in the same 
  "realm" the certs would need to at least go into the crossCertificatePair 
  attribute and could also be present in the caCertificates attribute if issued 
  by a CA in the same realm.</FONT></SPAN></DIV>
  <DIV><SPAN class=385420219-19102001><FONT face=Arial color=#0000ff 
  size=2></FONT></SPAN>&nbsp;</DIV>
  <DIV><SPAN class=385420219-19102001><FONT face=Arial color=#0000ff 
  size=2>Wouldn't it be nice if we had a clean sheet - one attribute for 
  self-issued certs, one attribute for certs "issued by this CA" and one 
  attribute for certs "issued to this CA" - unfortunately we don't have that 
  luxury.</FONT></SPAN></DIV>
  <DIV><SPAN class=385420219-19102001><FONT face=Arial color=#0000ff 
  size=2></FONT></SPAN>&nbsp;</DIV>
  <DIV><SPAN class=385420219-19102001><FONT face=Arial color=#0000ff size=2>Oh 
  yes, just for completeness on the crossCertificatePair attribute, don't forget 
  the recent approved defect (256) that requires all certificates issued BY a CA 
  to other CAs to be stored in the "issuedByThisCA" component of the 
  crossCertificatePair attribute, except certificates issued to a subordinate CA 
  by its superior CA in a hierarchy.</FONT></SPAN></DIV>
  <DIV><SPAN class=385420219-19102001><FONT face=Arial color=#0000ff 
  size=2></FONT></SPAN>&nbsp;</DIV>
  <DIV><SPAN class=385420219-19102001><FONT face=Arial color=#0000ff 
  size=2>Cheers,</FONT></SPAN></DIV>
  <DIV><SPAN class=385420219-19102001><FONT face=Arial color=#0000ff 
  size=2></FONT></SPAN>&nbsp;</DIV>
  <DIV><SPAN class=385420219-19102001><FONT face=Arial color=#0000ff 
  size=2>Sharon</FONT></SPAN></DIV>
  <DIV><SPAN class=385420219-19102001></SPAN><FONT face=Tahoma><FONT 
  size=2><SPAN class=385420219-19102001><FONT face=Arial 
  color=#0000ff></FONT></SPAN></FONT></FONT>&nbsp;</DIV>
  <DIV><FONT face=Tahoma><FONT size=2><SPAN 
  class=385420219-19102001>&nbsp;</SPAN>-----Original 
  Message-----<BR><B>From:</B> Santosh Chokhani 
  [mailto:[e-mail]]<BR><B>Sent:</B> Friday, October 19, 2001 11:25 
  AM<BR><B>To:</B> Housley, Russ; Santosh Chokhani<BR><B>Cc:</B> 
  [e-mail]<BR><B>Subject:</B> RE: AW: I-D 
  ACTION:draft-ietf-pkix-new-part1-09.txt<BR><BR></DIV></FONT></FONT>
  <BLOCKQUOTE dir=ltr 
  style="PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #0000ff 2px solid; MARGIN-RIGHT: 0px">
    <P><FONT size=2>Russ:</FONT> </P>
    <P><FONT size=2>I agree with you that you understand my concern.&nbsp; I 
    also do not have objection to using caCertificate attribute.&nbsp; Actually, 
    I prefer that.</FONT></P>
    <P><FONT size=2>However, it may break ldap v3 schema.&nbsp; It seems that 
    ldap states that all certificates must be published in crossCertificatePair 
    attribute and ONLY the domain certificates appear in caCertificate 
    attribute.</FONT></P>
    <P><FONT size=2>-----Original Message-----</FONT> <BR><FONT size=2>From: 
    Housley, Russ [<A 
    href="mailto:[e-mail]">mailto:[e-mail]</A>]</FONT> 
    <BR><FONT size=2>Sent: Friday, October 19, 2001 10:28 AM</FONT> <BR><FONT 
    size=2>To: Santosh Chokhani</FONT> <BR><FONT size=2>Cc: 
    [e-mail]</FONT> <BR><FONT size=2>Subject: RE: AW: I-D 
    ACTION:draft-ietf-pkix-new-part1-09.txt</FONT> </P><BR>
    <P><FONT size=2>Santosh:</FONT> </P>
    <P><FONT size=2>&gt;I am ok with what you wrote for the URI.&nbsp; My 
    question relates to when the </FONT><BR><FONT size=2>&gt;DN is specified as 
    the caIssuers.&nbsp; We need either a mandate that a </FONT><BR><FONT 
    size=2>&gt;particular attribute (caCertificate, crossCertificatePair) will 
    be used or </FONT><BR><FONT size=2>&gt;we need the syntax to permit to 
    specify either one of the attributes.</FONT> <BR><FONT size=2>&gt;</FONT> 
    <BR><FONT size=2>&gt;Also, we as a community need to decide, for 
    crossCertiifcatePair) whether </FONT><BR><FONT size=2>&gt;the client will 
    have to determine the element or will the pointer specify </FONT><BR><FONT 
    size=2>&gt;the element, i.e., forward or reverse.</FONT> </P>
    <P><FONT size=2>I am sorry that I misunderstood your original point.&nbsp; 
    Let me make sure that </FONT><BR><FONT size=2>I got it right this 
    time.</FONT> </P>
    <P><FONT size=2>The accessMethod is a GeneralName.&nbsp; When the 
    GeneralName has the form of a </FONT><BR><FONT size=2>URI, you are happy 
    with the LDAP situation described in RFC 2255.&nbsp; However, 
    </FONT><BR><FONT size=2>when the GeneralName has the form of an X.500 
    Distinguished Name, you are </FONT><BR><FONT size=2>still unhappy because 
    the text does not say which directory attribute is </FONT><BR><FONT 
    size=2>expected to be populated.&nbsp; You have proposed two alternatives: 
    </FONT><BR><FONT size=2>caCertificate and crossCertificatePair.&nbsp; Both 
    of these attributes can hold </FONT><BR><FONT size=2>more than one 
    value.</FONT> </P>
    <P><FONT size=2>My preference would be caCertificate.&nbsp; Does anyone have 
    an issue with this </FONT><BR><FONT size=2>approach?</FONT> </P>
    <P><FONT size=2>Russ</FONT> </P></BLOCKQUOTE></BLOCKQUOTE></BODY></HTML>

------_=_NextPart_001_01C159A5.BBAD3090--


Received: by above.proper.com (8.11.6/8.11.3) id f9JMOnT12302 for ietf-pkix-bks; Fri, 19 Oct 2001 15:24:49 -0700 (PDT)
Received: from gamma.isi.edu (gamma.isi.edu [128.9.144.145]) by above.proper.com (8.11.6/8.11.3) with ESMTP id f9JMOlD12298 for <[e-mail]>; Fri, 19 Oct 2001 15:24:47 -0700 (PDT)
Received: from ISI.EDU (jet.isi.edu [128.9.160.87]) by gamma.isi.edu (8.11.6/8.11.2) with ESMTP id f9JMOiH29267; Fri, 19 Oct 2001 15:24:44 -0700 (PDT)
Message-Id: <[e-mail]>
To: IETF-Announce: ;
Subject: RFC 3161 on Time-Stamp Protocol (TSP)
Cc: [e-mail], [e-mail]
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary=NextPart
Date: Fri, 19 Oct 2001 15:24:43 -0700
From: RFC Editor <[e-mail]>
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-pkix.imc.org>

--NextPart


A new Request for Comments is now available in online RFC libraries.


        RFC 3161

        Title:	    Internet X.509 Public Key Infrastructure
                    Time-Stamp Protocol (TSP)
        Author(s):  C. Adams, P. Cain, D. Pinkas, R. Zuccherato
        Status:     Standards Track
	Date:       August 2001
        Mailbox:    [e-mail], [e-mail],
                    [e-mail],
                    [e-mail] 
        Pages:      26
        Characters: 54582
        Obsoletes/Updates/SeeAlso:    None

        I-D Tag:    draft-ietf-pkix-time-stamp-15.txt

        URL:        ftp://ftp.rfc-editor.org/in-notes/rfc3161.txt


This document describes the format of a request sent to a Time
Stamping Authority (TSA) and of the response that is returned.  It
also establishes several security-relevant requirements for TSA
operation, with regards to processing requests to generate responses.

This document is a product of the Public-Key Infrastructure (C.509)
Working Group of the IETF.

This is now a Proposed Standard Protocol.

This document specifies an Internet standards track protocol for
the Internet community, and requests discussion and suggestions
for improvements.  Please refer to the current edition of the
"Internet Official Protocol Standards" (STD 1) for the
standardization state and status of this protocol.  Distribution
of this memo is unlimited.

This announcement is sent to the IETF list and the RFC-DIST list.
Requests to be added to or deleted from the IETF distribution list
should be sent to [e-mail].  Requests to be
added to or deleted from the RFC-DIST distribution list should
be sent to [e-mail].

Details on obtaining RFCs via FTP or EMAIL may be obtained by sending
an EMAIL message to [e-mail] with the message body 
help: ways_to_get_rfcs.  For example:

        To: [e-mail]
        Subject: getting rfcs

        help: ways_to_get_rfcs

Requests for special distribution should be addressed to either the
author of the RFC in question, or to [e-mail].  Unless
specifically noted otherwise on the RFC itself, all RFCs are for
unlimited distribution.echo 
Submissions for Requests for Comments should be sent to
[e-mail].  Please consult RFC 2223, Instructions to RFC
Authors, for further information.


Joyce K. Reynolds and Sandy Ginoza
USC/Information Sciences Institute

...

Below is the data which will enable a MIME compliant Mail Reader 
implementation to automatically retrieve the ASCII version
of the RFCs.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type:  Message/External-body;
        access-type="mail-server";
        server="[e-mail]"

Content-Type: text/plain
Content-ID: <[e-mail]>

RETRIEVE: rfc
DOC-ID: rfc3161

--OtherAccess
Content-Type:   Message/External-body;
        name="rfc3161.txt";
        site="ftp.isi.edu";
        access-type="anon-ftp";
        directory="in-notes"

Content-Type: text/plain
Content-ID: <[e-mail]>

--OtherAccess--
--NextPart--


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id f9JKIbS07945 for ietf-pkix-bks; Fri, 19 Oct 2001 13:18:37 -0700 (PDT)
Received: from SOTTMXS01.entrust.com ([216.191.251.35]) by above.proper.com (8.11.6/8.11.3) with ESMTP id f9JKIZD07939 for <[e-mail]>; Fri, 19 Oct 2001 13:18:35 -0700 (PDT)
Received: by SOTTMXS01.entrust.com with Internet Mail Service (5.5.2653.19) id <VGYT8GBK>; Fri, 19 Oct 2001 16:18:32 -0400
Message-ID: <[e-mail]>
From: Sharon Boeyen <[e-mail]>
To: Santosh Chokhani <[e-mail]>, "Housley, Russ" <[e-mail]>
Cc: [e-mail]
Subject: RE: AW: I-D ACTION:draft-ietf-pkix-new-part1-09.txt
Date: Fri, 19 Oct 2001 16:18:31 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C158DB.388D9710"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-pkix.imc.org>

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01C158DB.388D9710
Content-Type: text/plain

Santosh is right about the schemas. There have been at least 3 defect
reports against X.509 in this area over the past 2-3 years. 509 and PKIX
LDAP schema 
both aligned in this area with the very first defect report (DR 185) . Also
with DR 257, also approved, we no longer have "forward" and "reverse" but
rather "issuedToThisCA and "issuedByThisCA". All certs issued to a CA,
except self-issued certs, shall be stored in the issuedToThisCA element of
the crossCertificatePair. In addition to that, certificates issued to the
same CA, that were issued by other CAs in the same realm (where definition
of realm is a local policy matter) are ALSO stored in caCertificates
attribute. There are NO inbound certificates for a CA, that can be stored in
caCertificates without also being stored in crossCertificatePair. Since the
issuers of the certificates you are discussing may/may not be in the same
"realm" the certs would need to at least go into the crossCertificatePair
attribute and could also be present in the caCertificates attribute if
issued by a CA in the same realm.
 
Wouldn't it be nice if we had a clean sheet - one attribute for self-issued
certs, one attribute for certs "issued by this CA" and one attribute for
certs "issued to this CA" - unfortunately we don't have that luxury.
 
Oh yes, just for completeness on the crossCertificatePair attribute, don't
forget the recent approved defect (256) that requires all certificates
issued BY a CA to other CAs to be stored in the "issuedByThisCA" component
of the crossCertificatePair attribute, except certificates issued to a
subordinate CA by its superior CA in a hierarchy.
 
Cheers,
 
Sharon
 
 -----Original Message-----
From: Santosh Chokhani [mailto:[e-mail]]
Sent: Friday, October 19, 2001 11:25 AM
To: Housley, Russ; Santosh Chokhani
Cc: [e-mail]
Subject: RE: AW: I-D ACTION:draft-ietf-pkix-new-part1-09.txt



Russ: 

I agree with you that you understand my concern.  I also do not have
objection to using caCertificate attribute.  Actually, I prefer that.

However, it may break ldap v3 schema.  It seems that ldap states that all
certificates must be published in crossCertificatePair attribute and ONLY
the domain certificates appear in caCertificate attribute.

-----Original Message----- 
From: Housley, Russ [ mailto:[e-mail]
<mailto:[e-mail]> ] 
Sent: Friday, October 19, 2001 10:28 AM 
To: Santosh Chokhani 
Cc: [e-mail] 
Subject: RE: AW: I-D ACTION:draft-ietf-pkix-new-part1-09.txt 


Santosh: 

>I am ok with what you wrote for the URI.  My question relates to when the 
>DN is specified as the caIssuers.  We need either a mandate that a 
>particular attribute (caCertificate, crossCertificatePair) will be used or 
>we need the syntax to permit to specify either one of the attributes. 
> 
>Also, we as a community need to decide, for crossCertiifcatePair) whether 
>the client will have to determine the element or will the pointer specify 
>the element, i.e., forward or reverse. 

I am sorry that I misunderstood your original point.  Let me make sure that 
I got it right this time. 

The accessMethod is a GeneralName.  When the GeneralName has the form of a 
URI, you are happy with the LDAP situation described in RFC 2255.  However, 
when the GeneralName has the form of an X.500 Distinguished Name, you are 
still unhappy because the text does not say which directory attribute is 
expected to be populated.  You have proposed two alternatives: 
caCertificate and crossCertificatePair.  Both of these attributes can hold 
more than one value. 

My preference would be caCertificate.  Does anyone have an issue with this 
approach? 

Russ 


------_=_NextPart_001_01C158DB.388D9710
Content-Type: text/html

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=US-ASCII">
<TITLE>RE: AW: I-D ACTION:draft-ietf-pkix-new-part1-09.txt</TITLE>

<META content="MSHTML 5.50.4522.1800" name=GENERATOR></HEAD>
<BODY>
<DIV><SPAN class=385420219-19102001><FONT face=Arial color=#0000ff 
size=2>Santosh is right about the schemas. There have been at least 3 defect 
reports against X.509 in this area over the past 2-3 years. 509 and PKIX LDAP 
schema </FONT></SPAN></DIV>
<DIV><SPAN class=385420219-19102001><FONT face=Arial color=#0000ff size=2>both 
aligned in this area with the very first defect report (DR 185)&nbsp;. Also with 
DR 257, also approved, we no longer have "forward" and "reverse" but rather 
"issuedToThisCA and "issuedByThisCA". All certs </FONT></SPAN><SPAN 
class=385420219-19102001><FONT face=Arial color=#0000ff size=2>issued to a CA, 
except self-issued certs, shall be stored in the issuedToThisCA element of the 
crossCertificatePair. In addition to that, certificates issued to the same CA, 
that were issued by other CAs in the same realm (where definition of realm is a 
local policy matter) are ALSO stored in caCertificates attribute. There 
</FONT></SPAN><SPAN class=385420219-19102001><FONT face=Arial color=#0000ff 
size=2>are NO inbound certificates for a CA, that can be stored in 
caCertificates without also being stored in crossCertificatePair. Since the 
issuers of the certificates you are discussing may/may not be in the same 
"realm" the certs would need to at least go into the crossCertificatePair 
attribute and could also be present in the caCertificates attribute if issued by 
a CA in the same realm.</FONT></SPAN></DIV>
<DIV><SPAN class=385420219-19102001><FONT face=Arial color=#0000ff 
size=2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=385420219-19102001><FONT face=Arial color=#0000ff 
size=2>Wouldn't it be nice if we had a clean sheet - one attribute for 
self-issued certs, one attribute for certs "issued by this CA" and one attribute 
for certs "issued to this CA" - unfortunately we don't have that 
luxury.</FONT></SPAN></DIV>
<DIV><SPAN class=385420219-19102001><FONT face=Arial color=#0000ff 
size=2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=385420219-19102001><FONT face=Arial color=#0000ff size=2>Oh 
yes, just for completeness on the crossCertificatePair attribute, don't forget 
the recent approved defect (256) that requires all certificates issued BY a CA 
to other CAs to be stored in the "issuedByThisCA" component of the 
crossCertificatePair attribute, except certificates issued to a subordinate CA 
by its superior CA in a hierarchy.</FONT></SPAN></DIV>
<DIV><SPAN class=385420219-19102001><FONT face=Arial color=#0000ff 
size=2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=385420219-19102001><FONT face=Arial color=#0000ff 
size=2>Cheers,</FONT></SPAN></DIV>
<DIV><SPAN class=385420219-19102001><FONT face=Arial color=#0000ff 
size=2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=385420219-19102001><FONT face=Arial color=#0000ff 
size=2>Sharon</FONT></SPAN></DIV>
<DIV><SPAN class=385420219-19102001></SPAN><FONT face=Tahoma><FONT size=2><SPAN 
class=385420219-19102001><FONT face=Arial 
color=#0000ff>&nbsp;</FONT></SPAN></FONT></FONT></DIV>
<DIV><FONT face=Tahoma><FONT size=2><SPAN 
class=385420219-19102001>&nbsp;</SPAN>-----Original Message-----<BR><B>From:</B> 
Santosh Chokhani [mailto:[e-mail]]<BR><B>Sent:</B> Friday, October 
19, 2001 11:25 AM<BR><B>To:</B> Housley, Russ; Santosh Chokhani<BR><B>Cc:</B> 
[e-mail]<BR><B>Subject:</B> RE: AW: I-D 
ACTION:draft-ietf-pkix-new-part1-09.txt<BR><BR></DIV></FONT></FONT>
<BLOCKQUOTE dir=ltr 
style="PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #0000ff 2px solid; MARGIN-RIGHT: 0px">
  <P><FONT size=2>Russ:</FONT> </P>
  <P><FONT size=2>I agree with you that you understand my concern.&nbsp; I also 
  do not have objection to using caCertificate attribute.&nbsp; Actually, I 
  prefer that.</FONT></P>
  <P><FONT size=2>However, it may break ldap v3 schema.&nbsp; It seems that ldap 
  states that all certificates must be published in crossCertificatePair 
  attribute and ONLY the domain certificates appear in caCertificate 
  attribute.</FONT></P>
  <P><FONT size=2>-----Original Message-----</FONT> <BR><FONT size=2>From: 
  Housley, Russ [<A 
  href="mailto:[e-mail]">mailto:[e-mail]</A>]</FONT> 
  <BR><FONT size=2>Sent: Friday, October 19, 2001 10:28 AM</FONT> <BR><FONT 
  size=2>To: Santosh Chokhani</FONT> <BR><FONT size=2>Cc: 
  [e-mail]</FONT> <BR><FONT size=2>Subject: RE: AW: I-D 
  ACTION:draft-ietf-pkix-new-part1-09.txt</FONT> </P><BR>
  <P><FONT size=2>Santosh:</FONT> </P>
  <P><FONT size=2>&gt;I am ok with what you wrote for the URI.&nbsp; My question 
  relates to when the </FONT><BR><FONT size=2>&gt;DN is specified as the 
  caIssuers.&nbsp; We need either a mandate that a </FONT><BR><FONT 
  size=2>&gt;particular attribute (caCertificate, crossCertificatePair) will be 
  used or </FONT><BR><FONT size=2>&gt;we need the syntax to permit to specify 
  either one of the attributes.</FONT> <BR><FONT size=2>&gt;</FONT> <BR><FONT 
  size=2>&gt;Also, we as a community need to decide, for crossCertiifcatePair) 
  whether </FONT><BR><FONT size=2>&gt;the client will have to determine the 
  element or will the pointer specify </FONT><BR><FONT size=2>&gt;the element, 
  i.e., forward or reverse.</FONT> </P>
  <P><FONT size=2>I am sorry that I misunderstood your original point.&nbsp; Let 
  me make sure that </FONT><BR><FONT size=2>I got it right this time.</FONT> 
</P>
  <P><FONT size=2>The accessMethod is a GeneralName.&nbsp; When the GeneralName 
  has the form of a </FONT><BR><FONT size=2>URI, you are happy with the LDAP 
  situation described in RFC 2255.&nbsp; However, </FONT><BR><FONT size=2>when 
  the GeneralName has the form of an X.500 Distinguished Name, you are 
  </FONT><BR><FONT size=2>still unhappy because the text does not say which 
  directory attribute is </FONT><BR><FONT size=2>expected to be populated.&nbsp; 
  You have proposed two alternatives: </FONT><BR><FONT size=2>caCertificate and 
  crossCertificatePair.&nbsp; Both of these attributes can hold </FONT><BR><FONT 
  size=2>more than one value.</FONT> </P>
  <P><FONT size=2>My preference would be caCertificate.&nbsp; Does anyone have 
  an issue with this </FONT><BR><FONT size=2>approach?</FONT> </P>
  <P><FONT size=2>Russ</FONT> </P></BLOCKQUOTE></BODY></HTML>

------_=_NextPart_001_01C158DB.388D9710--


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id f9JFOLc17009 for ietf-pkix-bks; Fri, 19 Oct 2001 08:24:21 -0700 (PDT)
Received: from SOTTMXS01.entrust.com ([216.191.251.35]) by above.proper.com (8.11.6/8.11.3) with ESMTP id f9JFOKD17003 for <[e-mail]>; Fri, 19 Oct 2001 08:24:20 -0700 (PDT)
Received: by SOTTMXS01.entrust.com with Internet Mail Service (5.5.2653.19) id <VGYT8B5K>; Fri, 19 Oct 2001 11:24:16 -0400
Message-ID: <[e-mail]>
From: Santosh Chokhani <[e-mail]>
To: "Housley, Russ" <[e-mail]>, Santosh Chokhani <[e-mail]>
Cc: [e-mail]
Subject: RE: AW: I-D ACTION:draft-ietf-pkix-new-part1-09.txt
Date: Fri, 19 Oct 2001 11:25:08 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C158B2.3CB82A90"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-pkix.imc.org>

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01C158B2.3CB82A90
Content-Type: text/plain

Russ:

I agree with you that you understand my concern.  I also do not have
objection to using caCertificate attribute.  Actually, I prefer that.

However, it may break ldap v3 schema.  It seems that ldap states that all
certificates must be published in crossCertificatePair attribute and ONLY
the domain certificates appear in caCertificate attribute.

-----Original Message-----
From: Housley, Russ [mailto:[e-mail]]
Sent: Friday, October 19, 2001 10:28 AM
To: Santosh Chokhani
Cc: [e-mail]
Subject: RE: AW: I-D ACTION:draft-ietf-pkix-new-part1-09.txt


Santosh:

>I am ok with what you wrote for the URI.  My question relates to when the 
>DN is specified as the caIssuers.  We need either a mandate that a 
>particular attribute (caCertificate, crossCertificatePair) will be used or 
>we need the syntax to permit to specify either one of the attributes.
>
>Also, we as a community need to decide, for crossCertiifcatePair) whether 
>the client will have to determine the element or will the pointer specify 
>the element, i.e., forward or reverse.

I am sorry that I misunderstood your original point.  Let me make sure that 
I got it right this time.

The accessMethod is a GeneralName.  When the GeneralName has the form of a 
URI, you are happy with the LDAP situation described in RFC 2255.  However, 
when the GeneralName has the form of an X.500 Distinguished Name, you are 
still unhappy because the text does not say which directory attribute is 
expected to be populated.  You have proposed two alternatives: 
caCertificate and crossCertificatePair.  Both of these attributes can hold 
more than one value.

My preference would be caCertificate.  Does anyone have an issue with this 
approach?

Russ

------_=_NextPart_001_01C158B2.3CB82A90
Content-Type: text/html
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3DUS-ASCII">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2653.12">
<TITLE>RE: AW: I-D ACTION:draft-ietf-pkix-new-part1-09.txt</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=3D2>Russ:</FONT>
</P>

<P><FONT SIZE=3D2>I agree with you that you understand my =
concern.&nbsp; I also do not have objection to using caCertificate =
attribute.&nbsp; Actually, I prefer that.</FONT></P>

<P><FONT SIZE=3D2>However, it may break ldap v3 schema.&nbsp; It seems =
that ldap states that all certificates must be published in =
crossCertificatePair attribute and ONLY the domain certificates appear =
in caCertificate attribute.</FONT></P>

<P><FONT SIZE=3D2>-----Original Message-----</FONT>
<BR><FONT SIZE=3D2>From: Housley, Russ [<A =
HREF=3D"mailto:[e-mail]">mailto:[e-mail]=
</A>]</FONT>
<BR><FONT SIZE=3D2>Sent: Friday, October 19, 2001 10:28 AM</FONT>
<BR><FONT SIZE=3D2>To: Santosh Chokhani</FONT>
<BR><FONT SIZE=3D2>Cc: [e-mail]</FONT>
<BR><FONT SIZE=3D2>Subject: RE: AW: I-D =
ACTION:draft-ietf-pkix-new-part1-09.txt</FONT>
</P>
<BR>

<P><FONT SIZE=3D2>Santosh:</FONT>
</P>

<P><FONT SIZE=3D2>&gt;I am ok with what you wrote for the URI.&nbsp; My =
question relates to when the </FONT>
<BR><FONT SIZE=3D2>&gt;DN is specified as the caIssuers.&nbsp; We need =
either a mandate that a </FONT>
<BR><FONT SIZE=3D2>&gt;particular attribute (caCertificate, =
crossCertificatePair) will be used or </FONT>
<BR><FONT SIZE=3D2>&gt;we need the syntax to permit to specify either =
one of the attributes.</FONT>
<BR><FONT SIZE=3D2>&gt;</FONT>
<BR><FONT SIZE=3D2>&gt;Also, we as a community need to decide, for =
crossCertiifcatePair) whether </FONT>
<BR><FONT SIZE=3D2>&gt;the client will have to determine the element or =
will the pointer specify </FONT>
<BR><FONT SIZE=3D2>&gt;the element, i.e., forward or reverse.</FONT>
</P>

<P><FONT SIZE=3D2>I am sorry that I misunderstood your original =
point.&nbsp; Let me make sure that </FONT>
<BR><FONT SIZE=3D2>I got it right this time.</FONT>
</P>

<P><FONT SIZE=3D2>The accessMethod is a GeneralName.&nbsp; When the =
GeneralName has the form of a </FONT>
<BR><FONT SIZE=3D2>URI, you are happy with the LDAP situation described =
in RFC 2255.&nbsp; However, </FONT>
<BR><FONT SIZE=3D2>when the GeneralName has the form of an X.500 =
Distinguished Name, you are </FONT>
<BR><FONT SIZE=3D2>still unhappy because the text does not say which =
directory attribute is </FONT>
<BR><FONT SIZE=3D2>expected to be populated.&nbsp; You have proposed =
two alternatives: </FONT>
<BR><FONT SIZE=3D2>caCertificate and crossCertificatePair.&nbsp; Both =
of these attributes can hold </FONT>
<BR><FONT SIZE=3D2>more than one value.</FONT>
</P>

<P><FONT SIZE=3D2>My preference would be caCertificate.&nbsp; Does =
anyone have an issue with this </FONT>
<BR><FONT SIZE=3D2>approach?</FONT>
</P>

<P><FONT SIZE=3D2>Russ</FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C158B2.3CB82A90--


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id f9JERnB09789 for ietf-pkix-bks; Fri, 19 Oct 2001 07:27:49 -0700 (PDT)
Received: from tholian.securitydynamics.com (mail.rsasecurity.com [204.167.112.129]) by above.proper.com (8.11.6/8.11.3) with SMTP id f9JERlD09782 for <[e-mail]>; Fri, 19 Oct 2001 07:27:47 -0700 (PDT)
Received: from sdtihq24.securid.com by tholian.securitydynamics.com via smtpd (for mail.imc.org [208.184.76.43]) with SMTP; 19 Oct 2001 14:24:25 UT
Received: from ebola.securitydynamics.com (ebola.securid.com [192.168.7.4]) by sdtihq24.securid.com (Pro-8.9.3/Pro-8.9.3) with ESMTP id KAA16279 for <[e-mail]>; Fri, 19 Oct 2001 10:27:48 -0400 (EDT)
Received: from exna00.securitydynamics.com (localhost [127.0.0.1]) by ebola.securitydynamics.com (8.9.3+Sun/8.9.1) with ESMTP id KAA22545 for <[e-mail]>; Fri, 19 Oct 2001 10:27:46 -0400 (EDT)
Received: by exna00.securitydynamics.com with Internet Mail Service (5.5.2653.19) id <T1DQ5HC2>; Fri, 19 Oct 2001 10:27:39 -0400
Received: from HOUSLEY-LAP.rsasecurity.com (HOUSLEY-LAP [10.3.1.39]) by exna00.securitydynamics.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id T1DQ5HCG; Fri, 19 Oct 2001 10:27:32 -0400
From: "Housley, Russ" <[e-mail]>
To: Santosh Chokhani <[e-mail]>
Cc: [e-mail]
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Version 5.0.1
Date: Fri, 19 Oct 2001 10:27:31 -0400
Subject: RE: AW: I-D ACTION:draft-ietf-pkix-new-part1-09.txt
In-Reply-To: <[e-mail]. com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-pkix.imc.org>

Santosh:

>I am ok with what you wrote for the URI.  My question relates to when the 
>DN is specified as the caIssuers.  We need either a mandate that a 
>particular attribute (caCertificate, crossCertificatePair) will be used or 
>we need the syntax to permit to specify either one of the attributes.
>
>Also, we as a community need to decide, for crossCertiifcatePair) whether 
>the client will have to determine the element or will the pointer specify 
>the element, i.e., forward or reverse.

I am sorry that I misunderstood your original point.  Let me make sure that 
I got it right this time.

The accessMethod is a GeneralName.  When the GeneralName has the form of a 
URI, you are happy with the LDAP situation described in RFC 2255.  However, 
when the GeneralName has the form of an X.500 Distinguished Name, you are 
still unhappy because the text does not say which directory attribute is 
expected to be populated.  You have proposed two alternatives: 
caCertificate and crossCertificatePair.  Both of these attributes can hold 
more than one value.

My preference would be caCertificate.  Does anyone have an issue with this 
approach?

Russ


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id f9JEFRH08508 for ietf-pkix-bks; Fri, 19 Oct 2001 07:15:27 -0700 (PDT)
Received: from SOTTMXS01.entrust.com ([216.191.251.35]) by above.proper.com (8.11.6/8.11.3) with ESMTP id f9JEFQD08497 for <[e-mail]>; Fri, 19 Oct 2001 07:15:26 -0700 (PDT)
Received: by SOTTMXS01.entrust.com with Internet Mail Service (5.5.2653.19) id <VGYT8ARL>; Fri, 19 Oct 2001 10:15:16 -0400
Message-ID: <[e-mail]>
From: Santosh Chokhani <[e-mail]>
To: "Housley, Russ" <[e-mail]>, Santosh Chokhani <[e-mail]>
Cc: [e-mail]
Subject: RE: AW: I-D ACTION:draft-ietf-pkix-new-part1-09.txt
Date: Fri, 19 Oct 2001 10:16:09 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C158A8.99295F60"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-pkix.imc.org>

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01C158A8.99295F60
Content-Type: text/plain

Russ:

I am ok with what you wrote for the URI.  My question relates to when the DN
is specified as the caIssuers.  We need either a mandate that a particular
attribute (caCertificate, crossCertificatePair) will be used or we need the
syntax to permit to specify either one of the attributes.

Also, we as a community need to decide, for crossCertiifcatePair) whether
the client will have to determine the element or will the pointer specify
the element, i.e., forward or reverse.

-----Original Message-----
From: Housley, Russ [mailto:[e-mail]]
Sent: Thursday, October 18, 2001 3:36 PM
To: Santosh Chokhani
Cc: [e-mail]
Subject: RE: AW: I-D ACTION:draft-ietf-pkix-new-part1-09.txt



Santosh:

Please take a look at RFC 2255.  It says LDAP URLs have the following
format:

   ldapurl = scheme "://" [hostport] ["/" [dn ["?" [attributes]
     ["?" [scope] ["?" [filter] ["?"  extensions]]]]]]

Therefore, it is straightforward to specify a specific DN and a specific 
attribute.

Russ


At 02:13 PM 10/18/2001 -0400, Santosh Chokhani wrote:
>Russ: I am not sure that the DN name form will be 
><ldap://URI>ldap://URI.  The RFC seems to define DN, but does not state 
>that you need to obtain the appropriate attribute.
>-----Original Message-----
>From: Housley, Russ [mailto:[e-mail]]
>Sent: Thursday, October 18, 2001 11:52 AM
>To: Santosh Chokhani
>Cc: [e-mail]
>Subject: RE: AW: I-D ACTION:draft-ietf-pkix-new-part1-09.txt
>
>Santosh:
>
>In general, I expect this to be implemented with an ldap:// URI.  In this 
>case, what comes back is obvious from the attribute that is 
>referenced.  You are correct that other forms of URI are not specified.
>
>At 11:01 AM 10/18/2001 -0400, Santosh Chokhani wrote:
>>Also, when the name form for caIssuers is URL, I assume that will be the 
>>location of the certificate itself.  However, if the name form is the DN, 
>>it will not be the location of the certificate.  Rather, the client will 
>>have to get the caCertificate or crossCertificatePair attribute.  Given 
>>all the debate that has gone on in the past, how will we know which
attribute?
>Russ

------_=_NextPart_001_01C158A8.99295F60
Content-Type: text/html
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3DUS-ASCII">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2653.12">
<TITLE>RE: AW: I-D ACTION:draft-ietf-pkix-new-part1-09.txt</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=3D2>Russ:</FONT>
</P>

<P><FONT SIZE=3D2>I am ok with what you wrote for the URI.&nbsp; My =
question relates to when the DN is specified as the caIssuers.&nbsp; We =
need either a mandate that a particular attribute (caCertificate, =
crossCertificatePair) will be used or we need the syntax to permit to =
specify either one of the attributes.</FONT></P>

<P><FONT SIZE=3D2>Also, we as a community need to decide, for =
crossCertiifcatePair) whether the client will have to determine the =
element or will the pointer specify the element, i.e., forward or =
reverse.</FONT></P>

<P><FONT SIZE=3D2>-----Original Message-----</FONT>
<BR><FONT SIZE=3D2>From: Housley, Russ [<A =
HREF=3D"mailto:[e-mail]">mailto:[e-mail]=
</A>]</FONT>
<BR><FONT SIZE=3D2>Sent: Thursday, October 18, 2001 3:36 PM</FONT>
<BR><FONT SIZE=3D2>To: Santosh Chokhani</FONT>
<BR><FONT SIZE=3D2>Cc: [e-mail]</FONT>
<BR><FONT SIZE=3D2>Subject: RE: AW: I-D =
ACTION:draft-ietf-pkix-new-part1-09.txt</FONT>
</P>
<BR>
<BR>

<P><FONT SIZE=3D2>Santosh:</FONT>
</P>

<P><FONT SIZE=3D2>Please take a look at RFC 2255.&nbsp; It says LDAP =
URLs have the following format:</FONT>
</P>

<P><FONT SIZE=3D2>&nbsp;&nbsp; ldapurl =3D scheme &quot;://&quot; =
[hostport] [&quot;/&quot; [dn [&quot;?&quot; [attributes]</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp; [&quot;?&quot; [scope] =
[&quot;?&quot; [filter] [&quot;?&quot;&nbsp; extensions]]]]]]</FONT>
</P>

<P><FONT SIZE=3D2>Therefore, it is straightforward to specify a =
specific DN and a specific </FONT>
<BR><FONT SIZE=3D2>attribute.</FONT>
</P>

<P><FONT SIZE=3D2>Russ</FONT>
</P>
<BR>

<P><FONT SIZE=3D2>At 02:13 PM 10/18/2001 -0400, Santosh Chokhani =
wrote:</FONT>
<BR><FONT SIZE=3D2>&gt;Russ: I am not sure that the DN name form will =
be </FONT>
<BR><FONT SIZE=3D2>&gt;&lt;ldap://URI&gt;ldap://URI.&nbsp; The RFC =
seems to define DN, but does not state </FONT>
<BR><FONT SIZE=3D2>&gt;that you need to obtain the appropriate =
attribute.</FONT>
<BR><FONT SIZE=3D2>&gt;-----Original Message-----</FONT>
<BR><FONT SIZE=3D2>&gt;From: Housley, Russ [<A =
HREF=3D"mailto:[e-mail]">mailto:[e-mail]=
</A>]</FONT>
<BR><FONT SIZE=3D2>&gt;Sent: Thursday, October 18, 2001 11:52 AM</FONT>
<BR><FONT SIZE=3D2>&gt;To: Santosh Chokhani</FONT>
<BR><FONT SIZE=3D2>&gt;Cc: [e-mail]</FONT>
<BR><FONT SIZE=3D2>&gt;Subject: RE: AW: I-D =
ACTION:draft-ietf-pkix-new-part1-09.txt</FONT>
<BR><FONT SIZE=3D2>&gt;</FONT>
<BR><FONT SIZE=3D2>&gt;Santosh:</FONT>
<BR><FONT SIZE=3D2>&gt;</FONT>
<BR><FONT SIZE=3D2>&gt;In general, I expect this to be implemented with =
an ldap:// URI.&nbsp; In this </FONT>
<BR><FONT SIZE=3D2>&gt;case, what comes back is obvious from the =
attribute that is </FONT>
<BR><FONT SIZE=3D2>&gt;referenced.&nbsp; You are correct that other =
forms of URI are not specified.</FONT>
<BR><FONT SIZE=3D2>&gt;</FONT>
<BR><FONT SIZE=3D2>&gt;At 11:01 AM 10/18/2001 -0400, Santosh Chokhani =
wrote:</FONT>
<BR><FONT SIZE=3D2>&gt;&gt;Also, when the name form for caIssuers is =
URL, I assume that will be the </FONT>
<BR><FONT SIZE=3D2>&gt;&gt;location of the certificate itself.&nbsp; =
However, if the name form is the DN, </FONT>
<BR><FONT SIZE=3D2>&gt;&gt;it will not be the location of the =
certificate.&nbsp; Rather, the client will </FONT>
<BR><FONT SIZE=3D2>&gt;&gt;have to get the caCertificate or =
crossCertificatePair attribute.&nbsp; Given </FONT>
<BR><FONT SIZE=3D2>&gt;&gt;all the debate that has gone on in the past, =
how will we know which attribute?</FONT>
<BR><FONT SIZE=3D2>&gt;Russ</FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C158A8.99295F60--


Received: by above.proper.com (8.11.6/8.11.3) id f9JDNjn05384 for ietf-pkix-bks; Fri, 19 Oct 2001 06:23:45 -0700 (PDT)
Received: from tholian.securitydynamics.com (mail.rsasecurity.com [204.167.112.129]) by above.proper.com (8.11.6/8.11.3) with SMTP id f9JDNgD05370 for <[e-mail]>; Fri, 19 Oct 2001 06:23:42 -0700 (PDT)
Received: from sdtihq24.securid.com by tholian.securitydynamics.com via smtpd (for mail.imc.org [208.184.76.43]) with SMTP; 19 Oct 2001 13:20:20 UT
Received: from ebola.securitydynamics.com (ebola.securid.com [192.168.7.4]) by sdtihq24.securid.com (Pro-8.9.3/Pro-8.9.3) with ESMTP id JAA09451 for <[e-mail]>; Fri, 19 Oct 2001 09:23:43 -0400 (EDT)
Received: from exna00.securitydynamics.com (localhost [127.0.0.1]) by ebola.securitydynamics.com (8.9.3+Sun/8.9.1) with ESMTP id JAA15443 for <[e-mail]>; Fri, 19 Oct 2001 09:23:41 -0400 (EDT)
Received: by exna00.securitydynamics.com with Internet Mail Service (5.5.2653.19) id <T1DQ5FWY>; Fri, 19 Oct 2001 09:23:34 -0400
Received: from HOUSLEY-LAP.rsasecurity.com (HOUSLEY-LAP [10.3.1.39]) by exna00.securitydynamics.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id T1DQ5FWR; Fri, 19 Oct 2001 09:23:23 -0400
From: "Housley, Russ" <[e-mail]>
To: Fantou Patrick <[e-mail]>
Cc: [e-mail]
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Version 5.0.1
Date: Fri, 19 Oct 2001 09:15:50 -0400
Subject: Re: AW: AW: pseudonym : small typo
In-Reply-To: <1D82815C322BD41196EA00508B951F7B01B40C4E@MCHH265E>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-pkix.imc.org>

Patrick:

>you certainly wanted to write
>
>     id-at-pseudonym      AttributeType ::= { id-at 65 }
>
>and not
>     id-at-localityName      AttributeType ::= { id-at 65 }

You are obviously correct.  I caught this error right after new-part1-10 
was sent to the Internet-Draft repository.  We will correct it in new-part1-11.

Russ


Received: by above.proper.com (8.11.6/8.11.3) id f9JDNj105385 for ietf-pkix-bks; Fri, 19 Oct 2001 06:23:45 -0700 (PDT)
Received: from tholian.securitydynamics.com (mail.rsasecurity.com [204.167.112.129]) by above.proper.com (8.11.6/8.11.3) with SMTP id f9JDNhD05379 for <[e-mail]>; Fri, 19 Oct 2001 06:23:43 -0700 (PDT)
Received: from sdtihq24.securid.com by tholian.securitydynamics.com via smtpd (for mail.imc.org [208.184.76.43]) with SMTP; 19 Oct 2001 13:20:21 UT
Received: from ebola.securitydynamics.com (ebola.securid.com [192.168.7.4]) by sdtihq24.securid.com (Pro-8.9.3/Pro-8.9.3) with ESMTP id JAA09459 for <[e-mail]>; Fri, 19 Oct 2001 09:23:44 -0400 (EDT)
Received: from exna00.securitydynamics.com (localhost [127.0.0.1]) by ebola.securitydynamics.com (8.9.3+Sun/8.9.1) with ESMTP id JAA15444 for <[e-mail]>; Fri, 19 Oct 2001 09:23:41 -0400 (EDT)
Received: by exna00.securitydynamics.com with Internet Mail Service (5.5.2653.19) id <T1DQ5FWZ>; Fri, 19 Oct 2001 09:23:34 -0400
Received: from HOUSLEY-LAP.rsasecurity.com (HOUSLEY-LAP [10.3.1.39]) by exna00.securitydynamics.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id T1DQ5FWQ; Fri, 19 Oct 2001 09:23:23 -0400
From: "Housley, Russ" <[e-mail]>
To: Fantou Patrick <[e-mail]>
Cc: [e-mail]
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Version 5.0.1
Date: Fri, 19 Oct 2001 09:13:41 -0400
Subject: Re: AW: AW: I-D ACTION:draft-ietf-pkix-new-part1-09.txt
In-Reply-To: <1D82815C322BD41196EA00508B951F7B01B40C4D@MCHH265E>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-pkix.imc.org>

Patrick:

>I also support the extension of the phrase proposed by Santosh.
>In fact is there another possibility to get CA policy data than using the 
>CA certificate?

I am unaware of an accessMethod assignment for this purpose.

Russ


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id f9JDCJw04507 for ietf-pkix-bks; Fri, 19 Oct 2001 06:12:19 -0700 (PDT)
Received: from tholian.securitydynamics.com (mail.rsasecurity.com [204.167.112.129]) by above.proper.com (8.11.6/8.11.3) with SMTP id f9JDCBD04467 for <[e-mail]>; Fri, 19 Oct 2001 06:12:11 -0700 (PDT)
Received: from sdtihq24.securid.com by tholian.securitydynamics.com via smtpd (for mail.imc.org [208.184.76.43]) with SMTP; 19 Oct 2001 13:08:48 UT
Received: from ebola.securitydynamics.com (ebola.securid.com [192.168.7.4]) by sdtihq24.securid.com (Pro-8.9.3/Pro-8.9.3) with ESMTP id JAA08174 for <[e-mail]>; Fri, 19 Oct 2001 09:12:11 -0400 (EDT)
Received: from exna00.securitydynamics.com (localhost [127.0.0.1]) by ebola.securitydynamics.com (8.9.3+Sun/8.9.1) with ESMTP id JAA14122 for <[e-mail]>; Fri, 19 Oct 2001 09:12:09 -0400 (EDT)
Received: by exna00.securitydynamics.com with Internet Mail Service (5.5.2653.19) id <T1DQ5FQJ>; Fri, 19 Oct 2001 09:12:02 -0400
Received: from HOUSLEY-LAP.rsasecurity.com (HOUSLEY-LAP [10.3.1.39]) by exna00.securitydynamics.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id T1DQ5FQ2; Fri, 19 Oct 2001 09:11:54 -0400
From: "Housley, Russ" <[e-mail]>
To: Fantou Patrick <[e-mail]>
Cc: [e-mail]
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Version 5.0.1
Date: Fri, 19 Oct 2001 09:11:55 -0400
Subject: Re: AW: AW: I-D ACTION:draft-ietf-pkix-new-part1-09.txt
In-Reply-To: <1D82815C322BD41196EA00508B951F7B01B40C4C@MCHH265E>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-pkix.imc.org>

Patrick:

>I agree with this replacement text, which is much clearer on OCSP.
>But do you not think, that the last paragraph is redundant?
>It repeats what you say in the two new paragraphs before and still says
>that RFC2560 defines the access descriptor for OCSP. I would reduce it
>to the last sentence : "Additional access descriptors may be defined in
>other PKIX specifications."

Ooops.  We had a small problem with Microsoft Word.  Tim and I were using 
the revisions feature to discuss the proposed text.  When we did a 
cut-and-paste at the end, the strike through (to-be-deleted text) was 
copied too.

Please review the attached text.

Russ

= = = = = = = = = =

     4.2.2.1  Authority Information Access

    The authority information access extension indicates how to access CA
    information and services for the issuer of the certificate in which
    the extension appears.  Information and services may include on-line
    validation services and CA policy data.  (The location of CRLs is not
    specified in this extension; that information is provided by the
    cRLDistributionPoints extension.)  This extension may be included in
    subject or CA certificates, and it MUST be non-critical.

    id-pe-authorityInfoAccess OBJECT IDENTIFIER ::= { id-pe 1 }

    AuthorityInfoAccessSyntax  ::=
            SEQUENCE SIZE (1..MAX) OF AccessDescription

    AccessDescription  ::=  SEQUENCE {
            accessMethod          OBJECT IDENTIFIER,
            accessLocation        GeneralName  }

    id-ad OBJECT IDENTIFIER ::= { id-pkix 48 }

    id-ad-caIssuers OBJECT IDENTIFIER ::= { id-ad 2 }

    id-ad-ocsp OBJECT IDENTIFIER ::= { id-ad 1 }

    Each entry in the sequence AuthorityInfoAccessSyntax describes the
    format and location of additional information provided by the CA that
    issued the certificate in which this extension appears.  The type and
    format of the information is specified by the accessMethod field; the
    accessLocation field specifies the location of the information.  The
    retrieval mechanism may be implied by the accessMethod or specified
    by accessLocation.

    This profile defines two accessMethod OIDs: id-ad-caIssuers and
    id-ad-ocsp.


    The id-ad-caIssuers
    OID is used when the additional information lists CAs that have
    issued certificates superior to the CA that issued the certificate
    containing this extension.  The referenced CA Issuers description is
    intended to aid certificate users in the selection of a certification
    path that terminates at a point trusted by the certificate user.

    When id-ad-caIssuers appears as accessMethod, the accessLocation
    field describes the referenced description server and the access
    protocol to obtain the referenced description.  The accessLocation
    field is defined as a GeneralName, which can take several forms.
    Where the information is available via http, ftp, or ldap,
    accessLocation MUST be a uniformResourceIdentifier.  Where the
    information is available via the Directory Access Protocol (DAP),
    accessLocation MUST be a directoryName.  When the information is
    available via electronic mail, accessLocation MUST be an rfc822Name.
    The semantics of other id-ad-caIssuers accessLocation name forms are
    not defined.

    The id-ad-ocsp OID is used when revocation information for the
    certificate containing this extension is available using the
    Online Certificate Status Protocol (OCSP) [RFC 2560].

    When id-ad-ocsp appears as accessMethod, the accessLocation
    field is the location of the OCSP responder, using the
    conventions defined in [RFC 2560].

    Additional access descriptors may be defined in
    other PKIX specifications.


Received: by above.proper.com (8.11.6/8.11.3) id f9JBAK225176 for ietf-pkix-bks; Fri, 19 Oct 2001 04:10:20 -0700 (PDT)
Received: from ietf.org (odin.ietf.org [132.151.1.176]) by above.proper.com (8.11.6/8.11.3) with ESMTP id f9JBAID25169 for <[e-mail]>; Fri, 19 Oct 2001 04:10:18 -0700 (PDT)
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA13989; Fri, 19 Oct 2001 07:10:16 -0400 (EDT)
Message-Id: <[e-mail]>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Cc: [e-mail]
From: [e-mail]
Reply-to: [e-mail]
Subject: I-D ACTION:draft-ietf-pkix-new-part1-10.txt
Date: Fri, 19 Oct 2001 07:10:16 -0400
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-pkix.imc.org>

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Public-Key Infrastructure (X.509) Working Group of the IETF.

	Title		: Internet X.509 Public Key Infrastructure Certificate 
                          and CRL Profile
	Author(s)	: R. Housley, W. Ford, W. Polk, D. Solo
	Filename	: draft-ietf-pkix-new-part1-10.txt
	Pages		: 129
	Date		: 18-Oct-01
	
This is the ninth draft of a specification based upon RFC 2459.  When
complete, this specification will obsolete RFC 2459.
Please send comments on this document to the [e-mail] mail
list.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-pkix-new-part1-10.txt

To remove yourself from the IETF Announcement list, send a message to 
ietf-announce-request with the word unsubscribe in the body of the message.

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-pkix-new-part1-10.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt


Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[e-mail].
In the body type:
	"FILE /internet-drafts/draft-ietf-pkix-new-part1-10.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.
		
		
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body;
	access-type="mail-server";
	server="[e-mail]"

Content-Type: text/plain
Content-ID:	<[e-mail]>

ENCODING mime
FILE /internet-drafts/draft-ietf-pkix-new-part1-10.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-pkix-new-part1-10.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:	<[e-mail]>

--OtherAccess--

--NextPart--




Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id f9J7WbT01677 for ietf-pkix-bks; Fri, 19 Oct 2001 00:32:37 -0700 (PDT)
Received: from beamer.mchh.siemens.de (beamer.mchh.siemens.de [194.138.158.163]) by above.proper.com (8.11.6/8.11.3) with ESMTP id f9J7WZD01665 for <[e-mail]>; Fri, 19 Oct 2001 00:32:35 -0700 (PDT)
Received: from blues.mchh.siemens.de (mail2.mchh.siemens.de [194.138.158.227]) by beamer.mchh.siemens.de (8.9.3/8.9.3) with ESMTP id JAA04916; Fri, 19 Oct 2001 09:32:34 +0200 (MET DST)
Received: from mchh246e.demchh201e.icn.siemens.de ([139.21.200.56]) by blues.mchh.siemens.de (8.9.1/8.9.1) with ESMTP id JAA18429; Fri, 19 Oct 2001 09:32:33 +0200 (MET DST)
Received: by MCHH246E with Internet Mail Service (5.5.2653.19) id <4DLDCXC7>; Fri, 19 Oct 2001 09:32:14 +0200
Message-ID: <1D82815C322BD41196EA00508B951F7B01B40C4E@MCHH265E>
From: Fantou Patrick <[e-mail]>
To: "'Housley, Russ'" <[e-mail]>, Fantou Patrick <[e-mail]>
Cc: [e-mail]
Subject: AW: AW: pseudonym : small typo
Date: Fri, 19 Oct 2001 09:32:10 +0200
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id f9J7WaD01670
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-pkix.imc.org>

Russ,

you certainly wanted to write

    id-at-pseudonym      AttributeType ::= { id-at 65 }

and not
    id-at-localityName      AttributeType ::= { id-at 65 }

Additional typo : title of Appendix A.

		Appendix A. Pseudo-ASN.1 ...
and not 	Appendix A. Psuedo-ASN.1 ...
Patrick
> -----Ursprüngliche Nachricht-----
> Von: Housley, Russ [mailto:[e-mail]]
> Gesendet: Dienstag, 16. Oktober 2001 21:31
> An: Fantou Patrick
> Cc: [e-mail]
> Betreff: Re: AW: I-D ACTION:draft-ietf-pkix-new-part1-09.txt
> 
> 
> Patrick:
> 
> >1. pseudonym should be supported in issuer and subject names,
> >  but the oid for pseudonym is missing in this document 
> (id-at-pseudonym : 
> > id-at 65 from X.520 2000)
> 
> Section 4.1.2.4 lists pseudonym as one of the attributes that 
> SHOULD be 
> supported.  However, pseudonym is missing from the ASN.1 
> module.  We need 
> to add:
> 
>     -- Naming attributes of type X520Pseudonym
> 
>     id-at-localityName      AttributeType ::= { id-at 65 }
> 
>     X520Pseudonym ::= CHOICE {
>        teletexString     TeletexString   (SIZE (1..ub-pseudonym)),
>        printableString   PrintableString (SIZE (1..ub-pseudonym)),
>        universalString   UniversalString (SIZE (1..ub-pseudonym)),
>        utf8String        UTF8String      (SIZE (1..ub-pseudonym)),
>        bmpString         BMPString       (SIZE (1..ub-pseudonym)) }
> 
>     ub-pseudonym INTEGER ::= 128
> 


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id f9J7C5228471 for ietf-pkix-bks; Fri, 19 Oct 2001 00:12:05 -0700 (PDT)
Received: from beamer.mchh.siemens.de (beamer.mchh.siemens.de [194.138.158.163]) by above.proper.com (8.11.6/8.11.3) with ESMTP id f9J7C3D28458 for <[e-mail]>; Fri, 19 Oct 2001 00:12:03 -0700 (PDT)
Received: from blues.mchh.siemens.de (mail2.mchh.siemens.de [194.138.158.227]) by beamer.mchh.siemens.de (8.9.3/8.9.3) with ESMTP id JAA03238; Fri, 19 Oct 2001 09:11:54 +0200 (MET DST)
Received: from mchh247e.demchh201e.icn.siemens.de ([139.21.200.57]) by blues.mchh.siemens.de (8.9.1/8.9.1) with ESMTP id JAA12800; Fri, 19 Oct 2001 09:11:53 +0200 (MET DST)
Received: by MCHH247E with Internet Mail Service (5.5.2653.19) id <4DLHX086>; Fri, 19 Oct 2001 09:11:33 +0200
Message-ID: <1D82815C322BD41196EA00508B951F7B01B40C4D@MCHH265E>
From: Fantou Patrick <[e-mail]>
To: "'Santosh Chokhani'" <[e-mail]>, "Housley, Russ" <[e-mail]>, Fantou Patrick <[e-mail]>
Cc: [e-mail]
Subject: AW: AW: I-D ACTION:draft-ietf-pkix-new-part1-09.txt
Date: Fri, 19 Oct 2001 09:11:33 +0200
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1586D.48877140"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-pkix.imc.org>

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01C1586D.48877140
Content-Type: text/plain;
	charset="ISO-8859-1"
Content-Transfer-Encoding: quoted-printable

Russ,
=20
I also support the extension of the phrase proposed by Santosh.=20
In fact is there another possibility to get CA policy data than using =
the CA certificate?
=20
Patrick=20

-----Urspr=FCngliche Nachricht-----
Von: Santosh Chokhani [mailto:[e-mail]]
Gesendet: Donnerstag, 18. Oktober 2001 17:01
An: Housley, Russ; Fantou Patrick
Cc: [e-mail]
Betreff: RE: AW: I-D ACTION:draft-ietf-pkix-new-part1-09.txt



Russ:=20

It seems that the phrase "on-line validation services and CA policy =
data" should be replaced with "on-line validation services, CA =
certificate information and CA policy data".  I suggest this since the =
two OIDs you register are for OCSP and CA certificates.

Also, when the name form for caIssuers is URL, I assume that will be =
the location of the certificate itself.  However, if the name form is =
the DN, it will not be the location of the certificate.  Rather, the =
client will have to get the caCertificate or crossCertificatePair =
attribute.  Given all the debate that has gone on in the past, how will =
we know which attribute?

If my assumptions are correct and my questions are cogent, should there =
be explanation added for this?=20


------_=_NextPart_001_01C1586D.48877140
Content-Type: text/html;
	charset="ISO-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3DISO-8859-1">
<TITLE>RE: AW: I-D ACTION:draft-ietf-pkix-new-part1-09.txt</TITLE>

<META content=3D"MSHTML 5.00.3017.1000" name=3DGENERATOR></HEAD>
<BODY>
<DIV><FONT color=3D#0000ff face=3DArial size=3D2><SPAN=20
class=3D307100307-19102001>Russ,</SPAN></FONT></DIV>
<DIV><FONT color=3D#0000ff face=3DArial size=3D2><SPAN=20
class=3D307100307-19102001></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT color=3D#0000ff face=3DArial size=3D2><SPAN =
class=3D307100307-19102001>I also=20
support the extension of the phrase proposed by Santosh. =
</SPAN></FONT></DIV>
<DIV><FONT color=3D#0000ff face=3DArial size=3D2><SPAN =
class=3D307100307-19102001>In=20
fact is there another possibility to get&nbsp;CA policy data than using =
the CA=20
certificate?</SPAN></FONT></DIV>
<DIV><FONT color=3D#0000ff face=3DArial size=3D2><SPAN=20
class=3D307100307-19102001></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT color=3D#0000ff face=3DArial size=3D2><SPAN=20
class=3D307100307-19102001>Patrick&nbsp;</SPAN></FONT></DIV>
<BLOCKQUOTE=20
style=3D"BORDER-LEFT: #0000ff 2px solid; MARGIN-LEFT: 5px; =
MARGIN-RIGHT: 0px; PADDING-LEFT: 5px">
  <DIV align=3Dleft class=3DOutlookMessageHeader dir=3Dltr><FONT =
face=3DTahoma=20
  size=3D2>-----Urspr=FCngliche Nachricht-----<BR><B>Von:</B> Santosh =
Chokhani=20
  [mailto:[e-mail]]<BR><B>Gesendet:</B> Donnerstag, 18. =
Oktober=20
  2001 17:01<BR><B>An:</B> Housley, Russ; Fantou Patrick<BR><B>Cc:</B>=20
  [e-mail]<BR><B>Betreff:</B> RE: AW: I-D=20
  ACTION:draft-ietf-pkix-new-part1-09.txt<BR><BR></DIV></FONT>
  <P><FONT size=3D2>Russ:</FONT> </P>
  <P><FONT size=3D2>It seems that the phrase "on-line validation =
services and CA=20
  policy data" should be replaced with "on-line validation services, CA =

  certificate information and CA policy data".&nbsp; I suggest this =
since the=20
  two OIDs you register are for OCSP and CA certificates.</FONT></P>
  <P><FONT size=3D2>Also, when the name form for caIssuers is URL, I =
assume that=20
  will be the location of the certificate itself.&nbsp; However, if the =
name=20
  form is the DN, it will not be the location of the certificate.&nbsp; =
Rather,=20
  the client will have to get the caCertificate or crossCertificatePair =

  attribute.&nbsp; Given all the debate that has gone on in the past, =
how will=20
  we know which attribute?</FONT></P>
  <P><FONT size=3D2>If my assumptions are correct and my questions are =
cogent,=20
  should there be explanation added for this?</FONT>=20
</P></BLOCKQUOTE></BODY></HTML>

------_=_NextPart_001_01C1586D.48877140--


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id f9J73Q627487 for ietf-pkix-bks; Fri, 19 Oct 2001 00:03:26 -0700 (PDT)
Received: from gorilla.mchh.siemens.de (gorilla.mchh.siemens.de [194.138.158.18]) by above.proper.com (8.11.6/8.11.3) with ESMTP id f9J73OD27481 for <[e-mail]>; Fri, 19 Oct 2001 00:03:24 -0700 (PDT)
Received: from moody.mchh.siemens.de (mail2.mchh.siemens.de [194.138.158.226]) by gorilla.mchh.siemens.de (8.9.3/8.9.3) with ESMTP id JAA17952; Fri, 19 Oct 2001 09:03:09 +0200 (MET DST)
Received: from mchh273e.demchh201e.icn.siemens.de ([139.21.200.83]) by moody.mchh.siemens.de (8.9.1/8.9.1) with ESMTP id JAA20026; Fri, 19 Oct 2001 09:03:11 +0200 (MET DST)
Received: by MCHH273E with Internet Mail Service (5.5.2653.19) id <4DL2NYA5>; Fri, 19 Oct 2001 09:02:51 +0200
Message-ID: <1D82815C322BD41196EA00508B951F7B01B40C4C@MCHH265E>
From: Fantou Patrick <[e-mail]>
To: "'Housley, Russ'" <[e-mail]>, Fantou Patrick <[e-mail]>
Cc: [e-mail]
Subject: AW: AW: I-D ACTION:draft-ietf-pkix-new-part1-09.txt
Date: Fri, 19 Oct 2001 09:02:50 +0200
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id f9J73PD27483
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-pkix.imc.org>

Russ,

I agree with this replacement text, which is much clearer on OCSP.
But do you not think, that the last paragraph is redundant?
It repeats what you say in the two new paragraphs before and still says 
that RFC2560 defines the access descriptor for OCSP. I would reduce it
to the last sentence : "Additional access descriptors may be defined in
other PKIX specifications."

Patrick

> -----Ursprüngliche Nachricht-----
> Von: Housley, Russ [mailto:[e-mail]]
> Gesendet: Donnerstag, 18. Oktober 2001 15:56
> An: Fantou Patrick
> Cc: [e-mail]
> Betreff: Re: AW: I-D ACTION:draft-ietf-pkix-new-part1-09.txt
> 
> 
> Patrick:
> 
> >2. Clause 4.2.2.1 Authority Information Access says that RFC 
> 2560 defines 
> >the access descriptor for OCSP, but in fact id-ad-ocsp (id-ad 1) is 
> >defined in this draft and RFC 2560 imports it and uses it as 
> base for the 
> >OCSP OID arc.
> 
> Tim Polk and I finally talked.  Here is the proposed replacement text:
> 
>     4.2.2.1  Authority Information Access
> 
>     The authority information access extension indicates how 
> to access CA
>     information and services for the issuer of the 
> certificate in which
>     the extension appears. Information and services may 
> include on-line
>     validation services and CA policy data.  (The location of 
> CRLs is not
>     specified in this extension; that information is provided by the
>     cRLDistributionPoints extension.)  This extension may be 
> included in
>     subject or CA certificates, and it MUST be non-critical.
> 
>     id-pe-authorityInfoAccess OBJECT IDENTIFIER ::= { id-pe 1 }
> 
>     AuthorityInfoAccessSyntax  ::=
>             SEQUENCE SIZE (1..MAX) OF AccessDescription
> 
>     AccessDescription  ::=  SEQUENCE {
>             accessMethod          OBJECT IDENTIFIER,
>             accessLocation        GeneralName  }
> 
>     id-ad OBJECT IDENTIFIER ::= { id-pkix 48 }
> 
>     id-ad-caIssuers OBJECT IDENTIFIER ::= { id-ad 2 }
> 
>     id-ad-ocsp OBJECT IDENTIFIER ::= { id-ad 1 }
> 
>     Each entry in the sequence AuthorityInfoAccessSyntax describes the
>     format and location of additional information provided by 
> the CA who
>     issued the certificate in which this extension appears.  
> The type and
>     format of the information is specified by the 
> accessMethod field; the
>     accessLocation field specifies the location of the 
> information.  The
>     retrieval mechanism may be implied by the accessMethod or 
> specified
>     by accessLocation.
> 
>     This profile defines two accessMethod OIDs: 
> id-ad-caIssuers and id-
>     ad-ocsp.
> 
>     The id-ad-caIssuers OID is used when the additional 
> information lists
>     CAs that have issued certificates superior to the CA that 
> issued the
>     certificate containing this extension.  The referenced CA Issuers
>     description is intended to aid certificate users in the 
> selection of
>     a certification path that terminates at a point trusted by the
>     certificate user.
> 
>     When id-ad-caIssuers appears as accessMethod, the accessLocation
>     field describes the referenced description server and the access
>     protocol to obtain the referenced description.  The accessLocation
>     field is defined as a GeneralName, which can take several forms.
>     Where the information is available via http, ftp, or ldap,
>     accessLocation MUST be a uniformResourceIdentifier.  Where the
>     information is available via the Directory Access Protocol (DAP),
>     accessLocation MUST be a directoryName. When the information is
>     available via electronic mail, accessLocation MUST be an 
> rfc822Name.
>     The semantics of other id-ad-caIssuers accessLocation 
> name forms are
>     not defined.
> 
>     The id-ad-ocsp OID is used when revocation information for the
>     certificate containing this extension is available using 
> the Online
>     Certificate Status Protocol (OCSP) [RFC 2560].
> 
>     When id-ad-ocsp appears as accessMethod, the 
> accessLocation field is
>     the location of the OCSP responder, using the conventions 
> defined in
>     [RFC 2560].
> 
>     [RFC 2560] defines the access descriptor for the Online 
> Certificate
>     Status Protocol.  When this access descriptor appears in the
>     authority information access extension, this indicates the issuer
>     provides revocation information for this certificate through the
>     named OCSP service.  Additional access descriptors may be 
> defined in
>     other PKIX specifications.
> 
> Russ
> 


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id f9J0fN402533 for ietf-pkix-bks; Thu, 18 Oct 2001 17:41:23 -0700 (PDT)
Received: from relay2.softcomca.com (relay.softcomca.com [168.144.1.68] (may be forged)) by above.proper.com (8.11.6/8.11.3) with ESMTP id f9J0fKD02529 for <[e-mail]>; Thu, 18 Oct 2001 17:41:21 -0700 (PDT)
Received: from m2w071 ([168.144.108.71]) by relay2.softcomca.com with Microsoft SMTPSVC(5.0.2195.3779); Thu, 18 Oct 2001 20:41:24 -0400
X-Originating-IP: 211.47.195.11
X-URL: http://www.mail2web.com/
Subject: Re: I-D ACTION:draft-ietf-pkix-ipki-pkalgs-04.txt
From: "[e-mail]" <[e-mail]>
Date: Thu, 18 Oct 2001 20:41:56 -0400
To: "[e-mail]" <[e-mail]>
Reply-To: [e-mail]
X-Priority: 3
X-MSMail-Priority: Normal
Content-Transfer-Encoding: Quoted-Printable
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="--NEXT--2DC45F20-F1A1D859-E9856485"
X-Mailer: JMail 3.7.0 by Dimac (www.dimac.net)
Message-ID: <[e-mail]>
X-OriginalArrivalTime: 19 Oct 2001 00:41:24.0470 (UTC) FILETIME=[C7AF0960:01C15836]
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-pkix.imc.org>

This is a multi-part message in MIME format.

----NEXT--2DC45F20-F1A1D859-E9856485
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: Quoted-Printable

Sorry if I've repeated errors caught by others.
I'm time traveling in Korea this week and for me
it is already tomorrow.

Search for "the the" in the text. 

Note that there is a reference in the ASN.1 to an
X9.57 OID but not to that standard. I would guess
that FIPS 186 does not contain the ASN.1 notation
this OID identifies.

The draft refers to DER but gives no reference to
X.690 where DER is defined.

The draft refers to X.208, but see the notice on
X.208/X.209 in the attached.

Notice that "{ ansi-X9.62 2 }" is not a valid value
of type OBJECT IDENTIFIER as the dot is not allowed.

The extension marker appears to be missing in the line

  cofactor  INTEGER  OPTIONAL,  -- The integer h =3D #E(Fq)/n

causing the inclusion of the comma to be in error. This
marker ( ... ) is important as it alerts implementors 
to expect future values of type ECParameters to contain
additional components.

Type ECPVer is not a constrained integer. It would be
safer not to lead implementors to believe that the
"-- version is always 1". This condition may only 
hold true for this document. Best always to plan 
for change.

Phil Griffin


--------------------------------------------------------------------
mail2web - Check your email from the web at
http://mail2web.com/ .

----NEXT--2DC45F20-F1A1D859-E9856485
Content-Type: application/octet-stream; name="report-of-the-Bangalore-2001-ASN1-meeting.zip"
Content-Transfer-Encoding: base64
Content-Description: report-of-the-Bangalore-2001-ASN1-meeting.zip
Content-Disposition: attachment; filename="report-of-the-Bangalore-2001-ASN1-meeting.zip"

UEsDBBQAAAAIACyeUit6MUrZKCIAAACoAAAtAAAAcmVwb3J0LW9mLXRoZS1C
YW5nYWxvcmUtMjAwMS1BU04xLW1lZXRpbmcuZG9j7Fx9bBzHdZ8jKZIn8iRL
pCRbkuWxQsukfTzxjqRIsbYhiqS+RVLk0ZaBNMbe3ZJcaW/3vB+kaLdujSRF
UBSF/4mBJDWCtE7SIE3hGkjRBmhdu7ET/1FHQBoXDtJGdtwAQWsgNlQjKRCp
vzcz+3UkbcU1UMTlyI97Mzvz5n2/N3M0L39v25Uv/dXu11ldu481smvX06w5
NpYCTAWdmxg7p8auXb9+nYYmAdc32m9U+88vP8/O8nQTY7/Y/lyoWTSM7Oli
bAsrXShdeOPeN+5lq1q6aSfrGWHs9x+Q8PqtjN3ZwNj21VNFu3596/t+Dpop
fhabWPgk2IzPn8CzHc8L6l382RnD8Jga/1bb6ucwnu+0yfnNQJaNzX/1LsYe
gVnfh/Gd6BfV80K7fH+jzznggTDYA3fJ/o08IXA2DWI4FtZyjHnoP4rxHWx1
C/luX+Mle3/6HlX75jJqvF6edXiD/hN3SXkE6+qfNO/bbDWe+v6c2j9owfpf
t9XjIzztzRG+kQ7GDkGfP+tm7ApbzecHbSm1X7B/oV3a5T+82P/Jg+efT5E9
3dMS2V1Az8s9jO2tw1PE8yt49jFpf9T+Xc17M5dcH/RTdfoL7PexOv7Wezaw
1/DzZHGO9/Kibuplu1r1LaOseYZt8VlPsyqaUzEeUX297NlOZrY4N/4gPz4z
NTfNhzKZo5q1oJm2o2d5YZiP+gu+6/En+RCm1zy9WtIdXujry2cy53zdJTzd
bs9I+lzu8EEsnp2amxmbuEv1+czo9PTUTHFibiaTKZ4snpkYSZ/Vdc+wFrij
12zH4/O2w+Xah1a1zIycA1KDvTjNzOfS8f4IHy25nqOVPT67YnnaJT5pe5LD
KUvn3aOzk7l8T6aQntFqhE/3ncxZJ8enTGPJADfjfsk3XNe2MscczSrrgeT4
zIHxzHjxzMGzs/dnCoX+viF+RrMswjumV/RLanoLpo/wu/v7eYEfPsT7Bnn/
MB/syxzTLtUNH+YDg5mJ3qpmYEEHP/Hg9MTMmZOTpzmNePaIIigXEnRkXuzg
SXpyRFOq8wZm7Whp6c/FJO36pudm+nP59MTYJPqm5ukVvmw7FzOj3LQh4XnR
44uayxdsCM2wPJvT5IrvEA5vUeemBkPwlnVzSedV2/IW3SyHQeGd4fKq2mwZ
GMo2yLGgETECcc0blmZyvWLIgXmBruJo8x6fETaqwy6Fws7nDh0u8GXDWxRz
7NIF2KiBDUFOSQfpWmVF2Az2cLEH17zE/jlexLIFx/ZrghnXL5d1KKsCjkgQ
trlEJGimySE7GJFkgabWHHvJoJmSME+/5NEiIqOkuaDXLvsg1Mvykk+b6g7E
5HINcnEWdP6wr1me4a0Qe+VF+BAwCRyE3wCxDsm8pjnagqPVFl2iFMsXwBwh
WdS1pRXoQquQwGjTCYgLjILx8qJevogx8EqEg6dFRR7J2nEgIlNIpap52CTL
3ZpumoJP7I3tqlXNiU1WPK/UdAezLrpC3orVgEuugT01n3e7dlUXW/rQo6PP
g3eoGOL1DBBk6cQrFsdQSo5BQ0+OS04D9QtDW6Z1QqGw5WUsJ95CIwIt05pD
a6wK9fOHYA+T9pKIPrnMScG50ACYJiQPUzgQRAh7ABuwcGEn1DlDhjumyR3B
BLDSXFu8LAxK3LkMfAG2WDPhScoGoEoNxutg+SjZqBAM1kkrxQfXFxFFIBJh
RqJ3jZJhki1YQSAiAyvpukVWVvHLeiWQipCGUI3cWVoXcWTAXJV8eGmFG/Se
CNAdZbSBCxCbwjfL0qyx6zKvmQhV4DKQwTG9lDt4VnNgOojehVDUYHH2eH6I
dxue8F3bMRbIW2FQSRSRj/WQfmynogvjxFRsR3MMq+YLmUmP9tx6siHiYug2
pmuTxg0LK5XQICdLOqvSjRRpKMQ6gVN4IvHl+NiakiAxiFiD7UKz7vYt5Z09
REZkOiGXAmUmM264Zd8lolxoDxFIUFzSF3xLxqdzuWFkOOWsUq2CSjIaC8KQ
/kixaxRivETUIzH3FmE98Klab4H/Dj85O3Xw5MQYHxvn+YGBoUMFjCqMWoX8
JcQncSwvGlCgcJ4y3MHhJRuUIKh4PC9sQnwsqBBrOEo+FBMVAlqqIh3ZNtFo
SjnfTfJE5Cgb80HBEKLBCs8u22ZWrSXL0S9pIu4Qsa6G+FAyPLfXtnox0Isg
APyuWl72EUcg/P00RdBZWvF0d39yuxwyVCF9/uyZ3mSGCjzPVa433CfTjuzk
eUVHfpHRju/Hcn6/Zvp6WATsF6qVptTtI5CDK5qF9RXDhZGviO4SLXJ7Av9Z
lWly8JMhYbnuRWmhFLpDJ0Q/sjzKF3Vx/E7py24oVk2mGBEHwmAv4ykFiyoF
eREciE6bfhoW4jGsn0KbtGFXJYUKggGyEEUcGRhk2IZg8JAC97SLUEi5bPtW
0kerWkUP8hzMkR+DLZbIqeErFpUCKl0HO1Je8PTyIlWVZk+YDAMOEgZG4zL3
i3SVdM9Y0tGNhUWvd1nXL4JmrSKsJ6dixTL9GD85i0pyZur+USjKhunweQfF
EK2dOy34O6XVoH4pclfmKjfOVsBSFFaCyHvBRrEjXRoTe5RCaE1UL/LuudM9
HJlbjycZbA0LwiSwq5HaKjLGyzpDxPiTMqoihPGajWhSMkUpA6vxqF7VJN1E
cQXl2wKpVlByETZo6pUFpRpDyF2LpC1ZkHXOsu2bFW4aF3UZNzXrYoQWTmvq
2oIfimzZ5vsXbBtWonkoLOCEy0LOwIpoXYFNwCHBJdK3YftupGuuO47tECGw
YnibQBfWAkHIXnZsvDs6eSwWEl0ZgSJWY0JTmS6SKt6XwsqDihlZYoI4EYWF
gFe/XRt5okogTwV/tFeooCAhBeWIhgS0vFZN2i/pE/MohgiVxBOTyuvAMFc8
NozCpWxXVH6FXVKAiepHWcv6FCM0V+3p6sItpV4ngtUzvqlDeryb5KeVEPJB
O4o5FFjYNs5qaSUpBrLfSUEdXh61Ectkxq3VELKJ56DwDWQayIQwVbWLQdEf
6kf5f64nHrCyfNFe1pGIsiJzU6iJCqwaWZCIlCIGGI/IgCCiXuZDLuL6VBHH
V2t03ndol/U0OxDTrMgktKYKOYU2TsqbhatUtUjj4nwkleWh6HUTJVEQ/vR5
pDaDskNgDq5gR1iD5mm5ZAlIQWIFZhCUgtD72FrZJaqdA4kpeaHGUyVeXXVH
mbU/XQw9eQz+YyyQGDIqQAW1HjZSaMPMBm41vsZavxqeJLEKR9kYl3WnMhm3
wpRjrwrLwgxNiUmrS5RAE9szq2qgKtK2DxNwFmiFC73CmiOMdRUyqVEWX0rO
lOL1SzURRFaLT1TEwYkSshtIF8OYO+3YdCYV+KvweVPYqUYpn0yPF2ePwo6W
dNOuqVORXPeAXkJ1hoAuqJYCEBTNej6887gI5UM0zTVI99I0oJoImUGRz7qA
ClbYoEgUGt5XqIDC+2PFaZEmYkVavBK1yTelG/N5rSxPKIF7BacXOK0nTiN0
b0T1BIjAYVIEKhiC69plQ2ymi3sMWmHaFTqV4fhU1S4AXXRoV6WD5DMpPkNU
c1VRlSwBkYbMmIWidF0doHGmzorV4ZksESKl6F3lskI2cpukiyN4og7UeVAn
hSX1GuttESZsZ0Gz1A2ZG5hLDenG9CngdOu5hVyWLC3LJ4qzJ/Fxonjs0z3g
v+72qGJUhJHImk7FBFcElwuyrPQcA34haun5+eAyTAQ+qXJxYFEyVHaRFRW+
UfZR7skzfxCsQymGR1YlL8VpVsU5Co4oRTxZoOb7gxs+utNTJ4WEgONZt1oz
yEmJKzrNU4UubVAcUqFPXXNXhKWj0tRdWXkizzm98w7iYIUOlcgzYEsW/HxU
ep5n4PiAMkSVOupqkOwfNS0ivTSEeZuOmsQrOHPjSoxo9Gt0haJXRngx1z/M
uwM+UKgWcwN9fby7vy9YhrH7c4OHE5POy0kDA7FJ53PDOHJ0HwqHcjj75QsD
w3XIYq5C5J7PDRKqQn84RYjjfG5IDEfoRKlFlymLopBDZHdtCrqBQiEmITYS
DGo5N0puYp64x5KR07JQ3pdlmlXLpZeHx2AVqWThQ3KM38glPZTMDUHQC3SM
4hf2Iy7UXLjV0ZXQcvqzwnqyfHAASd+Gt4LSBQM25kjC4hGmPmz05wbTdT4r
zDqsbIJcMnuch0E5M2nTCaE/d2jNtSruN6y9lrJ+XuSUHB8YIX5jR/cw2gTJ
LCv5j9IvCnVtRfIVXEnxwqDAWhiJSrcx8m/bjO6iu3G+7vk1sMHmRqs4Q/SP
8OhQGxQg8Qng4X7dkdcnvkCgbkky8nwsJoG0GJrJGJrDaoOQckeGixsjtD83
tEoF8YujxD3t6msoKCZKtaomRG2lijsKWGsfsNeufta/4aJdgugaxRFZeXl6
1R2R+pOyykONiWu8QJ5rVVDqDkzEZTfKT7LGjx3ZK8FpVBC3JBUmDrmJEXFg
MNWVTPJ+xOXdMWGUAkZkyR7tREjUaUCdyYFyTcqli0USDCRWkhV5KO6cEM5A
zLjpkibInBRTEORpWBANkxhOjyNSBS51PlfoG1axr9B3OHPSEhcRTkWky/Cu
n65XxCHEVxU2DjOWrzkrIrjIpIOkR9/YmIZmuCQQJftYCeXKXEFV2Oo6WVS3
VTpF1dEUXSeYCFtEtCwman7JDKSfJeeTxyIpr5XE6QlGX5aqIDT1LqF0H91e
kUT7VORXxZ4gTVP1vbivEThpbcysVZrUxXlGjwqaKMS66ms+N5SAYMNdpAPv
QC59zPd8J9S2K0ww8olgWFz0KE8eyUyVPZs8fqg3n5fRnsiacvC+YmfCgDDY
mz8UvRZ3+JlAi/mB3vxwVjKBl7N2FRavexn4rSPVPNQLPnlsznHd0pc0aSJU
k2fOamQNvYWBaM5pW1yMwMxP+Ti75ft68wNSZBZdbyAHZaIvLocD8sXSUccv
abwbSwNieiJWaJvD70EK2KKX/fTyDA4fQUE+O3aIpBW+E/RFr0ahkYSI6YIG
J3tHXhUH11DiVvhUcYznD86O8UO5xLejmQa+X50M94tbSEuem+SXFmQXYEkc
omCQdUde8T3LA4h7pGsoiIoDJ3EGCaJAVdcsNzT28Asn1w9OtSZdFAhTEpeT
sEQ6r4sb3jB3Cz8XTqNu9E0oxFLX4sEsZGBRLXaPjk73cC1RlNeRP5pD1SVO
CRV72RJfly0ZGo9OGapODq7xZCVcW9Tc8DQSEleT22ajq4WsvCQRl1qqdDES
NWlWfuM3IO8q1QVHCbWOJS6gw1gGWg5SCBo3HPEde1iaiZIeKguuVyTRVWFy
7qJR47bINPLsJS4Kq/JLp0ADYAJ0o4AHee+paZR4vbyDT48en+CdhR28ty2D
xjbaRttoG22jfYRbE2MHAb9Fv60GeArwTcDLgB8DrgDeBuzYxNjHAIuALwO+
AvgR4F8B/wZINTPWAGgENAF2Ab7fytgPAAfTjOUBQ4C/bWfsFcB3tjB29zbG
nt4OfICrgHcB1wDZTsYmdzA2BVgBLO9i7Ffsl+xd9tPXXnnhlW+98LUXPvs1
/PijT7NP4t9j9O/SYw5+mvgoW9uh1senTjF2DtB24q5U+HkwGm8NPrBGzGgf
O3UzC0duCj5VT7Q3uQB2oKH18cYLhLu5NQUs8elzralwHpeT3mPG1rp3u+r6
wcTOtQbZzfER68R2MerhyfYBz30Rq6veN02famSsRezWzRrxZD2B/u8F3AeY
BywAHgE8Cvgs4EnAXyubIHvYqWzhMOAMoAj4Rdym3o53fhTv/CDeuRzvvLzu
m+/cWOeFeOeb8c434p0/i3c+d2OdRNvcwTqeZqwTsLMrdXKefgOepTtY5qVN
LDXUgJc/x8ufQ9DJMfrl0MaulBg60aimXWJaV4p0gDf0KbUb5rUT61pSLbtT
f7jpyCbqNKHDWsJPHU9/F/vvlNjEyJZPff+WA5VmrJ9+CQ7HrjenUuy3MQic
8XU/iWP/6h0vsG209+u3wxe6GNsNuHbt2rqcb7SPVmtIpRqLKqbbgD8APLUp
GcOzgCutMnYPAz6/mbEvAMbbGJtoi+L5f8URf5DOs/HOn8c7T8U7X1i38+SH
2klsGjThp41aVyNL7WJt2+BIN6UGDzS92PDVpoHm51toymZy+s2p3Y0NQw0W
5gvPPypCxa4gWjQ8abLWV/tYw2zj32xrOcCa9S2rtmqe6qwf6nwXi3e/Kvyb
YE/0cW/08dbo48CrzSy1udFk2ruNzzWuGbe2xXNxNpaPf6VycUenzMdBLl7a
iXwMWNol83IXAtYdgG8AfgL4GeC2PYz9d5zyRHJ4N95JTFu/k1iTwPYf8c4b
67557QN0/unGpiXyzvpv3qsJo2mB0aRepFxxSSiJtVGEb1Sxe7ArdXi8Cdmi
MS2McKiLDXexE11iZKuc2Nzw0Pa/FyNr26b4n7VguTE73hHoMK6/VugvvUfq
0dwLHwcM3srY+X2MPQj4PcAXAXs5agfALOCfkUOu3C5zyRsqn2wGtAG2AbYD
OgCdgF2Am1W+of/H6JdX37r61hUAu8quvnX5rauXv33179jVZ7/+7Bef/TqG
1hfc/3Xb1XdqT6xCY6i3WJPfmmqPj7MdsiKMj6EczASjt1JvvRrwNowf+Qxj
Y6d2stMnWOx9Gu/TTbdEWOrKzWQ9G9W67YQqWM5Jxz7gHwFvkt6h67v3JvX+
IOAvADPr6P5hwB8D/hLwQ8BN0P89t9eVgf/rzk/jnTfjnR+v2/mXdTsJbInO
9+KdRAx47kPtUNvSwTYfYG3HWtfyf/LWuhqyVTiuWNJMfo5krTrCr9eMI1vU
nLR4t5hKXW5o3vqpyw2fALCdpCcd8DjgT26Xfkw+3NIlfZj89JaYr34QZb0e
7ySOAz+MdxJng8SbRCeB7f9Ta9oanhKotzeI4U3h6WFt/b+XjbXdyTb3pQ5M
p1n+icXUbc/8bo4/893R259xmvYDPvaE09QFuOOZ9yFto/2mtnEFG22jbbSN
ttE22kbbaBtto220jbbRNtpG++i2TraPbWYpZrCtrDEcPYL/3r7egGc7a2aT
zGYOqzJN/FUu+ptWXNxHT51qYOcAD51INWmnbg4vlb0T9PfE6ts9bPTIO9e/
hGc728nGmc7mgdEHTg/4pvHZASyInzW2iLFj2NcSfwMrall225EUewdPouwE
sGisgp8O3mXAQ+alVia+Bkk1iNkcvDWk5GzCZwNfMPumutnn2bWpFDuaOo/Z
mzDPZmWs78ObfWybvIcdPNBAd2eDXUx+AXN4vIG+hNlX/+se2qlOEkcrxNHq
t4LCa1tTbH+qAsxtbJTNQqY5lic5Kh7pjzodYNuxyxbWtLsx+tIm37Vqt51y
t+31u3xc0F9IfRy7tDIXsqxip2l2RvxjbA/rWI2/4+lsin4PQfJw5DNNUO1e
dvrEKuz7sBqyxDMD6RTZFGjn4IEsohM/u9nckT9l51Ld2D0NzaxAi//T3rXH
RnGc8W/3dn1nG+w92xjbvI6ER8zjal61gYoYCsEQwK4NhaA0MeA77GB8xg8S
kqp1GpdGUdS6KWlRShTUgKqKJKJN1DZSVVFC1CK1EZWShlaq6rb0j0ZNRKL8
kVDA/X0ze3t7t7f2HkkgNPtZv5udb2d+87jZ2flmxnNc051oW120ByHyaMUc
ZdUcdYPI505lA0Jq1ndIVIWSNWQUV9R6sIomUvrqiJUtWkyr0CJ6lMUi3VWo
zzakHUEOY/SAaD0hxJZzpSGLYRnNRm4fVpYhVlh8C3vxFxPfRYSaRevk3LNm
Fz6Z5YvrDVSKgRSnoiaeECmOc8RNpatSpYhVJqqyWZT6R0oz4gRpHULHRV65
lXHZq2RZH9NPFQ8+pocH91+6B24rXPeyz6JqlOKnyizRrprE8xNDHjbhudpL
O82WTrSQpqCOTisLEW689Rx0mU9Dep4nkybyXEezwP1HpQ5xSrLEyVZHAWqY
o1BoItpaRC5gII94tKpVcSm0eVz5JE+KZPdzAB8uuAKIA7uBB4GHgCdJLsv/
nOQGoWGgHLS3AkuBDcBmoB1IAAeBp4GJSG+eKncr1epEdcBTSPiHwGo0+zXA
y6i/14DfFhDNHY/wwLEiouPAFeAqUGpADzSGiQ4A+0uI7gf2l8IFZpQTzQSe
B/4J/BuYhtL3A68AF4D8CvADncDLwJJKoruA54DmKqKvA88AkyejLoAWYB/w
beAF4C+AMQX9JxADHgaOAK9PkScuBlGnIaAiIlflDpM8n0/IAON6a6quSWPJ
KJrSMTQ/uaGaI2QToeEchh2aiR40llwHjTOHzjDXM4fOtJw5tE4MHSWMJR9R
42zhzjBimJCmcbZVZ6zSjFj5kcwwrFEcGtWhCTg0mkOjp2my5TCz5vMiSYVd
ozg0qkOTnp+xn1xvNRaKZIZhjeLQqA5NwKHRHBrdoclzaIIOTShNk7UUNXbN
U/Xop9M0BZQpHKZ4jDBjSTgLyviGJndu8Wr+BDJ7Yk3u4uXdYLwjhHcF8H1u
+RUAXlUYPZrnlmpyNwC3leOo+r8CPHzmd3vptrKRCYNc+/lAoZli6fSykScH
OCq/49eS3Nw1QUm9y3cCu4FnkeCJcrmZIR+YCVQDZ4HfA28BbwPFyFQJsBwZ
WwEMm+/Cy1PR8qal3okFQBlQGZHvxiBKEMT3LDHZhGa7tkM13eSfijFLmajJ
RjGq3Q/w+CcCa6Yfo61++HvxxyP6GowLl2FEzqOjbmE/9dF8uHF89sG6icFd
hfFaF8Y7bFclRMj5GKnV4G8BrqSVwFc8towhVocIHTXHjH4ucsvFdjMXWzH2
3oT7jbhqgX8zraGNGDvfDbdLpLxbxOoT16lxPduqfWKsv0Okvw9+Hge3mWPg
j7tkO5CHts94yT4dLcfPxfXMRQlabDt0nSIv3chFA+5F8N7ogT+OPw5f79Lm
eV6pl/aI9tz9ieazkA6t0A2FxmnO4+sVOlY/I+x2b1788FTtxZrXRooz/wy6
tOCtW4a+dqjceY9oy31PN138yuKF2e6djtduUYcGN2Xj/LLy921PnD76YLZ7
3wm9u73QJZ8PbTixp+BPJQezpffepOq977zz/slsnH3Tnt9/5tUz07Pd47Ga
Ncq0SSHe5sWD7Up48PDVCTwP0q7k3QN/K/yN6xX6EpC4DdF/cfHjojBSUXn+
IEVxTrUozql5vE/SjWLIjeKoblEc1UFxVJcUGig0SZGg0Sm6QxZFdwgU3SFJ
oYNClxQ/HiMX9YUWRX0hKOoLcy6IUWRRGEWgMIpyLsiwYVEMG6AYNnIuyMlS
i+JkKShOluZckIFyi2KgHBQD5TkXpKnSomiqBEVTZZaCSENDoUwJjNI6RVQ5
ZkbU1DS8t6gcPkqKmaYS0LNG50ZdcyW9UddcQXTdjB7F+NaiCOZEEbRRRJGf
FE1+Fpo6LTz4u/8KmjoNNHVaK/ygyc+giWJkbqMqzIGqMAtVFEW109kPOAhY
T23rpfSntvUS6Ma70EVhIaZR2nrRMSiLR6GMokbTacMZtKFgePCDDwRtKAja
ULAVftCGx6CNwl6Vlq9bE50UCA/+67KgnhQA9aRAK/xmEy00c5VjVG9N1DW6
9ybqSuE3Udcm6tqWbmATFR2xkcppekdci47orOyIarkjqkVHdPZKTu947xRD
bhT+CzpFcRO9oD/xduGP/VIUn8GmRU4Z3TKxUZz3h4/+u9kT5Y1+N5NTPHeg
8+WDMuBG4b0DdaXw3oG6UnjvQF0pvHegrhTeO1BXCu8dqCuF9w7UlcJ7B2qk
ovrvZjcK703LlcJ703Kl8N60XCm8Ny1XCk9Ni7t0nkAlm/Ckqd3PE5d2P0+c
2v086Wn380Su3c+TqXY/TwLb/TxhbPfzZK/dzxOudv9YP96aLmkvuDQZ7R5L
chmWt1AFVCJNTd9aVBmRy6dc64wQ8eExEt83Rw7mNyLckXplIOknOvN4GymU
8idFNcwLXjluZdZ6zioHDNIW4j2DvNvsfnyyNmSLKkOxS2JVNvOa1+3Xlg9x
FtW8gK7pakD71jJKkxHT3UwdYoa/l3jfXAzp8d42uRrWhftLwKOSriuqEsxT
raGNYaMa4I8WOiD23CXELtlFs0TqhXmayuKa+kqxqiF31q4NDyn2hX5ZxmDI
sDRyX8NGpBXBJ69H7KJ2pEg0f2TRSISK4lN2E92+RKQdDOSrqq5qrmnzzsV+
kb5c7ZGlJ1qeJ0pMGWLYrgf4Y6u5ItJmur3Q3YIBw4LQoxV08ZyafE7fPbT9
IOPcorsOykFis0b0bAWXkH8xVaOAsdhGrlgNjWV6gC4a5Mu1SY/Wox2nl+gb
D5fU8FdYKXba8n6OlbauK3b6H792IRhV1NTlwkfC/D39zWF+pMvISIl5VUTr
8OxtEe0utb9crq71mWF0tKmY2Me6x+O6oC+5yVV0Btp22/doCj99w9985r0P
G9uNE98N0dzZL/65BjruWUrM+4dJtoCjJPd7/ZLkrrMzJPeavU6yJx4mEjbe
f0i+Oi6TNFYrTK4Zivxl73q4/KLiXb3cL2xTSJhObYo4xYS64bLd84AiOyN+
x/Buq0cVmY8LGu9il2H4d403iV8sjLYl+qRe9CjQTzXz1RvbGdtDPXute/Bn
XnO+JQ+JcJxeU3tHZ2dHd6QhGlnb0xGPd3RJfs7DQuroTIbb2LGrJ9GbiPfx
IdptkaXRGuJXHNEdr9zKjrg+/+bdodrfKOL6alc//3K0/Tpg5odd7jXZ5Z5z
jMfMF1988cUXX3zxxRdffPHFF1/SxM3+Z436xh/eOBKdZHzvB7D/5334wmro
9AzdFxR5IDPb62yntpO0v7tJzgF8laStPUjyP5AeJ7l4eIikrc//M2kAx0ja
zM+R/K+jl0ja/r8yud+kdBuf5xlg4ws7mOcOA2Y4dnlmi923i/IpOfHt5k41
ZL6zzBmMM2SSyemCzR19nTFKGuSQ85SywyOmuo5kpHrTz9ecr3ub1q2+t2HD
uk13tljlWAl3yCRnHoP2WXx2l+txGjAX4FmyDnFmQoKWZezXj2bZr19PceoR
M9m7xB72GGLEcM3z21HTJZM/OePqiy+++OKLL7744osvvvjiy/+fJG1UtjPZ
pmZbk+1RXvfmtXpep+e1ebaX2Y5lm5zX4tleNkja9LyGz7Y7n43BJ4qw/c42
fgXJnSZ8wkjy9JApxHMOIyNsb0aA6cR7hoh4QXwGMNO8P5v4RDmiamAOSdt3
HjCfeIOyPDWsBlhAvOZOtIjkPMAS4PNALUlbfCnJ48aWE59AKE8aY/7bSdro
bIOvIt4LJX8HYY15n08paQDWAeuBOwE+Q2+jef8K0GReJ3EzCu90S4hTINaI
0yB66ADlIuWkK0kubkN5+XIu6ZS8fYc97KlXFz3CexqaydxARlznfObEDrpW
KSDVSp9lrPAsYuOTIa8X0GakvlPMilyLFJn/9pBL+rOAC1F5vVXsfWpDPfCZ
Av3WqRxepQrl5+eVn1uv6bNUm3sCdWoRqfK8En/3yXMJe6zTQBKj7qq67Rrq
n08BSta/7ih5bvmpQ/rcb+WSvmiUhrxWzPMbu6kRreC+UWJllxKkzy2e+0uv
6bMkU5Kp8oxcHzWJZ7Fz1HiZUo4SjFX/yecu6drvsedm7bt8+eii4NsPFMi2
m9l38/s7Yw/b6sSu/r2xrj4xJtjYwjqoxMPE19Hk/Wgdvb/0Z/vIl0+5/A9Q
SwECFAsUAAAACAAsnlIrejFK2SgiAAAAqAAALQAAAAAAAAAAACAAAAAAAAAA
cmVwb3J0LW9mLXRoZS1CYW5nYWxvcmUtMjAwMS1BU04xLW1lZXRpbmcuZG9j
UEsFBgAAAAABAAEAWwAAAHMiAAAAAA==

----NEXT--2DC45F20-F1A1D859-E9856485--




Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id f9ILnrw29141 for ietf-pkix-bks; Thu, 18 Oct 2001 14:49:53 -0700 (PDT)
Received: from e1.ny.us.ibm.com (e1.ny.us.ibm.com [32.97.182.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id f9ILnpD29137 for <[e-mail]>; Thu, 18 Oct 2001 14:49:51 -0700 (PDT)
Received: from northrelay02.pok.ibm.com (northrelay02.pok.ibm.com [9.117.200.22]) by e1.ny.us.ibm.com (8.9.3/8.9.3) with ESMTP id RAA271302; Thu, 18 Oct 2001 17:47:19 -0400
Received: from d01ml062.pok.ibm.com (d01ml062.pok.ibm.com [9.117.250.163]) by northrelay02.pok.ibm.com (8.11.1m3/NCO v4.98) with ESMTP id f9ILnjY74004; Thu, 18 Oct 2001 17:49:45 -0400
Importance: Normal
Subject: RE: AW: I-D ACTION:draft-ietf-pkix-new-part1-09.txt
To: "Housley, Russ" <[e-mail]>
Cc: Santosh Chokhani <[e-mail]>, [e-mail]
X-Mailer: Lotus Notes Release 5.0.7  March 21, 2001
Message-ID: <[e-mail]>
From: "Tom Gindin" <[e-mail]>
Date: Thu, 18 Oct 2001 17:50:03 -0400
X-MIMETrack: Serialize by Router on D01ML062/01/M/IBM(Release 5.0.8 SPR #MIAS4UTJ8H |June 21, 2001) at 10/18/2001 05:49:47 PM
MIME-Version: 1.0
Content-type: text/plain; charset=us-ascii
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-pkix.imc.org>

     Russ:

     We do need to address the non-URI case, even though the draft clearly
states that accessLocation MUST be a URI for LDAP, because accessLocation
does take the form of a DN for DAP.  Since we don't have to give precedence
rules between different values inside crossCertificatePair, I don't know
why we have to give precedence rules between the two attributes.  We can
simply say "When accessLocation is a DN, it is expected that the needed
certificates can be retrieved from the crossCertificatePair attribute or
the caCertificate attribute of that directory entry."
     Personally, I am not sure that accessLocation values of a DN would be
very useful.  I guess you could give alternate entries in a chain (the
issuer's issuer first, then the grandfather of that one if appropriate) and
that would cut off half your DAP retrievals.

          Tom Gindin

"Housley, Russ" <[e-mail]>@mail.imc.org on 10/18/2001
03:36:19 PM

Sent by:  [e-mail]


To:   Santosh Chokhani <[e-mail]>
cc:   [e-mail]
Subject:  RE: AW: I-D ACTION:draft-ietf-pkix-new-part1-09.txt



Santosh:

Please take a look at RFC 2255.  It says LDAP URLs have the following
format:

   ldapurl = scheme "://" [hostport] ["/" [dn ["?" [attributes]
     ["?" [scope] ["?" [filter] ["?"  extensions]]]]]]

Therefore, it is straightforward to specify a specific DN and a specific
attribute.

Russ


At 02:13 PM 10/18/2001 -0400, Santosh Chokhani wrote:
>Russ: I am not sure that the DN name form will be
><ldap://URI>ldap://URI.  The RFC seems to define DN, but does not state
>that you need to obtain the appropriate attribute.
>-----Original Message-----
>From: Housley, Russ [mailto:[e-mail]]
>Sent: Thursday, October 18, 2001 11:52 AM
>To: Santosh Chokhani
>Cc: [e-mail]
>Subject: RE: AW: I-D ACTION:draft-ietf-pkix-new-part1-09.txt
>
>Santosh:
>
>In general, I expect this to be implemented with an ldap:// URI.  In this
>case, what comes back is obvious from the attribute that is
>referenced.  You are correct that other forms of URI are not specified.
>
>At 11:01 AM 10/18/2001 -0400, Santosh Chokhani wrote:
>>Also, when the name form for caIssuers is URL, I assume that will be the
>>location of the certificate itself.  However, if the name form is the DN,

>>it will not be the location of the certificate.  Rather, the client will
>>have to get the caCertificate or crossCertificatePair attribute.  Given
>>all the debate that has gone on in the past, how will we know which
attribute?
>Russ




Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id f9IJb0R26368 for ietf-pkix-bks; Thu, 18 Oct 2001 12:37:00 -0700 (PDT)
Received: from tholian.securitydynamics.com (mail.rsasecurity.com [204.167.112.129]) by above.proper.com (8.11.6/8.11.3) with SMTP id f9IJarD26361 for <[e-mail]>; Thu, 18 Oct 2001 12:36:53 -0700 (PDT)
Received: from sdtihq24.securitydynamics.com by tholian.securitydynamics.com via smtpd (for mail.imc.org [208.184.76.43]) with SMTP; 18 Oct 2001 19:33:33 UT
Received: from ebola.securitydynamics.com (ebola.securid.com [192.168.7.4]) by sdtihq24.securid.com (Pro-8.9.3/Pro-8.9.3) with ESMTP id PAA18158; Thu, 18 Oct 2001 15:36:54 -0400 (EDT)
Received: from exna00.securitydynamics.com (localhost [127.0.0.1]) by ebola.securitydynamics.com (8.9.3+Sun/8.9.1) with ESMTP id PAA19781; Thu, 18 Oct 2001 15:36:51 -0400 (EDT)
Received: by exna00.securitydynamics.com with Internet Mail Service (5.5.2653.19) id <T1DQZ7TD>; Thu, 18 Oct 2001 15:36:43 -0400
Received: from HOUSLEY-LAP.rsasecurity.com (HOUSLEY-LAP [10.3.1.8]) by exna00.securitydynamics.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id T1DQZ7S0; Thu, 18 Oct 2001 15:36:38 -0400
From: "Housley, Russ" <[e-mail]>
To: Hans Schupp <[e-mail]>
Cc: [e-mail], [e-mail], [e-mail], [e-mail]
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Version 5.0.1
Date: Thu, 18 Oct 2001 14:52:40 -0400
Subject: Re: I-D ACTION:draft-ietf-pkix-ipki-pkalgs-04.txt
In-Reply-To: <[e-mail]>
References: <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-pkix.imc.org>

Hans:

>There is an inconsistency in the declaration of
>id-characteristic-two-basis. In the text it is declared as {
>characteristic-two-field basisType(1) } (on page 16) while in the ASN.1
>Module it says { characteristic-two-field basisType(3) }.
>
>IMHO the latter one is correct (according to X9.62).
>Can you please clarify and correct the draft?

You are correct.  My copy of X9.62 says:

         id-characteristic-two-basis OBJECT IDENTIFIER ::= {
                 characteristic-two-field basisType(3) }

The body of the document is wrong, and the ASN.1 module is correct.

Russ


Received: by above.proper.com (8.11.6/8.11.3) id f9IJasN26362 for ietf-pkix-bks; Thu, 18 Oct 2001 12:36:54 -0700 (PDT)
Received: from tholian.securitydynamics.com (mail.rsasecurity.com [204.167.112.129]) by above.proper.com (8.11.6/8.11.3) with SMTP id f9IJaqD26356 for <[e-mail]>; Thu, 18 Oct 2001 12:36:52 -0700 (PDT)
Received: from sdtihq24.securitydynamics.com by tholian.securitydynamics.com via smtpd (for mail.imc.org [208.184.76.43]) with SMTP; 18 Oct 2001 19:33:32 UT
Received: from ebola.securitydynamics.com (ebola.securid.com [192.168.7.4]) by sdtihq24.securid.com (Pro-8.9.3/Pro-8.9.3) with ESMTP id PAA18155 for <[e-mail]>; Thu, 18 Oct 2001 15:36:54 -0400 (EDT)
Received: from exna00.securitydynamics.com (localhost [127.0.0.1]) by ebola.securitydynamics.com (8.9.3+Sun/8.9.1) with ESMTP id PAA19780 for <[e-mail]>; Thu, 18 Oct 2001 15:36:50 -0400 (EDT)
Received: by exna00.securitydynamics.com with Internet Mail Service (5.5.2653.19) id <T1DQZ7TC>; Thu, 18 Oct 2001 15:36:43 -0400
Received: from HOUSLEY-LAP.rsasecurity.com (HOUSLEY-LAP [10.3.1.8]) by exna00.securitydynamics.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id T1DQZ7TB; Thu, 18 Oct 2001 15:36:39 -0400
From: "Housley, Russ" <[e-mail]>
To: Santosh Chokhani <[e-mail]>
Cc: [e-mail]
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Version 5.0.1
Date: Thu, 18 Oct 2001 15:36:19 -0400
Subject: RE: AW: I-D ACTION:draft-ietf-pkix-new-part1-09.txt
In-Reply-To: <[e-mail]. com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-pkix.imc.org>

Santosh:

Please take a look at RFC 2255.  It says LDAP URLs have the following format:

   ldapurl = scheme "://" [hostport] ["/" [dn ["?" [attributes]
     ["?" [scope] ["?" [filter] ["?"  extensions]]]]]]

Therefore, it is straightforward to specify a specific DN and a specific 
attribute.

Russ


At 02:13 PM 10/18/2001 -0400, Santosh Chokhani wrote:
>Russ: I am not sure that the DN name form will be 
><ldap://URI>ldap://URI.  The RFC seems to define DN, but does not state 
>that you need to obtain the appropriate attribute.
>-----Original Message-----
>From: Housley, Russ [mailto:[e-mail]]
>Sent: Thursday, October 18, 2001 11:52 AM
>To: Santosh Chokhani
>Cc: [e-mail]
>Subject: RE: AW: I-D ACTION:draft-ietf-pkix-new-part1-09.txt
>
>Santosh:
>
>In general, I expect this to be implemented with an ldap:// URI.  In this 
>case, what comes back is obvious from the attribute that is 
>referenced.  You are correct that other forms of URI are not specified.
>
>At 11:01 AM 10/18/2001 -0400, Santosh Chokhani wrote:
>>Also, when the name form for caIssuers is URL, I assume that will be the 
>>location of the certificate itself.  However, if the name form is the DN, 
>>it will not be the location of the certificate.  Rather, the client will 
>>have to get the caCertificate or crossCertificatePair attribute.  Given 
>>all the debate that has gone on in the past, how will we know which attribute?
>Russ


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id f9IICu124309 for ietf-pkix-bks; Thu, 18 Oct 2001 11:12:56 -0700 (PDT)
Received: from SOTTMXS01.entrust.com ([216.191.251.35]) by above.proper.com (8.11.6/8.11.3) with ESMTP id f9IICtD24304 for <[e-mail]>; Thu, 18 Oct 2001 11:12:55 -0700 (PDT)
Received: by SOTTMXS01.entrust.com with Internet Mail Service (5.5.2653.19) id <VDGSHFCG>; Thu, 18 Oct 2001 14:12:47 -0400
Message-ID: <[e-mail]>
From: Santosh Chokhani <[e-mail]>
To: "Housley, Russ" <[e-mail]>, Santosh Chokhani <[e-mail]>
Cc: [e-mail]
Subject: RE: AW: I-D ACTION:draft-ietf-pkix-new-part1-09.txt
Date: Thu, 18 Oct 2001 14:13:41 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C15800.9DE8F9A0"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-pkix.imc.org>

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01C15800.9DE8F9A0
Content-Type: text/plain

Russ: I am not sure that the DN name form will be ldap://URI <ldap://URI> .
The RFC seems to define DN, but does not state that you need to obtain the
appropriate attribute.

-----Original Message-----
From: Housley, Russ [mailto:[e-mail]]
Sent: Thursday, October 18, 2001 11:52 AM
To: Santosh Chokhani
Cc: [e-mail]
Subject: RE: AW: I-D ACTION:draft-ietf-pkix-new-part1-09.txt


Santosh:

In general, I expect this to be implemented with an ldap:// URI.  In this
case, what comes back is obvious from the attribute that is referenced.  You
are correct that other forms of URI are not specified.

At 11:01 AM 10/18/2001 -0400, Santosh Chokhani wrote:


Also, when the name form for caIssuers is URL, I assume that will be the
location of the certificate itself.  However, if the name form is the DN, it
will not be the location of the certificate.  Rather, the client will have
to get the caCertificate or crossCertificatePair attribute.  Given all the
debate that has gone on in the past, how will we know which attribute?


Russ


------_=_NextPart_001_01C15800.9DE8F9A0
Content-Type: text/html

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=US-ASCII">


<META content="MSHTML 5.50.4807.2300" name=GENERATOR></HEAD>
<BODY>
<DIV><SPAN class=825071118-18102001><FONT face=Arial color=#0000ff size=2>Russ: 
I am not sure that the DN name form will be <A 
href="ldap://URI">ldap://URI</A>.&nbsp; The RFC seems to define DN, but does not 
state that you need to obtain the appropriate attribute.</FONT></SPAN></DIV>
<BLOCKQUOTE>
  <DIV class=OutlookMessageHeader dir=ltr align=left><FONT face=Tahoma 
  size=2>-----Original Message-----<BR><B>From:</B> Housley, Russ 
  [mailto:[e-mail]]<BR><B>Sent:</B> Thursday, October 18, 2001 
  11:52 AM<BR><B>To:</B> Santosh Chokhani<BR><B>Cc:</B> 
  [e-mail]<BR><B>Subject:</B> RE: AW: I-D 
  ACTION:draft-ietf-pkix-new-part1-09.txt<BR><BR></FONT></DIV>Santosh:<BR><BR>In 
  general, I expect this to be implemented with an ldap:// URI.&nbsp; In this 
  case, what comes back is obvious from the attribute that is referenced.&nbsp; 
  You are correct that other forms of URI are not specified.<BR><BR>At 11:01 AM 
  10/18/2001 -0400, Santosh Chokhani wrote:<BR>
  <BLOCKQUOTE class=cite cite type="cite"><FONT size=2>Also, when the name 
    form for caIssuers is URL, I assume that will be the location of the 
    certificate itself.&nbsp; However, if the name form is the DN, it will not 
    be the location of the certificate.&nbsp; Rather, the client will have to 
    get the caCertificate or crossCertificatePair attribute.&nbsp; Given all the 
    debate that has gone on in the past, how will we know which 
  attribute?</BLOCKQUOTE><BR>Russ</FONT></BLOCKQUOTE></BODY></HTML>

------_=_NextPart_001_01C15800.9DE8F9A0--


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id f9IGhPV22027 for ietf-pkix-bks; Thu, 18 Oct 2001 09:43:25 -0700 (PDT)
Received: from gateway.secude.com (linux.secude.com [141.12.207.27]) by above.proper.com (8.11.6/8.11.3) with ESMTP id f9IGhND22013 for <[e-mail]>; Thu, 18 Oct 2001 09:43:23 -0700 (PDT)
Received: from remus.secude.com (remus.intranet.secude.com [192.168.2.2]) by gateway.secude.com (Postfix) with ESMTP id 7793E8E29; Thu, 18 Oct 2001 18:42:52 +0200 (CEST)
Received: from secude.com (vpn-dolivo.intranet.secude.com [192.168.1.7]) by remus.secude.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id 4VZ2WGWW; Thu, 18 Oct 2001 18:50:25 +0200
Message-ID: <[e-mail]>
Date: Thu, 18 Oct 2001 18:44:53 +0200
From: Hans Schupp <[e-mail]>
Organization: SECUDE GmbH
X-Mailer: Mozilla 4.77 [en] (Windows NT 5.0; U)
X-Accept-Language: en
MIME-Version: 1.0
To: [e-mail], [e-mail], [e-mail]
Cc: [e-mail], [e-mail]
Subject: Re: I-D ACTION:draft-ietf-pkix-ipki-pkalgs-04.txt
References: <[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-pkix.imc.org>

[e-mail] wrote:

>         Author(s)       : L. Bassham, R. Housley, W. Polk
>         Filename        : draft-ietf-pkix-ipki-pkalgs-04.txt

There is an inconsistency in the declaration of
id-characteristic-two-basis. In the text it is declared as {
characteristic-two-field basisType(1) } (on page 16) while in the ASN.1
Module it says { characteristic-two-field basisType(3) }.

IMHO the latter one is correct (according to X9.62).
Can you please clarify and correct the draft?

regards, Hans Schupp


Received: by above.proper.com (8.11.6/8.11.3) id f9IFqLX17912 for ietf-pkix-bks; Thu, 18 Oct 2001 08:52:21 -0700 (PDT)
Received: from tholian.securitydynamics.com (mail.rsasecurity.com [204.167.112.129]) by above.proper.com (8.11.6/8.11.3) with SMTP id f9IFqJD17903 for <[e-mail]>; Thu, 18 Oct 2001 08:52:19 -0700 (PDT)
Received: from sdtihq24.securitydynamics.com by tholian.securitydynamics.com via smtpd (for mail.imc.org [208.184.76.43]) with SMTP; 18 Oct 2001 15:48:57 UT
Received: from ebola.securitydynamics.com (ebola.securid.com [192.168.7.4]) by sdtihq24.securid.com (Pro-8.9.3/Pro-8.9.3) with ESMTP id LAA25814 for <[e-mail]>; Thu, 18 Oct 2001 11:52:19 -0400 (EDT)
Received: from exna00.securitydynamics.com (localhost [127.0.0.1]) by ebola.securitydynamics.com (8.9.3+Sun/8.9.1) with ESMTP id LAA26016 for <[e-mail]>; Thu, 18 Oct 2001 11:52:17 -0400 (EDT)
Received: by exna00.securitydynamics.com with Internet Mail Service (5.5.2653.19) id <T1DQZYFK>; Thu, 18 Oct 2001 11:52:10 -0400
Received: from HOUSLEY-LAP.rsasecurity.com (HOUSLEY-LAP [10.3.1.83]) by exna00.securitydynamics.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id T1DQZYF2; Thu, 18 Oct 2001 11:52:05 -0400
From: "Housley, Russ" <[e-mail]>
To: Santosh Chokhani <[e-mail]>
Cc: [e-mail]
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Version 5.0.1
Date: Thu, 18 Oct 2001 11:52:02 -0400
Subject: RE: AW: I-D ACTION:draft-ietf-pkix-new-part1-09.txt
In-Reply-To: <[e-mail]. com>
Mime-Version: 1.0
Content-Type: text/html; charset="us-ascii"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-pkix.imc.org>

<html>
Santosh:<br>
<br>
In general, I expect this to be implemented with an ldap:// URI.&nbsp; In
this case, what comes back is obvious from the attribute that is
referenced.&nbsp; You are correct that other forms of URI are not
specified.<br>
<br>
At 11:01 AM 10/18/2001 -0400, Santosh Chokhani wrote:<br>
<blockquote type=cite class=cite cite><font size=2>Also, when the name
form for caIssuers is URL, I assume that will be the location of the
certificate itself.&nbsp; However, if the name form is the DN, it will
not be the location of the certificate.&nbsp; Rather, the client will
have to get the caCertificate or crossCertificatePair attribute.&nbsp;
Given all the debate that has gone on in the past, how will we know which
attribute?</blockquote><br>
Russ</font></html>


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id f9IF0IY15825 for ietf-pkix-bks; Thu, 18 Oct 2001 08:00:18 -0700 (PDT)
Received: from SOTTMXS01.entrust.com ([216.191.251.35]) by above.proper.com (8.11.6/8.11.3) with ESMTP id f9IF0GD15816 for <[e-mail]>; Thu, 18 Oct 2001 08:00:16 -0700 (PDT)
Received: by SOTTMXS01.entrust.com with Internet Mail Service (5.5.2653.19) id <VDGSHCAG>; Thu, 18 Oct 2001 11:00:12 -0400
Message-ID: <[e-mail]>
From: Santosh Chokhani <[e-mail]>
To: "Housley, Russ" <[e-mail]>, Fantou Patrick <[e-mail]>
Cc: [e-mail]
Subject: RE: AW: I-D ACTION:draft-ietf-pkix-new-part1-09.txt
Date: Thu, 18 Oct 2001 11:01:06 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C157E5.B6898E40"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-pkix.imc.org>

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01C157E5.B6898E40
Content-Type: text/plain

Russ:

It seems that the phrase "on-line validation services and CA policy data"
should be replaced with "on-line validation services, CA certificate
information and CA policy data".  I suggest this since the two OIDs you
register are for OCSP and CA certificates.

Also, when the name form for caIssuers is URL, I assume that will be the
location of the certificate itself.  However, if the name form is the DN, it
will not be the location of the certificate.  Rather, the client will have
to get the caCertificate or crossCertificatePair attribute.  Given all the
debate that has gone on in the past, how will we know which attribute?

If my assumptions are correct and my questions are cogent, should there be
explanation added for this?

-----Original Message-----
From: Housley, Russ [mailto:[e-mail]]
Sent: Thursday, October 18, 2001 9:56 AM
To: Fantou Patrick
Cc: [e-mail]
Subject: Re: AW: I-D ACTION:draft-ietf-pkix-new-part1-09.txt



Patrick:

>2. Clause 4.2.2.1 Authority Information Access says that RFC 2560 defines 
>the access descriptor for OCSP, but in fact id-ad-ocsp (id-ad 1) is 
>defined in this draft and RFC 2560 imports it and uses it as base for the 
>OCSP OID arc.

Tim Polk and I finally talked.  Here is the proposed replacement text:

    4.2.2.1  Authority Information Access

    The authority information access extension indicates how to access CA
    information and services for the issuer of the certificate in which
    the extension appears. Information and services may include on-line
    validation services and CA policy data.  (The location of CRLs is not
    specified in this extension; that information is provided by the
    cRLDistributionPoints extension.)  This extension may be included in
    subject or CA certificates, and it MUST be non-critical.

    id-pe-authorityInfoAccess OBJECT IDENTIFIER ::= { id-pe 1 }

    AuthorityInfoAccessSyntax  ::=
            SEQUENCE SIZE (1..MAX) OF AccessDescription

    AccessDescription  ::=  SEQUENCE {
            accessMethod          OBJECT IDENTIFIER,
            accessLocation        GeneralName  }

    id-ad OBJECT IDENTIFIER ::= { id-pkix 48 }

    id-ad-caIssuers OBJECT IDENTIFIER ::= { id-ad 2 }

    id-ad-ocsp OBJECT IDENTIFIER ::= { id-ad 1 }

    Each entry in the sequence AuthorityInfoAccessSyntax describes the
    format and location of additional information provided by the CA who
    issued the certificate in which this extension appears.  The type and
    format of the information is specified by the accessMethod field; the
    accessLocation field specifies the location of the information.  The
    retrieval mechanism may be implied by the accessMethod or specified
    by accessLocation.

    This profile defines two accessMethod OIDs: id-ad-caIssuers and id-
    ad-ocsp.

    The id-ad-caIssuers OID is used when the additional information lists
    CAs that have issued certificates superior to the CA that issued the
    certificate containing this extension.  The referenced CA Issuers
    description is intended to aid certificate users in the selection of
    a certification path that terminates at a point trusted by the
    certificate user.

    When id-ad-caIssuers appears as accessMethod, the accessLocation
    field describes the referenced description server and the access
    protocol to obtain the referenced description.  The accessLocation
    field is defined as a GeneralName, which can take several forms.
    Where the information is available via http, ftp, or ldap,
    accessLocation MUST be a uniformResourceIdentifier.  Where the
    information is available via the Directory Access Protocol (DAP),
    accessLocation MUST be a directoryName. When the information is
    available via electronic mail, accessLocation MUST be an rfc822Name.
    The semantics of other id-ad-caIssuers accessLocation name forms are
    not defined.

    The id-ad-ocsp OID is used when revocation information for the
    certificate containing this extension is available using the Online
    Certificate Status Protocol (OCSP) [RFC 2560].

    When id-ad-ocsp appears as accessMethod, the accessLocation field is
    the location of the OCSP responder, using the conventions defined in
    [RFC 2560].

    [RFC 2560] defines the access descriptor for the Online Certificate
    Status Protocol.  When this access descriptor appears in the
    authority information access extension, this indicates the issuer
    provides revocation information for this certificate through the
    named OCSP service.  Additional access descriptors may be defined in
    other PKIX specifications.

Russ

------_=_NextPart_001_01C157E5.B6898E40
Content-Type: text/html
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3DUS-ASCII">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2653.12">
<TITLE>RE: AW: I-D ACTION:draft-ietf-pkix-new-part1-09.txt</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=3D2>Russ:</FONT>
</P>

<P><FONT SIZE=3D2>It seems that the phrase &quot;on-line validation =
services and CA policy data&quot; should be replaced with &quot;on-line =
validation services, CA certificate information and CA policy =
data&quot;.&nbsp; I suggest this since the two OIDs you register are =
for OCSP and CA certificates.</FONT></P>

<P><FONT SIZE=3D2>Also, when the name form for caIssuers is URL, I =
assume that will be the location of the certificate itself.&nbsp; =
However, if the name form is the DN, it will not be the location of the =
certificate.&nbsp; Rather, the client will have to get the =
caCertificate or crossCertificatePair attribute.&nbsp; Given all the =
debate that has gone on in the past, how will we know which =
attribute?</FONT></P>

<P><FONT SIZE=3D2>If my assumptions are correct and my questions are =
cogent, should there be explanation added for this?</FONT>
</P>

<P><FONT SIZE=3D2>-----Original Message-----</FONT>
<BR><FONT SIZE=3D2>From: Housley, Russ [<A =
HREF=3D"mailto:[e-mail]">mailto:[e-mail]=
</A>]</FONT>
<BR><FONT SIZE=3D2>Sent: Thursday, October 18, 2001 9:56 AM</FONT>
<BR><FONT SIZE=3D2>To: Fantou Patrick</FONT>
<BR><FONT SIZE=3D2>Cc: [e-mail]</FONT>
<BR><FONT SIZE=3D2>Subject: Re: AW: I-D =
ACTION:draft-ietf-pkix-new-part1-09.txt</FONT>
</P>
<BR>
<BR>

<P><FONT SIZE=3D2>Patrick:</FONT>
</P>

<P><FONT SIZE=3D2>&gt;2. Clause 4.2.2.1 Authority Information Access =
says that RFC 2560 defines </FONT>
<BR><FONT SIZE=3D2>&gt;the access descriptor for OCSP, but in fact =
id-ad-ocsp (id-ad 1) is </FONT>
<BR><FONT SIZE=3D2>&gt;defined in this draft and RFC 2560 imports it =
and uses it as base for the </FONT>
<BR><FONT SIZE=3D2>&gt;OCSP OID arc.</FONT>
</P>

<P><FONT SIZE=3D2>Tim Polk and I finally talked.&nbsp; Here is the =
proposed replacement text:</FONT>
</P>

<P><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp; 4.2.2.1&nbsp; Authority =
Information Access</FONT>
</P>

<P><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp; The authority information access =
extension indicates how to access CA</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp; information and services for the =
issuer of the certificate in which</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp; the extension appears. =
Information and services may include on-line</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp; validation services and CA policy =
data.&nbsp; (The location of CRLs is not</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp; specified in this extension; that =
information is provided by the</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp; cRLDistributionPoints =
extension.)&nbsp; This extension may be included in</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp; subject or CA certificates, and =
it MUST be non-critical.</FONT>
</P>

<P><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp; id-pe-authorityInfoAccess OBJECT =
IDENTIFIER ::=3D { id-pe 1 }</FONT>
</P>

<P><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp; AuthorityInfoAccessSyntax&nbsp; =
::=3D</FONT>
<BR><FONT =
SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp; SEQUENCE SIZE (1..MAX) OF AccessDescription</FONT>
</P>

<P><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp; AccessDescription&nbsp; =
::=3D&nbsp; SEQUENCE {</FONT>
<BR><FONT =
SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp; accessMethod&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
OBJECT IDENTIFIER,</FONT>
<BR><FONT =
SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp; accessLocation&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
GeneralName&nbsp; }</FONT>
</P>

<P><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp; id-ad OBJECT IDENTIFIER ::=3D { =
id-pkix 48 }</FONT>
</P>

<P><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp; id-ad-caIssuers OBJECT IDENTIFIER =
::=3D { id-ad 2 }</FONT>
</P>

<P><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp; id-ad-ocsp OBJECT IDENTIFIER ::=3D =
{ id-ad 1 }</FONT>
</P>

<P><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp; Each entry in the sequence =
AuthorityInfoAccessSyntax describes the</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp; format and location of additional =
information provided by the CA who</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp; issued the certificate in which =
this extension appears.&nbsp; The type and</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp; format of the information is =
specified by the accessMethod field; the</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp; accessLocation field specifies =
the location of the information.&nbsp; The</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp; retrieval mechanism may be =
implied by the accessMethod or specified</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp; by accessLocation.</FONT>
</P>

<P><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp; This profile defines two =
accessMethod OIDs: id-ad-caIssuers and id-</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp; ad-ocsp.</FONT>
</P>

<P><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp; The id-ad-caIssuers OID is used =
when the additional information lists</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp; CAs that have issued certificates =
superior to the CA that issued the</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp; certificate containing this =
extension.&nbsp; The referenced CA Issuers</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp; description is intended to aid =
certificate users in the selection of</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp; a certification path that =
terminates at a point trusted by the</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp; certificate user.</FONT>
</P>

<P><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp; When id-ad-caIssuers appears as =
accessMethod, the accessLocation</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp; field describes the referenced =
description server and the access</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp; protocol to obtain the referenced =
description.&nbsp; The accessLocation</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp; field is defined as a =
GeneralName, which can take several forms.</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp; Where the information is =
available via http, ftp, or ldap,</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp; accessLocation MUST be a =
uniformResourceIdentifier.&nbsp; Where the</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp; information is available via the =
Directory Access Protocol (DAP),</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp; accessLocation MUST be a =
directoryName. When the information is</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp; available via electronic mail, =
accessLocation MUST be an rfc822Name.</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp; The semantics of other =
id-ad-caIssuers accessLocation name forms are</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp; not defined.</FONT>
</P>

<P><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp; The id-ad-ocsp OID is used when =
revocation information for the</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp; certificate containing this =
extension is available using the Online</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp; Certificate Status Protocol =
(OCSP) [RFC 2560].</FONT>
</P>

<P><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp; When id-ad-ocsp appears as =
accessMethod, the accessLocation field is</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp; the location of the OCSP =
responder, using the conventions defined in</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp; [RFC 2560].</FONT>
</P>

<P><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp; [RFC 2560] defines the access =
descriptor for the Online Certificate</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp; Status Protocol.&nbsp; When this =
access descriptor appears in the</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp; authority information access =
extension, this indicates the issuer</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp; provides revocation information =
for this certificate through the</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp; named OCSP service.&nbsp; =
Additional access descriptors may be defined in</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp; other PKIX specifications.</FONT>
</P>

<P><FONT SIZE=3D2>Russ</FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C157E5.B6898E40--


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id f9IEG8e12444 for ietf-pkix-bks; Thu, 18 Oct 2001 07:16:08 -0700 (PDT)
Received: from tholian.securitydynamics.com (mail.rsasecurity.com [204.167.112.129]) by above.proper.com (8.11.6/8.11.3) with SMTP id f9IEG6D12440 for <[e-mail]>; Thu, 18 Oct 2001 07:16:06 -0700 (PDT)
Received: from sdtihq24.securitydynamics.com by tholian.securitydynamics.com via smtpd (for mail.imc.org [208.184.76.43]) with SMTP; 18 Oct 2001 14:12:44 UT
Received: from ebola.securitydynamics.com (ebola.securid.com [192.168.7.4]) by sdtihq24.securid.com (Pro-8.9.3/Pro-8.9.3) with ESMTP id KAA14604; Thu, 18 Oct 2001 10:16:06 -0400 (EDT)
Received: from exna00.securitydynamics.com (localhost [127.0.0.1]) by ebola.securitydynamics.com (8.9.3+Sun/8.9.1) with ESMTP id KAA14701; Thu, 18 Oct 2001 10:16:05 -0400 (EDT)
Received: by exna00.securitydynamics.com with Internet Mail Service (5.5.2653.19) id <T1DQZWHR>; Thu, 18 Oct 2001 10:15:58 -0400
Received: from HOUSLEY-LAP.rsasecurity.com (HOUSLEY-LAP [10.3.1.83]) by exna00.securitydynamics.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id T1DQZWHQ; Thu, 18 Oct 2001 10:15:55 -0400
From: "Housley, Russ" <[e-mail]>
To: [e-mail]
Cc: [e-mail], [e-mail], [e-mail]
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Version 5.0.1
Date: Thu, 18 Oct 2001 10:15:48 -0400
Subject: Re: PKAlgs: 04: ASN.1 typos
In-Reply-To: <[e-mail] l.telstra.com.au>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-pkix.imc.org>

James:

>Couple of ASN.1 typos in draft-ietf-pkix-ipki-pkalgs-04.txt:
>
>1. Comments in ASN.1 start with a pair of hyphens (--) and end with the next
>pair of hyphens or the end of the line.  Consequently, 4 hyphens cannot be
>used to start a comment as it would also end it as well.  Replace
>occurrences of 4 hyphens with 2 hyphens throughout the ASN.1 module.  For
>example:
>REPLACE:        ----   DSA Keys and Signatures
>WITH:           --   DSA Keys and Signatures

Actually we need to change all occurrences of "----" to a string that will 
not be interpreted as start of commend followed immediately by end of 
comment.  I know that Jim Schaad has pointed this out in the past.

>2. ecpkParameters is a type so it must start with a capital letter.  This
>type is simply called Parameters in X9.62.
>REPLACE:        ecpkParameters ::= CHOICE {
>WITH:           Parameters ::= CHOICE {
>OR WITH:        ECPKParameters ::= CHOICE {

Agree.  We need to change "ecpkParameters" to "ECPKParameters"

>3. Delete the comma after the cofactor field in ECParameters.
>REPLACE:        cofactor  INTEGER  OPTIONAL,  -- The integer..
>WITH:           cofactor  INTEGER  OPTIONAL   -- The integer..

Agree.  We need to delete the comma.

Russ


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id f9IE2KX12145 for ietf-pkix-bks; Thu, 18 Oct 2001 07:02:20 -0700 (PDT)
Received: from tholian.securitydynamics.com (mail.rsasecurity.com [204.167.112.129]) by above.proper.com (8.11.6/8.11.3) with SMTP id f9IE2ID12141 for <[e-mail]>; Thu, 18 Oct 2001 07:02:18 -0700 (PDT)
Received: from sdtihq24.securitydynamics.com by tholian.securitydynamics.com via smtpd (for mail.imc.org [208.184.76.43]) with SMTP; 18 Oct 2001 13:58:56 UT
Received: from ebola.securitydynamics.com (ebola.securid.com [192.168.7.4]) by sdtihq24.securid.com (Pro-8.9.3/Pro-8.9.3) with ESMTP id KAA13052 for <[e-mail]>; Thu, 18 Oct 2001 10:02:18 -0400 (EDT)
Received: from exna00.securitydynamics.com (localhost [127.0.0.1]) by ebola.securitydynamics.com (8.9.3+Sun/8.9.1) with ESMTP id KAA13023 for <[e-mail]>; Thu, 18 Oct 2001 10:02:18 -0400 (EDT)
Received: by exna00.securitydynamics.com with Internet Mail Service (5.5.2653.19) id <T1DQZV9H>; Thu, 18 Oct 2001 10:02:10 -0400
Received: from HOUSLEY-LAP.rsasecurity.com (HOUSLEY-LAP [10.3.1.83]) by exna00.securitydynamics.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id T1DQZV9G; Thu, 18 Oct 2001 10:02:07 -0400
From: "Housley, Russ" <[e-mail]>
To: Fantou Patrick <[e-mail]>
Cc: [e-mail]
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Version 5.0.1
Date: Thu, 18 Oct 2001 09:56:08 -0400
Subject: Re: AW: I-D ACTION:draft-ietf-pkix-new-part1-09.txt
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-pkix.imc.org>

Patrick:

>2. Clause 4.2.2.1 Authority Information Access says that RFC 2560 defines 
>the access descriptor for OCSP, but in fact id-ad-ocsp (id-ad 1) is 
>defined in this draft and RFC 2560 imports it and uses it as base for the 
>OCSP OID arc.

Tim Polk and I finally talked.  Here is the proposed replacement text:

    4.2.2.1  Authority Information Access

    The authority information access extension indicates how to access CA
    information and services for the issuer of the certificate in which
    the extension appears. Information and services may include on-line
    validation services and CA policy data.  (The location of CRLs is not
    specified in this extension; that information is provided by the
    cRLDistributionPoints extension.)  This extension may be included in
    subject or CA certificates, and it MUST be non-critical.

    id-pe-authorityInfoAccess OBJECT IDENTIFIER ::= { id-pe 1 }

    AuthorityInfoAccessSyntax  ::=
            SEQUENCE SIZE (1..MAX) OF AccessDescription

    AccessDescription  ::=  SEQUENCE {
            accessMethod          OBJECT IDENTIFIER,
            accessLocation        GeneralName  }

    id-ad OBJECT IDENTIFIER ::= { id-pkix 48 }

    id-ad-caIssuers OBJECT IDENTIFIER ::= { id-ad 2 }

    id-ad-ocsp OBJECT IDENTIFIER ::= { id-ad 1 }

    Each entry in the sequence AuthorityInfoAccessSyntax describes the
    format and location of additional information provided by the CA who
    issued the certificate in which this extension appears.  The type and
    format of the information is specified by the accessMethod field; the
    accessLocation field specifies the location of the information.  The
    retrieval mechanism may be implied by the accessMethod or specified
    by accessLocation.

    This profile defines two accessMethod OIDs: id-ad-caIssuers and id-
    ad-ocsp.

    The id-ad-caIssuers OID is used when the additional information lists
    CAs that have issued certificates superior to the CA that issued the
    certificate containing this extension.  The referenced CA Issuers
    description is intended to aid certificate users in the selection of
    a certification path that terminates at a point trusted by the
    certificate user.

    When id-ad-caIssuers appears as accessMethod, the accessLocation
    field describes the referenced description server and the access
    protocol to obtain the referenced description.  The accessLocation
    field is defined as a GeneralName, which can take several forms.
    Where the information is available via http, ftp, or ldap,
    accessLocation MUST be a uniformResourceIdentifier.  Where the
    information is available via the Directory Access Protocol (DAP),
    accessLocation MUST be a directoryName. When the information is
    available via electronic mail, accessLocation MUST be an rfc822Name.
    The semantics of other id-ad-caIssuers accessLocation name forms are
    not defined.

    The id-ad-ocsp OID is used when revocation information for the
    certificate containing this extension is available using the Online
    Certificate Status Protocol (OCSP) [RFC 2560].

    When id-ad-ocsp appears as accessMethod, the accessLocation field is
    the location of the OCSP responder, using the conventions defined in
    [RFC 2560].

    [RFC 2560] defines the access descriptor for the Online Certificate
    Status Protocol.  When this access descriptor appears in the
    authority information access extension, this indicates the issuer
    provides revocation information for this certificate through the
    named OCSP service.  Additional access descriptors may be defined in
    other PKIX specifications.

Russ


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id f9HIiaP17739 for ietf-pkix-bks; Wed, 17 Oct 2001 11:44:36 -0700 (PDT)
Received: from ietf.org (odin.ietf.org [132.151.1.176]) by above.proper.com (8.11.6/8.11.3) with ESMTP id f9HIiYD17735 for <[e-mail]>; Wed, 17 Oct 2001 11:44:34 -0700 (PDT)
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA03324; Wed, 17 Oct 2001 14:44:32 -0400 (EDT)
Message-Id: <[e-mail]>
To: IETF-Announce: ;
Subject: RFC 3161 on Time-Stamp Protocol (TSP)
Cc: [e-mail], [e-mail]
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
From: RFC Editor <[e-mail]>
Date: Wed, 17 Oct 2001 14:44:32 -0400
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-pkix.imc.org>

A new Request for Comments is now available in online RFC libraries.


        RFC 3161

        Title:	    Internet X.509 Public Key Infrastructure
                    Time-Stamp Protocol (TSP)
        Author(s):  C. Adams, P. Cain, D. Pinkas, R. Zuccherato
        Status:     Standards Track
	Date:       August 2001
        Mailbox:    [e-mail], [e-mail],
                    [e-mail],
                    [e-mail] 
        Pages:      26
        Characters: 54582
        Obsoletes/Updates/SeeAlso:    None

        I-D Tag:    draft-ietf-pkix-time-stamp-15.txt

        URL:        ftp://ftp.rfc-editor.org/in-notes/rfc3161.txt


This document describes the format of a request sent to a Time
Stamping Authority (TSA) and of the response that is returned.  It
also establishes several security-relevant requirements for TSA
operation, with regards to processing requests to generate responses.

This document is a product of the Public-Key Infrastructure (C.509)
Working Group of the IETF.

This is now a Proposed Standard Protocol.

This document specifies an Internet standards track protocol for
the Internet community, and requests discussion and suggestions
for improvements.  Please refer to the current edition of the
"Internet Official Protocol Standards" (STD 1) for the
standardization state and status of this protocol.  Distribution
of this memo is unlimited.

This announcement is sent to the IETF list and the RFC-DIST list.
Requests to be added to or deleted from the IETF distribution list
should be sent to [e-mail].  Requests to be
added to or deleted from the RFC-DIST distribution list should
be sent to [e-mail].

Details on obtaining RFCs via FTP or EMAIL may be obtained by sending
an EMAIL message to [e-mail] with the message body 
help: ways_to_get_rfcs.  For example:

        To: [e-mail]
        Subject: getting rfcs

        help: ways_to_get_rfcs

Requests for special distribution should be addressed to either the
author of the RFC in question, or to [e-mail].  Unless
specifically noted otherwise on the RFC itself, all RFCs are for
unlimited distribution.echo 
Submissions for Requests for Comments should be sent to
[e-mail].  Please consult RFC 2223, Instructions to RFC
Authors, for further information.


Joyce K. Reynolds and Sandy Ginoza
USC/Information Sciences Institute

...

Below is the data which will enable a MIME compliant Mail Reader 
implementation to automatically retrieve the ASCII version
of the RFCs.

----- End Included Message -----

----------
X-Sun-Data-Type: Multipart
X-Sun-Content-Length: 490
X-Sun-Charset: us-ascii
X-Sun-Content-Lines: 22

--OtherAccess
Content-Type:  Message/External-body;
        access-type="mail-server";
        server="[e-mail]"

Content-Type: text/plain
Content-ID: <[e-mail]>

RETRIEVE: rfc
DOC-ID: rfc3161

--OtherAccess
Content-Type:   Message/External-body;
        name="rfc3161.txt";
        site="ftp.isi.edu";
        access-type="anon-ftp";
        directory="in-notes"

Content-Type: text/plain
Content-ID: <[e-mail]>

--OtherAccess--
--NextPart--


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id f9GJVQv08233 for ietf-pkix-bks; Tue, 16 Oct 2001 12:31:26 -0700 (PDT)
Received: from tholian.securitydynamics.com (mail.rsasecurity.com [204.167.112.129]) by above.proper.com (8.11.6/8.11.3) with SMTP id f9GJVOD08227 for <[e-mail]>; Tue, 16 Oct 2001 12:31:25 -0700 (PDT)
Received: from sdtihq24.securitydynamics.com by tholian.securitydynamics.com via smtpd (for mail.imc.org [208.184.76.43]) with SMTP; 16 Oct 2001 19:28:06 UT
Received: from ebola.securitydynamics.com (ebola.securid.com [192.168.7.4]) by sdtihq24.securid.com (Pro-8.9.3/Pro-8.9.3) with ESMTP id PAA09977 for <[e-mail]>; Tue, 16 Oct 2001 15:31:26 -0400 (EDT)
Received: from exna00.securitydynamics.com (localhost [127.0.0.1]) by ebola.securitydynamics.com (8.9.3+Sun/8.9.1) with ESMTP id PAA26020 for <[e-mail]>; Tue, 16 Oct 2001 15:31:25 -0400 (EDT)
Received: by exna00.securitydynamics.com with Internet Mail Service (5.5.2653.19) id <T1DQYKSD>; Tue, 16 Oct 2001 15:31:19 -0400
Received: from HOUSLEY-LAP.rsasecurity.com (HOUSLEY-LAP [10.3.1.81]) by exna00.securitydynamics.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id T1DQYKSA; Tue, 16 Oct 2001 15:31:14 -0400
From: "Housley, Russ" <[e-mail]>
To: Fantou Patrick <[e-mail]>
Cc: [e-mail]
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Version 5.0.1
Date: Tue, 16 Oct 2001 15:30:59 -0400
Subject: Re: AW: I-D ACTION:draft-ietf-pkix-new-part1-09.txt
In-Reply-To: <1D82815C322BD41196EA00508B951F7B01B40C49@MCHH265E>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-pkix.imc.org>

Patrick:

>1. pseudonym should be supported in issuer and subject names,
>  but the oid for pseudonym is missing in this document (id-at-pseudonym : 
> id-at 65 from X.520 2000)

Section 4.1.2.4 lists pseudonym as one of the attributes that SHOULD be 
supported.  However, pseudonym is missing from the ASN.1 module.  We need 
to add:

    -- Naming attributes of type X520Pseudonym

    id-at-localityName      AttributeType ::= { id-at 65 }

    X520Pseudonym ::= CHOICE {
       teletexString     TeletexString   (SIZE (1..ub-pseudonym)),
       printableString   PrintableString (SIZE (1..ub-pseudonym)),
       universalString   UniversalString (SIZE (1..ub-pseudonym)),
       utf8String        UTF8String      (SIZE (1..ub-pseudonym)),
       bmpString         BMPString       (SIZE (1..ub-pseudonym)) }

    ub-pseudonym INTEGER ::= 128

>2. Clause 4.2.2.1 Authority Information Access says that RFC 2560 defines 
>the access descriptor for OCSP, but in fact id-ad-ocsp (id-ad 1) is 
>defined in this draft and RFC 2560 imports it and uses it as base for the 
>OCSP OID arc.

You are quite right.  I will propose replacement text after coordinating 
with Tim Polk.

Russ


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id f9GF5YK26048 for ietf-pkix-bks; Tue, 16 Oct 2001 08:05:34 -0700 (PDT)
Received: from beamer.mchh.siemens.de (beamer.mchh.siemens.de [194.138.158.163]) by above.proper.com (8.11.6/8.11.3) with ESMTP id f9GF5WD26044 for <[e-mail]>; Tue, 16 Oct 2001 08:05:32 -0700 (PDT)
Received: from blues.mchh.siemens.de (mail2.mchh.siemens.de [194.138.158.227]) by beamer.mchh.siemens.de (8.9.3/8.9.3) with ESMTP id RAA27110 for <[e-mail]>; Tue, 16 Oct 2001 17:05:21 +0200 (MET DST)
Received: from mchh247e.demchh201e.icn.siemens.de ([139.21.200.57]) by blues.mchh.siemens.de (8.9.1/8.9.1) with ESMTP id RAA11112 for <[e-mail]>; Tue, 16 Oct 2001 17:05:20 +0200 (MET DST)
Received: by MCHH247E with Internet Mail Service (5.5.2653.19) id <4DLHVZXR>; Tue, 16 Oct 2001 17:05:03 +0200
Message-ID: <1D82815C322BD41196EA00508B951F7B01B40C49@MCHH265E>
From: Fantou Patrick <[e-mail]>
To: [e-mail]
Cc: Fantou Patrick <[e-mail]>
Subject: AW: I-D ACTION:draft-ietf-pkix-new-part1-09.txt
Date: Tue, 16 Oct 2001 17:04:55 +0200
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id f9GF5XD26045
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-pkix.imc.org>

Two small things:

1. pseudonym should be supported in issuer and subject names,
 but the oid for pseudonym is missing in this document (id-at-pseudonym : id-at 65 from X.520 2000)

2. Clause 4.2.2.1 Authority Information Access says that RFC 2560 defines the access descriptor for OCSP,
but in fact id-ad-ocsp (id-ad 1) is defined in this draft and RFC 2560 imports it 
and uses it as base for the OCSP OID arc.

Regards
Patrick

> -----Ursprüngliche Nachricht-----
> Von: [e-mail] [mailto:[e-mail]]
> Gesendet: Dienstag, 16. Oktober 2001 13:08
> Cc: [e-mail]
> Betreff: I-D ACTION:draft-ietf-pkix-new-part1-09.txt
> 
> 
> A New Internet-Draft is available from the on-line 
> Internet-Drafts directories.
> This draft is a work item of the Public-Key Infrastructure 
> (X.509) Working Group of the IETF.
> 
> 	Title		: Internet X.509 Public Key 
> Infrastructure Certificate 
>                           and CRL Profile
> 	Author(s)	: R. Housley, W. Ford, W. Polk, D. Solo
> 	Filename	: draft-ietf-pkix-new-part1-09.txt
> 	Pages		: 128
> 	Date		: 15-Oct-01
> 	
> This is the ninth draft of a specification based upon RFC 2459.  When
> complete, this specification will obsolete RFC 2459.
> Please send comments on this document to the [e-mail] mail
> list.
> 
> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-ietf-pkix-new-part1-09.txt
> 
> To remove yourself from the IETF Announcement list, send a message to 
> ietf-announce-request with the word unsubscribe in the body 
> of the message.
> 
> Internet-Drafts are also available by anonymous FTP. Login 
> with the username
> "anonymous" and a password of your e-mail address. After logging in,
> type "cd internet-drafts" and then
> 	"get draft-ietf-pkix-new-part1-09.txt".
> 
> A list of Internet-Drafts directories can be found in
> http://www.ietf.org/shadow.html 
> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
> 
> 
> Internet-Drafts can also be obtained by e-mail.
> 
> Send a message to:
> 	[e-mail].
> In the body type:
> 	"FILE /internet-drafts/draft-ietf-pkix-new-part1-09.txt".
> 	
> NOTE:	The mail server at ietf.org can return the document in
> 	MIME-encoded form by using the "mpack" utility.  To use this
> 	feature, insert the command "ENCODING mime" before the "FILE"
> 	command.  To decode the response(s), you will need "munpack" or
> 	a MIME-compliant mail reader.  Different MIME-compliant 
> mail readers
> 	exhibit different behavior, especially when dealing with
> 	"multipart" MIME messages (i.e. documents which have been split
> 	up into multiple messages), so check your local documentation on
> 	how to manipulate these messages.
> 		
> 		
> Below is the data which will enable a MIME compliant mail reader
> implementation to automatically retrieve the ASCII version of the
> Internet-Draft.
> 


Received: by above.proper.com (8.11.6/8.11.3) id f9GB8Vn12462 for ietf-pkix-bks; Tue, 16 Oct 2001 04:08:31 -0700 (PDT)
Received: from ietf.org (odin.ietf.org [132.151.1.176]) by above.proper.com (8.11.6/8.11.3) with ESMTP id f9GB8UD12457 for <[e-mail]>; Tue, 16 Oct 2001 04:08:30 -0700 (PDT)
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA09161; Tue, 16 Oct 2001 07:08:28 -0400 (EDT)
Message-Id: <[e-mail]>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Cc: [e-mail]
From: [e-mail]
Reply-to: [e-mail]
Subject: I-D ACTION:draft-ietf-pkix-new-part1-09.txt
Date: Tue, 16 Oct 2001 07:08:28 -0400
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-pkix.imc.org>

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Public-Key Infrastructure (X.509) Working Group of the IETF.

	Title		: Internet X.509 Public Key Infrastructure Certificate 
                          and CRL Profile
	Author(s)	: R. Housley, W. Ford, W. Polk, D. Solo
	Filename	: draft-ietf-pkix-new-part1-09.txt
	Pages		: 128
	Date		: 15-Oct-01
	
This is the ninth draft of a specification based upon RFC 2459.  When
complete, this specification will obsolete RFC 2459.
Please send comments on this document to the [e-mail] mail
list.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-pkix-new-part1-09.txt

To remove yourself from the IETF Announcement list, send a message to 
ietf-announce-request with the word unsubscribe in the body of the message.

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-pkix-new-part1-09.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt


Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[e-mail].
In the body type:
	"FILE /internet-drafts/draft-ietf-pkix-new-part1-09.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.
		
		
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body;
	access-type="mail-server";
	server="[e-mail]"

Content-Type: text/plain
Content-ID:	<[e-mail]>

ENCODING mime
FILE /internet-drafts/draft-ietf-pkix-new-part1-09.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-pkix-new-part1-09.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:	<[e-mail]>

--OtherAccess--

--NextPart--




Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id f9GB8QE12453 for ietf-pkix-bks; Tue, 16 Oct 2001 04:08:26 -0700 (PDT)
Received: from ietf.org (odin.ietf.org [132.151.1.176]) by above.proper.com (8.11.6/8.11.3) with ESMTP id f9GB8OD12448 for <[e-mail]>; Tue, 16 Oct 2001 04:08:24 -0700 (PDT)
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA09145; Tue, 16 Oct 2001 07:08:22 -0400 (EDT)
Message-Id: <[e-mail]>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Cc: [e-mail]
From: [e-mail]
Reply-to: [e-mail]
Subject: I-D ACTION:draft-ietf-pkix-ipki-pkalgs-04.txt
Date: Tue, 16 Oct 2001 07:08:22 -0400
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-pkix.imc.org>

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Public-Key Infrastructure (X.509) Working Group of the IETF.

	Title		: Algorithms and Identifiers for the Internet X.509 
                          Public Key Infrastructure Certificate and CRI Profile
	Author(s)	: L. Bassham, R. Housley, W. Polk
	Filename	: draft-ietf-pkix-ipki-pkalgs-04.txt
	Pages		: 27
	Date		: 15-Oct-01
	
This document specifies algorithm identifiers and ASN.1 encoding
formats for digital signatures and subject public keys used in the
Internet X.509 Public Key Infrastructure (PKI).  Digital signatures
are used to sign certificates and certificate revocation lists
(CRLs).  Certificates include the public key of the named subject.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-pkix-ipki-pkalgs-04.txt

To remove yourself from the IETF Announcement list, send a message to 
ietf-announce-request with the word unsubscribe in the body of the message.

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-pkix-ipki-pkalgs-04.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt


Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[e-mail].
In the body type:
	"FILE /internet-drafts/draft-ietf-pkix-ipki-pkalgs-04.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.
		
		
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body;
	access-type="mail-server";
	server="[e-mail]"

Content-Type: text/plain
Content-ID:	<[e-mail]>

ENCODING mime
FILE /internet-drafts/draft-ietf-pkix-ipki-pkalgs-04.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-pkix-ipki-pkalgs-04.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:	<[e-mail]>

--OtherAccess--

--NextPart--




Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id f9BKjB116192 for ietf-pkix-bks; Thu, 11 Oct 2001 13:45:11 -0700 (PDT)
Received: from tholian.securitydynamics.com (mail.rsasecurity.com [204.167.112.129]) by above.proper.com (8.11.6/8.11.3) with SMTP id f9BKj8D16187 for <[e-mail]>; Thu, 11 Oct 2001 13:45:08 -0700 (PDT)
Received: from sdtihq24.securitydynamics.com by tholian.securitydynamics.com via smtpd (for mail.imc.org [208.184.76.43]) with SMTP; 11 Oct 2001 20:41:55 UT
Received: from ebola.securitydynamics.com (ebola.securid.com [192.168.7.4]) by sdtihq24.securid.com (Pro-8.9.3/Pro-8.9.3) with ESMTP id QAA08752 for <[e-mail]>; Thu, 11 Oct 2001 16:45:10 -0400 (EDT)
Received: from spirit.dynas.se (localhost [127.0.0.1]) by ebola.securitydynamics.com (8.9.3+Sun/8.9.1) with SMTP id QAA07221 for <[e-mail]>; Thu, 11 Oct 2001 16:45:09 -0400 (EDT)
Received: (qmail 21122 invoked from network); 11 Oct 2001 20:45:08 -0000
Received: from dsf.dynas.se (192.168.102.2) by spirit.dynas.se with SMTP; 11 Oct 2001 20:45:08 -0000
Received: (qmail 511 invoked from network); 11 Oct 2001 20:45:08 -0000
Received: from karoni.sto.dynas.se (HELO mnystrom-lap) (192.168.102.2) by karoni.sto.dynas.se with SMTP; 11 Oct 2001 20:45:08 -0000
Date: Thu, 11 Oct 2001 22:46:13 +0200 (W. Europe Daylight Time)
From: Magnus Nystrom <[e-mail]>
Reply-To: =?iso-8859-1?Q?Magnus_Nystr=F6m?= <[e-mail]>
To: <[e-mail]>
Subject: Re: Polling in CMP
Message-ID: <Pine.WNT.4.31.0110112245380.1168-100000@mnystrom-lap>
X-X-Sender: [e-mail]
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-pkix.imc.org>

Amit,

Thanks for your comments.

On Mon, 17 Sep 2001, Amit Kapoor wrote:

> Hi Magnus, Gareth,
>
>      A quick glance seems the proposal is inline with the original
> discussion. However, I would like to expand the scope of polling a
> little bit.  One of the other problems we have been dealing with is
> that issuance of certificates sometimes require a back and forth
> question & answer session between the end entity and the server
> for identity authentication.  The current interoperable subset of
> the CMP protocol assumes

> (a) all the information needed by the server is in the original
> request or
> (b) the server does out of band verification if information needed
> is not sufficient.
>
>      I believe this requirement is generic enough to require
> interoperable support and should go into the CMP protocol.  Based on
> the use of the proposed CMP poll request & response, it looks like a
> good choice. Would like to hear your thoughts......

This is probably rather a question for the ir/ip pair, or cr/cp,
perhaps in conjunction with enhancements to PKIStatus. In any event, I
rather not mix the polling functionality with interactions between the
RA/CA and the EE.

BR,
-- Magnus




Received: by above.proper.com (8.11.6/8.11.3) id f99EeQd14569 for ietf-pkix-bks; Tue, 9 Oct 2001 07:40:26 -0700 (PDT)
Received: from kakapo.cs.auckland.ac.nz (kakapo.cs.auckland.ac.nz [130.216.34.10]) by above.proper.com (8.11.6/8.11.3) with ESMTP id f99EeMD14562 for <[e-mail]>; Tue, 9 Oct 2001 07:40:22 -0700 (PDT)
Received: from ruru.cs.auckland.ac.nz (firebird.cs.auckland.ac.nz [130.216.34.12]) by kakapo.cs.auckland.ac.nz (8.8.6/8.8.6/cs-master) with ESMTP id DAA23529; Wed, 10 Oct 2001 03:40:18 +1300 (NZDT) (sender [e-mail])
Received: (from pgut001@localhost) by ruru.cs.auckland.ac.nz (8.9.3/8.8.6/cs-slave) id DAA370341; Wed, 10 Oct 2001 03:40:18 +1300 (NZDT) (sender [e-mail])
Date: Wed, 10 Oct 2001 03:40:18 +1300 (NZDT)
Message-ID: <[e-mail]>
From: [e-mail] (Peter Gutmann)
To: [e-mail], [e-mail]
Subject: Re: New test TSA available
Cc: [e-mail]
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-pkix.imc.org>

Bernd Matthes <[e-mail]> writes:

>But the next question: You send the root of the TSA cert in certificates
>field. My verify function complains that a self sign cert is in cert chain.
>Should I tolerate this or is the complaint ok? I'm not sure.

Given the open-ended interpretation of what you can put in there, I'm sure it
could be argued that stuffing PGP certs in there is valid.  For my part, I just
put the whole chain in and let the relying party pepper and salt it as they
please.

Peter.


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id f99DuuD13148 for ietf-pkix-bks; Tue, 9 Oct 2001 06:56:56 -0700 (PDT)
Received: from brot.celocom.de (brot.celocom.de [212.78.104.200]) by above.proper.com (8.11.6/8.11.3) with ESMTP id f99DusD13144 for <[e-mail]>; Tue, 9 Oct 2001 06:56:55 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by brot.celocom.de (Postfix) with ESMTP id 243C83000D; Tue,  9 Oct 2001 15:56:41 +0200 (CEST)
Received: from frolic.celocom.de (frolic.celocom.de [212.78.104.90]) by brot.celocom.de (Postfix) with ESMTP id 1D5B630009; Tue,  9 Oct 2001 15:56:39 +0200 (CEST)
Date: Tue, 09 Oct 2001 15:56:28 +0200
From: Bernd Matthes <[e-mail]>
X-Mailer: Mozilla 4.78 [en] (WinNT; U)
X-Accept-Language: de,en
MIME-Version: 1.0
To: Peter Gutmann <[e-mail]>
Cc: [e-mail]
Subject: Re: New test TSA available
References: <[e-mail]>
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms01470819F60469801D9F722B"
Message-Id: <[e-mail]>
X-Virus-Scanned: by AMaViS perl-11
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-pkix.imc.org>

This is a cryptographically signed message in MIME format.

--------------ms01470819F60469801D9F722B
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Peter Gutmann wrote:
> 
> >In parsing the response I got an ASN.1 error.
> 
> It's already fixed (I was using the PKCS #7 rather than CMS interpretation),
> but because it's a pain to update the system it's running on it's still using
> old code.  I'll have to reload the system at some point...
> 
> Peter.

Hi Peter!

Today I've test again Your TSA server. It looks good.

But the next question: You send the root of the TSA cert
in certificates field. My verify function complains 
that a self sign cert is in cert chain. 
Should I tolerate this or is the complaint ok?
I'm not sure.


with kind regards
-- 
Bernd Matthes               Celo Communications GmbH
Senior Software Engineer          - a Gemplus Company
Dipl.-Ing.(FH)              mailto:[e-mail]
------------------------------------------------------------
"Complexity breeds bugs. Bugs prevent adoption,
lack of adoption results in death. Death not good."
--------------ms01470819F60469801D9F722B
Content-Type: application/x-pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature

MIIH6gYJKoZIhvcNAQcCoIIH2zCCB9cCAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC
Bb0wggKMMIIB9aADAgECAgMEZkswDQYJKoZIhvcNAQEEBQAwgZIxCzAJBgNVBAYTAlpBMRUw
EwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEPMA0GA1UEChMGVGhh
d3RlMR0wGwYDVQQLExRDZXJ0aWZpY2F0ZSBTZXJ2aWNlczEoMCYGA1UEAxMfUGVyc29uYWwg
RnJlZW1haWwgUlNBIDIwMDAuOC4zMDAeFw0wMTAzMTYxNDA0MzJaFw0wMjAzMTYxNDA0MzJa
MEsxHzAdBgNVBAMTFlRoYXd0ZSBGcmVlbWFpbCBNZW1iZXIxKDAmBgkqhkiG9w0BCQEWGWJl
cm5kLm1hdHRoZXNAZ2VtcGx1cy5jb20wgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBANAA
w8BVu1sFXcFZ0RiaI1E7cQGzD/ilmkCBs2shzSy/ORqzS5XCQvXat5tbDgWQg1qKKvh4gvly
pgwvJtnyOyqUBJ6/L+BiFHYsSgFZZ8dWCSnJFPWbYtvrAzvN3IhkRgkOiit/jo6mIOFDjQKm
ZbxC2sQzcuf3eUJVL5zXvjmnAgMBAAGjNjA0MCQGA1UdEQQdMBuBGWJlcm5kLm1hdHRoZXNA
Z2VtcGx1cy5jb20wDAYDVR0TAQH/BAIwADANBgkqhkiG9w0BAQQFAAOBgQBy4Avl5Chdn6uQ
MnVuQd14NYuqtWZaAPL84JN0P6mEfrSxjvb/XsQNXBnfFeBe9dC28ENTWQqboh2EYlhM1LjD
+BmyyORFcEbJWqQce76vBXu7HAQXo+3GlesUKy3bW34z/bMdbiovChqBxTCbSxe1qCzxdFS3
WDxx+LaaIFJUGDCCAykwggKSoAMCAQICAQwwDQYJKoZIhvcNAQEEBQAwgdExCzAJBgNVBAYT
AlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEaMBgGA1UE
ChMRVGhhd3RlIENvbnN1bHRpbmcxKDAmBgNVBAsTH0NlcnRpZmljYXRpb24gU2VydmljZXMg
RGl2aXNpb24xJDAiBgNVBAMTG1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBDQTErMCkGCSqG
SIb3DQEJARYccGVyc29uYWwtZnJlZW1haWxAdGhhd3RlLmNvbTAeFw0wMDA4MzAwMDAwMDBa
Fw0wMjA4MjkyMzU5NTlaMIGSMQswCQYDVQQGEwJaQTEVMBMGA1UECBMMV2VzdGVybiBDYXBl
MRIwEAYDVQQHEwlDYXBlIFRvd24xDzANBgNVBAoTBlRoYXd0ZTEdMBsGA1UECxMUQ2VydGlm
aWNhdGUgU2VydmljZXMxKDAmBgNVBAMTH1BlcnNvbmFsIEZyZWVtYWlsIFJTQSAyMDAwLjgu
MzAwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAN4zMqZjxwklRT7SbngnZ4HF2ogZgpcO
40QpimM1Km1wPPrcrvfudG8wvDOQf/k0caCjbZjxw0+iZdsN+kvx1t1hpfmFzVWaNRqdknWo
J67Ycvm6AvbXsJHeHOmr4BgDqHxDQlBRh4M88Dm0m1SKE4f/s5udSWYALQmJ7JRr6aFpAgMB
AAGjTjBMMCkGA1UdEQQiMCCkHjAcMRowGAYDVQQDExFQcml2YXRlTGFiZWwxLTI5NzASBgNV
HRMBAf8ECDAGAQH/AgEAMAsGA1UdDwQEAwIBBjANBgkqhkiG9w0BAQQFAAOBgQBzG28mZYv/
FTRLWWKK7US+ScfoDbuPuQ1qJipihB+4h2N0HG23zxpTkUvhzeY42e1Q9DpsNJKs5pKcbsEj
AcIJp+9LrnLdBmf1UG8uWLi2C8FQV7XsHNfvF7bViJu3ooga7TlbOX00/LaWGCVNavSdxcOR
L6mWuAU8Uvzd6WIDSDGCAfUwggHxAgEBMIGaMIGSMQswCQYDVQQGEwJaQTEVMBMGA1UECBMM
V2VzdGVybiBDYXBlMRIwEAYDVQQHEwlDYXBlIFRvd24xDzANBgNVBAoTBlRoYXd0ZTEdMBsG
A1UECxMUQ2VydGlmaWNhdGUgU2VydmljZXMxKDAmBgNVBAMTH1BlcnNvbmFsIEZyZWVtYWls
IFJTQSAyMDAwLjguMzACAwRmSzAJBgUrDgMCGgUAoIGxMBgGCSqGSIb3DQEJAzELBgkqhkiG
9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTAxMTAwOTEzNTYzNVowIwYJKoZIhvcNAQkEMRYEFNjR
oZilfQUv9qZPGhWznT9BdHgdMFIGCSqGSIb3DQEJDzFFMEMwCgYIKoZIhvcNAwcwDgYIKoZI
hvcNAwICAgCAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgFAMA0GCCqGSIb3DQMCAgEoMA0GCSqG
SIb3DQEBAQUABIGArLsucU8CQ7Z/gE5H48W0sbjYuK0lCcKGxMhJcZp0+EQP/An31XEoIrI+
KzHvhHemuF1or9uqGoQ0UC9N9naTUYd4h4bVDokruRHJlwhdHs2ySQN5nxal/P1biR90uyuG
vMdVcRa9+bhStH9MrmvmrXOE+sW/RfXTieVm2wSx6zk=
--------------ms01470819F60469801D9F722B--



Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id f962PEQ23375 for ietf-pkix-bks; Fri, 5 Oct 2001 19:25:14 -0700 (PDT)
Received: from ns.scan.utm.my (ns.scan.utm.my [161.139.189.189]) by above.proper.com (8.11.6/8.11.3) with ESMTP id f962PBD23371 for <[e-mail]>; Fri, 5 Oct 2001 19:25:12 -0700 (PDT)
Received: from scan04 (BlowFish.scan.utm.my [161.139.189.8]) by ns.scan.utm.my (8.10.1/8.10.1) with SMTP id f962Fqp03520 for <[e-mail]>; Sat, 6 Oct 2001 10:15:52 +0800
Message-ID: <001401c14e0e$bf227660$[e-mail]>
From: "Rachel" <[e-mail]>
To: <[e-mail]>
Subject: Key Recovery in PKIX CMP
Date: Sat, 6 Oct 2001 10:29:37 +0800
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.50.4807.1700
X-MIMEOLE: Produced By Microsoft MimeOLE V5.50.4807.1700
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-pkix.imc.org>

Hi all,

I have some questions here regarding the PKI messages used for key recovery purposes.
They are Key Recovery Request and Key Recovery Response messages.
According to RFC2510 and RFC2511, the key recovery request is of type CertReqMessages and
KeyRecRepContent respectively.  My questions are:

1) Why the key recovery request is made identical as cert request format ? I can't see both of them
have the same nature.Cert request is used when someone want to register for his new key pair.  In
order to complete that, one has to send in the CertTemplate with all those necessary fields filled
in, also, he has to provide Proof-of-Possession about his key pair.  Now, if we look at the typical
procedure for a key recovery system (or key escrow system), anyone (the owner of the key, a third
party) can issue a request for the recovery of the key.  In this context, does the key recovery
requester need to send in the cert template again ?  Also, how can an authorised third party
presents his POP of the key to be recovered (although he is not the owner, but he has the right to
do so) ??

2) The 2nd question is about the key recovery response PKI message.  Does anyone know why
newSigCert, caCerts and keyPairHist is returned to the recovery requester ?  And can you explain the
scenario is which the new signature certificate should be returned and why ?  The RFC I have do not
cover that, I mean the explanation on the existance of a particular field.

Hope to hear from you soon.  Thanks in advance.

regards,
Rachel
UTM




Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id f9375CR25594 for ietf-pkix-bks; Wed, 3 Oct 2001 00:05:12 -0700 (PDT)
Received: from kakapo.cs.auckland.ac.nz (kakapo.cs.auckland.ac.nz [130.216.34.10]) by above.proper.com (8.11.6/8.11.3) with ESMTP id f9375BD25585 for <[e-mail]>; Wed, 3 Oct 2001 00:05:11 -0700 (PDT)
Received: from ruru.cs.auckland.ac.nz (firebird.cs.auckland.ac.nz [130.216.34.12]) by kakapo.cs.auckland.ac.nz (8.8.6/8.8.6/cs-master) with ESMTP id TAA09599; Wed, 3 Oct 2001 19:05:04 +1200 (NZST) (sender [e-mail])
Received: (from pgut001@localhost) by ruru.cs.auckland.ac.nz (8.9.3/8.8.6/cs-slave) id TAA155964; Wed, 3 Oct 2001 19:05:04 +1200 (NZST) (sender [e-mail])
Date: Wed, 3 Oct 2001 19:05:04 +1200 (NZST)
Message-ID: <[e-mail]>
From: [e-mail] (Peter Gutmann)
To: [e-mail], [e-mail]
Subject: Re: New test TSA available
Cc: [e-mail]
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-pkix.imc.org>

>In parsing the response I got an ASN.1 error.

It's already fixed (I was using the PKCS #7 rather than CMS interpretation),
but because it's a pain to update the system it's running on it's still using
old code.  I'll have to reload the system at some point...

Peter.


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id f92HLrT22135 for ietf-pkix-bks; Tue, 2 Oct 2001 10:21:53 -0700 (PDT)
Received: from brot.celocom.de (brot.celocom.de [212.78.104.200]) by above.proper.com (8.11.6/8.11.3) with ESMTP id f92HLqD22124 for <[e-mail]>; Tue, 2 Oct 2001 10:21:52 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by brot.celocom.de (Postfix) with ESMTP id 948353000D; Tue,  2 Oct 2001 19:21:42 +0200 (CEST)
Received: from frolic.celocom.de (frolic.celocom.de [212.78.104.90]) by brot.celocom.de (Postfix) with ESMTP id 698F830009; Tue,  2 Oct 2001 19:21:40 +0200 (CEST)
Message-ID: <[e-mail]>
Date: Tue, 02 Oct 2001 19:21:34 +0200
From: Bernd Matthes <[e-mail]>
X-Mailer: Mozilla 4.78 [en] (WinNT; U)
X-Accept-Language: de,en
MIME-Version: 1.0
To: Peter Gutmann <[e-mail]>
Cc: [e-mail]
Subject: Re: New test TSA available
References: <[e-mail]>
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------msA8F728CBE5F315DD03FE3248"
X-Virus-Scanned: by AMaViS perl-11
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-pkix.imc.org>

This is a cryptographically signed message in MIME format.

--------------msA8F728CBE5F315DD03FE3248
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Peter Gutmann wrote:
> 
> There's a new TSA available at tsa.cryptoapps.com:3318, running in a FIPS 140-1
> level 4 device (it's just a demo which runs single-threaded, so if you throw
> a huge number of concurrent requests at it you may get some refused
> connections, although I doubt it'll be a big issue for now).  There will also
> be an OCSP responder at ocsp.cryptoapps.com and a CMP server at
> cmp.cryptoapps.com in the near future running on the same hardware, at the
> moment I think the ports are still blocked so you won't be able to get to them.
> 
> Peter.

Hi Peter!

I tried Your TSA.
I could connect and got a response.
In parsing the response I got an ASN.1 error.
Here is Yours: 
   0 30 1706: SEQUENCE {
   4 30    3: . SEQUENCE {
   6 02    1: . . INTEGER 0
            : . . }
   9 30 1697: . SEQUENCE {
  13 06    9: . . OBJECT IDENTIFIER pkcs7signedData (1 2 840 113549 1 7
2)
  24 A0 1682: . . [CONTEXT-SPECIFIC 0] {
  28 30 1678: . . . SEQUENCE {
  32 02    1: . . . . INTEGER 1
  35 31   11: . . . . SET {
  37 30    9: . . . . . SEQUENCE {
  39 06    5: . . . . . . OBJECT IDENTIFIER sha1 (1 3 14 3 2 26)
  46 05    0: . . . . . . NULL
            : . . . . . . }
            : . . . . . }
  48 30  121: . . . . SEQUENCE {
  50 06   11: . . . . . OBJECT IDENTIFIER
            : . . . . . . id-smime-ct-TSTInfo (1 2 840 113549 1 9 16 1
4)
  63 A0  106: . . . . . [CONTEXT-SPECIFIC 0] {
  65 30  104: . . . . . . SEQUENCE {
      ^---- My question: Should this tag be an OCTET STRING like in the
dump below?

  67 30  102: . . . . . . . SEQUENCE {
  69 02    1: . . . . . . . . INTEGER 1
  72 06   10: . . . . . . . . OBJECT IDENTIFIER '1 3 6 1 4 1 3029 56 36
54'

and now a other:
   0 30 1583: SEQUENCE {
   4 30    3: . SEQUENCE {
   6 02    1: . . INTEGER 0
            : . . }
   9 30 1574: . SEQUENCE {
  13 06    9: . . OBJECT IDENTIFIER pkcs7signedData (1 2 840 113549 1 7
2)
  24 A0 1559: . . [CONTEXT-SPECIFIC 0] {
  28 30 1555: . . . SEQUENCE {
  32 02    1: . . . . INTEGER 1
  35 31   11: . . . . SET {
  37 30    9: . . . . . SEQUENCE {
  39 06    5: . . . . . . OBJECT IDENTIFIER sha1 (1 3 14 3 2 26)
  46 05    0: . . . . . . NULL
            : . . . . . . }
            : . . . . . }
  48 30  312: . . . . SEQUENCE {
  52 06   11: . . . . . OBJECT IDENTIFIER
            : . . . . . . id-smime-ct-TSTInfo (1 2 840 113549 1 9 16 1
4)
  65 A0  295: . . . . . [CONTEXT-SPECIFIC 0] {
  69 04  291: . . . . . . OCTET STRING, encapsulates {
  73 30  287: . . . . . . . . SEQUENCE {
  77 02    1: . . . . . . . . . INTEGER 1



with kind regards

-- 
Bernd Matthes               Celo Communications GmbH
Senior Software Engineer          - a Gemplus Company
Dipl.-Ing.(FH)              mailto:[e-mail]
------------------------------------------------------------
"Complexity breeds bugs. Bugs prevent adoption,
lack of adoption results in death. Death not good."
--------------msA8F728CBE5F315DD03FE3248
Content-Type: application/x-pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature

MIIH6gYJKoZIhvcNAQcCoIIH2zCCB9cCAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC
Bb0wggKMMIIB9aADAgECAgMEZkswDQYJKoZIhvcNAQEEBQAwgZIxCzAJBgNVBAYTAlpBMRUw
EwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEPMA0GA1UEChMGVGhh
d3RlMR0wGwYDVQQLExRDZXJ0aWZpY2F0ZSBTZXJ2aWNlczEoMCYGA1UEAxMfUGVyc29uYWwg
RnJlZW1haWwgUlNBIDIwMDAuOC4zMDAeFw0wMTAzMTYxNDA0MzJaFw0wMjAzMTYxNDA0MzJa
MEsxHzAdBgNVBAMTFlRoYXd0ZSBGcmVlbWFpbCBNZW1iZXIxKDAmBgkqhkiG9w0BCQEWGWJl
cm5kLm1hdHRoZXNAZ2VtcGx1cy5jb20wgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBANAA
w8BVu1sFXcFZ0RiaI1E7cQGzD/ilmkCBs2shzSy/ORqzS5XCQvXat5tbDgWQg1qKKvh4gvly
pgwvJtnyOyqUBJ6/L+BiFHYsSgFZZ8dWCSnJFPWbYtvrAzvN3IhkRgkOiit/jo6mIOFDjQKm
ZbxC2sQzcuf3eUJVL5zXvjmnAgMBAAGjNjA0MCQGA1UdEQQdMBuBGWJlcm5kLm1hdHRoZXNA
Z2VtcGx1cy5jb20wDAYDVR0TAQH/BAIwADANBgkqhkiG9w0BAQQFAAOBgQBy4Avl5Chdn6uQ
MnVuQd14NYuqtWZaAPL84JN0P6mEfrSxjvb/XsQNXBnfFeBe9dC28ENTWQqboh2EYlhM1LjD
+BmyyORFcEbJWqQce76vBXu7HAQXo+3GlesUKy3bW34z/bMdbiovChqBxTCbSxe1qCzxdFS3
WDxx+LaaIFJUGDCCAykwggKSoAMCAQICAQwwDQYJKoZIhvcNAQEEBQAwgdExCzAJBgNVBAYT
AlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEaMBgGA1UE
ChMRVGhhd3RlIENvbnN1bHRpbmcxKDAmBgNVBAsTH0NlcnRpZmljYXRpb24gU2VydmljZXMg
RGl2aXNpb24xJDAiBgNVBAMTG1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBDQTErMCkGCSqG
SIb3DQEJARYccGVyc29uYWwtZnJlZW1haWxAdGhhd3RlLmNvbTAeFw0wMDA4MzAwMDAwMDBa
Fw0wMjA4MjkyMzU5NTlaMIGSMQswCQYDVQQGEwJaQTEVMBMGA1UECBMMV2VzdGVybiBDYXBl
MRIwEAYDVQQHEwlDYXBlIFRvd24xDzANBgNVBAoTBlRoYXd0ZTEdMBsGA1UECxMUQ2VydGlm
aWNhdGUgU2VydmljZXMxKDAmBgNVBAMTH1BlcnNvbmFsIEZyZWVtYWlsIFJTQSAyMDAwLjgu
MzAwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAN4zMqZjxwklRT7SbngnZ4HF2ogZgpcO
40QpimM1Km1wPPrcrvfudG8wvDOQf/k0caCjbZjxw0+iZdsN+kvx1t1hpfmFzVWaNRqdknWo
J67Ycvm6AvbXsJHeHOmr4BgDqHxDQlBRh4M88Dm0m1SKE4f/s5udSWYALQmJ7JRr6aFpAgMB
AAGjTjBMMCkGA1UdEQQiMCCkHjAcMRowGAYDVQQDExFQcml2YXRlTGFiZWwxLTI5NzASBgNV
HRMBAf8ECDAGAQH/AgEAMAsGA1UdDwQEAwIBBjANBgkqhkiG9w0BAQQFAAOBgQBzG28mZYv/
FTRLWWKK7US+ScfoDbuPuQ1qJipihB+4h2N0HG23zxpTkUvhzeY42e1Q9DpsNJKs5pKcbsEj
AcIJp+9LrnLdBmf1UG8uWLi2C8FQV7XsHNfvF7bViJu3ooga7TlbOX00/LaWGCVNavSdxcOR
L6mWuAU8Uvzd6WIDSDGCAfUwggHxAgEBMIGaMIGSMQswCQYDVQQGEwJaQTEVMBMGA1UECBMM
V2VzdGVybiBDYXBlMRIwEAYDVQQHEwlDYXBlIFRvd24xDzANBgNVBAoTBlRoYXd0ZTEdMBsG
A1UECxMUQ2VydGlmaWNhdGUgU2VydmljZXMxKDAmBgNVBAMTH1BlcnNvbmFsIEZyZWVtYWls
IFJTQSAyMDAwLjguMzACAwRmSzAJBgUrDgMCGgUAoIGxMBgGCSqGSIb3DQEJAzELBgkqhkiG
9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTAxMTAwMjE3MjEzNlowIwYJKoZIhvcNAQkEMRYEFGxM
svMxqsJqn4nRNzi5NKkTg68fMFIGCSqGSIb3DQEJDzFFMEMwCgYIKoZIhvcNAwcwDgYIKoZI
hvcNAwICAgCAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgFAMA0GCCqGSIb3DQMCAgEoMA0GCSqG
SIb3DQEBAQUABIGAayAD5gCYkB9HJkgWfg5qtZbnsu09Q+6UVqd+NtkbFyJr5XncYUfOky3k
dfjeuSVClpotvoMWSepbHg912ovnuMfq2ac7VZtV8ApdEbCGNQSUacbHGnSiHj140I1bCLYi
ZHdcKpxzuNssyUGUyAfrDbyQjk3jovcNx6hYN2HwaQI=
--------------msA8F728CBE5F315DD03FE3248--



Received: by above.proper.com (8.11.6/8.11.3) id f92ENGZ05813 for ietf-pkix-bks; Tue, 2 Oct 2001 07:23:16 -0700 (PDT)
Received: from hitiij.hitachi.co.jp (hitiij.hitachi.co.jp [133.145.224.3]) by above.proper.com (8.11.6/8.11.3) with ESMTP id f92ENFD05807 for <[e-mail]>; Tue, 2 Oct 2001 07:23:16 -0700 (PDT)
Received: from hitiij-kan.hitachi.co.jp by hitiij.hitachi.co.jp (8.9.3/3.7W-hitiij) id XAA11013; Tue, 2 Oct 2001 23:23:16 +0900 (JST)
Received: from navsg6.hitachi.co.jp by hitiij-kan.hitachi.co.jp (8.9.3/3.7W-hitiij-kan) id XAA23569; Tue, 2 Oct 2001 23:23:16 +0900 (JST)
Received: from vgate.hitachi.co.jp ([133.145.228.15]) by navsg6.hitachi.co.jp (NAVGW 2.5.1.12) with SMTP id M2001100223231605480 for <[e-mail]>; Tue, 02 Oct 2001 23:23:16 +0900
Received: from mlgw2.system.hitachi.co.jp by vgate.hitachi.co.jp (8.9.3/3.7W-vgate) id XAA08931; Tue, 2 Oct 2001 23:23:16 +0900 (JST)
Received: from mlgw3 by mlgw2.system.hitachi.co.jp (8.9.3/3.7W-mlgw2) id XAA04825; Tue, 2 Oct 2001 23:23:10 +0900 (JST)
Received: from bisdmlvg1.bisd.hitachi.co.jp by bisdgw.bisd.hitachi.co.jp (8.9.3+3.2W/3.7W-bisdgw) with SMTP id XAA24470 for <[e-mail]>; Tue, 2 Oct 2001 23:23:15 +0900 (JST) (envelope-from [e-mail])
Received: from localhost by bisdmail.bisd.hitachi.co.jp (8.9.3/3.7W-bisdmail) with ESMTP id XAA27254; Tue, 2 Oct 2001 23:23:08 +0900 (JST) (envelope-from [e-mail])
To: [e-mail]
Cc: [e-mail]
Subject: question about the DN Qualifier
From: Takeshi AKUTSU <[e-mail]>
X-Mailer: Mew version 1.94.1 on Emacs 19.34 / Mule 2.3 (SUETSUMUHANA)
Mime-Version: 1.0
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-Id: <[e-mail]>
Date: Tue, 02 Oct 2001 23:23:07 +0900 (JST)
X-Dispatcher: imput version 990905(IM130)
Lines: 37
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-pkix.imc.org>

Dear all,

I have a question about DN Qualifier.

RFC2459 states 
   Implementations of this specification MUST be prepared to 
   receive the following standard attribute types in issuer
   names: country, organization, organizational-unit, 
   distinguished name qualifier, state or province name,  
   and common name (e.g., "SusanHousley").

but I don't understand how the DN Qualifier is used.

I put the following description of X.520(draft). 
I confuse the DSA part.
How can I use the DN Qualifier? 
Is there any good example how to use it?

-----------------
5.2.8	DN Qualifier 

The DN Qualifier attribute type specifies disambiguating information
to add to the relative distinguished name of an entry. It is intended
to be used for entries held in multiple DSAs which would otherwise
have the same name, and that its value be the same in a given DSA for
all entries to which this information has been added.
-----------------

Sincerely,



Takeshi AKUTSU  <[e-mail]> 
Hitachi,Ltd. Business & Information System Development Division
Electronic Commerce Department