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

From: Peter Sylvester <[email-masked]>
Date: Wed, 31 Oct 2001 18:58:29 +0100 (MET)

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
> 

From: Peter Sylvester <[email-masked]>
Date: Wed, 31 Oct 2001 18:58:29 +0100 (MET)
To: [email-masked], [email-masked]
Subject: Re: draft-ietf-pkix-dsv-dpv-dpd-req-00.txt
Cc: [email-masked], [email-masked]
Sender: [email-masked]

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
> 

From: "Housley, Russ" <[email-masked]>
To: Peter Sylvester <[email-masked]>
Cc: [email-masked]
Date: Wed, 31 Oct 2001 11:41:40 -0500
Subject: Re: draft-ietf-pkix-dsv-dpv-dpd-req-00.txt
Sender: [email-masked]

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

From: Peter Sylvester <[email-masked]>
Date: Wed, 31 Oct 2001 13:14:10 +0100 (MET)
To: [email-masked], [email-masked], [email-masked], [email-masked]
Subject: Re: draft-ietf-pkix-dsv-dpv-dpd-req-00.txt
Sender: [email-masked]

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

Date: Tue, 30 Oct 2001 17:34:41 -0800
To: Peter Sylvester <[email-masked]>, [email-masked], [email-masked]
From: Paul Hoffman / IMC <[email-masked]>
Subject: Re: draft-ietf-pkix-dsv-dpv-dpd-req-00.txt
Sender: [email-masked]

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

From: Peter Sylvester <[email-masked]>
Date: Tue, 30 Oct 2001 19:48:00 +0100 (MET)
To: [email-masked], [email-masked], [email-masked], [email-masked]
Subject: Re: draft-ietf-pkix-dsv-dpv-dpd-req-00.txt
Sender: [email-masked]

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

Content-return: allowed
Date: Tue, 30 Oct 2001 10:19:06 -0800
From: Ambarish Malpani <[email-masked]>
Subject: RE: draft-ietf-pkix-dsv-dpv-dpd-req-00.txt
To: [email-masked]
Sender: [email-masked]

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.                                  [email-masked]
339 N. Bernardo Ave.                          http://www.valicert.com
Mountain View, CA 94043

> -----Original Message-----
> From: Paul Hoffman / IMC [mailto:[email-masked]]
> Sent: Tuesday, October 30, 2001 8:53 AM
> To: [email-masked]; [email-masked]
> 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
> 

Date: Tue, 30 Oct 2001 10:10:27 -0800
To: Peter Sylvester <[email-masked]>, [email-masked], [email-masked]
From: Paul Hoffman / IMC <[email-masked]>
Subject: Re: draft-ietf-pkix-dsv-dpv-dpd-req-00.txt
Sender: [email-masked]

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

From: Peter Sylvester <[email-masked]>
Date: Tue, 30 Oct 2001 19:03:02 +0100 (MET)
To: [email-masked], [email-masked], [email-masked]
Subject: Re: draft-ietf-pkix-dsv-dpv-dpd-req-00.txt
Sender: [email-masked]

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

Date: Tue, 30 Oct 2001 17:31:23 +0000
From: Sean Mullan <[email-masked]>
Organization: Sun Microsystems
To: [email-masked]
Subject: PKIX roadmap
Sender: [email-masked]

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

Date: Tue, 30 Oct 2001 08:52:54 -0800
To: [email-masked] (Denis Pinkas), [email-masked]
From: Paul Hoffman / IMC <[email-masked]>
Subject: Re: draft-ietf-pkix-dsv-dpv-dpd-req-00.txt
Sender: [email-masked]

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

From: "Martin Szotkowski" <[email-masked]>
To: <[email-masked]>
Subject: maybe problem in RFC2459 with keyIdentifier
Date: Tue, 30 Oct 2001 16:27:31 +0100
Organization: PVT, a.s.
Sender: [email-masked]

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

