[Date Prev][Date Next] [Chronological] [Thread] [Top]

Re: Certificate list validation



Pierangelo Masarati wrote:
> I'm playing with certification authorities and so, and I came across
> certificate lists.  Currently, the certificate list syntax
> 1.3.6.1.4.1.1466.115.121.1.9 is validated by sequenceValidate, which
> simply checks if the value starts with a LBER_SEQUENCE tag.  After
> reading related RFCs and X.509 I understood that a certificate list is
> always supposed to be a complete structure, respectful of X.509 7.3.

Yes, I wouldn't add just dummy values.

> I stumbled on this problem because I have to implement an architecture
> based on strongAuthenticationUser and certificationAuthority (I know
> they're deprecated in favor of pkiUser and pkiCA, but this is not an
> option right now, unfortunately), 

Guess you're using a LDAP-enabled CA software which has things
hard-coded? Isn't that one of the problems which could be solved with
yet another overlay? ;-)

> where the latter requires
> authorityRevocationList and certificateRevocationList.

The CA MUST be capable of issuing CRLs. Otherwise your PKI isn't
complete anyway. The CRLs SHOULD be copied in the CA's entry if this
entry is used by any LDAP-/PKI-enabled software at all.

> When the lists are empty, common practice allowed to use an arbitrary
> dummy value, while OpenLDAP requires at least ":: MAAAAA==" (i.e.
> LBER_SEQUENCE in base64) to fool sequenceValidate().

I would not mess with any dummy values at all.

> - is my understanding of X.509 correct? (certificate lists need to be
> complete as per X.509 7.3, with no revokedCertificates)

IMO yes.

> - is there any other common practice to deal with empty
> authorityRevocationList/certificateRevocationList?

Not one I would trust. Note that some "PKI-enabled" software chokes on
invalid data and crashes. Well, some software also chokes on valid data.
Overall quality is rather poor. :-(

> - would a certificateListValidate() that complies with X.509 7.3 be
> helpful/welcome in 2.4?

Yes!

Ciao, Michael.