Re: [Sks-devel] SKS should not accept or replay non-exportable certifications

[John Clizbe]

Daniel Kahn Gillmor wrote:
> On 09/14/2013 05:00 PM, Robert J. Hansen wrote:
> [dkg wrote]:
>>> > I have told numerous people that the keyserver network will not 
>>> > propagate local signatures.
>>
>> This is true.
> 
> No, unfortunately, it is not true in any way for SKS 1.1.4 (and probably
> earlier versions, though i have not tested).  In its current form, SKS
> both accepts and transmits (including via standard gossip) *all*
> non-exportable certifications.re is no other option

Careful here. Gossip is referring to recon and there is no other option in
recon. Keys are just blobs of bits with a hash value.  We can control what we
accept, to try and make it conform to RFC 4880, et alia,... as much as
possible, and we can control what is delivered by the server by cleaning and
or filtering. The second is a dangerous approach because we are then
controlling what is delivered, i.e., we're censoring. I think the task of
verifying what is acceptable after a key is requested is probably best left to
the client OpenPGP implementations.

> I'd love to be wrong about this, but I've tested it and I'm reporting my
> observations.  If you have conducted other experiments or made other 
> observations that contradict this, I would love to hear about them,
> specifically.

As I see it, we have two related problems here, both involving the no-export
signature flag:

1) Dan signs John's key with lsign and then keyserver/export options with
export-local-sigs and sends the key with local-sigs to the keyserver network
where the lsigs are accepted. This is clearly an error and these sigs should
be removed when a key is submitted containing them. On a get, we have to make
the call, do we enforce or put it on the client. I leave that for discussion.

2) JimBob lsigns his own key, creating a non-exportable selfsig then delsigs
all of the exportable selfsigs.  This is shooting oneself in the foot. If we
honor no-export on a selfsig, we create keys with UIDs that have no binding
signature. THIS IS VERY VERY BAD. I think the RFC folks should probably have
been more explicit on this case, but to be fair, it's probably a use case they
did not anticipate.

My compromise suggestion of trying to DTRT but with minimum harm is in the
case of 1, where signing key != signed key, strip the non-exportable sig
before we import into the key store.

In the case of 2, where signing key == signed key (lsign your own key) we have
a user either intentionally or accidentally shooting himself in the crypto
foot. We can a) hold our noses and accept the key, or b) reject the entire key
as malformed -- there is no way to honor the no-export sig flag and still have
a valid key.

Another possibility is that if there are earlier or later exportable
selfsig(s), just strip the errant selfsig with the no-export flag.


$0.02 -- keep the change.  Discuss.

-John
-- 
John P. Clizbe                      Inet: John (a) Gingerbear DAWT net
SKS/Enigmail/PGP-EKP                  or: John ( @ ) Enigmail DAWT net
FSF Assoc #995 / FSFE Fellow #1797  hkp://keyserver.gingerbear.net  or
     mailto:address@hidden

Q:"Just how do the residents of Haiku, Hawai'i hold conversations?"
A:"An odd melody / island voices on the winds / surplus of vowels"

signature.asc
Description: OpenPGP digital signature