[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Sks-devel] Re: Delete key from keyserver
From: |
Jeff Johnson |
Subject: |
Re: [Sks-devel] Re: Delete key from keyserver |
Date: |
Wed, 08 Sep 2010 11:29:23 -0400 |
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
- Re: [Sks-devel] Re: Delete key from keyserver, (continued)
- Re: [Sks-devel] Re: Delete key from keyserver, Jeff Johnson, 2010/09/07
- Re: [Sks-devel] Re: Delete key from keyserver, Yaron Minsky, 2010/09/07
- Re: [Sks-devel] Re: Delete key from keyserver, news, 2010/09/08
- Re: [Sks-devel] Re: Delete key from keyserver, news, 2010/09/08
- Re: [Sks-devel] Re: Delete key from keyserver, Yaron Minsky, 2010/09/08
- Re: [Sks-devel] Re: Delete key from keyserver, Kiss Gabor (Bitman), 2010/09/08
- Re: [Sks-devel] Re: Delete key from keyserver, Johan van Selst, 2010/09/08
- Re: [Sks-devel] Re: Delete key from keyserver, Alexander B. Schmidt, 2010/09/08
- Re: [Sks-devel] Re: Delete key from keyserver, Jeff Johnson, 2010/09/08
- Re: [Sks-devel] Re: Delete key from keyserver, Jeff Johnson, 2010/09/08
- Re: [Sks-devel] Re: Delete key from keyserver,
Jeff Johnson <=
Re: [Sks-devel] Re: Delete key from keyserver, Robert J. Hansen, 2010/09/07
Fw: [Sks-devel] Re: Delete key from keyserver, Kristian Fiskerstrand, 2010/09/08
Re: [Sks-devel] Re: Delete key from keyserver, news, 2010/09/08