-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On 4 Dec 2000, lcs Mixmaster Remailer wrote:
> Examples of the first case would be an identifier which indicates the
> signing key. In PGP this would be the key ID; in SMIME, CMS and other
> PKCS-7 derived formats it is the IssuerAndSerialNumber. These fields
> are not hashed. This is not security critical because it is essentially
> a hint about where to find the key. If this data is altered, the wrong
> key will be found and the signature won't verify.
Agreed. This is the main exception I pointed out to Ralf, and these are
the reasons I gave him in my private email to him.
> Examples of the second case would be other kinds of hints for finding the
> signing key, in the form of URLs or database pointers which might change.
> PGP's preferred key server subpacket might fall into this category.
I'm hesitant to put this outside the hashed area. The preferred key server
is a preference stated by the key owner; he should be the only one able
to change that.
> PGP might want to add a countersignature mechanism in the future and an
> unhashed subpacket would be a good place for it.
I'm not against unhashed subpackets. I'm against unhashed
security-critical subpackets. I would think that the best way to design a
program interpreting certificates with such packets would be to have a
"whitelist" of subpackets permitted outside the hashed area. Anything not
in this whitelist should be rejected or ignored.
- --Len.
__
L. Sassaman
Security Architect | "The world's gone crazy,
Technology Consultant | and it makes no sense..."
|
http://sion.quickie.net | --Sting
-----BEGIN PGP SIGNATURE-----
Comment: OpenPGP Encrypted Email Preferred.
iD8DBQE6LCvtPYrxsgmsCmoRAhkKAJ42qvI3uMksU0VkQgVkO14ZkAtPpQCg7pUN
zJeRhi/+IXcqSDalM9MSLiE=
=wOQl
-----END PGP SIGNATURE-----
