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

[Sean Leonard <[e-mail]>]

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