Re: [urn] Informal NID registration interest

[Ted Hardie <[e-mail]>]

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