On Jun 25, 2014, at 1:24 AM, Francis Dupont <[email protected]> wrote:
> Suresh Krishnan writes: > >> Summary: This draft is almost ready for publication as a Proposed >> Standard but I have a comment you might wish to address. >> * Section 2 >> >> The Encode_96 function mentions that the output is obtained by >> "extracting the middle 96-bit long bitstring" from the argument. This >> seems to be in conflict with Appendix E of RFC5201bis where the HIT suite >> 3 recommends truncation of the hash to 96 bits. Shouldn't this just be a >> truncation function? > > => Encode_96 is a truncation function because it takes a continuous > part of the input, or with other words truncated allows to truncate > one at one end, or twice. I agree it is not the usual/default truncation > function which takes the first bits. So IMHO there is no conflict, > even one can argue RFC5201bis is not enough accurate. (*) > > BTW all truncation functions are not really equivalent from a > crypto point of view but in this particular use case it doesn't matter. > > To finish the Orchid v1 (RFC4843) uses an Encode_100 with the middle > 100 bits. > > Regards > > Francis Dupont <[email protected]> > > PS (*): RFC5201bis misses the 128 bit Context ID in the hash input > so there is already a conflict. > > PPS for Julien: at line 289 > OLD > ORCHID := Prefix | Encode_96( Hash ) > NEW > ORCHID := Prefix | OGA ID | Encode_96( Hash ) Oh! That’s quite a mistake, this has been introduced while rebuilding the XML by hand earlier end of last year… Will need to fix this ASAP. Thanks for catching this, Francis! —julien _______________________________________________ Gen-art mailing list [email protected] https://www.ietf.org/mailman/listinfo/gen-art
