-----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. > >> 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
