Subject: [P2PSIP] No such thing as "the hash function for the overlay".

From: "Michael Chen" <[email-masked]>
Date: Sun, 07 Jul 2013 07:26:19 -0700

Hi
 
In the current p2psip-base-26, section 7.3.1, 7.3.2, 7.3.3, 7.3.4 and 13.5.1, all refers to "the hash function for the overlay". For example,
 
In the USER-MATCH policy, a given value MUST be written (or
 overwritten) if and only if the signer's certificate has a user name
 which hashes (using the hash function for the overlay) to the
 Resource-ID for the resource. Recall that the certificate may,
 depending on the overlay configuration, be self-signed.

However, there is no such hash function defined in the configuration XML, except the <self-signed-permitted> tag's "digest" attribute. The <self-signed-permitted> tag does not exist for enrolled overlay configuration.
 
While the RELOAD signature dynamically specifies the hash function in used, we need an explicit hash function contract for other usage like computing the Resource-ID from the SIP AoR.
 
I propose moving the "digest" attribute out of <self-signed-permitted> tag and into the top level <configuration> tag, alongside "instance-name", etc., or adding a new attribute to that effect.
 
Thanks
 
--Michael

---

From: Marc Petit-Huguenin <[email-masked]>
Date: Sun, 07 Jul 2013 07:46:25 -0700

Hi Michael,

On 07/07/2013 07:26 AM, Michael Chen wrote:
> Hi
> 
> In the current p2psip-base-26, section 7.3.1, 7.3.2, 7.3.3, 7.3.4 and
> 13.5.1, all refers to "the hash function for the overlay". For example,
> 
> 
> In the USER-MATCH policy, a given value MUST be written (or overwritten) if
> and only if the signer's certificate has a user name which hashes (using
> *the hash function for the overlay*) to the Resource-ID for the resource.
> Recall that the certificate may, depending on the overlay configuration, be
> self-signed.
> 
> 
> However, there is no such hash function defined in the configuration XML,
> except the <self-signed-permitted> tag's "digest" attribute. The 
> <self-signed-permitted> tag does not exist for enrolled overlay
> configuration.

The hash function is indirectly defined by the <topology-plugin> element.
When it is set to CHORD-OVERLAY (or if the element is not present), then the
hash definition is the one in 10.2.

> 
> While the RELOAD signature dynamically specifies the hash function in used,
> we need an explicit hash function contract for other usage like computing
> the Resource-ID from the SIP AoR.
> 
> I propose moving the "digest" attribute out of <self-signed-permitted> tag
> and into the top level <configuration> tag, alongside "instance-name",
> etc., or adding a new attribute to that effect.
> 

- -- 
Marc Petit-Huguenin
Email: [email-masked]
Blog: http://blog.marc.petit-huguenin.org
Profile: http://www.linkedin.com/in/petithug