From: "Stefan Kelm" <[email-masked]>
Organization: Secorvo Security Consulting GmbH
To: "Kronenberg, Peter" <[email-masked]>, "[email-masked]'" <[email-masked]>
Date: Tue, 30 Oct 2001 09:42:52 +0100
Subject: Re: Software for PKI
Reply-to: [email-masked]
Sender: [email-masked]

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. +49 721 6105-461, Fax +49 721 6105-455
E-Mail [email-masked], http://www.secorvo.de
-------------------------------------------------------
PGP Fingerprint 87AE E858 CCBC C3A2 E633 D139 B0D9 212B

Date: Tue, 30 Oct 2001 00:11:06 +0100
From: Massimiliano Pala <[email-masked]>
Organization: OpenCA
Cc: [email-masked]
Subject: Re: Software for PKI
Sender: [email-masked]

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]                  [email-masked]
                                                          [email-masked]
                                                     [email-masked]
http://www.openca.org                            Tel.:   +39 (0)59  270  094
http://openca.sourceforge.net                    Mobile: +39 (0)347 7222 365
--------------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

--------------msAE87A5BA7C82CB9CAD23C904--

Subject: Re: Software for PKI
To: "[email-masked]'" <[email-masked]>
From: "Bernhard Weber" <[email-masked]>
Date: Mon, 29 Oct 2001 18:50:13 +0100
Sender: [email-masked]

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

Date: Sat, 27 Oct 2001 14:05:44 +1300 (NZDT)
From: [email-masked] (Peter Gutmann)
To: [email-masked], [email-masked]
Subject: Re:  Software for PKI
Sender: [email-masked]

"Kronenberg, Peter" <[email-masked]> 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.

content-class: urn:content-classes:message
Subject: RE: Software for PKI
Date: Fri, 26 Oct 2001 12:51:05 -0400
From: "Michael J. Rowan" <[email-masked]>
To: "Kronenberg, Peter" <[email-masked]>, <[email-masked]>
Sender: [email-masked]

-----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:
[email-masked] (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:[email-masked]]
Sent: Friday, October 26, 2001 10:24 AM
To: [email-masked]'
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

From: "Housley, Russ" <[email-masked]>
To: Denis Pinkas <[email-masked]>
Cc: [email-masked]
Date: Thu, 25 Oct 2001 18:47:07 -0400
Subject: Re: draft-ietf-pkix-dsv-dpv-dpd-req-00.txt
Sender: [email-masked]

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

Date: Fri, 26 Oct 2001 15:36:36 +0100
From: Sean Mullan <[email-masked]>
Organization: Sun Microsystems
To: "Kronenberg, Peter" <[email-masked]>
CC: "[email-masked]'" <[email-masked]>
Subject: Re: Software for PKI
Sender: [email-masked]

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

From: "Kronenberg, Peter" <[email-masked]>
To: "[email-masked]'" <[email-masked]>
Subject: Software for PKI
Date: Fri, 26 Oct 2001 15:24:09 +0100
Sender: [email-masked]

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

To: IETF-Announce: ;
Cc: [email-masked]
From: [email-masked]
Reply-to: [email-masked]
Subject: I-D ACTION:draft-ietf-pkix-new-part1-11.txt
Date: Fri, 26 Oct 2001 07:03:41 -0400
Sender: [email-masked]

--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 [email-masked] 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:
	[email-masked].
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="[email-masked]"

Content-Type: text/plain
Content-ID:	<[email-masked]>

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:	<[email-masked]>

--OtherAccess--

--NextPart--

To: IETF-Announce: ;
Cc: [email-masked]
From: [email-masked]
Reply-to: [email-masked]
Subject: I-D ACTION:draft-ietf-pkix-ipki-pkalgs-05.txt
Date: Fri, 26 Oct 2001 07:03:35 -0400
Sender: [email-masked]

--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:
	[email-masked].
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="[email-masked]"

Content-Type: text/plain
Content-ID:	<[email-masked]>

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:	<[email-masked]>

--OtherAccess--

--NextPart--

From: [email-masked] (Denis Pinkas)
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
To: [email-masked]
Sender: [email-masked]

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

