Subject: SV: SV: Permanent identifiers in QC

From: "Stefan Santesson" <[email-masked]>
Date: Mon, 3 Apr 2000 21:19:16 +0930

Tom,

I support your concerns.

I believe though that what the present solution already handles the issues
that you are addressing. At least as far as it ought to.

The qcStatemsnts extension are there to express policy statements. The
predefined statement is there to express that the certificate follows syntax
and semantics of the QC profile. The optional qualifying information may
hold information that the certificate further adopts to a certain ID-scheme
(such as a specific Italian ID-scheme).

I don't think we should expand that feature beyond that.

What I think we should do know is to move this forward.

/Stefan

> -----Ursprungligt meddelande-----
> Från: [email-masked] [mailto:[email-masked]]
> Skickat: den 1 april 2000 09:14
> Till: Stefan Santesson
> Kopia: [email-masked]
> Ämne: Re: SV: Permanent identifiers in QC
>
>
>      I take your point about duplicating the serial number using the
> two-name form I proposed for
> id-qcs-identifierAssignmentAuthority, and I
> hereby withdraw that suggestion.
>      However, assuming that adding name information in the
> qcStatements
> extension contradicts the purpose of that extension, I still
> do not see why
> the one-name version of id-qcs-identifierAssignmentAuthority,
> in which the
> only name in the extension is the name of the identifier assignment
> authority, contradicts the purpose of the extension.  The
> draft's current
> definition says about the name component: "The
> NameRegistrationAuthorities
> component, if present, SHALL contain a name of one or more name
> registration authorities, responsible for registration of
> attributes or
> names associated with the subject."  Why does the assigner of a serial
> number not fit into this definition of a registration authority?
>      Equally, id-qcs-nationalIdentifier and id-qcs-CALocal define the
> semantics of an existing attribute in a DN within the
> certificate.  How
> does that contradict the statement that a semantics ID "may define
> semantics for all, or for a subgroup of all present attributes and/or
> names"?  Perhaps it would be more in keeping with the spirit
> of the profile
> if there were two different OID's for each of these three
> semantics, one to
> interpret subject name serial numbers and one to interpret subject
> alternate name serial numbers, but that is not a reason not
> to have the
> feature available.
>
>           Tom Gindin
>
>
> "Stefan Santesson" <[email-masked]> on 03/31/2000 06:45:54 AM
>
> To:   Tom Gindin/Watson/IBM@IBMUS, "'Stefan Santesson'"
>       <[email-masked]>
> cc:   <[email-masked]>
> Subject:  SV: Permanent identifiers in QC
>
>
>
> Tom,
>
> Using this extension to contain subject name information
> would break the
> intent of this extension.
>
> /Stefan
>
> > -----Ursprungligt meddelande-----
> > Från: [email-masked] [mailto:[email-masked]]
> > Skickat: den 31 mars 2000 09:10
> > Till: Stefan Santesson
> > Kopia: [email-masked]
> > Ämne: Re: Permanent identifiers in QC
> >
> >
> >      I have a counter-proposal.  Given the profile defined for
> > serialNumber, and the definition of SemanticsInformation in
> > draft section
> > 3.2.5.1, a semanticsIdentifier known as
> > id-qcs-identifierAssignmentAuthority should be assigned with
> > the following
> > rules of interpretation: either one or two name registration
> > authorities
> > must be present, and the first one present shall be
> interpreted as the
> > authority governing the name space, while the second
> > (optional) one may
> > contain the serial number or other unique identifier; if
> > there is only one
> > name registration authority present, the unique identifier is
> > assumed to be
> > the serial number attribute of the subject name if there is a
> > serial number
> > attribute in it, and the first serial number attribute
> > encountered in the
> > subject alternate name if there is none in the subject
> name.  Another
> > semanticsIdentifier known as id-qcs-CALocal should be
> > assigned to identify
> > serial numbers assigned locally within the CA.  Optionally, a
> > semanticsIdentifier known as id-qcs-nationalIdentifier might also be
> > assigned with the rule that when one searches for the serial
> > number in the
> > subject name and subject alternate name in the same way as
> > for identifier
> > assignment authorities with only one name registration
> authority, the
> > serial number shall be interpreted as being assigned by the
> > country given
> > in the DN where the serial number is found.
> >
> >           Tom Gindin
> >
> >
> > "Stefan Santesson" <[email-masked]> on 03/30/2000 01:49:44 AM
> >
> > To:   <[email-masked]>
> > cc:
> > Subject:  Permanent identifiers in QC
> >
> >
> >
> > The PKIX meeting in Adelaide raised only 1 issue related to
> > the QC draft.
> >
> > This issue is whether we should include a new name form in the
> > subjectAltName extension holding  a permanent identifier.
> >
> > The permanent identifier would then be a name of the subject,
> > unique within
> > the issuers domain, that is not reused over time for
> another subject.
> >
> > The reason to include such a name form would be that the use of
> > serialNumber in DN, or directoryName in subjectAltName
> > extension, does not
> > explicitly define this property by itself, unless seen in the
> > light of a
> > defined policy etc.
> >
> > Chair Stephen Kent decided that the decision whether or not
> > to include this
> > name form in QC should be taken to the list.
> >
> > My observation in regards to this is:
> >
> > 1) Adding this name form would add confusion to the QC
> > specification since
> > it would overlap use of serialNumber in the DN.
> >
> > [Tom Gindin]   Why would this cause confusion if the name
> > form itself had
> > the same syntax as a DN, and the identity were in the serialNumber
> > attribute of that name?
> >
> > 2) Use of DN attributes covers all needs related to
> > identification of the
> > subject, and that's all we need to support electronic
> > signatures, at least
> > as seen from the EU-directive. And as far I know, this goes
> > for any other
> > legal system.
> >
> > [Tom Gindin]   This does not cover the joint specification of
> > an ID and an
> > assignment authority.  A single ID field with quasi-arbitrary values
> > similar to a serial number has meaning primarily within the
> > scope of its
> > assignment authority.
> >
> > 3) Use of DN in combination with either implicit knowledge, use of
> > Directory name in the subjectAltname ext, use of a related policy
> > identifier or use of information in the qcStatements
> > extension also provide
> > support for use of permanent identifiers identified as such.
> >
> > [Tom Gindin]   No rule for implicit knowledge which would permit an
> > arbitrary RP to recognize a permanent identifier and its assignment
> > authority within a DN (whether subject name or alt name)
> has yet been
> > received with favor.  However, it should be possible to do
> > this using the
> > semanticsIdentifier.
> >
> > 4) In each and every case raised in favor of this new name form, the
> > benefit relates to access control rather than electronic signatures.
> >
> > [Tom Gindin]   Allowing organizations to assign permanent
> > identifiers of
> > this type (most usually, but not necesarily, to employees)
> > has roughly the
> > same impact on signatures as on access control.  If it is
> > assumed that the
> > identity number is assigned by a governmental or quasi-governmental
> > authority, then the serial number is sufficient because my
> > above arguments
> > for assignment authority become irrelevant.
> >
> > 5) This is a new input to the discussion, which before
> > adoption must be
> > reviewed by the community over some time.
> >
> > [Tom Gindin]   It has been under discussion for months.
> >
> > Observation 4 makes this whole discussion outside the scope
> > of QC and in
> > combination with the other observations, I would request that
> > the QC is
> > moved forward to proposed standard without this new name form.
> >
> > [Tom Gindin]   If QC requires that the serial number be
> > assigned either by
> > a governmental or quasi-governmental authority as a permanent
> > identifier or
> > by the CA as a tiebreaker, and that the certificate itself contain
> > somewhere an indicator of whether the name is a permanent
> > identifier or a
> > tiebreaker, then this name form would not be relevant to
> > QC's.  Otherwise
> > it would.
> >
> > If PKIX at a later stage would find that a permanent
> > identifier solution,
> > as discussed here, is of general value, then this can be
> > moved forward as a
> > separate item. At that time we would also know if it should
> > be merged with
> > RFC 2459 or the QC profile, if merged at all.
> >
> >
> >
> > /Stefan
> >
>
>
>

