IETF-SSH archive

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

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



Henrick Hellström wrote:
Bill Sommerfeld wrote:

I would have hoped to see:

1) expected relationship(s), if any between the certificate Subject and/or subjectAltName fields and the identity of the server or user which owns the certificate. (This of course opens up the "Naming is Hard" discussion.)

I mostly agree with these points. Without these there seems to be little
point in using X.509 certificates at all.

I can only see a point in using X.509 certificates with SSH, in case
secure distribution of public keys between the server and the clients is
not feasible.

To be honest, this covers most SSH cases, right?

Or at least, in most cases, password authentication must also
be enable to enable the secure distribution of publickeys,
and host keys are generally not distributed securely.

In the case of naming, what would really make sense would be a
relationship between:

a) On one hand the URI and version string of the server, and on the
other hand the subject and/or subjectAltName of the server certificate

So what you are saying is that the draft ought to include text along
the lines of:

When the certificate is used as a hostkey, either the subject name
or the subjectaltname SHOULD match the canonical name of the server.
(Are their multiple names in the subject name or subject alt name;
I don't recall?)

Or should match the name used by the user?  Are there DNS issues
in saying canonical name?

b) On one hand the username of the client, and on the other hand the
subject and/or subjectAltName of the client certificate.

And what you are saying here is that the draft ought to include text
along the lines of:

When the certificate is used as part of publickey authentication,
the username specified in the publickey packet SHOULD match
either the subject name or the subjectAltName in the certificate.

The presumption of the secsh wg ought to be that the URI of the server
and the username of the client user already identifies these entities.

Is this saying what I said above?

2) text regarding KeyUsage and ExtendedKeyUsage.

This is application specific, so it should go into the secsh-x509 spec.

It sounds like there is a missing 'not' in this sentance?

If their isn't a missing 'not', can you give me some more
details as to what you are thinking?

5) more text about the use of certificates for user authentication or
a claim that it's entirely out of scope for the document..

Agreed.

This I can handle.  They can be used for authentication... once I start
to get a handle on what other changes we are going to make to the
document to address the other concerns, I'll make sure this is clear.

Thanks,

Joseph



Home | Main Index | Thread Index | Old Index