Re: [art] [dispatch] [Secdispatch] Plain text JSON digital signatures

Samuel Erdtman <samuel@erdtman.se> Thu, 06 May 2021 21:00 UTC

Return-Path: <samuel@erdtman.se>
X-Original-To: art@ietfa.amsl.com
Delivered-To: art@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 664E03A319A for <art@ietfa.amsl.com>; Thu, 6 May 2021 14:00:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.896
X-Spam-Level:
X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=erdtman-se.20150623.gappssmtp.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 tT6pK5ILslcx for <art@ietfa.amsl.com>; Thu, 6 May 2021 14:00:44 -0700 (PDT)
Received: from mail-ot1-x332.google.com (mail-ot1-x332.google.com [IPv6:2607:f8b0:4864:20::332]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B0E2C3A319B for <art@ietf.org>; Thu, 6 May 2021 14:00:44 -0700 (PDT)
Received: by mail-ot1-x332.google.com with SMTP id g15-20020a9d128f0000b02902a7d7a7bb6eso6109322otg.9 for <art@ietf.org>; Thu, 06 May 2021 14:00:44 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=erdtman-se.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=sPJTkKFBcS5Raq7fUDsHN1NWyN1I0S1OYR+LQoQJSMQ=; b=FxtnDzyxQWLrvXJhm7k6oRBbymaxHTUPIYqJHhOVBZFBWitfUtU0UapfSckOjpj5iZ abFhBtVf4DP/gNLwzMjeYVDN0ed0wE1QcbXfzz07SXEDyMdZeYPtCBepofT3+k4xCANt ma89NSOmDStd8J6vsIREpYHBFYo0CBW1oPtJuHHlrALnMk2Sg0iIwz8K+VWx2JJ7ybnE wmQ66BETeN23muwB7ZebSAAEGnh7sSuYdtU3/8iEoIE1rjanrMVOxhnpnyLTU3TJt5Al Dp8gHSiJPQwZLbr1Mvf7M10DmYZU1oStYZCbodqDGMCC0KrJg6ORkJ3T+5k73WETWbSn cmcQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=sPJTkKFBcS5Raq7fUDsHN1NWyN1I0S1OYR+LQoQJSMQ=; b=HpnTIxXz8Dn2y2JiB4IG6FUfUZDG7Zbby3+55ohk9DPovo7zvYl/t9CqUa9JduD5gG is+L2uOfr2Sj5BY5GLENazqdabypV2Fx5Y0yzQSD1S6Js0L+SjCCSHfKU/c40GzyyfN7 Sp2869F57aO80nqD61u6tiAmumg6DZdj4NplbzErzlnKX60SkeM2unGzrb/6++fiFyrh iYBeir6CEKDvYh4aH1m/tCn9CweD7Kub9P9fMlLDZDRAFFu/yRv3+p+Gu/wwHfEM3iib SS1DCVt62FcDgWx/9ACRSzze3Uy1VPto6AdFKUclM5LCoSP2LfRSr5RcTnmUXKX0PCVB fHug==
X-Gm-Message-State: AOAM530Pi9B9Zmx6dKmiJBrqmDUpYk+RcIsF5SzWwN6sf/xK6yI1shyZ zeSeKeaL+AVqJjj0G4J6YbXoezAs4C8UU9uuG3CAlA==
X-Google-Smtp-Source: ABdhPJwAed776sRfTR23xrF0xoJkL+fngj8W6S6nDq2BQAsK8PD4pRTEuSwr09+WCkQM3JftQ+oGCMhuCTh6WJdYdus=
X-Received: by 2002:a9d:4b0e:: with SMTP id q14mr5255712otf.254.1620334842872; Thu, 06 May 2021 14:00:42 -0700 (PDT)
MIME-Version: 1.0
References: <CAD9ie-v7uJOpjj+nbZCfQe+4JEQt-6=b6cm57iFPAn_enGeRCQ@mail.gmail.com> <3B394519-4061-43A8-8963-55A6ADEDF269@gmail.com> <19a99964-8495-2de9-b49a-52aa8321c12e@aaa-sec.com> <220475a6-1e04-107e-6327-366d48d8b420@gmail.com> <27833d9d-53c3-d01c-b01c-e7d53424b5ab@aaa-sec.com> <A88D122C-C1EB-477B-A83C-A22F1BB3CC47@gmail.com> <B8E5AF13-7B59-4329-890F-2B14766032A5@tzi.org> <CAF2hCbahPMAwe_63dT+pcz2BZSy0XOPstXqpxsCq1Vj0UmSDPg@mail.gmail.com> <1B4304D2-E82E-4255-B10C-F29ABCABE15E@tzi.org> <CAF2hCbaAx00dxxb2jRmQzVBaW7yyhefQ33+yt0uHwvwt+W_hfw@mail.gmail.com> <CAF2hCbaMz26X4m2vshVzJXkeDWia-53oTocHvxJ4a+1M_=-zAg@mail.gmail.com> <B48FA387-B5E1-4191-B0C3-B92132B18399@tzi.org>
In-Reply-To: <B48FA387-B5E1-4191-B0C3-B92132B18399@tzi.org>
From: Samuel Erdtman <samuel@erdtman.se>
Date: Thu, 06 May 2021 23:00:31 +0200
Message-ID: <CAF2hCbaoyueDmi9if-Yd0J1t7MgsAAdVkrmswRg4gZda9kxDjw@mail.gmail.com>
To: Carsten Bormann <cabo@tzi.org>
Cc: DISPATCH <dispatch@ietf.org>, art@ietf.org, IETF SecDispatch <Secdispatch@ietf.org>, "RFC ISE (Adrian Farrel)" <rfc-ise@rfc-editor.org>
Content-Type: multipart/alternative; boundary="000000000000ba197105c1af9a7e"
Archived-At: <https://mailarchive.ietf.org/arch/msg/art/GjBSj8MU1xzmAaoUj3srmZj88rA>
Subject: Re: [art] [dispatch] [Secdispatch] Plain text JSON digital signatures
X-BeenThere: art@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Applications and Real-Time Area Discussion <art.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/art>, <mailto:art-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/art/>
List-Post: <mailto:art@ietf.org>
List-Help: <mailto:art-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/art>, <mailto:art-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 06 May 2021 21:00:50 -0000

Thanks again Carsten for sharing your thoughts

See comment inline

On Mon, May 3, 2021 at 5:37 PM Carsten Bormann <cabo@tzi.org> wrote:

> On 2021-05-01, at 23:28, Samuel Erdtman <samuel@erdtman.se> wrote:
> >
> > Hi Carsten,
> >
> > One more thing, you wrote "Signing data at rest certainly is a use case
> that is worth addressing.". With my new fond insights (thanks) does this
> mean that you are in favor of specifying how to do enveloped signatures for
> JSON (or at least not against it)?
>
> Signing data at rest doesn’t mean that the signature then needs to be put
> into the signed object.  This is essentially adulterating that object, and
> is part of the XMLDSig “what was just signed?” practicability issue.
>

Agree the signature does not have to go into the signed document, but in my
opinion has its benefits compared to the alternatives. if puting the
signature somewhere else only referencing the signed document it would be
inconvenient to find the signature when needed (yes you could create a
system for that, there likely exists multiple of them all working slightly
differently). The alternative I see would be to create some structure that
would wrap the signed data and the signature but in that way it would not
be much different from the ascii armoring done by normal JWS, I would like
to cater for the use case where you want your doc unchanged apart from the
addition of the signature. (This is my opinion, and I´m okay with not
agreeing)


> (Such as, does my countersignature include the previous signature or not?
> What does it mean to sign a signed object?  Nothing about the existing
> signature, or does it mean I endorse the existing signature, or does it
> mean my signature actually is conditional on the validity of that existing
> signature?)
>

Yes there are questions that would need to be answered, but to me the
questions above would be application questions, what is the specific
application trying to achieve, all of the options would be possible to
technically construct.


>
> I’m not sure though I know what an “enveloped signature” is, and whether
> what I just said above even replies to what I asked.
>

With enveloped signature I was referring to when the document that is
signed will contain the signature opposed to enveloping signatures where
the signature encapsulated the document being signed. (maybe not an
established naming)


>
> Grüße, Carsten
>
>