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

Martin Rex <mrex@sap.com> Sat, 28 January 2012 00:37 UTC

Return-Path: <mrex@sap.com>
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 76DA521F850F; Fri, 27 Jan 2012 16:37:48 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.131
X-Spam-Level:
X-Spam-Status: No, score=-10.131 tagged_above=-999 required=5 tests=[AWL=0.118, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-8]
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 zjJjNP1dXi2m; Fri, 27 Jan 2012 16:37:48 -0800 (PST)
Received: from smtpde01.sap-ag.de (smtpde01.sap-ag.de [155.56.68.170]) by ietfa.amsl.com (Postfix) with ESMTP id A759421F84C9; Fri, 27 Jan 2012 16:37:47 -0800 (PST)
Received: from mail.sap.corp by smtpde01.sap-ag.de (26) with ESMTP id q0S0bkw5004367 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Sat, 28 Jan 2012 01:37:46 +0100 (MET)
From: Martin Rex <mrex@sap.com>
Message-Id: <201201280037.q0S0bjqe004577@fs4113.wdf.sap.corp>
To: paul.hoffman@vpnc.org (Paul Hoffman)
Date: Sat, 28 Jan 2012 01:37:45 +0100 (MET)
In-Reply-To: <028B4903-E2C7-41BA-9C9A-B416A41C4E8F@vpnc.org> from "Paul Hoffman" at Jan 27, 12 10:20:42 am
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8bit
X-SAP: out
Cc: simon@josefsson.org, apps-discuss@ietf.org, pkix@ietf.org
Subject: Re: [apps-discuss] [pkix] PKIX text encodings
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
Reply-To: mrex@sap.com
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: Sat, 28 Jan 2012 00:37:48 -0000

Paul Hoffman wrote:
> 
> 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.

Not necessarily.  If your ASN.1 decoder can not distinguish your private
from your public key, then you have a whole different kind of problem.


>
> I propose this is not a good idea from a security perspective.

Huh?  That textual label is not integrity protected in any way,
so how should this be a security problem?

This is really only about convenience for admins.


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

HUH?  How could being liberal on *INPUT* possibly cause problems?

Any reasonable ASN.1 decoder can reliably tell apart
  - X.509 certificates
  - private keys
  - encrypted private keys
  - pkcs10 requests
  - crls
  - pkcs7/cms 
  - pkcs7/cms as certificate bag
  - pkcs7/cms as crl bag
  - pkcs12

So any implementation that is ignoring the explicit label, will have to
use the implicit label from successfuly ASN.1 decode of the types
of objects that are applicable for the requested operation.


Microsoft seems to ignore the label.  If you double-click on
a pkcs7 file (extension .p7s or .p7b) it will be PEM-decoded independent
of what label is used.  Same for certificate (.cer).


I find it much more confusing when only a few, but non-unique labels
are accepted:
OpenSSL seems to accept certs with "X509 CERTIFICATE" and "CERTIFICATE"
and PKCS7 as "PKCS7" or "CERTIFICATE" but _not_ "X509 CERTIFICATE"


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

For OUTPUT we should try to find an reuse the most commonly used label,
because the installed base is going to be with us another 10+ years.


-Martin