[jose] Question regarding RFC 7515
Arshad Noor <arshad.noor@strongkey.com> Wed, 02 December 2020 03:26 UTC
Return-Path: <arshad.noor@strongkey.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 BF9213A0FB2 for <jose@ietfa.amsl.com>; Tue, 1 Dec 2020 19:26:54 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
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 b8cE8ECqRvE6 for <jose@ietfa.amsl.com>; Tue, 1 Dec 2020 19:26:53 -0800 (PST)
Received: from mailhost.strongkey.com (mailhost.strongkey.com [65.49.77.134]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7FC8A3A0FAE for <jose@ietf.org>; Tue, 1 Dec 2020 19:26:53 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by mailhost.strongkey.com (Postfix) with ESMTP id 4766C180631C5C for <jose@ietf.org>; Tue, 1 Dec 2020 19:26:53 -0800 (PST)
Received: from mailhost.strongkey.com ([127.0.0.1]) by localhost (mailhost.strongkey.com [127.0.0.1]) (amavisd-new, port 10032) with ESMTP id wBMEnjki1xjD; Tue, 1 Dec 2020 19:26:52 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by mailhost.strongkey.com (Postfix) with ESMTP id C87D2180744773; Tue, 1 Dec 2020 19:26:52 -0800 (PST)
X-Virus-Scanned: amavisd-new at mailhost.strongkey.com
Received: from mailhost.strongkey.com ([127.0.0.1]) by localhost (mailhost.strongkey.com [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id 1iNcQ4xlvBrl; Tue, 1 Dec 2020 19:26:52 -0800 (PST)
Received: from atlas3.noorhome.net (mailhost.strongauth.com [172.1.63.233]) by mailhost.strongkey.com (Postfix) with ESMTPSA id 92F90180631C5C; Tue, 1 Dec 2020 19:26:52 -0800 (PST)
To: jose@ietf.org
From: Arshad Noor <arshad.noor@strongkey.com>
Organization: StrongKey
Message-ID: <d12dfc98-bf1a-66dc-6d60-0b53887114e7@strongkey.com>
Date: Tue, 01 Dec 2020 19:26:52 -0800
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.4.0
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/jose/6EH2pyiWikqGtt3A8A_N-YKf5nY>
X-Mailman-Approved-At: Wed, 02 Dec 2020 05:30:51 -0800
Subject: [jose] Question regarding RFC 7515
X-BeenThere: jose@ietf.org
X-Mailman-Version: 2.1.29
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: <https://mailarchive.ietf.org/arch/browse/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: Wed, 02 Dec 2020 03:27:31 -0000
Hi, I have a few questions on the use of the "x5c" header parameter for which there is insufficient guidance. 1) Section 4.1.6 (X.509 Certificate Chain) states that the "..chain is represented as a JSON array..". However, it is not clear whether a single certificate still needs to be enclosed within an array if one is using a self-signed certificate, and when using "Flattened JWS JSON Serialization Syntax". 2) Section 6 (Key Identification) states that "..Header parameters .. "x5c" .. MUST be integrity protected if the information ...is to be utilized in a trust decision. I take this to read that, when using the flattened JWS JSON serialization, "x5c" must be included in the "protected" attribute. In Section 4.1.1 (Algorithm), the RFC states "This Header Parameter MUST be present .." and in Section 5.1 (Message Signature), "..(algorithm) Header Parameter MUST be present in the JOSE Header..". This implies that "alg" is part of the "protected" section of the JWS. However, there is no guidance on how the "protected" attribute must be encoded when both, "alg" and "x5c" are present in the JWS. It seems logical that it would be encoded as a sub-JSON object; but there is neither any guidance nor an example of what is canonical here. Second, if one creates a sub-JSON for "protected" in a "Flattened" JWS, should the "protected" attribute remain in text form or should it be Base64Url encoded before being signed? 3) Appendix B shows an example of an X.509 Certificate Chain using Base64-encoded strings to represent certificates. While this will work with most code, is there any rationale for departing from the PKI industry practice of using PEM encoded certificates for textual representations (considering the JWS JSON Serialization is not concerned with space limitations)? This advice is mandated in Section 4.1.5 for "x5u", referencing Section 6.1 of RFC 4945, but not so for "x5c". Thank you. Arshad Noor StrongKey
- [jose] Question regarding RFC 7515 Arshad Noor
- Re: [jose] Question regarding RFC 7515 Anders Rundgren