[hpke] Re: Clarification on some corner cases of HPKE

[Filippo Valsorda <[e-mail]>]

This again sounds a bit backwards: OpenSSL is pretty popular, if it implements an arbitrary subset of the specification, protocols and applications will need to adapt to this partial API, so the use case will never materialize. It will be generally unpleasant for protocols and applications to discover, though, not being in the spec.

If you think we ought to add these restrictions to HPKE, wouldn't it be more appropriate to propose them for draft-ietf-hpke-hpke, instead of unilaterally implementing them in a popular API?

2026-06-18 01:01 GMT+02:00 Stephen Farrell <[e-mail]>:
> 
> Generalising from what mt said (via highly selective quoting:-)
> 
> On 17/06/2026 23:39, Martin Thomson wrote:
> > is there really a problem?
> 
> I think that's the main question. If there were a real
> thing that needed zero length HPKE plaintexts I'd be fine
> with making a PR (and don't expect that'd be hard). If
> there were real HPKE auth-mode uses that needed a psk_id
> that could have a NUL in the middle, similarly. (Bit of
> a pain to change the API, esp as we may be on the way to
> deprecating auth modes.)
> 
> IIUC, neither situation actually applies though. We can
> of course meanwhile argue the pros/cons (and as I said I
> generally turn out on the losing side of the argument when
> David's on the other;-), but on balance I'm not seeing
> expending effort on OpenSSL PRs as worthwhile now.
> 
> Cheers,
> S.
> 
> 
> _______________________________________________
> hpke mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]
> 
> 
> *Attachments:*
>  • OpenPGP_signature.asc