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

Samuel Erdtman <> Thu, 06 May 2021 21:00 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 98D353A319F for <>; Thu, 6 May 2021 14:00:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.896
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=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 6Zzhf_I2nXfW for <>; Thu, 6 May 2021 14:00:44 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4864:20::335]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 84F6B3A319A for <>; Thu, 6 May 2021 14:00:44 -0700 (PDT)
Received: by with SMTP id q7-20020a9d57870000b02902a5c2bd8c17so6131206oth.5 for <>; Thu, 06 May 2021 14:00:44 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; 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;; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=sPJTkKFBcS5Raq7fUDsHN1NWyN1I0S1OYR+LQoQJSMQ=; b=dGRJ6kfZ2s/U9NRiN+S3kS5u3k7F3tXhfjzuvCCBEhSUAUh89Y4C/f+wP2yzm+SSUQ iCOakgnegYZj95DtJmQNoD1LOOFMwQI3bKo1mBKyBcEAis4YBiVpbK8mV6RTgynsLFQI uRmKRgmMdfIp8it8cMRmIRz5FXsVCHcIqy0Thf+EipZEtu69l1Cl+4kfLy8/w2mWsqaM TB+3atk6bWnN/Zx2HkuWRDt2ihsQOcWU4DfFRxGxeDAgGf1kOJUHZAXd4LthqKzn0twb 00Hb2VovxCPMBTWKbahZSoMvTtNQuog14aL24S9wGTGUobfC0PyRW1g9GxEoJQA0I7zL AHHA==
X-Gm-Message-State: AOAM530+zxwHpC/9WCvadZIwCbiAymmnaMUo3/MG4JXfTKrTbkVMy4+/ QXjQiYV0oXM0OpbExJR90vm4SGX95oTJUs7mLNsg23MRzsU=
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: <> <> <> <> <> <> <> <> <> <> <> <>
In-Reply-To: <>
From: Samuel Erdtman <>
Date: Thu, 06 May 2021 23:00:31 +0200
Message-ID: <>
To: Carsten Bormann <>
Cc: DISPATCH <>,, IETF SecDispatch <>, "RFC ISE (Adrian Farrel)" <>
Content-Type: multipart/alternative; boundary="000000000000ba197105c1af9a7e"
Archived-At: <>
Subject: Re: [dispatch] [art] [Secdispatch] Plain text JSON digital signatures
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: DISPATCH Working Group Mail List <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-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 <> wrote:

> On 2021-05-01, at 23:28, Samuel Erdtman <> 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

> (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