Re: DRM?

[MFPA]

-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 "certification
acceptance signature" calculated over a certification that you were
happy to keep on your key?


- --
Best regards

MFPA  

Wait. You think I'm right?
-BEGIN PGP SIGNATURE-

iNUEARYKAH0WIQSWDIYo1ZL/jN6LsL/g4t7h1sju+gUCWmE90V8UgAAuAChp
c3N1ZXItZnByQG5vdGF0aW9ucy5vcGVucGdwLmZpZnRoaG9yc2VtYW4ubmV0OTYw
Qzg2MjhENTkyRkY4Q0RFOEJCMEJGRTBFMkRFRTFENkM4RUVGQQAKCRDg4t7h1sju
+hqVAQDaLYjl+DH/MMkM5b8XAvR82SMIqzdGYvqnZNIdimLbFQD/Vg7WIlGxktC1
SzxDJkIawQ9T4nCHCJNZbO3/EWEppwaJApMEAQEKAH0WIQRSX6konxd5jbM7JygT
DfUWES/A/wUCWmE90l8UgAAuAChpc3N1ZXItZnByQG5vdGF0aW9ucy5vcGVu
cGdwLmZpZnRoaG9yc2VtYW4ubmV0NTI1RkE5Mjg5RjE3Nzk4REIzM0IyNzI4MTMw
REY1MTYxMTJGQzBGRgAKCRATDfUWES/A/9G1D/9JMe2exEnkEZr3kZqtjuVUOkwD
+5EeEyEQ0yX1j6haOQ8ErHuuV1QNjU+QpZfFUsyXQijkBitSdQyuKXMOlObWvFMj
WtGPQNqIjRq170T1Psf/+ug7NFmXEuqvpJCytiQHfq3GuybHfy3EeCdy98b2oEWc
T94h4KDUhDZ3ArjmMzQQqtJBDVGxtHaRo/lWisOi7GlMDDbIqF7XdRHqgRIuPwF5
vtwSHDXGfPyeCpyHMadYXTNsX3y8hlhVRQdnGbD5hMNpdxLvfCFvFZSZpBWQY7el
tGQad4vsLHkSKZ5dtYnjm8A0U82VNquEVLytKuoAx4jqETiqPBNL9cwVmhRGTHGC
0r/wDEK5pyDHphvbpjt94KfoA2Dyz90zcqVSachwTOTC4u+BdtwRjZ//7m6M/dkr
Z64UQMnu0lIYkD3tvH7wNE6CcfBnSM6mcZO7H8KleIYsgwdc8sB2p0ogq6ezi06C
95xNCnsEg/vMH54vK54N++tvq09psst9wOTosfwktdCqNrHuYDUA2HDrH/O+kTZ4
X3WBl5kbn97bNnpS78gu+CZK9aohvS7s8ON/elIwlUZJILD8u0oCgNHLRn0r9W9G
NMe0ItPnoLlXarIl/RI4KMNNagPKmcnW2d50+ZFatQ/WHwibvZpo9vKr+0fuTVM/
O9wgKMtNvRQOPKOqBw==
=VyAk
-END PGP SIGNATURE-


___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

DRM

[vedaal]

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 is theoretically and practically possible to have a keyserver that
>honors such requests, but what many people want is *enforcement*.  Not
>merely a voluntary system that's trivially circumventable, but some
>mechanism by which their public keys can be actively kept out of
>circulation.

=

It could be done automatically by the keyservers if they wanted to,
and if they made it that *the only way* a Public key can be uploaded to that 
keyserver,
if it were accompanied by a signed statement by that key,  stating " I allow my 
key to show up on keyservers".

Ideally, if this could be done by gnupg by editing the key, much the same as 
editing an e-mail address, it would streamline the process;

i.e. something like this:

gpg --edit-key foo
...
Secret key is available.
...
[ultimate] (1). foo 

gpg> --allow-keyserver-publication

gpg: This requires you to sign that you allow keyserver publication of your 
key, and will be added as a comment to your key.
Do you really want to do this?  Y/N

gpg: Please enter passphrase to sign

gpg;  your key now has a comment  "Keyserver Publication Allowed"

gpg: you may upload this key to any participating keyserver


or something along those lines, assuming that keyservers will abide by this and 
require this 'comment' before accepting a key 


vedaal




___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: DRM?

[Kristian Fiskerstrand]

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 constitute an issue either for security or privacy,
>> though. 
> They DO, if unwanted or rashly made signatures on pubkeys disclose 
> connections between people, groups etc..

by "vandalism", I'm taking trollwot cases into account, which doesn't
affect anything to the extent it is DoS-able.

-- 

