Re: [certid] Comments on draft-saintandre-tls-server-id-check-03

Martin Rex <mrex@sap.com> Tue, 11 May 2010 22:47 UTC

Return-Path: <mrex@sap.com>
X-Original-To: certid@core3.amsl.com
Delivered-To: certid@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 82E403A6940 for <certid@core3.amsl.com>; Tue, 11 May 2010 15:47:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.765
X-Spam-Level:
X-Spam-Status: No, score=-7.765 tagged_above=-999 required=5 tests=[AWL=-0.116, BAYES_50=0.001, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 22la80t+6la7 for <certid@core3.amsl.com>; Tue, 11 May 2010 15:47:44 -0700 (PDT)
Received: from smtpde03.sap-ag.de (smtpde03.sap-ag.de [155.56.68.140]) by core3.amsl.com (Postfix) with ESMTP id AA5363A6858 for <certid@ietf.org>; Tue, 11 May 2010 15:47:43 -0700 (PDT)
Received: from mail.sap.corp by smtpde03.sap-ag.de (26) with ESMTP id o4BMlVtp007747 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for <certid@ietf.org>; Wed, 12 May 2010 00:47:31 +0200 (MEST)
From: Martin Rex <mrex@sap.com>
Message-Id: <201005112247.o4BMlUH3011595@fs4113.wdf.sap.corp>
To: certid@ietf.org
Date: Wed, 12 May 2010 00:47:30 +0200 (MEST)
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8bit
X-Scanner: Virus Scanner virwal08
X-SAP: out
Subject: Re: [certid] Comments on draft-saintandre-tls-server-id-check-03
X-BeenThere: certid@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
Reply-To: mrex@sap.com
List-Id: Representation and verification of identity in certificates <certid.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/certid>, <mailto:certid-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/certid>
List-Post: <mailto:certid@ietf.org>
List-Help: <mailto:certid-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/certid>, <mailto:certid-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 11 May 2010 22:47:51 -0000

Jeff Hodges wrote:
>
> > The various standards for translating a DER encoded Name into
> > a string call for the RDNs to be ordered, left to right, from
> > most specific to most general, the reverse of the order in which
> > they appear in the DER encoded certificate.
>
> AFAICT, there is only one clear non-implementation-specific
> specification for a X.500/LDAP DN string representation,
> and that's (now) RFC4514 (obsoletes 2253, which obsoleted 1779,
> which obsoleted 1485). Is there a DN string rep specified
> anywhere in the ISO specs (I can't find one)?

The description above oversimplifies the process.

In ASN.1 a distinguished name is a sequence of RDNames, which are
sets of attribute-value pairs.  Often these sets only contain a
single attribute value pair, but they _can_ contain several
attribute value pairs, and some CA software seems to stuff
serialNumber and CN into a single RDName set.

The result is a little weird.  Multiple attribute-value pairs
in a set are glued together with a plus (+) sign instead of a
comma (,) and the original ordering of the set is retained!
(where as the ordering of the RDName elements is reversed).

Further complicating the issue: While DER encoding leaves the ordering
of the contents of an ASN.1 SEQUENCE as is, the ordering of the contents
of an ASN.1 SET is "canonicalized" by DER encoding (based on the
numeric ordering of the final binary encoding of each element).
So the shorter elements will always end up first in RDNames
containing multiple attribute-value pairs in a SET.

i.e.

     CN=Foo+2.5.4.5=123ABC,O=bar,C=ZZ
     2.5.4.5=227DEF+CN=LongName,O=bar,C=ZZ


Btw. the XMLdsig guys actually recommend an additional restriction
on top of rfc4514:

  http://www.w3.org/TR/xmldsig-core/#dname-encrules


One area that may create slight interop problems with some legacy software
is the printable attribute label used for certain attributes.

   rfc4514
   SN=        2.5.4.surname(4)
   2.5.4.5=   2.5.4.serialNumber(5)
   ST=        2.5.4.stateOrProvince(8)

The string representation also does not carry through the
"simple type" used in the original ASN.1 DER encoding
(like PrintableString,IA5String,UTF8String,BMPString).


-Martin