Subject: Re: Permanent identifiers in QC

From: [email-masked]
Date: Tue, 11 Apr 2000 20:13:25 -0400

I am responding to some of your replies below.  However, if an
OTHER-NAME is more appropriate for this purpose than a QC statement, the
following ASN.1 definitions for such an OTHER-NAME might make it clear what
I am suggesting:

authorityAssignedID OTHER-NAME ::= { AuthorityAssignedID IDENTIFIED BY
                    id-pkix-authorityAssignedID }
AuthorityAssignedID ::= SEQUENCE   {
     authority GeneralName,
     ID        DirectoryString
     }

CAAssignedID OTHER-NAME ::= { IssuerAssignedID IDENTIFIED BY
                    id-pkix-CAAssignedID }
IssuerAssignedID    ::= DirectoryString

     National identities can easily be represented by an
authorityAssignedID with the authority specified by a DN containing only a
country attribute.
     The first of these two forms has quite general use, and the only
application the second is specific to is the CA itself.

          Tom Gindin

Stephen Kent <[email-masked]> on 04/11/2000 04:01:23 PM

To:   Tom Gindin/Watson/IBM@IBMUS
cc:   [email-masked]
Subject:  Re: Permanent identifiers in QC

Tom,

>      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.

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.

[Tom Gindin] My major point is that this facility is no more beyond the
core scope of NR than beyond that of authentication.  If Denis' proposal is
the one in his posting of March 15, it covers one of the three cases I
proposed in my postings of March 30-31 - the case I described as
id-qcs-CALocal.  The  proposed identifier assignment authority is more
general and would enable comparisons for equality across CA's.  The
heuristic is: two such identities match if both the authorities and the
identifiers match, and do not match otherwise.  The issuer name does not
enter into the comparison in this case.  In the special case where the
issuer is defined to be the assignment authority (which I assigned its own
semantics identifier), the identities cannot be compared across CA's.

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.

[Tom Gindin] A requirement for a name form consisting of an assignment
authority and an identifier seems to be fairly general.  It has come up
both in the QC discussions and for access control.

Steve

---

From: Stephen Kent <[email-masked]>
Date: Thu, 13 Apr 2000 14:02:59 -0400

Tom,

I have no problems with the sorts of IDs you proposed in your ASN 
GeneralName Other-Name examples. They seem to be consistent with the 
arguments that Denis has made for such constructs. However, before we 
add these to the updated part 1, I think we need more time to explore 
the utility for these name forms.  The debate on the list shows that 
there are widely diverse opinions about what such IDs are good for, 
what scope is feasible/appropriate, etc.  I'd hesitant to hold up 
progress on the revision to 2459 to add this sort of facility which 
has been proposed only recently.  That's why several folks have 
suggested a separate, small document whoch can be advanced 
separately, and merged into 2459 if there is sufficient, consistent 
support.

Steve

---

From: Russ Housley <[email-masked]>
Date: Fri, 14 Apr 2000 10:36:05 -0400

I agree with Steve.  Note that the CAT Working Group has defined an 
OTHER-NAME for Kerberos names.

Russ

At 02:02 PM 04/13/2000 -0400, Stephen Kent wrote:
>arguments that Denis has made for such constructs. However, before we add 
>these to the updated part 1, I think we need more time to explore the 
>utility for these name forms.  The debate on the list shows that there are 
>widely diverse opinions about what such IDs are good for, what scope is 
>feasible/appropriate, etc.  I'd hesitant to hold up progress on the 
>revision to 2459 to add this sort of facility which has been proposed only 
>recently.  That's why several folks have suggested a separate, small 
>document whoch can be advanced separately, and merged into 2459 if there 
>is sufficient, consistent support.
>
>Steve