Re: draft-igoe-secsh-x509v3-00

[Jeffrey Hutzelman <[e-mail]>]

--On Tuesday, December 15, 2009 11:42:23 AM -0700 Joseph Galbraith 
<[e-mail]> wrote:

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

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.




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

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.


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

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.


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

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

-- Jeff