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

From: [email-masked]
Date: Tue, 16 Oct 2001 07:08:28 -0400

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.

---

From: "Housley, Russ" <[email-masked]>
Date: Thu, 18 Oct 2001 09:56:08 -0400

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

---

From: Santosh Chokhani <[email-masked]>
Date: Thu, 18 Oct 2001 11:01:06 -0400

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

Russ

---

From: "Housley, Russ" <[email-masked]>
Date: Thu, 18 Oct 2001 11:52:02 -0400

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]>
Date: Thu, 18 Oct 2001 14:13:41 -0400

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.

Russ

---

From: "Housley, Russ" <[email-masked]>
Date: Thu, 18 Oct 2001 15:36:19 -0400

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.
>case, what comes back is obvious from the attribute that is 
>referenced.  You are correct that other forms of URI are not specified.
>
>>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: "Tom Gindin" <[email-masked]>
Date: Thu, 18 Oct 2001 17:50:03 -0400

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:

Russ

---

From: Santosh Chokhani <[email-masked]>
Date: Fri, 19 Oct 2001 10:16:09 -0400

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:

Russ

---

From: "Housley, Russ" <[email-masked]>
Date: Fri, 19 Oct 2001 10:27:31 -0400

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

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]>
Date: Fri, 19 Oct 2001 11:25:08 -0400

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

Russ

---

From: Sharon Boeyen <[email-masked]>
Date: Fri, 19 Oct 2001 16:18:31 -0400

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: 

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

Russ

---

From: Santosh Chokhani <[email-masked]>
Date: Sat, 20 Oct 2001 16:28:09 -0400

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

 
 
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: 

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

Russ

---

From: "Housley, Russ" <[email-masked]>
Date: Mon, 22 Oct 2001 09:19:56 -0400

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 i!
n !
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-----

Cc: [email-masked]

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

To: Santosh Chokhani

Cc: [email-masked]

more than one value.

approach?

Russ

---

From: Santosh Chokhani <[email-masked]>
Date: Mon, 22 Oct 2001 09:41:35 -0400

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

issued by a CA in ! the same realm.

 
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: 

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

To: Santosh Chokhani 

Cc: [email-masked] 

more than one value. 

approach? 

Russ

---

From: "Housley, Russ" <[email-masked]>
Date: Mon, 22 Oct 2001 11:06:44 -0400

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

To: Sharon Boeyen

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

Sharon:

Russ

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.

Cheers,

Sharon

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

Cc: [email-masked]

Russ:

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

To: Santosh Chokhani

Cc: [email-masked]

more than one value.

approach?

Russ

---

From: Santosh Chokhani <[email-masked]>
Date: Mon, 22 Oct 2001 11:13:23 -0400

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

Russ:

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

To: Sharon Boeyen 

Sharon:

Russ

Cheers, 

Sharon 

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

Cc: [email-masked] 

Russ: 

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

To: Santosh Chokhani 

Cc: [email-masked] 

more than one value. 

approach? 

Russ