Re: [Cfrg] Question from JOSE working group

Mike Jones <> Mon, 02 July 2012 18:33 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id AF4D111E80D1 for <>; Mon, 2 Jul 2012 11:33:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -3.783
X-Spam-Status: No, score=-3.783 tagged_above=-999 required=5 tests=[AWL=-0.184, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id tDwoO+ZP0Ume for <>; Mon, 2 Jul 2012 11:33:58 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 98F1F11E80EF for <>; Mon, 2 Jul 2012 11:33:57 -0700 (PDT)
Received: from ( by ( with Microsoft SMTP Server id; Mon, 2 Jul 2012 18:32:05 +0000
Received: from mail88-db3 (localhost []) by (Postfix) with ESMTP id 4F4CE4E05CE; Mon, 2 Jul 2012 18:32:05 +0000 (UTC)
X-Forefront-Antispam-Report: CIP:; KIP:(null); UIP:(null); IPV:NLI;; RD:none; EFVD:NLI
X-SpamScore: -32
X-BigFish: VS-32(zz9371I1b0bM542M1432Izz1202hzz1033IL8275bh8275dhz2fh2a8h668h839h944hd25hf0ah)
Received-SPF: pass (mail88-db3: domain of designates as permitted sender) client-ip=;; ; ;
Received: from mail88-db3 (localhost.localdomain []) by mail88-db3 (MessageSwitch) id 1341253919606124_15011; Mon, 2 Jul 2012 18:31:59 +0000 (UTC)
Received: from (unknown []) by (Postfix) with ESMTP id 900AC240137; Mon, 2 Jul 2012 18:31:59 +0000 (UTC)
Received: from ( by ( with Microsoft SMTP Server (TLS) id; Mon, 2 Jul 2012 18:31:58 +0000
Received: from ([]) by ([]) with mapi id 14.02.0298.005; Mon, 2 Jul 2012 18:33:32 +0000
From: Mike Jones <>
To: "" <>
Thread-Topic: [Cfrg] Question from JOSE working group
Thread-Index: Ac1YgS4wo9tuM20zQ029ZMkY7eroAQ==
Date: Mon, 02 Jul 2012 18:33:31 +0000
Message-ID: <>
Accept-Language: en-US
Content-Language: en-US
x-originating-ip: []
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: "" <>
Subject: Re: [Cfrg] Question from JOSE working group
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Crypto Forum Research Group <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 02 Jul 2012 18:33:58 -0000

Dear cfrg,

Since Richard is providing examples of choices made by other systems, I'll add that XML DSIG does integrity protect the algorithm and other parameters.

				-- Mike

-----Original Message-----
From: [] On Behalf Of Richard L. Barnes
Sent: Monday, July 02, 2012 11:07 AM
Subject: [jose] Fwd: [Cfrg] Question from JOSE working group

FYI, trying to recruit some additional crypto expertise on this question.


Begin forwarded message:

> From: "Richard L. Barnes" <>
> Subject: [Cfrg] Question from JOSE working group
> Date: July 2, 2012 2:00:11 PM EDT
> To:
> Dear CFRG,
> This is a request for input on a crypto question that has come up in the JOSE working group.
> The question is whether there is any benefit to applying integrity protection to cryptographic parameters attached to a signed/authenticated/encrypted object.  By "cryptographic parameters" here, I mean public keys, wrapped symmetric keys, algorithm identifiers, etc.
> For historical background:
> CMS does not provide parameter protection [RFC5652].  The content that is signed / authenticated / encrypted is precisely the protected content (eContent).  Optionally, an application may add signed attributes.  In the case of SignedData and AuthenticatedData, if signed attributes are present, then they must include the message digest that was signed or authenticated; not a parameter, but an intermediate result.
> IKE and TLS does not provide integrity protection for parameters [RFC4306][RFC5246].  Algorithm negotiation is done in parallel with key agreement in the initial phase of IKEv2   Algorithm negotiation in TLS is done in the ClientHello / ServerHello messages, which are sent before the secure channel is established.  When TLS client certificates are used, the client demonstrates its possession of the relevant private key by signing the handshake messages, which provides an integrity check on cryptographic parameters as a side-effect.  However, the parameters for this signature (the public key and signature/hash algorithms) are not protected.
> PKIX is an intermediate case.  The signature algorithm used to sign / verify the certificate is included in the certificate body (under the signature) as well as ouside the signature.
> Back to today:
> The current draft specifications for JOSE [JWS][JWE] require integrity protection for parameters.  The creator of an object constructs a "header" value including the cryptographic parameters used to generate the object.  This header value is prepended to the protected content before the content is signed / authenticated (JWS), or attached as "Associated Data" to the encrypted content (JWE).  (JWE only allows AEAD algorithms.)
> So the questions for this group are the following: 
> -- Does applying integrity protection to cryptographic parameters result in a meaningful increase the security of an secure object format?  
> -- What are the classes of attack that this integrity protection would address?
> -- Does parameter protection create any additional security vulnerabilities?
> Any input would be very helpful for the group to decide on a way forward.
> Thanks a lot,
> --Richard
> [RFC5652] <>
> [RFC4306] <>
> [RFC5246] <>
> [RFC5280] <>
> [JWS] <>
> [JWE] <>
> _______________________________________________
> Cfrg mailing list

jose mailing list