Subject: Re: [MMUSIC] Draft new version: draft-ietf-mmusic-4572-update-01 - WHERE WE ARE

From: Christer Holmberg <[email-masked]>
Date: Thu, 12 May 2016 08:11:10 +0000

Hi,

Based on the discussions, it seems (please correct me if I¹m wrong) that
we have to alternatives:

ALTERNATIVE 1 (Martin¹s):

The SENDER MUST provide one or more hash functions for each offered
certificate. The set of hash functions MUST be identical for each offered
certificate.

The RECEIVER MUST match each selected* certificate with each hash function
provided by the sender (and supported by the receiver).

ALTERNATIVE 2 (Roman¹s):

The SENDER MUST provide one or more hash functions for each offered
certificate. The set of hash functions can be different for each offered
certificate.

The RECEIVER MUST match each selected* certificate with one hash function
supported by the receiver and provided by the sender. That hash function
may be different for each used certificate, as long as it is considered
secure by the receiver.

Regards,

Christer

* In most cases a single certificate is selected (as part of the DTLS
handshake), but there are use-cases where RTP and RTCP will use separate
certificates

---

From: Roman Shpount <[email-masked]>
Date: Thu, 12 May 2016 20:49:13 -0400

Now we have the third alternative:

Define the new attribute where all hash values must match. Provide both old
fingerprint and new attribute for backwards compatibility.

_____________
Roman Shpount

On Thu, May 12, 2016 at 4:11 AM, Christer Holmberg <
[email-masked]> wrote:

> _______________________________________________
> mmusic mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mmusic
>