Digests: deprecating parameters?

Lucas Pardue <lucaspardue.24.7@gmail.com> Tue, 18 August 2020 09:52 UTC

Return-Path: <ietf-http-wg-request+bounce-httpbisa-archive-bis2juki=lists.ie@listhub.w3.org>
X-Original-To: ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com
Delivered-To: ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0B6CA3A0141 for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Tue, 18 Aug 2020 02:52:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.997
X-Spam-Level:
X-Spam-Status: No, score=-2.997 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, MAILING_LIST_MULTI=-1, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id R2tJaDI09HdN for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Tue, 18 Aug 2020 02:52:11 -0700 (PDT)
Received: from lyra.w3.org (lyra.w3.org [128.30.52.18]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 30A153A012A for <httpbisa-archive-bis2Juki@lists.ietf.org>; Tue, 18 Aug 2020 02:52:10 -0700 (PDT)
Received: from lists by lyra.w3.org with local (Exim 4.92) (envelope-from <ietf-http-wg-request@listhub.w3.org>) id 1k7yFJ-0000my-Ky for ietf-http-wg-dist@listhub.w3.org; Tue, 18 Aug 2020 09:49:33 +0000
Resent-Date: Tue, 18 Aug 2020 09:49:33 +0000
Resent-Message-Id: <E1k7yFJ-0000my-Ky@lyra.w3.org>
Received: from mimas.w3.org ([128.30.52.79]) by lyra.w3.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from <lucaspardue.24.7@gmail.com>) id 1k7yFG-0000mD-HT for ietf-http-wg@listhub.w3.org; Tue, 18 Aug 2020 09:49:30 +0000
Received: from mail-ed1-x52a.google.com ([2a00:1450:4864:20::52a]) by mimas.w3.org with esmtps (TLS1.3:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92) (envelope-from <lucaspardue.24.7@gmail.com>) id 1k7yFE-000238-Re for ietf-http-wg@w3.org; Tue, 18 Aug 2020 09:49:30 +0000
Received: by mail-ed1-x52a.google.com with SMTP id l23so14717562edv.11 for <ietf-http-wg@w3.org>; Tue, 18 Aug 2020 02:49:28 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to:cc; bh=Sv5aPnMqMEbL4hmLM9qSUNh/yfCN4l8SX1kOHn0VqFw=; b=j7rszl4/CHTiYlHshleWwWjDDuDTaDE6J5LDFktKd0qdl7Ape5iPJEHoyKKiEYi0YX LGYDzQi3ODBDVlhVUXsAj93dNjCo0XFEPn+vMGIDwf2zUrbw51D+s14TsQpn+vYPm/NC ZGH1Uz/gzbPW6yReBMOvxMaWSLf4/LUyh2KEQo976KDP5wgTRox0NBvEr1wdUROSSBOe XhlDK8KOzMYCih5IeStYWdvJk5dJaJOogTAvm3xqBslO3R59Q/Wp3QzoqJg1bDCEs/1Q UtiuDduwkjmWd59UlNx/BV/KlfNs8fejdmNxyQmANPFHaRbCsFYsTMqWmP+Bu7S8h83x F6Fg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to:cc; bh=Sv5aPnMqMEbL4hmLM9qSUNh/yfCN4l8SX1kOHn0VqFw=; b=o/yOuU2gi7eGmUIw5NkhWkeEjU65SSq5eK05+zLtBvA+/7H42YNKLBqTuWEROUdmp3 lDZxtqU+o+aM7F9Fw+d/LCkYZewytdPTMGXeLFyc8odeAfbFAbbkEo0zmO6S4S/HZ6p3 E09f+jIBg61TDKs5kXH1eAa/0ft14J/Yo7oWgJcf8DV8b6IGkllxYskMlgXBRqWdIhKv ng/U39+AmRSJp8WZIOiBdTAPGsDDue+e+jssCD1c3fInyb7ogBPNsYTGR2+jFce9z3oH ++QQuvSS1PjjQRHegj+lQB29ZRSslzCoxXIWtsvDpC8hWDA+WAMFebCwwMUl08nIDbRE RxWw==
X-Gm-Message-State: AOAM533X79Nzs2CsiMt/n3rW8AA78BeHI5fRRtnyjznC7Oa0iPdUAOpD lZJAxnCg7tvwomzPpedEci25pd8t4RpQkpR/ooOFGq18aaPpBQ==
X-Google-Smtp-Source: ABdhPJxhRJ7/JnbtbGam9KHJb9sX9UjhlkdDgQQFO4x3ZcO5KlDiuLmipwzBbRuwbyClfU9fMVmoHBs73aHmsKACk/o=
X-Received: by 2002:a50:9d88:: with SMTP id w8mr18258171ede.122.1597744156921; Tue, 18 Aug 2020 02:49:16 -0700 (PDT)
MIME-Version: 1.0
From: Lucas Pardue <lucaspardue.24.7@gmail.com>
Date: Tue, 18 Aug 2020 10:49:05 +0100
Message-ID: <CALGR9oYCU2b3wiTFV8uNO37opK0XMgq_=D0sTyZVw8kVuKG+4g@mail.gmail.com>
To: HTTP Working Group <ietf-http-wg@w3.org>
Cc: Roberto Polli <robipolli@gmail.com>
Content-Type: multipart/alternative; boundary="000000000000ea514505ad23cc94"
Received-SPF: pass client-ip=2a00:1450:4864:20::52a; envelope-from=lucaspardue.24.7@gmail.com; helo=mail-ed1-x52a.google.com
X-W3C-Hub-Spam-Status: No, score=-7.8
X-W3C-Hub-Spam-Report: BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, W3C_AA=-1, W3C_IRA=-1, W3C_IRR=-3, W3C_WL=-1
X-W3C-Scan-Sig: mimas.w3.org 1k7yFE-000238-Re 00d59cc36d13ab1bb713bf6d18b763dc
X-Original-To: ietf-http-wg@w3.org
Subject: Digests: deprecating parameters?
Archived-At: <https://www.w3.org/mid/CALGR9oYCU2b3wiTFV8uNO37opK0XMgq_=D0sTyZVw8kVuKG+4g@mail.gmail.com>
Resent-From: ietf-http-wg@w3.org
X-Mailing-List: <ietf-http-wg@w3.org> archive/latest/37930
X-Loop: ietf-http-wg@w3.org
Resent-Sender: ietf-http-wg-request@w3.org
Precedence: list
List-Id: <ietf-http-wg.w3.org>
List-Help: <https://www.w3.org/Mail/>
List-Post: <mailto:ietf-http-wg@w3.org>
List-Unsubscribe: <mailto:ietf-http-wg-request@w3.org?subject=unsubscribe>

Hello folks,

We're wondering what the group might think about deprecating the Digest
parameters. Please respond for or against the idea, either here or on the
GitHub issue https://github.com/httpwg/http-extensions/issues/850

*Background*
While updating the Digests spec we've found somewhat of a gap when it comes
to "parameters". These are mentioned in RFC 3230:

   For some algorithms, one or more parameters may be
   supplied.

      digest-algorithm = token

   The BNF for "parameter" is as is used in RFC 2616 [4].  All digest-
   algorithm values are case-insensitive.

It seems wrong to define parameters as part of the algorithm, so we started
on a PR to fix things up. But the discussion moved on to examples and
real-world usage; as far as we can tell there are no canonical examples
either in the specification or on the wild Internet.

Keeping this spec gap seems wrong, so one option we could consider is to
simply deprecate "parameters". For use cases that might have a future need
of such a thing, they could easily define a new algorithm that encodes
their parameters in the digest-value (the encoded checksum) itself.

Please let us know what you think.

Lucas and Roberto
Digest Editors