[urn] Informal NID registration interest

[Kate Gray <[e-mail]>]

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
    NID                = "urn" - DIGIT
    TenantId           = 3*(label)
    TenantVersion      = version
    IssuerId           = 3*(label) / 3*(label) ":" 3*(label) / 3*(label) ":" 3*(label) ":" 3*(label)
    IssuerVersion      = version
    Purpose            = 3*(alphanum / other)
    PurposeVersion     = version
    ResourceId         = 1*(alphanum / other)
    ResourceKeyVersion = version
    label              = loalpha / loalpha *(alphanum / "-") alphanum
    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.

    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.