Subject: draft-igoe-secsh-x509v3-00

From: "Igoe, Kevin M." <[email-masked]>
Date: Wed, 18 Nov 2009 12:26:12 -0500

Colleagues:
 
  I'd like to call your attention to the following draft submission for
X.509 certificates in Secure Shell:
 
 http://www.ietf.org/id/draft-igoe-secsh-x509v3-00.txt

Your comments, suggestions and insights are appreciated!

---

From: Joseph Galbraith <[email-masked]>
Date: Wed, 18 Nov 2009 16:50:28 -0700

> Your comments, suggestions and insights are appreciated!

Thanks for picking this work up.  I'm definitely interested
in seeing this move forward, and I know I've had a number of
people express interest in this work as well.

I think this draft needs to spell out, explicitly, various formats.

For example,

 > The key format has the following specific encoding:
 >
 >      string    "x509v3-ssh-dss" / "x509v3-ssh-rsa" /
 >                "x509v3-ecdsa-sha2-*" / "x509v3-ecmqv-sha2"
 >      string    certificate-chain
 >
 > A certificate-chain is a DER-encoded ASN.1 SEQUENCE of certificates.

I suppose you might omit the second string and embed the ASN.1 sequence
directly, but usually SSH wraps that kind of data in a string.

Notice the algorithm name is encoded into the publickey.  This is
the way ssh-dss and ssh-rsa work, but not the way the (undocumented)
de-facto x509 implementation that is currently floating around works.
(And in case it isn't obvious, I think it should work like the existing
algorithms and encode the algorithm name in the publickey.)

It might be more SSH friendly to encode the chain using SSH rather
than ASN.1:

 > The "x509v3-ssh-dss" key format has the following specific encoding:
 >
 >      string    "x509v3-ssh-dss" / "x509v3-ssh-rsa" /
 >                "x509v3-ecdsa-sha2-*" / "x509v3-ecmqv-sha2"
 >      uint32    certificate-count
 >      string    certificate[1..certificate-count]

I'd also include an example, just because we've had a number of
implementation problems in this area (the string nesting can be a
little confusing.)

 >  byte      SSH_MSG_KEXDH_REPLY
 >  string    0x00 0x00 0xXX 0xXX
 >      0x00 0x00 0x00 0x0D "x509v3-ssh-dss"
 >      0x00 0x00 0x00 0x02
 >      0x00 0x00 0xXX 0xXX DER-encoded senders certificate
 >      0x00 0x00 0xXX 0xXX DER-encoded issuer certificate
 >  mpint     f
 >  string    signature of H

I think we also need to document signature algorithms.

 > Signing and verifying using the "x509v3-ssh-dss" key format
 > is done according to the Digital Signature Standard [FIPS-186-2]
 > using the SHA-1 hash [FIPS-180-2].
 >
 > The resulting signature is encoded as follows:
 >
 >      string    "ssh-dss"
 >      string    dss_signature_blob
 >
 > The value for 'dss_signature_blob' is encoded as a string containing
 > r, followed by s (which are 160-bit integers, without lengths or
 > padding, unsigned, and in network byte order).
 >
 > Signing and verifying using the "x509v3-ssh-rsa" key format
 > is performed according to the RSASSA-PKCS1-v1_5 scheme in
 > [RFC3447] using the SHA-1 hash.
 >
 > The resulting signature is encoded as follows:
 >
 >     string    "ssh-rsa"
 >     string    rsa_signature_blob
 >
 >  The value for 'rsa_signature_blob' is encoded as a string containing
 >  s (which is an integer, without lengths or padding, unsigned, and in
 >  network byte order).
 >
 >  These formats are that same as "ssh-rsa" and "ssh-dss", see RFC 4253,
 >  6.6. Public Key Algorithms

You'll probably also need details for "x509v3-ecdsa-sha2-*"
and "x509v3-ecmqv-sha2" signature encodings.

