Unable to use CRL without "issuing distribution point"

[jasperpatterson]

I'm running into a problem getting my CRL to be recognized as authoritative for a certificate.

The certificate itself has a "distribution point" listed on it, however the given CRL does not use the "issuing distribution point" extension, which appears to be optional in RFC 5280. I couldn't find anything in the spec which specifically relates these two fields as a requirement to be present when the other is. As another data point, I do not run into this issue with PKIjs.

In practice, this affects people using AWS Private CA, a managed PKI offering which includes the issuance of X.509 certificates, and hosting of CRLs. The certificates issued by Private CA contain a "distribution point" while the CRLs do not implement the "issuing distribution point" extension.

To be clear, I'm hitting the return cert_dps.is_none() check in this code, returning false:

pub(crate) fn authoritative(&self, path: &PathNode<'_>) -> bool {
    // In all cases we require that the authoritative CRL have the same issuer
    // as the certificate. Recall we do not support indirect CRLs.
    if self.issuer() != path.cert.issuer() {
        return false;
    }

    let crl_idp = match (
        path.cert.crl_distribution_points(),
        self.issuing_distribution_point(),
    ) {
        // If the certificate has no CRL distribution points, and the CRL has no issuing distribution point,
        // then we can consider this CRL authoritative based on the issuer matching.
        (cert_dps, None) => return cert_dps.is_none(),

        // If the CRL has an issuing distribution point, parse it so we can consider its scope
        // and compare against the cert CRL distribution points, if present.
        (_, Some(crl_idp)) => {
            match IssuingDistributionPoint::from_der(untrusted::Input::from(crl_idp)) {
                Ok(crl_idp) => crl_idp,
                Err(_) => return false, // Note: shouldn't happen - we verify IDP at CRL-load.
            }
        }
    };

    crl_idp.authoritative_for(path)
}

[cpu]

Thanks for filing an issue. Have you spoken to Amazon about why their CRLs do not include an IDP extension? Is this something a user can configure, or a baked-in constraint of the product?

For broader context this was discussed fairly thoroughly in #121

[jasperpatterson]

I haven't yet reached out to AWS to ask about it. However I know it is not user-configurable, the CRL is fully managed.

[jasperpatterson]

I reached out to AWS about this and they provided the following response:

The only required CRL extensions are the Authority Key Identifier (AKI) and CRL number. The IDP extension is not required for non-partitioned CRLs. You mentioned associating certificates to a CRL. This is only required for partitioned CRLs. A non-partitioned CRL is authoritative for all certificates issued by a given CA. When ACM PCA service implement partitioned CRL support, internal team mentioned they will add the IDP extension to CRLs.

[cpu]

Thanks for passing on their reply. I'll have to find time to page back in more context here. I agree the IDP extension is not required per 5280, but when the end entity certificates have a CRL distribution point, wouldn't you want the CRL to have an IDP that identifies it as the same CRL mentioned in the cert CRL DP?

What is the proposed change in behaviour you want to see in webpki (keeping in mind the constraints discussed in #121)?

[jasperpatterson]

I'm not sure I fully understand the constraints from #121 but I suppose the proposal here would be treating the CRL authoritative based solely on the issuer, if the CRL is non-partitioned.

[cpu]

Relaxing the check so that a CRL without an IDP ext. is considered authoritative for a cert with a CRL DP ext. iff the CRL issuer matches the cert issuer might be reasonable, but I think we avoided that out of wariness of substitution attacks. Admitedly the specifics are out of my mental cache.

@jsha Tagging you here as well since you raised the initial concerns in #121 that resulted in the stricter matching logic. Any thoughts on this case? I'm having a hard time justifying our approach based on 5280 alone, but it also seems like relaxing our logic could be dangerous.