----- Original Message ----- > From: "Phillip Hallam-Baker" <ph...@hallambaker.com> > To: "Gervase Markham" <g...@mozilla.org> > Cc: "Rob Stradling" <rob.stradl...@comodo.com>, > mozilla-dev-security-pol...@lists.mozilla.org, "Hubert Kario" > <hka...@redhat.com> > Sent: Friday, September 5, 2014 2:11:09 PM > Subject: Re: Short-lived certs > > We probably need to mark them in some way as being intended to be > short lived. And we certainly need to fix the problem of getting them > renewed efficiently.
I'd say that this is purely CA problem. Since the short lived certs are supposed to be a replacement for the revocation checking, using the same key for those certs is not a problem. As such, the CA may just re-sign the certificate on a daily basis and publish it in a non-obvious directory (e.g. SHA-1 hash of the certificate public key) if they don't want to make it easy to compute how many certificate they issue. Then the server downloads the certificate over HTTP, FTP, or gets it in email, validates if it matches the key it has, validates the signature and issuer and then starts serving it to clients. If you want to use new key for every certificate you'll have to use Simple Certificate Enrollment Protocol (SCEP), Certificate Management Protocol (CMP) or something similar. So it is possible to have a full spectrum between trivial and very complex as far as certificate re-issuance and management goes. I don't think it is good idea to mandate one specific implementation over another... -- Regards, Hubert Kario Quality Engineer, QE BaseOS Security team Email: hka...@redhat.com Web: www.cz.redhat.com Red Hat Czech s.r.o., Purkyňova 99/71, 612 45, Brno, Czech Republic _______________________________________________ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
