Subject: RE: unqualified topic - not solved yet.

From: Charles Moore <[email-masked]>
Date: Wed, 1 Dec 1999 16:02:04 +1000

-----Original Message-----
From: Anders Rundgren [mailto:[email-masked]]
Sent: Wednesday, 1 December 1999 16:36
To: Charles Moore; 'Tony Bartoletti'; 'Stefan Santesson';
[email-masked]
Cc: David P. Kemp
Subject: Re: unqualified topic - not solved yet.

Charles,
Being the one who originally brought this pesty thing out of the dark
I will try to comment this

<snip>

> Indeed, I would like Charles to
>elaborate just a bit on how the "wrong semantics" would now conflict
>with the "right semantics" already in use.  Concrete examples if possible.
>
>cm> I issue a cert to a machine ( under deligation policy rules) I want the
>delegation to be controlled to a specific machine and make use of a machine
>serail number... I place the serial number into the attraibute... Alll
works
>ok ( also belive that the semantics assocaited with "machine serial numebr
>are uniqueness)...  Now all of a sudden I get one of these PKIX things that
>has National ID  of a person in the same attribute... I apply my policy
that
>says that any certifiacte for a device must have a serial number and .....

I don't see why this should be a probem.  Every certificate-class can (and
usually have)
its own CPS and rules. 

cm> Agree that every certificate may have one or more Certificate
policies...

  The serialNumber stuff is just an OPTION (but for certain
classes of certificates it will be mandatory) that an RP can use in such a
way that
QCs indeed can be compared which was where all this started.

cm> I thought ( based on the current draft)  that serial numbers were used
to assist in the "unmistakable identity" requirement ( actually like the
current text)...

Now I would have a problem that a CP would overload the semantics of
Attribute ( I believe in CPS but not sure this is really viable to
deploy)...

<snip>

>cm> Need to determine if serial number is the single attribute for
>uniqueness ?, this would be a problem from my perspective, or it is for
>determining uniquess when there are no other unique attribute....  The
first
>is a problem for a global QC the latter should meet the requirements as I
>have seen them stated....

I hope that the semanics are such that if serialnumber is available the
rest of subject (or issuer) data (available or not) can be treated as
"informative" only.

cm> I assumed that serial number takes on the role assigned in the QC
profile to Dnq, making this informative would not be useful??? Would it?
Perhaps I have missed something fundamental...

Exactly what naming domain serialNumber belongs to, I assume unfortunately
is still be a part of CPS.  I.e. it could be CA-unique or "externally
defined"

cm> I believe that the naming rules i.e. what attribute to use and when, are
part of the CP rules.

Regarding global QCs: Assuming that QC CAs do not use conflicting issuer
names
all conforming QCs should be globally unique regardless if they use
serialNumber or not.

cm> Experience has been that the list of normal naming attributes do not
lead to such a solution, we have used dnq and also private attributes to
solve these issues.

The serialNumber  is AFAIK just a way to support a [usually static] unique
single-attribute
identity concept for a certain subject.  Under some regimes like national
ID-systems you may have to
keep this number (string) your whole life, while you some other contexts
often will be able to get a new
serialnumber if you feel that you have "worn out" your electronic identity.

cm> Agree, but I believe that one can achieve "unmistakable identity"
without the need for all subjects of a CA to have a value of a unique
identifier. While I accept that some jurisdictions require a unique number,
there are jurisdictions that provide protection against such identification.
I believe that the QC profile needs to support both national or
jurisdictional requirements. 

The single-attribute identity concept is very suitable for access control
systems that have
huge problems coping with a variant set of attributes of arbitrary length
and type.

cm> I have no problem with such a requiremnt,and this can be enforced by CP.

My guess is that this kind of use will be dominant.
cm> The real issue is that I dont believe it is the single only solution or
requirement.

Back to the past....

I am not arguing that serial number or dnq be exclusively used, my personal
preference would be dnq, but rather require we have a standard that reflects
reality and provides a long term solution that can be used by all existing
communities...not selective interest groups...

I have a problem with overloading of semantics, as they produce
indeterminate results...
I also dont believe a CP is the means to achieve this, keep the protocol
clean and use rules/policy to determine the usage....

Anders

---

From: Stefan Santesson <[email-masked]>
Date: Wed, 01 Dec 1999 10:38:06 +0100

Charles,

At 04:02 PM 12/1/99 +1000, Charles Moore wrote:
<snip>
>clean and use rules/policy to determine the usage....

One thing that may have to be clarified here is that I have had a dialogue
with Sharon Boyen, who is involved in the X.509, X.520 and X.521
standardization, and she claims that they are willing to change the
definition of serialNumber and related object classes, so that this
attribute can be used for any type of object.

Sharon says that this is considered to be a minor adjustment that almost
was fixed 4 years ago but was forgotten in the process.

This is the fundamental reason for proposing use of serialNumber.

Having this in mind, I fail to see any problems.

I' don't want to enter a privacy discussion here, but I just want to stress
that there is NOTHING in the QC profile that require inclusion of privacy
sensitive information. In fact, the possibility to use a Pseudonym name is
clearly stated. The use of a unique identifier doesn't necessarily means
that it is privacy sensitive. That depends completely what you can do with
that number.

The fact is that we need to add support for inclusion of such identifiers,
regardless of their actual content.

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