[jose] Comments about WG documents

Massimiliano Pala <massimiliano.pala@gmail.com> Mon, 21 July 2014 17:24 UTC

Return-Path: <massimiliano.pala@gmail.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 DFCA01A0326 for <jose@ietfa.amsl.com>; Mon, 21 Jul 2014 10:24:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level:
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] 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 x8tjOuUZy-le for <jose@ietfa.amsl.com>; Mon, 21 Jul 2014 10:24:21 -0700 (PDT)
Received: from mail-vc0-x236.google.com (mail-vc0-x236.google.com [IPv6:2607:f8b0:400c:c03::236]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E3FB91A0317 for <jose@ietf.org>; Mon, 21 Jul 2014 10:24:18 -0700 (PDT)
Received: by mail-vc0-f182.google.com with SMTP id hy4so12644313vcb.41 for <jose@ietf.org>; Mon, 21 Jul 2014 10:24:17 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=MPBByTRG1EnA6ad6Qv8bMYvmD/EGNwrGV1IaNuzCk0M=; b=RqvM2LZ8o3Mk5vw//8oDNEfCl4duVOcdOadGjrkuTcX3PRO3emQglmotCnaRiezBzt sAmJaNXzki8ZV0wR/5tFfeAB1JDc25Qh+aHBMW9xxY6wYHbR+gBR7zVT67ZEGSDC1w8y SncP+WWJG9yqqUbNyEKgR+qPL3M2kT25mAaFWlJeNiw9EbDlgmmq71syNVHbvDk+SnBd aj8FXtAZWORd0fxgyiBARLwClck8dAkt/KmSDg//IZVLk6bTs2SzuWdptifRxdMd/B8c k4Shq395nBT4BfobazZk+7d1yyuYzYplGnF+cjiLlUjT7NW6BYX9gkziyJ2VyVZF71Te 88eA==
MIME-Version: 1.0
X-Received: by 10.220.144.147 with SMTP id z19mr31413495vcu.26.1405963457707; Mon, 21 Jul 2014 10:24:17 -0700 (PDT)
Received: by 10.58.202.198 with HTTP; Mon, 21 Jul 2014 10:24:17 -0700 (PDT)
Date: Mon, 21 Jul 2014 13:24:17 -0400
Message-ID: <CAJjM7HYNWbeg_42JQKU17DcGfu+_TVE60Z=v+uPcnOGcwmVCjQ@mail.gmail.com>
From: Massimiliano Pala <massimiliano.pala@gmail.com>
To: jose@ietf.org
Content-Type: multipart/alternative; boundary="047d7b34367e76c3eb04feb760e0"
Archived-At: http://mailarchive.ietf.org/arch/msg/jose/3iuKL-2WQDdfXF7_uwd_lqLyWg0
Subject: [jose] Comments about 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 17:25:41 -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