Re: [Sks-devel] nokeyserver annotation

No? :( - V Vincent Breitmoser(look@my.amazin.horse)@Fri, Jan 27, 2017 at 12:43:56AM +0100: > Pretty please? :) > > - V > > Vincent Breitmoser(look@my.amazin.horse)@Thu, Jan 19, 2017 at 03:34:12AM > +0100: > > Ping? :) > > > > This thread sort of died down, but I'd like to know if this is >

Re: [Sks-devel] nokeyserver annotation

Pretty please? :) - V Vincent Breitmoser(look@my.amazin.horse)@Thu, Jan 19, 2017 at 03:34:12AM +0100: > Ping? :) > > This thread sort of died down, but I'd like to know if this is > conceptually acceptable and would have a chance of being accepted if > someone implemented it. > > - V > >

Re: [Sks-devel] nokeyserver annotation

Ping? :) This thread sort of died down, but I'd like to know if this is conceptually acceptable and would have a chance of being accepted if someone implemented it. - V ___ Sks-devel mailing list Sks-devel@nongnu.org

Re: [Sks-devel] nokeyserver annotation

> An invalid notation might not be rejected by a client (is it critical > marked?). Is there a reference for this behavior in RFC and tested on > various implementations? I still don't understand. It's not the notation that is invalid, it's the certificate itself. It's my key, as long as we don't

Re: [Sks-devel] nokeyserver annotation

I think I am beginning to understand more clearly what you are proposing now. Thank you for the description. It does look neat, especially as it does not require cryptography on the server. The thing that worries me is that "Subpackets that appear in a certification self-signature apply to the

Re: [Sks-devel] nokeyserver annotation

On 12/20/2016 07:58 PM, Vincent Breitmoser wrote: >> If you can trick a user into importing a package that hinders >> distribution of the keyblock > > This should be prevented by client implementations, why would they ever > import a non-verifying self-cert? An invalid notation might not be

Re: [Sks-devel] nokeyserver annotation

> If you can trick a user into importing a package that hinders > distribution of the keyblock This should be prevented by client implementations, why would they ever import a non-verifying self-cert? > believes it gets uploaded to keyserver with the modified packet but at > that point it is

Re: [Sks-devel] nokeyserver annotation

On 12/20/2016 07:41 PM, Daniel Kahn Gillmor wrote: > scenario (a) doesn't matter -- the keyservers simply won't propagate > that modified cert, which is fine, because it's not actually Alice's > self-sig anyway. How wouldn't this matter? If you can trick a user into importing a package that

Re: [Sks-devel] nokeyserver annotation

On Tue 2016-12-20 12:24:56 -0500, Kim Minh Kaplan wrote: > - to do this keyservers will have to actually do cryptography I think i disagree here. The keyservers currently don't validate anything, and i don't see how this proposal would change things. The two "attack" scenarios i can imagine

Re: [Sks-devel] nokeyserver annotation

Kristian Fiskerstrand(kristian.fiskerstr...@sumptuouscapital.com)@Tue, Dec 20, 2016 at 07:31:35PM +0100: > On 12/20/2016 07:29 PM, Vincent Breitmoser wrote: > >> Without verifying the signature this opens up for a DoS on users > >> expecting to distribute the keys, e.g in case of a revocation

Re: [Sks-devel] nokeyserver annotation

> Without verifying the signature this opens up for a DoS on users > expecting to distribute the keys, e.g in case of a revocation certificate. I'm not sure how, could you quickly describe the scenario you have in mind? - V ___ Sks-devel mailing list

Re: [Sks-devel] nokeyserver annotation

Vincent Breitmoser writes: >> - to do this keyservers will have to actually do cryptography > > Are you sure? I don't think there's any attack scenario here: If any > such signature exists, you can't upload the key. You can strip that signature. If you only consider

Re: [Sks-devel] nokeyserver annotation

> Assuming the intention is tagging my key (which hasn't been published so > far) so it doesn't end up on the keyserver. In that case *all* self-sigs > would need to carry the notation as otherwise an intruder could just > remove the newest nokeyserver selfsig and still have a valid key (iff > all

Re: [Sks-devel] nokeyserver annotation

Daniel Kahn Gillmor wrote: > i've been trying to make it possible for key to state that > it should be excluded from some keyservers, but those attempts to fix > things have failed thus far due to filter synchronization issues: > > >

[Sks-devel] nokeyserver annotation

hi folks-- as you know, i've been trying to make it possible for key to state that it should be excluded from some keyservers, but those attempts to fix things have failed thus far due to filter synchronization issues: