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. _______________________________________________ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
