On Fri, Jun 19, 2015 at 11:32 AM, Jan Kaluža <jkal...@redhat.com> wrote: > On 06/18/2015 12:22 PM, Yann Ylavic wrote: >> >> On Thu, Jun 18, 2015 at 11:49 AM, Jan Pazdziora <jpazdzi...@redhat.com> >> wrote: >>> >>> >>> I'd appreciate any comments about suitability of such change, as well >>> as the implementation. Specifically, I'm not sure if people will >>> prefer the generic and currently proposed >>> >>> SSL_CLIENT_SAN_otherName_n >>> >>> which gets any value of otherName type, or perhaps going with >>> >>> SSL_CLIENT_SAN_UPN_n >>> >>> and checking the OID just for the UPNs. Based on that decision I plan >>> to then respin the patch with documentation changes included. >> >> >> I think a more generic way would to have something like >> SSL_CLIENT_OID_<oid>_n, so that we wouldn't have to add a new field >> each time. >> In this case, that would be: SSL_CLIENT_OID_1.3.6.1.4.1.311.20.2.3_n. > > > I think that's nice idea. I can probably work on that. The only question is > if we would like to have this generic way as additional feature, or we > really want to use it instead of the SSL_CLIENT_SAN_otherName_n as proposed > by Jan. > > I think that the common cases should have non-generic variable. The question > is if otherName is the common case.
Depends on whether one needs it or not I guess :) > > Ideas? Instead of SSL_CLIENT_OID_, we could also have something like SSL_CLIENT__<oid|shortname|fullname>__n since the underlying mod_ssl code handles both (IIRC). I don't know if SAN_otherName/UPN have a short/long name though, but many have.
