In the course of performing recent draft revisions, I had some
additional questions about the HIT Suite IDs.
http://tools.ietf.org/html/draft-ietf-hip-rfc5201-bis-19#section-5.2.10
Briefly, RFC 7343 specifies that ORCHIDs consist of the special prefix,
a 4-bit Orchid Generation Algorithm (OGA), and a 96-bit hash. RFC 7343
does not ask IANA to set up a registry for OGA values. The RFC states
"... the value of the OGA identifier according to the
document defining the context usage identified by the Context ID."
My read of this is that the assignment of OGA identifiers is delegated
to the documents defining the context usage identified by the Context
ID; in this case, it would be RFC5201-bis.
The HIT Suite ID in RFC5201-bis is used as the OGA ID in HIP. The IANA
considerations section states this, although someone looking explicitly
for assigned OGA values may have to dig for it.
The reason that the HIT Suite ID is not named the 'OGA ID' in HIP is due
to the potential growth capability that is defined in section 5.2.10.
Specifically, the zero value for HIT Suite ID is reserved, to allow for
growth of the field should the four-bit field be exhausted. So it
technically is an 8-bit value, and the 4 higher-order bits are used to
form the OGA (for now).
Basically, the draft is saying that if HIT Suite ID is zero, then this
ORCHID encoding:
ORCHID := Prefix | OGA ID | Encode_96( Hash )
becomes instead:
ORCHID := Prefix | HIT Suite ID | Encode_92( Hash )
and the bits immediately after the Prefix are used also to identify the
length of this OGA ID. It seems to me that this could either be
clarified further in the draft, or simplified.
For clarification, it might be a good idea to add some text that says
more explicitly that the OGA ID is formed by taking the four high-order
bits of the ID found in the HIT_SUITE_LIST, and by making the table read
something like:
HIT Suite 4-bit truncated value 8-bit ID
RESERVED 0 0
RSA,DSA/SHA-256 1 (REQUIRED) 65536
ECDSA/SHA-384 2 (RECOMMENDED) 131072
ECDSA_LOW/SHA-1 3 (RECOMMENDED) 262144
However, I wonder whether the better choice would be to simplify the
current encodings and make it a right-aligned field, keep the value 0 as
reserved, and leave future growth to future updates. The same kind of
growth could be accommodated if the (future) extended OGA ID were
encoded with the nibbles swapped.
Thoughts?
- Tom
_______________________________________________
Hipsec mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/hipsec
