Re: OpenSSH Certkey (PKI)

	Sigh. My objections to this are my objections to PKI implementations
in general.  In my experience PKI methods are implemented and deployed
the same way people deploy half done raid drivers - we'll make the
disk work, but we won't worry about how to monitor and fix it when it
gets fucked up.  "that'll be implemented later/left as an exercise for
the deployer to hack up something disgusting"

> 
>  b) It adds a certificate to the public key of a ssh user so the ssh
>  server can verify the authenticity of a users pubkey without having
>  to have a pre-populated authorized_keys file in each users home
>  directory on all machines this user has access to.
>  keys and authorized keys files).

	I maintain it does NOT do this - and here is why :

> 
>  Less severe incidents include lost or compromised user keys.  OpenSSH
>  PKI gives two methods to deal with this.  First it allows to specify
>  an expiry date for all certificates.  If set sufficiently short all
>  certs lose their usefulness quickly.  All users have to be re-certified
>  in intervals and the re-certification can be tied to any number of
>  administrative criteria.  For immediate reactions any number of public
>  key fingerprints can be blacklisted on the ssh server.  This is a simple
>  file based certificate revocation.  Online revocation checks could
>  optionally be implemented as well.  The operator then has to specify
>  whether to fail open or close depending on priorities and risk
>  assessments.

	In other words, I have to maintain a pre-populated "un-authorized"
keys file  because in any real deployment you are GOING to have these. 
and quite frequently with any sizable deployment. So I still have
to maintain a file. 

	"authorized keys" -> anything that is not allowed is denied. 
	"un-authorized keys" -> anything that is not denied is allowed.

	NOT being prepared to maintain a file when doing this
is pretty much akin to "Don't worry, I'll pull out before I cum". Everything's
great until there a problem and then it's a fuckshow.  
	
	I.E. this is the same "it's really cool and we almost have it right"
argument I've seen from everything pushing PKI and x509 goo as
authentication. An expiry date for all the user certs? gimme a break.
even setting it to a month (which would be a pita to have users
constantly re-certed) means someone gets a month to fuck around. Even
suggesting that certificate expiry times should be used to mitigate
this is irresponsible. You have to be able to nail something you know
is compromised quickly. The only thing expiry times to is A) make
money for commercial CA's, B) make stuff not have to stay forever in
your CRL if you have one. 

	Don't get me wrong, I think this is possibly useful, but I don't
think it should go in incomplete like this. In my view it is complete
where when turning it on you specify a set of (possibly other) ssh
server(s) the server itself will connect to and use as a CRL when
presented with a key. - i.e. we should make it decently doable and
document how to use a CRL in this case. I feel quite strongly that
without tying the last piece together, we're handing people an
incomplete thing with enough rope to hang themselves - "Here's a nice
thing for a centralized deployment but oops if a luser loses a key you
have to run around and do a panty raid to all your servers, because we
left that as an exercise just like every other fucktard that
implements this stuff does instead of giving you the tools to do it
right"

	So, My two cents, make it complete first. Making an archetecture
for ssh that makes it easy to add trust centrally WITHOUT MAKING IT EASY
TO REMOVE IT is irresponsible.

	(Now I'll go away and be cranky elsewhere, having a bad day)

	-Bob