Subject: RE: draft-ietf-pkix-rfc3280bis-04.txt

From: "Carl Wallace" <[email-masked]>
Date: Wed, 12 Jul 2006 06:06:12 -0700

> Secondly, you forgot to mention the use of 
> AuthorityKeyIdentifier which according to 3280 is " a means 
> of identifying the public key corresponding to the private 
> key used to sign a certificate." So this precisely gives us 
> the pointer we need to point to the PKC of the issuer of the 
> AC in which this extension occurs. 

Identifying a public key is not the same as pointing to a PKC.  The AKID
extension will not do what you seem to want.  It is easy enough to use
id-caIssuers to point to a PKC used to verify an attribute certificate
signature and to define a new access method to point to an attribute
certificate that precedes the attribute certificate containing the
extension in a PMI chain.  Further overloading id-caIssuers, which can
already point to a PKCS7 blob or a cert, to point to attribute
certificates is a bad idea, in my opinion.

> This is in line with its 
> current use in PKCs. Thus we do not need the AIA to point to 
> the PKC of the issuer.
> 
> The second point means that we only need to use the AIA to 
> point to the AC of the issuer. And caissuers can be used for 
> this unambiguously if we edit the first sentence of its 
> description in 3280-bis. The current wording does in my 
> opinion rule out its use in CRLs. So it would be advantageous 
> to change the wording,regardless of the AC debate.

The wording appears in a section that describes public key certificate
extensions.  Language specific to PKCs in that section does not preclude
language elsewhere that describes how the extension can be used in
different types of objects, such as CRLs or attribute certificates.
Ideally, other usage should be consistent with the RFC3280 usage, i.e.,
the extension should be used to point to certs or P7 blobs.

---

From: David Chadwick <[email-masked]>
Date: Fri, 14 Jul 2006 15:53:11 +0100

Carl Wallace wrote:

> extension will not do what you seem to want. 

Carl

since the syntax of AKID and AIA are both GeneralNames, then it seems 
obvious to me that a url can be used in both to point to the location 
where the issuer's cert can be found, as the text in AIA describes. (In 
fact AIA caIssuers is not really needed is it?)

> It is easy enough to use
> extension in a PMI chain. 

Sure, this is an alternative way of doing it. We can do this if 
concensus is that this is the best way

  Further overloading id-caIssuers, which can
> certificates is a bad idea, in my opinion.

It all depends upon the semantics of caIssuers. Can it only point to the 
CA issuer or can it point to the issuer (as is used in CRLs). This is 
the point that I am trying to clarify

thanks

David

*****************************************************************
David W. Chadwick, BSc PhD
Professor of Information Systems Security
The Computing Laboratory, University of Kent, Canterbury, CT2 7NF
Tel: +44 1227 82 3221
Fax +44 1227 762 811
Mobile: +44 77 96 44 7184
Email: [email-masked]
Home Page: http://www.cs.kent.ac.uk/people/staff/dwc8/index.html
Research Web site: http://sec.cs.kent.ac.uk
Entrust key validation string: MLJ9-DU5T-HV8J
PGP Key ID is 0xBC238DE5

*****************************************************************

---

From: David Chadwick <[email-masked]>
Date: Fri, 14 Jul 2006 15:48:35 +0100

Carl Wallace wrote:

> extensions.  

Carl

the wording appears in the very first section where caIssuers is 
described. Therefore since this is the first (and only) description of 
caIssuers it is natural to assume that this is the definitive definition 
of caIssuers. And my reading of it rules out the use of caIssuers for 
anything other than CAs. A very tiny wording change removes this 
exclusive use of caIssuers. Specifically, the current 3280 sentence says

    The id-ad-caIssuers OID is used when the additional information lists
    certificates that were issued to the CA that issued the certificate
    containing this extension.

this implies that it can only be used to point to a CA.

Replacing it with

    When the id-ad-caIssuers OID is used [in a public key certificate] 
            the additional information lists
    certificates that were issued to the CA that issued the certificate
    containing this extension.

implies it can be used elsewhere as well as in PKCs. The text in [] is 
optional. You may not think it is necessary as it is implied by context. 
The revised sentence opens the door for it to be used to point to other 
things than CAs

regards

