KDF API review, round 2

[Anthony Scarpino]

On 11/27/2017 11:16 AM, Jamil Nimeh wrote:

> I thought that we had ditched setParameter in favor of putting these 
> parameters in getInstance.  IIRC we were headed toward an algorithm 
> naming convention of <KDF>/<PRF>, plus APS in the getInstance (which may 
> be null (and might be for most KDFs that we start with: HKDF and 
> possibly TLS-PRF).
> 
> For those I could see naming conventions:
> HKDF would need a PRF specifier, so HKDF/HmacSHA256, HKDF/HmacSHA384.  
> Basically for that PRF field I want to see values that line up with Mac 
> algorthms in the standard names document.
> TLS-PRF would probably allow a default "TLS-PRF" would be TLS-PRF used 
> in 1.1 and earlier.  "TLS-PRF/SHA256" would be P_SHA256 from RFC 5246.  
> Or we could make it also follow the Mac standard name, so 
> "TLS-PRF/HmacSHA256".  I'm fine with that too.  Basically each 
> implementation


When the naming convention first came up, I never got around to 
replying.  I think it would be better to specify the KDF and PRF as 
separate parameters.  I don't think it's worth creating an naming 
convention given what we have/are experiencing with Cipher 
transformations, it's simpler to spell out each one separately.

Tony