Re: Martin Duke's No Objection on draft-ietf-httpbis-message-signatures-17: (with COMMENT)

Hi Martin, thanks for the comment.

> On Jun 7, 2023, at 7:09 PM, Martin Duke via Datatracker <noreply@ietf.org> wrote:
> 
> Martin Duke has entered the following ballot position for
> draft-ietf-httpbis-message-signatures-17: No Objection
> 
> When responding, please keep the subject line intact and reply to all
> email addresses included in the To and CC lines. (Feel free to cut this
> introductory paragraph, however.)
> 
> 
> Please refer to https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/ 
> for more information about how to handle DISCUSS and COMMENT positions.
> 
> 
> The document, along with other ballot positions, can be found here:
> https://datatracker.ietf.org/doc/draft-ietf-httpbis-message-signatures/

> 
> 
> 
> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
> 
> What is the position on including national crypto and other potentially
> compromised algorithms? Section 6.2 doesn't demand that the DE evaluate
> algorithm security, but section 7.3.1 says "The HTTP Message Signatures
> Algorithm Registry is one source of trusted signature algorithms for
> applications to apply to their messages."
> 
> I could see a case for including not-provably secure algorithms in the registry
> to avoid squatting, assuming they are fully specified, but if this were the
> case the registry probably needs a recommended/non recommended field.
> 


Thanks - Roman pointed out something similar. The nature of this registry is to provide one place for fully defined algorithms to be used by applications that don’t have their own algorithm definitions, or need to use the “alg” field for interoperability with each other. An insecure or compromised algorithm shouldn’t be added to the registry in the first place - and if it was at one point, then it should be marked as “Deprecated” by the current IANA guidance by some update.

Roman’s suggested alternative labels - “Recommended” and “Not recommended”, if I understand correctly, to mirror what TLS uses. I’m amenable to shifting the labels on the registry if it means we’re giving clearer guidance to implementors.

 — Justin

Received on Friday, 9 June 2023 18:37:04 UTC