[jose] Issues with the WG documents

Massimiliano Pala <director@openca.org> Mon, 21 July 2014 15:10 UTC

Return-Path: <director@openca.org>
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 262181A0172 for <jose@ietfa.amsl.com>; Mon, 21 Jul 2014 08:10:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 2.093
X-Spam-Level: **
X-Spam-Status: No, score=2.093 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FH_HOST_EQ_D_D_D_D=0.765, HELO_MISMATCH_NET=0.611, HOST_EQ_IT=1.245, HOST_EQ_STATICB=1.372, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=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 orUpgjbuYOT5 for <jose@ietfa.amsl.com>; Mon, 21 Jul 2014 08:10:22 -0700 (PDT)
Received: from mo.hackmasters.net (static-217-133-36-163.clienti.tiscali.it [217.133.36.163]) by ietfa.amsl.com (Postfix) with ESMTP id 4092D1A026A for <jose@ietf.org>; Mon, 21 Jul 2014 08:10:19 -0700 (PDT)
Received: from nyc.openca.org (dragon.hackmasters.net [127.0.0.1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by mo.hackmasters.net (Postfix) with ESMTPS id 4586341E00B6 for <jose@ietf.org>; Mon, 21 Jul 2014 17:10:17 +0200 (CEST)
Received: from localhost (unknown [127.0.0.1]) by nyc.openca.org (Postfix) with ESMTP id 33945154AEA0 for <jose@ietf.org>; Mon, 21 Jul 2014 15:10:16 +0000 (UTC)
X-Virus-Scanned: amavisd-new at openca.org
Received: from nyc.openca.org ([127.0.0.1]) by localhost (blackmamba.openca.dyndns.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id T3HcnoFMV2zO for <jose@ietf.org>; Mon, 21 Jul 2014 11:10:15 -0400 (EDT)
Received: from dhcp-b553.meeting.ietf.org (BlackMamba.OpenCA.DynDNS.Org [127.0.0.1]) (using TLSv1 with cipher ECDHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by nyc.openca.org (Postfix) with ESMTPSA id 16CCB154AE33 for <jose@ietf.org>; Mon, 21 Jul 2014 11:10:15 -0400 (EDT)
Message-ID: <53CD2D56.4010604@openca.org>
Date: Mon, 21 Jul 2014 11:10:14 -0400
From: Massimiliano Pala <director@openca.org>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0
MIME-Version: 1.0
To: jose@ietf.org
Content-Type: multipart/alternative; boundary="------------000000000100000009080207"
Archived-At: http://mailarchive.ietf.org/arch/msg/jose/fvao9_3miayKm85ysFOUQu0FR9A
Subject: [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:10:24 -0000

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)


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