headers
Stefan Santesson | 1 Dec 1999 01:19
Picon

Re: dnQualifier topic - not solved yet.

Charles,

You wanted me to address your issues. Well I regard David's reply here as a
good expression of my view as well.

/Stefan

At 06:46 PM 11/30/99 -0500, David P. Kemp wrote:
>
>> From: "Charles Moore" <cmoore <at> spyrus.com.au>
>> 
>> So if nobody strongly object to this I will go ahead and include this in
>> the QC profile and I assume that rfc 2459 will be updated accordingly
>> 
>> cm> I object for the reasons previously outlined.. You are using it with the
>> wrong sematics and it will be impossible to distinguish from previous usage
>> that has the correct semantics...
>> Please address these issues...
>
>Charles,
>
>I don't understand this objection.  If X.520 is modified as suggested
>(so that serialNumber applies to person objects as well as device objects),
>what is "incorrect" about the semantics?   To my American English ear :-),
>the word "serialNumber" when applied to a person means the same thing
>as "employee number" or "customer number" when applied to a person, or
>"VIN" when applied to an automobile.  The word "number" shouldn't be
>the problem - even when applied to devices such as modems and
>lawnmowers, serial numbers are generally alphanumeric, not purely
>numeric.
(Continue reading)

Permalink | Reply | 501 comments |
headers
Charles Moore | 1 Dec 1999 01:52
Picon

RE: unqualified topic - not solved yet.

comments in line...

-----Original Message-----
From: Stefan Santesson [mailto:stefan <at> accurata.se]
Sent: Wednesday, 1 December 1999 10:20
To: Charles Moore; ietf-pkix <at> imc.org
Cc: David P. Kemp
Subject: Re: dnQualifier topic - not solved yet.

Charles,

You wanted me to address your issues. Well I regard David's reply here as a
good expression of my view as well.

/Stefan

At 06:46 PM 11/30/99 -0500, David P. Kemp wrote:
>
>> From: "Charles Moore" <cmoore <at> spyrus.com.au>
>> 
>> So if nobody strongly object to this I will go ahead and include this in
>> the QC profile and I assume that rfc 2459 will be updated accordingly
>> 
>> cm> I object for the reasons previously outlined.. You are using it with
the
>> wrong sematics and it will be impossible to distinguish from previous
usage
>> that has the correct semantics...
>> Please address these issues...
>
(Continue reading)

Permalink | Reply | 1 comment |
headers
Tony Bartoletti | 1 Dec 1999 02:35

RE: unqualified topic - not solved yet.

All,

At first, I didn't understand Charles' objection at all.  Other than
a philosophic objection to being treated as a "device", the "serialNumber"
seems to fulfill the intended purpose.  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.

While also swayed by Peter's "only unique-per-issuer" argument, there
are some subtle differences.  I can certainly go from one bank to another
and obtain a new "customer account number".  But however I change my state
of residence, each state expects my car (if it is the same car) to be
registered with the same VID (vehicleID) it always had, no exceptions.

Now, to my understanding, QCs dream of maintaining this same degree of
association to my ... me.  And so long as this QC contains only "soft"
references to "me", no real problem.  But when biometric elements are
included, it becomes quite a bit more like a chassis-stamped VehicleID,
and able to be "globalized" independent of the originally local intent.

But this is more a complaint about the QC-uniqueness concept per-se.
If you go with it, then "serialNumber" seems to hit the mark precisely;)

Comments?  

___tony___

Tony Bartoletti                                             LL
IOWA Center                                              LL LL
Lawrence Livermore National Laboratory                LL LL LL
(Continue reading)

Permalink | Reply | 0 comments |
headers
Charles Moore | 1 Dec 1999 03:16
Picon

RE: unqualified topic - not solved yet.


-----Original Message-----
From: Tony Bartoletti [mailto:azb <at> llnl.gov]
Sent: Wednesday, 1 December 1999 11:35
To: Charles Moore; 'Stefan Santesson'; ietf-pkix <at> imc.org
Cc: David P. Kemp
Subject: RE: unqualified topic - not solved yet.

All,

At first, I didn't understand Charles' objection at all.  Other than
a philosophic objection to being treated as a "device", the "serialNumber"
seems to fulfill the intended purpose. 
cm> Not realy a philosophic objection, sematics are part of the information
transfer, if I expect that the semantics of the syntax assocaited with
serial number are "a device"  and you expect it to be a person, why would
you expect the information transfer to be complete or meaningfull. 
If sematics are not imporatnt then just use the syntax of DirectoryString...
I belive sematics are important to achiveing a sucessful transfer of
information...Overloading semantics has all the problems of versioning and
object reuse... My preference is to solve changing semantics and also syntax
by a explicit change....

 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
