Re: [Modules] [monkeysphere] mod_gnutls/libmsv

[Clint Adams]

On Thu, May 05, 2011 at 03:32:34PM -0400, Daniel Kahn Gillmor wrote:
> Is it really forbidden?  I'm pretty sure i have X.509 certificates with
> an emailAddress in them.  For example, take a look at
> 
>   /etc/ssl/certs/spi-cacert-2008.pem

Perhaps not, but /usr/include/gnutls/x509.h contains

/* The following should not be included in DN.
 */
#define GNUTLS_OID_PKCS9_EMAIL  "1.2.840.113549.1.9.1"

> Have you looked at the structure and contents of an S/MIME e-mail
> signing X.509 certificate issued by one of the members of the CA cartel?

I have not.

> As i read the docs [0], this will only return otherName members of the
> subjectAltName field, so you won't get anything for, say, dNSName
> members of the subjectAltName [1].  And i don't see any guarantee that
> additional otherName designees will not get defined by future versions
> of gnutls; but maybe we should raise this question on the gnutls
> development list.

I'm not sure this is a problem; either the SAN holds a peername
which matches a OpenPGP uid associated with the pkcdata, or it
doesn't.  If the issue is X.509 certs generated by someone else,
then of course having GnuTLS, mod_gnutls, and Monkeysphere
all able to understand the same field would be helpful.
___
Modules mailing list
Modules@lists.outoforder.cc
http://lists.outoforder.cc/mailman/listinfo/modules

Re: [Modules] [monkeysphere] mod_gnutls/libmsv

[Clint Adams]

On Thu, May 05, 2011 at 12:32:49PM -0400, Daniel Kahn Gillmor wrote:
> from a monkeysphere perspective, it'd be nice to see libmsv in use for
> OpenPGP certificates as well as X.509 certificates.

In that case, what should be passed to MSVA as the peername?

> Is there a reason you have dynamically-allocated buf?  it would seem
> simpler to put it directly on the stack if you're going to keep it
> fixed-size anyway.

Ideally it should resize buf if
gnutls_x509_crt_get_subject_alt_othername_oid returns
GNUTLS_E_SHORT_MEMORY_BUFFER, unless you want an arbitrary
length limit on peername.

> your use of gnutls_x509_crt_get_subject_alt_othername_oid seems
> problematic to me, since the docs say:
> 
>This function is only useful if
>gnutls_x509_crt_get_subject_alt_name() returned
>GNUTLS_SAN_OTHERNAME.
> 
> but it doesn't look like you've tested for this condition.

Presumably gnutls_x509_crt_get_subject_alt_othername_oid() will
fail if no SAN is present, with or without the
gnutls_x509_crt_get_subject_alt_name() check.

> In general, i'm concerned about the use of this function, actually,
> since it implies that it might change its behavior based on the version
> of gnutls (depending on the known OIDs compiled into gnutls).
> 
> Are you expecting client certificates to supply some sort of
> monkeysphere-specific OID in SAN?  If so, what is that OID?  we have OID
> space allocated for the monkeysphere project -- i'd be happy to allocate
> an OID if there's a clear definition.

I'm not sure where the peername should go, since email appears
to be forbidden in the DN.

Since my version of gnutls will return GNUTLS_SAN_OTHERNAME
for any oid but GNUTLS_SAN_OTHERNAME_XMPP, I think both known
and unknown oids can be handled.
___
Modules mailing list
Modules@lists.outoforder.cc
http://lists.outoforder.cc/mailman/listinfo/modules