[prev in list] [next in list] [prev in thread] [next in thread] 

List:       bouncycastle-crypto-dev
Subject:    Re: [dev-crypto] PGPPublicKey.getSignaturesForUserAttribute returns only the first match
From:       Daniele Ricci <daniele.athome () gmail ! com>
Date:       2014-01-21 21:25:06
Message-ID: CA+yWqeX8UEjMNsGY+8Sm_7xoBkGaCMHNcyn-8PXPqJW9xgN9JA () mail ! gmail ! com
[Download RAW message or body]

I think it's the former. Here is our conversation:
http://lists.gnupg.org/pipermail/gnupg-users/2014-January/048809.html

The conversation degenerated because... ehm... I went a bit off-topic
:-) but I saw what I needed to see.

On Tue, Jan 21, 2014 at 10:19 PM, David Hook <dgh@autochthonous.org> wrote:
>
> I'd agree with that, the question is whether you would add the signature to
> the user attributes object that is already there (after all it's identical,
> or we wouldn't be in this situation) or you add another user attributes
> object with another signature (in which case you have two identical ones
> with different directives associated with them - I'm pretty sure doing it
> this way would be the path to disaster).
>
> Regards,
>
> David
>
>
> On 22/01/14 08:05, Daniele Ricci wrote:
>>
>> Hi again,
>> I asked to the gnupg-users mailing list, they seemed a bit...
>> confused. RFC isn't really clear about this, but they were pretty
>> convinced that when more signatures are found, the most recent one
>> should take precedence.
>>
>> On Wed, Jan 8, 2014 at 1:35 AM, David Hook <dgh@autochthonous.org> wrote:
>>>
>>> I think I'd add another certification - it's a bit of an odd one, but I
>>> think what you'd really be trying to say is that for a certain time
>>> interval
>>> the user attribute would not be valid and then it would be valid again.
>>>
>>> Regards,
>>>
>>> David
>>>
>>>
>>> On 07/01/14 21:01, Daniele Ricci wrote:
>>>>
>>>> Thanks David,
>>>> but let's say I do something like this:
>>>>
>>>> * I create an attribute and sign it
>>>> * I revoke that attribute by appending a certification revocation
>>>> (attribute is no more valid)
>>>> * I decide to make that attribute valid again, but I can't use the
>>>> previous one any more (can I? I mean it's been revoked, revocation is
>>>> for good isn't it?)
>>>> * I create a new attribute with the same content and sign it
>>>>
>>>> The actual doubts are the questions between brackets: can I recycle an
>>>> old attribute by signing it again with a positive certification? Or do
>>>> I have to necessarily create a new one even if the content is
>>>> identical? I really can't find anything about that in RFC 4880...
>>>>
>>>>
>>>>
>>>> On Tue, Jan 7, 2014 at 10:01 AM, David Hook <dgh@autochthonous.org>
>>>> wrote:
>>>>>
>>>>> I'm not sure how this would work - I think you're really only supposed
>>>>> to
>>>>> have one UserAttribute of a particular kind. It can have multiple
>>>>> certifications against it though. Section 11 of RFC 4880 does seem to
>>>>> imply
>>>>> that if there are multiple user IDs and user attributes they should be
>>>>> different, although I do have to admit it doesn't say that
>>>>> specifically.
>>>>>
>>>>> Regards,
>>>>>
>>>>> David
>>>>>
>>>>>
>>>>> On 06/01/14 03:14, Daniele Ricci wrote:
>>>>>>
>>>>>> Hello devs and happy new year.
>>>>>> I'm extending some BC classes to implement a custom PGP user
>>>>>> attribute.
>>>>>> I've just noticed from getSignaturesForUserAttribute code that the
>>>>>> "ids" list is looped until an equals() returns true.
>>>>>> But what if there are two identical user attributes, for example the
>>>>>> first one being revoked and the second one being the valid one?
>>>>>> As far as I can see, equals() checking on user attributes is a byte
>>>>>> array comparison, so how do you distinguish one from another?
>>>>>> The first thing that comes to my mind is looking at the signature
>>>>>> timestamp, yet the for loop in getSignaturesForUserAttribute stops at
>>>>>> the first match.
>>>>>>
>>>>>> Regards
>>>>>
>>>>>
>>>>>
>>>>
>>>
>>
>>
>
>



-- 
Daniele

[prev in list] [next in list] [prev in thread] [next in thread]