(And I assumed you wanted to use the existing encodings for signatures--
if not, you'll need to spell something different out.)

In addition, in your "IANA Considerations", you specified that there
were new entries in the key exchange algorithms, but I don't think
you actually introduced any new key exchange algorithms did you? These
are just new public key types that can be used in combination with any
of the existing key exchange algorithms.

Other miscellaneous thoughts:

o Do we want to require processing of (or give guidance with regards to)
   any extensions, such as BasicConstraints, KeyUsage, and
   SubjectAltName?

o Do we need language about respecting critical extensions or rejecting
   the certificate?

o Do we want to define any extended key usage key purpose ids?

o When we were working on x509v3 before, people seemed to want to
   include revocation data as well as chain data; I was never quite
   sure whether this was really needed or if it was gold plating, so
   to speak.

I'm more than happy to see any of these discarded as unneeded fluff...
to be honest, I know a lot about SSH, but not so much about x509, so
these thoughts mostly reflect feedback I was given when working on
the (now abandoned) x509v3 draft
  (http://tools.ietf.org/html/draft-ietf-secsh-x509-03)

o We should require the first certificate in a chain to use the correct
   type of key (i.e., it must have a rsa key if it is a
   "x509v3-ssh-rsa".)

Thanks,

Joseph

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Thu, 19 Nov 2009 10:18:11 -0500

> o Do we need language about respecting critical extensions or rejecting

We probably should require that KeyUsage include one or more of 
digitalSignature, keyEncipherment, and/or keyAgreement, depending on the 
requirements of the key exchange algorithm in use.

I don't think we need specific language detailing how to validate 
certificates, beyond "MUST comply with RFC5280".

> o Do we want to define any extended key usage key purpose ids?

IMHO we should, because defining an EKU key purpose ID is the only way to 
allow issuance of a certificate that can be used _only_ for SSH, and not 
for any other application.

>    sure whether this was really needed or if it was gold plating, so

For most protocols, including an OCSP response alongside a certificate is 
an optimization, because it allows the recipient to verify that the 
certificate is valid without independently contacting an OCSP server.  This 
is particularly interesting when the party that includes the OCSP response 
uses its certificate frequently in a short period of time, because it can 
cache and reuse the OCSP response for as long as it is valid, reducing load 
on OCSP servers.

For SSH, this capability might be valuable chiefly because it would permit 
clients to provide OCSP responses to SSH servers living in restricted 
networks or under other constraints which might prevent them from 
contacting the OCSP server directly.

>    type of key (i.e., it must have a rsa key if it is a

We could go a step further, and require that all certificates in the chain 
use key types corresponding to algorithms that were advertised by the side 
that will verify the certificate.  This would put SSH years ahead of 
virtually every other certificate-using protocol, in that we would actually 
have a means of negotiating which algorithms to use not only in end-entity 
certificates but in all certificates relied on for a particular session. 
On the other hand, it's not clear how much value that capability has in 
practice.

-- Jeff

---

From: Joseph Galbraith <[email-masked]>
Date: Thu, 19 Nov 2009 13:11:43 -0700

> requirements of the key exchange algorithm in use.

If I'm not mistaken, all current key exchange algorithms
(all derivatives of diffie hellman) only require digitalSignature,
since the hostkey isn't actually used during the key agreement
stage.  Does that sound correct?

(Though there may be future algorithms that require the
other usages.)

> IMHO we should, because defining an EKU key purpose ID is the only way 
> to allow issuance of a certificate that can be used _only_ for SSH, and 
> not for any other application.

In that case, the original (abandoned) x509v3 draft included
these:

        id-kp-ssh-server OBJECT IDENTIFIER
          ::= { 1.3.6.1.4.1.2213.15.1.1 }
        id-kp-ssh-client OBJECT IDENTIFIER
          ::= { 1.3.6.1.4.1.2213.15.1.2 }
        id-kp-ssh-clientHostbased OBJECT IDENTIFIER
          ::= { 1.3.6.1.4.1.2213.15.1.3 }

I don't recall how we came up with the oids...

> For most protocols, including an OCSP response alongside a certificate 
> is an optimization, because it allows the recipient to verify that the 
> certificate is valid without independently contacting an OCSP server.  
> This is particularly interesting when the party that includes the OCSP 
> response uses its certificate frequently in a short period of time, 
> because it can cache and reuse the OCSP response for as long as it is 
> valid, reducing load on OCSP servers.
> 
> For SSH, this capability might be valuable chiefly because it would 
> permit clients to provide OCSP responses to SSH servers living in 
> restricted networks or under other constraints which might prevent them 
> from contacting the OCSP server directly.

Then we might do something like:

 > This key format has the following specific encoding:
 >
 >      uint32    ocsp-response-count
 >      string    ocsp-response[0..ocsp-response-count]

If I'm understanding the PKI correctly, ocsp-response-count should
be at most certificate-count - 1 (once ocsp response for each issuing
certificate in the chain.)

Thanks,

Joseph

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Thu, 19 Nov 2009 20:06:58 -0500

> stage.  Does that sound correct?

Yes, I believe that's currently true.
>         id-kp-ssh-server OBJECT IDENTIFIER

1.3.6.1.4.1.2213 is the PEN assigned to Data Fellows.  So presumably, 
someone employed by them who was working on this document allocated these 
numbers out of their arc.

> certificate in the chain.)

I'm not sure.  I would not expect more OCSP responses than certificates, 
but it's unclear to me whether it's useful to provide for more than one.  I 
suppose this is something we ought to ask the PKI experts about.

-- Jeff