Re: OpenSSH certified keys

[Damien Miller <djm%mindrot.org@localhost>]

On Tue, 16 Mar 2010, Jeffrey Hutzelman wrote:

> --On Wednesday, March 17, 2010 04:19:28 AM +1100 Damien Miller
> <djm%mindrot.org@localhost> wrote:
> 
> > OpenSSH 5.4p1 introduced a novel, lightweight certificate format for
> > user and host keys. These were designed to reuse SSH wire-encoding and
> > signature primitives to minimise the additional attack surface exposed
> > pre-auth. In particular, we are not comfortable with the complexity
> > (syntactically or sematically) of X.509.
> 
> That's unfortunate, because it's what the rest of the world already has as its
> infrastructure.  By not supporting it, you force people to choose between
> supporting your odd, proprietary, unproven certificate format or not getting
> to use certificates at all.  Guess which one anyone with more than 5 machines
> is going to choose?
> 
> 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.

> > signature key contains the CA key used to sign the certificate.
> > The valid key types for CA keys are ssh-rsa and ssh-dss. "Chained"
> > certificates, where the signature key type is a certificate type itself
> > are NOT supported. Note that it is possible for a RSA certificate key to
> > be signed by a DSS CA key and vice-versa.
> 
> 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.

> > The name field identifies the constraint and the data field encodes
> > constraint-specific information (see below). All constraints are
> > "critical", if an implementation does not recognise a constraint
> > then the validating party should refuse to accept the certificate.
> >  ...
> > permit-X11-forwarding   empty         Flag indicating that X11 forwarding
> >                                       should be permitted. X11 forwarding
> > will                                       be refused if this constraint
> > is absent.
> 
> 
> This is a poor combination, because it means that the server must understand
> all the things I am allowed to do, even if it doesn't implement them.  And
> really, "permit foo" is not a constraint at all; it's the reverse of a
> constraint.
> 
> I recommend _both_ inverting the sense of the "permit-*" items _and_ allowing
> for non-critical extensions, which are often essential for extending a
> protocol in a meaningful way.

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

-d