[secdir] Secdir review of draft-josefsson-pkix-textual

Magnus Nyström <magnusn@gmail.com> Tue, 02 December 2014 14:19 UTC

Return-Path: <magnusn@gmail.com>
X-Original-To: secdir@ietfa.amsl.com
Delivered-To: secdir@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com []) by ietfa.amsl.com (Postfix) with ESMTP id 69A4E1A1B98 for <secdir@ietfa.amsl.com>; Tue, 2 Dec 2014 06:19:10 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.699
X-Spam-Status: No, score=-1.699 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, MIME_8BIT_HEADER=0.3, SPF_PASS=-0.001] autolearn=no
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id FA8Jx63kQQcN for <secdir@ietfa.amsl.com>; Tue, 2 Dec 2014 06:19:09 -0800 (PST)
Received: from mail-wi0-x236.google.com (mail-wi0-x236.google.com [IPv6:2a00:1450:400c:c05::236]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DC8891ACDC4 for <secdir@ietf.org>; Tue, 2 Dec 2014 06:19:02 -0800 (PST)
Received: by mail-wi0-f182.google.com with SMTP id h11so21104124wiw.15 for <secdir@ietf.org>; Tue, 02 Dec 2014 06:19:01 -0800 (PST)
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=Si2GKM3nps4yZsBdDv46iju6nGgb3WwqR/pji81u/KE=; b=PVlW/3UELd/nk1PBDr2WhzBZJvZR9ePowN/s5QywrFYTUdc0qXgwBLhizfHQGj9ZP2 xUYz30Msl3RA72ANxckVoU/bkmFJ7e3zQPMucwHveJm4JjKgAucLTB2tHDyiti00387M pShqqgFtgc1X70yX7nlvIwHPANCvHkJc9aO2A+GeF6XrRQ0L9tg0l0b6aWOsSaYddMMY 99zflpaZQrxiy8uFAxR1LCEin6zmO4kPRk4DRcBNdxgMrcqyC7TvwyUEFi/bMypn4kXi lYYLmq66i+yXp0cZny/QRRIr86H+6V/THGPARhywPSRswHQWTI4S5Z3pXs+AjLt6c0Ts Tvrw==
MIME-Version: 1.0
X-Received: by with SMTP id bw19mr9726584wib.69.1417529941523; Tue, 02 Dec 2014 06:19:01 -0800 (PST)
Received: by with HTTP; Tue, 2 Dec 2014 06:19:01 -0800 (PST)
Date: Tue, 2 Dec 2014 15:19:01 +0100
Message-ID: <CADajj4aSUWX9vM+Lc=p26ZvLgc4ws50wpYTEFbf_fFoMzRy+uQ@mail.gmail.com>
From: =?UTF-8?Q?Magnus_Nystr=C3=B6m?= <magnusn@gmail.com>
To: "secdir@ietf.org" <secdir@ietf.org>, draft-josefsson-pkix-textual@tools.ietf.org
Content-Type: multipart/alternative; boundary=f46d043892519f815b05093c68c4
Archived-At: http://mailarchive.ietf.org/arch/msg/secdir/bwBx-04t0NrEnwWur7QxoKQK8yA
Subject: [secdir] Secdir review of draft-josefsson-pkix-textual
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Security Area Directorate <secdir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/secdir>, <mailto:secdir-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/secdir/>
List-Post: <mailto:secdir@ietf.org>
List-Help: <mailto:secdir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 02 Dec 2014 14:19:12 -0000

I have reviewed this document as part of the security directorate's ongoing
effort to review all IETF documents being processed by the IESG. These
comments were written primarily for the benefit of the security area
directors. Document editors and WG chairs should treat these comments just
like any other last call comments.

This memo documents textual encodings of various well-established
PKI-related data structures and formats. The document is intended to be
published as a Standards-Track RFC.
Comments and suggestions:

Section 5.1:
 - For clarity and common keyword usage, suggest replacing "The encoded
data MUST be a BER (DER strongly preferred) encoded ASN.1..." with: "The
encoded data MUST be BER and SHOULD be a DER encoded ASN.1..." (In fact
this comment goes for all places where you have text like "MUST be a BER
(DER [strongly] preferred" - better to use established RFC 2119 language).
- I wonder why you state "Parsers are NOT RECOMMENDED to treat "X509
CERTIFICATE" or "X.509 CERTIFICATE" as equivalent to "CERTIFICATE", but a
valid exception may be for backwards compatibility (potentially together
with a warning)" since to my knowledge, they all refer to the same
structure and in the spirit of "strict in issuance, generous in receipt",
it would seem to be better to state: ""Parsers MAY treat ... as equivalent
- I also wonder about the warning above since if the structure indeed does
parse as a certificate, what value would the warning bring (and to whom)?

Section 5.3:
I disagree with the deprecation of .cer in favor of .crt. The .cer
convention is used broadly. I would suggest updating the text to recommend
use of .crt OR .cer. Better yet, remove the section, since this document
specifically is about textual encodings and not file extension naming and
you do not discuss extension naming elsewhere.

Section 6:
Same comments as for Section 5.1 above, but for CRLs...

Section 7:
Same comment as my first for Section 5.1. I note that you have the same
language with regards to parser flexibility here that I have suggested for
Section 5.1 and Section 6.

Security Considerations:
No particular comments.

-- Magnus