(Continue reading)

Permalink | Reply | 0 comments |
headers
Tony Bartoletti | 1 Dec 1999 03:21

Re: Server-signatures: Re: proposed key usaged text -- the final round

At 09:08 AM 11/28/1999 -0000, Anders Rundgren wrote:
>Hi Guys,
>I just wonder how your NR-text matches server-based signatures.
>The following text of yours indicates some problems in this area:
>
>
>    >The protection afforded private keys is a critical factor in main-
>    >taining security. On a small scale, failure of users to protect
>    >their private keys will permit an attacker to masquerade as them, or
>    >decrypt their personal information. [stuff about CA keys deleted]
>
>
>"entity owning the private keys" used in other places looks like a
>good replacement for user.   Or why not start with a definition of
>user that can be both a person or a device and that
>a person can be the owner or just be a trusted user (employee) of said private keys?

Anders,

Let me explore the latter application.  Suppose I am a "company-trusted"
employee, using a company-owned "private key".  I assume further that the
company has its own mechanism for (hoping to) control who has the use of
a given key at a given time, or at least who is responsible for its use.

Now, I use the private key in question, entering into some obligation with
an external RP.  Later, I attempt to deny my actions, causing this RP some
hardship.

My understanding is that this "bindings" in question look like:
(Continue reading)

Permalink | Reply | 0 comments |
headers
Anders Rundgren | 1 Dec 1999 05:58

Re: Server-signatures: Re: proposed key usaged text -- the final round

Tony,
I may be wrong but I assumed that the text below was to be included in the NR-document
and if so is the case it talks about things like "users" and "personal information" which
is not coherent with server-generated signatures.

>>    >The protection afforded private keys is a critical factor in main-
>>    >taining security. On a small scale, failure of users to protect
>>    >their private keys will permit an attacker to masquerade as them, or
>>    >decrypt their personal information. [stuff about CA keys deleted]

When I refer to server-based signatures I meant for example things like automated
bills from energy and phone companies.  Such bills are usually never touched by
a human and would typically only have a company ID of some kind as subject when/if
converted into an electronic digitally signed format.

The user is "certificateSubject" or "entity owning the private keys"

<snip>

I agree with your nicely formulated lines regarding "company owned keys" below

>Let me explore the latter application.  Suppose I am a "company-trusted"
>employee, using a company-owned "private key".  I assume further that the
>company has its own mechanism for (hoping to) control who has the use of
>a given key at a given time, or at least who is responsible for its use.
>
>Now, I use the private key in question, entering into some obligation with
>an external RP.  Later, I attempt to deny my actions, causing this RP some
>hardship.
>
(Continue reading)

Permalink | Reply | 835 comments |
headers
Anders Rundgren | 1 Dec 1999 07:35

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

<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....
(Continue reading)

Permalink | Reply | 0 comments |
headers
Charles Moore | 1 Dec 1999 07:02
Picon

RE: unqualified topic - not solved yet.


-----Original Message-----
From: Anders Rundgren [mailto:anders.rundgren <at> jaybis.com]
Sent: Wednesday, 1 December 1999 16:36
To: Charles Moore; 'Tony Bartoletti'; 'Stefan Santesson';
ietf-pkix <at> imc.org
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
(Continue reading)

Permalink | Reply | 1 comment |
headers
Anders Rundgren | 1 Dec 1999 09:47

Re: unqualified topic - not solved yet.

Charles,

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

The current draft states TWO uses of dnQualifier.  With the serialNumber
addition it does only have to have ONE use.  Differentiator.

It is very unlikely but not forbidden to use both attributes in a certificate.

<snip>

>I believe that the QC profile needs to support both national or
>jurisdictional requirements. 

That is something that I believe all interested parties want.

Anders
Permalink | Reply | 0 comments |
headers
Stefan Santesson | 1 Dec 1999 10:38
Picon

RE: unqualified topic - not solved yet.

Charles,

At 04:02 PM 12/1/99 +1000, Charles Moore wrote:
<snip>
>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....
>

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.
(Continue reading)

Permalink | Reply | 0 comments |

Gmane