RFC 4325

RFC 4325 ✨ Internet X.509 Public Key Infrastructure Authority Information Access Certificate Revocation List (CRL) Extension

Okay bestie, let's get into it 🦋 This is RFC 4325, published in December 2005 by Stefan Santesson (Microsoft) and Russell Housley (Vigil Security). It's a Standards Track doc from the Network Working Group, and it updates RFC 3280. The header doesn't list anything it obsoletes. It's all about adding an Authority Information Access extension to CRLs so you can find the certs you need to build the CRL issuer's path 🔥

---

Status of This Memo 📜

This document specifies an Internet standards track protocol for the Internet community, and it's asking for discussion and suggestions for improvements 💬 If you want to know where this protocol stands in standardization, check the current edition of the "Internet Official Protocol Standards" (STD 1) 🧐 Distribution of this memo is unlimited 🌈

Copyright Notice 🎀

Copyright (C) The Internet Society (2005).

Abstract 🌸

Okay so this document updates RFC 3280 by defining the Authority Information Access Certificate Revocation List (CRL) extension ✨ RFC 3280 already defines the Authority Information Access certificate extension with the same syntax. The CRL version gives you a way to discover and retrieve CRL issuer certificates, which is so useful 🙌

Table of Contents 🗂️

   1. Introduction ....................................................2
      1.1. Terminology ................................................3
   2. Authority Information Access CRL Extension ......................3
   3. Security Considerations .........................................5
   4. References ......................................................5
      4.1. Normative References .......................................5
      4.2. Informative References .....................................6

---

1. Introduction 🌸

Okay so RFC 3280 [PKIX1] covers validating certification paths 🛤️ One part of that is figuring out whether a certificate has been revoked, and one way to check is the Certificate Revocation List (CRL). CRL validation is also specified in RFC 3280, and it involves building a valid certification path for the CRL issuer. Building that path from the signer of the CRL up to a trust anchor is easy when the CRL issuer's cert is already in the path for the target cert. It gets messy in other situations 😭

There are a bunch of legit scenarios where the CRL issuer's cert isn't in the target's path, or isn't easy to find. That can happen with indirect CRLs, when the Certification Authority (CA) that issued the target cert changes its certificate signing key, or when the CA uses separate keys for signing certs and signing CRLs 🔑

Right now there are ways to find the CRL issuer's cert, like an accessible directory location, or the Subject Information Access extension in intermediate CA certs 🔍

Directory lookup needs a directory that exists, is accessible, and has all the necessary certs in it 📚 The Subject Information Access extension supports building the CRL issuer certification path top-down (from the trust anchor down to the CRL issuer). But it needs some certs in that CRL issuer path to include an appropriate Subject Information Access extension 💅

RFC 3280 [PKIX1] also supports bottom-up discovery of certification paths through the Authority Information Access extension. There, the id-ad-caIssuers access method can have one or more accessLocation fields pointing to CA certs linked to the cert that contains the extension ✨

This document lets the Authority Information Access extension show up in CRLs too 🦋 That way a CRL checking app can use the id-ad-caIssuers access method to find certs that might help build a valid CRL issuer certification path up to an appropriate trust anchor. Main character energy 👑

1.1. Terminology 💅

Okay, here's the vocab. The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119] 🫶

---

2. Authority Information Access CRL Extension 🔥

This section is all about using the Authority Information Access extension in a CRL 🧚 The syntax and semantics that RFC 3280 [PKIX1] defines for the certificate extensions are also used for the CRL extension, so nothing new to learn there 💖

This CRL extension MUST NOT be marked critical. 🙅‍♀️

This extension MUST be identified by the extension object identifier (OID) that RFC 3280 defines (1.3.6.1.5.5.7.1.1). The AuthorityInfoAccessSyntax MUST be used to form the extension value. For convenience, the ASN.1 [X.680] definition of the Authority Information Access extension is repeated below 🍓

      id-pe-authorityInfoAccess OBJECT IDENTIFIER  ::=  { id-pe 1 }

      AuthorityInfoAccessSyntax  ::=  SEQUENCE SIZE (1..MAX) OF
                               AccessDescription

      AccessDescription  ::=  SEQUENCE {
         accessMethod          OBJECT IDENTIFIER,
         accessLocation        GeneralName  }

      id-ad OBJECT IDENTIFIER  ::=  { id-pkix 48 }

      id-ad-caIssuers OBJECT IDENTIFIER  ::=  { id-ad 2 }

When this extension is present in a CRL, it MUST include at least one AccessDescription that specifies id-ad-caIssuers as the accessMethod 🎯 Access method types other than id-ad-caIssuers MUST NOT be included 🚫 At least one instance of AccessDescription SHOULD specify an accessLocation that is an HTTP [HTTP/1.1] or Lightweight Directory Access Protocol [LDAP] Uniform Resource Identifier [URI] 🌐

---

Part 1 of 2. Part 2 picks up with the file formats for HTTP and FTP, MIME types, directory and LDAP locations, and the rest of the RFC, so stay tuned 💜

Full Copyright Statement 💖

Okay bestie, the legal stuff 🙈 Copyright (C) The Internet Society (2005). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights 💅

This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Intellectual Property 🦋

Ngl, this part is about who owns what 👑 The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document, or the extent to which any license under such rights might or might not be available. It also does not represent that it has made any independent effort to identify any such rights. Info on the procedures for rights in RFC documents can be found in BCP 78 and BCP 79 🌸

Copies of IPR disclosures made to the IETF Secretariat, and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification, can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr ✨

The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Send that info to the IETF at ietf-ipr@ietf.org 📬🧚

Acknowledgement 🫶

Funding for the RFC Editor function is currently provided by the Internet Society 🌈💜