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

[pgut001%cs.auckland.ac.nz@localhost (Peter Gutmann)]

Oskari Saarenmaa <oskari.saarenmaa%f-secure.com@localhost> writes:

>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.