IETF-SSH archive

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

Re: OpenSSH certified keys



How will extensions to this PKI cert format be handled?  I see nothing
about criticality...

I understand the aversion to PKIX, which probably derives from an
aversion to x.500-style naming, ASN.1 and BER/DER/CER.  But there are
more lessons to be learned from PKIX than "x.500 sucks" and "BER sucks".

I also understand the intention of having a simple cert format just for
use with SSHv2.  But SSHv2 doesn't exist in isolation.  People use it in
environments where they use Kerberos, so we've added extensions to allow
the use of GSS-API mechanisms and, through that, Kerberos.  Similarly
for PKIX.  If this cert format becomes popular then people will want to
use it elsewhere for the simple reason that having more than one
credentials/authentication infrastructure sucks.

To me this means that we have to ask whether this is desirable right
now.  If it becomes popular then, of course, it sure will be desirable
(and to be sure, I think the OpenSSH team certainly has the ability to
make this protocol popular).  Which means that we'd better get some
aspects of this Right right now; at minimum these issues have to be
handled correctly from day 1:

 - revocation (PKIX lesson: CRLs _suck_)
 - extensibility (how to add critical and non-critical cert elements)
 - principal naming (there's more than just 'hostnames' and 'usernames')
 - federation / CA naming / PKI hierarchies, including mapping to the
   DNS (you might rely entirely on DNSSEC for hierarchy, that'd be a
   fine solution)

Implementation-wise I urge to to make this as much library-like as
possible, so that eventually you can make a trivial GSS-API mechanism
out of it.

Nico
-- 



Home | Main Index | Thread Index | Old Index