Re: [urn] Informal NID registration interest
Kate Gray <kate@aerobatt.com> Tue, 30 March 2021 07:42 UTC
Return-Path: <kate@aerobatt.com>
X-Original-To: urn@ietfa.amsl.com
Delivered-To: urn@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 17C593A2A10 for <urn@ietfa.amsl.com>; Tue, 30 Mar 2021 00:42:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=aboveandbeyondaero.onmicrosoft.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 evjc0dbWhJe7 for <urn@ietfa.amsl.com>; Tue, 30 Mar 2021 00:42:24 -0700 (PDT)
Received: from NAM12-MW2-obe.outbound.protection.outlook.com (mail-mw2nam12on2110.outbound.protection.outlook.com [40.107.244.110]) (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 E534A3A2A12 for <urn@ietf.org>; Tue, 30 Mar 2021 00:42:23 -0700 (PDT)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=Q5sbJaf+9wlvqvzR0Y/qCu0bo8pQZziLI18CSJNyGgGIlqY3b0OCcnLbIFLBy61hMb771Bn88PQkctQILQw4rnEag3/CwLOwcnSY82H7eR0tqwYGjhoevSi/gG6y0hI14crexC+xKkAHW/FpnJOYbypezT7v4KQ/GqIe3PmIUBA1nV9V6f/XsvFFk5TOwuRq89cp2oZrDqh0eBYbT2PoT7D0RvHJirvm1eMu78Dpi2ntn3jYKg1WGg0PTd+AsLL1rRYml/sTkn21tYYsTtdk220IvAAGUl4uOfdwXuBgSu/9xB0Wvamk/y4tTNYrhc2+4dRSTquE7YNrVS3Q6wtBLA==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=jbszcNA7UWJkVQTu36K95z8ybwUeFP+aTFpqMhdm62U=; b=EdLlppg8LCGV4siKAkhOpepUFm5RXywkGRlAcF9/JoUjAbQ/UebNcj69E304qKrw5Q5/SMqYa7Eih97TV/JPktUZ/X/VlizcxioQQdNnBZ/9DOuEOA47X0ZK+2plNX9qqBLF+XEy3SnBOIzHPiyJTSK55/C/OgZnEPbr8g2LZASPLre5BUNpZJF6kRwHP6nOC9FJN3HS+mVjO0YOB5ceo4uKGY4DHOO3CeNnP4Awm/ZNThyylKEiCiq7Ed3eh28QjGeLEd59bYgTtDlaY/iLYA+buFPZb6Fv8Xqvi1b7Dgqxf+dMsexGNAdclQiPeTfCRzgI32sDEm7esH1gPO9GQg==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=aerobatt.com; dmarc=pass action=none header.from=aerobatt.com; dkim=pass header.d=aerobatt.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=aboveandbeyondaero.onmicrosoft.com; s=selector1-aboveandbeyondaero-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=jbszcNA7UWJkVQTu36K95z8ybwUeFP+aTFpqMhdm62U=; b=GjBq2MC635JzmpupWINcg2tRgAjnRVL6jP6672c22qmaUWaXB9sCth2jDFVsPMnkosv2EVTMVGeFKmTolPAVUFmVOXg8PyQDw+eR8pvToQi0FDrHRRxizrFj36h/m7hzfRuaEGF2UcJIR3HpozPvEo20312W6sYdOsFYkz0Um7A=
Received: from DM6PR18MB3473.namprd18.prod.outlook.com (2603:10b6:5:2a1::10) by DM6PR18MB3523.namprd18.prod.outlook.com (2603:10b6:5:2ab::7) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3977.25; Tue, 30 Mar 2021 07:42:21 +0000
Received: from DM6PR18MB3473.namprd18.prod.outlook.com ([fe80::b926:3fc1:246f:f907]) by DM6PR18MB3473.namprd18.prod.outlook.com ([fe80::b926:3fc1:246f:f907%3]) with mapi id 15.20.3977.033; Tue, 30 Mar 2021 07:42:20 +0000
From: Kate Gray <kate@aerobatt.com>
To: "urn@ietf.org" <urn@ietf.org>
Thread-Topic: [urn] Informal NID registration interest
Thread-Index: AQHXI6jsp2uW4D9GK0abAS580bTAN6qbDkYAgAEZ9S4=
Date: Tue, 30 Mar 2021 07:42:20 +0000
Message-ID: <DM6PR18MB3473EFA05F1C684FC3132CDAB47D9@DM6PR18MB3473.namprd18.prod.outlook.com>
References: <DM6PR18MB3473CBFBFF360DF0CD5FBA0DB47F9@DM6PR18MB3473.namprd18.prod.outlook.com>, <CA+9kkMAvvBgo+Mw3RhD0a0t2M6F4M_=CFDtkQncHVZuZmrKeoQ@mail.gmail.com>
In-Reply-To: <CA+9kkMAvvBgo+Mw3RhD0a0t2M6F4M_=CFDtkQncHVZuZmrKeoQ@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
authentication-results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=aerobatt.com;
x-originating-ip: [67.79.85.206]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 74020fc8-4bc1-40ad-9214-08d8f34f59d4
x-ms-traffictypediagnostic: DM6PR18MB3523:
x-microsoft-antispam-prvs: <DM6PR18MB3523DE4D541AEB59D701DE64B47D9@DM6PR18MB3523.namprd18.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:7219;
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: QT4ObUT3CvzMdSNoFRdJTHcVJKRnCoZ/679URFHSxWfJU1Ichcm5zjaZMQXH5UTr5dXv3fcfz/D/X6LMMZjK6fnQG14TDxIG3jT/iC4QVk9hlbcximDLrg4KYCX+3yaMVgssUW8ac/wrCSg0KL1cIVN7tjP4Thkh9aBu5FriYIeTedRYiAfLRX5VUPJibDmy1JmjimjN5rQbHnSAfnJCr19wOM5f95gVHzYX8my0IFDfj4MXY3Qo6nyydL+maVjNCWbz+hujqTcPi9mJ40lkxDrZf023e67pBnszNKgZGtb8qhWMLoRCh22ccwRvwXJBsQIZeRcSObM1nrB0pBHf3ggNRtMIEJGZ/x5YPjYi4FtJ09wP1Ac9xRoO0KAEFCTZRCKeUu/Lmgd3SAhREDsNwnz+A2Z9IQWbCnlywyqzzqpdlAs2eMj1HKapWFIItu/wQUZP32luBtnNpf4oyOgq2vRAfATWzyEmzcqJp+p/zJEa5xTVot+4fEwAshMHMbc8fIXF4g9Cya52n1ms+wXGynqSEOMAE61AbucQ2G2Ozkf9gkxkfBJWTHxZw5Q79dsZTliB8VAdpW5HWNANG2c+eZd7aoNU0v281GyeuUs/lA+lFygThofKD7AzIHRRASedRotHi1T7qlpKtsjtU69+5ghpz/QvEyYOWUS50UfD9uLqOKEwFssUywOv28wASFu00aZjOF0T1C9hqvX9HVVPp0Y2BXJ8Rgs6rbDgXxnlUibgNBpb65t9UhR5+Z1N37qv
x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:DM6PR18MB3473.namprd18.prod.outlook.com; PTR:; CAT:NONE; SFS:(39830400003)(136003)(346002)(396003)(376002)(366004)(30864003)(478600001)(45080400002)(66574015)(83380400001)(66476007)(66556008)(64756008)(66446008)(52536014)(66946007)(91956017)(76116006)(5660300002)(86362001)(33656002)(186003)(966005)(38100700001)(8936002)(316002)(9686003)(6916009)(8676002)(26005)(53546011)(7696005)(6506007)(55016002)(71200400001)(166002)(19627405001)(2906002)(71440200001); DIR:OUT; SFP:1102;
x-ms-exchange-antispam-messagedata: n8gQ0Dn6jUylt6biD236atKy0m3oSIJI1G9BFtJwuOgLVyVWhqDFHRj4MwWO5Dq6F2jnLgCVNdZVUTQL74Bb46WePDFd2sFm3BugM4QYMTlCgF2Rrad4H54rNjdSup1iZJJMDToq8K8afnYpoC6RrEJ0qMJLMIoqBZYE8InkFXVx6wYv5JQp2dCdjRSOkDkKMOSsORhZMpBo2T1NJ7bARFVrqawk7XJR8MJnqFdPDF0FTcWgSNokY0fZ8CDtagxzCX8UYsrE199F4f3mAdynyyTIdYO4Ax/z2dDMKBFGMUFc9XJOFPfguKnQsrXf+O/uu/9ejjpsTQAxwNZLiTcedHW7+JGE9DlUv6TZHuL7T0kbeLaS141x6Wq8sy1YFYjcS7IGubSxtj/AXyUQjOHCROs0cO0VpQa60gJ0xMugw4DeRUY3J0pE6l5xHBWyDBGaV17/n5wmo6dpv2BWE4dhCyGkz8LMCYFUFS9jpOc+4bt66WjODHC7qFrD0ZxOhqGZUmtH9xYde72PagtNKfxYnZvsTnFPnZ37G6t3Unfy5FmW7hWon6IEK9LNyTsICr/dUefbFIoWbwRwSwlFNdRbwLW36ZFCJlbcbRmlXIAi4YCYQYUqNkuFMIM6r+hBRg3Vj3tF9ncsBbBOyDDWG2vNuF0kGxSEVQxTslNnBoQjeRnQpXdAMma09MIDOcqk3XzfHvo7Ri99lxKzh12nHSvtKNmqZaas8xbU/O7Av9GO35Kre3PPd0pPwNcP7Ry9Bd4FNH0VMNM3nEd06s3DoerdWGeYH8QWDg27oMqouCSBQ3a7k8Aj+q67jzln9UTvqlI4HT36s8nSpSt6pmC3QmeOd0BvG5RJM/V7BZq33ZLtlD+QHr4OJdcaoTyCGulkbZ1Qybfxc/NEi+fyxUyoypK6foepL517aiEMoaq1B6Ihqy93bVBFKy5MBbkUwhybyazQJwUMUvdtppsNLKQipfKYKD+MFCrxFQvhfOUmkQivtRfDzJNeGa7HFykBy21hJQFDCSKvaZZ5zXTPBZuMSPz0AEIlKdY04RFwEIqrQyVSzbXE8d3dj/4Vcfonf0AIKx8ffeiKJMyTY7UeQRj+13gg8L+kkYFHG4FlIBtLkoRxcMhsh8LTLOC97RgvxmqlLVetp19wpypCbAjq5IT4Db1KVL3O71PP5U7+TmDU+DrJVUWTPNhPYhwF0HGEkpUbs6qyh+rHlLafht05HQbuxBGK99maAT7gn5w5yl6x4MFyTqOZ7FhaXs8Jvw08YE+Y/3GG+mGDEJOdP9S9JUcldyDKSRoV/uhDP17k7RkURSWmjco=
x-ms-exchange-transport-forked: True
Content-Type: multipart/alternative; boundary="_000_DM6PR18MB3473EFA05F1C684FC3132CDAB47D9DM6PR18MB3473namp_"
MIME-Version: 1.0
X-OriginatorOrg: aerobatt.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: DM6PR18MB3473.namprd18.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 74020fc8-4bc1-40ad-9214-08d8f34f59d4
X-MS-Exchange-CrossTenant-originalarrivaltime: 30 Mar 2021 07:42:20.5385 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: e0c10a5c-cb0d-4dbf-8351-c088c95ec14d
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: ET3R3xHoMJXz0QS2jHrYhym7ccn0YvYuymaUGbSV4Ulk+HJu9UTI9nuNW51W/u43KpBuARiLx7bEw3txSfjjgQ==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM6PR18MB3523
Archived-At: <https://mailarchive.ietf.org/arch/msg/urn/3q4FymwsHFCioaYUsmvZIsH9iKA>
Subject: Re: [urn] Informal NID registration interest
X-BeenThere: urn@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Revisions to URN RFCs <urn.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/urn>, <mailto:urn-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/urn/>
List-Post: <mailto:urn@ietf.org>
List-Help: <mailto:urn-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/urn>, <mailto:urn-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 30 Mar 2021 07:42:29 -0000
From: Kate Gray <kate@aerobatt.com> Sent: Monday, March 29, 2021 1:40 PM To: Ted Hardie <ted.ietf@gmail.com> Subject: Re: [urn] Informal NID registration interest Answers inline. ________________________________ From: Ted Hardie <ted.ietf@gmail.com> Sent: Monday, March 29, 2021 10:50 AM To: Kate Gray <kate@aerobatt.com> Cc: urn@ietf.org <urn@ietf.org> Subject: Re: [urn] Informal NID registration interest Howdy, Thanks for submitting the registration. I have a couple of questions, inline below. On Sun, Mar 28, 2021 at 3:05 PM Kate Gray <kate@aerobatt.com<mailto:kate@aerobatt.com>> wrote: Hello, I am interested in registering an informal NID for URNs. I have attempted to fill out the template as requested. I apologize if I screwed up somewhere; this is my first time doing this. Namespace Identifier: Assigned by IANA (informal) Version: 1 Date: 2021-03-28 Registrant: Kate Gray <kate&codebykate.com<http://codebykate.com/>> 340 S Lemon Ave #5926 Walnut, CA 91789 USA Purpose: The purpose of this NID is to provide a Uniform Resource Name representing derived keys within a card issuance scheme. Specifically, they provide a path within a hierarchal tree representing implementers (referred to as tenants within the system), card issuers (e.g. Universities), optional sub- issuers (e.g. Departments), and individual keys within a card (used for different purposes). These URNs will be used by card manufacturers (to preload data for issuers), as well as issuers and users to refer to the cards and keys throughout the card lifecycle. Good security practices require the use of diversified (per-card) keys, so that an attacker who defeats the security on a card will not have the keys required to attack other cards within the system. A cryptographic module (generally a smart card) can be pre-provisioned with the issuer keys, and the URN for a given key provided to it. With this information and cryptographic keying material, the appropriate keys can be derived, without the host needing to know the issuer keys. While this URN will be implemented into software (including open source software), and published to permit others within the industry to interoperate, it is not expected to become a formal standard, or to be publicly resolvable. The general use will be between actors in a card issuance scheme, for purposes like enabling a vending machine to derive a balance update key for a stored balance wallet on a card, or for a help desk agent to determine the Personal Unblocking Key (PUK) for a user that has lost their PIN. Syntax: All URNs defined under the namespace have the following structure, specified in RFC 7405 ABNF notation[1]: NSS = %s"urn:" NID ":" TenantId "@" TenantVersion ":" IssuerId "@" IssuerVersion ":" Purpose "@" PurposeVersion "/" ResourceId "@" ResourceKeyVersion NID = "urn" - DIGIT TenantId = 3*(label) TenantVersion = version IssuerId = 3*(label) / 3*(label) ":" 3*(label) / 3*(label) ":" 3*(label) ":" 3*(label) IssuerVersion = version To confirm my understanding here: the TenantId is associated with the software writer who went to the website and requested a new ID. That implementer then manages the uniqueness of the TenantVersion, the IssuerId, and IssuerVersion of the NSS. The latter two are managed by ensuring that each IssuerID minted goes only to a single organization? Is that correct? The tenantID is associated with the implementer of the card issuance scheme. It's functionally similar to a persistent domain name, issued without charge and in perpetuity. The implementer may be a commercial entity, a standards body, or a parent organization of some sort. For example, an organization like the UC system might wish to run their own tenant, with issuer keys given to each particular university within the system. The term tenant is used within the scheme because it's intended to allow key management software to create separate trees in much the way that Gmail and Office 365 have separate tenants within their hosted email solutions. Allowing a single piece of software to have multiple tenants allows for organizational flexibility in terms of division of responsibility. Purpose = 3*(alphanum / other) PurposeVersion = version ResourceId = 1*(alphanum / other) ResourceKeyVersion = version label = loalpha / loalpha *(alphanum / "-") alphanum I am not sure that I understand the ABNF of "label". According to section 3.6 of RFC 5234, * without a minimum or maximum bound can include zero of the following element. That appears to mean that loalpha alphanum would be a legal result. Is that intended, or is the "-" always present? The intent is that the first character in the label must be lowercase alpha. After that, alpha numeric may be used. Dashes may be present, but if present, must be followed by at least one alpha numeric character. version = 2*2(HEXDIG) alphanum = loalpha / DIGIT loalpha = %x61-7A other = "-" / "_" As the full string of the URN is used as an input to the Key Derivation Function, equivalent URNs are impossible. As such, the equivalency rules consist of bit-by-bit comparisons (Simple String Comparison). Assignment: Registration within this NID is private. Implementers will register a Tenant ID, and be responsibile for issuers and sub-issuers within their card issuance tenancy. The web site will be responsible for ensuring that Tenant IDs are unique. Can you specify the website which will issue them? As written, it might be misread to imply that someone else could set up a website to issue these, which could result in collisions. Tenant IDs will be registered, free of charge, through the website "credentsys.cloud". Uniqueness will be guaranteed through a combination of statistical and database-based methods. For example, when issuing management for PIV cards, the keying material used incudes a UUID that is guaranteed mathematically to be unique. In contrast, when deriving GlobalPlatform keys (which use a 10 byte unique ID for the card), issuers will be responsible for keeping a record of all such cards issued and ensuring there are no duplicate IDs. GlobalPlatform keys do not appear to be referenced in the ABNF above. Are these a sub type of the ResourceID? If so, given these examples, is 1 really the minimum number of characters for a ResourceID? That was intended as an example. Different applets and card types provide different identifiers. GlobalPlatform (the most common type of key) only allows 10 characters for derivation. The goal is to ultimately be platform agnostic. Because each issuer is at a unique path within the hierarchal tree, uniqueness is guaranteed as long as they take care not to issue duplicate cards within their own subtree. Security and Privacy: As these identifiers will be used in the generation of cryptographic keys, their opacity does serve to provide a degree of "security through obscurity" for attackers looking to compromise the cards. The loss of that obscurity (for example, if an attacker is able to find a users card ID in the browser history) in theory represents a slight loss of security for the user. Keys for this system will be stored in Hardware Security Modules (HSMs), and configured such that the actual keying material for that level never leaves the cryptographic envelope. Through the use of hash functions that provide strong cryptographic guarantees, and hardware security on the keys themselves, there is no need for the identifiers to be private, and no risk to the user should an attacker somehow gain access to his identifier without having additionally compromised the HSM or a machine connected to the HSM. In a broader sense, the point of this card issuance scheme is to facilitate the issuance of privacy-protecting and security-enhancing credentials to individuals within organizations. Such cards permit strong authentication, as well as multi-factor logins that are resistant to phishing and which enable mutual authentication from the server level. As such, the net effect on Privacy and Security will be positive. Evaluating the system described is beyond the scope of the URN review process, but I will say that the description above seems to place a great deal of stress on the HSM and not much on what other inputs the hash function has and what properties are available to update the hash function used. If you desire such a review, I believe the IETF security area advisory group (saag@ietf.org<mailto:saag@ietf.org>) could provide that. Thank you for the recommendation. Interoperability: The author is not aware of any potential conflicts with this namespace, and given the rather tightly coupled nature of the identifier with the implementation, any overlapping areas of concern for other systems should not present interoperability issues, as there will be no operability. Resolution: Resolution mechanisms are not intended or anticipated for this namespace. Thanks again for submitting the registration. regards, Ted Hardie _______________________________________________ urn mailing list urn@ietf.org<mailto:urn@ietf.org> https://www.ietf.org/mailman/listinfo/urn ________________________________ From: Ted Hardie <ted.ietf@gmail.com> Sent: Monday, March 29, 2021 10:50 AM To: Kate Gray <kate@aerobatt.com> Cc: urn@ietf.org <urn@ietf.org> Subject: Re: [urn] Informal NID registration interest Howdy, Thanks for submitting the registration. I have a couple of questions, inline below. On Sun, Mar 28, 2021 at 3:05 PM Kate Gray <kate@aerobatt.com<mailto:kate@aerobatt.com>> wrote: Hello, I am interested in registering an informal NID for URNs. I have attempted to fill out the template as requested. I apologize if I screwed up somewhere; this is my first time doing this. Namespace Identifier: Assigned by IANA (informal) Version: 1 Date: 2021-03-28 Registrant: Kate Gray <kate&codebykate.com<http://codebykate.com>> 340 S Lemon Ave #5926 Walnut, CA 91789 USA Purpose: The purpose of this NID is to provide a Uniform Resource Name representing derived keys within a card issuance scheme. Specifically, they provide a path within a hierarchal tree representing implementers (referred to as tenants within the system), card issuers (e.g. Universities), optional sub- issuers (e.g. Departments), and individual keys within a card (used for different purposes). These URNs will be used by card manufacturers (to preload data for issuers), as well as issuers and users to refer to the cards and keys throughout the card lifecycle. Good security practices require the use of diversified (per-card) keys, so that an attacker who defeats the security on a card will not have the keys required to attack other cards within the system. A cryptographic module (generally a smart card) can be pre-provisioned with the issuer keys, and the URN for a given key provided to it. With this information and cryptographic keying material, the appropriate keys can be derived, without the host needing to know the issuer keys. While this URN will be implemented into software (including open source software), and published to permit others within the industry to interoperate, it is not expected to become a formal standard, or to be publicly resolvable. The general use will be between actors in a card issuance scheme, for purposes like enabling a vending machine to derive a balance update key for a stored balance wallet on a card, or for a help desk agent to determine the Personal Unblocking Key (PUK) for a user that has lost their PIN. Syntax: All URNs defined under the namespace have the following structure, specified in RFC 7405 ABNF notation[1]: NSS = %s"urn:" NID ":" TenantId "@" TenantVersion ":" IssuerId "@" IssuerVersion ":" Purpose "@" PurposeVersion "/" ResourceId "@" ResourceKeyVersion NID = "urn" - DIGIT TenantId = 3*(label) TenantVersion = version IssuerId = 3*(label) / 3*(label) ":" 3*(label) / 3*(label) ":" 3*(label) ":" 3*(label) IssuerVersion = version To confirm my understanding here: the TenantId is associated with the software writer who went to the website and requested a new ID. That implementer then manages the uniqueness of the TenantVersion, the IssuerId, and IssuerVersion of the NSS. The latter two are managed by ensuring that each IssuerID minted goes only to a single organization? Is that correct? Purpose = 3*(alphanum / other) PurposeVersion = version ResourceId = 1*(alphanum / other) ResourceKeyVersion = version label = loalpha / loalpha *(alphanum / "-") alphanum I am not sure that I understand the ABNF of "label". According to section 3.6 of RFC 5234, * without a minimum or maximum bound can include zero of the following element. That appears to mean that loalpha alphanum would be a legal result. Is that intended, or is the "-" always present? version = 2*2(HEXDIG) alphanum = loalpha / DIGIT loalpha = %x61-7A other = "-" / "_" As the full string of the URN is used as an input to the Key Derivation Function, equivalent URNs are impossible. As such, the equivalency rules consist of bit-by-bit comparisons (Simple String Comparison). Assignment: Registration within this NID is private. Implementers will register a Tenant ID, and be responsibile for issuers and sub-issuers within their card issuance tenancy. The web site will be responsible for ensuring that Tenant IDs are unique. Can you specify the website which will issue them? As written, it might be misread to imply that someone else could set up a website to issue these, which could result in collisions. Uniqueness will be guaranteed through a combination of statistical and database-based methods. For example, when issuing management for PIV cards, the keying material used incudes a UUID that is guaranteed mathematically to be unique. In contrast, when deriving GlobalPlatform keys (which use a 10 byte unique ID for the card), issuers will be responsible for keeping a record of all such cards issued and ensuring there are no duplicate IDs. GlobalPlatform keys do not appear to be referenced in the ABNF above. Are these a sub type of the ResourceID? If so, given these examples, is 1 really the minimum number of characters for a ResourceID? Because each issuer is at a unique path within the hierarchal tree, uniqueness is guaranteed as long as they take care not to issue duplicate cards within their own subtree. Security and Privacy: As these identifiers will be used in the generation of cryptographic keys, their opacity does serve to provide a degree of "security through obscurity" for attackers looking to compromise the cards. The loss of that obscurity (for example, if an attacker is able to find a users card ID in the browser history) in theory represents a slight loss of security for the user. Keys for this system will be stored in Hardware Security Modules (HSMs), and configured such that the actual keying material for that level never leaves the cryptographic envelope. Through the use of hash functions that provide strong cryptographic guarantees, and hardware security on the keys themselves, there is no need for the identifiers to be private, and no risk to the user should an attacker somehow gain access to his identifier without having additionally compromised the HSM or a machine connected to the HSM. In a broader sense, the point of this card issuance scheme is to facilitate the issuance of privacy-protecting and security-enhancing credentials to individuals within organizations. Such cards permit strong authentication, as well as multi-factor logins that are resistant to phishing and which enable mutual authentication from the server level. As such, the net effect on Privacy and Security will be positive. Evaluating the system described is beyond the scope of the URN review process, but I will say that the description above seems to place a great deal of stress on the HSM and not much on what other inputs the hash function has and what properties are available to update the hash function used. If you desire such a review, I believe the IETF security area advisory group (saag@ietf.org<mailto:saag@ietf.org>) could provide that. Interoperability: The author is not aware of any potential conflicts with this namespace, and given the rather tightly coupled nature of the identifier with the implementation, any overlapping areas of concern for other systems should not present interoperability issues, as there will be no operability. Resolution: Resolution mechanisms are not intended or anticipated for this namespace. Thanks again for submitting the registration. regards, Ted Hardie _______________________________________________ urn mailing list urn@ietf.org<mailto:urn@ietf.org> https://www.ietf.org/mailman/listinfo/urn
- [urn] Informal NID registration interest Kate Gray
- Re: [urn] Informal NID registration interest Ted Hardie
- Re: [urn] Informal NID registration interest Kate Gray
- Re: [urn] Informal NID registration interest Ted Hardie
- Re: [urn] Informal NID registration interest Kate Gray
- [urn] Fw: [abnf-discuss] FW: Informal NID registr… Kate Gray