ietf-openpgp
[Top] [All Lists]

Re: theory (was Re: Back-signatures proposal)

2003-10-31 13:14:00

At 08:44 AM 10/31/2003 -0800, Carl Ellison wrote:

[...]
For example, the thing granting power might be a patent application. How would this grant power to a key?

Suppose I download the patent application from USPTO's site, over a secure link.

I notice the patent has a signature on it, and I know the USPTO is in the habit of signing pending applications with its own key.

I go to a PGP key server and find a key claiming to belong to USPTO. I use it to verify the application. Since it verifies, I jump to the conclusion that the key belongs to the USPTO.

This conclusion is unwarranted and dangerous, as things stand - just cause a key verifies a signature, doesn't mean the key made the signature.

However, if the signed application contained the key or its hash anywhere, then I *could* use the application to "authenticate" the key.

The odd thing is the key or its hash doesn't need to be inside the signature, just attached to the document somewhere, since the only meaningful attack here is one performed by an attacker who can't modify the document - such an active attacker could just re-sign the document himself.

Or is that true? I'm not sure. Is it possible that an attacker would be able to fiddle the key hash but not actually re-sign the document? Perhaps not, but it seems safest to put the key-hash inside the signature, just in case.

Anyways, if this was done, then users who make the naive assumption that if a key verifies a signature, it must have made the signature, would be safe.


--- (stray thought, not related to PGP) ---

There's another use for including extra "context" in a signature. I think this use is more important in general, but less important in the particular case of PGP subkeys. But I summarize it here cause it's theoretically interesting.

This use is to include extra context in a signature so as to differentiate between multiple instances of the same key.

For example, I believe an SPKI signature covers the subject certificate only, not the issuer's certificate. Thus if an issuer has multiple certificates containing the same key, a subject can "re-root" itself under whichever of the issuer's certificates is most to its (the subject's) liking.

For example: suppose an issuer certificate is revoked, and the issuer receives a new certificate for the same key. You might assume all certificates issued under the revoked certificate are also revoked, but you'd be wrong: the holders of these certificates could re-root themselves under the issuer's new certificate.

Similar things are possible in X.509, which is why a recent book on PKI [1] recommends against re-using keys:

"There is a more compelling reason not to put a single public key in multiple certificates, however: It is too easy to "slip up" and not hold all other important aspects of these multiple certificates constant.[...] Such situations may allow an attacker (or even an underhanded certificate subject) to substitute one certificate for another so that what was once merely a signed piece of data now takes on an entirely new meaning. Mandating that different certificates always contain different public keys is a simple way to entirely preclude the risk of such substitution attacks."

I dislike that mandate, since there are good reasons for re-using keys (limited key storage, the expense of key generation, etc..). Instead, I think it would be preferable if every signature covers all relevant context needed to differentiate the signing key from the same key used in a different certificate.

Granted, in PGP subkeys this may not be worth doing. But at the "theory" level, this seems a good principle for certificate formats.

I'm curious if you agree with that (I suspect you don't, or SPKI would be different :-). This is wandering off-topic, though, I know..

Trevor

[1] Understanding PKI, 2nd Ed., Carlisle Adams and Steve Lloyd

<Prev in Thread] Current Thread [Next in Thread>