Subject: Re: draft-igoe-secsh-x509v3-00

From: Douglas Stebila <[email-masked]>
Date: Tue, 15 Dec 2009 12:10:19 +1000

Thanks for the feedback, Joseph and Jeff.

Let me try to summarize the various points from your chain of emails.

First off, points that we will address as requested (although a new draft probably won't appear until the new year):

1) Include more specifics (key encodings, signature formats) and examples in the document.  We will do this in the next draft.

2) Add discussion on keyUsage extensions (digitalSignature for most uses in SSH, and keyAgreement for the ECMQV cipher suite).  We will do this in the next draft.

3) Require the first cert in the chain to use the correct type of key.  We will do this in the next draft.

4) Suggest/require the cert chain to only use signatures that are acceptable to the peer according to the SSH public key algorithm negotiation.  I like Jeff's suggestion that this would mean we actually negotiate certs that are useful for the entire process.  I will add this in the next draft.  Recognizing, however, that servers may have a single cert chain that they can't change on the fly, I will include a note suggesting that implementations SHOULD be prepared to receive a non-compliant (in terms of algorithms used) chain and MAY still choose to verify it if they wish.

And some points for further discussion:

5) Encode certificate chains as a native SSH data structure, not in ASN.1.  Kevin and I had discussed this originally and went with ASN.1 for the following reasons: (a) since certificates themselves are in ASN.1, implementations will need to have an ASN.1 tool around anyway; (b) I think most existing tools using certificates keep them in ASN.1, so someone supplying a certificate chain to an SSH implementation is likely using ASN.1 elsewhere for that; (c) the certificate chain only needs to be kept as a single blob in the filesystem as opposed to multiple files, making configuration easier.  But if the consensus is that an SSH data structure is more appropriate, we can change the draft.

6) Extended key usage key purpose IDs.  I must confess to being a bit confused about this one.  In the original X.509 in SSH draft, you say that SSH implementations SHOULD NOT use extended key usage extensions, but then go on to provide some anyway.  Can you help me understand what appears to be a contradiction?  Would we need to get new OIDs or could we reuse the ones from the previous document?

7) Certificate revocation list / OCSP responses.  You've suggested including CRL or OCSP data alongside the certificate chain for efficiency purposes.  I'm not a PKI expert either, so I'd like to hear more feedback, especially from implementers, on whether this would be of interest to them.  I know that SunSSH's support for X.509 has some consideration of CRL/OCSP, so maybe Jan can comment on what he thinks of including that data with the cert chain or handling it outside of the protocol.

Thanks,

Douglas

On 2009-Nov-19, at 9:50 AM, Joseph Galbraith wrote:

> Igoe, Kevin M. wrote:
>> 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!
> 
> 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: Joseph Galbraith <[email-masked]>
Date: Tue, 15 Dec 2009 11:42:23 -0700

Douglas Stebila wrote:
> First off, points that we will address as requested (although a new
> draft probably won't appear until the new year):
> 
> 1) Include more specifics (key encodings, signature formats) and
> examples in the document.  We will do this in the next draft.
> 
> 2) Add discussion on keyUsage extensions (digitalSignature for most
> uses in SSH, and keyAgreement for the ECMQV cipher suite).  We will
> do this in the next draft.
> 
> 4) Suggest/require the cert chain to only use signatures that are
> acceptable to the peer according to the SSH public key algorithm
> negotiation.  I like Jeff's suggestion that this would mean we
> actually negotiate certs that are useful for the entire process.  I
> will add this in the next draft.  Recognizing, however, that servers
> may have a single cert chain that they can't change on the fly, I
> will include a note suggesting that implementations SHOULD be
> prepared to receive a non-compliant (in terms of algorithms used)
> chain and MAY still choose to verify it if they wish.

When I first read Jeff's (I think) proposal on this I thought it
was a great idea.  Then when I was reading your description above,
I realized that it might not be such a great idea.

I reviewed RFC 4253, 7.1.  Algorithm Negotiation, and what is
actually negotiated is "server_host_key_algorithms".  So the absence
of an algorithm in the list does not imply that the server
doesn't support he algorithm, just that it doesn't have a hostkey
using that algorithm.

This is further supported by the fact that publickey usage during
publickey userauth is not restricted to the algorithms negotiated
during key exchange.

