-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
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.
Here's my proposal:
Section 3.2.1:
" o Establish a connection with an arbitrary peer in the overlay
(perhaps based on network proximity or an inability to establish a
direct connection with the responsible peer). In this case, the
client will rely on RELOAD's Destination List feature to ensure
reachability. The client can initiate requests, and any node in
the overlay that knows the Destination List to its current
location can reach it, but the client is not directly reachable
using only its Node-ID. If the client is to receive incoming
requests from other members of the overlay, the Destination List
required to reach it must be learnable via other mechanisms, such
as being stored in the overlay by a usage. If the certificate used
by the client contains multiple Node-IDs, the client MUST immediately
send a Ping request with a wildcard Node-ID, so the client and peer
can learn each other Node-Id."
Section 5.1
" o The first entry on the destination list is an ID for which the
peer is responsible. A peer is always responsible for the wildcard
Node-ID."
Section 5.1.1
" o If the entry is a Resource-ID, then it MUST be the only entry on
the destination list. If there are other entries, the message
MUST be silently dropped. Otherwise, the message is destined for
this node and it passes it up to the upper layers.
o If the entry is the wildcard Node-ID, the message is destined for
this node and it passes it up to the upper layers."
Section 5.3.4:
" enum { reservedSignerIdentity(0),
cert_hash(1), cert_hash_node_id(2) (255)} SignerIdentityType;
struct {
select (identity_type) {
case cert_hash:
HashAlgorithm hash_alg; // From TLS
opaque certificate_hash<0..2^8-1>;
case cert_hash_node_id:
HashAlgorithm hash_alg; // From TLS
opaque certificate_hash<0..2^8-1>;
NodeId node_id;
/* This structure may be extended with new types if necessary*/
};
} SignerIdentityValue;
struct {
SignerIdentityType identity_type;
uint16 length;
SignerIdentityValue identity[SignerIdentity.length];
} SignerIdentity;
struct {
SignatureAndHashAlgorithm algorithm; // From TLS
SignerIdentity identity;
opaque signature_value<0..2^16-1>;
} Signature;
The signature construct contains the following values:
algorithm
The signature algorithm in use. The algorithm definitions are
found in the IANA TLS SignatureAlgorithm Registry. All
implementations MUST support RSASSA-PKCS1-v1_5 [RFC3447]
signatures with SHA-256 hashes.
identity
The identity used to form the signature.
signature_value
The value of the signature.
The identity format can take two forms, depending if the certificate
contains one or more Node-IDs. If the certificate contains only one
Node-ID, the cert_hash is used The hash_alg field is used to indicate the
algorithm used to produce the hash. The certificate_hash contains
the hash of the certificate object (i.e., the DER-encoded
certificate).
If the certificate contains more than one Node-ID, the cert_hash_node_id
form is used, with node_id containing the Node-ID selected."
- --
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/p3oACgkQ9RoMZyVa61eNBQCfX+eI0wF1JDA5yEnMQYrf/8hY
I/EAniINgUsB4zqYOzOcN62bhNl9tt/N
=0+mS
-----END PGP SIGNATURE-----
_______________________________________________
P2PSIP mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/p2psip
