Re: [P2PSIP] Signature validation for TURN-SERVICE kind

[Bruce Lowekamp <[e-mail]>]

On Sat, Jul 23, 2011 at 2:47 PM, Marc Petit-Huguenin <[e-mail]> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> On 07/22/2011 10:58 PM, Marc Petit-Huguenin wrote:
>> On 07/22/2011 01:48 PM, Bruce Lowekamp wrote:
>>> On Fri, Jul 22, 2011 at 4:37 PM, Marc Petit-Huguenin <[e-mail]> wrote:
>>> On 07/22/2011 01:32 PM, Bruce Lowekamp wrote:
>>>>>> >From 5.3.4:
>>>>>>
>>>>>> The certificates bucket SHOULD contain all the certificates necessary
>>>>>>    to verify every signature in both the message and the internal
>>>>>>    message objects.  This is the only location in the message which
>>>>>>    contains certificates, thus allowing for only a single copy of each
>>>>>>    certificate to be sent.  In systems which have some alternate
>>>>>>    certificate distribution mechanism, some certificates MAY be omitted.
>>>>>>    However, implementors should note that this creates the possibility
>>>>>>    that messages may not be immediately verifiable because certificates
>>>>>>    must first be retrieved.
>>>>>>
>>>>>>
>>>>>> This implies that a TURN-SERVICE implementation caches the
>>>>>> certificates needed for replication.  Will add a note to the
>>>>>> TURN-SERVICE description for clarification.
>>
>>> OK, but isn't this true also for all other kinds that do not use USER-MATCH or
>>> NODE-MATCH?
>>
>>
>>>> Yes, since 5.3.4 is the definition of the basic SecurityBlock, it
>>>> applies to anything using the protocol.  Though I would expect such
>>>> usages to be rare.
>>
>> Well, in addition to the TURN-SERVICE kind, all the kinds defined as Shared
>> resource (draft-knauf-p2psip-share), the VIPR kind and the ReDir kind.  That's
>> not rare.
>>
>>> Do you have any suggestions for how/where to
>>>> clarify this point?
>>
>> IMO, it should be required that each peer stores all the certificates needed to
>> verify all the stored values at this peer.  When replicating the stored values,
>> the peer must also send the matching certificates in the GenericCertificate
>> field of the SecurityBlock request.
>
> If should be also required that a Fetch returns in the SecurityBlock all the
> certificates for all the StoredValue it will return.  With this the
> CERTIFICATE_BY_NODE and CERTIFICATE_BY_USER kinds are redundant and can be
> removed from the spec.
>

This is already covered by 5.3.4.  As agreed earlier, we will clarify
it.  Since the two certificate usages aren't really intended to be
used to validate messages, I don't see a reason to remove them here.

Bruce



>>
>>> If we add a sentence in 5.3.4 and one with
>>>> TURN-SERVICE, I think that will cover anyone reading the spec
>>>> thoroughly and anyone just looking at TURN-SERVICE as an example usage
>>>> while writing another.
>>
>>>> Bruce
>>
>>
>>
>>>>>>
>>>>>> Bruce
>>>>>>
>>>>>>
>>>>>>
>>>>>> On Sun, Jul 17, 2011 at 1:11 PM, Marc Petit-Huguenin <[e-mail]> wrote:
>>>>>> When storing a TURN-SERVICE kind, the storing peer cannot count on having the
>>>>>> certificate used to sign the value available locally, because the
>>>>>> CERTIFICATE_BY_NODE and CERTIFICATE_BY_USER kinds will be stored in a different
>>>>>> peer.
>>>>>>
>>>>>> Is the intent that the storing peer remotely fetch the certificate for the
>>>>>> validation or should it fail when the certificate is not sent in the
>>>>>> certificates field of the SecurityBlock?
>>>>>>
>>>>>> Note that if the request should fail, then it is a problem with replications as
>>>>>> there is very little chance to have the right certificate in the SecurityBlock
>>>>>> when the value is replicated.
>>>>>>
>
> - --
> Marc Petit-Huguenin
> Personal email: [e-mail]
> Professional email: [e-mail]
> Blog: http://blog.marc.petit-huguenin.org
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.11 (GNU/Linux)
>
> iEYEARECAAYFAk4rFysACgkQ9RoMZyVa61cnoACdEqchCvjXnTAFAPSzrWv8Z2TW
> 2uAAnAxG+SD6/d7JyUvpGyXIqqVV0SNw
> =/W+3
> -----END PGP SIGNATURE-----
>