Date: Thu, 25 Oct 2001 18:55:54 +0200
From: Denis Pinkas <[email-masked]>
Organization: Integris. A Bull Company
To: "Housley, Russ" <[email-masked]>
CC: [email-masked]
Subject: Re: draft-ietf-pkix-dsv-dpv-dpd-req-00.txt
Sender: [email-masked]

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

From: [email-masked] ("Housley, Russ")
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
To: [email-masked]
Sender: [email-masked]

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

Date: Wed, 24 Oct 2001 09:01:24 -0400
To: [email-masked]
From: "Housley, Russ" <[email-masked]>
Subject: draft-ietf-pkix-dsv-dpv-dpd-req-00.txt
Sender: [email-masked]

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

From: Santosh Chokhani <[email-masked]>
To: "Housley, Russ" <[email-masked]>, Santosh Chokhani <[email-masked]>
Cc: [email-masked]
Subject: RE: AW: I-D ACTION:draft-ietf-pkix-new-part1-09.txt
Date: Mon, 22 Oct 2001 11:13:23 -0400
Sender: [email-masked]

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:[email-masked]]
Sent: Monday, October 22, 2001 11:07 AM
To: Santosh Chokhani
Cc: [email-masked]
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:[email-masked]
<mailto:[email-masked]> ] 

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

To: Sharon Boeyen 

Cc: Santosh Chokhani; [email-masked] 

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:[email-masked]
<mailto:[email-masked]> ] 

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

To: Housley, Russ; Santosh Chokhani 

Cc: [email-masked] 

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:[email-masked]
<mailto:[email-masked]> ] 

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

To: Santosh Chokhani 

Cc: [email-masked] 

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:[email-masked]]<BR><B>Sent:</B> Monday, October 22, 2001 
  11:07 AM<BR><B>To:</B> Santosh Chokhani<BR><B>Cc:</B> 
  [email-masked]<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:[email-masked]" 
      eudora="autourl">mailto:[email-masked]</A>] 
      <DD>Sent:</B> Monday, October 22, 2001 9:20 AM 
      <DD>To:</B> Sharon Boeyen 
      <DD>Cc:</B> Santosh Chokhani; [email-masked] 
      <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:[email-masked]" 
        eudora="autourl">mailto:[email-masked]</A>] 
        <DD>Sent:</B> Friday, October 19, 2001 11:25 AM 
        <DD>To:</B> Housley, Russ; Santosh Chokhani 
        <DD>Cc:</B> [email-masked] 
        <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:[email-masked]">mailto:[email-masked]</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: [email-masked]</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--

From: "Housley, Russ" <[email-masked]>
To: Santosh Chokhani <[email-masked]>
Cc: [email-masked]
Date: Mon, 22 Oct 2001 11:06:44 -0400
Subject: RE: AW: I-D ACTION:draft-ietf-pkix-new-part1-09.txt
Sender: [email-masked]

<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:[email-masked]" eudora="autourl">mailto:[email-masked]</a>]
<dd>Sent:</b> Monday, October 22, 2001 9:20 AM
<dd>To:</b> Sharon Boeyen
<dd>Cc:</b> Santosh Chokhani; [email-masked]
<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:[email-masked]" eudora="autourl">mailto:[email-masked]</a>]
<dd>Sent:</b> Friday, October 19, 2001 11:25 AM
<dd>To:</b> Housley, Russ; Santosh Chokhani
<dd>Cc:</b> [email-masked]
<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:[email-masked]">mailto:[email-masked]</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: [email-masked]</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>

From: Santosh Chokhani <[email-masked]>
To: "Housley, Russ" <[email-masked]>, Sharon Boeyen <[email-masked]>
Cc: Santosh Chokhani <[email-masked]>, [email-masked]
Subject: RE: AW: I-D ACTION:draft-ietf-pkix-new-part1-09.txt
Date: Mon, 22 Oct 2001 09:41:35 -0400
Sender: [email-masked]

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:[email-masked]]
Sent: Monday, October 22, 2001 9:20 AM
To: Sharon Boeyen
Cc: Santosh Chokhani; [email-masked]
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:[email-masked]
<mailto:[email-masked]> ]
Sent: Friday, October 19, 2001 11:25 AM
To: Housley, Russ; Santosh Chokhani
Cc: [email-masked]
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:[email-masked]
<mailto:[email-masked]> ] 

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

