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

From: Hans Nilsson <[email-masked]>
Date: Mon, 22 Nov 1999 17:06:23 +0100

Magnus,

The German "Working group of Trust Centers for Digital Signatures" have in
their current draft interoperability specification also decided to use
serialNumber as "Name differentiator". So in your words, is Gemany "another
lost case" :-) ?

I dont think so. I think this is the only reasonable way to go forward. This
is an item that we have discussed for *years* now, after the initial Swedish
Allterminal use of serialNumber, and when we finally decided on something
else, we goofed. I would understand the objections if anyone raised his
voice and said: "Hey wait, we are already using serialNumber for this device
here, and please dont change the semantics, because it would ruin our
system". But I have not heard *anyone* using serialNumber for anything else
than a  "unique identifier of a person".

Hans

-----Original Message-----
From: Magnus Nystrom [mailto:[email-masked]]
Sent: den 22 november 1999 13:40
To: Stefan Santesson
Cc: [email-masked]; Ella Paton Bassett; [email-masked];
[email-masked]; [email-masked]; [email-masked];
[email-masked]; [email-masked];
[email-masked]; [email-masked]; [email-masked];
[email-masked]; [email-masked]
Subject: Re: We have to choose serialNumber instead of dnQualifier
NOW!!!

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

On Mon, 22 Nov 1999, Stefan Santesson wrote:

> 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

---

From: "David P. Kemp" <[email-masked]>
Date: Mon, 22 Nov 1999 11:31:07 -0500 (EST)

> From: Magnus Nystrom <[email-masked]>
> 
> 'person' object class) as well.

Magnus,

Three questions:

 1) For systems which use an attribute to hold a device number, would
using the same attribute to hold a person number cause any problems?

 2) For systems which use an attribute to hold a person number, would
using the same attribute to hold a device number cause any problems?

 3) Would it be any easier to add a new attribute to X.500, X.520, and
X.521 than it would be to add the serialNumber attribute in the same
places?

> I guess one possibility is to re-name

Based on Sharon's data and SEIS usage, there appears to be historical
experience with using serialNumber for people.  The semantics of a
"device serial number" match exactly the semantics of
"employee/student/customer/citizen number"; if one were to design
the best possible system from scratch, would it not use one attribute to
refer to all objects rather than having separate attributes to express
the identical semantics over separate object classes?  Isn't commonName
used for all types of objects?

I can't think of a single advantage to having two attributes, and there
are real disadvantages to forcing renaming in existing systems which
use serialNumber for people.

---

From: "Anders Rundgren" <[email-masked]>
Date: Mon, 22 Nov 1999 22:38:32 -0000

Magnus,

>something which may not be the optimal solution.

Actually the situation in Finland, Sweden and Germany etc. probably requires the famous
kludge solution.

That means that they must (if production has started) continue with SerialNumber, DNqalifier or whatever
homebrewed scheme that is used. 

Then if a new solution becomes standardized you add that as well but keep the kludge until
all applications out there only use the standard attribute.

Looks ugly but works well :-)

SerialNumber is at least a lousy name as the identifier we are talking about neither needs
to be numeric or serially incrementing

<snip>
Anders

---

From: Peter Williams <[email-masked]>
Date: Tue, 23 Nov 1999 14:00:22 -0800

> Sent: Tuesday, November 23, 1999 5:19 AM
> To: Jyri Tähtinen
> 

> On Tue, 23 Nov 1999, Jyri Tähtinen wrote:
> 
> > Magnus Nystrom wrote:
> 
> [...] 
> > > There's just one problem: The object identifier is really 
> long (and
> > > invalid).
> > 
> > I don't know whether the length of OID is a real problem (except for
> > human readers ;-)
> 
> It could be a problem in resource-constrained environments (space,
> bandwidth) since certificates containing such OIDs will tend to be
> unnecessary long.
>  
> > 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 ).
> 
> 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.
>

The editor is perhaps wrong. It was probably hijacked by UCL-CS. Funny 
to see so many formal US State legal framework now built on such shaky
ground and pilot program status, given the transience of the UCL 
network registrations underlying...
 
[Kil89]  S.E. Kille. A string encoding of presentation address.
         Research Note RN/89/14, Department of Computer Science,
         University College London, February 1989.

See ftp://ftp.isi.edu/in-notes/rfc1278.txt for the derivation
of the BT packet switch stream service X121 data service's
idi value 2342, and ucl-cs's dsp 19200300 values.

also, see

http://wwwpks.atnf.csiro.au/library/WWW/pmdf/x500_sysman/book_h.html#appendi
x_c

(quipu OBJECT IDENTIFIER ::= {ccitt data(9) pss(2342) ucl(19200300)
quipu(99)} 
                                     -- interim QUIPU OID)

(The number of people who understand directory names is small. The number
of people who have ever built a (Quipu) I&A security policy using 
properly architected directory names, with or without strong 
authentication and certified keys, is probably even smaller.)

The oid is particularly relevant to PKIX because of:

http://www.landfield.com/rfcs/rfc2247.html

Thus the domain name "CS.UCL.AC.UK" can be transformed into

        DC=CS,DC=UCL,DC=AC,DC=UK

   Distinguished names in which there are one or more RDNs, all
   containing only the attribute type DC, can be mapped back into domain
   names. Note that this document does not define a domain name
   equivalence for any other distinguished names.

4. Attribute Type Definition

   The DC (short for domainComponent) attribute type is defined as
   follows:

    ( 0.9.2342.19200300.100.1.25 NAME 'dc' EQUALITY caseIgnoreIA5Match
     SUBSTR caseIgnoreIA5SubstringsMatch
     SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 SINGLE-VALUE )