Re: [Sks-devel] Re: Delete key from keyserver

[Jeff Johnson]

On Sep 8, 2010, at 9:38 AM, Jeff Johnson wrote:

> 
> Expiries and revocations are permitted on SKS servers because there is 
> already a trusted introducer.
> If a "pseudo-key deletion token" key could be represented as an additional 
> form (like
> a key with no user id, only self certifications and revocations/expiry) and 
> or an explicit
> attribute that controls the "owner" preference to "delete"), then the only 
> additional
> implementation on servers would be to recognize that key as a "deletion" token
> and perform a deletion.
> 
> I'll call the key-with-revocation-and-attribute I just described a "anonymous 
> self-revocation"
> for short.
> 

I misspoke re "self-certification" above because that involves a signature
binding a userid (which MUST be discarded) to the pubkey packet and
that is at odds with the "anonymous" part of a "anonymous self-revocation".

In fact, all certification signatures have the pubkey+userid as plaintext
and would need to be dropped (from memory).

But I have RFC 4880 in the browser and here are the gory details that I
suggest for a "pseudo-key deletion token" representation. If using a
"anonymous self-revocation" looks like an acceptable representation
for a "pseudo-key deletion token", I can generate up sufficient instances
to achieve test coverage.

Pubkeys first, then subkeys, cross ref'd to RFC 4880 (ignoring V3 signatures 
for simplicity).

An "anonymous self-revocation" key/token on the pubkey would contain these tags:

    5.5.1.1 Public-Key Packet (Tag 6) as always, needed for fingerprint
    5.2.3     V4 Signature Packet (Tag 2) containing the revocation

Good: The pubkey revocation signature needs only the pubkey packet as plaintext 
(I wasn't sure
how the plaintext was defined is the reason for the gory details).

There is also
    5.2.3.23 Reason for Revocation
that likely could be easily extended with a "deleted" marker. There are likely 
other ways to
achieve an explicit "deleted" marker too.

Now subkeys (where I have far less experience, please correct me if I get
some detail wrong).

The details of subkey revocation are in RFC 4880 5.2.3.3.

So to revoke a subkey, one revokes the subkey binding signature.

The plaintext for the subkey binding signature is as follows'
    5.5.1.1 Public-Key Packet (Tag 6) as always, needed for fingerprint
    5.5.1.2 Public-Subkey Packet (Tag 14)

Good: no userid in plaintext here either.

So the "deleted" subkey revocation would need
    5.2.3   V4 Signature packet (Tag 2) containing the subkey binding signature
    5.2.3   V4 Signature packet (Tag 2) containing the subkey revocation 
signature.

(Hmmm: dunno what the plaintext is for the subkey revocation signature, never 
tried).

(Hmmm: there's also some notion of a "authorized revocation key" that likely 
needs to be worried about).

FInally encryption keys (which I've never ever looked at) but is presumably 
parallel to
subkeys with a 5.5.3 Secret-Key Packet instead.

So it looks feasible (to me) to represent an "anonymous self-revocation" within 
RFC 4880 packets.

I cannot speak to whether a "anonymous self-revocation" is a wise approach 
however; I just needed
to check if the engineering was possible to generate an "anonymous" revocation 
that could
be distributed just like any other key materiel.

If using a "anonymous self-revocation" looks like an acceptable representation
for a "pseudo-key deletion token", I can generate up sufficient random instances
to achieve test coverage. I can also upload the test cases to a key server if 
desired.
Next would be to start looking at doing a replacement (rather than
a merge) within the SKS OCAML code down the road a bit.

Do the above details describing a way to represent a "pseudo-key deletion token"
in RFC-4880 packets sound like a workable approach to "deleting" (by 
anonymizing)
a key?

hth

73 de Jeff