[ldapext] parsing LDIF: leading spaces

Michael Ströder <michael@stroeder.com> Wed, 30 September 2015 10:21 UTC

Return-Path: <michael@stroeder.com>
X-Original-To: ldapext@ietfa.amsl.com
Delivered-To: ldapext@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com []) by ietfa.amsl.com (Postfix) with ESMTP id EDFF21B2E03 for <ldapext@ietfa.amsl.com>; Wed, 30 Sep 2015 03:21:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.388
X-Spam-Status: No, score=0.388 tagged_above=-999 required=5 tests=[BAYES_50=0.8, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id Ck4lJSjyQ_am for <ldapext@ietfa.amsl.com>; Wed, 30 Sep 2015 03:21:20 -0700 (PDT)
Received: from srv1.stroeder.com (srv1.stroeder.com []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EFB5B1B2E08 for <ldapext@ietf.org>; Wed, 30 Sep 2015 03:21:18 -0700 (PDT)
Received: from srv4.stroeder.local (unknown []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mail.stroeder.local", Issuer "stroeder.com Server CA no. 2009-07" (verified OK)) by srv1.stroeder.com (Postfix) with ESMTPS id 47A341CEAB for <ldapext@ietf.org>; Wed, 30 Sep 2015 10:21:16 +0000 (UTC)
Received: from nb2.stroeder.local (nb2.stroeder.local []) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by srv4.stroeder.local (Postfix) with ESMTPS id 71FC61CF9C for <ldapext@ietf.org>; Wed, 30 Sep 2015 10:21:12 +0000 (UTC)
To: ldapext <ldapext@ietf.org>
From: =?UTF-8?Q?Michael_Str=c3=b6der?= <michael@stroeder.com>
X-Enigmail-Draft-Status: N1110
Message-ID: <560BB797.9040405@stroeder.com>
Date: Wed, 30 Sep 2015 12:21:11 +0200
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 SeaMonkey/2.35
MIME-Version: 1.0
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms050304070000050701060607"
Archived-At: <http://mailarchive.ietf.org/arch/msg/ldapext/mqLkF_ELVUZPD-6oiWUcX_x46Qg>
Subject: [ldapext] parsing LDIF: leading spaces
X-BeenThere: ldapext@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: LDAP Extension Working Group <ldapext.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ldapext>, <mailto:ldapext-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ldapext/>
List-Post: <mailto:ldapext@ietf.org>
List-Help: <mailto:ldapext-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ldapext>, <mailto:ldapext-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 30 Sep 2015 10:21:22 -0000


How does implementors here parse LDIF with *leading* spaces in value-spec
defined in RFC 2849?

value-spec               = ":" (    FILL 0*1(SAFE-STRING) /
                                ":" FILL (BASE64-STRING) /
                                "<" FILL url)
                           ; See notes 7 and 8, below
FILL                     = *SPACE

Since [1] and even its pre-predecessor [2] says that this means zero or more
occurences of SPACE the following gets ambigous:

foo:  bar
foo: bar

One could read RFC 2849 that all these result in the same attribute value
'bar'. But does that meet the expectations or would this cause interop issues?

Before somebody claims that values with leading spaces must be base64-encoded:

from RFC 2849:

      8)  Values or distinguished names that end with SPACE SHOULD be
          base-64 encoded.

This is only a SHOULD and AFAICS it says nothing about leading spaces.

[1] https://tools.ietf.org/html/rfc5234#section-3.6
[2] https://tools.ietf.org/html/rfc2234#section-3.6

Ciao, Michael.