Random thoughts/crazy idea: Drop SSL certs

[Pierre-Yves Chibon]

On Mon, Apr 27, 2015 at 05:59:14PM +0200, Till Maas wrote:
> On Mon, Apr 27, 2015 at 03:45:00PM +0200, Pierre-Yves Chibon wrote:
> 
> > The following only works under the assumption that it is.
> > So SSL certs are basically a certain type of API token. Everyone has one,
> > specific to koji and the lookaside cache, time limited and gives us a way of
> > doing authentication and authorization server side.
> > 
> > So on this they behave just like any other API token, but using SSL certs has
> > some pros and downs:
> 
> It is not an API token in the sense that the key is not transfered via
> TLS, so if there are bugs in TLS like Poodle, they do not expose the
> token.
> 
> > cons:
> >   - One per client
> >   - Hard to invalidate iiuc (ie: if someone's machine is compromised/lost it is
> >     hard to make this user's certificate invalide)
> 
> This is not the case currently afaik. If one creates a new certificate,
> the old one is revoked and our systems honor this.

Yes but can an admin easily do this ?
Say, I'm traveling, my laptop is stolen, I do not have access to the internet
but I can text X informing of the theft. Can an admin easily invalidate my
client cert?

Don't get me wrong, I'm happy if this is the case, but I am under the impression
it isn't :)

> >   - Relies on the master certificate that expires every X years making everyone
> >     generate a new client certificate
> 
> The expiration of the master certificate does not require the client
> certificate to be regenerated as long as the same master key is used.
> Also it is easily possible to move to a new master CA while keeping the
> old CA valid for a migration time (e.g. the duration of normal client
> certificates).

Hm, I guess this just exposes my ignorance of the SSL workflow, but from a
discussion with Dennis, I seem to have understood that changing the master
certificate would imply asking everyone to get a new client certificate.
Could this be because koji only accepts one master cert? (Or do I just wrongly
recall? :))

> > On the otherside, recently we have been more and more feeling the need for a
> > centralized API authentication place. Something along the line of a personalized
> > 0Auth. This has also pros and cons.
> > 
> > pros
> >   - API token per user and per application
> 
> This is something I would like very much, but also with a fine-grained
> permissions system. E.g. allowing to create a token that can only be
> used to retire pkgs in pkgdb could be used to automate retiring pkgs
> without using credentials that can also a everything else.

This is really something that would be cool to get :)


Pierre