On Sat, Jul 23, 2011 at 2:47 PM, Marc Petit-Huguenin <[email protected]> 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 <[email protected]> >>> 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 <[email protected]> >>>>>> 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: [email protected] > Professional email: [email protected] > 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----- > _______________________________________________ P2PSIP mailing list [email protected] https://www.ietf.org/mailman/listinfo/p2psip
