IETF-SSH archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Re: Certificate authentication



"Glen Matthews" <glen%montreal.hcl.com@localhost writes:

>sorry for the dumb question (if it is dumb) but I can't see any drafts
>dealing with certificate authentication in ssh. ssh.com seems to support
>this, and I see a patch for openssh by Roumen Petrov - but is there any
>position from the wg on this?

I looked at this a while back and the group consensus is that no two people
can agree on how to handle it :-).  I went through the list archives
collecting all the comments on this, it starts around July'01 with:

  For x.509 certificates using rsa keys, SSH Communications 3.0 appears to be
  using PKCS #1 with MD5.

That doesn't describe the format, merely what's inside the RSA bignum... and
the debate then fizzled out again.  There's another post from August '01:

  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.

but then later he says:

  So, we decided to change x.509v3 certificates to use pkcs7 signatures,
  because otherwise, there is no way to know what hashing algorithm was used.

  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.

which never appeard in the RFC.  There's a  followup in Jan'02 asking why it's
not present yet, and several other ones indicating that no two people can
agree on how to do this, including the [editorial comment deleted] suggestion
to use:

   The certificate formats based on ssh-rsa extend the public key
   format to include certificate data:

     string    "ssh-rsa-x509v3" / "ssh-rsa-spki" / "ssh-rsa-pgp"
     mpint     e
     mpint     n
     string    certificate

which practically guarantees that one or more implementations will use the e
and n from outside the cert (particularly ones only pretending to do X.509),
completely voiding the purpose of having the cert in the first place.  Even
ssh.com don't seem to know what to do:

  moreover, implementations supporting x509 (e.g. ssh.com) currently send

        string  "DER-encoded cert"

  without even sending the key type.

   Certificates and public keys are encoded as follows:

     string   certificate or public key format identifier
     byte[n]  key/certificate data

  so, i'm confused by the draft and the implementations.

Markus Friedl then comments that:

  This is obviously wrong,

Bill Sommerfeld finally sums it up with:

  i do not want to hold up the core drafts waiting for folks to figure out how
  to use x.509 with ssh.

and Damien Miller followed up with the observation that:

  The current spec is too vague to implement.

There were further comments more recently which indicated that interest in
doing X.509 with SSH was sufficiently low that no-one cared too much about
this issue anyway.

Peter.



Home | Main Index | Thread Index | Old Index