[Modules] [monkeysphere] mod_gnutls/libmsv

[Daniel Kahn Gillmor]

On 05/05/2011 01:45 PM, Clint Adams wrote:
> 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?

Perhaps the primary User ID?  Or just the first user ID in the cert?
I'm not sure how you'd handle the case if only a fingerprint was
transmitted, though.

>> 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.

ok, if that's planned for future work then i guess it makes sense.  I'd
probably leave it static until the future work is done myself, but *shrug*

>> 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.

My concern is that it might not fail if a SAN is present but it is of a
known OID.

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

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

Here are two simple proposals for how a monkeysphere-specific X.509
HTTPS client-side cert could embed an OpenPGP User ID:

 0) Designate a new OID (using the monkeysphere PEN-prefixed OID space)
that means "OpenPGP User ID" as a UTF-8 string (or maybe such an OID
exists already?) have a Subject Alternative Name of one member: an
otherName identifier, with the OpenPGP User ID OID, and the content of
the full User ID string.

 1) Assuming that the User ID in question is a typical "Real Name
<email at example.net>", split it into two pieces (name and e-mail), and
use a subject DN of  "CN=Real Name/EMAIL=email at example.net".

 2) do both 0 and 1 in a belt-and-suspenders kind of approach.

 3) have a SAN of 1 member: an rfc822Name ("email at example.net"), and a
simple subject DN of "CN=Real Name"

X.509 is terribly flexible, so i'm sure there are many other possible
ways to do this, but it'd be nice to pick one way that we recommend.

Note that the above proposals assume that this is a self-generated X.509
certificate, where the cert-holder has full control over the
identifiable information.

For certificates issued by CAs, which may have other policies about what
identity information they're willing to certify, we may need other
accomodations.

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?
 It might be worth seeing how they populate this information.

> 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.

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.

	--dkg

[0]
http://www.gnu.org/software/gnutls/manual/html_node/X_002e509-certificate-functions.html#index-gnutls_005fx509_005fcrt_005fget_005fsubject_005falt_005fothername_005foid-549
[1] https://tools.ietf.org/html/rfc5280#page-38

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 1030 bytes
Desc: OpenPGP digital signature
Url : http://lists.outoforder.cc/pipermail/modules/attachments/20110505/e55607bf/attachment.bin