Re: [MMUSIC] Draft new version: draft-ietf-mmusic-dtls-sdp-09

Paul Kyzivat <pkyzivat@alum.mit.edu> Tue, 01 March 2016 21:32 UTC

Return-Path: <pkyzivat@alum.mit.edu>
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3236E1B41D2 for <mmusic@ietfa.amsl.com>; Tue, 1 Mar 2016 13:32:05 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.235
X-Spam-Level:
X-Spam-Status: No, score=-1.235 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_SOFTFAIL=0.665] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gC_e0gkCNhMx for <mmusic@ietfa.amsl.com>; Tue, 1 Mar 2016 13:32:03 -0800 (PST)
Received: from resqmta-po-12v.sys.comcast.net (resqmta-po-12v.sys.comcast.net [IPv6:2001:558:fe16:19:96:114:154:171]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B70611B41ED for <mmusic@ietf.org>; Tue, 1 Mar 2016 13:32:03 -0800 (PST)
Received: from resomta-po-12v.sys.comcast.net ([96.114.154.236]) by resqmta-po-12v.sys.comcast.net with comcast id QlXU1s00756HXL001lY3M1; Tue, 01 Mar 2016 21:32:03 +0000
Received: from Paul-Kyzivats-MacBook-Pro.local ([73.218.51.154]) by resomta-po-12v.sys.comcast.net with comcast id QlY21s0033KdFy101lY2A1; Tue, 01 Mar 2016 21:32:03 +0000
To: Roman Shpount <roman@telurix.com>
References: <7594FB04B1934943A5C02806D1A2204B37E45EA2@ESESSMB209.ericsson.se> <56D46C50.9060601@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B37E4D6D5@ESESSMB209.ericsson.se> <CAD5OKxsTLt5DM6erqfE+7oYb53VKkW1suK__hv0acujJK7-wFQ@mail.gmail.com> <56D4C351.1000003@alum.mit.edu> <CAD5OKxujX4W4LyoeVJPcv3PGaS2F+RTOY2S-5cdSTCf-M5na-w@mail.gmail.com> <56D5F512.60306@alum.mit.edu> <CAD5OKxs3aqUfOsjNc9A8hXrgf-+UfLP3E2TnJ9rs761231631g@mail.gmail.com>
From: Paul Kyzivat <pkyzivat@alum.mit.edu>
Message-ID: <56D60A51.2070800@alum.mit.edu>
Date: Tue, 01 Mar 2016 16:32:01 -0500
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:38.0) Gecko/20100101 Thunderbird/38.6.0
MIME-Version: 1.0
In-Reply-To: <CAD5OKxs3aqUfOsjNc9A8hXrgf-+UfLP3E2TnJ9rs761231631g@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Transfer-Encoding: 7bit
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1456867923; bh=K20LIWd+ah2BlCbkoXX41BVHocEzbY/iEJMpv1PjWA8=; h=Received:Received:Subject:To:From:Message-ID:Date:MIME-Version: Content-Type; b=Tppz2Ded8nnBqhJcekKm1emz1H7BFwKjU8Ae+KeS98EArRgjshQpv5UJ23i7HfAzu SHY6/PGibgzcf53slzWVnAxM9ln49+WMhBe80zRsm8Heg4A+MdDhWLYBQl8HouqnpT gVRE8FTgtzMACYRcR2YQANlDoQHIFyi8gciXSiQJHH3CW81TlnAsgkcx0i+zbHuA3+ JySdiGhrD5T5KWzEA5hV3IeJ8hK5OUvysJKa3kmPKsyY0kGPzY8XDCF0+hY2JjB0K2 miXU65QS83FsS8/nFJAjSaG190mTM95QdlVMOOp5aoWa/7l+H2LJavKWfLXC0sQZwi OjEcWpE0hZw2g==
Archived-At: <http://mailarchive.ietf.org/arch/msg/mmusic/IAb6sVHnkFVDbERzYX6OQSf9UbA>
Cc: "mmusic-chairs@ietf.org" <mmusic-chairs@ietf.org>, "mmusic@ietf.org" <mmusic@ietf.org>, Christer Holmberg <christer.holmberg@ericsson.com>
Subject: Re: [MMUSIC] Draft new version: draft-ietf-mmusic-dtls-sdp-09
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group <mmusic.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/mmusic>, <mailto:mmusic-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/mmusic/>
List-Post: <mailto:mmusic@ietf.org>
List-Help: <mailto:mmusic-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mmusic>, <mailto:mmusic-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 01 Mar 2016 21:32:05 -0000

On 3/1/16 3:55 PM, Roman Shpount wrote:

> When there is a new association, new DTLS handshake occurs. During this
> handshake, capabilities and then certificates are exchanged. Certificate
> received from the remote party is checked against the list of
> fingerprints. If a fingerprint matching the certificate is found, then
> connection is accepted. If no matching fingerprint is found, connection
> MUST be torn down.

What is unclear (to me) is how to deal with multiple fingerprints. And, 
IIUC, there can also be multiple certificates.

As it used to be, the crypto used on the fingerprint had to match that 
on the certificate. So if you could handle the certificate you could 
handle the fingerprint. I gather that there is now a request to break 
that linkage. So the fingerprint might use a different crypto than the 
cert if signs.

So, am I to choose all the certs I can decode and try to verify them 
with all the fingerprint I can?

What are the criteria for success? One fingerprint verifying one cert?

	Thanks,
	Paul