Re: [apps-discuss] [pkix] PKIX text encodings

Paul Hoffman <paul.hoffman@vpnc.org> Fri, 27 January 2012 18:20 UTC

Return-Path: <paul.hoffman@vpnc.org>
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E9B2421F867D; Fri, 27 Jan 2012 10:20:47 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.553
X-Spam-Level:
X-Spam-Status: No, score=-102.553 tagged_above=-999 required=5 tests=[AWL=0.046, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MrlyerkvEQfu; Fri, 27 Jan 2012 10:20:45 -0800 (PST)
Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id 09AE621F8647; Fri, 27 Jan 2012 10:20:45 -0800 (PST)
Received: from [10.20.30.103] (50-0-66-4.dsl.dynamic.fusionbroadband.com [50.0.66.4]) (authenticated bits=0) by hoffman.proper.com (8.14.5/8.14.3) with ESMTP id q0RIKhO7054128 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 27 Jan 2012 11:20:43 -0700 (MST) (envelope-from paul.hoffman@vpnc.org)
Mime-Version: 1.0 (Apple Message framework v1251.1)
Content-Type: text/plain; charset=us-ascii
From: Paul Hoffman <paul.hoffman@vpnc.org>
In-Reply-To: <201201271811.q0RIB5Wu012578@fs4113.wdf.sap.corp>
Date: Fri, 27 Jan 2012 10:20:42 -0800
Content-Transfer-Encoding: quoted-printable
Message-Id: <028B4903-E2C7-41BA-9C9A-B416A41C4E8F@vpnc.org>
References: <201201271811.q0RIB5Wu012578@fs4113.wdf.sap.corp>
To: Simon Josefsson <simon@josefsson.org>
X-Mailer: Apple Mail (2.1251.1)
Cc: PKIX <pkix@ietf.org>, "apps-discuss@ietf.org Discuss" <apps-discuss@ietf.org>
Subject: Re: [apps-discuss] [pkix] PKIX text encodings
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: General discussion of application-layer protocols <apps-discuss.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/apps-discuss>
List-Post: <mailto:apps-discuss@ietf.org>
List-Help: <mailto:apps-discuss-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 27 Jan 2012 18:20:50 -0000

On Jan 27, 2012, at 10:11 AM, Martin Rex wrote:

> the Label that is used within '-----BEGIN <some-label>----'
> should be ignored on the receiver side, and all implemented formats
> should be tried, that are applicable for the requested operation.

This would cause things like private keys and public keys to be mixed up. I propose this is not a good idea from a security perspective. Instead, Simon might add some text saying that some applications sometimes ignore the label in order to be more liberal, but in doing so can cause problems with systems that assume those labels are important.

> 
> Normally, these PEM-framed base64 encodings are used for administrative
> interfaces used by humans that are used with a low frequency,
> rather for authentication exchanges that are used with a high
> frequency. For administrative user interfaces it is usually sensible to
> spend a few extra CPU cycles to improve the usability.
> 
> Strongly recommeding standardized labelling on output of these formats
> is OK, and may facilitate troubleshooting.
> 
> But on input, e.g. when processing a certification response, the
> administrative interface should IMO be tolerant to accept a single
> certificate (provided the remaining certs required to build a
> complete path are already present), accept a sequence of several
> certificates, or a PKCS#7 container carry multiple certificates,
> independent of what labels are used with BEGIN/END.

These are all separate issues, but definitely worthy of discussion in the document. "Some systems will accept multiple certificates in a single text block, while others will reject the entire text block as malformed if more than one certificate is included."

> When the administrative interface has access to the PKI credentials
> for which a certification response is to be processed, then it
> can detect the end-entity cert automatically, compose the full
> and correctly ordererd certificate chain automatically, and ignore
> any superfluous/unrelated certs that may have been part of the input.
> 
> 
> Btw. PKCS#7 can also be used as a carry bag for multiple CRLs,
> which can be used to allow revocation checking in offline
> scenarios or on isolated networks.


Indeed.

Just a thought: we define *new* labels that do what we think everyone should do, such as multiple items in the block. There would not be much uptake on those new labels in the short run, but could become the standard 20 years from now.

--Paul Hoffman