Re: [babel] info-model: preparing -09 on github

["STARK, BARBARA H" <[e-mail]>]

> > Is this suggesting that it's ok for info-model to provide babel-hmac
> > with any value between 0 and 64 bytes in length for HMAC-SHA256 or
> > between 0 and 32 bytes in length for Blake2s and babel-hmac can be
> > expected to zero-pad? Or are you still expecting info-model to do the
> > zero-padding before providing to babel-hmac?
> 
> The former.  You give me anything between 0 and 32/64, and I deal with it.

Cool. Then from a purely info-model perspective, it sounds like the key-value parameter length constraints are:

  This value is of a length suitable for the associated
  babel-mac-key-algorithm.  If the algorithm is based on the HMAC
  construction, the length MUST be between 0 and the block size of the
  underlying hash inclusive (where "HMAC-SHA256" block size is 64 bytes
  as described in {{RFC4868}}).
  If the algorithm is "BLAKE2s", the length MUST be between 0 and 32 bytes
  inclusive, as described in {{RFC7693}}.

Anything complying with info-model won't supply anything longer than the identified max length.
A babel-hmac implementation may get something as short as zero length, but will be expected to deal with it. Info-model doesn't care and doesn't need to know what "deal with it" means.
For HMAC and Blake2s algorithms, "deal with it" means hmac-babel will zero-pad shorter strings, because that's what the algorithm RFCs say to do (and not because babel-hmac has any extra requirements going beyond the algorithm specs).
Info-model won't send strings longer than the indicated length. If there is a UI to info model that accepts a longer string, hashes it, and then info-model provides the hashed value, that is what it is. Neither info-model nor babel-hmac care or know or need to know about this.
If a babel-hmac implementation does have special handling for longer strings, that's fine, too. But a value coming from info-model will never trigger this special code.
Does that sound right?
Barbara