Subject: We have to choose serialNumber instead of dnQualifier NOW!!!

From: Stefan Santesson <[email-masked]>
Date: Mon, 22 Nov 1999 12:28:51 +0100

All,

Regarding the issue to select an attribute type for storage of personal
identifiers of certificate subjects.

Finland's national electronic identity project starts FULL production in 2
weeks, where they will  issue certificates to the people of Finland in a
large scale.

They need to know TODAY, what attribute type they should use to store
electronic identity numbers of Finnish citizens.

- I think the latest discussions have shown that dnQualifier is out of the
picture.

- UID is useless because of the bit string syntax.

- There is no time to define a new attribute.

So they will have to go with serialNumber. A big reason for this is also
that the Germans have decided to go with the serialNumber attribute as
well. So now Finland and Germany will at least be compliant.

So folks, as I see this we have no choice other than to support
serialNumber at this moment.

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

-------------------------------------------------------------------
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: Magnus Nystrom <[email-masked]>
Date: Mon, 22 Nov 1999 13:40:24 +0100 (W. Europe Standard Time)

Taking advantage of the timezone difference to be the first to
respond...;)

I must say I am a bit reluctant to choose a long-term solution because of
short-term time constraints in this case. Finland is, in my view, a "lost
case" anyway, our decision won't affect them much right now anyway. What
says "There is no time to define a new attribute"? Better to think this
through properly and let everyone express their view than to rush
something which may not be the optimal solution.

As I previously stated, I am not too convinced serialNumber is the best
alternative. Squeezing in new semantics in an existing attribute may cause
more problems than it solves. Since any change in the semantics of
serialNumber will affect X.520, it ought to affect X.521 (e.g. the
'person' object class) as well. I guess one possibility is to re-name
serialNumber as well, to something more declarative, like "uniqueNumber"
or similar, but it would be just as easy to define a new attribute - X.520
and X.521 will have to change anyway if they are to support this at all.
Note: I am not saying I object to this proposal, just that I think we need
some more time.

Regards,
-- Magnus
Magnus Nystrom		Email: [email-masked]
RSA Laboratories

---

From: Stefan Santesson <[email-masked]>
Date: Mon, 22 Nov 1999 15:57:04 +0100

Good,

We have a dialogue here. I don't think the Finnish case is lost, but it is
urgent. They will have a meeting tomorrow morning and they now ask why we
don't use the unique identifier attribute from rfc 1274. I supply the mail
from Jyri Tähtinen below:

I remember that we considered this attribute a long time ago in the Swedish
EID project but that we abandoned it for some reason.

/Stefan

At 02:50 PM 11/22/99 +0200, Jyri Tähtinen wrote:
>Dear Mr. Santesson, cc: FINEID people
>
>I think Vesa Vatka and Ari Saapunki have been in touch with you in this
>dNQualifier va serialNumber issue.
>
>My question is:
>
>- why don't PKIX people specify uniqueIdentifier (PilotAttributeType.44)
>for storage of uniquely identifying data? This attribute should be
>widely known (from rfc1274) and it has directory string syntax.
>
>(Of course there can be a problem, if client software don't understand
>this attribute type which is part of subject name...)
>
>- the serialNumber attribute type is not good, because
>
>a. it already identifies also the certificate serial number in
>directory! The certificates are stored in directory and named with cert.
>serialnumber.
>I have quoted below part of a message from you (that Markku Kontio
>forwarded to me).
>
>b. it is more related to devices than subjects of certification
>
>By the way, do you have suggestions which attribute to use for
>certificate serialNumber if you use serial number for UID?
>Should we define new attribute type certificateSerialNumber or something
>like that?
>
>Anyway, it would be wise to use same attributes in certificate and in
>directory - otherwise there is big risk of misunderstandings. (If UID is
>stored in serialNumber in certificate but in directory serialNumber is
>used to store cert.serial number!)
>
>> After all mails so far I must say that the current status of my 
>> understanding is that we use the dnQualifier attribute wrong, if we use it 
>> for this purpose. 
>>
>> That's the first thing we must agree on. Can we do that? 
>>
>> The second is what we should do about it. We have some choices. 
>>
>> 1) To continue to use dnQualifier even though we break it's intended
purpose 
>> 2) To use another existing X.520 attribute (serialNumber or UID) 
>> 3) To find another suitable attribute, defined by someone else 
>> 4) To define a new attribute. 
>
>I suggest choice nr 3 and the solution would be from RFC1274:
>
>9.3.34.  Unique Identifier
>
>   The Unique Identifier attribute type specifies a "unique identifier"
>   for an object represented in the Directory.  The domain within which
>   the identifier is unique, and the exact semantics of the identifier,
>   are for local definition.  For a person, this might be an
>   institution-wide payroll number.  For an organisational unit, it
>   might be a department code.
>
>     uniqueIdentifier ATTRIBUTE
>         WITH ATTRIBUTE-SYNTAX
>             caseIgnoreStringSyntax
>             (SIZE (1 .. ub-unique-identifier))
>     ::= {pilotAttributeType 44}
>
>
>Could you comment on that as soon as possible, please!
>
>We will have a meeting on this issue early on Tuesday morning.
>
>Regards,
>
>Jyri Tähtinen
>
>-- 
> --------------------------------  - - - - - - - - - - - - - - - - - - -
>  J y r i   T ä h t i n e n        Development Manager, M.Sc.
> 
>  Helsinki Telephone Corporation   Telephone    +358 9 606 4546
>  Kolumbus Services                Mobile phone +358 50 5666599
>  Asemapäällikönkatu 2 (PAD510)    Fax          +358 9 606 3290 
>  P.O.Box 133                      E-mail       [email-masked]
>  FIN-00521 HELSINKI               <PGP available on request>
> --------------------------------  - - - - - - - - - - - - - - - - - - -

