[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]