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

From: Sean Leonard <[email-masked]>
Date: Sun, 05 Oct 2014 07:00:41 -0700

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 are over half a dozen standardized 
ways to represent dates and times in ASN.1 (probably over a dozen 
including CHOICE types invented over the years). For its purpose, 
however, GeneralizedTime gets the job done. It's been around since 
X.208:1984, so everybody should support it.

-Sean

---

From: Michael Ströder <[email-masked]>
Date: Sun, 05 Oct 2014 23:18:54 +0200

Sean Leonard wrote:
> 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.

Ciao, Michael.

---

From: Sean Leonard <[email-masked]>
Date: Sun, 05 Oct 2014 14:52:58 -0700

> Furthermore I'm strongly against arbitrarily using zeroed time in case of

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

---

From: Michael Ströder <[email-masked]>
Date: Mon, 06 Oct 2014 09:04:30 +0200

Sean Leonard wrote:
> Well what can I say.

We should better discuss that in a followup to your message announcing
draft-seantek-ldap-pkcs9-00.txt.

Ciao, Michael.

---

From: Kurt Zeilenga <[email-masked]>
Date: Sun, 26 Oct 2014 06:03:14 -0700

> On Oct 5, 2014, at 2:52 PM, Sean Leonard <[email-masked]> wrote:
> 
> 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.

I note it would surely represent the wrong date in +13 and +14 timezones.   To be safe, one has to extract the date using the UTC (Z) timezone.

-- Kurt

---

From: Sean Leonard <[email-masked]>
Date: Sun, 26 Oct 2014 08:18:33 -0700

On 10/26/2014 6:03 AM, Kurt Zeilenga wrote:
>
>> On Oct 5, 2014, at 2:52 PM, Sean Leonard <[email-masked] 
>> <mailto:[email-masked]>> wrote:
>>
>> 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.
>
> I note it would surely represent the wrong date in +13 and +14 
> timezones.   To be safe, one has to extract the date using the UTC (Z) 
> timezone.

Ok...so is the point that "dateOfBirth" should have been constrained or 
encoded differently, such as:
#1 a string with the pattern YYYY-MM-DD (i.e., not GeneralizedTime, 
since GeneralizedTime apparently requires a time spec, X.680:2008 Clause 
46), or
#2 some structured data, such as a SEQUENCE of three integers for year, 
month, and date, or a NumericString using spaces as delimiters?

I note that the new TIME type (X.680:2008 Clause 38) allows for 
arbitrary time specifications, including YEAR-MONTH-DAY (X.680:2008 
Annex B). And that TIME was not invented at the time when dateOfBirth 
came out.

If that is the point, I see the objection. I also find it difficult to 
accept that "dateOfBirth" was defined incorrectly, given the state of 
the technology at the time. It could have been a lot worse.

Sean

---

From: Kurt Zeilenga <[email-masked]>
Date: Sun, 26 Oct 2014 08:41:29 -0700

> On Oct 26, 2014, at 8:18 AM, Sean Leonard <[email-masked]> wrote:
> 
> Ok...so is the point that "dateOfBirth" should have been constrained or encoded differently, such as:
> #1 a string with the pattern YYYY-MM-DD (i.e., not GeneralizedTime, since GeneralizedTime apparently requires a time spec, X.680:2008 Clause 46), or
> #2 some structured data, such as a SEQUENCE of three integers for year, month, and date, or a NumericString using spaces as delimiters?
> 
> I note that the new TIME type (X.680:2008 Clause 38) allows for arbitrary time specifications, including YEAR-MONTH-DAY (X.680:2008 Annex B). And that TIME was not invented at the time when dateOfBirth came out.
> 
> If that is the point, I see the objection. I also find it difficult to accept that "dateOfBirth" was defined incorrectly, given the state of the technology at the time. It could have been a lot worse.

My point is that a minor clarification to RFC 3739 would be appropriate, if and when its updated, to note that parsers MUST also decode the date in the UTC timezone to avoid shifting of the date due to timezone differences (such as in +14).  Or, if this approach was used in LDAP (which is what I recommend), a comment in the LDAP spec would be appropriate at this time.

-- Kurt

---

From: Sean Leonard <[email-masked]>
Date: Sun, 26 Oct 2014 08:44:49 -0700

> My point is that a minor clarification to RFC 3739 would be appropriate, if and when its updated, to note that parsers MUST also decode the date in the UTC timezone to avoid shifting of the date du…

Ok, got it. I will notify the RFC 3739 authors (which I am doing now).

As for my own ldap-pkcs9 draft, I will add clarifying text on the matter.

(I would be fine with making dateofBirth a CHOICE between 
GeneralizedTime and another type such as the ones mentioned above. 
However, there would be interoperability issues.)

Sean

---

From: Michael Ströder <[email-masked]>
Date: Mon, 27 Oct 2014 10:55:35 +0100

> My point is that a minor clarification to RFC 3739 would be appropriate, if and when its updated, to note that parsers MUST also decode the date in the UTC timezone to avoid shifting of the date du…

To clarify: Implementations calculating the age of a person must entirely
ignore the time part and simply compare to the local date. At least that't
current practice when calculating the age based on date of birth  in a passport.

Ciao, Michael.