On 19.06.2015 16:51, Jan Pazdziora wrote:
> On Thu, Jun 18, 2015 at 12:22:21PM +0200, Yann Ylavic wrote:
>> 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.
The point with the otherName SAN type is that it's yet another bag of
potentially arbitrary ASN.1 stuff, actually (not just simple strings, as
is the case for rfc822Name or dNSName):
GeneralName ::= CHOICE {
otherName [0] OtherName,
rfc822Name [1] IA5String,
dNSName [2] IA5String,
x400Address [3] ORAddress,
directoryName [4] Name,
ediPartyName [5] EDIPartyName,
uniformResourceIdentifier [6] IA5String,
iPAddress [7] OCTET STRING,
registeredID [8] OBJECT IDENTIFIER }
OtherName ::= SEQUENCE {
type-id OBJECT IDENTIFIER,
value [0] EXPLICIT ANY DEFINED BY type-id }
^^^^^^^^^^^^^^^^^^^^^^
(See RFC 7299 section 3.14 for the otherName forms defined by the PKIX
WG in the past.)
While Microsoft's UPN happens to be a very simple case (the value is
just a bare UTF8String here), this need not be true for other forms
of otherName.
Adding support for msUPN seems useful, but it's really something which
needs special-case coding in ssl_util_ssl.c:modssl_X509_getSAN(). I
suggest using SSL_{CLIENT,SERVER}_SAN_OTHER_msUPN_* for the variable
name(s), to make it clear that it's a subjectAltName entry of type
otherName. Then, in the code for GEN_OTHERNAME, specifically look for
this otherName form via "NID_ms_upn" - as only in this case, you
can be sure to expect a simple UTF8String in otherName->value
(strongSwan's openssl_x509.c might be a source of inspiration for coding
this).
Note that for exposing the msUPN variables with StdEnvVars, you also
need to adapt ssl_engine_vars.c:modssl_var_extract_san_entries().
Kaspar