Kristian Fiskerstrand
Blog: https://blog.sumptuouscapital.com
Twitter: @krifisk

Public OpenPGP keyblock at hkp://pool.sks-keyservers.net
fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3

"Happiness in intelligent people is the rarest thing I know."
(Ernest Hemingway)



signature.asc
Description: OpenPGP digital signature
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: DRM?

[Matthias Mansfeld]

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,
> though. 

They DO, if unwanted or rashly made signatures on pubkeys disclose 
connections between people, groups etc..

Regards
Matthias
--
OpenPGP: http://www.mansfeld-elektronik.de/gnupgkey/mansfeld.asc
Fingerprint: 6563 057D E6B8 9105 1CE4 18D0 4056 1F54 8B59 40EF


___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: DRM?

[James R Cutler]

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@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: DRM?

[Kristian Fiskerstrand]

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 do,
your client will filter unknown keys and actually verify the rest) you
will see all kinds of interesting things like the Christmas present of
["funny sks"] on my keyblock some years ago. But it doesn't constitute
an *issue* when OpenPGP is used correctly.

References:
["funny sks"]
https://sks-keyservers.net/pks/lookup?op=vindex&search=0x94CBAFDD30345109561835AA0B7F8B60E3EDFAE3
-- 

Kristian Fiskerstrand
Blog: https://blog.sumptuouscapital.com
Twitter: @krifisk

Public OpenPGP keyblock at hkp://pool.sks-keyservers.net
fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3

"A committee is a group that keeps minutes and loses hours."
(Milton Berle)



signature.asc
Description: OpenPGP digital signature
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: DRM?

[Andrew Gallagher]

> 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, it would be easier for keyservers to
>> only serve the master key + revocation cert for *all* cases where a
>> revocation cert exists. What does it matter who signed a key that has
>> been revoked, or what IDs it used to be tied to? It's dead, throw it away.
> 
> The important thing would actually be that the data is retained in the
> database, as that wouldn't break sync.

Yes, absolutely. This would be a presentational fix. It would also be a method 
of giving people a way around right to be forgotten - revoke your cert and your 
info becomes more or less unsearchable. 

> this is within the scope of feasibility,
> although wouldn't do anything one way or the other with regards to
> security. Whether it would help privacy is also a questionable matter,
> as the full data store is downloadable, so anyone can download it
> containing the data wanting to be hidden.

Agreed. I was thinking more along the lines of having some method of causing 
signature vandalism to expire.  

A

___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: DRM?

[Kristian Fiskerstrand]

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 production rollout, although I believe a
proof of concept was written based on it for a thesis.

-- 

Kristian Fiskerstrand
Blog: https://blog.sumptuouscapital.com
Twitter: @krifisk

Public OpenPGP keyblock at hkp://pool.sks-keyservers.net
fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3

"A government that robs Peter to pay Paul can always depend on the
support of Paul."
(George Bernard Shaw)



signature.asc
Description: OpenPGP digital signature
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: DRM?

[Leo Gaspard]

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 to be “on
>> 2018-04-01, please expose only the master key and its revocation
>> certificate(s) to clients” would likely handle this particular issue.
>>
>> All I'm saying is that a system like this one is not a silver bullet
>> solution, but may handle a few of the current complaints against the SKS
>> network?
> 
> Not really (and that is ignoring disagreement with the complaints to
> begin with).
> 
> One issue with the first statement "please allow to be on keyserver" is
> that it doesn't provide any verification that the email in UID (or just
> the name) is accurate, so most of the complains regarding occurrence of
> multiple matches for a search would not be honored, as you could anyways
> create multiple keyblocks with this property.

