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

From: Bruce Lowekamp <[email-masked]>
Date: Thu, 4 Aug 2011 13:31:10 -0400

I still feel that writing this as a conditional MUST makes this even
more awkward (because trying to anticipate future conditions other
than shared-secret and being specific seems hard), though I could be
persuaded otherwise if enough people feel differently.

Bruce

New text for 5.3.4:

                   <t>The certificates bucket SHOULD contain all the
          certificates necessary to verify every signature in both the
          message and the internal message objects, except for those
          certificates in a root-cert element of the current
          configuration file. 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 that have
          an alternative certificate distribution mechanism, some
          certificates MAY be omitted. However, unless an alternative
          mechanism for immediately generating certifcates, such as
          shared secret security (<xref
          target="sec-shared-secret"></xref>) is used, it is strongly
          RECOMMENDED that implementors include all referenced
          certificates, otherwise there is the possibility that
          messages may not be immediately verifiable because
          certificates must first be retrieved.</t>

          <t>NOTE TO IMPLEMENTERS: This requirement implies that a
          peer storing data is obligated to retain certificates for
          the data it holds regardless of whether it is responsible
          for or actually holding the certificates for the Certificate
          Store usage.</t>

And in the turn service section:

           <t>NOTE TO IMPLEMENTERS: As the access control for this usage is
      not CERTIFICATE_BY_NODE or CERTIFICATE_BY_USER, the certificates
      used by TurnServer entries need to be retained as described in
      <xref target="sec-signature"></xref>.</t>

On Sat, Jul 23, 2011 at 3:14 PM, Marc Petit-Huguenin <[email-masked]> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> On 07/23/2011 09:03 PM, Bruce Lowekamp wrote:
>> On Sat, Jul 23, 2011 at 2:47 PM, Marc Petit-Huguenin <[email-masked]> wrote:
>> 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 <[email-masked]> 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.
>
> OK.
>
> - --
> Marc Petit-Huguenin
> Personal email: [email-masked]
> Professional email: [email-masked]
> Blog: http://blog.marc.petit-huguenin.org
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.11 (GNU/Linux)
>
> iEYEARECAAYFAk4rHX8ACgkQ9RoMZyVa61cq9wCfbnQU3aIHl7OeGWJma1oxskxE
> /lkAn3X6xzxMeqmq7LhDejCvRozcIvGc
> =mQI0
> -----END PGP SIGNATURE-----
>