ASN.1 questions

[Lon Willett]

Hi!

At 08:41 27/10/00, Torbjorn Tornkvist wrote:

>Hi !
>
>> Coming from the PKI world, I'll point out that the X.500/X.509 
>> does require a bit more in the way of DER encoding. 
>
>Regarding PKI, I'm a bit curious, does this also apply for LDAP ?
>
>I've just been reading RFC 2259 and 1778 and as I
>understand it the relevant LDAP attributes should be 
>encoded according to the 'Undefined' syntax (RFC 1778,
>chap.2.1), which states that it should be BER encoded.

This stuff shouldn't be relevant for LDAP.  DER (as opposed to BER) only comes into play when you need a canonical representation, e.g. in order to digitally sign some data, or to verify a digital signature.  It's been a while since I read the LDAP RFCs, but IIRC they just deal with straight BER.

The only catch is that the ASN.1 and X.500 directory stuff is really a mess in a few places, so its not always safe to completely decode and re-encode something.  What I mean is best illustrated by an example: supposing when you store a certificate, you choose to store it in a decoded form.  So the name "CN=Lon Willett,O=SSE,C=IE" from inside the cert is broken down and stored as some erlang term.  Then when you try to reconstruct the certificate, you'll have to decide how to encode the string "Lon Willett".  Unfortunately, you have a number of choices, although the only two good ones (for this example) would be as a PrintableString or a UTF8String.  If you pick the wrong one, then the certificate signature will be invalid.  Moral: one needs to be very careful in how signed pieces of data are handled.

This situation is aggravated somewhat by the requirement that when verifying a signature (e.g. on a certificate), one is not allowed to assume that it (i.e. the cert) is already DER encoded, and instead one is supposed to decode it and then re-encode it using DER, and then use the re-encoded version for the signature verification.

Since you are just writing an LDAP server, not a full X.500 directory (thank your lucky stars), you can probably get away with just dealing with certs and CRLs as binary values, which avoids all the encoding issues.

>> If I get the time to play with this, I'll be sure to check with 
>> you first, so we don't duplicate each others work.  But I probably 
>> won't have the time this month anyway.  )-:
>
>Just to avoid double work, I'm currently implementing 
>an Erlang LDAPv3 interface (GPL). It would be great to 
>get some input about specific LDAP requirements related 
>to PKI.

Urk.  There is a big can of worms here (certificate path construction and validation).  But fortunately for you, I think its all on the client side.  I don't think you need to do anything special to support X.509 PKI.  The only thing that I can think of that could be a problem, outside of the representation problem mentioned above, is that CRLs (certificate revocation lists) can get _very_ large, and you need to be prepared to handle attributes whose value is a CRL.

Cheers,

/Lon