Re: [jose] Issues with the WG documents
"Jim Schaad" <ietf@augustcellars.com> Mon, 21 July 2014 15:59 UTC
Return-Path: <ietf@augustcellars.com>
X-Original-To: jose@ietfa.amsl.com
Delivered-To: jose@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 660CF1A02DE for <jose@ietfa.amsl.com>; Mon, 21 Jul 2014 08:59:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham
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 6UncpMoqzh1E for <jose@ietfa.amsl.com>; Mon, 21 Jul 2014 08:59:08 -0700 (PDT)
Received: from smtp1.pacifier.net (smtp1.pacifier.net [64.255.237.171]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9FF641A02E2 for <jose@ietf.org>; Mon, 21 Jul 2014 08:59:07 -0700 (PDT)
Received: from Philemon (dhcp-a0c4.meeting.ietf.org [31.133.160.196]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: jimsch@nwlink.com) by smtp1.pacifier.net (Postfix) with ESMTPSA id B33B72CA03; Mon, 21 Jul 2014 08:59:06 -0700 (PDT)
From: Jim Schaad <ietf@augustcellars.com>
To: 'Massimiliano Pala' <director@openca.org>, jose@ietf.org
References: <53CD2D56.4010604@openca.org>
In-Reply-To: <53CD2D56.4010604@openca.org>
Date: Mon, 21 Jul 2014 11:56:52 -0400
Message-ID: <0a2e01cfa4fc$6586f150$3094d3f0$@augustcellars.com>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_0A2F_01CFA4DA.DE777430"
X-Mailer: Microsoft Outlook 14.0
Thread-Index: AQF0YsbrEUMga8kAbz+wTO0a0JDy2JxhMmXQ
Content-Language: en-us
Archived-At: http://mailarchive.ietf.org/arch/msg/jose/tWsDaSVESSuXd5rzeSp0iekMmjc
Subject: Re: [jose] Issues with the WG documents
X-BeenThere: jose@ietf.org
X-Mailman-Version: 2.1.15
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: Mon, 21 Jul 2014 15:59:11 -0000
From: jose [mailto:jose-bounces@ietf.org] On Behalf Of Massimiliano Pala Sent: Monday, July 21, 2014 11:10 AM To: jose@ietf.org Subject: [jose] Issues with the WG documents Hello Jose WG, I just review the WG document in the effort of understanding the features that are being addressed and the inter-WG possible interoperability capabilities and / or issues. I have to apologize for not being able to participate to the WG efforts before. Unfortunately, it seems (IMHO) that much of the previous work that has been done in the security area, most noticeable by the PKIX WG, has been practically ignored. In particular (and please forget me if I am raising points that have already been addressed in the past - if so, please provide me with references so that I can understand these choices), here's the overall general issues that I found throughout the documents: * Duplication of Registration for Algorithm Identifiers (cross-application). This is particularly bad because the use of text identifiers (even if it is specified that they should be unique), might be "overloaded" in their usage because of the chosen names. Those identifiers (as today written in the docs) are similar to the description, rather than IDs * Format-Dependent content protection - This seems to be an over-engineering of the format where not needed - i.e., content is content, not JSON without spaces on one line content. * Algorithm Agility - I find it odd that, with all the work that has been done in the past for moving from specifying algorithm to providing specs for extensible algorithms field has been ignored (e.g., fixed SHA-1 and SHA-256 specification for certificate identifiers * Interoperability with PKIX formats. No effort, AFAIK, has been done (at least reflected in the documents) about format translation from the structures used from the PKIX group into JSON - that would provide a more useful tool for integrating JSON into existing cryptographic libraries (ease of deployment and format interoperability) This work would be out of scope for the JOSE working group. The documents more closely correspond to those found in the CMS work from the S/MIME working group than anything found in PKIX. Jim Last, I found it very weird the following notation: ASCII(BASE64(.)) since the BASE64 is an ASCII representation, what does the ASCII() specs mean in this case and why it is needed? Best Regards, Dr. Pala
- [jose] Issues with the WG documents Massimiliano Pala
- Re: [jose] Issues with the WG documents Jim Schaad