Re: [ldapext] Fwd: New Version Notification for draft-stroeder-mailboxrelatedobject-06.txt

Sean Leonard <dev+ietf@seantek.com> Sun, 05 October 2014 21:53 UTC

Return-Path: <dev+ietf@seantek.com>
X-Original-To: ldapext@ietfa.amsl.com
Delivered-To: ldapext@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1C1791A0070 for <ldapext@ietfa.amsl.com>; Sun, 5 Oct 2014 14:53:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.301
X-Spam-Level:
X-Spam-Status: No, score=-2.301 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001] autolearn=ham
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 NLev_MeneyXr for <ldapext@ietfa.amsl.com>; Sun, 5 Oct 2014 14:53:37 -0700 (PDT)
Received: from mxout-08.mxes.net (mxout-08.mxes.net [216.86.168.183]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E955E1A006F for <ldapext@ietf.org>; Sun, 5 Oct 2014 14:53:36 -0700 (PDT)
Received: from [192.168.123.7] (unknown [23.240.242.6]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 9A347509B5; Sun, 5 Oct 2014 17:53:35 -0400 (EDT)
Message-ID: <5431BDBA.70506@seantek.com>
Date: Sun, 05 Oct 2014 14:52:58 -0700
From: Sean Leonard <dev+ietf@seantek.com>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.1.2
MIME-Version: 1.0
To: =?windows-1252?Q?Michael_Str=F6der?= <michael@stroeder.com>, ldapext@ietf.org
References: <20140926115934.25447.2865.idtracker@ietfa.amsl.com> <542558EB.4000709@stroeder.com> <5425848B.3040504@seantek.com> <54258E77.4010004@stroeder.com> <54258F68.7010109@stroeder.com> <54314F09.6080408@seantek.com> <5431B5BE.9030103@stroeder.com>
In-Reply-To: <5431B5BE.9030103@stroeder.com>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 8bit
Archived-At: http://mailarchive.ietf.org/arch/msg/ldapext/fecPPoatV-ps8wSoOfadYYc9qQM
Subject: Re: [ldapext] Fwd: New Version Notification for draft-stroeder-mailboxrelatedobject-06.txt
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: <http://www.ietf.org/mail-archive/web/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: Sun, 05 Oct 2014 21:53:38 -0000

On 10/5/2014 2:18 PM, Michael Ströder wrote:
> Sean Leonard wrote:
>> On 9/26/2014 9:08 AM, Michael Ströder wrote:
>>> Michael Ströder wrote:
>>>> Personally I consider PKCS#9 to be seriously flawed. E.g. defining as
>>>> GeneralizedTime is bad design. Yuck!
>>> Should have been: "defining dateOfBirth as GeneralizedTime"
>>>                           ^^^^^^^^^^^
>> Hi Michael, I just wanted to follow up on this. What exactly is the problem
>> with GeneralizedTime?
> There's no real semantics using a time part for dateOfBirth and matching will
> be incorrect.
>
> Furthermore I'm strongly against arbitrarily using zeroed time in case of
> unknown birth time.

Well what can I say. I'm not going to defend it. I wasn't involved in 
the 80s when GeneralizedTime was created, nor was I involved in the 90s 
when PKCS #9 came out. Suffice to say, the protocol designers had those 
tools available to them at the time, and they ran with it. The ASN.1 
TIME type was not invented until 2004. Too late now.

RFC 3739 says:

       The dateOfBirth attribute SHALL, when present, contain the value
       of the date of birth of the subject.  The manner in which the date
       of birth is associated with the subject is outside the scope of
       this document.  The date of birth is defined in the
       GeneralizedTime format and SHOULD specify GMT 12.00.00 (noon) down
       to the granularity of seconds, in order to prevent accidental
       change of date due to time zone adjustments.  For example, a birth
       date of September 27, 1959 is encoded as "19590927120000Z".
       Compliant certificate parsing applications SHOULD ignore any time
       data and just present the contained date without any time zone
       adjustments.



This seems like a reasonable compromise under the circumstances and is 
not "arbitrary" since regardless of the time zone of the receiver, it 
would be interpreted as the same date anyway.

Sean