-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 07/23/2011 08:59 PM, Bruce Lowekamp wrote: > On Fri, Jul 22, 2011 at 5:09 PM, Marc Petit-Huguenin <[email protected]> wrote: > 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.
If there was something in it that I thought was necessary to the base draft, I would have send it directly. > > > 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. I can assure you that it is not what implementers understand (and I am not talking about myself). This is the problem when a SHOULD is used instead of a conditional MUST. > > 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. OK. - -- 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) iEYEARECAAYFAk4rHRoACgkQ9RoMZyVa61flsACfb10o/deRx4Q24yV/rE+KIjns thYAnRdr8OeI1CWv1mpzZZM6ablxnpZJ =UFHi -----END PGP SIGNATURE----- _______________________________________________ P2PSIP mailing list [email protected] https://www.ietf.org/mailman/listinfo/p2psip
