Elliot,
Am 15.01.20 um 14:24 schrieb Elliot Otchet:
> As always, feedback is greatly appreciated. If acceptable, what are the next
> steps to get this accepted?
I have a few more suggestions on top of the ones from Willy:
> @@ -15246,7 +15246,7 @@ ssl_c_err : integer
> to your SSL library's documentation to find the exhaustive list of error
> codes.
>
> -ssl_c_i_dn([<entry>[,<occ>]]) : string
> +ssl_c_i_dn([<entry>[,<occ>],<format>]) : string
I believe the formatting is incorrect here. It should read:
ssl_c_i_dn([<entry>[,<occ>[,<format>]]]) or
ssl_c_i_dn([<entry>],[<occ>],[<format>])
depending on how you consider those optional arguments to work. The
former would be more consistent with the previous formatting.
> When the incoming connection was made over an SSL/TLS transport layer,
> returns the full distinguished name of the issuer of the certificate
> presented by the client when no <entry> is specified, or the value of the
> @@ -15255,8 +15255,10 @@ ssl_c_i_dn([<entry>[,<occ>]]) : string
> the value of the nth given entry value from the beginning/end of the DN.
> For instance, "ssl_c_i_dn(OU,2)" the second organization unit, and
> "ssl_c_i_dn(CN)" retrieves the common name.
> + To obtain a DN formatted according to RFC 2253 for LDAP v3, specify
> + "ssl_c_i_dn(,0,rfc2253)" in the configuration.
I'd phrase this a bit more general:
The <format> parameter allows you to receive the DN suitable for
consumption by different protocols. Currently supported is rfc2253 for
LDAP v3.
If you'd like to modify the format only you can specify an empty string
and zero for the first two parameters. Example: ssl_c_i_dn(,0,rfc2253)
> -ssl_c_key_alg : string
> +ssl_c_key_alg : string]
There's a typo here.
> @@ -15271,7 +15273,7 @@ ssl_c_notbefore : string
> YYMMDDhhmmss[Z] when the incoming connection was made over an SSL/TLS
> transport layer.
>
> -ssl_c_s_dn([<entry>[,<occ>]]) : string
> +ssl_c_s_dn([<entry>[,<occ>],<format>]) : string
See above.
> @@ -15280,6 +15282,8 @@ ssl_c_s_dn([<entry>[,<occ>]]) : string
> the value of the nth given entry value from the beginning/end of the DN.
> For instance, "ssl_c_s_dn(OU,2)" the second organization unit, and
> "ssl_c_s_dn(CN)" retrieves the common name.
> + To obtain a DN formatted according to RFC 2253 for LDAP v3, specify
> + "ssl_c_s_dn(,0,rfc2253)" in the configuration.
I wonder if we should reference back to 'ssl_c_i_dn' to avoid explaining
the same stuff multiple times, possibly forgetting to update one of
those. It should go into a dedicated CLEANUP patch, though.
> @@ -15320,7 +15324,7 @@ ssl_f_der : binary
> incoming connection was made over an SSL/TLS transport layer. When used for
> an ACL, the value(s) to match against can be passed in hexadecimal form.
>
> -ssl_f_i_dn([<entry>[,<occ>]]) : string
> +ssl_f_i_dn([<entry>[,<occ>],<format>]) : string
Ditto.
> @@ -15329,6 +15333,8 @@ ssl_f_i_dn([<entry>[,<occ>]]) : string
> the value of the nth given entry value from the beginning/end of the DN.
> For instance, "ssl_f_i_dn(OU,2)" the second organization unit, and
> "ssl_f_i_dn(CN)" retrieves the common name.
> + To obtain a DN formatted according to RFC 2253 for LDAP v3, specify
> + "ssl_f_i_dn(,0,rfc2253)" in the configuration.
Ditto.
> ssl_f_key_alg : string
> Returns the name of the algorithm used to generate the key of the
> certificate
> @@ -15345,7 +15351,7 @@ ssl_f_notbefore : string
> YYMMDDhhmmss[Z] when the incoming connection was made over an SSL/TLS
> transport layer.
>
> -ssl_f_s_dn([<entry>[,<occ>]]) : string
> +ssl_f_s_dn([<entry>[,<occ>],<format>]) : string
Ditto.
> @@ -15354,6 +15360,8 @@ ssl_f_s_dn([<entry>[,<occ>]]) : string
> the value of the nth given entry value from the beginning/end of the DN.
> For instance, "ssl_f_s_dn(OU,2)" the second organization unit, and
> "ssl_f_s_dn(CN)" retrieves the common name.
> + To obtain a DN formatted according to RFC 2253 for LDAP v3, specify
> + "ssl_f_s_dn(,0,rfc2253)" in the configuration.
Ditto.
> @@ -11148,24 +11185,24 @@ static struct sample_fetch_kw_list
> sample_fetch_keywords = {ILH, {
> { "ssl_c_ca_err_depth", smp_fetch_ssl_c_ca_err_depth, 0,
> NULL, SMP_T_SINT, SMP_USE_L5CLI },
> { "ssl_c_der", smp_fetch_ssl_x_der, 0,
> NULL, SMP_T_BIN, SMP_USE_L5CLI },
> { "ssl_c_err", smp_fetch_ssl_c_err, 0,
> NULL, SMP_T_SINT, SMP_USE_L5CLI },
> - { "ssl_c_i_dn", smp_fetch_ssl_x_i_dn,
> ARG2(0,STR,SINT), NULL, SMP_T_STR, SMP_USE_L5CLI },
> + { "ssl_c_i_dn", smp_fetch_ssl_x_i_dn,
> ARG3(0,STR,SINT,STR),NULL, SMP_T_STR, SMP_USE_L5CLI },
> { "ssl_c_key_alg", smp_fetch_ssl_x_key_alg, 0,
> NULL, SMP_T_STR, SMP_USE_L5CLI },
> { "ssl_c_notafter", smp_fetch_ssl_x_notafter, 0,
> NULL, SMP_T_STR, SMP_USE_L5CLI },
> { "ssl_c_notbefore", smp_fetch_ssl_x_notbefore, 0,
> NULL, SMP_T_STR, SMP_USE_L5CLI },
> { "ssl_c_sig_alg", smp_fetch_ssl_x_sig_alg, 0,
> NULL, SMP_T_STR, SMP_USE_L5CLI },
> - { "ssl_c_s_dn", smp_fetch_ssl_x_s_dn,
> ARG2(0,STR,SINT), NULL, SMP_T_STR, SMP_USE_L5CLI },
> + { "ssl_c_s_dn", smp_fetch_ssl_x_s_dn,
> ARG3(0,STR,SINT,STR),NULL, SMP_T_STR, SMP_USE_L5CLI },
> { "ssl_c_serial", smp_fetch_ssl_x_serial, 0,
> NULL, SMP_T_BIN, SMP_USE_L5CLI },
> { "ssl_c_sha1", smp_fetch_ssl_x_sha1, 0,
> NULL, SMP_T_BIN, SMP_USE_L5CLI },
> { "ssl_c_used", smp_fetch_ssl_c_used, 0,
> NULL, SMP_T_BOOL, SMP_USE_L5CLI },
> { "ssl_c_verify", smp_fetch_ssl_c_verify, 0,
> NULL, SMP_T_SINT, SMP_USE_L5CLI },
> { "ssl_c_version", smp_fetch_ssl_x_version, 0,
> NULL, SMP_T_SINT, SMP_USE_L5CLI },
> { "ssl_f_der", smp_fetch_ssl_x_der, 0,
> NULL, SMP_T_BIN, SMP_USE_L5CLI },
> - { "ssl_f_i_dn", smp_fetch_ssl_x_i_dn,
> ARG2(0,STR,SINT), NULL, SMP_T_STR, SMP_USE_L5CLI },
> + { "ssl_f_i_dn", smp_fetch_ssl_x_i_dn,
> ARG3(0,STR,SINT,STR),NULL, SMP_T_STR, SMP_USE_L5CLI },
> { "ssl_f_key_alg", smp_fetch_ssl_x_key_alg, 0,
> NULL, SMP_T_STR, SMP_USE_L5CLI },
> { "ssl_f_notafter", smp_fetch_ssl_x_notafter, 0,
> NULL, SMP_T_STR, SMP_USE_L5CLI },
> { "ssl_f_notbefore", smp_fetch_ssl_x_notbefore, 0,
> NULL, SMP_T_STR, SMP_USE_L5CLI },
> { "ssl_f_sig_alg", smp_fetch_ssl_x_sig_alg, 0,
> NULL, SMP_T_STR, SMP_USE_L5CLI },
> - { "ssl_f_s_dn", smp_fetch_ssl_x_s_dn,
> ARG2(0,STR,SINT), NULL, SMP_T_STR, SMP_USE_L5CLI },
> + { "ssl_f_s_dn", smp_fetch_ssl_x_s_dn,
> ARG3(0,STR,SINT,STR),NULL, SMP_T_STR, SMP_USE_L5CLI },
> { "ssl_f_serial", smp_fetch_ssl_x_serial, 0,
> NULL, SMP_T_BIN, SMP_USE_L5CLI },
> { "ssl_f_sha1", smp_fetch_ssl_x_sha1, 0,
> NULL, SMP_T_BIN, SMP_USE_L5CLI },
> { "ssl_f_version", smp_fetch_ssl_x_version, 0,
> NULL, SMP_T_SINT, SMP_USE_L5CLI },
Please add a validation function for the "format" parameter to ensure
that the user either passes rfc2253 or nothing. It goes where the NULL
currently is. You can find an example in http_fetch.c
Best regards
Tim Düsterhus
