Subject: Use of authorityInfoAccess extension (id-ad-caIssuers accessMethod) in an attribute certificate

From: "David A. Cooper" <[email-masked]>
Date: Mon, 02 Oct 2006 12:10:10 -0400

All,

At the previous IETF meeting there was a question about the use of the
id-ad-caIssuers access method of the authorityInfoAccess extension in
attribute certificates.  After some discussion, it seemed to have been
generally agreed that it would be acceptable to use this access method
to aid relying parties in locating the public key certificate needed to
verify the signature on the attribute certificate.  In order to help
ensure that this access method is used in a consistent manner when
included in an attribute certificate, I wrote a very short Internet
Draft describing its use.  The Internet Draft is now available at
http://www.ietf.org/internet-drafts/draft-cooper-pkix-aiaac-00.txt.
The I-D is written as an update to RFC 3281 and it was created by
liberally copying from RFC 4325 (Internet X.509 Public Key
Infrastructure Authority Information Access Certificate Revocation List
(CRL) Extension).

You may notice that the description of the rules for HTTP URIs is the
same as in RFC 4325 and in the latest draft of 3280bis.  There is no
need to comment on that.  I intend to align the text in this document
to align with whatever is agreed to for the text in 3280bis.

Dave

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

Subject:

Re: draft-ietf-pkix-rfc3280bis-04.txt

Date:

Fri, 14 Jul 2006 11:31:30 -0400

From:

David A. Cooper <[email-masked]>

To:

David Chadwick <[email-masked]>

CC:

pkix <[email-masked]>

References:

<[email-masked]>
<[email-masked]>

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:
> Carl Wallace wrote:
>> Identifying a public key is not the same as pointing to a PKC. The AKID
>> 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
>> 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.
>
> 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
>> already point to a PKCS7 blob or a cert, to point to attribute
>> 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