sks-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Sks-devel] SKS peering request [sks-server.randala.com]


From: Martin Papik
Subject: Re: [Sks-devel] SKS peering request [sks-server.randala.com]
Date: Wed, 09 Apr 2014 03:36:24 +0300
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.4.0

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

Dear Kristian

Thank you for your response.

>> Second, with 1.1.3, are ECC signatures lost? Meaning if someone 
>> queries my server running 1.1.3 for a key containing an ECC 
>> signature, will only the one signature be missing or will there
>> be problems syncing any further signatures?
> 
> For signatures the ECC signature will be gone by default, or an
> error will be shown for a primary ECC key. The keys will
> synchronize and the full key can be gotten from a 1.1.3 server
> using &clean=off option that disable the presentation filter.
> You'll find some details on number of ECC (primary) keys at [2]

So all the keys will be in the database on a 1.1.3 server, but
searching for ECC keys will fail with an error, and ECC signatures
will be omitted due to the filter which can be disabled with
clean=off. Did I understand you correctly? In which case, a 1.1.4
server that is only peering with a single 1.1.3 server which peers
with the networ will get all the keys and return correct results. Is
that true? Will a dump on a 1.1.3 contain the ECC key material?

>> I.e. will the whole key be lost, the ECC signatures only, or any 
>> signature after the first ECC signature is added? Another
>> question that occurs to me is, how many ECC signatures are
>> actually in the wild? Are many users affected? If so, I wonder if
>> the logic that selects my server for inclusion in the pool is
>> doing the right thing. Mine isn't the only 1.1.3 server included.
>> So I wonder.
> 
> ECC safe pool is the subset pool c.f. [0]. The 1.1.3 requirement
> is set mainly due to subkey safe searching. This will be bumped to
> 1.1.5 once released.

Which requirement is this? For the ECC-safe pool? Because otherwise
this seems to contradict the next paragraph.

> 1.1.3 should be reasonably safe (in the meaning I don't have any 
> immediate plans to discard it form the pool), however do note that 
> 1.1.4 was released in October 2012[1].

>>> I believe that Kristian is currently trying to coordinate 
>>> getting some final changes in before a 1.1.5 release which
>>> will have enough cleanups and improvements in ECC and web
>>> security areas that it should be considered a "really really
>>> should upgrade" release.
> 
> It would have its set of improvements, indeed. And you're correct
> in that I'm in favor of a new release soon, although I must state
> the disclaimer that we haven't decided on this in the team yet.

Do you have a time frame in mind?

Are the planned improvements documented somewhere? Are they in the
repository in the TODO file?

Is the repository always the latest version?

Is the repository always safe to run? I mean, can the head always be
safely deployed to be part of the public network?

PS, sorry if my questions are tedious, but I'm new to sks so there's a
lot that's not clear to me and I would like to make sure I don't
misunderstand something. I hope it's okay.

Martin
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQIcBAEBCgAGBQJTRJX7AAoJELsEaSRwbVYrqvkP/Rov7oiy2Jssq0TxD6KzHUeJ
R7GlqFJpY9U0eSfPiekKwNLMLYGhfOjLaaMUR/tCY0Bj61Hzlefb8YcAE+A+xM4W
VYyMRN6kG1lFWM0K+e4+USlNu3tL2yqgxveYKhdLDn3n2Tih49QItNpuy/cqujPh
Cl+I109Nok+kZJsDsC1TcPzNA7ElM7wIjstIK7Vz830jXVIdMpQIElo33vYamgp4
PWArv5n8nTSWdPtLQS3qftPzT76TdjB89lasfJc/3Xudl+/TbOGUcPdRoTLUU+Ya
1HyumOm4br6ecuqa2cjHGYvZ2zti1qcwnjoPuU3/Eby6ei6pSF2BzeADcizbNDG2
WD3bcFKBfcGff4YLbktjUYn1MrTyf8m3vs7ZoQFlAYngz7yqLgx9wOELjfET1Ari
qaAUO89y2zYBwfyJpuTyreAGtu47y2/4fdDm8R50JHkwezV/pzPUgPiZIPhhKVR5
meT4Y07LHerBR5EoRg55L/Y/JFBZ4vSGcP6dZFBoPmNLhsZvp/TfGLe5VAobZfxj
O1Yo9t03isA0TMrdGWLpmrZRIMPnzfxsSbG7Dyk0bEU4cS6adD3lIjfiMwiJvdfC
7rBqoRVLwqO3lcXDb02csn+nsZylNNe0BALIK1VQjSyniZcyvOL4GUTfD0vSGu9T
wUlQM+mU2MCG0K45wCcs
=UC66
-----END PGP SIGNATURE-----



reply via email to

[Prev in Thread] Current Thread [Next in Thread]