nts_lib

[Hal Murray]

I think we need to change the names in the enum types in order to avoid 
potential name collisions.

Things like AEAD_AES_128_GCM are likely to appear in OpenSSL and/or we are 
likely to go looking for them there.  There are actually 2 name spaces for 
that sort of thing, 2 different enums.  One is for OpenSSL.  The other is for 
protocols like NTS-KE that use an IANA managed list.

I'd probably put an NTS_KE_ in front of all the record_types, IANA_ on the 
crypto list, and NTP_EX_ on the NTP extension types.


I'm about to start work on the NTS-KE client.  Mostly, I'll be copying and 
cleaning up stuff from my hacks.  What I need after I get the connection setup 
is a routine that appends a record to a buffer.  I'm not solid on what I want 
for an API.  nts_record_form with record_bits doesn't look right.

There is a difference between NTS-KE and NTP extensions.  NTP extensions are 
padded out to a word (4 byte) boundary.  That's probably an extra argument.  
(or the NTS-KE caller could backup over the padding)

I think what I want is a buffer block/struct with:
  base pointer and length
  current pointer
  maybe space used or left

Maybe:
  ntp_append_record(&buffer-blk, type, length, &data, pad)
It would byte-swap and append the type and length, copy the data, and maybe 
pad.
It would silently truncate if it didn't fit.
The caller could check for nothing left after putting everything in to see if 
it overflowed.

On receive, I think I want a ntp_next_record that would return the type, store 
the length iand pointer to data in arguments, and bump the pointer to the next 
record.  It can't copy the data anyplace because I don't know where I want to 
put it until I dispatch on the type.

We probably want special routines that handle the data being a 2 byte int.

--------

Eric:

  I'm still not happy with your nts_decorate and nts_validate.  We can sort 
that out later.

  On receive, I'm assuming that something like ntp_next_record will leave the 
caller with a pointer to the data in the raw packet.  Obviously it has to get 
copied over if it is going to be saved, but things like decoding a cookie can 
be done in place.

Similarly, on transmit ntp_append_record will put things into the raw packet buffer starting after the fixed format header.

We have to verify that we can encrypt/decrypt in place.


-- 
These are my opinions.  I hate spam.