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.
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), where the latter requires authorityRevocationList and certificateRevocationList.
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'd like to know:
- is my understanding of X.509 correct? (certificate lists need to be complete as per X.509 7.3, with no revokedCertificates)
- is there any other common practice to deal with empty authorityRevocationList/certificateRevocationList?
- would a certificateListValidate() that complies with X.509 7.3 be helpful/welcome in 2.4?
p.
Ing. Pierangelo Masarati OpenLDAP Core Team
SysNet s.r.l. via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it --------------------------------------- Office: +39 02 23998309 Mobile: +39 333 4963172 Email: pierangelo.masarati@sys-net.it ---------------------------------------
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.
Michael Ströder wrote:
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!
The point is: I guess a CA should be allowed to publish no CRL (or no ARL) if that would be empty. That's why pkiCA allows certificateRevocationList, while certificationAuthority requires it. So the problem is that certificationAuthority was poorly designed (like lots of old standard schema, I believe). My current issue is that I need to use the old objectClasses, but I have no control on what the CA does, I only publish data received from someone else, and I'd like to have things as correct as possible.
Anyway, thanks. I'll probably propose a certificateListValidate() function ASAP. p.
Ing. Pierangelo Masarati OpenLDAP Core Team
SysNet s.r.l. via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it --------------------------------------- Office: +39 02 23998309 Mobile: +39 333 4963172 Email: pierangelo.masarati@sys-net.it ---------------------------------------
-
Michael Ströder -
Pierangelo Masarati