Re: (ITS#6466) certificateListValidate rejects valid X.509 CRLs (but not RFC-compliant)

[hyc@symas.com]

erwann.abalea@keynectis.com wrote:
> Full_Name: Erwann Abalea
> Version: 2.4.17
> OS: Debian/testing
> URL: ftp://ftp.openldap.org/incoming/
> Submission from: (NULL) (217.167.155.1)
>
>
> As indicated in the subject, certificateListValidate() doesn't validate some
> valid CRLs. Those CRLs are valid from X.509 point of view, but do not conform to
> RFC5280 (which is only a profile of the standard).
>
> When no certificate is revoked, the revokedCertificate element SHOULD be
> omitted, instead of being included as an empty SEQUENCE OF SEQUENCE. RFC5280 has
> changed the SHOULD into a MUST, but I don't think this is checked by the
> function. I think it only skips over the next element (in my case, the
> crlExtensions).

Thanks for the report. The code in CVS HEAD has been patched to silently 
accept this case. However, it's worth pointing out that even in X.509(2005):

 >>>>
         If none of the certificates covered by this CRL have been revoked,
it is strongly recommended that
revokedCertificates parameter be omitted from the CRL, rather than being
included with an empty SEQUENCE.
<<<<

Also note that, technically, LDAP is defined to conform to the 1993 edition of 
the X.500 specs, and X.509(1993) makes no such allowance here.

We may consider logging a warning for this case. What software generated this 
CRL? It seems to be defective...

> Here's a real-life CRL:
> certificateRevocationList;binary:: MIIBPTCBpwIBATANBgkqhkiG9w0BAQUFADAkMQswCQY
>   DVQQGEwJGUjEVMBMGA1UEChMMR0lQLUNQUy1URVNUFw0wOTA5MTcxMDEyNTdaFw0xMDA2MjQxMDEy
>   NTdaMACgTTBLMB8GA1UdIwQYMBaAFOH6F/gUI8Xen3tJVqLlQphs5EovMAoGA1UdFAQDAgECMBwGA
>   1UdEgQVMBOBEWFjLWdpcEBnaXAtY3BzLmZyMA0GCSqGSIb3DQEBBQUAA4GBAByCwHi4fZG95ScpLO
>   2HW+5I1zeodXlbTOCgnbLVLLz0WjXXZpa5ecn2aHpqrc5L70UIKBhrk/LJ8+y03UBtx6z1gdGNL3u
>   +rbVQcMgbKJ5AbLojfyWeS4d6n8TZBlM0Wd5eJ6AlwPKRvNV//QH3vjMPVWeD2XYtwQhBYqEGJrvn
>
> And a real-life deltaCRL:
> deltaRevocationList;binary:: MIIBTjCBuAIBATANBgkqhkiG9w0BAQUFADAkMQswCQYDVQQGE
>   wJGUjEVMBMGA1UEChMMR0lQLUNQUy1URVNUFw0wODEyMjQwMzAwMjNaFw0wODEyMzAwMzAwMjNaMA
>   CgXjBcMB8GA1UdIwQYMBaAFOH6F/gUI8Xen3tJVqLlQphs5EovMAsGA1UdFAQEAgIKAjAOBgNVHRs
>   BAf8EBAICCgEwHAYDVR0SBBUwE4ERYWMtZ2lwQGdpcC1jcHMuZnIwDQYJKoZIhvcNAQEFBQADgYEA
>   gEk/dBR5Vz+RtfBp4hpPaSX1aXFAzx6pZCSBaQ4dFfbXV9HkbPM/2dh32HRDueyhJnXmfn/m5Q9Vo
>   syEzF1MQEDYZV0A5Liu8oiZtY9gfe522pz7+oehZdOyzkLx6nUw6uLLTL62q8lRbDsNbZNsu22sz7
>   dAucnBo63ksdGgdFQ=
>
> You'll see empty SEQUENCEs. Bug probably around line 314 of file schema_init.c,
> but I don't know openldap internals enough to correct it by myself.
>
> Thanks.

-- 
   -- Howard Chu
   CTO, Symas Corp.           http://www.symas.com
   Director, Highland Sun     http://highlandsun.com/hyc/
   Chief Architect, OpenLDAP  http://www.openldap.org/project/