Subject: Re: Unmistakable Identity (Was: Internet draft for Qualified Certificates.)

From: Stefan Santesson <[email-masked]>
Date: Thu, 29 Oct 1998 11:31:27 +0100

Anders,

I see your problems but fail to see in what way they are unique to digital
agreements.

Many long term contracts are drawn up using "non static" ID-attributes.
They work so I'm convinced that they would work if they are signed through
digital mechanisms.

Clearly the requirements on a supporting infrastructure will differ
dependent on which ID-attributes that are used. But that's outside the
scope of this draft.

Secondly all ID-attributes have different characteristics. I wouldn't know
how to categorize them in a way that is internationally meaningful. You are
free though to  propose any writing in this sense.

/Stefan

At 10:15 AM 10/29/98 +0100, Anders Rundgren wrote:
>Stefan,
>New try with this Unmistakable business:
>
>Assumptions
>  Users have SEIS EID certificates (qualified I assume) based on the
proposed CP
>  The certificate-relaying party is a computer program
>  The certificate-relaying part and the certificate-subject have a
long-term relation
>
>Now I try to apply the algorithm from the I-D that says that an
*unmistakable* name
>should be created by combining Name, civicRegNr etc..
>
>Statement 1: By combining the name of physical persons in Sweden with other
>attributes to form an unmistakable identity, the chance that some future
certificate
>for a certain person will fail during authentication due to name changes
is around *20%*! 
>Unless of course the certificate-relying party is free to ask the CA
>questions like: Was XYX formerly known as DFT?
>
>Statement 2: By only using civicRegNr (which departs from the I-D
definition) this risk
>goes down to a mere *0.001%*.
>
>Do I smell interoperability problems and confusion?  Lots of it.  I was
actually recommended
>by one major EID-vendor (who's identity will remain in secret) to use the
entire certificate (!!!)
>as a key in authentication so even the s.c professionals have problems
with this part.
>
>
>Now to this *static* thing.  That there is currently no room in the I-D
for the definition
>of such a characteristic is a serious omission.   This is as you pointed
out a market and 
>legislative issue so it is very important for certificate-subjects and
certificate-relying
>parties to know what they can expect.  And for issuers to point out in
their marketing.
>Note that this has nothing to do with recommendations
>
>Anders
>
>----------
>From:  Stefan Santesson [SMTP:[email-masked]]
>Sent:  Wednesday, October 28, 1998 17:07
>To:  'SEIS-List'
>Subject:  RE: Internet draft for Qualified Certificates.
>
>--- Message on the SEIS mailing list ([email-masked])
>
>Anders,
>
>An unmistakable name doesn't have to be static. It is unmitakable as long
>as the relying party can use the name to identiy the subject for as long as
>the certificate is valid and not revoked.
>
>It is at this moment outside the scope of this I-D to make any requirements
>on how static a name should be. This is up to the CA to decide and up to
>the relying party to accept.
>
>/Stefan
>
>
>At 04:17 PM 10/28/98 +0100, Anders Rundgren wrote:
>>--- Message on the SEIS mailing list ([email-masked])
>>
>>Stefan, I still have some serious problems with the definitions and
>interpretations.
>>
>>>>How does a certificate-relying party know what fields form
>>>>an unmistakable name of the subject?
>>>>
>>>>Unmistakable is different from static identity I guess?
>>>>
>>>>Anders
>>
>>>An unmistakable name of the subject SHALL be obtained by combining the
>value of the subjects 
>>>registered name attributes or pseudonym attributes, with the values of
>the following attribute 
>>>types;
>>>countryName
>>>civicRegistrationNumber
>>>serialNumber
>>>organizationName
>>>organizationalUnitName
>>>postalAddress
>>
>>To me a Swedish EID forms an unmistakable subject identity (99.999%) by just
>>using civicRegistrationNumber.
>>
>>By using the other (non-static) attributes you loose unmistakable.  You
>just have to change
>>employer to break it! 
>>
>>I would also like to see the *static* identity possibility covered by the
>draft.  I.e. it should
>>be clear for a certificate-relaying party if is unmistakable in the way
>you use that
>>word in other contexts.
>>
>>Anders
>>
>>
>>
>>----------------- SEIS mailing list ([email-masked])
>>Info about this list: http://www.nc-forum.com/seis
>>SEIS Contact: [email-masked]
>>
>>
>>
>-------------------------------------------------------------------
>Stefan Santesson                <[email-masked]>
>Accurata Systemsäkerhet AB     
>Lotsgatan 27 D                  Tel. +46-40 152211              
>216 42  Malmö                   Fax. +46-40 150790              
>Sweden                        Mobile +46-70 5247799
>
>PGP fingerprint: 89BC 6C79 5B3D 591B 8547  1512 7D11 DBF4 528F 29A0
>-------------------------------------------------------------------
>
>
>----------------- SEIS mailing list ([email-masked])
>Info about this list: http://www.nc-forum.com/seis
>SEIS Contact: [email-masked]
>
>
>
>
-------------------------------------------------------------------
Stefan Santesson                <[email-masked]>
Accurata Systemsäkerhet AB     
Lotsgatan 27 D                  Tel. +46-40 152211              
216 42  Malmö                   Fax. +46-40 150790              
Sweden                        Mobile +46-70 5247799

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