Subject: Re: dnQualifier topic - not solved yet.

From: Stefan Santesson <[email-masked]>
Date: Tue, 30 Nov 1999 13:41:36 +0100

Magnus and I have had discussions on this topic.

Going through what have been said lately, together with some of-list
comments, convince us that we actually have a rough consensus that
everybody can live with.

And that is to use the serialNumber attribute.

The good thing about selecting serialNumber is that it is widely
implemented anyway, it works and it has a short OID.

But our choice of this attribute should also be a clear signal to the X.500
folks that we want to have X.520 and X.521 updated and fixed so this
attribute is clearly related, not only to devices, but to any type of object.

So if nobody strongly object to this I will go ahead and include this in
the QC profile and I assume that rfc 2459 will be updated accordingly

The proposal was previously presented as:
> I suggest that we:
> 
> - Add serialNumber to son of rfc2459 supportedAttributes as a MUST
> implement attribute (i.e. compliant applications MUST be able to understand
> it).
> 
> - Keep dnQualifier in son of rfc2459, with a note stating it's intended
> purpose, the fact that new certificates should not break this intended
> usage, and also saying that clients should expect that some existing
> certificates may use this attribute to hold any type of value.
> 
> - specify use of serialNumber but NOT dnQualifier in the Qualified
> Certificates profile.
> 
> It would help to get your immediate support for this. Can you live with it??
> 
> /Stefan

With respect to inclusion in rfc2459, David Kemp wrote:
>Yes.  If dnQualifier remains in son of rfc2459 a requirement level will
>have to be specified.  I believe dnQualifier should be omitted entirely
>from the PKIX profile or be included at the MAY level with the usage note.
>But if there is a constituency for keeping it at the SHOULD or 
>MUST level (in addition to serialNumber), I could live with that.

I can live with both ways, so lets leave that up to the rfc2459 editors to
resolve.

/Stefan

-------------------------------------------------------------------
Stefan Santesson                <[email-masked]>
Accurata AB                     http://www.accurata.se
Slagthuset                      Tel. +46-40 108588              
211 20  Malmö                   Fax. +46-40 150790              
Sweden                        Mobile +46-70 5247799

PGP fingerprint: 89BC 6C79 5B3D 591B 8547  1512 7D11 DBF4 528F 29A0
-------------------------------------------------------------------

---

From: John Saylor <[email-masked]>
Date: 30 Nov 1999 09:05:05 -0500

Hi

>>>>> "SS" == Stefan Santesson <[email-masked]> writes:

 SS> And that is to use the serialNumber attribute.

 SS> The good thing about selecting serialNumber is that it is widely
 SS> implemented anyway, it works and it has a short OID.

Yes, but the bad part is that the name "serialNumber" carries baggage
that is misleading if it were to be used as a unique identifier of
some sort.

Also, some of the same arguments in favor of serialNumber could be
applied to dnQualifier [widely implemented, works, short OID]. But
here the problem is that the intended useage is not followed [which
is also be the case (to a lesser degree) with serialNumber].

Conceptually, it seems the "right" thing to do is to add on OID for
uniqueIdentifier; however there is no shortage of operational problems 
that crop up with this course.

 SS> So if nobody strongly object to this I will go ahead and include
 SS> this in the QC profile and I assume that rfc 2459 will be updated
 SS> accordingly

I can't come up with a better plan.

-- 
\js

---

From: "Charles Moore" <[email-masked]>
Date: Wed, 1 Dec 1999 05:45:23 +1000

----- Original Message -----
From: Stefan Santesson <[email-masked]>
To: <[email-masked]>
Sent: Tuesday, November 30, 1999 10:41 PM
Subject: Re: dnQualifier topic - not solved yet.

But our choice of this attribute should also be a clear signal to the X.500
folks that we want to have X.520 and X.521 updated and fixed so this
attribute is clearly related, not only to devices, but to any type of
object.

cm> I object for the reasons previously outlined.. You are using it with the
wrong sematics and it will be impossible to distinguish from previous usage
that has the correct semantics...
Please address these issues...

> implement attribute (i.e. compliant applications MUST be able to
understand
cm> See above this is not possible given existing usage...
Also please address the usage and privacy issue....
> - specify use of serialNumber but NOT dnQualifier in the Qualified
cm> See above...

> It would help to get your immediate support for this. Can you live with
it??

cm> No...

>MUST level (in addition to serialNumber), I could live with that.

cm> No...

/Stefan