Re: [stir] Questions about stir-certificates
"Peterson, Jon" <jon.peterson@team.neustar> Thu, 19 October 2017 16:17 UTC
Return-Path: <prvs=54656a1026=jon.peterson@team.neustar>
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 796E5132D51 for <stir@ietfa.amsl.com>; Thu, 19 Oct 2017 09:17:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.001
X-Spam-Level:
X-Spam-Status: No, score=-2.001 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_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=team.neustar
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 weqZHDh4Ui-A for <stir@ietfa.amsl.com>; Thu, 19 Oct 2017 09:17:10 -0700 (PDT)
Received: from mx0b-0018ba01.pphosted.com (mx0b-0018ba01.pphosted.com [67.231.157.90]) (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 CAA2713263F for <stir@ietf.org>; Thu, 19 Oct 2017 09:17:10 -0700 (PDT)
Received: from pps.filterd (m0078668.ppops.net [127.0.0.1]) by mx0b-0018ba01.pphosted.com (8.16.0.21/8.16.0.21) with SMTP id v9JGH1fr017219; Thu, 19 Oct 2017 12:17:06 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=team.neustar; h=from : to : cc : subject : date : message-id : content-type : content-id : content-transfer-encoding : mime-version; s=selector1; bh=g+ZG7EscQK4TtdtsrF9JcCAP69hN3QiEc68AwCdc8Dk=; b=cCRgcQnVuHbM6IWyvZH9U0MuDiB0B0yg0lqAdWHsmxHl8zJwzgd0Jm8FejhKhwk3i3IQ QaBuFcxZcBVp2ni6+RkmJwFbeOkLH63oWnaOvOT/pSCCBmHBkW61oA5z3iXbF+0s2gM1 26VmXqlMrhsgQHoBIFzCeH8FoU+j20LTfXE+WV6IK/T7fJFXPmJAPb9R6YgF+Q6llmKm Ja5Y80vKb6gugBMauQlNMf3FhD9aIIiPuJUJK2L7Mn/gTFhG+M/Lc7gu9yuxguCRycdA prWmu+LQUJq71tcKafiXBs+VEX//aIBMK7wJsgguGDEkmA6w91ullJwhV5bB0kTiMrjA 6w==
Received: from stntexhc11.cis.neustar.com ([156.154.17.216]) by mx0b-0018ba01.pphosted.com with ESMTP id 2dpxp1rap3-2 (version=TLSv1 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 19 Oct 2017 12:17:05 -0400
Received: from STNTEXMB11.cis.neustar.com ([169.254.1.47]) by stntexhc11.cis.neustar.com ([::1]) with mapi id 14.03.0279.002; Thu, 19 Oct 2017 12:17:04 -0400
From: "Peterson, Jon" <jon.peterson@team.neustar>
To: Martin Thomson <martin.thomson@gmail.com>, "stir@ietf.org" <stir@ietf.org>
CC: Sean Turner <sean@sn3rd.com>
Thread-Topic: [stir] Questions about stir-certificates
Thread-Index: AQHTSPWyRv2YsK2tJ06aOIlm8TEYkg==
Date: Thu, 19 Oct 2017 16:17:03 +0000
Message-ID: <D60E0087.1EEE44%jon.peterson@neustar.biz>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/14.6.3.160329
x-originating-ip: [10.96.12.133]
Content-Type: text/plain; charset="us-ascii"
Content-ID: <2AEDE3755985234D88F662D7720F79ED@neustar.biz>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-10-19_05:, , signatures=0
X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 spamscore=0 suspectscore=0 malwarescore=0 lowpriorityscore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1707230000 definitions=main-1710190224
Archived-At: <https://mailarchive.ietf.org/arch/msg/stir/v8yATH06vHObcPtex3Zs1ZWAhow>
Subject: Re: [stir] Questions about stir-certificates
X-BeenThere: stir@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
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: Thu, 19 Oct 2017 16:17:12 -0000
So as Sean Turner and I have been dotting the last I's and crossing the last T's in auth48 *cough* for stir-certs we did want to make sure we didn't neglect the things Martin talks about below, including pretty fundamental questions about how we structure the TNAuthList and what properties that structure can support, like delegation. Before slipping in any last minute changes that might be surprising, we wanted to run this by the group. >The first question is whether this delegation makes any sense for >service provider codes. A service provider that signs a subordinate >(such as an enterprise that operates a PBX) is hardly going to allow >that subordinate to use their service provider code. In light of >that, it seems like subjectAltName is entirely appropriate place to >put a service provider code. I think the use case for SPC delegation is probably not the enterprise case. A service bureau case makes more sense. We've also entertained cases where a large carrier, say, might have authority over multiple SPCs in one cert, but might want to delegate to some part of its own network a certificate for just one of those SPCs. I've also dimly envisioned, if this all takes off, use cases for selectively delegating applications associated with an SPC for a particular service, probably to a service bureau: like, Company A is doing the SMS for SPC 6166. >I really don't think that it's a great design choice to bundle service >provider codes with telephone numbers as TNAuthList does currently. >It seems arbitrary. I'll concede that this might seem partly an >aesthetic objection, but the two are entirely different things with >different rules. Given that the authority to sign for a telephone >number is most often a consequence of being a particular service >provider (and having a valid code) rather than a direct and >independent authority. That last point is rather what persuaded me at least that the two are coupled. I might even say that for verification purposes an SPC is just shorthand for a set telephone numbers that the SPC covers. >It's also unclear to me whether a certificate that includes AIA for >telephone numbers also effectively constrains subordinates to comply >with that set. I hope it does, yes. We can make sure the document does say that. > The document doesn't say. On the assumption that it >does, what happens when the resource identified in the AIA changes? This is supposed to be a feature, believe it or not. If the resource behind the AIA changes, the scope of the certificate changes. Part of resolving the chain of authority in this model would be dereferencing any such AIA's, yes, and making sure it still holds. >There's a possibility that changes in the referenced resource could >invalidate subordinates. Doesn't this put AIA on the critical path? That last point is probably better for Sean to speak to than me. >The draft is unclear on how uniqueness is managed for service provider >codes, or even if uniqueness is a requirement. Is this a property of >the certification path in that a trust anchor will be connected to a >particular country prefix (or set thereof), or is there something more >concrete? The SPC as specified is admittedly a blank check we're writing at this point, but I think that's about where we are in deployment. The early adopters of this are North American carriers, there are already bodies who allocate codes for such carriers. I don't think the IETF is the right place to do that or to try to figure out how those identifiers should be internationally allocated or what should happen when signed messages pass into places where other sorts of SPCs might be in use. What's there now is good enough to let people kick the tires and get some experience; it will give national and international bodies enough leeway to define what they want for it, and we can point to that later. >How does one add `count` to a number containing "*" or "#"? Don't get wrong: I won't pretend that every possible corner case involving "*" and "#" has been given adequate consideration. They are there in the syntax to cover a very small number of paranoid forward-compatibility use cases of the "To" header field, mostly ones that in turn will use the proposed "divert" extension. (For example, I'm dialing *69. That goes to a server that is going to retarget the call to the last party who called me. How should that retargeting server sign the "divert"?) I don't think count will be practically relevant to those cases, which will would have to use specialized certs anyway. I know we don't have all that fully specified, but kind of like SPC, we're trying to leave a bit of wiggle room in the syntax not to close doors on possibilities. >Does the addition of `count` treat the `start` as an integer? >What does a `count` of 0 mean? I believe a count of '0' is disallowed. >How do I express that all numbers in the +1 prefix are covered? If it were up to me, probably, I wouldn't want the NANPA to publish a cert with authority for +1, but instead, for the valid set of 10,000 blocks (done with "count") that cover the allocated +1NPANXX's. But to your bigger question... > (The NANP is perhaps a bad example, try finding solid >information on the numbering plan for +257). Did the working group >consider a number prefix in addition to the range, to allow for saying >"+1..." as a single rule? I went back and forth a lot between count versus prefix a couple years ago, and honestly neither is perfect. Count can least theoretically do things prefix can't; but doing some that are ugly to do with count can be done very elegantly with prefix. Maybe the best thing for us to do is at least leave the door open in the syntax to specify another way to do number ranges? I think for our current purposes count is probably okay, but I wouldn't object to adding wiggle room so we could specify other options in the future. >Why does JWTClaimName use IA5String rather than UTF8String? If you >need constraints on valid characters, prose is a better choice. RFC >7519 permits any Unicode string by not constraining the format of the >name. We discussed this quite a bit with the IESG in terms of consistency across the three drafts, and I think what we have in the post-auth48 versions should be okay. We just want to make sure that the claim names and the syntax of the JWTClaimNames are the same - practically speaking I don't think we're going to see things in the claim names outside the IA5 range, so I don't think it's a problem as such. Jon Peterson Neustar, Inc.
- [stir] Questions about stir-certificates Martin Thomson
- Re: [stir] Questions about stir-certificates Peterson, Jon
- Re: [stir] Questions about stir-certificates Chris Wendt
- Re: [stir] Questions about stir-certificates David Bryan
- Re: [stir] Questions about stir-certificates Martin Thomson
- Re: [stir] Questions about stir-certificates Gorman, Pierce A [CTO]
- Re: [stir] Questions about stir-certificates Gorman, Pierce A [CTO]
- Re: [stir] Questions about stir-certificates David Bryan
- Re: [stir] Questions about stir-certificates Paul Kyzivat
- Re: [stir] Questions about stir-certificates Gorman, Pierce A [CTO]
- Re: [stir] Questions about stir-certificates Paul Kyzivat
- Re: [stir] Questions about stir-certificates Richard Shockey
- Re: [stir] Questions about stir-certificates Chris Wendt
- Re: [stir] Questions about stir-certificates Paul Kyzivat
- Re: [stir] Questions about stir-certificates Richard Shockey
- Re: [stir] Questions about stir-certificates Gorman, Pierce A [CTO]
- Re: [stir] Questions about stir-certificates Richard Shockey
- Re: [stir] Questions about stir-certificates Paul Kyzivat
- Re: [stir] Questions about stir-certificates Sean Turner
- Re: [stir] Questions about stir-certificates Martin Thomson
- Re: [stir] Questions about stir-certificates Paul Kyzivat
- Re: [stir] Questions about stir-certificates Martin Thomson
- Re: [stir] Questions about stir-certificates Paul Kyzivat
- Re: [stir] Questions about stir-certificates Sean Turner
- Re: [stir] Questions about stir-certificates Sean Turner
- Re: [stir] Questions about stir-certificates Martin Thomson
- Re: [stir] Questions about stir-certificates Sean Turner
- Re: [stir] Questions about stir-certificates Keith Drage