To: Santosh Chokhani 

Cc: [email-masked] 

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:[email-masked]]<BR><B>Sent:</B> Monday, October 22, 2001 
  9:20 AM<BR><B>To:</B> Sharon Boeyen<BR><B>Cc:</B> Santosh Chokhani; 
  [email-masked]<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:[email-masked]" 
    eudora="autourl">mailto:[email-masked]</A>]<BR><B>Sent:</B> Friday, 
    October 19, 2001 11:25 AM<BR><B>To:</B> Housley, Russ; Santosh 
    Chokhani<BR><B>Cc:</B> [email-masked]<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:[email-masked]">mailto:[email-masked]</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: [email-masked]</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--

From: "Housley, Russ" <[email-masked]>
To: Sharon Boeyen <[email-masked]>
Cc: Santosh Chokhani <[email-masked]>, [email-masked]
Date: Mon, 22 Oct 2001 09:19:56 -0400
Subject: RE: AW: I-D ACTION:draft-ietf-pkix-new-part1-09.txt
Sender: [email-masked]

<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:[email-masked]" eudora="autourl">mailto:[email-masked]</a>]<br>
<b>Sent:</b> Friday, October 19, 2001 11:25 AM<br>
<b>To:</b> Housley, Russ; Santosh Chokhani<br>
<b>Cc:</b> [email-masked]<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:[email-masked]">mailto:[email-masked]</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: [email-masked]</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>

To: IETF-Announce: ;
Cc: [email-masked]
From: [email-masked]
Reply-to: [email-masked]
Subject: I-D ACTION:draft-ietf-pkix-dsv-dpv-dpd-req-00.txt
Date: Mon, 22 Oct 2001 07:03:26 -0400
Sender: [email-masked]

--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:
	[email-masked].
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="[email-masked]"

Content-Type: text/plain
Content-ID:	<[email-masked]>

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:	<[email-masked]>

--OtherAccess--

--NextPart--

From: Santosh Chokhani <[email-masked]>
To: Sharon Boeyen <[email-masked]>, "'Housley, Russ'" <[email-masked]>
Cc: "[email-masked]'" <[email-masked]>
Subject: RE: AW: I-D ACTION:draft-ietf-pkix-new-part1-09.txt
Date: Sat, 20 Oct 2001 16:28:09 -0400
Sender: [email-masked]

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: [email-masked]
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:[email-masked]]
Sent: Friday, October 19, 2001 11:25 AM
To: Housley, Russ; Santosh Chokhani
Cc: [email-masked]
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:[email-masked]
<mailto:[email-masked]> ] 
Sent: Friday, October 19, 2001 10:28 AM 
To: Santosh Chokhani 
Cc: [email-masked] 
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> [email-masked]<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:[email-masked]]<BR><B>Sent:</B> Friday, October 19, 2001 11:25 
  AM<BR><B>To:</B> Housley, Russ; Santosh Chokhani<BR><B>Cc:</B> 
  [email-masked]<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:[email-masked]">mailto:[email-masked]</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: 
    [email-masked]</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--

To: IETF-Announce: ;
Subject: RFC 3161 on Time-Stamp Protocol (TSP)
Cc: [email-masked], [email-masked]
Date: Fri, 19 Oct 2001 15:24:43 -0700
From: RFC Editor <[email-masked]>
Sender: [email-masked]

--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:    [email-masked], [email-masked],
                    [email-masked],
                    [email-masked] 
        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 [email-masked].  Requests to be
added to or deleted from the RFC-DIST distribution list should
be sent to [email-masked].

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

        To: [email-masked]
        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 [email-masked].  Unless