---

From: Russ Housley <[email-masked]>
Date: Mon, 22 Nov 1999 11:34:40 -0500

Stefan:

I can live with this approach.

Russ

---

From: Magnus Nystrom <[email-masked]>
Date: Tue, 23 Nov 1999 10:01:15 +0100 (W. Europe Standard Time)

I basically agree with the comments from Finland. Reading through RFC
1274, it appears to me as if uniqueIdentifier would be 
an excellent choice - no need to redefine semantics for existing
attributes with unknown effects, good semantics and syntax from the start.
There's just one problem: The object identifier is really long (and
invalid).

-- Magnus

-- Magnus

---

From: Juergen Brauckmann <[email-masked]>
Date: Tue, 23 Nov 1999 10:40:12 +0100

>> >directory! The certificates are stored in directory and named with cert.

Jyri,

I think you are wrong here, because the attribute we talk about is a part
of the certificate DN and has not necessarily something to do with the
serialnumber of the certificate itself in the directory. And I believe that
it's not correct to use the X.520 serialNumber Attribute for storing
certificate serial numbers in a X.500 directory. The two serial"numbers"
even don't have the same type (printableString for X.520 serialNumber,
Integer for X.509 certificate serial number). Please correct me if this is
wrong... .

Regards,
    Juergen

-- 
Juergen Brauckmann             Tel.:  040 / 8080 26 311
TC Trust Center GmbH           Fax.:  040 / 8080 26 126
Sonninstraße 24-28   	    mailto:[email-masked]
20097 Hamburg 		    http://www.trustcenter.de

---

From: Jyri Tähtinen <[email-masked]>
Date: Tue, 23 Nov 1999 13:28:43 +0200

Juergen Brauckmann wrote:
> serialnumber of the certificate itself in the directory. 

True. But in our implementation it is so that I stated.

>And I believe that
> certificate serial numbers in a X.500 directory. 

Well, that's the way how it is implemented now in FINEID system. But we
will change this.

>The two serial"numbers"

You're right, but it also seems that there is no other standard based
solution for storing cert serial numbers in LDAP directory. If you know
one, please tell me!

(And Printable string syntax can contain numbers/integers, so that
attribute type can be used for storing certificate serial numbers.)

However, we had to make a quick decision this morning.

The result was that we will use serialNumber attribute in certificate
subject name to store unique identifier like the FINUID number. And for
storing certificate serial number in directory, we will specify a new
attribute type certificateSerialNumber (from fineidAttributeType OID
tree) with PrintableString syntax.

Regards,

Jyri

---

From: Jyri Tähtinen <[email-masked]>
Date: Tue, 23 Nov 1999 14:46:46 +0200

> attributes with unknown effects, good semantics and syntax from the start.

Unfortunately in Finland we did not have time to wait for this
discussion to end, but we had to make decision this morning. (Anyway, I
feel that uniqueIdentifier would be the best candidate for the UID
usage, at least better than both serialNumber and dnQualifier.)

We chose to use serialNumber attribute type in certificate
subject name to store unique identifier (like the FINUID number). The
reasons for this were that dnQualifier seemed to be impossible solution
and serialNumber is in use at least in Germany. Other choices were not
considered practical at this moment (software support etc.).

For storing certificate serial number in LDAP directory, we will specify
a new
attribute type certificateSerialNumber (from fineidAttributeType OID
tree) with PrintableString syntax. That will be presented in FINEID S5
specs.

If there will be in future a better standardized solution provided by
PKIX working group, we may choose to follow that later on. Of course,
with a large amount of distributed certificates, it may not be so easy
to change specifications on the run.

> There's just one problem: The object identifier is really long (and

I don't know whether the length of OID is a real problem (except for
human readers ;-)

I am not ASN.1 expert and therefore can not say how the OID is invalid,
but at least these OIDs are widely in use. 

For example, email address, LDAP v3 attribute type mail = LDAP v2
rfc822Mailbox is pilotAttributeType.3 (OID 0.9.2342.19200300.100.1.3 ).

regards,

Jyri

---

From: Magnus Nystrom <[email-masked]>
Date: Tue, 23 Nov 1999 14:18:38 +0100 (W. Europe Standard Time)

> Magnus Nystrom wrote:

[...] 
> I don't know whether the length of OID is a real problem (except for

It could be a problem in resource-constrained environments (space,
bandwidth) since certificates containing such OIDs will tend to be
unnecessary long.
 
> rfc822Mailbox is pilotAttributeType.3 (OID 0.9.2342.19200300.100.1.3 ).

I know, but a second-level branch of 9 is not defined. The branch 0 9 was,
citing the editor of X.680/ISO 8824-1 "hi-jacked" by IETF. But this is
another story however.

-- Magnus

---

From: Stefan Santesson <[email-masked]>
Date: Tue, 23 Nov 1999 18:49:27 -0500

I guess that this is the same problem then for all "pilotAttributeType",
such as our problem with domainComponent, that the OID branch is high jacked.

/Stefan