-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
On Tuesday 16 January 2018 at 6:50:45 PM, in
, Andrew
Gallagher wrote:-
> Agreed. I was thinking more along the lines of having
> some method
> of causing signature vandalism to expire.
Perhaps this could be achieved by introducing a "certifica
Robert J. Hansen rjh at sixdemonbag.org wrote on
Tue Jan 16 17:42:29 CET 2018 :
...
>> The mechanism to prove you are the owner of a public key is pretty much
>> in place :-). A mechanism where you can have a signed statement saying
>> "on 2018-01-16, I allow my key to show up on keyservers"
>It i
On 01/16/2018 10:33 PM, Matthias Mansfeld wrote:
> On 16 Jan 2018 at 20:08, Kristian Fiskerstrand wrote:
>
>> On 01/16/2018 07:50 PM, Andrew Gallagher wrote:
>>> Agreed. I was thinking more along the lines of having some method of
>>> causing signature vandalism to expire.
>> They don't really con
On 16 Jan 2018 at 20:08, Kristian Fiskerstrand wrote:
> On 01/16/2018 07:50 PM, Andrew Gallagher wrote:
> > Agreed. I was thinking more along the lines of having some method of
> > causing signature vandalism to expire.
>
> They don't really constitute an issue either for security or privacy,
> t
Can anyone explain in the context of this discussion just what “public” in
“public key” is supposed to mean explicitly and implicitly?
James R. Cutler
james.cut...@consultant.com
PGP keys at http://pgp.mit.edu
___
Gnupg-users mailing list
Gnupg-users@g
On 01/16/2018 07:50 PM, Andrew Gallagher wrote:
> Agreed. I was thinking more along the lines of having some method of
> causing signature vandalism to expire.
They don't really constitute an issue either for security or privacy,
though. If looking at keyserver directly (which you really shouldn't
> On 16 Jan 2018, at 18:15, Kristian Fiskerstrand
> wrote:
>
>> On 01/16/2018 07:12 PM, Andrew Gallagher wrote:
>>> On 16/01/18 17:19, Leo Gaspard wrote:
>>> “on 2018-04-01, please expose only the master key and its revocation
>>> certificate(s) to clients”
>>
>> IF you wanted to go this route
On 01/16/2018 07:17 PM, Leo Gaspard wrote:
> That said, thanks for the link! Just curious, I never saw information
> about this in enigmail, do you know whether it has been implemented yet?
First and foremost you'd have to establish the robot-ca with an API of
some sort. I'm not aware of any produ
On 01/16/2018 06:33 PM, Kristian Fiskerstrand wrote:
> On 01/16/2018 06:19 PM, Leo Gaspard wrote:
>> Also, there are flaws with this approach (like after a private key
>> compromise, it would allow to prevent dissemination of the revocation
>> certificate) [1], but fixes like allowing the statement
On 01/16/2018 07:12 PM, Andrew Gallagher wrote:
> On 16/01/18 17:19, Leo Gaspard wrote:
>> “on 2018-04-01, please expose only the master key and its revocation
>> certificate(s) to clients”
>
> IF you wanted to go this route, it would be easier for keyservers to
> only serve the master key + revoc
On 16/01/18 17:19, Leo Gaspard wrote:
> “on 2018-04-01, please expose only the master key and its revocation
> certificate(s) to clients”
IF you wanted to go this route, it would be easier for keyservers to
only serve the master key + revocation cert for *all* cases where a
revocation cert exists.
On 16/01/18 17:19, Leo Gaspard wrote:
> Well, if such requests were honored, this would fix the OP's answer (ie.
> “how do I hide the fact I mistakenly associated two unrelated UIDs on my
> key”, if I understood correctly), as well as requests pertaining to the
> EU's “right to be forgotten”
The r
On 01/16/2018 06:19 PM, Leo Gaspard wrote:
> Also, there are flaws with this approach (like after a private key
> compromise, it would allow to prevent dissemination of the revocation
> certificate) [1], but fixes like allowing the statement to be “on
> 2018-04-01, please expose only the master key
ost their
private key and still claim this right, but I guess the extraordinary
measures taken for the last time it was invoked would still be possible).
So that's at least a good part of the current problem solved, I think --
though obviously nothing close to the nightmare scenario or
means to
> show how it would be access control rather than DRM.
I'd personally agree that the whole right to be forgotten EU is talking
about is a form of DRM, whereby they want individuals to be able to wipe
out any trace of their historical behavior after said behavior has been
publishe
On 16/01/18 17:42, Robert J. Hansen wrote:
> [...] what many people want is *enforcement*.
Now, /that/ would be DRM, I agree. I just considered "what
well-configured keyservers in the keyserver pool should do" as the
boundary of the problem statement. Just like a well-configured w
On 16/01/18 17:47, Kristian Fiskerstrand wrote:
> I'm somewhat interested in hearing how this scheme would work in the
> case of a compromised private key. Mainly;
I was merely using the description of the basics of it as a means to
show how it would be access control rather than D
On 01/16/2018 05:26 PM, Peter Lebbing wrote:
> A mechanism where you can have a signed statement saying
> "on 2018-01-16, I allow my key to show up on keyservers", and a signed
> statement saying "from 2018-04-01 on you should no longer expose this
> key to clients"
I'm somewhat interested in hear
> The mechanism to prove you are the owner of a public key is pretty much
> in place :-). A mechanism where you can have a signed statement saying
> "on 2018-01-16, I allow my key to show up on keyservers"
It is theoretically and practically possible to have a keyserver that
honors such requests,
;. That doesn't
mean that the GnuPG webserver is implementing DRM to prevent me to share
my own e-mail. It's basic access control when only the operator can
change the website, not DRM, and cryptography is used to facilitate the
access control.
The mechanism to prove you are the owner o
On Apr 12, 2010, at 2:33 PM, M.B.Jr. wrote:
> Hi,
> I have this simple question (sorry for it), regarding "digital rights
> management".
>
> As I understand, DRM in essence is the use of asymmetric cryptography,
> which turns simple public keys into not-publicly-avai
Hi,
I have this simple question (sorry for it), regarding "digital rights
management".
As I understand, DRM in essence is the use of asymmetric cryptography,
which turns simple public keys into not-publicly-available public
keys.
Is it correct?
Regards,
Marcio B
22 matches
Mail list logo
