Random thoughts/crazy idea: Drop SSL certs

Dennis Gilmore dennis at ausil.us
Mon Apr 27 16:50:00 UTC 2015


On Monday, April 27, 2015 06:23:38 PM Pierre-Yves Chibon wrote:
> 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?

you would need to get on fas01 today and manually revoke it. so yes it is 
doable. 

> 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? :))

That is how I was proposing a move to dogtag or some other new robust system, 
as dogtag from previous conversations can not easily reuse the existing CA. 
but I may missunderstand that or things may have changed since I last talked 
to the dogtag folks about it.

> > > 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 :)
This is not something that can really be done with certs etc. it would require 
a fundamental change in how all the tools deal with permissions.

Dennis
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.fedoraproject.org/pipermail/rel-eng/attachments/20150427/14d109b1/attachment.sig>


More information about the rel-eng mailing list