[saag] A simpler form of OID

Phillip Hallam-Baker <[email protected]>
Newsgroups gmane.ietf.saag
Message-ID <CAMm+LwiAc3VCB84nKUctAni2ANG5N1ERraXT0jnpO3w8ZfagTg@mail.gmail.com>
The one thing I really, really like from ASN.1 that I haven't seen an
equivalent of in XML or JSON is the OID, an extensible identifier format
whose length is self describing. That is a building block I would really
like in any binary protocol.

The downside of OIDs is of course the need for a registry, the format is
fiddly, etc. etc. But I do really like the notion that I can simply splice
a variable length sequence of octets into a stream and be guaranteed I have
a unique ID.

So I had a bunch of thoughts on using variants for the purpose and suddenly
realized there is a much simpler approach than specifying the conversion of
integers to strings of octets: The octet sequence is sufficient.

So a type identifier is simply a sequence of octets in which the final
octet is even and all the others are odd, e.g:

[00]
[01 00]
[23 13 68]
[67 25 93 93 42]

This would be backed by an IANA registry (of course) with the following
rules:

Number of Octets

1-2: Standards Action Required [Special]
3-4: Standards Action Required
5-6: Specification and expert review Required
7-15: First come first served.
16-64: Open Season

What this approach allows me to do is to make use of a temporary
unregistered identifier derived from a hash in development and switch
painlessly to a compact identifier in production.

This would overcome a problem with ni where a binary algorithm field was
specified with... 64 entries which has been mostly filled up.

I would see the initial registry entries being very limited, just the bare
essentials:

[32]: SHA-3-AES-GCM
[34]:  SHA-3-AES-GCM in DARE Envelope
[80]: SHA-3-512
[81 00]: SHA-3-256
[82]: SHA-3-512 in DARE Envelope
[104]: Random nonce
[96]: SHA-2-512
[97 00]: SHA-2-256

Basic principle here being, only the items that are expected to be used a
lot get a single byte identifier, only for applications where there is
going to be direct human impact and only the highest security version of
any algorithms.

If people want to declare code points for everything they feel they might
want to use, they can but this is subtly discouraged.

Given that our production of major cryptographic algorithms is about two
per decade and there are good reasons not to expect that to accelerate very
much, it should be at least a millenium before the single octet identifiers
are exhausted.

_______________________________________________
saag mailing list -- [email protected]
To unsubscribe send an email to [email protected]
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.