Subject: Re: IESG last call changes to the CRL AIA draft

From: Denis Pinkas <[email-masked]>
Date: Mon, 12 Sep 2005 22:02:59 +0200

Maybe I missed something, but the question is: in which case the 
certificate located through
this extension, used to validate signatures on CRLs may not be a CA 
certificate ?

Denis

>During IESG last call on the CRL AIA draft, David Cooper submitted some
>editorial comments which has been corrected and included in a new draft
>03, submitted today.
>
>The changes are:
>
>1) Clarification that a certificate located through this extension, used
>to validate signatures on CRLs may not be a CA certificate and thus may
>be found in the userCertificate attribute. The old text in section 2
>was:
>
>     When the accessLocation is a directoryName, the information is to
>     be obtained by the application from whatever directory server is
>     locally configured.  The entry for the directoryName contains CA
>     certificates in the crossCertificatePair and/or cACertificate
>     attributes as specified in [RFC 2587].  The protocol that
>     application uses to access the directory (e.g., DAP or LDAP) is a
>     local matter.
>
>The new text reads:
>
>     When the accessLocation is a directoryName, the information is to
>     be obtained by the application from whatever directory server is
>     locally configured.  When one CA public key is used to validate
>     signatures on certificates and CRLs, the desired CA certificate is
>     stored in the crossCertificatePair and/or cACertificate attributes
>     as specified in [RFC 2587].  When different public keys are used to
>     validate signatures on certificates and CRLs, the desired
>     certificate is stored in the userCertificate attribute as specified
>     in [RFC 2587]. Thus, implementations that support the directoryName
>     form of accessLocation MUST be prepared to find the needed
>     certificate in any of these three attributes.  The protocol that an
>     application uses to access the directory (e.g., DAP or LDAP) is a
>     local matter.
>
>2) Removing the DER encoded requirement for CMS messages and instead use
>reliance on RFC 2797 to specify necessary coding conventions.
>
>3) Aligning the ldap examples so that all now includes the ";binary"
>option.
>
>The changes have been concluded and edited in cooperation with Russ,
>Sam, Steve and Tim.
>
>
>Stefan Santesson
>Program Manager, Standards Liaison
>Windows Security
> 
>
>
>  
>

---

From: "David A. Cooper" <[email-masked]>
Date: Mon, 12 Sep 2005 17:21:35 -0400

> this extension, used to validate signatures on CRLs may not be a CA 

Denis,

According to X.509, in order for a certificate to be stored in the 
cACertificate or crossCertificatePair attribute, the certificate "shall 
include a basicConstraints extension with the cA value set to TRUE."  
The cA value of the basicConstraints extension "indicates if the 
certified public key may be used to verify certificate signatures."  So, 
if subject public key in the certificate pointed to by the AIA extension 
in the CRL is used to verify signatures on CRLs but not signatures on 
certificates, then the certificate would not include a basicConstraints 
extension with the cA value set to TRUE and so the certificate could not 
be stored in the cACertificate or crossCertificatePair attribute.  The 
only other attribute that is defined for holding public key certificates 
is the userCertificate attribute.

Dave

---

From: Tom Gindin <[email-masked]>
Date: Thu, 15 Sep 2005 08:14:23 -0400

David:

        RFC 3280 section 4.2.1.10 says that CRL Signing certificates MAY 
contain basicConstraints.  There is some tension between X.509 and RFC 
3280 on this point.  Of course, any CRL Signing certificate which doesn't 
contain basicConstraints does belong in userCertificate.

Tom Gindin

"David A. Cooper" <[email-masked]>
Sent by: [email-masked]
09/12/2005 05:21 PM
 
        To:     Denis Pinkas <[email-masked]>
        cc:     pkix <[email-masked]>, Sam Hartman 
<[email-masked]>
        Subject:        Re: IESG last call changes to the CRL AIA draft

Denis,

Dave