Subject: Re: QC comparisons are DEADLY serious!

From: Stefan Santesson <[email-masked]>
Date: Mon, 01 Nov 1999 09:38:12 +0100

Anders,

What you describe is another issue. Comparing the subjects name against an
access control database may be a desired function. 

It should be noted though that in this case it is up to the local policy of
the relying party (and the content of the certificate) to decide if a new
certificate match a specific entity in the database (matching the old
certificate). 

It should also be clear that it is NOT a function of the QC profile to
guarantee that two certificates for the same person will be considered to
match the same entity in an access control database. This must be resolved
by other means.

But I promise I will bring this up in Washington to check others view.

/Stefan 

At 03:20 PM 10/30/99 +0100, Anders Rundgren wrote:
>Stefan, 
>
>I strongly disagree on your conclusions regarding certificate comparisons. 
>Rather, I consider the possibility to compare certificates from a certain 
>issuer and CPS 
>to be a major "quality" property that deserves a section of its own. 
>
>To give an example. If you have a QC issued by a TTP (ID-certificates that 
>will only be used within the issuer's own domain are pretty uninteresting)
and 
>your bank accepts that certificate in conjunction with its Internet-bank it 
>is VERY interesting for BOTH the bank (RP) and for the customer (Subscriber) 
>to know what will happen the day you log in with a renewed certificate. 
>IN ADVANCE. 
>
>So what you describe as a "minor issue" is for some people a FUNDAMENTAL 
>ISSUE that the QC draft IMLHO must address in much more serious way than in 
>V02. 
>
>Anders
>
>
>
>-----Original Message-----
>From: Stefan Santesson <[email-masked]>
>To: Anders Rundgren <[email-masked]>; 'SEIS-List' 
><[email-masked]>; [email-masked] <[email-masked]>
>Date: Friday, October 29, 1999 23:09
>Subject: SEIS: Re: QC certificates MAY CERTAINLY be compared!
>
>
>>--- Message on the SEIS mailing list ([email-masked])
>>
>>Anders,
>>
>>Thank you, I have noticed your comment.
>>
>>The security considerations section contains CONSIDERATIONS for the general
>>case and I still believe in the intent behind this sentence, as a good
>>general guidance to implementations. 
>>
>>Setting up implementations with the intent to compare two qualified
>>certificates to see if they represent the same person IS generally a bad
>>service that shouldn't be performed. Since in the general case, you will
>>have clear risk of misleading results.
>>
>>Well, if you leave the general case and go into speciffic cases such as
>>comparing SEIS certificates within a local region (such as Sweden), then
>>there will allways be cases where some security considerations does not
>>apply (such as this particular one).
>>
>>I think this is a minor issue within the security consideration section
>>which does not affect the implementation of the profile. Shure there are an
>>even better way of expressing the original intent behind that sentence. But
>>on the other hand,  there will allways be a better way of everything.
>>
>>I think the present description is good enough. Can you live with it ?
>>
>>/Stefan
>>
>>At 17:55 1999-10-25 +0100, Anders Rundgren wrote:
>>>Stefan,
>>>I have said it before and I say it again.  The following QC-statement is 
>>>higly doubtful:
>>>
>>>"Comparing two qualified certificates to determine if they represent
>>> the same physical entity may provide misleading results and should
>>> not be performed"
>>>
>>>As you know our famous (?) SEIS-card does indeed allow certificates to
>>>be compared for subject identity.   That is IMO the whole (and only) point 
>>>with *real* ID-cards!
>>>
>>>So this is a statement of the CPS.  Not of the draft.
>>>
>>>
>>>
>>>BTW, why no explicit support for "container ID" (card serial) as most QCs 
>>>will be
>>>put in smart cards?  It was in SEIS already.
>>>
>>>
>>>Anders
>>>
>>>
>>>-----Original Message-----
>>>From: Stefan Santesson <[email-masked]>
>>>To: [email-masked] <[email-masked]>
>>>Date: Monday, October 25, 1999 14:14
>>>Subject: New submitted draft for Qualified Certificates
>>>
>>>
>>>>All,
>>>>
>>>>A new draft for a Qualified Certificates Profile was submitted friday 22.
>>>>
>>>>The new draft can be obtained from:
>>>>http://www.accurata.se/QC/documents/draft-ietf-pkix-qc-02.txt
>>>>
>>>>The QC website has been udated accrodingly:
>>>>http://www.accurata.se/QC/
>>>>
>>>>See also under settled topics to obtain information about major
>>>>considerations since the last draft.
>>>>
>>>>/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
>>>>-------------------------------------------------------------------
>>>> 
>>
>>
>>----------------- SEIS mailing list ([email-masked])
>>Info about this list: http://www.nc-forum.com/seis
>>SEIS Contact: [email-masked]
>>
>>

-------------------------------------------------------------------
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: [email-masked] (Peter Gutmann)
Date: Fri, 5 Nov 1999 03:53:44 (NZDT)

Stephen Kent <[email-masked]> writes:

>In version 2 X.509 certs there was a field added for unique subject and 
>issuer IDs.  It was a bad idea, designed to address what appear to be some 
>of the issues you alluded to above; nobody uses it.

Well, nobody's *supposed* to use it, but it was used briefly in SEIS certs
(it's now been replaced by a cert extension).  The style guide has the
following comment on unique identifiers:

uniqueIdentifier

  There are at least two incompatible objects called uniqueIdentifier, the
  first is an attribute defined in 1991 in RFC 1274 with string syntax, the
  second is an attribute defined in 1993 in X.520v2 with BIT STRING syntax.
  LDAPv2 used the RFC 1274 interpretation, RFC 2256 changed the name for the
  X.520 version to x500uniqueIdentifier for use with LDAPv3.  There is also a
  uid attribute defined in RFC 1274, this is different again.

There are also proprietary equivalents for uniqueIdentifiers which I haven't
mentioned in the guide, eg the Telesec nameDistinguisher.  X.520 also has some
other uniqueXXX attribute [pause] uniqueMember whose purpose I don't recall.

Peter.