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

From: Kate Gray <[email-masked]>
Date: Tue, 30 Mar 2021 21:40:45 +0000

Hello,

I'm travelling for the next few days but will put together a more comprehensive list of examples when I arrive.  I need to do that for testing that the syntax matches anyway.

While I'm doing so, I suppose I should ask - what is the difference between "formal" and "informal" URN registrations, other than the numbered NID?  The goal of this effort is to fill a need, specifically to provide a way to reference keys within a path with a persistent, unique, and useful identifier.

Towards that end, it might make sense for us to have this within a structure in which partners and those within the industry have the say - for example, set up an open committee for allocating tenant IDs, and discussion of standards around it.  Interoperability (as we've seen with the PIV standard) brought a lot of benefits - the same card can be used without third party drivers on Windows, Mac, (or using OpenSC) Linux.  It easily does SSH, SSL client certificates, S/MIME, etc.

The missing link (and what's especially harming adoption in the small and mid-size organizations) is to a large extent the difficulties with card issuance, and part of that is a lack of standardization on tools, and ways to manage the keys.  This is a piece of that much larger puzzle, and perhaps it would make sense to try to go for a formal NID, managed by a formal committee, that can have KDF URNs under it's NID, as well as other standards at a future date, if the needs of the community require it.

As a technical consultant and security engineer, I've helped organizations do this kind of thing internally.  This is the first time that I've worked with an organization that wants to think bigger, and is open to sharing the tools, information, methods, etc. out there - trying to drive the adoption of hardware security as an industry and as a planet, rather than trying to just protect their own internal services.

Thank you for your patience,

Kate
________________________________
From: Paul Overell <[email-masked]>
Sent: Tuesday, March 30, 2021 12:02 PM
To: Francesca Palombini <francesca.palombini=[email-masked]>; [email-masked] <[email-masked]>
Cc: Kate Gray <[email-masked]>
Subject: Re: [abnf-discuss] FW: [urn] Informal NID registration interest

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

--
Paul Overell