Re: OpenSSH certified keys

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

On Tue, 16 Mar 2010, Jeffrey Hutzelman wrote:

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

A similar operational effect could be achieved by having additional
trusted CA keys established ahead of time and securely placed in reserve
for the case where a primary CA key is compromised. Next?

In case you are wondering, recursive verification is not included for
reasons of conceptual and implementation simplicity. 

> 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 don't really see the mechanism of key revocation as part of the
certificate _format_. Just because X.509 includes it there isn't a
strong reason that others need to do so.

In answer to your question, the current OpenSSH implementation supports
a text file of revoked keys distributed out of band. This isn't
scalable, but it isn't the only possibility; it wouldn't be hard to
define an online method of testing key revocation (a la OCSP), perhaps
via a new SSH subsystem. A defined subsystem for enrolling keys would
be nice, but that is outside the scope of the certificate format
description too.

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

That is a fair point and it is potentially worth reconsidering the
criticality of certificate extensions because of it. I think that
in the presence of non-critical extensions though, the sense of the
extensions is more important; if a non-critical extension that disables
some protocol feature is skipped by an implementation that does not
understand it (but does implement the protocol feature), then there are
more security consequences than the converse.

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

The document I sent is not set in stone (clearly; it was sent
for feedback) and there is only one server that implements it,
which happens to ignore this field's contents. So using it as an
extensibility mechanism is a simple matter of clarifying its intent in
the specification.

-d