-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On Fri, 15 Dec 2000, Dave Del Torto wrote:
If the intent is to allow a Alice to effectively Remove her public
key -- even if the keyserver's policy/software doesn't allow her to
Delete it -- then I think this is useful. Of course, this presumes
that Alice still retains her ability to modify the public key.
Of course.
However, if the intent is to "mask" the presence of Bob's key on the
keyserver in lieu of Deleting it, it's hard to see what sort of
keyserver response behaviour would prevent Eve from trying to
determine the presence of Bob's key on the server -- by deducing that
information using the very 0x40 flag you describe in conjunction with
the keyserver behaviour. This simply shifts the policy focus from the
pksd's delete policy to its search policy.
All Eve would need to do is upload the public component to the
keyserver in order to determine the status of the subpacket 23
enable/disable flags: if the key is present but disabled, it will
"vanish," confirming that it's disabled. If not present, it will be
returned by a subsequent search. A rudimentary traffic analysis
technique.
Where is the threat here? The reason I prefer a "disable" approach to a
"delete" approach is that deleted keys can always reappear. The behavior
you describe seems to me to be the appropriate one.
The big question of course, is "who can set these flags?" IMHO, they
musn't be outside the hashed subpackets: they need to be set by the
key-owner, lest they contribute to a DoS attack on any given public
key. This means that Alice or Bob could just as easily Revoke (or,
pksd policy permitting, Delete) their keypairs. If the keyserver
admmin is to be allowed to set the flag, this raises a serious key
management policy question, again just shifting the problem
elsewhere, but not solving it entirely.
Right, no one, not even the key server admin, would be able to set these
flags besides the key owner. I didn't feel that needed stating, since
these flags are an addition to an existing subpacket which is already only
found in self-signatures.
They MUST NOT be placed outside the hashed area.
- --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.
iD8DBQE6Op9fPYrxsgmsCmoRAvRKAKCsxYv996YOGDSAqWyAa+iSuJltqgCg+wn8
F54h58lhEm9yYUcvEAuiHAY=
=/A05
-----END PGP SIGNATURE-----