-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
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)
iEYEARECAAYFAk1/oHcACgkQ9RoMZyVa61fhdQCfcJkRvC8OBng8QJ0EOEk3CY9R
8dYAoKJ3Q8n4SW71Pn499FWEau6k87gm
=roHV
-----END PGP SIGNATURE-----
_______________________________________________
P2PSIP mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/p2psip
