Comments on draft-ietf-secsh-x509-03

[Oskari Saarenmaa <oskari.saarenmaa%f-secure.com@localhost>]

Some comments on the new x509 draft based on off-list emails and
discussions at IETF-64 and Connectathon:

The reason for including OCSP responses in "x509v3-sign" was that the
peer might not have access to (or might not want to access) the OCSP or
CRL server if it is behind a firewall for example.  OCSP responses are
signed, so the peer can trust them, but we should add some text to
security considerations about this.  The signature format for
"x509v3-sign" needs to be specified in more detail, specifically the OID
is an US-ASCII text representation of the identifier, and the signature
is encoded as specified in RFC 3279.

"x509v3-sign-rsa-sha1" and "x509v3-sign-dss-sha1" formats could be
dropped, the only argument for defining them was that they are pretty
close to what many implementations did before any of the x509/ssh stuff
was documented.  But as they're just "pretty close to" existing
implementations, defining them with new names and slightly different
formats won't buy any interoperability and only adds redundancy.

There were also some concerns that we might not actually need three
different EKUs for SSH, and should define just one or two.  As I see it
there are three pretty distinctive ways to use certificates in SSH so
each of them could use their own EKU definition, but I have no strong
feelings about the issue.

Any comments/feedback are welcome.

Cheers,
Oskari