Re: OpenSSH certified keys

[Jeffrey Hutzelman <jhutz%cmu.edu@localhost>]

--On Wednesday, March 17, 2010 09:52:04 AM +1100 Damien Miller 
<djm%mindrot.org@localhost> wrote:

> > OpenSSH would be a lot more useful if it supported the same
> > authentication mechanisms as the rest of the world.
>
> Well, unfortunately we consider the additional complexity and attack
> surface added by X.509 to be too great. That being said, there are
> well-maintained 3rd party patches to OpenSSH that support X.509
> certificates if users have a need that isn't supported by this mechanism.

As I said, that's unfortunate.

> > This seems like a serious shortcoming.  Practically no one uses
> > single-level certificate heirarchies any more; there's nearly always at
> > least one intermediate CA for operational and security reasons.  Taking
> > out this feature makes the system less secure.
>
> I disagree with this too. This certificate format isn't saddled with
> X.509's one-PKI-to-bind-them mentality and doesn't have to be
> singly-rooted.  OpenSSH supports simultaneous trust of multiple CA keys,
> so this deals with CA key revocation and rollover differently.

I see no such mentality.  The several most widely-deployed X.509 
implementations all support multiple trust anchors, and both X.509 and PKIX 
contemplate the possibility of such.  However, that's not a sufficient 
answer to scalability issues that multi-level PKI's solve.  It also doesn't 
allow for the sorts of cutouts that allow one to sign certificates on a 
regular basis while keeping the secret key for the widely-distributed trust 
anchor offline and under lock and key, which is important given the 
operational impact of having to revoke that key.

BTW, saying you revoke keys rather than certificates doesn't really do 
much.  Who is authorized to revoke a key?  How is that information 
distributed.  A server configuration option that must be manually 
maintained on each SSH server is not really a scalable solution to this 
problem, especially when the majority of servers are not operated by the 
same person as the CA.




> I agree that the term "constraint" may be something of a misnomer, but
> disagree that the sense of the extension should be flipped. The intention
> here is that new protocol features should not be automatically granted to
> old certificates.

That's fine, but should be up to the CA.  For example, one might have a 
constraint that prohibits use of (some class of) protocol features other 
than ones explicitly listed.  In your model, not only is there no way to 
issue a certificate which can be used with any protocol features including 
new ones, there is also no way to issue a certificate which allows use of a 
new protocol feature but can be also used with servers that do not yet 
support that feature.  That means I need a separate certificate for every 
permutation of features supported by the servers I use, which again is not 
scalable.

If the "constraints" _disable_ protocol features then
> they will inherit whatever ambient permissions may be added in the future.
>
> wrt non-critical extensions. This is a possibility, via the "reserved"
> field in the future if they are really necessary.

But you haven't defined how the reserved field will work, or what it MUST 
contain in the current protocol.  So not only is it impossible for anyone 
to define such an extension without "taking over" this field (and you've 
defined no means of coordination for that); you've actually made it 
impossible to use the field at all, because no one can predict what 
existing servers will do with it or what it might contain in existing 
certificates.

-- Jeff