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

[Paul Overell <[e-mail]>]

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
> [e-mail]
> https://www.ietf.org/mailman/listinfo/abnf-discuss

-- 
Paul Overell