David

--

---

From: "David A. Cooper" <[email-masked]>
Date: Fri, 14 Jul 2006 11:31:30 -0400

David,

The AKI extension cannot be used as a pointer to the certificate needed 
to verify the signature on the certificate containing the extension.  
This is the reason that we need the id-ad-caIssuers access method of the 
AIA extension in addition to the AKI extension in both public key 
certificates and CRLs even though the AKI extension is also defined for 
inclusion in these as well.

The problem with using the AKI extension is that the GeneralNames field 
in AKI is not defined as a pointer to the certificate of interest.  The 
authorityCertIssuer field is used in combination with the 
authorityCertSerialNumber field to identify a certificate by issuer name 
and serial number.  Thus, the authorityCertIssuer field specifies the 
name(s) of the issuer of the certificate whose subject public key can be 
used to verify the signature on the object (e.g., certificate or CRL) 
that contains the AKI extension.  So, I don't see how the 
authorityCertIssuer field could point to the certificate of interest 
when the field is the identifier of a certificate issuer, an issuer that 
has most likely issued more than one certificate.

I believe that the correct solution is to specify the use of the AIA 
extension in an attribute certificate.  Since the PKIX profile for 
attribute certificates (RFC 3281) does not support delegation, I do not 
see the PKIX WG specifying an access method for pointing to other 
attribute certificates, but I think it would be appropriate for PKIX to 
specify an access method for inclusion in an attribute certificate that 
points to the public key certificate(s) that can be used to verify the 
signature on the attribute certificate.  Of course, any such work should 
be written as a separate I-D that updates RFC 3281 rather than being 
done as part of any current I-D.

Since an AIA access method that points to the public key certificate(s) 
needed to verify the signature on an attribute certificate that includes 
the extension seems consistent with the use of the id-ad-caIssuers 
access method in public key certificates and CRLs, I think it would be 
acceptable to use the id-ad-caIssuers OID for this purpose in attribute 
certificates as well, but one could just as easily define a new OID.

If the id-ad-caIssuers access method is to be used, then I think that 
PKIX should specify its use since PKIX "owns" the OID.  In order to help 
things progress in this area, I put together a very short I-D that that 
specifies the use of the id-ad-caIssuers access point to point to the 
public key certificate(s) whose subject public key(s) can be used to 
verify the signature on the attribute certificate that includes the 
extension.  I simply took RFC 4325 (Internet X.509 Public Key 
Infrastructure Authority Information Access Certificate Revocation List 
(CRL) Extension) and replaced "CRL" with "attribute certificate".  It 
would, of course, be very easy to change the draft to specify a 
different OID for the access method. If anyone is interested in seeing 
this, I can send a copy.

Dave

David Chadwick wrote:
> where the issuer's cert can be found, as the text in AIA describes. 
> (In fact AIA caIssuers is not really needed is it?)
>
>> It is easy enough to use
> It all depends upon the semantics of caIssuers. Can it only point to 
> the CA issuer or can it point to the issuer (as is used in CRLs). This 
> is the point that I am trying to clarify
>
>
> thanks
>
> David

---

From: David Chadwick <[email-masked]>
Date: Sun, 16 Jul 2006 23:39:03 +0100

Hi David

lets be clear about this. When LDAP is being used, AKI is actually much 
better than AIA for finding the certificate of the issuer that is needed 
to verify the signature. This is because AIA is only a general name 
(LDAP URL), whereas AKI is a general name plus a serial number. If you 
read the current 3280 and 4325 specs you will see they are difficient 
because they only pick up the attribute type and not the actual 
attribute value.

So if the general name is a url and points to the LDAP entry of the 
issuer e.g.

http://ldap.myorg.com/cn=some issuer, o=myorg, c=gb?<attribute type here>

then the serial number says which public key cert is needed from all the 
ones that are in the attribute type in the LDAP entry.

This is perfectly in line with the standard.  So how do you propose to 
point to the exact public key certificate using caIssuers? It seems to 
me that AIA and caIssuers is currenly deficient.

By the way, I do appreciate you writing the new ID for the use of 
caIssuers in ACs, and we can use this as a fallback if needs be, if AKI 
is technically deemed to be unusable

regards

David

--