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

[Magnus Nystrom <magnus@xxxxxxxxxxxxxxx>]

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

On Mon, 22 Nov 1999, Stefan Santesson wrote:

> 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       jyri.tahtinen@hpy.fi
> >  FIN-00521 HELSINKI               <PGP available on request>
> > --------------------------------  - - - - - - - - - - - - - - - - - - -
> 
> 
> 
> At 01:40 PM 11/22/99 +0100, Magnus Nystrom wrote:
> >
> >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: magnus@rsasecurity.com
> >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
> 
> -------------------------------------------------------------------
> Stefan Santesson                <stefan@accurata.se>
> 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
> -------------------------------------------------------------------
> 

-- Magnus
Magnus Nystrom		Email: magnus@rsasecurity.com
RSA Laboratories