Thank you Daniel,
it actually sounds very right. Now that I think about it, storing this
kind of data in the public key block isn't so good afterall. I will
investigate over this and ask to the right ML next time.
Thank you everyone for your help.
On Sun, Jan 19, 2014 at 5:21 PM, Daniel Kahn Gillm
On 01/19/2014 09:55 AM, Daniele Ricci wrote:
> Ok, so I have to conclude it's implementation specific?
> I'm using a custom user attribute to store something that can change
> quite often (privacy lists for a chat user). What do you suggest?
I don't know what a "privacy list for a chat user" is.
Am So 19.01.2014, 15:55:51 schrieb Daniele Ricci:
> Ok, so I have to conclude it's implementation specific?
> I'm using a custom user attribute to store something that can change
> quite often (privacy lists for a chat user). What do you suggest?
My first thought is: Why should it make sense to pu
Ok, so I have to conclude it's implementation specific?
I'm using a custom user attribute to store something that can change
quite often (privacy lists for a chat user). What do you suggest?
On Fri, Jan 17, 2014 at 1:28 PM, Hauke Laging
wrote:
> Am Fr 17.01.2014, 11:44:55 schrieb Daniele Ricci:
On Friday 17 January 2014 14:33:25 Daniel Kahn Gillmor wrote:
> I think you're conflating revocation of the primary key with revocation
> of a user ID.
>
> Revocation of a primary key is permanent and cannot be overridden.
> Revocation of a user ID can be overridden as long as the primary key
> (t
Am Fr 17.01.2014, 20:03:15 schrieb Johannes Zarl:
> If, however, the revocation is only a temporary act until a newer
> self- signature supersedes it, it would be almost impossible to
> effectively and permanently revoke a key.
That's why we all use only the super-secure (haha) offline mainkeys.
On 01/17/2014 02:03 PM, Johannes Zarl wrote:
> If the revocation is a final act, as long as I can make sure that the
> revocation certificate reaches my communication partners I can be sure that
> nobody can compromise the key and "reenable" it and start impersonating me.
>
> If, however, the re
On Friday 17 January 2014 13:28:50 Hauke Laging wrote:
> IIRC then GnuPG accepts a later self-signature (overriding the
> revocation). IMHO that makes most sense. As long as the mainkey isn't
> revoked or expired why shouldn't one "change one's mind"?
Wouldn't that have huge implications for the s
Am Fr 17.01.2014, 11:44:55 schrieb Daniele Ricci:
> My question is the following: suppose I create a user ID or attribute.
> I sign it with my key and that's ok.
> One day I revoke that user ID or attribute and sign it again with a
> certification revocation.
>
> A few years later, I want to rest
Hello list,
I'm manipulating PGP keys with Bouncy Castle, especially signatures of
user IDs and user attributes. But my question is not about
development, it's about signatures.
My question is the following: suppose I create a user ID or attribute.
I sign it with my key and that's ok.
One day I re
10 matches
Mail list logo
