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
>
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
>
> ___
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
https://lists.nongnu.org/mailman/l
> 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
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 use
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 rejec
> 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 reje
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 hinder
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 cryp
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 cert
> Some quick thoughts:
>
> - interesting idea,
> - to do this keyservers will have to actually do cryptography
This is the only problem I think.
But it is not too serious.
A server has to verify a signature once in a key's lifetime.
> - how does one propagates a "nokeyserver" annotation on a key
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 certificate.
>
> I'm not sure how, could you quickly describe the scenario you have in
> mind?
If any third party
> 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
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 accidental uploads of
the key
On 12/20/2016 07:18 PM, Vincent Breitmoser wrote:
>> - 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. It's impossible to
> attach those to another person's key, and
> 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
> - 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. It's impossible to
attach those to another person's key, and that's the only attack
scenario I can see.
> - how doe
Hi!
Kim Minh Kaplan writes:
> Daniel Kahn Gillmor wrote:
>> I'd like the keyservers to reject keys with any self-sigs with the
>> "nokeyserver" notation. The novel thing is that this notation doesn't
>> exist yet :)
> - how does one propagates a "nokeyserver" annotation on a key in the
> SKS
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:
>
>
> https://bitbucket.org/skskeyserver/sks-keyserver/pull-reques
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:
https://bitbucket.org/skskeyserver/sks-keyserver/pull-request/20/trim-loca
20 matches
Mail list logo