Re: x509

["Joseph Galbraith" <galb-list%vandyke.com@localhost>]

This is clearly still an open issue--

We discussed it on the list before the
August meeting, at the August meeting,
and it has been brought up at least
once recently.

Here is a email I sent right before the
August meeting with a proposed change:

> In the transport draft, Section 4.6, we specify that
> public keys are, in general encoded as:
>
>      string   certificate or public key format identifier
>      byte[n]  key/certificate data
>
> However, the sections on x.509 are less clear.  And in fact,
> SSH Communications current x.509 implementation omits the
> string, including only the certificate data -- although
> the string is included when sending signatures.
>
> I would suggest we include the following text in section
> documenting "x509v3-sign-rsa":
>
> The "x509v3-sign-rsa" key format has the following specific encoding:
>
>      string    "x509v3-sign-rsa"
>      byte[n]   x.509v3 compatible der encoded certificate data
>
> The resulting signature is encoded as follows:
>
>      string    "x509v3-sign-rsa"
>      string    rsa_signature_blob
>
>
> Variants to this go in the other x.509 sections as appropriate.
>
> In addition, I would suggest that we note that signatures
> made with x509v3-sign-rsa keys MUST use the SHA-1 hash, and
> be done using PKCS1.

During the August meeting, we decided that
we needed to use PKCS 7, because if a hardware
device was in play, it might not be possible
to control the hash algorithm it uses.

Here is an email I sent after the meeting
with this proposed change in it:

> --------- Transport draft, Section 4.6
>
> (We might want to number the different sections
> of this, so that ssh-dss becomes 4.6.1, ssh-rsa
> becomes 4.6.2, and x509v3-* becomes 4.6.3)
>
> 4.6.3 x.509v3 certificates
>
>   The "x509v3-*" methods indicate that the certificates, the
>   public key, and the resulting signature are in X.509v3 compatible
>   DER-encoded format.  The formats used in X.509v3 are described in
>   [RFC2459].  The formats used for signatures are described in
>   [PKCS7].
>
>   Note, that there is no such algorithm as "x509v3-*", but the
>   * is used only in this document to denote all algorithms
>   beginning with x509v3.
>
>   There are currently two such algorithms defined:
>     x509v3-sign-rsa      RECOMMENDED  sign    X.509 certificates (RSA key)
>     x509v3-sign-dss      RECOMMENDED  sign    X.509 certificates (DSS key)
>
>   The "x509v3-*" key format has the following generic encoding:
>
>     string    "x509v3-*"
>     string    x.509v3 compatible der encoded certificate data
>
>   The resulting signature is encoded as follows:
>
>     string    "pkcs7"
>     string    PKCS-7 signature, DER encoded
>
>   The "x509v3-sign-rsa" method indicates that the key
>   (or one of the keys in the certificate) is an RSA-key.
>
>   The "x509v3-sign-dss".  As above, but indicates that the key (or
>   one of the keys in the certificate) is a DSS-key.

Now -- on further reflection, I'm not sure.  Do hardware
devices like smartcards do a hashing operation, or are
they passed the hash to sign?

If they don't do the hashing operation, and we don't think
we need to provide that kind of flexibility, we can probably
get away without PKCS 7, and do something like what Markus is
proposing in this email:

> i don't see why we cannot use the current "ssh-rsa" encoding:
> transfer a x509 certificate in addition to "ssh-rsa" encoded
> signature?
>
> since "x509v3-sign-rsa" is not specified in detail, it should be
> dropped from the draft and replaced by something like
> "x509v5-ssh-rsa"
> meaning:
> public key is transfered in "x509v3" format and
> the current "ssh-rsa" is used for encoding for signatures.
>
> i think all the confusion is due to the fact that a single
> identifier is used for specifying to encoding of
> keys, certificates and signatures.
>
> i don't see why the current signature formats cannot
> be used together with x509 certificates.

- Joseph