stapling extensions to public keys instead of certificates? [was: Re: Sharing Trust Policy between Crypto Libraries]

[Stef Walter]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

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
      key.
    * 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.

Cheers,

Stef

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)
Comment: Using GnuPG with undefined - http://www.enigmail.net/

iEYEARECAAYFAlDmBfkACgkQe/sRCNknZa+gowCgoEa316322CWf9MgoADOEUm6I
9mEAoLzIGvUA28c2lMVZFENIm07yHWAh
=2QVu
-----END PGP SIGNATURE-----