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

OK, if that's the intent, then it should be added to the instructions for
the DE in IANA considerations

On Fri, Jun 9, 2023 at 11:36 AM Justin Richer <jricher@mit.edu> wrote:

> 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