multiple subkeys and key transition

Ben McGinnes ben at adversary.org
Thu Dec 9 22:01:09 CET 2010


On 10/12/10 7:48 AM, Daniel Kahn Gillmor wrote:
> On 12/09/2010 03:09 PM, Ben McGinnes wrote:
> 
>> Is this why a revoked key can still be used to decrypt data that was
>> encrypted with a non-revoked copy of the key?
> 
> the things that get revoked are OpenPGP certificates.  the certificates
> themselves contain key material.  The math that makes the key material
> effective for encryption, decryption, signing, or verification doesn't
> know or care about the revocation of the certificates.
> 
> We *interpret* those revocations to give us some reasonable real-world
> guidance about whether to rely on a given key for encryption, signature
> verification, or authentication.  But the underlying asymmetric crypto
> operations will continue to work regardless of whether the certificates
> are revoked.

Ah, thankyou very much.  I think this is the clearest explanation of
the process and why it behaves the way it does that I've seen
anywhere.

>>> even need a new version of the entire spec, it would just be an update
>>> to the spec, claiming a new subpacket type from IANA.  And an example
>>> implementation in a popular tool like GnuPG wouldn't hurt either, of
>>> course. :)
>>
>> Why do I get the feeling that this bit is addressed to Werner ...  ;)
> 
> It was addressed to anyone who wants to implement it, actually.  Anyone
> looking to cut their teeth on this kind of stuff could pick this up as a
> reasonable project.

Cool.  My C knowledge is, ah, rudimentary so I'll have to wait for a
guru to look into it.

> Here's a previous discussion to get you started:
> 
>   http://www.imc.org/ietf-openpgp/mail-archive/msg06733.html
> 
> hth,

Very much so, thanks again.  :)


Regards,
Ben

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 227 bytes
Desc: OpenPGP digital signature
URL: </pipermail/attachments/20101210/01c6cffe/attachment.pgp>


More information about the Gnupg-users mailing list