Re: [stir] Alexey Melnikov's Discuss on draft-ietf-stir-certificates-11: (with DISCUSS and COMMENT)

Dave Crocker <dcrocker@gmail.com> Wed, 02 November 2016 18:52 UTC

Return-Path: <dcrocker@gmail.com>
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 9C4BA129B4F; Wed, 2 Nov 2016 11:52:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.7
X-Spam-Level:
X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
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 R1y0WB3tG3vv; Wed, 2 Nov 2016 11:52:12 -0700 (PDT)
Received: from mail-pf0-x22f.google.com (mail-pf0-x22f.google.com [IPv6:2607:f8b0:400e:c00::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 61B0A129B45; Wed, 2 Nov 2016 11:52:12 -0700 (PDT)
Received: by mail-pf0-x22f.google.com with SMTP id n85so16410778pfi.1; Wed, 02 Nov 2016 11:52:12 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:subject:to:references:cc:reply-to:organization:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=pYxnXTPvUiHG051BHEZ+pOYMAjpdudQf/974cTUDsJM=; b=tRZcP7AbOYPTP/4TuxE26L1zTiQxk75OXtla1D5bEVRy15yEUJxDDnpWTb4MnQKWKW zEwVa35s7neLK5fbIbMVYlEF7/uxoUNJLtB5NtJSlFL0usCyTcM5eXrP7sEpiqL3w8ji qrcxQINEke6X3eAIqK+8EdCqjcvPLaxmFWWIsIySIDhMQGqBxdyLSUAZ0i1tIaDuM6t6 QhGWMjOi9ikkBNhELSb3Kl/kuUbBIfA9PsRcOSLZiCy0w6rG3jkppca63122qcS8qskf pYIFsf9h5tulALYVQClVASC3g5wPD4SYOTpCksXBuNVGZmczEGw3uFyduk9uzjSnEjrJ DB/Q==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:subject:to:references:cc:reply-to :organization:message-id:date:user-agent:mime-version:in-reply-to :content-transfer-encoding; bh=pYxnXTPvUiHG051BHEZ+pOYMAjpdudQf/974cTUDsJM=; b=IzY1jk5aTqpz1Gyoa4am7TjDBpH5IxnLbQAFeLrQv/+9D48CoXl04f1HxN94BX3OUh j+/E7xBT0fjg/VFVwwapYECTAd+OKaaydCctupNZ65gn9TcuNDdQnsa8JaPV/QqlHC7V CNGa0tv949gbuZU/ptVhFRzmrOZkr5KrtDJSkhwpB6fKbLdnkHSppx06mgGmpV+mC23f kqGtpVEZ7qjU1hk5L+R3BWivYFRls+Gu6U9bPcZeEeWbxHxN3MAk+leTBGX4XfHnZvxk zk+2nRrjhdRQ+vpZkbAiyp+iYPquPeuEGBbbkcDUtKiLUywRbjdYaq4qbuZvjjVs+y0d qxuw==
X-Gm-Message-State: ABUngvcLlEEAgF3WDn/gElJnRWTywfM0WL6RjU29ZAf6FxYkxZ9eYwiczWZJSePAmxQMRg==
X-Received: by 10.98.23.88 with SMTP id 85mr9453607pfx.21.1478112731992; Wed, 02 Nov 2016 11:52:11 -0700 (PDT)
Received: from [10.71.12.45] ([8.25.222.2]) by smtp.gmail.com with ESMTPSA id l7sm6464415pfk.80.2016.11.02.11.52.07 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 02 Nov 2016 11:52:11 -0700 (PDT)
From: Dave Crocker <dcrocker@gmail.com>
X-Google-Original-From: Dave Crocker <dhc@dcrocker.net>
To: Alissa Cooper <alissa@cooperw.in>, Alexey Melnikov <aamelnikov@fastmail.fm>
References: <147800730286.23932.1515952198717955239.idtracker@ietfa.amsl.com> <BE53511C-3C37-4C94-8C01-681EB413C670@sn3rd.com> <1478101725.216255.775166569.1BD2E379@webmail.messagingengine.com> <58F5F6BD-02E0-4DC9-8A69-D918AB5A4B65@vigilsec.com> <26856EBB-3272-4D70-A60E-2714E8B1FB15@cooperw.in>
Organization: Brandenburg InternetWorking
Message-ID: <5bf2eeec-e634-f4f6-2f61-9494dcb20ce0@dcrocker.net>
Date: Wed, 02 Nov 2016 11:52:03 -0700
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.4.0
MIME-Version: 1.0
In-Reply-To: <26856EBB-3272-4D70-A60E-2714E8B1FB15@cooperw.in>
Content-Type: text/plain; charset="windows-1252"; format="flowed"
Content-Transfer-Encoding: 8bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/stir/huoxfP8KeUOw3Bsu6tdk5twSuwQ>
Cc: Russ Housley <housley@vigilsec.com>, IETF STIR Mail List <stir@ietf.org>, IESG <iesg@ietf.org>, draft-ietf-stir-certificates@ietf.org, stir-chairs@ietf.org, Robert Sparks <rjsparks@nostrum.com>
Subject: Re: [stir] Alexey Melnikov's Discuss on draft-ietf-stir-certificates-11: (with DISCUSS and COMMENT)
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: Wed, 02 Nov 2016 18:52:13 -0000

On 11/2/2016 11:41 AM, Alissa Cooper wrote:
> My understanding of the JWT Claim Constraints is that a CA can use them to constrain which claims it expects to receive when asked to validate a cert. Let’s imagine a context in which the base set of claims defined in this spec has been extended to include a “confidence” claim that allows a carrier to differentiate between cases where a number block is fully operated by a customer (e.g., Carrier X assigns a block to Enterprise Y), delegated to a wholesaler, or operating via an SBC. Imagine that the “full,” “delegated,” and “sbc” claims about a “confidence” claim have all been specified. The permitted and excluded constraints could be used to limit claims to one of these categories, e.g., permitted would be set to “full” for the claim “confidence” for numbers in the block used by Enterprise Y.


Alissa,

This presumes that claims are to be made about 'interesting' properties 
and issues, whereas the actual task the work is chartered for is far 
simpler, namely authentication of a call's identifier.

More generally, you have described here a broad model for processing 
that is to be performed by the receiver, based on these (standardized?) 
claims by the caller (or, rather, the caller's operator.)

Do you have examples of such a distributed, multi-administration policy 
and decision model being used successfully?

What has been defined and what you describe is quite a complex system.

d/
-- 

   Dave Crocker
   Brandenburg InternetWorking
   bbiw.net