Re: [jose] Propsoed Signing Procedure
"Jim Schaad" <ietf@augustcellars.com> Sat, 29 June 2013 20:23 UTC
Return-Path: <ietf@augustcellars.com>
X-Original-To: jose@ietfa.amsl.com
Delivered-To: jose@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 00E3B21F9AAE for <jose@ietfa.amsl.com>; Sat, 29 Jun 2013 13:23:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.598
X-Spam-Level:
X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DpeS-zJSkqxF for <jose@ietfa.amsl.com>; Sat, 29 Jun 2013 13:23:16 -0700 (PDT)
Received: from smtp2.pacifier.net (smtp2.pacifier.net [64.255.237.172]) by ietfa.amsl.com (Postfix) with ESMTP id DD04321F9AEC for <jose@ietf.org>; Sat, 29 Jun 2013 13:23:15 -0700 (PDT)
Received: from Philemon (winery.augustcellars.com [206.212.239.129]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: jimsch@nwlink.com) by smtp2.pacifier.net (Postfix) with ESMTPSA id CBE952C9F4; Sat, 29 Jun 2013 13:23:13 -0700 (PDT)
From: Jim Schaad <ietf@augustcellars.com>
To: 'Mike Jones' <Michael.Jones@microsoft.com>, jose@ietf.org
References: <063101ce747e$425dd4f0$c7197ed0$@augustcellars.com> <4E1F6AAD24975D4BA5B1680429673943678A8DDE@TK5EX14MBXC283.redmond.corp.microsoft.com>
In-Reply-To: <4E1F6AAD24975D4BA5B1680429673943678A8DDE@TK5EX14MBXC283.redmond.corp.microsoft.com>
Date: Sat, 29 Jun 2013 13:22:16 -0700
Message-ID: <067301ce7506$59c24300$0d46c900$@augustcellars.com>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_0674_01CE74CB.AD698580"
X-Mailer: Microsoft Outlook 14.0
Thread-Index: AQJ0ZpASfqhOiWpDoSxBqh+0BS1yoALr+1MWl+mye2A=
Content-Language: en-us
Subject: Re: [jose] Propsoed Signing Procedure
X-BeenThere: jose@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Javascript Object Signing and Encryption <jose.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/jose>, <mailto:jose-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/jose>
List-Post: <mailto:jose@ietf.org>
List-Help: <mailto:jose-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/jose>, <mailto:jose-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 29 Jun 2013 20:23:22 -0000
You are making an assumption which is incorrect. This text is in response to a request by you to outline the procedures for not base64 encoding the content. Thus it is completely correct that there no difference between the JWS payload and the JWS encoded payload because under that proposal there isn't any difference. The problem with doing things piecemeal over time is that one forgets things. I was going to add a new section to the document as well X. Content Preparation requirements on the Application Applications need to do a certain amount of preparation of the content before it can be signed. The only content that can be signed is a stream of octet values. How the stream of octet values is represented is specific to the language and, potentially, library being used for the implementation of JWS. Some libraries will provide helper functions that can do the preparation for the application, however the capabilities will vary from library to library and are not covered by this specification. The compact serialization method requires that the content be placed in the base64url character set prior to being signed. This can be done either by the application doing the base64url encoding on the content, or by the application constraining the set of possible values to be signed to those in the base64url character set. Again this is a feature that some libraries will provide helper functions for but how it is done will be library specific. From: Mike Jones [mailto:Michael.Jones@microsoft.com] Sent: Friday, June 28, 2013 9:38 PM To: Jim Schaad; jose@ietf.org Subject: RE: [jose] Propsoed Signing Procedure Your description below confuses the JWS Payload (which can be any octet sequence) and the Encoded JWS Payload (which is the base64url encoded representation of the JWS Payload). For instance, you made a typo in your point 3.c.iii below by writing "JWS Payload" when you meant "Encoded JWS Payload". Likewise, your first point 3 in your proposed 8.1 should be referring to the Encoded JWS Payload - not the JWS Payload. Similarly, you left off the "Encoded" in the second point 3 of your proposed 8.1. Likewise, you are confusing the Encoded Payload and the Payload in your proposed 8.2 text. The payload has to be able to represent any octet stream, which your text doesn't enable. That's why we have the Encoded Payload in the first place. Do you want to revise your proposal to eliminate this confusion, differentiating between the JWS Payload - which can represent any octet sequence, and the JWS Encoded Payload, which is a URL-safe, JSON-string-safe representation of that octet stream? I understand that editorially you're trying to restructure the signing and verification sections to be more agnostic to whether there are multiple signatures. I don't have any issue with that. Thanks, -- Mike From: jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] On Behalf Of Jim Schaad Sent: Friday, June 28, 2013 9:07 PM To: jose@ietf.org; Mike Jones Subject: [jose] Propsoed Signing Procedure I would suggest something along the following lines. It is still missing some of the descriptive text that is required, but not a great deal of it. Jim 5.1 Message signing or MACing To create a JWS, on performs the following steps. The order of the steps is information, however the result of performing the steps is prescriptive. 1. Verify the content to be used as the JWS Payload is an octet stream. If it is not then the fail. 2. If a common signature header field exists, then serialize the object describing the header using UTF-8 and then base64 URL that result. This is now the Encoded JWS Header. 3. For each signature to be created perform the following steps: a. Obtain the algorithm to be used for the signature operation. This may be in the common signature protected header, the common signature unprotected header or the signature header objects. If this is not a legal and supported signature algorithm then fail. b. Verify that the key to be used for the signature operation is compatible with the signature algorithm. c. Concatenate the following values for the octet stream to be signed: i. The Encoded JWS header if it exists, ii. One period character ('.') iii. The JWS payload d. Compute the signature value using the key, the signature algorithm and the octet stream to be signed. e. Base64url encode the signature value, this is the Encoded JWS signature. Section 8.1 Compact serialization In order for a compact serialization to be created, the following conditions must be met: 1. There must be exactly one signer 2. There must not be a common unprotected header field or a signer header field. These can be combined before the signature is created to form the common protected header field. 3. The JWS payload MUST conform to the character set which is used for base64url encoding. This is A-Za-z0-9 (and whatever the rest of them are) The compact serialization is formed by concatenating the following items: 1. The Encoded JWS Header, 2. One period character ('.') 3. The JWS Payload 4. One period character ('.') 5. The Encoded JWS signature Section 8.2 JSON Serialization The JSON serialization is an object with the following members: Protected - a string containing the Encoded JWS Header (OPTIONAL) Unprotected - an object containing any common unprotected header values (OPTINAL) Payload - a string containing the JWS Payload (REQUIRED) Signatures - an array containing one element for each signature created. Each array element consists of an object with the following members: Header - an object containing any signer specific unprotected header values (OPTINAL) Signature - a string containing the Encoded JWS Signature for that signer.
- Re: [jose] Propsoed Signing Procedure Richard Barnes
- [jose] Propsoed Signing Procedure Jim Schaad
- Re: [jose] Propsoed Signing Procedure Mike Jones
- Re: [jose] Propsoed Signing Procedure Jim Schaad