Re: x509

[nisse%lysator.liu.se@localhost (Niels Möller)]

A few comments on some of the issues here.

> > > i don't see why we cannot use the current "ssh-rsa" encoding:
> > > transfer a x509 certificate in addition to "ssh-rsa" encoded
> > > signature?

I think it makes sense to keep the ssh-dsa and ssh-rsa encodings for
signatures. Certificate standards typically don't define formats for
detached signatures. Whether or not a new name is attached to the data
isn't terribly important, but I'd prefer *not* introducing new
redundant names.

> string "ssh-rsa-x509v3"
> mpint e
> mpint n
> string der_encoded_certificate
> 
> This scales nicely to the other certificate (SPKI, OpenPGP) methods. 

This has one big advantage: The ssh(d) program can verify the
signature, and delegate processing of the certificates to an external
program or library, which doesn't need to know the SSH protocol data
that was signed.

One potential disadvantage is that it might encourage implementations
to claim they understand x509, and silently ignore the certificate
data. In this situation, the right thing to do is to use only plain
"ssh-rsa".

The certificate blob is still slightly underdefined:

  string der_encoded_certificate

There may be more than one certificate, and there's more than one way
to represent a certificate chain (e.g. pure x.509 and SSL do it
differently). The spec should at least say explicitly what type of
ASN.1-object is expected inside the DER encoding.

(Personally, I dislike x.509, but these encoding issues are quite
similar for spki).

/Niels