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

From: "Stefan Santesson" <[email-masked]>
Date: Mon, 12 Sep 2005 22:59:46 +0100

When the CRL is signed by a CRL issuer that does not use the same
private signing key to sign certificates.

Stefan Santesson
Program Manager, Standards Liaison
Windows Security

> -----Original Message-----
> From: [email-masked]
[mailto:[email-masked]]
> On Behalf Of Denis Pinkas
> Sent: den 12 september 2005 13:03
> To: [email-masked]
> Cc: PKIX; Sam Hartman
> Subject: Re: IESG last call changes to the CRL AIA draft
> 
> 
> 
> 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
> >
> >
> >
> >
> >
>