Subject: Re: [pkix] AuthKeyId and CrlEntryExtension.CertificateIssuer

From: Santosh Chokhani <[email-masked]>
Date: Wed, 15 Feb 2012 13:20:02 -0500

All,

IDP criticality must be enforced with the knowledge that the CRL may be incorrect one for the scope and//or may have partial information.

RFC 5280 does not say or imply that use any old CRL without processing or without applying critical IDP extension and assume that the information in the incorrect or incomplete CRL means revocation information has been obtained.

-----Original Message-----
From: Martin Rex [mailto:[email-masked]] 
Sent: Tuesday, February 14, 2012 7:11 PM
To: Erwann Abalea
Cc: [email-masked]; Santosh Chokhani; [email-masked]
Subject: Re: [pkix] AuthKeyId and CrlEntryExtension.CertificateIssuer

Erwann Abalea wrote:
> 
> "Martin Rex":
> >
> > Santosh Chokhani wrote:
> > >
> > > Originally, CRL DP was designed to partition the CRL.
> > > If CRL DP is not included in a certificate, that certificate 
> > > cannot go in a partition.
> > >
> > > When you ignore a critical IDP extension in CRL, you are insecure.
> 
> This point is important.
>
> If you ignore a *critical* extension, then you fail. Completely. 
> You're free to ignore any non critical extension (at least in X.509, 
> not RFC5280), but if you encounter a critical extension that you don't 
> understand, you MUST reject the object.

I would agree to criticality of X.509 certificate(!) extensions, but I believe that the expectations are unjusitified with respect to criticial CRL extensions (and entirely misled about criticial
CRLEntryExtensions)

The default configuration for CRL checking, similar to OCSP checking is to *not* hard-fail.  Sticking one's head in the sand about this is not going to change reality.

>From the definition of the IssuingDistributionPoint CRL Extension:

   http://tools.ietf.org/html/rfc5280#section-5.2.5

   5.2.5. Issuing Distribution Point

   The issuing distribution point is a critical CRL extension that
   identifies the CRL distribution point and scope for a particular CRL,
   and it indicates whether the CRL covers revocation for end entity
   certificates only, CA certificates only, attribute certificates only,
   or a limited set of reason codes.  Although the extension is
   critical, conforming implementations are not required to support this
   extension.  However, implementations that do not support this
   extension MUST either treat the status of any certificate not listed
   on this CRL as unknown or locate another CRL that does not contain
   any unrecognized critical extensions.

Scoping of the CRL by the Distribution Point, rather than by "entity certificates ony, CA certificates only, attributes certificates only  or a limited set of reason codes" goes beyond the specified design goals, so don't be surprised if it breaks.

The wording of the last sentences is particularly confusing:

                      However, implementations that do not support this
   extension MUST either treat the status of any certificate not listed
   on this CRL as unknown or locate another CRL that does not contain
   any unrecognized critical extensions.

"unknown" is not a status known to the CRL Validation algorithm in section 6.2.  And while our implementation (the software module above the
ASN.1 parser) does not "support this extension", the ASN.1 parser of our implementation *DOES* recognize it. 

> 
> > If someone fubars his PKI so badly, so that there is no CRL DP with 
> > full scope listed in his certs, or that the CRL returned from that 
> > URL is unusable for the promised purpose, then for our RP the 
> > customer will have to manually configure a download URL for that 
> > issuerName so that our CRL cache can populated/updated out-of-band 
> > with conforming CRLs ... or disable revocation checking for that 
> > issuerName.
> 
> Would you trust such a CA?

That question does not apply to us.

We do not ship a single CA as pretrusted with out implementation, our customers have to configure *each* CA that they want to trust explicitly.  And because of buggy PKI software and non-conforming CAs, there is a non-marginal amount of non-conformance that your PKI software has to tolerate.

Keep in mind that rfc5280 is VERY explicit about being liberal about conformance during certificate path validation:

   http://tools.ietf.org/html/rfc5280#page-72

   Therefore, the algorithm only includes checks to verify that the
   certification path is valid according to X.509 and does not include
   checks to verify that the certificates and CRLs conform to this
   profile.  While the algorithm could be extended to include checks for
   conformance to the profiles in Sections 4 and 5, this profile
   RECOMMENDS against including such checks.

So rfc5280 explicitly RECOMMENDS against including conformance checks from Section 5 of rfc5280, and that includes 5.2.5 Issuing Distribution Point above!

So one may claim conformance to PKIX rfc5280 in spite of ignoring conformance checks from Sections 4 & 5 of rfc5280.  That is what it says. 

-Martin