On Fri, Jul 22, 2011 at 5:09 PM, Marc Petit-Huguenin <[email protected]> wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > On 07/22/2011 01:54 PM, Bruce Lowekamp wrote: >> On Fri, Jul 22, 2011 at 11:55 AM, Marc Petit-Huguenin <[email protected]> >> wrote: >> On 07/01/2011 04:38 AM, Gonzalo Camarillo wrote: >>>>> Folks, >>>>> >>>>> the P2PSIP WG chairs are in the process of requesting the publication of >>>>> the following draft: >>>>> >>>>> https://datatracker.ietf.org/doc/draft-ietf-p2psip-base/ >>>>> >>>>> At this point, they are working with the secretary to fix the state of >>>>> the document in the tracker (it should be publication requested) and to >>>>> upload the document's PROTO write up. >>>>> >>>>> While that gets fixed, I have done my AD review (see below) in order to >>>>> gain some time. As soon as these comments are addressed, I will start >>>>> the IETF LC on this draft. >>>>> >> >> The IETF LC ends today but Michael Chen and I sent multiple questions to the >> mailing-list that are still without answer. I find it difficult to decide if >> this specification is ready to be published until this questions are >> answered. >> >> >>> Marc, >> >>> The other authors and I greatly appreciate the time you have put into >>> implementing and evaluating the protocol, and into providing comments >>> on the document. However, it's difficult to keep track of them since >>> they are generally in separate emails, so I would appreciate it if you >>> could be specific listing any unanswered questions. I've looked >>> through my email archive and responded to the two questions (one from >>> you and one from Michael Chen) that I found, both of which I think are >>> simple to resolve in the text. If there are any others, please list >>> them so we can be sure to address them. > > http://www.ietf.org/mail-archive/web/p2psip/current/msg05937.html >
Thanks for pointing that out. I didn't go back beyond the beginning of last call when I looked yesterday. > > You may also want to look at my draft containing stuff I plan to publish as > extensions or in RELOAD 2.0: > If you have a comment to make about the current draft, please make it clearly on-list. I sure wouldn't expect a 2.0 document anytime soon, and if you believe there are issues that somehow need to be resolved, you should be making clear technical statements about them. I've read that draft, but I'm not going to go through guessing what you think you want to do later as extensions and what you think should be changed in the current draft. > http://www.ietf.org/internet-drafts/draft-petithuguenin-p2psip-reload-bis-00.txt > > Version -01 will contains at least one additional section, here's the current > draft (which is related to the TURN-SERVICE question): > > <section title="Certificate Processing"> > <t> > An original store is able to verify the signature of the items to store > because the signer of the request is the same than the signer of the stored > values, but it is not true for replica stores, where the request signer and > the > stored value signer are different. > Even for the Access Control Policies where the certificate is stored at the > same peer than the stored value, there is no guarantee that during a > replication > the certificate will be available for verification of the value. > </t> > > <t> > This document adds a rule to the list in section 6.4.1.1 that says that > when > processing a StoreReq, none of the modifications is visible to the validation > process until the whole content of the StoreReq is validated. > This means for example that sending a certificate with a > CERTIFICATE_BY_NODE > kind in the same StoreReq than a a value signed by this certificate will not > permit to validate this value. > The certificate has to be stored before in a different Store request or has > to be sent in the GenericCertificate field of the SecurityBlock of the > request. > </t> > > <t> > This document also requires that each peer stores all the certificates > needed to verify all the stored values. None of this seems to add anything beyond what's already in 5.3.4, that the certificates necessary to validate a request SHOULD be in the message. Quoting again from that section: In systems which have some alternate certificate distribution mechanism, some certificates MAY be omitted. that's the exception, clearly stated. Otherwise, the certs are included. > When replicating the stored values, the peer MUST also send the matching > certificates in the GenericCertificate field of the SecurityBlock request. The exception was requested by some people with specific scenarios where they had (or could get) certificates quite easily. The exception also applies to the shared-secret security mechanism in the document (12.4). Since that specific case where certs don't need to be included is already in the base document, I would be against changing the current approach by making including certs a MUST. Bruce > - -- > 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) > > iEYEARECAAYFAk4p5xQACgkQ9RoMZyVa61eHuQCgp4Cinv0NrOcCR7IWF/qcz67l > KrgAniXutvo9Tp+k/TTtfbR89hP+3g/U > =Aftz > -----END PGP SIGNATURE----- > _______________________________________________ P2PSIP mailing list [email protected] https://www.ietf.org/mailman/listinfo/p2psip