So, based on that, I'm not sure we should actually make any restrictions
based on the negotiated algorithms.

> 5) Encode certificate chains as a native SSH data structure, not in
> ASN.1.  Kevin and I had discussed this originally and went with ASN.1
> for the following reasons: (a) since certificates themselves are in
> ASN.1, implementations will need to have an ASN.1 tool around anyway;
> (b) I think most existing tools using certificates keep them in
> ASN.1, so someone supplying a certificate chain to an SSH
> implementation is likely using ASN.1 elsewhere for that; (c) the
> certificate chain only needs to be kept as a single blob in the
> filesystem as opposed to multiple files, making configuration easier.
> But if the consensus is that an SSH data structure is more
> appropriate, we can change the draft.

The CERT libraries I've dealt with seem to want to deal with individual
certificates.  I.e., I have to add certificates to a store object of
some sort individually and then the library will build a chain.  Or
I have to put the chain in a C array of CERT* in chaining order.

These libraries probably expose a general purpose ASN.1 decoder, but it
is another piece of code I have to interface with...

All that said... it's not going to break my heart if we use ASN.1 here.

> 6) Extended key usage key purpose IDs.  I must confess to being a bit
> confused about this one.  In the original X.509 in SSH draft, you say
> that SSH implementations SHOULD NOT use extended key usage
> extensions, but then go on to provide some anyway.  Can you help me
> understand what appears to be a contradiction?  Would we need to get
> new OIDs or could we reuse the ones from the previous document?

Yeah... the language in the draft baffled me to, and I wrote it :-)

I think we should pretend the SHOULD NOT phrase was never written
unless someone else can come up with a reason why.

I don't think Data Fellows is involved in SSH anymore, so we'll
probably need new OIDs... is there an ietf pool we can pull from?

> 7) Certificate revocation list / OCSP responses.  You've suggested
> including CRL or OCSP data alongside the certificate chain for
> efficiency purposes.  I'm not a PKI expert either, so I'd like to
> hear more feedback, especially from implementers, on whether this
> would be of interest to them.  I know that SunSSH's support for X.509
> has some consideration of CRL/OCSP, so maybe Jan can comment on what
> he thinks of including that data with the cert chain or handling it
> outside of the protocol.

As an implementor that currently supports the undocumented x.509
protocol, our customers forced us to add a 'Don't do revocation
checking' option because they had systems that couldn't reach the
revocation service.

So I know there is a real problem to be solved.

Thanks,

Joseph

>>> 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!
>> 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.
>> 
>>> "x509v3-ecdsa-sha2-*" / "x509v3-ecmqv-sha2" string
>>> certificate-chain
>>> 
>> 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.
>> 
>> 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.)
>> 
>>> "x509v3-ecdsa-sha2-*" / "x509v3-ecmqv-sha2" uint32
>>> certificate-count string    certificate[1..certificate-count]
>>> 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
>>> Signing and verifying using the "x509v3-ssh-dss" key format is
>>> done according to the Digital Signature Standard [FIPS-186-2] 
>>> 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.
>>> 
>>> 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.
>> 
>> 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?
>> 
>> 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 
>> 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: Tue, 15 Dec 2009 16:41:01 -0500

> based on the negotiated algorithms.

As you note, the absence of an algorithm in the server's list indicates 
only that it does not have a key using that algorithm, not that the 
algorithm is not supported.  However, the absence of an algorithm in the 
client's list does mean the client does not support that algorithm for host 
keys.  So I think it is reasonable to advise servers to prefer certificate 
chains using algorithms which the client claims to support.

However, I also agree with Douglas that a client must be prepared to 
receive a chain that contains other algorithms (and which it might not be 
able to validate), since a server may have a fixed chain and have no 
control over the algorithms used.

Or maybe we should drop the idea entirely.

> is another piece of code I have to interface with...

OpenSSL, or at least every OpenSSL-using application I've seen, exposes an 
interface where you hand it a file containing one or more certificates in 
PEM-encoded ASN.1 and it builds a chain to use in the TLS handshake.  Now, 
I don't know if it exposes similar interfaces for non-TLS applications 
using X.509 directly.

> unless someone else can come up with a reason why.