Hmm, I was thinking only about de-listing information someone
inadvertently made public, not about having the keyservers become CAs
(which I don't think should happen, even though from a UI perspective
it's easier when things are centralized). I must say I basically took
only the “please delist me” signature packet into account in my answer,
not the “please list me”, as I don't think it would bring large
improvements.

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?

___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: DRM?

[Kristian Fiskerstrand]

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 + revocation cert for *all* cases where a
> revocation cert exists. What does it matter who signed a key that has
> been revoked, or what IDs it used to be tied to? It's dead, throw it away.

The important thing would actually be that the data is retained in the
database, as that wouldn't break sync. Aside from that the keyservers
would have to implement cryptography and verify that the revocation
certificate is accurate, this is within the scope of feasibility,
although wouldn't do anything one way or the other with regards to
security. Whether it would help privacy is also a questionable matter,
as the full data store is downloadable, so anyone can download it
containing the data wanting to be hidden.

-- 

Kristian Fiskerstrand
Blog: https://blog.sumptuouscapital.com
Twitter: @krifisk

Public OpenPGP keyblock at hkp://pool.sks-keyservers.net
fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3

"By three methods we may learn wisdom: First, by reflection, which is
noblest; Second, by imitation, which is easiest; and third by
experience, which is the bitterest."
(Confucius)



signature.asc
Description: OpenPGP digital signature
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: DRM?

[Andrew Gallagher]

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. What does it matter who signed a key that has
been revoked, or what IDs it used to be tied to? It's dead, throw it away.

-- 
Andrew Gallagher



signature.asc
Description: OpenPGP digital signature
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: DRM?

[Andrew Gallagher]

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 right to be forgotten is not absolute. For example, it does not
require that published news be unpublished, although it does sometimes
ask that published news not show up in search results. It also does not
require that search engine operators scrub their internal databases.

It is technically difficult to prevent keys from being propagated
because altering or deleting data packets breaks the assumptions upon
which the reconciliation algorithm is founded. But there is nothing to
stop individual servers from scrubbing search results of keys that have
a valid "nopublish cert" (however this may be technically implemented).
This would not affect SKS reconciliation and would reduce the
computational overhead.

IF something like this were to be implemented, then only searches for
IDs should be stripped. Searches on fingerprints should always return
data, in order to ensure that revocation certificates are still
distributed. "Nopublish" certs could also be used by well-behaved
clients as a guard against accidental disclosure, even if preventing
malicious disclosure is technically impossible.

If we were worried about the *legal* implications of right to be
forgotten, then this could be a defensible fallback position. But it is
not a solution to many of the *practical* problems in privacy protection.

Ultimately, the PGP ecosystem prioritises security over privacy. They
are not the same thing, and in some cases they are in conflict.

-- 
Andrew Gallagher



signature.asc
Description: OpenPGP digital signature
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: DRM?

[Kristian Fiskerstrand]

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 and its revocation
> certificate(s) to clients” would likely handle this particular issue.
> 
> All I'm saying is that a system like this one is not a silver bullet
> solution, but may handle a few of the current complaints against the SKS
> network?

Not really (and that is ignoring disagreement with the complaints to
begin with).

One issue with the first statement "please allow to be on keyserver" is
that it doesn't provide any verification that the email in UID (or just
the name) is accurate, so most of the complains regarding occurrence of
multiple matches for a search would not be honored, as you could anyways
create multiple keyblocks with this property.

To answer that request for feature, you need to make the keyserver a
de-facto CA instead of separating the roles, and performing some ID
verification at upload point, for email this might be a simple
robot-signing, but email addresses changes over time, and a key might be
relevant even after changing email providers to verify historical
signatures etc.

But for OpenPGP this isn't an issue to begin with. No keyblock should be
used without first verifying the material, which historically is mostly
done through fingerprint exchanges / key signing parties. If wanting to
introduce a CA in the system, nothing is stopping you, and you will find
some discussion on robo-signers etc e.g at [0], but it doesn't require
any changes on the keyserver side, exactly because that is just a data
store and distribution point without any other responsibility.

Obviously the same goes for a TOFU model and WKD, which still can use
the keyserver network as distribution point for updates of
expirations/revocations/etc...


References:
[0]
https://wiki.gnupg.org/OpenPGPEmailSummit201512/EmailValidation?action=AttachFile&do=get&target=EmailValidation20151207.pdf
-- 

Kristian Fiskerstrand
Blog: https://blog.sumptuouscapital.com
Twitter: @krifisk

Public OpenPGP keyblock at hkp://pool.sks-keyservers.net
fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3

Aut dosce, aut disce, aut discede
Either teach, or study, or leave



signature.asc
Description: OpenPGP digital signature
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: DRM?

[Leo Gaspard]

On 01/16/2018 05:42 PM, Robert J. Hansen wrote:
>> 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, but what many people want is *enforcement*.  Not
> merely a voluntary system that's trivially circumventable, but some
> mechanism by which their public keys can be actively kept out of
> circulation.

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” (modulo people who would have lost 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 people
wanting to DRM their keys.

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 and its revocation
certificate(s) to clients” would likely handle this particular issue.

All I'm saying is that a system like this one is not a silver bullet
solution, but may handle a few of the current complaints against the SKS
network?


[1] It looks like Kristian has written more about it during my typing
this mail if I can guess from Peter's answer, though Kristian's mail
didn't land in my mailbox yet.

___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: DRM?

[Kristian Fiskerstrand]

On 01/16/2018 06:05 PM, Peter Lebbing wrote:
> 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 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
published / happened, but through legal means rather than a technical
restriction. Actually there are many aspects of GDPR that is quite
hostile to both free speech and businesses.

I would agree access control would be relevant up to the point that the
information is public to begin with.


in the current state EU seems to be building strongly on roots of
left-wing bias and a liberal's wet dream of a society.

/me goes back to re-reading the Fountainhead and dreams of a world where
people have principles and take responsibility for their actions... :)