specifically noted otherwise on the RFC itself, all RFCs are for
unlimited distribution.echo 
Submissions for Requests for Comments should be sent to
[email-masked].  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="[email-masked]"

Content-Type: text/plain
Content-ID: <[email-masked]>

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: <[email-masked]>

--OtherAccess--
--NextPart--

From: Sharon Boeyen <[email-masked]>
To: Santosh Chokhani <[email-masked]>, "Housley, Russ" <[email-masked]>
Cc: [email-masked]
Subject: RE: AW: I-D ACTION:draft-ietf-pkix-new-part1-09.txt
Date: Fri, 19 Oct 2001 16:18:31 -0400
Sender: [email-masked]

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:[email-masked]]
Sent: Friday, October 19, 2001 11:25 AM
To: Housley, Russ; Santosh Chokhani
Cc: [email-masked]
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:[email-masked]
<mailto:[email-masked]> ] 
Sent: Friday, October 19, 2001 10:28 AM 
To: Santosh Chokhani 
Cc: [email-masked] 
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:[email-masked]]<BR><B>Sent:</B> Friday, October 
19, 2001 11:25 AM<BR><B>To:</B> Housley, Russ; Santosh Chokhani<BR><B>Cc:</B> 
[email-masked]<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:[email-masked]">mailto:[email-masked]</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: 
  [email-masked]</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--

From: Santosh Chokhani <[email-masked]>
To: "Housley, Russ" <[email-masked]>, Santosh Chokhani <[email-masked]>
Cc: [email-masked]
Subject: RE: AW: I-D ACTION:draft-ietf-pkix-new-part1-09.txt
Date: Fri, 19 Oct 2001 11:25:08 -0400
Sender: [email-masked]

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:[email-masked]]
Sent: Friday, October 19, 2001 10:28 AM
To: Santosh Chokhani
Cc: [email-masked]
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:[email-masked]">mailto:[email-masked]=
</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: [email-masked]</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--

From: "Housley, Russ" <[email-masked]>
To: Santosh Chokhani <[email-masked]>
Cc: [email-masked]
Date: Fri, 19 Oct 2001 10:27:31 -0400
Subject: RE: AW: I-D ACTION:draft-ietf-pkix-new-part1-09.txt
Sender: [email-masked]

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

From: Santosh Chokhani <[email-masked]>
To: "Housley, Russ" <[email-masked]>, Santosh Chokhani <[email-masked]>
Cc: [email-masked]
Subject: RE: AW: I-D ACTION:draft-ietf-pkix-new-part1-09.txt
Date: Fri, 19 Oct 2001 10:16:09 -0400
Sender: [email-masked]

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:[email-masked]]
Sent: Thursday, October 18, 2001 3:36 PM
To: Santosh Chokhani
Cc: [email-masked]
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:[email-masked]]
>Sent: Thursday, October 18, 2001 11:52 AM
>To: Santosh Chokhani
>Cc: [email-masked]
>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:[email-masked]">mailto:[email-masked]=
</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: [email-masked]</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:[email-masked]">mailto:[email-masked]=
</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: [email-masked]</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--

From: "Housley, Russ" <[email-masked]>
To: Fantou Patrick <[email-masked]>
Cc: [email-masked]
Date: Fri, 19 Oct 2001 09:15:50 -0400
Subject: Re: AW: AW: pseudonym : small typo
Sender: [email-masked]

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

From: "Housley, Russ" <[email-masked]>
To: Fantou Patrick <[email-masked]>
Cc: [email-masked]
Date: Fri, 19 Oct 2001 09:13:41 -0400
Subject: Re: AW: AW: I-D ACTION:draft-ietf-pkix-new-part1-09.txt
Sender: [email-masked]

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

From: "Housley, Russ" <[email-masked]>
To: Fantou Patrick <[email-masked]>
Cc: [email-masked]
Date: Fri, 19 Oct 2001 09:11:55 -0400
Subject: Re: AW: AW: I-D ACTION:draft-ietf-pkix-new-part1-09.txt
Sender: [email-masked]

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.