The EKU extension carries the semantics "this certificate may be used 
_only_ for the listed purposes".  So, if you want it to be possible for a 
certificate using the extension to list your application as one of the 
permitted uses, then you need to define a keyPurposeId.  It makes some 
amount of logical sense to say SHOULD NOT include the EKU extension (i.e. 
don't apply a usage restriction), but to define a keyPurposeId to be used 
when a restriction is applied.

That said, IMHO the SHOULD NOT is inappropriate, unless someone knows of an 
interoperabiltiy reason for it.  So I think just dropping the SHOULD NOT 
phrase is best.

> probably need new OIDs... is there an ietf pool we can pull from?

The security AD's control an OID arc that can be used for IETF 
security-related protocols.

-- Jeff

---

From: Nicolas Williams <[email-masked]>
Date: Tue, 15 Dec 2009 16:03:52 -0600

On Tue, Dec 15, 2009 at 12:10:19PM +1000, Douglas Stebila wrote:
> that SSH implementations SHOULD NOT use extended key usage extensions,
> but then go on to provide some anyway.  Can you help me understand
> what appears to be a contradiction?  Would we need to get new OIDs or
> could we reuse the ones from the previous document?

The document should (must!, IMO) define an EKU for ssh.  For the rest,
the EKU rules in RFC5280 should suffice.  This is all about ensuring
that there's a way to create certificates that can only be used for
specific protocols, as opposed "any protocol".  Administrators need not
actually require use certs with EKUs if they don't want to, but they
must have the option to.

> efficiency purposes.  I'm not a PKI expert either, so I'd like to hear
> more feedback, especially from implementers, on whether this would be
> of interest to them.  I know that SunSSH's support for X.509 has some
> consideration of CRL/OCSP, so maybe Jan can comment on what he thinks
> of including that data with the cert chain or handling it outside of
> the protocol.

First, SunSSH does not support x.509 yet.

Second, I *strongly* recommend that both, the client and server be able
to send OCSP responses for their own certs to the other, and that
servers be able to send OCSP responses for the client's certs back to
the client.  This has a number of major benefits:

 - OCSP scales much better than CRLs, and while OCSP can be used by the
   relying party...

 - ...having each party send OCSP responses for its cert (and cert
   chain) to the other is an optimization:

    - reduces latency (the relying party need not go find OCSP
      responders, resolve them, and send requests to them; clients can
      cache OCSP responses and thus reduce the amount of time spent
      talking to online infrastructure);

    - reduces OCSP responder load;

    - puts the onus for caching OCSP responses on the client's
      shoulders.

   Think of cert+OCSP_response as being like a Kerberos ticket.  The
   server will not have to use any online infrastructure in order to
   authenticate the client.  (It's better than a Kerberos ticket: the
   x.509 client can use the same credential to authenticate to many
   servers, whereas the Kerberos client has to talk to online
   infrastructure at least once for every server it wishes to
   authenticate to.)

 - If a client cannot reach OCSP responders or does not support OCSP
   directly, the server can still send it OCSP responses for the
   client's certs so that the client can be responsible for caching and
   subsequently send those responses to other servers.

In fact, I can't imagine new PKIX applications not supporting use of
OCSP in these ways.

The main issue, I think, is not whether to use OCSP but how to know when
a peer needs various large items (cert chains) a priori, whether to
incur extra round-trips to exchange those.

Nico
--

---

From: Nicolas Williams <[email-masked]>
Date: Tue, 15 Dec 2009 15:47:41 -0600

On Thu, Nov 19, 2009 at 08:06:58PM -0500, Jeffrey Hutzelman wrote:
> --On Thursday, November 19, 2009 01:11:43 PM -0700 Joseph Galbraith 
> >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?
> 
> Yes, I believe that's currently true.

Right.  RFC4432 introduced RSA key transport, but hosts are still
authenticated via public key signatures.

Nico
--

---

From: Jan Pechanec <[email-masked]>
Date: Wed, 16 Dec 2009 13:55:56 +0100 (CET)

>First, SunSSH does not support x.509 yet.

	Douglas knows that I did some interop tests with VanDyke and 
Attachment and that it went OK. The code is still somewhere in my 
workspace and I haven't ever released a patch, that's true.

>the client.  This has a number of major benefits:

	I agree with that. I think this idea of sending OCSP responses 
was already in the original draft by Joseph and Oskari, if I remember 
correctly. BTW, kmf_validate_cert() accepts optional OCSP response data.

	J.

-- 
Jan Pechanec