Re: [stir] Review of: draft-ietf-stir-rfc4474bis-10

Dave Crocker <dhc@dcrocker.net> Fri, 19 August 2016 15:55 UTC

Return-Path: <dhc@dcrocker.net>
X-Original-To: stir@ietfa.amsl.com
Delivered-To: stir@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 08D2A12DB65 for <stir@ietfa.amsl.com>; Fri, 19 Aug 2016 08:55:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.198
X-Spam-Level:
X-Spam-Status: No, score=-1.198 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_MSPIKE_BL=0.01, RCVD_IN_MSPIKE_L5=0.001, RDNS_NONE=0.793, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=dcrocker.net
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 Xt0x_AFeDubl for <stir@ietfa.amsl.com>; Fri, 19 Aug 2016 08:55:17 -0700 (PDT)
Received: from simon.songbird.com (unknown [72.52.113.5]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 20BF512DBA1 for <stir@ietf.org>; Fri, 19 Aug 2016 08:55:16 -0700 (PDT)
Received: from [192.168.1.168] (76-218-8-128.lightspeed.sntcca.sbcglobal.net [76.218.8.128]) (authenticated bits=0) by simon.songbird.com (8.14.4/8.14.4/Debian-4.1ubuntu1) with ESMTP id u7JFtLDf025663 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NOT); Fri, 19 Aug 2016 08:55:21 -0700
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=dcrocker.net; s=default; t=1471622121; bh=1jB8gv0ABtYm/MXiB95iqnbk7P/RWJe0Pn15jpsAah8=; h=Subject:To:References:Reply-To:From:Date:In-Reply-To:From; b=p727AxoKZEnEu/60p4FMvmbRnCgjYF70s2C6y5MFuwsqVbplvqZlfBIrqSl02jt9B +bzzBBTQd1DUvZvxh8iz9ZLakK9qEDTpqeK7dTWc4djry31wHK7MM88pOYHQIKIZ74 dMRcuMXCdGAknykVxkWfzadAzK2pNchQvTh4zp5Q=
To: Paul Kyzivat <pkyzivat@alum.mit.edu>, stir@ietf.org
References: <c3a85ffc-8340-ac54-4d8e-21a16fefd032@dcrocker.net> <D3D41210.1A72E4%jon.peterson@neustar.biz> <CAHBDyN7W8zkgGjeUqzGaxLfRD-nFDgD9R3kxioQ47Kbp4_B8EA@mail.gmail.com> <6bd1e4bc946a4a02a1f4fdac385984b9@PLSWE13M08.ad.sprint.com> <D3DB2EE9.1A7B59%jon.peterson@neustar.biz> <fbf38cef-bfb0-60df-175d-c57362917c4c@dcrocker.net> <8b99c0c3-67af-9eec-e6c0-6fad56413318@alum.mit.edu>
From: Dave Crocker <dhc@dcrocker.net>
Organization: Brandenburg InternetWorking
Message-ID: <c057e894-b456-8ad7-390a-67eb8e31f149@dcrocker.net>
Date: Fri, 19 Aug 2016 08:55:00 -0700
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0
MIME-Version: 1.0
In-Reply-To: <8b99c0c3-67af-9eec-e6c0-6fad56413318@alum.mit.edu>
Content-Type: text/plain; charset="windows-1252"; format="flowed"
Content-Transfer-Encoding: 7bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/stir/FWheklAIyg6T4k0ky2EjgfGhE4E>
Subject: Re: [stir] Review of: draft-ietf-stir-rfc4474bis-10
X-BeenThere: stir@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
Reply-To: dcrocker@bbiw.net
List-Id: Secure Telephone Identity Revisited <stir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/stir>, <mailto:stir-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/stir/>
List-Post: <mailto:stir@ietf.org>
List-Help: <mailto:stir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/stir>, <mailto:stir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 19 Aug 2016 15:55:18 -0000

On 8/19/2016 8:49 AM, Paul Kyzivat wrote:
> What this means is that any *prioritization* of these needs to be a
> decision made by the validator (perhaps differently for different
> validators in the same call), and not by the signers.


Paul,

As you have phrased it, this seems likely to produce non-interoperability.

Some -- and maybe all -- of the details concerning the basic mechanics 
and semantics of multiple signatures need to be specified for consonant 
behavior between signers and validators.  Otherwise, the signer won't 
know how the validator will interpret the signatures.  And the validator 
won't know what the signer(s) meant.

(This is, of course, separate from any policies the receiving side might 
choose to have for the /use/ of the results of that interpretation.)

d/

-- 

   Dave Crocker
   Brandenburg InternetWorking
   bbiw.net