-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 I found two more issues not fixed in -13 that were in my list but were also reported previously to the mailing-list by someone else. Instead of repeating, here's the last message exchanged on each of these subjects:
http://www.ietf.org/mail-archive/web/p2psip/current/msg05792.html http://www.ietf.org/mail-archive/web/p2psip/current/msg05564.html On 03/15/2011 10:23 AM, Marc Petit-Huguenin wrote: > Please see below for additional items that are not fixed in -13. I'll respond > in separate emails to your proposals. > > On 03/14/2011 05:43 PM, Cullen Jennings wrote: > >> There are a few things that did not get fixed in the -13 draft. Some due to >> just not sure how to fix them yet and some due to lack of time. The >> remanning open items are > > >> We need to update a few things to clarify usage when certificates have >> multiple node-id. Proposal is to say that, in cases other than when >> signaling a bootstrap peer, the first message is an Attach. The node-id used >> in the SignerIdentity of the Attach would indicate the node-id that this >> connection represented. The SignerIdentity still has to be one of the >> node-is in the certificate or the message is rejected. The same approach >> works for the non certificate based security modes. I realize this paragraph >> is clear as mud - we will work on better text. I may have misunderstood some >> of the email on this but I think this is the proposal from Marc, Bruce, and >> EKR. > > >> In section 6.3.4, it is not specified how to encode i into the hash. I'm >> proposing treating it as a uint32 and hashing that. > > > >>> A.39. Section 6.2.2 >>> >>> I am not really sure to understand how the "exists=False" are synthesized >>> when >>> doing a Fetch on an array. For example if a Store was made for an object >>> with >>> an index of 0xfffffffe, and the Fetch requests the whole array, will the >>> answer >>> contains 4294967294 "exists=False" objects? > >> Proposal: Yes > >>> Also how are this synthesized elements signed? > >> Proposal: >> The "opaque value<0..2^32-1>;" would just indicate a 0 byte long binary blog >> and be encoded per normal. > > >>> A.40. Section 6.4.3.2 >>> >>> If exist is False, should the hash_value be the hash value of an empty byte >>> array (i.e. da39a3ee5e6b4b0d3255bfef95601890afd80709 for SHA-1) or be >>> omitted? > >> Proposal: >> empty byte array ... keep the code path all the same with no special rules >> for exists == False. Keep in mind that you need to "sign" a delete of an >> entry and have that interact properly when a partitioned overlay merges" > > >>> A.43. Section 10.1 Element signature >>> >>> What certificate should be used to compute (and verify) the signature for >>> the >>> whole configuration file? > > >> Proposal: >> Add a <config-signer> to the configuration that is much like the >> <kind-signer> but says who can sing the configuration file. IN the case of >> the first time you get a configuration file, that could come at same time as >> enrollment and be secured that way. > >>> A.47. Section 6.3 >>> >>> The four policies defined in p2psip-base consistently says that "[a] given >>> value >>> MUST be written (or overwritten) if and only if the request is signed ..." >>> Additional access control policies defined elsewhere use similar wording. >>> >>> But should not the StoredData signature be used instead of the request >>> signature? When replicating the data, the signer of the StoreRequest will >>> be >>> different from the signer of the original request and so the test will no >>> longer >>> work. Section 6.4.1.1 says that "[a] peer MUST [check that] [e]ach element >>> is >>> signed by a credential which is authorized to write this kind at this >>> Resource-ID.", which seems to confirm that this is the element's signature >>> that >>> must be checked, not the request's. > >> So the elements sig need to be checked for sure. The questions is should the >> request sig also be checked before that. Unless we can say how to check it, >> seems like bad idea. Proposal: remove this or clarify. > >>> A.38. Section 5.5.1.1. 'rel_addr_port corresponds to the rel-addr and >>> rel-port >>> productions. Only present for type "relay".' >>> >>> In ICE, the rel address and port are also present for srflx and prflx >>> candidates. > >> my brain hurts. Proposal: go for beer > > > A.12 Section 10.3 states that "[t]he SubjectAltName field in the certificate > contains the following values: One or more Node-IDs...", but nowhere it is > said > how to request multiple Node-IDs. Is it an URL parameter of the POST request? > An attribute in the Certification Request object? > > EKR: "Good question. This is an issue that's simply not addressed in the > draft., > but presumably we'll need to do something like this, yeah. My taste would be > for > it to be a URL in the POSt." > > CJ: "It's not really defined in this draft how to have Certificates with > multiple node-id. There are some arguments about if multiple node ids are > useful > or not - The goal here is just to make sure that option is left open if a > future > extension does this. A parameter on the post URL sounds like a good approach." > > > A.24. Section 10.1.1. "| attribute id { xsd:int })," > > Does not match 13.6, that is saying that this is an unsigned integer. Should > probably use xsd:unsignedInt instead. > > (the private kind ids, 4026531844 and up, cannot be used with this > definition). > - -- 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) iEYEARECAAYFAk2ABx4ACgkQ9RoMZyVa61eh9gCeOixeQEAI7L7iz3xH+OTJPvLR uu4Aniug3tJHjB1wI6Qf7BPWrBkalLZs =dY6D -----END PGP SIGNATURE----- _______________________________________________ P2PSIP mailing list [email protected] https://www.ietf.org/mailman/listinfo/p2psip
