Re: [abnf-discuss] FW: [urn] Informal NID registration interest

Paul Overell <paul@bayleaf.org.uk> Tue, 30 March 2021 16:03 UTC

Return-Path: <paul@bayleaf.org.uk>
X-Original-To: abnf-discuss@ietfa.amsl.com
Delivered-To: abnf-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A4ACA3A1996 for <abnf-discuss@ietfa.amsl.com>; Tue, 30 Mar 2021 09:03:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.898
X-Spam-Level:
X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, NICE_REPLY_A=-0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=bayleaf-org-uk.20150623.gappssmtp.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 wmMB-tTJlPwS for <abnf-discuss@ietfa.amsl.com>; Tue, 30 Mar 2021 09:03:11 -0700 (PDT)
Received: from mail-wm1-x32f.google.com (mail-wm1-x32f.google.com [IPv6:2a00:1450:4864:20::32f]) (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 1CCCA3A1992 for <abnf-discuss@ietf.org>; Tue, 30 Mar 2021 09:02:59 -0700 (PDT)
Received: by mail-wm1-x32f.google.com with SMTP id g20so8665591wmk.3 for <abnf-discuss@ietf.org>; Tue, 30 Mar 2021 09:02:59 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bayleaf-org-uk.20150623.gappssmtp.com; s=20150623; h=subject:to:cc:references:from:message-id :disposition-notification-to:date:user-agent:mime-version :in-reply-to:content-transfer-encoding:content-language; bh=D8z03AI8MNQYE2qlbNmpHEExePNRpZvrHis2R3Iu3kw=; b=RUjrJCZazTrDrhH/gIIF/d4x0xSdCaVGXm+DVxk/+rklUapW8iWy3wJSmS8YtJIzcW jjsz3o0c1rtQys83Ogoo0LbpssRmoXq+58/HAOd2vg0m1za3X+sZ/IfgwGrV/tFObGBr V4gB81ZhhRlGRQFEEKEBeDnqlNXI7M7zfKN1n7Z+Eg6xYCpcYA7XO5gQztsWmALh6b0d GXT4CJMhTaT467uuUO7ee2Ro2vsiqXhCa2n5qzdvauB6XdpPqPENlaehmZrF7LLRpYy1 amB8tdKIRUk567ntevTOA8ajoPgY/6MoBJlecRbFFKA940E1Rf1UlhaJmLI5sr0Zer9Q Lgiw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id :disposition-notification-to:date:user-agent:mime-version :in-reply-to:content-transfer-encoding:content-language; bh=D8z03AI8MNQYE2qlbNmpHEExePNRpZvrHis2R3Iu3kw=; b=AijYRsa1aSCm3iHBg3VWDZOENNZBZojlWvb0HGDE8hH3Ok9rLB3hhp4Hr5ETUStQj7 LA8Bc8O+tZKh7yf0UoV7n+4puAOT7s+40veXT9uH4susvr+7aVlak0EOX73CRjDAPGUK bnx3q/i/31GlX7TxhgMGuZnOjkIMbpju+c7Tq9T0up7O5sfG3t8LUbVVZIzUKwGowYJN SfwN5A75k7FOLPaEakgLS6acrDXpFGXB6dVzlFTlTZLsPSwfSapGvEG26AzwMqYEEQeB rGMLjyO+WA+oB0M4ytM7644cKqyYMoY2WFRcf+l+TsYhmE1oIoJG08RqVgjEaIRm/TDk VBZA==
X-Gm-Message-State: AOAM530wof4JCi7LD7h3qiW4et2L1Y4NKwFkyBE/VZmbmMnt3zqyjZCe U5Q1NDcBeiRQwFLABCQ1Nd/7Est1NJq1sveJ
X-Google-Smtp-Source: ABdhPJzKeOjlYLEQUfPsvnZlysK2jDUJXJkiEuFT/QrXQhP0V0hnv6mMrGzhnhq7pr9H19fOt8aqhQ==
X-Received: by 2002:a7b:cb55:: with SMTP id v21mr4799363wmj.188.1617120177511; Tue, 30 Mar 2021 09:02:57 -0700 (PDT)
Received: from linux-r5ig.lan (173.254.7.51.dyn.plus.net. [51.7.254.173]) by smtp.gmail.com with ESMTPSA id g9sm34877784wrp.14.2021.03.30.09.02.56 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 30 Mar 2021 09:02:57 -0700 (PDT)
To: Francesca Palombini <francesca.palombini=40ericsson.com@dmarc.ietf.org>, "abnf-discuss@ietf.org" <abnf-discuss@ietf.org>
Cc: "kate@aerobatt.com" <kate@aerobatt.com>
References: <63D60ED7-CB73-46E1-937A-56CD3F99C35E@ericsson.com>
From: Paul Overell <paul@bayleaf.org.uk>
Message-ID: <301948cc-46fe-54a5-ea2d-befca88ca0e6@bayleaf.org.uk>
Date: Tue, 30 Mar 2021 17:02:56 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.8.0
MIME-Version: 1.0
In-Reply-To: <63D60ED7-CB73-46E1-937A-56CD3F99C35E@ericsson.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Content-Language: en-GB
Archived-At: <https://mailarchive.ietf.org/arch/msg/abnf-discuss/cQRux5bQBhWKBVUIohc3spbBHEA>
Subject: Re: [abnf-discuss] FW: [urn] Informal NID registration interest
X-BeenThere: abnf-discuss@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "General discussion about tools, activities and capabilities involving the ABNF meta-language" <abnf-discuss.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/abnf-discuss>, <mailto:abnf-discuss-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/abnf-discuss/>
List-Post: <mailto:abnf-discuss@ietf.org>
List-Help: <mailto:abnf-discuss-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/abnf-discuss>, <mailto:abnf-discuss-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 30 Mar 2021 16:03:16 -0000

Hi,

I've commented on the syntax of the ABNF, but I can't comment on the 
correctness of the ABNF for this particular application as I'm not 
familiar with it.  Need some examples of NSS strings.

Comments inline


Regards

On 30/03/2021 14:48, Francesca Palombini wrote:
> Hi all,
>
> The URN mailing list just got this registration request, which contains ABNF - if any of the ABNF experts has time to review it, I think it would be helpful to the author (in CC).
>
> Francesca
>
> ---
> https://mailarchive.ietf.org/arch/msg/urn/RiNCn4BYeY6xoilYpiGdDBUd0QQ/
>
> [urn] Informal NID registration interest
> Kate Gray Sun, 28 March 2021 09:01 UTC
>
> 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>
>      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

The alternative operator "/" has the lowest precedence, adding some 
extra redundant parentheses might make the scope of the alternative clearer.

>      NID                = "urn" - DIGIT

This is not correct ABNF syntax.  The "-" is used in value ranges, not 
sure what the intent is here.  Also "urn" here is case insensitive 
whereas in NSS it is case sensitive, is that the intent?

>      TenantId           = 3*(label)

Assuming the intent is "at least three labels": the parentheses are not 
wrong, but are not required here, 3*label is sufficient. However, as a 
label is of indefinite length and can start and end with a loalpha there 
is no way to spot when one label ends and another one begins.

>      TenantVersion      = version
>      IssuerId           = 3*(label) / 3*(label) ":" 3*(label) / 3*(label) ":" 3*(label) ":" 3*(label)

Comment as above.

>      IssuerVersion      = version
>      Purpose            = 3*(alphanum / other)
>      PurposeVersion     = version
>      ResourceId         = 1*(alphanum / other)
>      ResourceKeyVersion = version
>      label              = loalpha / loalpha *(alphanum / "-") alphanum
>      version            = 2*2(HEXDIG)
Not wrong, but 2HEXDIG is sufficient.  Note that HEXDIG is case 
insensitive.  Does this matter?
>      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.
>
>      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.
>
>      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.
>
> 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.
>
> _______________________________________________
> abnf-discuss mailing list
> abnf-discuss@ietf.org
> https://www.ietf.org/mailman/listinfo/abnf-discuss

-- 
Paul Overell