[ANN] autosign extension

[Lasse Kliemann]

* Message by -Lasse Kliemann- from Thu 2009-05-14:

> > > X.509 should be supported, yes. We would have to adopt the above
> > > scheme of fingerprint-username pairs to it, if accepted. I could make
> > > a proposal for it then.
> > 
> > Please go ahead... I have no big need for this extension myself, I just
> > figured it would be cool to have :-) So I don't think I will be driving
> > the development very actively, at best I'll be stearing it.
> 
> I have a concrete idea how to include X509 with OpenSSL. I have 
> to check out some things on the OpenSSL mailing list first. I'll 
> present it here shortly.

Here is a short proposal.

We add three fields to the changeset:

- The signer's distinguished name (DN) in clear text. This DN 
  should contain at least a common name and an email address, but 
  it may of course also contain other information, such as the 
  country code, etc.
- A hash of that DN in the sense of 'openssl x509 -subject_hash 
  -in cert.pem', where 'cert.pem' is the signer's certificate.
- The actual signature made with 'openssl dgst ...'.

Users (i.e., signers) put their certificates in a directory of 
the repository. Files in this directory are named following the 
usual scheme: subject hash (obtained via 'openssl x509 
-subject_hash -in cert.pem'), then a dot, and then a serial 
number to compensate for ambiguities.

Verification. We extract the signer's DN hash from the changeset.  
It should match some filename in the certificate directory in the  
repository (plus a serial number). For each matching certificate, 
we check whether
- the public key in this certificate can verify the signature on 
  the changeset,
- the subject DN of the certificate matches the signer's DN in 
  the changeset,
- and the certificate is trusted, i.e. signed by a trusted 
  authority.

In addition, it is checked whether the common name plus the email 
address in the signer's DN is exactly the 'user' field in the 
changeset. If we rely on this combination to form a unique ID, 
then we can go with the scheme of first checking all signatures 
and then relying on 'user' fields (as displayed by 'hg log') to 
be trustworthy.

If all three conditions listed above are fulfilled for at least 
one certificate, and the signer's DN matches the 'user' field as 
described in the previous paragraph, then the check for the 
changeset at hand is considered successful.

Users can specify which authorities to trust via '-CApath'.
This is a local issue; each user has its own set of trusted 
authorities, and these are not part of the repository.


I had sketched the basic idea of including the subject hash (i.e.  
a hash of the signer's DN) in the signed document on the OpenSSL 
mailing list. Since I had never seen or done something like this 
before, I wanted to make sure. There were only a few replies. The 
most interesting suggestion was to just use S/MIME.  However, it 
seems that S/MIME is unnecessarily restrictive: it appears to 
only allow verification against the *exact* certificate that made 
the signature; even a certificate corresponding to the same 
private key and with the same subject DN is not accepted. I do 
not see why we should not accept such a certificate - after all 
it establishes a connection between the signer's DN and the 
public key, and that's all we need.

Anyhow, let us first get the OpenPGP-based implementation 
complete and stable. I will code the missing parts soon. BTW, I 
finally found a way to get the per-uid trust in a parseable form.  
We can let users decide whether to use this, or whether to use a 
separate keyring which is then considered fully trusted.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 835 bytes
Desc: not available
Url : http://selenic.com/pipermail/mercurial/attachments/20090516/5d382161/attachment.pgp