[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: theory (was Re: Back-signatures proposal)
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
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
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
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 
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
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
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..
 Understanding PKI, 2nd Ed., Carlisle Adams and Steve Lloyd