-- 

Kristian Fiskerstrand
Blog: https://blog.sumptuouscapital.com
Twitter: @krifisk

Public OpenPGP keyblock at hkp://pool.sks-keyservers.net
fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3

"If your kids are giving you a headache, follow the directions on the
aspirin bottle, especially the part that says "keep away from children."
(Neil McElroy)



signature.asc
Description: OpenPGP digital signature
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: DRM?

[Peter Lebbing]

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 webserver
will not change their homepage when a random person on the internet asks
for it.

Cheers,

Peter.

-- 
I use the GNU Privacy Guard (GnuPG) in combination with Enigmail.
You can send me encrypted mail if you want some privacy.
My key is available at <http://digitalbrains.com/2012/openpgp-key-peter>



signature.asc
Description: OpenPGP digital signature
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: DRM?

[Peter Lebbing]

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 DRM. All the thorny
extra issues I never even seriously considered is part of why I also
said "I'm not saying this is the way to go."

> (iii) iff (ii)(a) and (ii)(b) differ; how would you handle a sync
> conflict of said data?

Sounds really, really difficult to solve. Perhaps impossible? Since I'm
not advocating implementing this in the first case, I'm not spending
many computation cycles on the issue either :-). It might be there is an
imperfect but acceptable solution, though. The problem with that is
again litigation: "What do you mean, you can't remove me? You have a
removal feature! See you in court!"

Cheers,

Peter.

-- 
I use the GNU Privacy Guard (GnuPG) in combination with Enigmail.
You can send me encrypted mail if you want some privacy.
My key is available at <http://digitalbrains.com/2012/openpgp-key-peter>



signature.asc
Description: OpenPGP digital signature
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: DRM?

[Kristian Fiskerstrand]

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 hearing how this scheme would work in the
case of a compromised private key. Mainly;

(i) How would you distribute revocation certificates
(ii) Would you trust a signature for removal of keyblock provided to the
keyserver (a) after a revocation certificate has been added (b) before a
revocation has been added (as measured on the specific keyserver).
(iii) iff (ii)(a) and (ii)(b) differ; how would you handle a sync
conflict of said data?

-- 

Kristian Fiskerstrand
Blog: https://blog.sumptuouscapital.com
Twitter: @krifisk

Public OpenPGP keyblock at hkp://pool.sks-keyservers.net
fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3

"If you don't drive your business, you will be driven out of business"
(B. C. Forbes)



signature.asc
Description: OpenPGP digital signature
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: DRM?

[Robert J. Hansen]

> 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, but what many people want is *enforcement*.  Not
merely a voluntary system that's trivially circumventable, but some
mechanism by which their public keys can be actively kept out of
circulation.



signature.asc
Description: OpenPGP digital signature
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

DRM? (was: a step in the right direction)

[Peter Lebbing]

On 16/01/18 15:54, Robert J. Hansen wrote:
> What Stefan and Listo want is some mechanism by which, if I have a copy
> of their public key, I can be prohibited from sharing that with a
> keyserver.

I think that's not really the issue. You can share the key all you want,
it just won't be provided to others /by/ the keyserver, that is the
crux. You could of course run your own keyserver if you want it to do
something different.

I am in the possession of this very mail I'm typing now, yet I can't
make it show up if somebody types in <https://gnupg.org/>. 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 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", and a signed
statement saying "from 2018-04-01 on you should no longer expose this
key to clients" is not DRM, IMHO, just authentication. Anybody could
upload this statement to the keyserver. But it will only be
cryptographically valid if *created* by the holder of the private key.

I'm not saying this is the way to go. Just that I don't see it as DRM as
far as I understand.

This "right to be forgotten" is obviously management of restrictions on
the dissemination of data. It's just not digital so far.

My 2 cents,

Peter.

-- 
I use the GNU Privacy Guard (GnuPG) in combination with Enigmail.
You can send me encrypted mail if you want some privacy.
My key is available at <http://digitalbrains.com/2012/openpgp-key-peter>



signature.asc
Description: OpenPGP digital signature
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: DRM -- digital rights management

[David Shaw]

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-available public
> keys.
> 
> Is it correct?

No.  DRM is a collective term for the various means of controlling use of media 
in one way or another.  It's possible to use asymmetric crypto as part of a DRM 
scheme, but this is not a requirement, or inherent in the idea of DRM.

David


___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

DRM -- digital rights management

[M.B.Jr.]

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 Barbado, Jr.

___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users