> On Jul 31, 2017, at 12:08 PM, Claus Assmann <ca+postfix-us...@esmtp.org> 
> wrote:
> 
> On Mon, Jul 31, 2017, Viktor Dukhovni wrote:
> 
>> I don't know what milters expect to find in "{cert_issuer}" and
>> "{cert_subject}".  The CN or the full DN (and if so in what
>> encoding).  We provide CNs, but perhaps Sendmail provides
>> DNs?
> 
> It's in the fine documentation (op.*)
> 
>      ${cert_issuer}
>           The DN (distinguished name) of the CA
>           (certificate authority) that signed the presented
>           certificate (the cert issuer) (STARTTLS only).
> 
>      ${cert_subject}
>           The DN of the presented certificate (called the
>           cert subject) (STARTTLS only).
> ....
>   6.7.  Encoding of STARTTLS and AUTH related Macros
> 
>           Macros that contain STARTTLS and AUTH related
>      data which comes from outside sources, e.g., all
>      macros containing information from certificates, are
>      encoded to avoid problems with non-printable or
>      special characters.  The latter are '\', '<', '>',
>      '(', ')', '"', '+', and ' '.  All of these characters
>      are replaced by their value in hexadecimal with a
>      leading '+'.  For example:
> 
>          /C=US/ST=California/O=endmail.org/OU=private/CN=Darth Mail (Cert)/
>          Email=darth+c...@endmail.org
> 
>      is encoded as:
> 
>          /C=US/ST=California/O=endmail.org/OU=private/
>          CN=Darth+20Mail+20+28Cert+29/Email=darth+2bc...@endmail.org
> 
>      (line breaks have been inserted for readability).  The
>      macros which are subject to this encoding are
>      {cert_subject}, {cert_issuer}, {cn_subject},
>      {cn_issuer}, as well as {auth_authen} and
>      {auth_author}.

Thanks for that.  We should probably update Postfix to send {cn_subject}
and {cn_issuer} (xtext encoded) and perhaps also the DNs in {cert_subject}
and {cert_issuer}.

Mind you, the encoding I was asking about was not the "super-encoding"
with xtext as seen above, but rather which of the various forms of the
subject and issuer DNs are expected.  There's the ad-hoc lossy form in
the OpenSSL "oneline" form of the DN, then there's RFC 2253, and one
can also choose various multibyte encodings or UTF-8.  The relevant
manpage is X509_NAME_print_ex(3):

   NOTES
       The functions X509_NAME_oneline() and X509_NAME_print() are legacy
       functions which produce a non standard output form, they don't handle
       multi character fields and have various quirks and inconsistencies.
       Their use is strongly discouraged in new applications.


I prefer to go with X509_NAME_print_ex() and a flags setting of:

    (XN_FLAG_RFC2253 & ~ASN1_STRFLGS_ESC_MSB)

The xtext encoding is an added complication at the next layer up...

In any case, I think that we need to provide macros that are compatible
reasonably compatible with Sendmail, and so even if the RFC2253 form is
technically superior, we may need to go with one of the deprecated forms
for compatibility...

Any interest in introducing new macros if the current underlying DN
format (once xtext decoded) is one of the deprecated ones?

-- 
        Viktor.

Reply via email to