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 _______________________________________________ P2PSIP mailing list [email protected] https://www.ietf.org/mailman/listinfo/p2psip
