stapling extensions to public keys instead of certificates? [was: Re: Sharing Trust Policy between Crypto Libraries]
stefw at redhat.com
Thu Jan 3 14:28:09 PST 2013
-----BEGIN PGP SIGNED MESSAGE-----
On 01/03/2013 10:48 PM, Daniel Kahn Gillmor wrote:
> On 01/03/2013 03:45 PM, Nikos Mavrogiannopoulos wrote:
>> One small patch also to allow for a subjectpublickeyinfo
>> structure instead of a full certificate.
> heh. one of my side notes was about whether it makes sense to
> want to staple these extensions to public keys instead of (or in
> addition to) certificates.
> At the very least, i think that we should be capable of
> blacklisting public keys directly (to avoid re-use of a blacklisted
> key in a new certificate).
> But i also think it might be more complicated than nikos' proposed
> simple patch suggests.
I added this to the 'Known Outstanding Issues' of the document.
So that I can sleep and stop thinking about this (heh, heh) ... I've
done a bit of a brain dump here. Roughly, here are my current
outstanding questions for discussion and research on this topic:
Related to use cases:
* Blacklisting public keys.
* Setting trust policy on a raw public key in a protocol where
they are used instead of X.509 certificates.
* What kind policy?
* Which extension would be used as trust policy on a public key
in a real world protocol / use case?
* Is that a previously defined certificate extension?
* Or perhaps a custom certificate extension?
* Do anchors (ie: explicitly trusted keys) make sense in this
context? Real world use case?
* Setting trust policy on a public key instead of a certificate
so that if the certificate changes for a key, policy remains.
* How useful is this given that a key can change just as easily?
If you're going to get a CA to sign a certificate, you can just
as easily (well usually) get them to sign it with a new public
* Or are we talking about anchors here?
* ie: does this solve a real world security problem?
Not strictly related to raw public keys:
* Is the goal to make stapled certificate extensions follow newly
issued certificates for the same entity?
* This would mean association with a subject DN. Which of course
raises all sorts of issues.
* Is this even solveable?
* We might choose to not have this as a design goal. The main use
case for locally stored policy is anchors (usually long lasting,
and a case where you don't want to automatically have trust follow
an entity), black lists (where it seems public keys are a clear
way to associate trust policy) and other configuration style
policy tweaks like pinned certificates.
Then one more below...
> For example, let's say i encounter a certificate with extension X
> (it doesn't have extension Y). If i pin new contents of extension
> X to the public key directly, and a new certificate (with extension
> Y) shows up using the same public key, then the new certificate
> will be evaluated in the context of extensions X and Y combined.
Which raises the question (for me at least):
If it makes sense to store trust policy associated the public key *of*
a certificate instead of the certificate itself (see question above),
then should stapled certificate extensions should always be associated
with a given public key, and never with a certificate directly?
Obviously this depends on the earlier questions.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)
Comment: Using GnuPG with undefined - http://www.enigmail.net/
-----END PGP SIGNATURE-----
More information about the p11-glue