---

From: [email-masked]
Date: Mon, 3 Apr 2000 11:22:57 -0400

But I don't think you answered my questions.  Why is "the serial
number in the subject DN was assigned by the following naming authority"
not a valid QC statement?  Also, why are "the serial number in the subject
DN represents a national identity number" or "the serial number in the
subject DN was assigned locally by the issuer" not valid QC statements?
     These are certainly "defined statements related to Qualified
Certificates", and there is no other place for them in the certificate.  If
qcStatements are restricted purely to statements of policy, why is not the
extension redundant with the existing policy extension?  The present
solution does NOT provide for statements of this sort to go into the
certificate except insofar as an OTHER-NAME could be defined outside the
profile, and to say that it does so "as far as it ought to" is to say that
there should be no standard way of putting them in.  Note that Russ
Housley, at least, is opposed to putting any new name forms into either
profile.
     Your example of the qualifying information is, in fact, a case of
either "assigned by the following naming authority" or "represents a
national identity number".  If these features are to be made widely
interoperable, the object identifiers should be in one of the common
profiles.  I agree that we should move forward, but with this feature
rather than without it.

          Tom Gindin

"Stefan Santesson" <[email-masked]> on 04/03/2000 07:49:16 AM

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

Tom,

I support your concerns.

predefined statement is there to express that the certificate follows
syntax

/Stefan

---

From: "Anders Rundgren" <[email-masked]>
Date: Mon, 3 Apr 2000 22:23:40 +0100

Tom,

>subject DN was assigned locally by the issuer" not valid QC statements?

