Subject: Re: Permanent identifiers in QC

From: [email-masked]
Date: Tue, 11 Apr 2000 14:12:47 -0400

I do not understand why permanent identifiers would be much less
useful in a non-repudiation situation than in an access control situation.
A third-party verifier is just as interested in distinguishing between two
individuals named "John Smith" to decide whether the subject of the
certificate used to sign a document in the past is the same person as the
relying party claims it is as an access control system would be in whether
the certificate subject is the owner of account "jsmith".  It is true that
transaction volumes for NR verification would probably be low enough that
manual techniques like checking what identification was presented to the CA
or RA could be used in the absence of a permanent identifier, and that the
verifier might wind up having to check the CA's records anyway, especially
if certification masquerade is claimed.  However, access control systems
may not think that a permanent ID match from a cross-certified CA is
absolute proof of identity either, and might prefer storing specific
certificate ID's.

          Tom Gindin

Stephen Kent <[email-masked]> on 04/10/2000 07:06:29 PM

To:   "Anders Rundgren" <[email-masked]>
cc:   "David P. Kemp" <[email-masked]>, <[email-masked]>
Subject:  Re: Permanent identifiers in QC

Anders & Dave,

The scenario Dave provided is an access control example.  It is
broader than what Denis suggested in his presentation, and thus is
not what I was referring to, but it is still valid.

The emphasis on signatures verified using QC certificates has been on
their use in non-repudiable transactions.  In such cases, access
control may or may not be an issue.

Steve

---

From: Stephen Kent <[email-masked]>
Date: Tue, 11 Apr 2000 16:01:23 -0400

Tom,

>absolute proof of identity either, and might prefer storing specific

I understand your point that under some circumstances it may be 
desirable to be able to determine if two different certs, involved in 
signing two different objects, are the same individual.  But that 
certainly is an extension of the basic non-repudiation service, which 
focuses on whether a given signature for a signed object is valid, 
relative to a set of rules re certificate issuance, path validation, 
revocation, etc.  We probably ought not add features to QC certs to 
address increasingly more complex scenarios, vs. the general case NR 
scenarios that the QC document editor has established as the scope of 
that effort.  For example, Denis's proposal does not ensure that one 
can compare the IDs in the new name form when they are issued under 
two different CAs. I can imagine applications where that might be an 
important feature, but that does not mean that we ought to define a 
construct for supporting such a facility.

In another example, the PKIX WG was treated to an impressive 
presentation in Adelaide on a protocol suite that supports very 
complex document management applications. It probably subsumes the 
functions of SCVP, OCSP, and maybe parts of CMP!  However, that 
protocol is probably too elaborate and too focused on a specific 
application context to match the WG charter of standardizing generic, 
infrastructure services and data formats.

Steve

---

From: Denis Pinkas <[email-masked]>
Date: Wed, 12 Apr 2000 12:31:47 +0200

Steve, Anders, Stefan, Tom, Russ, and the WG, 

I will use the response from Steve to comment and add a few things
captured in other E-mails.

Mike said: " I see no reason for PKIX to establish requirements
governing or defining the notion of a permanent identifier.  <
snip>  That is the task of other WGs. " 

Russ said something similar: "If some Internet application needs a
permanent identifier, then the needy application should specify it".

The right answer has been given by Steve: " ... if there is a need
for such forms of IDs, and if they span multiple applications, then
we could reasonably define them in PKIX."

So the basic question is whether there is a need for such form of
permanent ID. Some arguments were raised whether the need was for
acces control purposes only or also for non-repudiation purposes. No
one is disputing that it is usefull for access control purposes. I
would like to mention that this OPTIONAL feature MAY also be usefull
for non-repudiation purposes. A non repudiation service may be used
in the context of a transaction. It may be usefull to be able to
relate different transactions to the same individual, *even when the
name (i.e. DN) of the individual changes*. The current DN cannot be
used for such a purpose. A permanent identifier allows to support
that feature. 

At the meeting we said, as Stefan reported: " the decision whether
or not to include this name form in QC should be taken to the list".
This is correct (and not reflected in the draft minutes just
received). :-(

A basic question is whether the permanent identifier should be
described in the son of RFC 2459 or in QC. Let us forget the
technical aspect for a moment and face the procedural aspect. Let us
suppose that it is not defined in QC, but in the son of RFC 2459.
Since QC refers to RFC 2459, not the son of RFC 2459, even if it is
described there it will not apply, i.e. it will not be a possible
feature of QC. 

We should include it in QC now, because there is a need to define
what is (or what is not) a QC within a couple of months. If this is
not included, it will not be possible to people to issue QCs with
permanent identifiers, even if the feature is described in another
separate document. Otherwise it would mean that in order to conform
to the European Directive, you would have to consult two separate
RFCs, which would be a little odd or bizare.

Now I would like to come back to the technical aspect. Stefan said:
 
" 1) Adding this name form would add confusion to the QC
specification since it would overlap use of serialNumber in the DN." 

If we are not careful with the text defining what a serial Number
is, Stefan is right when he says that some confusion might be
possible. But is it easy to fix it. The permanent identifier can
include ANY attribute. Currently the definition of serialNumber
mandates its use only in the DN. We could extend the definition (as
I have proposed) and its meaning when it is included either in the
DN or in the permanent identifier.

> revocation, etc.  

I do not see this as an extension. One way to look at the problem is
to consider at a broad level the difference between the DN and the
permanent identifier.

The permanent identifier is basically "machine processable" while
the DN is mainly "human processable". The permanent identifier does
not necessarilly allow a human being to identify directly the
individual, e.g. a social security number for an individual or an
employee number (associated with a company name) for an employee.

The DN allows a better direct identification (if a pseudonym is not
used and if there are no homonyms). The serialNumber when used in
conjunction with a DN does not allow a better identification, it
only allows to differentiate between two homonyms, i.e. John Smith
22 and John Smith 41. Some "other (undefined) means" are needed to
tell which John Smith you are looking for.

Let me present two simple scenarios which explain how the permanent
identifier might be used in the context of non-repudiation.

1) The first time a transaction is being received by a transaction
system, the DN is looked at in conjunction with some "other means"
(maybe using some human intelligence). If it is found acceptable,
then the permanent identifier can be used to link future
transactions from the same individual, even if the DN changes.

2) When a user registers to a transaction system, it presents his
certificate. Once the certificate is accepted, then the permanent
identifier is used to accept and link subsequent transactions, even
if the DN changes. 
 
> We probably ought not add features to QC certs to
> that effort.  

> For example, Denis's proposal does not ensure that one

Please, do not make the story more complicated than requested. The
permanent identifier is a name of the subject, unique within the
issuer domain, that is not reused over time for another subject. The
name is only unique within the issuer domain (i.e. CA). Making the
name unique across different CAs would break the current PKIX model. 

Denis