Background
The crypto/x509 package contains a variety of types representing objects which make up the PKI ecosystem, such as certificates, OCSP requests and responses, and CRLs. Most of these types represent both the underlying ASN.1 structure (e.g. the Certificate type has a RawTBSCertificate field) and a collection of ergonomic helpers which abstract away ASN.1 details (e.g. the Certificate type has the DNSNames field, which corresponds with a subset of the contents of the SubjectAltNames extension).
The crypto/x509/pkix sub-package contains a collection of types which are much more closely tied to their raw ASN.1 definitions, without the addtional ergonomics provided by the crypto/x509 types. These types are very useful for directly (un)marshalling ASN.1 data.
Currently, CRLs exist in a sort of in-between state. The x509.RevocationList type has a Number field which abstracts away the underlying ASN.1 crlNumber extension. However, the actual list of entries inside an x509.RevocationList is a []pkix.RevokedCertificate. This means that we do not have a ReasonCode field to abstract away the underlying ASN.1 reasonCode extension.
Objective
Provide a way for the crypto/x509 package to expose the revocation reason for every entry in a CRL, without requiring the user to directly interface with ASN.1 extensions.
Proposal
Add a new type to the x509 package which represents a single CRL entry with extra ergonommics added on top:
// CRLEntry represents a single entry in a Certificate Revocation List.
type CRLEntry struct {
SerialNumber *big.Int
RevocationDate time.Time
RevocationReason int
ExtraExtensions []pkix.Extension
}
The RevocationReason field would take the same values as the crypto/ocsp.Response.RevocationReason field. It is unfortunate that the revocation reason constants are all defined in the crypto/ocsp package (e.g. ocsp.KeyCompromise) despite being originally defined in RFC 5280; perhaps moving those into the crypto/x509 package and giving them their own type would be part of this proposal as well.
Add a new field to x509.RevocationList which is a list of the above new type. Deprecate the old RevokedCertificates field.
type RevocationList struct {
...
// Entries is used to populate the revokedCertificates
// sequence in the CRL, or is populated from the revokedCertificates
// sequence when parsing a CRL. It is an error for both CRLEntries
// and RevokedCertificates to be non-nil when passed as a template
// to CreateRevocationList.
Entries []x509.CRLEntry
// RevokedCertificates is used to populate the revokedCertificates
// sequence in the CRL, if Entries is nil.
// DEPRECATED: use Entries instead.
RevokedCertificates []pkix.RevokedCertificate
...
}
Background
The crypto/x509 package contains a variety of types representing objects which make up the PKI ecosystem, such as certificates, OCSP requests and responses, and CRLs. Most of these types represent both the underlying ASN.1 structure (e.g. the Certificate type has a RawTBSCertificate field) and a collection of ergonomic helpers which abstract away ASN.1 details (e.g. the Certificate type has the DNSNames field, which corresponds with a subset of the contents of the SubjectAltNames extension).
The crypto/x509/pkix sub-package contains a collection of types which are much more closely tied to their raw ASN.1 definitions, without the addtional ergonomics provided by the crypto/x509 types. These types are very useful for directly (un)marshalling ASN.1 data.
Currently, CRLs exist in a sort of in-between state. The x509.RevocationList type has a Number field which abstracts away the underlying ASN.1 crlNumber extension. However, the actual list of entries inside an x509.RevocationList is a []pkix.RevokedCertificate. This means that we do not have a ReasonCode field to abstract away the underlying ASN.1 reasonCode extension.
Objective
Provide a way for the crypto/x509 package to expose the revocation reason for every entry in a CRL, without requiring the user to directly interface with ASN.1 extensions.
Proposal
Add a new type to the x509 package which represents a single CRL entry with extra ergonommics added on top:
The RevocationReason field would take the same values as the crypto/ocsp.Response.RevocationReason field. It is unfortunate that the revocation reason constants are all defined in the crypto/ocsp package (e.g. ocsp.KeyCompromise) despite being originally defined in RFC 5280; perhaps moving those into the crypto/x509 package and giving them their own type would be part of this proposal as well.
Add a new field to x509.RevocationList which is a list of the above new type. Deprecate the old RevokedCertificates field.