I agree that these look like valid QC statements but I doubt that they
are universal enough.   If you need "the serial number + organization in the
subject DN is a permanent ID within the local CA domain" you run into
problems.   We do need some kind of extension but it should be parameterized
to cover different naming schemes.  IMO at least.

Anders
<snip>

---

From: Michael Myers <[email-masked]>
Date: Thu, 6 Apr 2000 13:02:08 -0700

All,

I agree with Russ.  I see no reason for PKIX to establish requirements
governing or defining the notion of a permanent identifier.  We establish
means by which entity identification values can be bound to a public key.
We do not establish requirements on specific instances.  That is the task of
other WGs.  

Mike

> -----Original Message-----
> From: Russ Housley [mailto:[email-masked]]
> Sent: Friday, March 31, 2000 11:52 PM
> To: [email-masked]
> Subject: Re: Permanent identifiers in QC
> 
> 
> I cannot see any reason for PKIX to specify a permanent identifier.
> 
> In my view, it is the job of PKIX (in the son-of-RFC2459 
> document and the 
> companion QC document) to specify the means to bind an 
> identity to a public 
> key.  This does not include specifying new methods of specifying an 
> identity.  If some Internet application needs a permanent 
> identifier, then 
> the needy application should specify it.  Once it is 
> specified, it can be 
> used in certificates, just like all of the other name forms that are 
> already supported.
> 
> Russ
> 
> 
> At 04:19 PM 03/30/2000 +0930, Stefan Santesson wrote:
> >The permanent identifier would then be a name of the 
> subject, unique within
> >the issuers domain, that is not reused over time for another subject.
> >
> >The reason to include such a name form would be that the use 
> of serialNumber
> >in DN, or directoryName in subjectAltName extension, does 
> not explicitly
> >define this property by itself, unless seen in the light of 
> a defined policy
> >etc.
> >
> >3) Use of DN in combination with either implicit knowledge, 
> use of Directory
> >name in the subjectAltname ext, use of a related policy 
> identifier or use of
> >information in the qcStatements extension also provide 
> support for use of
> >permanent identifiers identified as such.
> >
> >4) In each and every case raised in favor of this new name 
> form, the benefit
> >relates to access control rather than electronic signatures.
> >
> >combination with the other observations, I would request 
> that the QC is
> identifier solution, as
> >discussed here, is of general value, then this can be moved 
> forward as a

---

From: "Anders Rundgren" <[email-masked]>
Date: Sun, 9 Apr 2000 17:32:07 +0100

<snip>

>Looking over this thread, and recalling Denis's presentation in Adelaide, I agree with Stefan that IF we were to adopt a permanent >ID name type in PKIX, the motivations cited by Denis for his proposal are access control based and thus NOT suitable for inclusion >in the QC document. Also, since there is still disagreement over other motivations for such identifiers, and their form in QCs, I think >it unwise to incluide them in the QC document at this late date. Thus I believe that we are ready to proceed with the QC document.

Steve, you are right that it may be best to proceed with the QC document, but you are definitely wrong when you
say that permanent IDs only apply to access control.  They apply to ANY situation where the identity of the signer,
authenticator etc has to be verified on-line.  From Internet-banking to authority-to-citizen communication.  At least if
TTPs are used as CAs for client certficates.

<snip>

Anders

---

From: "David P. Kemp" <[email-masked]>
Date: Mon, 10 Apr 2000 13:15:21 -0400 (EDT)

Anders,

Perhaps Steve meant access control in a broader sense than you mean it.

When a human views an authenticated identity, it might be solely for
the purpose of being able to say "yeah, that's nice".  And a machine
might capture an authenticated identity solely for tracking or audit
purposes.

But for the applications you mention, there is a decision made on the
basis of the authenticated identity: the bank grants access to a
particular account, the authority grants access to a particular
citizen's records.  Do you have in mind any scenario where an identity
is authenticated but not used to mediate access to a resource?

Dave

> From: "Anders Rundgren" <[email-masked]>
> To: <[email-masked]>, "Stephen Kent" <[email-masked]>
> Date: Sun, 9 Apr 2000 17:32:07 +0100
> 
> >Looking over this thread, and recalling Denis's presentation in Adelaide, I 
agree with Stefan that IF we were to adopt a permanent >ID name type in PKIX, 
the motivations cited by Denis for his proposal are access control based and 
thus NOT suitable for inclusion >in the QC document. Also, since there is still 
disagreement over other motivations for such identifiers, and their form in QCs, 
I think >it unwise to incluide them in the QC document at this late date. Thus I 
believe that we are ready to proceed with the QC document.
> say that permanent IDs only apply to access control.  They apply to ANY 
situation where the identity of the signer,
> authenticator etc has to be verified on-line.  From Internet-banking to 
authority-to-citizen communication.  At least if
> TTPs are used as CAs for client certficates.
*******************************************************************************
> This confirms that this email message has been swept by
> MIMEsweeper for the presence of computer viruses.
> 
*******************************************************************************