80 likes | 224 Vues
This report outlines five critical issues regarding Certificate Revocation List (CRL) Authority Information Access (AIA), along with proposed solutions for each. Key discussions include the necessity of issuer certifications by the CA, the interpretation of RFC 3280 concerning CRL path construction, clarifications on MIME encoding within protocol layers, and harmonization of access methods with RFC 3280bis. The report emphasizes the distinct roles of CRL AIA and SIA, alongside recommendations for technical specifications to enhance clarity and functionality.
E N D
AIA in CRLs Stefan Santesson – Microsoft Russ Housley – Vigil Security
AIA in CRL status report • 5 Issues recorded • Solution proposed for each
Issue #1 • Denis: CRL issuer certs MUST be issued by the certificate issueing CA • Respone: No - There is no such requirement and this document is not the place to handle any such requirement.
Issue #2 • Denis: Construction of a CRL path is not discussed in RFC 3280 • Response: Wrong. It is discussed in section "5.1.1.3 signatureValue” • Comment: It is obvious that a certification path of the CRL signer must be generated and validated as part of CRL verification
Issue #3 • Denis: Objections to introductory text which says that says that SIA and other solutions are "not generally applicable" • Response: The text is motivating the solution specifed in this document • Comment: SIA works in the situations that Denis advocates, but CRL AIA works in those situations and ones that SIA does not work, such as when Indirect CRLs are used
Issue #4 • Matt Cooper: Clarify that any MIME encoding of the type of file content is performed at the protocol layer and not embeded as part of the file content. • Response: Text proposed on the mail list: "When the HTTP scheme is specified, the URI MUST specify the location of a certificate containing file. The file MUST contain either a single binary DER encoded certificate (indicated by the .cer file extension) or one or more certificates encapsulated in a CMS certs-only (PKCS#7) message [ref] (indicated by the .p7c file extension).HTTP server implementations accessed via the URI SHOULD use the appropriate MIME [ref] content-type for the certificate containing file.Specifically, the HTTP server SHOULD use the content-type application/pkix-cert [ref] for a single DER encoded certificate and application/pkcs7-mime [ref] for CMS certs-only (PKCS#7). Consuming clients may use the MIME type and file extension as a hint to the file content, but should not depend solely on the presence of the correct MIME type or file extension in the server response."
Issue #5 • Harmonizing required and recommended supported access methods between this draft and RFC 3280bis. • directoryName allowed (may be used for DAP or LDAP) • uniformResourceIdentifier allowed (may be used for, LDAP, HTTP, and FTP) • When the id-ad-caIssuers accessMethod is used, at least one instance SHOULD specify an accessLocation that is an HTTP or LDAP URI • Crlaia-00: • All present accessLocation values MUST use the uniformResourceIdentifier [URI] form, and the values MUST use either the ldap scheme [LDAP] or the http scheme [HTTP/1.1]. • Resolution: Propose harmonizing with 3280bis. Confirm with the mail list.
Way Forward • Post issue 5 to the mail list • Post revised ID by end of March • Ready for WG Last call in April