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

<magnusn@gmail.com> Thu, 11 December 2014 16:30 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 [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 00A741A1F04; Thu, 11 Dec 2014 08:30:53 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.018
X-Spam-Level:
X-Spam-Status: No, score=-0.018 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, FREEMAIL_REPLY=1, HTML_FONT_FACE_BAD=0.981, 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 6FFJDHerbpRf; Thu, 11 Dec 2014 08:30:51 -0800 (PST)
Received: from mail-pd0-x236.google.com (mail-pd0-x236.google.com [IPv6:2607:f8b0:400e:c02::236]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D9A851A6FC7; Thu, 11 Dec 2014 08:30:50 -0800 (PST)
Received: by mail-pd0-f182.google.com with SMTP id p10so5307810pdj.27 for <multiple recipients>; Thu, 11 Dec 2014 08:30:50 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:mime-version:from:to:cc:subject:importance:date :in-reply-to:references:content-type; bh=U15brPKdTKReW0bg6UkYSbirEFmZfvASAbngRq3Y0Iw=; b=dHcNZeqEvmmaepYbzXANKbubHllXEyfdJqcDjsVbRBC3b69OVSSoQj43liyTNTo11E Wwa2PiG5+iXNHVE0bBGAa/gK2rhwGL39CUbWTqYjhx5ncsauOcx5f26n8fwHG7utWHxs d5b9IrbjaEdn0FGsJfBjscKvTAVjhLTC1fQ/96PWNDwsd0z325sW+IYkD0iBh5fmeeGp mN2wnYvFNPsRl24BBtnloqpT6c0IoSXuJ+CL1n0IWPKoMY32EJP+yg5W9AerOELkLahs jRChYik6WI/ok+EmOM7xweK6HXZhGTZ0dXc2ymm7vbZz4a6rX6iWO3nV8LvDsZleM32p qLPg==
X-Received: by 10.68.208.65 with SMTP id mc1mr18274172pbc.111.1418315449657; Thu, 11 Dec 2014 08:30:49 -0800 (PST)
Received: from MAGNUSDevbox2.ntdev.corp.microsoft.com ([2001:4898:80e8:ee31::2]) by mx.google.com with ESMTPSA id bn13sm1851535pdb.4.2014.12.11.08.30.47 for <multiple recipients> (version=TLSv1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Thu, 11 Dec 2014 08:30:48 -0800 (PST)
Message-ID: <5489c6b8.6d59460a.0f26.4799@mx.google.com>
MIME-Version: 1.0
From: <magnusn@gmail.com>
To: =?utf-8?Q?Yoav_Nir?= <ynir.ietf@gmail.com>
Importance: Normal
Date: Thu, 11 Dec 2014 16:26:34 +0000
In-Reply-To: <715DF31C-F5BF-4DBC-8D0F-6595F7B1F692@gmail.com>
References: <CADajj4aSUWX9vM+Lc=p26ZvLgc4ws50wpYTEFbf_fFoMzRy+uQ@mail.gmail.com>, <715DF31C-F5BF-4DBC-8D0F-6595F7B1F692@gmail.com>
Content-Type: multipart/alternative; boundary="_9B80DCDA-2DDE-40F1-A071-AC2F13C01694_"
Archived-At: http://mailarchive.ietf.org/arch/msg/secdir/mg5JbPbPaw1ATvhfsJxkyFxGrxE
Cc: =?utf-8?Q?The_IESG?= <iesg@ietf.org>, "=?utf-8?Q?draft-josefsson-pkix-textual@tools.ietf.org?=" <draft-josefsson-pkix-textual@tools.ietf.org>, "=?utf-8?Q?secdir@ietf.org?=" <secdir@ietf.org>
Subject: Re: [secdir] =?utf-8?q?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: Thu, 11 Dec 2014 16:30:53 -0000

Thanks Yoav,

I don’t want to create a long thread here, but just to note my thinking on the two aspects you comment on:

On the first one, IMHO we shouldn’t introduce new language in addition to 2119. If there is a “good case” for saying preferred, then I also think there is a good case for saying “SHOULD.”

On the .cer and .crt, I maintain that the document should stick to what its purpose is, which is “textual encodings of the Public-Key Infrastructure X.509 (PKIX), Public-Key Cryptography Standards (PKCS), and Cryptographic Message Syntax (CMS)”. Introducing deprecations for file extensions seems not only to be far away from that but also without thought-through consequences.






Sent from Windows Mail





From: Yoav Nir
Sent: ‎Wednesday‎, ‎3‎ ‎December‎, ‎2014 ‎04‎:‎01
To: Magnus Nyström
Cc: secdir@ietf.org, draft-josefsson-pkix-textual@tools.ietf.org, The IESG




Hi Magnus



[adding IESG]




See below





On Dec 2, 2014, at 4:19 PM, Magnus Nyström <magnusn@gmail.com> wrote:




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).





In general (this is not a hard and fast rule) a SHOULD should come with an explanation of when it isn’t needed. Unless we have a good case for saying when it’s OK to use non-DER, I’d rather stick with the non-2119 “prefer”.







- 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 to "CERTIFICATE" “ ?




I’ll leave this to the authors to answer.







- 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)?




ditto





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.




IDK. These formats are used mostly in files, and despite twenty years of attempts, classification by extension is still the norm. .cer files often contain either BER or a textual representation, while .crt tends to mostly be textual. I don’t see why we shouldn’t document this convention.





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


Yoav