To: IETF-Announce: ;
Cc: [email-masked]
From: [email-masked]
Reply-to: [email-masked]
Subject: I-D ACTION:draft-ietf-pkix-new-part1-10.txt
Date: Fri, 19 Oct 2001 07:10:16 -0400
Sender: [email-masked]

--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 [email-masked] 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:
	[email-masked].
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="[email-masked]"

Content-Type: text/plain
Content-ID:	<[email-masked]>

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:	<[email-masked]>

--OtherAccess--

--NextPart--

From: Fantou Patrick <[email-masked]>
To: "'Housley, Russ'" <[email-masked]>, Fantou Patrick <[email-masked]>
Cc: [email-masked]
Subject: AW: AW: pseudonym : small typo
Date: Fri, 19 Oct 2001 09:32:10 +0200
Sender: [email-masked]

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:[email-masked]]
> Gesendet: Dienstag, 16. Oktober 2001 21:31
> An: Fantou Patrick
> Cc: [email-masked]
> 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
> 

From: Fantou Patrick <[email-masked]>
To: "'Santosh Chokhani'" <[email-masked]>, "Housley, Russ" <[email-masked]>, Fantou Patrick <[email-masked]>
Cc: [email-masked]
Subject: AW: AW: I-D ACTION:draft-ietf-pkix-new-part1-09.txt
Date: Fri, 19 Oct 2001 09:11:33 +0200
Sender: [email-masked]

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:[email-masked]]
Gesendet: Donnerstag, 18. Oktober 2001 17:01
An: Housley, Russ; Fantou Patrick
Cc: [email-masked]
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:[email-masked]]<BR><B>Gesendet:</B> Donnerstag, 18. =
Oktober=20
  2001 17:01<BR><B>An:</B> Housley, Russ; Fantou Patrick<BR><B>Cc:</B>=20
  [email-masked]<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--

From: Fantou Patrick <[email-masked]>
To: "'Housley, Russ'" <[email-masked]>, Fantou Patrick <[email-masked]>
Cc: [email-masked]
Subject: AW: AW: I-D ACTION:draft-ietf-pkix-new-part1-09.txt
Date: Fri, 19 Oct 2001 09:02:50 +0200
Sender: [email-masked]

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:[email-masked]]
> Gesendet: Donnerstag, 18. Oktober 2001 15:56
> An: Fantou Patrick
> Cc: [email-masked]
> 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
> 

Subject: Re: I-D ACTION:draft-ietf-pkix-ipki-pkalgs-04.txt
From: "[email-masked]" <[email-masked]>
Date: Thu, 18 Oct 2001 20:41:56 -0400
To: "[email-masked]" <[email-masked]>
Reply-To: [email-masked]
Sender: [email-masked]

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"

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

Importance: Normal
Subject: RE: AW: I-D ACTION:draft-ietf-pkix-new-part1-09.txt
To: "Housley, Russ" <[email-masked]>
Cc: Santosh Chokhani <[email-masked]>, [email-masked]
From: "Tom Gindin" <[email-masked]>
Date: Thu, 18 Oct 2001 17:50:03 -0400
Sender: [email-masked]

     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" <[email-masked]>@mail.imc.org on 10/18/2001
03:36:19 PM

Sent by:  [email-masked]

To:   Santosh Chokhani <[email-masked]>
cc:   [email-masked]
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:[email-masked]]
>Sent: Thursday, October 18, 2001 11:52 AM
>To: Santosh Chokhani
>Cc: [email-masked]
>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

From: "Housley, Russ" <[email-masked]>
To: Hans Schupp <[email-masked]>
Cc: [email-masked], [email-masked], [email-masked], [email-masked]
Date: Thu, 18 Oct 2001 14:52:40 -0400
Subject: Re: I-D ACTION:draft-ietf-pkix-ipki-pkalgs-04.txt
Sender: [email-masked]

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

