Subject: Comments on draft-ietf-secsh-x509-03

From: Oskari Saarenmaa <[email-masked]>
Date: Wed, 15 Mar 2006 16:51:00 -0800

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

---

From: Roumen Petrov <[email-masked]>
Date: Fri, 17 Mar 2006 00:15:16 +0200

Oskari Saarenmaa wrote:
> [SNIP] The signature format for

May be the signature format should be part of public key algorithm name.
The client shouldn't guess which signature format is supported by server
and shouldn't send blindly signed authentication request.

Other possibility is to extend 'public key authentication method' with new message[s].
May be a new response SSH_MSG_USERAUTH_X509_OK:
       byte      SSH_MSG_USERAUTH_X509_OK
       string    public key algorithm name from the request, i.e. "x509v3-sign"
       string    public key blob from the request
       name-list signature algorithms supported by server.

In first case we should define many names without to change protocol,
but the client should send a certificate with diferent algorithm names
until server accept one or reject all. Then client can begin with next
certificate and so on and so forth.

In second case is with just one name, but require protocol changes.
:-\

May be SHA1 algorithm is sufficient. The problem with hash algorithms
exist for rsa/dss keys too.

Regards,
Roumen Petrov

---

From: [email-masked] (Peter Gutmann)
Date: Mon, 20 Mar 2006 16:11:00 +1200

>Any comments/feedback are welcome.

I have some comments (these may be best read to the sound of an Alka-seltzer
fizzing in a glass :-).

Section 3.1.1 is self-contradicting, first there's a paragraph saying you
shouldn't use eKU, and then the following paragraph tells you what to set eKU
to.  Is this an editing error where one of the two paragraphs was supposed to
have been removed, or was it deliberate?  If it's deliberate, why are there
two contradicting requirements?

Wouldn't it be better to use the existing, universally-implemented
client/serverAuth eKU's instead of inventing new, incompatible ones?  The
latter strategy practically guarantees that they'll never see support in any
mainstream PKI software, which kind of defeats the point of using standard
X.509 certs to contain the keys.

Section 4's use of OCSP is IMHO a bad move, it hard-codes a particular
revocation-checking mechanism into the exchange while excluding all others.
What if you're using CRLs for checking?  What about signed attestations?  The
explicit hardcoding of OCSP constrains implementors into a single mechanism
for checking, and excludes all others.

In addition, much of this section seems to be reinventing the wheel that the
TLS folks spent ages thrashing out.  From the history of TLS, it's going to
take endless tweaks and revisions to get this into a form where it works for
all users.  Since what's being done here is identical to what TLS does, except
for a minor difference in encoding (TLS uses uint24's instead of uint32's for
lengths, otherwise the two formats are identical), it would be better to
simply refer to the TLS sections that cover this same material and build on
the experience they've gained with this.

The algorithm-encoding in section 4 is also a bad move.  Firstly, it's
incompatible with the existing well-established SSH method for doing this, so
you now need to implement two parallel and incompatible algorithm-encoding
methods, one for all of SSH except SSH-with-X.509, and another for SSH-with-
X.509 only.  In addition since there are vast numbers of redundant OIDs
(there's half a dozen or more for SHA-1 alone), you'd need to provide a
central registry in the SSH docs for each allowed value, in which case you're
simply duplicating the existing (non-OID) SSH algorithm registry.  Finally,
the dotted form for text-mode OIDs is incorrect, this is an aberration found
in some IETF texts but isn't valid ASN.1.  The correct form has spaces, not
dots.

(The fact that this error has made it into the spec is an example of why using
OIDs is not a good idea, just stick with the standard SSH algorithm IDs).

Section 5 should probably be removed, like the OCSP use it seems to hardcode a
pile of arbitrary restrictions on usage on the use of X.509 certs in SSH.  Why
do you need to verify the full chain?  Even the PKIX spec never requires this,
it merely requires verification up to a trust anchor.  If you have an
explicitly trusted EE cert, you don't need to look at the other certs at all.
In addition if you subscribe to some of the more peculiar ideas in PKIX, the
concept of a "chain" doesn't really exist any more since you're now dealing
with a full graph with unpredictable semantics.  The requirement to refuse a
cert if no OCSP responses are included extends the comment I made about
section 4, this *forces* you to use OCSP, whether you want to, or whether it's
appropriate, or not.  This section really doesn't have any place in this
document, how an implementation handles the certificates it receives is purely
a local policy issue .

Overall I think this document should restrict itself to specifying the basic
formats, and leave cert-processing details and policy issues to things like
PKIX, who have generated thousands of pages (literally!) of documentation on
this.  Also, since what's being done here is identical to what TLS has spent
several years working on, re-using the results of the TLS work would help
avoid the need to re-work the SSH stuff once people start rediscovering the
various issues that the TLS folks have already dealt with.

Peter.

---

From: Joseph Galbraith <[email-masked]>
Date: Mon, 20 Mar 2006 09:41:58 -0700

> various issues that the TLS folks have already dealt with.

This was our original intent (and if you look at the first couple
of versions of the document, what we did.)

However, it seemed like people wanted more out of the draft.

I'd be really happy to go back to simply describing how
to encode x.509 certificates and signatures in the SSH
protocol and call this draft done.

But-- I guess we need people who care about this to
come out of the woodwork and speak up now about what
the working group wants out of this document.

Thanks,

Joseph

---

From: [email-masked] (Peter Gutmann)
Date: Tue, 21 Mar 2006 23:09:31 +1200

Joseph Galbraith <[email-masked]> writes:

>This was our original intent (and if you look at the first couple of versions
>of the document, what we did.)

Yeah, I wondered why it'd changed so suddenly.

>I'd be really happy to go back to simply describing how to encode x.509
>certificates and signatures in the SSH protocol and call this draft done.
>
>But-- I guess we need people who care about this to come out of the woodwork
>and speak up now about what the working group wants out of this document.

I'd prefer to just have the format documented and call it done.  Fiddling with
certificate-management policy is something that other WGs have spent
(literally) years over, and reached consensus only in the sense that everyone
was equally unhappy with the result... I'd say document the bits on the wire,
and leave the policy side to someone else to write up in their own draft.

Peter.