Re: [woes] Proposed charter, post-Quebec edition

John Bradley <> Thu, 04 August 2011 13:29 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id A699421F8788 for <>; Thu, 4 Aug 2011 06:29:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -3.548
X-Spam-Status: No, score=-3.548 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id Qnw+qrKdauzQ for <>; Thu, 4 Aug 2011 06:29:38 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 6784A21F8726 for <>; Thu, 4 Aug 2011 06:29:38 -0700 (PDT)
Received: by qyk15 with SMTP id 15so1006574qyk.10 for <>; Thu, 04 Aug 2011 06:29:53 -0700 (PDT)
Received: by with SMTP id fz1mr576032qab.345.1312464592304; Thu, 04 Aug 2011 06:29:52 -0700 (PDT)
Received: from [] ([]) by with ESMTPS id 1sm1338926qcy.31.2011. (version=TLSv1/SSLv3 cipher=OTHER); Thu, 04 Aug 2011 06:29:51 -0700 (PDT)
Mime-Version: 1.0 (Apple Message framework v1244.3)
Content-Type: multipart/signed; boundary="Apple-Mail=_D43A7525-9DB0-4A93-8597-4D548C657C49"; protocol="application/pkcs7-signature"; micalg=sha1
From: John Bradley <>
In-Reply-To: <>
Date: Thu, 4 Aug 2011 09:29:46 -0400
Message-Id: <>
References: <> <> <>
To: Phillip Hallam-Baker <>
X-Mailer: Apple Mail (2.1244.3)
Subject: Re: [woes] Proposed charter, post-Quebec edition
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "Web Object Encryption and Signing \(woes\) BOF discussion list" <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 04 Aug 2011 13:29:39 -0000

HMAC is requirement for adoption in the JWS use cases.

If we want to describe it as something other than a "Qualified Digital Signature",  that is fine as long as it is MTI:)

John B.

On 2011-08-04, at 9:12 AM, Phillip Hallam-Baker wrote:

> On Thu, Aug 4, 2011 at 9:03 AM, Sean Turner <> wrote:
> On 8/2/11 7:13 PM, Paul Hoffman wrote:
> Here is a proposal for the charter based on the discussion in the BoF last week and later discussion with Sean Turner. Comments, praise, scorn, etc., are welcome.
> --Paul and Richard
> Javascript Object Signing and Encrypting (jose)
> ===============================================
> Background
> ----------
> Javascript Object Notation (JSON) is a text format for the serialization of structured data described in RFC 4627. The JSON format is often used for serializing and transmitting structured data over a network connection. With the increased usage of JSON in protocols in the IETF and elsewhere, there is now a desire to offer security services such as encryption and digital signatures for data that is being carried in JSON format.
> Different proposals for providing such security services have already been defined and implemented. This Working Group's task is to standardize two security services, encrypting and digitally signing, in order to increase interoperability of security features between protocols that use JSON.  The Working Group will base its work on well-known message security primitives (e.g., CMS), and will solicit input from the rest of the IETF Security Area to be sure that the security functionality in the JSON format is correct.
> This group is chartered to work on four documents:
> 1) A Standards Track document specifying how to apply a JSON-structured digital signature to data, including (but not limited to) JSON data structures. "Digital signature" is defined as a hash operation followed by a signature operation using asymmetric keys.
> I just want to make sure that we agree now that a digital signature is a hash followed by a signature algorithm (e.g., RSA with SHA-256).  I've seen a couple of drafts that tried to say an HMAC (e.g., HMAC-SHA256) was a digital signature; one called it a symmetric key based digital signature algorithm (note this phrase didn't get through the IESG).
> An HMAC is not a digital signature, but the spec definitely needs to be able to cover MAC based authentication.
> I know that public key is getting easier as far as computation goes. But for many applications the non-repudiation you get in digital signatures is actually undesirable.
> There are interesting tricks you can do with symmetric crypto that are much harder to do in public key and end up with some scheme that only 50 academics in the world can follow and has a security proof that rest on rather esoteric assumptions.
> -- 
> Website:
> _______________________________________________
> woes mailing list