From: "Housley, Russ" <[email-masked]>
To: Santosh Chokhani <[email-masked]>
Cc: [email-masked]
Date: Thu, 18 Oct 2001 15:36:19 -0400
Subject: RE: AW: I-D ACTION:draft-ietf-pkix-new-part1-09.txt
Sender: [email-masked]

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:[email-masked]]
>Sent: Thursday, October 18, 2001 11:52 AM
>To: Santosh Chokhani
>Cc: [email-masked]
>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

From: Santosh Chokhani <[email-masked]>
To: "Housley, Russ" <[email-masked]>, Santosh Chokhani <[email-masked]>
Cc: [email-masked]
Subject: RE: AW: I-D ACTION:draft-ietf-pkix-new-part1-09.txt
Date: Thu, 18 Oct 2001 14:13:41 -0400
Sender: [email-masked]

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:[email-masked]]
Sent: Thursday, October 18, 2001 11:52 AM
To: Santosh Chokhani
Cc: [email-masked]
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:[email-masked]]<BR><B>Sent:</B> Thursday, October 18, 2001 
  11:52 AM<BR><B>To:</B> Santosh Chokhani<BR><B>Cc:</B> 
  [email-masked]<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--

Date: Thu, 18 Oct 2001 18:44:53 +0200
From: Hans Schupp <[email-masked]>
Organization: SECUDE GmbH
To: [email-masked], [email-masked], [email-masked]
Cc: [email-masked], [email-masked]
Subject: Re: I-D ACTION:draft-ietf-pkix-ipki-pkalgs-04.txt
Sender: [email-masked]

[email-masked] 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

From: "Housley, Russ" <[email-masked]>
To: Santosh Chokhani <[email-masked]>
Cc: [email-masked]
Date: Thu, 18 Oct 2001 11:52:02 -0400
Subject: RE: AW: I-D ACTION:draft-ietf-pkix-new-part1-09.txt
Sender: [email-masked]

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

From: Santosh Chokhani <[email-masked]>
To: "Housley, Russ" <[email-masked]>, Fantou Patrick <[email-masked]>
Cc: [email-masked]
Subject: RE: AW: I-D ACTION:draft-ietf-pkix-new-part1-09.txt
Date: Thu, 18 Oct 2001 11:01:06 -0400
Sender: [email-masked]

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:[email-masked]]
Sent: Thursday, October 18, 2001 9:56 AM
To: Fantou Patrick
Cc: [email-masked]
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:[email-masked]">mailto:[email-masked]=
</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: [email-masked]</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--

From: "Housley, Russ" <[email-masked]>
To: [email-masked]
Cc: [email-masked], [email-masked], [email-masked]
Date: Thu, 18 Oct 2001 10:15:48 -0400
Subject: Re: PKAlgs: 04: ASN.1 typos
Sender: [email-masked]

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

From: "Housley, Russ" <[email-masked]>
To: Fantou Patrick <[email-masked]>
Cc: [email-masked]
Date: Thu, 18 Oct 2001 09:56:08 -0400
Subject: Re: AW: I-D ACTION:draft-ietf-pkix-new-part1-09.txt
Sender: [email-masked]

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

To: IETF-Announce: ;
Subject: RFC 3161 on Time-Stamp Protocol (TSP)
Cc: [email-masked], [email-masked]
From: RFC Editor <[email-masked]>
Date: Wed, 17 Oct 2001 14:44:32 -0400
Sender: [email-masked]

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:    [email-masked], [email-masked],
                    [email-masked],
                    [email-masked] 
        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 [email-masked].  Requests to be
added to or deleted from the RFC-DIST distribution list should
be sent to [email-masked].

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

        To: [email-masked]
        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 [email-masked].  Unless
specifically noted otherwise on the RFC itself, all RFCs are for
unlimited distribution.echo 
Submissions for Requests for Comments should be sent to
[email-masked].  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="[email-masked]"

Content-Type: text/plain
Content-ID: <[email-masked]>

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: <[email-masked]>

--OtherAccess--
--NextPart--

