On 08 Feb 2015, at 10:23 AM, Kaspar Brand <[email protected]> wrote:
> It's probably a rarely used format, but if the CertificateExactAssertion
> thing is useful for LDAP querying, then fine with me. One caveat
> to keep in mind is that GSER (the "Generic String Encoding Rules",
> on which RFC 4523 relies) "do not define a canonical encoding",
> as stated in RFC 3641 section 5. The following strings for identifying
> the certificate from RFC 5280 appendix C.2 are equivalent according
> to RFC 4523 (and RFC 4514), e.g.:
>
> {serialNumber 18,issuer rdnSequence:"CN=Example CA,DC=example,DC=com"}
> { serialNumber 18, issuer
> rdnSequence:"CN=#130A4578616D706C65204341,DC=#16076578616D706C65,DC=#1603636F6D”
> }
I originally used the deprecated serial$issuer format, and then changed it - my
head was bleeding once I’d done it.
> Implementation-wise, there's some room for improvement:
>
> - "..._SNAI" sounds like fairly cryptic naming to me, I would prefer
> an explicit RFC reference, e.g. SSL_CLIENT_CERT_RFC4523_CEA (searching
> for "cea" in that RFC will quickly turn up its definition)
>
> - the syntax of the value isn't correct yet: your code does not add
> the "rdnSequence:" before the issuer DN, and it needs to be quoted,
>
> - instead of adding another BIO_* dance to ssl_engine_vars.c,
> relying on SSL_X509_NAME_to_string (and apr_pstrcat) allows saving
> quite some code
>
> - to also export the variable with "SSLOptions StdEnvVars", you need
> to add it to ssl_hook_Fixup_vars[] in ssl_engine_kernel.c, too
I have updated the patch accordingly. “SNAI” was “subject name and issuer” but
writing that out made a variable name that was too long.
> That's what I meant when suggesting something like SSL_CLIENT_CERT_DER
> in my last message in the "Re: [Patch] mod_ssl SSL_CLIENT_CERT_SUBJECTS -
> access to full client certificate chain" thread, yes. I would probably
> go for Base64 encoded DER values, to avoid '\0'-byte issues when
> shuffling things around (i.e., it would be "PEM without headers",
> so to say).
I’m keen on a mechanism that avoids a cycle of base64/unbase64, and I don’t
want any of the LDAP code to have any knowledge of PEM or base64. What I had in
mind was a generic mechanism that allowed binary data to be provided by any
module that wanted to provide data to any module that wanted to consume it, and
then teaching mod_ssl to provide it and mod_authnz_ldap to use it (and other
mod_auth* modules as needed).
Regards,
Graham
—
httpd-mod_ssl-rfc4523-cea.patch
Description: Binary data