From: "Housley, Russ" <[email-masked]>
To: Fantou Patrick <[email-masked]>
Cc: [email-masked]
Date: Tue, 16 Oct 2001 15:30:59 -0400
Subject: Re: AW: I-D ACTION:draft-ietf-pkix-new-part1-09.txt
Sender: [email-masked]

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

From: Fantou Patrick <[email-masked]>
To: [email-masked]
Cc: Fantou Patrick <[email-masked]>
Subject: AW: I-D ACTION:draft-ietf-pkix-new-part1-09.txt
Date: Tue, 16 Oct 2001 17:04:55 +0200
Sender: [email-masked]

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: [email-masked] [mailto:[email-masked]]
> Gesendet: Dienstag, 16. Oktober 2001 13:08
> Cc: [email-masked]
> 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 [email-masked] 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:
> 	[email-masked].
> 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.
> 

To: IETF-Announce: ;
Cc: [email-masked]
From: [email-masked]
Reply-to: [email-masked]
Subject: I-D ACTION:draft-ietf-pkix-new-part1-09.txt
Date: Tue, 16 Oct 2001 07:08:28 -0400
Sender: [email-masked]

--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 [email-masked] 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:
	[email-masked].
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="[email-masked]"

Content-Type: text/plain
Content-ID:	<[email-masked]>

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:	<[email-masked]>

--OtherAccess--

--NextPart--

To: IETF-Announce: ;
Cc: [email-masked]
From: [email-masked]
Reply-to: [email-masked]
Subject: I-D ACTION:draft-ietf-pkix-ipki-pkalgs-04.txt
Date: Tue, 16 Oct 2001 07:08:22 -0400
Sender: [email-masked]

--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:
	[email-masked].
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="[email-masked]"

Content-Type: text/plain
Content-ID:	<[email-masked]>

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:	<[email-masked]>

--OtherAccess--

--NextPart--

Date: Thu, 11 Oct 2001 22:46:13 +0200 (W. Europe Daylight Time)
From: Magnus Nystrom <[email-masked]>
Reply-To: =?iso-8859-1?Q?Magnus_Nystr=F6m?= <[email-masked]>
To: <[email-masked]>
Subject: Re: Polling in CMP
Sender: [email-masked]

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

Date: Wed, 10 Oct 2001 03:40:18 +1300 (NZDT)
From: [email-masked] (Peter Gutmann)
To: [email-masked], [email-masked]
Subject: Re: New test TSA available
Cc: [email-masked]
Sender: [email-masked]

Bernd Matthes <[email-masked]> 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.

Date: Tue, 09 Oct 2001 15:56:28 +0200
From: Bernd Matthes <[email-masked]>
To: Peter Gutmann <[email-masked]>
Cc: [email-masked]
Subject: Re: New test TSA available
Sender: [email-masked]

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:[email-masked]
------------------------------------------------------------
"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

--------------ms01470819F60469801D9F722B--

From: "Rachel" <[email-masked]>
To: <[email-masked]>
Subject: Key Recovery in PKIX CMP
Date: Sat, 6 Oct 2001 10:29:37 +0800
Sender: [email-masked]

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

Date: Wed, 3 Oct 2001 19:05:04 +1200 (NZST)
From: [email-masked] (Peter Gutmann)
To: [email-masked], [email-masked]
Subject: Re: New test TSA available
Cc: [email-masked]
Sender: [email-masked]

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

Date: Tue, 02 Oct 2001 19:21:34 +0200
From: Bernd Matthes <[email-masked]>
To: Peter Gutmann <[email-masked]>
Cc: [email-masked]
Subject: Re: New test TSA available
Sender: [email-masked]

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:[email-masked]
------------------------------------------------------------
"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

--------------msA8F728CBE5F315DD03FE3248--

To: [email-masked]
Cc: [email-masked]
Subject: question about the DN Qualifier
From: Takeshi AKUTSU <[email-masked]>
Date: Tue, 02 Oct 2001 23:23:07 +0900 (JST)
Lines: 37
Sender: [email-masked]

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  <[email-masked]> 
Hitachi,Ltd. Business & Information System Development Division
Electronic Commerce Department