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

From: "Anders Rundgren" <[email-masked]>
Date: Wed, 1 Dec 1999 04:58:39 -0000

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.
>
>My understanding is that this "bindings" in question look like:
>
>   RP <---> Transaction <---> Key/Cert <---> Company <---> Me
>
>That is, the RP must take up issue with the company, being the owner
>(or certSubject or Operator) of the key, directly.  It falls upon the
>company to follow the chain, so to speak, and take me to task.
>
>The central point is that the RP has only a certificate, and its
>"named holder", to point to in a dispute.  If the means by which
>the company above "secures the connection between key and user"
>is hidden from view, no amount of NR-servicing on the RP side can
>suffice to hold the "user" accountable.  They are forced instead to
>pressure the company, who may in turn pressure the employee.

>Perhaps I don't fully understand all of the details you assume to
>hold in the server-based example.  I may be confusing different
>scenarios:
>
>1.  Cert says "owned by BigCorp, as key nnn" but I control its use,
>    or at least I did last Thursday when I checked it out.

This is the hard one.  "I" may have checked it out but I installed in
an automated system which is administered and owned by BigCorp

>2.  Cert says "owned by Tony", and the company controls its use in
>    some automated system, with my supposed blessings/restrictions.
>
>In the second case, the RP would be expected to come after me directly.
>If I am innocent, I am forced to take issue with the company.

Unusual case but possible¨

>
>In each case, the RP can turn only to the "certificateSubject".

Absolutely!  But the reference in the cited text in the beginning is slightly wrong if
it deals woth personal data in situations like #1

Anders

From: "Anders Rundgren" <[email-masked]>
To: "Charles Moore" <[email-masked]>, "'Tony Bartoletti'" <[email-masked]>, "'Stefan Santesson'" <[email-masked]>, <[email-masked]>
Cc: "David P. Kemp" <[email-masked]>
Subject: Re: unqualified topic - not solved yet.
Date: Wed, 1 Dec 1999 08:47:44 -0000

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

From: Charles Moore <[email-masked]>
To: "'Anders Rundgren'" <[email-masked]>, Charles Moore <[email-masked]>, "'Tony Bartoletti'" <[email-masked]>, "'Stefan Santesson'" <[email-masked]>, [email-masked]
Cc: "David P. Kemp" <[email-masked]>
Subject: RE: unqualified topic - not solved yet.
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: "Anders Rundgren" <[email-masked]>
To: "Charles Moore" <[email-masked]>, "'Tony Bartoletti'" <[email-masked]>, "'Stefan Santesson'" <[email-masked]>, <[email-masked]>
Cc: "David P. Kemp" <[email-masked]>
Subject: Re: unqualified topic - not solved yet.
Date: Wed, 1 Dec 1999 06:35:52 -0000

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

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.

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"

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.

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.

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.
My guess is that this kind of use will be dominant.

Anders

From: "Anders Rundgren" <[email-masked]>
To: "Denis Pinkas" <[email-masked]>, "Russ Housley" <[email-masked]>, "Tim Polk" <[email-masked]>, <[email-masked]>, "Tony Bartoletti" <[email-masked]>
Subject: Re: Server-signatures: Re: proposed key usaged text -- the final round
Date: Wed, 1 Dec 1999 04:58:39 -0000

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.
>
>My understanding is that this "bindings" in question look like:
>
>   RP <---> Transaction <---> Key/Cert <---> Company <---> Me
>
>That is, the RP must take up issue with the company, being the owner
>(or certSubject or Operator) of the key, directly.  It falls upon the
>company to follow the chain, so to speak, and take me to task.
>
>The central point is that the RP has only a certificate, and its
>"named holder", to point to in a dispute.  If the means by which
>the company above "secures the connection between key and user"
>is hidden from view, no amount of NR-servicing on the RP side can
>suffice to hold the "user" accountable.  They are forced instead to
>pressure the company, who may in turn pressure the employee.

>Perhaps I don't fully understand all of the details you assume to
>hold in the server-based example.  I may be confusing different
>scenarios:
>
>1.  Cert says "owned by BigCorp, as key nnn" but I control its use,
>    or at least I did last Thursday when I checked it out.

This is the hard one.  "I" may have checked it out but I installed in
an automated system which is administered and owned by BigCorp

>2.  Cert says "owned by Tony", and the company controls its use in
>    some automated system, with my supposed blessings/restrictions.
>
>In the second case, the RP would be expected to come after me directly.
>If I am innocent, I am forced to take issue with the company.

Unusual case but possible¨

>
>In each case, the RP can turn only to the "certificateSubject".

Absolutely!  But the reference in the cited text in the beginning is slightly wrong if
it deals woth personal data in situations like #1

Anders

Date: Tue, 30 Nov 1999 18:21:16 -0800
To: "Anders Rundgren" <[email-masked]>, "Denis Pinkas" <[email-masked]>, "Russ Housley" <[email-masked]>, "Tim Polk" <[email-masked]>, <[email-masked]>
From: Tony Bartoletti <[email-masked]>
Subject: 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:

   RP <---> Transaction <---> Key/Cert <---> Company <---> Me

That is, the RP must take up issue with the company, being the owner
(or certSubject or Operator) of the key, directly.  It falls upon the
company to follow the chain, so to speak, and take me to task.

The central point is that the RP has only a certificate, and its
"named holder", to point to in a dispute.  If the means by which
the company above "secures the connection between key and user"
is hidden from view, no amount of NR-servicing on the RP side can
suffice to hold the "user" accountable.  They are forced instead to
pressure the company, who may in turn pressure the employee.

Perhaps I don't fully understand all of the details you assume to
hold in the server-based example.  I may be confusing different
scenarios:

1.  Cert says "owned by BigCorp, as key nnn" but I control its use,
    or at least I did last Thursday when I checked it out.

2.  Cert says "owned by Tony", and the company controls its use in
    some automated system, with my supposed blessings/restrictions.

In the second case, the RP would be expected to come after me directly.
If I am innocent, I am forced to take issue with the company.

In each case, the RP can turn only to the "certificateSubject".

Could you elaborate?

___tony___ 

Tony Bartoletti                                             LL
IOWA Center                                              LL LL
Lawrence Livermore National Laboratory                LL LL LL
PO Box 808, L - 089                                   LL LL LL
Livermore, CA 94551-9900                              LL LL LLLLLLLL
phone: 925-422-3881   fax: 925-423-8081               LL LLLLLLLL
email: [email-masked]                                   LLLLLLLL

From: Charles Moore <[email-masked]>
To: "'Tony Bartoletti'" <[email-masked]>, "'Stefan Santesson'" <[email-masked]>, [email-masked]
Cc: "David P. Kemp" <[email-masked]>
Subject: RE: unqualified topic - not solved yet.
Date: Wed, 1 Dec 1999 12:16:34 +1000 

-----Original Message-----
From: Tony Bartoletti [mailto:[email-masked]]
Sent: Wednesday, 1 December 1999 11:35
To: Charles Moore; 'Stefan Santesson'; [email-masked]
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
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 .....

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

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

Comments?  

___tony___

Tony Bartoletti                                             LL
IOWA Center                                              LL LL
Lawrence Livermore National Laboratory                LL LL LL
PO Box 808, L - 089                                   LL LL LL
Livermore, CA 94551-9900                              LL LL LLLLLLLL
phone: 925-422-3881   fax: 925-423-8081               LL LLLLLLLL
email: [email-masked]                                   LLLLLLLL

Date: Tue, 30 Nov 1999 17:35:11 -0800
To: Charles Moore <[email-masked]>, "'Stefan Santesson'" <[email-masked]>, [email-masked]
From: Tony Bartoletti <[email-masked]>
Subject: RE: unqualified topic - not solved yet.
Cc: "David P. Kemp" <[email-masked]>

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
PO Box 808, L - 089                                   LL LL LL
Livermore, CA 94551-9900                              LL LL LLLLLLLL
phone: 925-422-3881   fax: 925-423-8081               LL LLLLLLLL
email: [email-masked]                                   LLLLLLLL

From: Charles Moore <[email-masked]>
To: "'Stefan Santesson'" <[email-masked]>, Charles Moore <[email-masked]>, [email-masked]
Cc: "David P. Kemp" <[email-masked]>
Subject: RE: unqualified topic - not solved yet.
Date: Wed, 1 Dec 1999 10:52:40 +1000 

comments in line...

-----Original Message-----
From: Stefan Santesson [mailto:[email-masked]]
Sent: Wednesday, 1 December 1999 10:20
To: Charles Moore; [email-masked]
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" <[email-masked]>
>> 
>> 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? 
Problem: a) there are existing implementation of serial number. From the
current standard:
"5.2.9	Serial Number 
The Serial Number attribute type specifies an identifier, the serial number
of a device. 
An attribute value for Serial Number is a printable string. "..
Clearly the standard does not cover your requirement today...
Should the ITU change the semantics of the serial number to be as above,
they had better change the OID!! otherwise the protocol is broke....
This amounts to defining a new attribute, where we started from...

  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.

cm> This approach is a) hard to intepret from the standard, and if this
stretch is made for serial number then it can also be applied to
dnQualifier...b) the result does no meet the requirement see my previous
email on this subject...

>
>What incompatibility or problem with existing usage would be caused by
>adding "person" to the class of objects to which serialNumber applies?

cm> Why add when there are already classes that include Dnq, and what you
propose does not fix the problem, refer to above rational...

>
>
>
>> The proposal was previously presented as:
>> > I suggest that we:
>> >
>> > - Add serialNumber to son of rfc2459 supportedAttributes as a MUST
>> > implement attribute (i.e. compliant applications MUST be able to
>> understand
>> > it).
>> cm> See above this is not possible given existing usage...
>> Also please address the usage and privacy issue....
>
>What privacy issue?  There is nothing that implies a serialNumber attribute
>must be a National ID (or a Global ID); more likely it will be unique
>per issuer. 
cm> I would respectfully submit that serial number and uniqueness are part
of the semantics... Remember this si a standard existing attribute, in use
today....

 Your customer number from Land's End Direct Merchants is
>different from your driver's license number, your bank account
>number(s), and your brokerage account number(s), and your employer's
>retirement account number.

cm> Need to explain further, I dont understand the point...
>
>Your proposed new attribute would be no different from serialNumber from
>a privacy perspective - privacy is affected by the scope of uniqueness
>(the number of databases which know you by a particular identifier),
>not by the choice of attribute OID.

cm> Sorry, you are not correct... We need to uniquely differentiate people
using a unique identifier, this does NOT imply that all people that receive
qualified certificates MUST have an unique identifier... this is very
important.... We have a culture that goes to great lengths ( including legal
protection) preventing the application of unique numbers to people)... 
>
>
>> > It would help to get your immediate support for this. Can you live with
>> it??
>> 
>> cm> No...
>
>So far the consensus for serialNumber seems smooth, with only one nay.

cm> Is this an international standard or not, consensus is not based on
volume of a few...
End soap...

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

Date: Wed, 01 Dec 1999 01:19:54 +0100
To: "Charles Moore" <[email-masked]>, [email-masked]
From: Stefan Santesson <[email-masked]>
Subject: Re: dnQualifier topic - not solved yet.
Cc: "David P. Kemp" <[email-masked]>

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" <[email-masked]>
>> 
>> 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.
>
>What incompatibility or problem with existing usage would be caused by
>adding "person" to the class of objects to which serialNumber applies?
>
>
>
>> The proposal was previously presented as:
>> > I suggest that we:
>> >
>> > - Add serialNumber to son of rfc2459 supportedAttributes as a MUST
>> > implement attribute (i.e. compliant applications MUST be able to
>> understand
>> > it).
>> cm> See above this is not possible given existing usage...
>> Also please address the usage and privacy issue....
>
>What privacy issue?  There is nothing that implies a serialNumber attribute
>must be a National ID (or a Global ID); more likely it will be unique
>per issuer.  Your customer number from Land's End Direct Merchants is
>different from your driver's license number, your bank account
>number(s), and your brokerage account number(s), and your employer's
>retirement account number.
>
>Your proposed new attribute would be no different from serialNumber from
>a privacy perspective - privacy is affected by the scope of uniqueness
>(the number of databases which know you by a particular identifier),
>not by the choice of attribute OID.
>
>
>> > It would help to get your immediate support for this. Can you live with
>> it??
>> 
>> cm> No...
>
>So far the consensus for serialNumber seems smooth, with only one nay.

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

Date: Tue, 30 Nov 1999 18:46:00 -0500 (EST)
From: "David P. Kemp" <[email-masked]>
Reply-To: "David P. Kemp" <[email-masked]>
Subject: Re: dnQualifier topic - not solved yet.
To: [email-masked]
Content-MD5: B3GtiSM9PZk0CksDnq/KWA==

> From: "Charles Moore" <[email-masked]>
> 
> 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.

What incompatibility or problem with existing usage would be caused by
adding "person" to the class of objects to which serialNumber applies?

> The proposal was previously presented as:
> > I suggest that we:
> >
> > - Add serialNumber to son of rfc2459 supportedAttributes as a MUST
> > implement attribute (i.e. compliant applications MUST be able to
> understand
> > it).
> cm> See above this is not possible given existing usage...
> Also please address the usage and privacy issue....

What privacy issue?  There is nothing that implies a serialNumber attribute
must be a National ID (or a Global ID); more likely it will be unique
per issuer.  Your customer number from Land's End Direct Merchants is
different from your driver's license number, your bank account
number(s), and your brokerage account number(s), and your employer's
retirement account number.

Your proposed new attribute would be no different from serialNumber from
a privacy perspective - privacy is affected by the scope of uniqueness
(the number of databases which know you by a particular identifier),
not by the choice of attribute OID.

> > It would help to get your immediate support for this. Can you live with
> it??
> 
> cm> No...

So far the consensus for serialNumber seems smooth, with only one nay.

From: Alex Deacon <[email-masked]>
To: "'Bill Price'" <[email-masked]>, [email-masked], [email-masked]
Cc: [email-masked]
Subject: RE: Unknown private verisign extension
Date: Tue, 30 Nov 1999 15:37:26 -0800

Hello,

Until I get some time to make the VeriSign OID repository ready for public
consumption and place them on our web site, here is a (very) high level view
of what we have done.

--
-- Root of the VeriSign ARC
--  (2.16.840.1.113733)
--
id-verisign OBJECT IDENTIFIER ::= {2 16 US(840) 1 verisign(113733)} 

-- 
-- VeriSign PKI Sub Tree
--  (2.16.840.1.113733.1)
-- 
id-pki OBJECT IDENTIFIER ::= {id-verisign pki(1)} 

--
-- VeriSign defined certificate extension sub tree
--   (2.16.840.1.113733.1.6)
--
id-extensions OBJECT IDENTIFIER ::= {id-pki extensions(6)} 

--
-- VeriSign defined certificate policy identifier sub tree
--  (2.16.840.1.113733.1.7)
--   
id-policies OBJECT IDENTIFIER ::= {id-pki policies(7)}

--
-- VeriSign defined attribute sub tree
--  (2.16.840.1.113733.1.9)
--   
id-attributes	OBJECT IDENTIFIER ::= {id-pki attributes(9)} 

As was mentioned in previous messages

{id-extensions 3} is the CZAG extension (country, zip, age and gender).  I
need to find out if I can disclose the details on this one.  If I can it
will be in the doc.

{id-extensions 6} is a private extension we defined for use in certs issued
to Netscape InBox customers.  I beleive its a simple IA5String.

> 2 16 840 1 113733 1 7 1 1 1 and 2 16 840 1 113733 1 7 1 1 2 mean,
> for some

As for the above policy oids, there seems to be to many 1's in them....

{id-policies 1 1} is the policyIdentifier OID for version 1 of the VeriSign
CPS

You may see other policy OIDS which define policyIdentifiers for our various
affiliates.  Again, these will be listed in the public OID doc.

Hope this helps.

Alex

-----Original Message-----
From: Bill Price [mailto:[email-masked]]
Sent: Tuesday, November 23, 1999 2:27 PM
To: [email-masked]; [email-masked]
Cc: [email-masked]
Subject: RE: Unknown private verisign extension

After a series of exchanges with Verisign, I was told that the ... ".1.6.3
OID extension contains country, zip, date of birth, and gender. This data is
masked to prevent misuse or abuse by third parties." (You can voluntarily
provide the information when requesting a cert.)  I was told that I'd have
to contact my sales rep and enter some sort of non-disclosure agreement to
learn how to unmask the data. The designated sales rep has not responded.

Has anyone cracked the masking?

Bill Price

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]
> Sent: Wednesday, November 24, 1999 4:20 AM
> To: [email-masked]
> Cc: [email-masked]
> Subject: Re: Unknown private verisign extension
>
>
> [cc'd to PKIX for comment]
>
> [email-masked] writes:
>
> >Included below is a exchange of E-Mails with verisign support. I recently
> >obtained a versign cert and found an undocumented private
> verisign extension
> >in it. It is obvious that I want to know what information is
> stored in that
> >extension. Verisign fails to give an sufficient answer.
>
> I've been trying to find out what 2.16.840.1.113733.1.6.3 and
> 2.16.840.1.113733.1.6.6 are, as well as what the policy qualifiers
> 2 16 840 1 113733 1 7 1 1 1 and 2 16 840 1 113733 1 7 1 1 2 mean,
> for some
> time now, but noone at Verisign will tell you.
>
> This leads to an interesting question: What are the semantics for
> these things?
> As far as anyone knows, the .1 policy could be "By using this
> certificate you
> agree to take full responsibility for any misuse of this certificate,
> regardless of what the CPS says" (which would be perfectly valid,
> since it's a
> policy qualifier), .2 might be "In the event of any dispute,
> Verisign is always
> right", .3 contains a copy of your private key encrypted with
> _NSAKEY :-), and
> who knows what .6 is.  Since the point of a CPS is that both the
> end entity and
> relying party can read it and know what they're getting, wouldn't
> the use of
> unpublished qualifiers and extensions which can modify the CPS destroy any
> possibility of reliance on the certs which contain them?
>
> Peter.
>

From: "Charles Moore" <[email-masked]>
To: <[email-masked]>, "Stefan Santesson" <[email-masked]>
Subject: Re: dnQualifier topic - not solved yet.
Date: Wed, 1 Dec 1999 05:45:23 +1000

----- Original Message -----
From: Stefan Santesson <[email-masked]>
To: <[email-masked]>
Sent: Tuesday, November 30, 1999 10:41 PM
Subject: Re: dnQualifier topic - not solved yet.

Magnus and I have had discussions on this topic.

Going through what have been said lately, together with some of-list
comments, convince us that we actually have a rough consensus that
everybody can live with.

And that is to use the serialNumber attribute.

The good thing about selecting serialNumber is that it is widely
implemented anyway, it works and it has a short OID.

But our choice of this attribute should also be a clear signal to the X.500
folks that we want to have X.520 and X.521 updated and fixed so this
attribute is clearly related, not only to devices, but to any type of
object.

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

The proposal was previously presented as:
> I suggest that we:
>
> - Add serialNumber to son of rfc2459 supportedAttributes as a MUST
> implement attribute (i.e. compliant applications MUST be able to
understand
> it).
cm> See above this is not possible given existing usage...
Also please address the usage and privacy issue....
>
> - Keep dnQualifier in son of rfc2459, with a note stating it's intended
> purpose, the fact that new certificates should not break this intended
> usage, and also saying that clients should expect that some existing
> certificates may use this attribute to hold any type of value.
>
> - specify use of serialNumber but NOT dnQualifier in the Qualified
> Certificates profile.
cm> See above...

>
> It would help to get your immediate support for this. Can you live with
it??

cm> No...
> /Stefan

With respect to inclusion in rfc2459, David Kemp wrote:
>Yes.  If dnQualifier remains in son of rfc2459 a requirement level will
>have to be specified.  I believe dnQualifier should be omitted entirely
>from the PKIX profile or be included at the MAY level with the usage note.
>But if there is a constituency for keeping it at the SHOULD or
>MUST level (in addition to serialNumber), I could live with that.

cm> No...

I can live with both ways, so lets leave that up to the rfc2459 editors to
resolve.

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

Date: Tue, 30 Nov 1999 11:03:52 -0800
From: Ed Gerck <[email-masked]>
To: Peter Williams <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: non-repudiation, was Re: proposed key usage text

Peter:

Thanks for the useful links, including patents.  The topic
extension seems to be off-charter for PKIX -- though one may
expect that other standards and references may realign
themselves with PKIX, but this is on their turf.  What could
be done here was IMO done to a large extent -- to clear the
PKIX discourse and to make NR useful and distinguished
from authentication, while reducing its potentially misleading
aspects.  Especially useful was to clarify that NR has nothing
to do with "willful intent", it has to do with evidences.  So,  this
WG has now a rather objective  agreement (if one also includes
the archives, for context) on NR and work can go on until this
agreement is again challenged by facts.  Until then, I am happy
to pursue this discussion in private or in other technical fora
such as the MCG -- in particular on modeling NR as a "modus
tolens" logical affirmation in modal logic.

Cheers,

Ed Gerck

From: "Linn, John" <[email-masked]>
To: "'Tim Polk'" <[email-masked]>, "Linn, John" <[email-masked]>, "'Russ Housley'" <[email-masked]>, [email-masked]
Subject: RE: proposed key usaged text -- the final round
Date: Tue, 30 Nov 1999 11:42:39 -0500

Tim,
 
Yes; that works for me.  Thanks.
 
--jl

-----Original Message-----
From: Tim Polk [mailto:[email-masked]]
Sent: Tuesday, November 30, 1999 9:37 AM
To: Linn, John; 'Russ Housley'; [email-masked]
Subject: RE: proposed key usaged text -- the final round

John, 

Is see the confusion. The answer is (b), the nonRepudiation bit is
irrelevant when validating the signature on a certificate or certifcate
status information (e.g., CRL or OCSP message). 

Perhaps it would be clearer to simply say: 

This service protects against the certificate subject falsely denying
signing the data. 

and add the following sentences to the next paragraph: 

The values of the digitalSignature and nonRepudiation bits are not
considered when validating the signature on certificates or certificate
status information. (See keyCertSign and cRLSigning, below, for values that
are considered when validating such signatures.) 

Would this clear things up? 

>Editorially, under the paragraphs for keyAgreement and keyEncipherment, 

>"shall asserted" -> "shall be asserted". 

Gee, my quality control must be slipping! Thanks for catching this one. 

Thanks, 

Tim Polk 

At 04:49 PM 11/29/1999 -0500, Linn, John wrote: 

>The content looks good. I've just one question and one editorial point. In 

>the sentence re the NR bit, "This service protects against the certificate 

>subject falsely denying signing the data, excluding certificate or CRL 

>signing", I'm not sure how to interpret the scope and intent of the 

>"excluding" clause. If a CA certificate has NR set, is the intent to say: 

>(a) that the certified CA is free to deny issuance of any certificate or
CRL 

>it signs, (b) to state that the value of the NR bit is definitionally 

>irrelevant to the repudiability of issued certificates or CRLs as the scope

>of the NR service is confined to usage on data other than certificates and 

>CRLs, or (c) to state that the question of semantics (if any) of NR for 

>certificate and CRL issuance is undefined in this specification,
potentially 

>to be considered in policy documents? I'll assume not (a), but it might be 

>useful to clarify towards (b) or (c). 

>Editorially, under the paragraphs for keyAgreement and keyEncipherment, 

>"shall asserted" -> "shall be asserted". 

>--jl 

Date: Tue, 30 Nov 1999 09:36:33 -0500
To: "Linn, John" <[email-masked]>, "'Russ Housley'" <[email-masked]>, [email-masked]
From: Tim Polk <[email-masked]>
Subject: RE: proposed key usaged text -- the final round

John,

Is see the confusion.  The answer is (b), the nonRepudiation bit is
irrelevant when validating the signature on a certificate or certifcate
status information (e.g., CRL or OCSP message).

Perhaps it would be clearer to simply say:

<paraindent><param>left</param>This service protects against the
certificate subject falsely denying signing the data.

</paraindent>

and add the following sentences to the next paragraph:

<paraindent><param>left</param>The values of the digitalSignature and
nonRepudiation bits are not considered when validating the signature on
certificates or certificate status information.  (See keyCertSign and
cRLSigning, below, for values that are considered when validating such
signatures.)

</paraindent>

Would this clear things up?

>Editorially, under the paragraphs for keyAgreement and 
keyEncipherment,

>"shall asserted" -> "shall be asserted". 

Gee, my quality control must be slipping!  Thanks for catching this 
one.

Thanks,

Tim Polk

At 04:49 PM 11/29/1999 -0500, Linn, John wrote:

>The content looks good.  I've just one question and one editorial point.
 In

>the sentence re the NR bit, "This service protects against the
certificate

>subject falsely denying signing the data, excluding certificate or CRL

>signing", I'm not sure how to interpret the scope and intent of the

>"excluding" clause.  If a CA certificate has NR set, is the intent to
say:

>(a) that the certified CA is free to deny issuance of any certificate or
CRL

>it signs, (b) to state that the value of the NR bit is definitionally

>irrelevant to the repudiability of issued certificates or CRLs as the
scope

>of the NR service is confined to usage on data other than certificates
and

>CRLs, or (c) to state that the question of semantics (if any) of NR 
for

>certificate and CRL issuance is undefined in this specification,
potentially

>to be considered in policy documents?  I'll assume not (a), but it might
be

>useful to clarify towards (b) or (c). 

>Editorially, under the paragraphs for keyAgreement and 
keyEncipherment,

>"shall asserted" -> "shall be asserted". 

>--jl

Sender: [email-masked]
To: Stefan Santesson <[email-masked]>
Cc: [email-masked]
Subject: Re: dnQualifier topic - not solved yet.
Organization: CyberTrust
From: John Saylor <[email-masked]>
Date: 30 Nov 1999 09:05:05 -0500
Lines: 31

Hi

>>>>> "SS" == Stefan Santesson <[email-masked]> writes:

 SS> And that is to use the serialNumber attribute.

 SS> The good thing about selecting serialNumber is that it is widely
 SS> implemented anyway, it works and it has a short OID.

Yes, but the bad part is that the name "serialNumber" carries baggage
that is misleading if it were to be used as a unique identifier of
some sort.

Also, some of the same arguments in favor of serialNumber could be
applied to dnQualifier [widely implemented, works, short OID]. But
here the problem is that the intended useage is not followed [which
is also be the case (to a lesser degree) with serialNumber].

Conceptually, it seems the "right" thing to do is to add on OID for
uniqueIdentifier; however there is no shortage of operational problems 
that crop up with this course.

 SS> So if nobody strongly object to this I will go ahead and include
 SS> this in the QC profile and I assume that rfc 2459 will be updated
 SS> accordingly

I can't come up with a better plan.

-- 
\js

Date: Tue, 30 Nov 1999 13:41:36 +0100
To: [email-masked]
From: Stefan Santesson <[email-masked]>
Subject: Re: dnQualifier topic - not solved yet.

Magnus and I have had discussions on this topic.

Going through what have been said lately, together with some of-list
comments, convince us that we actually have a rough consensus that
everybody can live with.

And that is to use the serialNumber attribute.

The good thing about selecting serialNumber is that it is widely
implemented anyway, it works and it has a short OID.

But our choice of this attribute should also be a clear signal to the X.500
folks that we want to have X.520 and X.521 updated and fixed so this
attribute is clearly related, not only to devices, but to any type of object.

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

The proposal was previously presented as:
> I suggest that we:
> 
> - Add serialNumber to son of rfc2459 supportedAttributes as a MUST
> implement attribute (i.e. compliant applications MUST be able to understand
> it).
> 
> - Keep dnQualifier in son of rfc2459, with a note stating it's intended
> purpose, the fact that new certificates should not break this intended
> usage, and also saying that clients should expect that some existing
> certificates may use this attribute to hold any type of value.
> 
> - specify use of serialNumber but NOT dnQualifier in the Qualified
> Certificates profile.
> 
> It would help to get your immediate support for this. Can you live with it??
> 
> /Stefan

With respect to inclusion in rfc2459, David Kemp wrote:
>Yes.  If dnQualifier remains in son of rfc2459 a requirement level will
>have to be specified.  I believe dnQualifier should be omitted entirely
>from the PKIX profile or be included at the MAY level with the usage note.
>But if there is a constituency for keeping it at the SHOULD or 
>MUST level (in addition to serialNumber), I could live with that.

I can live with both ways, so lets leave that up to the rfc2459 editors to
resolve.

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

From: Peter Williams <[email-masked]>
To: Ed Gerck <[email-masked]>, "David P. Kemp" <[email-masked]>
Cc: [email-masked]
Subject: RE: non-repudiation, was Re: proposed key usage text
Date: Tue, 30 Nov 1999 03:51:06 -0800

> -----Original Message-----
> From: Ed Gerck [mailto:[email-masked]]
> Sent: Thursday, November 18, 1999 2:12 PM
> To: David P. Kemp
> Cc: [email-masked]
> Subject: Re: non-repudiation, was Re: proposed key usage text
> 

Now that you are getting close to consensus, here is some
additional material to be potentially harmonized, or
considered (patents, particularly):

1. http://thesource.dwpub.com/frames/1997/09/18.html

2. Authentication & Non-Repudiation - Verifying the received document is
really from the advertised sender. Additionally, the non-repudiation process
involves processing and sending a message back to the sender so there can be
no repudiating the validity and authenticity of the sent and received
document.

(se.commerce.net)

3.
http://www.techweb.com/encyclopedia/defineterm?term=NON-REPUDIATION&exact=1

Unable to deny the validity of a document. 

http://www.rnbo.com/PROD/rmadillo/b/b4doc1.htm#data

NSA's (old) view...

http://members.tripod.com/jayp_7/professional/Samples/EDI/EDI-4.htm

BT's 1992 View of bisynch's NR "undeniable confirmation that your trading 
partner received your EDI transaction?"

http://csrc.ncsl.nist.gov/nistpubs/800-7/node239.html#SECTION083660000000000
00000

NIST admits that X.400 allows NR via non digital signature means...

http://www.itu.int/itudoc/itu-t/rec/f/f435.html extra NR services added 
to X.400, in 1991

http://www.disa.mil/DISN/disns562.html

Encryption-based NR: 

Making additional security protection available to DISN users commensurate
with policy-required provisions for authentication, non-repudiation of
traffic origination or delivery and protection of classified information.
This will be provided through the use of link encryption and end-to-end
encryption units, such as secure telephone units and secure video
teleconferencing systems. 

http://www.arraydev.com/commerce/JIBC/9811-08.htm

Eric Blot-Lefevre's dematerialization view of NR

4. patents...

LMITCO Invention Disclosure, Digital Signature System with Non-Repudiation
for Relational Databases, B. J. Groeneveld, W. E. Austad, S. C. Walsh, C. A.
Herring, filed 27-July-1998. 
http://id.inel.gov/4150/ppp/austad_wayne.html

Use of control vectors (like key usage extension...) to enable MOA NR:

http://www.patents.ibm.com/details?pn=US04918728__ (properly references
Davies.)

5 Fishing

http://www.fishnet.co.nz/gen/Dec3_97.html claims international standards for
NR already exist such that the NZ fishing industry does not need to
invent anything new.

> 
> 
> "David P. Kemp" wrote:
> 
> > > Date: Thu, 18 Nov 1999 12:02:54 -0800
> > > From: Ed Gerck <[email-masked]>
> > >
> > > Stefan Santesson wrote:
> > >
> > > > How can you say that the X.509 definition is wrong???
> > >
> > > Because it is redundant (the same as authentication as I 
> commented)
> > > and thus superfluous.
> >
> > Some people believe that there is a difference between "provable
> > data origin authentication with integrity" and "entity 
> authentication",
> > and that nonRepudiation as used in X.509 is an appropriate 
> name for the
> > former.
> 
> David:
> 
> It is useful to list what X.509 actually says before further 
> discussing about
> "nonRepudiation as used in X.509".  These are all the 
> occurrences that I
> find when I look for the key text "repudiation" in X.509:
> 
>  "It is a matter for the security policy and responsibility 
> of the CA to keep old
>  certificates for a period of time if a non repudiation of 
> data service is provided."
> 
>  "If a non-repudiation of data service is dependent on keys 
> provided by the CA,
>  the service should ensure that all relevant keys of the CA 
> (revoked or expired)
>  and the timestamped revocation lists are archived and 
> certified by a current
>  authority."
> 
>  "nonRepudiation:  for verifying digital signatures used in 
> providing a
>  nonrepudiation service which protects against the signing 
> entity falsely
>  denying some action (excluding certificate or CRL signing, 
> as in f) or g)
>  below);"
> 
>  "The date in this extension is not, by itself, sufficient 
> for nonrepudiation
>  purposes. For example, this date may be a date advised by 
> the private key
>  holder, and it is possible for such a person to fraudulently 
> claim that a key
>  was compromised some time in the past, in order to repudiate a
>  validly-generated signature."
> 
>  "Repudiation -- The denial by a user of having participated 
> in part or all
>  of a communication."
> 
> and, the one quoted by Stefan:
> 
>  "Non-repudiation -- This service provides proof of the 
> integrity and origin
>  of data -- both in an unforgeable relationship -- which can 
> be verifed by any
>  third party at any time."
> 
> plus:
> 
>  "The data integrity mechanism supports the data integrity 
> service. It also
>  partially supports the non-repudiation service (that service 
> also needs the
>  digital signature mechanism for its requirements to be fully met)."
> 
>  "The digital signature mechanism supports the data integrity 
> service and
>  also supports the non-repudiation service."
> 
> which shows that X.509 itself  is in contradiction.  To 
> X.509, nonrepudiation
> does NOT provide proof of integrity, which needs the digital signature
> mechanism.  This is made clear in  Table B.1 "Threats and 
> protection", where
> we can read that the non-repudiation service is depicted as 
> protecting against
> the threats  of replay and repudiation -- and that "data 
> integrity" and "end
> authentication" are different services, different from 
> non-repudiation.
> 
> Thus, that is why I wrote the following in regard to the 
> definition that Stefan
> quoted from X.509:
> 
>  This definition is wrong, as well as the consequences 
> derived from it. Compare
>  with the technical definition of Menezes in  Handbook of Applied
>  Cryptography (cf.):
> 
>  Non-repudiation: a service that prevents the denial of a 
> previous act.
> 
> But, surprise! The above NR definition by Menezes can be also found in
> *another* part of X.509, if you read the X.509 definition for 
> *repudiation*
> that I quoted above:
> 
>  "Repudiation -- The denial by a user of having participated 
> in part or all
>   of a communication."
> 
> and you construct the logical complement of "non" as:
> 
> Non-Repudiation -- Preventing the denial by a user of having 
> participated in
> part or all of a communication.
> 
> Further, authentication that is neither provable nor provides 
> for integrity is
> not authentication in the sense of strong authentication as used in
> X.509 digital signatures (Section 10.1).   Thus, when you say 
> that "provable
> data origin authentication with integrity" is an appropriate name for
> non-repudiation in X.509, I must disagree and cite X.509 
> itself.  That X.509
> definition quoted by Stefan in incoherent with all other 
> definitions of X.509.
> It was a bad pick.
> 
> Actually, elsewhere as shown above, X.509 textually *agrees* with the
> definition by Menezes et. al. and with the usual sense people 
> would attach
> to something that is the complement of repudiation, the 
> complement of denial.
> 
> On the other hand, "provable data origin authentication with 
> integrity" is
> NOT an attribute of non-repudiation in X.509 but is provided by strong
> authentication as given in Section "10.1 Overview", where two-way
> authentication provides assurances for "the integrity and
> originality  of the authentication token sent in the reply".
> 
> So, should we accept that NR definition quoted by Stefan and deny
> all the other passages of X.509, including those for 
> authentication, that
> contradict with it ... or should we mark that specific 
> passage as wrong
> and accept the rest of X.509?
> 
> Cheers,
> 
> Ed Gerck
> 

From: Peter Williams <[email-masked]>
To: Ed Gerck <[email-masked]>
Cc: [email-masked]
Subject: RE: proposed key usaged text -- the final round
Date: Tue, 30 Nov 1999 02:32:05 -0800

> -----Original Message-----
> From: Ed Gerck [mailto:[email-masked]]
> Sent: Thursday, November 25, 1999 10:01 AM
> Cc: Russ Housley; [email-masked]; [email-masked]
> Subject: Re: proposed key usaged text -- the final round
> 
> 
> 
> 
> Denis Pinkas wrote:
> 
> > I am not going to die with the proposed text :-) ...
> 
> But, perhaps we could all live with it ;-) and move on ....
> 
> > However, there are two sentences that are rather obscure or
> > not helpul and I would like to take advantage of some earlier
> > E-mail exchanges to canibalize these exchanges in order to
> > improve the text. The two last sentences of the section
> > explaining the NR bit could be deleted without loosing
> > much:
> >
> >   [The nonRepudiation bit is asserted when the subject
> >   public key is used to verify digital signatures used to
> >   provide a non-repudiation  service].  This service protects
> >   against the certificate subject falsely denying signing the
> >   data, excluding certificate or CRL signing. In the case of
> >    later conflict, a reliable third party may determine the
> >    authenticity of the signed data.
> 

What happens when two pieces of definitive NR evidence do
not agree?

http://www.imc.org/ietf-ediint/archive1/0003.html suggests that
digital signatures are not the only mechanism to achieve
NR (of receipt).

> I disagree -- the first sentence explains what the NR bit is used
> for (to verify digital signatures) in a specific context ( to provide
> a non-repudiation service), in contrast to explaining what the service
> is and why it would be useful to use it (protects against the
> certificate subejct falsely denying signing).
> 
> If you believe that it could be deleted without loosing much, and
> in fact something *is* lost, then it is IMO better to keep it 
> and be clear
> in a subject which has been unclear for far too long.  I 
> would rather we
> would not need to beat this horse dead an umpth-time.
> 
> > I propose to keep the first sentence unchanged and have the 
> following
> > global replacement for the three sentences:
> >
> > " The nonRepudiation bit is asserted when the subject public key is
> > used to verify digital signatures used to provide a non-repudiation
> > service. When present, the nonRepudiation bit indicates that the
> > private key corresponding to the subject public key present in that
> > certificate may be used to indicate the user's conscious and willing
> > intent to endorse what is being signed."
> 
> I disagree -- is there anything more "rather obscure or not helpul"
> than "the user's conscious and willing intent"?  So, the change IMO
> is in contradiction with the purpose. Further, "to endorse" may have
> different legal meanings in different jurisdictions ("endorsement
> sans recourse" in the UK is one of the few that does not have legal
> consequences, but it needs to have the "sans recourse" appended
> to it and it is not valid in civil law regimes where almost 
> anything that
> you do flows back to the original agent -- you).
> 
> Finally, I would lint anything that predicates measuring, assessing,
> controlling or even estimating "the user's conscious and willing
> intent" in PKIX because if there is anything that no law, policy or
> dictatorship has ever managed to do is to control people's "conscious
> and willing intent" -- so, this is a slippery slope which was already
> debated, spotted and marked as leading nowhere in an Internet
> protocol; and debating this on and on and on and on will not change
> it or make it valid by repetition.
> 
> Gosh, if we can't even say *who* the sender is, *what* path did that
> message take, *if* the full communication of the sender with 
> all its follow
> up certified partial messages arrived or if there was a 
> partial or total denial
> en route which was blocked by an attacker, then how can we say what
> that unknown person in an unknown place with an unknown communication
> *intented* to say???
> 
> 
> > I would also propose to add a note that explains the case of a
> > certificate having both the DS and the NR bits set and to place this
> > addition at the end of the whole section 4.2.1.3:
> >
> > " Note: A certificate with the nonRepudiation bit set should only be
> > used when it is possible to get full confidence of the environments
> > where the private key will be used. If a certificate has both the
> > digitalSignature and the nonRepudiation bit set, the entity owning
> > the private key should have full confidence of all the various
> > environments and applications where the private key will being used.
> > For the cases where that condidence cannot be obtained, two
> > different certificates, one with one public public key and the
> > digitalSignature bit set and another one with a different public key
> > and the nonRepudiation bit set, should be used."
> 
> I do not want to sound in opposition to your entire email, but I also
> disagree. This is an "explanation mode" definition which is repetitive
> ("possible to get full confidence of the environments where 
> the private
> key will be used" and "should have full confidence of all the various
> environments and applications where the private key will being used");
> predicates an impossible condition (full confidence) in an overbroad
> context (all  the various environments where the private key will be
> used); indeterminate ("For the cases where that condidence cannot
> be obtained"); ineffective ("two different certificates ..."); and
> contradictory (why would two wrong certificates make a right one?)
> 
> Cheers,
> 
> Ed Gerck
> 
> 

From: Charles Moore <[email-masked]>
To: "'Anders Rundgren'" <[email-masked]>, Charles Moore <[email-masked]>, [email-masked], Stefan Santesson <[email-masked]>
Subject: RE: dnQualifier topic - not solved yet.
Date: Tue, 30 Nov 1999 08:47:33 +1000

-----Original Message-----
From: Anders Rundgren [mailto:[email-masked]]
Sent: Tuesday, 30 November 1999 8:59
To: Charles Moore; [email-masked]; Stefan Santesson
Subject: Re: dnQualifier topic - not solved yet.

Charles,

>a) Document the use of options 1 and 2 as they have already been
implemented
>and are in use...
>b) Define a new attribute within the RFC something like 'distiguising
>qualifier' with a discription something like "The Distinguishing Qualifier
>attribute type specifies disambiguating information used to uniquely
>identify a subject".

dnQualifier supports disambiguity right now AFAIK but has been used as a
unique
identifier as well.  That makes its use ambigious and semantics unclear.

cm> The standard is ambiguous enough to legitimately use it for the
purpose... So we must deal with this reality...

>
>A value of the 'distiguising qualifier'  attribute identifies and conveys
>qualifier information for the subject,and is only used if disambiguation is
>required ( needed to meet privacy concerns, i.e to prevent national ID type
>usage).

The quest is for a suitable unique identifier to be used in not only by
national ID-schemes
but within companies.

cm> Agreed, but I want its use to be optional, i.e. not mandated in all
certs, as this causes real privacy issues within my country.... The (...)
stuff is for info, not normative...

serialNumber has a lousy name but since serial numbers normally are unique a
changed text should not change any actual usage.  I.e. my wote is on
serialNumber
and updated semantics.

cm> I believe that semantics are important, and the overloading is a
problem... I dont believe that this attribute has different semantics that
has already been used by many systems, overloading will cause problems...

I agree there is no perfect solution, my proposal was to document what we
have, a nd provide a migration solution we  can all live with...

Anders

From: "Anders Rundgren" <[email-masked]>
To: "Charles Moore" <[email-masked]>, <[email-masked]>, "Stefan Santesson" <[email-masked]>
Subject: Re: dnQualifier topic - not solved yet.
Date: Mon, 29 Nov 1999 22:59:03 -0000

Charles,

>a) Document the use of options 1 and 2 as they have already been implemented
>and are in use...
>b) Define a new attribute within the RFC something like 'distiguising
>qualifier' with a discription something like "The Distinguishing Qualifier
>attribute type specifies disambiguating information used to uniquely
>identify a subject".

dnQualifier supports disambiguity right now AFAIK but has been used as a unique
identifier as well.  That makes its use ambigious and semantics unclear.

>
>A value of the 'distiguising qualifier'  attribute identifies and conveys
>qualifier information for the subject,and is only used if disambiguation is
>required ( needed to meet privacy concerns, i.e to prevent national ID type
>usage).

The quest is for a suitable unique identifier to be used in not only by national ID-schemes
but within companies.

serialNumber has a lousy name but since serial numbers normally are unique a
changed text should not change any actual usage.  I.e. my wote is on serialNumber
and updated semantics.

Anders

From: "Linn, John" <[email-masked]>
To: "'Russ Housley'" <[email-masked]>, [email-masked]
Cc: [email-masked]
Subject: RE: proposed key usaged text -- the final round
Date: Mon, 29 Nov 1999 16:49:23 -0500

The content looks good.  I've just one question and one editorial point.  In
the sentence re the NR bit, "This service protects against the certificate
subject falsely denying signing the data, excluding certificate or CRL
signing", I'm not sure how to interpret the scope and intent of the
"excluding" clause.  If a CA certificate has NR set, is the intent to say:
(a) that the certified CA is free to deny issuance of any certificate or CRL
it signs, (b) to state that the value of the NR bit is definitionally
irrelevant to the repudiability of issued certificates or CRLs as the scope
of the NR service is confined to usage on data other than certificates and
CRLs, or (c) to state that the question of semantics (if any) of NR for
certificate and CRL issuance is undefined in this specification, potentially
to be considered in policy documents?  I'll assume not (a), but it might be
useful to clarify towards (b) or (c). 

Editorially, under the paragraphs for keyAgreement and keyEncipherment,
"shall asserted" -> "shall be asserted". 

--jl

From: "Charles Moore" <[email-masked]>
To: <[email-masked]>, "Stefan Santesson" <[email-masked]>
Subject: Re: dnQualifier topic - not solved yet.
Date: Tue, 30 Nov 1999 07:21:39 +1000

My suggestion is to take the same approach as the UTC/Generalised time and
several others todate..

a) Document the use of options 1 and 2 as they have already been implemented
and are in use...
b) Define a new attribute within the RFC something like 'distiguising
qualifier' with a discription something like "The Distinguishing Qualifier
attribute type specifies disambiguating information used to uniquely
identify a subject".

A value of the 'distiguising qualifier'  attribute identifies and conveys
qualifier information for the subject,and is only used if disambiguation is
required ( needed to meet privacy concerns, i.e to prevent national ID type
usage).

An attribute value for Distinguishing Qualifier is a string
distinguishingQualifier ATTRIBUTE ::= {
 SUBTYPE OF  name
 WITH SYNTAX  DirectoryString {ub-name}
 ID  id-at-distinguishingQualifier }

Text should state that the use of options 1&2 should be deprecated after say
2002....

My two cents worth...

Charles...

----- Original Message -----
From: Stefan Santesson <[email-masked]>
To: <[email-masked]>
Sent: Tuesday, November 30, 1999 6:24 AM
Subject: dnQualifier topic - not solved yet.

All,

My last trial to settle the dnQualifier topic drowned in the NR-bit
struggle.

So I take the chance, during this apparent rest in the traffic, to bring
this up again for settlement.

What we need:
-------------
We need an attribute that we can use to store an identifier of a
certificate subject. This may be a unique identifier (sufficient to
identify the subject) or may act as a name distinguisher (sufficient to
identify the subject if combined with other names of the subject)

What do we have:
----------------
We have five candidate solutions, all with troubles. they are -

1) X.520 dnQualifier - the only attribute from rfc2459 with an intention
close to what we need. The problem is that using this attribute will break
the INTENT of this attribute according to X.520. This is also a solution
implemented by some vendors today.

2) X.520 serialNumber - Having the problem that it is defined for a device.
It is also only used with the object class device in X.501. It has however
been considered by X.500 standardization to change this to include support
for use with any type of "object". This is however not done yet and not
formally approved. It should also be noted that this is the current
solution of Finland, Sweden, Germany and probably more national electronic
ID-projects.

3) X.520 uniqueIdentifier - Having the problem that it is defined as a bit
string. This makes it impossible to display in any standardized way except
as a hex dump. Not a very useful format.

4) RFC 1274 uniqueIdentifier - Having the problem that is has an illegal
OID, together with all attributes defined under the PilotAttributeType
branch. This is in fact the same problem with the attribute domainComponent
also used in RFC2459 and the QC-profile, so using this attribute does not
introduce a new problem, but it makes the existing problem worse and more
critical.

5) To define a completely new attribute - Having the problem that we may
have a longer road to travel before this gets recognized and implemented in
proucts.

We need a solution that can be used consistently in the subject field in
son of RFC 2459 as well as in the QC profile.

So Please fellows.

This must be an important problem to solve for many of you out there,
affecting your products and implementations. So be active and propose
actions. Don't wait for others to solve this for you. Make your voice heard.

I hope we can solve this within a couple of weeks and perhaps make a straw
poll if consensus is hard to reach.

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

Date: Mon, 29 Nov 1999 21:24:30 +0100
To: [email-masked]
From: Stefan Santesson <[email-masked]>
Subject: dnQualifier topic - not solved yet.

All,

My last trial to settle the dnQualifier topic drowned in the NR-bit struggle.

So I take the chance, during this apparent rest in the traffic, to bring
this up again for settlement.

What we need:
-------------
We need an attribute that we can use to store an identifier of a
certificate subject. This may be a unique identifier (sufficient to
identify the subject) or may act as a name distinguisher (sufficient to
identify the subject if combined with other names of the subject)

What do we have:
----------------
We have five candidate solutions, all with troubles. they are -

1) X.520 dnQualifier - the only attribute from rfc2459 with an intention
close to what we need. The problem is that using this attribute will break
the INTENT of this attribute according to X.520. This is also a solution
implemented by some vendors today.

2) X.520 serialNumber - Having the problem that it is defined for a device.
It is also only used with the object class device in X.501. It has however
been considered by X.500 standardization to change this to include support
for use with any type of "object". This is however not done yet and not
formally approved. It should also be noted that this is the current
solution of Finland, Sweden, Germany and probably more national electronic
ID-projects.

3) X.520 uniqueIdentifier - Having the problem that it is defined as a bit
string. This makes it impossible to display in any standardized way except
as a hex dump. Not a very useful format.

4) RFC 1274 uniqueIdentifier - Having the problem that is has an illegal
OID, together with all attributes defined under the PilotAttributeType
branch. This is in fact the same problem with the attribute domainComponent
also used in RFC2459 and the QC-profile, so using this attribute does not
introduce a new problem, but it makes the existing problem worse and more
critical.

5) To define a completely new attribute - Having the problem that we may
have a longer road to travel before this gets recognized and implemented in
proucts.

We need a solution that can be used consistently in the subject field in
son of RFC 2459 as well as in the QC profile.

So Please fellows.

This must be an important problem to solve for many of you out there,
affecting your products and implementations. So be active and propose
actions. Don't wait for others to solve this for you. Make your voice heard.

I hope we can solve this within a couple of weeks and perhaps make a straw
poll if consensus is hard to reach.

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

From: "Anders Rundgren" <[email-masked]>
To: "Denis Pinkas" <[email-masked]>, "Russ Housley" <[email-masked]>, "Tim Polk" <[email-masked]>, <[email-masked]>
Subject: Server-signatures: Re: proposed key usaged text -- the final round
Date: Sun, 28 Nov 1999 09:08:32 -0000

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

Date: Fri, 26 Nov 1999 16:22:33 -0500
To: Denis Pinkas <[email-masked]>, Russ Housley <[email-masked]>
From: Tim Polk <[email-masked]>
Subject: Re: proposed key usaged text -- the final round
Cc: [email-masked]

Denis,

At 11:52 AM 11/25/1999 +0100, Denis Pinkas wrote:

>Tim and Russ,

>> To people who still care about NR:

>I care.

We thought you might.  :-)

I've cut and pasted a bit to asssist those reading along at home...  I
trust I haven't altered your intent.

Our proposed text:

>        The nonRepudiation bit is asserted when the subject public key
is

>        used to verify digital signatures used to provide a
non-repudiation

>        service.  This service protects against the certificate 
subject

>        falsely denying signing the data, excluding certificate or CRL

>        signing. In the case of later conflict, a reliable third party
may

>        determine the authenticity of the signed data.

Your proposed text:

>" The nonRepudiation bit is asserted when the subject public key is

>used to verify digital signatures used to provide a non-repudiation

>service. When present, the nonRepudiation bit indicates that the

>private key corresponding to the subject public key present in that

>certificate may be used to indicate the user's conscious and willing

>intent to endorse what is being signed." 

I prefer our text, since it sticks to the definition of the service.  The
certificate subject can use their private key for anything they'd like. 
The question for the key usage extension is, "Should I use this public
key to implement this service?".  I believe our text describes the
general case, yours an important specific case.

Russ and I worked very hard to remove the word "intent" in our latest
proposal.  Intent can only be indicated through context, such as the
signing policy that ETSI has proposed.  This specification cannot do a
thing to ensure that any particular signature was generated conciously
and willingly.

Since our text includes your case, and ETSI is already working on the
mechanisms to describe the signing context, I think our text is a good
middle ground.

You also wrote:

>I would also propose to add a note that explains the case of a

>certificate having both the DS and the NR bits set and to place this

>addition at the end of the whole section 4.2.1.3:

>" Note: A certificate with the nonRepudiation bit set should only be

>used when it is possible to get full confidence of the environments

>where the private key will be used. If a certificate has both the

>digitalSignature and the nonRepudiation bit set, the entity owning

>the private key should have full confidence of all the various

>environments and applications where the private key will being used.

>For the cases where that condidence cannot be obtained, two

>different certificates, one with one public public key and the

>digitalSignature bit set and another one with a different public key

>and the nonRepudiation bit set, should be used." 

I substituted "issued" for "used" in this paragraph.  I'm assuming you
are talking about how a CA determines *which* bits should be asserted. 
Is that right?  On that assumption, I think it is a policy issue or a
security consideration.  [Side note:  What do you mean by "full
confidence"?]  The next paragraph points to the policy for additional
information. 

The other possibility would be the security considerations section.  It
could build on the current text, which includes the folowing:

<bigger>

   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]

</bigger>

Adding the following paragraph might address your concern:

      A CA may include the key usage extension and assert the
nonRepudiation bit

      when issuing a certificate.  This implies that a reliable third
party will

      be able to determine the authenticity of signed data in the event
of a dispute.

      If the certificate subject uses the private key in an insecure
environment,

      it may be difficult to detect or prevent key compromise.  This
could prevent a 

      reliable third party from determining the authenticity of signed
data.  A CA

      should consider the environment of the private key before asserting
the

      nonRepudiation bit.

I know this text is very rough, but would this serve your purpose?

Thanks,

Tim

Date: Fri, 26 Nov 1999 14:27:04 -0500
To: "Aram Perez" <[email-masked]>, [email-masked]
From: Tim Polk <[email-masked]>
Subject: Re: proposed key usaged text -- the final round
Cc: [email-masked]

Hi Aram,

I At 01:35 PM 11/24/1999 -0800, Aram Perez wrote:
>Hi Tim and Russ,
>
>Thanks for taking the effort to clarify and settling the key usage debate.
>Below are a few comments...
>
[snip]
>>
>>        The dataEncipherment bit is asserted when the subject public key
>>        is used for enciphering user data, other than cryptographic keys.
>
>I'd would change "enciphering user data" to "enciphering data".
>

At the moment, I can't think of a technical reason to retain "user" in that
phrase.  However, that bit of text has been stable since at least draft 5
(July '97).  The word user doesn't add much, but is it *really* a problem?

My inclination is to leave it alone unless it is really broken.

>>
>>        The keyAgreement bit is asserted when the subject public key is
>>        used for key agreement.  For example, when a Diffie-Hellman key is
>>        to be used for key management, then this bit shall asserted.
>>
>>        The keyCertSign bit is asserted when the subject public key is
>>        used for verifying a signature on certificates.  This bit may only
>>        be asserted in CA certificates.  If the keyCertSign bit is
>>        asserted, then the cA bit in the basic constraints extension (see
>>        4.2.1.10) MUST also be asserted. If the keyCertSign bit is not
>>        asserted, then the cA bit in the basic constraints extension MUST
>>        NOT be asserted.
>>
>>        The cRLSign bit is asserted when the subject public key is used
>>        for verifying a signature on revocation information (e.g., a CRL).
>
>Neither of you responded to my previous comment on this bit. If cRLSign bit
>is asserted, must the cA bit in the basic constraints extension also be
>asserted? And vice-versa?
>

My apologies for the lack of a response.  I have been swamped since we
posted the text.

There is no direct relationship between the cA bit in basic constraints and
the cRLSign bit in key usage.  Consider a subject that issues indirect CRLs
but does not generate certificates.  In this case, the cRLSign bit would be
set, but the cA bit in basic constraints and the keyCertSign bit in key
usage would not be set.

Alternatively, CAs may not issue CRLs; they may rely on indirect CRLs or
OCSP for example.  In that case, the cA bit in basic constraints and the
keyCertSign bit in key usage would be set; the cRLSign bit would not.

Would a brief note stating that no relationship exists clarify matters?
Perhaps the following would do?

        The cRLSign bit is asserted when the subject public key is used
        for verifying a signature on revocation information (e.g., a CRL).
        [Note: Unlike the keyCertSign bit, there is no relationship
        between the value of cRLSign and the basic constraints extension.]

>>     This profile does not restrict the combinations of bits that may be
>>     set in an instantiation of the keyUsage extension.  However,
>>     appropriate values for keyUsage extensions for particular algorithms
>>     are specified in section 7.3.
>
>Again, neither of you responded to my previous comment on at least
>recommending against certain combinations.
>

See apology above.  From your email on 11/17:
>I think this is a mistake and causes confusion. In an extreme example, since
>there is no restrictions, I could have a certificate that has all the bits
>set. This means that I can do the following with my asymmetric key pair:
>
>1) sign for entity authentication and data origin authentication with
>integrity,
>2) sign with a non-repudiation service,
>3) encrypt keys for transport using RSA like algorithms,
>4) encrypt data,
>5) exchange keys using D-H like algorithms,
>6) sign certificates,
>7) sign CRLs,
>8) encrypt data using D-H like algorithms, and
>9) decrypt data using D-H like algorithms.
>
>
That's true.  That is also the case if the key usage extension isn't
included in the certificate.

We rely on the algorithm text (section 7.3) to recommend against
combinations that don't make sense cryptographically.  (That is, if the
public key is a DSA key, don't asssert keyEncipherment or
dataEncipherment.) I expect that is all this group can do.

More from 11/17:
>At a minimum, the profile should list the combination of bits which are not
>allowed. A few examples:
>
>1) If keyCertSign is asserted, then the only other bit that can be asserted
>is the cRLSign bit.
>2) If cRLSign is asserted, then the only other bit that can be asserted is
>the keyCertSign bit.
>3) If keyEncipherment is asserted, then keyAgreement MUST NOT be asserted.
>
>
There has been a lot of debate here, and in other groups, about which
combinations should be permitted or forbidden.  There are lots of different
opinions.  For example, I personally could accept 1) and 2) but not 3).
There are algorithms that would let me use my RSA key for key agreement or
my elliptic curve key for key transport.  I don't think I should need two
certificates to support that.  Others have rational arguments with 1) and 2).

IMHO, there is absolutely no chance that this group would ever reach
consensus on which combinations should be restricted.  It is rathole as
dark and deep as the NR bit!

Besides, PKIX client systems need to handle any combinations of key usage
bits for the sake of interoperability.  As long as path building is "hard",
people will try to limit the number of certificates they generate by
asserting all (cryptographically) reasonable bits.

>Regards,
>Aram Perez

Thanks,

Tim Polk

>P.S. I'm leaving shortly on vacation and will not be back until December 6,
>so I won't read any responses until then. Have a great Thanksgiving!
>
>

P.S. Hope you had a great vacation! 

Date: Thu, 25 Nov 1999 10:01:02 -0800
From: Ed Gerck <[email-masked]>
CC: Russ Housley <[email-masked]>, [email-masked], [email-masked]
Subject: Re: proposed key usaged text -- the final round

Denis Pinkas wrote:

> I am not going to die with the proposed text :-) ...

But, perhaps we could all live with it ;-) and move on ....

> However, there are two sentences that are rather obscure or
> not helpul and I would like to take advantage of some earlier
> E-mail exchanges to canibalize these exchanges in order to
> improve the text. The two last sentences of the section
> explaining the NR bit could be deleted without loosing
> much:
>
>   [The nonRepudiation bit is asserted when the subject
>   public key is used to verify digital signatures used to
>   provide a non-repudiation  service].  This service protects
>   against the certificate subject falsely denying signing the
>   data, excluding certificate or CRL signing. In the case of
>    later conflict, a reliable third party may determine the
>    authenticity of the signed data.

I disagree -- the first sentence explains what the NR bit is used
for (to verify digital signatures) in a specific context ( to provide
a non-repudiation service), in contrast to explaining what the service
is and why it would be useful to use it (protects against the
certificate subejct falsely denying signing).

If you believe that it could be deleted without loosing much, and
in fact something *is* lost, then it is IMO better to keep it and be clear
in a subject which has been unclear for far too long.  I would rather we
would not need to beat this horse dead an umpth-time.

> I propose to keep the first sentence unchanged and have the following
> global replacement for the three sentences:
>
> " The nonRepudiation bit is asserted when the subject public key is
> used to verify digital signatures used to provide a non-repudiation
> service. When present, the nonRepudiation bit indicates that the
> private key corresponding to the subject public key present in that
> certificate may be used to indicate the user's conscious and willing
> intent to endorse what is being signed."

I disagree -- is there anything more "rather obscure or not helpul"
than "the user's conscious and willing intent"?  So, the change IMO
is in contradiction with the purpose. Further, "to endorse" may have
different legal meanings in different jurisdictions ("endorsement
sans recourse" in the UK is one of the few that does not have legal
consequences, but it needs to have the "sans recourse" appended
to it and it is not valid in civil law regimes where almost anything that
you do flows back to the original agent -- you).

Finally, I would lint anything that predicates measuring, assessing,
controlling or even estimating "the user's conscious and willing
intent" in PKIX because if there is anything that no law, policy or
dictatorship has ever managed to do is to control people's "conscious
and willing intent" -- so, this is a slippery slope which was already
debated, spotted and marked as leading nowhere in an Internet
protocol; and debating this on and on and on and on will not change
it or make it valid by repetition.

Gosh, if we can't even say *who* the sender is, *what* path did that
message take, *if* the full communication of the sender with all its follow
up certified partial messages arrived or if there was a partial or total denial
en route which was blocked by an attacker, then how can we say what
that unknown person in an unknown place with an unknown communication
*intented* to say???

> I would also propose to add a note that explains the case of a
> certificate having both the DS and the NR bits set and to place this
> addition at the end of the whole section 4.2.1.3:
>
> " Note: A certificate with the nonRepudiation bit set should only be
> used when it is possible to get full confidence of the environments
> where the private key will be used. If a certificate has both the
> digitalSignature and the nonRepudiation bit set, the entity owning
> the private key should have full confidence of all the various
> environments and applications where the private key will being used.
> For the cases where that condidence cannot be obtained, two
> different certificates, one with one public public key and the
> digitalSignature bit set and another one with a different public key
> and the nonRepudiation bit set, should be used."

I do not want to sound in opposition to your entire email, but I also
disagree. This is an "explanation mode" definition which is repetitive
("possible to get full confidence of the environments where the private
key will be used" and "should have full confidence of all the various
environments and applications where the private key will being used");
predicates an impossible condition (full confidence) in an overbroad
context (all  the various environments where the private key will be
used); indeterminate ("For the cases where that condidence cannot
be obtained"); ineffective ("two different certificates ..."); and
contradictory (why would two wrong certificates make a right one?)

Cheers,

Ed Gerck

From: "Hiroyuki Sakakibara" <[email-masked]>
To: "Khaja E. Ahmed" <[email-masked]>, <[email-masked]>
Subject: RE: Question:Authority Information Access
Date: Thu, 25 Nov 1999 21:23:51 +0900

Mr. Khaja E. Ahmed

Thank you for your quick reply.

>All the burden you are placing on the client to check multiple places
should
>really not be necessary.  It should be possible for the client to go to a
>single location indicated by either the DP or the AIA extension and
*depend*
>on it being there just as much as you depends on the availability of the
>network itself.  Revocation status checking service should have the same

"It should be possible for the client to go to a single location ... "

The reason is that if a client communicates multiple servers( OCSP
servers and CRL DP servers) for checking the revocation status
of one certificate, the path processing will be heavy, right ?

>availability / dependability of something like DNS.  If you suddenly lose
>access to DNS service you have lost access to a mission critical service
and
>are essentially "down" or severely hobbled in your functionality.  That is
>why DNS service is designed to be highly available and dependable.

The environment where a OCSP server is always available is convinient.
However, eventhough a OCSP system has high availability and
dependability like DNS, it is not 100% perfect.
So I think, it is good that
a certificate is checked automatically
in another optional way, CRL DPs, when a OCSP system is down.

Again, in RFC2459 specification,  are following "[1] and [2] "
legal or illegal ?

----------------------------------------------------------------------------
----------------
[1] AIA + CRL DPs
1st:  OCSP server-1 ( described in AIA )
2nd: CRL DPs( described in CRL DPs )

or

[2]  AIA
1st : AccessDescription-1  "OCSP server-1"
2nd : AccessDescription-2  "use CRLs ( indicated by OBJID ),
                                                 located here( indicated by
GenelalName)"
----------------------------------------------------------------------------
----------------

Do these make sense ? No ?

Hioryuki Sakakibara

=========================================================
>> -----Original Message-----
>> From: Hiroyuki Sakakibara [mailto:[email-masked]]
>> Sent: Tuesday, November 23, 1999 7:02 PM
>> To: [email-masked]
>> Subject: Question:Authority Information Access
>>
>>
>> Hello
>>
>> I have questions about RFC2459 Authority Information Access extension .
>> In RFC2459, this extension is defined as
>>
>> "The authority information access extension indicates how to access CA
>>    information and services for the issuer of the certificate in which
>>    the extension appears. Information and services may include on-line
>>    validation services and CA policy data.  (The location of CRLs is not
>>    specified in this extension; that information is provided by the
>>    cRLDistributionPoints extension.)  This extension may be included in
>>    subject or CA certificates, and it MUST be non-critical." ...
>>
>>
>> Question 1.
>> If a certificate path verification function of a secure application
>> finds a certificate which includes BOTH Authority Information Access(AIA)
>> extension and CRL DP extension,
>> which extension will the function use ?
>>
>> Question 2.
>> I assume the following situations "case1, case2, case3".
>> I think that case1 and case2 are OK.
>> But, how about case3 ?
>> In example2, I think that AIA and CRL DPs are not available ...
>> I think that "priority" descriptions are needed in somewhere ... ???
>>
>> *****************************************
>> case 1:
>> In this case, the application policy is
>> "at first, a certificate is checked by OCSP server-1.
>> If OCSP server-1 is not available, then it will be checked by
>> OCSP server-2."
>>
>> 1st.       OCSP server-1
>> 2nd.      OCSP server-2
>>
>> -> use AIA extension only.
>>
>> case 2:
>> In this case, the application policy is
>> "at first, a certificate is checked by CRL DP-1.
>> If CRL DP-1 is not available, then it will be checked by
>> CRL DP-2."
>>
>> 1st.       CRL DP-1
>> 2nd.      CRL DP-2
>>
>> -> use CRL DPs extension only
>>
>> case 3:
>>  In this case, the application policy is
>> "a certificate is checked by OCSP servers and CRL DPs.
>>
>> example1
>>
>> 1st.       OCSP server-1
>> 2nd.      OCSP server-2
>> 3rd.      CRL DP-1
>> 4th.      CRL DP-2
>>
>> example2
>>
>> 1st.        OCSP server-1
>> 2nd.       CRL DP-1
>> 3rd.       OCSP server-2
>> 4th.       CRL DP-2
>>
>> etc ...
>>
>> *****************************************
>>
>> =========================================
>> Hiroyuki Sakakibara
>> Research Engineer
>> Information Security Department
>> Mitsubishi Electric Corporation
>> Information Technology R&D Center
>> 5-1-1 Ofuna, Kamakura, Kanagawa, 247-8501, Japan
>> PHONE: +81-467-41-2183
>> FAX: +81-467-41-2185
>> ==========================================
>>
>
>

Date: Thu, 25 Nov 1999 06:32:59 -0500
To: Russ Housley <[email-masked]>, [email-masked]
From: Stefan Santesson <[email-masked]>
Subject: Re: proposed key usaged text -- the final round
Cc: [email-masked]

Russ and Tim,

Well done!!!!!

I can certainly live with this.

/Stefan

At 15:43 1999-11-24 -0500, Russ Housley wrote:
>To people who still care about NR:
>
>In a last ditch hope of settling the key usage debate Tim Polk and I have 
>made minor adjustments to the key usage text.  We hope that this is text 
>that everyone can live with (but we know that there are some people who 
>will feel compelled to argue on and on and on and on and on and on ...).
>
>We believe that the PKIX Working Group Chairmen will have to determine 
>whether or not we have reached rough consensus or not.
>
>Thanks,
>   Tim Polk and Russ Housley
>
>
>
>----Proposed text for 4.2.1.3 Key Usage
>
>
>4.2.1.3  Key Usage
>
>    The key usage extension defines the purpose (e.g., encipherment, sig-
>    nature, certificate signing) of the key contained in the certificate.
>    The usage restriction might be employed when a key that could be used
>    for more than one operation is to be restricted.  For example, when
>    an RSA key should be used only for signing, the digitalSignature
>    and/or nonRepudiation bits would be asserted. Likewise, when an RSA
>    key should be used only for key management, the keyEncipherment bit
>    would be asserted. When used, this extension SHOULD be marked criti-
>    cal.
>
>       id-ce-keyUsage OBJECT IDENTIFIER ::=  { id-ce 15 }
>
>       KeyUsage ::= BIT STRING {
>            digitalSignature        (0),
>            nonRepudiation          (1),
>            keyEncipherment         (2),
>            dataEncipherment        (3),
>            keyAgreement            (4),
>            keyCertSign             (5),
>            cRLSign                 (6),
>            encipherOnly            (7),
>            decipherOnly            (8) }
>
>
>    Bits in the KeyUsage type are used as follows:
>
>       The digitalSignature bit is asserted when the subject public key
>       is used with a digital signature mechanism to support security
>       services other than non-repudiation (bit 1), certificate signing
>       (bit 5), or revocation information signing (bit 6). Digital signa-
>       ture mechanisms are often used for entity authentication and data
>       origin authentication with integrity.
>
>       The nonRepudiation bit is asserted when the subject public key is
>       used to verify digital signatures used to provide a non-repudiation
>       service.  This service protects against the certificate subject
>       falsely denying signing the data, excluding certificate or CRL
>       signing. In the case of later conflict, a reliable third party may
>       determine the authenticity of the signed data.
>
>       Further distinctions between the digitalSignature and nonRepudiation
>       bits may be provided in specific certificate policies.  The values
>       of the digitalSignature and nonRepudiation bits is insufficient to
>       determine the intentions of the certificate subject.  The context
>       in which the data was signed MUST also be considered.  A signature
>       policy identifier embedded in the signed data MAY be used to
>       explicitly provide context.
>
>       The keyEncipherment bit is asserted when the subject public key is
>       used for key transport.  For example, when an RSA key is to be
>       used for key management, then this bit shall asserted.
>
>       The dataEncipherment bit is asserted when the subject public key
>       is used for enciphering user data, other than cryptographic keys.
>
>       The keyAgreement bit is asserted when the subject public key is
>       used for key agreement.  For example, when a Diffie-Hellman key is
>       to be used for key management, then this bit shall asserted.
>
>       The keyCertSign bit is asserted when the subject public key is
>       used for verifying a signature on certificates.  This bit may only
>       be asserted in CA certificates.  If the keyCertSign bit is
>       asserted, then the cA bit in the basic constraints extension (see
>       4.2.1.10) MUST also be asserted. If the keyCertSign bit is not
>       asserted, then the cA bit in the basic constraints extension MUST
>       NOT be asserted.
>
>       The cRLSign bit is asserted when the subject public key is used
>       for verifying a signature on revocation information (e.g., a CRL).
>
>       The meaning of the encipherOnly bit is undefined in the absence of
>       the keyAgreement bit.  When the encipherOnly bit is asserted and
>       the keyAgreement bit is also set, the subject public key may be
>       used only for enciphering data while performing key agreement.
>
>       The meaning of the decipherOnly bit is undefined in the absence of
>       the keyAgreement bit.  When the decipherOnly bit is asserted and
>       the keyAgreement bit is also set, the subject public key may be
>       used only for deciphering data while performing key agreement.
>
>    This profile does not restrict the combinations of bits that may be
>    set in an instantiation of the keyUsage extension.  However,
>    appropriate values for keyUsage extensions for particular algorithms
>    are specified in section 7.3.

Date: Thu, 25 Nov 1999 11:52:00 +0100
From: Denis Pinkas <[email-masked]>
Organization: Bull
To: Russ Housley <[email-masked]>
CC: [email-masked], [email-masked]
Subject: Re: proposed key usaged text -- the final round

Tim and Russ,

> To people who still care about NR:

I care.

> In a last ditch hope of settling the key usage debate Tim Polk and I have
> made minor adjustments to the key usage text.  We hope that this is text
> that everyone can live with (but we know that there are some people who
> will feel compelled to argue on and on and on and on and on and on ...).

I am not going to die with the proposed text :-) ... However, there
are two sentences that are rather obscure or not helpul and I would
like to take advantage of some earlier E-mail exchanges to
canibalize these exchanges in order to improve the text. The two
last sentences of the section explaining the NR bit could be deleted
without loosing much:

        [The nonRepudiation bit is asserted when the subject public
key is
        used to verify digital signatures used to provide a
non-repudiation
        service].  This service protects against the certificate
subject
        falsely denying signing the data, excluding certificate or
CRL
        signing. In the case of later conflict, a reliable third
party may
        determine the authenticity of the signed data.

Then we could take advantage of a letter sent on November the 18 th
by David P. Kemp proposing to turn back the clock to April 29, in
order to follow a proposal from Bob Jueneman. 

" > Date: Fri, 30 Apr 1999 13:37:05 -0600
  > From: "Bob Jueneman" <[email-masked]>
  > 
  > Recently, we have been having some discussion regarding 
  > Nonrepudiation on the cert-talk list, and I have been taking the 
  > position that the Nonrepudiation key usage bit should be
reserved
  > for those key pairs that are used exclusively to indicate the
user's
  > conscious and willing intent to be legally bound by what is
being 
  > signed.

  I agree with Stefan and Peter that we should turn back the clock
to
  April 29, and use the bit to specify exclusively concrete usage of 
  the key by applications."

There was no text proposal at that time. Using this input, (and
replacing "legally bound" by the notion of "endorsement" that
contains less legal sensitivity) I propose to keep the first
sentence unchanged and have the following global replacement for the
three sentences:

" The nonRepudiation bit is asserted when the subject public key is
used to verify digital signatures used to provide a non-repudiation
service. When present, the nonRepudiation bit indicates that the
private key corresponding to the subject public key present in that
certificate may be used to indicate the user's conscious and willing
intent to endorse what is being signed." 

I would also propose to add a note that explains the case of a
certificate having both the DS and the NR bits set and to place this
addition at the end of the whole section 4.2.1.3:

" Note: A certificate with the nonRepudiation bit set should only be
used when it is possible to get full confidence of the environments
where the private key will be used. If a certificate has both the
digitalSignature and the nonRepudiation bit set, the entity owning
the private key should have full confidence of all the various
environments and applications where the private key will being used.
For the cases where that condidence cannot be obtained, two
different certificates, one with one public public key and the
digitalSignature bit set and another one with a different public key
and the nonRepudiation bit set, should be used." 

Denis

> We believe that the PKIX Working Group Chairmen will have to determine
> whether or not we have reached rough consensus or not.
> 
> Thanks,
>    Tim Polk and Russ Housley
> 
> ----Proposed text for 4.2.1.3 Key Usage
> 
> 4.2.1.3  Key Usage
> 
>     The key usage extension defines the purpose (e.g., encipherment, sig-
>     nature, certificate signing) of the key contained in the certificate.
>     The usage restriction might be employed when a key that could be used
>     for more than one operation is to be restricted.  For example, when
>     an RSA key should be used only for signing, the digitalSignature
>     and/or nonRepudiation bits would be asserted. Likewise, when an RSA
>     key should be used only for key management, the keyEncipherment bit
>     would be asserted. When used, this extension SHOULD be marked criti-
>     cal.
> 
>        id-ce-keyUsage OBJECT IDENTIFIER ::=  { id-ce 15 }
> 
>        KeyUsage ::= BIT STRING {
>             digitalSignature        (0),
>             nonRepudiation          (1),
>             keyEncipherment         (2),
>             dataEncipherment        (3),
>             keyAgreement            (4),
>             keyCertSign             (5),
>             cRLSign                 (6),
>             encipherOnly            (7),
>             decipherOnly            (8) }
> 
>     Bits in the KeyUsage type are used as follows:
> 
>        The digitalSignature bit is asserted when the subject public key
>        is used with a digital signature mechanism to support security
>        services other than non-repudiation (bit 1), certificate signing
>        (bit 5), or revocation information signing (bit 6). Digital signa-
>        ture mechanisms are often used for entity authentication and data
>        origin authentication with integrity.
> 
>        The nonRepudiation bit is asserted when the subject public key is
>        used to verify digital signatures used to provide a non-repudiation
>        service.  This service protects against the certificate subject
>        falsely denying signing the data, excluding certificate or CRL
>        signing. In the case of later conflict, a reliable third party may
>        determine the authenticity of the signed data.
> 
>        Further distinctions between the digitalSignature and nonRepudiation
>        bits may be provided in specific certificate policies.  The values
>        of the digitalSignature and nonRepudiation bits is insufficient to
>        determine the intentions of the certificate subject.  The context
>        in which the data was signed MUST also be considered.  A signature
>        policy identifier embedded in the signed data MAY be used to
>        explicitly provide context.
> 
>        The keyEncipherment bit is asserted when the subject public key is
>        used for key transport.  For example, when an RSA key is to be
>        used for key management, then this bit shall asserted.
> 
>        The dataEncipherment bit is asserted when the subject public key
>        is used for enciphering user data, other than cryptographic keys.
> 
>        The keyAgreement bit is asserted when the subject public key is
>        used for key agreement.  For example, when a Diffie-Hellman key is
>        to be used for key management, then this bit shall asserted.
> 
>        The keyCertSign bit is asserted when the subject public key is
>        used for verifying a signature on certificates.  This bit may only
>        be asserted in CA certificates.  If the keyCertSign bit is
>        asserted, then the cA bit in the basic constraints extension (see
>        4.2.1.10) MUST also be asserted. If the keyCertSign bit is not
>        asserted, then the cA bit in the basic constraints extension MUST
>        NOT be asserted.
> 
>        The cRLSign bit is asserted when the subject public key is used
>        for verifying a signature on revocation information (e.g., a CRL).
> 
>        The meaning of the encipherOnly bit is undefined in the absence of
>        the keyAgreement bit.  When the encipherOnly bit is asserted and
>        the keyAgreement bit is also set, the subject public key may be
>        used only for enciphering data while performing key agreement.
> 
>        The meaning of the decipherOnly bit is undefined in the absence of
>        the keyAgreement bit.  When the decipherOnly bit is asserted and
>        the keyAgreement bit is also set, the subject public key may be
>        used only for deciphering data while performing key agreement.
> 
>     This profile does not restrict the combinations of bits that may be
>     set in an instantiation of the keyUsage extension.  However,
>     appropriate values for keyUsage extensions for particular algorithms
>     are specified in section 7.3.

From: "Peter Lewis" <[email-masked]>
To: <[email-masked]>
Subject: IPSec 2000 
Date: Thu, 25 Nov 1999 10:47:18 +0100
Organization: Upperside

This is a multi-part message in MIME format.

------=_NextPart_000_0112_01BF3732.7200A2C0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

IPSec 2000 Global Summit: the international rendez-vous. A CFP is online =
at:
http://www.upperside.fr/baipsecy2k.htm

------=_NextPart_000_0112_01BF3732.7200A2C0
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META content=3D"text/html; charset=3Diso-8859-1" =
http-equiv=3DContent-Type>
<META content=3D"MSHTML 5.00.2314.1000" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV>
<DIV><FONT color=3D#000000 size=3D3>IPSec 2000 Global Summit: the =
international=20
rendez-vous. A CFP is online at:</FONT></DIV>
<DIV><FONT color=3D#000000 size=3D3><A=20
href=3D"http://www.upperside.fr/baipsecy2k.htm">http://www.upperside.fr/b=
aipsecy2k.htm</A></FONT></DIV>
<DIV>&nbsp;</DIV></DIV></BODY></HTML>

------=_NextPart_000_0112_01BF3732.7200A2C0--

Date: Wed, 24 Nov 1999 14:39:36 -0800
From: Ed Gerck <[email-masked]>
To: Russ Housley <[email-masked]>
CC: [email-masked], [email-masked]
Subject: Re: proposed key usaged text -- the final round

Russ Housley wrote:

> To people who still care about NR:
>
> In a last ditch hope of settling the key usage debate Tim Polk and I have
> made minor adjustments to the key usage text.  We hope that this is text
> that everyone can live with (but we know that there are some people who
> will feel compelled to argue on and on and on and on and on and on ...).

Russ and Tim:

Fine. The changes are IMO enough to capture the main points that I saw
worthwhile to discuss on and on and on ;-)  The inclusion of "falsely"
is now also in IMO fine, because it is clearly seen from the relying-party
viewpoint.   I have just one minor comment that is most probably just a
text glitch that can easily be corrected:

The text:

 The dataEncipherment bit is asserted when the subject public key
 is used for enciphering user data, other than cryptographic keys.

should be:

 The dataEncipherment bit is asserted when the subject public key
 is used for enciphering data other than cryptographic keys.

[i.e., deleted "user" and the comma]

Thank you both for the fine job!

Have a Great Thanksgiving.

Cheers,

Ed Gerck

>
> ----Proposed text for 4.2.1.3 Key Usage
>
> 4.2.1.3  Key Usage
>
>     The key usage extension defines the purpose (e.g., encipherment, sig-
>     nature, certificate signing) of the key contained in the certificate.
>     The usage restriction might be employed when a key that could be used
>     for more than one operation is to be restricted.  For example, when
>     an RSA key should be used only for signing, the digitalSignature
>     and/or nonRepudiation bits would be asserted. Likewise, when an RSA
>     key should be used only for key management, the keyEncipherment bit
>     would be asserted. When used, this extension SHOULD be marked criti-
>     cal.
>
>        id-ce-keyUsage OBJECT IDENTIFIER ::=  { id-ce 15 }
>
>        KeyUsage ::= BIT STRING {
>             digitalSignature        (0),
>             nonRepudiation          (1),
>             keyEncipherment         (2),
>             dataEncipherment        (3),
>             keyAgreement            (4),
>             keyCertSign             (5),
>             cRLSign                 (6),
>             encipherOnly            (7),
>             decipherOnly            (8) }
>
>     Bits in the KeyUsage type are used as follows:
>
>        The digitalSignature bit is asserted when the subject public key
>        is used with a digital signature mechanism to support security
>        services other than non-repudiation (bit 1), certificate signing
>        (bit 5), or revocation information signing (bit 6). Digital signa-
>        ture mechanisms are often used for entity authentication and data
>        origin authentication with integrity.
>
>        The nonRepudiation bit is asserted when the subject public key is
>        used to verify digital signatures used to provide a non-repudiation
>        service.  This service protects against the certificate subject
>        falsely denying signing the data, excluding certificate or CRL
>        signing. In the case of later conflict, a reliable third party may
>        determine the authenticity of the signed data.
>
>        Further distinctions between the digitalSignature and nonRepudiation
>        bits may be provided in specific certificate policies.  The values
>        of the digitalSignature and nonRepudiation bits is insufficient to
>        determine the intentions of the certificate subject.  The context
>        in which the data was signed MUST also be considered.  A signature
>        policy identifier embedded in the signed data MAY be used to
>        explicitly provide context.
>
>        The keyEncipherment bit is asserted when the subject public key is
>        used for key transport.  For example, when an RSA key is to be
>        used for key management, then this bit shall asserted.
>
>        The dataEncipherment bit is asserted when the subject public key
>        is used for enciphering user data, other than cryptographic keys.
>
>        The keyAgreement bit is asserted when the subject public key is
>        used for key agreement.  For example, when a Diffie-Hellman key is
>        to be used for key management, then this bit shall asserted.
>
>        The keyCertSign bit is asserted when the subject public key is
>        used for verifying a signature on certificates.  This bit may only
>        be asserted in CA certificates.  If the keyCertSign bit is
>        asserted, then the cA bit in the basic constraints extension (see
>        4.2.1.10) MUST also be asserted. If the keyCertSign bit is not
>        asserted, then the cA bit in the basic constraints extension MUST
>        NOT be asserted.
>
>        The cRLSign bit is asserted when the subject public key is used
>        for verifying a signature on revocation information (e.g., a CRL).
>
>        The meaning of the encipherOnly bit is undefined in the absence of
>        the keyAgreement bit.  When the encipherOnly bit is asserted and
>        the keyAgreement bit is also set, the subject public key may be
>        used only for enciphering data while performing key agreement.
>
>        The meaning of the decipherOnly bit is undefined in the absence of
>        the keyAgreement bit.  When the decipherOnly bit is asserted and
>        the keyAgreement bit is also set, the subject public key may be
>        used only for deciphering data while performing key agreement.
>
>     This profile does not restrict the combinations of bits that may be
>     set in an instantiation of the keyUsage extension.  However,
>     appropriate values for keyUsage extensions for particular algorithms
>     are specified in section 7.3.

Date: Wed, 24 Nov 1999 13:35:39 -0800
Subject: Re: proposed key usaged text -- the final round
From: "Aram Perez" <[email-masked]>
To: [email-masked]

Hi Tim and Russ,

Thanks for taking the effort to clarify and settling the key usage debate.
Below are a few comments...

> To people who still care about NR:
>
> In a last ditch hope of settling the key usage debate Tim Polk and I have
> made minor adjustments to the key usage text.  We hope that this is text
> that everyone can live with (but we know that there are some people who
> will feel compelled to argue on and on and on and on and on and on ...).
>
> We believe that the PKIX Working Group Chairmen will have to determine
> whether or not we have reached rough consensus or not.
>
> Thanks,
>    Tim Polk and Russ Housley
>
[snip]
>
>        The dataEncipherment bit is asserted when the subject public key
>        is used for enciphering user data, other than cryptographic keys.

I'd would change "enciphering user data" to "enciphering data".

>
>        The keyAgreement bit is asserted when the subject public key is
>        used for key agreement.  For example, when a Diffie-Hellman key is
>        to be used for key management, then this bit shall asserted.
>
>        The keyCertSign bit is asserted when the subject public key is
>        used for verifying a signature on certificates.  This bit may only
>        be asserted in CA certificates.  If the keyCertSign bit is
>        asserted, then the cA bit in the basic constraints extension (see
>        4.2.1.10) MUST also be asserted. If the keyCertSign bit is not
>        asserted, then the cA bit in the basic constraints extension MUST
>        NOT be asserted.
>
>        The cRLSign bit is asserted when the subject public key is used
>        for verifying a signature on revocation information (e.g., a CRL).

Neither of you responded to my previous comment on this bit. If cRLSign bit
is asserted, must the cA bit in the basic constraints extension also be
asserted? And vice-versa?

>
>        The meaning of the encipherOnly bit is undefined in the absence of
>        the keyAgreement bit.  When the encipherOnly bit is asserted and
>        the keyAgreement bit is also set, the subject public key may be
>        used only for enciphering data while performing key agreement.
>
>        The meaning of the decipherOnly bit is undefined in the absence of
>        the keyAgreement bit.  When the decipherOnly bit is asserted and
>        the keyAgreement bit is also set, the subject public key may be
>        used only for deciphering data while performing key agreement.
>
>     This profile does not restrict the combinations of bits that may be
>     set in an instantiation of the keyUsage extension.  However,
>     appropriate values for keyUsage extensions for particular algorithms
>     are specified in section 7.3.

Again, neither of you responded to my previous comment on at least
recommending against certain combinations.

Regards,
Aram Perez

P.S. I'm leaving shortly on vacation and will not be back until December 6,
so I won't read any responses until then. Have a great Thanksgiving!

Date: Wed, 24 Nov 1999 15:43:37 -0500
To: [email-masked]
From: Russ Housley <[email-masked]>
Subject: proposed key usaged text -- the final round
Cc: [email-masked]

To people who still care about NR:

In a last ditch hope of settling the key usage debate Tim Polk and I have 
made minor adjustments to the key usage text.  We hope that this is text 
that everyone can live with (but we know that there are some people who 
will feel compelled to argue on and on and on and on and on and on ...).

We believe that the PKIX Working Group Chairmen will have to determine 
whether or not we have reached rough consensus or not.

Thanks,
   Tim Polk and Russ Housley

----Proposed text for 4.2.1.3 Key Usage

4.2.1.3  Key Usage

    The key usage extension defines the purpose (e.g., encipherment, sig-
    nature, certificate signing) of the key contained in the certificate.
    The usage restriction might be employed when a key that could be used
    for more than one operation is to be restricted.  For example, when
    an RSA key should be used only for signing, the digitalSignature
    and/or nonRepudiation bits would be asserted. Likewise, when an RSA
    key should be used only for key management, the keyEncipherment bit
    would be asserted. When used, this extension SHOULD be marked criti-
    cal.

       id-ce-keyUsage OBJECT IDENTIFIER ::=  { id-ce 15 }

       KeyUsage ::= BIT STRING {
            digitalSignature        (0),
            nonRepudiation          (1),
            keyEncipherment         (2),
            dataEncipherment        (3),
            keyAgreement            (4),
            keyCertSign             (5),
            cRLSign                 (6),
            encipherOnly            (7),
            decipherOnly            (8) }

    Bits in the KeyUsage type are used as follows:

       The digitalSignature bit is asserted when the subject public key
       is used with a digital signature mechanism to support security
       services other than non-repudiation (bit 1), certificate signing
       (bit 5), or revocation information signing (bit 6). Digital signa-
       ture mechanisms are often used for entity authentication and data
       origin authentication with integrity.

       The nonRepudiation bit is asserted when the subject public key is
       used to verify digital signatures used to provide a non-repudiation
       service.  This service protects against the certificate subject
       falsely denying signing the data, excluding certificate or CRL
       signing. In the case of later conflict, a reliable third party may
       determine the authenticity of the signed data.

       Further distinctions between the digitalSignature and nonRepudiation
       bits may be provided in specific certificate policies.  The values
       of the digitalSignature and nonRepudiation bits is insufficient to
       determine the intentions of the certificate subject.  The context
       in which the data was signed MUST also be considered.  A signature
       policy identifier embedded in the signed data MAY be used to
       explicitly provide context.

       The keyEncipherment bit is asserted when the subject public key is
       used for key transport.  For example, when an RSA key is to be
       used for key management, then this bit shall asserted.

       The dataEncipherment bit is asserted when the subject public key
       is used for enciphering user data, other than cryptographic keys.

       The keyAgreement bit is asserted when the subject public key is
       used for key agreement.  For example, when a Diffie-Hellman key is
       to be used for key management, then this bit shall asserted.

       The keyCertSign bit is asserted when the subject public key is
       used for verifying a signature on certificates.  This bit may only
       be asserted in CA certificates.  If the keyCertSign bit is
       asserted, then the cA bit in the basic constraints extension (see
       4.2.1.10) MUST also be asserted. If the keyCertSign bit is not
       asserted, then the cA bit in the basic constraints extension MUST
       NOT be asserted.

       The cRLSign bit is asserted when the subject public key is used
       for verifying a signature on revocation information (e.g., a CRL).

       The meaning of the encipherOnly bit is undefined in the absence of
       the keyAgreement bit.  When the encipherOnly bit is asserted and
       the keyAgreement bit is also set, the subject public key may be
       used only for enciphering data while performing key agreement.

       The meaning of the decipherOnly bit is undefined in the absence of
       the keyAgreement bit.  When the decipherOnly bit is asserted and
       the keyAgreement bit is also set, the subject public key may be
       used only for deciphering data while performing key agreement.

    This profile does not restrict the combinations of bits that may be
    set in an instantiation of the keyUsage extension.  However,
    appropriate values for keyUsage extensions for particular algorithms
    are specified in section 7.3.

From: [email-masked]
Subject: inhibitAnyPolicy extension
To: [email-masked]
Date: Wed, 24 Nov 1999 08:36:00 +0100 (CET)

In the son-of-RFC-2459, a basic path validation algorithm mentions
an inhibitAnyPolicy extension (Section 6.1.4, step (j)). Can some please
explain where is this extension defined or what is its precise syntax and
semantics?

Regards,

Tomaz Klobucar

-----------------------------------------------
Laboratory for Open Systems and Networks
Jozef Stefan Institute
Jamova 39, 1000 Ljubljana, Slovenia
[email-masked]
http://www.e5.ijs.si

From: "Khaja E. Ahmed" <[email-masked]>
To: "Hiroyuki Sakakibara" <[email-masked]>, <[email-masked]>
Subject: RE: Question:Authority Information Access
Date: Tue, 23 Nov 1999 19:36:47 -0800
Importance: Normal

All the burden you are placing on the client to check multiple places should
really not be necessary.  It should be possible for the client to go to a
single location indicated by either the DP or the AIA extension and *depend*
on it being there just as much as you depends on the availability of the
network itself.  Revocation status checking service should have the same
availability / dependability of something like DNS.  If you suddenly lose
access to DNS service you have lost access to a mission critical service and
are essentially "down" or severely hobbled in your functionality.  That is
why DNS service is designed to be highly available and dependable.

That degree of dependability and availability is precisely what you should
expect of your PKI / Validation service/product provider.  This is very
doable and these solutions are COTS and today.

Khaja

> -----Original Message-----
> From: Hiroyuki Sakakibara [mailto:[email-masked]]
> Sent: Tuesday, November 23, 1999 7:02 PM
> To: [email-masked]
> Subject: Question:Authority Information Access
>
>
> Hello
>
> I have questions about RFC2459 Authority Information Access extension .
> In RFC2459, this extension is defined as
>
> "The authority information access extension indicates how to access CA
>    information and services for the issuer of the certificate in which
>    the extension appears. Information and services may include on-line
>    validation services and CA policy data.  (The location of CRLs is not
>    specified in this extension; that information is provided by the
>    cRLDistributionPoints extension.)  This extension may be included in
>    subject or CA certificates, and it MUST be non-critical." ...
>
>
> Question 1.
> If a certificate path verification function of a secure application
> finds a certificate which includes BOTH Authority Information Access(AIA)
> extension and CRL DP extension,
> which extension will the function use ?
>
> Question 2.
> I assume the following situations "case1, case2, case3".
> I think that case1 and case2 are OK.
> But, how about case3 ?
> In example2, I think that AIA and CRL DPs are not available ...
> I think that "priority" descriptions are needed in somewhere ... ???
>
> *****************************************
> case 1:
> In this case, the application policy is
> "at first, a certificate is checked by OCSP server-1.
> If OCSP server-1 is not available, then it will be checked by
> OCSP server-2."
>
> 1st.       OCSP server-1
> 2nd.      OCSP server-2
>
> -> use AIA extension only.
>
> case 2:
> In this case, the application policy is
> "at first, a certificate is checked by CRL DP-1.
> If CRL DP-1 is not available, then it will be checked by
> CRL DP-2."
>
> 1st.       CRL DP-1
> 2nd.      CRL DP-2
>
> -> use CRL DPs extension only
>
> case 3:
>  In this case, the application policy is
> "a certificate is checked by OCSP servers and CRL DPs.
>
> example1
>
> 1st.       OCSP server-1
> 2nd.      OCSP server-2
> 3rd.      CRL DP-1
> 4th.      CRL DP-2
>
> example2
>
> 1st.        OCSP server-1
> 2nd.       CRL DP-1
> 3rd.       OCSP server-2
> 4th.       CRL DP-2
>
> etc ...
>
> *****************************************
>
> =========================================
> Hiroyuki Sakakibara
> Research Engineer
> Information Security Department
> Mitsubishi Electric Corporation
> Information Technology R&D Center
> 5-1-1 Ofuna, Kamakura, Kanagawa, 247-8501, Japan
> PHONE: +81-467-41-2183
> FAX: +81-467-41-2185
> ==========================================
>

From: "Hiroyuki Sakakibara" <[email-masked]>
To: <[email-masked]>
Subject: Question:Authority Information Access
Date: Wed, 24 Nov 1999 12:01:31 +0900

Hello

I have questions about RFC2459 Authority Information Access extension .
In RFC2459, this extension is defined as

"The authority information access extension indicates how to access CA
   information and services for the issuer of the certificate in which
   the extension appears. Information and services may include on-line
   validation services and CA policy data.  (The location of CRLs is not
   specified in this extension; that information is provided by the
   cRLDistributionPoints extension.)  This extension may be included in
   subject or CA certificates, and it MUST be non-critical." ...

Question 1.
If a certificate path verification function of a secure application
finds a certificate which includes BOTH Authority Information Access(AIA)
extension and CRL DP extension,
which extension will the function use ?

Question 2.
I assume the following situations "case1, case2, case3".
I think that case1 and case2 are OK.
But, how about case3 ?
In example2, I think that AIA and CRL DPs are not available ...
I think that "priority" descriptions are needed in somewhere ... ???

*****************************************
case 1: 
In this case, the application policy is 
"at first, a certificate is checked by OCSP server-1.
If OCSP server-1 is not available, then it will be checked by
OCSP server-2."

1st.       OCSP server-1 
2nd.      OCSP server-2

-> use AIA extension only.

case 2: 
In this case, the application policy is 
"at first, a certificate is checked by CRL DP-1. 
If CRL DP-1 is not available, then it will be checked by
CRL DP-2."

1st.       CRL DP-1
2nd.      CRL DP-2

-> use CRL DPs extension only 

case 3:
 In this case, the application policy is 
"a certificate is checked by OCSP servers and CRL DPs.

example1

1st.       OCSP server-1
2nd.      OCSP server-2 
3rd.      CRL DP-1
4th.      CRL DP-2

example2

1st.        OCSP server-1
2nd.       CRL DP-1
3rd.       OCSP server-2
4th.       CRL DP-2

etc ...

*****************************************

=========================================
Hiroyuki Sakakibara
Research Engineer
Information Security Department
Mitsubishi Electric Corporation
Information Technology R&D Center
5-1-1 Ofuna, Kamakura, Kanagawa, 247-8501, Japan
PHONE: +81-467-41-2183
FAX: +81-467-41-2185
==========================================

Date: Tue, 23 Nov 1999 18:49:27 -0500
To: Jyri =?iso-8859-1?Q?T=E4htinen?= <[email-masked]>, [email-masked]
From: Stefan Santesson <[email-masked]>
Subject: Re: We have to choose serialNumber instead of dnQualifier  NOW!!!
Cc: [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked]

I guess that this is the same problem then for all "pilotAttributeType",
such as our problem with domainComponent, that the OID branch is high jacked.

/Stefan

At 08:46 1999-11-23 +0200, Jyri Tähtinen wrote:
>> There's just one problem: The object identifier is really long (and
>> invalid).
>
>I don't know whether the length of OID is a real problem (except for
>human readers ;-)
>
>I am not ASN.1 expert and therefore can not say how the OID is invalid,
>but at least these OIDs are widely in use. 
>
>For example, email address, LDAP v3 attribute type mail = LDAP v2
>rfc822Mailbox is pilotAttributeType.3 (OID 0.9.2342.19200300.100.1.3 ).
>
>
>regards,
>
>Jyri
>
>> 
>> -- Magnus
>> 

From: "Bill Price" <[email-masked]>
To: <[email-masked]>, <[email-masked]>
Cc: <[email-masked]>
Subject: RE: Unknown private verisign extension
Date: Tue, 23 Nov 1999 17:26:38 -0500
Importance: Normal

After a series of exchanges with Verisign, I was told that the ... ".1.6.3
OID extension contains country, zip, date of birth, and gender. This data is
masked to prevent misuse or abuse by third parties." (You can voluntarily
provide the information when requesting a cert.)  I was told that I'd have
to contact my sales rep and enter some sort of non-disclosure agreement to
learn how to unmask the data. The designated sales rep has not responded.

Has anyone cracked the masking?

Bill Price

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]
> Sent: Wednesday, November 24, 1999 4:20 AM
> To: [email-masked]
> Cc: [email-masked]
> Subject: Re: Unknown private verisign extension
>
>
> [cc'd to PKIX for comment]
>
> [email-masked] writes:
>
> >Included below is a exchange of E-Mails with verisign support. I recently
> >obtained a versign cert and found an undocumented private
> verisign extension
> >in it. It is obvious that I want to know what information is
> stored in that
> >extension. Verisign fails to give an sufficient answer.
>
> I've been trying to find out what 2.16.840.1.113733.1.6.3 and
> 2.16.840.1.113733.1.6.6 are, as well as what the policy qualifiers
> 2 16 840 1 113733 1 7 1 1 1 and 2 16 840 1 113733 1 7 1 1 2 mean,
> for some
> time now, but noone at Verisign will tell you.
>
> This leads to an interesting question: What are the semantics for
> these things?
> As far as anyone knows, the .1 policy could be "By using this
> certificate you
> agree to take full responsibility for any misuse of this certificate,
> regardless of what the CPS says" (which would be perfectly valid,
> since it's a
> policy qualifier), .2 might be "In the event of any dispute,
> Verisign is always
> right", .3 contains a copy of your private key encrypted with
> _NSAKEY :-), and
> who knows what .6 is.  Since the point of a CPS is that both the
> end entity and
> relying party can read it and know what they're getting, wouldn't
> the use of
> unpublished qualifiers and extensions which can modify the CPS destroy any
> possibility of reliance on the certs which contain them?
>
> Peter.
>

From: Peter Williams <[email-masked]>
To: [email-masked], =?iso-8859-1?Q?Jyri_T=E4htinen?= <[email-masked]>
Cc: [email-masked]
Subject: RE: We have to choose serialNumber instead of dnQualifier  NOW!!!
Date: Tue, 23 Nov 1999 14:00:22 -0800

> -----Original Message-----
> From: Magnus Nystrom [mailto:[email-masked]]
> Sent: Tuesday, November 23, 1999 5:19 AM
> To: Jyri Tähtinen
> 
> Subject: Re: We have to choose serialNumber instead of dnQualifier
> NOW!!!

> On Tue, 23 Nov 1999, Jyri Tähtinen wrote:
> 
> > Magnus Nystrom wrote:
> 
> [...] 
> > > There's just one problem: The object identifier is really 
> long (and
> > > invalid).
> > 
> > I don't know whether the length of OID is a real problem (except for
> > human readers ;-)
> 
> It could be a problem in resource-constrained environments (space,
> bandwidth) since certificates containing such OIDs will tend to be
> unnecessary long.
>  
> > I am not ASN.1 expert and therefore can not say how the OID 
> is invalid,
> > but at least these OIDs are widely in use. 
> > 
> > For example, email address, LDAP v3 attribute type mail = LDAP v2
> > rfc822Mailbox is pilotAttributeType.3 (OID 
> 0.9.2342.19200300.100.1.3 ).
> 
> I know, but a second-level branch of 9 is not defined. The 
> branch 0 9 was,
> citing the editor of X.680/ISO 8824-1 "hi-jacked" by IETF. But this is
> another story however.
>

The editor is perhaps wrong. It was probably hijacked by UCL-CS. Funny 
to see so many formal US State legal framework now built on such shaky
ground and pilot program status, given the transience of the UCL 
network registrations underlying...
 
[Kil89]  S.E. Kille. A string encoding of presentation address.
         Research Note RN/89/14, Department of Computer Science,
         University College London, February 1989.

See ftp://ftp.isi.edu/in-notes/rfc1278.txt for the derivation
of the BT packet switch stream service X121 data service's
idi value 2342, and ucl-cs's dsp 19200300 values.

also, see

http://wwwpks.atnf.csiro.au/library/WWW/pmdf/x500_sysman/book_h.html#appendi
x_c

(quipu OBJECT IDENTIFIER ::= {ccitt data(9) pss(2342) ucl(19200300)
quipu(99)} 
                                     -- interim QUIPU OID)

(The number of people who understand directory names is small. The number
of people who have ever built a (Quipu) I&A security policy using 
properly architected directory names, with or without strong 
authentication and certified keys, is probably even smaller.)

The oid is particularly relevant to PKIX because of:

http://www.landfield.com/rfcs/rfc2247.html

Thus the domain name "CS.UCL.AC.UK" can be transformed into

        DC=CS,DC=UCL,DC=AC,DC=UK

   Distinguished names in which there are one or more RDNs, all
   containing only the attribute type DC, can be mapped back into domain
   names. Note that this document does not define a domain name
   equivalence for any other distinguished names.

4. Attribute Type Definition

   The DC (short for domainComponent) attribute type is defined as
   follows:

    ( 0.9.2342.19200300.100.1.25 NAME 'dc' EQUALITY caseIgnoreIA5Match
     SUBSTR caseIgnoreIA5SubstringsMatch
     SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 SINGLE-VALUE )

> -- Magnus

Reply-To: "Winchel 'Todd' Vincent, III" <[email-masked]>
From: "Winchel 'Todd' Vincent, III" <[email-masked]>
To: "Tim Moses" <[email-masked]>, <[email-masked]>, <[email-masked]>
Subject: Re:      Re: Certificate Policy vs Certification Practice .. where are the             boundaries? ... what belongs where?
Date: Tue, 23 Nov 1999 16:08:31 -0500

> A certificate's conditions of use can be bound to the authority public key
> with which it is verified in the mechanism used to distribute that
authority
> public key, perhaps using XML, as Todd suggests.  With a standard Document
> Type Definition and associated style sheet, one can render the conditions
of
> use for the authority's certificates in a way that is readily understood
by
> potential relying parties.  This approach is also consistent with the
> Santesson/Baum notion of a PKI Disclosure Statement.

Wow!!!

I've found a soulmate!!

110% agreement.

Stated a bit differently, stylesheets can hide or extract particular
portions of a larger "smart" document (e.g., CP or CPS coded in XML) and
distribute only relevant portions, in context, to the person who is
interested in the information . . . a smaller subset of information might be
a subscriber agreement, a relying party agreement, a PKI disclosure
statement, a consumer notice, an auditor's checklist . . . just about
anything you want provided the information is continued in the larger
document (or even documents).

XML can also be parsed into databases (if this is the method of choice) so
that like provisions of different CPs or CPSs can be compared . . .which is
*not* a way of using artificial intelligence to map policies (i.e., nobody
get scared, we're not trying to replace lawyers and consultants), but is
merely a way of using an information management tool to avoid having to wade
through a lot of paper and/or "dumb" electronic documents.

Todd

From: "John C. Kennedy" <[email-masked]>
To: "Russ Housley" <[email-masked]>
Cc: <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>, "Elaine Barker" <[email-masked]>, "Sharon Keller" <[email-masked]>, "Simon Blake-Wilson" <[email-masked]>, "Phil Griffin" <[email-masked]>
Subject: RE: FIPS 186 and X9.42: One of these things is not like the other
Date: Tue, 23 Nov 1999 12:52:36 -0800
Importance: Normal

Russ,

No harm done.  At the same time, I apologize if you or anyone else might
have taken my comments personally.  I know that trying to align the work of
different standards groups is like trying to herd cats.  Especially in the
case of ANSI and IETF. (In fact, my doctor said that I am only allowed to
resume standards work if I boost my medication. ;-)

Moving forward, I think we still need to revisit the RFC 2631 / X9.42
alignment issue.  If a implementor claims to support "X9.42 Diffie-Hellman",
but has based their implementation on RFC 2631, no one is particularly well
served.

1) If X9.42 is not stable, then it is not a good foundation for derivative
IETF standards like it is now.

2) If X9.42 *is* stable (which I doubt purely based on experience), then RFC
2631 should probably look more like draft-ietf-smime-ecc-00.txt on.  I.e., a
profile that does not duplicate or approximate the mathematical details of
the referenced draft standard.  This is expecially true if it gives
attribution to X9.42.  If close is good enough, then perhaps we just profile
IEEE P1363 and reference it as the base standard instead.  P1363 can supply
all the bells and whistles in X9.42 except for the ASN.1 and test vectors.
This might also help avoid copyright infringement issues that might
reasonably argued with regards to RFC 2631 and X9.42.

3) I would like to continue this discussion but without continuing to copy
so many people and lists.  I have already pruned out IPSEC.  Please advise
whether this should just continue only within the S/Mime list or if it
affects all of the security groups as I believe it might.

Regards,

-John Kennedy

> -----Original Message-----
> From: Russ Housley [mailto:[email-masked]]
> Sent: Tuesday, November 23, 1999 6:18 AM
> To: John C. Kennedy
> Cc: [email-masked]; [email-masked]; [email-masked];
> [email-masked]; [email-masked]; [email-masked];
> [email-masked]; [email-masked]; [email-masked];
> [email-masked]; Elaine Barker; Sharon Keller; Simon
> Blake-Wilson; Phil Griffin
> Subject: RE: FIPS 186 and X9.42: One of these things is not like the
> other
>
>
> John:
>
> At 12:57 PM 11/22/99 -0800, John C. Kennedy wrote:
> >1. With all due respect, saying that I have been "out of the loop" is not
> >quite correct.  I have continued to track the output of both
> X9F1 and IETF
> >with regards to X9.42 and DH for the last couple of years. I have copies
> >of X9.42 drafts up through February 1999.  One does not have to
> be "in the
> >loop" to see the inconsistencies I have pointed out.
> >
> >2. The PKIX "son-of-2459" work, of which mostly only the ASN.1 portion of
> >X9.42 is relevant, is probably correct.  What is a bigger problem is that
> >RFC 2631 (Diffie-Hellman Key Agreement Method) by Eric Rescorla
> references
> >a 1998 draft. The related drafts,
> <draft-ietf-smime-small-subgroup-02.txt>
> >and <draft-ietf-pkix-dhpop-02.txt>, reference RFC 2631.  Is there proper
> >alignment in these works with the current state of X9.42?  I don't think
> >so.  How would the larger IETF community know if they were?  Is ANSI
> >keeping all these authors "in the loop"?
> >
> >3. FIPS 186-1 on DSA and rDSA is a good example.  If the X9.42
> >specification had been kept as simple as FIPS 186 we wouldn't be where we
> >are now.  It is unfortunate that crypto-politics and other machinations
> >did not allow NIST to handle this work independent of ANSI from the
> >beginning.
>
> 1.  I apologize.  You certainly have not taken an active role in the IETF
> or X9F1 for the last few years.  I am glad to hear that you have kept
> current.  I would encourage you to become actively involved again.
>
> 2.  Once the IETF adopted X9.42, I worked diligently with X9F1 to ensure
> that none of the aspects of X9.42 that were adopted by the IETF were
> changed.  We made a final comparison of the X9.42 draft and RFC 2631 just
> prior to publication of the RFC.  I have commitment that the
> parts of X9.42
> that are included in RFC 2631 will not be changed unless a
> security problem
> is discovered.  If a security problem is discovered, then the IETF will
> want to update RFC 2631 anyway, so this is not a concern.
>
> 3.  Agree.
>
> Russ

Date: Tue, 23 Nov 1999 11:40:14 -0800
Subject: Re: NR Signing-Entity vs Certificate-Subject
From: "Aram Perez" <[email-masked]>
To: PKIX <[email-masked]>

Irene Gassko wrote:

> Will renaming NR bit into "archival" or "persistent" signature bit (as
> opposed to "ephemeral")
> make everybody happy? If yes, then we need to state what additional steps
> are to be
> associated with it.

First define "archival" or "persistent" with respect to keyUsage.

Regards,
Aram Perez

Date: Tue, 23 Nov 1999 11:39:03 -0800
From: Ed Gerck <[email-masked]>
To: "David P. Kemp" <[email-masked]>
CC: [email-masked]
Subject: Re: NR Signing-Entity vs Certificate-Subject

"David P. Kemp" wrote:

> The question to be answered is: "are there any application actions
> which depend on the state of a single bit, can be specified in a
> testable manner without reference to a CPS or other non-protocol
> documentation, and which are useful in support of a system which
> provides non-repudiation services?"
>

Dave:

This is the conclusion I tried to motivate -- unless we restrict the scope
of your previous question, any answer is OK.  This is the same malady
plaguing the NR bit, where so many things are implied in today's definition
that nothing can be asserted -- who asserts what, the CA or the subscriber,
is just the first indeterminate issue.

So, now that we agree on more than one topic ;-) is there an answer
in a more restricted scope?

Yes, most definitely IMO.  The present state-of-the-art answer is
supplied by Tom Gidin's RFC.  And, to allow such answer to be
further developed there are only a few changes needed when
transposing X.509 to PKIX. The changes are:

1. to lint a faulty NR definition (that can be deleted and replaced
with the main one) and,

2. to avoid the lame reference "falsely" in the NR definition,
which can however be introduced in a coherent way by the
NR service itself if one desires to first qualify and then verify.

3. (Tony's) change "signing entity" to "subject in a certificate"
in the NR definition.

4. To include Tom Gidin's RFC as a suggested implementation
(experimental might be a better word) -- let's work with it
and improve it.

Thus, the NR definitions (plural) in X.509 would be unified
to read:

 nonRepudiation:  for verifying digital signatures used in providing a
 service which protects against the subject in a certificate denying
 some action.

and Tom's RFC would provide a starting basis. Note that while Tom's
RFC on non-repudiation service is compliant with this definition,
authentication service alone is not.  Which IMO shows its usefulness.

Cheers,

Ed Gerck

Date: Tue, 23 Nov 1999 14:30:47 -0500
To: Eric Murray <[email-masked]>
From: Irene Gassko <[email-masked]>
Subject: Re: NR Signing-Entity vs Certificate-Subject
Cc: Aram Perez <[email-masked]>, [email-masked]

Will renaming NR bit into "archival" or "persistent" signature bit (as
opposed to "ephemeral")
make everybody happy? If yes, then we need to state what additional steps
are to be
associated with it.

Irene

At 11:19 AM 11/23/1999 -0800, Eric Murray wrote:
>On Tue, Nov 23, 1999 at 10:53:14AM -0800, Aram Perez wrote:
>> Dave Kemp wrote:
>> 
>> >
>> > If consensus were reached on this interpretation, then I would agree
>> > with those who suggest that the bit be deprecated, because the bit has
>> > no useful meaning if applications cannot be usefully checked for
>> > conformance.  Requiring that applications ignore the state of the bit,
>> > or act on the bit only in the context of some external and non-parsable
>> > information, is not a useful conformance specification.
>> 
>> Well stated Dave. That now makes three of us! Anyone else want to join the
>> "Deprecate NR or Bust" wagon?
>
>
>Yes.  Having watched this debate go around and around and around
>and around for the last 6 months or more, it's obvious that there's
>not going to be any consensus any time soon.
>
>So, I would suggest deprecating the NR bit and leaving the problem for
>another working group who can define a format for describing
>(internal to certs and in a and parseable way) what NR means to any
>given party to a certificate.
>
>-- 
> Eric Murray www.lne.com/~ericm  ericm at the site lne.com  PGP keyid:E03F65E5

----------------------------------------------------------------------------
-------------------------------------------------------
Irene Gassko			 Bell Laboratories		http://www.lucent.com
Lucent Technologies		Secure Technologies Dept.
1600 Osgood Street			 phone:	(978) 960-5767
Room 30-2-A31			 e-mail: 	[email-masked]
N. Andover, MA 01845		 fax: 	(978) 960-3240

Date: Tue, 23 Nov 1999 11:19:29 -0800
From: Eric Murray <[email-masked]>
To: Aram Perez <[email-masked]>
Cc: [email-masked]
Subject: Re: NR Signing-Entity vs Certificate-Subject

On Tue, Nov 23, 1999 at 10:53:14AM -0800, Aram Perez wrote:
> Dave Kemp wrote:
> 
> >
> > If consensus were reached on this interpretation, then I would agree
> > with those who suggest that the bit be deprecated, because the bit has
> > no useful meaning if applications cannot be usefully checked for
> > conformance.  Requiring that applications ignore the state of the bit,
> > or act on the bit only in the context of some external and non-parsable
> > information, is not a useful conformance specification.
> 
> Well stated Dave. That now makes three of us! Anyone else want to join the
> "Deprecate NR or Bust" wagon?

Yes.  Having watched this debate go around and around and around
and around for the last 6 months or more, it's obvious that there's
not going to be any consensus any time soon.

So, I would suggest deprecating the NR bit and leaving the problem for
another working group who can define a format for describing
(internal to certs and in a and parseable way) what NR means to any
given party to a certificate.

-- 
 Eric Murray www.lne.com/~ericm  ericm at the site lne.com  PGP keyid:E03F65E5

Date: Tue, 23 Nov 1999 11:07:58 -0800
From: Ed Gerck <[email-masked]>
To: "[email-masked]" <[email-masked]>
Subject: Re: NR Signing-Entity vs Certificate-Subject

Irene Gassko wrote:

> >So, retaining "signing entity" is to retain a dangling reference.  To use
> >"keyholder" only makes sense in X.509 if it means the "certificate subject".
> >So, why not call the thing by its name?  "Certificate subject" is all we can
> >point our finger at -- and, if the certificate subject is NOT the only
> >keyholder then it is up to the certificate subject himself to deal with it,
> >certainly not the CA and certainly not X.509.
> >
>
> Here is the problem with this as I see it. Suppose that an enterprise generates
> (private,public) key pairs for its employees and distributes certificates
> to them.
> As a result of a software bug the same key was put into certs of two different
> persons. One of them signed a document and now claims that the other one
> is the real signer. Unless we have a provision that NR==1 requires saving
> a hash of a certificate used for authentication, how do we know who it was?

Irene:

This example is outside the scope of X.509 because the second person would not
have the corresponding private-key (which is kept private to the certificate
subject and is unknown to the CA, in X.509).  Thus, the second person could not
have signed though she could have received a certificate with an exact copy
of the first public-key, by a software bug.

But, what could happen in X.509 is the reverse of what you say -- the second person
could claim that she is the real signer, providing a certificate with her DN
and the first person's key in order to prove it. This would be an impersonation,
a crime in may jurisdcitions.  It is a good example when the CA has to deal with
it because the fault lies at the CA (in other words, we can't point our finger only
at a certificate's subject).

And, some moons ago I also suggested using the certificate hash as an
"intrinsic DN" for the certificate subject in this very discussion, as well as
two years ago.  However, there are other solutions with varying degrees of
effectiveness, such as saving the DN of the signer (which does not, however,
have to be unique even in the same CA), the certificate serialNumber (which
also does not work well and may be repeated by a software bug), etc.

The solution to this "impersonation-bug" scenario (in either case -- when the
CA generates private-keys and when it does not) is thus first to recognize
that the liability falls squarely on the CA's shoulders, which can be somewhat
reduced if the CA cooperates and goes out in an effort to prove that the second
person did not sign -- which may be impossible if the second person also
obtained the corresponding private-key by directly attacking the first person's
machine (a known target, by querying the CA for the owners of the public-key).
Note that the CA may not suspect the glitch, since different subjects may
have the same key (for example, your own different email names in different
ISPs).

Now, of course, the CA can use available NR services that the first subject
*himself* might have decided to use. Which NR services may or may not
depend on that CA and may or may not provide the level of detail
*and* the level of verifiable assurance that could indicate the actual signer
in a balance of probabilities .  So, "you get what you pay for" is also valid here
and the CA might wish the first keyholder had used a more comprehensive
NR service, but this call is not for the CA to make.

Regarding the use of the name keyholder, yes it is ambiguous and that
is why Section 3.3.3 of X.509v3 defines a certificate as: "The public keys of a
user, *together  with some other information* [MY EMPHASIS], rendered
unforgeable by encipherment with the private key of the certification authority
which issued it.".  In other words, the certificate is not only the signed key. That
"some other information" is provided in order to enable a relying-party to
verify the certificate *and* the certificate subject before accepting it -- whereby
ambiguity can be removed as much or as little as allowed for by the CA's CPS.
And, we need also to keep in mind that a CA's assurances in verifying any
data in a certificate may not be the assurances you need for your purposes.

Cheers,

Ed Gerck

Date: Tue, 23 Nov 1999 10:53:14 -0800
Subject: Re: NR Signing-Entity vs Certificate-Subject
From: "Aram Perez" <[email-masked]>
To: [email-masked]

Dave Kemp wrote:

> 
>> From: Ed Gerck <[email-masked]>
> 
>> 
>> >   Should we require that whatever definition we come up with for the
>> >   NR bit enable the checking of software applications for conformance
>> >   with the definition?
>>
>> Yes, trivially -- even if the definition cannot enable the checking of
>> software applications for conformance with the definition, as the CPS
>> definition does not allow, because not checking would be part of the
>> definition.
>
> If consensus were reached on this interpretation, then I would agree
> with those who suggest that the bit be deprecated, because the bit has
> no useful meaning if applications cannot be usefully checked for
> conformance.  Requiring that applications ignore the state of the bit,
> or act on the bit only in the context of some external and non-parsable
> information, is not a useful conformance specification.

Well stated Dave. That now makes three of us! Anyone else want to join the
"Deprecate NR or Bust" wagon?

;-)
Aram Perez

Date: Tue, 23 Nov 1999 10:50:01 -0800
To: "David P. Kemp" <[email-masked]>, [email-masked]
From: Tony Bartoletti <[email-masked]>
Subject: Re: NR Signing-Entity vs Certificate-Subject

At 10:45 AM 11/23/1999 -0500, David P. Kemp wrote:
>
>> From: "David P. Kemp" <[email-masked]>
>> 
>> > From: Tony Bartoletti <[email-masked]>
>> > 
>> > All,
>> > 
>> > Would it not be more "up front" to refer to the "signing entity"
>> > in the NR definition as the "certificate subject"?
>> > 
>> > Granted, in these circles it may seem to be another one of those
>> > "understood" things, but to common folk it might appear a bit
>> > disengenuous.
>> 
>> It would be disengenuous to refer to certificate subject.  "Signing
>> entity" or "keyholder" is the proper term, because an engineering
>> specification should not make claims it cannot enforce.
>
>To clarify, it would be disengenuous to refer to "the person named in
>the certificate".
>
>If by "certificate subject" you mean "the subject field of the
>certificate", I agree that there is a binding between the subject field
>and the public key field created by the CA signature, a mathematical
>correspondence between the public key and the private key, and a
>mathematical correspondence between the private key and the signature.
>So there is little difference between "signing entity" (possessor of
>the private key) and "subject field of the certificate".
>
>But there could be a significant difference between "signing entity"
>and "person named in the certificate", so you can't use the term
>"certificate subject" without saying whether you mean a DN or a
>person.  "signing entity" doesn't suffer from that ambiguity.

True.  But "signing entity" will be commonly construed to mean
"the person who effected the signature" (pushed the OK button).
It is precisely because an engineering specification should not
make claims it cannot enforce that I feel we should avoid giving
the impression that NR somehow targets the "active signer".

In contrast, the term "certificate subject" (yes, how to emphasize
we mean the "Name" and not the "Person"?) tends to reinforce the
notion that the "binding begins here", and all else must follow
from other artifacts.

___tony___ 

Tony Bartoletti                                             LL
IOWA Center                                              LL LL
Lawrence Livermore National Laboratory                LL LL LL
PO Box 808, L - 089                                   LL LL LL
Livermore, CA 94551-9900                              LL LL LLLLLLLL
phone: 925-422-3881   fax: 925-423-8081               LL LLLLLLLL
email: [email-masked]                                   LLLLLLLL

Date: Tue, 23 Nov 1999 13:21:48 -0500 (EST)
From: "David P. Kemp" <[email-masked]>
Reply-To: "David P. Kemp" <[email-masked]>
Subject: Re: NR Signing-Entity vs Certificate-Subject
To: [email-masked]
Content-MD5: ARSI8URk5DRAgbgo7FzZaw==

> From: Ed Gerck <[email-masked]>

> 
> >   Should we require that whatever definition we come up with for the
> >   NR bit enable the checking of software applications for conformance
> >   with the definition?
> 
> Yes, trivially -- even if the definition cannot enable the checking of
> software applications for conformance with the definition, as the CPS
> definition does not allow, because not checking would be part of the
> definition.

If consensus were reached on this interpretation, then I would agree
with those who suggest that the bit be deprecated, because the bit has
no useful meaning if applications cannot be usefully checked for
conformance.  Requiring that applications ignore the state of the bit,
or act on the bit only in the context of some external and non-parsable
information, is not a useful conformance specification.

> May this highlight the difficulty we have, because any definition
> for the NR bit MUST rely on factors outside the scope if X.509
> if we are willing to continue to accept the only conclusion that we
> so far unanimously agreed upon:
> 
>  The NR bit is neither necessary nor sufficient to provide
>  non-repudiation services.

Public key cryptography is neither necessary nor sufficient to provide
non-repudiation services.

PKIX is neither necessary nor sufficient to provide non-repudiation
services.

V3 certs with a critical keyUsage extension are neither necessary nor
sufficient to provide non-repudiation services.

So the conclusion is unanimously agreed to because it is trivially
true.  However, it has no meaning that can be used as a basis for
further reasoning.

The question to be answered is: "are there any application actions
which depend on the state of a single bit, can be specified in a
testable manner without reference to a CPS or other non-protocol
documentation, and which are useful in support of a system which
provides non-repudiation services?"

This is a weaker criterion than requiring that a keyUsage bit be
necessary (you can't provide non-repudiation services without that bit)
and sufficient (the bit guarantees the success of non-repudiation
services).

"Weaker", however, does not equate to "worthless" or "should be
deprecated".

Date: Tue, 23 Nov 1999 10:04:16 -0800
From: Ed Gerck <[email-masked]>
To: "[email-masked]" <[email-masked]>
Subject: signing entity in X.509

All:

The question has been called by Tony Bartoletti, whether "signing
entity" should be read (and, written) as "certificate subscriber" in one
of the definitions for non-repudiation (NR) found in X.509:

 nonRepudiation:  for verifying digital signatures used in providing
 a nonrepudiation service which protects against the signing entity
 falsely denying some action (excluding certificate or CRL signing,
 as in f) or g) below)

I wish to provide some of my conclusions on this, which may be
useful at this time.

There is a single occurrence of the words "signing entity" in X.509
and they occur only in that one definition for non-repudiation copied
above.  Since certificate or CRL signing are *excluded* from that NR
definition, the "signing entity" cannot be the CA.

Next, I recall that while X.509 focuses on defining a mechanism by
which information can be made available in a secure way to a third-party,
X.509 does not intend to address the level of effort which is needed
to validate the information in a certificate neither define a global
meaning to that information outside the CA's management acts.
The main purpose of a CA is to bind a public key to the name
contained in the certificate and thus assure third parties that some
measure of care was taken to ensure that this binding is valid for
both -- i.e., name and key. However, the issue whether a user's DN
actually corresponds to identity credentials that are linked to a
person or simply to an e-mail address -- and how such association
was verified --  is outside the scope of X.509 and depends on each
CA's self-defined CPS.  For X.509 quotes supporting these
conclusions, see [1].

In other words, X.509 deals with abstract and formally defined protocol
entities such as name and key, while the CPS is the interface between
such abstract entities and materially defined entities with flesh, blod,
nuts, bolts and legal papers such as persons, machines and companies.

Further, and this was a design choice of X.509, the very specification
how this interface is to be built and work is NOT given in X.509 but
left to the interface itself [2].  So, a CPS may assign a DN to a machine,
a person or a corporation in one-to-one, many-to-one, one-to-many,
many-to-many and even any-to-none combinations -- which DN becomes
then the entity called "certificate subject" in X.509.

So, "signing entity" as cited in one NR definition of X.509 could only be
an entity of X.509, not of the CPS (the world of persons and corporations).
Since it cannot be the CA (excluded in the NR definition), it can only be
the certificate subject.

Thus, it would be beneficial to deprecate the term "signing entity" in
X.509 and use "certificate subject", otherwise implementors and users
may labor under the misleading impression that X.509 deals with persons
or corporations in that regard -- it does not, it generally deals with
credentials and such credentials are quite arbitrarily defined in a CPS.

Comments are welcome.

Cheers,

Ed Gerck

-----------------------------
REFERENCES:

[1] Overview of Certification Systems, in http://www.mcg.org.br/cert.htm

[2]  For example, regarding validation procedures for the user's identity,
Section 11.2.a states that: "a certification authority shall be satisfied of t
he identity of a user before creating a certificate for it", which means that
identity validation procedures are to be satisfied in the CA's frame of
reference by following the CA's own self-defined rules (called CPS), which
are declared outside the scope of X.509 and can be entirely different for
different CAs. [1. ibid.]

Date: Tue, 23 Nov 1999 12:11:11 -0500
To: "[email-masked]" <[email-masked]>
From: Irene Gassko <[email-masked]>
Subject: Re: NR Signing-Entity vs Certificate-Subject

>So, retaining "signing entity" is to retain a dangling reference.  To use
>"keyholder" only makes sense in X.509 if it means the "certificate subject".
>So, why not call the thing by its name?  "Certificate subject" is all we can
>point our finger at -- and, if the certificate subject is NOT the only 
>keyholder
>then it is up to the certificate subject himself to deal with it,
certainly not
>the CA and certainly not X.509.
>

Here is the problem with this as I see it. Suppose that an enterprise generates
(private,public) key pairs for its employees and distributes certificates
to them.
As a result of a software bug the same key was put into certs of two different
persons. One of them signed a document and now claims that the other one
is the real signer. Unless we have a provision that NR==1 requires saving
a hash of a certificate used for authentication, how do we know who it was?
In this case, a "key holder" is the only word that covers both of them. But it 
seems that unless we add the hash requirement, none of the wordings will
be helpful in a such a situation. 

Irene

----------------------------------------------------------------------------
-------------------------------------------------------
Irene Gassko			 Bell Laboratories		http://www.lucent.com
Lucent Technologies		Secure Technologies Dept.
1600 Osgood Street			 phone:	(978) 960-5767
Room 30-2-A31			 e-mail: 	[email-masked]
N. Andover, MA 01845		 fax: 	(978) 960-3240

Date: Tue, 23 Nov 1999 08:38:35 -0800
From: Ed Gerck <[email-masked]>
To: "[email-masked]" <[email-masked]>
Subject: Re: Unknown private verisign extension

Peter Gutmann wrote:

> [cc'd to PKIX for comment]
>
> [email-masked] writes:
>
> >Included below is a exchange of E-Mails with verisign support. I recently
> >obtained a versign cert and found an undocumented private verisign extension
> >in it. It is obvious that I want to know what information is stored in that
> >extension. Verisign fails to give an sufficient answer.
>
> I've been trying to find out what 2.16.840.1.113733.1.6.3 and
> 2.16.840.1.113733.1.6.6 are, as well as what the policy qualifiers
> 2 16 840 1 113733 1 7 1 1 1 and 2 16 840 1 113733 1 7 1 1 2 mean, for some
> time now, but noone at Verisign will tell you.
>
> This leads to an interesting question: What are the semantics for these things?
> As far as anyone knows, the .1 policy could be "By using this certificate you
> agree to take full responsibility for any misuse of this certificate,
> regardless of what the CPS says" (which would be perfectly valid, since it's a
> policy qualifier), .2 might be "In the event of any dispute, Verisign is always
> right", .3 contains a copy of your private key encrypted with _NSAKEY :-), and
> who knows what .6 is.  Since the point of a CPS is that both the end entity and
> relying party can read it and know what they're getting, wouldn't the use of
> unpublished qualifiers and extensions which can modify the CPS destroy any
> possibility of reliance on the certs which contain them?

No, exactly because the terms are fully unknown and unkownable.  No one can
be bound by a private contract which he did not agree to, much less read.

By keeping it private, Verisign is making it safe for the subscriber -- whatever
it is.

Cheers,

Ed Gerck

Date: Tue, 23 Nov 1999 08:35:17 -0800
From: Ed Gerck <[email-masked]>
To: "[email-masked]" <[email-masked]>
Subject: Re: NR Signing-Entity vs Certificate-Subject

"David P. Kemp" wrote:

> > From: Tony Bartoletti <[email-masked]>
> >
> > All,
> >
> > Would it not be more "up front" to refer to the "signing entity"
> > in the NR definition as the "certificate subject"?
> >
> > Granted, in these circles it may seem to be another one of those
> > "understood" things, but to common folk it might appear a bit
> > disengenuous.
>
> It would be disengenuous to refer to certificate subject.  "Signing
> entity" or "keyholder" is the proper term, because an engineering
> specification should not make claims it cannot enforce.

Dave:

In engineering terms, the actor is the keyholder -- whoever that may be,
even more than one.  However, "signing entity" is not defined.  Further,
the keyholder is called the "certificate subject" in X.509.  So, the text
should not IMO go into a side track *in a definition*, and *there
alone in the entire spec*, introduce the "signing entity" out of X.509's
protoplasma ;-)

So, retaining "signing entity" is to retain a dangling reference.  To use
"keyholder" only makes sense in X.509 if it means the "certificate subject".
So, why not call the thing by its name?  "Certificate subject" is all we can
point our finger at -- and, if the certificate subject is NOT the only keyholder
then it is up to the certificate subject himself to deal with it, certainly not
the CA and certainly not X.509.

Any other presumption is thus IMO outside the scope of X.509 and might
belong in a CPS, but not in the engineering spec where we need to deal
with objectively qualified terms.

> The production of ephemeral/non-ephemeral evidence is essentially all
> the meaning you can cram into a single bit.

If the bit would be there to represent CRL lifetime.  This is not the case for the
NR bit (whatever that pesky bit may be) -- in an analogy, in order to fire a
bomb it makes sense to require an ephemeral authorization (the bomb is to
be fired now, not tomorrow)  that has a potentially ephemeral CRL listing,
but it also makes sense to require a non-repudiable authorization, one that
cannot be denied in the future (after the bomb exploded and after the
authorization expired).

Repudiation is not the same as expiration -- since repudiation of an act
negates the very existence of the act, whereas expiration only pertains
to the time window during which the act can be potentially applied.

So, the NR bit (as it is called, anyway) is there to prevent REPUDIATION
(as defined in X.509 -- the denial of some action), which has nothing to do
with LIFETIME (the time during which an authorization exists and can
be verified in a CRL).

>   Should we require that whatever definition we come up with for the
>   NR bit enable the checking of software applications for conformance
>   with the definition?
>
> My opinion is "yes".

Yes, trivially -- even if the definition cannot enable the checking of
software applications for conformance with the definition, as the CPS
definition does not allow, because not checking would be part of the
definition.

May this highlight the difficulty we have, because any definition
for the NR bit MUST rely on factors outside the scope if X.509
if we are willing to continue to accept the only conclusion that we
so far unanimously agreed upon:

 The NR bit is neither necessary nor sufficient to provide
 non-repudiation services.

even if the NR-bit would mean "non-ephemeral bit".

Cheers,

Ed Gerck

Date: Tue, 23 Nov 1999 10:45:51 -0500 (EST)
From: "David P. Kemp" <[email-masked]>
Reply-To: "David P. Kemp" <[email-masked]>
Subject: Re: NR Signing-Entity vs Certificate-Subject
To: [email-masked]
Content-MD5: GA0mr1RANSncdiNFwHP8Xg==

> From: "David P. Kemp" <[email-masked]>
> 
> > From: Tony Bartoletti <[email-masked]>
> > 
> > All,
> > 
> > Would it not be more "up front" to refer to the "signing entity"
> > in the NR definition as the "certificate subject"?
> > 
> > Granted, in these circles it may seem to be another one of those
> > "understood" things, but to common folk it might appear a bit
> > disengenuous.
> 
> It would be disengenuous to refer to certificate subject.  "Signing
> entity" or "keyholder" is the proper term, because an engineering
> specification should not make claims it cannot enforce.

To clarify, it would be disengenuous to refer to "the person named in
the certificate".

If by "certificate subject" you mean "the subject field of the
certificate", I agree that there is a binding between the subject field
and the public key field created by the CA signature, a mathematical
correspondence between the public key and the private key, and a
mathematical correspondence between the private key and the signature.
So there is little difference between "signing entity" (possessor of
the private key) and "subject field of the certificate".

But there could be a significant difference between "signing entity"
and "person named in the certificate", so you can't use the term
"certificate subject" without saying whether you mean a DN or a
person.  "signing entity" doesn't suffer from that ambiguity.

Date: Tue, 23 Nov 1999 07:34:08 -0800
From: Ed Gerck <[email-masked]>
To: Russ Housley <[email-masked]>
CC: [email-masked]
Subject: Re: MOTION ON NR

Russ Housley wrote:

> We just disagree....

Russ:

OK and, more than respect your opinion,
I think you are right that in some cases using
the qualifier "falsely" before "denying" may
make more sense.

And, that is why I suggest we abolish it
(along with some linting) because there
are cases where IMO it does not apply --
so, deleting "falsely" serves all cases
since it logically negates none.

For example, a specific NR service can
introduce the need to somehow verify
if the denial  is "false" before the
denial itself is technically verified --
thus, reintroducing the "falsely"
requirement.   Another NR service
might require that first the denial
itself be technically verified, before
somehow verifying if the denial seems
to be falsely or truthfully claimed.

This seems to me to be a quite even-handed
approach. Would this seem to be neutral to
you also?

Cheers,

Ed Gerck

From: [email-masked] (Peter Gutmann)
To: [email-masked]
Subject: Re: Unknown private verisign extension
Cc: [email-masked]
Sender: [email-masked]
Reply-To: [email-masked]
Date: Wed, 24 Nov 1999 04:20:01 (NZDT)

[cc'd to PKIX for comment]

[email-masked] writes:

>Included below is a exchange of E-Mails with verisign support. I recently
>obtained a versign cert and found an undocumented private verisign extension
>in it. It is obvious that I want to know what information is stored in that
>extension. Verisign fails to give an sufficient answer.

I've been trying to find out what 2.16.840.1.113733.1.6.3 and
2.16.840.1.113733.1.6.6 are, as well as what the policy qualifiers
2 16 840 1 113733 1 7 1 1 1 and 2 16 840 1 113733 1 7 1 1 2 mean, for some 
time now, but noone at Verisign will tell you.

This leads to an interesting question: What are the semantics for these things?
As far as anyone knows, the .1 policy could be "By using this certificate you
agree to take full responsibility for any misuse of this certificate,
regardless of what the CPS says" (which would be perfectly valid, since it's a
policy qualifier), .2 might be "In the event of any dispute, Verisign is always
right", .3 contains a copy of your private key encrypted with _NSAKEY :-), and
who knows what .6 is.  Since the point of a CPS is that both the end entity and
relying party can read it and know what they're getting, wouldn't the use of
unpublished qualifiers and extensions which can modify the CPS destroy any
possibility of reliance on the certs which contain them?

Peter.

Date: Tue, 23 Nov 1999 09:59:56 -0500 (EST)
From: "David P. Kemp" <[email-masked]>
Reply-To: "David P. Kemp" <[email-masked]>
Subject: Re: NR Signing-Entity vs Certificate-Subject
To: [email-masked]
Content-MD5: hUkSvMfJTtqqLjrThnRqaQ==

> From: Tony Bartoletti <[email-masked]>
> 
> All,
> 
> Would it not be more "up front" to refer to the "signing entity"
> in the NR definition as the "certificate subject"?
> 
> Granted, in these circles it may seem to be another one of those
> "understood" things, but to common folk it might appear a bit
> disengenuous.

It would be disengenuous to refer to certificate subject.  "Signing
entity" or "keyholder" is the proper term, because an engineering
specification should not make claims it cannot enforce.

The production of ephemeral/non-ephemeral evidence is essentially all
the meaning you can cram into a single bit.  All of the rest of the
things that go into a technical/social system to support NR, including
how strongly the certified identity is bound to an entity and how
strongly the private key is bound to the same entity (not to mention
the entity's "intentions" when creating a non-ephemeral signed object,
and whether the legal system will allow the entity to reverse the
charges on a check he can prove he did not sign) are beyond the scope
of a keyUsage bit as it can be acted upon by software.

The NR bit, when 1, should enable an application to sign a non-ephemeral
object, using whatever private key corresponds to the certificate.
The NR bit, when 0, should inhibit an application from signing non-ephemeral
data (except as allowed by the cert and CRL bits).

What additional claims could be placed into a protocol standard in a
manner such that applications could be tested for conformance with the
standard?

Paul claims that this seven month discussion is not converging.  As one
step towards convergence, I pose the question:

  Should we require that whatever definition we come up with for the
  NR bit enable the checking of software applications for conformance
  with the definition?

My opinion is "yes".

Date: Tue, 23 Nov 1999 09:18:21 -0500
To: "John C. Kennedy" <[email-masked]>
From: Russ Housley <[email-masked]>
Subject: RE: FIPS 186 and X9.42: One of these things is not like the other
Cc: <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>, "Elaine Barker" <[email-masked]>, "Sharon Keller" <[email-masked]>, "Simon Blake-Wilson" <[email-masked]>, "Phil Griffin" <[email-masked]>

John:

At 12:57 PM 11/22/99 -0800, John C. Kennedy wrote:
>1. With all due respect, saying that I have been "out of the loop" is not
>quite correct.  I have continued to track the output of both X9F1 and IETF
>with regards to X9.42 and DH for the last couple of years. I have copies
>of X9.42 drafts up through February 1999.  One does not have to be "in the
>loop" to see the inconsistencies I have pointed out.
>
>2. The PKIX "son-of-2459" work, of which mostly only the ASN.1 portion of
>X9.42 is relevant, is probably correct.  What is a bigger problem is that
>RFC 2631 (Diffie-Hellman Key Agreement Method) by Eric Rescorla references
>a 1998 draft. The related drafts, <draft-ietf-smime-small-subgroup-02.txt>
>and <draft-ietf-pkix-dhpop-02.txt>, reference RFC 2631.  Is there proper
>alignment in these works with the current state of X9.42?  I don't think
>so.  How would the larger IETF community know if they were?  Is ANSI
>keeping all these authors "in the loop"?
>
>3. FIPS 186-1 on DSA and rDSA is a good example.  If the X9.42
>specification had been kept as simple as FIPS 186 we wouldn't be where we
>are now.  It is unfortunate that crypto-politics and other machinations
>did not allow NIST to handle this work independent of ANSI from the
>beginning.

1.  I apologize.  You certainly have not taken an active role in the IETF 
or X9F1 for the last few years.  I am glad to hear that you have kept 
current.  I would encourage you to become actively involved again.

2.  Once the IETF adopted X9.42, I worked diligently with X9F1 to ensure 
that none of the aspects of X9.42 that were adopted by the IETF were 
changed.  We made a final comparison of the X9.42 draft and RFC 2631 just 
prior to publication of the RFC.  I have commitment that the parts of X9.42 
that are included in RFC 2631 will not be changed unless a security problem 
is discovered.  If a security problem is discovered, then the IETF will 
want to update RFC 2631 anyway, so this is not a concern.

3.  Agree.

Russ

Date: Tue, 23 Nov 1999 09:27:30 -0500
To: Tony Bartoletti <[email-masked]>
From: Russ Housley <[email-masked]>
Subject: Re: MOTION ON NR
Cc: Ed Gerck <[email-masked]>, "[email-masked]" <[email-masked]>, Nicholas Bohm <[email-masked]>

I do not mind if we substitute "certificate subject" for "signing entity".

Russ

At 02:08 PM 11/22/99 -0800, Tony Bartoletti wrote:
>At 02:44 PM 11/22/1999 -0500, Russ Housley wrote:
> >Tony:
> >
> >How is that any better than "... a service which protects against the
> >signing entity falsely denying some action."
> >
> >Russ
>
>Russ,
>
>Not much better!  Only helps to recognize that many moons ago, some of
>the NR threads asked the question "How can NR prevent me from denying...".
>Of course, nothing can prevent you from "issuing a denial".  Hence the
>wording above MUST interpret "protects against ... denying" to mean
>"protects against ... prevailing in a denial".  It does not alter
>the (untenably vague) meaning in the overall definition.
>
>Seriously, why not substitute "certificate subject" for "signing entity"?
>The so-called "signing entity" is nowhere an element of the certificate.
>
>And what is this "some action".  Why would it hurt to be a bit more
>precise.  Clearly, "some action" must be something authorized by the
>signature in question, as Irene Gassko wrote.  Perhaps this is just
>another one of the "its understood" things that too many of us don't
>seem to understand.
>
>Indeed, as I wrote several months ago, as a "signer", I might want NR
>myself:  Perhaps I am signing my patent submission.  If anyone later
>tries to deny (falsely, if you must) that I signed or submitted that
>patent, it would be a rival developer, not me.  So it seems that the
>current definition is biased in this regard.  It assumes only the
>(purported) signer might be restrained from "falsely denying some action".
>
>Just as surely, this NR service would
>
>    "protect the signer in truely affirming some action".
>
>Why is the current definition skewed in this regard.  The way it is
>worded, it is assumed that the only wronged party can be the RP.
>
>Now a difference of opinion exists between Ed Gerck, who maintains that
>NR should serve as a "trump card", that cares not whether the denial
>is true or false (sort of like the deductible you agree to pay anyway)
>and those who expect NR to simply (and neutrally) allow a trusted
>third party to hold/adjudicate over evidence.)  If we take the former
>position (NR hedges both true and false denials), then indeed the
>definition has the "right" to be skewed.  But if we intend NR to
>support the more neutral "independent evidentiary" service, then
>it should not be so skewed.
>
>___tony___
>
> >At 10:55 AM 11/22/99 -0800, Tony Bartoletti wrote:
> >>At 10:30 AM 11/22/1999 -0500, Russ Housley wrote:
> >> >I cannot support this direction.  You suggest:
> >> >
> >> >      1'. nonRepudiation:  for verifying digital signatures used in
> >> providing a
> >> >       service which protects against the signing entity  denying some
> >> action.
> >> >
> >> >The signer can always deny taking some action.  The point is having
> >> >evidence to refute the claim if it is false.
> >> >
> >> >Russ
> >>
> >>Of course.  I think we must all agree that we use the phrase "prevent a
> >>denial"
> >>to mean that we "prevent someone from prevailing in a denial".  If they 
> deny
> >>but lose, that's ok.
> >>
> >>I would accept "prevailing in a denial of some action" just to 
> eliminate one
> >>more point of argument (yes, insert laughter here.)
> >>
>
>
>Tony Bartoletti                                             LL
>IOWA Center                                              LL LL
>Lawrence Livermore National Laboratory                LL LL LL
>PO Box 808, L - 089                                   LL LL LL
>Livermore, CA 94551-9900                              LL LL LLLLLLLL
>phone: 925-422-3881   fax: 925-423-8081               LL LLLLLLLL
>email: [email-masked]                                   LLLLLLLL

Date: Tue, 23 Nov 1999 09:31:02 -0500
To: [email-masked]
From: Russ Housley <[email-masked]>
Subject: Re: MOTION ON NR
Cc: [email-masked]

Gene:

This implies that digitalSignature signatures cannot be retained.  I do not 
agree.  Using Denis Pinkas' usual authentication example: if a 
challenge-response protocol is used to open a door, then the entity that 
opens the door may retain the signed response as part of the audit log.

Russ

At 05:23 PM 11/22/99 -0500, [email-masked] wrote:

>Instead of all the legal-psychological speculation about the meaning of
>"denial", why not just say what it provides. IMO the critical distinction 
>for an
>NR key is that it is intended for persistent signature action *evidence* - not
>just for immediate (e.g. session establishment) *decisions.*    Accordingly, I
>suggest the following:
>
>1'. nonRepudiation:  for a digital signature verification key that may be used
>by a relying party to verify a digital signature, and retained as persistent
>evidence of a signer's signature action
>
>How far in the future an NR key is usable a matter of the issuer's archive
>policy and practices for the policy under which the certificate is issued, and
>any other arguments that one might want to make.
>
>-Gene Hilborn

Date: Tue, 23 Nov 1999 09:33:30 -0500
To: Paul Koning <[email-masked]>
From: Russ Housley <[email-masked]>
Subject: Re: MOTION ON NR
Cc: [email-masked]

Time and I had hoped to provide language that made everyone equally 
unhappy, yet everyone could live with it.  As you point out, the closure 
that we hoped for did not happen.

Russ

At 05:33 PM 11/22/99 -0500, Paul Koning wrote:
>I wonder if I'm the only one here who's getting the feeling that this
>discussion is, at best, divergent, and at worst, chaotic.  It very
>definitely doesn't look like it is heading towards any kind of
>closure.
>
>It certainly serves to reinforce my earlier opinion that the NR bit
>should be deprecated on the grounds that there is no possible
>consensus on whether it has any meaning, much less what that meaning
>is.
>
>         paul

Date: Tue, 23 Nov 1999 09:25:47 -0500
To: Ed Gerck <[email-masked]>
From: Russ Housley <[email-masked]>
Subject: Re: MOTION ON NR
Cc: [email-masked]

We just disagree....

Russ

At 02:02 PM 11/22/99 -0800, Ed Gerck wrote:

>Russ Housley wrote:
>
> > Tony:
> >
> > How is that any better than "... a service which protects against the
> > signing entity falsely denying some action."
>
>Russ:
>
>Because wheter the denial is false or truthful is irrelevant to the protocol.
>The signer may be 100% truthful  in that he did not sign and yet the NR
>system in place, which the signer accepted beforehand (in order for
>example to be able to have his checks accepted without paying/delaying
>for a live confirmation for each check), will still provide the risk-bearer
>with a tool to prevent the denial of a signature that did not look like
>a signature that the signer did NOT make (negative logic is necessary
>here).
>
>However, writing
>
>1'a. nonRepudiation:  for verifying digital signatures used in
>providing a   service which protects against the signing entity
>prevailing when denying some action.
>
>seems to me to be an "explanation mode" definition, which explanation
>could be provided in a short comment.  The same applies to
>
>1'b. nonRepudiation:  for verifying digital signatures used in
>providing a  service which protects against the signing entity
>prevailing when denying actions authenticated by that signature.
>
>since the "actions" are NR-specific actions that  may (or,
>may not) directly depend on the signature. This can be likewise
>explained in a short comment, where one must carefully restrict it to
>NR service specified actions -- e.g., possibly NOT including:
>
>-- actions based on semantic content of the signed message itself;
>-- all actions that can be possibly derived from that signature;
>-- the signature itself  (desired may be only non-repudiation of a
>      time stamp, for example),
>-- etc.
>
>or, possibly including ANY or even ALL the above.
>
>That is why IMO the definition
>
>1'. nonRepudiation:  for verifying digital signatures used in
>providing a  service which protects against the signing entity
>denying some action.
>
>could be useful, since its eventually dubious aspects are few
>and they can be explained by *short* expanding notes from the
>root concept of "some actions", to wit:
>
>i. The words "some action" mean specific actions protected by
>the service, and may include any aspect of a digital signature
>including its signed content.
>
>ii. The words "the signing entity denying some action"  mean
>the signing entity denying the action itself after the action.
>
>iii. The signing entity may always deny some action at any time.
>
>iv. The words "protects against the signing entity denying some
>action" mean that the service intends to prevent the signing
>entity from prevailing in a denial of some action, as qualified in
>(i) and (ii), to some degree. The signing entity must however
>always be sucessful in denying some action before the action.
>
>v. The words "verifying digital signatures used in providing
>a  service" mean that a service boundary is defined when
>verifying  digital signatures, which service boundary may
>nonetheless vary from service to service.  The service
>boundary is a conceptual (though it may also be physical)
>limit.  It is irrelevant to the service whether the denial of some
>action is false or truthful outside the service boundary.
>
>Comments?
>
>Cheers,
>
>Ed Gerck

Date: Tue, 23 Nov 1999 14:18:38 +0100 (W. Europe Standard Time)
From: Magnus Nystrom <[email-masked]>
Reply-To: [email-masked]
To: Jyri =?iso-8859-1?Q?T=E4htinen?= <[email-masked]>
cc: Stefan Santesson <[email-masked]>, [email-masked], Ella Paton Bassett <[email-masked]>, [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked]
Subject: Re: We have to choose serialNumber instead of dnQualifier  NOW!!!

On Tue, 23 Nov 1999, Jyri Tähtinen wrote:

> Magnus Nystrom wrote:

[...] 
> > There's just one problem: The object identifier is really long (and
> > invalid).
> 
> I don't know whether the length of OID is a real problem (except for
> human readers ;-)

It could be a problem in resource-constrained environments (space,
bandwidth) since certificates containing such OIDs will tend to be
unnecessary long.
 
> I am not ASN.1 expert and therefore can not say how the OID is invalid,
> but at least these OIDs are widely in use. 
> 
> For example, email address, LDAP v3 attribute type mail = LDAP v2
> rfc822Mailbox is pilotAttributeType.3 (OID 0.9.2342.19200300.100.1.3 ).

I know, but a second-level branch of 9 is not defined. The branch 0 9 was,
citing the editor of X.680/ISO 8824-1 "hi-jacked" by IETF. But this is
another story however.

-- Magnus

Date: Tue, 23 Nov 1999 14:46:46 +0200
From: Jyri =?iso-8859-1?Q?T=E4htinen?= <[email-masked]>
Organization: Helsinki Telephone Corporation, Kolumbus Services
To: [email-masked]
CC: Stefan Santesson <[email-masked]>, [email-masked], Ella Paton Bassett <[email-masked]>, [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked]
Subject: Re: We have to choose serialNumber instead of dnQualifier  NOW!!!

Magnus Nystrom wrote:
> 
> I basically agree with the comments from Finland. Reading through RFC
> 1274, it appears to me as if uniqueIdentifier would be
> an excellent choice - no need to redefine semantics for existing
> attributes with unknown effects, good semantics and syntax from the start.

Unfortunately in Finland we did not have time to wait for this
discussion to end, but we had to make decision this morning. (Anyway, I
feel that uniqueIdentifier would be the best candidate for the UID
usage, at least better than both serialNumber and dnQualifier.)

We chose to use serialNumber attribute type in certificate
subject name to store unique identifier (like the FINUID number). The
reasons for this were that dnQualifier seemed to be impossible solution
and serialNumber is in use at least in Germany. Other choices were not
considered practical at this moment (software support etc.).

For storing certificate serial number in LDAP directory, we will specify
a new
attribute type certificateSerialNumber (from fineidAttributeType OID
tree) with PrintableString syntax. That will be presented in FINEID S5
specs.

If there will be in future a better standardized solution provided by
PKIX working group, we may choose to follow that later on. Of course,
with a large amount of distributed certificates, it may not be so easy
to change specifications on the run.

> There's just one problem: The object identifier is really long (and
> invalid).

I don't know whether the length of OID is a real problem (except for
human readers ;-)

I am not ASN.1 expert and therefore can not say how the OID is invalid,
but at least these OIDs are widely in use. 

For example, email address, LDAP v3 attribute type mail = LDAP v2
rfc822Mailbox is pilotAttributeType.3 (OID 0.9.2342.19200300.100.1.3 ).

regards,

Jyri

> 
> -- Magnus
> 
> On Mon, 22 Nov 1999, Stefan Santesson wrote:
> 
> > Good,
> >
> > We have a dialogue here. I don't think the Finnish case is lost, but it is
> > urgent. They will have a meeting tomorrow morning and they now ask why we
> > don't use the unique identifier attribute from rfc 1274. I supply the mail
> > from Jyri Tähtinen below:
> >
> > I remember that we considered this attribute a long time ago in the Swedish
> > EID project but that we abandoned it for some reason.
> >
> > /Stefan
> >
> > At 02:50 PM 11/22/99 +0200, Jyri Tähtinen wrote:
> > >Dear Mr. Santesson, cc: FINEID people
> > >
> > >I think Vesa Vatka and Ari Saapunki have been in touch with you in this
> > >dNQualifier va serialNumber issue.
> > >
> > >My question is:
> > >
> > >- why don't PKIX people specify uniqueIdentifier (PilotAttributeType.44)
> > >for storage of uniquely identifying data? This attribute should be
> > >widely known (from rfc1274) and it has directory string syntax.
> > >
> > >(Of course there can be a problem, if client software don't understand
> > >this attribute type which is part of subject name...)
> > >
> > >- the serialNumber attribute type is not good, because
> > >
> > >a. it already identifies also the certificate serial number in
> > >directory! The certificates are stored in directory and named with cert.
> > >serialnumber.
> > >I have quoted below part of a message from you (that Markku Kontio
> > >forwarded to me).
> > >
> > >b. it is more related to devices than subjects of certification
> > >
> > >By the way, do you have suggestions which attribute to use for
> > >certificate serialNumber if you use serial number for UID?
> > >Should we define new attribute type certificateSerialNumber or something
> > >like that?
> > >
> > >Anyway, it would be wise to use same attributes in certificate and in
> > >directory - otherwise there is big risk of misunderstandings. (If UID is
> > >stored in serialNumber in certificate but in directory serialNumber is
> > >used to store cert.serial number!)
> > >
> > >> After all mails so far I must say that the current status of my
> > >> understanding is that we use the dnQualifier attribute wrong, if we use it
> > >> for this purpose.
> > >>
> > >> That's the first thing we must agree on. Can we do that?
> > >>
> > >> The second is what we should do about it. We have some choices.
> > >>
> > >> 1) To continue to use dnQualifier even though we break it's intended
> > purpose
> > >> 2) To use another existing X.520 attribute (serialNumber or UID)
> > >> 3) To find another suitable attribute, defined by someone else
> > >> 4) To define a new attribute.
> > >
> > >I suggest choice nr 3 and the solution would be from RFC1274:
> > >
> > >9.3.34.  Unique Identifier
> > >
> > >   The Unique Identifier attribute type specifies a "unique identifier"
> > >   for an object represented in the Directory.  The domain within which
> > >   the identifier is unique, and the exact semantics of the identifier,
> > >   are for local definition.  For a person, this might be an
> > >   institution-wide payroll number.  For an organisational unit, it
> > >   might be a department code.
> > >
> > >     uniqueIdentifier ATTRIBUTE
> > >         WITH ATTRIBUTE-SYNTAX
> > >             caseIgnoreStringSyntax
> > >             (SIZE (1 .. ub-unique-identifier))
> > >     ::= {pilotAttributeType 44}
> > >
> > >
> > >Could you comment on that as soon as possible, please!
> > >
> > >We will have a meeting on this issue early on Tuesday morning.
> > >
> > >Regards,
> > >
> > >Jyri Tähtinen
> > >
> > >--
> > > --------------------------------  - - - - - - - - - - - - - - - - - - -
> > >  J y r i   T ä h t i n e n        Development Manager, M.Sc.
> > >
> > >  Helsinki Telephone Corporation   Telephone    +358 9 606 4546
> > >  Kolumbus Services                Mobile phone +358 50 5666599
> > >  Asemapäällikönkatu 2 (PAD510)    Fax          +358 9 606 3290
> > >  P.O.Box 133                      E-mail       [email-masked]
> > >  FIN-00521 HELSINKI               <PGP available on request>
> > > --------------------------------  - - - - - - - - - - - - - - - - - - -
> >
> >
> >
> > At 01:40 PM 11/22/99 +0100, Magnus Nystrom wrote:
> > >
> > >Taking advantage of the timezone difference to be the first to
> > >respond...;)
> > >
> > >I must say I am a bit reluctant to choose a long-term solution because of
> > >short-term time constraints in this case. Finland is, in my view, a "lost
> > >case" anyway, our decision won't affect them much right now anyway. What
> > >says "There is no time to define a new attribute"? Better to think this
> > >through properly and let everyone express their view than to rush
> > >something which may not be the optimal solution.
> > >
> > >As I previously stated, I am not too convinced serialNumber is the best
> > >alternative. Squeezing in new semantics in an existing attribute may cause
> > >more problems than it solves. Since any change in the semantics of
> > >serialNumber will affect X.520, it ought to affect X.521 (e.g. the
> > >'person' object class) as well. I guess one possibility is to re-name
> > >serialNumber as well, to something more declarative, like "uniqueNumber"
> > >or similar, but it would be just as easy to define a new attribute - X.520
> > >and X.521 will have to change anyway if they are to support this at all.
> > >Note: I am not saying I object to this proposal, just that I think we need
> > >some more time.
> > >
> > >Regards,
> > >-- Magnus
> > >Magnus Nystrom               Email: [email-masked]
> > >RSA Laboratories
> > >
> > >On Mon, 22 Nov 1999, Stefan Santesson wrote:
> > >
> > >> All,
> > >>
> > >> Regarding the issue to select an attribute type for storage of personal
> > >> identifiers of certificate subjects.
> > >>
> > >> Finland's national electronic identity project starts FULL production in 2
> > >> weeks, where they will  issue certificates to the people of Finland in a
> > >> large scale.
> > >>
> > >> They need to know TODAY, what attribute type they should use to store
> > >> electronic identity numbers of Finnish citizens.
> > >>
> > >> - I think the latest discussions have shown that dnQualifier is out of the
> > >> picture.
> > >>
> > >> - UID is useless because of the bit string syntax.
> > >>
> > >> - There is no time to define a new attribute.
> > >>
> > >> So they will have to go with serialNumber. A big reason for this is also
> > >> that the Germans have decided to go with the serialNumber attribute as
> > >> well. So now Finland and Germany will at least be compliant.
> > >>
> > >>
> > >> So folks, as I see this we have no choice other than to support
> > >> serialNumber at this moment.
> > >>
> > >> I suggest that we:
> > >>
> > >> - Add serialNumber to son of rfc2459 supportedAttributes as a MUST
> > >> implement attribute (i.e. compliant applications MUST be able to understand
> > >> it).
> > >>
> > >> - Keep dnQualifier in son of rfc2459, with a note stating it's intended
> > >> purpose, the fact that new certificates should not break this intended
> > >> usage, and also saying that clients should expect that some existing
> > >> certificates may use this attribute to hold any type of value.
> > >>
> > >> - specify use of serialNumber but NOT dnQualifier in the Qualified
> > >> Certificates profile.
> > >>
> > >> It would help to get your immediate support for this. Can you live with it??
> > >>
> > >> /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
> > -------------------------------------------------------------------
> >
> 
> -- Magnus
> Magnus Nystrom          Email: [email-masked]
> RSA Laboratories

-- 
 --------------------------------  - - - - - - - - - - - - - - - - - - -
  J y r i   T ä h t i n e n        Development Manager, M.Sc.
 
  Helsinki Telephone Corporation   Telephone    +358 9 606 4546
  Kolumbus Services                Mobile phone +358 50 5666599
  Asemapäällikönkatu 2 (PAD510)    Fax          +358 9 606 3290 
  P.O.Box 133                      E-mail       [email-masked]
  FIN-00521 HELSINKI               <PGP available on request>
 --------------------------------  - - - - - - - - - - - - - - - - - - -

Date: Tue, 23 Nov 1999 13:28:43 +0200
From: Jyri =?iso-8859-1?Q?T=E4htinen?= <[email-masked]>
Organization: Helsinki Telephone Corporation, Kolumbus Services
To: Juergen Brauckmann <[email-masked]>
CC: [email-masked]
Subject: Re: We have to choose serialNumber instead of dnQualifier NOW!!!

Juergen Brauckmann wrote:
> 
> >> At 02:50 PM 11/22/99 +0200, Jyri Tähtinen wrote:
> >> >Dear Mr. Santesson, cc: FINEID people
> >> >- the serialNumber attribute type is not good, because
> >> >
> >> >a. it already identifies also the certificate serial number in
> >> >directory! The certificates are stored in directory and named with cert.
> >> >serialnumber.
> 
> Jyri,
> 
> I think you are wrong here, because the attribute we talk about is a part
> of the certificate DN and has not necessarily something to do with the
> serialnumber of the certificate itself in the directory. 

True. But in our implementation it is so that I stated.

>And I believe that
> it's not correct to use the X.520 serialNumber Attribute for storing
> certificate serial numbers in a X.500 directory. 

Well, that's the way how it is implemented now in FINEID system. But we
will change this.

>The two serial"numbers"
> even don't have the same type (printableString for X.520 serialNumber,
> Integer for X.509 certificate serial number). Please correct me if this is
> wrong... .

You're right, but it also seems that there is no other standard based
solution for storing cert serial numbers in LDAP directory. If you know
one, please tell me!

(And Printable string syntax can contain numbers/integers, so that
attribute type can be used for storing certificate serial numbers.)

However, we had to make a quick decision this morning.

The result was that we will use serialNumber attribute in certificate
subject name to store unique identifier like the FINUID number. And for
storing certificate serial number in directory, we will specify a new
attribute type certificateSerialNumber (from fineidAttributeType OID
tree) with PrintableString syntax.

Regards,

Jyri

> 
> Regards,
>     Juergen
> 
> --
> Juergen Brauckmann             Tel.:  040 / 8080 26 311
> TC Trust Center GmbH           Fax.:  040 / 8080 26 126
> Sonninstraße 24-28          mailto:[email-masked]
> 20097 Hamburg               http://www.trustcenter.de

-- 
 --------------------------------  - - - - - - - - - - - - - - - - - - -
  J y r i   T ä h t i n e n        Development Manager, M.Sc.
 
  Helsinki Telephone Corporation   Telephone    +358 9 606 4546
  Kolumbus Services                Mobile phone +358 50 5666599
  Asemapäällikönkatu 2 (PAD510)    Fax          +358 9 606 3290 
  P.O.Box 133                      E-mail       [email-masked]
  FIN-00521 HELSINKI               <PGP available on request>
 --------------------------------  - - - - - - - - - - - - - - - - - - -

Date: Tue, 23 Nov 1999 10:40:12 +0100
To: [email-masked], [email-masked]
From: Juergen Brauckmann <[email-masked]>
Subject: Re: We have to choose serialNumber instead of dnQualifier  NOW!!!

>> At 02:50 PM 11/22/99 +0200, Jyri Tähtinen wrote:
>> >Dear Mr. Santesson, cc: FINEID people
>> >- the serialNumber attribute type is not good, because
>> >
>> >a. it already identifies also the certificate serial number in
>> >directory! The certificates are stored in directory and named with cert.
>> >serialnumber.

Jyri,

I think you are wrong here, because the attribute we talk about is a part
of the certificate DN and has not necessarily something to do with the
serialnumber of the certificate itself in the directory. And I believe that
it's not correct to use the X.520 serialNumber Attribute for storing
certificate serial numbers in a X.500 directory. The two serial"numbers"
even don't have the same type (printableString for X.520 serialNumber,
Integer for X.509 certificate serial number). Please correct me if this is
wrong... .

Regards,
    Juergen

-- 
Juergen Brauckmann             Tel.:  040 / 8080 26 311
TC Trust Center GmbH           Fax.:  040 / 8080 26 126
Sonninstraße 24-28   	    mailto:[email-masked]
20097 Hamburg 		    http://www.trustcenter.de	

Date: Tue, 23 Nov 1999 10:01:15 +0100 (W. Europe Standard Time)
From: Magnus Nystrom <[email-masked]>
Reply-To: [email-masked]
To: Stefan Santesson <[email-masked]>
cc: [email-masked], Ella Paton Bassett <[email-masked]>, [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked]
Subject: Re: We have to choose serialNumber instead of dnQualifier  NOW!!!

I basically agree with the comments from Finland. Reading through RFC
1274, it appears to me as if uniqueIdentifier would be 
an excellent choice - no need to redefine semantics for existing
attributes with unknown effects, good semantics and syntax from the start.
There's just one problem: The object identifier is really long (and
invalid).

-- Magnus

On Mon, 22 Nov 1999, Stefan Santesson wrote:

> Good,
> 
> We have a dialogue here. I don't think the Finnish case is lost, but it is
> urgent. They will have a meeting tomorrow morning and they now ask why we
> don't use the unique identifier attribute from rfc 1274. I supply the mail
> from Jyri Tähtinen below:
> 
> I remember that we considered this attribute a long time ago in the Swedish
> EID project but that we abandoned it for some reason.
> 
> /Stefan
> 
> At 02:50 PM 11/22/99 +0200, Jyri Tähtinen wrote:
> >Dear Mr. Santesson, cc: FINEID people
> >
> >I think Vesa Vatka and Ari Saapunki have been in touch with you in this
> >dNQualifier va serialNumber issue.
> >
> >My question is:
> >
> >- why don't PKIX people specify uniqueIdentifier (PilotAttributeType.44)
> >for storage of uniquely identifying data? This attribute should be
> >widely known (from rfc1274) and it has directory string syntax.
> >
> >(Of course there can be a problem, if client software don't understand
> >this attribute type which is part of subject name...)
> >
> >- the serialNumber attribute type is not good, because
> >
> >a. it already identifies also the certificate serial number in
> >directory! The certificates are stored in directory and named with cert.
> >serialnumber.
> >I have quoted below part of a message from you (that Markku Kontio
> >forwarded to me).
> >
> >b. it is more related to devices than subjects of certification
> >
> >By the way, do you have suggestions which attribute to use for
> >certificate serialNumber if you use serial number for UID?
> >Should we define new attribute type certificateSerialNumber or something
> >like that?
> >
> >Anyway, it would be wise to use same attributes in certificate and in
> >directory - otherwise there is big risk of misunderstandings. (If UID is
> >stored in serialNumber in certificate but in directory serialNumber is
> >used to store cert.serial number!)
> >
> >> After all mails so far I must say that the current status of my 
> >> understanding is that we use the dnQualifier attribute wrong, if we use it 
> >> for this purpose. 
> >>
> >> That's the first thing we must agree on. Can we do that? 
> >>
> >> The second is what we should do about it. We have some choices. 
> >>
> >> 1) To continue to use dnQualifier even though we break it's intended
> purpose 
> >> 2) To use another existing X.520 attribute (serialNumber or UID) 
> >> 3) To find another suitable attribute, defined by someone else 
> >> 4) To define a new attribute. 
> >
> >I suggest choice nr 3 and the solution would be from RFC1274:
> >
> >9.3.34.  Unique Identifier
> >
> >   The Unique Identifier attribute type specifies a "unique identifier"
> >   for an object represented in the Directory.  The domain within which
> >   the identifier is unique, and the exact semantics of the identifier,
> >   are for local definition.  For a person, this might be an
> >   institution-wide payroll number.  For an organisational unit, it
> >   might be a department code.
> >
> >     uniqueIdentifier ATTRIBUTE
> >         WITH ATTRIBUTE-SYNTAX
> >             caseIgnoreStringSyntax
> >             (SIZE (1 .. ub-unique-identifier))
> >     ::= {pilotAttributeType 44}
> >
> >
> >Could you comment on that as soon as possible, please!
> >
> >We will have a meeting on this issue early on Tuesday morning.
> >
> >Regards,
> >
> >Jyri Tähtinen
> >
> >-- 
> > --------------------------------  - - - - - - - - - - - - - - - - - - -
> >  J y r i   T ä h t i n e n        Development Manager, M.Sc.
> > 
> >  Helsinki Telephone Corporation   Telephone    +358 9 606 4546
> >  Kolumbus Services                Mobile phone +358 50 5666599
> >  Asemapäällikönkatu 2 (PAD510)    Fax          +358 9 606 3290 
> >  P.O.Box 133                      E-mail       [email-masked]
> >  FIN-00521 HELSINKI               <PGP available on request>
> > --------------------------------  - - - - - - - - - - - - - - - - - - -
> 
> 
> 
> At 01:40 PM 11/22/99 +0100, Magnus Nystrom wrote:
> >
> >Taking advantage of the timezone difference to be the first to
> >respond...;)
> >
> >I must say I am a bit reluctant to choose a long-term solution because of
> >short-term time constraints in this case. Finland is, in my view, a "lost
> >case" anyway, our decision won't affect them much right now anyway. What
> >says "There is no time to define a new attribute"? Better to think this
> >through properly and let everyone express their view than to rush
> >something which may not be the optimal solution.
> >
> >As I previously stated, I am not too convinced serialNumber is the best
> >alternative. Squeezing in new semantics in an existing attribute may cause
> >more problems than it solves. Since any change in the semantics of
> >serialNumber will affect X.520, it ought to affect X.521 (e.g. the
> >'person' object class) as well. I guess one possibility is to re-name
> >serialNumber as well, to something more declarative, like "uniqueNumber"
> >or similar, but it would be just as easy to define a new attribute - X.520
> >and X.521 will have to change anyway if they are to support this at all.
> >Note: I am not saying I object to this proposal, just that I think we need
> >some more time.
> >
> >Regards,
> >-- Magnus
> >Magnus Nystrom		Email: [email-masked]
> >RSA Laboratories
> >
> >On Mon, 22 Nov 1999, Stefan Santesson wrote:
> >
> >> All,
> >> 
> >> Regarding the issue to select an attribute type for storage of personal
> >> identifiers of certificate subjects.
> >> 
> >> Finland's national electronic identity project starts FULL production in 2
> >> weeks, where they will  issue certificates to the people of Finland in a
> >> large scale.
> >> 
> >> They need to know TODAY, what attribute type they should use to store
> >> electronic identity numbers of Finnish citizens.
> >> 
> >> - I think the latest discussions have shown that dnQualifier is out of the
> >> picture.
> >> 
> >> - UID is useless because of the bit string syntax.
> >> 
> >> - There is no time to define a new attribute.
> >> 
> >> So they will have to go with serialNumber. A big reason for this is also
> >> that the Germans have decided to go with the serialNumber attribute as
> >> well. So now Finland and Germany will at least be compliant.
> >> 
> >> 
> >> So folks, as I see this we have no choice other than to support
> >> serialNumber at this moment.
> >> 
> >> I suggest that we:
> >> 
> >> - Add serialNumber to son of rfc2459 supportedAttributes as a MUST
> >> implement attribute (i.e. compliant applications MUST be able to understand
> >> it).
> >> 
> >> - Keep dnQualifier in son of rfc2459, with a note stating it's intended
> >> purpose, the fact that new certificates should not break this intended
> >> usage, and also saying that clients should expect that some existing
> >> certificates may use this attribute to hold any type of value.
> >> 
> >> - specify use of serialNumber but NOT dnQualifier in the Qualified
> >> Certificates profile.
> >> 
> >> It would help to get your immediate support for this. Can you live with it??
> >> 
> >> /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
> -------------------------------------------------------------------
> 

-- Magnus
Magnus Nystrom		Email: [email-masked]
RSA Laboratories

From: "Gary W. Seehousz" <[email-masked]>
To: "[email-masked]'" <[email-masked]>
Subject: unsubscribe
Date: Mon, 22 Nov 1999 21:36:52 -0500

unsubscribe

Date: Mon, 22 Nov 1999 18:39:07 -0800
To: [email-masked]
From: Tony Bartoletti <[email-masked]>
Subject: Re: MOTION ON NR
Cc: "[email-masked]" <[email-masked]>, [email-masked], Ed Gerck <[email-masked]>, Tim Polk <[email-masked]>

At 05:23 PM 11/22/1999 -0500, you wrote:
>
>
>Instead of all the legal-psychological speculation about the meaning of
>"denial", why not just say what it provides. IMO the critical distinction for an
>NR key is that it is intended for persistent signature action *evidence* - not
>just for immediate (e.g. session establishment) *decisions.*    Accordingly, I
>suggest the following:
>
>1'. nonRepudiation:  for a digital signature verification key that may be used
>by a relying party to verify a digital signature, and retained as persistent
>evidence of a signer's signature action
>
>How far in the future an NR key is usable a matter of the issuer's archive
>policy and practices for the policy under which the certificate is issued, and
>any other arguments that one might want to make.
>
>-Gene Hilborn

Gene,

I think "retained as evidence" is appropriate.  But as (I believe it was)
Ed Gerck who pointed out, there may be applications that require NR for
only the "short term", while others that may arbitrarily decide to have
even NR=0 transactions "notarized in perpetuity" for auditing purposes.

This is just to point out that "long-term vs short-term" is not
(necessarily) the issue.  But perhaps "ephemeral vs evidentiary" is,
where these refer not to length-of-time, but rather "secure retention"
(or not) for any length of time.

Should we not ask what this NR bit is supposed to be saying to:

  1.  The certificate subject (purchaser)
  2.  The relying party
  3.  The CA
  4.  The software folk writing "compliant" products?

Oops.  I almost left out:

  5.  The "Signing Entity", for which NR=1 says "the owner of this
      key is gonna be in REAL trouble when I get through using this."

(I agree with Ed, that any distinction between "signer" and "cert subject"
lies outside of the certification process, so is generally meaningless in
any key usage definitions.  I, too, vote for certificate subject.)

My thought:  If the RP needs to have transactions archived as evidence,
then what is to stop them?  And why should the NR bit be of any special
value to them?  Why should a court of law say that you are "more liable"
because the cert you SUPPOSEDLY own, and whose key you SUPPOSEDLY used,
had its NR-bit set ON?  What it it supposed to be evidence of, and why
is such evidence to be believed?

In a certificate, NR=1 is indeed evidence that its value was NR=1
at the time the certificate was created.  Someone please chime in
with whatever else it is intended to be evidence of.

It seems absurd to me that this bit is intended to be a flag to
applications that they should "archive this transaction as NR".
As if the application does not know a-priori the type of
transaction it is currently processing!  So the only other use
is to have applications that already know they are processing
(NR/non-NR) transactions use the value to demand certs of a
particular NR setting.

But again, why?  Why should the processor of NR-transactions care,
no less require, NR=1 certified keys?  Perhaps there is a better
argument for why the processor of non-NR-transactions would demand
NR=0 certificates, or care.... I mean Really Care.

Someone, please, explain. 

___tony___

Tony Bartoletti                                             LL
IOWA Center                                              LL LL
Lawrence Livermore National Laboratory                LL LL LL
PO Box 808, L - 089                                   LL LL LL
Livermore, CA 94551-9900                              LL LL LLLLLLLL
phone: 925-422-3881   fax: 925-423-8081               LL LLLLLLLL
email: [email-masked]                                   LLLLLLLL

Date: Mon, 22 Nov 1999 17:33:06 -0800
To: [email-masked]
From: Tony Bartoletti <[email-masked]>
Subject: Re: NR Signing-Entity vs Certificate-Subject
Cc: "[email-masked]" <[email-masked]>

At 06:37 PM 11/22/1999 -0500, you wrote:

(pardon me if I break the first paragraph into two parts.)

>     The main reason for using "signing entity" here is that if the named
>certificate subject can PROVE that he was not the signing entity he may
>well not be held responsible.

OK, suppose I PROVE that I (true-cert-owner) was NOT the signing entity.

In which case, the "signing entity" was "Mr. Else".  So the description

  "prevent the signing entity from falsely denying some actions"

would seem to imply that NR helps to prevent this "Mr. Else" from
falsely denying HIS role.  But of course it does not.

In essence, its real meaning is "prevents the cert-subject from denying
they are the signing entity unless (perhaps) they can prove otherwise."

Or perhaps "places burden of proof upon the cert subject upon their
denial of signature (authenticity, liability, actuality, pick any)."

In any case, a full explanation involves the term "cert-subject" at
some point, and this is missing, IMO.  It treats "signing entity" as
a nebulous quantity.  Is it the OK-button-pusher?  Is it the party
who willfully unlocked the signing key, but turned away while his
mischevious cat stepped on the OK-send button?  Where is the term
"signing entity" defined with any particular care in this regard?

Especially, does NR=1 trigger some assumption about the *identity*
of the "signing entity" that NR=0 does not?
  
>If he can prove that the certificate was
>issued to someone else as a result of a masquerade he probably will not be
>held responsible.

That sounds fairly difficult!  If its as easy to get other folks credentia
are we are led to believe (credit card receipts, credit reports, etc) and
someone doesn't like you, they fraudulently obtain a NR-cert/key in your
name, and proceed to bind you in knots.  It would seem that NR serves them
very nicely.

>     However, it is worth reiterating that there are only two basic ways
>for the law to treat the question of whether the certificate subject is the
>signing entity: in the first, the certificate subject must prove that he
>was not the signing entity; and in the second, where the relying party must
>prove that the certificate subject was the signing entity, the NR service
>is not likely to be of much use.

But is that not precisely its intended use?  That is, to place the burden
of proof on the cert-subject to show they were:

(a) not the certOwnerInFact (nor the signer), in case of cert fraud, or
(b) not the signer, in case of key compromise or even carelessness?

Is the burden suddenly shifted to the RP because the (supposed) cert
subject proclaims "I never requested/obtained that cert"?  Sounds too
easy.

___tony___

>     That particular program would be better off asking for a PIN.
>
>          Tom Gindin

Tony Bartoletti                                             LL
IOWA Center                                              LL LL
Lawrence Livermore National Laboratory                LL LL LL
PO Box 808, L - 089                                   LL LL LL
Livermore, CA 94551-9900                              LL LL LLLLLLLL
phone: 925-422-3881   fax: 925-423-8081               LL LLLLLLLL
email: [email-masked]                                   LLLLLLLL

Date: Mon, 22 Nov 1999 17:31:15 -0800
From: Ed Gerck <[email-masked]>
To: [email-masked]
CC: Tony Bartoletti <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: NR Signing-Entity vs Certificate-Subject

[email-masked] wrote:

>    The main reason for using "signing entity" here is that if the named
> certificate subject can PROVE that he was not the signing entity he may
> well not be held responsible.  If he can prove that the certificate was
> issued to someone else as a result of a masquerade he probably will not be
> held responsible.

The object "signing entity" is nowhere defined in X.509, and is used only once.
So, what you mention is not written and should be used as an argument unless
you are actually proposing a change to X.509 and PKIX.

OTOH, since DNs in X.509 are not unambiguous to individuals  (and, were
never intended to be, even in a local registry under X.500),  X.509 certificates
cannot be considered proof of identity -- neither legally nor protocol-wise.

The distinction between "signing entity" and "certificate subject" (aka key
holder, or certificate subscriber) is thus artificial and *cannot* be dealt with
within X.509. Hence, if any, it must lie outside the scope of X.509.

Thus, it makes sense to substitute it for "certificate subject" -- a well-defined
object, visible in the certificate.

> However, it is worth reiterating that there are only two basic ways
> for the law to treat the question of whether the certificate subject is the
> signing entity: in the first, the certificate subject must prove that he
> was not the signing entity; and in the second, where the relying party must
> prove that the certificate subject was the signing entity, the NR service
> is not likely to be of much use.

I suggest that digressing to legal evaluation will not be very helpful here.
However, the NR service can be of use if the technical assessment can prove
within an acceptable margin that the subject's private-key was used to
produce the signature. Further, the NR service can be of use if the technical
assessment can prove within an acceptable margin that the subject's
private-key was not used to produce the signature.

Likewise, though, there are "only two basic ways" -- either is was or was not ;-)
Of course, in law and here, this means that one is using an explicit  threshhold
value  in the balance of probabilities in order to differentiate between each way.

Cheers,

Ed Gerck

Date: Mon, 22 Nov 1999 15:49:21 -0800
From: Ed Gerck <[email-masked]>
To: Tony Bartoletti <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: MOTION ON NR

Tony Bartoletti wrote:

> Seriously, why not substitute "certificate subject" for "signing entity"?
> The so-called "signing entity" is nowhere an element of the certificate.

Good point. And X.509 also uses "signer" for the same purpose. So, we
could indeed lint these occurrences and unify the references.

> And what is this "some action".  Why would it hurt to be a bit more
> precise.

No, it would not hurt at all. See my previous msg where I suggest that
all necessary comments/context be added as short notes after the definition.
I already list five notes -- which would make the definition itself cumbersome
if smply added to it.  In trying to making things clear we need of course to
include a chain of references, which cannot become so long that the
definition may actually become an essay by itself ;-) ... that is, if those
references are included in the definition itself.

> Now a difference of opinion exists between Ed Gerck, who maintains that
> NR should serve as a "trump card", that cares not whether the denial
> is true or false (sort of like the deductible you agree to pay anyway)
> and those who expect NR to simply (and neutrally) allow a trusted
> third party to hold/adjudicate over evidence.)  If we take the former
> position (NR hedges both true and false denials), then indeed the
> definition has the "right" to be skewed.  But if we intend NR to
> support the more neutral "independent evidentiary" service, then
> it should not be so skewed.

Yes. The "skew factor" can however be reduced or increased by chosing
a boundary for the NR service (see my previous posting).  As the NR
service boundary increases, more variables and subsystems are included,
but processing time, cost and inconsistencies also increase (a  system of
some complexity cannot be both consistent and complete, as a general
property also valid here). Eventually, a compromise must be reached for
the NR service boundary -- whatever it is, it cannot be infinite. Then, some
variables must be left outside and it is irrevelant to *that* NR system
whether those variables are truthful or false.  Another nesting NR system
may, however, use the result of the first NR system and apply other variables
that were missing from the first NR result, arriving at a second NR result,
which may differ from the first and which may (or not) superseed the first
NR result, and so on for a series of nesting NR systems. This can happen
both in the technical as well as in the legal domain, or between both -- as
when a higher court (a third NR system) asks for a new technical expert to
be considered by a lower court, effectively increasing the boundaries of the
variables considered in the first NR result -- which may or may not alter the
result.

So, what we are dealing with here is a NR service which can be defined
according to need while, at the same time, remaining neutral to anything
that lies *outside* the service.  The alternative would be to prejudge that
which lies outside the system -- even before the result from the system is
ever announced. A logic design flaw which can be circumvented by
considered nested NR systems as commented above. In terms of trust,
the nested NR systems correspond to a trusted chain of events built
from the one trust-point backwards -- for example, in a decision tree.

Cheers,

Ed Gerck

From: [email-masked]
To: Tony Bartoletti <[email-masked]>
cc: "[email-masked]" <[email-masked]>
Date: Mon, 22 Nov 1999 18:37:06 -0500
Subject: Re: NR Signing-Entity vs Certificate-Subject

     The main reason for using "signing entity" here is that if the named
certificate subject can PROVE that he was not the signing entity he may
well not be held responsible.  If he can prove that the certificate was
issued to someone else as a result of a masquerade he probably will not be
held responsible.
     However, it is worth reiterating that there are only two basic ways
for the law to treat the question of whether the certificate subject is the
signing entity: in the first, the certificate subject must prove that he
was not the signing entity; and in the second, where the relying party must
prove that the certificate subject was the signing entity, the NR service
is not likely to be of much use.
     That particular program would be better off asking for a PIN.

          Tom Gindin

Tony Bartoletti <[email-masked]> on 11/22/99 05:59:33 PM

To:   "[email-masked]" <[email-masked]>
cc:
Subject:  NR Signing-Entity vs Certificate-Subject

All,

Would it not be more "up front" to refer to the "signing entity"
in the NR definition as the "certificate subject"?

Granted, in these circles it may seem to be another one of those
"understood" things, but to common folk it might appear a bit
disengenuous.

Suppose I am about to execute an electronic contract with you,
and I'm all ready to hit the "sign with NR here" button.  But I
have second thoughts, and get up to brew another cup of coffee.
In my absense, a neighbor walks in, and out of mischief or
misguided helpfulness, clicks the button for me.

Who is the "signing entity"?

(Yes, I may well be the liable party, and "effectively" the
signing entity.  But many would reasonable hold that the person
who "effected the signature" was the neighbor.  So... )

I go to court (or am taken there upon refusal to honor the
contract) and I subpoena my (now uncooperative) neighbor as a
hostile witness, claiming that they perpetrated a fraud by
signing with my signature key.  The neighbor falsely denies it.

The NR definition says "protects against the signing entity
falsely denying...".  Now in fact, my neighbor is the signing
entity, and is falsely denying!  But NR is not interested!

As the relying party, you don't care to be protected from my
neighbor's false denials (especially is they have no assets;)
You intend to hold ME responsible (as I may well be through
negligence) and NR only serves you in this regard.  Why ME?
Not because I am the "signing entity" in the commonly used
sense, but because I am the certified key holder.

So why not replace "signing entity" with "certificate subject"
and eliminate one more point of semantic indirection and
confusion?  Unless you are prepared to be able to distinguish
the two (especially via the NR service) I see no reason to
obscure this issue.

___tony___

Tony Bartoletti                                             LL
IOWA Center                                              LL LL
Lawrence Livermore National Laboratory                LL LL LL
PO Box 808, L - 089                                   LL LL LL
Livermore, CA 94551-9900                              LL LL LLLLLLLL
phone: 925-422-3881   fax: 925-423-8081               LL LLLLLLLL
email: [email-masked]                                   LLLLLLLL

Date: Mon, 22 Nov 1999 14:59:33 -0800
To: "[email-masked]" <[email-masked]>
From: Tony Bartoletti <[email-masked]>
Subject: NR Signing-Entity vs Certificate-Subject

All,

Would it not be more "up front" to refer to the "signing entity"
in the NR definition as the "certificate subject"?

Granted, in these circles it may seem to be another one of those
"understood" things, but to common folk it might appear a bit
disengenuous.

Suppose I am about to execute an electronic contract with you,
and I'm all ready to hit the "sign with NR here" button.  But I
have second thoughts, and get up to brew another cup of coffee.
In my absense, a neighbor walks in, and out of mischief or
misguided helpfulness, clicks the button for me.

Who is the "signing entity"?

(Yes, I may well be the liable party, and "effectively" the
signing entity.  But many would reasonable hold that the person
who "effected the signature" was the neighbor.  So... )

I go to court (or am taken there upon refusal to honor the
contract) and I subpoena my (now uncooperative) neighbor as a
hostile witness, claiming that they perpetrated a fraud by
signing with my signature key.  The neighbor falsely denies it.

The NR definition says "protects against the signing entity
falsely denying...".  Now in fact, my neighbor is the signing
entity, and is falsely denying!  But NR is not interested!

As the relying party, you don't care to be protected from my
neighbor's false denials (especially is they have no assets;)
You intend to hold ME responsible (as I may well be through
negligence) and NR only serves you in this regard.  Why ME?
Not because I am the "signing entity" in the commonly used
sense, but because I am the certified key holder.

So why not replace "signing entity" with "certificate subject"
and eliminate one more point of semantic indirection and
confusion?  Unless you are prepared to be able to distinguish
the two (especially via the NR service) I see no reason to
obscure this issue.

___tony___

Tony Bartoletti                                             LL
IOWA Center                                              LL LL
Lawrence Livermore National Laboratory                LL LL LL
PO Box 808, L - 089                                   LL LL LL
Livermore, CA 94551-9900                              LL LL LLLLLLLL
phone: 925-422-3881   fax: 925-423-8081               LL LLLLLLLL
email: [email-masked]                                   LLLLLLLL

From: [email-masked] (Peter Gutmann)
To: [email-masked], [email-masked], [email-masked], [email-masked], [email-masked]
Subject: Re: FIPS 186 and X9.42: One of these things is not like the other
Sender: [email-masked]
Reply-To: [email-masked]
Date: Tue, 23 Nov 1999 11:39:10 (NZDT)

[Recipient list trimmed somewhat, I hope this is going to appropriate people]

Russ Housley <[email-masked]> writes:

>Both of these parameter structures are included in RFC 2459.  Concerns about
>alignment of the two structures should have been raised many months ago.
>
>While it might have been nice to have the two parameter definitions use the
>same order for p, q, and g, this is not a show stopper.  People have
>implemented with against the current specifications, and I am strongly
>opposed to changes at this late date.

I had the impression that for an outsider to influence ANSI standards was close
to impossible (if it wasn't for P1363 I'd never even have seen X9.42), which is
why I never commented on it.  Besides, I can't go around nitpicking *every*
standard around, there are only so many hours in the day :-).  That's why, in
my original message, I merely suggested that any new work which uses X9.42 and
FIPS 186/X9.30/whatever other standard it appears in point out that although
the keys look the same and quack the same, they have two of the parameters
(with names which look almost identical) reversed in the ASN.1 form.  This is a
trap just waiting to catch the unwary.

[Having said that, I'd certainly like to see the ASN.1 fixed so the two match
 up, but I guess that's unlikely to happen at this stage].

Peter.

Date: Mon, 22 Nov 1999 17:33:10 -0500
From: Paul Koning <[email-masked]>
To: [email-masked]
Subject: Re: MOTION ON NR

I wonder if I'm the only one here who's getting the feeling that this
discussion is, at best, divergent, and at worst, chaotic.  It very
definitely doesn't look like it is heading towards any kind of
closure. 

It certainly serves to reinforce my earlier opinion that the NR bit
should be deprecated on the grounds that there is no possible
consensus on whether it has any meaning, much less what that meaning
is.

	paul

From: [email-masked]
To: [email-masked]
Date: Mon, 22 Nov 1999 17:23:15 -0500
Subject: Re: MOTION ON NR

Instead of all the legal-psychological speculation about the meaning of
"denial", why not just say what it provides. IMO the critical distinction for an
NR key is that it is intended for persistent signature action *evidence* - not
just for immediate (e.g. session establishment) *decisions.*    Accordingly, I
suggest the following:

1'. nonRepudiation:  for a digital signature verification key that may be used
by a relying party to verify a digital signature, and retained as persistent
evidence of a signer's signature action

How far in the future an NR key is usable a matter of the issuer's archive
policy and practices for the policy under which the certificate is issued, and
any other arguments that one might want to make.

-Gene Hilborn

Date: Mon, 22 Nov 1999 14:08:52 -0800
To: Russ Housley <[email-masked]>
From: Tony Bartoletti <[email-masked]>
Subject: Re: MOTION ON NR
Cc: Ed Gerck <[email-masked]>, "[email-masked]" <[email-masked]>, Nicholas Bohm <[email-masked]>

At 02:44 PM 11/22/1999 -0500, Russ Housley wrote:
>Tony:
>
>How is that any better than "... a service which protects against the 
>signing entity falsely denying some action."
>
>Russ

Russ,

Not much better!  Only helps to recognize that many moons ago, some of
the NR threads asked the question "How can NR prevent me from denying...".
Of course, nothing can prevent you from "issuing a denial".  Hence the
wording above MUST interpret "protects against ... denying" to mean
"protects against ... prevailing in a denial".  It does not alter
the (untenably vague) meaning in the overall definition.

Seriously, why not substitute "certificate subject" for "signing entity"?
The so-called "signing entity" is nowhere an element of the certificate.

And what is this "some action".  Why would it hurt to be a bit more
precise.  Clearly, "some action" must be something authorized by the
signature in question, as Irene Gassko wrote.  Perhaps this is just
another one of the "its understood" things that too many of us don't
seem to understand.

Indeed, as I wrote several months ago, as a "signer", I might want NR
myself:  Perhaps I am signing my patent submission.  If anyone later
tries to deny (falsely, if you must) that I signed or submitted that
patent, it would be a rival developer, not me.  So it seems that the
current definition is biased in this regard.  It assumes only the
(purported) signer might be restrained from "falsely denying some action".

Just as surely, this NR service would

   "protect the signer in truely affirming some action".

Why is the current definition skewed in this regard.  The way it is
worded, it is assumed that the only wronged party can be the RP.

Now a difference of opinion exists between Ed Gerck, who maintains that
NR should serve as a "trump card", that cares not whether the denial
is true or false (sort of like the deductible you agree to pay anyway)
and those who expect NR to simply (and neutrally) allow a trusted
third party to hold/adjudicate over evidence.)  If we take the former
position (NR hedges both true and false denials), then indeed the
definition has the "right" to be skewed.  But if we intend NR to
support the more neutral "independent evidentiary" service, then
it should not be so skewed.
 
___tony___

>At 10:55 AM 11/22/99 -0800, Tony Bartoletti wrote:
>>At 10:30 AM 11/22/1999 -0500, Russ Housley wrote:
>> >I cannot support this direction.  You suggest:
>> >
>> >      1'. nonRepudiation:  for verifying digital signatures used in 
>> providing a
>> >       service which protects against the signing entity  denying some 
>> action.
>> >
>> >The signer can always deny taking some action.  The point is having
>> >evidence to refute the claim if it is false.
>> >
>> >Russ
>>
>>Of course.  I think we must all agree that we use the phrase "prevent a 
>>denial"
>>to mean that we "prevent someone from prevailing in a denial".  If they deny
>>but lose, that's ok.
>>
>>I would accept "prevailing in a denial of some action" just to eliminate one
>>more point of argument (yes, insert laughter here.)
>>

Tony Bartoletti                                             LL
IOWA Center                                              LL LL
Lawrence Livermore National Laboratory                LL LL LL
PO Box 808, L - 089                                   LL LL LL
Livermore, CA 94551-9900                              LL LL LLLLLLLL
phone: 925-422-3881   fax: 925-423-8081               LL LLLLLLLL
email: [email-masked]                                   LLLLLLLL

Date: Mon, 22 Nov 1999 14:02:09 -0800
From: Ed Gerck <[email-masked]>
To: Russ Housley <[email-masked]>, Tony Bartoletti <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: MOTION ON NR

Russ Housley wrote:

> Tony:
>
> How is that any better than "... a service which protects against the
> signing entity falsely denying some action."

Russ:

Because wheter the denial is false or truthful is irrelevant to the protocol.
The signer may be 100% truthful  in that he did not sign and yet the NR
system in place, which the signer accepted beforehand (in order for
example to be able to have his checks accepted without paying/delaying
for a live confirmation for each check), will still provide the risk-bearer
with a tool to prevent the denial of a signature that did not look like
a signature that the signer did NOT make (negative logic is necessary
here).

However, writing

1'a. nonRepudiation:  for verifying digital signatures used in
providing a   service which protects against the signing entity
prevailing when denying some action.

seems to me to be an "explanation mode" definition, which explanation
could be provided in a short comment.  The same applies to

1'b. nonRepudiation:  for verifying digital signatures used in
providing a  service which protects against the signing entity
prevailing when denying actions authenticated by that signature.

since the "actions" are NR-specific actions that  may (or,
may not) directly depend on the signature. This can be likewise
explained in a short comment, where one must carefully restrict it to
NR service specified actions -- e.g., possibly NOT including:

-- actions based on semantic content of the signed message itself;
-- all actions that can be possibly derived from that signature;
-- the signature itself  (desired may be only non-repudiation of a
     time stamp, for example),
-- etc.

or, possibly including ANY or even ALL the above.

That is why IMO the definition

1'. nonRepudiation:  for verifying digital signatures used in
providing a  service which protects against the signing entity
denying some action.

could be useful, since its eventually dubious aspects are few
and they can be explained by *short* expanding notes from the
root concept of "some actions", to wit:

i. The words "some action" mean specific actions protected by
the service, and may include any aspect of a digital signature
including its signed content.

ii. The words "the signing entity denying some action"  mean
the signing entity denying the action itself after the action.

iii. The signing entity may always deny some action at any time.

iv. The words "protects against the signing entity denying some
action" mean that the service intends to prevent the signing
entity from prevailing in a denial of some action, as qualified in
(i) and (ii), to some degree. The signing entity must however
always be sucessful in denying some action before the action.

v. The words "verifying digital signatures used in providing
a  service" mean that a service boundary is defined when
verifying  digital signatures, which service boundary may
nonetheless vary from service to service.  The service
boundary is a conceptual (though it may also be physical)
limit.  It is irrelevant to the service whether the denial of some
action is false or truthful outside the service boundary.

Comments?

Cheers,

Ed Gerck

From: "Anders Rundgren" <[email-masked]>
To: <[email-masked]>
Cc: <[email-masked]>, "Ella Paton Bassett" <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>, "Stefan Santesson" <[email-masked]>
Subject: Re: We have to choose serialNumber instead of dnQualifier NOW!!!
Date: Mon, 22 Nov 1999 22:38:32 -0000

Magnus,

>I must say I am a bit reluctant to choose a long-term solution because of
>short-term time constraints in this case. Finland is, in my view, a "lost
>case" anyway, our decision won't affect them much right now anyway. What
>says "There is no time to define a new attribute"? Better to think this
>through properly and let everyone express their view than to rush
>something which may not be the optimal solution.
>

Actually the situation in Finland, Sweden and Germany etc. probably requires the famous
kludge solution.

That means that they must (if production has started) continue with SerialNumber, DNqalifier or whatever
homebrewed scheme that is used. 

Then if a new solution becomes standardized you add that as well but keep the kludge until
all applications out there only use the standard attribute.

Looks ugly but works well :-)

SerialNumber is at least a lousy name as the identifier we are talking about neither needs
to be numeric or serially incrementing

<snip>
Anders

From: "John C. Kennedy" <[email-masked]>
To: "Russ Housley" <[email-masked]>
Cc: <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>, "Elaine Barker" <[email-masked]>, "Sharon Keller" <[email-masked]>, "Simon Blake-Wilson" <[email-masked]>, "Phil Griffin" <[email-masked]>
Subject: RE: FIPS 186 and X9.42: One of these things is not like the other
Date: Mon, 22 Nov 1999 12:57:13 -0800
Importance: Normal

This is a multi-part message in MIME format.

------=_NextPart_000_0056_01BF34E9.03F25260
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit

Russ,

1. With all due respect, saying that I have been "out of the loop" is not
quite correct.  I have continued to track the output of both X9F1 and IETF
with regards to X9.42 and DH for the last couple of years. I have copies
of X9.42 drafts up through February 1999.  One does not have to be "in the
loop" to see the inconsistencies I have pointed out.

2. The PKIX "son-of-2459" work, of which mostly only the ASN.1 portion of
X9.42 is relevant, is probably correct.  What is a bigger problem is that
RFC 2631 (Diffie-Hellman Key Agreement Method) by Eric Rescorla references
a 1998 draft. The related drafts, <draft-ietf-smime-small-subgroup-02.txt>
and <draft-ietf-pkix-dhpop-02.txt>, reference RFC 2631.  Is there proper
alignment in these works with the current state of X9.42?  I don't think
so.  How would the larger IETF community know if they were?  Is ANSI
keeping all these authors "in the loop"?

3. FIPS 186-1 on DSA and rDSA is a good example.  If the X9.42
specification had been kept as simple as FIPS 186 we wouldn't be where we
are now.  It is unfortunate that crypto-politics and other machinations
did not allow NIST to handle this work independent of ANSI from the
beginning.

-John
[email-masked]

> -----Original Message-----
> From: Russ Housley [mailto:[email-masked]]

> John:
>
> You have been out of the loop for over two years, and your
> observation are
> simply incorrect!
>

> The people that have been working on the PKIX and S/MIME standards that
> refer to X9.42 have been given every version of the document as it
became
> available to the X9F1 working group participants.  And, X9F1 has
> worked to
> ensure that they did not change the parts of X9.42 that were
> adopted by the
> IETF.
>
> Peter may not like the minor differences between X9.42 and DSA.  But the
> IETF documents are aligned with the X9.42 (just as they claim).  By the
> way, FIPS 186 contains no ASN.1; it only contains the algorithm
> specification.
>
> Russ
>
>
> At 01:17 AM 11/21/99 -0800, John C. Kennedy wrote:
> >(A long but hopefully illuminating follow-up regarding ANSI X9.42)
> >
> >(**Summary: The use or referencing of the ANSI X9.42
> (Diffie-Hellman) drafts
> >in IETF standards has resulted in the propagation of a number of
> errors and
> >inconsistencies within IETF drafts and RFCs.  IMHO, it is questionable
> >whether the still unratified ANSI X9.42 draft should be used as
> a basis or
> >even a reference for ongoing IETF Diffie-Hellman protocol
standardization
> >work.)
> >
> >Peter,
> >
> >I was the editor of the ANSI X9.42 Diffie-Hellman draft up until
> about April
> >of 1997 when I changed employers and passed the X9.42 editing
> torch.  Since
> >my current work has given me a reason to wade back into the IETF
> process, I
> >wanted to share a few comments and provide some additional data on the
> >apparent state of Diffie-Hellman in IETF work.  As I revisit things 2.5
> >years later it seems to still be a bit of a mess in need of some
> tidying up.
> >
> >(1) RFC 2459 (PKIX) references a December 1997 draft of ANSI X9.42.  I
> >believe this may be a draft that I "strategically distributed" to a few
> >select people working in IPSEC, PKIX, and other IETF working
> groups around
> >that time.  ANSI X9F has never had a lot of interest in seeing X9.42
> >reviewed or adopted by IETF.  [In fact, it is ridiculous that
> after almost
> >five years of work and innumerable rewrites, neither ANSI or NIST have
> >published an authoritative interoperability standard for one the most
> >fundamental and powerful public key techniques for key agreement we
have.
> >(Hint: It is not because of patents or because it is too difficult to
> >communicate.)]
> >
> >(2) RFC 2631 (Diffie-Hellman Key Agreement Method) references a
> 1998 draft
> >of X9.42.  This X9.42 draft is probably the one made available by ANSI
to
> >IEEE P1363 members at
> >http://grouper.ieee.org/groups/1363/private/x9-42-10-02-98.doc (You
will
> >need an IEEE P1363 password to get at this.)  This draft is
> better than the
> >1997 draft, but still has problems.  Since I have not been involved
with
> >ANSI for about 3 years, I can't comment on where the X9.42 draft
> currently
> >stands.  Since the X9.42 draft document is (still!) not public, it is
not
> >clear whether it is relevant to the IETF's work anyway.  RFC 2631 is
> >currently a proposed standard in IETF.  Since RFC 2631 propagates
errors
> >that existed in the 1998 X9.42 draft, a second look at it is
> probably called
> >for. (These errors are noted below)
> >
> >(3) RFC 2412 (OAKLEY Key Agreement) doesn't reference any
Diffie-Hellman
> >standards.  While the techniques given in this document are
> mathematically
> >accurate and certainly filled a gap in the IPSEC work at the time, the
> >OAKLEY RFC doesn't quite provide all the pieces needed to link
> up with PKIX
> >and some other security standards.
> >
> >(4) The following drafts contain relevant references to Diffie-Hellman
or
> >related protocols.  The first two reference RFC 2631 and the second
> >specifies a new DH variant altogether:
> >draft-ietf-smime-small-subgroup-02.txt
> >draft-ietf-pkix-dhpop-02.txt
> >draft-ietf-secsh-transport-06.txt
> >
> >(5) Both of the ANSI documents currently referenced were drafts
> and probably
> >weren't the best basis for IETF standards.  Given the lack of
> anything else
> >to point to, I can't say I blame the authors, however.  They
> certainly meant
> >well.  What is also unfortunate is that IETF community has not
> been provided
> >with access to more current X9.42 drafts.  This is, IMHO,
> probably related
> >to the situation I pointed out in (1).
> >
> >Now, in reponse to your observations:
> >
> >(6) RFC 2631 states "X9.42 requires that the private key x be in the
> >interval [2, (q - 2)]"
> >In other words, (1 < x < q-1).  **It is quite clear that the referenced
> >X9.42 draft is not only wrong but inconsistent**.  And in a number of
> >places.  The Diffie-Hellman private key x should be chosen in the
closed
> >interval [2^(m-1), q-1], where m is the minimum length in bits
acceptable
> >for the private key.  (Typically m>=160, but your mileage may
> vary...)  This
> >is consistent with security recommendations in the current IEEE P1363
> >documents as well as definitions in
> draft-ietf-smime-small-subgroup-02.txt,
> >draft-ietf-pkix-dhpop-02.txt.  (If there is a mathematical
> subtlety I have
> >forgotten and x should be in [2^(m-1), q-2], I hope someone speaks up
to
> >correct me.)
> >
> >Note that choosing x in [1, q-1] will work just fine mathematically,
but
> >does not reflect or enforce the minimum key size requirement.
> Note that if
> >the size of q is at least a few bit greater than m and you are
> using a good
> >RNG to pick x, the point is probably moot anyway.  If you are using a
> >long-term (aka "static") DH keys, however, it probably not a bad
> idea to put
> >the minimum keysize check in your keygen routine as a "belt and
> suspenders"
> >type measure.
> >
> >(7) The domain parameter generation routines in X9.42 were in
> fact derived
> >from those in the FIP 186 spec to allow re-use of DSA parameters
> (p, q, and
> >g) with X9.42 if desired.  I can't say I am a big fan of this because
it
> >forces q to 160 bits which is probably not appropriate if you intend to
> >enforce a minimum DH private key size greater than 160.
> >
> >(8) The parameter order switch was not a deliberate booby trap,
although
> >these types of things do help to keep crypto engineers on their
> toes. :)  As
> >I recall, the parameters q and j were added when concerns about small
> >subgroup attacks on Diffie-Hellman surfaced.  It is more of a
coincidence
> >that the DSA algorithm exploits the use of a subgroup also defined by a
> >prime called q.  In other words, DSA included q from the beginning
while
> >X9.42 added q as a security enhancement.  The ASN.1 encoding
> choices are an
> >artifact of the development process, not a deliberate reversal.
> If you feel
> >like lobbying ANSI X9F to change the ordering to make everyone's life
> >easier, have at it.  I wouldn't hold my breath however. :)
> >
> >(9) RFC 2459 (PKIX) shows ASN.1 encoding of the DH parameters as:
> >  DomainParameters ::= SEQUENCE {
> >               p       INTEGER, -- odd prime, p=jq +1
> >               g       INTEGER, -- generator, g
> >               q       INTEGER, -- factor of p-1
> >               j       INTEGER OPTIONAL, -- subgroup factor
> >               validationParms  ValidationParms OPTIONAL }
> >
> >         ValidationParms ::= SEQUENCE {
> >               seed             BIT STRING,
> >               pgenCounter      INTEGER }
> >
> >whereas the 1998 X9.42 draft shows them as:
> >
> >DomainParameters ::= SEQUENCE {  -- Galois field group parameters
> >    p                INTEGER,        -- odd prime, p = jq + 1
> >    g                INTEGER,        -- generator, g
> >    q                INTEGER,        -- prime factor of p-1
> >    j                INTEGER,        -- subgroup factor, j >= 2
> >    validationParms  ValidationParms OPTIONAL
> >(**Note q is no longer optional.** JK)
> >
> >if you can find a copy of the 1997 draft (which I happen to
> have) we see the
> >original version:
> >
> >DomainParameters ::= SEQUENCE {  -- Galois field group parameters
> >    p                INTEGER,        -- odd prime, p = jq + 1
> >    g                INTEGER,        -- generator, g
> >    q                INTEGER OPTIONAL,        -- prime factor of p-1
> >    j                INTEGER OPTIONAL,        -- subgroup factor, j >=
2
> >    validationParms  ValidationParms OPTIONAL
> >
> >(This early draft reflects my admitted ignorance of proper ASN.1 at the
> >time. You cannot have multiple optional INTEGERS without tags on them.)
> >
> >My guess is that the middle version (i.e., with only ValidationParms
> >optional) is the preferred version, which means RFC 2459 should
> probably be
> >changed.  I do not know what the current X9.42 draft gives.
> >
> >****Conclusion****
> >(10) Because of the aforementioned errors and inconsistencies, I have
> >serious reservations about the continued use or referencing of
> ANSI X9.42 in
> >IETF drafts or standards.  The use or referencing of the ANSI
> X9.42 draft in
> >IETF standards has resulted in the propagation of a number of errors
and
> >inconsistencies within IETF drafts and RFCs.  IMHO, it is questionable
> >whether the apparently still unratified and possibly unstable ANSI
X9.42
> >draft should be used as a basis or reference for ongoing IETF
> Diffie-Hellman
> >protocol standardization efforts.  Because of this, I respectfully
submit
> >that the IETF should consider whether RFC 2631 should be deprecated and
> >rewritten in a manner which removes unnecessary references to
> the mysterious
> >and forever-unpublished ANSI X9.42 draft.
> >
> >
> >-John Kennedy
> >[email-masked]
> >
> >
> >
> >-----Original Message-----
> >From: [email-masked] [mailto:[email-masked]]
> >Sent: Sunday, November 21, 1999 1:58 PM
> >To: [email-masked]; [email-masked]
> >Subject: FIPS 186 and X9.42: One of these things is not like the other
> >
> >
> >FIPS 186/X9.30 and X9.42 (and by extension RFC 2631) share the same key
> >generation algorithm, and have domain parameters which look identical,
> >however
> >there are two subtle differences between them, one of which is really
> >annoying.
> >
> >The annoying difference is that when writing the domain parameters, the
> >order
> >of q and g is reversed for FIPS 186 and X9.42 keys, so that
> while DSA domain
> >parameters are written (p, q, g), exactly the same domain parameters
when
> >viewed as X9.42 values are written (p, g, q).  This isn't helped
> by the fact
> >that in many fonts lowercase q and g look very similar.  Apart
> from the fact
> >that it's a booby-trap for implementors, it also means that if the
domain
> >parameters are identified in the traditional way (SHA-1 hash),
identical
> >parameters will appear to be different depending on whether you're
> >interpreting
> >them as DSA/KEA or DH parameters.
> >
> >The second difference is in the allowed range for x:
> >
> >   FIPS 186: 0 < x < q (ie x = 1...q-1)
> >   X9.42: 1 < x <= q-2 in one place, [2...q-2] in another (ie x =
2..q-2)
> >
> >This looks like a transcription error from FIPS 186, given that using
any
> >x < ~2^160 is unsound I can't see why there'd be any difference between
1
> >and 2
> >as a lower bound.
> >
> >Perhaps new RFC's which cover this (eg son-of-RFC2459) could include
> >warnings
> >to the effect that although the parameters are the same internally,
their
> >external representations differ.
> >
> >Does anyone know why X9.42 decided to reverse the parameter order?
> >
> >(The motivation for this post is that ages ago I solved the
> problem of the
> >  reversed parameters by swapping the pointers for the X9.42 g
> and q values
> >so
> >  they were read and written in the correct order, recently I was
looking
> >  through the code and wondered why it was working fine for both
> >interpretations
> >  of parameter ordering.  There's now a big comment block by the code
> >explaining
> >  the Bug which Isn't)
> >
> >Peter.

------=_NextPart_000_0056_01BF34E9.03F25260
Content-Type: application/x-pkcs7-signature;
	name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment;
	filename="smime.p7s"

------=_NextPart_000_0056_01BF34E9.03F25260--

From: "Don Johnson" <[email-masked]>
To: "John C. Kennedy" <[email-masked]>
cc: [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], "Elaine Barker" <[email-masked]>, "Sharon Keller" <[email-masked]>, "Simon Blake-Wilson" <[email-masked]>, [email-masked]
Date: Mon, 22 Nov 1999 15:17:00 -0500
Subject: RE: FIPS 186 and X9.42: One of these things is not like the other

--0__=ACDP3UzyXR808KoURSahabzWVpJ5vRGS4kMPU5dQEQ0kvhjbvaZoHErM
Content-type: text/plain; charset=us-ascii
Content-Disposition: inline

John,

1. ANSI X9.42 is supposed to go shortly to final ballot.
2. Yes, it looks like the different orders of parms are now cast in concrete.
3. A duplicate private key can be detected by checking for a duplicate public
key, if this is a concern.  For example, if an ephemeral public key repeats,
then the forward secrecy property may fail.  But this is often handled as being
a event so rare it does not need to be checked.  If it is a concern, it can be
checked.
Don Johnson

"John C. Kennedy" <[email-masked]> on 11/22/99 03:08:47 PM

To:   Don Johnson/Certicom@Certicom
cc:   [email-masked], [email-masked], [email-masked],
      [email-masked], [email-masked], [email-masked],
      [email-masked], [email-masked], [email-masked],
      [email-masked], "Elaine Barker" <[email-masked]>,
      "Sharon Keller" <[email-masked]>, Simon Blake-Wilson/Certicom@Certicom,
      "Phil Griffin" <[email-masked]>

Subject:  RE: FIPS 186 and X9.42: One of these things is not like the other

Don,

1. I truly hope it is ready for final ballot.  Many people have been
patiently waiting for it and respectfully referencing and including
placeholders in code and other standards in anticipation of it.  It is not
ANSI X9F1's responsibility to supply IETF with algorithm standards in a
timely fashion.  By the same token, IETF security working groups must be
vigilant to not delay important work by continuing to hitch its wagon to a
Diffie-Hellman draft that the ANSI committee continues to revise and which
is *still* not ratified.  My first post gave valid evidence of the results
of this decision thus far.

2. IMHO, the order of the parameters is irrelevant as long as they are
labeled and encoded correctly.

3. Is the private key now called 'd' instead of 'x'? <sigh>
As for the range of the private key, the checks to be performed during
generation should be unambiguous.  Whether or not the receiver of the
corresponding public number can verify that these checks were done is
somewhat meaningless.  For example, can the receiver tell whether or not
the sender's private number was generated with a robust PRNG that won't
repeat itself every tenth time it is accessed?

-John

-----Original Message-----
From: Don Johnson [mailto:[email-masked]]
Sent: Monday, November 22, 1999 6:36 AM
To: John C. Kennedy
Cc: [email-masked]; [email-masked]; [email-masked];
[email-masked]; [email-masked]; [email-masked];
[email-masked]; [email-masked]; [email-masked];
[email-masked]; Elaine Barker; Sharon Keller; Simon
Blake-Wilson; Phil Griffin
Subject: RE: FIPS 186 and X9.42: One of these things is not like the
other

John,

A few comments on X9.42.
1. Elaine Barkey and Sharon Keller of NIST are the editors of ANSI X9.42.
I am
copying them on your note.  It should be ready for final ballot.
2. The order of the parameters in the domain parameters should be made
consistent with X9.30 DSA, I think.  If this is not the way it is, it
should be
changed in X9.42.
3. The private key d should be a value from 1 to q-1 in X9.42.  It is
allowed to
chop off the ends and make it 2 to q-2.  Any further reduction risks
reducing
the keysize and therefore aiding the adversary.  The reason that "low"
values
are allowed sometimes is that it is not known how to detect such a
situation.
In fact, if it were, then DH would unravel anyway.

Don Johnson

"John C. Kennedy" <[email-masked]> on 11/21/99 04:17:21 AM

To:   [email-masked], [email-masked], [email-masked],
      [email-masked]
cc:   [email-masked], [email-masked], Don
      Johnson/Certicom@Certicom, [email-masked], [email-masked],
      [email-masked], [email-masked]

Subject:  RE: FIPS 186 and X9.42: One of these things is not like the
other

(A long but hopefully illuminating follow-up regarding ANSI X9.42)

(**Summary: The use or referencing of the ANSI X9.42 (Diffie-Hellman)
drafts
in IETF standards has resulted in the propagation of a number of errors
and
inconsistencies within IETF drafts and RFCs.  IMHO, it is questionable
whether the still unratified ANSI X9.42 draft should be used as a basis or
even a reference for ongoing IETF Diffie-Hellman protocol standardization
work.)

Peter,

I was the editor of the ANSI X9.42 Diffie-Hellman draft up until about
April
of 1997 when I changed employers and passed the X9.42 editing torch.
Since
my current work has given me a reason to wade back into the IETF process,
I
wanted to share a few comments and provide some additional data on the
apparent state of Diffie-Hellman in IETF work.  As I revisit things 2.5
years later it seems to still be a bit of a mess in need of some tidying
up.

(1) RFC 2459 (PKIX) references a December 1997 draft of ANSI X9.42.  I
believe this may be a draft that I "strategically distributed" to a few
select people working in IPSEC, PKIX, and other IETF working groups around
that time.  ANSI X9F has never had a lot of interest in seeing X9.42
reviewed or adopted by IETF.  [In fact, it is ridiculous that after almost
five years of work and innumerable rewrites, neither ANSI or NIST have
published an authoritative interoperability standard for one the most
fundamental and powerful public key techniques for key agreement we have.
(Hint: It is not because of patents or because it is too difficult to
communicate.)]

(2) RFC 2631 (Diffie-Hellman Key Agreement Method) references a 1998 draft
of X9.42.  This X9.42 draft is probably the one made available by ANSI to
IEEE P1363 members at
http://grouper.ieee.org/groups/1363/private/x9-42-10-02-98.doc (You will
need an IEEE P1363 password to get at this.)  This draft is better than
the
1997 draft, but still has problems.  Since I have not been involved with
ANSI for about 3 years, I can't comment on where the X9.42 draft currently
stands.  Since the X9.42 draft document is (still!) not public, it is not
clear whether it is relevant to the IETF's work anyway.  RFC 2631 is
currently a proposed standard in IETF.  Since RFC 2631 propagates errors
that existed in the 1998 X9.42 draft, a second look at it is probably
called
for. (These errors are noted below)

(3) RFC 2412 (OAKLEY Key Agreement) doesn't reference any Diffie-Hellman
standards.  While the techniques given in this document are mathematically
accurate and certainly filled a gap in the IPSEC work at the time, the
OAKLEY RFC doesn't quite provide all the pieces needed to link up with
PKIX
and some other security standards.

(4) The following drafts contain relevant references to Diffie-Hellman or
related protocols.  The first two reference RFC 2631 and the second
specifies a new DH variant altogether:
draft-ietf-smime-small-subgroup-02.txt
draft-ietf-pkix-dhpop-02.txt
draft-ietf-secsh-transport-06.txt

(5) Both of the ANSI documents currently referenced were drafts and
probably
weren't the best basis for IETF standards.  Given the lack of anything
else
to point to, I can't say I blame the authors, however.  They certainly
meant
well.  What is also unfortunate is that IETF community has not been
provided
with access to more current X9.42 drafts.  This is, IMHO, probably related
to the situation I pointed out in (1).

Now, in reponse to your observations:

(6) RFC 2631 states "X9.42 requires that the private key x be in the
interval [2, (q - 2)]"
In other words, (1 < x < q-1).  **It is quite clear that the referenced
X9.42 draft is not only wrong but inconsistent**.  And in a number of
places.  The Diffie-Hellman private key x should be chosen in the closed
interval [2^(m-1), q-1], where m is the minimum length in bits acceptable
for the private key.  (Typically m>=160, but your mileage may vary...)
This
is consistent with security recommendations in the current IEEE P1363
documents as well as definitions in
draft-ietf-smime-small-subgroup-02.txt,
draft-ietf-pkix-dhpop-02.txt.  (If there is a mathematical subtlety I have
forgotten and x should be in [2^(m-1), q-2], I hope someone speaks up to
correct me.)

Note that choosing x in [1, q-1] will work just fine mathematically, but
does not reflect or enforce the minimum key size requirement.  Note that
if
the size of q is at least a few bit greater than m and you are using a
good
RNG to pick x, the point is probably moot anyway.  If you are using a
long-term (aka "static") DH keys, however, it probably not a bad idea to
put
the minimum keysize check in your keygen routine as a "belt and
suspenders"
type measure.

(7) The domain parameter generation routines in X9.42 were in fact derived
from those in the FIP 186 spec to allow re-use of DSA parameters (p, q,
and
g) with X9.42 if desired.  I can't say I am a big fan of this because it
forces q to 160 bits which is probably not appropriate if you intend to
enforce a minimum DH private key size greater than 160.

(8) The parameter order switch was not a deliberate booby trap, although
these types of things do help to keep crypto engineers on their toes. :)
As
I recall, the parameters q and j were added when concerns about small
subgroup attacks on Diffie-Hellman surfaced.  It is more of a coincidence
that the DSA algorithm exploits the use of a subgroup also defined by a
prime called q.  In other words, DSA included q from the beginning while
X9.42 added q as a security enhancement.  The ASN.1 encoding choices are
an
artifact of the development process, not a deliberate reversal.  If you
feel
like lobbying ANSI X9F to change the ordering to make everyone's life
easier, have at it.  I wouldn't hold my breath however. :)

(9) RFC 2459 (PKIX) shows ASN.1 encoding of the DH parameters as:
 DomainParameters ::= SEQUENCE {
              p       INTEGER, -- odd prime, p=jq +1
              g       INTEGER, -- generator, g
              q       INTEGER, -- factor of p-1
              j       INTEGER OPTIONAL, -- subgroup factor
              validationParms  ValidationParms OPTIONAL }

        ValidationParms ::= SEQUENCE {
              seed             BIT STRING,
              pgenCounter      INTEGER }

whereas the 1998 X9.42 draft shows them as:

DomainParameters ::= SEQUENCE {  -- Galois field group parameters
   p                INTEGER,        -- odd prime, p = jq + 1
   g                INTEGER,        -- generator, g
   q                INTEGER,        -- prime factor of p-1
   j                INTEGER,        -- subgroup factor, j >= 2
   validationParms  ValidationParms OPTIONAL
(**Note q is no longer optional.** JK)

if you can find a copy of the 1997 draft (which I happen to have) we see
the
original version:

DomainParameters ::= SEQUENCE {  -- Galois field group parameters
   p                INTEGER,        -- odd prime, p = jq + 1
   g                INTEGER,        -- generator, g
   q                INTEGER OPTIONAL,        -- prime factor of p-1
   j                INTEGER OPTIONAL,        -- subgroup factor, j >= 2
   validationParms  ValidationParms OPTIONAL

(This early draft reflects my admitted ignorance of proper ASN.1 at the
time. You cannot have multiple optional INTEGERS without tags on them.)

My guess is that the middle version (i.e., with only ValidationParms
optional) is the preferred version, which means RFC 2459 should probably
be
changed.  I do not know what the current X9.42 draft gives.

****Conclusion****
(10) Because of the aforementioned errors and inconsistencies, I have
serious reservations about the continued use or referencing of ANSI X9.42
in
IETF drafts or standards.  The use or referencing of the ANSI X9.42 draft
in
IETF standards has resulted in the propagation of a number of errors and
inconsistencies within IETF drafts and RFCs.  IMHO, it is questionable
whether the apparently still unratified and possibly unstable ANSI X9.42
draft should be used as a basis or reference for ongoing IETF
Diffie-Hellman
protocol standardization efforts.  Because of this, I respectfully submit
that the IETF should consider whether RFC 2631 should be deprecated and
rewritten in a manner which removes unnecessary references to the
mysterious
and forever-unpublished ANSI X9.42 draft.

-John Kennedy
[email-masked]

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: Sunday, November 21, 1999 1:58 PM
To: [email-masked]; [email-masked]
Subject: FIPS 186 and X9.42: One of these things is not like the other

FIPS 186/X9.30 and X9.42 (and by extension RFC 2631) share the same key
generation algorithm, and have domain parameters which look identical,
however
there are two subtle differences between them, one of which is really
annoying.

The annoying difference is that when writing the domain parameters, the
order
of q and g is reversed for FIPS 186 and X9.42 keys, so that while DSA
domain
parameters are written (p, q, g), exactly the same domain parameters when
viewed as X9.42 values are written (p, g, q).  This isn't helped by the
fact
that in many fonts lowercase q and g look very similar.  Apart from the
fact
that it's a booby-trap for implementors, it also means that if the domain
parameters are identified in the traditional way (SHA-1 hash), identical
parameters will appear to be different depending on whether you're
interpreting
them as DSA/KEA or DH parameters.

The second difference is in the allowed range for x:

  FIPS 186: 0 < x < q (ie x = 1...q-1)
  X9.42: 1 < x <= q-2 in one place, [2...q-2] in another (ie x = 2..q-2)

This looks like a transcription error from FIPS 186, given that using any
x < ~2^160 is unsound I can't see why there'd be any difference between 1
and 2
as a lower bound.

Perhaps new RFC's which cover this (eg son-of-RFC2459) could include
warnings
to the effect that although the parameters are the same internally, their
external representations differ.

Does anyone know why X9.42 decided to reverse the parameter order?

(The motivation for this post is that ages ago I solved the problem of the
 reversed parameters by swapping the pointers for the X9.42 g and q values
so
 they were read and written in the correct order, recently I was looking
 through the code and wondered why it was working fine for both
interpretations
 of parameter ordering.  There's now a big comment block by the code
explaining
 the Bug which Isn't)

Peter.

--0__=ACDP3UzyXR808KoURSahabzWVpJ5vRGS4kMPU5dQEQ0kvhjbvaZoHErM
Content-type: application/octet-stream; 
	name="smime.p7s"
Content-Disposition: attachment; filename="smime.p7s"
Content-transfer-encoding: base64

--0__=ACDP3UzyXR808KoURSahabzWVpJ5vRGS4kMPU5dQEQ0kvhjbvaZoHErM--

Content-return: allowed
Date: Mon, 22 Nov 1999 12:37:18 -0500
From: "Heimberg, Jim" <[email-masked]>
Subject: RE: proposed key usage text
To: "'Russ Housley'" <[email-masked]>, Stefan Santesson <[email-masked]>
Cc: Aram Perez <[email-masked]>, [email-masked]

I have been following this discussion for a while, but wanted to clarify
what I read here.  So, for the sake of clarity, do you mean that in an X.500
based system, authentication is based on directory information and
nonrepudiation is based on the user's information?  If that is so, it might
clarify the discussion.

Our understanding is that use of STRONG binding in the certificate will
result in authentication being based on the certificate, but use of SIMPLE
binding will result in authentication based on the directory information.
Hope that helps.
Jim

-----Original Message-----
From: Russ Housley [mailto:[email-masked]]
Sent: Monday, November 22, 1999 11:31 AM
To: Stefan Santesson
Cc: Aram Perez; [email-masked]
Subject: Re: proposed key usage text

At 10:47 AM 11/22/99 +0100, Stefan Santesson wrote:
>So to me there is no such thing as signing messages just for authentication
>purpose but NOT for non-repudiation. Not in real life.
>
>Can anyone show me a REAL implementation where a messages are signed, where
>this is strictly NOT non-repudiation.

Yes.  X.509 was originally written for X.500 Directory Strong 
Authentication.  This is a case where authentication, not non-repudiation, 
is implemented.

Russ

From: "John C. Kennedy" <[email-masked]>
To: "Don Johnson" <[email-masked]>
Cc: <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>, "Elaine Barker" <[email-masked]>, "Sharon Keller" <[email-masked]>, "Simon Blake-Wilson" <[email-masked]>, "Phil Griffin" <[email-masked]>
Subject: RE: FIPS 186 and X9.42: One of these things is not like the other
Date: Mon, 22 Nov 1999 12:08:47 -0800
Importance: Normal

This is a multi-part message in MIME format.

------=_NextPart_000_003E_01BF34E2.38788920
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit

Don,

1. I truly hope it is ready for final ballot.  Many people have been
patiently waiting for it and respectfully referencing and including
placeholders in code and other standards in anticipation of it.  It is not
ANSI X9F1's responsibility to supply IETF with algorithm standards in a
timely fashion.  By the same token, IETF security working groups must be
vigilant to not delay important work by continuing to hitch its wagon to a
Diffie-Hellman draft that the ANSI committee continues to revise and which
is *still* not ratified.  My first post gave valid evidence of the results
of this decision thus far.

2. IMHO, the order of the parameters is irrelevant as long as they are
labeled and encoded correctly.

3. Is the private key now called 'd' instead of 'x'? <sigh>
As for the range of the private key, the checks to be performed during
generation should be unambiguous.  Whether or not the receiver of the
corresponding public number can verify that these checks were done is
somewhat meaningless.  For example, can the receiver tell whether or not
the sender's private number was generated with a robust PRNG that won't
repeat itself every tenth time it is accessed?

-John

-----Original Message-----
From: Don Johnson [mailto:[email-masked]]
Sent: Monday, November 22, 1999 6:36 AM
To: John C. Kennedy
Cc: [email-masked]; [email-masked]; [email-masked];
[email-masked]; [email-masked]; [email-masked];
[email-masked]; [email-masked]; [email-masked];
[email-masked]; Elaine Barker; Sharon Keller; Simon
Blake-Wilson; Phil Griffin
Subject: RE: FIPS 186 and X9.42: One of these things is not like the
other

John,

A few comments on X9.42.
1. Elaine Barkey and Sharon Keller of NIST are the editors of ANSI X9.42.
I am
copying them on your note.  It should be ready for final ballot.
2. The order of the parameters in the domain parameters should be made
consistent with X9.30 DSA, I think.  If this is not the way it is, it
should be
changed in X9.42.
3. The private key d should be a value from 1 to q-1 in X9.42.  It is
allowed to
chop off the ends and make it 2 to q-2.  Any further reduction risks
reducing
the keysize and therefore aiding the adversary.  The reason that "low"
values
are allowed sometimes is that it is not known how to detect such a
situation.
In fact, if it were, then DH would unravel anyway.

Don Johnson

"John C. Kennedy" <[email-masked]> on 11/21/99 04:17:21 AM

To:   [email-masked], [email-masked], [email-masked],
      [email-masked]
cc:   [email-masked], [email-masked], Don
      Johnson/Certicom@Certicom, [email-masked], [email-masked],
      [email-masked], [email-masked]

Subject:  RE: FIPS 186 and X9.42: One of these things is not like the
other

(A long but hopefully illuminating follow-up regarding ANSI X9.42)

(**Summary: The use or referencing of the ANSI X9.42 (Diffie-Hellman)
drafts
in IETF standards has resulted in the propagation of a number of errors
and
inconsistencies within IETF drafts and RFCs.  IMHO, it is questionable
whether the still unratified ANSI X9.42 draft should be used as a basis or
even a reference for ongoing IETF Diffie-Hellman protocol standardization
work.)

Peter,

I was the editor of the ANSI X9.42 Diffie-Hellman draft up until about
April
of 1997 when I changed employers and passed the X9.42 editing torch.
Since
my current work has given me a reason to wade back into the IETF process,
I
wanted to share a few comments and provide some additional data on the
apparent state of Diffie-Hellman in IETF work.  As I revisit things 2.5
years later it seems to still be a bit of a mess in need of some tidying
up.

(1) RFC 2459 (PKIX) references a December 1997 draft of ANSI X9.42.  I
believe this may be a draft that I "strategically distributed" to a few
select people working in IPSEC, PKIX, and other IETF working groups around
that time.  ANSI X9F has never had a lot of interest in seeing X9.42
reviewed or adopted by IETF.  [In fact, it is ridiculous that after almost
five years of work and innumerable rewrites, neither ANSI or NIST have
published an authoritative interoperability standard for one the most
fundamental and powerful public key techniques for key agreement we have.
(Hint: It is not because of patents or because it is too difficult to
communicate.)]

(2) RFC 2631 (Diffie-Hellman Key Agreement Method) references a 1998 draft
of X9.42.  This X9.42 draft is probably the one made available by ANSI to
IEEE P1363 members at
http://grouper.ieee.org/groups/1363/private/x9-42-10-02-98.doc (You will
need an IEEE P1363 password to get at this.)  This draft is better than
the
1997 draft, but still has problems.  Since I have not been involved with
ANSI for about 3 years, I can't comment on where the X9.42 draft currently
stands.  Since the X9.42 draft document is (still!) not public, it is not
clear whether it is relevant to the IETF's work anyway.  RFC 2631 is
currently a proposed standard in IETF.  Since RFC 2631 propagates errors
that existed in the 1998 X9.42 draft, a second look at it is probably
called
for. (These errors are noted below)

(3) RFC 2412 (OAKLEY Key Agreement) doesn't reference any Diffie-Hellman
standards.  While the techniques given in this document are mathematically
accurate and certainly filled a gap in the IPSEC work at the time, the
OAKLEY RFC doesn't quite provide all the pieces needed to link up with
PKIX
and some other security standards.

(4) The following drafts contain relevant references to Diffie-Hellman or
related protocols.  The first two reference RFC 2631 and the second
specifies a new DH variant altogether:
draft-ietf-smime-small-subgroup-02.txt
draft-ietf-pkix-dhpop-02.txt
draft-ietf-secsh-transport-06.txt

(5) Both of the ANSI documents currently referenced were drafts and
probably
weren't the best basis for IETF standards.  Given the lack of anything
else
to point to, I can't say I blame the authors, however.  They certainly
meant
well.  What is also unfortunate is that IETF community has not been
provided
with access to more current X9.42 drafts.  This is, IMHO, probably related
to the situation I pointed out in (1).

Now, in reponse to your observations:

(6) RFC 2631 states "X9.42 requires that the private key x be in the
interval [2, (q - 2)]"
In other words, (1 < x < q-1).  **It is quite clear that the referenced
X9.42 draft is not only wrong but inconsistent**.  And in a number of
places.  The Diffie-Hellman private key x should be chosen in the closed
interval [2^(m-1), q-1], where m is the minimum length in bits acceptable
for the private key.  (Typically m>=160, but your mileage may vary...)
This
is consistent with security recommendations in the current IEEE P1363
documents as well as definitions in
draft-ietf-smime-small-subgroup-02.txt,
draft-ietf-pkix-dhpop-02.txt.  (If there is a mathematical subtlety I have
forgotten and x should be in [2^(m-1), q-2], I hope someone speaks up to
correct me.)

Note that choosing x in [1, q-1] will work just fine mathematically, but
does not reflect or enforce the minimum key size requirement.  Note that
if
the size of q is at least a few bit greater than m and you are using a
good
RNG to pick x, the point is probably moot anyway.  If you are using a
long-term (aka "static") DH keys, however, it probably not a bad idea to
put
the minimum keysize check in your keygen routine as a "belt and
suspenders"
type measure.

(7) The domain parameter generation routines in X9.42 were in fact derived
from those in the FIP 186 spec to allow re-use of DSA parameters (p, q,
and
g) with X9.42 if desired.  I can't say I am a big fan of this because it
forces q to 160 bits which is probably not appropriate if you intend to
enforce a minimum DH private key size greater than 160.

(8) The parameter order switch was not a deliberate booby trap, although
these types of things do help to keep crypto engineers on their toes. :)
As
I recall, the parameters q and j were added when concerns about small
subgroup attacks on Diffie-Hellman surfaced.  It is more of a coincidence
that the DSA algorithm exploits the use of a subgroup also defined by a
prime called q.  In other words, DSA included q from the beginning while
X9.42 added q as a security enhancement.  The ASN.1 encoding choices are
an
artifact of the development process, not a deliberate reversal.  If you
feel
like lobbying ANSI X9F to change the ordering to make everyone's life
easier, have at it.  I wouldn't hold my breath however. :)

(9) RFC 2459 (PKIX) shows ASN.1 encoding of the DH parameters as:
 DomainParameters ::= SEQUENCE {
              p       INTEGER, -- odd prime, p=jq +1
              g       INTEGER, -- generator, g
              q       INTEGER, -- factor of p-1
              j       INTEGER OPTIONAL, -- subgroup factor
              validationParms  ValidationParms OPTIONAL }

        ValidationParms ::= SEQUENCE {
              seed             BIT STRING,
              pgenCounter      INTEGER }

whereas the 1998 X9.42 draft shows them as:

DomainParameters ::= SEQUENCE {  -- Galois field group parameters
   p                INTEGER,        -- odd prime, p = jq + 1
   g                INTEGER,        -- generator, g
   q                INTEGER,        -- prime factor of p-1
   j                INTEGER,        -- subgroup factor, j >= 2
   validationParms  ValidationParms OPTIONAL
(**Note q is no longer optional.** JK)

if you can find a copy of the 1997 draft (which I happen to have) we see
the
original version:

DomainParameters ::= SEQUENCE {  -- Galois field group parameters
   p                INTEGER,        -- odd prime, p = jq + 1
   g                INTEGER,        -- generator, g
   q                INTEGER OPTIONAL,        -- prime factor of p-1
   j                INTEGER OPTIONAL,        -- subgroup factor, j >= 2
   validationParms  ValidationParms OPTIONAL

(This early draft reflects my admitted ignorance of proper ASN.1 at the
time. You cannot have multiple optional INTEGERS without tags on them.)

My guess is that the middle version (i.e., with only ValidationParms
optional) is the preferred version, which means RFC 2459 should probably
be
changed.  I do not know what the current X9.42 draft gives.

****Conclusion****
(10) Because of the aforementioned errors and inconsistencies, I have
serious reservations about the continued use or referencing of ANSI X9.42
in
IETF drafts or standards.  The use or referencing of the ANSI X9.42 draft
in
IETF standards has resulted in the propagation of a number of errors and
inconsistencies within IETF drafts and RFCs.  IMHO, it is questionable
whether the apparently still unratified and possibly unstable ANSI X9.42
draft should be used as a basis or reference for ongoing IETF
Diffie-Hellman
protocol standardization efforts.  Because of this, I respectfully submit
that the IETF should consider whether RFC 2631 should be deprecated and
rewritten in a manner which removes unnecessary references to the
mysterious
and forever-unpublished ANSI X9.42 draft.

-John Kennedy
[email-masked]

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: Sunday, November 21, 1999 1:58 PM
To: [email-masked]; [email-masked]
Subject: FIPS 186 and X9.42: One of these things is not like the other

FIPS 186/X9.30 and X9.42 (and by extension RFC 2631) share the same key
generation algorithm, and have domain parameters which look identical,
however
there are two subtle differences between them, one of which is really
annoying.

The annoying difference is that when writing the domain parameters, the
order
of q and g is reversed for FIPS 186 and X9.42 keys, so that while DSA
domain
parameters are written (p, q, g), exactly the same domain parameters when
viewed as X9.42 values are written (p, g, q).  This isn't helped by the
fact
that in many fonts lowercase q and g look very similar.  Apart from the
fact
that it's a booby-trap for implementors, it also means that if the domain
parameters are identified in the traditional way (SHA-1 hash), identical
parameters will appear to be different depending on whether you're
interpreting
them as DSA/KEA or DH parameters.

The second difference is in the allowed range for x:

  FIPS 186: 0 < x < q (ie x = 1...q-1)
  X9.42: 1 < x <= q-2 in one place, [2...q-2] in another (ie x = 2..q-2)

This looks like a transcription error from FIPS 186, given that using any
x < ~2^160 is unsound I can't see why there'd be any difference between 1
and 2
as a lower bound.

Perhaps new RFC's which cover this (eg son-of-RFC2459) could include
warnings
to the effect that although the parameters are the same internally, their
external representations differ.

Does anyone know why X9.42 decided to reverse the parameter order?

(The motivation for this post is that ages ago I solved the problem of the
 reversed parameters by swapping the pointers for the X9.42 g and q values
so
 they were read and written in the correct order, recently I was looking
 through the code and wondered why it was working fine for both
interpretations
 of parameter ordering.  There's now a big comment block by the code
explaining
 the Bug which Isn't)

Peter.

------=_NextPart_000_003E_01BF34E2.38788920
Content-Type: application/x-pkcs7-signature;
	name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment;
	filename="smime.p7s"

------=_NextPart_000_003E_01BF34E2.38788920--

Date: Mon, 22 Nov 1999 14:56:30 -0500
To: "Don Johnson" <[email-masked]>
From: Russ Housley <[email-masked]>
Subject: RE: FIPS 186 and X9.42: One of these things is not like the other
Cc: "John C. Kennedy" <[email-masked]>, [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], Elaine Barker <[email-masked]>, Sharon Keller <[email-masked]>, "Simon Blake-Wilson" <[email-masked]>, "Phil Griffin" <[email-masked]>

Don:

The ASN.1 associated with DSA in X9.57 is completely aligned with PKIX (RFC 
2459).  The DSA parameters contain p, q, and g.

The ASN.1 associated with Diffie-Hellman in the draft X9.42 is completely 
aligned with PKIX (RFC 2459) and S/MIME (RFC 2631).  The D-H parameters 
contain p, g, q, j (optional), and validationParms (also optional).

Both of these parameter structures are included in RFC 2459.  Concerns 
about alignment of the two structures should have been raised many months ago.

While it might have been nice to have the two parameter definitions use the 
same order for p, q, and g, this is not a show stopper.  People have 
implemented with against the current specifications, and I am strongly 
opposed to changes at this late date.

Russ

At 02:06 PM 11/22/99 -0500, Don Johnson wrote:
>Russ,
>
>Yes, the ASN.1 for X9.30 is/was in X9.57 Certificate Management, DSA was the
>only public key ANSI X9 had at that time.
>Don Johnson
>
>
>
>
>
>Russ Housley <[email-masked]> on 11/22/99 01:50:56 PM
>
>To:   Don Johnson/Certicom@Certicom
>cc:   "John C. Kennedy" <[email-masked]>, [email-masked],
>       [email-masked], [email-masked], [email-masked],
>       [email-masked], [email-masked], [email-masked], 
> [email-masked],
>       [email-masked], Elaine Barker <[email-masked]>, 
> Sharon
>       Keller <[email-masked]>, Simon Blake-Wilson/Certicom@Certicom, "Phil
>       Griffin" <[email-masked]>
>
>Subject:  RE: FIPS 186 and X9.42: One of these things is not like the  other
>
>
>
>
>Don:
>
>At 09:36 AM 11/22/99 -0500, Don Johnson wrote:
> >2. The order of the parameters in the domain parameters should be made
> >consistent with X9.30 DSA, I think.  If this is not the way it is, it
> >should be
> >changed in X9.42.
>
>I find no ASN.1 in X9.30 part 1.
>
>Russ
>
>

Date: Mon, 22 Nov 1999 14:44:54 -0500
To: Tony Bartoletti <[email-masked]>
From: Russ Housley <[email-masked]>
Subject: Re: MOTION ON NR
Cc: Ed Gerck <[email-masked]>, "[email-masked]" <[email-masked]>, Nicholas Bohm <[email-masked]>

Tony:

How is that any better than "... a service which protects against the 
signing entity falsely denying some action."

Russ

At 10:55 AM 11/22/99 -0800, Tony Bartoletti wrote:
>At 10:30 AM 11/22/1999 -0500, Russ Housley wrote:
> >I cannot support this direction.  You suggest:
> >
> >      1'. nonRepudiation:  for verifying digital signatures used in 
> providing a
> >       service which protects against the signing entity  denying some 
> action.
> >
> >The signer can always deny taking some action.  The point is having
> >evidence to refute the claim if it is false.
> >
> >Russ
>
>Of course.  I think we must all agree that we use the phrase "prevent a 
>denial"
>to mean that we "prevent someone from prevailing in a denial".  If they deny
>but lose, that's ok.
>
>I would accept "prevailing in a denial of some action" just to eliminate one
>more point of argument (yes, insert laughter here.)
>
>___tony___
>
>Tony Bartoletti                                             LL
>IOWA Center                                              LL LL
>Lawrence Livermore National Laboratory                LL LL LL
>PO Box 808, L - 089                                   LL LL LL
>Livermore, CA 94551-9900                              LL LL LLLLLLLL
>phone: 925-422-3881   fax: 925-423-8081               LL LLLLLLLL
>email: [email-masked]                                   LLLLLLLL

Date: Mon, 22 Nov 1999 11:51:02 -0800
From: Ed Gerck <[email-masked]>
To: Tony Bartoletti <[email-masked]>
CC: Russ Housley <[email-masked]>, "[email-masked]" <[email-masked]>, Nicholas Bohm <[email-masked]>
Subject: Re: MOTION ON NR

Tony Bartoletti wrote:

> At 10:30 AM 11/22/1999 -0500, Russ Housley wrote:
> >I cannot support this direction.  You suggest:
> >
> >      1'. nonRepudiation:  for verifying digital signatures used in providing a
> >       service which protects against the signing entity  denying some action.
> >
> >The signer can always deny taking some action.  The point is having
> >evidence to refute the claim if it is false.
> >
> >Russ
>
> Of course.  I think we must all agree that we use the phrase "prevent a denial"
> to mean that we "prevent someone from prevailing in a denial".  If they deny
> but lose, that's ok.

Yes.

> I would accept "prevailing in a denial of some action" just to eliminate one
> more point of argument (yes, insert laughter here.)

No protocol can guarantee that the NR service will  be"prevailng in a denial of
some action".  Perhaps some other term can be found to make it clearer?

Cheers,

Ed Gerck

Date: Mon, 22 Nov 1999 11:42:58 -0800
From: Ed Gerck <[email-masked]>
To: Russ Housley <[email-masked]>
CC: "[email-masked]" <[email-masked]>, Nicholas Bohm <[email-masked]>
Subject: Re: MOTION ON NR

Russ Housley wrote:

> I cannot support this direction.  You suggest:
>
>       1'. nonRepudiation:  for verifying digital signatures used in providing a
>        service which protects against the signing entity  denying some action.
>
> The signer can always deny taking some action.

Russ:

This is a basic right that the signer has.  It is not a function of the protocol
to be a tribunal over the signer and decide *beforehand* whether the denial
is truthful or false -- this is unworkable as we may see in several examples of
temporal logic.  Indeed, the signer may always *later on* deny  taking some
action and the risk-bearer (aka, the relying-party) may decide (or not) that is
worthwhile and possible to protect against such denials *beforehand*.

> The point is having evidence to refute the claim if it is false.

Exactly the point -- but even truthful denials may not be acceptable.
I believe this goes to the heart of the dilemma facing those (including
myself) that see the unfairness of setting up a system that can disallow
truthful denials, by recognizing that "truth" is a matter of reference -- if the
customer wants his check to be cashed without the bank calling (and,
charging) him for every check to be paid, then the client must accept
that the bank needs to independently verify whether the signature is
correct or not, truthful or false. This is the truth that the client accepts,
and accepts it because she profits from it.

In other words, if the signer wants (and profits) from open-loop
acceptance of her orders then the signer must cope with closed-loop
errors which might occur within a risk boundary.  If this is unaceptable
for any risk whatsoever, then the signer should NOT give the risk-bearer
the impossible task of accepting an order that looks like a duck,
quacks like a duck but is not a duck -- i.e., the risk-bearer would need
to reject all orders until proven by the signer in person, in order to avoid
uncovered losses.  E-commerce and banking could not work like this,
of course.

Non-repudiation is a tool that apportions risk -- where the signer risks
paying for a transaction that she claims she did not sign for but which the
risk-bearer could not distinguish from a transaction that the signer did
NOT sign  (note the subtle negative logic here), while the risk-bearer risks
accepting a transaction which the signer can later on prove in a balance
of probabilities that it could not have been made by the signer.  In
either case, whether the signer's claim is truthful or false is irrelevant.
What is relevant is what the risk-berar is able to decide *incomunicado*
from the signer whether that transaction is likely to be repudiated or not
-- which is *independent* from its authentication in integrity and origin.

Thus, preserving the ability of open-loop decisions in a fair system is what
IMO non-repudiation is all about -- and, why it is needed especially on
the Internet where the loop is *always* open (the Internet viewed as
network of networks, where no one can control both ends of a
communication process, nor the route in-between).

Finally, non-repudiation is a tool to build trust when trust is viewed
as qualified reliance on received information.   The risk-bearer needs
to rely on the received information in order to make decisions.  This
trust can be earned protocol-wise for each transaction and can also be
cumulative, not just given away as an open-ended authorization
equally valid for all transactions.

Cheers,

Ed Gerck

Date: Mon, 22 Nov 1999 11:33:30 -0800
To: Irene Gassko <[email-masked]>
From: Tony Bartoletti <[email-masked]>
Subject: Re: MOTION ON NR
Cc: Russ Housley <[email-masked]>, Ed Gerck <[email-masked]>, "[email-masked]" <[email-masked]>, Nicholas Bohm <[email-masked]>

Irene,

Yes, absolutely.  Put both together and we get:

    "successfully denying action authenticated by that signature"

We must be careful, however, to avoid one of Murphy's Correlates:

    "By making things absolutely clear, people will become confused."

:)

___tony___

At 02:14 PM 11/22/1999 -0500, Irene Gassko wrote:
>"Denying some action" sounds somewhat vague to me :-). There are plenty of
>actions not related to that signature which you can deny to your heart's
>content.
>Shouldn't it be something like " denying an action authenticated by that
>signature."?
>
>Irene
>
>At 10:55 AM 11/22/1999 -0800, Tony Bartoletti wrote:
>>At 10:30 AM 11/22/1999 -0500, Russ Housley wrote:
>>>I cannot support this direction.  You suggest:
>>>
>>>      1'. nonRepudiation:  for verifying digital signatures used in 
>>providing a
>>>       service which protects against the signing entity  denying some
>action.
>>>
>>>The signer can always deny taking some action.  The point is having 
>>>evidence to refute the claim if it is false.
>>>
>>>Russ
>>
>>Of course.  I think we must all agree that we use the phrase "prevent a
>denial"
>>to mean that we "prevent someone from prevailing in a denial".  If they deny
>>but lose, that's ok.
>>
>>I would accept "prevailing in a denial of some action" just to eliminate one
>>more point of argument (yes, insert laughter here.)
>>
>>___tony___ 
>>
>-------------------------------------------------------
>Irene Gassko			 Bell Laboratories		http://www.lucent.com
>Lucent Technologies		Secure Technologies Dept.
>1600 Osgood Street			 phone:	(978) 960-5767
>Room 30-2-A31			 e-mail: 	[email-masked]
>N. Andover, MA 01845		 fax: 	(978) 960-3240
>
>

Tony Bartoletti                                             LL
IOWA Center                                              LL LL
Lawrence Livermore National Laboratory                LL LL LL
PO Box 808, L - 089                                   LL LL LL
Livermore, CA 94551-9900                              LL LL LLLLLLLL
phone: 925-422-3881   fax: 925-423-8081               LL LLLLLLLL
email: [email-masked]                                   LLLLLLLL

From: "Don Johnson" <[email-masked]>
To: Russ Housley <[email-masked]>
cc: "John C. Kennedy" <[email-masked]>, [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], Elaine Barker <[email-masked]>, Sharon Keller <[email-masked]>, "Simon Blake-Wilson" <[email-masked]>, "Phil Griffin" <[email-masked]>
Date: Mon, 22 Nov 1999 14:07:00 -0500
Subject: RE: FIPS 186 and X9.42: One of these things is not like the other

Russ,

Also, I am not suggesting it MUST be changed, just that it would be preferred to
be consistent, if at all possible,
Don Johnson

Russ Housley <[email-masked]> on 11/22/99 01:50:56 PM

To:   Don Johnson/Certicom@Certicom
cc:   "John C. Kennedy" <[email-masked]>, [email-masked],
      [email-masked], [email-masked], [email-masked],
      [email-masked], [email-masked], [email-masked], [email-masked],
      [email-masked], Elaine Barker <[email-masked]>, Sharon
      Keller <[email-masked]>, Simon Blake-Wilson/Certicom@Certicom, "Phil
      Griffin" <[email-masked]>

Subject:  RE: FIPS 186 and X9.42: One of these things is not like the  other

Don:

At 09:36 AM 11/22/99 -0500, Don Johnson wrote:
>2. The order of the parameters in the domain parameters should be made
>consistent with X9.30 DSA, I think.  If this is not the way it is, it
>should be
>changed in X9.42.

I find no ASN.1 in X9.30 part 1.

Russ

From: "Don Johnson" <[email-masked]>
To: Russ Housley <[email-masked]>
cc: "John C. Kennedy" <[email-masked]>, [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], Elaine Barker <[email-masked]>, Sharon Keller <[email-masked]>, "Simon Blake-Wilson" <[email-masked]>, "Phil Griffin" <[email-masked]>
Date: Mon, 22 Nov 1999 14:06:17 -0500
Subject: RE: FIPS 186 and X9.42: One of these things is not like the other

Russ,

Yes, the ASN.1 for X9.30 is/was in X9.57 Certificate Management, DSA was the
only public key ANSI X9 had at that time.
Don Johnson

Russ Housley <[email-masked]> on 11/22/99 01:50:56 PM

To:   Don Johnson/Certicom@Certicom
cc:   "John C. Kennedy" <[email-masked]>, [email-masked],
      [email-masked], [email-masked], [email-masked],
      [email-masked], [email-masked], [email-masked], [email-masked],
      [email-masked], Elaine Barker <[email-masked]>, Sharon
      Keller <[email-masked]>, Simon Blake-Wilson/Certicom@Certicom, "Phil
      Griffin" <[email-masked]>

Subject:  RE: FIPS 186 and X9.42: One of these things is not like the  other

Don:

At 09:36 AM 11/22/99 -0500, Don Johnson wrote:
>2. The order of the parameters in the domain parameters should be made
>consistent with X9.30 DSA, I think.  If this is not the way it is, it
>should be
>changed in X9.42.

I find no ASN.1 in X9.30 part 1.

Russ

Date: Mon, 22 Nov 1999 14:14:47 -0500
To: Tony Bartoletti <[email-masked]>
From: Irene Gassko <[email-masked]>
Subject: Re: MOTION ON NR
Cc: Russ Housley <[email-masked]>, Ed Gerck <[email-masked]>, "[email-masked]" <[email-masked]>, Nicholas Bohm <[email-masked]>

"Denying some action" sounds somewhat vague to me :-). There are plenty of
actions not related to that signature which you can deny to your heart's
content.
Shouldn't it be something like " denying an action authenticated by that
signature."?

Irene

At 10:55 AM 11/22/1999 -0800, Tony Bartoletti wrote:
>At 10:30 AM 11/22/1999 -0500, Russ Housley wrote:
>>I cannot support this direction.  You suggest:
>>
>>      1'. nonRepudiation:  for verifying digital signatures used in 
>providing a
>>       service which protects against the signing entity  denying some
action.
>>
>>The signer can always deny taking some action.  The point is having 
>>evidence to refute the claim if it is false.
>>
>>Russ
>
>Of course.  I think we must all agree that we use the phrase "prevent a
denial"
>to mean that we "prevent someone from prevailing in a denial".  If they deny
>but lose, that's ok.
>
>I would accept "prevailing in a denial of some action" just to eliminate one
>more point of argument (yes, insert laughter here.)
>
>___tony___ 
>
>Tony Bartoletti                                             LL
>IOWA Center                                              LL LL
>Lawrence Livermore National Laboratory                LL LL LL
>PO Box 808, L - 089                                   LL LL LL
>Livermore, CA 94551-9900                              LL LL LLLLLLLL
>phone: 925-422-3881   fax: 925-423-8081               LL LLLLLLLL
>email: [email-masked]                                   LLLLLLLL

----------------------------------------------------------------------------
-------------------------------------------------------
Irene Gassko			 Bell Laboratories		http://www.lucent.com
Lucent Technologies		Secure Technologies Dept.
1600 Osgood Street			 phone:	(978) 960-5767
Room 30-2-A31			 e-mail: 	[email-masked]
N. Andover, MA 01845		 fax: 	(978) 960-3240

Date: Mon, 22 Nov 1999 10:55:14 -0800
To: Russ Housley <[email-masked]>, Ed Gerck <[email-masked]>
From: Tony Bartoletti <[email-masked]>
Subject: Re: MOTION ON NR
Cc: "[email-masked]" <[email-masked]>, Nicholas Bohm <[email-masked]>

At 10:30 AM 11/22/1999 -0500, Russ Housley wrote:
>I cannot support this direction.  You suggest:
>
>      1'. nonRepudiation:  for verifying digital signatures used in providing a
>       service which protects against the signing entity  denying some action.
>
>The signer can always deny taking some action.  The point is having 
>evidence to refute the claim if it is false.
>
>Russ

Of course.  I think we must all agree that we use the phrase "prevent a denial"
to mean that we "prevent someone from prevailing in a denial".  If they deny
but lose, that's ok.

I would accept "prevailing in a denial of some action" just to eliminate one
more point of argument (yes, insert laughter here.)

___tony___ 

Tony Bartoletti                                             LL
IOWA Center                                              LL LL
Lawrence Livermore National Laboratory                LL LL LL
PO Box 808, L - 089                                   LL LL LL
Livermore, CA 94551-9900                              LL LL LLLLLLLL
phone: 925-422-3881   fax: 925-423-8081               LL LLLLLLLL
email: [email-masked]                                   LLLLLLLL

Date: Mon, 22 Nov 1999 13:50:56 -0500
To: "Don Johnson" <[email-masked]>
From: Russ Housley <[email-masked]>
Subject: RE: FIPS 186 and X9.42: One of these things is not like the other
Cc: "John C. Kennedy" <[email-masked]>, [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], Elaine Barker <[email-masked]>, Sharon Keller <[email-masked]>, "Simon Blake-Wilson" <[email-masked]>, "Phil Griffin" <[email-masked]>

Don:

At 09:36 AM 11/22/99 -0500, Don Johnson wrote:
>2. The order of the parameters in the domain parameters should be made
>consistent with X9.30 DSA, I think.  If this is not the way it is, it 
>should be
>changed in X9.42.

I find no ASN.1 in X9.30 part 1.

Russ

Date: Mon, 22 Nov 1999 10:50:20 -0800
From: Ed Gerck <[email-masked]>
To: Stefan Santesson <[email-masked]>
CC: Aram Perez <[email-masked]>, [email-masked]
Subject: DS and NR bit combinations, Re: proposed key usage text

Stefan Santesson wrote:

> Ed,
>
> I must admit that I was thinking about situations where a physical person
> sign information.
> I guess when the signer is a service, there will always be a context
> deciding the assurance value of the signature, which should be obvious for
> the user of the service.
>
> But I still think that there is a common understanding of the differences
> between non-repudiation and authentication and the way the NR-bit is
> distinguished from the DS-bit in implementations out there. And I think
> that understanding is rather close to what I was trying to say.
>
> But of course your example destroys my simplified definition :-(

When we use public discussions as a mechanism to mine the gold of truth,
verifying that some gold pieces are actually faux gold is beneficial to all
and IMO does not "destroy" but builds a better understanding.

And, in this case, David Kemp also added an argument (in a different thread)
which adds a perhaps even stronger reason than the one I stated in my
message, of why we need to keep DS vs NR functionality distinct:

 If you care about separating challenge signatures from signed messages,
  you will use different keys, with DS set for one and NR set for the other.

where not the assurance value associated with the signature is the needed
difference between authentication and NR but the integrity and origin values
of the signature that is used -- without any need for non-repudiation
whatsoever.

These reasons motivate the importance of this discussion (even if it needs to
be repeated from time to time, or may flare up from nowhere), because otherwise
we would lose resolution of important differences (plural) that we ought to
highlight and make clear -- not shove under the carpet.

In regard to Aram's question of why the two bits DS and NR should be allowed
to coexist or, if they coexist, what is the precedence order between them, there
are several possible answers of course.  The one that IMO would solve all problems
and create none uses the fact (already given in 2459) that all bits are independent for the
purpose of compliance testing -- while any application is free to provide its own
restrictions and/or requirements.  The combination of (DS=1,NR=1) can then
be used to signal the highest validity assurance possible in the system, in a graded
scale as I suggested before (see archives) of all *four* possible cases  for the two
bits of (DS,NR) and for which there is no bit precedence at all since all two-bit values
are assigned to different security functions.

The encoding of four validity values in two bits can be entirely optional (since all
bits are independent for the compliance testing) and yet afford a convenient grading
for *all* types of non-repudiation that have been discussed here -- as depicted in
the table already given (see archives).

In other words, the solution to this debate does not have to be either/or but can
actually profit from the diversity of views expressed here in order to provide a
comprehensive system that is able to interoperate in a large variety of circumstances,
including cross-interoperation (since the suggested validity scale for the two-bit
combination is ordered).

Cheers,

Ed Gerck

Date: Mon, 22 Nov 1999 10:36:08 -0800
To: [email-masked]
From: Tony Bartoletti <[email-masked]>
Subject: Re: NR-Bit Truth-In-Advertising
Cc: Tim Polk <[email-masked]>, [email-masked]

At 10:32 PM 11/19/1999 -0500, [email-masked] wrote:
>     I don't think that the list of claims given (denial of ownership, key
>compromise, etc. ) is the list of claims that the NR service protects
>against.  In fact, that was my guess at the list of claims which the NR
>service may not be able to guarantee against.  What the NR services should
>be able to do is to provide a level of certainty for the validity of the
>specified signature high enough that a party disclaiming such a signature
>needs to establish one of those claims with some level of real proof - the
>level required not being a technical matter which this group can help with.
>     Some NR products may help weaken or eliminate some of the claims on
>the list, but I seriously doubt that PKIX can do much about signer
>incompetence or duress.
>
>          Tom Gindin

Tom,

I do agree, and in that respect I support your suggested version.  But to
those who want the bit to say "this CA is OK with using such a cert to
support a service that hopes to provide some or all of those provisions"
then at least the listed provisions give someone more of a clue than just
"protects against the signing entity falsely denying some action".  And I
still object to "signing entity", since the term tends to hide that fact
that "presumption begins with the cert-holder".

I keep returning to the point that these Key Usage bits and definitions
are mostly guidance for the folks that make "conforming" software.  That
is why your version is reasonable.  I would have some idea what I was
supposed to conform to.  The standing definition leaves far too much
to my limited imagination... :)

___tony___

Tony Bartoletti                                             LL
IOWA Center                                              LL LL
Lawrence Livermore National Laboratory                LL LL LL
PO Box 808, L - 089                                   LL LL LL
Livermore, CA 94551-9900                              LL LL LLLLLLLL
phone: 925-422-3881   fax: 925-423-8081               LL LLLLLLLL
email: [email-masked]                                   LLLLLLLL

Date: Mon, 22 Nov 1999 09:35:42 -0800
Subject: Re: proposed key usage text
From: "Aram Perez" <[email-masked]>
To: PKIX <[email-masked]>

Al Arsenault wrote:

> Aram Perez wrote:
>> 
>> Hi Russ,
>> 
>> > Hi Aram.
>> >
>> >  >>       The digitalSignature bit is asserted when the subject public key
>> >  >>       is used with a digital signature mechanism to support security
>> >  >>       services other than non-repudiation (bit 1), certificate signing
>> >  >>       (bit 5), or revocation information signing (bit 6). Digital
signa-
>> >  >>       ture mechanisms are often used for entity authentication and data
>> >  >>       origin authentication with integrity.
>> >  >>
>> >  >>       The nonRepudiation bit is asserted when the subject public key is
>> >  >>       used to verify digital signatures used to provide a non-
>> >  >>       repudiation service which protects against the signing entity
>> >  >>       falsely denying some action, excluding certificate or CRL
signing.
>> >  >>       In the case of later conflict, a reliable third party may deter-
>> >  >>       mine the authenticity of the signed data.
>> >  >>
>> >  >>       Further distinctions between the digitalSignature and nonRepudia-
>> >  >>       tion bits may be provided in specific certificate policies.
>> >  >
>> >  > What is happens when both the digitalSignature and nonRepudiation bits
are
>> >  > set? Does one of them take precendence?
>> >
>> > I guess that you missed our point altogether.  There is no precedence.  If
>> > both the digitalSignature and nonRepudiation bits are set, then the public
>> > key may be used with a digital signature mechanism to support
>> > authentication and integrity and it may also be used to verify digital
>> > signatures used to provide non-repudiation.  One public can might be used
>> > for both purposes.
>>
>> But how do you distinguish between what use was intended? If someone
>> captures a message that I signed for "authentication and integrity" and
>> another message that I signed for "non-repudiation", how does a third party
>> distinguish which use was intended?
>>
>> I have seen many authentication protocols that require the party being
>> authenticated to sign a challenge (that is supposed to be a random number or
>> a nonce). Now suppose that I'm trying to get access to a system that instead
>> of sending me a random challenge, sends me the following message: "I agree
>> to sell 1000 shares of Apple at $10.00 per share." My software will blindly
>> sign the message and send my certificate which has the DS and NR bits set.
>> Am I now obligated to sell 1000 shares of Apple at $10.00? Can I prove to a
>> third party that I was only trying to do authentication and not
>> non-repudiation?
>>
>> Regards,
>> Aram Perez
>
>
> AWA:  Aram, that's what the rest of the non-repudiation system is for.
> Your key has been shown to have been used to sign a message.  You do not
> want to take the action indicated in the signed message.  Among other
> things, the following questions have to be answered:
>
>  1 - was it really you that caused the signature to occur?  Was your key
> compromised, or your workstation used by one of your co-workers without
> your knowledge/permission?  What evidence exists that it really was or
> was not you?
>
>  2 - did you know what you were signing?  Should you have known?  What
> evidence is there that you took a conscious effort to understand and
> verify before signing?
>
>  3 - was the key used appropriate for the message signed?
>
> The value of the NR bit only enters into #3 here.  And I suspect you
> will find a lawyer willing to argue for you and against you regardless
> of the value of that bit.
>
> A non-repudiation system consists of a lot more than just one bit in a
> certificate.

I totally agree with your statements. I have previously stated that for
non-repudiation you need to look at the "system" and not just the bit. And
since this bit seems to cause more confusion and hence discussion than any
other bit, I personally believe it should be deprecated (as I have also
stated previously). If we who claim to be security experts can't agree on
the meaning and value of the bit, how are programmers trying to implement
the standard supposed to know what to do?

Regards,
Aram Perez

Date: Mon, 22 Nov 1999 09:21:20 -0800
Subject: Re: proposed key usage text
From: "Aram Perez" <[email-masked]>
To: PKIX <[email-masked]>

David Kemp wrote:

>> >
>> > I guess that you missed our point altogether.  There is no precedence.  If
>> > both the digitalSignature and nonRepudiation bits are set, then the public
>> > key may be used with a digital signature mechanism to support
>> > authentication and integrity and it may also be used to verify digital
>> > signatures used to provide non-repudiation.  One public can might be used
>> > for both purposes.
>>
>> But how do you distinguish between what use was intended? If someone
>> captures a message that I signed for "authentication and integrity" and
>> another message that I signed for "non-repudiation", how does a third party
>> distinguish which use was intended?
>
>
> If you care about separating challenge signatures from signed messages,
> you will use different keys, with DS set for one and NR set for the other.
>
> There's no point in defining a "precedence" to handle the case where
> both bits are set, because no one who cares will set both.  Those
> who choose to use one key for two functions are accepting the risk
> that an authentication server will send them a contract and their
> client will blindly sign it.
>

This is one of my big security pet peeves: Why do we, who claim to be
security experts, allow non-security persons to take what we would consider
unacceptable risks?

Regards,
Aram Perez

Date: Mon, 22 Nov 1999 09:14:24 -0800
Subject: Re: proposed key usage text
From: "Aram Perez" <[email-masked]>
To: PKIX <[email-masked]>

Hi Lynn,

> 
> 
> we are doing something like that for AADS radius (i.e. being able to upgrade
> something like 99% of the current internet ISP authentication infrastructure
to
> digital signature authentication). The strategy is that the ISP sends a
> challenge string ... basically somehting like "please authenticate 'userid'"
> with a time-stamp/nonce (in lieu of the "please enter password" message), the
> user then adds their own nonce, signs it and returns it.

Having the party being authenticated add their own nonce is a step that many
authentication protocols forget and hence the situation I described.

[snip]

Regards,
Aram Perez

Date: Mon, 22 Nov 1999 11:31:07 -0500 (EST)
From: "David P. Kemp" <[email-masked]>
Reply-To: "David P. Kemp" <[email-masked]>
Subject: Re: We have to choose serialNumber instead of dnQualifier NOW!!!
To: [email-masked], [email-masked]
Cc: [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked]
Content-MD5: h/8toLjue5Ovq8uOF9WUAw==

> From: Magnus Nystrom <[email-masked]>
> 
> As I previously stated, I am not too convinced serialNumber is the best
> alternative. Squeezing in new semantics in an existing attribute may cause
> more problems than it solves. Since any change in the semantics of
> serialNumber will affect X.520, it ought to affect X.521 (e.g. the
> 'person' object class) as well.

Magnus,

Three questions:

 1) For systems which use an attribute to hold a device number, would
using the same attribute to hold a person number cause any problems?

 2) For systems which use an attribute to hold a person number, would
using the same attribute to hold a device number cause any problems?

 3) Would it be any easier to add a new attribute to X.500, X.520, and
X.521 than it would be to add the serialNumber attribute in the same
places?

> I guess one possibility is to re-name
> serialNumber as well, to something more declarative, like "uniqueNumber"
> or similar, but it would be just as easy to define a new attribute - X.520
> and X.521 will have to change anyway if they are to support this at all.
> Note: I am not saying I object to this proposal, just that I think we need
> some more time.

Based on Sharon's data and SEIS usage, there appears to be historical
experience with using serialNumber for people.  The semantics of a
"device serial number" match exactly the semantics of
"employee/student/customer/citizen number"; if one were to design
the best possible system from scratch, would it not use one attribute to
refer to all objects rather than having separate attributes to express
the identical semantics over separate object classes?  Isn't commonName
used for all types of objects?

I can't think of a single advantage to having two attributes, and there
are real disadvantages to forcing renaming in existing systems which
use serialNumber for people.

Date: Mon, 22 Nov 1999 11:34:40 -0500
To: Stefan Santesson <[email-masked]>
From: Russ Housley <[email-masked]>
Subject: Re: We have to choose serialNumber instead of dnQualifier NOW!!!
Cc: [email-masked], [email-masked], Ella Paton Bassett <[email-masked]>, [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked]

Stefan:

I can live with this approach.

Russ

At 12:28 PM 11/22/99 +0100, Stefan Santesson wrote:
>All,
>
>Regarding the issue to select an attribute type for storage of personal
>identifiers of certificate subjects.
>
>Finland's national electronic identity project starts FULL production in 2
>weeks, where they will  issue certificates to the people of Finland in a
>large scale.
>
>They need to know TODAY, what attribute type they should use to store
>electronic identity numbers of Finnish citizens.
>
>- I think the latest discussions have shown that dnQualifier is out of the
>picture.
>
>- UID is useless because of the bit string syntax.
>
>- There is no time to define a new attribute.
>
>So they will have to go with serialNumber. A big reason for this is also
>that the Germans have decided to go with the serialNumber attribute as
>well. So now Finland and Germany will at least be compliant.
>
>
>So folks, as I see this we have no choice other than to support
>serialNumber at this moment.
>
>I suggest that we:
>
>- Add serialNumber to son of rfc2459 supportedAttributes as a MUST
>implement attribute (i.e. compliant applications MUST be able to understand
>it).
>
>- Keep dnQualifier in son of rfc2459, with a note stating it's intended
>purpose, the fact that new certificates should not break this intended
>usage, and also saying that clients should expect that some existing
>certificates may use this attribute to hold any type of value.
>
>- specify use of serialNumber but NOT dnQualifier in the Qualified
>Certificates profile.
>
>It would help to get your immediate support for this. Can you live with it??
>
>/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
>-------------------------------------------------------------------

Date: Mon, 22 Nov 1999 11:31:24 -0500
To: Stefan Santesson <[email-masked]>
From: Russ Housley <[email-masked]>
Subject: Re: proposed key usage text
Cc: "Aram Perez" <[email-masked]>, [email-masked]

At 10:47 AM 11/22/99 +0100, Stefan Santesson wrote:
>So to me there is no such thing as signing messages just for authentication
>purpose but NOT for non-repudiation. Not in real life.
>
>Can anyone show me a REAL implementation where a messages are signed, where
>this is strictly NOT non-repudiation.

Yes.  X.509 was originally written for X.500 Directory Strong 
Authentication.  This is a case where authentication, not non-repudiation, 
is implemented.

Russ

Date: Mon, 22 Nov 1999 11:00:16 -0500
To: "John C. Kennedy" <[email-masked]>
From: Russ Housley <[email-masked]>
Subject: RE: FIPS 186 and X9.42: One of these things is not like the other
Cc: <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>

John:

You have been out of the loop for over two years, and your observation are 
simply incorrect!

The people that have been working on the PKIX and S/MIME standards that 
refer to X9.42 have been given every version of the document as it became 
available to the X9F1 working group participants.  And, X9F1 has worked to 
ensure that they did not change the parts of X9.42 that were adopted by the 
IETF.

Peter may not like the minor differences between X9.42 and DSA.  But the 
IETF documents are aligned with the X9.42 (just as they claim).  By the 
way, FIPS 186 contains no ASN.1; it only contains the algorithm specification.

Russ

At 01:17 AM 11/21/99 -0800, John C. Kennedy wrote:
>(A long but hopefully illuminating follow-up regarding ANSI X9.42)
>
>(**Summary: The use or referencing of the ANSI X9.42 (Diffie-Hellman) drafts
>in IETF standards has resulted in the propagation of a number of errors and
>inconsistencies within IETF drafts and RFCs.  IMHO, it is questionable
>whether the still unratified ANSI X9.42 draft should be used as a basis or
>even a reference for ongoing IETF Diffie-Hellman protocol standardization
>work.)
>
>Peter,
>
>I was the editor of the ANSI X9.42 Diffie-Hellman draft up until about April
>of 1997 when I changed employers and passed the X9.42 editing torch.  Since
>my current work has given me a reason to wade back into the IETF process, I
>wanted to share a few comments and provide some additional data on the
>apparent state of Diffie-Hellman in IETF work.  As I revisit things 2.5
>years later it seems to still be a bit of a mess in need of some tidying up.
>
>(1) RFC 2459 (PKIX) references a December 1997 draft of ANSI X9.42.  I
>believe this may be a draft that I "strategically distributed" to a few
>select people working in IPSEC, PKIX, and other IETF working groups around
>that time.  ANSI X9F has never had a lot of interest in seeing X9.42
>reviewed or adopted by IETF.  [In fact, it is ridiculous that after almost
>five years of work and innumerable rewrites, neither ANSI or NIST have
>published an authoritative interoperability standard for one the most
>fundamental and powerful public key techniques for key agreement we have.
>(Hint: It is not because of patents or because it is too difficult to
>communicate.)]
>
>(2) RFC 2631 (Diffie-Hellman Key Agreement Method) references a 1998 draft
>of X9.42.  This X9.42 draft is probably the one made available by ANSI to
>IEEE P1363 members at
>http://grouper.ieee.org/groups/1363/private/x9-42-10-02-98.doc (You will
>need an IEEE P1363 password to get at this.)  This draft is better than the
>1997 draft, but still has problems.  Since I have not been involved with
>ANSI for about 3 years, I can't comment on where the X9.42 draft currently
>stands.  Since the X9.42 draft document is (still!) not public, it is not
>clear whether it is relevant to the IETF's work anyway.  RFC 2631 is
>currently a proposed standard in IETF.  Since RFC 2631 propagates errors
>that existed in the 1998 X9.42 draft, a second look at it is probably called
>for. (These errors are noted below)
>
>(3) RFC 2412 (OAKLEY Key Agreement) doesn't reference any Diffie-Hellman
>standards.  While the techniques given in this document are mathematically
>accurate and certainly filled a gap in the IPSEC work at the time, the
>OAKLEY RFC doesn't quite provide all the pieces needed to link up with PKIX
>and some other security standards.
>
>(4) The following drafts contain relevant references to Diffie-Hellman or
>related protocols.  The first two reference RFC 2631 and the second
>specifies a new DH variant altogether:
>draft-ietf-smime-small-subgroup-02.txt
>draft-ietf-pkix-dhpop-02.txt
>draft-ietf-secsh-transport-06.txt
>
>(5) Both of the ANSI documents currently referenced were drafts and probably
>weren't the best basis for IETF standards.  Given the lack of anything else
>to point to, I can't say I blame the authors, however.  They certainly meant
>well.  What is also unfortunate is that IETF community has not been provided
>with access to more current X9.42 drafts.  This is, IMHO, probably related
>to the situation I pointed out in (1).
>
>Now, in reponse to your observations:
>
>(6) RFC 2631 states "X9.42 requires that the private key x be in the
>interval [2, (q - 2)]"
>In other words, (1 < x < q-1).  **It is quite clear that the referenced
>X9.42 draft is not only wrong but inconsistent**.  And in a number of
>places.  The Diffie-Hellman private key x should be chosen in the closed
>interval [2^(m-1), q-1], where m is the minimum length in bits acceptable
>for the private key.  (Typically m>=160, but your mileage may vary...)  This
>is consistent with security recommendations in the current IEEE P1363
>documents as well as definitions in draft-ietf-smime-small-subgroup-02.txt,
>draft-ietf-pkix-dhpop-02.txt.  (If there is a mathematical subtlety I have
>forgotten and x should be in [2^(m-1), q-2], I hope someone speaks up to
>correct me.)
>
>Note that choosing x in [1, q-1] will work just fine mathematically, but
>does not reflect or enforce the minimum key size requirement.  Note that if
>the size of q is at least a few bit greater than m and you are using a good
>RNG to pick x, the point is probably moot anyway.  If you are using a
>long-term (aka "static") DH keys, however, it probably not a bad idea to put
>the minimum keysize check in your keygen routine as a "belt and suspenders"
>type measure.
>
>(7) The domain parameter generation routines in X9.42 were in fact derived
>from those in the FIP 186 spec to allow re-use of DSA parameters (p, q, and
>g) with X9.42 if desired.  I can't say I am a big fan of this because it
>forces q to 160 bits which is probably not appropriate if you intend to
>enforce a minimum DH private key size greater than 160.
>
>(8) The parameter order switch was not a deliberate booby trap, although
>these types of things do help to keep crypto engineers on their toes. :)  As
>I recall, the parameters q and j were added when concerns about small
>subgroup attacks on Diffie-Hellman surfaced.  It is more of a coincidence
>that the DSA algorithm exploits the use of a subgroup also defined by a
>prime called q.  In other words, DSA included q from the beginning while
>X9.42 added q as a security enhancement.  The ASN.1 encoding choices are an
>artifact of the development process, not a deliberate reversal.  If you feel
>like lobbying ANSI X9F to change the ordering to make everyone's life
>easier, have at it.  I wouldn't hold my breath however. :)
>
>(9) RFC 2459 (PKIX) shows ASN.1 encoding of the DH parameters as:
>  DomainParameters ::= SEQUENCE {
>               p       INTEGER, -- odd prime, p=jq +1
>               g       INTEGER, -- generator, g
>               q       INTEGER, -- factor of p-1
>               j       INTEGER OPTIONAL, -- subgroup factor
>               validationParms  ValidationParms OPTIONAL }
>
>         ValidationParms ::= SEQUENCE {
>               seed             BIT STRING,
>               pgenCounter      INTEGER }
>
>whereas the 1998 X9.42 draft shows them as:
>
>DomainParameters ::= SEQUENCE {  -- Galois field group parameters
>    p                INTEGER,        -- odd prime, p = jq + 1
>    g                INTEGER,        -- generator, g
>    q                INTEGER,        -- prime factor of p-1
>    j                INTEGER,        -- subgroup factor, j >= 2
>    validationParms  ValidationParms OPTIONAL
>(**Note q is no longer optional.** JK)
>
>if you can find a copy of the 1997 draft (which I happen to have) we see the
>original version:
>
>DomainParameters ::= SEQUENCE {  -- Galois field group parameters
>    p                INTEGER,        -- odd prime, p = jq + 1
>    g                INTEGER,        -- generator, g
>    q                INTEGER OPTIONAL,        -- prime factor of p-1
>    j                INTEGER OPTIONAL,        -- subgroup factor, j >= 2
>    validationParms  ValidationParms OPTIONAL
>
>(This early draft reflects my admitted ignorance of proper ASN.1 at the
>time. You cannot have multiple optional INTEGERS without tags on them.)
>
>My guess is that the middle version (i.e., with only ValidationParms
>optional) is the preferred version, which means RFC 2459 should probably be
>changed.  I do not know what the current X9.42 draft gives.
>
>****Conclusion****
>(10) Because of the aforementioned errors and inconsistencies, I have
>serious reservations about the continued use or referencing of ANSI X9.42 in
>IETF drafts or standards.  The use or referencing of the ANSI X9.42 draft in
>IETF standards has resulted in the propagation of a number of errors and
>inconsistencies within IETF drafts and RFCs.  IMHO, it is questionable
>whether the apparently still unratified and possibly unstable ANSI X9.42
>draft should be used as a basis or reference for ongoing IETF Diffie-Hellman
>protocol standardization efforts.  Because of this, I respectfully submit
>that the IETF should consider whether RFC 2631 should be deprecated and
>rewritten in a manner which removes unnecessary references to the mysterious
>and forever-unpublished ANSI X9.42 draft.
>
>
>-John Kennedy
>[email-masked]
>
>
>
>-----Original Message-----
>From: [email-masked] [mailto:[email-masked]]
>Sent: Sunday, November 21, 1999 1:58 PM
>To: [email-masked]; [email-masked]
>Subject: FIPS 186 and X9.42: One of these things is not like the other
>
>
>FIPS 186/X9.30 and X9.42 (and by extension RFC 2631) share the same key
>generation algorithm, and have domain parameters which look identical,
>however
>there are two subtle differences between them, one of which is really
>annoying.
>
>The annoying difference is that when writing the domain parameters, the
>order
>of q and g is reversed for FIPS 186 and X9.42 keys, so that while DSA domain
>parameters are written (p, q, g), exactly the same domain parameters when
>viewed as X9.42 values are written (p, g, q).  This isn't helped by the fact
>that in many fonts lowercase q and g look very similar.  Apart from the fact
>that it's a booby-trap for implementors, it also means that if the domain
>parameters are identified in the traditional way (SHA-1 hash), identical
>parameters will appear to be different depending on whether you're
>interpreting
>them as DSA/KEA or DH parameters.
>
>The second difference is in the allowed range for x:
>
>   FIPS 186: 0 < x < q (ie x = 1...q-1)
>   X9.42: 1 < x <= q-2 in one place, [2...q-2] in another (ie x = 2..q-2)
>
>This looks like a transcription error from FIPS 186, given that using any
>x < ~2^160 is unsound I can't see why there'd be any difference between 1
>and 2
>as a lower bound.
>
>Perhaps new RFC's which cover this (eg son-of-RFC2459) could include
>warnings
>to the effect that although the parameters are the same internally, their
>external representations differ.
>
>Does anyone know why X9.42 decided to reverse the parameter order?
>
>(The motivation for this post is that ages ago I solved the problem of the
>  reversed parameters by swapping the pointers for the X9.42 g and q values
>so
>  they were read and written in the correct order, recently I was looking
>  through the code and wondered why it was working fine for both
>interpretations
>  of parameter ordering.  There's now a big comment block by the code
>explaining
>  the Bug which Isn't)
>
>Peter.

From: Hans Nilsson <[email-masked]>
To: "[email-masked]'" <[email-masked]>, Stefan Santesson <[email-masked]>, [email-masked]
Cc: [email-masked], [email-masked], [email-masked]
Subject: RE: We have to choose serialNumber instead of dnQualifier NOW!!!
Date: Mon, 22 Nov 1999 17:06:23 +0100

Magnus,

The German "Working group of Trust Centers for Digital Signatures" have in
their current draft interoperability specification also decided to use
serialNumber as "Name differentiator". So in your words, is Gemany "another
lost case" :-) ?

I dont think so. I think this is the only reasonable way to go forward. This
is an item that we have discussed for *years* now, after the initial Swedish
Allterminal use of serialNumber, and when we finally decided on something
else, we goofed. I would understand the objections if anyone raised his
voice and said: "Hey wait, we are already using serialNumber for this device
here, and please dont change the semantics, because it would ruin our
system". But I have not heard *anyone* using serialNumber for anything else
than a  "unique identifier of a person".

Hans

-----Original Message-----
From: Magnus Nystrom [mailto:[email-masked]]
Sent: den 22 november 1999 13:40
To: Stefan Santesson
Cc: [email-masked]; Ella Paton Bassett; [email-masked];
[email-masked]; [email-masked]; [email-masked];
[email-masked]; [email-masked];
[email-masked]; [email-masked]; [email-masked];
[email-masked]; [email-masked]
Subject: Re: We have to choose serialNumber instead of dnQualifier
NOW!!!

Taking advantage of the timezone difference to be the first to
respond...;)

I must say I am a bit reluctant to choose a long-term solution because of
short-term time constraints in this case. Finland is, in my view, a "lost
case" anyway, our decision won't affect them much right now anyway. What
says "There is no time to define a new attribute"? Better to think this
through properly and let everyone express their view than to rush
something which may not be the optimal solution.

As I previously stated, I am not too convinced serialNumber is the best
alternative. Squeezing in new semantics in an existing attribute may cause
more problems than it solves. Since any change in the semantics of
serialNumber will affect X.520, it ought to affect X.521 (e.g. the
'person' object class) as well. I guess one possibility is to re-name
serialNumber as well, to something more declarative, like "uniqueNumber"
or similar, but it would be just as easy to define a new attribute - X.520
and X.521 will have to change anyway if they are to support this at all.
Note: I am not saying I object to this proposal, just that I think we need
some more time.

Regards,
-- Magnus
Magnus Nystrom		Email: [email-masked]
RSA Laboratories

On Mon, 22 Nov 1999, Stefan Santesson wrote:

> All,
> 
> Regarding the issue to select an attribute type for storage of personal
> identifiers of certificate subjects.
> 
> Finland's national electronic identity project starts FULL production in 2
> weeks, where they will  issue certificates to the people of Finland in a
> large scale.
> 
> They need to know TODAY, what attribute type they should use to store
> electronic identity numbers of Finnish citizens.
> 
> - I think the latest discussions have shown that dnQualifier is out of the
> picture.
> 
> - UID is useless because of the bit string syntax.
> 
> - There is no time to define a new attribute.
> 
> So they will have to go with serialNumber. A big reason for this is also
> that the Germans have decided to go with the serialNumber attribute as
> well. So now Finland and Germany will at least be compliant.
> 
> 
> So folks, as I see this we have no choice other than to support
> serialNumber at this moment.
> 
> I suggest that we:
> 
> - Add serialNumber to son of rfc2459 supportedAttributes as a MUST
> implement attribute (i.e. compliant applications MUST be able to
understand
> it).
> 
> - Keep dnQualifier in son of rfc2459, with a note stating it's intended
> purpose, the fact that new certificates should not break this intended
> usage, and also saying that clients should expect that some existing
> certificates may use this attribute to hold any type of value.
> 
> - specify use of serialNumber but NOT dnQualifier in the Qualified
> Certificates profile.
> 
> It would help to get your immediate support for this. Can you live with
it??
> /Stefan

Date: Mon, 22 Nov 1999 10:30:38 -0500
To: Ed Gerck <[email-masked]>
From: Russ Housley <[email-masked]>
Subject: Re: MOTION ON NR
Cc: "[email-masked]" <[email-masked]>, Nicholas Bohm <[email-masked]>

I cannot support this direction.  You suggest:

      1'. nonRepudiation:  for verifying digital signatures used in providing a
       service which protects against the signing entity  denying some action.

The signer can always deny taking some action.  The point is having 
evidence to refute the claim if it is false.

Russ

At 09:55 AM 11/20/99 -0800, Ed Gerck wrote:

>All:
>
>Looking at all NR suggestions here, it seems that above all
>we must not introduce a judgement of value (the word "falsely"
>in "falsely denies")which does NOT exist in non-repudiation
>proofs and which opens a can of worms for both engineers (we
>can't measure it) and lawyers (they can't prove it).  Worse, we
>need to recognize that the word "falsely" is entirely lame in this
>context, both for engineers and for lawyers.
>
>So, instead of having a definition which anyone (engineers and lawyers)
>could apply *and build upon*, we are faced in the current PKIX wording with
>a jury decision carved in stone in a protocol.  This is what this discussion
>oftentimes miss -- we should impose the *least* burden of compliance.
>
>And, the least burden of compliance comes from recognizing that the call
>whether the denial was falsely or truthfully made is NOT ours.  What we
>*can* do is provide a protocol NR service *exactly* as predicated in X.509
>(which does NOT include authentication, as I analyzed on 18 Nov 1999),
>and which protects against REPLAY and REPUDIATION. Both terms are
>well-defined in X.509 Appendix B.1 as:
>
>  Replay -- The recording and subsequent replay of a communication
>  at some later date.
>
>  Repudiation -- The denial by a user of having participated in part or
>  all of a communication.
>
>This is IT, folks.  Simple, doable, in our turf. Let's just follow X.509 
>and lint
>its inconsistencies for PKIX -- according to the term REPUDIATION
>as *already* defined in X.509. Two definitions of X.509 need IMO to
>be linted in this regard, because they are in conflict with one another
>and with the  corpus of X.509 -- as I analyzed on 18 Nov 1999, here.
>The definitions to be linted are:
>
>1. nonRepudiation:  for verifying digital signatures used in providing a
>  nonrepudiation service which protects against the signing entity falsely
>  denying some action
>
>which should become (eliminating the circular reference to
>"nonrepudiation" itself and the lame reference to "falsely"):
>
>1'. nonRepudiation:  for verifying digital signatures used in providing a
>  service which protects against the signing entity  denying some action.
>
>and,
>
>2. Non-repudiation -- This service provides proof of the integrity and origin
>  of data -- both in an unforgeable relationship -- which can be verifed 
> by any
>  third party at any time.
>
>which is conflicting with the first, wrong (see why in my mail of 18 Nov 1999)
>and should be simply replaced with 1' (of course, one should NEVER define
>the same thing in two different ways in the same document).
>
>For lawyer remarks on non-repudiation and the distinction we ourselves
>often miss here between technical and legal assessments, please see [1].
>
>I call attention to the fact that the remarks *include* the use of the word
>"falsely" from the viewpoint of the risk-bearer (who does not want the
>signer to falsely deny an act) , but *exclude* that same word from
>the viewpoint of proof  (where it is irrelevant whether the denial was
>false or truthful -- whether the signer actually made the signature or not,
>whether the signer actually intended to make the signature or not, etc.).
>I believe this explains the dilemma facing those (including myself) that
>see the unfairness of setting up a system that can disallow truthful
>denials, by recognizing that "truth" is a matter of reference -- if the
>customer wants his check to be cashed without the bank calling (and,
>charging) him for every check to be paid, then the client must accept
>that the bank needs to independently verify whether the signature is
>correct or not, truthful or false. This is the truth that the client accepts,
>and accepts it because she profits from it.
>
>Of relevance is only if the technical assesment can be used (and, herein
>lies the slippery slope for this PKIX WG, in our social liability and ethic
>as engineers) to support a legal assessment holding that the apparent
>maker of the signature is bound by it  -- *whether she made it or not*.
>
>This opinion confirms that non-repudiation is that which can prevent
>even truthful denials, not only false denials.  So, non-repudiation
>has to do, logically speaking, only with preventing denials (since both
>complementary cases of truthful and false are included and decided
>elsewhere).
>
>Thus, let's not try to include jury, judge and executioner in our protocols.
>Therefore, to be concrete I propose the following *minimum* changes:
>
>----------------
>  MOTION ON NR
>
>  That definition 1'  be accepted, that definition 2 be replaced with 1' --
>  all in their equivalent places in PKIX from X.509. The X.509 definition
>  of repudiation stays unchanged.
>
>  The actual specification how the NR services are provided need not
>  concern PKIX, as they are bound to be different for each realm
>  of application (common law, civil law, military, government, private
>  sector agreements, intra-company, etc.), CPS, etc. Thus, the
>  specification of NR services is to be considered outside the scope
>  of PKIX.
>
>  Tom Gidin's proposed RFC provides one example of how NR services
>  can be implemented. Implementors are free to devise their own
>  examples, if  needed.
>
>  The current PKIX specification that keyUsage bits are independent
>  should NOT be changed, and wording to the contrary in PKIX should
>  NOT be used for compliance testing (they are merely examples of usage).
>----------
>
>
>Cheers,
>
>Ed Gerck
>
>
>[1] Remarks received in private from Nicholas Bohm, a lawyer that used
>to work for banks in the City of London, Cc'd above.
>
>1       It is often (although not invariably) a desirable objective of a 
>system
>to provide a non-repudiation service, either to prevent a signatory from
>falsely repudiating a genuine signature or to prevent the recipient of a
>message from falsely denying its receipt.  Whether a particular system
>provides such a service, and the degree of its reliability, are matters for
>technical assessment.
>
>2       If a system is believed to provide a reliable non-repudiation service,
>and is used in circumstances where legal consequences may follow the
>signing or receipt of a message, the contractual terms which establish the
>legal framework for the operation of the system may provide that what the
>system recognises as a valid signature shall bind the apparent maker,
>whether she made the signature in fact or not; or that where the system
>records a message as having been received, the apparent recipient shall be
>treated as having received it, whether he received it in fact or not.  Such
>terms may be described as providing for the non-repudiation of signatures
>or receipt of messages.
>
>3       A technical assessment may prove that it is highly probable that a
>signature was made by its apparent maker.  A legal assessment may hold that
>the apparent maker of a signature is bound by it whether she made it or
>not.  These two conclusions seem similar, but operate in different realms
>of thought.  Debate about non-repudiation sometimes overlooks the
>distinction, to the evident frustration of the lawyers and engineers whose
>arguments pass through one another like angry ghosts.

Date: Mon, 22 Nov 1999 15:57:04 +0100
To: [email-masked]
From: Stefan Santesson <[email-masked]>
Subject: Re: We have to choose serialNumber instead of dnQualifier NOW!!!
Cc: [email-masked], Ella Paton Bassett <[email-masked]>, [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked]

Good,

We have a dialogue here. I don't think the Finnish case is lost, but it is
urgent. They will have a meeting tomorrow morning and they now ask why we
don't use the unique identifier attribute from rfc 1274. I supply the mail
from Jyri Tähtinen below:

I remember that we considered this attribute a long time ago in the Swedish
EID project but that we abandoned it for some reason.

/Stefan

At 02:50 PM 11/22/99 +0200, Jyri Tähtinen wrote:
>Dear Mr. Santesson, cc: FINEID people
>
>I think Vesa Vatka and Ari Saapunki have been in touch with you in this
>dNQualifier va serialNumber issue.
>
>My question is:
>
>- why don't PKIX people specify uniqueIdentifier (PilotAttributeType.44)
>for storage of uniquely identifying data? This attribute should be
>widely known (from rfc1274) and it has directory string syntax.
>
>(Of course there can be a problem, if client software don't understand
>this attribute type which is part of subject name...)
>
>- the serialNumber attribute type is not good, because
>
>a. it already identifies also the certificate serial number in
>directory! The certificates are stored in directory and named with cert.
>serialnumber.
>I have quoted below part of a message from you (that Markku Kontio
>forwarded to me).
>
>b. it is more related to devices than subjects of certification
>
>By the way, do you have suggestions which attribute to use for
>certificate serialNumber if you use serial number for UID?
>Should we define new attribute type certificateSerialNumber or something
>like that?
>
>Anyway, it would be wise to use same attributes in certificate and in
>directory - otherwise there is big risk of misunderstandings. (If UID is
>stored in serialNumber in certificate but in directory serialNumber is
>used to store cert.serial number!)
>
>> After all mails so far I must say that the current status of my 
>> understanding is that we use the dnQualifier attribute wrong, if we use it 
>> for this purpose. 
>>
>> That's the first thing we must agree on. Can we do that? 
>>
>> The second is what we should do about it. We have some choices. 
>>
>> 1) To continue to use dnQualifier even though we break it's intended
purpose 
>> 2) To use another existing X.520 attribute (serialNumber or UID) 
>> 3) To find another suitable attribute, defined by someone else 
>> 4) To define a new attribute. 
>
>I suggest choice nr 3 and the solution would be from RFC1274:
>
>9.3.34.  Unique Identifier
>
>   The Unique Identifier attribute type specifies a "unique identifier"
>   for an object represented in the Directory.  The domain within which
>   the identifier is unique, and the exact semantics of the identifier,
>   are for local definition.  For a person, this might be an
>   institution-wide payroll number.  For an organisational unit, it
>   might be a department code.
>
>     uniqueIdentifier ATTRIBUTE
>         WITH ATTRIBUTE-SYNTAX
>             caseIgnoreStringSyntax
>             (SIZE (1 .. ub-unique-identifier))
>     ::= {pilotAttributeType 44}
>
>
>Could you comment on that as soon as possible, please!
>
>We will have a meeting on this issue early on Tuesday morning.
>
>Regards,
>
>Jyri Tähtinen
>
>-- 
> --------------------------------  - - - - - - - - - - - - - - - - - - -
>  J y r i   T ä h t i n e n        Development Manager, M.Sc.
> 
>  Helsinki Telephone Corporation   Telephone    +358 9 606 4546
>  Kolumbus Services                Mobile phone +358 50 5666599
>  Asemapäällikönkatu 2 (PAD510)    Fax          +358 9 606 3290 
>  P.O.Box 133                      E-mail       [email-masked]
>  FIN-00521 HELSINKI               <PGP available on request>
> --------------------------------  - - - - - - - - - - - - - - - - - - -

At 01:40 PM 11/22/99 +0100, Magnus Nystrom wrote:
>
>Taking advantage of the timezone difference to be the first to
>respond...;)
>
>I must say I am a bit reluctant to choose a long-term solution because of
>short-term time constraints in this case. Finland is, in my view, a "lost
>case" anyway, our decision won't affect them much right now anyway. What
>says "There is no time to define a new attribute"? Better to think this
>through properly and let everyone express their view than to rush
>something which may not be the optimal solution.
>
>As I previously stated, I am not too convinced serialNumber is the best
>alternative. Squeezing in new semantics in an existing attribute may cause
>more problems than it solves. Since any change in the semantics of
>serialNumber will affect X.520, it ought to affect X.521 (e.g. the
>'person' object class) as well. I guess one possibility is to re-name
>serialNumber as well, to something more declarative, like "uniqueNumber"
>or similar, but it would be just as easy to define a new attribute - X.520
>and X.521 will have to change anyway if they are to support this at all.
>Note: I am not saying I object to this proposal, just that I think we need
>some more time.
>
>Regards,
>-- Magnus
>Magnus Nystrom		Email: [email-masked]
>RSA Laboratories
>
>On Mon, 22 Nov 1999, Stefan Santesson wrote:
>
>> All,
>> 
>> Regarding the issue to select an attribute type for storage of personal
>> identifiers of certificate subjects.
>> 
>> Finland's national electronic identity project starts FULL production in 2
>> weeks, where they will  issue certificates to the people of Finland in a
>> large scale.
>> 
>> They need to know TODAY, what attribute type they should use to store
>> electronic identity numbers of Finnish citizens.
>> 
>> - I think the latest discussions have shown that dnQualifier is out of the
>> picture.
>> 
>> - UID is useless because of the bit string syntax.
>> 
>> - There is no time to define a new attribute.
>> 
>> So they will have to go with serialNumber. A big reason for this is also
>> that the Germans have decided to go with the serialNumber attribute as
>> well. So now Finland and Germany will at least be compliant.
>> 
>> 
>> So folks, as I see this we have no choice other than to support
>> serialNumber at this moment.
>> 
>> I suggest that we:
>> 
>> - Add serialNumber to son of rfc2459 supportedAttributes as a MUST
>> implement attribute (i.e. compliant applications MUST be able to understand
>> it).
>> 
>> - Keep dnQualifier in son of rfc2459, with a note stating it's intended
>> purpose, the fact that new certificates should not break this intended
>> usage, and also saying that clients should expect that some existing
>> certificates may use this attribute to hold any type of value.
>> 
>> - specify use of serialNumber but NOT dnQualifier in the Qualified
>> Certificates profile.
>> 
>> It would help to get your immediate support for this. Can you live with it??
>> 
>> /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
-------------------------------------------------------------------

From: "Don Johnson" <[email-masked]>
To: "John C. Kennedy" <[email-masked]>
cc: [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], Elaine Barker <[email-masked]>, Sharon Keller <[email-masked]>, "Simon Blake-Wilson" <[email-masked]>, "Phil Griffin" <[email-masked]>
Date: Mon, 22 Nov 1999 09:36:04 -0500
Subject: RE: FIPS 186 and X9.42: One of these things is not like the other

John,

A few comments on X9.42.
1. Elaine Barkey and Sharon Keller of NIST are the editors of ANSI X9.42.  I am
copying them on your note.  It should be ready for final ballot.
2. The order of the parameters in the domain parameters should be made
consistent with X9.30 DSA, I think.  If this is not the way it is, it should be
changed in X9.42.
3. The private key d should be a value from 1 to q-1 in X9.42.  It is allowed to
chop off the ends and make it 2 to q-2.  Any further reduction risks reducing
the keysize and therefore aiding the adversary.  The reason that "low" values
are allowed sometimes is that it is not known how to detect such a situation.
In fact, if it were, then DH would unravel anyway.

Don Johnson

"John C. Kennedy" <[email-masked]> on 11/21/99 04:17:21 AM

To:   [email-masked], [email-masked], [email-masked],
      [email-masked]
cc:   [email-masked], [email-masked], Don
      Johnson/Certicom@Certicom, [email-masked], [email-masked],
      [email-masked], [email-masked]

Subject:  RE: FIPS 186 and X9.42: One of these things is not like the other

(A long but hopefully illuminating follow-up regarding ANSI X9.42)

(**Summary: The use or referencing of the ANSI X9.42 (Diffie-Hellman) drafts
in IETF standards has resulted in the propagation of a number of errors and
inconsistencies within IETF drafts and RFCs.  IMHO, it is questionable
whether the still unratified ANSI X9.42 draft should be used as a basis or
even a reference for ongoing IETF Diffie-Hellman protocol standardization
work.)

Peter,

I was the editor of the ANSI X9.42 Diffie-Hellman draft up until about April
of 1997 when I changed employers and passed the X9.42 editing torch.  Since
my current work has given me a reason to wade back into the IETF process, I
wanted to share a few comments and provide some additional data on the
apparent state of Diffie-Hellman in IETF work.  As I revisit things 2.5
years later it seems to still be a bit of a mess in need of some tidying up.

(1) RFC 2459 (PKIX) references a December 1997 draft of ANSI X9.42.  I
believe this may be a draft that I "strategically distributed" to a few
select people working in IPSEC, PKIX, and other IETF working groups around
that time.  ANSI X9F has never had a lot of interest in seeing X9.42
reviewed or adopted by IETF.  [In fact, it is ridiculous that after almost
five years of work and innumerable rewrites, neither ANSI or NIST have
published an authoritative interoperability standard for one the most
fundamental and powerful public key techniques for key agreement we have.
(Hint: It is not because of patents or because it is too difficult to
communicate.)]

(2) RFC 2631 (Diffie-Hellman Key Agreement Method) references a 1998 draft
of X9.42.  This X9.42 draft is probably the one made available by ANSI to
IEEE P1363 members at
http://grouper.ieee.org/groups/1363/private/x9-42-10-02-98.doc (You will
need an IEEE P1363 password to get at this.)  This draft is better than the
1997 draft, but still has problems.  Since I have not been involved with
ANSI for about 3 years, I can't comment on where the X9.42 draft currently
stands.  Since the X9.42 draft document is (still!) not public, it is not
clear whether it is relevant to the IETF's work anyway.  RFC 2631 is
currently a proposed standard in IETF.  Since RFC 2631 propagates errors
that existed in the 1998 X9.42 draft, a second look at it is probably called
for. (These errors are noted below)

(3) RFC 2412 (OAKLEY Key Agreement) doesn't reference any Diffie-Hellman
standards.  While the techniques given in this document are mathematically
accurate and certainly filled a gap in the IPSEC work at the time, the
OAKLEY RFC doesn't quite provide all the pieces needed to link up with PKIX
and some other security standards.

(4) The following drafts contain relevant references to Diffie-Hellman or
related protocols.  The first two reference RFC 2631 and the second
specifies a new DH variant altogether:
draft-ietf-smime-small-subgroup-02.txt
draft-ietf-pkix-dhpop-02.txt
draft-ietf-secsh-transport-06.txt

(5) Both of the ANSI documents currently referenced were drafts and probably
weren't the best basis for IETF standards.  Given the lack of anything else
to point to, I can't say I blame the authors, however.  They certainly meant
well.  What is also unfortunate is that IETF community has not been provided
with access to more current X9.42 drafts.  This is, IMHO, probably related
to the situation I pointed out in (1).

Now, in reponse to your observations:

(6) RFC 2631 states "X9.42 requires that the private key x be in the
interval [2, (q - 2)]"
In other words, (1 < x < q-1).  **It is quite clear that the referenced
X9.42 draft is not only wrong but inconsistent**.  And in a number of
places.  The Diffie-Hellman private key x should be chosen in the closed
interval [2^(m-1), q-1], where m is the minimum length in bits acceptable
for the private key.  (Typically m>=160, but your mileage may vary...)  This
is consistent with security recommendations in the current IEEE P1363
documents as well as definitions in draft-ietf-smime-small-subgroup-02.txt,
draft-ietf-pkix-dhpop-02.txt.  (If there is a mathematical subtlety I have
forgotten and x should be in [2^(m-1), q-2], I hope someone speaks up to
correct me.)

Note that choosing x in [1, q-1] will work just fine mathematically, but
does not reflect or enforce the minimum key size requirement.  Note that if
the size of q is at least a few bit greater than m and you are using a good
RNG to pick x, the point is probably moot anyway.  If you are using a
long-term (aka "static") DH keys, however, it probably not a bad idea to put
the minimum keysize check in your keygen routine as a "belt and suspenders"
type measure.

(7) The domain parameter generation routines in X9.42 were in fact derived
from those in the FIP 186 spec to allow re-use of DSA parameters (p, q, and
g) with X9.42 if desired.  I can't say I am a big fan of this because it
forces q to 160 bits which is probably not appropriate if you intend to
enforce a minimum DH private key size greater than 160.

(8) The parameter order switch was not a deliberate booby trap, although
these types of things do help to keep crypto engineers on their toes. :)  As
I recall, the parameters q and j were added when concerns about small
subgroup attacks on Diffie-Hellman surfaced.  It is more of a coincidence
that the DSA algorithm exploits the use of a subgroup also defined by a
prime called q.  In other words, DSA included q from the beginning while
X9.42 added q as a security enhancement.  The ASN.1 encoding choices are an
artifact of the development process, not a deliberate reversal.  If you feel
like lobbying ANSI X9F to change the ordering to make everyone's life
easier, have at it.  I wouldn't hold my breath however. :)

(9) RFC 2459 (PKIX) shows ASN.1 encoding of the DH parameters as:
 DomainParameters ::= SEQUENCE {
              p       INTEGER, -- odd prime, p=jq +1
              g       INTEGER, -- generator, g
              q       INTEGER, -- factor of p-1
              j       INTEGER OPTIONAL, -- subgroup factor
              validationParms  ValidationParms OPTIONAL }

        ValidationParms ::= SEQUENCE {
              seed             BIT STRING,
              pgenCounter      INTEGER }

whereas the 1998 X9.42 draft shows them as:

DomainParameters ::= SEQUENCE {  -- Galois field group parameters
   p                INTEGER,        -- odd prime, p = jq + 1
   g                INTEGER,        -- generator, g
   q                INTEGER,        -- prime factor of p-1
   j                INTEGER,        -- subgroup factor, j >= 2
   validationParms  ValidationParms OPTIONAL
(**Note q is no longer optional.** JK)

if you can find a copy of the 1997 draft (which I happen to have) we see the
original version:

DomainParameters ::= SEQUENCE {  -- Galois field group parameters
   p                INTEGER,        -- odd prime, p = jq + 1
   g                INTEGER,        -- generator, g
   q                INTEGER OPTIONAL,        -- prime factor of p-1
   j                INTEGER OPTIONAL,        -- subgroup factor, j >= 2
   validationParms  ValidationParms OPTIONAL

(This early draft reflects my admitted ignorance of proper ASN.1 at the
time. You cannot have multiple optional INTEGERS without tags on them.)

My guess is that the middle version (i.e., with only ValidationParms
optional) is the preferred version, which means RFC 2459 should probably be
changed.  I do not know what the current X9.42 draft gives.

****Conclusion****
(10) Because of the aforementioned errors and inconsistencies, I have
serious reservations about the continued use or referencing of ANSI X9.42 in
IETF drafts or standards.  The use or referencing of the ANSI X9.42 draft in
IETF standards has resulted in the propagation of a number of errors and
inconsistencies within IETF drafts and RFCs.  IMHO, it is questionable
whether the apparently still unratified and possibly unstable ANSI X9.42
draft should be used as a basis or reference for ongoing IETF Diffie-Hellman
protocol standardization efforts.  Because of this, I respectfully submit
that the IETF should consider whether RFC 2631 should be deprecated and
rewritten in a manner which removes unnecessary references to the mysterious
and forever-unpublished ANSI X9.42 draft.

-John Kennedy
[email-masked]

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: Sunday, November 21, 1999 1:58 PM
To: [email-masked]; [email-masked]
Subject: FIPS 186 and X9.42: One of these things is not like the other

FIPS 186/X9.30 and X9.42 (and by extension RFC 2631) share the same key
generation algorithm, and have domain parameters which look identical,
however
there are two subtle differences between them, one of which is really
annoying.

The annoying difference is that when writing the domain parameters, the
order
of q and g is reversed for FIPS 186 and X9.42 keys, so that while DSA domain
parameters are written (p, q, g), exactly the same domain parameters when
viewed as X9.42 values are written (p, g, q).  This isn't helped by the fact
that in many fonts lowercase q and g look very similar.  Apart from the fact
that it's a booby-trap for implementors, it also means that if the domain
parameters are identified in the traditional way (SHA-1 hash), identical
parameters will appear to be different depending on whether you're
interpreting
them as DSA/KEA or DH parameters.

The second difference is in the allowed range for x:

  FIPS 186: 0 < x < q (ie x = 1...q-1)
  X9.42: 1 < x <= q-2 in one place, [2...q-2] in another (ie x = 2..q-2)

This looks like a transcription error from FIPS 186, given that using any
x < ~2^160 is unsound I can't see why there'd be any difference between 1
and 2
as a lower bound.

Perhaps new RFC's which cover this (eg son-of-RFC2459) could include
warnings
to the effect that although the parameters are the same internally, their
external representations differ.

Does anyone know why X9.42 decided to reverse the parameter order?

(The motivation for this post is that ages ago I solved the problem of the
 reversed parameters by swapping the pointers for the X9.42 g and q values
so
 they were read and written in the correct order, recently I was looking
 through the code and wondered why it was working fine for both
interpretations
 of parameter ordering.  There's now a big comment block by the code
explaining
 the Bug which Isn't)

Peter.

Date: Mon, 22 Nov 1999 13:40:24 +0100 (W. Europe Standard Time)
From: Magnus Nystrom <[email-masked]>
Reply-To: [email-masked]
To: Stefan Santesson <[email-masked]>
cc: [email-masked], Ella Paton Bassett <[email-masked]>, [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked]
Subject: Re: We have to choose serialNumber instead of dnQualifier NOW!!!

Taking advantage of the timezone difference to be the first to
respond...;)

I must say I am a bit reluctant to choose a long-term solution because of
short-term time constraints in this case. Finland is, in my view, a "lost
case" anyway, our decision won't affect them much right now anyway. What
says "There is no time to define a new attribute"? Better to think this
through properly and let everyone express their view than to rush
something which may not be the optimal solution.

As I previously stated, I am not too convinced serialNumber is the best
alternative. Squeezing in new semantics in an existing attribute may cause
more problems than it solves. Since any change in the semantics of
serialNumber will affect X.520, it ought to affect X.521 (e.g. the
'person' object class) as well. I guess one possibility is to re-name
serialNumber as well, to something more declarative, like "uniqueNumber"
or similar, but it would be just as easy to define a new attribute - X.520
and X.521 will have to change anyway if they are to support this at all.
Note: I am not saying I object to this proposal, just that I think we need
some more time.

Regards,
-- Magnus
Magnus Nystrom		Email: [email-masked]
RSA Laboratories

On Mon, 22 Nov 1999, Stefan Santesson wrote:

> All,
> 
> Regarding the issue to select an attribute type for storage of personal
> identifiers of certificate subjects.
> 
> Finland's national electronic identity project starts FULL production in 2
> weeks, where they will  issue certificates to the people of Finland in a
> large scale.
> 
> They need to know TODAY, what attribute type they should use to store
> electronic identity numbers of Finnish citizens.
> 
> - I think the latest discussions have shown that dnQualifier is out of the
> picture.
> 
> - UID is useless because of the bit string syntax.
> 
> - There is no time to define a new attribute.
> 
> So they will have to go with serialNumber. A big reason for this is also
> that the Germans have decided to go with the serialNumber attribute as
> well. So now Finland and Germany will at least be compliant.
> 
> 
> So folks, as I see this we have no choice other than to support
> serialNumber at this moment.
> 
> I suggest that we:
> 
> - Add serialNumber to son of rfc2459 supportedAttributes as a MUST
> implement attribute (i.e. compliant applications MUST be able to understand
> it).
> 
> - Keep dnQualifier in son of rfc2459, with a note stating it's intended
> purpose, the fact that new certificates should not break this intended
> usage, and also saying that clients should expect that some existing
> certificates may use this attribute to hold any type of value.
> 
> - specify use of serialNumber but NOT dnQualifier in the Qualified
> Certificates profile.
> 
> It would help to get your immediate support for this. Can you live with it??
> 
> /Stefan

Date: Mon, 22 Nov 1999 12:44:53 +0100
To: Ed Gerck <[email-masked]>
From: Stefan Santesson <[email-masked]>
Subject: Re: proposed key usage text
Cc: Aram Perez <[email-masked]>, [email-masked]

Ed,

I must admit that I was thinking about situations where a physical person
sign information.
I guess when the signer is a service, there will always be a context
deciding the assurance value of the signature, which should be obvious for
the user of the service.

But I still think that there is a common understanding of the differences
between non-repudiation and authentication and the way the NR-bit is
distinguished from the DS-bit in implementations out there. And I think
that understanding is rather close to what I was trying to say.

But of course your example destroys my simplified definition :-(

/Stefan

At 02:10 AM 11/22/99 -0800, Ed Gerck wrote:
>
>
>Stefan Santesson wrote:
>
>> Can anyone show me a REAL implementation where a messages are signed, where
>> this is strictly NOT non-repudiation.
>
>The Shared Registry Protocol for DNS names used by registrars for COM/NET/ORG
>has a provision for signing email messages ... just to make forging email 
>messages
>more difficult.  But, there is no assurance value associated with the 
>signature  -- and
>this is a very common use of email signatures even exemplified in this 
>discussion
>group (see archives).
>
>And, this is also so defined in X.509 -- where authentication and 
>non-repudiation
>are considered different services.
>
>So, making non-repudiation a blob together with authentication will not be 
>useful,
>since it does not occur --  neither in pratice nor in theory.  And, IMO, it 
>will not
>allow non-repudiation to be somehow "better defined", as by clumping it with
>authentication. In fact, we would lose resolution of a difference that we 
>ought to
>highlight.
>
>Cheers,
>
>Ed Gerck

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

Date: Mon, 22 Nov 1999 12:28:51 +0100
To: [email-masked], [email-masked], Ella Paton Bassett <[email-masked]>
From: Stefan Santesson <[email-masked]>
Subject: We have to choose serialNumber instead of dnQualifier NOW!!!
Cc: [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked]

All,

Regarding the issue to select an attribute type for storage of personal
identifiers of certificate subjects.

Finland's national electronic identity project starts FULL production in 2
weeks, where they will  issue certificates to the people of Finland in a
large scale.

They need to know TODAY, what attribute type they should use to store
electronic identity numbers of Finnish citizens.

- I think the latest discussions have shown that dnQualifier is out of the
picture.

- UID is useless because of the bit string syntax.

- There is no time to define a new attribute.

So they will have to go with serialNumber. A big reason for this is also
that the Germans have decided to go with the serialNumber attribute as
well. So now Finland and Germany will at least be compliant.

So folks, as I see this we have no choice other than to support
serialNumber at this moment.

I suggest that we:

- Add serialNumber to son of rfc2459 supportedAttributes as a MUST
implement attribute (i.e. compliant applications MUST be able to understand
it).

- Keep dnQualifier in son of rfc2459, with a note stating it's intended
purpose, the fact that new certificates should not break this intended
usage, and also saying that clients should expect that some existing
certificates may use this attribute to hold any type of value.

- specify use of serialNumber but NOT dnQualifier in the Qualified
Certificates profile.

It would help to get your immediate support for this. Can you live with it??

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

Date: Mon, 22 Nov 1999 02:10:47 -0800
From: Ed Gerck <[email-masked]>
To: Stefan Santesson <[email-masked]>
CC: Aram Perez <[email-masked]>, [email-masked]
Subject: Re: proposed key usage text

Stefan Santesson wrote:

> Can anyone show me a REAL implementation where a messages are signed, where
> this is strictly NOT non-repudiation.

The Shared Registry Protocol for DNS names used by registrars for COM/NET/ORG
has a provision for signing email messages ... just to make forging email messages
more difficult.  But, there is no assurance value associated with the signature  -- and
this is a very common use of email signatures even exemplified in this discussion
group (see archives).

And, this is also so defined in X.509 -- where authentication and non-repudiation
are considered different services.

So, making non-repudiation a blob together with authentication will not be useful,
since it does not occur --  neither in pratice nor in theory.  And, IMO, it will not
allow non-repudiation to be somehow "better defined", as by clumping it with
authentication. In fact, we would lose resolution of a difference that we ought to
highlight.

Cheers,

Ed Gerck

Date: Mon, 22 Nov 1999 10:47:16 +0100
To: "Aram Perez" <[email-masked]>, [email-masked]
From: Stefan Santesson <[email-masked]>
Subject: Re: proposed key usage text

At 08:21 AM 11/19/99 -0800, Aram Perez wrote:
<snip>
>But how do you distinguish between what use was intended? If someone
>captures a message that I signed for "authentication and integrity" and
>another message that I signed for "non-repudiation", how does a third party
>distinguish which use was intended?

This is the problem in a nut shell.

If you sign a message - then it must be for the purpose of providing
non-repudiation, because if you sign a message, you can count on the fact
that someone may try to hold you responsible for it (in some way)
regardless of what any bits in a certificate was saying.

So to me there is no such thing as signing messages just for authentication
purpose but NOT for non-repudiation. Not in real life. 

Can anyone show me a REAL implementation where a messages are signed, where
this is strictly NOT non-repudiation.

I would make the technical distinction that in case of authentication only,
this means a service where the signer signs data as part of an
authentication protocol, where good practice says that the signer should
include some self-generated nonce.

I can live with the text as proposed. But a clarification of this technical
distinction would be very useful.

/Stefan

   \\|||//   Stefan Santesson
    (@ @)    Accurata Systemsäkerhet AB
_ooO_(_)_Ooo____________________________________
|__|___|____|_____|_____|_____|_____|_____|_____| 
|___|____|____|_____|_____|_____|_____|_____|___|
|  Tel. +46-40 108588 , Mobile +46-705 247799   |
|  [email-masked] , http://www.accurata.se  |
-------------------------------------------------

From: [email-masked]
To: [email-masked]
Date: Sun, 21 Nov 1999 16:02:20 -0800
Subject: somewhat related timer discussion with geoplex

From: Anne & Lynn Wheeler <[email-masked]>
Subject: Re: GEOPLEX
Newsgroups: bit.listserv.ibm-main,alt.folklore.computers
Date: Sun, 21 Nov 1999 21:07:03 GMT
Reply-To: Anne & Lynn Wheeler <[email-masked]>
Organization: Wheeler&Wheeler

long ago & far away we had that problem with JES2 link between STL and
Hursley being switched from a land-line to a double-hop satellite
link. They brought up JES2 pair on the link and couldn't establish a
connection ...so they stopped and brought up VNET on the link and
everything would transfer fine w/o any errors. They dropped the link
and brought up pair of JES2 again and were unable to establish a
connection. Somebody's conclusion was that the line was full of errors
and VNET was just too stupid to realize it (of course the problem was
that JES2 had a keep-alive ping that had time-out shorter than the
satellite double-hop round trip).

misc. references (including hardware FEC for reliable transmission,
also frequently used in many satellite systems):

http://www.garlic.com/~lynn/99.html#210

http://www.garlic.com/~lynn/96.html#15
http://www.garlic.com/~lynn/99.html#33
http://www.garlic.com/~lynn/99.html#71
http://www.garlic.com/~lynn/99.html#77
http://www.garlic.com/~lynn/99.html#91
http://www.garlic.com/~lynn/99.html#110
http://www.garlic.com/~lynn/99.html#145
http://www.garlic.com/~lynn/99.html#184
http://www.garlic.com/~lynn/99.html#209

[email-masked] writes:

> >Can I have a GEOPLEX player several thousand miles away and have
> >a minimum of 1 structure list i.e. logger?
>
> No.  No can do.
>
> There is a finite limit to the distance allowed for the communication
> protocols used for the Sysplex Timer and Coupling Facility, which is the
> limiting factor to a Geographically dispersed Sysplex.
> Greg
>
> Greg Dyck
> IBM Poughkeepsie, OS/390 BCP Platform team

--
--
Anne & Lynn Wheeler   | [email-masked], [email-masked]
 http://www.garlic.com/~lynn/ http://www.adcomsys.net/lynn/

From: "John C. Kennedy" <[email-masked]>
To: "Ben Laurie" <[email-masked]>
Cc: <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>
Subject: RE: FIPS 186 and X9.42: One of these things is not like the other
Date: Sun, 21 Nov 1999 13:43:23 -0800
Importance: Normal
Disposition-Notification-To: "John C. Kennedy" <[email-masked]>

As I recall, I argued the same point and lost.  I believe the prevailing
argument was that including both j and q saved a parameter validator the
cost of doing a division to derive the other value.  If j=2, the most common
case, the division is simply a right-shift, and the argument is moot.  If
you are using a q of 160 and j>>2, say in the case where DSA parameters are
being overloaded for use as DH parameters, the p/q calculation is more
expensive.  If you are doing the calculation on a memory/CPU limited smart
card the inclusion of p,q,j may be useful.

The values q and j are made available for verification of domain parameters
and for guiding selection of appropriately sized private keys.

-John
[email-masked]

-----Original Message-----
From: Ben Laurie [mailto:[email-masked]]
Sent: Sunday, November 21, 1999 2:44 AM
To: John C. Kennedy
Cc: [email-masked]; [email-masked]; [email-masked];
[email-masked]; [email-masked]; [email-masked];
[email-masked]; [email-masked]; [email-masked]; [email-masked];
[email-masked]
Subject: Re: FIPS 186 and X9.42: One of these things is not like the
other

"John C. Kennedy" wrote:
> (9) RFC 2459 (PKIX) shows ASN.1 encoding of the DH parameters as:
>  DomainParameters ::= SEQUENCE {
>               p       INTEGER, -- odd prime, p=jq +1
>               g       INTEGER, -- generator, g
>               q       INTEGER, -- factor of p-1
>               j       INTEGER OPTIONAL, -- subgroup factor
>               validationParms  ValidationParms OPTIONAL }

I was perusing the OpenSSL DH code recently, and I noticed that DH was
using a Germain prime for p (miscommented as a strong prime, btw),
which, of course, makes j=2. But q and j are not kept - what are they
actually used for? (Answers in the form "read XXX" are welcome)

BTW, why the redundancy? If you have any two of p, j and q, you don't
need the other, and surely the work involved to recover the third one is
minimal in comparison to anything else you'd need to do, sumswise?

Cheers,

Ben.

--
http://www.apache-ssl.org/ben.html

"My grandfather once told me that there are two kinds of people: those
who work and those who take the credit. He told me to try to be in the
first group; there was less competition there."
     - Indira Gandhi

Date: Sun, 21 Nov 1999 10:44:17 +0000
From: Ben Laurie <[email-masked]>
Organization: A.L. Group plc
To: "John C. Kennedy" <[email-masked]>
CC: [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked]
Subject: Re: FIPS 186 and X9.42: One of these things is not like the other

"John C. Kennedy" wrote:
> (9) RFC 2459 (PKIX) shows ASN.1 encoding of the DH parameters as:
>  DomainParameters ::= SEQUENCE {
>               p       INTEGER, -- odd prime, p=jq +1
>               g       INTEGER, -- generator, g
>               q       INTEGER, -- factor of p-1
>               j       INTEGER OPTIONAL, -- subgroup factor
>               validationParms  ValidationParms OPTIONAL }

I was perusing the OpenSSL DH code recently, and I noticed that DH was
using a Germain prime for p (miscommented as a strong prime, btw),
which, of course, makes j=2. But q and j are not kept - what are they
actually used for? (Answers in the form "read XXX" are welcome)

BTW, why the redundancy? If you have any two of p, j and q, you don't
need the other, and surely the work involved to recover the third one is
minimal in comparison to anything else you'd need to do, sumswise?

Cheers,

Ben.

--
http://www.apache-ssl.org/ben.html

"My grandfather once told me that there are two kinds of people: those
who work and those who take the credit. He told me to try to be in the
first group; there was less competition there."
     - Indira Gandhi

From: "John C. Kennedy" <[email-masked]>
To: <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>
Cc: <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>
Subject: RE: FIPS 186 and X9.42: One of these things is not like the other
Date: Sun, 21 Nov 1999 01:17:21 -0800
Importance: Normal

(A long but hopefully illuminating follow-up regarding ANSI X9.42)

(**Summary: The use or referencing of the ANSI X9.42 (Diffie-Hellman) drafts
in IETF standards has resulted in the propagation of a number of errors and
inconsistencies within IETF drafts and RFCs.  IMHO, it is questionable
whether the still unratified ANSI X9.42 draft should be used as a basis or
even a reference for ongoing IETF Diffie-Hellman protocol standardization
work.)

Peter,

I was the editor of the ANSI X9.42 Diffie-Hellman draft up until about April
of 1997 when I changed employers and passed the X9.42 editing torch.  Since
my current work has given me a reason to wade back into the IETF process, I
wanted to share a few comments and provide some additional data on the
apparent state of Diffie-Hellman in IETF work.  As I revisit things 2.5
years later it seems to still be a bit of a mess in need of some tidying up.

(1) RFC 2459 (PKIX) references a December 1997 draft of ANSI X9.42.  I
believe this may be a draft that I "strategically distributed" to a few
select people working in IPSEC, PKIX, and other IETF working groups around
that time.  ANSI X9F has never had a lot of interest in seeing X9.42
reviewed or adopted by IETF.  [In fact, it is ridiculous that after almost
five years of work and innumerable rewrites, neither ANSI or NIST have
published an authoritative interoperability standard for one the most
fundamental and powerful public key techniques for key agreement we have.
(Hint: It is not because of patents or because it is too difficult to
communicate.)]

(2) RFC 2631 (Diffie-Hellman Key Agreement Method) references a 1998 draft
of X9.42.  This X9.42 draft is probably the one made available by ANSI to
IEEE P1363 members at
http://grouper.ieee.org/groups/1363/private/x9-42-10-02-98.doc (You will
need an IEEE P1363 password to get at this.)  This draft is better than the
1997 draft, but still has problems.  Since I have not been involved with
ANSI for about 3 years, I can't comment on where the X9.42 draft currently
stands.  Since the X9.42 draft document is (still!) not public, it is not
clear whether it is relevant to the IETF's work anyway.  RFC 2631 is
currently a proposed standard in IETF.  Since RFC 2631 propagates errors
that existed in the 1998 X9.42 draft, a second look at it is probably called
for. (These errors are noted below)

(3) RFC 2412 (OAKLEY Key Agreement) doesn't reference any Diffie-Hellman
standards.  While the techniques given in this document are mathematically
accurate and certainly filled a gap in the IPSEC work at the time, the
OAKLEY RFC doesn't quite provide all the pieces needed to link up with PKIX
and some other security standards.

(4) The following drafts contain relevant references to Diffie-Hellman or
related protocols.  The first two reference RFC 2631 and the second
specifies a new DH variant altogether:
draft-ietf-smime-small-subgroup-02.txt
draft-ietf-pkix-dhpop-02.txt
draft-ietf-secsh-transport-06.txt

(5) Both of the ANSI documents currently referenced were drafts and probably
weren't the best basis for IETF standards.  Given the lack of anything else
to point to, I can't say I blame the authors, however.  They certainly meant
well.  What is also unfortunate is that IETF community has not been provided
with access to more current X9.42 drafts.  This is, IMHO, probably related
to the situation I pointed out in (1).

Now, in reponse to your observations:

(6) RFC 2631 states "X9.42 requires that the private key x be in the
interval [2, (q - 2)]"
In other words, (1 < x < q-1).  **It is quite clear that the referenced
X9.42 draft is not only wrong but inconsistent**.  And in a number of
places.  The Diffie-Hellman private key x should be chosen in the closed
interval [2^(m-1), q-1], where m is the minimum length in bits acceptable
for the private key.  (Typically m>=160, but your mileage may vary...)  This
is consistent with security recommendations in the current IEEE P1363
documents as well as definitions in draft-ietf-smime-small-subgroup-02.txt,
draft-ietf-pkix-dhpop-02.txt.  (If there is a mathematical subtlety I have
forgotten and x should be in [2^(m-1), q-2], I hope someone speaks up to
correct me.)

Note that choosing x in [1, q-1] will work just fine mathematically, but
does not reflect or enforce the minimum key size requirement.  Note that if
the size of q is at least a few bit greater than m and you are using a good
RNG to pick x, the point is probably moot anyway.  If you are using a
long-term (aka "static") DH keys, however, it probably not a bad idea to put
the minimum keysize check in your keygen routine as a "belt and suspenders"
type measure.

(7) The domain parameter generation routines in X9.42 were in fact derived
from those in the FIP 186 spec to allow re-use of DSA parameters (p, q, and
g) with X9.42 if desired.  I can't say I am a big fan of this because it
forces q to 160 bits which is probably not appropriate if you intend to
enforce a minimum DH private key size greater than 160.

(8) The parameter order switch was not a deliberate booby trap, although
these types of things do help to keep crypto engineers on their toes. :)  As
I recall, the parameters q and j were added when concerns about small
subgroup attacks on Diffie-Hellman surfaced.  It is more of a coincidence
that the DSA algorithm exploits the use of a subgroup also defined by a
prime called q.  In other words, DSA included q from the beginning while
X9.42 added q as a security enhancement.  The ASN.1 encoding choices are an
artifact of the development process, not a deliberate reversal.  If you feel
like lobbying ANSI X9F to change the ordering to make everyone's life
easier, have at it.  I wouldn't hold my breath however. :)

(9) RFC 2459 (PKIX) shows ASN.1 encoding of the DH parameters as:
 DomainParameters ::= SEQUENCE {
              p       INTEGER, -- odd prime, p=jq +1
              g       INTEGER, -- generator, g
              q       INTEGER, -- factor of p-1
              j       INTEGER OPTIONAL, -- subgroup factor
              validationParms  ValidationParms OPTIONAL }

        ValidationParms ::= SEQUENCE {
              seed             BIT STRING,
              pgenCounter      INTEGER }

whereas the 1998 X9.42 draft shows them as:

DomainParameters ::= SEQUENCE {  -- Galois field group parameters
   p                INTEGER,        -- odd prime, p = jq + 1
   g                INTEGER,        -- generator, g
   q                INTEGER,        -- prime factor of p-1
   j                INTEGER,        -- subgroup factor, j >= 2
   validationParms  ValidationParms OPTIONAL
(**Note q is no longer optional.** JK)

if you can find a copy of the 1997 draft (which I happen to have) we see the
original version:

DomainParameters ::= SEQUENCE {  -- Galois field group parameters
   p                INTEGER,        -- odd prime, p = jq + 1
   g                INTEGER,        -- generator, g
   q                INTEGER OPTIONAL,        -- prime factor of p-1
   j                INTEGER OPTIONAL,        -- subgroup factor, j >= 2
   validationParms  ValidationParms OPTIONAL

(This early draft reflects my admitted ignorance of proper ASN.1 at the
time. You cannot have multiple optional INTEGERS without tags on them.)

My guess is that the middle version (i.e., with only ValidationParms
optional) is the preferred version, which means RFC 2459 should probably be
changed.  I do not know what the current X9.42 draft gives.

****Conclusion****
(10) Because of the aforementioned errors and inconsistencies, I have
serious reservations about the continued use or referencing of ANSI X9.42 in
IETF drafts or standards.  The use or referencing of the ANSI X9.42 draft in
IETF standards has resulted in the propagation of a number of errors and
inconsistencies within IETF drafts and RFCs.  IMHO, it is questionable
whether the apparently still unratified and possibly unstable ANSI X9.42
draft should be used as a basis or reference for ongoing IETF Diffie-Hellman
protocol standardization efforts.  Because of this, I respectfully submit
that the IETF should consider whether RFC 2631 should be deprecated and
rewritten in a manner which removes unnecessary references to the mysterious
and forever-unpublished ANSI X9.42 draft.

-John Kennedy
[email-masked]

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: Sunday, November 21, 1999 1:58 PM
To: [email-masked]; [email-masked]
Subject: FIPS 186 and X9.42: One of these things is not like the other

FIPS 186/X9.30 and X9.42 (and by extension RFC 2631) share the same key
generation algorithm, and have domain parameters which look identical,
however
there are two subtle differences between them, one of which is really
annoying.

The annoying difference is that when writing the domain parameters, the
order
of q and g is reversed for FIPS 186 and X9.42 keys, so that while DSA domain
parameters are written (p, q, g), exactly the same domain parameters when
viewed as X9.42 values are written (p, g, q).  This isn't helped by the fact
that in many fonts lowercase q and g look very similar.  Apart from the fact
that it's a booby-trap for implementors, it also means that if the domain
parameters are identified in the traditional way (SHA-1 hash), identical
parameters will appear to be different depending on whether you're
interpreting
them as DSA/KEA or DH parameters.

The second difference is in the allowed range for x:

  FIPS 186: 0 < x < q (ie x = 1...q-1)
  X9.42: 1 < x <= q-2 in one place, [2...q-2] in another (ie x = 2..q-2)

This looks like a transcription error from FIPS 186, given that using any
x < ~2^160 is unsound I can't see why there'd be any difference between 1
and 2
as a lower bound.

Perhaps new RFC's which cover this (eg son-of-RFC2459) could include
warnings
to the effect that although the parameters are the same internally, their
external representations differ.

Does anyone know why X9.42 decided to reverse the parameter order?

(The motivation for this post is that ages ago I solved the problem of the
 reversed parameters by swapping the pointers for the X9.42 g and q values
so
 they were read and written in the correct order, recently I was looking
 through the code and wondered why it was working fine for both
interpretations
 of parameter ordering.  There's now a big comment block by the code
explaining
 the Bug which Isn't)

Peter.

From: [email-masked] (Peter Gutmann)
To: [email-masked], [email-masked]
Subject: FIPS 186 and X9.42: One of these things is not like the other
Sender: [email-masked]
Reply-To: [email-masked]
Date: Sun, 21 Nov 1999 13:58:14 (NZDT)

FIPS 186/X9.30 and X9.42 (and by extension RFC 2631) share the same key
generation algorithm, and have domain parameters which look identical, however
there are two subtle differences between them, one of which is really annoying.

The annoying difference is that when writing the domain parameters, the order
of q and g is reversed for FIPS 186 and X9.42 keys, so that while DSA domain
parameters are written (p, q, g), exactly the same domain parameters when
viewed as X9.42 values are written (p, g, q).  This isn't helped by the fact
that in many fonts lowercase q and g look very similar.  Apart from the fact
that it's a booby-trap for implementors, it also means that if the domain
parameters are identified in the traditional way (SHA-1 hash), identical
parameters will appear to be different depending on whether you're interpreting
them as DSA/KEA or DH parameters.

The second difference is in the allowed range for x:

  FIPS 186: 0 < x < q (ie x = 1...q-1)
  X9.42: 1 < x <= q-2 in one place, [2...q-2] in another (ie x = 2..q-2)

This looks like a transcription error from FIPS 186, given that using any
x < ~2^160 is unsound I can't see why there'd be any difference between 1 and 2
as a lower bound.

Perhaps new RFC's which cover this (eg son-of-RFC2459) could include warnings
to the effect that although the parameters are the same internally, their
external representations differ.

Does anyone know why X9.42 decided to reverse the parameter order?

(The motivation for this post is that ages ago I solved the problem of the
 reversed parameters by swapping the pointers for the X9.42 g and q values so
 they were read and written in the correct order, recently I was looking
 through the code and wondered why it was working fine for both interpretations
 of parameter ordering.  There's now a big comment block by the code explaining
 the Bug which Isn't)
 
Peter.

Date: Sat, 20 Nov 1999 13:57:04 -0800
From: Ed Gerck <[email-masked]>
To: "[email-masked]" <[email-masked]>
Subject: Re: MOTION ON NR

[fwd'd from a private exchange, which might be helpful to all]

-------- Original Message --------
Subject: Re: MOTION ON NR
Date: Sat, 20 Nov 1999 13:54:36 -0800
From: Ed Gerck <[email-masked]>

Thanks. I know that many people only see "motion" as a call to
vote, but "motion" is also a proposal for action (dictionary
meaning).

So, knowing how the IETF process works in a WG, my subject 
line tried to convey the idea that it is time for action 
on this matter. Let's stop stomping and dead beating the 
same problem twice in the same year ;-)

Cheers,

Ed Gerck

[] wrote:

> Um, IETF WGs don't have "motions". If you want voting (which I don't think
> you should), those are done as straw polls that are conducted by the WG
> chair(s). You might want to reword your posting as a "suggested change to
> the draft" and see if it gets support and makes it into the next version of
> the draft.
>

Date: Sat, 20 Nov 1999 09:55:00 -0800
From: Ed Gerck <[email-masked]>
To: "[email-masked]" <[email-masked]>, Nicholas Bohm <[email-masked]>
Subject: MOTION ON NR

All:

Looking at all NR suggestions here, it seems that above all 
we must not introduce a judgement of value (the word "falsely" 
in "falsely denies")which does NOT exist in non-repudiation 
proofs and which opens a can of worms for both engineers (we 
can't measure it) and lawyers (they can't prove it).  Worse, we 
need to recognize that the word "falsely" is entirely lame in this 
context, both for engineers and for lawyers.

So, instead of having a definition which anyone (engineers and lawyers)
could apply *and build upon*, we are faced in the current PKIX wording with
a jury decision carved in stone in a protocol.  This is what this discussion
oftentimes miss -- we should impose the *least* burden of compliance.

And, the least burden of compliance comes from recognizing that the call
whether the denial was falsely or truthfully made is NOT ours.  What we
*can* do is provide a protocol NR service *exactly* as predicated in X.509
(which does NOT include authentication, as I analyzed on 18 Nov 1999),
and which protects against REPLAY and REPUDIATION. Both terms are
well-defined in X.509 Appendix B.1 as:

 Replay -- The recording and subsequent replay of a communication
 at some later date.

 Repudiation -- The denial by a user of having participated in part or
 all of a communication.

This is IT, folks.  Simple, doable, in our turf. Let's just follow X.509 and lint
its inconsistencies for PKIX -- according to the term REPUDIATION
as *already* defined in X.509. Two definitions of X.509 need IMO to
be linted in this regard, because they are in conflict with one another
and with the  corpus of X.509 -- as I analyzed on 18 Nov 1999, here.
The definitions to be linted are:

1. nonRepudiation:  for verifying digital signatures used in providing a
 nonrepudiation service which protects against the signing entity falsely
 denying some action

which should become (eliminating the circular reference to
"nonrepudiation" itself and the lame reference to "falsely"):

1'. nonRepudiation:  for verifying digital signatures used in providing a
 service which protects against the signing entity  denying some action.

and,

2. Non-repudiation -- This service provides proof of the integrity and origin
 of data -- both in an unforgeable relationship -- which can be verifed by any
 third party at any time.

which is conflicting with the first, wrong (see why in my mail of 18 Nov 1999)
and should be simply replaced with 1' (of course, one should NEVER define
the same thing in two different ways in the same document).

For lawyer remarks on non-repudiation and the distinction we ourselves
often miss here between technical and legal assessments, please see [1].

I call attention to the fact that the remarks *include* the use of the word
"falsely" from the viewpoint of the risk-bearer (who does not want the
signer to falsely deny an act) , but *exclude* that same word from
the viewpoint of proof  (where it is irrelevant whether the denial was
false or truthful -- whether the signer actually made the signature or not,
whether the signer actually intended to make the signature or not, etc.).
I believe this explains the dilemma facing those (including myself) that
see the unfairness of setting up a system that can disallow truthful
denials, by recognizing that "truth" is a matter of reference -- if the
customer wants his check to be cashed without the bank calling (and,
charging) him for every check to be paid, then the client must accept
that the bank needs to independently verify whether the signature is
correct or not, truthful or false. This is the truth that the client accepts,
and accepts it because she profits from it.

Of relevance is only if the technical assesment can be used (and, herein
lies the slippery slope for this PKIX WG, in our social liability and ethic
as engineers) to support a legal assessment holding that the apparent
maker of the signature is bound by it  -- *whether she made it or not*.

This opinion confirms that non-repudiation is that which can prevent
even truthful denials, not only false denials.  So, non-repudiation
has to do, logically speaking, only with preventing denials (since both
complementary cases of truthful and false are included and decided
elsewhere).

Thus, let's not try to include jury, judge and executioner in our protocols.
Therefore, to be concrete I propose the following *minimum* changes:

----------------
 MOTION ON NR

 That definition 1'  be accepted, that definition 2 be replaced with 1' --
 all in their equivalent places in PKIX from X.509. The X.509 definition
 of repudiation stays unchanged.

 The actual specification how the NR services are provided need not
 concern PKIX, as they are bound to be different for each realm
 of application (common law, civil law, military, government, private
 sector agreements, intra-company, etc.), CPS, etc. Thus, the
 specification of NR services is to be considered outside the scope
 of PKIX.

 Tom Gidin's proposed RFC provides one example of how NR services
 can be implemented. Implementors are free to devise their own
 examples, if  needed.

 The current PKIX specification that keyUsage bits are independent
 should NOT be changed, and wording to the contrary in PKIX should
 NOT be used for compliance testing (they are merely examples of usage).
----------

Cheers,

Ed Gerck

[1] Remarks received in private from Nicholas Bohm, a lawyer that used
to work for banks in the City of London, Cc'd above.

1       It is often (although not invariably) a desirable objective of a system
to provide a non-repudiation service, either to prevent a signatory from
falsely repudiating a genuine signature or to prevent the recipient of a
message from falsely denying its receipt.  Whether a particular system
provides such a service, and the degree of its reliability, are matters for
technical assessment.

2       If a system is believed to provide a reliable non-repudiation service,
and is used in circumstances where legal consequences may follow the
signing or receipt of a message, the contractual terms which establish the
legal framework for the operation of the system may provide that what the
system recognises as a valid signature shall bind the apparent maker,
whether she made the signature in fact or not; or that where the system
records a message as having been received, the apparent recipient shall be
treated as having received it, whether he received it in fact or not.  Such
terms may be described as providing for the non-repudiation of signatures
or receipt of messages.

3       A technical assessment may prove that it is highly probable that a
signature was made by its apparent maker.  A legal assessment may hold that
the apparent maker of a signature is bound by it whether she made it or
not.  These two conclusions seem similar, but operate in different realms
of thought.  Debate about non-repudiation sometimes overlooks the
distinction, to the evident frustration of the lawyers and engineers whose
arguments pass through one another like angry ghosts.

From: [email-masked]
Date: Sat, 20 Nov 1999 11:28:29 EST
Subject: Passage of Electronic Signature/Electronic Commerce Bill
To: [email-masked], [email-masked]

For Immediate Release               
Contact:            Kawika Daguio
                    301-332-5224

Financial Information Protection Association (FIPA) Applauds Passage of 
Federal Electronic Signature Bills.

Washington, DC  (November 20, 1999) - Financial Information Protection 
Association (FIPA - www.fipanet.org) congratulates the House and Senate for 
passing two critical pieces of legislation that when their differences are 
resolved will provide a much needed uniform federal legal infrastructure for 
electronic commerce that covers electronic signatures and electronic 
agreements.

Kawika M. Daguio, Executive Vice President of FIPA said, "The financial 
services industry, its commercial customers and consumers will all benefit 
from the increased flexibility and savings that will result from the 
innovative services that it will now be possible to deliver safely and with 
the requisite certainty that resulting electronic agreements can be enforced. 
  Until now, many kinds of commercial transactions could not done on the 
Internet because of concerns that the contracts might be unenforceable.

The Executive staff and many of the members of FIPA have been involved in 
efforts to pass electronic commerce and electronic signatures legislation for 
over four years, and have been involved in every strategic step forward taken 
over the last few years.   Mr. Daguio said, "We have had a number of 
incremental yet meaningful wins during the last four years, but this week's 
progress has been amazing."

Mr. Daguio added, "We have invested our time, money, and other resources into 
making electronic commerce safer and more efficient and we are very pleased 
that the Congress has responded to help meet the needs of the electronic 
commerce marketplace."

In a letter to FIPA's Congressional Liasons Mr. Daguio said, "We are looking 
forward to working with the House, Senate, and Clinton Administration to 
produce a conference agreement that will meet the needs of the consumer and 
corporate customers of financial services firms as well as others involved in 
electronic financial services and electronic commerce."

ABOUT FIPA
FIPA, (www.fipanet.org ) which offers individual professional and 
institutional memberships, is dedicated to helping individuals, firms, and 
governments work together to protect sensitive financial information while 
promoting commerce.  Members of FIPA have demonstrated their commitment and 
contributions to the protection of financial information and are uniquely 
qualified to make determinations of the reasonableness of information 
protection policies and measures in their firms.

From: [email-masked]
To: "Todd Glassey @ GMTsw" <[email-masked]>
cc: [email-masked]
Date: Sat, 20 Nov 1999 08:13:16 -0800
Subject: Re: Certifiedtime.com

note that the AADSS radius case with time-stamp/nonce is a reply-attack scenario
and so it doesn't really require real-time.

this particular is more akin to virtual time work on log merge. when i was doing
cluster distributed lock manager work ... misc. ref:

http://www.garlic.com/~lynn/96.html#15
http://www.garlic.com/~lynn/95.html#13

i had also worked out the process for doing cache-to-cache buffer copies w/o
having to do the disk write first. this made several of the database  people
uneasy since various failure mode recovery scenarios required doing log merging
between the different nodes. in part because it was a closed system, "virtual"
time providing relative ordering of the entries for the same record in different
logs was sufficient (the distributed database & filesystems guys have recently
picked up renewed interest in this area).

reliable "real" time becomes an issue when trying to prove relative ordering in
an open infrastructure (possibly even involving real world, non-computerized
events) as opposed to "virtual" time which can be used in closed systems (like
large distributed cluster databases & filesystems ... something even as simple
as a version #).

There are numerous financial and contractual events that would benefit from
being able to show real-world ordering.

Date: Sat, 20 Nov 1999 10:08:19 -0500 ()
From: Anne Anderson <[email-masked]>
To: [email-masked]
Subject: PKIX compliance tests
Reply-To: Anne Anderson <[email-masked]>

Does anyone know of test suites to test for PKIX compliance?

Anne
-- 
Anne Anderson         email: [email-masked]
28 Minuteman Road
Acton, MA 01720-3840

From: [email-masked]
To: Tony Bartoletti <[email-masked]>
cc: Tim Polk <[email-masked]>, [email-masked]
Date: Fri, 19 Nov 1999 22:32:32 -0500
Subject: Re: NR-Bit Truth-In-Advertising

     I don't think that the list of claims given (denial of ownership, key
compromise, etc. ) is the list of claims that the NR service protects
against.  In fact, that was my guess at the list of claims which the NR
service may not be able to guarantee against.  What the NR services should
be able to do is to provide a level of certainty for the validity of the
specified signature high enough that a party disclaiming such a signature
needs to establish one of those claims with some level of real proof - the
level required not being a technical matter which this group can help with.
     Some NR products may help weaken or eliminate some of the claims on
the list, but I seriously doubt that PKIX can do much about signer
incompetence or duress.

          Tom Gindin

Tony Bartoletti <[email-masked]> on 11/19/99 09:51:28 PM

To:   Tim Polk <[email-masked]>, [email-masked]
cc:
Subject:  NR-Bit Truth-In-Advertising

Tim,

My problem with the suggested wording in 4.2.1.3 Key Usage:

   The nonRepudiation bit is asserted when the subject public key is
   used to verify digital signatures used to provide a non-repudiation
   service which protects against the signing entity falsely denying
   some action, excluding certificate or CRL signing.  In the case of
   later conflict, a reliable third party may determine the authenticity
   of the signed data.

First, the term "signing entity" is misleading.  The central theme of NR
is to establish that the "named-cert-holder" is first of all the signer
in question, and the one who must bear the burden of proving a "true
denial" in the face of a presumption of falsity.  For instance, if my
NR-key is compromised, and a stranger uses it to sign, NR is not going
to begin by challenging the stranger in his false denial, even though
he is the "true signer".  The point is, I may be forced to accept my
role or responsibility, especially in an unsubstantiable compromise.

So, in the interest of "truth in advertizing", I offer my

   Suggested Replacement, short version:

   The nonRepudiation bit is asserted when the subject public key is
   used to verify digital signatures used to provide a non-repudiation
   service which protects against the named certificate subject falsely
   denying responsibility for a signature generated by the certified key,
   excluding certificate or CRL signing.  Such service may allow a
   determine the veracity of various elements in a claim of repudiation.

Second, the term "some action" is way-overly vague.  I know there are
many kinds of NR, and we cannot hope to enumerate them all, but why not
be a bit more specific, helpful?  Here is a suggestion, borrowing from
Tom Gindin's partial enumeration:

   Suggested Replacement, long version:

   The nonRepudiation bit is asserted when the subject public key is
   used to verify digital signatures used to provide a non-repudiation
   service which protects against the named certificate subject falsely
   denying responsibility for a signature generated by the certified key,
   through false claims that may include denial of ownership, assertion
   of key compromise, assertion of misleading presentation, assertion of
   software problem, or of incompetence or duress, excluding certificate
   or CRL signing.  Such service may allow a reliable third party to
   determine the veracity of various elements in a claim of repudiation.

Finally, I was not happy with the last sentence, in particular the
mere "authenticity of the signed data".  This suggests that the reliable
third party may do no more than help establish that the signing key was
actually used, and the certificate valid at the time.  If that was all
there were, we should adopt Tom Gindin's version directly, since it
refers to this property alone.  Perhaps the intent was for "signed data"
to refer to ALL of the elements that an NR service might archive with
respect to a transaction.  My suggestion would be to replace

   In the case of later conflict, a reliable third party may determine
   the authenticity of the signed data.

with the more general

   Such service may allow a reliable third party to determine the
   veracity of various elements in a claim of repudiation.

____tony____

Tony Bartoletti                                             LL
IOWA Center                                              LL LL
Lawrence Livermore National Laboratory                LL LL LL
PO Box 808, L - 089                                   LL LL LL
Livermore, CA 94551-9900                              LL LL LLLLLLLL
phone: 925-422-3881   fax: 925-423-8081               LL LLLLLLLL
email: [email-masked]                                   LLLLLLLL

Date: Fri, 19 Nov 1999 18:51:28 -0800
To: Tim Polk <[email-masked]>, [email-masked]
From: Tony Bartoletti <[email-masked]>
Subject: NR-Bit Truth-In-Advertising

Tim,

My problem with the suggested wording in 4.2.1.3 Key Usage:

   The nonRepudiation bit is asserted when the subject public key is
   used to verify digital signatures used to provide a non-repudiation
   service which protects against the signing entity falsely denying
   some action, excluding certificate or CRL signing.  In the case of
   later conflict, a reliable third party may determine the authenticity
   of the signed data.

First, the term "signing entity" is misleading.  The central theme of NR
is to establish that the "named-cert-holder" is first of all the signer
in question, and the one who must bear the burden of proving a "true
denial" in the face of a presumption of falsity.  For instance, if my
NR-key is compromised, and a stranger uses it to sign, NR is not going
to begin by challenging the stranger in his false denial, even though
he is the "true signer".  The point is, I may be forced to accept my
role or responsibility, especially in an unsubstantiable compromise.

So, in the interest of "truth in advertizing", I offer my
 
   Suggested Replacement, short version:

   The nonRepudiation bit is asserted when the subject public key is
   used to verify digital signatures used to provide a non-repudiation
   service which protects against the named certificate subject falsely
   denying responsibility for a signature generated by the certified key,
   excluding certificate or CRL signing.  Such service may allow a
   determine the veracity of various elements in a claim of repudiation.

Second, the term "some action" is way-overly vague.  I know there are
many kinds of NR, and we cannot hope to enumerate them all, but why not
be a bit more specific, helpful?  Here is a suggestion, borrowing from
Tom Gindin's partial enumeration:

   Suggested Replacement, long version:

   The nonRepudiation bit is asserted when the subject public key is
   used to verify digital signatures used to provide a non-repudiation
   service which protects against the named certificate subject falsely
   denying responsibility for a signature generated by the certified key,
   through false claims that may include denial of ownership, assertion
   of key compromise, assertion of misleading presentation, assertion of
   software problem, or of incompetence or duress, excluding certificate
   or CRL signing.  Such service may allow a reliable third party to
   determine the veracity of various elements in a claim of repudiation.

Finally, I was not happy with the last sentence, in particular the
mere "authenticity of the signed data".  This suggests that the reliable
third party may do no more than help establish that the signing key was
actually used, and the certificate valid at the time.  If that was all
there were, we should adopt Tom Gindin's version directly, since it
refers to this property alone.  Perhaps the intent was for "signed data"
to refer to ALL of the elements that an NR service might archive with
respect to a transaction.  My suggestion would be to replace

   In the case of later conflict, a reliable third party may determine
   the authenticity of the signed data.

with the more general

   Such service may allow a reliable third party to determine the
   veracity of various elements in a claim of repudiation.

____tony____

Tony Bartoletti                                             LL
IOWA Center                                              LL LL
Lawrence Livermore National Laboratory                LL LL LL
PO Box 808, L - 089                                   LL LL LL
Livermore, CA 94551-9900                              LL LL LLLLLLLL
phone: 925-422-3881   fax: 925-423-8081               LL LLLLLLLL
email: [email-masked]                                   LLLLLLLL

Date: Fri, 19 Nov 1999 16:55:02 -0800
From: Ed Gerck <[email-masked]>
To: Al Arsenault <[email-masked]>
CC: "David P. Kemp" <[email-masked]>, [email-masked]
Subject: Re: non-ephemeral vs. non-repudiation, was Re: proposed key usage text

Al Arsenault wrote:

> Now, in fact it would probably come down to which side had the better
> lawyer, and who the judge was, but the lawyers I've talked to about this
> are pretty confident about the scenario I've described.  Thus, Ed, I'm
> going to stick to my disagreement with you.

I see your "lawyer" text as fiction, especially in the US where banks
dictate the rules over consumers.  For your benefit, however, I suggest
you read your bank's policies on check cancellation.  Or, if you provide me
your bank's name, I can gratuitously get them for you and point out where
you are amiss.

> I do not have to prove intent via a protocol over a wire.  "False denial"
> means that in point of fact I did it and I'm trying to argue I didn't.

"Point of fact" is unknown -- perhaps an omniscient being can tell you
what "point of fact" is, but I doubt anyone else could.

Cheers,

Ed Gerck

Date: Fri, 19 Nov 1999 16:24:22 -0800
To: Al Arsenault <[email-masked]>, Ed Gerck <[email-masked]>
From: Tony Bartoletti <[email-masked]>
Subject: Re: non-ephemeral vs. non-repudiation, was Re: proposed key usagetext
Cc: [email-masked], "David P. Kemp" <[email-masked]>, [email-masked]

At 05:37 PM 11/19/1999 -0500, Al Arsenault wrote:
>
>
>Ed Gerck wrote:
>> 
><large amount of material snipped>
>> 
>> Now, regarding the use of "falsely" (or, "truly"), please recall that
>> non-repudiation is that which prevents even truthful denials. Ben King
>> has also timely recalled the example of the non-repudiation fee of $50.00
>> applied to all of us credit-card holders -- maybe, other points could be likewise
>> recalled by re-reading the archives.
>> 
>
>AWA:  Again, I could not disagree more with this.  Non-repudiation is,
>as the definition in 2459, and in Schneier, and in Ford & Baum, and in
>... says, concerned with preventing *false denials*.  It should not be
>thought of as preventing "truthful denials" [...]
[snip]

Al,

I would grant you that the "NR-service" implied in the definition of the
NR-bit is not intended by the drafters to prevent "truthful denials"
as a design goal.  But that is not really the issue.  For instance,
if indeed I needed to set up a system that would prevent "true denials",
it seems the NR-bit is still the bit I would require, as a signal for
later presentation of evidence.

My issue with the wording is that of the term "signer", and the phrase
"denying some action".

It is not the "signer", but the "certificate owner" that is being held
to accounts.  So why not say so?

Also, my NR signature on a recent purchase order cannot prevent me from
denying I was the second gunman on the grassy knoll in Dallas.  So why
not a bit greater specifics about the "some action" I shall not deny?

We all agree, I believe, that the math itself demonstrates the key used
in a disputed signature, so that cannot be the reasonable issue.  The
same math, applied to the CA signature key, makes the binding of the
cert-owner-name to the signature-key of the disputed signature just
as virtually indisputable.  No need yet for the NR-bit.  Hmmm.

So, just what is the "some action" that the NR-service intends to
prevent the cert-owner from denying?  The only realistic possibilities
that remain are:

    Active Participant In Signature (fingerprint on the button)

    Willful Participant In Signature (no arm-twisting allowed)

    Cognizance In The Signing (knew what was being signed, even if they
      authorized their secretary to push the button)

    Liability For The Signature (throw kitchen sink in here)

But above all, it is the Named-Cert-Owner who is to be prevented from
denying.  Calling this party the "signer" is a bit like using the desired
conclusion as an axiom in the argument.  It is also a bit misleading:

  "Hey, I think I'll buy LOTS of these newfangled NR-certified keys, and
   leave them around the office.  They might be useful.  Heck, I'm not
   worried if some of the staff use them.  After all, NR is dee-signed
   only to hold the "true signer" accountable. Yup. Yessir."

Is my point here clear?  The current NR-bit definition sounds just a bit
too "mostly harmless".  Who can argue with catching FALSE denials?  Its
comes off a bit like the sell for crypto-restrictions, namely "you don't
want criminals to get away, do you?"

The NR-bit, if it comes to mean anything, is like a strong prescription
drug, and should not be given a cavalier over-the-counter dispensation.

___tony___

Tony Bartoletti                                             LL
IOWA Center                                              LL LL
Lawrence Livermore National Laboratory                LL LL LL
PO Box 808, L - 089                                   LL LL LL
Livermore, CA 94551-9900                              LL LL LLLLLLLL
phone: 925-422-3881   fax: 925-423-8081               LL LLLLLLLL
email: [email-masked]                                   LLLLLLLL

Sender: [email-masked]
Date: Fri, 19 Nov 1999 17:26:16 -0800
From: Marc Branchaud <[email-masked]>
Organization: Xcert International Inc.
To: [email-masked]
Subject: Re: proposed key usage text

I'm still not convinced that a nonce is needed in all cases, but your
proposal would work for me.

So, in the repudiable case, the bytes that get signed consist of

	- The digest or challenge
	- A nonce
	- The repudiation token

But in the non-repudiable case, the repudiation token is absent (replaced
with padding).

This sounds OK to me.  Why do I get the feeling that I'm missing some kind of
detail?

		Marc

Tony Bartoletti wrote:
> 
> Marc,
> 
> I can see a way around this, maybe.
> 
> Suppose the signer always has the opportunity to add a recognized
> "RepudiableBinding" token as a nonce to what they sign.  Then, if
> I must enter into a NR transaction, I must take care NOT to include
> this token, else the transaction will be rejected.
> 
> The presence of the "RB" token "trumps" any other presumption of NR
> that the transaction might otherwise imply.  In particular, the
> signer can safely countersign "unseen challenges", though it would
> require the challenging party to do a tiny bit of parsing upon
> receipt of the signed challenge to ensure the original challenge
> is contained.
> 
> ___tony___
>

From: Peter Williams <[email-masked]>
To: "Todd Glassey @ GMTsw" <[email-masked]>, [email-masked]
Subject: RE: Certifiedtime.com
Date: Fri, 19 Nov 1999 15:35:31 -0800

You might as well tell us all about it now, without
selling it.

Is it a realization of the BOF and I-D work you have 
been arguing for in the last few months? Are there any 
downloads, free toolkits, multi-vendor interoperability 
trials, etc., etc.?

An occasional, small dash of marketing by 
individual technology leaders or user groups is ok, 
providing its designed to make open standards real for
all. (DoD folk here do it all the time...)

Sharing a passion for an internet PKI technology and 
its realization is what we are here for.  

> -----Original Message-----
> From: Todd Glassey @ GMTsw [mailto:[email-masked]]
> Sent: Friday, November 19, 1999 3:18 PM
> To: [email-masked]
> Cc: [email-masked]
> Subject: Re: Certifiedtime.com
> 
> 
> My profuse apologies to the list, the CC window was hidden, 
> Sorry Stephen,
> this was not intended to have been posted
> 
> ----- Original Message -----
> From: "Todd Glassey @ GMTsw" <[email-masked]>
> To: <[email-masked]>
> Cc: <[email-masked]>
> Sent: Friday, November 19, 1999 11:32 AM
> Subject: Certifiedtime.com
> 
> 
> > Lynn, I want to talk with you on the phine about 
> CertifiedTime.com and
> what
> > it does.
> 
> Todd
> 

Date: Fri, 19 Nov 1999 15:29:43 -0800
To: [email-masked], [email-masked]
From: Tony Bartoletti <[email-masked]>
Subject: Re: proposed key usage text

At 06:02 PM 11/19/1999 -0500, [email-masked] wrote:
[snip]
>     One other possibility would be for a rule to be applied to all new
>protocols other than those explicit barring NR certificates as follows: the
>suggested nonce MAY have the sequence (standard repudiation attribute)
>appended to it before signing.  It would be SEQUENCE { OID
>id-authentication-exchange, NULL }.

Tom,

Would the inclusion of (standard repudiation attribute) above be something
that can be toggled by the signer upon receipt (perhaps invisible receipt)
of the nonce?  Or would it be strictly controlled by the challenger?

My thought, as a sort of "Safety Feature", would be to set my signing
application to ALWAYS toggle to "repudiable", unless I forcefully override.

Do any extant protocols allow the "challengee" to append to a given
challange?  Seems only to require the challenger do a tiny bit of parsing
to ensure the original challenge was indeed contained.  Thus timeliness,
replay protection and POP are still satisfied.  And if the repudiation
attribute can "trump all others wrt NR", there is no longer the fear of
signing challenges, some portion of which may be "unseen".

___tony___

Tony Bartoletti                                             LL
IOWA Center                                              LL LL
Lawrence Livermore National Laboratory                LL LL LL
PO Box 808, L - 089                                   LL LL LL
Livermore, CA 94551-9900                              LL LL LLLLLLLL
phone: 925-422-3881   fax: 925-423-8081               LL LLLLLLLL
email: [email-masked]                                   LLLLLLLL

From: "Todd Glassey @ GMTsw" <[email-masked]>
To: <[email-masked]>
Cc: <[email-masked]>
Subject: Re: Certifiedtime.com
Date: Fri, 19 Nov 1999 15:18:19 -0800
Organization: GMTsw

My profuse apologies to the list, the CC window was hidden, Sorry Stephen,
this was not intended to have been posted

----- Original Message -----
From: "Todd Glassey @ GMTsw" <[email-masked]>
To: <[email-masked]>
Cc: <[email-masked]>
Sent: Friday, November 19, 1999 11:32 AM
Subject: Certifiedtime.com

> Lynn, I want to talk with you on the phine about CertifiedTime.com and
what
> it does.

Todd

Date: Fri, 19 Nov 1999 14:55:19 -0800
To: Marc Branchaud <[email-masked]>, [email-masked]
From: Tony Bartoletti <[email-masked]>
Subject: Re: proposed key usage text

At 02:48 PM 11/19/1999 -0800, you wrote:
>
>I can sortof see your point, but how can you have any sort of non-repudiation
>if the bits are unknown to the signer?  It seems to me that for
>non-repudiation the signer has to digest the bits directly, and so doesn't
>have to worry about being vulnerable to the kind of attacks you mention.
>
>I know I would be very uncomfortable if my application had to sign some
>random hash in a non-repudiable way.  I would very much want to see what I'm
>signing first.
>
>		Marc
>

Marc,

I can see a way around this, maybe.

Suppose the signer always has the opportunity to add a recognized
"RepudiableBinding" token as a nonce to what they sign.  Then, if
I must enter into a NR transaction, I must take care NOT to include
this token, else the transaction will be rejected.

The presence of the "RB" token "trumps" any other presumption of NR
that the transaction might otherwise imply.  In particular, the
signer can safely countersign "unseen challenges", though it would
require the challenging party to do a tiny bit of parsing upon
receipt of the signed challenge to ensure the original challenge
is contained.

___tony___

Tony Bartoletti                                             LL
IOWA Center                                              LL LL
Lawrence Livermore National Laboratory                LL LL LL
PO Box 808, L - 089                                   LL LL LL
Livermore, CA 94551-9900                              LL LL LLLLLLLL
phone: 925-422-3881   fax: 925-423-8081               LL LLLLLLLL
email: [email-masked]                                   LLLLLLLL

Date: Fri, 19 Nov 1999 17:37:42 -0500
From: Al Arsenault <[email-masked]>
Organization: @Home Network
To: Ed Gerck <[email-masked]>
CC: [email-masked], "David P. Kemp" <[email-masked]>, [email-masked]
Subject: Re: non-ephemeral vs. non-repudiation, was Re: proposed key usagetext

Ed Gerck wrote:
<large amount of material snipped>
> 
> Now, regarding the use of "falsely" (or, "truly"), please recall that
> non-repudiation is that which prevents even truthful denials. Ben King
> has also timely recalled the example of the non-repudiation fee of $50.00
> applied to all of us credit-card holders -- maybe, other points could be likewise
> recalled by re-reading the archives.
> 

AWA:  Again, I could not disagree more with this.  Non-repudiation is,
as the definition in 2459, and in Schneier, and in Ford & Baum, and in
... says, concerned with preventing *false denials*.  It should not be
thought of as preventing "truthful denials" - that's such a rare service
(at least in the US) that I don't think that we need to concern
ourselves with it.  Further, I think that if the vast majority of US
consumers understand that we're building Internet security systems that
will hold them liable for things they can prove they didn't do, this
stuff will never get used.  Most consumers understand that if something
happens and they can't prove that they didn't do it, they'll probably
get stuck for something, like the $50 liability mentioned above.  But,
they tend to have faith that if they can prove they didn't do it,
they're not going to be held responsible.  (Most customers, if able to
prove they didn't do something, would be able to beat the $50 charge by
the credit card company, too.  There aren't many courts that are going
to uphold such a contract.)

> Further, intent or cognizance of ulterior unspoken and unknowable
> motives is not in question here.  But,  again, if one insists on defining
> PKIX non-repudiation as that which "protects against the signing
> entity falsely denying some action" then one must be prepared to
> prove that intent (as in false or true denial) can be measured by an
> Internet protocol over the wire.  Can you?
> 

AWA:  Again, no, you don't have to do this in an Internet protocol; you
do it in the rest of the non-repudiation system/in the courts.

I'll state once again my position: accept the words that Tim and Russ
have proposed, and let's get on with this.

			Al Arsenault

Date: Fri, 19 Nov 1999 17:28:50 -0500
From: Al Arsenault <[email-masked]>
Organization: @Home Network
To: Tony Bartoletti <[email-masked]>
CC: [email-masked], Tim Polk <[email-masked]>, [email-masked]
Subject: Re: proposed key usage text

Tony,

	Comments in line.

Tony Bartoletti wrote:
> 
> At 10:11 PM 11/18/1999 -0500, Al Arsenault wrote:
> >
> >AWA:  The CA is involved in NR assertions only to the point of stating
> >its desires, and implicitly what it will or won't support with respect
> >to later investigations.  Everything else comes from outside the CA.
> 
> Al,
> 
> This is my conclusion, as well.
> 
> I suppose one must consider the NR bit to be a potential signal to
> (1) the CA upon certification, (2) the RP upon transaction acceptance,
> and (3) the signer upon transaction initiation.  And one must ask how
> much benefit, assurance or liability each can extract from this bit.
> The bit speaks to all three, and so its definition must reveal its
> significance to all three.
> 
> That is, I imagine myself an RP who wants certain transactions to
> be non-repudiable (as far as possible).  So I ensure my application
> only accepts NR=1 certified signatures, and I can sleep peacefully;)
> Seriously, what kind of assurance does this get me?  On the CA side,
> it would seem entirely dependent upon the CP statement, so in this
> respect we would need to think of it as the "CA's NR policies bit".
> 

AWA:  I agree with this.

> If there were some way to ensure that the signer can only initiate
> the transactions of interest through a NR-sensitive interface that
> flashes colors and warning buzzers when the user signs with NR=1,
> (and this could be somehow demonstrable at a later time) then of
> course the RP may sleep easier.  And so, I imagine, would the signer.
> 

AWA:  Again, I agree - it would make for a stronger NR system if this
could be shown to be the case.

> Which brings me around to the signer's interest in NR=1 certificates.
> 
> As a signer, why would I want one?  (Or, is NR-phobia a good thing?)
> Likely, I want one because some transaction required it.  How would
> I know this?  I suppose that my "signing application" will tell me.
> (NOTE:  I call it MY signing application, but would it not likely
> be the RP's applet?)  I suppose when I click the button that says:
> 
>     "Try our free trial home delivery?"  <OK>
> 
> it (the applet) may search my disk for an NR cert, and complain if
> one is not found.  But will it say anything at all if one IS found?
> As a prudent NR-cert holder, should I want low-level auditing
> running on my system at all times, just in case, and notarized on
> an hourly basis?
>

AWA:  The only reason I can think of for a signer wanting an NR cert is
because the application (s)he wants to use requires it.

I would hope that an NR system would say something about "this is the
key/certificate that I'm going to use; is this okay?"  If it did not,
but instead blindly selected keys, that might provide a ground for later
repudiation.
 
> Backing up a few steps, what is the possibility that I may request
> a certificate, and not even know that it is an NR-cert?
>

AWA:  One would hope that your application lets you look at the contents
of the certificate you get in some nice, human-friendly format.  I
recognize that not all products do, though; it's an issue that has to be
worked with developers.  It's also, in my opinion, beyond the scope of
what PKIX can do (we don't address the way systems present information
to humans.)
 
> It would seem that this NR-bit needs to speak loud and clear to all
> parties, and of course this means to all implementers of code.
> After all, the "Key-Usage Definitions" are first and foremost a
> signal to the folks who will write the code that reads the bits.
> 
> Does the definition say enough to them?  Perhaps it does?
> 

AWA:  To me, it says as much as it can.  Perhaps when Tom Gindin's draft
is more complete, that will help as well.  And, potentially, the ABA
might produce some useful guidelines.  But, I don't think that we should
hold up son-of-RFC-2459 because of it. 

			Al Arsenault

Date: Fri, 19 Nov 1999 17:22:31 -0500
From: Al Arsenault <[email-masked]>
Organization: @Home Network
To: Aram Perez <[email-masked]>
CC: [email-masked]
Subject: Re: proposed key usage text

Aram Perez wrote:
> 
> Hi Russ,
> 
> > Hi Aram.
> >
> >  >>       The digitalSignature bit is asserted when the subject public key
> >  >>       is used with a digital signature mechanism to support security
> >  >>       services other than non-repudiation (bit 1), certificate signing
> >  >>       (bit 5), or revocation information signing (bit 6). Digital  signa-
> >  >>       ture mechanisms are often used for entity authentication and data
> >  >>       origin authentication with integrity.
> >  >>
> >  >>       The nonRepudiation bit is asserted when the subject public key is
> >  >>       used to verify digital signatures used to provide a non-
> >  >>       repudiation service which protects against the signing entity
> >  >>       falsely denying some action, excluding certificate or CRL  signing.
> >  >>       In the case of later conflict, a reliable third party may deter-
> >  >>       mine the authenticity of the signed data.
> >  >>
> >  >>       Further distinctions between the digitalSignature and nonRepudia-
> >  >>       tion bits may be provided in specific certificate policies.
> >  >
> >  > What is happens when both the digitalSignature and nonRepudiation bits are
> >  > set? Does one of them take precendence?
> >
> > I guess that you missed our point altogether.  There is no precedence.  If
> > both the digitalSignature and nonRepudiation bits are set, then the public
> > key may be used with a digital signature mechanism to support
> > authentication and integrity and it may also be used to verify digital
> > signatures used to provide non-repudiation.  One public can might be used
> > for both purposes.
> 
> But how do you distinguish between what use was intended? If someone
> captures a message that I signed for "authentication and integrity" and
> another message that I signed for "non-repudiation", how does a third party
> distinguish which use was intended?
> 
> I have seen many authentication protocols that require the party being
> authenticated to sign a challenge (that is supposed to be a random number or
> a nonce). Now suppose that I'm trying to get access to a system that instead
> of sending me a random challenge, sends me the following message: "I agree
> to sell 1000 shares of Apple at $10.00 per share." My software will blindly
> sign the message and send my certificate which has the DS and NR bits set.
> Am I now obligated to sell 1000 shares of Apple at $10.00? Can I prove to a
> third party that I was only trying to do authentication and not
> non-repudiation?
> 
> Regards,
> Aram Perez

AWA:  Aram, that's what the rest of the non-repudiation system is for. 
Your key has been shown to have been used to sign a message.  You do not
want to take the action indicated in the signed message.  Among other
things, the following questions have to be answered:

	1 - was it really you that caused the signature to occur?  Was your key
compromised, or your workstation used by one of your co-workers without
your knowledge/permission?  What evidence exists that it really was or
was not you?

	2 - did you know what you were signing?  Should you have known?  What
evidence is there that you took a conscious effort to understand and
verify before signing?

	3 - was the key used appropriate for the message signed?

The value of the NR bit only enters into #3 here.  And I suspect you
will find a lawyer willing to argue for you and against you regardless
of the value of that bit.

A non-repudiation system consists of a lot more than just one bit in a
certificate.

			Al Arsenault

-- insert standard disclaimer about this not reflecting my employer's
policies here.

Date: Fri, 19 Nov 1999 17:15:39 -0500
From: Al Arsenault <[email-masked]>
Organization: @Home Network
To: Ed Gerck <[email-masked]>
CC: "David P. Kemp" <[email-masked]>, [email-masked]
Subject: Re: non-ephemeral vs. non-repudiation, was Re: proposed key usage text

(comment in line, below)

Ed Gerck wrote:
> 
> Al Arsenault wrote:
> 
> > ... when Ed says:
> >
> > > ... Further,
> > > a bank teller will not ask whether you "intended" to sign a
> > > check that was paid and then kindly reverse the charge to the
> > > bank if you say "No", but will verify whether the signature
> > > cannot be distinguished from your signature in the archives --
> > > in which case the teller will pay the check and will not reverse
> > > it, even if you later on prove that you were in coma shock
> > > that day.
> > >
> >
> > My attorney asserts that this is most assuredly not true, at least under
> > the US/Maryland legal systems.  She's confident that, as a competent
> > attorney, if we could "prove" that I could not possibly have written the
> > check, she could win this case in court, and get the money restored to
> > my account.
> 
> I can understand how she can say this *before* reading the
> contract you have with your bank ... but not afterwards.  Most
> probably, your bank has the same non-repudiation terms found in
> bank contracts in the UK (common law) and which I quoted here
> before.  Yes, even if you could prove beyond any doubt that you
> did not write that check, as long as:
> 
> (i) the bank teller could not have (in the balance of probabilities)
> distinguished the check signature from a signature you did *not*
> make, and
> 
> (ii) you could *not* prove that you told the bank not to cash that
> check *before* the check hit the bank teller,
> 
> you cannot repudiate that check. Freedom of contract has allowed
> you and the bank to define mutually acceptable rules, to which
> you must comply. Legally, in the US also.
> 

AWA:  No, this is not correct in the US.  I *can* and *will* repudiate
that check, and will most likely prevail in court. 

I readily acknowledge not knowing UK law on this point.  So, I will not
dispute what you say - I will leave support or disagreement for your
point to those who know what they're talking about.

According to my attorney's overview, this is how the argument would go:

	- remember that, as Ed himself has pointed out, any contract can be
nullified under the UCC if it is on its face unfair to one of the
signing parties.  This is particularly true if the party to which it is
unfair is a "standard consumer", and the other party is a
well-resourced, experienced organization.

	- so the trick would be to show that the contract between myself and
the bank is unfair to me.  This is accomplished as follows:

	1) prove that fraud can be committed.  This is trivial, given our
assumptions.  I can prove that I did not sign the check.  The bank
asserts that it has a signed check.  Therefore, fraud was committed, and
therefore fraud can be committed.  

	2) show that the bank itself could have committed the fraud. (I don't
have to show that the bank DID commit the fraud, or that it has ever
committed such fraud; just that it could.) This is the tricky part, but
what you would do is show that the bank could easily have gotten a check
printed up that would be valid for my account, and that the bank could
have forged my signature to meet their standards.  This most likely can
be shown - since the bank controls the standards for the signature, and
somebody is capable of meething their standards, as shown in 1), the
bank could if it wanted commit the fraud.

	3) show that if the bank did commit this fraud, I would be defenseless
under the terms of the contract.  That is, assuming that the terms of
the contract were in force, and that the bank had a "department of
forgery" set up to steal money from customers' accounts through forged
checks, I would be absolutely powerless to stop the bank from stealing
every nickel I have - they hold all the cards in the game.

Given these three items, it becomes clear that a contract that holds me
liable for something I can prove I didn't do is so one-sided in the
bank's favor that it is unfair to me, and thus the contract would be
nullified.

Now, in fact it would probably come down to which side had the better
lawyer, and who the judge was, but the lawyers I've talked to about this
are pretty confident about the scenario I've described.  Thus, Ed, I'm
going to stick to my disagreement with you.

> The same goes for your other examples of different technical
> definitions for non-repudiation -- X.509 itself agrees with Menezes,
> as I pointed out in another thread today.  But,  if one insists on
> defining non-repudiation as that which "protects against the signing
> entity falsely denying some action" then one must be prepared to
> prove that intent (as in false or true denial) can be measured by a
> protocol over the wire.  Can you?
> 

AWA:  No, I disagree with this point completely.  I do not have to prove
intent via a protocol over a wire.  "False denial" means that in point
of fact I did it and I'm trying to argue I didn't.  "True denial" means
that I really didn't do it, and I'm arguing that.  No protocol can ever
know which human is doing something, and thus whether a later denial
will be true or false.  That's what the rest of the non-repudiation
system is for.

The only place "intent" ever enters into non-repudiation is if I did
something without understanding the full implications of it - that is, I
signed a blank check and gave it to Dave K. to hold.  There, I really
did something, but I didn't mean for him to clean out my entire account,
just get 20 bucks cash for me. You can't tell that in a protocol,
either; that's what the rest of the NR system is for.

			Al Arsenault

-- insert usual disclaimer about this not reflecting my employer's
policies here.

Sender: [email-masked]
Date: Fri, 19 Nov 1999 14:48:49 -0800
From: Marc Branchaud <[email-masked]>
Organization: Xcert International Inc.
To: [email-masked]
Subject: Re: proposed key usage text

I can sortof see your point, but how can you have any sort of non-repudiation
if the bits are unknown to the signer?  It seems to me that for
non-repudiation the signer has to digest the bits directly, and so doesn't
have to worry about being vulnerable to the kind of attacks you mention.

I know I would be very uncomfortable if my application had to sign some
random hash in a non-repudiable way.  I would very much want to see what I'm
signing first.

		Marc

Terry Hayes wrote:
> 
> Marc Branchaud wrote:
> 
> > I suggest that the presence of the nonce be the distinguishing factor in mere
> > authentication vs. non-repudiation.
> >
> > If the intent is to sign for authentication, then the signer adds a nonce to
> > the blob being signed.
> >
> > If the intent is to sign for non-repudiation, then there is no nonce.
> >
> >                 Marc
> >
> 
> I don't buy this.  It would be true if I (or actually my signing application)
> recognized and verified every bit that was in the data being signed.  In this
> way, I can tell that the bits correctly relate to the transaction in progress.
> If there are bits that are unknown to the signer (such as a nonce supplied by
> the other party), then I can't tell if the other party is mounting some sort
> of attack by varying bits in the message.
> 
> There are cases (SET is one example - but don't get started on that) where one
> party signs references to data that it doesn't know to bind it to the rest of
> the transaction.
> 
> I'd be much more comfortable adding a nonce in all cases.
> 
> Terry

Date: Fri, 19 Nov 1999 13:38:24 -0800
From: Ed Gerck <[email-masked]>
To: [email-masked]
CC: Al Arsenault <[email-masked]>, "David P. Kemp" <[email-masked]>, [email-masked]
Subject: Re: non-ephemeral vs. non-repudiation, was Re: proposed key usagetext

[email-masked] wrote:

>      There are multiple definitions of the word "denial" and one of them
> yields a sensible meaning for Menezes' definition - see my elaboration
> below.
>
> (Menezes's definition, often quoted by Gerck:)
>
>    Non-repudiation: a service that prevents the denial of a previous
> act.
>
> [Tom Gindin]  Here are the six definitions given in Webster's New World
> Dictionary, boiled down to essentials: 1 - the opposite of compliance; 2 -
> the opposite of affirmation; 3 - a disowning or repudiation (the example
> given is a denial of one's family); 4 - a refusal to believe; 5 - a refusal
> to give; 6 - abstinence.  Obviously, one of the first three definitions is
> intended in the standard, and it seems likely to me that Ed and Menezes
> intend number 3 (especially since the definition actually uses the term
> repudiation), while almost everyone else (including me) thinks that number
> 2 is the main definition of the word.

No, speaking for myself ;-) I do not intend #3 to be used.  This should
have been clear by now, after tens (hundreds?) of messages where I
have written more or less always the same words:

"Authentication is akin to the affirmation of a truth, while non-repudiation
is akin to the denial of a falsity. Both are equivalent if and only if the system
is boolean -- which security systems almost never are, since they are not
atomic and they are not binary-valued".

My Webster quotes denial as a "negation in logic" -- and this is what I
always meant and is also what Menezes must have meant as well what
X.509 *itself* meant when it defines:

"Repudiation -- The denial by a user of having participated in part or all
  of a communication."

where one can read:

"Repudiation -- The negation by a user of having participated in part or all
  of a communication."

[Try also cf. Menezes: "non-repudiation -- a service that prevents the
negation  of a previous act."]

Now, if we don't want to split hairs  you may note that your Webster's
#2 preferred definition is akin to my Webster's definition for denial,
as a "negation in logic".  Of course, the "opposite of affirmation" is not
exactly the "negation of affirmation" but is good enough for our purposes.

So, if you have been thinking of #3 while you were reading my messages,
please read them again ;-)

:-) Now, there is a further meaning of denial which could be used in
this discussion, namely -- denial is a refusal to admit the truth or reality.
It is a psychological defense mechanism in which confrontation with a
personal problem or with reality is avoided by denying the existence of
the problem or reality.

Now, regarding the use of "falsely" (or, "truly"), please recall that
non-repudiation is that which prevents even truthful denials. Ben King
has also timely recalled the example of the non-repudiation fee of $50.00
applied to all of us credit-card holders -- maybe, other points could be likewise
recalled by re-reading the archives.

Further, intent or cognizance of ulterior unspoken and unknowable
motives is not in question here.  But,  again, if one insists on defining
PKIX non-repudiation as that which "protects against the signing
entity falsely denying some action" then one must be prepared to
prove that intent (as in false or true denial) can be measured by an
Internet protocol over the wire.  Can you?

Cheers,

Ed Gerck

Sender: [email-masked] (Terry Hayes)
Date: Fri, 19 Nov 1999 13:26:37 -0800
From: Terry Hayes <[email-masked]>
To: Marc Branchaud <[email-masked]>
CC: [email-masked]
Subject: Re: proposed key usage text

Marc Branchaud wrote:

> I suggest that the presence of the nonce be the distinguishing factor in mere
> authentication vs. non-repudiation.
>
> If the intent is to sign for authentication, then the signer adds a nonce to
> the blob being signed.
>
> If the intent is to sign for non-repudiation, then there is no nonce.
>
>                 Marc
>

I don't buy this.  It would be true if I (or actually my signing application)
recognized and verified every bit that was in the data being signed.  In this way, I
can tell that the bits correctly relate to the transaction in progress.  If there
are bits that are unknown to the signer (such as a nonce supplied by the other
party), then I can't tell if the other party is mounting some sort of attack by
varying bits in the message.

There are cases (SET is one example - but don't get started on that) where one party
signs references to data that it doesn't know to bind it to the rest of the
transaction.

I'd be much more comfortable adding a nonce in all cases.

Terry

From: [email-masked]
To: [email-masked]
cc: Ed Gerck <[email-masked]>, [email-masked]
Date: Fri, 19 Nov 1999 15:19:09 -0500
Subject: Re: non-ephemeral vs. non-repudiation, was Re: proposed key usage text

>      There are multiple definitions of the word "denial" and one of them
> yields a sensible meaning for Menezes' definition - see my elaboration
> below.  If one assumes the most common definition of the word, as most of
> us on the list have done, Menezes' definition is absurd - he must be using
> this other one.
>
>           Tom Gindin

Not that my opinion matters, but I disagree whole-heartedly.   It is my feeling
that Ed is correct in his interpretation of the definition cited.   An example
that
he used a few months ago involved the $50 non-repudiable liability assumed
by U.S. credit-card holders:  by signing the card-holder agreement, you agree
that $50 of any disputed transaction will be non-repudiable, i.e. you must pay
the $50, no matter what.   If the President and the Pope both swear you were
with them that day, you still have to pay.   That's the crux of non-repudiation:
it prevents even truthful denials.

Really though, I thought this issue had been beaten to death, stomped upon,
and had little pins stuck into voodoo doll symbols of itself.   Ed is trying to
get the name changed from "non-repudiation" to "the foo bit is set", so that
his sense of professional ethics will be served.   The resistance to changing
the bit-name stems, I assume, from the fact that many of our bosses will kill
us if we say we "let the IETF strike NR from the standard", because then
all of the banks (BoNY, DuetscheBank, etc) may flee.

Just as security through obscurity is no security at all, liability through
bit-setting
is no liability at all, either.   The attribute does not indicate liability.  It
indicates
that the bit was set by the signer according to the CA, and nothing else.

I have absolutely no idea what I am talking about, though.

--ben

Sender: [email-masked]
Date: Fri, 19 Nov 1999 13:17:44 -0800
From: Marc Branchaud <[email-masked]>
Organization: Xcert International Inc.
To: [email-masked]
Subject: Re: proposed key usage text

I suggest that the presence of the nonce be the distinguishing factor in mere
authentication vs. non-repudiation.

If the intent is to sign for authentication, then the signer adds a nonce to
the blob being signed.

If the intent is to sign for non-repudiation, then there is no nonce.

		Marc

[email-masked] wrote:
> 
> we are doing something like that for AADS radius (i.e. being able to upgrade
> something like 99% of the current internet ISP authentication infrastructure to
> digital signature authentication). The strategy is that the ISP sends a
> challenge string ... basically somehting like "please authenticate 'userid'"
> with a time-stamp/nonce (in lieu of the "please enter password" message), the
> user then adds their own nonce, signs it and returns it. Having webserver
> products at the large web farms also support radius ... then allows a single
> authentication administrative infrastructure for the majority of existing
> internet operations.
> 
> Aram Perez wrote:
> 
> > But how do you distinguish between what use was intended? If someone
> > captures a message that I signed for "authentication and integrity" and
> > another message that I signed for "non-repudiation", how does a third party
> > distinguish which use was intended?
> >
> > I have seen many authentication protocols that require the party being
> > authenticated to sign a challenge (that is supposed to be a random number or
> > a nonce). Now suppose that I'm trying to get access to a system that instead
> > of sending me a random challenge, sends me the following message: "I agree
> > to sell 1000 shares of Apple at $10.00 per share." My software will blindly
> > sign the message and send my certificate which has the DS and NR bits set.
> > Am I now obligated to sell 1000 shares of Apple at $10.00? Can I prove to a
> > third party that I was only trying to do authentication and not
> > non-repudiation?
> >
> > Regards,
> > Aram Perez

From: [email-masked]
To: Al Arsenault <[email-masked]>
cc: Ed Gerck <[email-masked]>, "David P. Kemp" <[email-masked]>, [email-masked]
Date: Fri, 19 Nov 1999 14:52:32 -0500
Subject: Re: non-ephemeral vs. non-repudiation, was Re: proposed key usage text

     There are multiple definitions of the word "denial" and one of them
yields a sensible meaning for Menezes' definition - see my elaboration
below.  If one assumes the most common definition of the word, as most of
us on the list have done, Menezes' definition is absurd - he must be using
this other one.

          Tom Gindin

Al Arsenault <[email-masked]> on 11/18/99 09:36:43 PM

To:   Ed Gerck <[email-masked]>
cc:   "David P. Kemp" <[email-masked]>, [email-masked]
Subject:  Re: non-ephemeral vs. non-repudiation, was Re: proposed key usage
      text

With all due respect to Ed Gerck and to Menezes, et alia, I must
disagree with Ed's proposed definition of non-repudiation.

The salient point is the absence of the word "falsely"; i.e.,

(Polk & Housley's proposed wording:)

  ...a non-repudiation service which protects against the signing entity
falsely denying some action...

(Menezes's definition, often quoted by Gerck:)

   Non-repudiation: a service that prevents the denial of a previous
act.

[Tom Gindin]  Here are the six definitions given in Webster's New World
Dictionary, boiled down to essentials: 1 - the opposite of compliance; 2 -
the opposite of affirmation; 3 - a disowning or repudiation (the example
given is a denial of one's family); 4 - a refusal to believe; 5 - a refusal
to give; 6 - abstinence.  Obviously, one of the first three definitions is
intended in the standard, and it seems likely to me that Ed and Menezes
intend number 3 (especially since the definition actually uses the term
repudiation), while almost everyone else (including me) thinks that number
2 is the main definition of the word.

To me, the presence of that word "falsely" is important.  Building a
service that purports to hold you responsible for something you can
prove beyond a doubt you didn't do is not in general useful.  (Although
I do acknowledge that there are some very rare situations where it is
useful and even necessary.  Those are not the general case, though.)

[Tom Gindin]   Given the definition of "denial" which Ed is using here, the
correct modifier for it would be "successfully" or "unsuccessfully" rather
than "falsely" or "truly".  However, I question how meaningful the
distinction is between an "unsuccessful denial" in this sense and a "false
denial" in the sense of the primary definition of "denial" (a claim that
something is either not true or not associated with one's self).

In addition, in my search of the technical literature, I find Menezes et
alia almost alone in this definition.  Almost everybody else includes
the word "falsely".  Check Schneier, for example.  Also, the write-up of
non-repudiation in Ford & Baum's "Secure Electronic Commerce" is one of
the better ones, in my opinion, and it certainly doesn't agree with
Menezes. So, I disagree with Ed's assertion that:

(snip)

Date: Fri, 19 Nov 1999 11:41:08 -0800
To: Al Arsenault <[email-masked]>
From: Tony Bartoletti <[email-masked]>
Subject: Re: proposed key usage text
Cc: [email-masked], Tim Polk <[email-masked]>, [email-masked]

At 10:11 PM 11/18/1999 -0500, Al Arsenault wrote:
>
>AWA:  The CA is involved in NR assertions only to the point of stating
>its desires, and implicitly what it will or won't support with respect
>to later investigations.  Everything else comes from outside the CA.

Al,

This is my conclusion, as well.

I suppose one must consider the NR bit to be a potential signal to
(1) the CA upon certification, (2) the RP upon transaction acceptance,
and (3) the signer upon transaction initiation.  And one must ask how
much benefit, assurance or liability each can extract from this bit.
The bit speaks to all three, and so its definition must reveal its
significance to all three.

That is, I imagine myself an RP who wants certain transactions to
be non-repudiable (as far as possible).  So I ensure my application
only accepts NR=1 certified signatures, and I can sleep peacefully;)
Seriously, what kind of assurance does this get me?  On the CA side,
it would seem entirely dependent upon the CP statement, so in this
respect we would need to think of it as the "CA's NR policies bit".

If there were some way to ensure that the signer can only initiate
the transactions of interest through a NR-sensitive interface that
flashes colors and warning buzzers when the user signs with NR=1,
(and this could be somehow demonstrable at a later time) then of
course the RP may sleep easier.  And so, I imagine, would the signer.

Which brings me around to the signer's interest in NR=1 certificates.

As a signer, why would I want one?  (Or, is NR-phobia a good thing?)
Likely, I want one because some transaction required it.  How would
I know this?  I suppose that my "signing application" will tell me.
(NOTE:  I call it MY signing application, but would it not likely
be the RP's applet?)  I suppose when I click the button that says:

    "Try our free trial home delivery?"  <OK>

it (the applet) may search my disk for an NR cert, and complain if
one is not found.  But will it say anything at all if one IS found?
As a prudent NR-cert holder, should I want low-level auditing
running on my system at all times, just in case, and notarized on
an hourly basis?

Backing up a few steps, what is the possibility that I may request
a certificate, and not even know that it is an NR-cert?

It would seem that this NR-bit needs to speak loud and clear to all
parties, and of course this means to all implementers of code.
After all, the "Key-Usage Definitions" are first and foremost a
signal to the folks who will write the code that reads the bits.

Does the definition say enough to them?  Perhaps it does?

___tony___

Tony Bartoletti                                             LL
IOWA Center                                              LL LL
Lawrence Livermore National Laboratory                LL LL LL
PO Box 808, L - 089                                   LL LL LL
Livermore, CA 94551-9900                              LL LL LLLLLLLL
phone: 925-422-3881   fax: 925-423-8081               LL LLLLLLLL
email: [email-masked]                                   LLLLLLLL

From: "Todd Glassey @ GMTsw" <[email-masked]>
To: <[email-masked]>
Cc: <[email-masked]>
Subject: Certifiedtime.com
Date: Fri, 19 Nov 1999 11:32:43 -0800
Organization: GMTsw

Lynn, I want to talk with you on the phine about CertifiedTime.com and what
it does. I believe that this is the only reliable time source in the
commercial world today and want to explain how and why what we do what we
do.

Our system is a commercial Timing Authority selling the setting of
commercial clients time and timebase services. We are a private company that
provides Trusted Third Party timesetting and this would be a good value at
FD's operating service models.

I suggest that we chat and setup a dog and pony.

Todd

Reply-To: <[email-masked]>
From: "Jeffrey Hyman" <[email-masked]>
To: <[email-masked]>
Subject: unsubscribe
Date: Fri, 19 Nov 1999 10:21:21 -0800
Importance: Normal

unsubscribe

Reply-To: <[email-masked]>
From: "Jeffrey Hyman" <[email-masked]>
To: <[email-masked]>
Subject: UNSUBSCRIBE
Date: Fri, 19 Nov 1999 10:11:18 -0800
Importance: Normal

UNSUBSCRIBE

From: [email-masked]
To: "Aram Perez" <[email-masked]>
cc: [email-masked]
Date: Fri, 19 Nov 1999 09:02:34 -0800
Subject: Re: proposed key usage text

we are doing something like that for AADS radius (i.e. being able to upgrade
something like 99% of the current internet ISP authentication infrastructure to
digital signature authentication). The strategy is that the ISP sends a
challenge string ... basically somehting like "please authenticate 'userid'"
with a time-stamp/nonce (in lieu of the "please enter password" message), the
user then adds their own nonce, signs it and returns it. Having webserver
products at the large web farms also support radius ... then allows a single
authentication administrative infrastructure for the majority of existing
internet operations.

Aram Perez wrote:

> But how do you distinguish between what use was intended? If someone
> captures a message that I signed for "authentication and integrity" and
> another message that I signed for "non-repudiation", how does a third party
> distinguish which use was intended?
>
> I have seen many authentication protocols that require the party being
> authenticated to sign a challenge (that is supposed to be a random number or
> a nonce). Now suppose that I'm trying to get access to a system that instead
> of sending me a random challenge, sends me the following message: "I agree
> to sell 1000 shares of Apple at $10.00 per share." My software will blindly
> sign the message and send my certificate which has the DS and NR bits set.
> Am I now obligated to sell 1000 shares of Apple at $10.00? Can I prove to a
> third party that I was only trying to do authentication and not
> non-repudiation?
>
> Regards,
> Aram Perez

Date: Fri, 19 Nov 1999 08:21:41 -0800
Subject: Re: proposed key usage text
From: "Aram Perez" <[email-masked]>
To: [email-masked]

Hi Russ,

> Hi Aram.
> 
>  >>       The digitalSignature bit is asserted when the subject public key
>  >>       is used with a digital signature mechanism to support security
>  >>       services other than non-repudiation (bit 1), certificate signing
>  >>       (bit 5), or revocation information signing (bit 6). Digital  signa-
>  >>       ture mechanisms are often used for entity authentication and data
>  >>       origin authentication with integrity.
>  >>
>  >>       The nonRepudiation bit is asserted when the subject public key is
>  >>       used to verify digital signatures used to provide a non-
>  >>       repudiation service which protects against the signing entity
>  >>       falsely denying some action, excluding certificate or CRL  signing.
>  >>       In the case of later conflict, a reliable third party may deter-
>  >>       mine the authenticity of the signed data.
>  >>
>  >>       Further distinctions between the digitalSignature and nonRepudia-
>  >>       tion bits may be provided in specific certificate policies.
>  >
>  > What is happens when both the digitalSignature and nonRepudiation bits are
>  > set? Does one of them take precendence?
>
> I guess that you missed our point altogether.  There is no precedence.  If
> both the digitalSignature and nonRepudiation bits are set, then the public
> key may be used with a digital signature mechanism to support
> authentication and integrity and it may also be used to verify digital
> signatures used to provide non-repudiation.  One public can might be used
> for both purposes.

But how do you distinguish between what use was intended? If someone
captures a message that I signed for "authentication and integrity" and
another message that I signed for "non-repudiation", how does a third party
distinguish which use was intended?

I have seen many authentication protocols that require the party being
authenticated to sign a challenge (that is supposed to be a random number or
a nonce). Now suppose that I'm trying to get access to a system that instead
of sending me a random challenge, sends me the following message: "I agree
to sell 1000 shares of Apple at $10.00 per share." My software will blindly
sign the message and send my certificate which has the DS and NR bits set.
Am I now obligated to sell 1000 shares of Apple at $10.00? Can I prove to a
third party that I was only trying to do authentication and not
non-repudiation?

Regards,
Aram Perez

Date: Fri, 19 Nov 1999 07:49:16 -0800
From: Ed Gerck <[email-masked]>
To: Russ Housley <[email-masked]>
CC: Stefan Santesson <[email-masked]>, [email-masked]
Subject: Re: non-repudiation, was Re: proposed key usage text

Russ Housley wrote:

> Ed:
>
> To my way of thinking, you are omitting an important
> distinction.  Authentication involves only two parties.  In those two
> parties are satisfied, then sthe service is provided.  Non-repudiation
> involves three parties.

Russ:

The distinction is omitted because it is not correct, though often
mentioned. The same argument you make for non-repudiation can
of course be  made for authentication -- or, where would one consider
the CA?  The CA is a third-party; authentication per X.509 involves
three parties. Conversely, authentication even in X.509/PKIX (but, not
for end-users) can be provided with only two parties in the case of
self-signed certificates, which also opens the possibility for
non-repudiation based on two parties only -- with the
same problems/features as when self-signed certificates are used.

> In a conflict, the two parties can takes theire
> evidence to a third party (a judge or adjudicator) who can independently
> verify the transactions without either party having to disclose any secret
> or private values.

In a three-party model, but in the same way as authentication -- where in the
case of absence of a known public-key for each, the two parties can
take their query to a third-party (the CA) who can independently
provide the respective keys without either party having to disclose
any secret or private values.

This could also be a four-party model for authentication and
for non-repudiation, where each party would *additionally* rely
on a common insurance agent. Or, a five-party model where
the insurance agent would be different for each party and could
then dispute between themselves.  Or, a six-party model, or,
seven-party and so on as you include an arbitration court,
jury, etc.

So, the number of parties involved  is not what distingushes
authentication from non-repudiation [1].

Further, in PKIX/X.509 both authentication and non-repudiation
must be based on three-parties for end-users [2].

Cheers,

Ed Gerck

[1]  Both dialogue parties (though NOT in PKIX/X.509) could also
rely only on themselves for each case.  To do this in a reliable
fashion one would need however to consider the dynamics of trust
building between both parties, which is  outside the scope of
X.509/PKIX  *both* for authentication as well as for non-repudiation
cases.

[2]  BUT not for the CA signing certificate which is self-signed
for authentication and self-validated for non-repudiation.  If I
receive a CA certificate signed by Verisign, I have no algorithmic
way of relying on it and I need to trust Verisign to affirm signing it
by itself (in self-authentication) or to deny its validity by itself (in
self-repudiation), as well known.  Note that simple absence of that
CA certificate in a CRL is not enough to support its validity in
non-repudiation because it might be a rogue certificate.  And, even
if the CA certificate came embedded in my newest browser, because
that CA certificate is a new trust point that I need to acquire and I
have no assurances from the browser provider that any embedded
certificate is correct.

Date: Fri, 19 Nov 1999 09:32:55 -0500
To: Ed Gerck <[email-masked]>
From: Russ Housley <[email-masked]>
Subject: Re: non-repudiation, was Re: proposed key usage text
Cc: Stefan Santesson <[email-masked]>, [email-masked]

Ed:

To my way of thinking, you are omitting an important 
distinction.  Authentication involves only two parties.  In those two 
parties are satisfied, then sthe service is provided.  Non-repudiation 
involves three parties.  In a conflict, the two parties can takes theire 
evidence to a third party (a judge or adjudicator) who can independently 
verify the transactions without either party having to disclose any secret 
or private values.

Russ

At 08:59 AM 11/18/99 -0800, Ed Gerck wrote:

>Stefan Santesson wrote:
>
> > In fact we know rather well, up to a certain level, what NR means.
> >
> > NR is defined in X.509 as:
> >
> > Non-repudiation:  This service provides proof of the integrity and 
> origin of
> > data  both in an unforgeable relationship  which can be verified by any 
> third
> > party at any time.
>
>This definition is wrong, as well as the consequences derived from it. Compare
>with the technical definition of Menezes in  Handbook of Applied
>Cryptography (cf.):
>
>  Non-repudiation: a service that prevents the denial of a previous act.
>
>and we may agree that the definition in X.509 is just a round-about way
>of defining *strong authentication* -- where authentication affirms the
>truth of an act (which can be verified by any third party at any time).
>Quite different logic, as non-repudiation denies the falsity of an act --
>and, thus, prevents the denial of the act.  Both are equal if and only if
>the proposition is boolean, which it almost never the case is in security
>(where propositions are not atomic, and are multivalued).
>
>So, confusing non-repudiation with "authentication", or
>"strong authentication", or "non-ephemeral authentication"
>and thus actually vacating the concept of non-repudiation
>will not go very far.  It leaves non-repudiation undefined
>though still needed.
>
>In other words, to rename or to forget a problem is not a
>solution to the problem ... at least, technically ;-)
>
>Cheers,
>
>Ed Gerck

Date: Fri, 19 Nov 1999 09:15:13 -0500
To: [email-masked]
From: Russ Housley <[email-masked]>
Subject: Re: proposed key usage text
Cc: [email-masked]

Hi Aram.

 >>       The digitalSignature bit is asserted when the subject public key
 >>       is used with a digital signature mechanism to support security
 >>       services other than non-repudiation (bit 1), certificate signing
 >>       (bit 5), or revocation information signing (bit 6). Digital  signa-
 >>       ture mechanisms are often used for entity authentication and data
 >>       origin authentication with integrity.
 >>
 >>       The nonRepudiation bit is asserted when the subject public key is
 >>       used to verify digital signatures used to provide a non-
 >>       repudiation service which protects against the signing entity
 >>       falsely denying some action, excluding certificate or CRL  signing.
 >>       In the case of later conflict, a reliable third party may deter-
 >>       mine the authenticity of the signed data.
 >>
 >>       Further distinctions between the digitalSignature and nonRepudia-
 >>       tion bits may be provided in specific certificate policies.
 >
 > What is happens when both the digitalSignature and nonRepudiation bits are
 > set? Does one of them take precendence?

I guess that you missed our point altogether.  There is no precedence.  If 
both the digitalSignature and nonRepudiation bits are set, then the public 
key may be used with a digital signature mechanism to support 
authentication and integrity and it may also be used to verify digital 
signatures used to provide non-repudiation.  One public can might be used 
for both purposes.

Russ

From: Steve Cummings <[email-masked]>
Date: Fri, 19 Nov 1999 08:14:01 -0600
Subject: subscribe
TO: [email-masked]

--openmail-part-166c861d-00000001
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Content-Disposition: inline; filename="BDY.TXT"

subscribe

--openmail-part-166c861d-00000001--

From: [email-masked]
To: [email-masked]
Date: Tue, 16 Nov 1999 18:11:43 -0500
Subject: remove

From: "Khaja E. Ahmed" <[email-masked]>
To: <[email-masked]>
Subject: ANSI X9.79 - CA Control Objectives.
Date: Fri, 19 Nov 1999 00:47:29 -0800
Importance: Normal

Does anyone know if there a publicly accessible location of the draft ANSI
X9.79 standard - "PKI Practices and Policy Framework", editor Mark Ludlin?

If so, can some kindly soul reply with a pointer to this draft.

Thanks.

Khaja

Date: Thu, 18 Nov 1999 22:57:34 -0800
From: Ed Gerck <[email-masked]>
To: Al Arsenault <[email-masked]>
CC: "David P. Kemp" <[email-masked]>, [email-masked]
Subject: Re: non-ephemeral vs. non-repudiation, was Re: proposed key usage text

Al Arsenault wrote:

> ... when Ed says:
>
> > ... Further,
> > a bank teller will not ask whether you "intended" to sign a
> > check that was paid and then kindly reverse the charge to the
> > bank if you say "No", but will verify whether the signature
> > cannot be distinguished from your signature in the archives --
> > in which case the teller will pay the check and will not reverse
> > it, even if you later on prove that you were in coma shock
> > that day.
> >
>
> My attorney asserts that this is most assuredly not true, at least under
> the US/Maryland legal systems.  She's confident that, as a competent
> attorney, if we could "prove" that I could not possibly have written the
> check, she could win this case in court, and get the money restored to
> my account.

I can understand how she can say this *before* reading the
contract you have with your bank ... but not afterwards.  Most
probably, your bank has the same non-repudiation terms found in
bank contracts in the UK (common law) and which I quoted here
before.  Yes, even if you could prove beyond any doubt that you
did not write that check, as long as:

(i) the bank teller could not have (in the balance of probabilities)
distinguished the check signature from a signature you did *not*
make, and

(ii) you could *not* prove that you told the bank not to cash that
check *before* the check hit the bank teller,

you cannot repudiate that check. Freedom of contract has allowed
you and the bank to define mutually acceptable rules, to which
you must comply. Legally, in the US also.

The same goes for your other examples of different technical
definitions for non-repudiation -- X.509 itself agrees with Menezes,
as I pointed out in another thread today.  But,  if one insists on
defining non-repudiation as that which "protects against the signing
entity falsely denying some action" then one must be prepared to
prove that intent (as in false or true denial) can be measured by a
protocol over the wire.  Can you?

Cheers,

Ed Gerck

Date: Thu, 18 Nov 1999 22:11:56 -0500
From: Al Arsenault <[email-masked]>
Organization: @Home Network
To: Tony Bartoletti <[email-masked]>
CC: [email-masked], Tim Polk <[email-masked]>, [email-masked]
Subject: Re: proposed key usage text

Tony Bartoletti wrote:
> 
> [Tim Polk provides, from 4.2.1.3 Key Usage]:
> 
>    The nonRepudiation bit is asserted when the subject public key is
>    used to verify digital signatures used to provide a non-
>    repudiation service which protects against the signing entity
>    falsely denying some action, excluding certificate or CRL  signing.
>    In the case of later conflict, a reliable third party may deter-
>    mine the authenticity of the signed data.
> 
> Apologies to Tim Polk and Russ Housley, but this NR paragraph is easily
> as wishy-washy as the original, if not more so.  Are we to suppose that
> the NR bit could NOT be used to protect against a presumed signer "honestly"
> denying some action?  Are we to suppose that if NR=0, then a reliable third
> party is somehow precluded from determining the authenticity?
> 

AWA:  As I noted in my response to Ed Gerck, yes, I believe that in the
general case the NR bit is irrelevant if a presumed signer is "honestly"
(and has the evidence to back it up) denying some action.  Also, if NR
=0, the attorneys will do what they want, and that may include holding
the signer liable for his/her actions.  All that NR=0 means is that the
CA did not want this certificate to be used in situations where a
non-repudiation service is offered, and possibly the CA will not/cannot
support any "investigation".

> Importantly, is the term "signing entity" intended to signify the
> "ActiveSigner", the "SubscriberInFact" or the "SubscriberOfRecord"?
> (See definitions below.)
>

AWA:  In your terms, the "SubscriberOfRecord".  That is the "purported
signer" of the message, unless demonstrated otherwise.
 
> It doth seem to me that the NR-bit asserts nothing of any substance.
>

AWA:  It asserts the CA's intent.
 
<CF stuff snipped.>

> [Tom writes]
> >     Mine replaces the clause starting with "which protects" by : "which
> >provides evidence that a given object was signed by the private key
> >corresponding to a given certificate which was valid at the time of
> >signature. "
> >
> >     The issue comes down to which assertions are necessary to constitute a
> >non-repudiation service.  In particular, is a service still a
> >non-repudiation service if the principal evidence that the signer is also
> >the subject of the signing certificate is derived from the CA?  Also, is a
> >service still a non-repudiation service if there is not conclusive proof
> >that the signer was adequately informed of the content of the document
> >being signed?
> >
> >          Tom Gindin
> 
> Tom,
> 
> I agree that we need to ask about the utility of the assertion made wrt NR.
> Your version seems to boil down to "a cert for this key was valid at time
> of signature", which seems like an odd assertion for a CA to make before
> any such signatures have been generated.
> 
> Since it is the CA which signs, and hence asserts the key usage binding,
> one has to ask what assertion the CA can make that will make the given
> certificate more "useful" to some (possibly independent) NR service.
> 
> This is a question in two parts:
> 
>   a.  What CA-asserted key usage restrictions are reasonably enforceable
>       by the CA (hence worth more than simply "the CA wishes...").
>

AWA:  None are "enforceable" by the CA; they're all enforced by the
applications/rest of the system.  The only thing a CA can do after
issuing the certificate is, in accordance with its CP/CPS, maintain
records (or not), and cooperate or not with later investigations.
 
>   b.  What subset of (a) above are of value to any independent NR service.
> 
> In particular, is the NR service provider interested in binding a given
> signature act to the: (my definitions)
> 
> 1   SubscriberInFact:
>         The person who presented themselves as "X" to the CA in order to
>         receive a certificate that says "key owned by X"
> 
> 2   SubscriberOfRecord:
>         The person named as subscriber in the certificate.  That is, the
>         "X" in "key owned by X"
> 
> 3   ActiveSigner:
>         The person actually effecting a signature to occur, in particular,
>         independent of whether or not they are the "owner".
> 
> Consider that if person Y presents herself as X to a CA and obtains a
> fraudulent certificate, but then has the key stolen and used by Z,
> all three of the above may be different people.  In a certificate fraud,
> we might expect (1) and (3) to be functionally the same, and yet it
> seems that much of NR is focused upon binding the act to (2)!
>

AWA:  As already pointed out:  If 1 <> 2, then a fraud or effor has
occurred.  The system depends on the CA preventing this; if it happens,
then all of the security of the PKI has vanished.

Assuming that 1 = 2, if 1 <> 3, then a "key compromise" (in effect) has
occurred. (Whether somebody stole the private key, or broke into the
facility and gained access to the computer on which the key was stored,
or factored a large composite number into its primes, or... is not
important.  We consider whatever happened to be a "key compromise".)
Again, in this case the security of the PKI (for at least this part of
it) is gone.  No NR or any other system in the world will protect
against this.

> Should NR=1 be the CA's vouching for a (functional) equivalence between
> some two of the above?  But what CA is of use that does not intend to
> assert that the "SubscriberInFact" is exactly the "SubscriberOfRecord"?
>

AWA:  No, NR=1 is not specifically the CA vouching for anything related
to 1-3 above.  In every certificate, the CA asserts that 1 = 2; it is up
to the rest of the system to assert that 1=3 and 2= 3 (the CA can't do
anything about that).  NR=1 is simply the CA's assertion about its
desires for the use of the certificate, and possibly an indication of
the support it will or won't provide later on.

<snip>
> 
> The more I think about it, the less it seems that a CA should be
> centrally involved in NR assertions.
> 

AWA:  The CA is involved in NR assertions only to the point of stating
its desires, and implicitly what it will or won't support with respect
to later investigations.  Everything else comes from outside the CA.

				Al Arsenault

-- this message represents the opinions of its author, and may or may
not represent the policies of his employer or of any other organization
with which he has a relationship

Date: Thu, 18 Nov 1999 21:54:10 -0500
From: Al Arsenault <[email-masked]>
Organization: @Home Network
To: Peter Williams <[email-masked]>
CC: Russ Housley <[email-masked]>, "[email-masked]'" <[email-masked]>
Subject: Re: Forward-dated entries in a CRL

Okay, I'll take a shot, but with the usual caveat that this represents
only my opinion, not official DoD positions:

Peter Williams wrote:

> Perhaps, answer the following question:
> 
> User signed transaction arrives at 13:00; it was timestamped at 11:00.
> Latest CRL was issued at 12:00, with 1 revocation notice, dated 10:00. User
> verifies authenticity at 14:00, after lunch, noting the latest CRL lists on
> itself
> a revoked certificate - for a cert used during PKIX cert processing.
> 
> Is the document signature good?  Is the contract properly signed?
>

Under your scenario, no.  There is strong evidence (as accepted by a CA,
indicated in the "invalidity Date" in the CRL) that the certificate was
revoked (1000) prior to the timestamp (1100), and thus, this is not a
valid transaction.
 
> Would DoD recognise the document as signed, and effective, for
> example, today, or not?
> 

It depends on a bunch of things.  First of all, a lot of the
applications with which I'm familiar don't do things with any finer
granularity than 1 day, in which case this transaction would be rejected
(since revocation happened on the same day as the transaction).  
Assuming that you had granularity to the hour, or even to the second,
then it would depend on how the applications treated the extension.  If
they chose to ignore it (as Russ pointed out, it's non-critical), then I
'm not sure what they'd do.  If they processed it, then they would
probably reject the transaction as well.

(A more interesting case would be if the transaction had been
time-stamped at 0800, with the rest of the data as you specify.  In that
case, the "right thing" to do would be to accept the transaction, but
I'm willing to bet that a significant number of applications would
reject it.)

			Al Arsenault

-- the opinions stated here are those of the author, and may or may not
reflect the official policies of his employer or of any other
organization with which he has a relationship.

Date: Thu, 18 Nov 1999 21:36:43 -0500
From: Al Arsenault <[email-masked]>
Organization: @Home Network
To: Ed Gerck <[email-masked]>
CC: "David P. Kemp" <[email-masked]>, [email-masked]
Subject: Re: non-ephemeral vs. non-repudiation, was Re: proposed key usage text

With all due respect to Ed Gerck and to Menezes, et alia, I must
disagree with Ed's proposed definition of non-repudiation.

The salient point is the absence of the word "falsely"; i.e.,

(Polk & Housley's proposed wording:)

  ...a non-repudiation service which protects against the signing entity
falsely denying some action...

(Menezes's definition, often quoted by Gerck:)

   Non-repudiation: a service that prevents the denial of a previous
act.

To me, the presence of that word "falsely" is important.  Building a
service that purports to hold you responsible for something you can
prove beyond a doubt you didn't do is not in general useful.  (Although
I do acknowledge that there are some very rare situations where it is
useful and even necessary.  Those are not the general case, though.)

In addition, in my search of the technical literature, I find Menezes et
alia almost alone in this definition.  Almost everybody else includes
the word "falsely".  Check Schneier, for example.  Also, the write-up of
non-repudiation in Ford & Baum's "Secure Electronic Commerce" is one of
the better ones, in my opinion, and it certainly doesn't agree with
Menezes. So, I disagree with Ed's assertion that:

> 
> Also, PKIX standard is free to call "non-repudiation" what is
> "non-ephemeral" but this seems to *add* to the confusion, no?
> It would decrease interoperation with accepted usages of the term, in
> the real-world of business for example.  Or, when one consults a
> dictionary. Or, with technical cryptographic texts and textbooks.
> It would be a private language.
> 

It might disagree with some limited set of texts, but not what appears
to me to be the majority.

Added to all of this is that, at least in the US legal system (and yes,
I recognize the international scope of PKIX, but I'm simply not as
familiar with other legal systems), any "contract" which purported to
hold me liable for something that I can prove I didn't do will almost
assuredly be tossed out in court as being "unfair" to me.  This is
particulary true when an individual is dealing with a large institution
such as a bank.  So, when Ed says:

> ... Further,
> a bank teller will not ask whether you "intended" to sign a
> check that was paid and then kindly reverse the charge to the
> bank if you say "No", but will verify whether the signature
> cannot be distinguished from your signature in the archives --
> in which case the teller will pay the check and will not reverse
> it, even if you later on prove that you were in coma shock
> that day.
> 

My attorney asserts that this is most assuredly not true, at least under
the US/Maryland legal systems.  She's confident that, as a competent
attorney, if we could "prove" that I could not possibly have written the
check, she could win this case in court, and get the money restored to
my account.  (Of course, I'd wind up paying her in legal fees far more
than the amount of any check that could possibly clear against my
account, so I'd have to make a tough choice, but that's a different
issue. :-)

I liked the words that Tim and Russ proposed.  I suggest that we go with
them.

			Al Arsenault

-- this message reflects the opinion of the author only, and may or may
not reflect the policies of his employer or of any other organization
with which he has a relationship.

> So, "intent" has nothing to do with non-repudiation.  Nor,
> whether it is ephemeral. An order to fire a bomb needs to
> be non-repudiable and yet it is very ephemeral.
> 
> Cheers,
> 
> Ed Gerck

Date: Thu, 18 Nov 1999 19:35:40 -0500
To: Ed Gerck <[email-masked]>
From: Stephen Kent <[email-masked]>
Subject: Re: non-ephemeral vs. non-repudiation, was Re: proposed keyusagetext
Cc: [email-masked]

Ed,

i was discussing reality, as reflected in standard protocols, as I 
said.  None of them use ephemeral signing key for authentication. I 
was not discussing what one might do, or why.

Steve

From: Peter Williams <[email-masked]>
To: Ed Gerck <[email-masked]>
Cc: [email-masked]
Subject: RE: non-repudiation, was Re: proposed key usage text
Date: Thu, 18 Nov 1999 16:28:37 -0800

This mail discusses NR. You are warned to
pass by, if you have real work to do.

> -----Original Message-----
> From: Ed Gerck [mailto:[email-masked]]
> Sent: Thursday, November 18, 1999 2:12 PM
> To: David P. Kemp
> Cc: [email-masked]
> Subject: Re: non-repudiation, was Re: proposed key usage text
> 
> 
> 
> 
> "David P. Kemp" wrote:
> 
> > > Date: Thu, 18 Nov 1999 12:02:54 -0800
> > > From: Ed Gerck <[email-masked]>
> > >
> > > Stefan Santesson wrote:
> > >
> > > > How can you say that the X.509 definition is wrong???
> > >
> > > Because it is redundant (the same as authentication as I 
> commented)
> > > and thus superfluous.
> >
> > Some people believe that there is a difference between "provable
> > data origin authentication with integrity" and "entity 
> authentication",
> > and that nonRepudiation as used in X.509 is an appropriate 
> name for the
> > former.
> 
> David:
> 
> It is useful to list what X.509 actually says before further 
> discussing about
> "nonRepudiation as used in X.509".  These are all the 
> occurrences that I
> find when I look for the key text "repudiation" in X.509:
> 
>  "It is a matter for the security policy and responsibility 
> of the CA to keep old
>  certificates for a period of time if a non repudiation of 
> data service is provided."
> 
>  "If a non-repudiation of data service is dependent on keys 
> provided by the CA,
>  the service should ensure that all relevant keys of the CA 
> (revoked or expired)
>  and the timestamped revocation lists are archived and 
> certified by a current
>  authority."
> 
>  "nonRepudiation:  for verifying digital signatures used in 
> providing a
>  nonrepudiation service which protects against the signing 
> entity falsely
>  denying some action (excluding certificate or CRL signing, 
> as in f) or g)
>  below);"
> 
>  "The date in this extension is not, by itself, sufficient 
> for nonrepudiation
>  purposes. For example, this date may be a date advised by 
> the private key
>  holder, and it is possible for such a person to fraudulently 
> claim that a key
>  was compromised some time in the past, in order to repudiate a
>  validly-generated signature."
> 
>  "Repudiation -- The denial by a user of having participated 
> in part or all
>  of a communication."
> 
> and, the one quoted by Stefan:
> 
>  "Non-repudiation -- This service provides proof of the 
> integrity and origin
>  of data -- both in an unforgeable relationship -- which can 
> be verifed by any
>  third party at any time."
> 
> plus:
> 
>  "The data integrity mechanism supports the data integrity 
> service. It also
>  partially supports the non-repudiation service (that service 
> also needs the
>  digital signature mechanism for its requirements to be fully met)."
> 
>  "The digital signature mechanism supports the data integrity 
> service and
>  also supports the non-repudiation service."
> 
> which shows that X.509 itself  is in contradiction.  To 
> X.509, nonrepudiation
> does NOT provide proof of integrity, which needs the digital signature
> mechanism.  This is made clear in  Table B.1 "Threats and 
> protection", where
> we can read that the non-repudiation service is depicted as 
> protecting against
> the threats  of replay and repudiation -- and that "data 
> integrity" and "end
> authentication" are different services, different from 
> non-repudiation.
> 
> Thus, that is why I wrote the following in regard to the 
> definition that Stefan
> quoted from X.509:
> 
>  This definition is wrong, as well as the consequences 
> derived from it. Compare
>  with the technical definition of Menezes in  Handbook of Applied
>  Cryptography (cf.):
> 
>  Non-repudiation: a service that prevents the denial of a 
> previous act.
> 
> But, surprise! The above NR definition by Menezes can be also found in
> *another* part of X.509, if you read the X.509 definition for 
> *repudiation*
> that I quoted above:
> 
>  "Repudiation -- The denial by a user of having participated 
> in part or all
>   of a communication."
> 
> and you construct the logical complement of "non" as:
> 
> Non-Repudiation -- Preventing the denial by a user of having 
> participated in
> part or all of a communication.
> 
> Further, authentication that is neither provable nor provides 
> for integrity is
> not authentication in the sense of strong authentication as used in
> X.509 digital signatures (Section 10.1).   Thus, when you say 
> that "provable
> data origin authentication with integrity" is an appropriate name for
> non-repudiation in X.509, I must disagree and cite X.509 
> itself.  That X.509
> definition quoted by Stefan in incoherent with all other 
> definitions of X.509.
> It was a bad pick.
> 
> Actually, elsewhere as shown above, X.509 textually *agrees* with the
> definition by Menezes et. al. and with the usual sense people 
> would attach
> to something that is the complement of repudiation, the 
> complement of denial.
> 
> On the other hand, "provable data origin authentication with 
> integrity" is
> NOT an attribute of non-repudiation in X.509 but is provided by strong
> authentication as given in Section "10.1 Overview", where two-way
> authentication provides assurances for "the integrity and
> originality  of the authentication token sent in the reply".
> 
> So, should we accept that NR definition quoted by Stefan and deny
> all the other passages of X.509, including those for 
> authentication, that
> contradict with it ... or should we mark that specific 
> passage as wrong
> and accept the rest of X.509?

Yes. The latest round of fiddling with X.509 did more harm
than good. Your analysis, and subtle definitional logic
is quite accurate, for the various cases, historically.

The original 1988 model of X.509 was nicely aligned with
Davies and Price, which uses terms authentication,
strong authentication, proof of origin, as you reinforce 
here, based (interestingly) on purely textual deductions.
(this says something for the specification skills
of the early-round authors of X.500/X.509)

BUT, interestingly: the one thing D&P did not do back in 1984 
was get a full handle on non-repudiation, even though they
refer to it: "the statement of a signature procedure is not
complete until the method of arbitrating a dispute is specified".
(this text clearly distinguishes earlier between a digital
signature, and  signatures which may have additional
arbitration properties. One can note also the use of
the concepts of legal effect, and discussion of 
the policy and legal requirements thereof, years before 
Baum et al. claimed to have originated the same
as the "PEM policy idea")

Indeed, the D&P notion of certificate mentioned is distinct
from that used in X.509 1988, and has an effect on the meaning
of NR. It could be argued by linguists that D&P intended CA-issued
"certificate" to be used in the notarization sense -
not as certificate is used today - that is, the issued cert attested 
to the current accuracy of an copy of the authentic public key, in 
the  context of a proof of origin determination for an current instance
of the service. And this extra step involving certs perhaps got 
renamed "non-repudiation",  somewhere along the line.  But 
use of this term and the underlying ideas get very murky from 
D&P onwards. You an argue I am being revisionist, here.

This is all a bit academic. But the literature does clearly
show that current X.509 concepts of NR and PKCS-only dig sigs 
are not historically supported. Symmetric dig sigs were contemplated,
not just those from public-key ciphers, and the very
term NR most probably derives from the work of Smit
on notarized (symmetric) keys used for proof of
origin, that is - authenticators intended for use
in dispute resolution before judges - ie NR. Regardless
of the origin of the term, definitional cliams used today are
not in line with this available historical record.

Written in 1984, Davies and Price "Security for Computer
Networks",  Wiley, is as good intro to data security
and the background to PKI as there is. Almost nothing has 
changed in 16 years apart from key lenghts and the ease
of generating PKI material on the fly; its just now we are doing 
what they were then discussing.  

> Cheers,
> Ed Gerck

Date: Thu, 18 Nov 1999 16:24:45 -0800
From: Ed Gerck <[email-masked]>
To: Stephen Kent <[email-masked]>
CC: [email-masked]
Subject: Re: non-ephemeral vs. non-repudiation, was Re: proposed keyusagetext

Stephen Kent wrote:

> Ed Gerck wrote:
> >
> >But they explictly do (most?) -- short-term authentication signing
> >pertains to the session, not to the message sent.  The difference is
> >between signing the protocol messages and signing what is conveyed
> >(tunneled) by the protocol, of course.  This is the difference I am
> >emphasizing, even though some protocol implementations may use the
> >same key for  both.  I surely can use different keys for both -- nowadays.
>
> Yes, the protocols in question sign data for session authentication,
> not data sent during the session.  We agree on that.  I objected to
> your comment that the keys used for such signing were ephemeral,
> which is untrue.

Steve:

The keys used for session signing could be ephemeral, and yet the
session may be NR.  OTOH, the keys used for message signing may
be non-ephemeral and yet the message may be non-NR (sorry for
the double negative ;-) -- ie, repudiable).

So, what I was pointing out is that equating "non-ephemeral" with
"non-repudiation" is similar to equating apples to speedboats -- they
are two different concepts. Namely, the time window of signature
usefulness and the context window of signature validity.

That is why "encoding" the NR attribute as a time window of signature
usefulness will not be sucessful, IMO.

Cheers,

Ed Gerck

Date: Thu, 18 Nov 1999 17:46:52 -0500
To: Ed Gerck <[email-masked]>
From: Stephen Kent <[email-masked]>
Subject: Re: non-ephemeral vs. non-repudiation, was Re: proposed key usagetext
Cc: [email-masked]

Ed,
>
>But they explictly do (most?) -- short-term authentication signing
>pertains to the session, not to the message sent.  The difference is
>between signing the protocol messages and signing what is conveyed
>(tunneled) by the protocol, of course.  This is the difference I am
>emphasizing, even though some protocol implementations may use the
>same key for  both.  I surely can use different keys for both -- nowadays.

Yes, the protocols in question sign data for session authentication, 
not data sent during the session.  We agree on that.  I objected to 
your comment that the keys used for such signing were ephemeral, 
which is untrue.

>  > and since there is not
>  > general agreement that this is a bad thing, let's not make statements
>  > of this sort a basis for further deliberation.
>
>There is a general agreement that a NR cert (whatever that beast
>might turn out to be) should not be used for non-NR purposes.
>This is what I am saying, no more.
>

Yes, we agree on that point as well.

steve

Date: Thu, 18 Nov 1999 14:26:25 -0800
From: Ed Gerck <[email-masked]>
To: Stephen Kent <[email-masked]>
CC: [email-masked]
Subject: Re: non-ephemeral vs. non-repudiation, was Re: proposed key usagetext

Stephen Kent wrote:

> Ed Gerck wrote:
>
> >Short-term authentication signing is an attribute of the signature
> >and is based on an ephemeral key valid during a session, while
> >long-term signature is an attribute both of the signature and of the
> >certificate and is based on a non-ephemeral public-key which may
> >be valid during many years (even if the private-key is destroyed
> >and especially so).
> >
> This might be nice, but it is not generally true.  Many (most?)
> protocols today that use signature for authentication do so using
> long term keys held in certs, not ephemeral signing keys, perhaps
> held in very short lived certs.  Since several standard protocols do
> operate in this fashion,e.g., TLS and IKE,

But they explictly do (most?) -- short-term authentication signing
pertains to the session, not to the message sent.  The difference is
between signing the protocol messages and signing what is conveyed
(tunneled) by the protocol, of course.  This is the difference I am
emphasizing, even though some protocol implementations may use the
same key for  both.  I surely can use different keys for both -- nowadays.

> and since there is not
> general agreement that this is a bad thing, let's not make statements
> of this sort a basis for further deliberation.

There is a general agreement that a NR cert (whatever that beast
might turn out to be) should not be used for non-NR purposes.
This is what I am saying, no more.

Cheers,

Ed Gerck

Date: Thu, 18 Nov 1999 14:12:25 -0800
From: Ed Gerck <[email-masked]>
To: "David P. Kemp" <[email-masked]>
CC: [email-masked]
Subject: Re: non-repudiation, was Re: proposed key usage text

"David P. Kemp" wrote:

> > Date: Thu, 18 Nov 1999 12:02:54 -0800
> > From: Ed Gerck <[email-masked]>
> >
> > Stefan Santesson wrote:
> >
> > > How can you say that the X.509 definition is wrong???
> >
> > Because it is redundant (the same as authentication as I commented)
> > and thus superfluous.
>
> Some people believe that there is a difference between "provable
> data origin authentication with integrity" and "entity authentication",
> and that nonRepudiation as used in X.509 is an appropriate name for the
> former.

David:

It is useful to list what X.509 actually says before further discussing about
"nonRepudiation as used in X.509".  These are all the occurrences that I
find when I look for the key text "repudiation" in X.509:

 "It is a matter for the security policy and responsibility of the CA to keep old
 certificates for a period of time if a non repudiation of data service is provided."

 "If a non-repudiation of data service is dependent on keys provided by the CA,
 the service should ensure that all relevant keys of the CA (revoked or expired)
 and the timestamped revocation lists are archived and certified by a current
 authority."

 "nonRepudiation:  for verifying digital signatures used in providing a
 nonrepudiation service which protects against the signing entity falsely
 denying some action (excluding certificate or CRL signing, as in f) or g)
 below);"

 "The date in this extension is not, by itself, sufficient for nonrepudiation
 purposes. For example, this date may be a date advised by the private key
 holder, and it is possible for such a person to fraudulently claim that a key
 was compromised some time in the past, in order to repudiate a
 validly-generated signature."

 "Repudiation -- The denial by a user of having participated in part or all
 of a communication."

and, the one quoted by Stefan:

 "Non-repudiation -- This service provides proof of the integrity and origin
 of data -- both in an unforgeable relationship -- which can be verifed by any
 third party at any time."

plus:

 "The data integrity mechanism supports the data integrity service. It also
 partially supports the non-repudiation service (that service also needs the
 digital signature mechanism for its requirements to be fully met)."

 "The digital signature mechanism supports the data integrity service and
 also supports the non-repudiation service."

which shows that X.509 itself  is in contradiction.  To X.509, nonrepudiation
does NOT provide proof of integrity, which needs the digital signature
mechanism.  This is made clear in  Table B.1 "Threats and protection", where
we can read that the non-repudiation service is depicted as protecting against
the threats  of replay and repudiation -- and that "data integrity" and "end
authentication" are different services, different from non-repudiation.

Thus, that is why I wrote the following in regard to the definition that Stefan
quoted from X.509:

 This definition is wrong, as well as the consequences derived from it. Compare
 with the technical definition of Menezes in  Handbook of Applied
 Cryptography (cf.):

 Non-repudiation: a service that prevents the denial of a previous act.

But, surprise! The above NR definition by Menezes can be also found in
*another* part of X.509, if you read the X.509 definition for *repudiation*
that I quoted above:

 "Repudiation -- The denial by a user of having participated in part or all
  of a communication."

and you construct the logical complement of "non" as:

Non-Repudiation -- Preventing the denial by a user of having participated in
part or all of a communication.

Further, authentication that is neither provable nor provides for integrity is
not authentication in the sense of strong authentication as used in
X.509 digital signatures (Section 10.1).   Thus, when you say that "provable
data origin authentication with integrity" is an appropriate name for
non-repudiation in X.509, I must disagree and cite X.509 itself.  That X.509
definition quoted by Stefan in incoherent with all other definitions of X.509.
It was a bad pick.

Actually, elsewhere as shown above, X.509 textually *agrees* with the
definition by Menezes et. al. and with the usual sense people would attach
to something that is the complement of repudiation, the complement of denial.

On the other hand, "provable data origin authentication with integrity" is
NOT an attribute of non-repudiation in X.509 but is provided by strong
authentication as given in Section "10.1 Overview", where two-way
authentication provides assurances for "the integrity and
originality  of the authentication token sent in the reply".

So, should we accept that NR definition quoted by Stefan and deny
all the other passages of X.509, including those for authentication, that
contradict with it ... or should we mark that specific passage as wrong
and accept the rest of X.509?

Cheers,

Ed Gerck

Date: Thu, 18 Nov 1999 15:59:22 -0500
To: Ed Gerck <[email-masked]>
From: Stephen Kent <[email-masked]>
Subject: Re: non-ephemeral vs. non-repudiation, was Re: proposed key usage text
Cc: [email-masked]

Ed,

>"David P. Kemp" wrote:
>
>  > > From: Stefan Santesson <[email-masked]>
>  > >
>  > > Some systems will in fact use this information to technically 
>separate keys
>  > > used for the challenge/response type of signing (DS bit) and 
>the electronic
>  > > signature on a message type of signing (NR-bit). So this IS a 
>very useful and
>  > > relevant distinction, even in absence of a policy.
>  > >
>  > > At 04:26 PM 11/18/99 +0000, Peter Gutmann wrote:
>  > > >
>  > > >Why not use NR vs digitalSignature to distinguish long-term signature vs
>  > > >short-term authentication signing?  Several standards already use it for
>  > > this, this usage at least is practical and meaningful.
>
>Short-term authentication signing is an attribute of the signature 
>and is based
>on an ephemeral key valid during a session, while long-term signature is an
>attribute both of the signature and of the certificate and is based on a
>non-ephemeral public-key which may be valid during many years (even if
>the private-key is destroyed and especially so).
>
This might be nice, but it is not generally true.  Many (most?) 
protocols today that use signature for authentication do so using 
long term keys held in certs, not ephemeral signing keys, perhaps 
held in very short lived certs.  Since several standard protocols do 
operate in this fashion,e.g., TLS and IKE, and since there is not 
general agreement that this is a bad thing, let's not make statements 
of this sort a basis for further deliberation.

Steve

Date: Thu, 18 Nov 1999 15:56:01 -0500 (EST)
From: "David P. Kemp" <[email-masked]>
Reply-To: "David P. Kemp" <[email-masked]>
Subject: Re: non-repudiation, was Re: proposed key usage text
To: [email-masked]
Content-MD5: w9BrEK2NZfEmSX0AOEfQbg==

> Date: Thu, 18 Nov 1999 12:02:54 -0800
> From: Ed Gerck <[email-masked]>
> 
> Stefan Santesson wrote:
> 
> > How can you say that the X.509 definition is wrong???
> 
> Because it is redundant (the same as authentication as I commented)
> and thus superfluous.

Some people believe that there is a difference between "provable
data origin authentication with integrity" and "entity authentication",
and that nonRepudiation as used in X.509 is an appropriate name for the
former.

Applications may require the keyEncipherment bit to be set before using
a key for key encipherment.  Applications may require the
nonRepudiation bit to be set before signing a chunk of non-ephemeral
data.  In neither case is it relevant how or why the keyUsage bit got
set in the first place, or what X.509 label is attached to the bit; the
end result is that given a cert, an app will perform some operations
with the key and will not perform others.  That is a concrete,
understandable definition of behavior.

Some people believe it's also a useful definition.

Reply-To: <[email-masked]>
From: "Jeffrey Hyman" <[email-masked]>
To: <[email-masked]>
Subject: usubscribe
Date: Thu, 18 Nov 1999 12:15:02 -0800
Importance: Normal

unsubscribe

Date: Thu, 18 Nov 1999 12:12:28 -0800
To: [email-masked], [email-masked]
From: Tony Bartoletti <[email-masked]>
Subject: Re: proposed key usage text

At 04:26 PM 11/18/1999, Peter Gutmann wrote:
>Tony Bartoletti <[email-masked]> writes:
>
>>I sometimes doubt that a CA-asserted "NR bit" can represent anything useful.  
>>But if I am proven wrong, it would be a shame to waste this bit on the fuzzy 
>>"Simon Says it OK to use this cert for X" when there is no clear sense of 
>>what X represents.
>
>Why not use NR vs digitalSignature to distinguish long-term signature vs 
>short-term authentication signing?  Several standards already use it for this,
>this usage at least is practical and meaningful.
>
>Peter.

At the extremes, this is practical and meaningful (distinguishing minor
authentication assurance from, say, binding contract signatures.)

The problem, if any, comes when I decide I must maintain a long-term,
unforgeable log of every authenticated access to a system.  Suppose I
allow authenticated login with NR=0, but submit the signed "logins",
along with certs, CRLs, etc to "NR, Inc" for permanent archive.

Will "NR, Inc" reject the submission since the certs have NR=0?

Should I require the users to obtain NR=1 certs for login purposes?
And would they want to use the same keys for signing contracts?

Perhaps this is grasping at straws.  Long-term vs Short-term (without
any additional implications of purpose) does, in fact, coincide almost
precisely with Tom Gindin's version.  It then becomes a matter for
applications to decide when a particular transaction requires formal
NR treatment, which would consequently require the "Long-Term Bit".

Still, my fundamental concern is a confusion about "who is in the
driver's seat" with respect to the setting, signing, vouching for
NR=1 certificates.  This would seem to be the CA, as they form and
"make authentic" the certificate itself.  And yet they are really
outside of the dialog itself.

Let me try to make this clearer (to myself at least:)

As a RP/application, I decide that certain transactions require
that the elements be given an NR treatment.  I must convey this
to the user community, even if only to let them know that their
"actions" will be (as it were) non-repudiable.  The users can
either agree or not.  Say they agree.  How can I know that they
have agreed?  By requiring them to obtain NR=1 certificates for
the keys they will use.

But I will not accept just any CA's certs that say NR=1.  Why?
If a given CA hands out NR=1 certs exactly as it would NR=0,
then when a dispute arises, the signer can still argue that
(1) they never read my "page" that said "this transaction is NR"
and (2) they didn't know they were using an NR-key.  Hence it
must be a CA that I trust (at least) to make the buyer (subscriber)
well aware of the implications in the use of NR=1 certified keys.

After all, so long as I have some "proof" that the signer "knew"
they were entering into a NR-transaction, I could care less if the
cert said NR=0 or NR=1, and neither should anyone else.  Its only
REAL purpose, it seems, is to engage the CA as yet-another-piece-
of-evidence that the subscriber understands the implications of
doing "the NR thing".

As a flag to my application, its only reasonable semantic would then
be "I can now act as if the signer knowns this is a NR transaction".

Of course, I would like to know more from the CA.  Especially,
did they take additional precautions that the subscriber was
really who they presented themselves to be?  But that would
really put them (the CA) on the hook, placing them directly
into the line-of-liability should things go wrong.

OK.  It didn't work.  I think I'm still confused, but I'm not sure.

___tony___

Tony Bartoletti                                             LL
IOWA Center                                              LL LL
Lawrence Livermore National Laboratory                LL LL LL
PO Box 808, L - 089                                   LL LL LL
Livermore, CA 94551-9900                              LL LL LLLLLLLL
phone: 925-422-3881   fax: 925-423-8081               LL LLLLLLLL
email: [email-masked]                                   LLLLLLLL

Date: Thu, 18 Nov 1999 12:02:54 -0800
From: Ed Gerck <[email-masked]>
To: Stefan Santesson <[email-masked]>
CC: [email-masked]
Subject: Re: non-repudiation, was Re: proposed key usage text

Stefan Santesson wrote:

> How can you say that the X.509 definition is wrong???

Because it is redundant (the same as authentication as I commented)
and thus superfluous. Because there is an accepted definition in the
technical cryptographic literature which is different, is simpler,
corresponds to the real-world usage of the term "non-repudiation"
as that which cannot be negated, is not redundant and thus cannot
be ignored --  namely, that definition by Menezes et. al.  in the HAC:

 Non-repudiation: a service that prevents the denial of a previous act.

> Since we are discussing the meaning of a X.509 defined bit for NR. Then of
> course we have to align with the X.509 definition of the term.
>
> That's common sense to me.

To align PKIX with the X.509 meaning is also fine to me, but in this
case there is NO meaning.  The "definition" of NR in X.509 is simply
a restatement of authentication properties -- there is no new meaning,
and no meaning that migh resemble non-repudiation practices in
business, banking, dictionaries.

Of course, I agree with Mark T. that common sense is that which
everyone always seems to have a lots of -- but in this case the sense
defined in X.509 does not seem to be common at all.

Cheers,

Ed Gerck

Date: Thu, 18 Nov 1999 20:37:09 +0100
To: Ed Gerck <[email-masked]>
From: Stefan Santesson <[email-masked]>
Subject: Re: non-repudiation, was Re: proposed key usage text
Cc: [email-masked]

How can you say that the X.509 definition is wrong???

Since we are discussing the meaning of a X.509 defined bit for NR. Then of
course we have to align with the X.509 definition of the term. 

That's common sense to me.

/Stefan

At 08:59 1999-11-18 -0800, Ed Gerck wrote:
>
>
>Stefan Santesson wrote:
>
>> In fact we know rather well, up to a certain level, what NR means.
>>
>> NR is defined in X.509 as:
>>
>> Non-repudiation:  This service provides proof of the integrity and origin of
>> data  both in an unforgeable relationship  which can be verified by any
third
>> party at any time.
>
>This definition is wrong, as well as the consequences derived from it. Compare
>with the technical definition of Menezes in  Handbook of Applied
>Cryptography (cf.):
>
> Non-repudiation: a service that prevents the denial of a previous act.
>
>and we may agree that the definition in X.509 is just a round-about way
>of defining *strong authentication* -- where authentication affirms the
>truth of an act (which can be verified by any third party at any time).
>Quite different logic, as non-repudiation denies the falsity of an act --
>and, thus, prevents the denial of the act.  Both are equal if and only if
>the proposition is boolean, which it almost never the case is in security
>(where propositions are not atomic, and are multivalued).
>
>So, confusing non-repudiation with "authentication", or
>"strong authentication", or "non-ephemeral authentication"
>and thus actually vacating the concept of non-repudiation
>will not go very far.  It leaves non-repudiation undefined
>though still needed.
>
>In other words, to rename or to forget a problem is not a
>solution to the problem ... at least, technically ;-)
>
>Cheers,
>
>Ed Gerck

From: Peter Williams <[email-masked]>
To: Russ Housley <[email-masked]>
Cc: "[email-masked]'" <[email-masked]>
Subject: RE: Forward-dated entries in a CRL
Date: Thu, 18 Nov 1999 11:04:40 -0800

> -----Original Message-----
> From: Russ Housley [mailto:[email-masked]]
> Sent: Thursday, November 18, 1999 6:05 AM
> To: Salz, Rich
> Cc: [email-masked]'
> Subject: Re: Forward-dated entries in a CRL
> 
> 
> Rich:
> 
> No.  RFC 2459 says:
> 
>     The invalidity date is a non-critical CRL entry extension that
>     provides the date on which it is known or suspected that 
> the private
>     key was compromised or that the certificate otherwise 
> became invalid.
> 
> Since the extension is non-critical, a certificate user can ignore 
> it.  Thus, any entry on the CRL is treated as revoked at the 
> time it is put 
> on the list.

Perhaps, answer the following question:

User signed transaction arrives at 13:00; it was timestamped at 11:00. 
Latest CRL was issued at 12:00, with 1 revocation notice, dated 10:00. User 
verifies authenticity at 14:00, after lunch, noting the latest CRL lists on
itself 
a revoked certificate - for a cert used during PKIX cert processing.

Is the document signature good?  Is the contract properly signed?

Would DoD recognise the document as signed, and effective, for 
example, today, or not?

> 
> Russ
> 
> 
> At 12:11 PM 11/16/99 -0500, Salz, Rich wrote:
> >Is it legal to put future date in the revocationDate
> >field of a revokedCertificates entry?
> 

Date: Thu, 18 Nov 1999 09:57:57 -0800
From: Ed Gerck <[email-masked]>
To: "David P. Kemp" <[email-masked]>
CC: [email-masked]
Subject: non-ephemeral vs. non-repudiation, was Re: proposed key usage text

"David P. Kemp" wrote:

> > From: Stefan Santesson <[email-masked]>
> >
> > Some systems will in fact use this information to technically separate keys
> > used for the challenge/response type of signing (DS bit) and the electronic
> > signature on a message type of signing (NR-bit). So this IS a very useful and
> > relevant distinction, even in absence of a policy.
> >
> > At 04:26 PM 11/18/99 +0000, Peter Gutmann wrote:
> > >
> > >Why not use NR vs digitalSignature to distinguish long-term signature vs
> > >short-term authentication signing?  Several standards already use it for
> > this, this usage at least is practical and meaningful.

Short-term authentication signing is an attribute of the signature and is based
on an ephemeral key valid during a session, while long-term signature is an
attribute both of the signature and of the certificate and is based on a
non-ephemeral public-key which may be valid during many years (even if
the private-key is destroyed and especially so).

Of course, one could have a long-term certificate used for short-term
signing, but the certificate lifetime should not be confused with the NR
bit in this case while the authentication would be still short-term as
defined in its signed attributes.

Also, PKIX standard is free to call "non-repudiation" what is
"non-ephemeral" but this seems to *add* to the confusion, no?
It would decrease interoperation with accepted usages of the term, in
the real-world of business for example.  Or, when one consults a
dictionary. Or, with technical cryptographic texts and textbooks.
It would be a private language.

> I agree with Stefan and Peter that we should turn back the clock to
> April 29, and use the bit to specify exclusively concrete usage of the
> key by applications.

I agree with this, but I don't need to travel back in time for it. Rather,
requiring "concrete usage of the key by applications" is what has
been the cornerstone of these discussions after April 29th, where the
lack of a real-world model for NR bit usage was apparent in the former
work.

> Any probative value of signed evidence would
> derive from the way applications apply the private key and how the
> private key has been handled, not on the state of the NR bit in a
> particular public key cert.

Agreed, as I don't subscribe to the notion that "intent" can
be present or be measurable by a bag of bytes.  Further,
a bank teller will not ask whether you "intended" to sign a
check that was paid and then kindly reverse the charge to the
bank if you say "No", but will verify whether the signature
cannot be distinguished from your signature in the archives --
in which case the teller will pay the check and will not reverse
it, even if you later on prove that you were in coma shock
that day.

So, "intent" has nothing to do with non-repudiation.  Nor,
whether it is ephemeral. An order to fire a bomb needs to
be non-repudiable and yet it is very ephemeral.

Cheers,

Ed Gerck

Date: Thu, 18 Nov 1999 08:59:44 -0800
From: Ed Gerck <[email-masked]>
To: Stefan Santesson <[email-masked]>
CC: [email-masked]
Subject: non-repudiation, was Re: proposed key usage text

Stefan Santesson wrote:

> In fact we know rather well, up to a certain level, what NR means.
>
> NR is defined in X.509 as:
>
> Non-repudiation:  This service provides proof of the integrity and origin of
> data  both in an unforgeable relationship  which can be verified by any third
> party at any time.

This definition is wrong, as well as the consequences derived from it. Compare
with the technical definition of Menezes in  Handbook of Applied
Cryptography (cf.):

 Non-repudiation: a service that prevents the denial of a previous act.

and we may agree that the definition in X.509 is just a round-about way
of defining *strong authentication* -- where authentication affirms the
truth of an act (which can be verified by any third party at any time).
Quite different logic, as non-repudiation denies the falsity of an act --
and, thus, prevents the denial of the act.  Both are equal if and only if
the proposition is boolean, which it almost never the case is in security
(where propositions are not atomic, and are multivalued).

So, confusing non-repudiation with "authentication", or
"strong authentication", or "non-ephemeral authentication"
and thus actually vacating the concept of non-repudiation
will not go very far.  It leaves non-repudiation undefined
though still needed.

In other words, to rename or to forget a problem is not a
solution to the problem ... at least, technically ;-)

Cheers,

Ed Gerck

Date: Thu, 18 Nov 1999 11:01:16 -0500
From: "Charles R. Merrill" <[email-masked]>
To: "Winchel 'Todd' Vincent, III" <[email-masked]>
CC: [email-masked], [email-masked], [email-masked], ABA ISC Mailing List <[email-masked]>
Subject: Re: Certificate Policy vs Certification Practice .. where are the  boundaries? ... what belongs where?

This is a multi-part message in MIME format.
--------------63220A28F6DA8646CE20844F
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

I agree pretty thoroughly with what Todd says.  The PAG (PKI Assessment
Guidelines) of the ABA Info Security Committee is attempting to address both the
CP/CPS distinction, and the need for a consistent PKI technical/legal vocabulary
- including the presentation of different views where there is not yet
consensus.

Chas Merrill, Co-Reporter of the PAG

[email-masked] wrote:

> The following is being forwarded to the pkix4 mailing list.
> Message originally sent by "Winchel 'Todd' Vincent, III" <[email-masked]>
> ---------------------------------------------------------------------------
>
> I apologize in advance for the cross posting.  I think this post is relevant
> both to the technical and legal community.  However, I'm not sure how many
> people are listening on the  PKIX Framework list (at IBM,
> [email-masked]) . . . (not the PKIX list, [email-masked]) . . .
> because the IBM list has been dead.   I think the proper place for this
> discussion (if any) is on the IBM list.
>
> <Juan Rodriguez-Torrent>
> > During the facts gathering effort the editorial committee received many
> > comments regarding the relationship between Certificate Policy and
> > Certification Practices. All these comments seem to point at the "need to
> > better define the difference between a CP and CPS".But what did strike me
> > the most was the passion that some people showed when this subject
> > surfaced. Several of these "passionate" critics are subscribers in this
> > list but have not mentioned once anything regarding this subject. Do I
> have
> > to believe that this is no longer an issue? or if it is still an issue why
> > not discuss it now?
> </Juan Rodriguez-Torrent>
>
> Juan, you are right.  However, I think the editorial committee has an
> obligation to pose questions to the community based on the comments it has
> received to date.  We haven't heard anything from the editorial committee
> other than posts to the list about what the new outline will look like.
>
> I wonder if I am one of those people who are considered "passionate" about
> this issue.  Although I have opinions about what the difference *should* be,
> I'm not sure that what I believe reflects what industry experts actually
> think it *is*.  As an "academic" I can ask a lot of questions, sit around
> and think, and study the documents (which I do), but I believe industry
> experts should weigh in on the issue and give specific examples of actual
> ways in which the documents are *being* used and the problems that arise
> that need to be solved.  It would be nice to have a requirements document
> for policy statements -- what is it that we're really trying to accomplish?
> That is the first step in deciding how to accomplish it.
>
> The questions I posed at the PKIX/ABA ISC meeting before RSA 1999
> (abbreviated version posted below) seemed to be well-received, but have not
> been discussed or answered by anyone openly (to my knowledge), including the
> editorial committee.   I certainly don't know of anything that has been
> published.  Unfortunately, there seems to be a desire to only slightly
> tinker with the Framework.   This is a shame.  The Framework is a great
> start, but it is only a start.  Indeed, lawyers, consultants, business
> people, and users would like to implement and/or benefit from the services
> PKI offers, but the underlying technology and the legal/policy issues
> surrounding PKI are not well-understood.  The "non-experts" don't get it and
> the "experts" don't seem to agree when asked about the details.  As a
> result, there are many who dislike PKI or are taking a wait-and-see
> approach.  This will change, of course.  The question is how quickly.  At
> RSA 1999, I recall a speaker saying something like, "last year, we said,
> 'this is the year of PKI' . . . maybe it wasn't, but this year is going to
> be . . . " . . . I wonder whether that will be said again at RSA 2000.  The
> point is, the sooner we answer some of these questions definitively, the
> closer we'll be to wider and more rational deployment of PKI.
>
> I would very much enjoy knowing the opinions of the editorial committee (and
> others) on the following questions.  Perhaps everyone agrees.  If so, we can
> write it, publish it, and everyone will be better off.  If everyone does not
> agree, then we should identify and resolve the issues.
>
> (Note: As most of you who know me are aware, I am a strong  advocate of
> machinable legal and policy statements using XML -- or, at least, whatever
> syntax makes people feel most comfortable.  This is a separate issue from
> the issues posed below.  However, I do believe that some of the legal/policy
> issues can be solved better using "smart" technology.  I am not, however,
> attempting to open this can of worms here . . . but reserve the right to do
> it later :-)
>
> I hypothesize that technologists, lawyers, policy makers and users might
> answer these questions very differently.  I might be wrong, I'm not  sure.
> That's why I ask.
>
> 1. What is the Relationship of, and Difference between, Certificate Policy
> and Certificate Practice Statement
>
>     a. Define the Difference Between Certificate Policy and Certificate
> Practice Statement
>
>     b. Define Expected Author of Each Document (legal, accounting/auditor/,
> technical)
>
>     c. Define Relationship Between Certificate Policy and Certificate
> Practice Statement (e.g., one-to-one, one-to-many, many-to-many)
>
>     d. Define Relationship among Certificate, CP,  CPS, and Object
> Identifier
>
>     i. Define Ancillary Documents (e.g., Subscriber Agreement, Relying Party
> Agreement, Interoperability Agreement)
>
>     e. Define Audience of Each Document (e.g., End Entities, Auditors,
> Governments, Customers)
>
>     f. Define Proprietary Nature of Each Document
>
> 2. Define Roles in a Public Key Infrastructure and the Expected Functions of
> Each Role
>
>     a. Policy Authority
>
>     b. Certification Authority (PKI Service Providers)
>         i. Issuer
>         ii. Certificate Manufacturer
>         iii. Repository
>         iv. Registration Authority (Registrar)
>
>     c. End Entities
>         i. Subscriber
>         ii. Relying Party
>
>     d. Define Other Roles (If Necessary)
>         i. Software Manufacturer
>         ii. Key Managers
>         iii. Government
>
> 3.  Is there a Need for a Common Set of PKI Technical and Legal Definitions?
> Should such a set of definitions be promulgated in the IETF?  Should there
> be something like an "ETerms" repository with standardize PKI terminology?
> Should this terminology be linked in a standardized way to PKI workflow . .
> . Ok, forgive me . . . I digressed . . .
>
> Winchel "Todd" Vincent III
> Attorney and Technical Researcher
> Project Director, E-CT-Filing Project
> Georgia State University
> J. Mack Robinson College of Business, eCommerce Institute
> and College of Law
> Phone: (404) 651-4297
> Fax: (404) 651-2092
> Email: [email-masked]
> Web: http://e-ct-file.gsu.edu/
> Legal XML: http://www.legalxml.org/

--------------63220A28F6DA8646CE20844F
Content-Type: text/x-vcard; charset=us-ascii;
 name="cmerrill.vcf"
Content-Transfer-Encoding: 7bit
Content-Description: Card for Charles R. Merrill
Content-Disposition: attachment;
 filename="cmerrill.vcf"

begin:vcard 
n:Merrill;Charles 
tel;fax:973.624.7070
tel;home:973.514.1779 - no voicemail
tel;work:973.622.4444 - has voicemail
x-mozilla-html:TRUE
org:http://www.mccarter.com;http://www.pkilaw.com  ===> last update 7/22/99  <=====
version:2.1
email;internet:[email-masked]
title:McCarter & English LLP, Newark, N.J. 
adr;quoted-printable:;;Four Gateway Center,=0D=0A100 Mulberry St;Newark;NJ;07101-0652;USA
x-mozilla-cpt:;-16976
fn:Charles R. Merrill
end:vcard

--------------63220A28F6DA8646CE20844F--

From: "Salz, Rich" <[email-masked]>
To: "'Sharon Boeyen'" <[email-masked]>, "[email-masked]'" <[email-masked]>
Subject: RE: Forward-dated entries in a CRL
Date: Thu, 18 Nov 1999 10:09:22 -0500

Thanks.
 
The question came up here during testing when someone  somewhere found or
generated a CRL with a post-dated entry.  As an implementor I'm glad that
such things are illegal; as a user, I concur with the Japanese delegation
that they can be useful.
    /r$

From: [email-masked]
To: [email-masked]
Date: Thu, 18 Nov 1999 09:30:37 -0500
Subject: RFC 2527 Revision: What's going on and how to subscribe

My apologies to Santosh Chokhani of CygnaCom Solutions for butchering his
name in my note last night. The first statement of the Background should
have read

Background:

The Internet Engineering Task Force (IETF) Request for Comments (RFC) 2527,
originally known as PKIX4 and also as "The Chokhani-Ford Framework", was
developed from ...

Juan Rodriguez-Torrent

Security Strategy and Business Development

Maildrop #042
150 Kettletown Rd.
Southbury,  CT  06488

Phone: 203 264-7806, Tie 549-9651
E-mail: [email-masked]

*
**
*** "The present never ages. Each moment is like a snowflake, unique,
unspoiled, unrepeatable and can be appreciated in its surprisingness." Gail
Sheeny
**
*

Date: Thu, 18 Nov 1999 09:20:04 -0500 (EST)
From: "David P. Kemp" <[email-masked]>
Reply-To: "David P. Kemp" <[email-masked]>
Subject: Re: proposed key usage text
To: [email-masked]
Content-MD5: t6JZub/puT+DcaikVyTGXg==

> From: Stefan Santesson <[email-masked]>
> 
> Some systems will in fact use this information to technically separate keys
> used for the challenge/response type of signing (DS bit) and the electronic
> signature on a message type of signing (NR-bit). So this IS a very useful and
> relevant distinction, even in absence of a policy.
> 
> At 04:26 PM 11/18/99 +0000, Peter Gutmann wrote:
> >
> >Why not use NR vs digitalSignature to distinguish long-term signature vs 
> >short-term authentication signing?  Several standards already use it for 
this,
> >this usage at least is practical and meaningful.

Which is where we started before Bob screwed things up seven months
ago :-) :

> Date: Fri, 30 Apr 1999 13:37:05 -0600
> From: "Bob Jueneman" <[email-masked]>
> 
> Recently, we have been having some discussion regarding 
> Nonrepudiation on the cert-talk list, and I have been taking the 
> position that the Nonrepudiation key usage bit should be reserved
> for those key pairs that are used exclusively to indicate the user's
> conscious and willing intent to be legally bound by what is being 
> signed.

I agree with Stefan and Peter that we should turn back the clock to
April 29, and use the bit to specify exclusively concrete usage of the
key by applications.  Any probative value of signed evidence would
derive from the way applications apply the private key and how the 
private key has been handled, not on the state of the NR bit in a
particular public key cert.

Date: Thu, 18 Nov 1999 09:04:34 -0500
To: "Salz, Rich" <[email-masked]>
From: Russ Housley <[email-masked]>
Subject: Re: Forward-dated entries in a CRL
Cc: "[email-masked]'" <[email-masked]>

Rich:

No.  RFC 2459 says:

    The invalidity date is a non-critical CRL entry extension that
    provides the date on which it is known or suspected that the private
    key was compromised or that the certificate otherwise became invalid.

Since the extension is non-critical, a certificate user can ignore 
it.  Thus, any entry on the CRL is treated as revoked at the time it is put 
on the list.

Russ

At 12:11 PM 11/16/99 -0500, Salz, Rich wrote:
>Is it legal to put future date in the revocationDate
>field of a revokedCertificates entry?

From: Sharon Boeyen <[email-masked]>
To: "'Salz, Rich'" <[email-masked]>, "[email-masked]'" <[email-masked]>
Subject: RE: Forward-dated entries in a CRL
Date: Thu, 18 Nov 1999 08:45:38 -0500

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01BF31CB.3305A1F4
Content-Type: text/plain;
	charset="iso-8859-1"

There was a ballot comment from Japan on this same issue at last month's
X.509 meeting. The resolution of that
comment at that meeting was that no, the current standard requires that any
certificate listed on a CRL be 
a certificate that HAS BEEN revoked. The delegation from Japan was going to
revist their requirement to determine
for sure whether they needed the ability to actually get revocation notices
into the hands of relying parties before
revocation occured (e.g. scheduled employee departures) or to have the CA
prepare in advance to issue a CRL when 
the revocations occur. Their example had to do a mass revocation of numerous
certificates at the same time.

If their requirement is for the former, then they may submit a new work
proposal on the topic. If you have requirements
for future dates, I'd be interested in hearing them to see how they relate
to the X.509 discussion of the Japanese 
requirements.

Sharon

-----Original Message-----
From: Salz, Rich [mailto:[email-masked]]
Sent: Tuesday, November 16, 1999 12:12 PM
To: [email-masked]'
Subject: Forward-dated entries in a CRL

Is it legal to put future date in the revocationDate
field of a revokedCertificates entry?

------_=_NextPart_001_01BF31CB.3305A1F4
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Diso-8859-1">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2448.0">
<TITLE>RE: Forward-dated entries in a CRL</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=3D2>There was a ballot comment from Japan on this same =
issue at last month's X.509 meeting. The resolution of that</FONT>
<BR><FONT SIZE=3D2>comment at that meeting was that no, the current =
standard requires that any certificate listed on a CRL be </FONT>
<BR><FONT SIZE=3D2>a certificate that HAS BEEN revoked. The delegation =
from Japan was going to revist their requirement to determine</FONT>
<BR><FONT SIZE=3D2>for sure whether they needed the ability to actually =
get revocation notices into the hands of relying parties before</FONT>
<BR><FONT SIZE=3D2>revocation occured (e.g. scheduled employee =
departures) or to have the CA prepare in advance to issue a CRL when =
</FONT>
<BR><FONT SIZE=3D2>the revocations occur. Their example had to do a =
mass revocation of numerous certificates at the same time.</FONT>
</P>

<P><FONT SIZE=3D2>If their requirement is for the former, then they may =
submit a new work proposal on the topic. If you have =
requirements</FONT>
<BR><FONT SIZE=3D2>for future dates, I'd be interested in hearing them =
to see how they relate to the X.509 discussion of the Japanese </FONT>
<BR><FONT SIZE=3D2>requirements.</FONT>
</P>

<P><FONT SIZE=3D2>Sharon</FONT>
</P>

<P><FONT SIZE=3D2>-----Original Message-----</FONT>
<BR><FONT SIZE=3D2>From: Salz, Rich [<A =
HREF=3D"mailto:[email-masked]">mailto:[email-masked]</A>]</FONT>
<BR><FONT SIZE=3D2>Sent: Tuesday, November 16, 1999 12:12 PM</FONT>
<BR><FONT SIZE=3D2>To: [email-masked]'</FONT>
<BR><FONT SIZE=3D2>Subject: Forward-dated entries in a CRL</FONT>
</P>
<BR>

<P><FONT SIZE=3D2>Is it legal to put future date in the =
revocationDate</FONT>
<BR><FONT SIZE=3D2>field of a revokedCertificates entry?</FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01BF31CB.3305A1F4--

Date: Thu, 18 Nov 1999 09:45:22 +0100
To: [email-masked]
From: Stefan Santesson <[email-masked]>
Subject: Re: proposed key usage text

In fact we know rather well, up to a certain level, what NR means.

NR is defined in X.509 as:

Non-repudiation:  This service provides proof of the integrity and origin of
data  both in an unforgeable relationship  which can be verified by any third
party at any time.

And that's all we know about it....

It does not say anything about:
- The quality of the proof
- The legal implications of the proof
- The ability to use the proof in the future (long term/short term)

All these additional interesting things must be provided by the certificate
policy, if provided at all. 

In this sense the NR bit is actually very similar to a policy-qualifier, so
that some parts in a policy may become active if the NR-bit is set.

But even without the additional things that the policy may add to this, the bit
have its basic defined meaning. To some applications that meaning is useless
but to some it may be very useful. But it is up to the relying party to decide
if this has any relevant meaning at all.

Finally, one of the problem with the proposed text is that it talks about
"falsely denying some action". Well this makes it very hard to distinguish NR
from authentication, because also pure authentication (challenge response) may
have this property.

X.509 (and the European ES-directive) on the other hand talks about "integrity
and origin of DATA", which is very different. In this sense the scope is
clearly limited to electronic signatures in order to proof origin and
authentication of a message. Not just any proof that I opened a door or logged
into a system.

So to make this easy, I would adopt the X.509 definition into RFC2459 with some
added notes about the dependency on a certificate policy for full understanding
of the implications of the bit.

Some systems will in fact use this information to technically separate keys
used for the challenge/response type of signing (DS bit) and the electronic
signature on a message type of signing (NR-bit). So this IS a very useful and
relevant distinction, even in absence of a policy.

/Stefan

At 04:26 PM 11/18/99 +0000, Peter Gutmann wrote:
>Tony Bartoletti <[email-masked]> writes:
>
>>I sometimes doubt that a CA-asserted "NR bit" can represent anything useful. 

>>But if I am proven wrong, it would be a shame to waste this bit on the fuzzy 
>>"Simon Says it OK to use this cert for X" when there is no clear sense of 
>>what X represents.
>>
>>I just wish I had a better notion of what a CA expects to be held to, if 
>>anything at all, for signing with NR=0/NR=1 at my request.
>>
>>Free Hints Accepted :)
>
>Why not use NR vs digitalSignature to distinguish long-term signature vs 
>short-term authentication signing?  Several standards already use it for this,
>this usage at least is practical and meaningful.
>
>Peter.

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

From: "Winchel 'Todd' Vincent, III" <[email-masked]>
To: <[email-masked]>, <[email-masked]>, <[email-masked]>, "ABA ISC Mailing List" <[email-masked]>
Subject: Re: Certificate Policy vs Certification Practice .. where are the boundaries? ... what belongs where?
Date: Thu, 18 Nov 1999 02:42:06 -0500

I apologize in advance for the cross posting.  I think this post is relevant
both to the technical and legal community.  However, I'm not sure how many
people are listening on the  PKIX Framework list (at IBM,
[email-masked]) . . . (not the PKIX list, [email-masked]) . . .
because the IBM list has been dead.   I think the proper place for this
discussion (if any) is on the IBM list.

<Juan Rodriguez-Torrent>
> During the facts gathering effort the editorial committee received many
> comments regarding the relationship between Certificate Policy and
> Certification Practices. All these comments seem to point at the "need to
> better define the difference between a CP and CPS".But what did strike me
> the most was the passion that some people showed when this subject
> surfaced. Several of these "passionate" critics are subscribers in this
> list but have not mentioned once anything regarding this subject. Do I
have
> to believe that this is no longer an issue? or if it is still an issue why
> not discuss it now?
</Juan Rodriguez-Torrent>

Juan, you are right.  However, I think the editorial committee has an
obligation to pose questions to the community based on the comments it has
received to date.  We haven't heard anything from the editorial committee
other than posts to the list about what the new outline will look like.

I wonder if I am one of those people who are considered "passionate" about
this issue.  Although I have opinions about what the difference *should* be,
I'm not sure that what I believe reflects what industry experts actually
think it *is*.  As an "academic" I can ask a lot of questions, sit around
and think, and study the documents (which I do), but I believe industry
experts should weigh in on the issue and give specific examples of actual
ways in which the documents are *being* used and the problems that arise
that need to be solved.  It would be nice to have a requirements document
for policy statements -- what is it that we're really trying to accomplish?
That is the first step in deciding how to accomplish it.

The questions I posed at the PKIX/ABA ISC meeting before RSA 1999
(abbreviated version posted below) seemed to be well-received, but have not
been discussed or answered by anyone openly (to my knowledge), including the
editorial committee.   I certainly don't know of anything that has been
published.  Unfortunately, there seems to be a desire to only slightly
tinker with the Framework.   This is a shame.  The Framework is a great
start, but it is only a start.  Indeed, lawyers, consultants, business
people, and users would like to implement and/or benefit from the services
PKI offers, but the underlying technology and the legal/policy issues
surrounding PKI are not well-understood.  The "non-experts" don't get it and
the "experts" don't seem to agree when asked about the details.  As a
result, there are many who dislike PKI or are taking a wait-and-see
approach.  This will change, of course.  The question is how quickly.  At
RSA 1999, I recall a speaker saying something like, "last year, we said,
'this is the year of PKI' . . . maybe it wasn't, but this year is going to
be . . . " . . . I wonder whether that will be said again at RSA 2000.  The
point is, the sooner we answer some of these questions definitively, the
closer we'll be to wider and more rational deployment of PKI.

I would very much enjoy knowing the opinions of the editorial committee (and
others) on the following questions.  Perhaps everyone agrees.  If so, we can
write it, publish it, and everyone will be better off.  If everyone does not
agree, then we should identify and resolve the issues.

(Note: As most of you who know me are aware, I am a strong  advocate of
machinable legal and policy statements using XML -- or, at least, whatever
syntax makes people feel most comfortable.  This is a separate issue from
the issues posed below.  However, I do believe that some of the legal/policy
issues can be solved better using "smart" technology.  I am not, however,
attempting to open this can of worms here . . . but reserve the right to do
it later :-)

I hypothesize that technologists, lawyers, policy makers and users might
answer these questions very differently.  I might be wrong, I'm not  sure.
That's why I ask.

1. What is the Relationship of, and Difference between, Certificate Policy
and Certificate Practice Statement

    a. Define the Difference Between Certificate Policy and Certificate
Practice Statement

    b. Define Expected Author of Each Document (legal, accounting/auditor/,
technical)

    c. Define Relationship Between Certificate Policy and Certificate
Practice Statement (e.g., one-to-one, one-to-many, many-to-many)

    d. Define Relationship among Certificate, CP,  CPS, and Object
Identifier

    i. Define Ancillary Documents (e.g., Subscriber Agreement, Relying Party
Agreement, Interoperability Agreement)

    e. Define Audience of Each Document (e.g., End Entities, Auditors,
Governments, Customers)

    f. Define Proprietary Nature of Each Document

2. Define Roles in a Public Key Infrastructure and the Expected Functions of
Each Role

    a. Policy Authority

    b. Certification Authority (PKI Service Providers)
        i. Issuer
        ii. Certificate Manufacturer
        iii. Repository
        iv. Registration Authority (Registrar)

    c. End Entities
        i. Subscriber
        ii. Relying Party

    d. Define Other Roles (If Necessary)
        i. Software Manufacturer
        ii. Key Managers
        iii. Government

3.  Is there a Need for a Common Set of PKI Technical and Legal Definitions?
Should such a set of definitions be promulgated in the IETF?  Should there
be something like an "ETerms" repository with standardize PKI terminology?
Should this terminology be linked in a standardized way to PKI workflow . .
. Ok, forgive me . . . I digressed . . .

Winchel "Todd" Vincent III
Attorney and Technical Researcher
Project Director, E-CT-Filing Project
Georgia State University
J. Mack Robinson College of Business, eCommerce Institute
and College of Law
Phone: (404) 651-4297
Fax: (404) 651-2092
Email: [email-masked]
Web: http://e-ct-file.gsu.edu/
Legal XML: http://www.legalxml.org/

From: [email-masked]
To: [email-masked]
Date: Thu, 18 Nov 1999 00:51:11 -0500
Subject: RFC 2527 Revision: What's going on and how to subscribe

Reminder: The RFC 2527 revision mail list only allows postings to
subscribed members. See how to subscribe below.

The list archives are at http://www.raleigh.ibm.com/maillists/pkix4/

Current postings to the list for commentary are section 5 (Outline) with
significant changes proposed in Section 2 (was General provisions now
proposed General, Legal and Business), Section 3 (Authentication and
Identification), Section 4  (Certificate Life Cycle Operational
Requirements), Section 5 (CA facility and management controls).

RFC 2527 (Certificate Policy and Certification Practices Framework)
Revision.

Background:

The Internet Engineering Task Force (IETF) Request for Comments (RFC) 2527,
originally known as PKIX4 and also as ?The Chaconi-Ford Framework?, was
developed from two different projects funded by the U.S. and Canadian
governments. The IETF PKIX group iterated the draft for about a year, then
was approved as an informal RFC. The final version is dated April 1998 and
the formal RFC number was granted in March 1999.

At some point, the original draft was used as a starting document by many
individuals and organizations developing Certificate Policies (CPs) and
Certification Practices Statements (CPSs) and began to be used in a number
of different forums. Feedback has indicated that the document in its
present state does not meet all the needs from the different communities it
is supposed to help. As a result of this feedback an effort to revise this
document coalesced. The broad acceptance and interest garnered by this work
from the business, legal, government, and technical communities motivated
widening the editorial group to include members of several interest groups.

Game Plan

To bring forward to the IETF open process a revised draft promptly, while
keeping the instructional value and the completeness of the original work
intact, the editorial group decided to obtain comments from the various
communities of interest. These comments are gathered in open meetings, and
a coherent draft will be released on or about December 1999. Other venues
to bring forth comments and requirements are joining the public mail list
?see how to join below- or sending a note to the chair of the editorial
group ([email-masked]).

Editorial Committee:
|--------------------------+--------------------------->
|                          |                           |
| Name                     | Organization              |
|                          |                           |
|--------------------------+--------------------------->
  >-----------------------------|
  |                             |
  | Email                       |
  |                             |
  >-----------------------------|
|--------------------------+--------------------------->
|                          |                           |
| Warwick Ford             | VeriSign                  |
|                          |                           |
|--------------------------+--------------------------->
  >-----------------------------|
  |                             |
  | [email-masked]          |
  |                             |
  >-----------------------------|
|--------------------------+--------------------------->
|                          |                           |
| Santosh Chokhani         | CygnaCom                  |
|                          |                           |
|--------------------------+--------------------------->
  >-----------------------------|
  |                             |
  | [email-masked]       |
  |                             |
  >-----------------------------|
|--------------------------+--------------------------->
|                          |                           |
| Charles Merrill          | McCarter & English        |
|                          |                           |
|--------------------------+--------------------------->
  >-----------------------------|
  |                             |
  | [email-masked]     |
  |                             |
  >-----------------------------|
|--------------------------+--------------------------->
|                          |                           |
| Michael Power            | Government of Canada      |
|                          |                           |
|--------------------------+--------------------------->
  >-----------------------------|
  |                             |
  | [email-masked] |
  |                             |
  |                             |
  >-----------------------------|
|--------------------------+--------------------------->
|                          |                           |
| Juan Rodiriguez-Torrent  | IBM                       |
|                          |                           |
|--------------------------+--------------------------->
  >-----------------------------|
  |                             |
  | [email-masked]          |
  |                             |
  >-----------------------------|
|--------------------------+--------------------------->
|                          |                           |
| Randy V. Sabett          | SPYRUS, Inc.              |
|                          |                           |
|--------------------------+--------------------------->
  >-----------------------------|
  |                             |
  | [email-masked]          |
  |                             |
  >-----------------------------|

To join the PKIX4 mailing list, send a request to [email-masked]
with ?subscribe pkix4? in the body of the message or to
[email-masked] with only the word ?subscribe? in the body of
the message. In either case DO NOT include the quotation marks on your
request.

Juan Rodriguez-Torrent

Security Strategy and Business Development

Maildrop #042
150 Kettletown Rd.
Southbury,  CT  06488

Phone: 203 264-7806, Tie 549-9651
E-mail: [email-masked]

*
**
*** "The present never ages. Each moment is like a snowflake, unique,
unspoiled, unrepeatable and can be appreciated in its surprisingness." Gail
Sheeny
**
*

From: [email-masked] (Peter Gutmann)
To: [email-masked]
Subject: Re: proposed key usage text
Sender: [email-masked]
Reply-To: [email-masked]
Date: Thu, 18 Nov 1999 16:26:38 (NZDT)

Tony Bartoletti <[email-masked]> writes:

>I sometimes doubt that a CA-asserted "NR bit" can represent anything useful.  
>But if I am proven wrong, it would be a shame to waste this bit on the fuzzy 
>"Simon Says it OK to use this cert for X" when there is no clear sense of 
>what X represents.
>
>I just wish I had a better notion of what a CA expects to be held to, if 
>anything at all, for signing with NR=0/NR=1 at my request.
>
>Free Hints Accepted :)

Why not use NR vs digitalSignature to distinguish long-term signature vs 
short-term authentication signing?  Several standards already use it for this,
this usage at least is practical and meaningful.

Peter.

Date: Wed, 17 Nov 1999 18:32:32 -0800
To: [email-masked], Tim Polk <[email-masked]>
From: Tony Bartoletti <[email-masked]>
Subject: Re: proposed key usage text
Cc: [email-masked]

Tom,

I think I really agree with your version, as being something that tends
toward "substance", especially given the standing alternative.

I sometimes doubt that a CA-asserted "NR bit" can represent anything
useful.  But if I am proven wrong, it would be a shame to waste this
bit on the fuzzy "Simon Says it OK to use this cert for X" when there
is no clear sense of what X represents.

I just wish I had a better notion of what a CA expects to be held to,
if anything at all, for signing with NR=0/NR=1 at my request.

Free Hints Accepted :)

___tony___

Tony Bartoletti                                             LL
IOWA Center                                              LL LL
Lawrence Livermore National Laboratory                LL LL LL
PO Box 808, L - 089                                   LL LL LL
Livermore, CA 94551-9900                              LL LL LLLLLLLL
phone: 925-422-3881   fax: 925-423-8081               LL LLLLLLLL
email: [email-masked]                                   LLLLLLLL

Date: Wed, 17 Nov 1999 17:22:17 -0800
To: [email-masked], Tim Polk <[email-masked]>
From: Tony Bartoletti <[email-masked]>
Subject: Re: proposed key usage text
Cc: [email-masked]

Tom,

Where I wrote:

>Your version seems to boil down to "a cert for this key was valid at time
>of signature", which seems like an odd assertion for a CA to make before
>any such signatures have been generated.
 
I was really overstating the problem.  It is OK for the CA to assert that
the USAGE IS INTENDED IN SUPPORT OF SERVICES that would provide assurance
that "a cert for this key was valid at time of signature".

I guess what really bothers me is the implication that, for any other usage
bit settings, such a service is not-to-be supported.  That, in essence, one
could not otherwise secure such a service, or the CA does not agree to
cooperate with such an endeavor.

Are not ALL key-usage bits an assertion by the CA that "If the key is used
in a manner that violates the key usage, then the CA is (possibly) freed
from some terms stated in its CP/CPS?"  And that this may be of some legal
consequence to an RP or NR-service?

If so, then the NR-bit question becomes "What elements of CA responsibility
become voided when NR=1 but the "signing entity" turns out to be someone
other than expected (in particular, an "owner" obtaining a certificate
through fraudulent credentials.)

___tony___

Tony Bartoletti                                             LL
IOWA Center                                              LL LL
Lawrence Livermore National Laboratory                LL LL LL
PO Box 808, L - 089                                   LL LL LL
Livermore, CA 94551-9900                              LL LL LLLLLLLL
phone: 925-422-3881   fax: 925-423-8081               LL LLLLLLLL
email: [email-masked]                                   LLLLLLLL

From: [email-masked]
To: Tony Bartoletti <[email-masked]>
cc: Tim Polk <[email-masked]>, [email-masked]
Date: Wed, 17 Nov 1999 20:00:33 -0500
Subject: Re: proposed key usage text

     In the message below, my points assume that the NR bit is to be set
even for services which meet no more stringent requirements than those of
"technical non-repudiation".

          Tom Gindin

Tony Bartoletti <[email-masked]> on 11/17/99 06:49:55 PM

To:   Tom Gindin/Watson/IBM@IBMUS, Tim Polk <[email-masked]>
cc:   [email-masked]
Subject:  Re: proposed key usage text

[Tim Polk provides, from 4.2.1.3 Key Usage]:

   The nonRepudiation bit is asserted when the subject public key is
   used to verify digital signatures used to provide a non-
   repudiation service which protects against the signing entity
   falsely denying some action, excluding certificate or CRL  signing.
   In the case of later conflict, a reliable third party may deter-
   mine the authenticity of the signed data.

Apologies to Tim Polk and Russ Housley, but this NR paragraph is easily
as wishy-washy as the original, if not more so.  Are we to suppose that
the NR bit could NOT be used to protect against a presumed signer
"honestly"
denying some action?  Are we to suppose that if NR=0, then a reliable third
party is somehow precluded from determining the authenticity?

Importantly, is the term "signing entity" intended to signify the
"ActiveSigner", the "SubscriberInFact" or the "SubscriberOfRecord"?
(See definitions below.)

It doth seem to me that the NR-bit asserts nothing of any substance.

One might as well add a "crimeFree" (CF) bit with usage specified as

  "The crimeFree bit is asserted when subject public key is used to verify
  digital signatures for transactions that are not a perpetration of fraud
  or other illegal activities.  In cases of dispute, get a good lawyer."

Of what value is this to anyone?  Would criminals seek to obtain certs
with CF=0 to avoid liability?  Would CF=1 lead you to increased trust
in the signature? For what possible reason?

[Tom writes]
>     Mine replaces the clause starting with "which protects" by : "which
>provides evidence that a given object was signed by the private key
>corresponding to a given certificate which was valid at the time of
>signature. "
>
>     The issue comes down to which assertions are necessary to constitute
a
>non-repudiation service.  In particular, is a service still a
>non-repudiation service if the principal evidence that the signer is also
>the subject of the signing certificate is derived from the CA?  Also, is a
>service still a non-repudiation service if there is not conclusive proof
>that the signer was adequately informed of the content of the document
>being signed?
>
>          Tom Gindin

Tom,

I agree that we need to ask about the utility of the assertion made wrt NR.
Your version seems to boil down to "a cert for this key was valid at time
of signature", which seems like an odd assertion for a CA to make before
any such signatures have been generated.

Since it is the CA which signs, and hence asserts the key usage binding,
one has to ask what assertion the CA can make that will make the given
certificate more "useful" to some (possibly independent) NR service.

[Tom Gindin]   The assertions I listed were assertions made by the NR
service.  The CA is merely stating that the NR service may use this
certificate.

This is a question in two parts:

  a.  What CA-asserted key usage restrictions are reasonably enforceable
      by the CA (hence worth more than simply "the CA wishes...").

  b.  What subset of (a) above are of value to any independent NR service.

In particular, is the NR service provider interested in binding a given
signature act to the: (my definitions)

1   SubscriberInFact:
        The person who presented themselves as "X" to the CA in order to
        receive a certificate that says "key owned by X"

2   SubscriberOfRecord:
        The person named as subscriber in the certificate.  That is, the
        "X" in "key owned by X"

3   ActiveSigner:
        The person actually effecting a signature to occur, in particular,
        independent of whether or not they are the "owner".

Consider that if person Y presents herself as X to a CA and obtains a
fraudulent certificate, but then has the key stolen and used by Z,
all three of the above may be different people.  In a certificate fraud,
we might expect (1) and (3) to be functionally the same, and yet it
seems that much of NR is focused upon binding the act to (2)!

[Tom Gindin]   When parties 1 and 3 are different, key compromise has
occurred and a revocation is usually expected.  When parties 1 and 2 are
different, a fraud has been perpetrated on the CA.  Also, the CA can't
enforce the distinction between keyEncipherment and dataEncipherment either
- the applications must.

Should NR=1 be the CA's vouching for a (functional) equivalence between
some two of the above?  But what CA is of use that does not intend to
assert that the "SubscriberInFact" is exactly the "SubscriberOfRecord"?

[Tom Gindin]   Actually, I think there is at least one CA which is not
asserting that.  The effective use of such a CA is that if you see two
transactions from the same key you can assume that they came from the same
party, and that the party wished to be described as having a specific name.
However, I think we can assume that any CA who issues an NR cert is
asserting that the SubscriberInFact is the SubscriberOfRecord, at least to
a rather high confidence level.

My suggested version was originally:

   "The nonRepudiation bit is asserted when the subject public key is
    used to verify digital signatures within a cryptographic service
    which intends to secure the cognizant role of the signing entity
    in the signature generation, excluding certificate or CRL signing."

But in retrospect, it suffers the same unspoken assumption that the
term "signing entity" is understood.

Additionally, the term "cognizant" may be too strong, inappropriate,
or unneeded.  Perhaps "active" or "liable" would better state the
case.

Which of these nine versions of assurance with regard to signature
generation really represent NR?

1.   "to secure the ACTIVE role of the ActiveSigner" (that's redundant!)
2.   "to secure the ACTIVE role of the SubscriberOfRecord"
3.   "to secure the ACTIVE role of the SubscriberInFact"
4.   "to secure the LIABILITY of the ActiveSigner"
5.   "to secure the LIABILITY of the SubscriberOfRecord"
6.   "to secure the LIABILITY of the SubscriberInFact"
7.   "to secure the COGNIZANT role of the ActiveSigner"
8.   "to secure the COGNIZANT role of the SubscriberOfRecord"
9.   "to secure the COGNIZANT role of the SubscriberInFact"

I imagine that a plaintiff is only interested in liability.  Who cares
if you were cognizant, or even took an active role, if you end up liable
anyway?  The plaintiff just wants to get paid.  The question is then
"Who is the 'YOU' that the plaintiff will go after?  Is it the YOU that
pushed the signature-button?  Or the YOU that is named in the certificate?
Or the YOU that obtained a fraudulent certificate in someone elses name?

[Tom Gindin]   Now I'll get legalistic.  No statute should ever create
liability for the SubscriberOfRecord if he or she is not the
SubscriberInFact - a much more likely rule would be to create liability for
the SubscriberInFact if he or she can be found, and if not the liability
rests on the CA or perhaps the RP.  In general, the only duty the
SubscriberOfRecord will have when he or she is not the SubscriberInFact is
to prove that.  Legislators or judges will set standards for the required
level of proof of that statement - PKIX won't.  Again, how much proof is
needed for a claim of key compromise and who bears responsibility if the
claim is late are legal matters.  Liability is not the only issue in NR,
because the purpose of some NR transactions is to produce clear evidence
that a given statement was made by the ActiveSigner at a known time - an
example would be a progress report submitted on a given date, which could
then be introduced by a contract supervisor in support of a claim that
progress had been misrepresented.  If there was a signed receipt, such a
report could be introduced by the person who wrote the report to prove that
he had advised the supervisor of the difficulties in a timely fashion.  As
for the distinction between ACTIVE and COGNIZANT roles, different
jurisdictions will require different standards for responsibility - all the
way from "no willful misrepresentation by RP" up to "multiple, clearly
worded and manually accepted dialog boxes".  We don't know which
jurisdiction will pick which standard, and for which agreements.

Perhaps in the end, the NR service should "secure the liability of
someone who can pay for the damages."

The more I think about it, the less it seems that a CA should be
centrally involved in NR assertions.

___tony___

Tony Bartoletti                                             LL
IOWA Center                                              LL LL
Lawrence Livermore National Laboratory                LL LL LL
PO Box 808, L - 089                                   LL LL LL
Livermore, CA 94551-9900                              LL LL LLLLLLLL
phone: 925-422-3881   fax: 925-423-8081               LL LLLLLLLL
email: [email-masked]                                   LLLLLLLL

Date: Wed, 17 Nov 1999 15:49:55 -0800
To: [email-masked], Tim Polk <[email-masked]>
From: Tony Bartoletti <[email-masked]>
Subject: Re: proposed key usage text
Cc: [email-masked]

[Tim Polk provides, from 4.2.1.3 Key Usage]:

   The nonRepudiation bit is asserted when the subject public key is
   used to verify digital signatures used to provide a non-
   repudiation service which protects against the signing entity
   falsely denying some action, excluding certificate or CRL  signing.
   In the case of later conflict, a reliable third party may deter-
   mine the authenticity of the signed data.

Apologies to Tim Polk and Russ Housley, but this NR paragraph is easily
as wishy-washy as the original, if not more so.  Are we to suppose that
the NR bit could NOT be used to protect against a presumed signer "honestly"
denying some action?  Are we to suppose that if NR=0, then a reliable third
party is somehow precluded from determining the authenticity? 

Importantly, is the term "signing entity" intended to signify the
"ActiveSigner", the "SubscriberInFact" or the "SubscriberOfRecord"?
(See definitions below.)

It doth seem to me that the NR-bit asserts nothing of any substance.

One might as well add a "crimeFree" (CF) bit with usage specified as

  "The crimeFree bit is asserted when subject public key is used to verify
  digital signatures for transactions that are not a perpetration of fraud
  or other illegal activities.  In cases of dispute, get a good lawyer."

Of what value is this to anyone?  Would criminals seek to obtain certs
with CF=0 to avoid liability?  Would CF=1 lead you to increased trust
in the signature? For what possible reason?

[Tom writes]
>     Mine replaces the clause starting with "which protects" by : "which
>provides evidence that a given object was signed by the private key
>corresponding to a given certificate which was valid at the time of
>signature. "
>
>     The issue comes down to which assertions are necessary to constitute a
>non-repudiation service.  In particular, is a service still a
>non-repudiation service if the principal evidence that the signer is also
>the subject of the signing certificate is derived from the CA?  Also, is a
>service still a non-repudiation service if there is not conclusive proof
>that the signer was adequately informed of the content of the document
>being signed?
>
>          Tom Gindin

Tom,

I agree that we need to ask about the utility of the assertion made wrt NR.
Your version seems to boil down to "a cert for this key was valid at time
of signature", which seems like an odd assertion for a CA to make before
any such signatures have been generated.
 
Since it is the CA which signs, and hence asserts the key usage binding,
one has to ask what assertion the CA can make that will make the given
certificate more "useful" to some (possibly independent) NR service.

This is a question in two parts:

  a.  What CA-asserted key usage restrictions are reasonably enforceable
      by the CA (hence worth more than simply "the CA wishes...").

  b.  What subset of (a) above are of value to any independent NR service.

In particular, is the NR service provider interested in binding a given
signature act to the: (my definitions)

1   SubscriberInFact:
        The person who presented themselves as "X" to the CA in order to
        receive a certificate that says "key owned by X"

2   SubscriberOfRecord:
        The person named as subscriber in the certificate.  That is, the
        "X" in "key owned by X"

3   ActiveSigner:
        The person actually effecting a signature to occur, in particular,
        independent of whether or not they are the "owner".

Consider that if person Y presents herself as X to a CA and obtains a
fraudulent certificate, but then has the key stolen and used by Z,
all three of the above may be different people.  In a certificate fraud,
we might expect (1) and (3) to be functionally the same, and yet it
seems that much of NR is focused upon binding the act to (2)!

Should NR=1 be the CA's vouching for a (functional) equivalence between
some two of the above?  But what CA is of use that does not intend to
assert that the "SubscriberInFact" is exactly the "SubscriberOfRecord"?

My suggested version was originally:

   "The nonRepudiation bit is asserted when the subject public key is
    used to verify digital signatures within a cryptographic service
    which intends to secure the cognizant role of the signing entity
    in the signature generation, excluding certificate or CRL signing."

But in retrospect, it suffers the same unspoken assumption that the
term "signing entity" is understood.

Additionally, the term "cognizant" may be too strong, inappropriate,
or unneeded.  Perhaps "active" or "liable" would better state the
case.

Which of these nine versions of assurance with regard to signature
generation really represent NR? 

1.   "to secure the ACTIVE role of the ActiveSigner" (that's redundant!)
2.   "to secure the ACTIVE role of the SubscriberOfRecord"
3.   "to secure the ACTIVE role of the SubscriberInFact"
4.   "to secure the LIABILITY of the ActiveSigner"
5.   "to secure the LIABILITY of the SubscriberOfRecord"
6.   "to secure the LIABILITY of the SubscriberInFact"
7.   "to secure the COGNIZANT role of the ActiveSigner"
8.   "to secure the COGNIZANT role of the SubscriberOfRecord"
9.   "to secure the COGNIZANT role of the SubscriberInFact"

I imagine that a plaintiff is only interested in liability.  Who cares
if you were cognizant, or even took an active role, if you end up liable
anyway?  The plaintiff just wants to get paid.  The question is then
"Who is the 'YOU' that the plaintiff will go after?  Is it the YOU that
pushed the signature-button?  Or the YOU that is named in the certificate?
Or the YOU that obtained a fraudulent certificate in someone elses name?

Perhaps in the end, the NR service should "secure the liability of
someone who can pay for the damages."

The more I think about it, the less it seems that a CA should be
centrally involved in NR assertions.

___tony___

Tony Bartoletti                                             LL
IOWA Center                                              LL LL
Lawrence Livermore National Laboratory                LL LL LL
PO Box 808, L - 089                                   LL LL LL
Livermore, CA 94551-9900                              LL LL LLLLLLLL
phone: 925-422-3881   fax: 925-423-8081               LL LLLLLLLL
email: [email-masked]                                   LLLLLLLL

From: [email-masked] (Peter Gutmann)
To: [email-masked], [email-masked]
Subject: Re: correction, was Re: proposed key usage text
Sender: [email-masked]
Reply-To: [email-masked]
Date: Thu, 18 Nov 1999 10:34:32 (NZDT)

>There are actually 9 bits, but the correct number of combinations is 256.
>Even in the current standard, the last two bits are mutually exclusive and
>dependent on keyAgreement so the combinations are (2**6 for the signature and
>encipherment bits * (keyAgreement off, keyAgreement without encipher/decipher,
>keyAgreement with encipher, keyAgreement with decipher)).  Given the profiles
>of keyUsage by key type in section 7.3, you could argue that the number of
>combinations is only 68 (4 for keyAgreement-type keys such as Diffie-Hellman,
>64 for RSA, with DSA's settings a subset of RSA's).  If further restrictions
>are made along this line, the number of legal combinations could turn out not
>to be very large.

It could be larger than you'd think, because DLP keys can be used in a wide
variety of ways - a DSA/X9.42 public key could be used for DSA, DH, and 
Elgamal, covering every combination of key bits (admittedly it's identified
by dhPublicNumber, but it's also used as an mqvPublicNumber and could just as 
easily be used as a dsaPublicNumber or elgamalPublicNumber).

Peter.

From: [email-masked]
To: Tim Polk <[email-masked]>
cc: [email-masked]
Date: Wed, 17 Nov 1999 16:20:25 -0500
Subject: Re: proposed key usage text

     Your proposed description of the NR bit goes: "The nonRepudiation bit
is asserted when the subject public key is used to verify digital
signatures used to provide a non-repudiation service which protects against
the signing entity falsely denying some action, excluding certificate or
CRL signing.  In the case of later conflict, a reliable third party may
determine the authenticity of the signed data."

     Mine replaces the clause starting with "which protects" by : "which
provides evidence that a given object was signed by the private key
corresponding to a given certificate which was valid at the time of
signature. "

     The issue comes down to which assertions are necessary to constitute a
non-repudiation service.  In particular, is a service still a
non-repudiation service if the principal evidence that the signer is also
the subject of the signing certificate is derived from the CA?  Also, is a
service still a non-repudiation service if there is not conclusive proof
that the signer was adequately informed of the content of the document
being signed?

          Tom Gindin

From: [email-masked]
To: Ed Gerck <[email-masked]>
cc: Aram Perez <[email-masked]>, [email-masked]
Date: Wed, 17 Nov 1999 16:15:04 -0500
Subject: Re: correction, was Re: proposed key usage text

     There are actually 9 bits, but the correct number of combinations is
256.  Even in the current standard, the last two bits are mutually
exclusive and dependent on keyAgreement so the combinations are (2**6 for
the signature and encipherment bits * (keyAgreement off, keyAgreement
without encipher/decipher, keyAgreement with encipher, keyAgreement with
decipher)).  Given the profiles of keyUsage by key type in section 7.3, you
could argue that the number of combinations is only 68 (4 for
keyAgreement-type keys such as Diffie-Hellman, 64 for RSA, with DSA's
settings a subset of RSA's).  If further restrictions are made along this
line, the number of legal combinations could turn out not to be very large.

          Tom Gindin

Date: Wed, 17 Nov 1999 12:32:07 -0800
From: Ed Gerck <[email-masked]>
To: Aram Perez <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: correction, was Re: proposed key usage text

Aram Perez wrote:

> Hi Ed,
>
> >> Then, we would need to consider all 64K combinations of  eight bits
> >> and provide rules for their usage or exclusion -- after all, we can't just
> >> stop at prohibiting (DS=1, NR=1) and would need to move on as
> >> Aram has tried to motivate (provoke?):
> >
> > Obvious slip, but just so that I don't overstate my case ;-)
> >
> > " we would need to consider all 256 combinations of  eight bits"
>
> Sorry, wrong again: there are NINE bits, numbered 0 - 8, so it would be 512
> combinations.
>
> ;-)
>
> Aram

Yes, because there is no need to consider bits 7 and 8 as mutually
exclusive even though they are respectively called decipherOnly and
encipherOnly.

And, we can add more bits with extendedKeyUsage. We may then even
end up with 64K combinations ;-)

Which just makes it harder to justify lisiting them all and enforcing
their meaning as code words ... even for 512 combinations.

Cheers,

Ed Gerck

Date: Wed, 17 Nov 1999 12:12:26 -0800
From: Ed Gerck <[email-masked]>
To: Aram Perez <[email-masked]>, [email-masked]
Subject: correction, was Re: proposed key usage text

Ed Gerck wrote:

> Then, we would need to consider all 64K combinations of  eight bits
> and provide rules for their usage or exclusion -- after all, we can't just
> stop at prohibiting (DS=1, NR=1) and would need to move on as
> Aram has tried to motivate (provoke?):

Obvious slip, but just so that I don't overstate my case ;-)

" we would need to consider all 256 combinations of  eight bits"

Cheers,

Ed Gerck

From: [email-masked] (Peter Gutmann)
To: [email-masked]
Subject: Should we make the cert Validity field optional?
Sender: [email-masked]
Reply-To: [email-masked]
Date: Thu, 18 Nov 1999 09:08:52 (NZDT)

>From email someone sent me:

>[...]
>Also many CA's will reissue the same certificate with an extended expiry
>date and in one instance we found a CA who issued a new cert with a start
>date just prior to the original certs expiry and a later expiry date. They
>later issued a third cert which had the same start date as the original cert
>and the expiry date of the new cert so for a short period of time the 3
>certificates were valid.   All 3 certs had the same key pair.
>[...]

Or maybe it should just be renamed to "RenewalFeeDueDate" to reflects its
actual usage :-).  Does anyone want to guess at the semantics for these certs?

Peter.

Date: Wed, 17 Nov 1999 11:22:40 -0800
From: Ed Gerck <[email-masked]>
To: Aram Perez <[email-masked]>
CC: [email-masked]
Subject: Re: proposed key usage text

Aram Perez wrote:

> > Tim Polk and Russ Housley
> >
> > ----Proposed text for 4.2.1.3 Key Usage
> ....
> >       The digitalSignature bit is asserted when the subject public key
> >       is used with a digital signature mechanism to support security
> >       services other than non-repudiation (bit 1),

RFC 2459, Section 4.2.1.3 states:

 "This profile does not restrict the combinations of bits that may
 be set in an instantiation of the keyUsage extension."

IMO, changing this (as you propose) would have two detrimental
effects: (i) impose an uniform and artificial constraint on all
applications; and (ii) change the focus from "bit usage" to
"word usage".

Then, we would need to consider all 64K combinations of  eight bits
and provide rules for their usage or exclusion -- after all, we can't just
stop at prohibiting (DS=1, NR=1) and would need to move on as
Aram has tried to motivate (provoke?):

> At a minimum, the profile should list the combination of bits which are not
> allowed. A few examples:
>
> 1) If keyCertSign is asserted, then the only other bit that can be asserted
> is the cRLSign bit.
> 2) If cRLSign is asserted, then the only other bit that can be asserted is
> the keyCertSign bit.
> 3) If keyEncipherment is asserted, then keyAgreement MUST NOT be asserted.

etc.

Cheers,

Ed Gerck

From: "Trevor Freeman (Exchange)" <[email-masked]>
To: "Pkix List (E-mail)" <[email-masked]>
Subject: RE: Associating symmetric algorithms with a public key
Date: Wed, 17 Nov 1999 10:51:56 -0800

I have seen no solutions to this issue for applications who are not LDAP
aware, and many may hold LDAP support as being a good idea, is not
mandatory. 
I accept that directory publication is more flexible, however there does
seem to be agreement that the current attribute in X.509 does not express
the necessary relationship.
If different applications all can use the same certificate, while having
different sets of symmetric algorithms, how is such a requirement to be met
in the LDAP case without introducing a management issue, and unnecessary
duplication?

From: "Trevor Freeman (Exchange)" <[email-masked]>
To: Bob Jueneman <[email-masked]>, [email-masked]
Subject: RE: Associating symmetric algorithms with a public key
Date: Wed, 17 Nov 1999 10:42:08 -0800

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01BF312B.73941002
Content-Type: text/plain

Bob,
This is not directly related to CMS, but it still begs the question of
distribution of information. I am also thinking of other application, not
just CMS. 

-----Original Message-----
From: Bob Jueneman [mailto:[email-masked]]
Sent: Tuesday, November 16, 1999 7:53 AM
To: Trevor Freeman (Exchange); [email-masked]
Subject: Re: Associating symmetric algorithms with a public key

Trevor,

S/MIME defines and SMIMECapabilites parameter which is normally
sent in-line along with the certificates, and they are now proposing to 
put it in the directory as well.

Are these applications independent of S/MIME?  Should this capability 
be added to CMS instead of being S/MIME specific?

To what extent, and why, are these symmetric keys tied to a particulat
public key?
Isn't this more likely to be a general client restriction?

I would understand, however, if you didn't want to use a 40-bit  RC2 key 
to respond to a triple-DES encrypted message using a 2048 bit RSA encryption

key, as Outlook Express currently does.

Bob

>>> "Trevor Freeman (Exchange)" <[email-masked]> 11/15/99
05:03PM >>>
There are a number of applications which need a hint as to the set of
symmetric algorithms which can be used with a public key from a certificate
for encrypting data with asynchronous applications. There is a directory
attribute defined in X.509 for defining supported algorithms which can list
a set of algorithms and parameters, but is not associated with any
particular key. Using this directory attribute in a certificate would seem
to solve the problem of binding a set of algorithms to a specific key.
Any objections for this to be added to son of 2459? (apart from giving Tim
yet more work - sorry Tim)
Trevor

------_=_NextPart_001_01BF312B.73941002
Content-Type: text/html
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Dus-ascii">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2650.12">
<TITLE>RE: Associating symmetric algorithms with a public key</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=3D2>Bob,</FONT>
<BR><FONT SIZE=3D2>This is not directly related to CMS, but it still =
begs the question of distribution of information. I am also thinking of =
other application, not just CMS. </FONT></P>

<P><FONT SIZE=3D2>-----Original Message-----</FONT>
<BR><FONT SIZE=3D2>From: Bob Jueneman [<A =
HREF=3D"mailto:[email-masked]">mailto:[email-masked]</A>]</F=
ONT>
<BR><FONT SIZE=3D2>Sent: Tuesday, November 16, 1999 7:53 AM</FONT>
<BR><FONT SIZE=3D2>To: Trevor Freeman (Exchange); =
[email-masked]</FONT>
<BR><FONT SIZE=3D2>Subject: Re: Associating symmetric algorithms with a =
public key</FONT>
</P>
<BR>

<P><FONT SIZE=3D2>Trevor,</FONT>
</P>

<P><FONT SIZE=3D2>S/MIME defines and SMIMECapabilites parameter which =
is normally</FONT>
<BR><FONT SIZE=3D2>sent in-line along with the certificates, and they =
are now proposing to </FONT>
<BR><FONT SIZE=3D2>put it in the directory as well.</FONT>
</P>

<P><FONT SIZE=3D2>Are these applications independent of S/MIME?&nbsp; =
Should this capability </FONT>
<BR><FONT SIZE=3D2>be added to CMS instead of being S/MIME =
specific?</FONT>
</P>

<P><FONT SIZE=3D2>To what extent, and why, are these symmetric keys =
tied to a particulat public key?</FONT>
<BR><FONT SIZE=3D2>Isn't this more likely to be a general client =
restriction?</FONT>
</P>

<P><FONT SIZE=3D2>I would understand, however, if you didn't want to =
use a 40-bit&nbsp; RC2 key </FONT>
<BR><FONT SIZE=3D2>to respond to a triple-DES encrypted message using a =
2048 bit RSA encryption </FONT>
<BR><FONT SIZE=3D2>key, as Outlook Express currently does.</FONT>
</P>

<P><FONT SIZE=3D2>Bob</FONT>
</P>

<P><FONT SIZE=3D2>&gt;&gt;&gt; &quot;Trevor Freeman (Exchange)&quot; =
&lt;[email-masked]&gt; 11/15/99 05:03PM =
&gt;&gt;&gt;</FONT>
<BR><FONT SIZE=3D2>There are a number of applications which need a hint =
as to the set of</FONT>
<BR><FONT SIZE=3D2>symmetric algorithms which can be used with a public =
key from a certificate</FONT>
<BR><FONT SIZE=3D2>for encrypting data with asynchronous applications. =
There is a directory</FONT>
<BR><FONT SIZE=3D2>attribute defined in X.509 for defining supported =
algorithms which can list</FONT>
<BR><FONT SIZE=3D2>a set of algorithms and parameters, but is not =
associated with any</FONT>
<BR><FONT SIZE=3D2>particular key. Using this directory attribute in a =
certificate would seem</FONT>
<BR><FONT SIZE=3D2>to solve the problem of binding a set of algorithms =
to a specific key.</FONT>
<BR><FONT SIZE=3D2>Any objections for this to be added to son of 2459? =
(apart from giving Tim</FONT>
<BR><FONT SIZE=3D2>yet more work - sorry Tim)</FONT>
<BR><FONT SIZE=3D2>Trevor</FONT>
</P>
<BR>

</BODY>
</HTML>
------_=_NextPart_001_01BF312B.73941002--

Date: Wed, 17 Nov 1999 10:32:22 -0800
Subject: Re: proposed key usage text
From: "Aram Perez" <[email-masked]>
To: [email-masked]

Hi Tim and Russ,

This is a good first step to clarifying the key usage bits. I do have some
comments below...

>
> Folks,
>
> In hopes of settling the key usage debate (insert laughter here) Russ
> Housley and I are proposing some minor additions in the key usage text.  We
> recognize that complete consensus regarding the nonRepudiation bit does not
> (and may never) exist.  However, this text represents a  compromise
> position that should make everyopne equally unhapppy.
>
> Please review this text and decide if you can *live with it*.
>
> Thanks,
>
> Tim Polk and Russ Housley
>
> ----Proposed text for 4.2.1.3 Key Usage
>
>
> 4.2.1.3  Key Usage
>
>    The key usage extension defines the purpose (e.g., encipherment,  sig-
>    nature, certificate signing) of the key contained in the  certificate.
>    The usage restriction might be employed when a key that could be  used
>    for more than one operation is to be restricted.  For example, when
>    an RSA key should be used only for signing, the digitalSignature
>    and/or nonRepudiation bits would be asserted. Likewise, when an RSA
>    key should be used only for key management, the keyEncipherment bit
>    would be asserted. When used, this extension SHOULD be marked criti-
>    cal.
>
>       id-ce-keyUsage OBJECT IDENTIFIER ::=  { id-ce 15 }
>
>       KeyUsage ::= BIT STRING {
>            digitalSignature        (0),
>            nonRepudiation          (1),
>            keyEncipherment         (2),
>            dataEncipherment        (3),
>            keyAgreement            (4),
>            keyCertSign             (5),
>            cRLSign                 (6),
>            encipherOnly            (7),
>            decipherOnly            (8) }
>
>
>    Bits in the KeyUsage type are used as follows:
>
>       The digitalSignature bit is asserted when the subject public key
>       is used with a digital signature mechanism to support security
>       services other than non-repudiation (bit 1), certificate signing
>       (bit 5), or revocation information signing (bit 6). Digital  signa-
>       ture mechanisms are often used for entity authentication and data
>       origin authentication with integrity.
>
>       The nonRepudiation bit is asserted when the subject public key is
>       used to verify digital signatures used to provide a non-
>       repudiation service which protects against the signing entity
>       falsely denying some action, excluding certificate or CRL  signing.
>       In the case of later conflict, a reliable third party may deter-
>       mine the authenticity of the signed data.
>
>       Further distinctions between the digitalSignature and nonRepudia-
>       tion bits may be provided in specific certificate policies.

What is happens when both the digitalSignature and nonRepudiation bits are
set? Does one of them take precendence?

>
>       The keyEncipherment bit is asserted when the subject public key  is
>       used for key transport.  For example, when an RSA key is to be
>       used for key management, then this bit shall asserted.
>
>       The dataEncipherment bit is asserted when the subject public key
>       is used for enciphering user data, other than cryptographic keys.
>
>       The keyAgreement bit is asserted when the subject public key is
>       used for key agreement.  For example, when a Diffie-Hellman key  is
>       to be used for key management, then this bit shall asserted.
>
>       The keyCertSign bit is asserted when the subject public key is
>       used for verifying a signature on certificates.  This bit may  only
>       be asserted in CA certificates.  If the keyCertSign bit is
>       asserted, then the cA bit in the basic constraints extension (see
>       4.2.1.10) MUST also be asserted. If the keyCertSign bit is not
>       asserted, then the cA bit in the basic constraints extension MUST
>       NOT be asserted.

Does section 4.2.1.10 state that "If the cA bit is asserted, then the
keyCertSign bit in the key usage extension (see 4.2.1.3) MUST also be
asserted. If the cA bit is not asserted, then the keyCertSign bit in the key
usage extension MUST NOT be asserted."?

If there is such a tight relation, why do you need both indicators? What
should happen if one bit is asserted and not the other.

>
>       The cRLSign bit is asserted when the subject public key is used
>       for verifying a signature on revocation information (e.g., a  CRL).

Shouldn't this bit have a similar relation to the basic constraint extension
as the keyCertSign bit?

>
>       The meaning of the encipherOnly bit is undefined in the absence  of
>       the keyAgreement bit.  When the encipherOnly bit is asserted and
>       the keyAgreement bit is also set, the subject public key may be
>       used only for enciphering data while performing key agreement.
>
>       The meaning of the decipherOnly bit is undefined in the absence  of
>       the keyAgreement bit.  When the decipherOnly bit is asserted and
>       the keyAgreement bit is also set, the subject public key may be
>       used only for deciphering data while performing key agreement.
>
>    This profile does not restrict the combinations of bits that may be
>    set in an instantiation of the keyUsage extension.  However,
>    appropriate values for keyUsage extensions for particular algorithms
>    are specified in section 7.3.

I think this is a mistake and causes confusion. In an extreme example, since
there is no restrictions, I could have a certificate that has all the bits
set. This means that I can do the following with my asymmetric key pair:

1) sign for entity authentication and data origin authentication with
integrity,
2) sign with a non-repudiation service,
3) encrypt keys for transport using RSA like algorithms,
4) encrypt data,
5) exchange keys using D-H like algorithms,
6) sign certificates,
7) sign CRLs,
8) encrypt data using D-H like algorithms, and
9) decrypt data using D-H like algorithms.

At a minimum, the profile should list the combination of bits which are not
allowed. A few examples:

1) If keyCertSign is asserted, then the only other bit that can be asserted
is the cRLSign bit.
2) If cRLSign is asserted, then the only other bit that can be asserted is
the keyCertSign bit.
3) If keyEncipherment is asserted, then keyAgreement MUST NOT be asserted.

Regards,
Aram Perez

From: Peter Williams <[email-masked]>
To: Paul Koning <[email-masked]>
Cc: [email-masked]
Subject: RE: Associating symmetric algorithms with a public key
Date: Wed, 17 Nov 1999 10:25:32 -0800

This is my last, hopefully useful, contribution on the topic:

The discussion seemed to be begging the question: how
can a certificate-borne control signal be used
to limit the application of a given public key to
mechanisms/protocols which are built
from a combination of more basic cryptographic primitive
operations. Alternatively, how can an authority control that
one algorithm is used only in combination with
other prescribed algorithms, for a given public key.

We know that such a quite-proper (keyUsage) signal exists to 
limit the usage of public keys to particular public-key using 
security mechanisms.

Why should not a similar control signal exist to limit
the use of a public key for combination mechanisms each
faciliated by distinct, named algorithms?

Just as the constraint (a) exists mainly to engender a world 
of  strong and weak key management for signature vs encryption 
keys, so the control (b) would exist to allow CAs to prevent
you the user using RSA except with weak symmetric algorithms,
say, or require that AES is used only in combination with DSS, etc.

I dont thing raw math properties come into this: it seems to be
about the desire and flexibility to assert control over the 
combination of algorithms  - presumably to engender assurance, 
or enable the imposition of national or cultural policies
for combined crypto-use. PKIX authors were complicit in 
the imposition of (a) on the Internet, why not (b)?

Remember, PKI is no longer an authentication framework. Its
primarily a framework for imposing centralized control, so
as to effect policy-based crypto management, and enable
authorities to assert their power to limit what users
can do with interoperable cryptography - once such
easy interoperability is faciliated by the use of PKI. 

Controlling the "appropriate/legitimate" combination of multiple 
algorithms could be seen as an important, missing element of 
infrastructure assurance.

> -----Original Message-----
> From: Paul Koning [mailto:[email-masked]]
> Sent: Wednesday, November 17, 1999 9:49 AM
> To: [email-masked]
> Cc: [email-masked]
> Subject: RE: Associating symmetric algorithms with a public key
> 
> 
> >>>>> "Peter" == Peter Williams <[email-masked]> writes:
> 
>  >> -----Original Message----- From: Paul Koning
> 
>  >>  I agree with that.  I also don't go along with the underlying
>  >> notion of an association between a public key and a set of
>  >> symmetric algorithms.  There is no such association,
>  >> cryptographically speaking.
> 
>  Peter> This is a fun topic.
> 
>  Peter> (a) There is a natural association between a public key and a
>  Peter> security mechanism such that dual/triple/multi cert regimes
>  Peter> are required per se in the PKI, apparently.
> 
>  Peter> (b) There is no natural association between a public and those
>  Peter> security mechanisms that require both public and symmetric
>  Peter> algorithm support, from the claim.
> 
> That's not what I said.
> 
>  Peter> What is an example of (b)?
> 
>  Peter> PEM had a security mechanism, which required that the output
>  Peter> of a private-key operation be ciphered in the DEK of the
>  Peter> session to ensure that only the intended recipient was
>  Peter> authorized to rely on the signature and/or learn the signature
>  Peter> ciphertext/plaintext pair.
> 
> Fine.  But that's not what I was talking about.  You're talking about
> the details of a particular key estabilishment protocol.  Clearly,
> there you want to establish a binding between the possession of a
> asymmetric system private key, and a newly established symmetric
> session key.  What you described is one way to do that.  (IKE is an
> example of a different protocol, one that doesn't do it in that way.)
> 
> What I meant: there is no cryptographic property of public keys that
> associates them with symmetric ciphers.  The bits, or the 
> mathematical 
> definition, of an RSA key are entirely independent of any symmetric
> cipher.  Indeed, if symmetric ciphers didn't exist at all, the public
> key and certificates that talk about it would remain meaningful.
> 
> How far should PKIX go in adding application specific things to certs?
> I find certs to be too big already, and would rather not see them
> fatten even more.
> 
> 	paul
> 

From: Santosh Chokhani <[email-masked]>
To: "'David P. Kemp'" <[email-masked]>, [email-masked]
Subject: RE: Associating symmetric algorithms with a public key
Date: Wed, 17 Nov 1999 13:19:55 -0500

Would n't the application protocol be the appropriate place to carry this
information.  For example, SIGNED MACRO carry the Algorithm OID.  Couldn't
application protocol carry the symmetric algorithm OID.  This also gives the
flexibility that the public key certificate can be used for key transfer (or
agreement) with a variety of symmetric algorithms.

-----Original Message-----
From: David P. Kemp [mailto:[email-masked]]
Sent: Wednesday, November 17, 1999 9:14 AM
To: [email-masked]
Subject: RE: Associating symmetric algorithms with a public key

I recognize: 1) that specific implementations may have different supported
combinations of public and symmetric keys, 2) that there does not
appear to be a suitable directory attribute currently defined for expressing
public-symmetric capabilities, and 3) that putting a list of symmetric
algorithms in a PK cert would express the desired result.

However, I agree with Steve and Paul that this is a configuration option
which does not belong in a cert.

The supported algorithm combinations could change as soon as the user
changes to a different version of the application, changes to a different
crypto module, or even clicks on some check boxes.  As soon as the
user takes one of these actions, he would have to communicate the change
to his correspondents.  The easiest way is to push a notification, or to
post an update to a directory attribute.  The hardest way is to get a
new cert, because the new cert would still have to be pushed or posted.

The IETF way of ensuring interoperability is to designate a
mandatory-to-implement algorithm suite.  The sender can guarantee
that the receiver can decode the message by using that suite, without
needing any new capability negotiation mechanism.  To express additional
capabilities, you may need to just define a new directory attribute if
existing S/MIME or other attributes cannot do the trick.  I'm curious
why S/MIME hasn't needed to solve this problem yet, so that an attribute
defined there could be used to support other asynchronous protocols.

Dave Kemp

> From: "Trevor Freeman (Exchange)" <[email-masked]>
> To: "'Stephen Kent'" <[email-masked]>
> Cc: "Pkix List (E-mail)" <[email-masked]>
> Subject: RE: Associating symmetric algorithms with a public key
> Date: Tue, 16 Nov 1999 17:19:46 -0800
> 
> Hi Steve,
> 
> I am sympathetic to being careful as to what is in a certificate. 
> The main reason for saying they are a hint is that in the final analysis,
> this kind of thing can never be more than a hint with asynchronous
> protocols, so it really is a reality check. I am equally hesitant to yet
> again build a dependency on the directory, and I am equally unconvinced
that
> it makes sense in this case to duplicate this information. This defined
> mechanism also give a clean package  of self contained data - wherever the
> certificate goes, so does the information regarding the associated
symmetric
> algorithms. RFC2459 supports the use of directory attributes, this is a
> directory attribute so all we are doing in reality is clarifying and
> highlighting a potential application of this specific attribute. Adding it
> to the certificate also simplifies the semantics because key usage and
> policy are now inherited from the certificate so are not needed in the
> extension.
> 
> Trevor

Date: Wed, 17 Nov 1999 12:49:24 -0500
From: Paul Koning <[email-masked]>
To: [email-masked]
Cc: [email-masked]
Subject: RE: Associating symmetric algorithms with a public key

>>>>> "Peter" == Peter Williams <[email-masked]> writes:

 >> -----Original Message----- From: Paul Koning

 >>  I agree with that.  I also don't go along with the underlying
 >> notion of an association between a public key and a set of
 >> symmetric algorithms.  There is no such association,
 >> cryptographically speaking.

 Peter> This is a fun topic.

 Peter> (a) There is a natural association between a public key and a
 Peter> security mechanism such that dual/triple/multi cert regimes
 Peter> are required per se in the PKI, apparently.

 Peter> (b) There is no natural association between a public and those
 Peter> security mechanisms that require both public and symmetric
 Peter> algorithm support, from the claim.

That's not what I said.

 Peter> What is an example of (b)?

 Peter> PEM had a security mechanism, which required that the output
 Peter> of a private-key operation be ciphered in the DEK of the
 Peter> session to ensure that only the intended recipient was
 Peter> authorized to rely on the signature and/or learn the signature
 Peter> ciphertext/plaintext pair.

Fine.  But that's not what I was talking about.  You're talking about
the details of a particular key estabilishment protocol.  Clearly,
there you want to establish a binding between the possession of a
asymmetric system private key, and a newly established symmetric
session key.  What you described is one way to do that.  (IKE is an
example of a different protocol, one that doesn't do it in that way.)

What I meant: there is no cryptographic property of public keys that
associates them with symmetric ciphers.  The bits, or the mathematical 
definition, of an RSA key are entirely independent of any symmetric
cipher.  Indeed, if symmetric ciphers didn't exist at all, the public
key and certificates that talk about it would remain meaningful.

How far should PKIX go in adding application specific things to certs?
I find certs to be too big already, and would rather not see them
fatten even more.

	paul

From: Peter Williams <[email-masked]>
To: Paul Koning <[email-masked]>
Cc: [email-masked]
Subject: RE: Associating symmetric algorithms with a public key
Date: Wed, 17 Nov 1999 09:26:34 -0800

> -----Original Message-----
> From: Paul Koning [mailto:[email-masked]]
> Sent: Wednesday, November 17, 1999 6:42 AM
> To: [email-masked]
> Cc: [email-masked]; [email-masked]
> Subject: RE: Associating symmetric algorithms with a public key
> 
> 
> >>>>> "Stephen" == Stephen Kent <[email-masked]> writes:
> 
>  Stephen> Trevor, I hate to see extra attributes added to certs....
>  Stephen> ....  However, I'd rather see the LDAP &
>  Stephen> X.500 folks provide better data structures for this in the
>  Stephen> directory, rather than adding a field that has only
>  Stephen> heuristic value to a cert.  If these are only hints, not
>  Stephen> proscriptive, then we don't seem to be making a string
>  Stephen> security statement about them anyway.
> 
> I agree with that.  I also don't go along with the underlying notion
> of an association between a public key and a set of symmetric
> algorithms.  There is no such association, cryptographically speaking.

This is a fun topic.

(a) There is a natural association between a public key and a security
mechanism such that dual/triple/multi cert regimes are required per se in 
the PKI, apparently.

(b) There is no natural association between a public and those security
mechanisms that require both public and symmetric algorithm support, from
the claim.

What is an example of (b)?

PEM had a security mechanism, which required that the output of
a private-key operation be ciphered in the DEK of the session to
ensure that only the intended recipient was authorized to rely on 
the signature and/or learn the signature ciphertext/plaintext pair.

(There was nothing artificial about the design of this security
mechanism; straight forward crypto-countermeasures engineering...)

> 
> It's conceivable that there exists an artificial association, in some
> applications, or some users, or some environments.  If so, does it
> make sense to burden certificates with this sort of
> application-specific baggage?  I don't think so.

if the word certificate include PMI certs (which in PKIX it
does) then there is no reason why the PMI cert cannot hold
such a directoryattribute which is used as an authenticated
control signal to control the multi-algorithm mechanism. That is 
what the PMI is for, after all, including using CRLs/OCSP etc to 
withdraw the privilege.

If the PMI cert can do this legitimately, nominally so can the 
id cert, given it now contains such enourmous amounts of other 
usage/purpose control signals now. 

Microsoft could invent a new IETF extension syntax, if there
is pro forma objection to the nice reusable one from ISO.  This 
would break the association with directory management, but enable
the (1 mechanism : multiple facility) control to be 
expressed via id/pmi certs.

> 	paul

Date: Wed, 17 Nov 1999 11:50:51 -0500
To: [email-masked]
From: Tim Polk <[email-masked]>
Subject: proposed key usage text

<bigger>

Folks,

In hopes of settling the key usage debate (insert laughter here) Russ
Housley and I are proposing some minor additions in the key usage text. 
We recognize that complete consensus regarding the nonRepudiation bit
does not (and may never) exist.  However, this text represents a 
compromise position that should make everyopne equally unhapppy.

Please review this text and decide if you can *live with it*.

Thanks,

Tim Polk and Russ Housley 

----Proposed text for 4.2.1.3 Key Usage

4.2.1.3  Key Usage

   The key usage extension defines the purpose (e.g., encipherment, 
sig-

   nature, certificate signing) of the key contained in the 
certificate.

   The usage restriction might be employed when a key that could be 
used

   for more than one operation is to be restricted.  For example, when

   an RSA key should be used only for signing, the digitalSignature

   and/or nonRepudiation bits would be asserted. Likewise, when an RSA

   key should be used only for key management, the keyEncipherment bit

   would be asserted. When used, this extension SHOULD be marked criti-

   cal.

      id-ce-keyUsage OBJECT IDENTIFIER ::=  { id-ce 15 }

      KeyUsage ::= BIT STRING {

           digitalSignature        (0),

           nonRepudiation          (1),

           keyEncipherment         (2),

           dataEncipherment        (3),

           keyAgreement            (4),

           keyCertSign             (5),

           cRLSign                 (6),

           encipherOnly            (7),

           decipherOnly            (8) }

   Bits in the KeyUsage type are used as follows:

      The digitalSignature bit is asserted when the subject public key

      is used with a digital signature mechanism to support security

      services other than non-repudiation (bit 1), certificate signing

      (bit 5), or revocation information signing (bit 6). Digital 
signa-

      ture mechanisms are often used for entity authentication and data

      origin authentication with integrity.

      The nonRepudiation bit is asserted when the subject public key is

      used to verify digital signatures used to provide a non-

      repudiation service which protects against the signing entity

      falsely denying some action, excluding certificate or CRL 
signing.

      In the case of later conflict, a reliable third party may deter-

      mine the authenticity of the signed data.

      Further distinctions between the digitalSignature and nonRepudia-

      tion bits may be provided in specific certificate policies.

      The keyEncipherment bit is asserted when the subject public key 
is

      used for key transport.  For example, when an RSA key is to be

      used for key management, then this bit shall asserted.

      The dataEncipherment bit is asserted when the subject public key

      is used for enciphering user data, other than cryptographic keys.

      The keyAgreement bit is asserted when the subject public key is

      used for key agreement.  For example, when a Diffie-Hellman key 
is

      to be used for key management, then this bit shall asserted.

      The keyCertSign bit is asserted when the subject public key is

      used for verifying a signature on certificates.  This bit may 
only

      be asserted in CA certificates.  If the keyCertSign bit is

      asserted, then the cA bit in the basic constraints extension (see

      4.2.1.10) MUST also be asserted. If the keyCertSign bit is not

      asserted, then the cA bit in the basic constraints extension MUST

      NOT be asserted.

      The cRLSign bit is asserted when the subject public key is used

      for verifying a signature on revocation information (e.g., a 
CRL).

      The meaning of the encipherOnly bit is undefined in the absence 
of

      the keyAgreement bit.  When the encipherOnly bit is asserted and

      the keyAgreement bit is also set, the subject public key may be

      used only for enciphering data while performing key agreement.

      The meaning of the decipherOnly bit is undefined in the absence 
of

      the keyAgreement bit.  When the decipherOnly bit is asserted and

      the keyAgreement bit is also set, the subject public key may be

      used only for deciphering data while performing key agreement.

   This profile does not restrict the combinations of bits that may be

   set in an instantiation of the keyUsage extension.  However,

   appropriate values for keyUsage extensions for particular algorithms

   are specified in section 7.3.

</bigger>

Date: Wed, 17 Nov 1999 10:54:20 -0500
To: "Trevor Freeman (Exchange)" <[email-masked]>
From: Stephen Kent <[email-masked]>
Subject: RE: Associating symmetric algorithms with a public key
Cc: "Pkix List (E-mail)" <[email-masked]>

Trevor,

Yes, 2459 does carry over the 509 facility for inclusion of directory 
attributes, but we recommend against its use.  So, if one wants to 
take advantage of that facility, it is "legal," but it also is 
clearly discouraged.  For the reasons I cited in my message, and 
seconded by others, I don't think we should encourage use of this 
facility and thus I don't believe that we ought to make any comments 
about this specific case relative to our current characterization of 
this certificate attribute.

Steve

Date: Tue, 16 Nov 1999 08:52:31 -0700
From: "Bob Jueneman" <[email-masked]>
To: <[email-masked]>, <[email-masked]>
Subject: Re: Associating symmetric algorithms with a public key

This is a MIME message. If you are reading this text, you may want to 
consider changing to a mail reader or gateway that understands how to 
properly handle MIME multipart messages.

--=_471E40EE.EA8BCDBD
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

Trevor,

S/MIME defines and SMIMECapabilites parameter which is normally
sent in-line along with the certificates, and they are now proposing to=20
put it in the directory as well.

Are these applications independent of S/MIME?  Should this capability=20
be added to CMS instead of being S/MIME specific?

To what extent, and why, are these symmetric keys tied to a particulat =
public key?
Isn't this more likely to be a general client restriction?

I would understand, however, if you didn't want to use a 40-bit  RC2 =
key=20
to respond to a triple-DES encrypted message using a 2048 bit RSA =
encryption=20
key, as Outlook Express currently does.

Bob

>>> "Trevor Freeman (Exchange)" <[email-masked]> 11/15/99 =
05:03PM >>>
There are a number of applications which need a hint as to the set of
symmetric algorithms which can be used with a public key from a certificate=

for encrypting data with asynchronous applications. There is a directory
attribute defined in X.509 for defining supported algorithms which can =
list
a set of algorithms and parameters, but is not associated with any
particular key. Using this directory attribute in a certificate would seem
to solve the problem of binding a set of algorithms to a specific key.
Any objections for this to be added to son of 2459? (apart from giving Tim
yet more work - sorry Tim)
Trevor

--=_471E40EE.EA8BCDBD
Content-Type: text/x-vcard
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="Bob Jueneman.vcf"

--=_471E40EE.EA8BCDBD--

To: [email-masked]
Subject: Re: Associating symmetric algorithms with a public key 
Date: Wed, 17 Nov 1999 14:59:23 +0000
From: Andrew Farrell <[email-masked]>

In message <[email-masked]>you 
write:

>There are a number of applications which need a hint as to the set of
>symmetric algorithms which can be used with a public key from a certificate
>for encrypting data with asynchronous applications. 

True, but it's also true that there may be a number of applications used
by the certificate holder, each of which has a different set of
symmetric algorithms that it supports. This attribute may be of use in
attribute certificates, but using it in a certificate ties a bit of
data (what symmetric algorithms you currently support) to a generally
orthogonal piece of data (that this is your asymmetric public key) with
a different duration.

Andrew.

Date: Wed, 17 Nov 1999 09:41:47 -0500
From: Paul Koning <[email-masked]>
To: [email-masked]
Cc: [email-masked], [email-masked]
Subject: RE: Associating symmetric algorithms with a public key

>>>>> "Stephen" == Stephen Kent <[email-masked]> writes:

 Stephen> Trevor, I hate to see extra attributes added to certs....
 Stephen> ....  However, I'd rather see the LDAP &
 Stephen> X.500 folks provide better data structures for this in the
 Stephen> directory, rather than adding a field that has only
 Stephen> heuristic value to a cert.  If these are only hints, not
 Stephen> proscriptive, then we don't seem to be making a string
 Stephen> security statement about them anyway.

I agree with that.  I also don't go along with the underlying notion
of an association between a public key and a set of symmetric
algorithms.  There is no such association, cryptographically speaking.

It's conceivable that there exists an artificial association, in some
applications, or some users, or some environments.  If so, does it
make sense to burden certificates with this sort of
application-specific baggage?  I don't think so.

	paul

From: "Salz, Rich" <[email-masked]>
To: "[email-masked]'" <[email-masked]>
Subject: Forward-dated entries in a CRL
Date: Tue, 16 Nov 1999 12:11:49 -0500

Is it legal to put future date in the revocationDate
field of a revokedCertificates entry?

Date: Wed, 17 Nov 1999 09:14:16 -0500 (EST)
From: "David P. Kemp" <[email-masked]>
Reply-To: "David P. Kemp" <[email-masked]>
Subject: RE: Associating symmetric algorithms with a public key
To: [email-masked]
Content-MD5: +5bwVP/McXNb8ROMXWDiMg==

I recognize: 1) that specific implementations may have different supported
combinations of public and symmetric keys, 2) that there does not
appear to be a suitable directory attribute currently defined for expressing
public-symmetric capabilities, and 3) that putting a list of symmetric
algorithms in a PK cert would express the desired result.

However, I agree with Steve and Paul that this is a configuration option
which does not belong in a cert.

The supported algorithm combinations could change as soon as the user
changes to a different version of the application, changes to a different
crypto module, or even clicks on some check boxes.  As soon as the
user takes one of these actions, he would have to communicate the change
to his correspondents.  The easiest way is to push a notification, or to
post an update to a directory attribute.  The hardest way is to get a
new cert, because the new cert would still have to be pushed or posted.

The IETF way of ensuring interoperability is to designate a
mandatory-to-implement algorithm suite.  The sender can guarantee
that the receiver can decode the message by using that suite, without
needing any new capability negotiation mechanism.  To express additional
capabilities, you may need to just define a new directory attribute if
existing S/MIME or other attributes cannot do the trick.  I'm curious
why S/MIME hasn't needed to solve this problem yet, so that an attribute
defined there could be used to support other asynchronous protocols.

Dave Kemp

> From: "Trevor Freeman (Exchange)" <[email-masked]>
> To: "'Stephen Kent'" <[email-masked]>
> Cc: "Pkix List (E-mail)" <[email-masked]>
> Subject: RE: Associating symmetric algorithms with a public key
> Date: Tue, 16 Nov 1999 17:19:46 -0800
> 
> Hi Steve,
> 
> I am sympathetic to being careful as to what is in a certificate. 
> The main reason for saying they are a hint is that in the final analysis,
> this kind of thing can never be more than a hint with asynchronous
> protocols, so it really is a reality check. I am equally hesitant to yet
> again build a dependency on the directory, and I am equally unconvinced that
> it makes sense in this case to duplicate this information. This defined
> mechanism also give a clean package  of self contained data - wherever the
> certificate goes, so does the information regarding the associated symmetric
> algorithms. RFC2459 supports the use of directory attributes, this is a
> directory attribute so all we are doing in reality is clarifying and
> highlighting a potential application of this specific attribute. Adding it
> to the certificate also simplifies the semantics because key usage and
> policy are now inherited from the certificate so are not needed in the
> extension.
> 
> Trevor

To: IETF-Announce: ;
Cc: [email-masked]
From: [email-masked]
Reply-to: [email-masked]
Subject: I-D ACTION:draft-ietf-pkix-generalname-00.txt
Date: Wed, 17 Nov 1999 06:59:23 -0500
Sender: [email-masked]

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Public-Key Infrastructure (X.509) Working Group of the IETF.

	Title		: A String Representation of General Name
	Author(s)	: A. Kapoor, R. Tschalar
	Filename	: draft-ietf-pkix-generalname-00.txt
	Pages		: 5
	Date		: 16-Nov-99
	
The PKIX working group has created the GeneralName [RFC2459] to support
more name types than just the distinguished name specified by OSI.
GeneralName is encoded in ASN.1.  When a GeneralName is communicated
not using a ASN.1 encoded protocol (e.g., in a configuration file), there is a need to have a string representation of GeneralName.  This document specifies a string format for representing names, which is designed to give a clean representation of commonly used names, whilst being able to represent any GeneralName.  This specification also recognizes that GeneralName needs to be communicated to humans, in which case the encoding has to be user friendly for display purposes, for e.g. on a business card or in an email message.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-pkix-generalname-00.txt

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-pkix-generalname-00.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[email-masked].
In the body type:
	"FILE /internet-drafts/draft-ietf-pkix-generalname-00.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body;
	access-type="mail-server";
	server="[email-masked]"

Content-Type: text/plain
Content-ID:	<[email-masked]>

ENCODING mime
FILE /internet-drafts/draft-ietf-pkix-generalname-00.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-pkix-generalname-00.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:	<[email-masked]>

--OtherAccess--

--NextPart--

Date: Wed, 17 Nov 1999 09:21:51 +0100
To: "Manger, James" <[email-masked]>, [email-masked]
From: Stefan Santesson <[email-masked]>
Subject: RE: PKIX: Use of dnQualifier must be settled

James,

I may not like it, but I can't close my eyes to the fact that what you are
saying here makes sense to me.

Is there any one out there who knows for sure that what James says in fact
is WRONG?

/Stefan

At 11:31 AM 11/17/99 +1100, Manger, James wrote:
>1. In the X.500 model, for any particular object there is precisely one
>object entry [X.501, 7.3] in the Directory Information Base (DIB).
>2. The intention of X.500 is to have a single DIB, composed of many systems
>and serving many applications [X.500, 6].
>3. The DIB is organized as a tree - the Directory Information Tree (DIT) -
>that is partitioned into distinct naming contexts held by different DSAs
>[X.501, 17.3].
>4. Each entry within the DIB is administered by one, and only one, DSA
>[X.501, 17.3].
>
>The model stumbles when more than one group wants to manage information for
>a single object.  For instance, two competing phone companies want to
>publish (in X.500 directories) a business phone book, a legal firm wants to
>run a DSA that lists the directors & secretary of companies and a
>stockbroker wants to publish stock prices via X.500.  All 4 groups want to
>manage their own DSAs, but  they all want entries for the same objects (e.g.
>companies).
>
>X.500 does not support "distributed entries", where different groups manage
>different information about the one entry.  [X.500 allows an entry to be
>replicated amongst many DSAs, but these are copies of one master entry.]
>The DN Qualifier attribute was introduced as a partial solution to this
>problem.  Different DSAs could have independent entries for the same object
>without violating X.500 by adding a per-DSA DN Qualifier value to the
>entries.  This gives the entries from different DSAs different DNs so they
>are different entries in the DIB.
>
>[I understand a more complete solution to this problem is currently being
>developed by an X.500 working group.  It introduces "domain identifiers"
>(DIT ids) that are used in conjunction with a DNs, but are not part of the
>DNs.  This mechanism may obviate the need for DN Qualifier, but this would
>in no way be justification for redefining DN Qualifier.]
>
>Hopefully this gives a context for DN Qualifier.  Hopefully it also shows
>that it was designed for a very different problem than holding
>employee/customer/org/unique ids and, consequently, is not appropriate for
>the latter.
>
>=> Define new attributes to hold (printable) ids for
>customers/employees/orgs that are unambiguous in a given context (e.g.
>organization, jurisdiction).
>
>
>In Russ Housley's example c=XX o=Acme grows so it adds a 2nd DSA for c=XX
>o=Acme ou=Sales.  No DN needs to change, even if it has a DN Qualifier
>value.  Both Acme DSAs can use the same DN Qualifier value because they
>don't need to disambiguate each others entries (if they did it wasn't just
>"reallocating the DIT among DSAs").  The DN Qualifier value disambiguates
>any entries in the Acme DSAs from other **independant** DSAs.
>
>
>
>> 	----------
>> 	From: 	Russ Housley[SMTP:[email-masked]]
>> 
>> 	Interpretation 1 cannot be correct.  The DIT can be reallocated
>> among DSAs, and this would result in name changes.  For example: assume
>> that c=XX, O=Acme was handled by one DSA, but the organization grew so
>> that a second DSA was added.  The new partition might be so that all of
>> c=XX, o=Acme, ou=Sales was moved to the new DSA.  I would hope that this
>> adjustment would nt cause any names to change.
>> 
>> 
>

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

From: "Trevor Freeman (Exchange)" <[email-masked]>
To: "'Stephen Kent'" <[email-masked]>
Cc: "Pkix List (E-mail)" <[email-masked]>
Subject: RE: Associating symmetric algorithms with a public key
Date: Tue, 16 Nov 1999 17:19:46 -0800

Hi Steve,

I am sympathetic to being careful as to what is in a certificate. 
The main reason for saying they are a hint is that in the final analysis,
this kind of thing can never be more than a hint with asynchronous
protocols, so it really is a reality check. I am equally hesitant to yet
again build a dependency on the directory, and I am equally unconvinced that
it makes sense in this case to duplicate this information. This defined
mechanism also give a clean package  of self contained data - wherever the
certificate goes, so does the information regarding the associated symmetric
algorithms. RFC2459 supports the use of directory attributes, this is a
directory attribute so all we are doing in reality is clarifying and
highlighting a potential application of this specific attribute. Adding it
to the certificate also simplifies the semantics because key usage and
policy are now inherited from the certificate so are not needed in the
extension.

Trevor

-----Original Message-----
From: Stephen Kent [mailto:[email-masked]]
Sent: Tuesday, November 16, 1999 4:14 PM
To: Trevor Freeman (Exchange)
Cc: Pkix List (E-mail)
Subject: RE: Associating symmetric algorithms with a public key

Trevor,

I hate to see extra attributes added to certs. I appreciate the 
desire to give hints to a user re what symmetric algorithms that user 
might employ when communicating with a target user, identified by the 
certificate in question.  However, I'd rather see the LDAP & X.500 
folks provide better data structures for this in the directory, 
rather than adding a field that has only heuristic value to a cert. 
If these are only hints, not proscriptive, then we don't seem to be 
making a string security statement about them anyway.

Even if we agree that Steve's Rule of Revocation is closer to linear 
or log than quadratic, the principle still applies ...

Steve

From: "Manger, James" <[email-masked]>
To: [email-masked]
Cc: "Kesterson, Hoyt" <[email-masked]>
Subject: RE: PKIX: Use of dnQualifier must be settled
Date: Wed, 17 Nov 1999 11:31:37 +1100

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_000_01BF3093.4778CA8C
Content-Type: text/plain

1. In the X.500 model, for any particular object there is precisely one
object entry [X.501, 7.3] in the Directory Information Base (DIB).
2. The intention of X.500 is to have a single DIB, composed of many systems
and serving many applications [X.500, 6].
3. The DIB is organized as a tree - the Directory Information Tree (DIT) -
that is partitioned into distinct naming contexts held by different DSAs
[X.501, 17.3].
4. Each entry within the DIB is administered by one, and only one, DSA
[X.501, 17.3].

The model stumbles when more than one group wants to manage information for
a single object.  For instance, two competing phone companies want to
publish (in X.500 directories) a business phone book, a legal firm wants to
run a DSA that lists the directors & secretary of companies and a
stockbroker wants to publish stock prices via X.500.  All 4 groups want to
manage their own DSAs, but  they all want entries for the same objects (e.g.
companies).

X.500 does not support "distributed entries", where different groups manage
different information about the one entry.  [X.500 allows an entry to be
replicated amongst many DSAs, but these are copies of one master entry.]
The DN Qualifier attribute was introduced as a partial solution to this
problem.  Different DSAs could have independent entries for the same object
without violating X.500 by adding a per-DSA DN Qualifier value to the
entries.  This gives the entries from different DSAs different DNs so they
are different entries in the DIB.

[I understand a more complete solution to this problem is currently being
developed by an X.500 working group.  It introduces "domain identifiers"
(DIT ids) that are used in conjunction with a DNs, but are not part of the
DNs.  This mechanism may obviate the need for DN Qualifier, but this would
in no way be justification for redefining DN Qualifier.]

Hopefully this gives a context for DN Qualifier.  Hopefully it also shows
that it was designed for a very different problem than holding
employee/customer/org/unique ids and, consequently, is not appropriate for
the latter.

=> Define new attributes to hold (printable) ids for
customers/employees/orgs that are unambiguous in a given context (e.g.
organization, jurisdiction).

In Russ Housley's example c=XX o=Acme grows so it adds a 2nd DSA for c=XX
o=Acme ou=Sales.  No DN needs to change, even if it has a DN Qualifier
value.  Both Acme DSAs can use the same DN Qualifier value because they
don't need to disambiguate each others entries (if they did it wasn't just
"reallocating the DIT among DSAs").  The DN Qualifier value disambiguates
any entries in the Acme DSAs from other **independant** DSAs.

> 	----------
> 	From: 	Russ Housley[SMTP:[email-masked]]
> 
> 	Interpretation 1 cannot be correct.  The DIT can be reallocated
> among DSAs, and this would result in name changes.  For example: assume
> that c=XX, O=Acme was handled by one DSA, but the organization grew so
> that a second DSA was added.  The new partition might be so that all of
> c=XX, o=Acme, ou=Sales was moved to the new DSA.  I would hope that this
> adjustment would nt cause any names to change.
> 
> 

------_=_NextPart_000_01BF3093.4778CA8C
Content-Type: application/ms-tnef
Content-Transfer-Encoding: base64

------_=_NextPart_000_01BF3093.4778CA8C--

Date: Tue, 16 Nov 1999 19:14:26 -0500
To: "Trevor Freeman (Exchange)" <[email-masked]>
From: Stephen Kent <[email-masked]>
Subject: RE: Associating symmetric algorithms with a public key
Cc: "Pkix List (E-mail)" <[email-masked]>

Trevor,

I hate to see extra attributes added to certs. I appreciate the 
desire to give hints to a user re what symmetric algorithms that user 
might employ when communicating with a target user, identified by the 
certificate in question.  However, I'd rather see the LDAP & X.500 
folks provide better data structures for this in the directory, 
rather than adding a field that has only heuristic value to a cert. 
If these are only hints, not proscriptive, then we don't seem to be 
making a string security statement about them anyway.

Even if we agree that Steve's Rule of Revocation is closer to linear 
or log than quadratic, the principle still applies ...

Steve

From: "Trevor Freeman (Exchange)" <[email-masked]>
To: "'Paul Koning'" <[email-masked]>
Cc: [email-masked]
Subject: RE: Associating symmetric algorithms with a public key
Date: Tue, 16 Nov 1999 14:14:46 -0800

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01BF307F.FE1BC1B8
Content-Type: text/plain;
	charset="windows-1252"

Now I get it even less, I think.

So if a cert said "DES" you could still use Blowfish to encrypt my
files?  I could still use CAST to protect my IPSEC sessions?

>>If the cert says DES, and you choose not to use DES, that is your
decision, its a big world, and you get to make you own choices, just don't
be surprised if only DES works.

If it's a "hint" that sounds like a user preference or application
interface default item.  You can put those things in your application
registry or in configuration files or user set-up scripts or stuff like 
that, but it definitely doesn't belong in a cert.

>>Putting it in the registry, local configuration file or set-up script does
not help me know what your preferences are, so it needs to be published. The
defined X.509 directory attribute, does not associate a public key with a
set of algorithms. 

Trevor

------_=_NextPart_001_01BF307F.FE1BC1B8
Content-Type: text/html;
	charset="windows-1252"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Dwindows-1252">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2650.12">
<TITLE>RE: Associating symmetric algorithms with a public key</TITLE>
</HEAD>
<BODY>
<BR>

<P><FONT SIZE=3D2>Now I get it even less, I think.</FONT>
</P>

<P><FONT SIZE=3D2>So if a cert said &quot;DES&quot; you could still use =
Blowfish to encrypt my</FONT>
<BR><FONT SIZE=3D2>files?&nbsp; I could still use CAST to protect my =
IPSEC sessions?</FONT>
</P>

<P><FONT SIZE=3D2>&gt;&gt;If the cert says DES, and you choose not to =
use DES, that is your decision, its a big world, and you get to make =
you own choices, just don't be surprised if only DES works.</FONT></P>

<P><FONT SIZE=3D2>If it's a &quot;hint&quot; that sounds like a user =
preference or application</FONT>
<BR><FONT SIZE=3D2>interface default item.&nbsp; You can put those =
things in your application</FONT>
<BR><FONT SIZE=3D2>registry or in configuration files or user set-up =
scripts or stuff like </FONT>
<BR><FONT SIZE=3D2>that, but it definitely doesn't belong in a =
cert.</FONT>
</P>

<P><FONT SIZE=3D2>&gt;&gt;Putting it in the registry, local =
configuration file or set-up script does not help me know what your =
preferences are, so it needs to be published. The defined X.509 =
directory attribute, does not associate a public key with a set of =
algorithms. </FONT></P>

<P><FONT SIZE=3D2>Trevor</FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01BF307F.FE1BC1B8--

Date: Tue, 16 Nov 1999 16:35:04 -0500
From: Paul Koning <[email-masked]>
To: [email-masked]
Cc: [email-masked]
Subject: RE: Associating symmetric algorithms with a public key

>>>>> Trevor writes:

 Trevor> This is a hint as to what to use, nothing more.

 Trevor> If I have you public key and want to encrypt a file, I
 Trevor> could guess what symmetric algorithms to use. It does not
 Trevor> hold that if I have publicise the set of symmetric
 Trevor> algorithms on my workstations, every public encryption key
 Trevor> I have in a certificate would successfully decrypt data
 Trevor> with any of the symmetric algorithms.  The key exchange
 Trevor> world complete successfully, and you client would know the
 Trevor> session key, but it is not guaranteed that that code with
 Trevor> the session key would have access to every symmetric
 Trevor> algorithms implementation on you workstation.

Now I get it even less, I think.

So if a cert said "DES" you could still use Blowfish to encrypt my
files?  I could still use CAST to protect my IPSEC sessions?

If it's a "hint" that sounds like a user preference or application
interface default item.  You can put those things in your application
registry or in configuration files or user setup scripts or stuff like 
that, but it definitely doesn't belong in a cert.

	paul

From: "Trevor Freeman (Exchange)" <[email-masked]>
To: "'Paul Koning'" <[email-masked]>
Cc: [email-masked]
Subject: RE: Associating symmetric algorithms with a public key
Date: Tue, 16 Nov 1999 10:56:34 -0800

This is a hint as to what to use, nothing more. 
If I have you public key and want to encrypt a file, I could guess what
symmetric algorithms to use. It does not hold that if I have publicise the
set of symmetric algorithms on my workstations, every public encryption key
I have in a certificate would successfully decrypt data with any of the
symmetric algorithms.  The key exchange world complete successfully, and you
client would know the session key, but it is not guaranteed that that code
with the session key would have access to every symmetric algorithms
implementation on you workstation.

-----Original Message-----
From: Paul Koning [mailto:[email-masked]]
Sent: Tuesday, November 16, 1999 10:20 AM
To: Trevor Freeman (Exchange)
Cc: [email-masked]
Subject: Re: Associating symmetric algorithms with a public key

>>>>> "Exchange" == Exchange  <Trevor> writes:

 Exchange> There are a number of applications which need a hint as to
 Exchange> the set of symmetric algorithms which can be used with a
 Exchange> public key from a certificate for encrypting data with
 Exchange> asynchronous applications. 

I'm puzzled by this.  What connection is there between a public key
and a set of supported, or permitted, symmetric algorithms?  I just
don't see the relationship.

	paul

Date: Tue, 16 Nov 1999 14:57:43 -0500
To: Stefan Santesson <[email-masked]>
From: Russ Housley <[email-masked]>
Subject: Re: Use of dnQualifier must be settled
Cc: [email-masked], Sean Turner <[email-masked]>, "Manger, James" <[email-masked]>, "Kesterson, Hoyt" <[email-masked]>, "David P. Kemp" <[email-masked]>, Anders Rundgren <[email-masked]>, "Ella P. Gardner" <[email-masked]>, "'wford'" <[email-masked]>, "'wpolk'" <[email-masked]>, "[email-masked]'" <[email-masked]>, "'Magnus Nyström'" <[email-masked]>

Interpretation 1 cannot be correct.  The DIT can be reallocated among DSAs, 
and this would result in name changes.  For example: assume that c=XX, 
O=Acme was handled by one DSA, but the organization grew so that a second 
DSA was added.  The new partition might be so that all of c=XX, o=Acme, 
ou=Sales was moved to the new DSA.  I would hope that this adjustment would 
nt cause any names to change.

Russ

At 04:00 PM 11/16/99 +0100, Stefan Santesson wrote:
>We must come to a common understanding on what the defined usage of
>dnQualifier is according to X.520.
>
>X.520 defines:
>--------------
>5.2.8 DN Qualifier
>The DN Qualifier attribute type specifies disambiguating information to add
>to the relative distinguished name of an entry. It is intended to be used
>for entries held in multiple DSAs which would otherwise have the same name,
>and that its value be the same in a given DSA for all entries to which this
>information has been added.
>[DSA = Directory System Agent, basically a directory server]
>-------------------
>
>Lets apply this to two DSA which in this case is represented by a group of
>entries each.
>
>DSA 1 group:            DSA 2 group:
>1) CN="Alice"           1) CN="Alice"
>2) CN="Bob"             2) CN="Bob"
>3) CN="Bob"             3) CN="Fred"
>
>
>INTERPRETATION 1:
>-----------------
>One interpretation (Manger) is that this means that dnQualifier is defined
>to disambiguate names between independent domains (DSA). In this case group
>1 above is invalid because names within in a group must be unique also
>without dnQualifier. but if we delete 3) from group 1 we can then use
>dnQualifier to disambiguate Alice and Bob btween group 1 and 2. dnQualifier
>is used to give all entries a common disambiguating value for each group.
>
>Ex.
>DSA 1 group:                  DSA 2 group:
>1) CN="Alice", DNQ="Grp 1"    1) CN="Alice", DNQ="Grp 2"
>2) CN="Bob", DNQ="Grp 1"      2) CN="Bob", DNQ="Grp 2"
>                               3) CN="Fred"
>
>Note that DNQ is not added to "Fred" since that is not needed.
>
>
>INTERPRETATION 2
>-----------------
>
>Interpretation 2 is the current interpretation behind the current rfc2459
>and also the interpretation in the QC profile. This interpretation says
>that dnQualifier can be used to disambiguate any name from any other name,
>regardless of whether these names are located within the same group or not.
>
>In this case the example groups may look like this:
>DSA 1 group:                  DSA 2 group:
>1) CN="Alice", DNQ="1"        1) CN="Alice", DNQ="2"
>2) CN="Bob", DNQ="1"          2) CN="Bob", DNQ="3"
>2) CN="Bob", DNQ="2"          3) CN="Fred", DNQ="1"
>
>It could also be used to store unique values like this:
>DSA 1 group:                  DSA 2 group:
>1) CN="Alice", DNQ="01"       1) CN="Alice", DNQ="11"
>2) CN="Bob", DNQ="02"         2) CN="Bob", DNQ="12"
>2) CN="Bob", DNQ="03"         3) CN="Fred", DNQ="13"
>
>
>
>Now we need to settle once and for all.....
>
>Is interpretation 1 or 2 the right one.
>
>Please be active on this one because it is VERY important that we agree on
>a consensus here very soon.
>
>
>/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
>-------------------------------------------------------------------

Date: Tue, 16 Nov 1999 13:19:59 -0500
From: Paul Koning <[email-masked]>
To: [email-masked]
Cc: [email-masked]
Subject: Re: Associating symmetric algorithms with a public key

>>>>> "Exchange" == Exchange  <Trevor> writes:

 Exchange> There are a number of applications which need a hint as to
 Exchange> the set of symmetric algorithms which can be used with a
 Exchange> public key from a certificate for encrypting data with
 Exchange> asynchronous applications. 

I'm puzzled by this.  What connection is there between a public key
and a set of supported, or permitted, symmetric algorithms?  I just
don't see the relationship.

	paul

From: "Trevor Freeman (Exchange)" <[email-masked]>
To: "[email-masked]'" <[email-masked]>
Cc: "Pkix List (E-mail)" <[email-masked]>
Subject: RE: Associating symmetric algorithms with a public key
Date: Tue, 16 Nov 1999 09:57:47 -0800

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01BF305C.17F75D78
Content-Type: text/plain;
	charset="windows-1252"

The set of application I see using this are not email clients. 
Do you have a specific objection for including this in son of 2459?
Trevor

-----Original Message-----
From: Stephen Farrell [mailto:[email-masked]]
Sent: Tuesday, November 16, 1999 3:13 AM
To: Trevor Freeman (Exchange)
Cc: Pkix List (E-mail)
Subject: Re: Associating symmetric algorithms with a public key

Trevor,

I seem to recall an objection to doing this which was raised
by Jim Schaad in the SMIME wg, can't recall exactly what it
was though, or whether it applies in general, or just to
SMIME messaging.

Regards,
Stephen.

> "Trevor Freeman (Exchange)" wrote:
> 
> There are a number of applications which need a hint as to the set of
symmetric algorithms which
> can be used with a public key from a certificate for encrypting data with
asynchronous
> applications. There is a directory attribute defined in X.509 for defining
supported algorithms
> which can list a set of algorithms and parameters, but is not associated
with any particular
> key. Using this directory attribute in a certificate would seem to solve
the problem of binding a
> set of algorithms to a specific key.
> Any objections for this to be added to son of 2459? (apart from giving Tim
yet more work - sorry
> Tim)
> Trevor

-- 
____________________________________________________________
Stephen Farrell         				   
Baltimore Technologies,   tel: (direct line) +353 1 647 7406
61 Fitzwilliam Lane,                    fax: +353 1 647 7499
Dublin 2.                mailto:[email-masked]
Ireland                             http://www.baltimore.com

------_=_NextPart_001_01BF305C.17F75D78
Content-Type: text/html;
	charset="windows-1252"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Dwindows-1252">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2650.12">
<TITLE>RE: Associating symmetric algorithms with a public key</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=3D2>The set of application I see using this are not email =
clients. </FONT>
<BR><FONT SIZE=3D2>Do you have a specific objection for including this =
in son of 2459?</FONT>
<BR><FONT SIZE=3D2>Trevor</FONT>
</P>

<P><FONT SIZE=3D2>-----Original Message-----</FONT>
<BR><FONT SIZE=3D2>From: Stephen Farrell [<A =
HREF=3D"mailto:[email-masked]">mailto:stephen.farrell@balt=
imore.ie</A>]</FONT>
<BR><FONT SIZE=3D2>Sent: Tuesday, November 16, 1999 3:13 AM</FONT>
<BR><FONT SIZE=3D2>To: Trevor Freeman (Exchange)</FONT>
<BR><FONT SIZE=3D2>Cc: Pkix List (E-mail)</FONT>
<BR><FONT SIZE=3D2>Subject: Re: Associating symmetric algorithms with a =
public key</FONT>
</P>
<BR>
<BR>

<P><FONT SIZE=3D2>Trevor,</FONT>
</P>

<P><FONT SIZE=3D2>I seem to recall an objection to doing this which was =
raised</FONT>
<BR><FONT SIZE=3D2>by Jim Schaad in the SMIME wg, can't recall exactly =
what it</FONT>
<BR><FONT SIZE=3D2>was though, or whether it applies in general, or =
just to</FONT>
<BR><FONT SIZE=3D2>SMIME messaging.</FONT>
</P>

<P><FONT SIZE=3D2>Regards,</FONT>
<BR><FONT SIZE=3D2>Stephen.</FONT>
</P>

<P><FONT SIZE=3D2>&gt; &quot;Trevor Freeman (Exchange)&quot; =
wrote:</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; There are a number of applications which need a =
hint as to the set of symmetric algorithms which</FONT>
<BR><FONT SIZE=3D2>&gt; can be used with a public key from a =
certificate for encrypting data with asynchronous</FONT>
<BR><FONT SIZE=3D2>&gt; applications. There is a directory attribute =
defined in X.509 for defining supported algorithms</FONT>
<BR><FONT SIZE=3D2>&gt; which can list a set of algorithms and =
parameters, but is not associated with any particular</FONT>
<BR><FONT SIZE=3D2>&gt; key. Using this directory attribute in a =
certificate would seem to solve the problem of binding a</FONT>
<BR><FONT SIZE=3D2>&gt; set of algorithms to a specific key.</FONT>
<BR><FONT SIZE=3D2>&gt; Any objections for this to be added to son of =
2459? (apart from giving Tim yet more work - sorry</FONT>
<BR><FONT SIZE=3D2>&gt; Tim)</FONT>
<BR><FONT SIZE=3D2>&gt; Trevor</FONT>
</P>

<P><FONT SIZE=3D2>-- </FONT>
<BR><FONT =
SIZE=3D2>____________________________________________________________</F=
ONT>
<BR><FONT SIZE=3D2>Stephen =
Farrell&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &nbsp;&nbsp; </FONT>
<BR><FONT SIZE=3D2>Baltimore Technologies,&nbsp;&nbsp; tel: (direct =
line) +353 1 647 7406</FONT>
<BR><FONT SIZE=3D2>61 Fitzwilliam =
Lane,&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&=
nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; fax: +353 1 647 =
7499</FONT>
<BR><FONT SIZE=3D2>Dublin =
2.&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp; <A =
HREF=3D"mailto:[email-masked]">mailto:stephen.farrell@balt=
imore.ie</A></FONT>
<BR><FONT =
SIZE=3D2>Ireland&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <A =
HREF=3D"http://www.baltimore.com" =
TARGET=3D"_blank">http://www.baltimore.com</A></FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01BF305C.17F75D78--

Date: Tue, 16 Nov 1999 10:31:20 -0500
From: Ella Paton Bassett <[email-masked]>
Organization: The MITRE Corporation
To: David Boyce <[email-masked]>
CC: Stefan Santesson <[email-masked]>, [email-masked], Sean Turner <[email-masked]>, "Manger, James" <[email-masked]>, "Kesterson, Hoyt" <[email-masked]>, "David P. Kemp" <[email-masked]>, Anders Rundgren <[email-masked]>, "'housley'" <[email-masked]>, "'wford'" <[email-masked]>, "'wpolk'" <[email-masked]>, "[email-masked]'" <[email-masked]>, "'Magnus Nystr m'" <[email-masked]>
Subject: Re: Use of dnQualifier must be settled

Folks:

I've suggested to Hoyt Kesterson and Sharon Boeyen that we consider
slipping a new attribute definition into the FPDAM for X.509 but haven't
heard from them.

 uniqueIdentity ATTRIBUTE        ::=     {
        WITH SYNTAX                     DirectoryString
        EQUALITY MATCHING RULE          caseIgnoreMatch
        ORDERING MATCHING RULE          caseIgnoreOrderingMatch
        SUBSTRINGS MATCHING RULE        caseIgnoreSubstringsMatch
        ID                              id-at-uniqueIdentity }

The uniqueIdentity attribute type provides an unambiguous identity that
may be used as an RDN or in combination with another attribute as an
RDN.

Ella

To: Stefan Santesson <[email-masked]>
cc: [email-masked], Sean Turner <[email-masked]>, "Manger, James" <[email-masked]>, "Kesterson, Hoyt" <[email-masked]>, "David P. Kemp" <[email-masked]>, Anders Rundgren <[email-masked]>, "Ella P. Gardner" <[email-masked]>, "'housley'" <[email-masked]>, "'wford'" <[email-masked]>, "'wpolk'" <[email-masked]>, "[email-masked]'" <[email-masked]>, =?iso-8859-1?Q?=22=27Magnus_Nystr m=27=22?= <[email-masked]>
Subject: Re: Use of dnQualifier must be settled 
Date: Tue, 16 Nov 1999 15:27:01 +0000
From: David Boyce <[email-masked]>

Stefan Santesson writes:

>We must come to a common understanding on what the defined usage of
>dnQualifier is according to X.520.

>Is interpretation 1 or 2 the right one. 
>
>Please be active on this one because it is VERY important that we 
agree on
>a consensus here very soon.

Taking your invitation to be active on this:

I'm coming at this from an X.500 point of view.   I cannot see how
Interpretation 2 can possibly be correct, given the statement in X.520
"that its value be the same in a given DSA for all entries to which this
information has been added".  Interpretation 2 clearly violates this, as
there are different values of dnQualifier for entries in the same DSA.

Consequently, if you are serious about conforming to X.520, I would have
to say interpretation 1 is the way to go.

(When we've done this, we can go on to discuss the proper order of RDNs
in Name.)

David.
-- 
David Boyce

MessagingDirect (UK) Ltd.
Tel:	+44 20 8332 9091		 Richmond, Surrey, ENGLAND
Email:	[email-masked]	 WWW: http://www.MessagingDirect.com/

Date: Tue, 16 Nov 1999 16:00:47 +0100
To: [email-masked]
From: Stefan Santesson <[email-masked]>
Subject: Use of dnQualifier must be settled
Cc: Sean Turner <[email-masked]>, "Manger, James" <[email-masked]>, "Kesterson, Hoyt" <[email-masked]>, "David P. Kemp" <[email-masked]>, Anders Rundgren <[email-masked]>, "Ella P. Gardner" <[email-masked]>, "'housley'" <[email-masked]>, "'wford'" <[email-masked]>, "'wpolk'" <[email-masked]>, "[email-masked]'" <[email-masked]>, =?iso-8859-1?Q?=22=27Magnus_Nyström=27=22?= <[email-masked]>

We must come to a common understanding on what the defined usage of
dnQualifier is according to X.520.

X.520 defines:
--------------
5.2.8 DN Qualifier 
The DN Qualifier attribute type specifies disambiguating information to add 
to the relative distinguished name of an entry. It is intended to be used 
for entries held in multiple DSAs which would otherwise have the same name, 
and that its value be the same in a given DSA for all entries to which this 
information has been added.
[DSA = Directory System Agent, basically a directory server]
-------------------

Lets apply this to two DSA which in this case is represented by a group of
entries each.

DSA 1 group:            DSA 2 group:          
1) CN="Alice"           1) CN="Alice"
2) CN="Bob"             2) CN="Bob"
3) CN="Bob"             3) CN="Fred"

INTERPRETATION 1:
-----------------
One interpretation (Manger) is that this means that dnQualifier is defined
to disambiguate names between independent domains (DSA). In this case group
1 above is invalid because names within in a group must be unique also
without dnQualifier. but if we delete 3) from group 1 we can then use
dnQualifier to disambiguate Alice and Bob btween group 1 and 2. dnQualifier
is used to give all entries a common disambiguating value for each group.

Ex.
DSA 1 group:                  DSA 2 group:          
1) CN="Alice", DNQ="Grp 1"    1) CN="Alice", DNQ="Grp 2"
2) CN="Bob", DNQ="Grp 1"      2) CN="Bob", DNQ="Grp 2"
                              3) CN="Fred"

Note that DNQ is not added to "Fred" since that is not needed.

INTERPRETATION 2
-----------------

Interpretation 2 is the current interpretation behind the current rfc2459
and also the interpretation in the QC profile. This interpretation says
that dnQualifier can be used to disambiguate any name from any other name,
regardless of whether these names are located within the same group or not.

In this case the example groups may look like this:
DSA 1 group:                  DSA 2 group:          
1) CN="Alice", DNQ="1"        1) CN="Alice", DNQ="2"
2) CN="Bob", DNQ="1"          2) CN="Bob", DNQ="3"
2) CN="Bob", DNQ="2"          3) CN="Fred", DNQ="1"

It could also be used to store unique values like this:
DSA 1 group:                  DSA 2 group:          
1) CN="Alice", DNQ="01"       1) CN="Alice", DNQ="11"
2) CN="Bob", DNQ="02"         2) CN="Bob", DNQ="12"
2) CN="Bob", DNQ="03"         3) CN="Fred", DNQ="13"

Now we need to settle once and for all.....

Is interpretation 1 or 2 the right one. 

Please be active on this one because it is VERY important that we agree on
a consensus here very soon.

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

Date: Tue, 16 Nov 1999 11:12:41 +0000
From: Stephen Farrell <[email-masked]>
Reply-To: [email-masked]
Organization: Baltimore Technologies Ltd.
To: "Trevor Freeman (Exchange)" <[email-masked]>
CC: "Pkix List (E-mail)" <[email-masked]>
Subject: Re: Associating symmetric algorithms with a public key

Trevor,

I seem to recall an objection to doing this which was raised
by Jim Schaad in the SMIME wg, can't recall exactly what it
was though, or whether it applies in general, or just to
SMIME messaging.

Regards,
Stephen.

> "Trevor Freeman (Exchange)" wrote:
> 
> There are a number of applications which need a hint as to the set of symmetric algorithms which
> can be used with a public key from a certificate for encrypting data with asynchronous
> applications. There is a directory attribute defined in X.509 for defining supported algorithms
> which can list a set of algorithms and parameters, but is not associated with any particular
> key. Using this directory attribute in a certificate would seem to solve the problem of binding a
> set of algorithms to a specific key.
> Any objections for this to be added to son of 2459? (apart from giving Tim yet more work - sorry
> Tim)
> Trevor

-- 
____________________________________________________________
Stephen Farrell         				   
Baltimore Technologies,   tel: (direct line) +353 1 647 7406
61 Fitzwilliam Lane,                    fax: +353 1 647 7499
Dublin 2.                mailto:[email-masked]
Ireland                             http://www.baltimore.com

Content-return: allowed
Date: Mon, 15 Nov 1999 19:40:47 -0500
From: "Sweigert, David" <[email-masked]>
Subject: RE: Licensed Certification Authorities in USA
To: [email-masked], Sungjin Lee <[email-masked]>, [email-masked]

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_000_01BF2FCB.3981520A
Content-Type: text/plain;
	charset="iso-8859-1"

You may find the attached of interest.

Dave Sweigert
General Dynamics
http://www.gd-cs.com

RE:
Release Date: November 10, 1999 

For immediate release  

The Federal Reserve Board today announced its approval of the proposal by
Bayerische Hypo- und Vereinsbank AG, Munich, Germany; Deutsche Bank AG,
Frankfurt, Germany; and Stichting Prioriteit ABN AMRO Holding, Stichting
Administratiekantoor ABN AMRO Holding, ABN AMRO Holding N.V., and ABN AMRO
Bank N.V., all of Amsterdam, The Netherlands; each to retain up to 12.5
percent of the voting interests of Identrus, LLC, New York, New York, and to
engage in acting as a certification authority in connection with financial
and nonfinancial transactions and other related activities.  

-----Original Message-----
From: Russ Savage [mailto:[email-masked]]
Sent: Tuesday, November 09, 1999 9:52 AM
To: Sweigert, David; Sungjin Lee; [email-masked]
Subject: RE: Licensed Certification Authorities in USA

Most states have some provision recognizing electronic signatures as
being the equivalent of a handwritten signature
(at least in some circumstance and form).

Some states may only define a form of use and say little about the CA.
Others, like Washington and Utah, license to add weight to the use.
But, as far as I know, no state requires CA licensing for
business to business use.

Most do define and manage electronic signature use involving state agencies.
That's basically just establishing and defining the minimum contract
requirements
for electronic signature interaction with those agencies.

If we haven't answered your question, email me off list and
I'll point you toward appropriate resources.

Russ Savage
Arizona's Office of the Secretary of State

-----Original Message-----
From: Sweigert, David [mailto:[email-masked]]
Sent: Tuesday, November 09, 1999 7:06 AM
To: Sungjin Lee; [email-masked]
Subject: RE: Licensed Certification Authorities in USA

Nearly each of the fifty states in the U.S. has some type of
digital signature law that allows for the provision of state
licensed C.A.s.  I belief your list is not comprehensive enough.

Dave Sweigert
General Dynamics
http://www.gd-cs.com

-----Original Message-----
From: Sungjin Lee [mailto:[email-masked]]
Sent: Tuesday, November 09, 1999 6:21 AM
To: [email-masked]
Subject: Licensed Certification Authorities in USA

I know that there are "Licensed Certification Authorities" in Utah and
Washington in USA

 - Digital Signature Trust Company, Arcanvs, USERFirst, Verisign, IC
Certify

Is there another "Licensed Certification Authority" in USA?

  Sungjin Lee

  SignKorea (http://www.signkorea.com)
  Korea Securities Computer Corp.
  Seoul, South Korea.

------_=_NextPart_000_01BF2FCB.3981520A
Content-Type: application/octet-stream;
	name="19991110.pdf"
Content-Transfer-Encoding: base64
Content-Disposition: attachment;
	filename="19991110.pdf"

------_=_NextPart_000_01BF2FCB.3981520A--

From: "Trevor Freeman (Exchange)" <[email-masked]>
To: "Pkix List (E-mail)" <[email-masked]>
Subject: Associating symmetric algorithms with a public key
Date: Mon, 15 Nov 1999 16:03:10 -0800

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01BF2FC5.F81EE3E0
Content-Type: text/plain;
	charset="iso-8859-1"

There are a number of applications which need a hint as to the set of
symmetric algorithms which can be used with a public key from a certificate
for encrypting data with asynchronous applications. There is a directory
attribute defined in X.509 for defining supported algorithms which can list
a set of algorithms and parameters, but is not associated with any
particular key. Using this directory attribute in a certificate would seem
to solve the problem of binding a set of algorithms to a specific key.
Any objections for this to be added to son of 2459? (apart from giving Tim
yet more work - sorry Tim)
Trevor

------_=_NextPart_001_01BF2FC5.F81EE3E0
Content-Type: text/html;
	charset="iso-8859-1"

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1">

<META content="MSHTML 5.00.2920.0" name=GENERATOR></HEAD>
<BODY>
<DIV><FONT face=Arial size=2><SPAN class=753175523-15111999>There are a number 
of applications which need a hint as to the set of symmetric algorithms which 
can be used with a public key from a certificate for encrypting data with 
asynchronous applications. There is a directory attribute defined in X.509 for 
defining supported algorithms which can list a set of algorithms and parameters, 
but is not associated with any particular key.&nbsp;Using this directory 
attribute in a certificate would seem to solve the problem of binding a set of 
algorithms to a specific key.</SPAN></FONT></DIV>
<DIV><FONT face=Arial size=2><SPAN class=753175523-15111999>Any objections for 
this to be added to son of 2459? (apart from giving Tim yet more work - sorry 
Tim)</SPAN></FONT></DIV>
<DIV><FONT face=Arial size=2><SPAN 
class=753175523-15111999>Trevor</SPAN></FONT></DIV></BODY></HTML>

------_=_NextPart_001_01BF2FC5.F81EE3E0--

Date: Mon, 15 Nov 1999 18:27:34 -0500
To: "Todd Glassey @ GMTsw" <[email-masked]>
From: Stephen Kent <[email-masked]>
Subject: Re: Timestamp: 04: comments
Cc: <[email-masked]>

Todd,

We're moving forward with the TSP, based on the model we have adopted 
for TSAs.  That model does not require tokens to contain GPS 
coordinates, or some of the other sorts of data that BERT contains.

Also, just because I said it's fine for you to go the STIME WG with 
BERT does not mean that STIME will accept that proposal.  Since that 
WG has a narrow focus on securing NTP, it is not clear to me how 
receptive they will be to BERT, but that's their call.

Steve

Date: Mon, 15 Nov 1999 22:35:23 +0000
From: Ben Laurie <[email-masked]>
Organization: A.L. Group plc
To: [email-masked]
CC: [email-masked]
Subject: Re: Extension Order

Peter Gutmann wrote:
> 
> "Scott, Greg" <[email-masked]> writes:
> 
> >There's been an in house discussion re whether the extension sequence should
> >have a certain order, i.e., one extension type should always proceed another,
> >the extensions should appear in OID order, order of appearance doesn't matter,
> >etc.
> >
> >It seems to me that any implementation should be able to handle extensions
> >appropriately regardless of the order they appear in the cert.
> >
> >RFC 2459 doesn't indicate a specific order of appearance, but is anyone aware
> >of an accepted order for extensions?  Has anyone experienced a fault brought
> >on by the extensions of a cert appearing in a certain sequence?
> 
> I've seen them sorted as per the DER SET rules, sorted by OID, probably sorted
> by functionality (extensions with related purposes grouped together), and in no
> discernable order.  I'd really recommend against requiring anything beyond the
> standard DER rules, it'll break large numbers of existing certs without any
> real gain.

Why does everyone think ASN.1 is so great when no-one can get it right?

Cheers,

Ben.

--
http://www.apache-ssl.org/ben.html

"My grandfather once told me that there are two kinds of people: those
who work and those who take the credit. He told me to try to be in the
first group; there was less competition there."
     - Indira Gandhi

From: [email-masked] (Peter Gutmann)
To: [email-masked]
Subject: Re:  Extension Order
Sender: [email-masked]
Reply-To: [email-masked]
Date: Tue, 16 Nov 1999 11:30:52 (NZDT)

"Scott, Greg" <[email-masked]> writes:

>There's been an in house discussion re whether the extension sequence should
>have a certain order, i.e., one extension type should always proceed another,
>the extensions should appear in OID order, order of appearance doesn't matter,
>etc.
>
>It seems to me that any implementation should be able to handle extensions
>appropriately regardless of the order they appear in the cert.
>
>RFC 2459 doesn't indicate a specific order of appearance, but is anyone aware
>of an accepted order for extensions?  Has anyone experienced a fault brought
>on by the extensions of a cert appearing in a certain sequence?

I've seen them sorted as per the DER SET rules, sorted by OID, probably sorted
by functionality (extensions with related purposes grouped together), and in no
discernable order.  I'd really recommend against requiring anything beyond the
standard DER rules, it'll break large numbers of existing certs without any
real gain.

Peter.

From: "Scott, Greg" <[email-masked]>
To: "[email-masked]'" <[email-masked]>
Subject:  Extension Order
Date: Mon, 15 Nov 1999 15:44:28 -0500

There's been an in house discussion re whether the extension sequence should
have a certain order, i.e., one extension type should always proceed
another, the extensions should appear in OID order, order of appearance
doesn't matter, etc.

It seems to me that any implementation should be able to handle extensions
appropriately regardless of the order they appear in the cert.  

RFC 2459 doesn't indicate a specific order of appearance, but is anyone
aware of an accepted order for extensions?  Has anyone experienced a fault
brought on by the extensions of a cert appearing in a certain sequence?

R/s Greg
http://www-pki.itsi.disa.mil/

Date: Mon, 15 Nov 1999 10:37:10 -0500 (EST)
From: "David P. Kemp" <[email-masked]>
Reply-To: "David P. Kemp" <[email-masked]>
Subject: Re: dnQualifier
To: [email-masked]
Content-MD5: SAjDAETjCeP4QBFzfYDxwg==

> Date: Wed, 10 Nov 1999 13:36:52 -0500
> From: schaen <[email-masked]>
> 
> The DoD has been issuing certs with a UID concatenated to the CN for the
> past 9 months.  We recognized the kludge at the time, but needed a way to
> provide unique identifiers for a very large organization in a highly
> distributed manner.  At the time, we found that many applications could
> not handle multi-attribute RDNs, and so went with the kludge.  The DoD
> will consider migrating when the standards solidify and applications
> support a standard approach.

And likewise the TRW and NIH technique of using a Static Identifier in
one RDN followed by Common Name in the terminal RDN is a kludge to work
around the non-availability of support for multi-attribute RDNs.

For current applications I think the TRW kludge is better than the DoD
kludge.

> Date: Fri, 12 Nov 1999 16:41:19 -0500
> From: "Ella P. Gardner" <[email-masked]>
> 
> I've been following with interest the discussion of the use of
> dnQualifier and was happy to see that the group had agreed to use that
> to disambiguate entities. I was also was glad to see that others support
> the use of multiple attributes to form an RDN.
> 
> In the Allied Communication Publication 133 Task Force, the group that
> makes agreements for directory support with our allies, we decided to
> use dnQualifier. We realized that the meaning in X.521 is not exactly
> what we need, but we preferred to use a standard attribute. We did not
> want to use the unique identifier for the same reason others don't - the
> bit string syntax.
> 
> So far we've been able to coordinate between PKIX documents and X.509 to
> use standard attributes. Let's use dnQualifier. If that threatens world
> peace, let's get a new definition into the X.509 FPDAM. 

For future applications with support for multi-attribute RDNs, we need
a standard way to represent the Static Identifier, an attribute such as
employee number which does *not* just disambiguate a name, it
identifies the same individual even when that individual's name
changes.  Three approaches have been suggested:

1) Use dnQualifier {id-at 46} in conjunction with a QC properties
   extension which says that in this instance the dnQualifier is a
   Static Identifier.

2) Modify the X.520 definition of dnQualifier to say that it always
   uniquely identifies a component (as opposed to the current
   definition which says only that the combination of dnQualifier and
   another attribute is unique).

3) Use a different attribute such as serialNumber {id-at 5} for the
   Static Identifier, modifying X.520 to say that serial number may
   refer to any object, not to just a "device".

Approach 3) is the cleanest because 1) applies only to QCs and requires
the presence of a certificate extension, and 2) modifies the definition
of dnQualifier in a manner that is neither backwards-compatible nor
consistent with the name "dnQualifier".

PKIX, X.520, and ACP 133 should be modified to use the RDN

  dnQualifier+commonName

in the case where only the combination of dnQualifier and commonName
uniquely identifies an entity, and to use the RDN

  serialNumber+commonName

in cases where serialNumber uniquely identifies an entity and commonName
is additional information provided for human convenience.

From: Darren Harter <[email-masked]>
To: "[email-masked]'" <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: RE: ASN.1 question to PKIHeader in CMP (RFC 2510) 
Date: Mon, 15 Nov 1999 15:15:10 -0000

Anette,

The important thing to remember here is that the sender and recipient are not OPTIONAL in the definition of PKIHeader, so they will always appear in the encoding.  So if you chose Name's for the sender and recipient then the encoding would begin:  30 ... 02 ... A4 ... A4 ....  This would then be followed by the OPTIONAl elements in the order shown in the definition..  So if you didn't have a messageTime, protectionAlg, senderKID or recipKID in your PKIHeader you encoding would begin 30 ... 02 ... A4 .. A4 ... 84 ...

Here the first A4 is the sender, the second A4 is the recipient and the 84 is the transactionID.  Note the use of 84 here not A4.  The reason that you have 84 for transactionID is that OCTET STRING are not a constructed type (they do not hold other ASN.1 elements*) where as Name (or more specifically RDNSequence) is a constructed type. The 6th bit is only set for constructed types.

Hope this helps,

Darren

p.s. * For the ASN.1 pedants, I'm aware that octet strings can be constructed when encoded using BER, and that they are often used to hold ASN.1-encoded data internally.  The description above is intended to be descriptive not prescriptive.

-------------------------------------------
Darren Harter B.Sc. (Hons) MBCS CEng
Application Development Group, UK
Entegrity Solutions Corp
Tel: +44 (0) 1452 371383
Fax: +44 (0) 1452 371384
Cell: +44 (0) 7801 812850
Mail: <mailto:[email-masked]>
Web: <http://www.entegrity.com>

-----Original Message-----
From:	Anette Byskov [SMTP:[email-masked]]
Sent:	15 November 1999 14:31
To:	[email-masked]
Subject:	ASN.1 question to PKIHeader in CMP (RFC 2510) 

This is a pure and somewhat trivial ASN.1 tagging question but I hope
some knowledgeable people will help my anyway :-)

In the PKIHeader in Certificate Management Protocols the sender and
recipient are GeneralName SEQUENCES. In GeneralName the tagging is
IMPLICIT - except for the directoryName which is promoted to EXPLICIT as
Name is a Choice. Right? So if you set the directoryName in the sender
and/or recipient you get an encoding like A4 xx 30 .. for that component
within the PKIHeader encoding.
But how do you distinguish between this and the transactionID which also
has an explicit tag [4] (resulting in an encoding like A4 xx 04 ..)?  
Ought the two outer tags not be different?

Regards,
Anette
-- 
Anette Byskov                          Cryptomathic A/S
Phone:  +45 86 13 90 20                Klostergade 28
Fax:    +45 86 20 29 75                DK-8000 Aarhus C
http://www.cryptomathic.dk/            Denmark

From: "Salter, Thomas A" <[email-masked]>
To: [email-masked], [email-masked]
Subject: RE: ASN.1 question to PKIHeader in CMP (RFC 2510) 
Date: Mon, 15 Nov 1999 09:58:24 -0500

There's no ambiguity because the sender and recipient fields are not
optional;  they will always be the second and third elements in the
sequence.  So, you could end up with a sequence containing elements like
this:
   Sequence {
	INTEGER
	[4] sender-DN
	[4] recipient-DN
	[4] transaction ID
	}

 > -----Original Message-----
 > From: Anette Byskov [mailto:[email-masked]]
 > Sent: Monday, November 15, 1999 9:31 AM
 > To: [email-masked]
 > Subject: ASN.1 question to PKIHeader in CMP (RFC 2510) 
 > 
 > 
 > This is a pure and somewhat trivial ASN.1 tagging question but I hope
 > some knowledgeable people will help my anyway :-)
 > 
 > In the PKIHeader in Certificate Management Protocols the sender and
 > recipient are GeneralName SEQUENCES. In GeneralName the tagging is
 > IMPLICIT - except for the directoryName which is promoted to 
 > EXPLICIT as
 > Name is a Choice. Right? So if you set the directoryName in 
 > the sender
 > and/or recipient you get an encoding like A4 xx 30 .. for 
 > that component
 > within the PKIHeader encoding.
 > But how do you distinguish between this and the 
 > transactionID which also
 > has an explicit tag [4] (resulting in an encoding like A4 xx 
 > 04 ..)?  
 > Ought the two outer tags not be different?
 > 
 > Regards,
 > Anette
 > -- 
 > Anette Byskov                          Cryptomathic A/S
 > Phone:  +45 86 13 90 20                Klostergade 28
 > Fax:    +45 86 20 29 75                DK-8000 Aarhus C
 > http://www.cryptomathic.dk/            Denmark
 > 

From: "Luo, Feng (Exchange)" <[email-masked]>
To: "[email-masked]'" <[email-masked]>
Subject: FW: Check this out quickly and respond!
Date: Mon, 15 Nov 1999 09:52:40 -0500

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_000_01BF2F79.5EC9E060
Content-Type: text/plain

> -----Original Message-----
> From:	Zhou, Qinyan [SMTP:[email-masked]]
> Sent:	Monday, November 15, 1999 9:40 AM
> To:	[email-masked]'
> Subject:	FW: Check this out quickly and respond!
> 
> 
> 
> > -----Original Message-----
> > From:	Jennifer Yan [SMTP:[email-masked]]
> > Sent:	Saturday, November 13, 1999 7:59 PM
> > To:	[email-masked]
> > Subject:	Fwd: Check this out quickly and respond!
> > 
> > 
> > 
> > Note: forwarded message attached.
> > 
> > 
> > =====
> > 
> > __________________________________________________
> > Do You Yahoo!?
> > Bid and sell for free at http://auctions.yahoo.com <<Check this out
> > quickly and respond!>>  <<Check this out quickly and respond!>> 

------_=_NextPart_000_01BF2F79.5EC9E060
Content-Type: message/rfc822
Content-Description: Check this out quickly and respond!

Message-ID: <[email-masked]>
From: Yue Wu <[email-masked]>
To: [email-masked]
Cc: [email-masked]
Subject: Check this out quickly and respond!
Date: Fri, 12 Nov 1999 22:28:30 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2448.0)
Content-Type: text/plain;
	charset="iso-8859-1"

>From: [email-masked]
>To: [email-masked], [email-masked], [email-masked]
>Subject: FW: Check this out quickly and respond!
>Date: Thu, 11 Nov 1999 13:17:37 -0500
>
>
>
>
>---------------------- Forwarded by Hong Sheng/JSI on 11/11/99 01:12 PM
>---------------------------
>
>
>Amil Kana
>11/11/99 12:34 PM
>
>To:   [email-masked], Troy Hamid/JSI@JSI, Jessy Aricatt/JSI@JSI, Darena
>       Gueorguieva/JSI@JSI, Daisy Ly/JSI@JSI, Nasra Farah/JSI@JSI, Christin
>       Banh/JSI@JSI, Hong Sheng/JSI@JSI
>cc:
>
>Subject:  FW: Check this out quickly and respond!
>
>
>---------------------- Forwarded by Amil Kana/JSI on 11/11/99 12:30 PM
>---------------------------
>
>
>Ernest Lim
>11/11/99 11:55 AM
>
>To:   Vincent Tiongson/JSI@JSI, Dina Callueng/JSI@JSI, Stephen
>       Rodrigo/JSI@JSI, Stephen Yen/JSI@JSI, Mike Lamacchia/JSI@JSI, Derek
>       Matys/JSI@JSI, Durwin Pryce/JSI@JSI, Lori Hinton/JSI@JSI, Amil
>       Kana/JSI@JSI, Julie Chong/JSI@JSI, [email-masked],
>       [email-masked], [email-masked]
>cc:
>
>Subject:  FW: Check this out quickly and respond!
>
>Easy money or BS?????
>---------------------- Forwarded by Ernest Lim/JSI on 11/11/99 11:52 AM
>---------------------------
>
>
>[email-masked] on 11/11/99 11:50:38 AM
>
>To:   jalteza
>cc:    (bcc: Ernest Lim/JSI)
>
>Subject:  FW: Check this out quickly and respond!
>
>
>
>
>Sorry guys... but this could be a short term solution to earlier
>retirement.
>
>---------------------- Forwarded by John Elliott/MCS/Price Waterhouse on
>11/11/99 10:06 AM ---------------------------
>
>
>[email-masked] on 11/11/99 09:17:46 AM
>To:   [email-masked], [email-masked], [email-masked], John
>       Elliott/MCS/Price Waterhouse, Anita C. Pompilio/North York 
>ON/C&L/CA,
>       [email-masked], [email-masked], [email-masked],
>       [email-masked], [email-masked], [email-masked],
>       [email-masked]
>cc:
>Subject:  FW: Check this out quickly and respond!
>
>
>
>
>
>
>: Check this out quickly and respond!
>
>I am forwarding this because the person who sent it to me is  a very
>professional
>business person and a good friend and does not send  me junk.
>
>Microsoft and AOL are now the largest Internet company and  in an effort
>make
>sure that Internet explorer remains the most widely  used program,
>Microsoft and
>AOLare running an e-mail beta  test.
>
>When you forward this e-mail to friends, Microsoft can and will  track it
>(if
>you are a Microsoft Windows user) for a two week time  period.
>
>For every person that you forward this e-mail to, Microsoft  will pay you
>$245.00,for
>every person that you sent it to that forwards  it on.
>
>Microsoft will pay you $243.00 and for every third person that  receives
>it,
>you will be paid $241.00. Within two weeks, Microsoft will  contact you for
>your
>address and then send you a check.
>
>I thought  this was a scam
>myself, but two weeks after receiving this e-mail and  forwarding it on.
>
>Microsoft contacted me for my e-mail and within  days, I received a check
>for
>$24,800.00. You need to respond before the  beta testing is over.
>
>If anyone can afford this Bill Gates is the  man.  It's all marketing
>expense
>to him.
>
>Do  Well!!!
>
>
>
>
>
>
>
>
>
>
>
>
>Wally Williamson
>Vice President and Account Executive
>Aon Re Canada
>Toronto, Ontario, Canada
>Phone: 416-979-3300        Fax: 416-979-7724
>
>
>
>
>Chris Pompilio
>Vice President
>Aon Re Canada
>Toronto
>Phone: 416 979 3300        Fax: 416 979 7724
>
>
>
>
>
>
>----------------------------------------------------------------
>The information transmitted is intended only for the person or entity to
>which it is addressed and may contain confidential and/or privileged
>material.  Any review, retransmission, dissemination or other use of, or
>taking of any action in reliance upon, this information by persons or
>entities other than the intended recipient is prohibited.   If you received
>  this in error, please contact the sender and delete the material from any
>computer.
>
>
>
>
>
>
>
>
>
>
>

______________________________________________________
Get Your Private, Free Email at http://www.hotmail.com

------_=_NextPart_000_01BF2F79.5EC9E060
Content-Type: text/plain; charset=us-ascii

***********************************************************************
Bear Stearns is not responsible for any recommendation, solicitation, 
offer or agreement or any information about any transaction, customer 
account or account activity contained in this communication.
***********************************************************************

------_=_NextPart_000_01BF2F79.5EC9E060--

Date: Mon, 15 Nov 1999 15:30:39 +0100
From: Anette Byskov <[email-masked]>
Reply-To: [email-masked]
Organization: Cryptomathic
To: [email-masked]
Subject: ASN.1 question to PKIHeader in CMP (RFC 2510) 

This is a pure and somewhat trivial ASN.1 tagging question but I hope
some knowledgeable people will help my anyway :-)

In the PKIHeader in Certificate Management Protocols the sender and
recipient are GeneralName SEQUENCES. In GeneralName the tagging is
IMPLICIT - except for the directoryName which is promoted to EXPLICIT as
Name is a Choice. Right? So if you set the directoryName in the sender
and/or recipient you get an encoding like A4 xx 30 .. for that component
within the PKIHeader encoding.
But how do you distinguish between this and the transactionID which also
has an explicit tag [4] (resulting in an encoding like A4 xx 04 ..)?  
Ought the two outer tags not be different?

Regards,
Anette
-- 
Anette Byskov                          Cryptomathic A/S
Phone:  +45 86 13 90 20                Klostergade 28
Fax:    +45 86 20 29 75                DK-8000 Aarhus C
http://www.cryptomathic.dk/            Denmark

From: "Todd Glassey @ GMTsw" <[email-masked]>
To: "Manger, James" <[email-masked]>, <[email-masked]>
Subject: Re: Timestamp: 04: comments
Date: Sat, 13 Nov 1999 17:46:50 -0800

----- Original Message -----
From: "Manger, James" <[email-masked]>
To: <[email-masked]>
Sent: Monday, November 08, 1999 04:02 PM
Subject: Timestamp: 04: comments

> Accuracy:
> Why is 1 second the default?  This seems an arbitrary figure.  There is no
> reason why clocks will have this accuracy instead of any other.  If you
> really want 1 s as the default, use the ASN.1 syntax to specify this:
> accuracy [0] Accuracy DEFAULT seconds:1
> I suggest keeping the field optional, but with no default value.  If
absent,
> no statement is made about accuracy (2 tokens from the same TSA can still
be
> meaningfully compared).
>
> Token:
> The timestamp token is the most important feature.  The request syntax is
> far less important (it has no security associated with it).  Reorder the
> draft to specify the timestamp token first, giving its syntax and
explaining
> the semantics for each field.  In a later section, define a protocol for
> requesting a timestamp.

If the token architecture is important then I suggest that it is what must
be standardized. The rest of the draft is the specific use model for the
token itself.

Stephen Kent has authorized us to take the BERT Token Structure into STime
and actually that makes sense. However the Token from the existing TS Drafts
should likewise be done that way tand the existing draft rewrtitten to
accomadate this new architeture.

My feeling is that this will increase the public acceptance of both
standards proposals and that this is good for all.

>
> Serial number:
> The timestamp token now has a "monotonically increasing" field and a
> "strictly monotonically increasing field", even though the later has no
> meaning other than its strict monotonicity and the former is trivial to
make
> strictly monotonic if the issuer desires.

these are specific to the use models and should probably be standardized at
the use level.

>
> Name:
> The timestamp signer's name (often a large field) is identified in
> triplicate: in the token as a "hint", in an ESSCertID authenticated
> attribute, and in signerInfo.  Ditch the first, allow (but don't require)
> the second and require the third.

these are specific to the use models and should probably be standardized at
the use level.

>
> Extensions:
> Even though no critical extensions are defined you still need to state
what
> an application should do on receiving an unrecognized critical extension.
> Better still, offer explicit extensibility via a SEQUENCE OF Attribute,
> instead of Extensions.
>

these are specific to the use models and should probably be standardized at
the use level.

The real big win would be rearchitecting the token so that it has
essentially a definable header and manifest so that one can determine:

    1)     What the token components are
    2)    What trust model services this token requires or is bound to
    3)    The state of the token itself
    4)    The use models for the token (i.e its policy)

Todd

From: [email-masked]
To: [email-masked]
Date: Sat, 13 Nov 1999 12:41:19 -0500
Subject: Unsubscribe

Unsubscribe

Bernard Hervault <[email-masked]> on 11/12/99 03:12:32 AM

Please respond to [email-masked]

To:   "[email-masked]" <[email-masked]>
cc:    (bcc: Cam F Johnston/Audit/ErnstYoung/CA)
Subject:  Unsubscribe

unsubscribe

--
______________________________________________________
Bernard Hervault - Email: <[email-masked]>
ETIAM "Cooperative medical imaging products"
20 rue du Pr.  Jean PECKER - 35000 RENNES - France -
Tel: (+33) 02 99 14 33 88 - Fax: (+33) 02 99 14 33 80
Web:  http://www.etiam.com
______________________________________________________

From: "Anders Rundgren" <[email-masked]>
To: "PKIX-List" <[email-masked]>
Subject: Stupid Q. re. PKCs and Directories
Date: Sat, 13 Nov 1999 10:33:50 -0000

Hi, 
This is a spin-off  of the dnQualifier/static identity discussion.
Pardon the somewhat naive question.  

To put information in tree-shaped directories makes sense for organizations that
divide information in groups like departments, projects, regions etc.. 
Traditional database systems are not very flexible on this point so directories have their
place in a dynamically changing world.

BUT, what is the value of putting a lot of directory information in a public key certificate?

It would be awfully nice if someone who is fully “directory-enabled” would in practical terms
show the benefit of that compared to having a single key into a directory and let directory attributes
attached to that entity be externally inputted with variable data (department, role, access rights)
or static data  (sex, age, telephone).  Of course you can when the entity cert is first encountered read
attributes and insert them in the directory but the next time the RP sees that cert it has no reason
to do that. 

Anders Rundgren

From: "Anders Rundgren" <[email-masked]>
To: "PKIX-List" <[email-masked]>, <[email-masked]>
Subject: Re: dnQualifier
Date: Sat, 13 Nov 1999 08:36:57 -0000

Ella, 
It seems that the issue is addressed by this group (PKIX) but I see no signs of 
consensus on a new interpretation on dnQualifier. At least not by reading the 
PKIX-postings.  

Personally I think that the feature requested (which is different than just distinguishing between 
entities with similar name) should get a new fresh attribute or extension. Its connection to 
X.500 directories is outside of my competence (I believe this feature will mostly be used in 
non-directory-oriented systems like access control, e-commerce and Internet-banking). 

In such systems a subscriber is usually reduced to a number and things like "Name",
"Gender", "Address" are  simply attributes that are used for display purposes and/or human
verification. 

As seen by some recent postings on this subject a lot of parties have already 
deployed their own style of "static unique identity string" 

It would of course be great for future interoperability if the lowest-level 
document (X.509 FPDAM?) supported such feature.

Anders

Date: Fri, 12 Nov 1999 16:41:19 -0500
From: "Ella P. Gardner" <[email-masked]>
Organization: The MITRE Corporation
To: [email-masked]
Subject: dnQualifier

Folks:

I've been following with interest the discussion of the use of
dnQualifier and was happy to see that the group had agreed to use that
to disambiguate entities. I was also was glad to see that others support
the use of multiple attributes to form an RDN.

In the Allied Communication Publication 133 Task Force, the group that
makes agreements for directory support with our allies, we decided to
use dnQualifier. We realized that the meaning in X.521 is not exactly
what we need, but we preferred to use a standard attribute. We did not
want to use the unique identifier for the same reason others don't - the
bit string syntax.

So far we've been able to coordinate between PKIX documents and X.509 to
use standard attributes. Let's use dnQualifier. If that threatens world
peace, let's get a new definition into the X.509 FPDAM. 

Regards,
Ella

Date: Fri, 12 Nov 1999 15:45:24 -0500
To: [email-masked]
From: Stephen Kent <[email-masked]>
Subject: draft PKIX meeting minutes

--============_-1269682966==_ma============
Content-Type: text/plain; charset="us-ascii" ; format="flowed"

Folks,

The following minutes are submitted for review.  Please respond to me 
with comments and corrections, no later than 11/26, so that I can 
submit the revised minutes to the IETF secretariat in a timely fashio.

Steve
----------

PKIX WG Meeting 11/9+10/99
Edited by Steve Kent (WG co-chair)

The PKIX WG met twice during the 46th IETF and a total of 
approximately 285 individuals participated in these meetings over two 
days.

The meeting began with a review of the status of all of the WG document,
presented by Warwick Ford, WG co-chair. The following text summarizes the
status of the documents:

PKIX COMPLETED DOCUMENTS

PKIX Certificate/CRL Profile (RFC 2459)
		Approved as Proposed Standard
KEA Algorithms for Profile (RFC 2528)
		Approved as Informational RFC
HTTP/FTP Operations (RFC 2585)
		Approved as Proposed Standard
LDAP V2 Operational Protocols (RFC 2559)
		Approved as Proposed Standard
LDAP V2 Schema (RFC 2587)
		Approved as Proposed Standard
OCSP (RFC 2560)
		Approved as Proposed Standard
CMP (RFC 2510)
		Approved as Proposed Standard
CRMF (RFC 2511)
		Approved as Proposed Standard
Certificate Policy/Practices Guideline (RFC 2527)
		Approved as Informational RFC
CMC
		In IETF last call
Diffie-Hellman Proof of Possesion
		In IETF last call

PKIX WORK IN PROGRESS

Revised Profile (draft-ietf-pkix-new-part1-00.txt)
	Work underway

ECDSA Algorithms for Profile (draft-ietf-pkix-ipki-ecdsa-02.txt)
	Completed Wg last call and ready to forwarded to IESG

Qualified Certificates (draft-ietf-pkix-qc-02.txt)

PKIX Roadmap (draft-ietf-pkix-roadmap-04.txt)

Time Stamp (draft-ietf-pkix-time-stamp-04.txt)

Operational Protocols - LDAPv3 (draft-chadwick-pkixldap-v3-01.txt)

Attribute Certificate Profile for Authorization 
(draft-ietf-pkix-ac509prof-01.txt)

Limited Attribute Certificates (draft-ietf-pkix-laap-00.txt)

DCS (draft-ietf-pkix-dcs-03.txt)

Simple Certificate Validation Protocol (SCVP) (draft-ietf-pkix-scvp-01.txt)

OCSP Extensions (draft-ietf-pkix-ocspx-00.txt)

CMP over HTTP (draft-ietf-pkix-cmp-http-00.txt)

CMP over TCP (draft-ietf-pkix-cmp-tcp-00.txt)

X.509 (2000) STATUS (S. Boyen- Entrust)

FPDAM Copenhagen meeting update. Deadline for revisions to ITU-T/ISO 
is 11/20, in preparation for March 2000 ballot. 2000 version (but not 
1997 version), will adopt PKIX convention re basicConstraints. 1997 
and 2000 text will reflect PKIX definition of v2 CRLs (with no 
extensions). New extension: inhibitAnyPolicy. Several new LDAP schema 
object classes defined for PKI support. Defect reports for several 
items being processed now.  There will be a complete restructuring of 
the X.509 text, to improve it. Attribute certificate changes (v2) 
include removal of some overly complex features (cross domain and 
indirect delegation of privileges), and addition of object hash 
facilities, as a means of binding an AC to a PKC or a software 
module, etc. See slides for more details on this presentation.

REPORTS ON ESTABLISHED WORK ITEMS:

Revisions to RFC 2459 (T. Polk-NIST)
Most text unchanged from RFC; a number of typos were fixed. Major 
changes are new path certificate path and added CRL validation text. 
(Old text was incomplete, new version corrects several defects 
discovered and then fixed in ISO/ITU-T text.) Other significant 
changes include AIA extension clarifications and DisplayText changes, 
plus addition of new extension from X.509 (inhibitAnyPolicy). 
Question: can we progress to Draft, or must we cycle as Proposed? The 
WG Chairs will talk with the Security ADs re this issue. The list is 
requested to identify 2 independent implementations as part of 
progression to Draft status. Please respond to the WG Chairs re this 
issue. Tim will work to resolve an issue with regard to the proper 
OID to use with the DC attribute in DNs. (This is an issue because 
another IETF WG defined this OID, but didn't register it properly.) A 
suggestion was made to keep ECDSA document (WG last call done) 
separate. A suggestion was made to add text to clarify the use of the 
NR bit, but most of the discussion was deferred to the more general 
NR topic at the end of the agenda.

CA Key Compromise Recovery (D. Pinkas) Both Germany and Italy, in 
digital signature regulations, require some for of ancillary time 
stamping of certificates to provide a transition interval for 
transition to newly issued certificates for users of the CA whose key 
was compromised. Adoption of these sorts of techniques would require 
extension of the path validation algorithm to process these time 
stamps, when there was an indication of CA key compromise.  (This 
indication could be provided by having the CA revoke its self-signed 
certificate in a CRL that is signed using a separate CA key, or via 
OCSP responses signed using a separate key.) It is noted that this 
mechanism addresses the problem of the compromise of one key (a CA 
key) by adding a second signature (for a time stamp) under a separate 
key. It also is possible for a CA to use key splitting and thus 
achieve the same effect in a transparent fashion. It also was 
suggested that one could add an extension that is an independent 
signature of the PublicKeyInfo (and SubjectName?) fields, to achieve 
the same effect. See slides for more details on this presentation.

Qualified Certificates (S. Santesson)
Since Oslo meeting conducted WG last call, and as a result of the 
comments received, a new ID was published on 10/22.  Changes include 
fixes to some ASN.1 syntax, inclusion of two new Subject attributes 
(pseudonym and title), plus a qcStatements extension.  Ongoing 
discussion focuses on several topics: can two QCs be compared to 
determine whether the same person is represented (reword to warn 
about such comparisons, but don't prohibit them), inclusion of a 
static identifier (use dnQualifier), use of ISO 3166 trigraphs vs. 
digraphs (use digraphs), and a restructuring of the personal data 
field attributes (done). So, time for WG last call, on this revised 
ID. RFC 2459 will be modified to recommend (SHOULD) support for the 
pseudonym attribute. See slides for more details on this presentation.

OCSP Extensions (P. Baker-VeriSign)
Original protocol focuses on validation of one certificate, returns a 
signed response to a client for later use in NR, and allows for a 
per-use charging model. This proposal to extend OCSP to support path 
processing, while maintaining most of the syntactic basis of OCSP. It 
is noted that delegation of path processing does not necessarily 
indicate delegation of trust, if the protocol returns the data needed 
to verify what the server did to determine certificate validity. Note 
that certificate policy processing is target dependent, so offloading 
path validation requires that the client must pass data to the 
server, to parameterize validation, e.g., a URI. (Note that this 
reveals more info to the server that would be necessary if the client 
merely passed parameters that would have been sent across an API for 
local path processing.)  Ultimately, this presentation proposes using 
OCSPX as the protocol for interacting with an authorization server, 
and that one can use the returned tokens as part of an audit trail.

Audience questions/comments: in what contexts might this be used vs. 
existing standard protocols (e.g., TLS, IPsec, etc.), whether the 
OCSP syntax is suitable for this application (OCSP does not pass full 
certificates), how attribute certificates fit in, two expressions of 
support for path construction and validation but not necessarily 
authorization.

PKIX Roadmap (S. Turner-IECSA)
Two updates since last meeting, focus on attribute certificates and 
non-repudiation. More text will be added for trust models, DCVS, POP, 
etc.

Time Stamping Protocol (D. Pinkas-Bull)
Denis discussed the differences between version 2 and version 4. 
Major changes include: A time stamp format based on GeneralizedTime 
(which allows sub-second time) and an optional field that specifies 
the accuracy of the first field is now employed. The serial number is 
now mandatory, allowing unique identification of a timestamp from a 
TSA. TDA extensions have been removed, but a facility for extensions 
has been retained. TSAs no longer explicitly assert anything about 
the hash function being used. The format of the TSTInfo has changed, 
and is now simpler. From a legal standpoint, there is better reason 
to believe that we can now proceed with this work without 
encountering significant intellectual property issues. The patent 
infringement case filed by Surety against Entrust resulted in the 
first four claims of the (most general) Surety patent being declared 
invalid.  These claims covered the basic notions of time stamping as 
we perform it in the TSP.  Other patent claims may still be 
applicable to implementations of a "secure" TSA clock, or the way the 
time stamp is employed.  For example there is a patent on secure 
hardware implementation of a time stamp time source, and on the use 
of a time stamp to extent the lifetime of a certificate. The basic 
protocol patent issues seem to be resolved at this time, at least in 
the US patent system. See slides for more details on this 
presentation.

LDAPv3 Profile (D. Chadwick- University of Salford)
No presentation. Need to check on status of document re WG last call.

Attribute Certificates	(S. Farrell-SSE)
Latest version moved LAAP to a separate draft, removed concept of 
"restrictions," added new AC revocation options (e.g., "never revoke" 
for short-lived certificates) and adds support of linking to owner 
via a hash value (currently just a link to a public key, but could be 
broadened to be more general). The new version is simplified and all 
parts are mandatory to implement. Several syntax changes were made, 
to help manage creation of new extension. More syntax changes will be 
required to align with v2 X.509 ACs. Plan is to create a 03 version 
before the March IETF and progress to WG last call around that time. 
See slides for more details on this presentation.

A new protocol (LAAP) for AC acquisition is defined here.  It is 
currently encapsulated in CMP PKIMessage syntax. It is not a 
replacement for LDAP, but an alternative when one choose not to store 
ACs in a directory. The protocol is quite limited in scope, e.g., 
fetches just one AC. It is not designed to be a management protocol 
for ACs (could extend CMP/CMC for that purpose).  Fetches are keyed 
using strings, either matched against attribute certificate string 
values or against string representations of AC OIDs. A number of open 
issues remain to be resolved, e.g., appropriate encapsulation and 
transport protocols. See slides for more details on this presentation.

Revision of PKIX Part 4 (J. Rodriguez-IBM)
Major changes to chapters 3, 4 and 5 have been made. No changes are 
proposed for sections 1, 6, 7, and 8. Revisions to sections 2 and 5 
should be completed before the end of the month. Confusion over 
differences between a CPS and a certificate policy continues, with 
some coordination with ABA ISC. The glossary also needs work. 
Revisions to sections 4 and 3 are slated for completion by the end of 
the year.  Plan to go to last call before the March meeting.

OTHER TOPICS

CMP/CMC Interoperability Testing	(R. Moskowitz-ISSA & C. Adams-Entrust)
Experience with CMP testing workshops, involving 6 vendors, suggests 
some changes should be made to CMP. Most vendors implemented DSA, 
some RSA. Some changes are minor, e.g., default MAC for PKIProtection 
undefined. Major changes include a new Confirm message format and an 
overhaul mapping to various transport protocols (e.g., TCP and HTTP). 
Plan is to issue an ID with changes to RFC 2510 and to complete 
update by March meeting. Denial of service attacks will be better 
addressed by changes to accompanying text. The transport mapping 
discussion may be moved to a separate document. Question is whether 
the revised document can progress to Draft, given that the changes 
are mostly minor, or represent removal of material. The WG co-chairs 
need to contact the Security ADs to discuss the issue of document 
progression. Planning for CMC interoperability testing is now 
underway. See slides for more details on this presentation.

ETSI Electronic Signature Standard (D. Pinkas-Bull)
The intent is to align this technical work with an EU directive which 
is expected to be approved before the end of this year. The goal of 
this standard is to specify what is needed to provide digital 
signatures that are (legally) equivalent to a handwritten signature. 
The scope of this work includes product and service certification, as 
well as technical specifications for protocols and data formats in 
support of electronic signatures. This work assumes the use of 
qualified certificates. The URL for this document was posted to the 
PKIX list for comments. Signature policy is a new element of this 
work, and the policy must be represented in a machine-processable 
form. CMS is base syntax adopted here for signed data, with 
ASN.1-defined extensions to carry a variety of additional data 
necessary to create a non-repudiable transaction. Both CRLs and OCSP 
responses are supported. Two APIs are defined to support these data 
structures. See slides for more details on this presentation.

PKI Disclosure Statements (S. Santesson)
Paper developed with ABA ISC and International Chamber of Commerce 
(ICC). Not a substitute for a CPS or a certificate policy (CP). 
Focus is on most critical elements of a CPS or CP, to be deposited in 
a repository for retrieval by prospective relying parties. CPS and CP 
are too complex and thus there is a need for a simpler, standard 
format to represent the most critical data.  (This is analogous to 
what was required of PCAs in RFC 1422 for the PEM PKI.) First version 
posted to PKIX list today, but we need to decide whether this will 
become a PKIX work item. One lawyer who attends the ABA ISC meetings 
was surprised to hear about this ...

Null Signature Algorithm (A. Malpani-ValiCert)
Motivation in part is that some data structures have a signature as 
an optional feature. One can achieve this effect by making the 
signature an optional data structure; this proposal suggests another 
way to represent this, i.e., by using a NULL algorithm for 
signatures. It also is suggested that this would be useful for 
testing. Comments from the floor were strongly negative. A straw poll 
of the meeting attendees showed strong opposition to adoption of this 
algorithm, so it will be dropped from the work item list.

Jonah Status (M. Shanzer-Iris)
Implementation of RFC 2459, CMP, CRMF, and LDAP (but not CMC or 
OCSP). C++ with a Java GUI, on NT and Solaris. Includes a CA, RA, and 
a trivial end entity. Now uses Cylink toolkit for crypto, but will 
make use of BSAFE soon. Jonah is exportable, but the crypto toolkit 
is not. Tested against NIST, Baltimore, Entrust, Trustpoint and Xeti.

Technical Requirements for Non-repudiation (T. Gindin-IBM)
The document was motivated by the list discussion over the role of 
the NR bit and ancillary certificate and CRL data. Note that the 
services described here do not constitute a complete service for 
legal non-repudiation, but may provide a suitable technical basis for 
legal non-repudiation. An obvious question is how this relates to the 
ETSI work described by Denis?  Based on comments from the audience, 
Tom has decided to remove the legal references from the document, 
modify or delete the text related to the invalidityDate extension. 
The revised document will be issued as a PKIX ID, with the intent of 
publication as an informational RFC in the future. Slides may be 
available with more details on this presentation.

--============_-1269682966==_ma============
Content-Type: text/enriched; charset="us-ascii"

<bigger>Folks,

The following minutes are submitted for review.  Please respond to me
with comments and corrections, no later than 11/26, so that I can
submit the revised minutes to the IETF secretariat in a timely fashio.

Steve

----------

<fontfamily><param>Courier_New</param>PKIX WG Meeting 11/9+10/99 

Edited by Steve Kent (WG co-chair)

The PKIX WG met twice during the 46th IETF and a total of approximately
285 individuals participated in these meetings over two days. 

The meeting began with a review of the status of all of the WG
document, 

presented by Warwick Ford, WG co-chair. The following text summarizes
the 

status of the documents:

PKIX COMPLETED DOCUMENTS

PKIX Certificate/CRL Profile (RFC 2459)

		Approved as Proposed Standard

KEA Algorithms for Profile (RFC 2528)

		Approved as Informational RFC

HTTP/FTP Operations (RFC 2585)

		Approved as Proposed Standard 

LDAP V2 Operational Protocols (RFC 2559)

		Approved as Proposed Standard 

LDAP V2 Schema (RFC 2587)

		Approved as Proposed Standard 

OCSP (RFC 2560)

		Approved as Proposed Standard

CMP (RFC 2510)

		Approved as Proposed Standard

CRMF (RFC 2511)

		Approved as Proposed Standard

Certificate Policy/Practices Guideline (RFC 2527)

		Approved as Informational RFC

CMC

		In IETF last call

Diffie-Hellman Proof of Possesion

		In IETF last call

PKIX WORK IN PROGRESS

Revised Profile (draft-ietf-pkix-new-part1-00.txt)

	Work underway

ECDSA Algorithms for Profile (draft-ietf-pkix-ipki-ecdsa-02.txt)

	Completed Wg last call and ready to forwarded to IESG

Qualified Certificates (draft-ietf-pkix-qc-02.txt)

PKIX Roadmap (draft-ietf-pkix-roadmap-04.txt)

Time Stamp (draft-ietf-pkix-time-stamp-04.txt)

Operational Protocols - LDAPv3 (draft-chadwick-pkixldap-v3-01.txt)

Attribute Certificate Profile for Authorization
(draft-ietf-pkix-ac509prof-01.txt)

Limited Attribute Certificates (draft-ietf-pkix-laap-00.txt)

DCS (draft-ietf-pkix-dcs-03.txt)

Simple Certificate Validation Protocol (SCVP)
(draft-ietf-pkix-scvp-01.txt)

OCSP Extensions (draft-ietf-pkix-ocspx-00.txt)

CMP over HTTP (draft-ietf-pkix-cmp-http-00.txt)

CMP over TCP (draft-ietf-pkix-cmp-tcp-00.txt)

X.509 (2000) STATUS (S. Boyen- Entrust)

FPDAM Copenhagen meeting update. Deadline for revisions to ITU-T/ISO is
11/20, in preparation for March 2000 ballot. 2000 version (but not 1997
version), will adopt PKIX convention re basicConstraints. 1997 and 2000
text will reflect PKIX definition of v2 CRLs (with no extensions). New
extension: inhibitAnyPolicy. Several new LDAP schema object classes
defined for PKI support. Defect reports for several items being
processed now.  There will be a complete restructuring of the X.509
text, to improve it. Attribute certificate changes (v2) include removal
of some overly complex features (cross domain and indirect delegation
of privileges), and addition of object hash facilities, as a means of
binding an AC to a PKC or a software module, etc. See slides for more
details on this presentation.

REPORTS ON ESTABLISHED WORK ITEMS:

Revisions to RFC 2459 (T. Polk-NIST)

Most text unchanged from RFC; a number of typos were fixed. Major
changes are new path certificate path and added CRL validation text.
(Old text was incomplete, new version corrects several defects
discovered and then fixed in ISO/ITU-T text.) Other significant changes
include AIA extension clarifications and DisplayText changes, plus
addition of new extension from X.509 (inhibitAnyPolicy). Question: can
we progress to Draft, or must we cycle as Proposed? The WG Chairs will
talk with the Security ADs re this issue. The list is requested to
identify 2 independent implementations as part of progression to Draft
status. Please respond to the WG Chairs re this issue. Tim will work to
resolve an issue with regard to the proper OID to use with the DC
attribute in DNs. (This is an issue because another IETF WG defined
this OID, but didn't register it properly.) A suggestion was made to
keep ECDSA document (WG last call done) separate. A suggestion was made
to add text to clarify the use of the NR bit, but most of the
discussion was deferred to the more general NR topic at the end of the
agenda.

CA Key Compromise Recovery (D. Pinkas) Both Germany and Italy, in
digital signature regulations, require some for of ancillary time
stamping of certificates to provide a transition interval for
transition to newly issued certificates for users of the CA whose key
was compromised. Adoption of these sorts of techniques would require
extension of the path validation algorithm to process these time
stamps, when there was an indication of CA key compromise.  (This
indication could be provided by having the CA revoke its self-signed
certificate in a CRL that is signed using a separate CA key, or via
OCSP responses signed using a separate key.) It is noted that this
mechanism addresses the problem of the compromise of one key (a CA key)
by adding a second signature (for a time stamp) under a separate key.
It also is possible for a CA to use key splitting and thus achieve the
same effect in a transparent fashion. It also was suggested that one
could add an extension that is an independent signature of the
PublicKeyInfo (and SubjectName?) fields, to achieve the same effect.
See slides for more details on this presentation.

Qualified Certificates (S. Santesson)

Since Oslo meeting conducted WG last call, and as a result of the
comments received, a new ID was published on 10/22.  Changes include
fixes to some ASN.1 syntax, inclusion of two new Subject attributes
(pseudonym and title), plus a qcStatements extension.  Ongoing
discussion focuses on several topics: can two QCs be compared to
determine whether the same person is represented (reword to warn about
such comparisons, but don't prohibit them), inclusion of a static
identifier (use dnQualifier), use of ISO 3166 trigraphs vs. digraphs
(use digraphs), and a restructuring of the personal data field
attributes (done). So, time for WG last call, on this revised ID. RFC
2459 will be modified to recommend (SHOULD) support for the pseudonym
attribute. See slides for more details on this presentation. 

OCSP Extensions (P. Baker-VeriSign)

Original protocol focuses on validation of one certificate, returns a
signed response to a client for later use in NR, and allows for a
per-use charging model. This proposal to extend OCSP to support path
processing, while maintaining most of the syntactic basis of OCSP. It
is noted that delegation of path processing does not necessarily
indicate delegation of trust, if the protocol returns the data needed
to verify what the server did to determine certificate validity. Note
that certificate policy processing is target dependent, so offloading
path validation requires that the client must pass data to the server,
to parameterize validation, e.g., a URI. (Note that this reveals more
info to the server that would be necessary if the client merely passed
parameters that would have been sent across an API for local path
processing.)  Ultimately, this presentation proposes using OCSPX as the
protocol for interacting with an authorization server, and that one can
use the returned tokens as part of an audit trail.

Audience questions/comments: in what contexts might this be used vs.
existing standard protocols (e.g., TLS, IPsec, etc.), whether the OCSP
syntax is suitable for this application (OCSP does not pass full
certificates), how attribute certificates fit in, two expressions of
support for path construction and validation but not necessarily
authorization.

PKIX Roadmap (S. Turner-IECSA)

Two updates since last meeting, focus on attribute certificates and
non-repudiation. More text will be added for trust models, DCVS, POP,
etc. 

Time Stamping Protocol (D. Pinkas-Bull)

Denis discussed the differences between version 2 and version 4. Major
changes include: A time stamp format based on GeneralizedTime (which
allows sub-second time) and an optional field that specifies the
accuracy of the first field is now employed. The serial number is now
mandatory, allowing unique identification of a timestamp from a TSA.
TDA extensions have been removed, but a facility for extensions has
been retained. TSAs no longer explicitly assert anything about the hash
function being used. The format of the TSTInfo has changed, and is now
simpler. From a legal standpoint, there is better reason to believe
that we can now proceed with this work without encountering significant
intellectual property issues. The patent infringement case filed by
Surety against Entrust resulted in the first four claims of the (most
general) Surety patent being declared invalid.  These claims covered
the basic notions of time stamping as we perform it in the TSP.  Other
patent claims may still be applicable to implementations of a "secure"
TSA clock, or the way the time stamp is employed.  For example there is
a patent on secure hardware implementation of a time stamp time source,
and on the use of a time stamp to extent the lifetime of a certificate.
The basic protocol patent issues seem to be resolved at this time, at
least in the US patent system. See slides for more details on this
presentation.

LDAPv3 Profile (D. Chadwick- University of Salford)

No presentation. Need to check on status of document re WG last call.

Attribute Certificates	(S. Farrell-SSE)

Latest version moved LAAP to a separate draft, removed concept of
"restrictions," added new AC revocation options (e.g., "never revoke"
for short-lived certificates) and adds support of linking to owner via
a hash value (currently just a link to a public key, but could be
broadened to be more general). The new version is simplified and all
parts are mandatory to implement. Several syntax changes were made, to
help manage creation of new extension. More syntax changes will be
required to align with v2 X.509 ACs. Plan is to create a 03 version
before the March IETF and progress to WG last call around that time.
See slides for more details on this presentation.

A new protocol (LAAP) for AC acquisition is defined here.  It is
currently encapsulated in CMP PKIMessage syntax. It is not a
replacement for LDAP, but an alternative when one choose not to store
ACs in a directory. The protocol is quite limited in scope, e.g.,
fetches just one AC. It is not designed to be a management protocol for
ACs (could extend CMP/CMC for that purpose).  Fetches are keyed using
strings, either matched against attribute certificate string values or
against string representations of AC OIDs. A number of open issues
remain to be resolved, e.g., appropriate encapsulation and transport
protocols. See slides for more details on this presentation.

Revision of PKIX Part 4 (J. Rodriguez-IBM)

Major changes to chapters 3, 4 and 5 have been made. No changes are
proposed for sections 1, 6, 7, and 8. Revisions to sections 2 and 5
should be completed before the end of the month. Confusion over
differences between a CPS and a certificate policy continues, with some
coordination with ABA ISC. The glossary also needs work. Revisions to
sections 4 and 3 are slated for completion by the end of the year. 
Plan to go to last call before the March meeting.

OTHER TOPICS

CMP/CMC Interoperability Testing	(R. Moskowitz-ISSA & C.
Adams-Entrust)

Experience with CMP testing workshops, involving 6 vendors, suggests
some changes should be made to CMP. Most vendors implemented DSA, some
RSA. Some changes are minor, e.g., default MAC for PKIProtection
undefined. Major changes include a new Confirm message format and an
overhaul mapping to various transport protocols (e.g., TCP and HTTP).
Plan is to issue an ID with changes to RFC 2510 and to complete update
by March meeting. Denial of service attacks will be better addressed by
changes to accompanying text. The transport mapping discussion may be
moved to a separate document. Question is whether the revised document
can progress to Draft, given that the changes are mostly minor, or
represent removal of material. The WG co-chairs need to contact the
Security ADs to discuss the issue of document progression. Planning for
CMC interoperability testing is now underway. See slides for more
details on this presentation.

ETSI Electronic Signature Standard (D. Pinkas-Bull)

The intent is to align this technical work with an EU directive which
is expected to be approved before the end of this year. The goal of
this standard is to specify what is needed to provide digital
signatures that are (legally) equivalent to a handwritten signature.
The scope of this work includes product and service certification, as
well as technical specifications for protocols and data formats in
support of electronic signatures. This work assumes the use of
qualified certificates. The URL for this document was posted to the
PKIX list for comments. Signature policy is a new element of this work,
and the policy must be represented in a machine-processable form. CMS
is base syntax adopted here for signed data, with ASN.1-defined
extensions to carry a variety of additional data necessary to create a
non-repudiable transaction. Both CRLs and OCSP responses are supported.
Two APIs are defined to support these data structures. See slides for
more details on this presentation.

PKI Disclosure Statements (S. Santesson)

Paper developed with ABA ISC and International Chamber of Commerce
(ICC). Not a substitute for a CPS or a certificate policy (CP).  Focus
is on most critical elements of a CPS or CP, to be deposited in a
repository for retrieval by prospective relying parties. CPS and CP are
too complex and thus there is a need for a simpler, standard format to
represent the most critical data.  (This is analogous to what was
required of PCAs in RFC 1422 for the PEM PKI.) First version posted to
PKIX list today, but we need to decide whether this will become a PKIX
work item. One lawyer who attends the ABA ISC meetings was surprised to
hear about this ...

Null Signature Algorithm (A. Malpani-ValiCert)

Motivation in part is that some data structures have a signature as an
optional feature. One can achieve this effect by making the signature
an optional data structure; this proposal suggests another way to
represent this, i.e., by using a NULL algorithm for signatures. It also
is suggested that this would be useful for testing. Comments from the
floor were strongly negative. A straw poll of the meeting attendees
showed strong opposition to adoption of this algorithm, so it will be
dropped from the work item list.

Jonah Status (M. Shanzer-Iris)

Implementation of RFC 2459, CMP, CRMF, and LDAP (but not CMC or OCSP).
C++ with a Java GUI, on NT and Solaris. Includes a CA, RA, and a
trivial end entity. Now uses Cylink toolkit for crypto, but will make
use of BSAFE soon. Jonah is exportable, but the crypto toolkit is not.
Tested against NIST, Baltimore, Entrust, Trustpoint and Xeti.

Technical Requirements for Non-repudiation (T. Gindin-IBM)

The document was motivated by the list discussion over the role of the
NR bit and ancillary certificate and CRL data. Note that the services
described here do not constitute a complete service for legal
non-repudiation, but may provide a suitable technical basis for legal
non-repudiation. An obvious question is how this relates to the ETSI
work described by Denis?  Based on comments from the audience, Tom has
decided to remove the legal references from the document, modify or
delete the text related to the invalidityDate extension.  The revised
document will be issued as a PKIX ID, with the intent of publication as
an informational RFC in the future. Slides may be available with more
details on this presentation. 
</fontfamily></bigger>

--============_-1269682966==_ma============--

From: Anders Rundgren <[email-masked]>
To: "[email-masked]" <[email-masked]>, "'David P. Kemp'" <[email-masked]>
Subject: RE: Use of dnQualifier in the QC profile
Date: Fri, 12 Nov 1999 19:18:47 +0100

Hi David,

<snip>

>Having this
>uniqueness and staticness property depend on a property semantics OID
>and the existence of a qcStatements extension is ridiculously complex
>compared to just profiling an attribute which has the desired
>semantics.

>Thus the answer to 3) is a clear YES :-).

Seems that we agree on this.

What do you think about my statement that this feature is really needed in son-of-2459 as well

Anders

Date: Fri, 12 Nov 1999 11:44:01 -0500 (EST)
From: "David P. Kemp" <[email-masked]>
Reply-To: "David P. Kemp" <[email-masked]>
Subject: Re: Use of dnQualifier in the QC profile
To: [email-masked]
Content-MD5: ThtX2DDHjmONt6t9+Bgyxg==

Stefan,

  I agree that these are the questions that need to be answered, and
would add a fourth:

  4) Should the unique/static identifier require directory and application
support for multi-value RDNs or can it be used in a single-value RDN?

I don't believe that consensus has yet been reached on the answers.

We do have consensus that the unique/static identifier should
have syntax PrintableString (not BITSTRING or NumericString), so
X.520 uniqueIdentifier {id-at 45} is excluded from consideration.

I agree that the answer to 1) is YES.

I agree that the answer to 2) is NO, because that would be a
redefinition (not just a profiling) of the X.520 semantics.

If we cannot require dnQualifier to contain a unique value, then I
believe that it cannot satisfy the requirement for a permanent/unique
"employee/student/customer identifier", because such an identifier is
by definition independent of the entity's Common Name and must continue
to be valid when a given entity's Common Name changes.  Saying that the
chosen attribute MAY be a unique identifier for the subject is not
sufficient, because applications then have no choice but to assume that
it also MIGHT NOT be a unique identifier for the subject.  Having this
uniqueness and staticness property depend on a property semantics OID
and the existence of a qcStatements extension is ridiculously complex
compared to just profiling an attribute which has the desired
semantics.

Thus the answer to 3) is a clear YES :-).

I don't have any particular preference for which attribute should be
used, although I believe a strong case can be made for serialNumber
{id-at 5}.  X.520 uses the word "object" for entities:

  "Unique Identifier ... used to distingush between object references ..."
  
  "... geographical positions or regions with which objects are associated."
  
  etc.

Thus little violence would be done to the spirit of X.520 if the
definition were changed from "the serial number of a device" to
"the serial number of an object".  Serial number is a PrintableString,
and it has, unlike dnQualifier, an upper bound.  A case could also be
made to define the name "staticIdentifier" as a synonym for {id-at 5},
to refer to identifiers which are not numbers issued in a series.

Alternatively, we could use "uniqueIdentifier"
{0 9 2342 19200300 100 1 44} defined in RFC 1274, which predates but
is not superseded by RFC 2459.  Disadvantages are: 1) the OID is bigger,
and 2) the name could be confused with {id-at 45}.

With regard to question 4, the directory experts will have to answer
whether a certificate with the DN

   "C=US, O=Foo.com, SID=123456, CN=Fred Smith"
   
MUST be stored in a directory entry 4 levels deep, or whether it MAY
legitimately be stored in a directory having only 3 levels.

The answer to that question will determine whether support for
multi-valued RDNs (SID+CN) is needed, or whether single-valued RDNs
(SID, CN) are acceptable.  I don't care either way, as long as
application developers can count on the fact that the SID attribute is
required to be static and unique.

Dave Kemp

> Date: Thu, 11 Nov 1999 17:13:18 -0500
> To: <[email-masked]>
> From: Stefan Santesson <[email-masked]>
> Subject: Use of dnQualifier in the QC profile
> 
> Here is the latest conclusions regarding use of dnQualifier and support for
> "unique/static identifiers"
> 
> There are three issues.
> 
> 1) Can dnQualifier be used as proposed (to hold a disambiguating value, which
> MAY be a unique identifier for the subject) ?
> 
> 2) Should we define that dnQualifier, when used, shall contain a unique value
> for each subject subscribing to the CA. ?
> 
> 3) Should we define any new attribute or extension for static/unique
> identifiers.
> 
> In issue 1, the answer i YES. dnQualifier can be used in this way. James 
Manger
> suggest another view, but no person here in Washington who I have spoken to,
> who have had a clear opinion on this, agrees with James. I assume that there
> will be a discussion on the list regarding this, but until that concludes into
> any other result, I will assume that we are compatible with X.520
> 
> In issue 2 the answer is NO. We have to allow the standard X.520 use of this
> attribute, as in RFC2459. This does however not mean that the dnQualifier 
can't
> be used to hold a unique value for each subject, since this provides the
> required disambiguating function. 
> 
> And if this is the case and a CA want to indicate this in the certificate, 
then
> the way to do it is to assign an attribute semantics OID in the qcStatements
> extension, defining this semantic property.
> 
> This is not different from the way a CA can indicate the type of value hold in
> this or any other attribute (i.e. locally defined number, SSN, drivers 
licence,
> civic registration number, etc).
> 
> Issue 3 is a clear NO. We already have dnQualifier covering this as stated
> above. Assigning new attributes is not a desired path.
> 
> 
> These solutions reflects the consensus I have experienced from many 
discussions
> this week, including discussions with the authors of RFC 2459.
> 
> 
> /Stefan
>  
> 
> 

From: Farrukh Ahmad <[email-masked]>
To: [email-masked]
Subject: RE: Model PKI Disclosure Statement (PDS)
Date: Fri, 12 Nov 1999 13:18:15 -0000
Importance: low

There definitely is confusion about the whole of the CP/CPS issue and how it
fits with other legal instruments. Will the PDS have any legal bearing - and
will it be a replacement for T&Cs in an open PKI where such things may not
exist?

Farrukh 

-----Original Message-----
From: Stefan Santesson [mailto:[email-masked]]
Sent: 11 November 1999 01:09
To: [email-masked]
Subject: Model PKI Disclosure Statement (PDS)

All,

A first preliminary draft of the model PKI disclosure statement (PDS), as
presented during the Washington PKIX session, is now available.

The document can be downloaded from: 
http://www.accurata.se/pds/dok/draft-ietf-xxx-pds-00_prel.txt

It should be noted that this document has ben developed in cooperation with
members of the ICC (International Chamber of Commerce) and ABA (American Bar
Association).

The purpose of posting this document to the list is to obtain comments and
to
determine if this should be adopted as a PKIX work item.

/Stefan

Date: Fri, 12 Nov 1999 09:12:32 +0100
From: Bernard Hervault <[email-masked]>
Reply-To: [email-masked]
Organization: Etiam
To: "[email-masked]" <[email-masked]>
Subject: Unsubscribe

unsubscribe

--
______________________________________________________
Bernard Hervault - Email: <[email-masked]>
ETIAM "Cooperative medical imaging products"
20 rue du Pr.  Jean PECKER - 35000 RENNES - France -
Tel: (+33) 02 99 14 33 88 - Fax: (+33) 02 99 14 33 80
Web:  http://www.etiam.com
______________________________________________________

Reply-To: <[email-masked]>
From: "Kirby Russell" <[email-masked]>
To: <[email-masked]>
Date: Thu, 11 Nov 1999 21:55:38 -0800
Importance: Normal

unsubscribe

From: "Anders Rundgren" <[email-masked]>
To: "Stefan Santesson" <[email-masked]>, <[email-masked]>
Cc: "Warwick Ford" <[email-masked]>
Subject: Use of dnQualifier in QC/2459   {Re: Use of dnQualifier in the QC profile}
Date: Fri, 12 Nov 1999 05:26:45 -0000

>Here is the latest conclusions regarding use of dnQualifier and support for
>"unique/static identifiers"
>
>1) Can dnQualifier be used as proposed (to hold a disambiguating value, which
>MAY be a unique identifier for the subject) ?

<snip>

>And if this is the case and a CA want to indicate this in the certificate, then
>the way to do it is to assign an attribute semantics OID in the qcStatements
>extension, defining this semantic property.

<snip>

>These solutions reflects the consensus I have experienced from many discussions
>this week, including discussions with the authors of RFC 2459.

Stefan,
Does this indicate that the authors of RFC 2459 believe that this issue is entirely QC-specific?

I think this conclusion is utterly wrong.   Vitnessed by for example VeriSign's/Execellerate's DUNS certificates.

This short-term solution works but does not solve the problem which is actually is buried in RFC2459.

Anders

Date: Thu, 11 Nov 1999 21:50:18 -0500
To: [email-masked]
From: Stefan Santesson <[email-masked]>
Subject: Re: Use of dnQualifier in the QC profile
Cc: [email-masked]

Tom,

The fact that the UID is a bit string is the reason it can't be used with
success.

What we want to store here is a displayable identifier. The fact that UID is a
bit string makes it impossible for a client to know how to display this
information unless additional information re character encoding is provided by
other means.

We originally tried to implement this in Scandinavia, carrying an ISO 8859-1
coded identifier. This proved to be a really nasty solution that we had to
abandon after encountering problems in almost every possible way.

So I really would argue against the UID.

Our next step in the SEIS project was to use the serial number. This works
technically well but the use of this attribute does definitely expand the
originally intent behind the attribute (serial number on a DEVICE). In addition
serial number is not supported by RFC 2459.

So this made us choose the dnQualifier for the QC profile.

So I hope that we can agree on this, or otherwise we will have to consider
inventing a new attribute :-(

/Stefan

At 18:02 1999-11-11 -0500, [email-masked] wrote:
>     Should we encourage the use of the UniqueIdentifier attribute from
>X.520 section 5.2.7 (OID 2.5.4.45) instead of DNQualifier for closer
>conformance to X.520?  Unfortunately it is a bit string, and its definition
>is not ideal for this purpose, as follows:   "The Unique Identifier
>attribute type specifies an identifier which may be used to distinguish
>between object references when a distinguished name has been reused. It may
>be, for example, an encoded object identifier, certificate, date,
>timestamp, or some other form of certification on the validity of the
>distinguished name."  It's the only attribute I can find whose definition
>is closer to the desired one than the dnQualifier definition - if anybody
>else knows of a better alternative (not necessarily from the ITU series),
>please say so.
>
>          Tom Gindin

From: [email-masked]
To: Stefan Santesson <[email-masked]>
cc: [email-masked]
Date: Thu, 11 Nov 1999 18:02:45 -0500
Subject: Re: Use of dnQualifier in the QC profile

     Should we encourage the use of the UniqueIdentifier attribute from
X.520 section 5.2.7 (OID 2.5.4.45) instead of DNQualifier for closer
conformance to X.520?  Unfortunately it is a bit string, and its definition
is not ideal for this purpose, as follows:   "The Unique Identifier
attribute type specifies an identifier which may be used to distinguish
between object references when a distinguished name has been reused. It may
be, for example, an encoded object identifier, certificate, date,
timestamp, or some other form of certification on the validity of the
distinguished name."  It's the only attribute I can find whose definition
is closer to the desired one than the dnQualifier definition - if anybody
else knows of a better alternative (not necessarily from the ITU series),
please say so.

          Tom Gindin

Date: Thu, 11 Nov 1999 15:51:33 -0700
From: "Bob Jueneman" <[email-masked]>
To: <[email-masked]>, <[email-masked]>
Subject: Re: Update of the QC personalData issue

Ironically, the subjectAltNames are MORE likely to be globally unique
than the DN.

Because the directory that the DN is likely to be drawn from or stored into
is not likely to be globally replicated and synchronized, it is entirely 
likely that there will be two end-entities with the same names in two different
directories, unless a randomized disambiguator is used that is large enough as to 
make a collision very unlikely.

On the other hand, most of the subjectAltNames are likely to include 
an e-mail address, a full organizational or geopolitical X.500 name, etc.,
and so those in all likelihood WILL be unique.

But not guaranteed, of course.

Bob

>>> Marc Branchaud <[email-masked]> 11/11/99 03:16PM >>>

On Wed, 10 Nov 1999, Stefan Santesson wrote:
> 
> The problem with subjectAltName extension though is that included names
> have to be unique.

Just so I'm sure, this is a QC-specific requirement, right?  I don't
recall anything about subjectAltName per se that mandates unique altNames.

		Marc

Date: Thu, 11 Nov 1999 14:16:05 -0800 (PST)
From: Marc Branchaud <[email-masked]>
To: [email-masked]
Subject: Re: Update of the QC personalData issue

On Wed, 10 Nov 1999, Stefan Santesson wrote:
> 
> The problem with subjectAltName extension though is that included names
> have to be unique.

Just so I'm sure, this is a QC-specific requirement, right?  I don't
recall anything about subjectAltName per se that mandates unique altNames.

		Marc

Date: Thu, 11 Nov 1999 17:13:18 -0500
To: <[email-masked]>
From: Stefan Santesson <[email-masked]>
Subject: Use of dnQualifier in the QC profile

Here is the latest conclusions regarding use of dnQualifier and support for
"unique/static identifiers"

There are three issues.

1) Can dnQualifier be used as proposed (to hold a disambiguating value, which
MAY be a unique identifier for the subject) ?

2) Should we define that dnQualifier, when used, shall contain a unique value
for each subject subscribing to the CA. ?

3) Should we define any new attribute or extension for static/unique
identifiers.

In issue 1, the answer i YES. dnQualifier can be used in this way. James Manger
suggest another view, but no person here in Washington who I have spoken to,
who have had a clear opinion on this, agrees with James. I assume that there
will be a discussion on the list regarding this, but until that concludes into
any other result, I will assume that we are compatible with X.520

In issue 2 the answer is NO. We have to allow the standard X.520 use of this
attribute, as in RFC2459. This does however not mean that the dnQualifier can't
be used to hold a unique value for each subject, since this provides the
required disambiguating function. 

And if this is the case and a CA want to indicate this in the certificate, then
the way to do it is to assign an attribute semantics OID in the qcStatements
extension, defining this semantic property.

This is not different from the way a CA can indicate the type of value hold in
this or any other attribute (i.e. locally defined number, SSN, drivers licence,
civic registration number, etc).

Issue 3 is a clear NO. We already have dnQualifier covering this as stated
above. Assigning new attributes is not a desired path.

These solutions reflects the consensus I have experienced from many discussions
this week, including discussions with the authors of RFC 2459.

/Stefan

Date: Thu, 11 Nov 1999 16:06:27 -0500
From: Sean Turner <[email-masked]>
Organization: IECA, Inc.
To: "Manger, James" <[email-masked]>
CC: [email-masked], "Kesterson, Hoyt" <[email-masked]>, Stefan Santesson <[email-masked]>
Subject: Re: dnQualifier is used incorrectly

James,

I disagree (with the part about the same dNQualifier must be used in the DSA in
every entry).  Say there are two DSAs.  The first DSA has an entries for Alice
and Bob.  The second DSA has entries for Alice (a different Alice than the one
on the first DSA) and Pat.  What X.520 says is that the different entries for
the two Alices on the DSAs use different dNQualifier values to disambiguate the
entries (you can use anything in the printableString just as long as they
disambiguate the entries).  Secondly, if the entry for either of the Alices uses
a dNQualifier it must be the same value in that particular entry (i.e., if
Alice's entries on the frist DSA use dNQualifier they must all have the same
value).

spt

"Manger, James" wrote:

> It is inappropriate to hold an employee/member/customer number as a
> dnQualifier attribute value.  When multiple directories each have an entry
> for the same person (or entity) the DN Qualifier disambiguates the entries.
> A DN Qualifier value indicates which directory a DN refers to, not which
> person in a directory.  In fact, the definition of DN Qualifier says the
> same value should be used for all entries in a given directory.  Mapping
> from directories to CAs, it is clear that the DN Qualifier should
> disambiguate certificates issued to the same person by different CAs.  The
> same DN Qualifier value should be used in all certificates issued by a given
> CA.  The DN Qualifier should identify the CA, not the subject.
>
> Example:
> A company, Frottleby Limited, is certified by two CAs.
> The TrustMe CA certifies Frottleby Limited using a DN:
>         { c "AU" / o "Frottleby Limited" dnQualifier "TrustMe Customer" }
> The SuperID CA certifies Frottleby Limited using a DN:
>         { c "AU" / o "Frottleby Limited" dnQualifier "SuperID" }
>
> Stephen & Stefan's quotes below are completely at odds with the original, &
> surely definitive, X.520 definition of the DN Qualifier attribute.
>
> Stephen Kent says, in 'Re: QC UID support must depart from RFC2459',
>
>         "..I believe that the DN Qualifier makes more sense as a component
> of a terminal RDN, at least from the standpoint of directory schema. I would
> also suggest that this is the most appropriate attribute as a means of
> expressing employee ID, payroll number, etc.  After all, these numbers were
> assigned in the pre-X.500 world to achieve the analogous effect, i.e., to
> disambiguate among database entries that might otherwise be identical."
>
> Stefan Santesson says,
>
>         "- Attributes for expressing a private identity (... dnQualifier)
> ...  Here the use of dnQualifier will be constrained to hold a unique
> identifier of the subject within the set of all certificates issued by a
> CA."
>
> >From X.520 | ISO/IEC 9594-6: 1993:
>
> 5.2.8 DN Qualifier
> The DN Qualifier attribute type specifies disambiguating information to add
> to the relative distinguished name of an entry.  It is intended to be used
> for entries held in multiple DSAs which would otherwise have the same name,
> and that its value be the same in a given DSA for all entries to which this
> information has been added.
>
> [DSA = Directory System Agent, basically a directory server]
>
>   ------------------------------------------------------------------------
>
>    Part 1.2    Type: application/ms-tnef
>            Encoding: base64

From: [email-masked]
To: [email-masked]
Date: Thu, 11 Nov 1999 09:01:04 -0500
Subject: unsubscribe

unsubscribe

From: "Andy Dowling" <[email-masked]>
To: "Stephen Farrell (Baltimore)" <[email-masked]>, "Russell Housley" <[email-masked]>
Cc: <[email-masked]>
Subject: Policy Authority Control
Date: Thu, 11 Nov 1999 12:20:23 -0000

Hi Folks,

Just a note about the use of PolicyAuthority (PA) in the IETFAttrSyntax.
At present, it seems possible for a badly-behaved AA to issue attributes
using an arbitrary PA. Whilst the issuing of attributes is controlled via
the AAControls
extension, the issuing of attributes from a specified PA is not controlled.

Perhaps including PA controls in the AAControls PKC extension would provide
a solution.
(This obviously depends on whether the AAControls mechanism is going to stay
or not)

Something along the lines of...

AAControls ::= SEQUENCE {
   pathLenConstraint...
   permittedAttrs...
   excludedAttrs...
   permitUnspecified...
   pAControls PAControls OPTIONAL
}

PAControls ::= SEQUENCE {
    permittedPAs [0]          GeneralNames OPTIONAL,
    excludedPAs  [1]          GeneralNames OPTIONAL,
    permitUnspecifiedPA  BOOLEAN DEFAULT TRUE,
}

It seems logical enough to place the PA controls in the AA controls
extension
(they serve very similar purposes). I don't need the need for placing it in
a separate
extension?? If PAControls is omitted from the AAControls extension, then an
AA can
claim to issue attributes for any PA.

Any comments would be appreciated.

Thanks,

Andy

-----
Andy Dowling
IT Security Consultant
SSE (A Siemens Company)
Fitzwilliam Court, Leeson Close,
Dublin 2, Ireland

E-Mail:  [email-masked]
Web: http://www.sse.ie
Phone: +353 1 216 2021
Fax:   +353 1 216 2082

From: "Andy Dowling" <[email-masked]>
To: <[email-masked]>
Cc: "Stephen Farrell (Baltimore)" <[email-masked]>
Subject: AC ASN.1
Date: Thu, 11 Nov 1999 09:13:28 -0000

Hi Folks,

Just looking at the "Owner" and "Issuer" fields of the AC as defined in
the latest ac509prof-01 and X.509 FPDAM v6...

The encodings have changed from a CHOICE
(baseCertId, entityName, and objectDigestInfo for Owner
and issuerName, baseCertId for Issuer)

to a SEQUENCE of three OPTIONALs.

What was the reason for this? From the ASN.1, it's now possible to have
BOTH baseCertId/entityName for the owner (plus other combinations).
The same applies to the "Issuer" field.
Is there a restriction to say that only one OPTIONAL must be used, and if
not,
shouldn't one be put in there?

Any info on this would be great.

Thanks,

Andy

-----
Andy Dowling
IT Security Consultant
SSE (A Siemens Company)
Fitzwilliam Court, Leeson Close,
Dublin 2, Ireland

E-Mail:  [email-masked]
Web: http://www.sse.ie
Phone: +353 1 216 2021
Fax:   +353 1 216 2082

From: "Andy Dowling" <[email-masked]>
To: <[email-masked]>
Cc: <[email-masked]>, <[email-masked]>, "xme" <[email-masked]>
Subject: Re: LAAP performance issues
Date: Thu, 11 Nov 1999 09:00:01 -0000

>
> Hi Andy,
>
> > 1. Batch LAAP requests.
>
> Rather not, unless there's strong concensus. Remember that the
> "L" in LAAP is for Limited. I expect that, in time, we'll have
> a CMP/CMC equivalent which can handle this.

This could also prove useful in cases where AC chaining is used (if the idea
sticks).
(i.e. the LRQ makes a single LAAP request for an entire AC chain for
verification)
Although this does assume that a single LRP can provide an entire AC chain,
this
may be the case in some environments (corporate VPN).

Could be worth thinking about...

Regards,

Andy

From: Anders Rundgren <[email-masked]>
To: "[email-masked]" <[email-masked]>, "'Stefan Santesson'" <[email-masked]>, "'Warwick Ford'" <[email-masked]>
Cc: =?iso-8859-1?Q?=27Magnus_Nystr=F6m=27?= <[email-masked]>
Subject: QC/Son-of-2459  "key-container-info"
Date: Thu, 11 Nov 1999 09:16:44 +0100

All,
This is a continuation of my Container-ID request for QC.

What it is really about is a structured attribute or extension for identifying the private
key container associated with the certificate in question.  Type and identity.

To me this looks like a general-purpose feature applicable on all kind
of public key certificates.

It will be important not only for smart-card based keys, but for soft keys, and
for server-based hardware-based key-stores like Ncipher.  The latter will
BTW make schemes like "Thin PKI" fly with greatly improved safety on board.

Conclusion: I think this should not only be in QC but in son-of-2459.

Anders

----------
From:  Stefan Santesson [SMTP:[email-masked]]
Sent:  Wednesday, November 03, 1999 10:36
To:  Anders Rundgren; [email-masked]; 'SEIS-List'
Subject:  SEIS:  Re: QC Container-ID (card serial)

--- Message on the SEIS mailing list ([email-masked])

Anders,

Lets agree to the fact that a container ID shouldn't be part of the
subjects name.

So if you want to express something about where the private key is stored
(which could be valuable information in some cases), then I suggest that
you use the qcStatataments extension.

You could define a statement saying "The private key associated with this
certificate is protected within a Smart Card that meets requirements
defined by FIPS xxxx ....."

Then you could add qualifying information expressing the ID of the
container (chip serial number or card serial number or what ever).

And then you are all set.

I will in fact suggest to the European standardization process that a
similar qcStatement should be defined as a response to the ES-directive.
This statement would state that the private key is contained in a secure
signature creation device according to the ES-directive Annex III.

/Stefan

At 07:54 AM 11/3/99 +0000, Anders Rundgren wrote:
>Sorry for bringing this up again but I have not received an answer yet.
>
>
>It is likely that a large part of future QCs will be put in smart cards, be it
>descrete credit-card-sized cards, SIM/WIM cards, or Java Rings etc.
>
>These physical containers always have a serial number or similar that
>I think should be possible to specify in QCs (using a pre-defined identifier)
>to be able to track which container that was used for generating a digital 
>signature.
>
>Please....
>
>Anders

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

----------------- SEIS mailing list ([email-masked])
Info about this list: http://www.nc-forum.com/seis
SEIS Contact: [email-masked]

From: "Anders Rundgren" <[email-masked]>
To: "Stefan Santesson" <[email-masked]>, <[email-masked]>
Cc: "Magnus (RSA)" <[email-masked]>, "Warwick Ford" <[email-masked]>
Subject: Static Identifiers {Re: Update of the QC personalData issue}
Date: Thu, 11 Nov 1999 07:48:57 -0000

Stefan,
you wanted comments on the static identifiers.
Here are the votes from the Uppsala  :-)

>One way to go here is that an appropriate attributeSemantics OID may provide
>the definition that the dnQualifier attribute is populated with a value that
>have this property, i.e. to be a unique static identifier of the certified
>subject.

This works. I can accept it although it is has a certain 'patch'-like flavor.

But the CLEAN and MEAN solution however is to make a brand new
attribute or extension with implicit semantics and a restricted syntax (for
reasons mentioned in earlier postings).   But this thing really also belongs to
son-of-2459 that needs to readdress the UID stuff.  Synchronization required!

>An alternative could be to define that dnQualifier in QC always MUST contain a
>unique value for the subject (within the set of all certificates issued by a
>CA)

As noted by others this is a redefinition of an existing attribute.  No good IMO.

Anders

Date: Wed, 10 Nov 1999 20:33:29 -0800
From: Ed Gerck <[email-masked]>
To: "[email-masked]" <[email-masked]>
Subject: Re: Model PKI Disclosure Statement (PDS)

Stefan:

Redundancy in information is usually a source of collision and also
invites different interpretations. So, I am not convinced that the PDS is
as useful as it proposes to be, by its own arguments, and it may make
matters worse -- in case of a collision, what is authoritative? The PDS or the
CPS?  If the CPS (as it should be) then there is no reason to even read the
PDS -- so, I see that confusion and user's workload would *increase* with
the PDS, not decrease.

My second comment is that the draft does not seem neutral. Besides its stated
purpose (to be inserted as a particular initiative by ICC, "ETERMS"),
it declares: "anticipated to often include a reference to the ICC's
arbitration services".  So, this RFC looks like (though it may not be, but
please recall Caesar's comment about his wife) a placeholder for a particular
commercial initiative for selling arbitration services by a particular company
(the ICC).  This may also explain the rather terse format proposed for the
PDS, which seems to conform to a template with standard fields like "refund
policy", for example. And, why would a CA offer a "refund policy"? This is
more an exception than the norm -- I know no relevant case, BTW.

My third comment is a question: What ICC? Nowhere the RFC identifies
what is "International Chamber of Commerce (ICC)", which however it cites
twice.   There  are many  "International Chamber of Commerce" (usually,
one in *each* country and under that country's sovereignity) and there is
also an "Internet Chamber of Commerce" at icc.org.  Which one is meant?
Which one is interested in this RFC and has worked with its drafters?

In summary, I see no reason to have a PDS in potential conflict with
a CPS and introducing further agents and indirections into what was
initially (yes, let us recalll this too) a *binary* dialogue between sender
and receiver.

Here, Marx Brothers fans will recall the scene in "A Day at the Races"
in which Groucho, intending to put his money on Sun-up, is induced
instead to buy a coded tip from Chico and is able to establish the
identity of the horse only, at some cost in terms of time and money, by
successive purchases from Chico of the code book, the master code book,
the breeders' guide and various other works of reference, by the end of
which the race is over, Sun-up having won.

Cheers,

Ed Gerck

Stefan Santesson wrote:

> All,
>
> A first preliminary draft of the model PKI disclosure statement (PDS), as
> presented during the Washington PKIX session, is now available.
>
> The document can be downloaded from:
> http://www.accurata.se/pds/dok/draft-ietf-xxx-pds-00_prel.txt
>
> It should be noted that this document has ben developed in cooperation with
> members of the ICC (International Chamber of Commerce) and ABA (American Bar
> Association).
>
> The purpose of posting this document to the list is to obtain comments and to
> determine if this should be adopted as a PKIX work item.
>
> /Stefan

From: "Manger, James" <[email-masked]>
To: [email-masked]
Subject: dnQualifier is used incorrectly
Date: Thu, 11 Nov 1999 11:24:10 +1100

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_000_01BF2BED.FEC6EAE0
Content-Type: text/plain

It is inappropriate to hold an employee/member/customer number as a
dnQualifier attribute value.  When multiple directories each have an entry
for the same person (or entity) the DN Qualifier disambiguates the entries.
A DN Qualifier value indicates which directory a DN refers to, not which
person in a directory.  In fact, the definition of DN Qualifier says the
same value should be used for all entries in a given directory.  Mapping
from directories to CAs, it is clear that the DN Qualifier should
disambiguate certificates issued to the same person by different CAs.  The
same DN Qualifier value should be used in all certificates issued by a given
CA.  The DN Qualifier should identify the CA, not the subject.

Example:
A company, Frottleby Limited, is certified by two CAs.
The TrustMe CA certifies Frottleby Limited using a DN:
	{ c "AU" / o "Frottleby Limited" dnQualifier "TrustMe Customer" }
The SuperID CA certifies Frottleby Limited using a DN:
	{ c "AU" / o "Frottleby Limited" dnQualifier "SuperID" }

Stephen & Stefan's quotes below are completely at odds with the original, &
surely definitive, X.520 definition of the DN Qualifier attribute.

Stephen Kent says, in 'Re: QC UID support must depart from RFC2459',

	"..I believe that the DN Qualifier makes more sense as a component
of a terminal RDN, at least from the standpoint of directory schema. I would
also suggest that this is the most appropriate attribute as a means of
expressing employee ID, payroll number, etc.  After all, these numbers were
assigned in the pre-X.500 world to achieve the analogous effect, i.e., to
disambiguate among database entries that might otherwise be identical."

Stefan Santesson says,

	"- Attributes for expressing a private identity (... dnQualifier)
...  Here the use of dnQualifier will be constrained to hold a unique
identifier of the subject within the set of all certificates issued by a
CA."

>From X.520 | ISO/IEC 9594-6: 1993:

5.2.8 DN Qualifier
The DN Qualifier attribute type specifies disambiguating information to add
to the relative distinguished name of an entry.  It is intended to be used
for entries held in multiple DSAs which would otherwise have the same name,
and that its value be the same in a given DSA for all entries to which this
information has been added.

[DSA = Directory System Agent, basically a directory server]

------_=_NextPart_000_01BF2BED.FEC6EAE0
Content-Type: application/ms-tnef
Content-Transfer-Encoding: base64

------_=_NextPart_000_01BF2BED.FEC6EAE0--

From: "Manger, James" <[email-masked]>
To: "[email-masked]'" <[email-masked]>
Subject: PKIX: employee/member/customer/org number attributes
Date: Thu, 11 Nov 1999 12:41:46 +1100

Proposed new attributes:
Note: the serialNumber attribute syntax is PrintableString, so these
"numbers" don't have to consist solely of numeric digits.

The following attributes are only meaningful in the context of an
organization.  It follows that the directory name of an entry with one or
more of these attributes shall be associated with an OrganizationName
attribute.

x.y.1
The Organization Person Number attribute specifies an identifier for an
employee of an organization.  Within the context of a given organization, an
Org Person Number shall unambiguously identify an employee and will usually
be unique, i.e. an employee will usually have only one Org Person Number for
a given organization.

orgPersonNumber ATTRIBUTE ::= { SUBTYPE OF serialNumber ...}

x.y.2
The Member Number attribute specifies an identifier for a member of an
organization.  Within the context of a given organization, a Member Number
shall unambiguously identify a member and will usually be unique, i.e. a
member will usually have only one Member Number for a given organization.

memberNumber ATTRIBUTE ::= { SUBTYPE OF serialNumber ...}

x.y.3
The Customer Number attributes specifies an identifier for a customer of an
organization.  Within the context of a given organization, a Customer Number
shall unambiguously identify a customer.  A customer may have more than one
Customer Number for a given organization.

customerNumber ATTRIBUTE ::= { SUBTYPE OF serialNumber ...}

x.z.1
The Organization Number attribute specifies an identifier for an
organization.  An Org Number shall unambiguously identify an organization
within the context of a given jurisdiction.  There may be a small number of
organization numbering schemes within a given jurisdiction.  Each Org Number
shall include a prefix unambiguously identifying the scheme within a given
jurisdiction.  An Org Number from a given scheme will often be unique (i.e.
the only such number the organization has), but not always, due to company
merges etc.

The jurisdiction within which a given Org Number is unambiguous is specified
by any CountryName  and StateOrProvinceName attributes associated with the
Org Number, e.g. in superior components of a DN.

orgNumber ATTRIBUTE ::= { SUBTYPE OF serialNumber ...}

[may be worth having separate attributes for globally unambiguous org
numbers (e.g. DUNS number) and/or org numbers that are unambiguous within a
country (e.g. Australian Company Number, ACN)]

Date: Wed, 10 Nov 1999 20:39:34 -0500
To: "Anders Rundgren" <[email-masked]>, <[email-masked]>
From: Stefan Santesson <[email-masked]>
Subject: Re: QC container ID support

As I said before it would be appropriate to define a qcStatement providing
essential information about the signature device associated with the
certificate. This may also carry an identifier of the actual container.

/Stefan 

At 21:16 1999-11-10 +0000, Anders Rundgren wrote:
>Stefan, 
>What happened to the smart-card serial number/container ID? 
>
>My request got support both from ID2 and TrustCenter. 
>
>When we are talking legally binding signatures it is nice to know from what 
>(possibly 
>stolen) container they emanated from. 
>
>Both SEIS and German signature law defines this.
>
>And most QCs will be smart-card-based. Otherwise they simply don't make
sense. 
>Anders

Date: Wed, 10 Nov 1999 20:08:45 -0500
To: <[email-masked]>
From: Stefan Santesson <[email-masked]>
Subject: Model PKI Disclosure Statement (PDS)

All,

A first preliminary draft of the model PKI disclosure statement (PDS), as
presented during the Washington PKIX session, is now available.

The document can be downloaded from: 
http://www.accurata.se/pds/dok/draft-ietf-xxx-pds-00_prel.txt

It should be noted that this document has ben developed in cooperation with
members of the ICC (International Chamber of Commerce) and ABA (American Bar
Association).

The purpose of posting this document to the list is to obtain comments and to
determine if this should be adopted as a PKIX work item.

/Stefan

Date: Wed, 10 Nov 1999 18:03:02 -0500
From: Sean Turner <[email-masked]>
Organization: IECA, Inc.
To: [email-masked]
CC: [email-masked], [email-masked]
Subject: Re: LAAP performance issues

Stephen,

After seeing your presentation at the WG I can see why you'd not want to
support this in LAAP.  Can you just add the design assumptions you used (no
AC chains, no revocation, etc.) to the introduction?  Once you clear that up
I think you answered my concerns.

spt

Stephen Farrell wrote:

> Hi Sean,
>
> > The model in the draft doesn't explicitly restrict the model to be for
> > the
> > "never revoke" method in draft-ietf-pkix-ac509prof-01.txt.  Should we
> > add a new
> > request and response to support revocation or was it intended to use
> > OCSP to get
> > revocation information?
>
> No to adding one and yes to using OCSP, which works just fine for
> ACs (so long as issuer names/keys don't get confused).
>
> Regards,
> Stephen.
>
> --
> ____________________________________________________________
> Stephen Farrell
> Baltimore Technologies,   tel: (direct line) +353 1 647 7406
> 61 Fitzwilliam Lane,                    fax: +353 1 647 7499
> Dublin 2.                mailto:[email-masked]
> Ireland                             http://www.baltimore.com

Date: Wed, 10 Nov 1999 18:08:21 -0500
To: <[email-masked]>
From: Stefan Santesson <[email-masked]>
Subject: Update of the QC personalData issue (errata)

Ooups, 

Two small errors in my previous mail.

1) countryName was missing in the list of attributes for the subject field,
and;
2) the attributes stored in the subject field are only required to form a
DN. To obtain an unmistakable identity, according to the QC profile
definition, it may also require examination of the
subjectDirectoryAttributes extension.

/Stefan

All,

Here is an update of the QC personalData issue after further considerations
and discussions during the Washington meeting.

To make a good solution here we have to go back to the original ideas
behind this structure.

The personalData structure was added in order to allow specification of
specific identity information without populating the subject field with odd
non-standardized attributes.

subjectAltName was a natural choice since we needed not only attributes but
also other information like attribute semantics and registration authority
info to be present.

The problem with subjectAltName extension though is that included names
have to be unique. This means that a complete unmistakable identity have to
be stored. Not only non-unique attributes, adding extra information to the
subject field.

Now this impose 2 problems:
1) Attributes like countryOfResidence can't be used unless a complete
identity is stored in the personalData.
2) Name/identity information must be duplicated with risk of ambiguity and
confusion between the subject field and the personalData structure.

Two major changes have made prerequisites different now compared to when
personalData was originally formed:
 1) The update of RFC 2459 will open up for use of
SubjectDirectoryAttributes in accordance with the proposal below.
2) The new qcStatements extension has a predefined statement declaring
conformance with syntax and semantics of the QC profile. This can include
qualifying data such as definition of attribute semantics and a list of
associated registration authorities.

The proposed solution is to take advantage of this and:

Allow storage of the following attributes in SubjectDirectoryAttributes:
   postalAddress
   gender
   placeOfBirth
   dateOfBirth
   countryOfCitizenship
   countryOfResidence

Further allow all RFC 2459 attributes to be present in the subject field
but require that a complete DN (in the form of an unmistakable identity) of
the subject shall be defined using an appropriate subset of the following
attributes: 

  commonName
  pseudonym
  surname
  givenName
  dnQualifier
  stateOrProvinceName
  localityName
  organizationName
  organizationalUnitName
  title

(Note that the pseudonym attribute will be included also in the next RFC
2459 update so all attribute will be supported by RFC 2459)

Finally we define (as said above) that an attribute semantics OID, and a
sequence of associated name registration authorities may be specified in
the qcStataments extension as a statement info carried with the predefined
statement declaring conformance with syntax and semantics defined in the QC
profile.

Preliminary ASN.1 definition: 

statementInfo QC-STATEMENT ::= {
    attributeSemanticsSyntax IDENTIFIED BY id-qcs-pkixQCSyntax-v1

attributeSemanticsSyntax   ::=  SEQUENCE       {
    attributeSemantics      OBJECT IDENTIFIER    OPTIONAL,
    registrationAuthorities RegistrationAuthorities OPTIONAL }

RegistrationAuthorities    ::=  SEQUENCE       {
    registrationAuthority   GeneralName }

So finally, after these changes, we can totally delete the personalData
structure which nobodey so far has shown a desire to implement anyway.

We can do this without loosing any of the functionality that we originally
needed the structure for and we end up with a much more consistent
specification with only one common place to store the identity attributes.

Another issue here has been static identifiers. 

One way to go here is that an appropriate attributeSemantics OID may
provide the definition that the dnQualifier attribute is populated with a
value that have this property, i.e. to be a unique static identifier of the
certified subject.

An alternative could be to define that dnQualifier in QC always MUST
contain a unique value for the subject (within the set of all certificates
issued by a CA)

I'm currently open for suggestions here.

Any comments are welcome.

If there seems to be consensus around this then it will be included in a
new draft in a few weeks (hopefully) and then go for a new WG last call.

/Stefan

Date: Wed, 10 Nov 1999 17:54:23 -0500
To: <[email-masked]>
From: Stefan Santesson <[email-masked]>
Subject: Update of the QC personalData issue

All,

Here is an update of the QC personalData issue after further considerations and
discussions during the Washington meeting.

To make a good solution here we have to go back to the original ideas behind
this structure.

The personalData structure was added in order to allow specification of
specific identity information without populating the subject field with odd
non-standardized attributes.

subjectAltName was a natural choice since we needed not only attributes but
also other information like attribute semantics and registration authority info
to be present.

The problem with subjectAltName extension though is that included names have to
be unique. This means that a complete unmistakable identity have to be stored.
Not only non-unique attributes, adding extra information to the subject field.

Now this impose 2 problems:
1) Attributes like countryOfResidence can't be used unless a complete identity
is stored in the personalData.
2) Name/identity information must be duplicated with risk of ambiguity and
confusion between the subject field and the personalData structure.

Two major changes have made prerequisites different now compared to when
personalData was originally formed:
 1) The update of RFC 2459 will open up for use of SubjectDirectoryAttributes
in accordance with the proposal below.
2) The new qcStatements extension has a predefined statement declaring
conformance with syntax and semantics of the QC profile. This can include
qualifying data such as definition of attribute semantics and a list of
associated registration authorities.

The proposed solution is to take advantage of this and:

Allow storage of the following attributes in SubjectDirectoryAttributes:
   postalAddress
   gender
   placeOfBirth
   dateOfBirth
   countryOfCitizenship
   countryOfResidence

Further allow all RFC 2459 attributes to be present in the subject field but
require that a complete DN (in the form of an unmistakable identity) of the
subject shall be defined using an appropriate subset of the following
attributes: 

  commonName
  pseudonym
  surname
  givenName
  dnQualifier
  stateOrProvinceName
  localityName
  organizationName
  organizationalUnitName
  title

(Note that the pseudonym attribute will be included also in the next RFC 2459
update so all attribute will be supported by RFC 2459)

Finally we define (as said above) that an attribute semantics OID, and a
sequence of associated name registration authorities may be specified in the
qcStataments extension as a statement info carried with the predefined
statement declaring conformance with syntax and semantics defined in the QC
profile.

Preliminary ASN.1 definition: 

statementInfo QC-STATEMENT ::= {
    attributeSemanticsSyntax IDENTIFIED BY id-qcs-pkixQCSyntax-v1

attributeSemanticsSyntax   ::=  SEQUENCE       {
    attributeSemantics      OBJECT IDENTIFIER    OPTIONAL,
    registrationAuthorities RegistrationAuthorities OPTIONAL }

RegistrationAuthorities    ::=  SEQUENCE       {
    registrationAuthority   GeneralName }

So finally, after these changes, we can totally delete the personalData
structure which nobodey so far has shown a desire to implement anyway.

We can do this without loosing any of the functionality that we originally
needed the structure for and we end up with a much more consistent
specification with only one common place to store the identity attributes.

Another issue here has been static identifiers. 

One way to go here is that an appropriate attributeSemantics OID may provide
the definition that the dnQualifier attribute is populated with a value that
have this property, i.e. to be a unique static identifier of the certified
subject.

An alternative could be to define that dnQualifier in QC always MUST contain a
unique value for the subject (within the set of all certificates issued by a
CA)

I'm currently open for suggestions here.

Any comments are welcome.

If there seems to be consensus around this then it will be included in a new
draft in a few weeks (hopefully) and then go for a new WG last call.

/Stefan

From: "Anders Rundgren" <[email-masked]>
To: "'SEIS-List'" <[email-masked]>, "'Stefan Santesson'" <[email-masked]>, <[email-masked]>
Cc: "Magnus (RSA)" <[email-masked]>
Subject: QC container ID support
Date: Wed, 10 Nov 1999 21:16:15 -0000

Stefan, 
What happened to the smart-card serial number/container ID? 

My request got support both from ID2 and TrustCenter. 

When we are talking legally binding signatures it is nice to know from what (possibly 
stolen) container they emanated from. 

Both SEIS and German signature law defines this.

And most QCs will be smart-card-based. Otherwise they simply don't make sense. 

Anders

From: "Bill Brice (listserv)" <[email-masked]>
To: "[email-masked]'" <[email-masked]>, Stephen Kent <[email-masked]>
Cc: "David P. Kemp" <[email-masked]>, [email-masked]
Subject: Re: QC UID support must depart from RFC2459
Date: Wed, 10 Nov 1999 13:37:16 -0600

All,

As the new kid on the block, I'd like to share with you the
design tensions we, as a CA, had to deal with quite recently
in designing UID support for our certificates. AlphaTrust
specializes in certificates which are used in legally binding
transactions (irrespective of the state of dig-sig law).

Since our members must be unambiguously identified from a
user universe of everyone on the planet, we had little choice
but to use some form of UID. After all, what's to differentiate
between one Fred Smith, (an individual with no O= or OU=) from 
the next Fred Smith.

Our original choice was to use a DN Qualifier with a CN, as Steve Kent
suggests as the correct approach. The market reality, and therefore
the tension, is that most cert using applications available
to the public (which is our market) do not process DN Qualifiers.
In fact, most user interfaces present only the CN to the user
when reporting on a certificate or asking the user to select one.
Multiple certs with the same CN are very confusing to an
average user.

So we made the same choice as the DoD and added the UID (
and two other items the user needs) into the CN field. The UID
also appears in the OU field (as many of our users do not
have an OU to report).

I agree this is not the correct approach and we welcome better
user interfaces and support of standards by the major software
suppliers. But its also important to remember that if a product
is not easy for a user to understand and use, all the standards
in the world won't help it.

Bill Brice, CEO
http://alphatrust.com

-----Original Message-----
From: schaen [mailto:[email-masked]]
Sent: Wednesday, November 10, 1999 12:37 PM
To: Stephen Kent
Cc: David P. Kemp; [email-masked]
Subject: DOD Plans [was: Re: QC UID support must depart from RFC2459]

A quick clarification of the DoD plans.

The DoD has been issuing certs with a UID concatenated to the CN for the
past 9 months.  We recognized the kludge at the time, but needed a way to
provide unique identifiers for a very large organization in a highly
distributed manner.  At the time, we found that many applications could
not handle multi-attribute RDNs, and so went with the kludge.  The DoD
will consider migrating when the standards solidify and applications
support a standard approach.

Sam Schaen
MITRE

Stephen Kent wrote:

> Dave,
> [snip]

> Is it really true that the DoD is going to concatenate a CN and a UID
> and represent the result as a CN?  I agree that this would be a very
> bad idea!  It is not at all the same as making the terminal RDN be a
> 2-element set consisting of a CN and a DN Qualifier, which would be
> consistent with PKIX and X.509. As for your closing question, I don't
> think that the TRW example is a good one, for the reasons cited
> above, and so I don't know that it will be consistent with the PKIX
> or QC profiles.
>
> Steve

Date: Wed, 10 Nov 1999 13:36:52 -0500
From: schaen <[email-masked]>
Reply-To: [email-masked]
Organization: MITRE
To: Stephen Kent <[email-masked]>
CC: "David P. Kemp" <[email-masked]>, [email-masked]
Subject: DOD Plans [was: Re: QC UID support must depart from RFC2459]

A quick clarification of the DoD plans.

The DoD has been issuing certs with a UID concatenated to the CN for the
past 9 months.  We recognized the kludge at the time, but needed a way to
provide unique identifiers for a very large organization in a highly
distributed manner.  At the time, we found that many applications could
not handle multi-attribute RDNs, and so went with the kludge.  The DoD
will consider migrating when the standards solidify and applications
support a standard approach.

Sam Schaen
MITRE

Stephen Kent wrote:

> Dave,
> [snip]

> Is it really true that the DoD is going to concatenate a CN and a UID
> and represent the result as a CN?  I agree that this would be a very
> bad idea!  It is not at all the same as making the terminal RDN be a
> 2-element set consisting of a CN and a DN Qualifier, which would be
> consistent with PKIX and X.509. As for your closing question, I don't
> think that the TRW example is a good one, for the reasons cited
> above, and so I don't know that it will be consistent with the PKIX
> or QC profiles.
>
> Steve

Date: Wed, 10 Nov 1999 10:50:05 -0500
To: "Anders Rundgren" <[email-masked]>
From: Stephen Kent <[email-masked]>
Subject: Re: QC: VERISIGN uses UIDs!
Cc: "Stefan Santesson" <[email-masked]>, "'SEIS-List'" <[email-masked]>, <[email-masked]>

>Anders,

You are certainly not on an auto-discard filter of mine.  I read ALL 
the PKIX traffic since I consider it my responsibility as co-chair. 
I don't respond to all of it, not even all of your messages :-), but 
I do read it.

>1. VeriSign was indeed involved in making RFC2459

yes, so?

>2.  Im am NOT arguing about syntax.  I am arguing about the 
>PRINCIPAL use of UIDs in
>certificates.  Also I am trying to make you and Stefan realize that 
>UID support is a
>MARKET REQUIREMENT.  And exactly how you achieve it (what you call 
>it and where
>you put it)  is another issue that I believe that you are fully 
>capable to perform.

I agree that we should focus on the principle of UIDs first, the 
discuss the syntax later.  I presume you are aware of why the Issuer 
and Subject UIDs were added in v2 certs, and why they are almost 
never used, and why their use is deprecated in 2459. If not, then we 
have a communication problem, since one should be aware of the 
history of these matters before advocating analogous capabilities.

>But FIRST we must agree (seems unlikey though) on the SEMANTICS 
>particularly with respect to
>certificate comparisions and the state of the other attributes when 
>an "UID-enabled"
>certificate is found.
>

You noted above that you are trying to convince the WG of the market 
need for UIDs.  Unfottunately, that's hard for an individual to do. 
We all deal with some set of clients and these clients want solutions 
to their problems in the simplest possible fashion.  However, we're 
in the business of creating standards and inserting fields in data 
structures to satisfy individual customer needs is not a good 
approach to devising standards.  We already have several examples of 
how such behavior has been detrimental to interoperability. Thus we 
need to proceed with caution.

>3. Is the product manager for GTE CyberTrust willing to atttest here and now
>that GTE (unlike VeriSign) will never engage in creating commercial 
>certificates
>using UIDs (of some kind)?

I don't know what the CA product manager might say, and I would not 
let his position influence my decision, unless he could make a 
compelling, general case.  In order to sell a product, vendors will 
often make decisions that are poor decisions from a standards 
perspective.  I have witnessed them internally and externally and 
been equally critical in both contexts. I spend a moderate amount of 
time acting as an advocate for standards in CyberTrust; I don't 
recall ever acting as an advocate for CyberTrust product features in 
PKIX.

Steve

Date: Wed, 10 Nov 1999 11:14:07 -0500
To: "David P. Kemp" <[email-masked]>
From: Stephen Kent <[email-masked]>
Subject: Re: QC UID support must depart from RFC2459
Cc: [email-masked]

Dave,

Thanks for the detailed and very thoughtful note.

First, 2459 is being revised to add the pseudonym attribute, so that 
disconnect will be eliminated.  The QC design is being revised to 
restructure the fields and that may eliminate the postaladdress 
conflict, but I'll defer to Stefan on that issue.  2459 attributes 
that must be supported need not be included in QC certs, since QC is 
a profile of 2459 and thus sub-setting is fine. These changes were 
announced at the PKIX meeting yesterday, so anyone who did not attend 
would not be expected to know of them until the minutes are sent out 
later this week (after our second meeting, this afternoon).

I think the TRW scheme may be a bad example.  A DN is a directory 
name.  In the example you cite, I believe that the DN Qualifier makes 
more sense as a component of a terminal RDN, at least from the 
standpoint of directory schema. I would also suggest that this is the 
most appropriate attribute as a means of expressing employee ID, 
payroll number, etc.  After all, these numbers were assigned in the 
pre-X.500 world to achieve the analogous effect, i.e., to 
disambiguate among database entries that might otherwise be identical.

When one uses an attribute that, by itself, is sufficient to uniquely 
identify a directory entry, then it really has no place in the middle 
of a DN.  Just drawing the tree for the directory would make that 
apparent, I think. So I am leery of the TRW use of UID.

What we have here is a conflict among multiple criteria for DN and 
cert design. Some people would like to use a simple UID for ACLs, so 
that changes in DN forms don't wreak havoc with their ACLs. All 
people need to be able to assign DNs that are unique, even when their 
nominal schema would produce collisions. (The X.520 of a UID 
attribute, a relatively new one I believe, is an escape for people 
who did a bad schema design, right?)

Whenever we start moving into the details of access control and how 
to use certs, we encounter a lot of confusion.  This arises from the 
fact that folks faced with these problems have not always had much 
experience in the security arena, may not be familiar with the 
literature on access control and naming from the last 25 years, and 
are anxious to create a solution that meets their local needs with 
the products they have at hand. This is not a good prescription for 
how to create standards to support customer requirements.

Is it really true that the DoD is going to concatenate a CN and a UID 
and represent the result as a CN?  I agree that this would be a very 
bad idea!  It is not at all the same as making the terminal RDN be a 
2-element set consisting of a CN and a DN Qualifier, which would be 
consistent with PKIX and X.509. As for your closing question, I don't 
think that the TRW example is a good one, for the reasons cited 
above, and so I don't know that it will be consistent with the PKIX 
or QC profiles.

Steve

Date: Wed, 10 Nov 1999 10:50:21 -0500
To: "David P. Kemp" <[email-masked]>, [email-masked]
From: Stefan Santesson <[email-masked]>
Subject: Re: QC UID support must depart from RFC2459
Cc: "Anders Rundgren" <[email-masked]>

David,

The discussions and consensus reached during the Washington IETF has
changed some of the issues raised here. This includes a solution for
"static identifiers".

First of all I would like to say that X.520 UID is a bad attribute of one
particular reason. It is represented by a bit string. This is bad for all
situations where you wish to display this information in any uniform way.
(Your referenced OID is also wrong I believe)

So seen from this perspective I believe that the dnQualifier is the most
suitable attribute for this type of identifier. And one good reason is that
it is supported by RFC 2459.

The differences in supported attributes in the subject field will be fixed.
The current proposal is to make the following changes:

RFC 2459 will add support for pseudonym in the next update (son of RFC 2459)
The QC profile will add stateAndProvinceName and delete postalAddress.

This will make these profiles in harmony.

The personalData will further be updated in order to support more dynamic
use of the attributes there.

I will come back later with more detailed information about the changes in
the personalData structure but the main changes are:

- Attributes for country of citizenship and residence, gender, date and
place of birth will be moved to subjectDirectoryAttributes extension so
that they may be utilized independently without including a complete
personal record.

- Attributes for expressing a private identity (commonName, pseudonym,
givenName, surname, localityName, StateOrProvinceName, postalAddress and
dnQualifier) may be stored as a Directory name in the subjectAltName
extension. Here the use of dnQualifier will be constrained to hold a unique
identifier of the subject within the set of all certificates issued by a CA. 

- Parameters defining attribute semantics and name registration authority
are moved to the qcStatements extension as parameters the defined statement
defining conformance with syntax and semantics of the QC profile. 

With these changes I hope that we have satisfied some real issues that has
been raised lately.

/Stefan

What you say 

At 09:03 1999-11-10 -0500, David P. Kemp wrote:
>Steve,
>
>There seems to be more heat here than what would be generated by actual
>differences in requirements.  It may be useful to restate the
>requirements in an effort to obtain a useful agreed-to profile.
>
>The QC profile lists the attributes that MAY be used in the subject
>field of a certificate - the QC list differs from the RFC 2459 list:
>
>QC atttribute  RFC245 MUST/SHOULD
>-----------   -----------------
>countryName          M
>commonName           M
>surname              S
>givenName            S
>dnQualifier          M
>orgName              M
>orgUnitName          M
>title                S
>localityName         S
>
>The QC profile lists two attributes not included in RFC2459:
>
>pseudonym            -
>postalAddress        -
>
>RFC2459 includes four attributes not listed in QC:
>
>stateOrProvinceName  M
>domainComponent      M
>initials             S
>generationQualifier  S
>
>
>No X.520 attributes appear to have the semantics of "employee number",
>"student number", "payroll number", etc that Anders is requesting.
>
>X.520:
>    "The Unique Identifier attribute type specifies an identifier
>    which may be used to distinguish between object references when
>    a distinguished name has been reused."
>    
>    "The DN Qualifier attribute type specifies disambiguating information
>    to add to the relative distinguished name of an entry."
>    
>    "The Serial Number attribute type specifies an identifier, the
>    serial number of a device."
>
>The DN Qualifier is suitable for use as you describe in the
>second paragraph, as part of a multi-value terminal RDN.  But what
>attribute should be used for the function you describe in the first
>paragraph: a permanent unique identifier that is suitable for use
>as a single-value RDN?
>
>TRW has described their corporate naming scheme to the Federal PKI
>technical working group - it looks something like:
>
>    C=US, O=TRW.COM, OU=Employees, UID=123456, CN=Fred Smith
>
>where UID is (I believe) 0.9.2342.19200300.100.1.1 defined in
>draft-smith-ldap-inetorgperson-03.txt.  This naming scheme allows
>the UID employee number to be used in comparisons (for example in
>access control lists) while the CN can change during an employee's
>tenure without affecting the comparisons.
>
>This scheme is IMHO eminently sensible (and much more sensible than the
>DoD's current plan to concatenate a common name and a UID in the CN
>attribute!).  How will son-of-2459 or the next QC draft profile the TRW
>naming scheme?
>
>Dave Kemp
>
>
>
>
>> Date: Mon, 8 Nov 1999 11:13:37 -0500
>> To: "Anders Rundgren" <[email-masked]>
>> From: Stephen Kent <[email-masked]>
>> 
>> Anders,
>> 
>> If QCs deviate from 2459 (in its future, revised version), then there will
>> be no QC profile as an IETF standard.  I assume this is obvious, but just
>> wanted to inject a little reality check here.
>> 
>
>    ... and ...
>
>>
>> Yes, many organizations do qualify individuals by employee, student,
>> payroll, or other numeric IDs.  The preferred way to make use of this
>> qualification is as one element of a two element set for the terminal RDN.
>> After all, this qualifying number is needed to uniquely identify two
>> individuals who would otherwise have the same DN, so it belongs in the DN.
>>
>> Steve
>>

Date: Wed, 10 Nov 1999 10:12:00 -0500
To: "Bob Jueneman" <[email-masked]>
From: Stephen Kent <[email-masked]>
Subject: Re: QC: VERISIGN uses UIDs!
Cc: <[email-masked]>, <[email-masked]>

>Bob,

>For someone who works for a competing Certification Authority,
>that was a cheap shot, and did not exhibit the impartiality
>that is normally expected of a WG chair.

My observations about some of the syntactic choices that have 
appeared in VeriSign certificates have nothing to do with my 
relationship to CyberTrust. CyberTrust is only one of the 3 corporate 
entities with which I work here at GTE.  In my capacity as Chief 
Scientist of Information Security for BBN I made similar observations 
about some of these issues long before the merger that brought 
CyberTrust into my realm.

The observations are factual.  One may argue that VeriSign, as the 
first major TTP CA, has been in the forefront of the business and 
thus has gone to market with their perceptions of what is appropriate 
before standards bodies have rendered decisions that would guide 
their implementations.  However, I think we can find examples where 
even that argument is overly charitable.  I don't mean to single out 
VeriSign as the only CA service provider who has made choices of this 
sort; others are guilty too, both as service providers and as CA 
technology providers.  But since Anders used VeriSign as the exemplar 
for appropriate certificate syntax, my response had to be couched in 
the context he established.

>Surely you understand the legacy of some of those particular
>"innovations", dating back to a time when the PKIX RFC was not nearly so
>advanced, and the various browsers were in a much more parlous
>state than they are now.  Back then VeriSign really didn't have much choice.

We all make design choices and those choices reflect individual 
tastes and prejudices. The PKIX list discussed many issues prior to 
issuing I-Ds and RFCs and the likely outcome was established well 
before issuance. It is always the case that vendors who chose to make 
product/service decisions prior to issuance of an RFC run the risk of 
not being compliant.  That is a tradeoff that vendors make in 
pursuing "first to market" strategies.

>I'm not saying that I defend or support everything that they do, nor
>GTE (my former and your current employer) either. The same is true of
>Entrust and others. And BTW, we have a CA product as well, and not
>everything is perfect with that product either.

Agreed.

>But just as I recognize the pre-eminent position of Microsoft in 
>many aspects of
>this business, I also recognize the considerable market success that 
>VeriSign has
>achieved. I may not always agree with what they do, but I don't throw rocks
>at them.

I have no qualms about throwing rocks at Microsoft either, when it is 
justifiable.  I never consider market position to be a substitute for 
correctness, for standards compliance, etc.  In fact, I think that 
companies who use their market position to flout standards deserve to 
be criticized for such behavior and I do so regularly, in a variety 
of fora.

>Although some people's stock is appreciating very nicely, I don't know
>of anyone in this business who is making a ton of money yet, and as a
>consequence I don't know of anyone who has all of the time and personnel
>they wish they had to make everything better all at once.
>
>Let's try to avoid both ad hominem and "ad corporate" attacks,
>and concentrate on the message. Taking an ex cathedra position
>on various issues, as you seem increasingly inclined to do, really
>isn't very helpful.
>
Sorry you don't like my comments.  I try to maintain impartiality in 
dealing with all the players in this arena, and I have received many 
private compliments on my general restraint, and my occasional 
rebukes, in the context of the debates we have on this list.  My 
observations on VeriSign are, as noted above, accurate and, I 
believe, justifiable, given the context of the message to which I 
have responded.  They were not intended to criticize VeriSign in 
isolation, but to refute the use of VeriSign as a reference point for 
the argument. As for ad hominem attacks, I feel that my rebukes to 
folks who have continually and forcefully espoused positions that 
have been rejected by the WG, have been necessary to avoid wasting my 
time and that of the list. Based on the feedback I have received, I'm 
satisfied with my behavior.

Steve

From: Michael Zolotarev <[email-masked]>
To: "[email-masked]'" <[email-masked]>
Subject: IMPORTANT info for those who is staying in OMNI Shoreham. Please  read.
Date: Thu, 11 Nov 1999 02:23:15 +1100

This morning I've discovered that the hotel charges you for every
international phone call you make, EVEN IF THERE WAS NO CONNECTION, i.e.
nobody answered.

More disgustingly, they charge $21.65 for each call like that, and it is
shown as a long distance call with 1 minute duration in your hotel bill
printout.

Which is obviously illegal. I spoke to the Sprint, which confirmed that it
is a rip of, and as a result my bill was IMMEDIATELY recalculated when I
raised the issue at the front desk.

The hotel is apparently aware of what's going on, but deliberatly fails to
inform you that there is a nice little 21.65xnnn illegal surcharge in your
bill. 

So be aware and take care of your money.

I'm posting it to the PKIX group only, as I'm not subscribed to others. But
I trust that you will pass the message across.

Michael

PS I forgot to mention that I also found that I was billed for using the
Honor Bar, which I did not touch. But this could be a real mistake,
though...

Date: Wed, 10 Nov 1999 09:03:22 -0500 (EST)
From: "David P. Kemp" <[email-masked]>
Reply-To: "David P. Kemp" <[email-masked]>
Subject: Re: QC UID support must depart from RFC2459
To: [email-masked]
Content-MD5: 6xR/2+AUBBMMLcR1heSRIQ==

Steve,

There seems to be more heat here than what would be generated by actual
differences in requirements.  It may be useful to restate the
requirements in an effort to obtain a useful agreed-to profile.

The QC profile lists the attributes that MAY be used in the subject
field of a certificate - the QC list differs from the RFC 2459 list:

QC atttribute  RFC245 MUST/SHOULD
-----------   -----------------
countryName          M
commonName           M
surname              S
givenName            S
dnQualifier          M
orgName              M
orgUnitName          M
title                S
localityName         S

The QC profile lists two attributes not included in RFC2459:

pseudonym            -
postalAddress        -

RFC2459 includes four attributes not listed in QC:

stateOrProvinceName  M
domainComponent      M
initials             S
generationQualifier  S

No X.520 attributes appear to have the semantics of "employee number",
"student number", "payroll number", etc that Anders is requesting.

X.520:
    "The Unique Identifier attribute type specifies an identifier
    which may be used to distinguish between object references when
    a distinguished name has been reused."
    
    "The DN Qualifier attribute type specifies disambiguating information
    to add to the relative distinguished name of an entry."
    
    "The Serial Number attribute type specifies an identifier, the
    serial number of a device."

The DN Qualifier is suitable for use as you describe in the
second paragraph, as part of a multi-value terminal RDN.  But what
attribute should be used for the function you describe in the first
paragraph: a permanent unique identifier that is suitable for use
as a single-value RDN?

TRW has described their corporate naming scheme to the Federal PKI
technical working group - it looks something like:

    C=US, O=TRW.COM, OU=Employees, UID=123456, CN=Fred Smith

where UID is (I believe) 0.9.2342.19200300.100.1.1 defined in
draft-smith-ldap-inetorgperson-03.txt.  This naming scheme allows
the UID employee number to be used in comparisons (for example in
access control lists) while the CN can change during an employee's
tenure without affecting the comparisons.

This scheme is IMHO eminently sensible (and much more sensible than the
DoD's current plan to concatenate a common name and a UID in the CN
attribute!).  How will son-of-2459 or the next QC draft profile the TRW
naming scheme?

Dave Kemp

> Date: Mon, 8 Nov 1999 11:13:37 -0500
> To: "Anders Rundgren" <[email-masked]>
> From: Stephen Kent <[email-masked]>
> 
> Anders,
> 
> If QCs deviate from 2459 (in its future, revised version), then there will
> be no QC profile as an IETF standard.  I assume this is obvious, but just
> wanted to inject a little reality check here.
> 

    ... and ...

>
> Yes, many organizations do qualify individuals by employee, student,
> payroll, or other numeric IDs.  The preferred way to make use of this
> qualification is as one element of a two element set for the terminal RDN.
> After all, this qualifying number is needed to uniquely identify two
> individuals who would otherwise have the same DN, so it belongs in the DN.
>
> Steve
>

From: [email-masked]
Date: Wed, 10 Nov 1999 08:23:19 EST
Subject: Re: QC: VERISIGN uses UIDs!
To: [email-masked], [email-masked], [email-masked], [email-masked]
CC: [email-masked]

Guys,

I think this discussion needs to be taken off line!

Charlie

From: Simon Tardell <[email-masked]>
To: "'Michael Zolotarev'" <[email-masked]>
Cc: "[email-masked]'" <[email-masked]>
Subject: RE: Timestamp: 04: comments
Date: Wed, 10 Nov 1999 10:35:48 +0100

> > Next it says that "By adding the accuracy value to the GeneralizedTime,
an
> > upper limit of the time at which the timestamp has been created by the
TSA
> > can be obtained. In the same way...". This is of course utter
nonsense.The
> > time we discuss here is a quantity subject to a physical measurement
about
> > which nothing can be said with certitude. What is missing is a
confidence
> > level. It should say something along the lines of "The time at which the
> > timestamp was created is between genTime-accuracy and genTime+accuracy
> > with a confidence level of 90%" (if we can agree on a confidence  level
of 90%,
> > which I think we cannot). The level of confidence (a percentage) could
> > optionally be bundled with the length of the confidence interval
> > ("Accuracy").
> > 
> 	MZ:
> 	And what exactly would you do with the confidence-level encoded
> accuracy? Take the token to the court and try to prove that 
> the time was "15% more likely to be the TokenTime+1ms then the 
> TokenTime+2ms ( for some given accuracy and confidence level)?

That is not the question you would ask in court,is it? The question is
rather something like "Was the timestamp before (or after, as it may be)
this time, neyond reasonable doubt.". The meaning of "reasonable doubt" is
"at some commonly accepted confidence level" except in legalese.

> 	More important, it does not prove anything anyway - the 
> actual time still could be anywhere within the interval, taking a single 
> token as a case. Which is a case. Unless you have a nice collection of a
thousand
> tokens, and assert the fact that at least 900 of them has the 
> time within the range.

Sorry, I don't grok that. Yes, the real time can be anywhere in the
interval. And it can be outside the interval (with a probability of
1-confidence level). And that has nothing to do with having one or thousands
of timestamps. On a side note: Taking additional timestamps from the same
TSA doesn't buy you anything since it is safe to assume that the accuracy is
mainly a systematic error that changes slowly (i.e. comes from bad frequency
calibration "drift").

> 	For the sake of a mental exercise, and for all practical means,
> wouldn't it be sufficient to just say that "the exact time  was within the
> interval"? Which of course corresponds to the confidence 
> level of 100%, practically speaking. If your confidence level is low, then
you simply
> increase the interval, to bring the confidence back to the 100% mark.

Except that confidence levels of 100% are unphysical, and this is a
measurement of a physical time. Unless, of course, you set your accuracy to
15 billion years or so.

Simon.

Simon Tardell, Software Architect, iD2 Technologies,
[email-masked]
voice +46 8 7755225, cell +46 70 3198319, fax +46 8 7267912
European IT-prize grand winners 1998 -- http://www.it-prize.org
AU-System Group Swedish IT-company of the year 1999

From: "Anders Rundgren" <[email-masked]>
To: "Stefan Santesson" <[email-masked]>, "'SEIS-List'" <[email-masked]>, <[email-masked]>
Cc: "Warwick Ford" <[email-masked]>
Subject: Re: QC: VERISIGN uses UIDs!
Date: Wed, 10 Nov 1999 08:12:31 -0000

Steve, why have you put me in your "mail-auto-rejection" filter?

>If we followed VeriSign's behavior re certificate syntax, we would 
>also encourage e-mail names hacked into DNs, CPS text embedded in 
>certificates, etc.  I'm afraid I don't consider VeriSign to be the 
>reference standard for certificate syntax.
>
>Steve

1. VeriSign was indeed involved in making RFC2459

2.  Im am NOT arguing about syntax.  I am arguing about the PRINCIPAL use of UIDs in
certificates.  Also I am trying to make you and Stefan realize that UID support is a
MARKET REQUIREMENT.  And exactly how you achieve it (what you call it and where
you put it)  is another issue that I believe that you are fully capable to perform.

But FIRST we must agree (seems unlikey though) on the SEMANTICS particularly with respect to
certificate comparisions and the state of the other attributes when an "UID-enabled"
certificate is found.

3. Is the product manager for GTE CyberTrust willing to atttest here and now
that GTE (unlike VeriSign) will never engage in creating commercial certificates
using UIDs (of some kind)?

Anders

Date: Tue, 09 Nov 1999 20:45:41 -0700
From: "Bob Jueneman" <[email-masked]>
To: <[email-masked]>, <[email-masked]>
Cc: <[email-masked]>
Subject: Re: QC: VERISIGN uses UIDs!

Steve,

For someone who works for a competing Certification Authority, 
that was a cheap shot, and did not exhibit the impartiality
that is normally expected of a WG chair.

Surely you understand the legacy of some of those particular 
"innovations", dating back to a time when the PKIX RFC was not nearly so
advanced, and the various browsers were in a much more parlous 
state than they are now.  Back then VeriSign really didn't have much choice.

I'm not saying that I defend or support everything that they do, nor
GTE (my former and your current employer) either. The same is true of 
Entrust and others. And BTW, we have a CA product as well, and not 
everything is perfect with that product either.

But just as I recognize the pre-eminent position of Microsoft in many aspects of
this business, I also recognize the considerable market success that VeriSign has
achieved. I may not always agree with what they do, but I don't throw rocks 
at them.

Although some people's stock is appreciating very nicely, I don't know 
of anyone in this business who is making a ton of money yet, and as a 
consequence I don't know of anyone who has all of the time and personnel
they wish they had to make everything better all at once.

Let's try to avoid both ad hominem and "ad corporate" attacks,
and concentrate on the message. Taking an ex cathedra position
on various issues, as you seem increasingly inclined to do, really 
isn't very helpful.

Bob

>>> Stephen Kent <[email-masked]> 11/09/99 03:29PM >>>
Anders,

If we followed VeriSign's behavior re certificate syntax, we would 
also encourage e-mail names hacked into DNs, CPS text embedded in 
certificates, etc.  I'm afraid I don't consider VeriSign to be the 
reference standard for certificate syntax.

Steve

Date: Tue, 09 Nov 1999 19:52:29 -0700
From: "Bob Jueneman" <[email-masked]>
To: <[email-masked]>, <[email-masked]>, <[email-masked]>
Subject: RE: Licensed Certification Authorities in USA

That's not quite true, David.  The number of US states that have passed some kind of 
digital signature legislation that enables the use of specifically licensed CA is probably 
closer to a dozen.  In addition, there are a somewhat larger number of foreign
countries that have passed similar laws.

Tom Smedinghoff, chair of the Science and Technology section of the
American Bar Association, runs an outstanding web site that tracks digital
signature legislation throughout the world, and I suggested to him today
that he consider tracking just who the licensed CAs re, and what states 
they are licensed in.

In addition to Utah and Washington, there are about a half dozen or more
states that have completed establishing regulations and may go live "real soon now".
These include Oregon, Michigan, North Carolina, Arizona, and Illinois(?).

I would expect that all of the currently licensed CAs would be certified in all of those
other states as quickly as the crank can be turned, since most provide
for some kind of reciprocity of recognition.

Check out Tom's former web site at www.mbc.com/ecommerce.html. 
His new site at Baker & McKensie seems to be still under construction.

Bob

>>> "Sweigert, David" <[email-masked]> 11/09/99 07:06AM >>>
Nearly each of the fifty states in the U.S. has some type of
digital signature law that allows for the provision of state
licensed C.A.s.  I belief your list is not comprehensive enough.

Dave Sweigert
General Dynamics
http://www.gd-cs.com 

-----Original Message-----
From: Sungjin Lee [mailto:[email-masked]] 
Sent: Tuesday, November 09, 1999 6:21 AM
To: [email-masked] 
Subject: Licensed Certification Authorities in USA

I know that there are "Licensed Certification Authorities" in Utah and
Washington in USA

 - Digital Signature Trust Company, Arcanvs, USERFirst, Verisign, IC
Certify

Is there another "Licensed Certification Authority" in USA?

  Sungjin Lee

  SignKorea (http://www.signkorea.com)
  Korea Securities Computer Corp.
  Seoul, South Korea.

Date: Tue, 9 Nov 1999 17:29:24 -0500
To: "Anders Rundgren" <[email-masked]>
From: Stephen Kent <[email-masked]>
Subject: Re: QC: VERISIGN uses UIDs!
Cc: "'SEIS-List'" <[email-masked]>, <[email-masked]>

Anders,

If we followed VeriSign's behavior re certificate syntax, we would 
also encourage e-mail names hacked into DNs, CPS text embedded in 
certificates, etc.  I'm afraid I don't consider VeriSign to be the 
reference standard for certificate syntax.

Steve

From: Michael Zolotarev <[email-masked]>
To: "'Simon Tardell'" <[email-masked]>
Cc: [email-masked]
Subject: RE: Timestamp: 04: comments
Date: Wed, 10 Nov 1999 08:13:47 +1100

	Simon wrote: 

> Next it says that "By adding the accuracy value to the GeneralizedTime, an
> upper limit of the time at which the timestamp has been created by the TSA
> can be obtained. In the same way...". This is of course utter nonsense.
> The
> time we discuss here is a quantity subject to a physical measurement about
> which nothing can be said with certitude. What is missing is a confidence
> level. It should say something along the lines of "The time at which the
> timestamp was created is between genTime-accuracy and genTime+accuracy
> with
> a confidence level of 90%" (if we can agree on a confidence level of 90%,
> which I think we cannot). The level of confidence (a percentage) could
> optionally be bundled with the length of the confidence interval
> ("Accuracy").
> 
	MZ:
	And what exactly would you do with the confidence-level encoded
accuracy? Take the token to the court and try to prove that the time was
"15% more likely to be the TokenTime+1ms then the TokenTime+2ms ( for some
given accuracy and confidence level)? 
	More important, it does not prove anything anyway - the actual time
still could be anywhere within the interval, taking a single token as a
case. Which is a case. Unless you have a nice collection of a thousand
tokens, and assert the fact that at least 900 of them has the time within
the range.
	For the sake of a mental exercise, and for all practical means,
wouldn't it be sufficient to just say that "the exact time was within the
interval"? Which of course corresponds to the confidence level of 100%,
practically speaking. If your confidence level is low, then you simply
increase the interval, to bring the confidence back to 
	the 100% mark.

From: "Anders Rundgren" <[email-masked]>
To: "Stephen Kent" <[email-masked]>, "'SEIS-List'" <[email-masked]>, "'Stefan Santesson'" <[email-masked]>, <[email-masked]>
Subject: Re: QC UID support must depart from RFC2459
Date: Tue, 9 Nov 1999 19:38:38 -0000

> Stephen Kent <[email-masked]>
>
>If QCs deviate from 2459 (in its future, revised version), then there will
>be no QC profile as an IETF standard.  I assume this is obvious, but just
>wanted to inject a little reality check here.

>As for letting "the market and legislators decide," surely you are joking
>about the former.

Steve & Stefan, I have presented an overwhelming amount of real (and some anticipated)
uses of UIDs (or rather privately profiled UIDs due to the sad state of 2459).

It does not make sense to put more energy on this subject if these FACTs are not enough.

And IMO the market is more important than 2459 or QC-002.  It is like
the map and reality.  Most people stick to reality when they differ.

Anders

From: Simon Tardell <[email-masked]>
To: 
Cc: [email-masked]
Subject: RE: Timestamp: 04: comments
Date: Tue, 9 Nov 1999 18:00:30 +0100 

> > Accuracy:
> > Why is 1 second the default?  This seems an arbitrary 
> figure.  There is no
> > reason why clocks will have this accuracy instead of any 
> other.  If you
> > really want 1 s as the default, use the ASN.1 syntax to 
> specify this:
> > 	accuracy [0] Accuracy DEFAULT seconds:1
> > I suggest keeping the field optional, but with no default 
> value.  If absent,
> > no statement is made about accuracy (2 tokens from the same 
> TSA can still be
> > meaningfully compared).
> 
> If you don't make a statement about accuracy, you cannot necessarily
> compare tokens even from the same TSA.  It might be reasonable to
> think you can do this IF the TSA hasn't rebooted in between.  (Then
> again, a TSA implementer might also reasonably interpret "no
> statement" to mean "NO statement at all"...)  But if you don't have a
> known accuracy, that means you may not know what the clock will do
> across a power glitch (because your OS timekeeping clock and your NV
> clock may not match, and by not making an accuracy statement you're
> making no guarantees about any bound on that offset).

Which still doesn't answer the question why the default accuracy should be
one second. It might make sense in imperial units, but certainly not in
metric.

Next it says that "By adding the accuracy value to the GeneralizedTime, an
upper limit of the time at which the timestamp has been created by the TSA
can be obtained. In the same way...". This is of course utter nonsense. The
time we discuss here is a quantity subject to a physical measurement about
which nothing can be said with certitude. What is missing is a confidence
level. It should say something along the lines of "The time at which the
timestamp was created is between genTime-accuracy and genTime+accuracy with
a confidence level of 90%" (if we can agree on a confidence level of 90%,
which I think we cannot). The level of confidence (a percentage) could
optionally be bundled with the length of the confidence interval
("Accuracy").

On a general note (regarding accuracy), there is a problem with syntax in
that if a TSA would like to time stamp something with less accuracy than a
second it has to go through hoops. For example, lets say it matters that may
matter only what day a document was received at a registrar but not at what
time that day. Then it would be superfluous to give any hours and minutes,
and in fact it could be desirable to not to (e.g. we don't want to make it
easy to reconstruct an electronic track of a person just because we are a
TTP. To get around that the TSA would have to set the timestamp to
YYYYMMDD120000Z (or rather 12:00:00 local time translated to Z) +/- 43200 s
(12 hours). It would have been more natural to set the timestamp to (just)
YYYYMMDD+ZZZZ. However, in their infinite wisdom the founding fathers made
GeneralizedTime not general enough to be able to represent that.

Simon.

Simon Tardell, Software Architect, iD2 Technologies
[email-masked], http://www.iD2tech.com
voice +46 8 7755225, cell +46 70 3198319, fax +46 8 7267912
European IT-prize grand winners 1998 -- http://www.it-prize.org
AU-System Group Swedish IT-company of the year 1999

From: Peter Sylvester <[email-masked]>
Date: Tue, 9 Nov 1999 17:24:20 +0100 (MET)
To: [email-masked], [email-masked]
Subject: Re: Timestamp: 04: comments
Cc: [email-masked]

The current text always requests for two serialnumber sn with times t: 

   sn1 > sn2 ==> t1 >= t2

Thus the following seems to be the original idea:

- in order to compare two stamps from the same TSP,
  one can use the serialnumbers.

- Time values can be used to compare against some external date/deadline. 

In the current draft there is no definition of the purpose and the
possible interpretations of accuracy:

Assume a time t and an accuracy a.
- Does this mean that the actual time is somewhere in a interval
  t-a or t+a? 
- Or it is at least at t but may actually be later up to t+a
- or earlier back to t-a? 

What does accuracy tell about serial numbers? Can I have for example

   sn1 > sn2  and  t1 < t2+a/100  

What can be said about two time stamps with

   sn1 > sn2   and t1 - t2 < a/100 

and what can be said about a time stamp with t1 when comparing it
to a deadline t and   |t-t1| < a/100
which is the same as comparing time stamps from two authorites
with different or identical accuracy.

Peter Sylvester

 

Date: Tue, 9 Nov 1999 10:17:53 -0500
From: Paul Koning <[email-masked]>
To: [email-masked]
Cc: [email-masked]
Subject: Re: Timestamp: 04: comments

>>>>> Manger, James <[email-masked]> writes:

> Accuracy:
> Why is 1 second the default?  This seems an arbitrary figure.  There is no
> reason why clocks will have this accuracy instead of any other.  If you
> really want 1 s as the default, use the ASN.1 syntax to specify this:
> 	accuracy [0] Accuracy DEFAULT seconds:1
> I suggest keeping the field optional, but with no default value.  If absent,
> no statement is made about accuracy (2 tokens from the same TSA can still be
> meaningfully compared).

If you don't make a statement about accuracy, you cannot necessarily
compare tokens even from the same TSA.  It might be reasonable to
think you can do this IF the TSA hasn't rebooted in between.  (Then
again, a TSA implementer might also reasonably interpret "no
statement" to mean "NO statement at all"...)  But if you don't have a
known accuracy, that means you may not know what the clock will do
across a power glitch (because your OS timekeeping clock and your NV
clock may not match, and by not making an accuracy statement you're
making no guarantees about any bound on that offset).

> Serial number:
> The timestamp token now has a "monotonically increasing" field and a
> "strictly monotonically increasing field", even though the later has no
> meaning other than its strict monotonicity and the former is trivial to make
> strictly monotonic if the issuer desires.

This terminology has been discussed before; it clearly causes
confusion (especially with the redundant "strictly" thrown in, which
suggests that plain "monotonically increasing" should be
misinterpreted as "monotonically non-decreasing").  Better would be to
state the requirement in plain English.  ("If token B is generated
after token A, the serial number of B must be larger than that of A,
for all A and B.")

	paul

Reply-To: <[email-masked]>
From: "Russ Savage" <[email-masked]>
To: "Sweigert, David" <[email-masked]>, "Sungjin Lee" <[email-masked]>, <[email-masked]>
Subject: RE: Licensed Certification Authorities in USA
Date: Tue, 9 Nov 1999 07:51:57 -0700
Importance: Normal

Most states have some provision recognizing electronic signatures as
being the equivalent of a handwritten signature
(at least in some circumstance and form).

Some states may only define a form of use and say little about the CA.
Others, like Washington and Utah, license to add weight to the use.
But, as far as I know, no state requires CA licensing for
business to business use.

Most do define and manage electronic signature use involving state agencies.
That's basically just establishing and defining the minimum contract
requirements
for electronic signature interaction with those agencies.

If we haven't answered your question, email me off list and
I'll point you toward appropriate resources.

Russ Savage
Arizona's Office of the Secretary of State

-----Original Message-----
From: Sweigert, David [mailto:[email-masked]]
Sent: Tuesday, November 09, 1999 7:06 AM
To: Sungjin Lee; [email-masked]
Subject: RE: Licensed Certification Authorities in USA

Nearly each of the fifty states in the U.S. has some type of
digital signature law that allows for the provision of state
licensed C.A.s.  I belief your list is not comprehensive enough.

Dave Sweigert
General Dynamics
http://www.gd-cs.com

-----Original Message-----
From: Sungjin Lee [mailto:[email-masked]]
Sent: Tuesday, November 09, 1999 6:21 AM
To: [email-masked]
Subject: Licensed Certification Authorities in USA

I know that there are "Licensed Certification Authorities" in Utah and
Washington in USA

 - Digital Signature Trust Company, Arcanvs, USERFirst, Verisign, IC
Certify

Is there another "Licensed Certification Authority" in USA?

  Sungjin Lee

  SignKorea (http://www.signkorea.com)
  Korea Securities Computer Corp.
  Seoul, South Korea.

Content-return: allowed
Date: Tue, 09 Nov 1999 09:06:07 -0500
From: "Sweigert, David" <[email-masked]>
Subject: RE: Licensed Certification Authorities in USA
To: Sungjin Lee <[email-masked]>, [email-masked]

Nearly each of the fifty states in the U.S. has some type of
digital signature law that allows for the provision of state
licensed C.A.s.  I belief your list is not comprehensive enough.

Dave Sweigert
General Dynamics
http://www.gd-cs.com

-----Original Message-----
From: Sungjin Lee [mailto:[email-masked]]
Sent: Tuesday, November 09, 1999 6:21 AM
To: [email-masked]
Subject: Licensed Certification Authorities in USA

I know that there are "Licensed Certification Authorities" in Utah and
Washington in USA

 - Digital Signature Trust Company, Arcanvs, USERFirst, Verisign, IC
Certify

Is there another "Licensed Certification Authority" in USA?

  Sungjin Lee

  SignKorea (http://www.signkorea.com)
  Korea Securities Computer Corp.
  Seoul, South Korea.

Date: Tue, 09 Nov 1999 20:21:20 +0900
From: Sungjin Lee <[email-masked]>
To: [email-masked]
Subject: Licensed Certification Authorities in USA

I know that there are "Licensed Certification Authorities" in Utah and
Washington in USA

 - Digital Signature Trust Company, Arcanvs, USERFirst, Verisign, IC
Certify

Is there another "Licensed Certification Authority" in USA?

  Sungjin Lee

  SignKorea (http://www.signkorea.com)
  Korea Securities Computer Corp.
  Seoul, South Korea.

Date: Mon, 8 Nov 1999 11:13:37 -0500
To: "Anders Rundgren" <[email-masked]>
From: Stephen Kent <[email-masked]>
Subject: Re: QC UID support must depart from RFC2459
Cc: "'SEIS-List'" <[email-masked]>, "'Stefan Santesson'" <[email-masked]>, <[email-masked]>

Anders,

If QCs deviate from 2459 (in its future, revised version), then there will
be no QC profile as an IETF standard.  I assume this is obvious, but just
wanted to inject a little reality check here.

Steve

Date: Mon, 8 Nov 1999 11:11:18 -0500
To: "Anders Rundgren" <[email-masked]>
From: Stephen Kent <[email-masked]>
Subject: RE: QC comparisons are DEADLY serious!
Cc: <[email-masked]>, "'Stefan Santesson'" <[email-masked]>, "'SEIS-List'" <[email-masked]>

Anders,

Yes, many organizations do qualify individuals by employee, student,
payroll, or other numeric IDs.  The preferred way to make use of this
qualification is as one element of a two element set for the terminal RDN.
After all, this qualifying number is needed to uniquely identify two
individuals who would otherwise have the same DN, so it belongs in the DN.

As for letting "the market and legislators decide," surely you are joking
about the former.

Steve

Date: Mon, 08 Nov 1999 19:35:15 -0500
From: Sean Turner <[email-masked]>
Organization: IECA, Inc.
To: [email-masked]
CC: PKIX <[email-masked]>
Subject: Re: Comments on draft-ietf-pkix-ac509prof-01.txt

Stephen Farrell wrote:

snip

> > 5. Right be the additional certification path checks in clause 5 there's
> > a parenthetical that should refer to (3) vice (2).
>
> Huh?
>

It should have said "right before".  Just do a search on (2) I think it should
refer to (3).

>
> > 6.  Where is the format for the AC revocation list?  Are the revoked ACs
> > going to be put on the CRL or in some AC specific revocation list?
>
> I had hoped to avoid this. Can't we just refer to 2459? (Maybe the
> text needs additions of course.)
>

I think we really have to say what the format is.  If you are recommending
that the CRLs include revoked ACs then I think we should discuss the merits of
having them on the CRL or on a separate revocation list.

>
> Stpehen.
>
> --
> ____________________________________________________________
> Stephen Farrell
> Baltimore Technologies,   tel: (direct line) +353 1 647 7406
> 61 Fitzwilliam Lane,                    fax: +353 1 647 7499
> Dublin 2.                mailto:[email-masked]
> Ireland                             http://www.baltimore.com

Cheers,

spt

From: "Manger, James" <[email-masked]>
To: [email-masked]
Subject: Timestamp: 04: comments
Date: Tue, 9 Nov 1999 11:02:40 +1100 

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_000_01BF2A45.9FB25FB0
Content-Type: text/plain

Accuracy:
Why is 1 second the default?  This seems an arbitrary figure.  There is no
reason why clocks will have this accuracy instead of any other.  If you
really want 1 s as the default, use the ASN.1 syntax to specify this:
	accuracy [0] Accuracy DEFAULT seconds:1
I suggest keeping the field optional, but with no default value.  If absent,
no statement is made about accuracy (2 tokens from the same TSA can still be
meaningfully compared).

Token:
The timestamp token is the most important feature.  The request syntax is
far less important (it has no security associated with it).  Reorder the
draft to specify the timestamp token first, giving its syntax and explaining
the semantics for each field.  In a later section, define a protocol for
requesting a timestamp.

Serial number:
The timestamp token now has a "monotonically increasing" field and a
"strictly monotonically increasing field", even though the later has no
meaning other than its strict monotonicity and the former is trivial to make
strictly monotonic if the issuer desires.

Name:
The timestamp signer's name (often a large field) is identified in
triplicate: in the token as a "hint", in an ESSCertID authenticated
attribute, and in signerInfo.  Ditch the first, allow (but don't require)
the second and require the third.

Extensions:
Even though no critical extensions are defined you still need to state what
an application should do on receiving an unrecognized critical extension.
Better still, offer explicit extensibility via a SEQUENCE OF Attribute,
instead of Extensions.

------_=_NextPart_000_01BF2A45.9FB25FB0
Content-Type: application/ms-tnef
Content-Transfer-Encoding: base64

------_=_NextPart_000_01BF2A45.9FB25FB0--

From: "Patterson, G. Shaun" <[email-masked]>
To: "[email-masked]'" <[email-masked]>
Date: Mon, 8 Nov 1999 14:32:51 -0500 

subscribe

From: "Patterson, G. Shaun" <[email-masked]>
To: "[email-masked]'" <[email-masked]>
Date: Mon, 8 Nov 1999 13:05:05 -0500 

suscribe

From: "Nick Pope" <[email-masked]>
To: "DENIS PINKAS" <[email-masked]>, "IETF-PXIX" <[email-masked]>
Cc: "JOHN ROSS" <[email-masked]>
Subject: time-stamp ASN.1 module
Date: Mon, 8 Nov 1999 17:44:20 -0000
Importance: Normal

Can an annex be added to the time-stamp specification containing an ASN.1
module with all the ASN.1 sytax defined for timestamping.

Nick

Date: Sun, 07 Nov 1999 17:06:41 +0000
From: Stephen Farrell <[email-masked]>
Reply-To: [email-masked]
Organization: Baltimore Technologies Ltd.
To: "Linn, John" <[email-masked]>
CC: [email-masked], xme <[email-masked]>
Subject: Re: I-D ACTION:draft-ietf-pkix-laap-00.txt

Hi John,

> I'm somewhat concerned about the definition of profile strings as AC
> selectors.  If the usual practice is that profile strings' values are
> meaningful only by bilateral agreement, this implies a lot of configuration
> and could be susceptible to misinterpretation by punning, especially if/as
> LRQs grow to interact with more than just one LRP. At the risk of a
> contrived example, a Mr. Teller's name, passed as a profile hint, shouldn't
> be interpreted as soliciting a role AC allowing him to handle cash at a
> bank.  I think general use of an OID tag with optional text qualifier would
> be safer, more general, and could contribute to more effective
> interoperability among prospective LAAP peers.  Some uniform tag values
> (e.g., "role") could be usefully defined.  I'm neutral as to whether the OID
> is carried in string-encoded form or not, but believe that some level of
> syntactic structure needs to be present to distinguish the OID from any
> associated qualifier(s).

I guess this is also Dave's opinion and I'm coming around myself.

> Is the fact of LAAP's definition within CMP likely to create demultiplexing
> problems in end systems where both LAAP and CMP services are provided, but
> by different internal entities?

I'd hope not, CMP encapsulation is for discussion in DC anyway, so lets
see what happens there.

Regards,
Stephen.

-- 
____________________________________________________________
Stephen Farrell         				   
Baltimore Technologies,   tel: (direct line) +353 1 647 7406
61 Fitzwilliam Lane,                    fax: +353 1 647 7499
Dublin 2.                mailto:[email-masked]
Ireland                             http://www.baltimore.com

Date: Sun, 07 Nov 1999 16:57:59 +0000
From: Stephen Farrell <[email-masked]>
Reply-To: [email-masked]
Organization: Baltimore Technologies Ltd.
To: Sean Turner <[email-masked]>
CC: [email-masked], [email-masked], xme <[email-masked]>
Subject: Re: LAAP performance issues

Hi Sean,

> The model in the draft doesn't explicitly restrict the model to be for
> the
> "never revoke" method in draft-ietf-pkix-ac509prof-01.txt.  Should we
> add a new
> request and response to support revocation or was it intended to use
> OCSP to get
> revocation information?

No to adding one and yes to using OCSP, which works just fine for
ACs (so long as issuer names/keys don't get confused).

Regards,
Stephen.

-- 
____________________________________________________________
Stephen Farrell         				   
Baltimore Technologies,   tel: (direct line) +353 1 647 7406
61 Fitzwilliam Lane,                    fax: +353 1 647 7499
Dublin 2.                mailto:[email-masked]
Ireland                             http://www.baltimore.com

Date: Sun, 07 Nov 1999 16:52:58 +0000
From: Stephen Farrell <[email-masked]>
Reply-To: [email-masked]
Organization: Baltimore Technologies Ltd.
To: Denis Pinkas <[email-masked]>
CC: IETF-PXIX <[email-masked]>, xme <[email-masked]>
Subject: Re: Comments on ac509prof-01

Hi Denis,

Sorry to take so long to get back, but at least its before
PKIX meets:-)
 
> First of all, thanks for Stephen and Russ, for providing the
> document in time. It has a much better shape and content when
> compared to the previous version. I have however several comments:

Thanks (and, as always, thanks for taking the time to
comment).

> The document is far too authorization oriented (as the current PDAM
> from ISO). While the basic content of the document is in the right
> direction, the abstract is not appropriate. The reader does not care
> too much about the possible uses of the attribute certificates, but
> care about what they are.

We'll take this on board and re do the abstract.

> The section 4.2 about Object Identifiers is misplaced, since it is a
> recap of what is supported but no explanations are provided at this
> time about their rational.

Mostly there for editing reasons (I didn't want to muck up and miss
one, which is very easy to do). I might move it to the end and make
it some sort of summary.

> AAControls are introduced in section 4.6.1 where it is said: "
> 
>    The AAControls PKC extension, intended to be used in CA
>    and AC Issuer PKCs, *MAY* be used to help answer the question.
> 
> However in section 5 on Attribute Certificate Validation we have the
> following text:
> 
>  2. All PKC's on the path from the AA CA down to and including the
>     AC issuer's PKC *MUST* contain an aaControls extension as
> defined
>     below (the PKC with the AA CA's as subject need not contain
>     this extension).
>  3. Only those attributes in the AC which are allowed according to
>     all of the aaControls extension values in all of the PKCs from
>     the AA CA to the AC issuer, may be used for authorization
>     decisions, all other attributes MUST be ignored ...
> 
> This is contradictory. 

Nope, its taken out of context. The second list quoted only applies
"   3.   If the AC issuer is not directly trusted as an AC issuer (by
        configuration or otherwise), then the AC issuer's certification
        path must satisfy the additional PKC checks described below"
as spec'd in the first numbered list in that section. Maybe the text
could be clearer on this though.

> On page 4, we have the following paragraph:
> 
>    In other cases, it is more suitable for a client simply to
>    authenticate to the server and for the server to request ("pull")
>    the client's AC from an AC issuer or a repository. A major
> benefit
>    of the "pull" model is that it can be implemented without changes
> to
>    the client or client-server protocol. It is also more suitable
> for
>    some inter-domain cases where the client's rights should be
> assigned
>    within the server's domain, rather than within the client's
> "home"
>    domain.
> 
> It would be nice to warn the user about the disadvantages of the
> pull model. It is thus proposed to add the following after the
> second sentence.
> 
> A major disadvantage of the "pull" model is that without any change
> a receiving entity does not know which attribute certificate to use
> and thus the principle of least privilege cannot be supported. In
> addition, all attributes certificates are not necessarily public and
> thus instead of providing a complex access control scheme to
> restrict the access to those attribute certificates, the scheme is
> better suited to public attributes or to attributes used in a closed
> domain.

Rather not get re-involved in push-good, pull-bad type discussions. 
Its an explicit requirement that this specification doesn't force
one to choose between push/pull. Also, the text you suggest only 
applies if LDAP is used in the pull model, with LAAP, least privilege
and selection are again AC issuer based (if they're needed).

> At the top of page 10. The first sentence reads:
>    For any protocol where the AC is passed in an authenticated
> message ...
> 
> It should be noticed that attribute certificates are not necessarily
> used in a protocol, but also in data structures (e.g. a signed
> message). The sentence should be changed to:
> 
>    For any environment where the AC is passed in an authenticated
> message ...

ok.

> 
> Side comments
> 
> Section 4.5.1 is for legacy systems and it is questionable if the
> complexity involved by the encipherment does not negate its
> practical use.

Let's not go there again; its specified, its optional, end of story.
(I hope:-)
 
> In section 4.5.2 (Access Identity), the syntax encourages for a
> multiplicity of names, one for each service, whereas the PKI
> encourages for the reverse. In fact, in that case attribute
> certificates are not more used to carry attributes like roles, but
> names instead.

Not sure what the impact of accepting this would be, can you clarify?

Regards,
Stephen.

-- 
____________________________________________________________
Stephen Farrell         				   
Baltimore Technologies,   tel: (direct line) +353 1 647 7406
61 Fitzwilliam Lane,                    fax: +353 1 647 7499
Dublin 2.                mailto:[email-masked]
Ireland                             http://www.baltimore.com

Date: Sun, 07 Nov 1999 16:56:17 +0000
From: Stephen Farrell <[email-masked]>
Reply-To: [email-masked]
Organization: Baltimore Technologies Ltd.
To: Andy Dowling <[email-masked]>
CC: [email-masked], [email-masked], xme <[email-masked]>
Subject: Re: LAAP performance issues

Hi Andy,

> 1. Batch LAAP requests. 

Rather not, unless there's strong concensus. Remember that the
"L" in LAAP is for Limited. I expect that, in time, we'll have
a CMP/CMC equivalent which can handle this.

> 2.  Support for a "keep-alive" TCP connection between LRQ and LRP.

I hope that this will be discussed in DC, but in general, if the CMP
encapsulation is kept, then whatever CMP does will apply to LAAP.

Regards,
Stephen.

-- 
____________________________________________________________
Stephen Farrell         				   
Baltimore Technologies,   tel: (direct line) +353 1 647 7406
61 Fitzwilliam Lane,                    fax: +353 1 647 7499
Dublin 2.                mailto:[email-masked]
Ireland                             http://www.baltimore.com

From: Warwick Ford <[email-masked]>
To: [email-masked]
Subject: Washington PKIX Agenda
Date: Sun, 7 Nov 1999 14:55:05 -0800 

Here is the draft agenda for the Washington meeting.  Please advise any
agenda change requests directly to Steve and me.

*	Introduction; Project Status; Agenda
*	Briefing on X.509 Revision (Sharon)
*	Active Projects:
*	  New Part 1 & ECDSA
*	  Qualified Certificates
*	  PKIX Roadmap
*	  Timestamp Protocol
*	  LDAP v3 Profile
*	  Attribute Certificates
*	  DCS, SCVP, and OCSP Extensions
*	  CMP Transports
*	Other Items
*	  CMP Interoperability (Bob Moskowitz)
*	  ETSI Electronic Signatures (Denis)
*	Any other business
*	Joint Meeting with ABA Info Sec Ctee (Thursday)

Warwick

---------------------------------------------------------------------
Warwick Ford, VeriSign Inc. Tel MA:(781)2456996 x225; CA:(650)4293445
           301 Edgewater Pl, Suite 210, Wakefield, MA 01880
Pager: (800)6937243       [email-masked]         Fax (781)2456006
---------------------------------------------------------------------

From: "Anders Rundgren" <[email-masked]>
To: "'SEIS-List'" <[email-masked]>, "'Stefan Santesson'" <[email-masked]>, <[email-masked]>
Cc: "Magnus (RSA)" <[email-masked]>, "Phillip M Hallam-Baker" <[email-masked]>, <[email-masked]>
Subject: QC: VERISIGN uses UIDs!
Date: Sun, 7 Nov 1999 15:31:41 -0000

Hi,
Just to make sure that you get the message that the commercial world (in spite
of what has been said on this list and SHALL NOTs in RFC2459) actually
need (and already use) unique identities of the kind that I propose.  

http://www.verisign.com/press/1999/partner/eccelerate.html

A 59M+ possible market!!!  So there are not only a few "disturbed, morons" like
me who require this.

>From a trusted source I have heard that unique identifiers also will be the case for WAP-certs.
Du U really think that you for each cert renewal will get a new UID?  That would
be as clever as getting new telephone numbers all time!

So if RFC2459 says SHALL NOT and QC-002 says certificates can't be compared,
the commercial world appararently does not give a s**t about that.

So why not adapt QC for COMMERCIAL needs and make this a described
and supported feature as well???

And maybe the revised 2459 as well?

Anders

-----Original Message-----
From: Anders Rundgren <[email-masked]>
To: 'SEIS-List' <[email-masked]>; 'Stefan Santesson' <[email-masked]>; [email-masked] <[email-masked]>
Cc: Magnus (RSA) <[email-masked]>
Date: Friday, November 05, 1999 17:27
Subject: QC UID support must depart from RFC2459

>
>>Stephen Kent <[email-masked]>
>>
>>In version 2 X.509 certs there was a field added for unique subject and
>>issuer IDs.  It was a bad idea, designed to address what appear to be some
>>of the issues you alluded to above; nobody uses it.  I don't think we
>>should include a similar facility in a QC.  You'll note that 2459
>>explicitly disparages use of the v2 UIDs.
>
>
>It is not hard to see why SEIS made a private profile given all the pointing fingers rubbish
>with (totatlly unmotivated) SHALL NOT etc.
>
>In order to support unique identity IDs in a CONFORMANT way there is no other way
>(due to RFC2459) than to REDEFINE this in QC.
>
>It cpuld be a new extension or reconsidered old one.  As "nobody" used the old one
>I think a new one according to the ANSI/WIM-lines should be most appropriate.
>
>Like OCTET STRING (1..16)
>
>Anders
>
>
>
>

Date: Sat, 06 Nov 1999 14:59:11 -0500
To: [email-masked], [email-masked]
From: "David A. Cooper" <[email-masked]>
Subject: FYI: Announcement of a security requirements document for CAs

All,

Over the past year, NIST has been working to write a security requirements
document for Certificate Issuing and Management Systems (e.g., CA hardware
and software). The goal of this document is to specify security requirements
(e.g., audit, archive, I&A, etc.) for products that are to be used to issue, revoke
and otherwise manage public-key certificates.

A first draft of the security requirements document is now available from our Web site:

		http://csrc.nist.gov/pki/secreqmts/welcome.html

If you have an opportunity to read this document, we would appreciate any comments
that you may have.

Thank you,
David Cooper

Date: Fri, 5 Nov 1999 16:05:34 -0500
From: Paul Koning <[email-masked]>
To: [email-masked]
Cc: [email-masked]
Subject: RE: PKIX: String representation of GeneralName

>>>>> "Manger" == Manger, James <[email-masked]> writes:

 Manger> Amit, There is already a standardized string representation
 Manger> of GeneralName values.  It is ASN.1 value notation.  As
 Manger> stated in the X.680 summary, ASN.1 provides "a notation
 Manger> .. for specifying values of these [ASN.1] types".  Almost
 Manger> all specifications defining ASN.1 types also use value
 Manger> notation to define some values, e.g. object identifier
 Manger> values, version values, default values, algorithm identifier
 Manger> values etc.

 Manger> Below are the examples from your draft in value notation:
 Manger> ...
 Manger> iPAddress:'C0A8000A'H

I think Amit is right to submit a spec of his own if this is the
alternative.  Any document that attempts to propose a "standard"
notation for IPv4 addresses as 8-digit hex strings is clearly broken.

An alternative would be to have that document repaired so it shows the
correct representation for IP addresses.  If that is done, the need
for Amit's draft may disappear.

	paul

From: Carlisle Adams <[email-masked]>
To: "[email-masked]'" <[email-masked]>
Cc: [email-masked]
Subject: RE: Last Call: Diffie-Hellman Proof-of-Possession Algorithms to P roposed Standard
Date: Fri, 5 Nov 1999 15:54:47 -0500 

Hello,

I realize that this is past the deadline for comments, but I've finally had
a chance to look at this draft in some detail.  I agree with the
comments/suggestions made by Denis Pinkas (on the PKIX list, dated Oct.
26th) and add two more comments.

1) On the bottom of page 2:  given the notation defined in items 1 and 2,
the notation given in item 3 is incorrect.  The sentence "[This is done by
the entity E as g^(y.Rpub) and by the Recipient as g^(x.Epub), ...]" should
be replaced with "[This is done by the entity E as Rpub^y and by the
Recipient as Epub^x, ...]".

2) Near the bottom of page 5:  in item 3 it says "If L @ 160".  I assume
this should be "If L > 160"?

The draft should not progress to Proposed Standard unless these typos are
corrected since they are required for clarity and correctness.

Carlisle.

> ----------
> From: 	The IESG[SMTP:[email-masked]]
> Reply To: 	[email-masked]
> Sent: 	Wednesday, October 13, 1999 7:32 AM
> To: 	IETF-Announce
> Cc: 	[email-masked]
> Subject: 	Last Call: Diffie-Hellman Proof-of-Possession Algorithms to
> Proposed Standard
> 
> The IESG has received a request from the Public-Key Infrastructure
> (X.509) Working Group to consider Diffie-Hellman Proof-of-Possession
> Algorithms <draft-ietf-pkix-dhpop-02.txt> as a Proposed Standard.
> 
> The IESG plans to make a decision in the next few weeks, and solicits
> final comments on this action.  Please send any comments to the
> [email-masked] or [email-masked] mailing lists by October 27, 1999.
> 
> Files can be obtained via
> http://www.ietf.org/internet-drafts/draft-ietf-pkix-dhpop-02.txt
> 
> 

From: "Amit Kapoor" <[email-masked]>
To: "PKIX" <[email-masked]>
Subject: FW: PKIX: String representation of GeneralName
Date: Fri, 5 Nov 1999 12:50:52 -0800
Importance: Normal

This is a multi-part message in MIME format.

------=_NextPart_000_002C_01BF278C.64975FD0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit

	And here I thought I was doing the right thing by signing my
	messages...:-)
	All right...(and before Peter Gutman responds ;-)), I am sending
	the message again.

-----------------------------

Hi James,

	You are right, in that there is a standardized string representation for
	any ASN.1 object.  However here are our reasons for not using it, and
	I believe your examples demonstrate the same:

1.	It is not user readable as in the IPAddress.  I think it will be a wee
	bit difficult for someone
	to translate the hex form to the standard and more friendly dotted form.
2.	DN name representation. (BTW, thanks to Tom Gindin@IBM, we have changed
	to RFC 2253 for UTF8 support)

	Instead of trying to mix and match two separate schemes, we tried to come
	up with one single scenario.   We also added "intuitive format" as one of
	the goals upfront.  You have also proposed the same to some extent, and
what
	we are disagreeing on is which is more "intuitive".

	regards

Amit

--------------------------------------------------------------------------
-----------------------------------------------

Amit,

There is already a standardized string representation of GeneralName
values.  It is ASN.1 value notation.  As stated in the X.680 summary,
ASN.1 provides "a notation .. for specifying values of these [ASN.1]
types".  Almost all specifications defining ASN.1 types also use value
notation to define some values, e.g. object identifier values, version
values, default values, algorithm identifier values etc.

Below are the examples from your draft in value notation:

	rfc822Name:"[email-masked]"

	dNSName:"gandalf.trustpoint.com"

	uniformResourceIdentifier:"http://www.trustpoint.com/"

	iPAddress:'C0A8000A'H

	registeredId:{ 1 2 3 4 5 6 }

Value notation looks very similar to the notation in draft-generalname.txt
for most general name choices.  The major exception is directory name.  A
directory name has such a rich syntax (an ordered collection of levels,
each with 1 or more values, each value with an arbitrary type) that it is
always going to be awkward to devise a human-friendly notation for all
possible values.  So it is probably reasonable to use RFC 1779 [DN] for
this choice:

	directoryName:CN=Amit Kapoor, O=Trustpoint, L=Mountain View,
ST=California, C=US

Your labels (e.g. "mail", "ip") may seem easier than the value notation
labels (e.g. "rfc822Name", "iPAddress") but the later match precisely &
obviously to fields in the type definition.  You get value notation for
free whenever a new ASN.1 type is defined.  Value notation offers a
notation for all the GeneralName choices (e.g. otherName), not just the 6
your draft lists.  Value notation offers a notation for all possible
values (e.g. values with unusual or unprintable characters).  It is likely
that anyone wanting a text representation for GeneralName values today
will want a text representation for values of another ASN.1 type tomorrow
so value notation, which works for all ASN.1 types, is preferable.

----------
From: 	Amit Kapoor[SMTP:[email-masked]]
Sent: 	Tuesday, 2 November 1999 9:34
To: 	PKIX
Subject: 	String representation of GeneralName

a draft to document a string representation of GeneralName

	http://www.trustpoint.com/draft-generalname.txt

-----------------------------------------------------
Certificate Authority: http://www.smeme.com
CA root : http://www.smeme.com/faq_operational.html#16
-----------------------------------------------------

------=_NextPart_000_002C_01BF278C.64975FD0
Content-Type: application/ms-tnef;
	name="winmail.dat"
Content-Transfer-Encoding: base64
Content-Disposition: attachment;
	filename="winmail.dat"

------=_NextPart_000_002C_01BF278C.64975FD0--

From: "Amit Kapoor" <[email-masked]>
To: "PKIX" <[email-masked]>
Subject: FW: PKIX: String representation of GeneralName
Date: Fri, 5 Nov 1999 12:35:10 -0800
Importance: Normal

From: "Anders Rundgren" <[email-masked]>
To: "'SEIS-List'" <[email-masked]>, "'Stefan Santesson'" <[email-masked]>, <[email-masked]>
Cc: "Magnus (RSA)" <[email-masked]>
Subject: QC UID support must depart from RFC2459
Date: Fri, 5 Nov 1999 18:25:52 -0000

>Stephen Kent <[email-masked]>
>
>In version 2 X.509 certs there was a field added for unique subject and
>issuer IDs.  It was a bad idea, designed to address what appear to be some
>of the issues you alluded to above; nobody uses it.  I don't think we
>should include a similar facility in a QC.  You'll note that 2459
>explicitly disparages use of the v2 UIDs.

It is not hard to see why SEIS made a private profile given all the pointing fingers rubbish
with (totatlly unmotivated) SHALL NOT etc.

In order to support unique identity IDs in a CONFORMANT way there is no other way
(due to RFC2459) than to REDEFINE this in QC.

It cpuld be a new extension or reconsidered old one.  As "nobody" used the old one
I think a new one according to the ANSI/WIM-lines should be most appropriate.

Like OCTET STRING (1..16)

Anders

From: Scott Cadzow <[email-masked]>
To: "'Phillip M Hallam-Baker'" <[email-masked]>, [email-masked]
Subject: RE: Possible patent issue with UTCTime hack
Date: Fri, 5 Nov 1999 16:13:43 -0000 

If it is fundemental it may not be enforcable as a patent. Consider the
wheel.

-----Original Message-----
From: Phillip M Hallam-Baker [mailto:[email-masked]]
Sent: 05 November 1999 17:11
To: [email-masked]
Subject: RE: Possible patent issue with UTCTime hack

> >It seems that McDonnell Douglas has patented the date "windowing" that is
> >used to get around Y2K problems:

A thought just occurred to me. The company that now "owns" this hack is
contacting companies systematically asserting the technique to be so
fundamental, so obvious that they MUST be using it...

	Phill

From: "Phillip M Hallam-Baker" <[email-masked]>
To: <[email-masked]>
Subject: RE: Possible patent issue with UTCTime hack
Date: Fri, 5 Nov 1999 11:11:18 -0500
Importance: Normal

> >It seems that McDonnell Douglas has patented the date "windowing" that is
> >used to get around Y2K problems:

A thought just occurred to me. The company that now "owns" this hack is
contacting companies systematically asserting the technique to be so
fundamental, so obvious that they MUST be using it...

	Phill

Date: Fri, 05 Nov 1999 09:06:40 -0500
From: Mike Williams <[email-masked]>
To: pkix <[email-masked]>
Subject: Agenda for wg

Is the agenda for the pkix wg meeting available yet?

From: "Parag Namjoshi" <[email-masked]>
To: "Denis Pinkas" <[email-masked]>
Cc: "IETF-PXIX" <[email-masked]>
Subject: Re: Comments on ETNRT
Date: Fri, 5 Nov 1999 18:50:08 +0530

Hi Dennis,

I am changing the title (again) to ETNRT. Never figured out what ETNPT was
:-).

> I still have difficulties to understand the rational for the (rather
> complex) scheme that is presented. The basic time stamping protocol
> provides a token (TST) that allows to make sure before which time a
> document and/or a certificate was signed. If some signed data needs
> to be protected by a time stamp, it seems more natural to append the
> TST to the data structure rather than going down a tree of
> "NRStorage".

> In addition, the data structure that is presented is twice
> recursive. :-(

The scheme in its entirity is indeed complex. The structure reflects the
complexities introduced due to the long period of time over over which the
tokens may remain valid. During this periods the "maintainance" of the token
may have to be taken over by different entity. Multiple copies of the token
may exist & may have to be reconciled. The format allows to create "chain of
custody" for the token as it's updated by different entities (eg.
responsibility
of maintanance of token may change or two tokens for same data may be
combined
and maintained as one after living separartely for some time). The format
will
provide *additional evidence* about the token,its managers and their
diligence.

But everyone need not use it to complete extent.
Implementations will have varying levels of complexity .
The simplest ones will just use the scheme to validate tokens with
comparatively smaller lifetimes to tide over imminent key update.
(In fact this will be the most common usage of the format)
In this case format will degenerate to simple pair of tokens. Even
timeToNextUpdate need not be present.

Smarter implementations will have chaining (ie appending
as you suggest) to provide basic functionality.A full featured
implementation
will support management of complete trees and may well go beyond that by
using policies to reconcile trees from different servers.

> Thus I am wondering the need for such a document. If you are present
> in Washington,

No I won't be there :(

Regards,
Parag.

>I would appreciate a talk on that topic.

> Regards,

> Denis

Date: Thu, 04 Nov 1999 17:02:46 -0800
From: Mack Hicks <[email-masked]>
Subject: Real Life Example - RFC822 in a mergered firm
Cc: [email-masked], [email-masked]

This is a cryptographically signed message in MIME format.

--------------ms90BE228F95E2D9D1FFFEC207
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

To: IETF PKIX list, IETF SMIME list,

This is all too familiar to those of you who follow these lists, but I could not
resist sharing my own "troubles."

Since Bank of America (BankAmerica.com) and NationsBank (NationsBank.com)
merged, the preferred domain for email is BankofAmerica.com.  Our kind email
gateway changes all the outbound (and inbound) names for us so that internally
we are still using the two old domains.  (See signature validation messages on
this S/MIME signed message.)

We have also implemented the SMTP sender authentication mechanism so I must
remain
     [email-masked]
internally.

But you can all call me: Mack
See you in DC.

--
-------------------------------------------------------------------
Mack Hicks, SVP     [email-masked]  ;-)
Bank of America, San Francisco, CA USA

--------------ms90BE228F95E2D9D1FFFEC207
Content-Type: application/x-pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature

--------------ms90BE228F95E2D9D1FFFEC207--

From: Greg Colla <[email-masked]>
To: [email-masked], [email-masked]
Subject: RE: Comparing rfc822 addresses to certificates
Date: Fri, 5 Nov 1999 10:46:24 +1100 

Bob's e-mail has triggered a couple of other issues with RFC822 addresses
and certificates that have been doing the rounds here.

Does it need to be an RFC822 address?
Probably not. Here's an example. A closed user group that are using a
proprietary mail system wish to use S/MIME. In this case, each user's
proprietary mail address would be sufficient in both the certificate's
subjectAltName field and message's From address fields for the sender/signer
comparison. 

Does there need to be a comparison?
Definitely yes. We need to ensure that the recipient is warned that the
signer is not the sender, even though the message can be verified.

Are there exceptions?
Also yes. 
1. Quite often when companies change name or merge, each user will be given
another e-mail address. to make the make PKI system more useable, we don't
want to enforce key and cert rolling for the whole organisation - they
probably have enough problems without us adding to it ;-)
One solution is that the users associate secondary addresses to
certificates. This must be a secure association, the user will know if it
has been tampered with. If a message is received where the sender's address
is equivalent to the address in the cert, or an address associated with the
cert, then no warning is given.

2. Domain signing. In some installations, a domain gateway is used to sign
on behalf of the sender as it exits the domain. In this case, the address in
the domain's signing cert won't match the originator's address. (Refer to
the DOMSEC draft for further info). The receiving client needs to compensate
for this. There are various work-arounds for this, including (A) the
generation of certificates on-the-fly, each with the same public key, but
different e-mail addresses, (B) association of users' addresses with the
domain's certificate on the recipient's client and (C) the DOMSEC methods.

3. Countersigning and co-signing. This is a big enough issue by itself and
can be left for a later date.

So the conclusion is that there should be a sender/signer comparison,
although the comparison may not be direct.

Greg

-----Original Message-----
From: Bob Jueneman [mailto:[email-masked]]
Sent: Friday, November 05, 1999 5:35 AM
To: [email-masked]; [email-masked]
Cc: [email-masked]
Subject: Comparing rfc822 addresses to certificates

>[email-masked] writes:
>
>>Contrary to how most public CAs do it, at least so far, the e-mail address
is
>>included in the subjectAltName as per the PKIX RFC, and to our pleasant
>>surprise all of the e-mail packages we have encountered to date have been 
>>able to handle that format correctly.
>>
>>Although we could have, we chose not to include an e-mail address of the
form
>>subjectAltName="Robert R. Jueneman" <[email-masked]> , in part
because
>>most e-mail packages would just as easily accept "President William
Jefferson
>>Clinton" <[email-masked]>. 
>
>D'you mean they'll accept that as an rfc822Name?  Are they supposed to do
that?
>Peter.
Let me clarify that.  I haven't tested that exhaustively across multiple 
packages, but I believe that e-mail packages generally ignore the "junk" 
prior to the rfc822 mailbox name itself, both on message origin and 
message receipt.

Many packages I am familiar with allow you to specify your own From address 
one way or the other, even though you may not be able to change the 
portion of the address within the angle brackets.

They may or may not reflect that name in the From address that is 
presented in the message window or header line, but I believe that most do.

Certainly it appears that you can put anything you wish in front of the
address, and the message will be both sent and received successfully.

That being the case, I doubt that many would complain about a 
mismatched rfc822 address in the certificate in that case, but I don't
know that for a fact.

Now, SHOULD they?  Honestly, I'm not sure.

Browsing through rfc822, I find the following snippets of definitions:

  4.4.1.  FROM / RESENT-FROM

        This field contains the identity of the person(s)  who  wished
        this  message to be sent.  The message-creation process should
        default this field  to  be  a  single,  authenticated  machine
        address,  indicating  the  AGENT  (person,  system or process)
        entering the message.  If this is not done, the "Sender" field
        MUST  be  present.  If the "From" field IS defaulted this way,
        the "Sender" field is  optional  and  is  redundant  with  the
        "From"  field.   In  all  cases, addresses in the "From" field
        must be machine-usable (addr-specs) and may not contain  named
        lists (groups).

6.1.  SYNTAX

     address     =  mailbox                      ; one addressee
                 /  group                        ; named list

     group       =  phrase ":" [#mailbox] ";"

     mailbox     =  addr-spec                    ; simple address
                 /  phrase route-addr            ; name & addr-spec

     route-addr  =  "<" [route] addr-spec ">"

     route       =  1#("@" domain) ":"           ; path-relative

     addr-spec   =  local-part "@" domain        ; global address

     local-part  =  word *("." word)             ; uninterpreted
                                                 ; case-preserved

     domain      =  sub-domain *("." sub-domain)

     sub-domain  =  domain-ref / domain-literal

     domain-ref  =  atom                         ; symbolic reference

phrase      =  1*word                       ; Sequence of words

     word        =  atom / quoted-string

Parentheses ("(" and ")") are used  to  indicate  comments.

So ignoring the optional route indicator, which I haven't seen used 
for at least five years, and excluding groups as required by the 
semantics of From, we have as an allowable From address:

address = mailbox  

mailbox = addr-spec /
                 phrase route-addr

route-addr = <addr-spec>

Unfortunately, the semantics of "phrase" or "word" don't seem 
to be defined, but the implication seems to be that they are the name of 
the originator in the case of a From or Sender field, and the name or
name of the desired recipient(s) in the case of a To or Cc field. This of 
course gets even more complicated in the case of a shared mailbox,
as might be the case for a family.

Since the form of the "name" isn't defined, I have to assume that 
"phrase" is essentially syntactic sugar, to be interpreted by the 
human user.

So I conclude that the following are all legitimate rfc822 From addresses:

[email-masked] 

Steve [email-masked] 

Stephen [email-masked] 

Also,

Bob Jueneman <[email-masked]>

"Robert R. Jueneman" <[email-masked]> 

Robert "R." (Bob) Jueneman (the one who is not the 
horse thief) <[email-masked]> 

However, as a message from Tom Gindin points out (and 
I'll take his word for it without checking the text of RFC 
2459 section 4.2.1.7), PKIX defines an rfc822 attribute 
within GeneralName as an addr-spec, NOT an "address".

The S/MIME spec also states that the end-entity certificates 
MUST contain an Internet mail address, and that the 
address must be an "addr-spec" as defined in Section 6.1.

X.509, however, is ambiguous, and needs to be corrected.

So that seems clear, now.  The above constructs would NOT be
legal as an rfc822 type DN or subjectAltName, although I strongly
suspect that many CAs and CA toolkits would accept them and
create certificates containing them.

Unfortunately, this leaves us with the case where the e-mail
package, if it performs correctly, will accept a message with
a From address of 

From: "President William Jefferson Clinton                         " 
(note the extra spaces, intended to cause truncation of the 
name -- it's really slick Bob in disguise) <[email-masked]> 

and then it will compare just the <[email-masked]> to the 
subjectAltName in my certificate and conclude that all is well,
since the addr-spec in the From matches the content of the attribute
in the certificate.

Worse yet, since some mail programs don't bother to display
the "real" addr-spec, but only the name portion, and most will
truncate even the name if it's too long, the recipient may not see 
that anything is amiss at all.

The S/MIME v2 Certificate Handling spec  (3.1, last paragraph) 
states that "... Receiving agents MUST check that the address (sic) 
in the From header of a mail message matches an Internet mail 
address in the signer's certificate. ..."

That's somewhat ambiguous, since the "address" portion of a From 
address is clearly the more general mailbox name.  But clarifying 
the S/MIME spec by requiring that the addr-spec portion of the 
>From address match the addr-spec in the certificate would 
merely highlight the problem, not solve it.

So we clearly have a problem where the relying party may be 
accidentally or even deliberately mislead, unless he is particularly 
careful to compare the full From address (which may only be 
available by looking at the mime.822 view of the message) against 
the certificate content.

What should we do?  I'm not quite sure, but I'm concerned.

Bob

From: Peter Sylvester <[email-masked]>
Date: Thu, 4 Nov 1999 20:20:44 +0100 (MET)
To: [email-masked], [email-masked]
Subject: RE: QC certificates and Nationality
Cc: [email-masked]

> 
> >But we are living in a world leaning toward XML, where non-validated
> >character fields reign :-).  How many implementations today actually
> >contain a table of 3166 digraphs, and how many just accept any two
> >PrintableString characters for the CountryName attribute?

And how many implementation treat  US, us, Us, uS in the same way :-)
> 
> In case anyone else needs this:
> 
> /* Check that a country code is valid */
> 

With Peter's example you cannot validate a document that was signed
in 1990 somewhere in Germany. There was a country code DD. 

I just remember that in 1991 I had to setup a rather strange 
mapping table for an X.400 gateway with one (and almost identical) 
mapping rule for each country. I simply ended up with 26*26 
rules. :-)

Why and where do you actually want to verify a country code?
Well, only if you say, all, except for the following n:
(arbitrary list of your favorites to be included here, WW, NN for example)

Date: Thu, 04 Nov 1999 11:34:54 -0700
From: "Bob Jueneman" <[email-masked]>
To: <[email-masked]>, <[email-masked]>
Cc: <[email-masked]>
Subject: Comparing rfc822 addresses to certificates

>[email-masked] writes:
>
>>Contrary to how most public CAs do it, at least so far, the e-mail address is
>>included in the subjectAltName as per the PKIX RFC, and to our pleasant
>>surprise all of the e-mail packages we have encountered to date have been 
>>able to handle that format correctly.
>>
>>Although we could have, we chose not to include an e-mail address of the form
>>subjectAltName="Robert R. Jueneman" <[email-masked]> , in part because
>>most e-mail packages would just as easily accept "President William Jefferson
>>Clinton" <[email-masked]>. 
>
>D'you mean they'll accept that as an rfc822Name?  Are they supposed to do that?
>
>Peter.
>
Let me clarify that.  I haven't tested that exhaustively across multiple 
packages, but I believe that e-mail packages generally ignore the "junk" 
prior to the rfc822 mailbox name itself, both on message origin and 
message receipt.

Many packages I am familiar with allow you to specify your own From address 
one way or the other, even though you may not be able to change the 
portion of the address within the angle brackets.

They may or may not reflect that name in the From address that is 
presented in the message window or header line, but I believe that most do.  

Certainly it appears that you can put anything you wish in front of the
address, and the message will be both sent and received successfully.

That being the case, I doubt that many would complain about a 
mismatched rfc822 address in the certificate in that case, but I don't
know that for a fact.

Now, SHOULD they?  Honestly, I'm not sure.

Browsing through rfc822, I find the following snippets of definitions:

  4.4.1.  FROM / RESENT-FROM

        This field contains the identity of the person(s)  who  wished
        this  message to be sent.  The message-creation process should
        default this field  to  be  a  single,  authenticated  machine
        address,  indicating  the  AGENT  (person,  system or process)
        entering the message.  If this is not done, the "Sender" field
        MUST  be  present.  If the "From" field IS defaulted this way,
        the "Sender" field is  optional  and  is  redundant  with  the
        "From"  field.   In  all  cases, addresses in the "From" field
        must be machine-usable (addr-specs) and may not contain  named
        lists (groups).

6.1.  SYNTAX

     address     =  mailbox                      ; one addressee
                 /  group                        ; named list

     group       =  phrase ":" [#mailbox] ";"

     mailbox     =  addr-spec                    ; simple address
                 /  phrase route-addr            ; name & addr-spec

     route-addr  =  "<" [route] addr-spec ">"

     route       =  1#("@" domain) ":"           ; path-relative

     addr-spec   =  local-part "@" domain        ; global address

     local-part  =  word *("." word)             ; uninterpreted
                                                 ; case-preserved

     domain      =  sub-domain *("." sub-domain)

     sub-domain  =  domain-ref / domain-literal

     domain-ref  =  atom                         ; symbolic reference

phrase      =  1*word                       ; Sequence of words

     word        =  atom / quoted-string

Parentheses ("(" and ")") are used  to  indicate  comments.

So ignoring the optional route indicator, which I haven't seen used 
for at least five years, and excluding groups as required by the 
semantics of From, we have as an allowable From address:

address = mailbox  

mailbox = addr-spec /
                 phrase route-addr

route-addr = <addr-spec>

Unfortunately, the semantics of "phrase" or "word" don't seem 
to be defined, but the implication seems to be that they are the name of 
the originator in the case of a From or Sender field, and the name or
name of the desired recipient(s) in the case of a To or Cc field. This of 
course gets even more complicated in the case of a shared mailbox,
as might be the case for a family.

Since the form of the "name" isn't defined, I have to assume that 
"phrase" is essentially syntactic sugar, to be interpreted by the 
human user.

So I conclude that the following are all legitimate rfc822 From addresses:

[email-masked] 

Steve [email-masked] 

Stephen [email-masked] 

Also,

Bob Jueneman <[email-masked]>

"Robert R. Jueneman" <[email-masked]> 

Robert "R." (Bob) Jueneman (the one who is not the 
horse thief) <[email-masked]> 

However, as a message from Tom Gindin points out (and 
I'll take his word for it without checking the text of RFC 
2459 section 4.2.1.7), PKIX defines an rfc822 attribute 
within GeneralName as an addr-spec, NOT an "address".

The S/MIME spec also states that the end-entity certificates 
MUST contain an Internet mail address, and that the 
address must be an "addr-spec" as defined in Section 6.1.

X.509, however, is ambiguous, and needs to be corrected.

So that seems clear, now.  The above constructs would NOT be
legal as an rfc822 type DN or subjectAltName, although I strongly
suspect that many CAs and CA toolkits would accept them and
create certificates containing them.

Unfortunately, this leaves us with the case where the e-mail
package, if it performs correctly, will accept a message with
a From address of 

From: "President William Jefferson Clinton                         " 
(note the extra spaces, intended to cause truncation of the 
name -- it's really slick Bob in disguise) <[email-masked]> 

and then it will compare just the <[email-masked]> to the 
subjectAltName in my certificate and conclude that all is well,
since the addr-spec in the From matches the content of the attribute
in the certificate.

Worse yet, since some mail programs don't bother to display
the "real" addr-spec, but only the name portion, and most will
truncate even the name if it's too long, the recipient may not see 
that anything is amiss at all.

The S/MIME v2 Certificate Handling spec  (3.1, last paragraph) 
states that "... Receiving agents MUST check that the address (sic) 
in the From header of a mail message matches an Internet mail 
address in the signer's certificate. ..."

That's somewhat ambiguous, since the "address" portion of a From 
address is clearly the more general mailbox name.  But clarifying 
the S/MIME spec by requiring that the addr-spec portion of the 
>From address match the addr-spec in the certificate would 
merely highlight the problem, not solve it.

So we clearly have a problem where the relying party may be 
accidentally or even deliberately mislead, unless he is particularly 
careful to compare the full From address (which may only be 
available by looking at the mime.822 view of the message) against 
the certificate content.

What should we do?  I'm not quite sure, but I'm concerned.

Bob

From: [email-masked] (Peter Gutmann)
To: [email-masked]
Subject: RE: QC certificates and Nationality
Sender: [email-masked]
Reply-To: [email-masked]
Date: Fri, 5 Nov 1999 07:00:24 (NZDT)

"David P. Kemp" <[email-masked]>

>But we are living in a world leaning toward XML, where non-validated
>character fields reign :-).  How many implementations today actually
>contain a table of 3166 digraphs, and how many just accept any two
>PrintableString characters for the CountryName attribute?

In case anyone else needs this:

/* Check that a country code is valid */

static BOOLEAN checkCountryCode( const char *countryCode )
	{
	const static char *countryCodes[] = {
		"AD", "AE", "AF", "AG", "AI", "AL", "AM", "AN", "AO", "AQ",
		"AR", "AS", "AT", "AU", "AW", "AZ", "BA", "BB", "BD", "BE",
		"BF", "BG", "BH", "BI", "BJ", "BM", "BN", "BO", "BR", "BS",
		"BT", "BV", "BW", "BY", "BZ", "CA", "CC", "CF", "CG", "CH",
		"CI", "CK", "CL", "CM", "CN", "CO", "CR", "CU", "CV", "CX",
		"CY", "CZ", "DE", "DJ", "DK", "DM", "DO", "DZ", "EC", "EE",
		"EG", "EH", "ER", "ES", "ET", "FI", "FJ", "FK", "FM", "FO",
		"FR", "FX", "GA", "GB", "GD", "GE", "GF", "GH", "GI", "GL",
		"GM", "GN", "GP", "GQ", "GR", "GS", "GT", "GU", "GW", "GY",
		"HK", "HM", "HN", "HR", "HT", "HU", "ID", "IE", "IL", "IN",
		"IO", "IQ", "IR", "IS", "IT", "JM", "JO", "JP", "KE", "KG",
		"KH", "KI", "KM", "KN", "KP", "KR", "KW", "KY", "KZ", "LA",
		"LB", "LC", "LI", "LK", "LR", "LS", "LT", "LU", "LV", "LY",
		"MA", "MC", "MD", "MG", "MH", "MK", "ML", "MM", "MN", "MO",
		"MP", "MQ", "MR", "MS", "MT", "MU", "MV", "MW", "MX", "MY",
		"MZ", "NA", "NC", "NE", "NF", "NG", "NI", "NL", "NO", "NP",
		"NR", "NU", "NZ", "OM", "PA", "PE", "PF", "PG", "PH", "PK",
		"PL", "PM", "PN", "PR", "PT", "PW", "PY", "QA", "RE", "RO",
		"RU", "RW", "SA", "SB", "SC", "SD", "SE", "SG", "SH", "SI",
		"SJ", "SK", "SL", "SM", "SN", "SO", "SR", "ST", "SV", "SY",
		"SZ", "TC", "TD", "TF", "TG", "TH", "TJ", "TK", "TM", "TN",
		"TO", "TP", "TR", "TT", "TV", "TW", "TZ", "UA", "UG", "UM",
		"US", "UY", "UZ", "VA", "VC", "VE", "VG", "VI", "VN", "VU",
		"WF", "WS", "YE", "YT", "YU", "ZA", "ZM", "ZR", "ZW", NULL
		};
	int i;

	/* Check that the country code is present in the table of known codes */
	for( i = 0; countryCodes[ i ] != NULL; i++ )
		if( !strcmp( countryCode, countryCodes[ i ] ) )
			return( TRUE );
	return( FALSE );
	}

This was valid as of a few years back, I'll probably need to update it when
Zklfguifstan, Okjhdfuihrgbec, and the Republic of Msdgfguidfgr declare
independence.

Peter.

Date: Thu, 4 Nov 1999 12:28:56 -0500 (EST)
From: "David P. Kemp" <[email-masked]>
Reply-To: "David P. Kemp" <[email-masked]>
Subject: RE: QC certificates and Nationality
To: [email-masked]
Content-MD5: LGD9w2seCyBZ3b5OzQI0rQ==

Bob,

In an ideal world, I too would prefer a single INTEGER type.

But we are living in a world leaning toward XML, where non-validated
character fields reign :-).  How many implementations today actually
contain a table of 3166 digraphs, and how many just accept any two
PrintableString characters for the CountryName attribute?

Look at it as an opportunity to differentiate - if you already support
validation of digraphs, how much harder would it be to extend your
implementation to handle a table of 3-tuples, and do equivalence
matching for free?  IMHO, going from unconstrained 2-character strings
to validated 3166 digraphs is the hard part, and extending that to
handle trigraphs is trivial.

It would make sense to make the QC constraint a bit more specific,
to prevent the use of ASCII numbers:

     (CONSTRAINED BY { -- IS 3166 digraphs and trigraphs only })

Regards,
  Dave

>   [...]
>
> If I had a choice, I would prefer a single attribute type, namely 
> INTEGER, since such things are obviously the easiest to look 
> up in a simple table without having to use either serial 
> comparisons or some sort of searching algorithm such as 
> a hash.
> 
> But I don't like having to be forced to implement three different 
> ways to  input and output the same information, or worse yet 
> to count the number of characters in order to determine which 
> table of allowable codes to use when validating the input.
> 
> Guess I'm still unconvinced.
> 
> Regards,
> 
> Bob

Date: Thu, 04 Nov 1999 09:43:48 -0700
From: "Bob Jueneman" <[email-masked]>
To: <[email-masked]>, <[email-masked]>
Subject: RE: QC certificates and Nationality

Dave, I confess to not having researched this as carefully as I 
probably should have, in particular not looking up the text of 
ISO 3166, and/or comparing it to the reference used for 
country codes in X.509. I apologize.

If the context is restricted to id-pda-countryOfCitizenship,
and not country codes more broadly, then I am mildly less 
concerned., but perhaps that merely reflects the fact that 
implementing the QC spec is still a ways off on my horizon. :-)

But I don't see a particularly strong architectural justification for using
a different encoding than the country code that is already fairly widely
used in X.509 certificates

However, architecturally I get upset at the thought of 
having to implement two different ways of identifying the same 
functionality.  get particularly upset at the thought of allowing 
either digraph or trigraph, and possibly even numeric codes in 
trigraph form, to be input via a varying string size constraint.

Defining the country code to be a printableString would mean 
that "US", "USA", and "840" would presumably all be valid, 
since they are "constrained by ISO 3166".

And how are such constraints to be enforced, without referencing
a table of allowable codes that is effectively the same kind 
of problem as that presented by a translation table? Is the user
responsible for enforcing this constraint?

If it is absolutely necessary to embed this kind of variability
in the architecture, rather than the API or GUI, then could 
you at least make the code a CHOICE of two or even three, 
specific, different types, so that the rules can be enforced 
during data entry, and type-enforced for 
consistency later on?

With respect to my allegation of English-centricity, I probably 
reacted too quickly.  I assumed, apparently incorrectly, 
that for ease of comprehension in the primarily US military 
environment, that for example "GER" would be the trigraph
for Germany, instead of whatever it is in fact -- "DER"?

If I had a choice, I would prefer a single attribute type, namely 
INTEGER, since such things are obviously the easiest to look 
up in a simple table without having to use either serial 
comparisons or some sort of searching algorithm such as 
a hash.

But I don't like having to be forced to implement three different 
ways to  input and output the same information, or worse yet 
to count the number of characters in order to determine which 
table of allowable codes to use when validating the input.

Guess I'm still unconvinced.

Regards,

Bob

>>> "David P. Kemp" <[email-masked]> 11/04/99 08:28AM >>>
Bob,

I'm having some difficulty understanding the logic here . . . comments
inline.

> 
> Sandy,
> 
> The digraph encoding of country codes is also an ISO standard, just a 
> different one.

ISO 3166 is a single standard with three country indices - digraphs,
trigraphs, and numeric.

> There is a long
> history of the existing encoding in X.500, X.400, and elsewhere,
> and insufficient justification to warrant a change to a lot of already 
existing
> CA, RP, and directory software.

We were discussing the id-pda-countryOfCitizenship and
id-pda-countryOfResidence attributes defined in the QC draft, which
currently have syntax:

   PrintableString (SIZE(2)) (CONSTRAINED BY { -- ISO 3166 codes only -- })

Sandi has proposed modifying the syntax to:

   PrintableString (SIZE(2..3)) (CONSTRAINED BY { -- ISO 3166 codes only -- })

I don't know of any existing X.500, X.400, or other software which
understands the id-pda-countryOfxxx attributes.  What software
would need to be modified if these two QC attributes were defined to
accommodate both two- and three-character country codes?

> There is another, more subtle issue here as well, and that is the question 
> of being overly English-centric.
> 
> What trigraph is proposed for Germany, for example, or Switzerland,
> or a number of other countries whose English names are not at all
> similar to their native language forms?  For that matter, what is the 
> code for that conglomeration headed by Queen Elisabeth -- is it UK, 
> or GBR?

This argument is way too subtle for me.  The ISO 3166 committee registers
codes as countries are created, partitioned, renamed, etc.  I have no
idea whether the committee is dominated by English-centric members, but
assuming that it is, I see no reason to expect them to apply their
English-centrism to the three-character index while refraining from
applying it to the two-character index.  The digraph for our country
is, after all, "US", not "EU" (as in the French Etats Unis).  If you
want to stamp out English-centrism, you should insist that *only*
numeric codes be allowed in the attributes so that all software would
have to translate for presentation:

  WITH SYNTAX INTEGER (CONSTRAINED BY { -- ISO 3166 codes only -- })

Moreover, if the ISO 3166 committee is indeed grievously
English-centric, it would seem that complaints should be addressed to
the committee, not to the maintainers of scores of standards which
reference 3166.

> US == USA == 840.  Anyone who can handle ASN.1 ought to be 
> able to handle the necessary conversions for a desired presentation 
> style, IMHO.

Sandi has addressed the significant implementation issues involved in
requiring all software which might require countryOfCitizenship to
understand SPIFs or use some other embedded index translation
mechanism.  Whether you are convinced that not requiring embedded
translation tables is simpler than requiring them is beside the point.
(If you believe translation is always practical, you should have no
problem with eating your own dog food and allowing only INTEGER country
codes in these QC attributes, as suggested above).

The point is that significant PKIX constituencies, including NATO, have
policies requiring the use of three-character country codes in HMIs;
at least some implementors believe that it is easier to display what is
contained in a country field directly rather than distributing new
translation tables to applications every time 3166 is updated; and
PKIX, as a generally-applicable standard, should be flexible enough to
accommodate the non-translation approach to three-character country
identifiers for those who choose to use it.

Dave

From: [email-masked]
To: [email-masked]
cc: [email-masked]
Date: Thu, 4 Nov 1999 11:16:26 -0500
Subject: Re: How to identify certs to users

     Since an rfc822Name inside GeneralName is defined as being an RFC 822
addr-spec (see RFC 2459 section 4.2.1.7), which is defined as
local-part@domain (RFC 822 section 6.1), the form "Personal Name
<local-part@domain>" is not legal for it according to PKIX.  The
difficulty, I suppose, is that a lot of software would treat this as being
an RFC 822 mailbox, for which that form is legal, especially since X.509
(1997) calls it "an Internet electronic mail address defined in accordance
with Internet RFC 822", which could plausibly be interpreted as either
mailbox or addr-spec.  I don't know if there are any corrections to X.509
on this yet, but if not there probably should be.

          Tom Gindin

Date: Thu, 4 Nov 1999 10:28:53 -0500 (EST)
From: "David P. Kemp" <[email-masked]>
Reply-To: "David P. Kemp" <[email-masked]>
Subject: RE: QC certificates and Nationality
To: [email-masked]
Content-MD5: FBOaP8rcPVKEdx+F6exPbw==

Bob,

I'm having some difficulty understanding the logic here . . . comments
inline.

> 
> Sandy,
> 
> The digraph encoding of country codes is also an ISO standard, just a 
> different one.

ISO 3166 is a single standard with three country indices - digraphs,
trigraphs, and numeric.

> There is a long
> history of the existing encoding in X.500, X.400, and elsewhere,
> and insufficient justification to warrant a change to a lot of already 
existing
> CA, RP, and directory software.

We were discussing the id-pda-countryOfCitizenship and
id-pda-countryOfResidence attributes defined in the QC draft, which
currently have syntax:

   PrintableString (SIZE(2)) (CONSTRAINED BY { -- ISO 3166 codes only -- })

Sandi has proposed modifying the syntax to:

   PrintableString (SIZE(2..3)) (CONSTRAINED BY { -- ISO 3166 codes only -- })

I don't know of any existing X.500, X.400, or other software which
understands the id-pda-countryOfxxx attributes.  What software
would need to be modified if these two QC attributes were defined to
accommodate both two- and three-character country codes?

> There is another, more subtle issue here as well, and that is the question 
> of being overly English-centric.
> 
> What trigraph is proposed for Germany, for example, or Switzerland,
> or a number of other countries whose English names are not at all
> similar to their native language forms?  For that matter, what is the 
> code for that conglomeration headed by Queen Elisabeth -- is it UK, 
> or GBR?

This argument is way too subtle for me.  The ISO 3166 committee registers
codes as countries are created, partitioned, renamed, etc.  I have no
idea whether the committee is dominated by English-centric members, but
assuming that it is, I see no reason to expect them to apply their
English-centrism to the three-character index while refraining from
applying it to the two-character index.  The digraph for our country
is, after all, "US", not "EU" (as in the French Etats Unis).  If you
want to stamp out English-centrism, you should insist that *only*
numeric codes be allowed in the attributes so that all software would
have to translate for presentation:

  WITH SYNTAX INTEGER (CONSTRAINED BY { -- ISO 3166 codes only -- })

Moreover, if the ISO 3166 committee is indeed grievously
English-centric, it would seem that complaints should be addressed to
the committee, not to the maintainers of scores of standards which
reference 3166.

> US == USA == 840.  Anyone who can handle ASN.1 ought to be 
> able to handle the necessary conversions for a desired presentation 
> style, IMHO.

Sandi has addressed the significant implementation issues involved in
requiring all software which might require countryOfCitizenship to
understand SPIFs or use some other embedded index translation
mechanism.  Whether you are convinced that not requiring embedded
translation tables is simpler than requiring them is beside the point.
(If you believe translation is always practical, you should have no
problem with eating your own dog food and allowing only INTEGER country
codes in these QC attributes, as suggested above).

The point is that significant PKIX constituencies, including NATO, have
policies requiring the use of three-character country codes in HMIs;
at least some implementors believe that it is easier to display what is
contained in a country field directly rather than distributing new
translation tables to applications every time 3166 is updated; and
PKIX, as a generally-applicable standard, should be flexible enough to
accommodate the non-translation approach to three-character country
identifiers for those who choose to use it.

Dave

From: Peter Sylvester <[email-masked]>
Date: Thu, 4 Nov 1999 16:24:08 +0100 (MET)
To: [email-masked]
Subject: Re: Comments on the PKIX Roadmap
Cc: [email-masked]

> > 
> > Okay I can add this.  Other have commented in private e-mail to expand
> > the DVCS description to include:
> > 
> > - delegation of verification to trustworthy servers
> > - Chaining of verifications
> > - The DVCS not only validates the signature of the document,  it checks
> > the validity of a document.
> 
> For the last sentence, I do not think so. The content of the signed
> part is not "validated"

Nothing in the protocol prohibits a server to use whatever
kwowledge. It doesn't mean that it tries to interprete
the content, the existance in some context may be sufficient.
The validity of the document can be asserted even if none of the
original signatures can be validated. Even if it bears no signatures
at all, e.g. when responding to a question like : is the following
text a valid law?)

A DVCS can have knowledge about all documents that have ever been
produced (and may be archived), and just uses this information as
a base of its decision.

Responding to questions 'Is this picture a beautiful one?'
seems outside the scope of that protocol, unless you restrict the answer
to some algorithm defined by yourself, or you believe in oracles, or
if you use DVCS as a voting protocol.

> "Impossible " means impossible, not "more difficult". :-)
I can't resist. Napolean Bonaparte: 'impossible' is not a French word. :-)

From: [email-masked] (Peter Gutmann)
To: [email-masked], [email-masked]
Subject: Re: QC comparisons are DEADLY serious!
Sender: [email-masked]
Reply-To: [email-masked]
Date: Fri, 5 Nov 1999 03:53:44 (NZDT)

Stephen Kent <[email-masked]> writes:

>In version 2 X.509 certs there was a field added for unique subject and 
>issuer IDs.  It was a bad idea, designed to address what appear to be some 
>of the issues you alluded to above; nobody uses it.

Well, nobody's *supposed* to use it, but it was used briefly in SEIS certs
(it's now been replaced by a cert extension).  The style guide has the
following comment on unique identifiers:

uniqueIdentifier

  There are at least two incompatible objects called uniqueIdentifier, the
  first is an attribute defined in 1991 in RFC 1274 with string syntax, the
  second is an attribute defined in 1993 in X.520v2 with BIT STRING syntax.
  LDAPv2 used the RFC 1274 interpretation, RFC 2256 changed the name for the
  X.520 version to x500uniqueIdentifier for use with LDAPv3.  There is also a
  uid attribute defined in RFC 1274, this is different again.

There are also proprietary equivalents for uniqueIdentifiers which I haven't
mentioned in the guide, eg the Telesec nameDistinguisher.  X.520 also has some
other uniqueXXX attribute [pause] uniqueMember whose purpose I don't recall.

Peter.

Date: Thu, 04 Nov 1999 15:45:21 +0100
From: Denis Pinkas <[email-masked]>
Organization: Bull
To: Parag Namjoshi <[email-masked]>
CC: IETF-PXIX <[email-masked]>
Subject: Comments on ETNPT

Parag,

This E-mail was initiated by a comment on the roadmap, but since
Sean erecommned to discuss this separately I changed the title of
this thread to ETNPT only.

> >> Page 9: The text says:"
> >>
> >>    [ETNPT] was developed to use [DCVS] to maintain the trust in a
> >>    token issued by a non-repudiation Trusted Third Party (NR TTP) after
> >>    the key initially used to establish trust in the token expires.
> >>     I would propose instead:
> >>
> >> [ETNPT]was proposed to maintain the trust in a token  issued by a
> >> non-repudiation Trusted Third Party (NR TTP) after the key initially
> >> used to establish trust in the token expires. However, since TSP
> >> provides that service, its goal needs to be clarified.
> 
> The basic purpose of the draft is to keep alive the trust in "long living"
> non-repudiation tokens/certificates even after the key used by the *service*
> ( say TSA )to sign the token has expired. This is logical extension of the
> the services provided by TSA/DVCS for extending the lifetime of signatures ,
> to extend lifetime of their own signatures. (somewhat similar to "old with
> new" of CMP.)

I still have difficulties to understand the rational for the (rather
complex) scheme that is presented. The basic time stamping protocol
provides a token (TST) that allows to make sure before which time a
document and/or a certificate was signed. If some signed data needs
to be protected by a time stamp, it seems more natural to append the
TST to the data structure rather than going down a tree of
"NRStorage". 

In addition, the data structure that is presented is twice
recursive. :-(

Thus I am wondering the need for such a document. If you are present
in Washington, I would appreciate a talk on that topic.

Regards,

Denis

> The draft uses the CS (now "VSD") service from DVCS
> to "recertify" the original token/certificate. The  ASN structure
> (local storage format ) is defined so that opeartion of the
> recertification of token & later verification ( maybe after 10 years
> when service has changed keys , say 5 times ) can be performed easily.
> (This would be much simpler and faster than retrieving tokens from
> an archive , getting some kind of certification from the service
> provider about its authenticiaty ect which would involve human
> interaction thus (comparatively) much larger delays.)
> 
> The format also allows for linking multiple such tokens (very likely from
> different service provider ) for same data. (Each of these tokens
> can (and should) be recertified to keep alive the initial trust in the
> token.)
> 
> This is absolutely necessary in the case that your service
> does not provide for archiving . And even if the archiving
> is provided you may not want to put all eggs in one basket.
> As an example,you do trust the service to protect its signing key well
> but not with the lagre token archive over a long period of time.
> 
> I hope I have clarified the goals for the draft well enough.
> 
> Note : The draft is somewhat out of date since after it was written ,
> 2/3 versions of TSA & DVCS draft have come out.
> 
> Regards,
> Parag.

Date: Thu, 04 Nov 1999 15:20:55 +0100
From: Denis Pinkas <[email-masked]>
Organization: Bull
To: Sean Turner <[email-masked]>
CC: IETF-PXIX <[email-masked]>
Subject: Re: Comments on the PKIX Roadmap

Sean,

Before packing to Washington, a short answer. I have deleted some
stuff to make this answer more readable.

> Denis,
> 
> Thanks for the comments.  Mine are in line.
> 
> Denis Pinkas wrote:
> 
> > Comments on the PKIX Roadmap <draft-ietf-pkix-roadmap-04.txt>
> > I would propose instead:

(...)

> > [DVCS] allows to verify and assert the validity of all signatures
> > attached to the signed document using all appropriate status
> > information and PKCs or to verify and assert the validity of one or
> > more PKCs at the specified time.
> >
> 
> Okay I can add this.  Other have commented in private e-mail to expand
> the DVCS description to include:
> 
> - delegation of verification to trustworthy servers
> - Chaining of verifications
> - The DVCS not only validates the signature of the document,  it checks
> the validity of a document.

For the last sentence, I do not think so. The content of the signed
part is not "validated"

(...)

> Okay except for the last sentence.  I thought [ETNPT] gave you a format
> to store the information locally (like on your HD).  I wasn't sure if
> TSP provided the same function (thought I guess it could if you stored
> the message).  If you think the goal for [ETNPT] needs to be clarified
> we should do that in a separate e-mail thread about ETNPT and not just
> put it in the roadmap.

I will do so.

> > Page 28: Section 4.5. Change the title into: "Time Stamp Protocols"
> >
> 
> Somebody else suggested "Time Stamping and Data Validation and
> Certification Server Protocols" can we use that instead?

The current title of TSP does not contains "and Data Validation and
Certification Server Protocols". Having TSP addressed separately
seems more appropriate.

> > Page 39: Section on POP. It should be noticed that POP is NOT always
> > needed. For some (old) "poorly designed" protocols, POP is needed
> > when the SAME key is being used for authentication purposes and non
> > repudiation purposes. Basically, if the protocol makes sure that the
> > identifier of the public key certificate is protected by the end
> > user signature, then POP does not need to be performed by the CA.
> > For the case of encryption, see the proposed text replacement. Here
> > is a full text replacement for that topic:
> >
> 
> In general, I have no real concerns with what you propose just a few
> questions.

(...)

> >
> > Protection can be gained by having Alice, as the true signer of the
> > transaction, include in the signed information her PKC or an
> > identifier of her PKC (e.g., a hash of her PKC). This makes
> > impossible for Mal to claim authorship because he does not know the
> > private key from Alice and thus is unable to include his certificate
> > under the signature.
> 
> The last sentence says "impossible."  What it used to say was:
> 
> This might make it more difficult for Mal to claim authorship - he would
> have to assert that he incorrectly included Alice's PKC, rather than his
> own. However, it would not stop Alice from falsely repudiating her
> actions. Since the PKC itself is a public item, Mal indeed could have
> inserted Alice's PKC into the signed transaction, and thus its presence
> does not indicate that Alice was the one who participated in the
> now-repudiated transaction. The only reliable way to stop this attack is
> to require that Mal prove he possesses X before his PKC is issued.
> 
> What was it that you didn't like from the previous text?

"Impossible " means impossible, not "more difficult". :-)

> > The adequate protection may be obtained in the general case, by
> > mandating the inclusion of a reference of the certificate every time
> > a signature (or non repudiation) key is being used in a protocol.
> >
> > However, because all the protocols were not doing so, a conservative
> > measure has been taken by requesting POP to be performed by CAs. It
> > should thus be understood, that this measure is not strictly
> > necessary and is only a temporary measure to make old protocols
> > secure. New protocols or data formats are being developed. If the
> > key being used is always used in a context where the identifier of
> > the certificate is included in the protocol, then POP by the CA is
> > not necessary. The inclusion of the identifier of the certificate in
> > the protocol or data format may be understood as POP being performed
> > at the transaction time rather than by the CA, at the registration
> > time of the user in the PKI.
> 
> The text indicating that the need for POP for signing keys not used for
> non-repudiation was removed.  What didn't you like about it?

The above is valid for all keys, as soon as the identifier of the
certificate may be closely tied to the signature key.

> I think the rest of the POP rewrite looks fine.

(...)

Regards,

Denis

From: "Parag Namjoshi" <[email-masked]>
To: "Sean Turner" <[email-masked]>, "Denis Pinkas" <[email-masked]>
Cc: "IETF-PXIX" <[email-masked]>
Subject: Re: Comments on the PKIX Roadmap
Date: Thu, 4 Nov 1999 18:05:22 +0530

>>
>> Page 9: The text says:"
>>
>>    [ETNPT] was developed to use [DCVS] to maintain the trust in a
>>    token issued by a non-repudiation Trusted Third Party (NR TTP) after
>>    the key initially used to establish trust in the token expires.
>>     I would propose instead:
>>
>> [ETNPT]was proposed to maintain the trust in a token  issued by a
>> non-repudiation Trusted Third Party (NR TTP) after the key initially
>> used to establish trust in the token expires. However, since TSP
>> provides that service, its goal needs to be clarified.

The basic purpose of the draft is to keep alive the trust in "long living"
non-repudiation tokens/certificates even after the key used by the *service*
( say TSA )to sign the token has expired. This is logical extension of the
the services provided by TSA/DVCS for extending the lifetime of signatures ,
to extend lifetime of their own signatures. (somewhat similar to "old with
new" of CMP.)

The draft uses the CS (now "VSD") service from DVCS
to "recertify" the original token/certificate. The  ASN structure
(local storage format ) is defined so that opeartion of the
recertification of token & later verification ( maybe after 10 years
when service has changed keys , say 5 times ) can be performed easily.
(This would be much simpler and faster than retrieving tokens from
an archive , getting some kind of certification from the service
provider about its authenticiaty ect which would involve human
interaction thus (comparatively) much larger delays.)

The format also allows for linking multiple such tokens (very likely from
different service provider ) for same data. (Each of these tokens
can (and should) be recertified to keep alive the initial trust in the
token.)

This is absolutely necessary in the case that your service
does not provide for archiving . And even if the archiving
is provided you may not want to put all eggs in one basket.
As an example,you do trust the service to protect its signing key well
but not with the lagre token archive over a long period of time.

I hope I have clarified the goals for the draft well enough.

Note : The draft is somewhat out of date since after it was written ,
2/3 versions of TSA & DVCS draft have come out.

Regards,
Parag.

>>
> Okay except for the last sentence.  I thought [ETNPT] gave you a format
> to store the information locally (like on your HD).

>I wasn't sure if
> TSP provided the same function (thought I guess it could if you stored
> the message).  If you think the goal for [ETNPT] needs to be clarified
> we should do that in a separate e-mail thread about ETNPT and not just
> put it in the roadmap.

From: "Anders Rundgren" <[email-masked]>
To: "Stephen Kent" <[email-masked]>, <[email-masked]>, "'Stefan Santesson'" <[email-masked]>, "'SEIS-List'" <[email-masked]>, "Magnus (RSA)" <[email-masked]>
Subject: RE: QC comparisons are DEADLY serious!
Date: Thu, 4 Nov 1999 07:46:24 -0000

Steve,

<snip>

>In version 2 X.509 certs there was a field added for unique subject and
>issuer IDs.  It was a bad idea, designed to address what appear to be some
>of the issues you alluded to above; nobody uses it.

Except for the Swedish and Finnish ID-card programs.  Well, to be honest they have
defined some subject extensions "on their own" to achive this functionality and I suggest
that this gets standardized.  And INTEROPERABILITY is a goal of QC isn't it?

BTW, I think that most employee systems use "emplyee numbers" internally to keep track
of employees.  To become a "new" employeee just because you have been promoted
is IMO an awkward solution.

Actually, I wonder how wide-spread the initial QC attribute-based identity scheme will be.

But Steve, let the MARKET and LEGISLATORS decide.  We provide the options.

<snip>

Anders

Date: Wed, 3 Nov 1999 22:46:55 -0500
To: "Todd Glassey @ GMT" <[email-masked]>, "Michael Duren" <[email-masked]>
From: Stephen Kent <[email-masked]>
Subject: Re: Timestamping Standards.
Cc: <[email-masked]>

Todd & Mike,

>Denis, Robert - here we are again, disagreeing on the Time Stamping
>Protocols.
>
>OK, if I agree to drop these issues, can I/we add an appendix or supplement
>to the current draft that contains a BCP model for maintaining the Clock
>Timebase. This of course would be at the OS level, that is below the TS
>Protocol that would be use-model compliant with OATS requirements.
>
>This would satisfy me and would allow the process to continue with this
>status-quo.
>
>Also this addition would address the need for this BCP Model in the 'Road
>Map' as well, and eliminate the need to address this further for any other
>of the protocols being forged in the furnace of PKIX or its related WG's.
>
>Bluntly, this appendix could be a recommendation for timebase management in
>all PKI or IETF Operating Models.

After the last IETF meeting I spoke with one of the security area directors
briefly, to discuss the question of BERT and similar time stamping issues.
There was agreement that tmost aspects of the proposals that you have put
forward are outside the scope of what we need to do in the PKIX
environment, given the long standing model for TSAs and a desire to not
impose constraints on how a TSA chooses to maintain its time base.
Moreover, there was agreement that the STIME WG provides a suitable
Internet standard for time representation, if we wish to refer to formats
consistent in the IETF arena.  Since I stated at the last meeting (and
reported in the minutes) that the WG chairs would consider the question of
whether BERT was within scope, and based on the feedback from a security
AD, I have decided that, going forward, PKIX will not address the
definition of a time token representation ala BERT or analogous proposals.

In the last couple of months, Todd proposed creation of a separate WG for
this sort of task and if the IESG agrees, one can be established.  However,
from now on, PKIX will not devote additional resources to this topic.  It
has not been an accepted work item, and enough time has been devoted to its
consideration for us to decide against adding it.

Steve

Date: Wed, 3 Nov 1999 22:32:31 -0500
To: "Todd Glassey @ GMT" <[email-masked]>
From: Stephen Kent <[email-masked]>
Subject: Re: Possible patent issue with UTCTime hack
Cc: <[email-masked]>

Todd,

Many of us are getting rather tired of seeing messages from you promoting
your company's time service notions whenever any time-related topic pops up
on any list, not just PKIX.

Steve

Date: Wed, 3 Nov 1999 22:20:00 -0500
To: Anders Rundgren <[email-masked]>
From: Stephen Kent <[email-masked]>
Subject: RE: QC comparisons are DEADLY serious!
Cc: "[email-masked]" <[email-masked]>, "'Stefan Santesson'" 	 <[email-masked]>, "'SEIS-List'" <[email-masked]>, "Magnus (RSA)" <[email-masked]>

Anders,

>As the dnQualifier seems to be reserved for a particular purpose and also have
>an arbitrary syntax it seems that dnQualifier is not a good candidate for
>access-control.
>
>Therefore I would like to see a new "subject item" named something like
>staticUniqueIdentity that if
>defined in a certificate, indicates that the CA indeed has the capability
>to (long-term) keep track
>of its subscribers.   Some preliminary rules to support this:
>
>16 decimal digits.  No more, no less.   Like VISA.  Why? to allow verbal
>communication of
> "digital identity" with ease.  Compatible with current systems after
>slight "translations".  16 digits
>is enough for a 100-billion terrestrial population (Yuck!)  for thousands
>of years.  Interoperability is IMO
>more important than "style" which is the reason for this admittedly rigid
>specification.
>
>The staticUniqueIdentity is guaranteed to be unique for a certain CA
>
>If staticUniqueIdentity is defined, other attributes and names are only of
>informational
>purposes (for human RP's) and should NOT be used to create a unique
>electronic identity.
>This allows a CA to manufacture certificates of different "weight" without
>screwing up identity.

In version 2 X.509 certs there was a field added for unique subject and
issuer IDs.  It was a bad idea, designed to address what appear to be some
of the issues you alluded to above; nobody uses it.  I don't think we
should include a similar facility in a QC.  You'll note that 2459
explicitly disparages use of the v2 UIDs.

Steve

From: [email-masked] (Peter Gutmann)
To: [email-masked]
Subject: Re: How to identify certs to users
Sender: [email-masked]
Reply-To: [email-masked]
Date: Thu, 4 Nov 1999 16:11:18 (NZDT)

[email-masked] writes:

>Contrary to how most public CAs do it, at least so far, the e-mail address is
>included in the subjectAltName as per the PKIX RFC, and to our pleasant
>surprise all of the e-mail packages we have encountered to date have been 
>able to handle that format correctly.
>
>Although we could have, we chose not to include an e-mail address of the form
>subjectAltName="Robert R. Jueneman" <[email-masked]> , in part because
>most e-mail packages would just as easily accept "President William Jefferson
>Clinton" <[email-masked]>.

D'you mean they'll accept that as an rfc822Name?  Are they supposed to do that?

Peter.

Content-return: allowed
Date: Wed, 03 Nov 1999 21:30:38 -0500
From: "Sweigert, David" <[email-masked]>
Subject: NIST key-based management ANSI X9.44
To: [email-masked], [email-masked], [email-masked]

This is a multi-part message in MIME format.

------=_NextPart_000_0029_01BF2640.19A3F080
Content-Type: multipart/alternative;
	boundary="----=_NextPart_000_0022_01BF2640.19A3F080"

------=_NextPart_000_0022_01BF2640.19A3F080
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit

-------------------------------------------------------------------------

[Federal Register: November 1, 1999 (Volume 64, Number 210)]
[Notices]
[Page 58808]
 From the Federal Register Online via GPO Access [wais.access.gpo.gov]
[DOCID:fr01no99-27]

-----------------------------------------------------------------------

DEPARTMENT OF COMMERCE

National Institute of Standards and Technology

Announcement of a Workshop on Key Management Using Public Key
Cryptography

AGENCY: National Institute of Standards and Technology.

ACTION: Notice of Public Workshop.

-----------------------------------------------------------------------

SUMMARY: The National Institute of Standards and Technology (NIST)
announces a workshop to examine public key-based management techniques
as specified in ANSI X9.42 (Agreement of Symmetric Keys Using Discrete
Logarithm Cryptography), ANSI X9.44 (Key Establishment Using Factoring-
Based Public Key Cryptography for the Financial Services Industry), and
ANSI X9.63 (Public Key Cryptography for the Financial Services
Industry: Key Agreement and Key Transport Using Elliptic Curve
Cryptography). The purpose of the workshop is to review the many
options and techniques contained in these standards and to discuss
other related issues.

DATES: The Key Management Standard (KMS) Workshop will be held on
Thursday, February 10 and Friday, February 11, 2000, from 9:00 a.m. to
5:00 p.m.

ADDRESSES: The KMS workshop will be held in the Administration Building
(Bldg. 101), National Institute of Standards and Technology,
Gaithersburg, Maryland. For planning purposes, advance registration is
encouraged. To register, please fax your name, address, telephone, fax
and
e-mail address, telephone, fax and
e-mail address to 301-948-1233 (Attn: KMS Workshop) by January 31,
2000. Registration questions should be addressed to Vickie Harris on
301-975-2920. Registration will also be available at the door, space
permitting. The workshop will be open to the public and is free of
charge.

FOR FURTHER INFORMATION: Further information may be obtained from the
KMS web site at http://www.nist.gov/kms or by contacting Morris
Dworkin, National Institute of Standards and Technology, 100 Bureau
Drive, Stop 8930, Gaithersburg, MD 20899-8930; telephone 301-975-2354;
Fax 301-948-1233, or email [email-masked].

SUPPLEMENTARY INFORMATION: This work effort is being initiated pursuant
to NIST's responsibilities under the computer Security Act of 1987, the
Information Technology Management Reform Act of 1996, Executive Order
13011, and OMB Circular A-130.
     The explosion in the use of electronic media to expedite commerce
in recent years has led to the need for well-established schemes that
can provide such services as data integrity and confidentiality.
Symmetric encryption schemes such as Triple DES, as defined in FIPS 46-
3, and the Advanced Encryption Standard (AES), which is currently under
development, make an attractive choice for the provision of these
services. Systems using symmetric techniques are efficient, and their
security requirements are well understood. Furthermore, these schemes
have been or will be standardized to facilitate interoperability
between systems. However, the implementation of such schemes requires
the establishment of a shared secret key in advance. As the size of a
system or the number of entities using a system explodes, key
establishment can lead to a key management problem. An attractive
solution to this problem is to employ key establishment techniques that
employ public key cryptography.
     The Federal Government currently has no standard of keys for
unclassified applications using a public key cryptographic methods. A
number of techniques have been defined in voluntary consensus industry
standards; however, the proliferation of techniques has lead to a
concern that some techniques may not provide suitable security to meet
the needs of the Federal Government and may not promote
interoperability between agencies of the government. In anticipation of
the development of a standard for key establishment, a Federal Register
Notice was published by NIST on May 13, 1997, (Vol. 62, No. 92)
requesting comments from the public concerning the development of such
a standard, and concerning the availability, security, and adequacy of
existing standards for public key-based key agreement and exchange.
Comments were received recommending the use of RSA, Diffie-Hellman, MQV
and elliptic curves, and several comments recommended the adoption of
ANSI X9.42, X9.44 and X9.62.
     This workshop will discuss the security and interoperability
requirements of the Federal government, the options available in the
above referenced voluntary consensus standards to address those needs,
and the planned development of a Federal Information Processing
Standard (FIPS) that will address those needs by including the
appropriate techniques from the voluntary consensus standards
referenced above. As with other FIPS, it is NIST's intention that the
proposed standard would be published for public review and comment.

     Dated: October 22 1999.
Karen H. Brown,
Deputy Director, NIST.
[FR Doc. 99-28495 Filed 10-29-99; 8:45 am]

------=_NextPart_000_0022_01BF2640.19A3F080
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Diso-8859-1">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2163.0">
<TITLE></TITLE>
</HEAD>
<BODY>
<BR>

<P><FONT =
SIZE=3D2>----------------------------------------------------------------=
---------</FONT>
</P>

<P><FONT SIZE=3D2>[Federal Register: November 1, 1999 (Volume 64, Number =
210)]</FONT>
<BR><FONT SIZE=3D2>[Notices]</FONT>
<BR><FONT SIZE=3D2>[Page 58808]</FONT>
<BR><FONT SIZE=3D2>&nbsp;From the Federal Register Online via GPO Access =
[wais.access.gpo.gov]</FONT>
<BR><FONT SIZE=3D2>[DOCID:fr01no99-27]</FONT>
</P>

<P><FONT =
SIZE=3D2>----------------------------------------------------------------=
-------</FONT>
</P>

<P><FONT SIZE=3D2>DEPARTMENT OF COMMERCE</FONT>
</P>

<P><FONT SIZE=3D2>National Institute of Standards and Technology</FONT>
</P>
<BR>

<P><FONT SIZE=3D2>Announcement of a Workshop on Key Management Using =
Public Key</FONT>
<BR><FONT SIZE=3D2>Cryptography</FONT>
</P>

<P><FONT SIZE=3D2>AGENCY: National Institute of Standards and =
Technology.</FONT>
</P>

<P><FONT SIZE=3D2>ACTION: Notice of Public Workshop.</FONT>
</P>

<P><FONT =
SIZE=3D2>----------------------------------------------------------------=
-------</FONT>
</P>

<P><FONT SIZE=3D2>SUMMARY: The National Institute of Standards and =
Technology (NIST)</FONT>
<BR><FONT SIZE=3D2>announces a workshop to examine public key-based =
management techniques</FONT>
<BR><FONT SIZE=3D2>as specified in ANSI X9.42 (Agreement of Symmetric =
Keys Using Discrete</FONT>
<BR><FONT SIZE=3D2>Logarithm Cryptography), ANSI X9.44 (Key =
Establishment Using Factoring-</FONT>
<BR><FONT SIZE=3D2>Based Public Key Cryptography for the Financial =
Services Industry), and</FONT>
<BR><FONT SIZE=3D2>ANSI X9.63 (Public Key Cryptography for the Financial =
Services</FONT>
<BR><FONT SIZE=3D2>Industry: Key Agreement and Key Transport Using =
Elliptic Curve</FONT>
<BR><FONT SIZE=3D2>Cryptography). The purpose of the workshop is to =
review the many</FONT>
<BR><FONT SIZE=3D2>options and techniques contained in these standards =
and to discuss</FONT>
<BR><FONT SIZE=3D2>other related issues.</FONT>
</P>

<P><FONT SIZE=3D2>DATES: The Key Management Standard (KMS) Workshop will =
be held on</FONT>
<BR><FONT SIZE=3D2>Thursday, February 10 and Friday, February 11, 2000, =
from 9:00 a.m. to</FONT>
<BR><FONT SIZE=3D2>5:00 p.m.</FONT>
</P>

<P><FONT SIZE=3D2>ADDRESSES: The KMS workshop will be held in the =
Administration Building</FONT>
<BR><FONT SIZE=3D2>(Bldg. 101), National Institute of Standards and =
Technology,</FONT>
<BR><FONT SIZE=3D2>Gaithersburg, Maryland. For planning purposes, =
advance registration is</FONT>
<BR><FONT SIZE=3D2>encouraged. To register, please fax your name, =
address, telephone, fax</FONT>
<BR><FONT SIZE=3D2>and</FONT>
<BR><FONT SIZE=3D2>e-mail address, telephone, fax and</FONT>
<BR><FONT SIZE=3D2>e-mail address to 301-948-1233 (Attn: KMS Workshop) =
by January 31,</FONT>
<BR><FONT SIZE=3D2>2000. Registration questions should be addressed to =
Vickie Harris on</FONT>
<BR><FONT SIZE=3D2>301-975-2920. Registration will also be available at =
the door, space</FONT>
<BR><FONT SIZE=3D2>permitting. The workshop will be open to the public =
and is free of</FONT>
<BR><FONT SIZE=3D2>charge.</FONT>
</P>

<P><FONT SIZE=3D2>FOR FURTHER INFORMATION: Further information may be =
obtained from the</FONT>
<BR><FONT SIZE=3D2>KMS web site at <A HREF=3D"http://www.nist.gov/kms" =
TARGET=3D"_blank">http://www.nist.gov/kms</A> or by contacting =
Morris</FONT>
<BR><FONT SIZE=3D2>Dworkin, National Institute of Standards and =
Technology, 100 Bureau</FONT>
<BR><FONT SIZE=3D2>Drive, Stop 8930, Gaithersburg, MD 20899-8930; =
telephone 301-975-2354;</FONT>
<BR><FONT SIZE=3D2>Fax 301-948-1233, or email =
[email-masked].</FONT>
</P>

<P><FONT SIZE=3D2>SUPPLEMENTARY INFORMATION: This work effort is being =
initiated pursuant</FONT>
<BR><FONT SIZE=3D2>to NIST's responsibilities under the computer =
Security Act of 1987, the</FONT>
<BR><FONT SIZE=3D2>Information Technology Management Reform Act of 1996, =
Executive Order</FONT>
<BR><FONT SIZE=3D2>13011, and OMB Circular A-130.</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp; The explosion in the use of =
electronic media to expedite commerce</FONT>
<BR><FONT SIZE=3D2>in recent years has led to the need for =
well-established schemes that</FONT>
<BR><FONT SIZE=3D2>can provide such services as data integrity and =
confidentiality.</FONT>
<BR><FONT SIZE=3D2>Symmetric encryption schemes such as Triple DES, as =
defined in FIPS 46-</FONT>
<BR><FONT SIZE=3D2>3, and the Advanced Encryption Standard (AES), which =
is currently under</FONT>
<BR><FONT SIZE=3D2>development, make an attractive choice for the =
provision of these</FONT>
<BR><FONT SIZE=3D2>services. Systems using symmetric techniques are =
efficient, and their</FONT>
<BR><FONT SIZE=3D2>security requirements are well understood. =
Furthermore, these schemes</FONT>
<BR><FONT SIZE=3D2>have been or will be standardized to facilitate =
interoperability</FONT>
<BR><FONT SIZE=3D2>between systems. However, the implementation of such =
schemes requires</FONT>
<BR><FONT SIZE=3D2>the establishment of a shared secret key in advance. =
As the size of a</FONT>
<BR><FONT SIZE=3D2>system or the number of entities using a system =
explodes, key</FONT>
<BR><FONT SIZE=3D2>establishment can lead to a key management problem. =
An attractive</FONT>
<BR><FONT SIZE=3D2>solution to this problem is to employ key =
establishment techniques that</FONT>
<BR><FONT SIZE=3D2>employ public key cryptography.</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp; The Federal Government =
currently has no standard of keys for</FONT>
<BR><FONT SIZE=3D2>unclassified applications using a public key =
cryptographic methods. A</FONT>
<BR><FONT SIZE=3D2>number of techniques have been defined in voluntary =
consensus industry</FONT>
<BR><FONT SIZE=3D2>standards; however, the proliferation of techniques =
has lead to a</FONT>
<BR><FONT SIZE=3D2>concern that some techniques may not provide suitable =
security to meet</FONT>
<BR><FONT SIZE=3D2>the needs of the Federal Government and may not =
promote</FONT>
<BR><FONT SIZE=3D2>interoperability between agencies of the government. =
In anticipation of</FONT>
<BR><FONT SIZE=3D2>the development of a standard for key establishment, =
a Federal Register</FONT>
<BR><FONT SIZE=3D2>Notice was published by NIST on May 13, 1997, (Vol. =
62, No. 92)</FONT>
<BR><FONT SIZE=3D2>requesting comments from the public concerning the =
development of such</FONT>
<BR><FONT SIZE=3D2>a standard, and concerning the availability, =
security, and adequacy of</FONT>
<BR><FONT SIZE=3D2>existing standards for public key-based key agreement =
and exchange.</FONT>
<BR><FONT SIZE=3D2>Comments were received recommending the use of RSA, =
Diffie-Hellman, MQV</FONT>
<BR><FONT SIZE=3D2>and elliptic curves, and several comments recommended =
the adoption of</FONT>
<BR><FONT SIZE=3D2>ANSI X9.42, X9.44 and X9.62.</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp; This workshop will discuss =
the security and interoperability</FONT>
<BR><FONT SIZE=3D2>requirements of the Federal government, the options =
available in the</FONT>
<BR><FONT SIZE=3D2>above referenced voluntary consensus standards to =
address those needs,</FONT>
<BR><FONT SIZE=3D2>and the planned development of a Federal Information =
Processing</FONT>
<BR><FONT SIZE=3D2>Standard (FIPS) that will address those needs by =
including the</FONT>
<BR><FONT SIZE=3D2>appropriate techniques from the voluntary consensus =
standards</FONT>
<BR><FONT SIZE=3D2>referenced above. As with other FIPS, it is NIST's =
intention that the</FONT>
<BR><FONT SIZE=3D2>proposed standard would be published for public =
review and comment.</FONT>
</P>

<P><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp; Dated: October 22 =
1999.</FONT>
<BR><FONT SIZE=3D2>Karen H. Brown,</FONT>
<BR><FONT SIZE=3D2>Deputy Director, NIST.</FONT>
<BR><FONT SIZE=3D2>[FR Doc. 99-28495 Filed 10-29-99; 8:45 am]</FONT>
</P>

</BODY>
</HTML>
------=_NextPart_000_0022_01BF2640.19A3F080--

------=_NextPart_000_0029_01BF2640.19A3F080
Content-Type: application/x-pkcs7-signature;
	name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment;
	filename="smime.p7s"

------=_NextPart_000_0029_01BF2640.19A3F080--

From: "Manger, James" <[email-masked]>
To: PKIX <[email-masked]>
Subject: RE: PKIX: String representation of GeneralName
Date: Thu, 4 Nov 1999 12:00:20 +1100 

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_000_01BF265F.72AB6250
Content-Type: text/plain

Amit,

There is already a standardized string representation of GeneralName values.
It is ASN.1 value notation.  As stated in the X.680 summary, ASN.1 provides
"a notation .. for specifying values of these [ASN.1] types".  Almost all
specifications defining ASN.1 types also use value notation to define some
values, e.g. object identifier values, version values, default values,
algorithm identifier values etc.

Below are the examples from your draft in value notation:

	rfc822Name:"[email-masked]"

	dNSName:"gandalf.trustpoint.com"

	uniformResourceIdentifier:"http://www.trustpoint.com/"

	iPAddress:'C0A8000A'H

	registeredId:{ 1 2 3 4 5 6 }

Value notation looks very similar to the notation in draft-generalname.txt
for most general name choices.  The major exception is directory name.  A
directory name has such a rich syntax (an ordered collection of levels, each
with 1 or more values, each value with an arbitrary type) that it is always
going to be awkward to devise a human-friendly notation for all possible
values.  So it is probably reasonable to use RFC 1779 [DN] for this choice:

	directoryName:CN=Amit Kapoor, O=Trustpoint, L=Mountain View,
ST=California, C=US

Your labels (e.g. "mail", "ip") may seem easier than the value notation
labels (e.g. "rfc822Name", "iPAddress") but the later match precisely &
obviously to fields in the type definition.  You get value notation for free
whenever a new ASN.1 type is defined.  Value notation offers a notation for
all the GeneralName choices (e.g. otherName), not just the 6 your draft
lists.  Value notation offers a notation for all possible values (e.g.
values with unusual or unprintable characters).  It is likely that anyone
wanting a text representation for GeneralName values today will want a text
representation for values of another ASN.1 type tomorrow so value notation,
which works for all ASN.1 types, is preferable.

> ----------
> From: 	Amit Kapoor[SMTP:[email-masked]]
> Sent: 	Tuesday, 2 November 1999 9:34
> To: 	PKIX
> Subject: 	String representation of GeneralName
> 
> a draft to document a string representation of GeneralName
> 
> 	http://www.trustpoint.com/draft-generalname.txt
> 

------_=_NextPart_000_01BF265F.72AB6250
Content-Type: application/ms-tnef
Content-Transfer-Encoding: base64

------_=_NextPart_000_01BF265F.72AB6250--

Date: Wed, 03 Nov 1999 18:32:15 -0500
From: Sean Turner <[email-masked]>
Organization: IECA, Inc.
To: PKIX <[email-masked]>
Subject: Comments on draft-ietf-pkix-qc-02.txt

Just a couple of comments/questions on the draft:

1. The draft covers qcs issued "to a natural person (living human
being)."  Does this include the CA operator or is just for EEs?  I
assumed it was just for EEs, but I wasn't 100% sure.

2.  Can capitalize the "may" in the second sentence of 3.2.1: "Instances
of this object MAY be used to construct unique names from personal
attributes of the subject."

3. Does the personalData OtherName form have to be a name in
subjectAltName or could it also be just an attribute that gets carried
in subjectDirectoryAttributes?  Better yet could we just carry the
attributes without all the wrapping of the personalData?

4. The text on key usage says only set the nr bit and nothing else.
What about processing?  Does the verifier have to make sure that only
the nr bit is set?

5. Could you change the next draft to explicitly say that the
biometricInfo and qcStatements extensions "MAY" be used to support ....
?  The current draft does not explicitly state this.

Thanks,

spt

From: [email-masked]
Date: Wed, 3 Nov 1999 15:01:00 -0600
Subject: Re: How to identify certs to users
To: [email-masked], [email-masked]

--____CPILXLVTUCRBHLFGCTCY____
Content-Type: multipart/mixed; boundary="____JCWHJTHCHIAZRLRJHVDZ____"

--____JCWHJTHCHIAZRLRJHVDZ____
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable

Peter,=20

Although I can't speak for other toolkit providers, our recent release of =
the
(FREE!) Novell Certificate Server 2.0 on NetWare/NDS, to be followed=20
by cross-platform implementations of NCS on NT, Solaris, and
Linux, make me believe that the number of certificates issued by=20
organizational CAs will soon increase sharply.

The train wreck between what the DN in the certificate should look like =
vs.
the directory schema for a DN has been looming for about ten years,=20
and the screeching and metal bending is now beginning to happen.=20
It's like watching The Fugitive in slow motion.

Because our cert server is tightly integrated with NDS, a more-or-less =
but=20
not quite (for good reasons) X.500 directory, we had to make some =
design=20
decisions in this area that might be of interest.

First of all, we decided that if we couldn't convince our own IS organizati=
on
to rename all of the objects in our DIT to conform to someone else's view
of what a DN ought to look like, when we only had 4000+ employees, we =
didn't=20
stand a ghost of a chance trying to convince say the US Navy to change =
theirs.
So the directory rules, and the DN in the certificate exactly matches the =
DN
of the user's object in the directory. Period.=20

(Well, actually that's just the default. In fact, the system administrator =
can=20
type in anything (s)he likes. But then some other things might not work
as well, like X.509 authentication.)

This means that the DN in my certificate is the not very informative
cN=3Dbjueneman, ou=3Dnsrd, ou=3Dprv, o=3DNovell. But at least it maps =
directly to=20
my DN in the directory, and therefore can very easily be used to=20
authenticate my access to NDS and to other servers.

Unfortunately, perhaps, the order of the attributes in the certificate =
isn't=20
explicitly spelled out in X.509 or RFC 2459, and so by default they are=20
included in the certificate in the conventional NDS presentation order,=20
little-endian first, rather than in top-down DIT order.

Contrary to how most public CAs do it, at least so far, the e-mail=20
address is included in the subjectAltName as per the PKIX RFC,=20
and to our pleasant surprise all of the e-mail packages we have=20
encountered to date have been able to handle that format correctly.

Although we could have, we chose not to include an e-mail address of the =
form subjectAltName=3D"Robert R. Jueneman" <[email-masked]> ,
in part because most e-mail packages would just as easily accept=20
"President William Jefferson Clinton" <[email-masked]>.

(According to my reading of RFC822, the name field that precedes the =
actual
RFC822 mailbox address is supposed to be a GROUP name, and whether the
inclusion of such a name in the semantics of a PKIX e-mail address =
attribute=20
is legitimate or not really isn't clear.)

The present version of the cert server GUI doesn't support the creation =
of=20
multiple subjectAltNames, but the API does, and I hope we will be able=20
to provide that capability in the GUI and the bulk certificate creation=20
method in the next release. =20

I believe that an additional subjectAltName is the "correct" place for=20
the subject's "real" geopolitical or organizational name in a form that is
intended for human consumption, e.g, c=3DUS, o=3D"Novell, Inc.",=20
ou=3DNetwork Security R&D, {cN=3D"Robert R. Jueneman"+employeeID=3D123456}

(Or, for that matter, the infamous MPEG movie (now upgraded to 16x9 =
HDTV=20
MPEG-2, with Dolby Digital 5.1) of me playing with my cat, the ASN.1=20
encoding of which I expect to be on my tombstone. :-)

Finally, with regard to the uniqueness of e-mail addresses, although I =
don't=20
know what practices the various public CAs may follow, I would NOT=20
assume that they are one-to-one with user's identities.

Certainly an individual user may wish to have two or more certificates=20
containing the same DN and same "real" name, but with different e-mail
addresses depending on which account he uses to send the mail =96 just=20
for the convenience of the recipient in validating the signature, and also
for the user's convenience if he uses two computers and doesn't want to
transport the private key for his "home" computer to his work computer,=20
where it might conceivably be more easily compromised.

Vice versa, although I wouldn't recommend it, I would certainly understand =
if=20
an entire family shared one-e-mail account (because of pricing consideratio=
ns),
and yet they each had their own certificates. Certainly better to do that =
than
to share the private key!

And of course the user might reasonably have two certificates containing=20=

precisely the same DN, and precisely the same subjectAltNames, but=20
perhaps with different validity periods, private key usage periods, =
different=20
algorithms or other attributes. including proprietary ones.

For all of these reasons, I would suggest that certificates be referred to =
by
a shorthand name, to simplify selecting the right one for a given purpose.

Regards,

Bob

>Spurred by recent questions on another mailing list about how to identify
>certificates in a useful-to-humans manner, I've been doing a bit of =
poking
>around to see how others solve the problem because I have no idea myself =
how to
>make anything meaningful to the average end user from a DN.  By the looks =
of it
>this is a problem which has occupied a number of people in the past, so =
I'll
>try and put something coherent in the style guide to summarize the =
situation
>and provide advice.  The following is based on a survey of a (somewhat =
small)
>number of online repositories, most CA's either don't seem to publish =
their
>certs or if they do they hide them really well, so I haven't been able to
>check too many implementations of cert lookup:
>
>-- Add to end of section on DN's --
>
>As the above text has probably indicated, DN's don't really work - =
there's no
>clear idea of what they should look like, most users don't know about =
(and
>don't want to know about) X.500 and its naming conventions, and as a
>consequence of this the DN can end up containing just about anything.  At =
the
>moment they seem to be heading in two main directions:
>
> - Public CA's typically set C=3DCA country, O=3DCA name, OU=3Dcertificate=
 type,
>   CN=3Duser name
>   - A small subset of CA's in Europe which issue certs in accordance =
with
>     various signature laws and profiles with their own peculiar =
requirements
>     can have all sorts of oddities in the DN.  You won't run into many =
of
>     these in the wild.
> - Private CA's (mostly people or organisations signing their own certs)
>   typically set any DN fields supported by their software to whatever =
makes
>   sense for them (some software requires all fields in the set
>   {C,O,OU,SP,L,CN} to be filled in, leading to strange or meaningless
>   entries).
>
>Generally you'll only run into certs from public CA's, for which the =
general
>rule is that the cert is identified by the CN and/or email address.  Some =
CA's
>issue certs with identical CN's and use the email address to disambiguate =
them,
>others modify the CN to make it unique.  The accepted user interface =
seems to
>be to let users search on the CN and/or email address (and sometimes also =
the
>serial number, which doesn't seem terribly useful), display a list of =
matches,
>and let the user pick the cert they want.  Probably the best strategy for =
a
>user interface which handles certs is:
>
>  if( email address known )
>    get a cert which matches the email address (any one should do);
>  elseif( name known )
>    search for all certs with CN=3Dname;
>    if( multiple matches )
>      display email addresses for matched certs to user, let them choose;
>  else
>    error;
>
>[Question for CA's: Do you require unique email addresses?  I managed to =
find
> some duplicates at Verisign, but not two active certs with the same =
email
> address]
>
>[Some sort of recommendation here, probably telling people to assume that =
the
> email address is unique, CN's are non-unique, and other DN components =
can't be
> relied upon.  If you need something unique (for example for a database =
key),
> use an X.500 serialNumber in an altName directoryName or define your own
> otherName. I'm trying to come up with one-size-fits-most guidelines on =
how to
> identify a cert in practice]
>
>Peter.
>

Robert R. Jueneman
Security Architect
Network Security Development
Novell, Inc.
122 East 1700 South
Provo, UT 84606
[email-masked]
1-801-861-7387

DISCLAIMER:
  If this message (with or without attached documents) is digitally =
signed, and/or if certificates are attached, the intended purpose is to=20
   (1) Ensure that e-mail came from the apparent sender
   (2) Protect e-mail from tampering
   (3) Ensure that the content of e-mail sent to me and encrypted in  my =
dual-use key cannot be viewed by others.
  It is explicitly NOT the intent of any such signed message or document =
to represent any type or form of legally binding contract or other =
representation, and any such interpretation should not be considered =
commercially reasonable and WILL BE REPUDIATED, notwithstanding any =
wording or implications to the opposite effect in the text of the message =
itself; due in part, but not exclusively, to the fact that the security of =
my workstation and its associated cryptography is not judged adequately =
strong for such purposes at present.

--____JCWHJTHCHIAZRLRJHVDZ____
Content-Type: text/x-vcard; charset=windows-1252; name="Bob Jueneman.vcf"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment; filename="Bob Jueneman.vcf";
	modification-date="Wed, 3 Nov 1999 15:01:50 -0700"

BEGIN:VCARD
VERSION:2.1
X-GWTYPE:USER
FN:Robert R. Jueneman
TEL;WORK:801-861-7387
ORG:Novell, Inc.;Network Security Development
TEL;PREF;FAX:801-861-2522
EMAIL;WORK;PREF;NGW:[email-masked]
N:Jueneman;Bob
TITLE:Consultant Engineer
ADR;INTL;WORK;PARCEL;POSTAL:;PRV-F331;122 E. 1700 South;Provo;Utah;84606;US=
A
LABEL;INTL;WORK;PARCEL;POSTAL;ENCODING=3DQUOTED-PRINTABLE:Robert R. =
Jueneman=3D0A=3D
PRV-F331=3D0A=3D
122 E. 1700 South=3D0A=3D
Provo, Utah  84606=3D0A=3D
USA
LABEL;DOM;WORK;PARCEL;POSTAL;ENCODING=3DQUOTED-PRINTABLE:Robert R. =
Jueneman=3D0A=3D
PRV-F331=3D0A=3D
122 E. 1700 South=3D0A=3D
Provo, Utah  84606
TEL;HOME:1-801-765-4378
TEL;CELL:1-801-361-1410
TEL;PREF:1-801-861-7387, 1-800-453-1267
X-GWUSERID:BJUENEMAN
END:VCARD

--____JCWHJTHCHIAZRLRJHVDZ____--

--____CPILXLVTUCRBHLFGCTCY____
Content-Type: application/x-pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
CONTENT-DESCRIPTION: S/MIME Cryptographic Signature

--____CPILXLVTUCRBHLFGCTCY____--

Date: Wed, 03 Nov 1999 18:03:59 -0500
From: Sean Turner <[email-masked]>
Organization: IECA, Inc.
To: Denis Pinkas <[email-masked]>
CC: IETF-PXIX <[email-masked]>
Subject: Re: Comments on the PKIX Roadmap

Denis,

Thanks for the comments.  Mine are in line.

Denis Pinkas wrote:

> Comments on the PKIX Roadmap <draft-ietf-pkix-roadmap-04.txt>
>
> Here are some comments and change text proposals followed by some
> typos (not all !) to prove that I skimmed through the draft. The
> problem was to get the time to read it and comment on it. :-)
>
> I would like to mention upfront that the draft is very valuable in
> general, in particular for the sections related to the historical
> construction and the naming constraints. However, ...  :-)
>
> Page 9:  The text says:
>
>    Of course, if
>    a true non-repudation service is to be provided additional
> services
>    that prove the data was actually in the possesion of the subject
>    requesting the time stamp. So, the [DVCS] draft was developed to
>    provide two mechaisms to prove the subject actually possed the
> data.
>    In addition, [DVCS] provides two additional services: one to
> verify
>    all signatures attached to the signed document using all
> appropriate
>    status information and PKCs and one to verify and assert the
> validity
>    of one or more PKCs at the specified time. Thoughtfully, [DVCS]
>    permits the [TSP] protocol to be used as one of the time stamp
>    tokens.
>
> I would propose instead:
>
> [DVCS] allows to verify and assert the validity of all signatures
> attached to the signed document using all appropriate status
> information and PKCs or to verify and assert the validity of one or
> more PKCs at the specified time.
>

Okay I can add this.  Other have commented in private e-mail to expand
the DVCS description to include:

- delegation of verification to trustworthy servers
- Chaining of verifications
- The DVCS not only validates the signature of the document,  it checks
the validity of a document.

I'll make sure your suggestions get worked in and the others too.

>
> Page 9: The text says:"
>
>    [ETNPT] was developed to use [DCVS] to maintain the trust in a
> token
>    issued by a non-repudiation Trusted Third Party (NR TTP) after
> the
>    key initially used to establish trust in the token expires.
>
> I would propose instead:
>
> [ETNPT]was proposed to maintain the trust in a token  issued by a
> non-repudiation Trusted Third Party (NR TTP) after the key initially
> used to establish trust in the token expires. However, since TSP
> provides that service, its goal needs to be clarified.
>

Okay except for the last sentence.  I thought [ETNPT] gave you a format
to store the information locally (like on your HD).  I wasn't sure if
TSP provided the same function (thought I guess it could if you stored
the message).  If you think the goal for [ETNPT] needs to be clarified
we should do that in a separate e-mail thread about ETNPT and not just
put it in the roadmap.

>
> Page 28: Section 4.5. Change the title into: "Time Stamp Protocols"
>

Somebody else suggested "Time Stamping and Data Validation and
Certification Server Protocols" can we use that instead?

>
> Page 39: Section on POP. It should be noticed that POP is NOT always
> needed. For some (old) "poorly designed" protocols, POP is needed
> when the SAME key is being used for authentication purposes and non
> repudiation purposes. Basically, if the protocol makes sure that the
> identifier of the public key certificate is protected by the end
> user signature, then POP does not need to be performed by the CA.
> For the case of encryption, see the proposed text replacement. Here
> is a full text replacement for that topic:
>

In general, I have no real concerns with what you propose just a few
questions.

>
> 5.2 POP
>
> Proof of Possession, or POP, or also CA POP, means that the CA is
> adequately convinced that the entity requesting a PKC containing a
> public key Y has access to the private key X corresponding to that
> public key.
>
> There has been some debate whether POP was or not needed.
>
> This question needs to be addressed separately considering the
> context of use of the key, in particular whether a key is used for
> an authentication or non repudiation service, or in a
> confidentiality service. Note that this does not map to the key
> usage bit directly, since it is possible to use a confidentiality
> key to perform an authentication service, e.g. by asking to decrypt
> an encrypted challenge.
>
> 5.2.1 POP for Signing Keys
>
> Suppose Alice legitimately has private key X and its corresponding
> public key Y. Alice has a PKC from Charlie, a CA, containing Y.
> Alice uses X to sign a transaction T. Without POP, Mal could also
> get a PKC from Charlie containing the same public key, Y. Now, there
> are two possible threats: Mal could claim to have been the real
> signer of T; or Alice can falsely deny signing T, claiming that it
> was instead Mal. Since no one can reliably prove that Mal did or did
> not ever possess X, neither of these claims can be refuted, and thus
> the service provided by and the confidence in the PKI has been
> defeated. (Of course, if Mal really did possess X, Alice's private
> key, then no POP mechanism in the world will help, but that is a
> different problem.)
>
> Protection can be gained by having Alice, as the true signer of the
> transaction, include in the signed information her PKC or an
> identifier of her PKC (e.g., a hash of her PKC). This makes
> impossible for Mal to claim authorship because he does not know the
> private key from Alice and thus is unable to include his certificate
> under the signature.
>

The last sentence says "impossible."  What it used to say was:

This might make it more difficult for Mal to claim authorship - he would
have to assert that he incorrectly included Alice's PKC, rather than his
own. However, it would not stop Alice from falsely repudiating her
actions. Since the PKC itself is a public item, Mal indeed could have
inserted Alice's PKC into the signed transaction, and thus its presence
does not indicate that Alice was the one who participated in the
now-repudiated transaction. The only reliable way to stop this attack is
to require that Mal prove he possesses X before his PKC is issued.

What was it that you didn't like from the previous text?

>
> The adequate protection may be obtained in the general case, by
> mandating the inclusion of a reference of the certificate every time
> a signature (or non repudiation) key is being used in a protocol.
>
> However, because all the protocols were not doing so, a conservative
> measure has been taken by requesting POP to be performed by CAs. It
> should thus be understood, that this measure is not strictly
> necessary and is only a temporary measure to make old protocols
> secure. New protocols or data formats are being developed. If the
> key being used is always used in a context where the identifier of
> the certificate is included in the protocol, then POP by the CA is
> not necessary. The inclusion of the identifier of the certificate in
> the protocol or data format may be understood as POP being performed
> at the transaction time rather than by the CA, at the registration
> time of the user in the PKI.
>

The text indicating that the need for POP for signing keys not used for
non-repudiation was removed.  What didn't you like about it?

I think the rest of the POP rewrite looks fine.

>
> 5.2.2 POP for Key Management Keys
>
> Suppose that Al is a new instructor in the Computer Science
> Department of a local University. Al has created a draft final exam
> for the Introduction to Networking course he is teaching. He wants
> to send a copy of the draft final to Dorothy, the Department Head,
> for her review prior to giving the exam. This exam will of course be
> encrypted, as several students have access to the computer system.
> However, a quick search of the PKC repository (e.g., search the
> repository for all records with subjectPublicKey=Dorothy's-value)
> turns up the fact that several students have PKCs containing the
> same public key management key as Dorothy. At this point, if no POP
> has been done by the CA, Al has no way of knowing whether all of the
> students have simply created these PKCs without knowing the
> corresponding private key (and thus it is safe to send the encrypted
> exam to Dorothy), or whether the students have somehow acquired
> Dorothy's private key (and thus it is certainly not safe to send the
> exam).
>
> The later case may seem unsafe. However, if the other students have
> acquired the key, they do not even need to publish their
> certificates and can simply decrypt in parallel.
>
> The end story is that, if the key only known to Dorothy, there is no
> problem. Thus POP by the CA is not needed.
>
> If the key, like a Diffie-Hellman key, is used for an authentication
> service the answer depends from the protocol being used. In the
> former example, the decryption was done locally and no data was sent
> back on the wire. In an authentication protocol, the story is
> different because either some encrypted or decrypted data is sent
> back. If the data sent back contains the identifier of the
> certificate in a way that it cannot be modified without that
> modification being detected, then there is no need for POP. On the
> contrary, POP by the CA is needed.
>
> As a conservative measure, POP for encryption keys is recommended,
> but it should be realized that it is not always needed.
>
> In general it should be noticed that POP at the time of the
> transaction is much superior than POP made by the CA, since it is
> possible in real time to be sure that everything is correct, rather
> than rely on that verification to be done at the time of
> registration by the CA. Should the CA fail in that verification,
> then there is a security breach. On the contrary, doing POP at the
> time of the transaction, eliminates that problem.
>
> CMP requires that POP be provided for all keys, either through on-
> line or out-of-band means. There are any number of ways to provide
> POP, and the choice of which to use is a local matter. Additionally,
> a PKC requester can provide POP to either a CA or to an RA, if the
> RA can adequately assure the CA that POP has been performed. Some of
> the acceptable ways to provide POP include [the following text has
> been kept unchanged]:
>
>  - Out-of-band means:
>
>  - For keys generated by the CA or an RA (e.g., on a token such as
>    a smart card or PCMCIA card), possession of the token can
>    provide adequate proof of possession of the private key.
>
>  - For user-generated keys, another approach can be used in
>    environments where "key recovery" requirements force the
>    requester to provide a copy of the private key to the CA or an
>    RA. In this case, the CA will not issue the requested PKC until
>    such time as the requester has provided the private key. This
>    approach is in general not recommended, as it is extremely
>    risky (e.g., the system designers need to figure out a way to
>    protect the private keys from compromise while they are being
>    sent to the CA/RA/other authority, and how to protect them
>    there), but it can be used.
>
>  - On-line means:
>
>  - For signature keys that are generated by an EE, the requester
>    of a PKC can be required to sign some piece of data (typically,
>    the PKC request itself) using the private key. The CA will then
>    use the requested public key to verify the signature. If the
>    signature verification works, the CA can safely conclude that
>    the requester had access to the private key. If the signature
>    verification process fails, the CA can conclude that the
>    requester did not have access to the correct private key, and
>    reject the request.
>
>  - For key management keys that are generated by the requester,
>    the CA can send the user the requested public key, along with
>    the CA's own private key, to encrypt some piece of data, and
>    send it to the requester to be decrypted. For example, the CA
>    can generate some random challenge, and require some action to
>    be taken after decryption (e.g., "decrypt this encrypted random
>    number and send it back to me"). If the requester does not take
>    the requested action, the CA concludes that the requester did
>    not possess the private key, and the PKC is not issued.
>
> Page 42: Section 5.3.1  on the key usage bits. The story about the
> digital signature and NR bit is not correct. Setting the NR bit does
> NOT means that the Signature bit must be present. [FORMAT] is clear
> on that topic. 4 th line from first paragraph. Remove "and/or
> nonRepudiation" then after make "bit" singular (i.e. remove the s).
>

Okay.

>
> Page 43. In the note in the middle of the page, delete the sentence:
> "However, the nonRepudiation key usage bit is provided as an
> indicator that such keys should not be used as a component of a
> system providing a non-repudiation service."
>

Okay.

>
> Page 43. About the discussion, starting with "According to
> [SIMONETTI], ..." I would propose a global replacement until the end
> of that topic:
>
> " The intent is that the digitalSignature bit should be set when
> what is desired is the ability to sign ephemeral transactions; e.g.,
> for a single session authentication. These transactions are
> "ephemeral" in the sense that they are important only while they are
> in existence; after the session is terminated, there is no long-term
> record of the digital signature and its properties kept.
>
> When something is intended to be kept for some period of time for
> non repudiation purposes, the nonRepudiation bit shall be set. This
> implies that an application will digitally sign something that may
> be used for non repudiation purposes; this bit must be turn on.
>
> A question came whether it was appropriate to turn on both the
> signature bit and the NR bit. It is possible to use the same key for
> two different purposes, but there is some danger to do so, if it may
> exist cases where the protocol invoking the signature key is not
> fully known. In such a case, it could happen, that instead of asking
> the signature of a challenge, the protocol could ask a signature
> over a hash that represents the hash of some transaction. A signer
> could then agree on the terms of that transaction, instead of
> opening a door which would be the case if the challenge is correctly
> signed. In order to avoid this kind of problem, two different keys
> are recommended. However, if, when using the same key for two
> different purposes, it can be made sure that such misuse of the key
> cannot happen, then this is not a problem. Since in many cases, it
> is difficult to make the verification and thus get that assurance, a
> good practice is to set only one bit at a time and thus use two
> different keys."
>

On this one, I'm going to let the dust settle a bit before I make a
change.  So I'm going to keep your comments in mind when I rewrite the
section.  I'll make sure the discussion gets to the list.

>
> Page 44. Section 5.4. Trust model. IMO, the approach that is
> described is not appropriate. Trust is not related to an entity CA,
> but to the trust placed by the EE in the context of an application.
> Also there is not ONE trust point necessarily, but several. The
> choice is NOT between a TOP CA (which does not necessarily exist)
> and the local CA of the EE. The whole section should be changed to
> reflect this.
>
> Proposed change :
>
> " An important design decision is which trust pointS for a
> particular application should be used by a particular EE. This
> decision depends from the context of use, i.e. from the kind of
> application being used. For example, in a SET transaction, the bank
> sets a single trust point and the end user has no choice about this.
> In a different context the user (or a domain administrator) may
> select which trust points to use.
>
> More text might be needed along these lines.
>

Okay for the next version I'll try to have something more along your
lines.  It was just something I threw together.

> A few typos (not all):

I'll get these in the next go around..

>
> Page 5: Sercurity
> Page 7: refrnce, posess, complimentary.
> Page 8: devloped
> Page 9: mecaisms , possesion, possed, repudation,  "can produced" to
> be replaced by "can be produced"
> Page 13: informtoin
> Page 21: In the sentence "[TSP] also defines" replace "defines" by
> "defined".
> Page 25: "Diffie-Hellman a key" to be replaced by "a Diffie-Hellman
> key"

Cheers,

spt

From: "Todd Glassey @ GMT" <[email-masked]>
To: "Michael Duren" <[email-masked]>, "Denis Pinkas" <[email-masked]>
Cc: <[email-masked]>
Subject: Timestamping vs timesetting...
Date: Wed, 3 Nov 1999 12:48:02 -0800

Thanks Michael,
I also wanted to twist this thread a bit to talk about the difference in
timesetting and timestamping and how important timesetting is to all of us.

Timesetting being the management of the underlying timebase, and
timestamping, of course being the memorialization of some event or event
stream as an evidentiary process.

Virtually every thing this group has done to date seems to revolve around
some "embedded assumption of timesetting". The timestamping model for
instance does not take into account the source of the time nor do any of the
policy fabric services that we have devised. This one key parametric
variable is totally unauthenticated, unaudited, and most astoundingly taken
as wrote pretty much everywhere.

I again suggest that PKIX in general may need a formal 'BCP Practices'
document(s) that specifies the constraints of operating PKI, more than the
current RoadMap at the End-Use Levels and maybe some forms of auditing
guidelines like those being done by other groups.

Todd
----- Original Message -----
From: "Michael Duren" <[email-masked]>
To: "Denis Pinkas" <[email-masked]>; "Todd Glassey @ GMT"
<[email-masked]>
Cc: <[email-masked]>
Sent: Wednesday, November 03, 1999 09:11 AM
Subject: Re: Timestamping Standards.

> Denis,
>
> Why don't you address Todd's proposed issue as it was stated?  Can we at
> least have a discussion regarding the scope of the spec and Todd's
> recommendation to consider industry requirements?
>
> Do you think that the current timestamping definition meets the needs of
the
> OATS requirements?
>
> Should it meet or attempt to address those requirements?  If not, should
the
> IETF address this in any way?
>
> Are there other industry requirements that should be considered?
>
> Is this within scope of this timestamping effort?  If not, where is the
> scope of this standard stated.  If so, what are some other suggestions for
> these addressing industry requirements?
>
> What does the group think?
>
> We touched on the scope issue at the Oslo meetings, but the group has not
> discussed it since then.
>
>
> Mike
>
>
> -----Original Message-----
> From: Denis Pinkas <[email-masked]>
> To: Todd Glassey @ GMT <[email-masked]>
> Cc: [email-masked] <[email-masked]>
> Date: Wednesday, November 03, 1999 11:17 AM
> Subject: Re: Timestamping Standards.
>
>
> >Todd,
> >
> >My comments are in line.
> >
> >> Denis, Robert - here we are again, disagreeing on the Time Stamping
> >> Protocols.
> >>
> >> OK, if I agree to drop these issues, can I/we add an appendix or
> supplement
> >> to the current draft that contains a BCP model for maintaining the
Clock
> >> Timebase.
> >
> >Strange kind of bargain ...  :-|
> >
> >Anyway the decision is not on us, but on a working group consensus.
> >It still appears that they are only two, may be three ?? people in
> >this working group supporting this idea. This does not form a
> >consensus. Since the Washington meeting is now very close, I propose
> >that we do not use the bandwith of the PKIX mailing list and discuss
> >this either at the PKIX meetings and/or in the corridors.
> >
> >Denis
> >
> >
> >> This of course would be at the OS level, that is below the TS
> >> Protocol that would be use-model compliant with OATS requirements.
> >>
> >> This would satisfy me and would allow the process to continue with this
> >> status-quo.
> >>
> >> Also this addition would address the need for this BCP Model in the
'Road
> >> Map' as well, and eliminate the need to address this further for any
> other
> >> of the protocols being forged in the furnace of PKIX or its related
WG's.
> >>
> >> Bluntly, this appendix could be a recommendation for timebase
management
> in
> >> all PKI or IETF Operating Models.
> >>
> >> Todd
> >>
> >> ----- Original Message -----
> >> From: "Denis Pinkas" <[email-masked]>
> >> To: "Todd Glassey @ GMT" <[email-masked]>
> >> Cc: <[email-masked]>; <[email-masked]>
> >> Sent: Wednesday, November 03, 1999 01:10 AM
> >> Subject: Re: Timestamping Standards.
> >>
> >> > > Hi all,  in the Timestamping services drafts there might want to be
a
> >> > > mention of the only standards regarding timestamping currently on
the
> >> books
> >> > > today, because the may change some of the focus in this effort.
> >> > >
> >> > > They provide for a requirements to provably timestamp within three
> (3)
> >> > > seconds of UTC and these are of course the NASD OATS requirements.
> NASD
> >> for
> >> > > thos that are unaware is the NAtional Association of Securities
> Dealers
> >> and
> >> > > any solution that is proffered as a timestamping one for commercial
> >> purposes
> >> > > should ought to fulfill the only mandate on the books today. To get
> more
> >> of
> >> > > this try the OATS pages at the www.nasdr.com site.
> >> > >
> >> > > I suggest that to satisfy OATS, several use-specific assumptions
have
> to
> >> be
> >> > > made like the timestamping system itself has some provable
connection
> to
> >> a
> >> > > "reliable" source of time, and the audit model to prove that the
time
> >> > > setting instance at the client end was accomplished appropriately,
> and
> >> that
> >> > > these assumptions should be spelled out i detail in the Draft
> >> > >
> >> > > Any comments?
> >> >
> >> > Todd,
> >> >
> >> > The draft says:
> >> >
> >> > " 2.1. Requirements of the TSA
> >> >
> >> > The TSA is REQUIRED:
> >> >
> >> >      1.  to provide a trustworthy source of time."
> >> >
> >> > To this respect there is no need to *prove* anything else. Any
> >> > additional information from the TSA may be carried back in the
> >> > security policy.
> >> >
> >> > Denis
> >> >
> >> >
> >> > > Todd Glassey
> >> >
> >
>
>

From: "Linn, John" <[email-masked]>
To: [email-masked]
Subject: RE: I-D ACTION:draft-ietf-pkix-laap-00.txt
Date: Wed, 3 Nov 1999 15:40:07 -0500 

I've a few thoughts re the LAAP draft.

I'm somewhat concerned about the definition of profile strings as AC
selectors.  If the usual practice is that profile strings' values are
meaningful only by bilateral agreement, this implies a lot of configuration
and could be susceptible to misinterpretation by punning, especially if/as
LRQs grow to interact with more than just one LRP. At the risk of a
contrived example, a Mr. Teller's name, passed as a profile hint, shouldn't
be interpreted as soliciting a role AC allowing him to handle cash at a
bank.  I think general use of an OID tag with optional text qualifier would
be safer, more general, and could contribute to more effective
interoperability among prospective LAAP peers.  Some uniform tag values
(e.g., "role") could be usefully defined.  I'm neutral as to whether the OID
is carried in string-encoded form or not, but believe that some level of
syntactic structure needs to be present to distinguish the OID from any
associated qualifier(s). 

Is the fact of LAAP's definition within CMP likely to create demultiplexing
problems in end systems where both LAAP and CMP services are provided, but
by different internal entities?

--jl

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]
> Sent: Wednesday, October 13, 1999 6:54 AM
> Cc: [email-masked]
> Subject: I-D ACTION:draft-ietf-pkix-laap-00.txt
> 
> 
> A New Internet-Draft is available from the on-line 
> Internet-Drafts directories.
> This draft is a work item of the Public-Key Infrastructure 
> (X.509) Working Group of the IETF.
> 
> 	Title		: Limited AttributeCertificate 
> Acquisition Protocol
> 	Author(s)	: S. Farrell, D. Chadwick
> 	Filename	: draft-ietf-pkix-laap-00.txt
> 	Pages		: 11
> 	Date		: 12-Oct-99
> 	
> The PKIX working group is profiling the use of X.509 attribute
> certificates. This document specifies a deliberately limited
> protocol for requesting an attribute certificate from a server. It
> is intended to be complementary to the use of LDAP for AC retrieval,
> covering those cases where use of an LDAP server is not suitable due
> to the type of authorization model being employed. For many other
> cases, the use of LDAP is preferred.
> 
> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-ietf-pkix-laap-00.txt
> 
> Internet-Drafts are also available by anonymous FTP. Login 
> with the username
> "anonymous" and a password of your e-mail address. After logging in,
> type "cd internet-drafts" and then
> 	"get draft-ietf-pkix-laap-00.txt".
> 
> A list of Internet-Drafts directories can be found in
> http://www.ietf.org/shadow.html 
> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
> 
> 
> Internet-Drafts can also be obtained by e-mail.
> 
> Send a message to:
> 	[email-masked].
> In the body type:
> 	"FILE /internet-drafts/draft-ietf-pkix-laap-00.txt".
> 	
> NOTE:	The mail server at ietf.org can return the document in
> 	MIME-encoded form by using the "mpack" utility.  To use this
> 	feature, insert the command "ENCODING mime" before the "FILE"
> 	command.  To decode the response(s), you will need "munpack" or
> 	a MIME-compliant mail reader.  Different MIME-compliant 
> mail readers
> 	exhibit different behavior, especially when dealing with
> 	"multipart" MIME messages (i.e. documents which have been split
> 	up into multiple messages), so check your local documentation on
> 	how to manipulate these messages.
> 		
> 		
> Below is the data which will enable a MIME compliant mail reader
> implementation to automatically retrieve the ASCII version of the
> Internet-Draft.
> 

Resent-Date: Wed, 3 Nov 1999 18:30:14 +0100 (MET)
Date: Wed, 3 Nov 1999 18:30:27 +0100 (MET)
From: Stefan Kelm <[email-masked]>
To: [email-masked]
Cc: [email-masked], [email-masked]
Reply-To: [email-masked]
Resent-Message-ID: <"_tMd6.A.N6E.mEHI4"@ns>
Resent-From: [email-masked]
Resent-Sender: [email-masked]
Subject: SEIS:  Re: Fresh version of the EU draft Electronic Signature directive

--- Message on the SEIS mailing list ([email-masked])

Stefan,

> I have updated the QC web page with the latest official version of the
> ES-directive, Included in the Common position paper adopted by the Council
> on June 28, 1999.
>
> This version contains an updated version of Annex III, which I was
> referring to earlier.

please note that last week the European Parliament approved this Common
Position. However, a few amendments from the European Committee were agreed
upon during the plenary session. You can download the session protocol
including those amendments from www.europarl.eu.int.

Next, the European Council will have to approve the modified text. The
Directive will probably enter into force at the end of this year.

Cheers,

        Stefan.

______________________________________________________________________________
Stefan Kelm            PGP key: "finger [email-masked]" or via key server
DFN-PCA                                                      <[email-masked]>
Vogt-Koelln-Str. 30                               http://www.pca.dfn.de/~kelm/
22527 Hamburg (Germany)                   Tel: +49 40 428 83-2262 / Fax: -2241

----------------- SEIS mailing list ([email-masked])
Info about this list: http://www.nc-forum.com/seis
SEIS Contact: [email-masked]

Date: Wed, 03 Nov 1999 09:59:13 -0800
From: Ed Gerck <[email-masked]>
CC: [email-masked]
Subject: [junk] Re: auto subscribe

[email-masked] wrote:

> WARNING:
>         Please try to use [email-masked]'
>         the next time when issuing (un)subscribe requests.
>
> You have added to the subscriber list of:
>
>         [email-masked]
>
> the following mail address:
>
>         [email-masked]
>
> By default, copies of your own submissions will be returned.

That is what happens when bots rave the land. At the
end, it will be my bot against your bot, NR and all ;-)

Cheers,

Ed Gerck

From: [email-masked]
Date: Wed, 3 Nov 1999 18:45:11 +0100 (MET)
To: [email-masked]
Subject: Re: unsubscribe [email-masked]

                 32752 [email-masked]
[email-masked]

You have been removed from the list.

---- 
You are no longer subscribing to the SEIS Mailing list.

------

If this wasn't your intention or you are having problems getting yourself
unsubscribed, reply to this mail now (quoting it entirely (for diagnostic
purposes), and of course adding any comments you see fit).

Transcript of unsubscription request follows:
-- 
>From [email-masked]  Wed Nov  3 18:45:08 1999
>Received: from ns.secondary.com (ns.secondary.com [208.184.76.39])
>	by ns.webway.se (8.9.3/8.9.3) with ESMTP id SAA20168
>	for <[email-masked]>; Wed, 3 Nov 1999 18:41:36 +0100 (MET)
>Received: by ns.secondary.com (8.9.3/8.9.3) id JAA11488;
>	Wed, 3 Nov 1999 09:43:20 -0800 (PST)
>Date: Wed, 3 Nov 1999 09:43:20 -0800 (PST)
>Message-Id: <[email-masked]>
>To: [email-masked]
>From: [email-masked]
>Subject: unsubscribe [email-masked]
>
>unsubscribe [email-masked]
>

Resent-Date: Wed, 3 Nov 1999 18:30:14 +0100 (MET)
Date: Wed, 3 Nov 1999 18:30:27 +0100 (MET)
From: Stefan Kelm <[email-masked]>
To: [email-masked]
Cc: [email-masked], [email-masked]
Reply-To: [email-masked]
Resent-Message-ID: <"_tMd6.A.N6E.mEHI4"@ns>
Resent-From: [email-masked]
Resent-Sender: [email-masked]
Subject: SEIS:  Re: Fresh version of the EU draft Electronic Signature directive

--- Message on the SEIS mailing list ([email-masked])

Stefan,

> I have updated the QC web page with the latest official version of the
> ES-directive, Included in the Common position paper adopted by the Council
> on June 28, 1999.
>
> This version contains an updated version of Annex III, which I was
> referring to earlier.

please note that last week the European Parliament approved this Common
Position. However, a few amendments from the European Committee were agreed
upon during the plenary session. You can download the session protocol
including those amendments from www.europarl.eu.int.

Next, the European Council will have to approve the modified text. The
Directive will probably enter into force at the end of this year.

Cheers,

        Stefan.

______________________________________________________________________________
Stefan Kelm            PGP key: "finger [email-masked]" or via key server
DFN-PCA                                                      <[email-masked]>
Vogt-Koelln-Str. 30                               http://www.pca.dfn.de/~kelm/
22527 Hamburg (Germany)                   Tel: +49 40 428 83-2262 / Fax: -2241

----------------- SEIS mailing list ([email-masked])
Info about this list: http://www.nc-forum.com/seis
SEIS Contact: [email-masked]

From: [email-masked]
Date: Wed, 3 Nov 1999 18:30:12 +0100 (MET)
To: [email-masked]
Subject: Re: auto subscribe

WARNING:
	Please try to use [email-masked]'
	the next time when issuing (un)subscribe requests.

You have added to the subscriber list of:

	[email-masked]

the following mail address:

	[email-masked]

By default, copies of your own submissions will be returned.

---------- SEIS Mailing list
Thank you for subscribing.

Important! Save this letter for future reference!

You are now a subscriber to the SEIS Mailing list

For your reference, a copy of your mail is attached.

--
>From [email-masked]  Wed Nov  3 18:30:07 1999
>Received: from procert.cert.dfn.de (kelm@[134.100.14.1])
>	by ns.webway.se (8.9.3/8.9.3) with ESMTP id SAA20071
>	for <[email-masked]>; Wed, 3 Nov 1999 18:29:08 +0100 (MET)
>Received: (from kelm@localhost)
>	by procert.cert.dfn.de (8.9.1a/8.9.1) id SAA19403;
>	Wed, 3 Nov 1999 18:30:27 +0100 (MET)
>Date: Wed, 3 Nov 1999 18:30:27 +0100 (MET)
>From: Stefan Kelm <[email-masked]>
>Message-Id: <[email-masked]>
>To: [email-masked]
>Cc: [email-masked], [email-masked]
>Reply-To: [email-masked]
>X-Sun-Charset: US-ASCII
>Subject: auto subscribe
>

Date: Wed, 3 Nov 1999 18:30:27 +0100 (MET)
From: Stefan Kelm <[email-masked]>
To: [email-masked]
Subject: Re: Fresh version of the EU draft Electronic Signature directive
Cc: [email-masked], [email-masked]
Reply-To: [email-masked]

Stefan,

> I have updated the QC web page with the latest official version of the
> ES-directive, Included in the Common position paper adopted by the Council
> on June 28, 1999.
>
> This version contains an updated version of Annex III, which I was
> referring to earlier.

please note that last week the European Parliament approved this Common
Position. However, a few amendments from the European Committee were agreed
upon during the plenary session. You can download the session protocol
including those amendments from www.europarl.eu.int.

Next, the European Council will have to approve the modified text. The
Directive will probably enter into force at the end of this year.

Cheers,

        Stefan.

______________________________________________________________________________
Stefan Kelm            PGP key: "finger [email-masked]" or via key server
DFN-PCA                                                      <[email-masked]>
Vogt-Koelln-Str. 30                               http://www.pca.dfn.de/~kelm/
22527 Hamburg (Germany)                   Tel: +49 40 428 83-2262 / Fax: -2241

Reply-To: "Michael Duren" <[email-masked]>
From: "Michael Duren" <[email-masked]>
To: "Denis Pinkas" <[email-masked]>, "Todd Glassey @ GMT" <[email-masked]>
Cc: <[email-masked]>
Subject: Re: Timestamping Standards.
Date: Wed, 3 Nov 1999 12:11:10 -0500

Denis,

Why don't you address Todd's proposed issue as it was stated?  Can we at
least have a discussion regarding the scope of the spec and Todd's
recommendation to consider industry requirements?

Do you think that the current timestamping definition meets the needs of the
OATS requirements?

Should it meet or attempt to address those requirements?  If not, should the
IETF address this in any way?

Are there other industry requirements that should be considered?

Is this within scope of this timestamping effort?  If not, where is the
scope of this standard stated.  If so, what are some other suggestions for
these addressing industry requirements?

What does the group think?

We touched on the scope issue at the Oslo meetings, but the group has not
discussed it since then.

Mike

-----Original Message-----
From: Denis Pinkas <[email-masked]>
To: Todd Glassey @ GMT <[email-masked]>
Cc: [email-masked] <[email-masked]>
Date: Wednesday, November 03, 1999 11:17 AM
Subject: Re: Timestamping Standards.

>Todd,
>
>My comments are in line.
>
>> Denis, Robert - here we are again, disagreeing on the Time Stamping
>> Protocols.
>>
>> OK, if I agree to drop these issues, can I/we add an appendix or
supplement
>> to the current draft that contains a BCP model for maintaining the Clock
>> Timebase.
>
>Strange kind of bargain ...  :-|
>
>Anyway the decision is not on us, but on a working group consensus.
>It still appears that they are only two, may be three ?? people in
>this working group supporting this idea. This does not form a
>consensus. Since the Washington meeting is now very close, I propose
>that we do not use the bandwith of the PKIX mailing list and discuss
>this either at the PKIX meetings and/or in the corridors.
>
>Denis
>
>
>> This of course would be at the OS level, that is below the TS
>> Protocol that would be use-model compliant with OATS requirements.
>>
>> This would satisfy me and would allow the process to continue with this
>> status-quo.
>>
>> Also this addition would address the need for this BCP Model in the 'Road
>> Map' as well, and eliminate the need to address this further for any
other
>> of the protocols being forged in the furnace of PKIX or its related WG's.
>>
>> Bluntly, this appendix could be a recommendation for timebase management
in
>> all PKI or IETF Operating Models.
>>
>> Todd
>>
>> ----- Original Message -----
>> From: "Denis Pinkas" <[email-masked]>
>> To: "Todd Glassey @ GMT" <[email-masked]>
>> Cc: <[email-masked]>; <[email-masked]>
>> Sent: Wednesday, November 03, 1999 01:10 AM
>> Subject: Re: Timestamping Standards.
>>
>> > > Hi all,  in the Timestamping services drafts there might want to be a
>> > > mention of the only standards regarding timestamping currently on the
>> books
>> > > today, because the may change some of the focus in this effort.
>> > >
>> > > They provide for a requirements to provably timestamp within three
(3)
>> > > seconds of UTC and these are of course the NASD OATS requirements.
NASD
>> for
>> > > thos that are unaware is the NAtional Association of Securities
Dealers
>> and
>> > > any solution that is proffered as a timestamping one for commercial
>> purposes
>> > > should ought to fulfill the only mandate on the books today. To get
more
>> of
>> > > this try the OATS pages at the www.nasdr.com site.
>> > >
>> > > I suggest that to satisfy OATS, several use-specific assumptions have
to
>> be
>> > > made like the timestamping system itself has some provable connection
to
>> a
>> > > "reliable" source of time, and the audit model to prove that the time
>> > > setting instance at the client end was accomplished appropriately,
and
>> that
>> > > these assumptions should be spelled out i detail in the Draft
>> > >
>> > > Any comments?
>> >
>> > Todd,
>> >
>> > The draft says:
>> >
>> > " 2.1. Requirements of the TSA
>> >
>> > The TSA is REQUIRED:
>> >
>> >      1.  to provide a trustworthy source of time."
>> >
>> > To this respect there is no need to *prove* anything else. Any
>> > additional information from the TSA may be carried back in the
>> > security policy.
>> >
>> > Denis
>> >
>> >
>> > > Todd Glassey
>> >
>

Date: Wed, 03 Nov 1999 09:09:59 -0800
To: [email-masked]
From: Paul Hoffman / IMC <[email-masked]>
Subject: Re: US relaxed export policy - When/IF and how?

Um, is any of this related specifically to PKIX? There are dozens of other 
mailing lists on which this is being discussed.

--Paul Hoffman, Director
--Internet Mail Consortium

From: [email-masked] (Peter Gutmann)
To: [email-masked]
Subject: Re: US relaxed export policy - When/IF and how?
Sender: [email-masked]
Reply-To: [email-masked]
Date: Thu, 4 Nov 1999 05:32:59 (NZDT)

"Bob Jueneman" <[email-masked]> writes:

>The absurdity of deciding crypto strength based on the type of store-front
>the product was purchased through has certainly not be lost on organizations
>such as the Business Software Alliance and the Alliance for Computer Privacy.
>If you can download the product, even for free, off the Internet, that
>apparently doesn't count as "retail".  In fact, even if you do sell a product
>through a store-front retail operation, such as a small-business, five user
>license version of something like Novell's NetWare, if that version could be
>upgraded to cover more users by simply buying additional licenses, that
>wouldn't be considered retail either.

There is one explanation for this which makes some sense, since the intent of
the controls is to delay the widespread availability of strong crypto
(specifically where it'll affect Echelon) for as long as possible you can
further this goal and silence your critics by allowing the export of security
pablum to the masses but not allowing the export of real security where it
matters.   At the moment it looks like the announcement has pretty successfully
derailed any attempts to reform the export controls via legislation while
probably not allowing any crypto out for areas where it'll make a difference -
one way I've seen it put is "You can export Microsoft security but you can't
export Sun or IBM or XXX security".  OTOH given the USG's long track record of
announcing Clayton's liberalisations (one every three months on average since
1994) I can't imagine whatever will appear in December will make much
difference in practice.

[I'm still puzzled over the announced changes though.  To me the best change
 would have been to "liberalise" by allowing source code exports, which derails
 all of the current legal challenges while still not making much difference to
 the world in general.  Allowing mass-market binaries but not source code seems
 to achieve exactly the opposite of what the spooks would want]

Peter.

Date: Wed, 03 Nov 1999 17:17:09 +0100
From: Denis Pinkas <[email-masked]>
Organization: Bull
To: "Todd Glassey @ GMT" <[email-masked]>
CC: [email-masked]
Subject: Re: Timestamping Standards.

Todd,

My comments are in line.

> Denis, Robert - here we are again, disagreeing on the Time Stamping
> Protocols.
> 
> OK, if I agree to drop these issues, can I/we add an appendix or supplement
> to the current draft that contains a BCP model for maintaining the Clock
> Timebase. 

Strange kind of bargain ...  :-|

Anyway the decision is not on us, but on a working group consensus.
It still appears that they are only two, may be three ?? people in
this working group supporting this idea. This does not form a
consensus. Since the Washington meeting is now very close, I propose
that we do not use the bandwith of the PKIX mailing list and discuss
this either at the PKIX meetings and/or in the corridors.

Denis

> This of course would be at the OS level, that is below the TS
> Protocol that would be use-model compliant with OATS requirements.
> 
> This would satisfy me and would allow the process to continue with this
> status-quo.
> 
> Also this addition would address the need for this BCP Model in the 'Road
> Map' as well, and eliminate the need to address this further for any other
> of the protocols being forged in the furnace of PKIX or its related WG's.
> 
> Bluntly, this appendix could be a recommendation for timebase management in
> all PKI or IETF Operating Models.
> 
> Todd
> 
> ----- Original Message -----
> From: "Denis Pinkas" <[email-masked]>
> To: "Todd Glassey @ GMT" <[email-masked]>
> Cc: <[email-masked]>; <[email-masked]>
> Sent: Wednesday, November 03, 1999 01:10 AM
> Subject: Re: Timestamping Standards.
> 
> > > Hi all,  in the Timestamping services drafts there might want to be a
> > > mention of the only standards regarding timestamping currently on the
> books
> > > today, because the may change some of the focus in this effort.
> > >
> > > They provide for a requirements to provably timestamp within three (3)
> > > seconds of UTC and these are of course the NASD OATS requirements. NASD
> for
> > > thos that are unaware is the NAtional Association of Securities Dealers
> and
> > > any solution that is proffered as a timestamping one for commercial
> purposes
> > > should ought to fulfill the only mandate on the books today. To get more
> of
> > > this try the OATS pages at the www.nasdr.com site.
> > >
> > > I suggest that to satisfy OATS, several use-specific assumptions have to
> be
> > > made like the timestamping system itself has some provable connection to
> a
> > > "reliable" source of time, and the audit model to prove that the time
> > > setting instance at the client end was accomplished appropriately, and
> that
> > > these assumptions should be spelled out i detail in the Draft
> > >
> > > Any comments?
> >
> > Todd,
> >
> > The draft says:
> >
> > " 2.1. Requirements of the TSA
> >
> > The TSA is REQUIRED:
> >
> >      1.  to provide a trustworthy source of time."
> >
> > To this respect there is no need to *prove* anything else. Any
> > additional information from the TSA may be carried back in the
> > security policy.
> >
> > Denis
> >
> >
> > > Todd Glassey
> >

Date: Wed, 03 Nov 1999 08:40:13 -0700
From: "Bob Jueneman" <[email-masked]>
To: <[email-masked]>, <[email-masked]>
Subject: Re: US relaxed export policy - When/IF and how?

Anders, my understanding is that although the new policy has been announced, 
the devil is in the details (the regulations), which should be published around
December 15th.  At that point it will be a race to see who can ship a product
the fastest.

One serious complication is the desire within certain factions of the US government 
to exclude networking products from the general relaxation.  To this end, they 
are attempting to fashion a particular tortuous distinction between mass-market 
products and "retail" products, claiming that a retail product is one the ordinary user
can buy off the shelf at ComputersRUs, vs. other products that are sold though
distribution channels and may or may not be custom installed. (These guys never 
give up, even after a high-level executive decision has been made.)

The significant difference is that although non-retail products may be exported 
(sold or given away) to individuals, they may not be exported to foreign governments
without extensive reporting and/or key size limitations.  Why some government 
procurement officer couldn't order the product in his own name isn't explained.
In addition, especially in Europe where many institutions are at least partially 
government owned, it would presumably not be possible to sell full strength crypto
to Fiat, Airbus, Deutsche Telecom, the British Museum, or even some high 
school in Zurich.

The absurdity of deciding crypto strength based on the type of store-front the 
product was purchased through has certainly not be lost on organizations such as the
Business Software Alliance and the Alliance for Computer Privacy.  If you can 
download the product, even for free, off the Internet, that apparently doesn't
count as "retail".  In fact, even if you do sell a product through a store-front
retail operation, such as a small-business, five user license version of something like
Novell's NetWare, if that version could be upgraded to cover more users by simply
buying additional licenses, that wouldn't be considered retail either.

Browsers will probably be exempt from this, although it certainly isn't clear why. But
servers, presumably including NT or the server version of Windows 2000, Solaris,
and even Linux, if it includes cryptography, would be more stringently controlled.

I predict you are going to see a lot of heavy political arm-twisting in the next several 
months, especially on one particular Presidential candidate who announced the policy
and needs support and contributions from places like San Jose and Redmond.

Stay tuned, in other words.

Bob

>>> Anders Rundgren <[email-masked]> 11/03/99 07:47AM >>>
Hi all crypto-nerds :-)

We who live in Europe are used to live with pretty "crummy" solutions for achieving
secure Internet-banking etc.   It is costly and inconvenient though!

Rumors says that the US government is changing the export regulations so my question is simply:

How long will we in Europe have to wait for strong cryptography in US-manufactured Browsers,
Operating systems, Certificates and Web-servers?

Regards
Anders Rundgren
Internet e-commerce Architect

From: [email-masked] (Peter Gutmann)
To: [email-masked]
Subject: How to identify certs to users
Sender: [email-masked]
Reply-To: [email-masked]
Date: Thu, 4 Nov 1999 04:59:55 (NZDT)

Spurred by recent questions on another mailing list about how to identify
certificates in a useful-to-humans manner, I've been doing a bit of poking
around to see how others solve the problem because I have no idea myself how to
make anything meaningful to the average end user from a DN.  By the looks of it
this is a problem which has occupied a number of people in the past, so I'll
try and put something coherent in the style guide to summarise the situation
and provide advice.  The following is based on a survey of a (somewhat small)
number of online repositories, most CA's either don't seem to publish their
certs or if they do they hide them really well, so I haven't been able to
check too many implementations of cert lookup:

-- Add to end of section on DN's --

As the above text has probably indicated, DN's don't really work - there's no
clear idea of what they should look like, most users don't know about (and
don't want to know about) X.500 and its naming conventions, and as a
consequence of this the DN can end up containing just about anything.  At the
moment they seem to be heading in two main directions:

 - Public CA's typically set C=CA country, O=CA name, OU=certificate type,
   CN=user name
   - A small subset of CA's in Europe which issue certs in accordance with
     various signature laws and profiles with their own peculiar requirements
     can have all sorts of oddities in the DN.  You won't run into many of
     these in the wild.
 - Private CA's (mostly people or organisations signing their own certs)
   typically set any DN fields supported by their software to whatever makes
   sense for them (some software requires all fields in the set
   {C,O,OU,SP,L,CN} to be filled in, leading to strange or meaningless
   entries).

Generally you'll only run into certs from public CA's, for which the general
rule is that the cert is identified by the CN and/or email address.  Some CA's
issue certs with identical CN's and use the email address to disambiguate them,
others modify the CN to make it unique.  The accepted user interface seems to
be to let users search on the CN and/or email address (and sometimes also the
serial number, which doesn't seem terribly useful), display a list of matches,
and let the user pick the cert they want.  Probably the best strategy for a
user interface which handles certs is:

  if( email address known )
    get a cert which matches the email address (any one should do);
  elseif( name known )
    search for all certs with CN=name;
    if( multiple matches )
      display email addresses for matched certs to user, let them choose;
  else
    error;

[Question for CA's: Do you require unique email addresses?  I managed to find
 some duplicates at Verisign, but not two active certs with the same email
 address]

[Some sort of recommendation here, probably telling people to assume that the
 email address is unique, CN's are non-unique, and other DN components can't be
 relied upon.  If you need something unique (for example for a database key),
 use an X.500 serialNumber in an altName directoryName or define your own
 otherName. I'm trying to come up with one-size-fits-most guidelines on how to
 identify a cert in practice]

Peter.

From: "Todd Glassey @ GMT" <[email-masked]>
To: "Marc Branchaud" <[email-masked]>, <[email-masked]>
Subject: Re: Possible patent issue with UTCTime hack
Date: Wed, 3 Nov 1999 07:59:41 -0800

Marc,
Seems to me that the problem in Certs is that there is no culpable mechanism
to deploy and prove the availability of "credible time" data. I think that
Certs should, in themselves, only list absolute time points, the use models
should provide a centerpoint of the windowing scheme that is reflected in
the evaluating of the Certs, but anyone that uses any time centric services
is responsible to prove that their time data is accurate and believable.
Especially CA's, RA's and other trust processors.

Seems to me that the key here is process used in the time setting services,
that is what and how the underlying OS has the Timebase set and proves it.
With this in mind, how would you get secure time data into a system?

Todd

----- Original Message -----
From: "Marc Branchaud" <[email-masked]>
To: <[email-masked]>
Sent: Tuesday, November 02, 1999 05:47 PM
Subject: Possible patent issue with UTCTime hack

>
> It seems that McDonnell Douglas has patented the date "windowing" that is
> used to get around Y2K problems:
>
> http://news.cnet.com/news/0-1009-200-1426450.html
>
> Since PKIX requires windowing UTCTime in certs, this may violate the
patent
> (note: I don't know anything about anything, especially patents).
>
> Marc
>

From: "Todd Glassey @ GMT" <[email-masked]>
To: "Denis Pinkas" <[email-masked]>
Cc: <[email-masked]>, <[email-masked]>
Subject: Re: Timestamping Standards.
Date: Wed, 3 Nov 1999 07:47:43 -0800

Denis, Robert - here we are again, disagreeing on the Time Stamping
Protocols.

OK, if I agree to drop these issues, can I/we add an appendix or supplement
to the current draft that contains a BCP model for maintaining the Clock
Timebase. This of course would be at the OS level, that is below the TS
Protocol that would be use-model compliant with OATS requirements.

This would satisfy me and would allow the process to continue with this
status-quo.

Also this addition would address the need for this BCP Model in the 'Road
Map' as well, and eliminate the need to address this further for any other
of the protocols being forged in the furnace of PKIX or its related WG's.

Bluntly, this appendix could be a recommendation for timebase management in
all PKI or IETF Operating Models.

Todd

----- Original Message -----
From: "Denis Pinkas" <[email-masked]>
To: "Todd Glassey @ GMT" <[email-masked]>
Cc: <[email-masked]>; <[email-masked]>
Sent: Wednesday, November 03, 1999 01:10 AM
Subject: Re: Timestamping Standards.

> > Hi all,  in the Timestamping services drafts there might want to be a
> > mention of the only standards regarding timestamping currently on the
books
> > today, because the may change some of the focus in this effort.
> >
> > They provide for a requirements to provably timestamp within three (3)
> > seconds of UTC and these are of course the NASD OATS requirements. NASD
for
> > thos that are unaware is the NAtional Association of Securities Dealers
and
> > any solution that is proffered as a timestamping one for commercial
purposes
> > should ought to fulfill the only mandate on the books today. To get more
of
> > this try the OATS pages at the www.nasdr.com site.
> >
> > I suggest that to satisfy OATS, several use-specific assumptions have to
be
> > made like the timestamping system itself has some provable connection to
a
> > "reliable" source of time, and the audit model to prove that the time
> > setting instance at the client end was accomplished appropriately, and
that
> > these assumptions should be spelled out i detail in the Draft
> >
> > Any comments?
>
> Todd,
>
> The draft says:
>
> " 2.1. Requirements of the TSA
>
> The TSA is REQUIRED:
>
>      1.  to provide a trustworthy source of time."
>
> To this respect there is no need to *prove* anything else. Any
> additional information from the TSA may be carried back in the
> security policy.
>
> Denis
>
>
> > Todd Glassey
>

Date: Wed, 3 Nov 1999 10:24:27 -0500
From: Paul Koning <[email-masked]>
To: [email-masked]
Cc: [email-masked]
Subject: Re: US relaxed export policy - When/IF and how?

>>>>> "Anders" == Anders Rundgren <[email-masked]> writes:

 Anders> Hi all crypto-nerds :-) We who live in Europe are used to
 Anders> live with pretty "crummy" solutions for achieving secure
 Anders> Internet-banking etc.  It is costly and inconvenient though!

 Anders> Rumors says that the US government is changing the export
 Anders> regulations so my question is simply:

 Anders> How long will we in Europe have to wait for strong
 Anders> cryptography in US-manufactured Browsers, Operating systems,
 Anders> Certificates and Web-servers?

We should know more by the end of the year.

Then again, the existing regulations are already essentially open for
the financial industry, so if the application is, say, secure banking, 
there shouldn't be an issue right now.

	paul

From: Anders Rundgren <[email-masked]>
To: "[email-masked]'" <[email-masked]>
Subject: US relaxed export policy - When/IF and how?
Date: Wed, 3 Nov 1999 15:47:59 +0100

Hi all crypto-nerds :-)

We who live in Europe are used to live with pretty "crummy" solutions for achieving
secure Internet-banking etc.   It is costly and inconvenient though!

Rumors says that the US government is changing the export regulations so my question is simply:

How long will we in Europe have to wait for strong cryptography in US-manufactured Browsers,
Operating systems, Certificates and Web-servers?

Regards
Anders Rundgren
Internet e-commerce Architect

Date:  3 Nov 99 06:22:01 PST
From: Eric Bomarsi <[email-masked]>
To: [email-masked]
Subject: PKI Software

We are looking for commercial-grade PKI software for a high end VPN gateway.
Software should include:

o RSA and DSA keypair generation
o PKCS #10 certificate request generation
o PKCS #7 certificate enrollment
o X509 V3 certificate database (RFC 2459 compliant)
o X509 V2 CRL database (RFC 2459 compliant)
o Certificate Management Protocols (CEP, CMP, CMC)
o Certificate/CRL Operational Protocols (LDAP, HTTP, FTP, OCSP)

Software must be available as source code license with maintenance
contract as it will run on proprietary hardware and O/S. Software 
should be easily portable to a unix-like O/S with socket interface.
Please respond directly to this email address as I am not on the 
mailing list.

Thanks,
/EE

____________________________________________________________________
Get your own FREE, personal Netscape WebMail account today at http://webmail.netscape.com.

From: "Miklos, Sue A." <[email-masked]>
To: "'Stefan Santesson'" <[email-masked]>, "'Bob Jueneman'" <[email-masked]>, "[email-masked]'" <[email-masked]>
Cc: "[email-masked]'" <[email-masked]>, "[email-masked]'" <[email-masked]>
Subject: error in previous post
Date: Wed, 3 Nov 1999 08:44:11 -0500 

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01BF2601.82C57B4A
Content-Type: text/plain;
	charset="iso-8859-1"

An error in my earlier post:

Index "13" is the place where the ISO-3166-1 3 numeric code elements are
contained.

SM 

------_=_NextPart_001_01BF2601.82C57B4A
Content-Type: text/html;
	charset="iso-8859-1"

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1">
<META NAME="Generator" CONTENT="MS Exchange Server version 5.5.2232.0">
<TITLE>error in previous post</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=2>An error in my earlier post:</FONT>
</P>

<P><FONT SIZE=2>Index &quot;13&quot; is the place where the ISO-3166-1 3 numeric code elements are contained.</FONT>
</P>

<P><FONT SIZE=2>SM </FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01BF2601.82C57B4A--

From: "Miklos, Sue A." <[email-masked]>
To: "'Stefan Santesson'" <[email-masked]>, Bob Jueneman <[email-masked]>, [email-masked]
Cc: [email-masked], [email-masked]
Subject: RE: QC certificates and Nationality
Date: Wed, 3 Nov 1999 08:30:17 -0500 

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01BF25FF.9176BA8E
Content-Type: text/plain;
	charset="iso-8859-1"

All,

I am sorry that the group is not willing to accept this request for
extensibility of a specific attribute.  I believe that as you evolve to work
the attribute certificate attribute type issues, you will be faced with
being able to support a significant number of differing attribute types that
the " ... long history of the existing encoding in X.500, X.400, and
elsewhere,
>and insufficient justification to warrant a change to a lot of already
existing
>CA, RP, and directory software" will not support.

Maybe when folks are ready to extend the schema to support, for example, the
attributes in the ECMA 209 (?) privilege attribute certificate syntax, the
idea of allowing more than one way of representing a nationality
(nationalities) will seem a bit trivial.   

As an additional note, the ISO 3166-1 contains 3 indexes - 11 is the alpha-2
code elements, 12 is the alpha-3 code elements and 12 is the numeric-3 code
elements; all indexes are in both English and French, which is consistent
with ISO and ITU standards practice.  If there are IETF documents in other
languages, please point me towards the repository, as I certainly cannot
afford to be English (or worse, US) centric in engineering such large scales
systems.

Regards,
Sandi Miklos
-----Original Message-----
From: Stefan Santesson [mailto:[email-masked]]
Sent: Wednesday, November 03, 1999 7:12 AM
To: Bob Jueneman; [email-masked]; [email-masked]
Cc: [email-masked]; [email-masked]
Subject: RE: QC certificates and Nationality

I agree with Bob.

We should stay compatible with coding in the X.520 country attribute.

/Stefan

At 06:42 PM 11/2/99 -0700, Bob Jueneman wrote:
>Sandy,
>
>The digraph encoding of country codes is also an ISO standard, just a 
>different one.  ISO currency codes, for example, are digraphs or 
>alternatively a numeric code -- yet another alternative.  There is a long
>history of the existing encoding in X.500, X.400, and elsewhere,
>and insufficient justification to warrant a change to a lot of already
existing
>CA, RP, and directory software 
>
>Although I'm reasonably sympathetic to MISSI's desires and role here,
>this is really a presentation layer API function, and not an 
>architectural/protocol issue, at least to my mind.
>
>There is another, more subtle issue here as well, and that is the question 
>of being overly English-centric.
>
>What trigraph is proposed for Germany, for example, or Switzerland,
>or a number of other countries whose English names are not at all
>similar to their native language forms?  For that matter, what is the 
>code for that conglomeration headed by Queen Elisabeth -- is it UK, 
>or GBR?
>
>US == USA == 840.  Anyone who can handle ASN.1 ought to be 
>able to handle the necessary conversions for a desired presentation 
>style, IMHO.
>
>With respect,
>
>Bob
>
>>>> "Miklos, Sue A." <[email-masked]> 11/02/99 12:48PM >>>
>Petra,
>
>The answer to the tri- versus di-graph is a bit detailed.  Trigraphs are
>believed to be more intuitive for an operator to determine which nation is
>referenced, as opposed to digraphs.  Thus, several security policies now
>mandate the use of the trigraph when populating the "Release To" field in a
>security label, or when populating the nationality (or multiples thereof)
of
>an authorization (or 'clearance') attribute.  Implementation plans
>(including training classes, etc.) are well underway.  Therefore, going
back
>and re-writing policy to reflect a digraph is not an acceptable
alternative.
>
>>From an information management perspective, the idea of maintaining (yet
>another) piece of code that translates digraphs to trigraphs every time the
>"Release To" field is used, or the authorization authority populates the
>nationality field in an attribute, adds to the configuration management
>difficulties associated with implementing a security policy.  This piece of
>code could reside in up to millions of nodes (clients, servers, gateway
>devices, etc.)
>
>Writing the translation code, distributing it (securely) and ensuring that
>all components were on the same version is going to be difficult enough for
>the access control decision function algorithm. We would like to avoid
>(wherever possible) extending the information management space to semantic
>content.  
>
>We would like to use existing information management processes to the
>greatest extent possible.  A majority opinion holds that ISO does the
>information maintenance quite well and at a reasonable cost when compared
to
>the security domain managers maintaining the conversion tables approach.
>ISO rapidly conveys changes when a nation is 'born' or 'renamed'. Thus, an
>operations manual can be upgraded much more quickly and at a lower cost
than
>any installed module that performs conversions.  The cost of ISO membership
>and subsequent re-distribution of changes is minimal in the overall scheme.
>
>An additional aspect is associated with performance impacts.  When one adds
>up all the processing associated with integrity and access control, it gets
>becomes noticeable.  Any area where 'translation' or additional lookup can
>be optimized is useful.
>
>If you see any other way out of this 'challenge' or flaws in the thinking,
>please respond!
>
>Regards,
>Sandi
>
>-----Original Message-----
>From: Petra Barzin (Gloeckner) [mailto:[email-masked]] 
>Sent: Tuesday, November 02, 1999 12:55 PM
>To: Miklos, Sue A.
>Cc: Russ Housley; [email-masked]; 'SEIS-List'; Stefan Santesson
>Subject: Re: QC certificates and Nationality
>
>
>Hi Sandi,
>
>the definition of our countryOfCitizenship attribute fulfils your first 
>requirement. But why would you want to use trigraphs? The two letter 
>codes cover all countries, don't they? 
>If your application needs the three letter codes, you can easily map 
>the two letter codes to the respective three letter codes.
>
>Regards - Petra
>
>> "Miklos, Sue A." wrote:
>> 
>> All,
>> 
>> I would like to request the attribute that represents a subject's
>> nationality be structured so that dual citizenship is allowed (default
>> Multivalued, which I believe is supported by countryOfCitizenship and,
>> that this attribute be populated with the ISO-3166-1 (trigraph) if
>> that is consistent with the domain using this piece of information.
>> 
>> I have requirements for both.  That is, I have a requirement for an
>> attribute that can indicate a subject is a citizen of both Country A
>> and Country B (country of domicile is not relevant at this point) and,
>> that the citizenship be indicated with a trigraph (USA, CAN, NZL,
>> etc.)
>> 
>> Regards,
>> Sandi Miklos
>> 
>> -----Original Message-----
>> From: Petra Barzin (Gloeckner) [mailto:[email-masked]] 
>> Sent: Tuesday, November 02, 1999 4:32 AM
>> To: Russ Housley
>> Cc: [email-masked]; 'SEIS-List'; Stefan Santesson
>> Subject: Re: QC certificates and Nationality
>> 
>> Russ Housley wrote:
>> >
>> > What goes into the QC when a person is a citizen of more than one
>> country?
>> >
>> > Russ
>> 
>> Hello Russ,
>> 
>> very good point! The wording in chapter 3.2.1 doesn't fit to the
>> definition of the attribute.
>> 
>> Right now, you have to add the attribute multiple times. I suggest
>> that
>> we replace the definition by the following:
>> 
>> countryOfCitizenship  ATTRIBUTE ::= {
>>         WITH SYNTAX   SEQUENCE OF PrintableString(SIZE (2))
>>                             -- IS 3166 codes only
>> 
>>         ID            id-at-countryOfCitizenship }
>> 
>> countryOfResidence    ATTRIBUTE ::= {
>>         WITH SYNTAX   SEQUENCE OF PrintableString(SIZE (2))
>>                             -- IS 3166 codes only
>> 
>>         ID            id-at-countryOfResidence }
>> 
>> 
>> Best regards - Petra

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

------_=_NextPart_001_01BF25FF.9176BA8E
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Diso-8859-1">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2232.0">
<TITLE>RE: QC certificates and Nationality</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=3D2>All,</FONT>
</P>

<P><FONT SIZE=3D2>I am sorry that the group is not willing to accept =
this request for extensibility of a specific attribute.&nbsp; I believe =
that as you evolve to work the attribute certificate attribute type =
issues, you will be faced with being able to support a significant =
number of differing attribute types that the &quot; ... long history of =
the existing encoding in X.500, X.400, and elsewhere,</FONT></P>

<P><FONT SIZE=3D2>&gt;and insufficient justification to warrant a =
change to a lot of already existing</FONT>
<BR><FONT SIZE=3D2>&gt;CA, RP, and directory software&quot; will not =
support.</FONT>
</P>

<P><FONT SIZE=3D2>Maybe when folks are ready to extend the schema to =
support, for example, the attributes in the ECMA 209 (?) privilege =
attribute certificate syntax, the idea of allowing more than one way of =
representing a nationality (nationalities) will seem a bit =
trivial.&nbsp;&nbsp; </FONT></P>

<P><FONT SIZE=3D2>As an additional note, the ISO 3166-1 contains 3 =
indexes - 11 is the alpha-2 code elements, 12 is the alpha-3 code =
elements and 12 is the numeric-3 code elements; all indexes are in both =
English and French, which is consistent with ISO and ITU standards =
practice.&nbsp; If there are IETF documents in other languages, please =
point me towards the repository, as I certainly cannot afford to be =
English (or worse, US) centric in engineering such large scales =
systems.</FONT></P>

<P><FONT SIZE=3D2>Regards,</FONT>
<BR><FONT SIZE=3D2>Sandi Miklos</FONT>
<BR><FONT SIZE=3D2>-----Original Message-----</FONT>
<BR><FONT SIZE=3D2>From: Stefan Santesson [<A =
HREF=3D"mailto:[email-masked]">mailto:[email-masked]</A>]</FONT>=

<BR><FONT SIZE=3D2>Sent: Wednesday, November 03, 1999 7:12 AM</FONT>
<BR><FONT SIZE=3D2>To: Bob Jueneman; [email-masked]; =
[email-masked]</FONT>
<BR><FONT SIZE=3D2>Cc: [email-masked]; [email-masked]</FONT>
<BR><FONT SIZE=3D2>Subject: RE: QC certificates and Nationality</FONT>
</P>
<BR>

<P><FONT SIZE=3D2>I agree with Bob.</FONT>
</P>

<P><FONT SIZE=3D2>We should stay compatible with coding in the X.520 =
country attribute.</FONT>
</P>

<P><FONT SIZE=3D2>/Stefan</FONT>
</P>

<P><FONT SIZE=3D2>At 06:42 PM 11/2/99 -0700, Bob Jueneman wrote:</FONT>
<BR><FONT SIZE=3D2>&gt;Sandy,</FONT>
<BR><FONT SIZE=3D2>&gt;</FONT>
<BR><FONT SIZE=3D2>&gt;The digraph encoding of country codes is also an =
ISO standard, just a </FONT>
<BR><FONT SIZE=3D2>&gt;different one.&nbsp; ISO currency codes, for =
example, are digraphs or </FONT>
<BR><FONT SIZE=3D2>&gt;alternatively a numeric code -- yet another =
alternative.&nbsp; There is a long</FONT>
<BR><FONT SIZE=3D2>&gt;history of the existing encoding in X.500, =
X.400, and elsewhere,</FONT>
<BR><FONT SIZE=3D2>&gt;and insufficient justification to warrant a =
change to a lot of already</FONT>
<BR><FONT SIZE=3D2>existing</FONT>
<BR><FONT SIZE=3D2>&gt;CA, RP, and directory software </FONT>
<BR><FONT SIZE=3D2>&gt;</FONT>
<BR><FONT SIZE=3D2>&gt;Although I'm reasonably sympathetic to MISSI's =
desires and role here,</FONT>
<BR><FONT SIZE=3D2>&gt;this is really a presentation layer API =
function, and not an </FONT>
<BR><FONT SIZE=3D2>&gt;architectural/protocol issue, at least to my =
mind.</FONT>
<BR><FONT SIZE=3D2>&gt;</FONT>
<BR><FONT SIZE=3D2>&gt;There is another, more subtle issue here as =
well, and that is the question </FONT>
<BR><FONT SIZE=3D2>&gt;of being overly English-centric.</FONT>
<BR><FONT SIZE=3D2>&gt;</FONT>
<BR><FONT SIZE=3D2>&gt;What trigraph is proposed for Germany, for =
example, or Switzerland,</FONT>
<BR><FONT SIZE=3D2>&gt;or a number of other countries whose English =
names are not at all</FONT>
<BR><FONT SIZE=3D2>&gt;similar to their native language forms?&nbsp; =
For that matter, what is the </FONT>
<BR><FONT SIZE=3D2>&gt;code for that conglomeration headed by Queen =
Elisabeth -- is it UK, </FONT>
<BR><FONT SIZE=3D2>&gt;or GBR?</FONT>
<BR><FONT SIZE=3D2>&gt;</FONT>
<BR><FONT SIZE=3D2>&gt;US =3D=3D USA =3D=3D 840.&nbsp; Anyone who can =
handle ASN.1 ought to be </FONT>
<BR><FONT SIZE=3D2>&gt;able to handle the necessary conversions for a =
desired presentation </FONT>
<BR><FONT SIZE=3D2>&gt;style, IMHO.</FONT>
<BR><FONT SIZE=3D2>&gt;</FONT>
<BR><FONT SIZE=3D2>&gt;With respect,</FONT>
<BR><FONT SIZE=3D2>&gt;</FONT>
<BR><FONT SIZE=3D2>&gt;Bob</FONT>
<BR><FONT SIZE=3D2>&gt;</FONT>
<BR><FONT SIZE=3D2>&gt;&gt;&gt;&gt; &quot;Miklos, Sue A.&quot; =
&lt;[email-masked]&gt; 11/02/99 12:48PM &gt;&gt;&gt;</FONT>
<BR><FONT SIZE=3D2>&gt;Petra,</FONT>
<BR><FONT SIZE=3D2>&gt;</FONT>
<BR><FONT SIZE=3D2>&gt;The answer to the tri- versus di-graph is a bit =
detailed.&nbsp; Trigraphs are</FONT>
<BR><FONT SIZE=3D2>&gt;believed to be more intuitive for an operator to =
determine which nation is</FONT>
<BR><FONT SIZE=3D2>&gt;referenced, as opposed to digraphs.&nbsp; Thus, =
several security policies now</FONT>
<BR><FONT SIZE=3D2>&gt;mandate the use of the trigraph when populating =
the &quot;Release To&quot; field in a</FONT>
<BR><FONT SIZE=3D2>&gt;security label, or when populating the =
nationality (or multiples thereof) of</FONT>
<BR><FONT SIZE=3D2>&gt;an authorization (or 'clearance') =
attribute.&nbsp; Implementation plans</FONT>
<BR><FONT SIZE=3D2>&gt;(including training classes, etc.) are well =
underway.&nbsp; Therefore, going back</FONT>
<BR><FONT SIZE=3D2>&gt;and re-writing policy to reflect a digraph is =
not an acceptable alternative.</FONT>
<BR><FONT SIZE=3D2>&gt;</FONT>
<BR><FONT SIZE=3D2>&gt;&gt;From an information management perspective, =
the idea of maintaining (yet</FONT>
<BR><FONT SIZE=3D2>&gt;another) piece of code that translates digraphs =
to trigraphs every time the</FONT>
<BR><FONT SIZE=3D2>&gt;&quot;Release To&quot; field is used, or the =
authorization authority populates the</FONT>
<BR><FONT SIZE=3D2>&gt;nationality field in an attribute, adds to the =
configuration management</FONT>
<BR><FONT SIZE=3D2>&gt;difficulties associated with implementing a =
security policy.&nbsp; This piece of</FONT>
<BR><FONT SIZE=3D2>&gt;code could reside in up to millions of nodes =
(clients, servers, gateway</FONT>
<BR><FONT SIZE=3D2>&gt;devices, etc.)</FONT>
<BR><FONT SIZE=3D2>&gt;</FONT>
<BR><FONT SIZE=3D2>&gt;Writing the translation code, distributing it =
(securely) and ensuring that</FONT>
<BR><FONT SIZE=3D2>&gt;all components were on the same version is going =
to be difficult enough for</FONT>
<BR><FONT SIZE=3D2>&gt;the access control decision function algorithm. =
We would like to avoid</FONT>
<BR><FONT SIZE=3D2>&gt;(wherever possible) extending the information =
management space to semantic</FONT>
<BR><FONT SIZE=3D2>&gt;content.&nbsp; </FONT>
<BR><FONT SIZE=3D2>&gt;</FONT>
<BR><FONT SIZE=3D2>&gt;We would like to use existing information =
management processes to the</FONT>
<BR><FONT SIZE=3D2>&gt;greatest extent possible.&nbsp; A majority =
opinion holds that ISO does the</FONT>
<BR><FONT SIZE=3D2>&gt;information maintenance quite well and at a =
reasonable cost when compared to</FONT>
<BR><FONT SIZE=3D2>&gt;the security domain managers maintaining the =
conversion tables approach.</FONT>
<BR><FONT SIZE=3D2>&gt;ISO rapidly conveys changes when a nation is =
'born' or 'renamed'. Thus, an</FONT>
<BR><FONT SIZE=3D2>&gt;operations manual can be upgraded much more =
quickly and at a lower cost than</FONT>
<BR><FONT SIZE=3D2>&gt;any installed module that performs =
conversions.&nbsp; The cost of ISO membership</FONT>
<BR><FONT SIZE=3D2>&gt;and subsequent re-distribution of changes is =
minimal in the overall scheme.</FONT>
<BR><FONT SIZE=3D2>&gt;</FONT>
<BR><FONT SIZE=3D2>&gt;An additional aspect is associated with =
performance impacts.&nbsp; When one adds</FONT>
<BR><FONT SIZE=3D2>&gt;up all the processing associated with integrity =
and access control, it gets</FONT>
<BR><FONT SIZE=3D2>&gt;becomes noticeable.&nbsp; Any area where =
'translation' or additional lookup can</FONT>
<BR><FONT SIZE=3D2>&gt;be optimized is useful.</FONT>
<BR><FONT SIZE=3D2>&gt;</FONT>
<BR><FONT SIZE=3D2>&gt;If you see any other way out of this 'challenge' =
or flaws in the thinking,</FONT>
<BR><FONT SIZE=3D2>&gt;please respond!</FONT>
<BR><FONT SIZE=3D2>&gt;</FONT>
<BR><FONT SIZE=3D2>&gt;Regards,</FONT>
<BR><FONT SIZE=3D2>&gt;Sandi</FONT>
<BR><FONT SIZE=3D2>&gt;</FONT>
<BR><FONT SIZE=3D2>&gt;-----Original Message-----</FONT>
<BR><FONT SIZE=3D2>&gt;From: Petra Barzin (Gloeckner) [<A =
HREF=3D"mailto:[email-masked]">mailto:[email-masked]</A>] </FONT>
<BR><FONT SIZE=3D2>&gt;Sent: Tuesday, November 02, 1999 12:55 PM</FONT>
<BR><FONT SIZE=3D2>&gt;To: Miklos, Sue A.</FONT>
<BR><FONT SIZE=3D2>&gt;Cc: Russ Housley; [email-masked]; =
'SEIS-List'; Stefan Santesson</FONT>
<BR><FONT SIZE=3D2>&gt;Subject: Re: QC certificates and =
Nationality</FONT>
<BR><FONT SIZE=3D2>&gt;</FONT>
<BR><FONT SIZE=3D2>&gt;</FONT>
<BR><FONT SIZE=3D2>&gt;Hi Sandi,</FONT>
<BR><FONT SIZE=3D2>&gt;</FONT>
<BR><FONT SIZE=3D2>&gt;the definition of our countryOfCitizenship =
attribute fulfils your first </FONT>
<BR><FONT SIZE=3D2>&gt;requirement. But why would you want to use =
trigraphs? The two letter </FONT>
<BR><FONT SIZE=3D2>&gt;codes cover all countries, don't they? </FONT>
<BR><FONT SIZE=3D2>&gt;If your application needs the three letter =
codes, you can easily map </FONT>
<BR><FONT SIZE=3D2>&gt;the two letter codes to the respective three =
letter codes.</FONT>
<BR><FONT SIZE=3D2>&gt;</FONT>
<BR><FONT SIZE=3D2>&gt;Regards - Petra</FONT>
<BR><FONT SIZE=3D2>&gt;</FONT>
<BR><FONT SIZE=3D2>&gt;&gt; &quot;Miklos, Sue A.&quot; wrote:</FONT>
<BR><FONT SIZE=3D2>&gt;&gt; </FONT>
<BR><FONT SIZE=3D2>&gt;&gt; All,</FONT>
<BR><FONT SIZE=3D2>&gt;&gt; </FONT>
<BR><FONT SIZE=3D2>&gt;&gt; I would like to request the attribute that =
represents a subject's</FONT>
<BR><FONT SIZE=3D2>&gt;&gt; nationality be structured so that dual =
citizenship is allowed (default</FONT>
<BR><FONT SIZE=3D2>&gt;&gt; Multivalued, which I believe is supported =
by countryOfCitizenship and,</FONT>
<BR><FONT SIZE=3D2>&gt;&gt; that this attribute be populated with the =
ISO-3166-1 (trigraph) if</FONT>
<BR><FONT SIZE=3D2>&gt;&gt; that is consistent with the domain using =
this piece of information.</FONT>
<BR><FONT SIZE=3D2>&gt;&gt; </FONT>
<BR><FONT SIZE=3D2>&gt;&gt; I have requirements for both.&nbsp; That =
is, I have a requirement for an</FONT>
<BR><FONT SIZE=3D2>&gt;&gt; attribute that can indicate a subject is a =
citizen of both Country A</FONT>
<BR><FONT SIZE=3D2>&gt;&gt; and Country B (country of domicile is not =
relevant at this point) and,</FONT>
<BR><FONT SIZE=3D2>&gt;&gt; that the citizenship be indicated with a =
trigraph (USA, CAN, NZL,</FONT>
<BR><FONT SIZE=3D2>&gt;&gt; etc.)</FONT>
<BR><FONT SIZE=3D2>&gt;&gt; </FONT>
<BR><FONT SIZE=3D2>&gt;&gt; Regards,</FONT>
<BR><FONT SIZE=3D2>&gt;&gt; Sandi Miklos</FONT>
<BR><FONT SIZE=3D2>&gt;&gt; </FONT>
<BR><FONT SIZE=3D2>&gt;&gt; -----Original Message-----</FONT>
<BR><FONT SIZE=3D2>&gt;&gt; From: Petra Barzin (Gloeckner) [<A =
HREF=3D"mailto:[email-masked]">mailto:[email-masked]</A>] </FONT>
<BR><FONT SIZE=3D2>&gt;&gt; Sent: Tuesday, November 02, 1999 4:32 =
AM</FONT>
<BR><FONT SIZE=3D2>&gt;&gt; To: Russ Housley</FONT>
<BR><FONT SIZE=3D2>&gt;&gt; Cc: [email-masked]; 'SEIS-List'; Stefan =
Santesson</FONT>
<BR><FONT SIZE=3D2>&gt;&gt; Subject: Re: QC certificates and =
Nationality</FONT>
<BR><FONT SIZE=3D2>&gt;&gt; </FONT>
<BR><FONT SIZE=3D2>&gt;&gt; Russ Housley wrote:</FONT>
<BR><FONT SIZE=3D2>&gt;&gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt;&gt; &gt; What goes into the QC when a person is =
a citizen of more than one</FONT>
<BR><FONT SIZE=3D2>&gt;&gt; country?</FONT>
<BR><FONT SIZE=3D2>&gt;&gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt;&gt; &gt; Russ</FONT>
<BR><FONT SIZE=3D2>&gt;&gt; </FONT>
<BR><FONT SIZE=3D2>&gt;&gt; Hello Russ,</FONT>
<BR><FONT SIZE=3D2>&gt;&gt; </FONT>
<BR><FONT SIZE=3D2>&gt;&gt; very good point! The wording in chapter =
3.2.1 doesn't fit to the</FONT>
<BR><FONT SIZE=3D2>&gt;&gt; definition of the attribute.</FONT>
<BR><FONT SIZE=3D2>&gt;&gt; </FONT>
<BR><FONT SIZE=3D2>&gt;&gt; Right now, you have to add the attribute =
multiple times. I suggest</FONT>
<BR><FONT SIZE=3D2>&gt;&gt; that</FONT>
<BR><FONT SIZE=3D2>&gt;&gt; we replace the definition by the =
following:</FONT>
<BR><FONT SIZE=3D2>&gt;&gt; </FONT>
<BR><FONT SIZE=3D2>&gt;&gt; countryOfCitizenship&nbsp; ATTRIBUTE ::=3D =
{</FONT>
<BR><FONT =
SIZE=3D2>&gt;&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; WITH =
SYNTAX&nbsp;&nbsp; SEQUENCE OF PrintableString(SIZE (2))</FONT>
<BR><FONT =
SIZE=3D2>&gt;&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&=
nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&=
nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; -- IS 3166 codes only</FONT>
<BR><FONT SIZE=3D2>&gt;&gt; </FONT>
<BR><FONT =
SIZE=3D2>&gt;&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
ID&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
id-at-countryOfCitizenship }</FONT>
<BR><FONT SIZE=3D2>&gt;&gt; </FONT>
<BR><FONT SIZE=3D2>&gt;&gt; countryOfResidence&nbsp;&nbsp;&nbsp; =
ATTRIBUTE ::=3D {</FONT>
<BR><FONT =
SIZE=3D2>&gt;&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; WITH =
SYNTAX&nbsp;&nbsp; SEQUENCE OF PrintableString(SIZE (2))</FONT>
<BR><FONT =
SIZE=3D2>&gt;&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&=
nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&=
nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; -- IS 3166 codes only</FONT>
<BR><FONT SIZE=3D2>&gt;&gt; </FONT>
<BR><FONT =
SIZE=3D2>&gt;&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
ID&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
id-at-countryOfResidence }</FONT>
<BR><FONT SIZE=3D2>&gt;&gt; </FONT>
<BR><FONT SIZE=3D2>&gt;&gt; </FONT>
<BR><FONT SIZE=3D2>&gt;&gt; Best regards - Petra</FONT>
</P>

<P><FONT =
SIZE=3D2>---------------------------------------------------------------=
----</FONT>
<BR><FONT SIZE=3D2>Stefan =
Santesson&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp; &lt;[email-masked]&gt;</FONT>
<BR><FONT SIZE=3D2>Accurata =
AB&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <A =
HREF=3D"http://www.accurata.se" =
TARGET=3D"_blank">http://www.accurata.se</A></FONT>
<BR><FONT =
SIZE=3D2>Slagthuset&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
; Tel. +46-40 =
108588&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp; </FONT>
<BR><FONT SIZE=3D2>211 20&nbsp; =
Malm=F6&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Fax. +46-40 =
150790&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp; </FONT>
<BR><FONT =
SIZE=3D2>Sweden&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp; Mobile +46-70 5247799</FONT>
</P>

<P><FONT SIZE=3D2>PGP fingerprint: 89BC 6C79 5B3D 591B 8547&nbsp; 1512 =
7D11 DBF4 528F 29A0</FONT>
<BR><FONT =
SIZE=3D2>---------------------------------------------------------------=
----</FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01BF25FF.9176BA8E--

From: Simon Corell <[email-masked]>
To: "'Anders Rundgren'" <[email-masked]>, Stefan Santesson <[email-masked]>, [email-masked], "'SEIS-List'" <[email-masked]>
Subject: RE: SEIS:  QC Container-ID (card serial)
Date: Wed, 3 Nov 1999 13:37:25 +0100 

Stefan, I remember this was a big issue in our first discussion on the
Swedish EID Card spexs. I was always pro a hard connection between the
certificate(s) and the devise in this special case. I hear from our friends
in the banking industry that they will not separate the revocation of
certificates and the physical device. If revoked the device is blocked. 
/Simon

Simon Corell, PKI Evangelist,  LL.B.
iD2 Technologies, Liljeholmsvägen 14, P.O.Box 44055, 100 73 Sweden
Phone: +46 8 7755219, Mobile: +46 706541470, Fax: +46 8 7267912
mail to: [email-masked], http://www.iD2tech.com

> iD2 - Securing the Internet economy
> 

-----Original Message-----
From: Anders Rundgren [mailto:[email-masked]]
Sent: den 3 november 1999 08:54
To: Stefan Santesson; [email-masked]; 'SEIS-List'
Subject: SEIS: QC Container-ID (card serial)

--- Message on the SEIS mailing list ([email-masked])

Sorry for bringing this up again but I have not received an answer yet.

It is likely that a large part of future QCs will be put in smart cards, be
it
descrete credit-card-sized cards, SIM/WIM cards, or Java Rings etc.

These physical containers always have a serial number or similar that
I think should be possible to specify in QCs (using a pre-defined
identifier)
to be able to track which container that was used for generating a digital
signature.

Please....

Anders

----------------- SEIS mailing list ([email-masked])
Info about this list: http://www.nc-forum.com/seis
SEIS Contact: [email-masked]

From: Anders Rundgren <[email-masked]>
To: "'Juergen Brauckmann'" <[email-masked]>, "[email-masked]'" <[email-masked]>
Cc: =?iso-8859-1?Q?=27Magnus_Nystr=F6m=27?= <[email-masked]>, "'Stefan Santesson'" <[email-masked]>
Subject: RE: QC Container-ID (card serial)
Date: Wed, 3 Nov 1999 13:24:48 +0100

Juergen,

>Disregarding the question whether this is in the scope of the QC profile or not,

This is indeed a problem IMO!  What IS the scope of QC?

>I would like to draw your attention to the ICCSN-extension that has
>been defined in the German Sig Law Interop Spec:

>iCCSN EXTENSION ::= {
>     SYNTAX ICCSNSyntax
>     IDENTIFIED BY id-sigi-at-iCCSN }

>ICCSNSyntax ::= IMPLICIT OCTETSTRING (SIZE(15..23))

>id-sigi-at-iCCSN OBJECT IDENTIFIER ::= { 1 3 36 8 3 6 }

Looks perfectly OK to me although I am not very proficient in ASN.1.

Regards
Anders

Date: Wed, 03 Nov 1999 13:11:39 +0100
To: "Bob Jueneman" <[email-masked]>, <[email-masked]>, <[email-masked]>
From: Stefan Santesson <[email-masked]>
Subject: RE: QC certificates and Nationality
Cc: <[email-masked]>, <[email-masked]>

I agree with Bob.

We should stay compatible with coding in the X.520 country attribute.

/Stefan

At 06:42 PM 11/2/99 -0700, Bob Jueneman wrote:
>Sandy,
>
>The digraph encoding of country codes is also an ISO standard, just a 
>different one.  ISO currency codes, for example, are digraphs or 
>alternatively a numeric code -- yet another alternative.  There is a long
>history of the existing encoding in X.500, X.400, and elsewhere,
>and insufficient justification to warrant a change to a lot of already
existing
>CA, RP, and directory software 
>
>Although I'm reasonably sympathetic to MISSI's desires and role here,
>this is really a presentation layer API function, and not an 
>architectural/protocol issue, at least to my mind.
>
>There is another, more subtle issue here as well, and that is the question 
>of being overly English-centric.
>
>What trigraph is proposed for Germany, for example, or Switzerland,
>or a number of other countries whose English names are not at all
>similar to their native language forms?  For that matter, what is the 
>code for that conglomeration headed by Queen Elisabeth -- is it UK, 
>or GBR?
>
>US == USA == 840.  Anyone who can handle ASN.1 ought to be 
>able to handle the necessary conversions for a desired presentation 
>style, IMHO.
>
>With respect,
>
>Bob
>
>>>> "Miklos, Sue A." <[email-masked]> 11/02/99 12:48PM >>>
>Petra,
>
>The answer to the tri- versus di-graph is a bit detailed.  Trigraphs are
>believed to be more intuitive for an operator to determine which nation is
>referenced, as opposed to digraphs.  Thus, several security policies now
>mandate the use of the trigraph when populating the "Release To" field in a
>security label, or when populating the nationality (or multiples thereof) of
>an authorization (or 'clearance') attribute.  Implementation plans
>(including training classes, etc.) are well underway.  Therefore, going back
>and re-writing policy to reflect a digraph is not an acceptable alternative.
>
>>From an information management perspective, the idea of maintaining (yet
>another) piece of code that translates digraphs to trigraphs every time the
>"Release To" field is used, or the authorization authority populates the
>nationality field in an attribute, adds to the configuration management
>difficulties associated with implementing a security policy.  This piece of
>code could reside in up to millions of nodes (clients, servers, gateway
>devices, etc.)
>
>Writing the translation code, distributing it (securely) and ensuring that
>all components were on the same version is going to be difficult enough for
>the access control decision function algorithm. We would like to avoid
>(wherever possible) extending the information management space to semantic
>content.  
>
>We would like to use existing information management processes to the
>greatest extent possible.  A majority opinion holds that ISO does the
>information maintenance quite well and at a reasonable cost when compared to
>the security domain managers maintaining the conversion tables approach.
>ISO rapidly conveys changes when a nation is 'born' or 'renamed'. Thus, an
>operations manual can be upgraded much more quickly and at a lower cost than
>any installed module that performs conversions.  The cost of ISO membership
>and subsequent re-distribution of changes is minimal in the overall scheme.
>
>An additional aspect is associated with performance impacts.  When one adds
>up all the processing associated with integrity and access control, it gets
>becomes noticeable.  Any area where 'translation' or additional lookup can
>be optimized is useful.
>
>If you see any other way out of this 'challenge' or flaws in the thinking,
>please respond!
>
>Regards,
>Sandi
>
>-----Original Message-----
>From: Petra Barzin (Gloeckner) [mailto:[email-masked]] 
>Sent: Tuesday, November 02, 1999 12:55 PM
>To: Miklos, Sue A.
>Cc: Russ Housley; [email-masked]; 'SEIS-List'; Stefan Santesson
>Subject: Re: QC certificates and Nationality
>
>
>Hi Sandi,
>
>the definition of our countryOfCitizenship attribute fulfils your first 
>requirement. But why would you want to use trigraphs? The two letter 
>codes cover all countries, don't they? 
>If your application needs the three letter codes, you can easily map 
>the two letter codes to the respective three letter codes.
>
>Regards - Petra
>
>> "Miklos, Sue A." wrote:
>> 
>> All,
>> 
>> I would like to request the attribute that represents a subject's
>> nationality be structured so that dual citizenship is allowed (default
>> Multivalued, which I believe is supported by countryOfCitizenship and,
>> that this attribute be populated with the ISO-3166-1 (trigraph) if
>> that is consistent with the domain using this piece of information.
>> 
>> I have requirements for both.  That is, I have a requirement for an
>> attribute that can indicate a subject is a citizen of both Country A
>> and Country B (country of domicile is not relevant at this point) and,
>> that the citizenship be indicated with a trigraph (USA, CAN, NZL,
>> etc.)
>> 
>> Regards,
>> Sandi Miklos
>> 
>> -----Original Message-----
>> From: Petra Barzin (Gloeckner) [mailto:[email-masked]] 
>> Sent: Tuesday, November 02, 1999 4:32 AM
>> To: Russ Housley
>> Cc: [email-masked]; 'SEIS-List'; Stefan Santesson
>> Subject: Re: QC certificates and Nationality
>> 
>> Russ Housley wrote:
>> >
>> > What goes into the QC when a person is a citizen of more than one
>> country?
>> >
>> > Russ
>> 
>> Hello Russ,
>> 
>> very good point! The wording in chapter 3.2.1 doesn't fit to the
>> definition of the attribute.
>> 
>> Right now, you have to add the attribute multiple times. I suggest
>> that
>> we replace the definition by the following:
>> 
>> countryOfCitizenship  ATTRIBUTE ::= {
>>         WITH SYNTAX   SEQUENCE OF PrintableString(SIZE (2))
>>                             -- IS 3166 codes only
>> 
>>         ID            id-at-countryOfCitizenship }
>> 
>> countryOfResidence    ATTRIBUTE ::= {
>>         WITH SYNTAX   SEQUENCE OF PrintableString(SIZE (2))
>>                             -- IS 3166 codes only
>> 
>>         ID            id-at-countryOfResidence }
>> 
>> 
>> Best regards - Petra

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

Date: Wed, 03 Nov 1999 12:09:22 +0100
To: [email-masked]
From: Juergen Brauckmann <[email-masked]>
Subject: Re: QC Container-ID (card serial)

At 11:32 03.11.99 +0100, Anders Rundgren wrote:
>>So if you want to express something about where the private key is stored
>>(which could be valuable information in some cases), then I suggest that
>>you use the qcStatataments extension.
>
>>You could define a statement saying "The private key associated with this
>>certificate is protected within a Smart Card that meets requirements
>>defined by FIPS xxxx ....."
>
>I do not agree as statements of the kind you describe cannot easily be
interpreted by
>computers without a lot of secret agreements between RPs and CAs.
>
>For that reason I suggest that this becomes an optional extension that does
>not need "interpretation" .  Like certificate serial numbers.

Disregarding the question whether this is in the scope of the QC profile or
not, I would like to draw your attention to the ICCSN-extension that has
been defined in the German Sig Law Interop Spec:

iCCSN EXTENSION ::= {
     SYNTAX ICCSNSyntax
     IDENTIFIED BY id-sigi-at-iCCSN }

ICCSNSyntax ::= IMPLICIT OCTETSTRING (SIZE(15..23))

id-sigi-at-iCCSN OBJECT IDENTIFIER ::= { 1 3 36 8 3 6 }

Regards,
   Juergen
-- 
Juergen Brauckmann             Tel.:  040 / 8080 26 311
TC Trust Center for Security   Fax.:  040 / 766 29 577
in Data Networks GmbH 	    mailto:[email-masked]
Am Werder 1    		    http://www.trustcenter.de	
21073 Hamburg

Date: Wed, 03 Nov 1999 11:46:25 +0100
To: Anders Rundgren <[email-masked]>, Anders Rundgren </o=Jaybis.AB/ou=JAYBIS/cn=Recipients/cn=[email-masked]>, "[email-masked]" <[email-masked]>, "'SEIS-List'" <[email-masked]>
From: Stefan Santesson <[email-masked]>
Subject: Re: QC Container-ID (card serial)

I don't agree.

I think your suggestion is to far away from the scope of this profile.

/Stefan

At 11:32 AM 11/3/99 +0100, Anders Rundgren wrote:
>Stefan,
>Comments in line
>
>>Lets agree to the fact that a container ID shouldn't be part of the
>>subjects name.
>
>I agree to that.   It is more like the serial number of the certificate.
>
>>So if you want to express something about where the private key is stored
>>(which could be valuable information in some cases), then I suggest that
>>you use the qcStatataments extension.
>
>>You could define a statement saying "The private key associated with this
>>certificate is protected within a Smart Card that meets requirements
>>defined by FIPS xxxx ....."
>
>I do not agree as statements of the kind you describe cannot easily be 
>interpreted by
>computers without a lot of secret agreements between RPs and CAs.
>
>For that reason I suggest that this becomes an optional extension that does
>not need "interpretation" .  Like certificate serial numbers.
>
><snip>
>
>/Anders

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

From: Anders Rundgren <[email-masked]>
To: Anders Rundgren </o=Jaybis.AB/ou=JAYBIS/cn=Recipients/cn=[email-masked]>, "[email-masked]" <[email-masked]>, "'SEIS-List'" <[email-masked]>, "'Stefan Santesson'" <[email-masked]>
Subject: Re: QC Container-ID (card serial)
Date: Wed, 3 Nov 1999 11:32:16 +0100

Stefan,
Comments in line

>Lets agree to the fact that a container ID shouldn't be part of the
>subjects name.

I agree to that.   It is more like the serial number of the certificate.

>So if you want to express something about where the private key is stored
>(which could be valuable information in some cases), then I suggest that
>you use the qcStatataments extension.

>You could define a statement saying "The private key associated with this
>certificate is protected within a Smart Card that meets requirements
>defined by FIPS xxxx ....."

I do not agree as statements of the kind you describe cannot easily be interpreted by
computers without a lot of secret agreements between RPs and CAs.

For that reason I suggest that this becomes an optional extension that does
not need "interpretation" .  Like certificate serial numbers.

<snip>

/Anders

Date: Wed, 03 Nov 1999 11:03:21 +0100
To: <[email-masked]>, "'SEIS-List'" <[email-masked]>
From: Stefan Santesson <[email-masked]>
Subject: Fresh version of the EU draft Electronic Signature directive

All,

For anyone interested.

I have updated the QC web page with the latest official version of the
ES-directive, Included in the Common position paper adopted by the Council
on June 28, 1999.

This version contains an updated version of Annex III, which I was
referring to earlier.

You can download the draft from:

http://www.accurata.se/QC/documents/direng990827.pdf

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

Date: Wed, 03 Nov 1999 10:35:33 +0100
To: "Anders Rundgren" <[email-masked]>, <[email-masked]>, "'SEIS-List'" <[email-masked]>
From: Stefan Santesson <[email-masked]>
Subject: Re: QC Container-ID (card serial)

Anders,

Lets agree to the fact that a container ID shouldn't be part of the
subjects name.

So if you want to express something about where the private key is stored
(which could be valuable information in some cases), then I suggest that
you use the qcStatataments extension.

You could define a statement saying "The private key associated with this
certificate is protected within a Smart Card that meets requirements
defined by FIPS xxxx ....."

Then you could add qualifying information expressing the ID of the
container (chip serial number or card serial number or what ever).

And then you are all set.

I will in fact suggest to the European standardization process that a
similar qcStatement should be defined as a response to the ES-directive.
This statement would state that the private key is contained in a secure
signature creation device according to the ES-directive Annex III.

/Stefan

At 07:54 AM 11/3/99 +0000, Anders Rundgren wrote:
>Sorry for bringing this up again but I have not received an answer yet.
>
>
>It is likely that a large part of future QCs will be put in smart cards, be it
>descrete credit-card-sized cards, SIM/WIM cards, or Java Rings etc.
>
>These physical containers always have a serial number or similar that
>I think should be possible to specify in QCs (using a pre-defined identifier)
>to be able to track which container that was used for generating a digital 
>signature.
>
>Please....
>
>Anders

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

Date: Wed, 03 Nov 1999 10:10:08 +0100
From: Denis Pinkas <[email-masked]>
Organization: Bull
To: "Todd Glassey @ GMT" <[email-masked]>
CC: [email-masked], [email-masked]
Subject: Re: Timestamping Standards.

> Hi all,  in the Timestamping services drafts there might want to be a
> mention of the only standards regarding timestamping currently on the books
> today, because the may change some of the focus in this effort.
> 
> They provide for a requirements to provably timestamp within three (3)
> seconds of UTC and these are of course the NASD OATS requirements. NASD for
> thos that are unaware is the NAtional Association of Securities Dealers and
> any solution that is proffered as a timestamping one for commercial purposes
> should ought to fulfill the only mandate on the books today. To get more of
> this try the OATS pages at the www.nasdr.com site.
> 
> I suggest that to satisfy OATS, several use-specific assumptions have to be
> made like the timestamping system itself has some provable connection to a
> "reliable" source of time, and the audit model to prove that the time
> setting instance at the client end was accomplished appropriately, and that
> these assumptions should be spelled out i detail in the Draft
> 
> Any comments?

Todd,

The draft says:

" 2.1. Requirements of the TSA

The TSA is REQUIRED:

     1.  to provide a trustworthy source of time."

To this respect there is no need to *prove* anything else. Any
additional information from the TSA may be carried back in the
security policy.

Denis

> Todd Glassey

From: "Anders Rundgren" <[email-masked]>
To: "Stefan Santesson" <[email-masked]>, <[email-masked]>, "'SEIS-List'" <[email-masked]>
Subject: QC Container-ID (card serial)
Date: Wed, 3 Nov 1999 07:54:24 -0000

Sorry for bringing this up again but I have not received an answer yet.

It is likely that a large part of future QCs will be put in smart cards, be it
descrete credit-card-sized cards, SIM/WIM cards, or Java Rings etc.

These physical containers always have a serial number or similar that
I think should be possible to specify in QCs (using a pre-defined identifier)
to be able to track which container that was used for generating a digital signature.

Please....

Anders

From: "Lunow, Pauwl PB SSI-TSIS" <[email-masked]>
To: "'Bob Jueneman'" <[email-masked]>
Cc: [email-masked]
Subject: RE: QC certificates and Nationality
Date: Wed, 3 Nov 1999 02:58:05 +0100 

For all interested, here's a link to the ISO standard codes:
(ISO 3166-1-Alpha-2 code elements)

http://www.din.de/gremien/nas/nabd/iso3166ma/codlstp1.html

Pauwl

-----Original Message-----
From: Bob Jueneman [mailto:[email-masked]]
Sent: 02 November 1999 19:42
To: [email-masked]; [email-masked]
Cc: [email-masked]; [email-masked]; [email-masked];
[email-masked]
Subject: RE: QC certificates and Nationality

Sandy,

The digraph encoding of country codes is also an ISO standard, just a 
different one.  ISO currency codes, for example, are digraphs or 
alternatively a numeric code -- yet another alternative.  There is a long
history of the existing encoding in X.500, X.400, and elsewhere,
and insufficient justification to warrant a change to a lot of already
existing
CA, RP, and directory software 

Although I'm reasonably sympathetic to MISSI's desires and role here,
this is really a presentation layer API function, and not an 
architectural/protocol issue, at least to my mind.

There is another, more subtle issue here as well, and that is the question 
of being overly English-centric.

What trigraph is proposed for Germany, for example, or Switzerland,
or a number of other countries whose English names are not at all
similar to their native language forms?  For that matter, what is the 
code for that conglomeration headed by Queen Elisabeth -- is it UK, 
or GBR?

US == USA == 840.  Anyone who can handle ASN.1 ought to be 
able to handle the necessary conversions for a desired presentation 
style, IMHO.

With respect,

Bob

>>> "Miklos, Sue A." <[email-masked]> 11/02/99 12:48PM >>>
Petra,

The answer to the tri- versus di-graph is a bit detailed.  Trigraphs are
believed to be more intuitive for an operator to determine which nation is
referenced, as opposed to digraphs.  Thus, several security policies now
mandate the use of the trigraph when populating the "Release To" field in a
security label, or when populating the nationality (or multiples thereof) of
an authorization (or 'clearance') attribute.  Implementation plans
(including training classes, etc.) are well underway.  Therefore, going back
and re-writing policy to reflect a digraph is not an acceptable alternative.

>From an information management perspective, the idea of maintaining (yet
another) piece of code that translates digraphs to trigraphs every time the
"Release To" field is used, or the authorization authority populates the
nationality field in an attribute, adds to the configuration management
difficulties associated with implementing a security policy.  This piece of
code could reside in up to millions of nodes (clients, servers, gateway
devices, etc.)

Writing the translation code, distributing it (securely) and ensuring that
all components were on the same version is going to be difficult enough for
the access control decision function algorithm. We would like to avoid
(wherever possible) extending the information management space to semantic
content.  

We would like to use existing information management processes to the
greatest extent possible.  A majority opinion holds that ISO does the
information maintenance quite well and at a reasonable cost when compared to
the security domain managers maintaining the conversion tables approach.
ISO rapidly conveys changes when a nation is 'born' or 'renamed'. Thus, an
operations manual can be upgraded much more quickly and at a lower cost than
any installed module that performs conversions.  The cost of ISO membership
and subsequent re-distribution of changes is minimal in the overall scheme.

An additional aspect is associated with performance impacts.  When one adds
up all the processing associated with integrity and access control, it gets
becomes noticeable.  Any area where 'translation' or additional lookup can
be optimized is useful.

If you see any other way out of this 'challenge' or flaws in the thinking,
please respond!

Regards,
Sandi

-----Original Message-----
From: Petra Barzin (Gloeckner) [mailto:[email-masked]] 
Sent: Tuesday, November 02, 1999 12:55 PM
To: Miklos, Sue A.
Cc: Russ Housley; [email-masked]; 'SEIS-List'; Stefan Santesson
Subject: Re: QC certificates and Nationality

Hi Sandi,

the definition of our countryOfCitizenship attribute fulfils your first 
requirement. But why would you want to use trigraphs? The two letter 
codes cover all countries, don't they? 
If your application needs the three letter codes, you can easily map 
the two letter codes to the respective three letter codes.

Regards - Petra

> "Miklos, Sue A." wrote:
> 
> All,
> 
> I would like to request the attribute that represents a subject's
> nationality be structured so that dual citizenship is allowed (default
> Multivalued, which I believe is supported by countryOfCitizenship and,
> that this attribute be populated with the ISO-3166-1 (trigraph) if
> that is consistent with the domain using this piece of information.
> 
> I have requirements for both.  That is, I have a requirement for an
> attribute that can indicate a subject is a citizen of both Country A
> and Country B (country of domicile is not relevant at this point) and,
> that the citizenship be indicated with a trigraph (USA, CAN, NZL,
> etc.)
> 
> Regards,
> Sandi Miklos
> 
> -----Original Message-----
> From: Petra Barzin (Gloeckner) [mailto:[email-masked]] 
> Sent: Tuesday, November 02, 1999 4:32 AM
> To: Russ Housley
> Cc: [email-masked]; 'SEIS-List'; Stefan Santesson
> Subject: Re: QC certificates and Nationality
> 
> Russ Housley wrote:
> >
> > What goes into the QC when a person is a citizen of more than one
> country?
> >
> > Russ
> 
> Hello Russ,
> 
> very good point! The wording in chapter 3.2.1 doesn't fit to the
> definition of the attribute.
> 
> Right now, you have to add the attribute multiple times. I suggest
> that
> we replace the definition by the following:
> 
> countryOfCitizenship  ATTRIBUTE ::= {
>         WITH SYNTAX   SEQUENCE OF PrintableString(SIZE (2))
>                             -- IS 3166 codes only
> 
>         ID            id-at-countryOfCitizenship }
> 
> countryOfResidence    ATTRIBUTE ::= {
>         WITH SYNTAX   SEQUENCE OF PrintableString(SIZE (2))
>                             -- IS 3166 codes only
> 
>         ID            id-at-countryOfResidence }
> 
> 
> Best regards - Petra

Date: Tue, 02 Nov 1999 18:42:10 -0700
From: "Bob Jueneman" <[email-masked]>
To: <[email-masked]>, <[email-masked]>
Cc: <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>
Subject: RE: QC certificates and Nationality

Sandy,

The digraph encoding of country codes is also an ISO standard, just a 
different one.  ISO currency codes, for example, are digraphs or 
alternatively a numeric code -- yet another alternative.  There is a long
history of the existing encoding in X.500, X.400, and elsewhere,
and insufficient justification to warrant a change to a lot of already existing
CA, RP, and directory software 

Although I'm reasonably sympathetic to MISSI's desires and role here,
this is really a presentation layer API function, and not an 
architectural/protocol issue, at least to my mind.

There is another, more subtle issue here as well, and that is the question 
of being overly English-centric.

What trigraph is proposed for Germany, for example, or Switzerland,
or a number of other countries whose English names are not at all
similar to their native language forms?  For that matter, what is the 
code for that conglomeration headed by Queen Elisabeth -- is it UK, 
or GBR?

US == USA == 840.  Anyone who can handle ASN.1 ought to be 
able to handle the necessary conversions for a desired presentation 
style, IMHO.

With respect,

Bob

>>> "Miklos, Sue A." <[email-masked]> 11/02/99 12:48PM >>>
Petra,

The answer to the tri- versus di-graph is a bit detailed.  Trigraphs are
believed to be more intuitive for an operator to determine which nation is
referenced, as opposed to digraphs.  Thus, several security policies now
mandate the use of the trigraph when populating the "Release To" field in a
security label, or when populating the nationality (or multiples thereof) of
an authorization (or 'clearance') attribute.  Implementation plans
(including training classes, etc.) are well underway.  Therefore, going back
and re-writing policy to reflect a digraph is not an acceptable alternative.

>From an information management perspective, the idea of maintaining (yet
another) piece of code that translates digraphs to trigraphs every time the
"Release To" field is used, or the authorization authority populates the
nationality field in an attribute, adds to the configuration management
difficulties associated with implementing a security policy.  This piece of
code could reside in up to millions of nodes (clients, servers, gateway
devices, etc.)

Writing the translation code, distributing it (securely) and ensuring that
all components were on the same version is going to be difficult enough for
the access control decision function algorithm. We would like to avoid
(wherever possible) extending the information management space to semantic
content.  

We would like to use existing information management processes to the
greatest extent possible.  A majority opinion holds that ISO does the
information maintenance quite well and at a reasonable cost when compared to
the security domain managers maintaining the conversion tables approach.
ISO rapidly conveys changes when a nation is 'born' or 'renamed'. Thus, an
operations manual can be upgraded much more quickly and at a lower cost than
any installed module that performs conversions.  The cost of ISO membership
and subsequent re-distribution of changes is minimal in the overall scheme.

An additional aspect is associated with performance impacts.  When one adds
up all the processing associated with integrity and access control, it gets
becomes noticeable.  Any area where 'translation' or additional lookup can
be optimized is useful.

If you see any other way out of this 'challenge' or flaws in the thinking,
please respond!

Regards,
Sandi

-----Original Message-----
From: Petra Barzin (Gloeckner) [mailto:[email-masked]] 
Sent: Tuesday, November 02, 1999 12:55 PM
To: Miklos, Sue A.
Cc: Russ Housley; [email-masked]; 'SEIS-List'; Stefan Santesson
Subject: Re: QC certificates and Nationality

Hi Sandi,

the definition of our countryOfCitizenship attribute fulfils your first 
requirement. But why would you want to use trigraphs? The two letter 
codes cover all countries, don't they? 
If your application needs the three letter codes, you can easily map 
the two letter codes to the respective three letter codes.

Regards - Petra

> "Miklos, Sue A." wrote:
> 
> All,
> 
> I would like to request the attribute that represents a subject's
> nationality be structured so that dual citizenship is allowed (default
> Multivalued, which I believe is supported by countryOfCitizenship and,
> that this attribute be populated with the ISO-3166-1 (trigraph) if
> that is consistent with the domain using this piece of information.
> 
> I have requirements for both.  That is, I have a requirement for an
> attribute that can indicate a subject is a citizen of both Country A
> and Country B (country of domicile is not relevant at this point) and,
> that the citizenship be indicated with a trigraph (USA, CAN, NZL,
> etc.)
> 
> Regards,
> Sandi Miklos
> 
> -----Original Message-----
> From: Petra Barzin (Gloeckner) [mailto:[email-masked]] 
> Sent: Tuesday, November 02, 1999 4:32 AM
> To: Russ Housley
> Cc: [email-masked]; 'SEIS-List'; Stefan Santesson
> Subject: Re: QC certificates and Nationality
> 
> Russ Housley wrote:
> >
> > What goes into the QC when a person is a citizen of more than one
> country?
> >
> > Russ
> 
> Hello Russ,
> 
> very good point! The wording in chapter 3.2.1 doesn't fit to the
> definition of the attribute.
> 
> Right now, you have to add the attribute multiple times. I suggest
> that
> we replace the definition by the following:
> 
> countryOfCitizenship  ATTRIBUTE ::= {
>         WITH SYNTAX   SEQUENCE OF PrintableString(SIZE (2))
>                             -- IS 3166 codes only
> 
>         ID            id-at-countryOfCitizenship }
> 
> countryOfResidence    ATTRIBUTE ::= {
>         WITH SYNTAX   SEQUENCE OF PrintableString(SIZE (2))
>                             -- IS 3166 codes only
> 
>         ID            id-at-countryOfResidence }
> 
> 
> Best regards - Petra

From: [email-masked] (Peter Gutmann)
To: [email-masked]
Subject: Re: Possible patent issue with UTCTime hack
Sender: [email-masked]
Reply-To: [email-masked]
Date: Wed, 3 Nov 1999 14:33:22 (NZDT)

Marc Branchaud <[email-masked]> writes:

>It seems that McDonnell Douglas has patented the date "windowing" that is
>used to get around Y2K problems:

This one's already been discussed in various lists, it's as bogus as many of
the other patents the USPTO is busy churning out (which doesn't help people in
the US I guess, from the report the lawyers behind it were planning to work
their way through the yellow pages starting at Aardvark Software threatening
each company which didn't pay them royalties).  People mentioned prior art
going back two decades without really thinking about it, the last I heard no
lawyers had weighed in on whether you're violating the patent every time you
write a date without the century (which is implicitly using windowing to
resolve the century).

Peter.

From: "Tim Dierks" <[email-masked]>
To: <[email-masked]>
Subject: RE: Possible patent issue with UTCTime hack
Date: Tue, 2 Nov 1999 17:24:51 -0800
Importance: Normal

Patent number appears to be 5806063, filed Oct. 3, 1996. I believe there's a
lot of prior art (possibly including PKIX drafts). I wouldn't worry about it
too much.

<http://www.patents.ibm.com/details?pn=US05806063__>

Tim Dierks
VP of Engineering, Certicom
[email-masked]
510.780.5409 [Hayward] -- 905.501.3791 [Mississauga]

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]On Behalf
> Of Marc Branchaud
> Sent: Tuesday, November 02, 1999 5:47 PM
> To: [email-masked]
> Subject: Possible patent issue with UTCTime hack
>
>
>
> It seems that McDonnell Douglas has patented the date "windowing" that is
> used to get around Y2K problems:
>
> 	http://news.cnet.com/news/0-1009-200-1426450.html
>
> Since PKIX requires windowing UTCTime in certs, this may violate
> the patent
> (note: I don't know anything about anything, especially patents).
>
> 		Marc
>

From: "Kurn, David" <[email-masked]>
To: "'Marc Branchaud'" <[email-masked]>, [email-masked]
Subject: RE: Possible patent issue with UTCTime hack
Date: Tue, 2 Nov 1999 16:46:37 -0800 

Somehow, this reminds me of Sesamee street's advertisement...
  This program is brought to you by the number 7

Are you sure this isn't a hoax, or someone's get-rich scheme?

Patents on ideas everyone has had for hundreds of years seems rediculous.  I
remember as a child hearing my grandparents talk about the Blizzard of 99,
and they never had to say "1899".  Or, is "Spirit of 76".  That was
windowing.

David Kurn
Compaq Computer Corp.

-----Original Message-----
From: Marc Branchaud [mailto:[email-masked]]
Sent: Tuesday, November 02, 1999 5:47 PM
To: [email-masked]
Subject: Possible patent issue with UTCTime hack

It seems that McDonnell Douglas has patented the date "windowing" that is
used to get around Y2K problems:

	http://news.cnet.com/news/0-1009-200-1426450.html

Since PKIX requires windowing UTCTime in certs, this may violate the patent
(note: I don't know anything about anything, especially patents).

		Marc

Sender: [email-masked]
Date: Tue, 02 Nov 1999 17:47:05 -0800
From: Marc Branchaud <[email-masked]>
Organization: Xcert International Inc.
To: [email-masked]
Subject: Possible patent issue with UTCTime hack

It seems that McDonnell Douglas has patented the date "windowing" that is
used to get around Y2K problems:

	http://news.cnet.com/news/0-1009-200-1426450.html

Since PKIX requires windowing UTCTime in certs, this may violate the patent
(note: I don't know anything about anything, especially patents).

		Marc

From: "Todd Glassey @ GMT" <[email-masked]>
To: <[email-masked]>, <[email-masked]>
Subject: Timestamping Standards.
Date: Tue, 2 Nov 1999 14:11:45 -0800

Hi all,  in the Timestamping services drafts there might want to be a
mention of the only standards regarding timestamping currently on the books
today, because the may change some of the focus in this effort.

They provide for a requirements to provably timestamp within three (3)
seconds of UTC and these are of course the NASD OATS requirements. NASD for
thos that are unaware is the NAtional Association of Securities Dealers and
any solution that is proffered as a timestamping one for commercial purposes
should ought to fulfill the only mandate on the books today. To get more of
this try the OATS pages at the www.nasdr.com site.

I suggest that to satisfy OATS, several use-specific assumptions have to be
made like the timestamping system itself has some provable connection to a
"reliable" source of time, and the audit model to prove that the time
setting instance at the client end was accomplished appropriately, and that
these assumptions should be spelled out i detail in the Draft

Any comments?

Todd Glassey

From: "Miklos, Sue A." <[email-masked]>
To: "'Paul Koning'" <[email-masked]>
Cc: [email-masked], [email-masked], [email-masked], [email-masked], [email-masked]
Subject: RE: QC certificates and Nationality
Date: Tue, 2 Nov 1999 15:09:48 -0500 

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01BF256E.37CCF534
Content-Type: text/plain;
	charset="iso-8859-1"

One of the painful lessons we have learned is that the security policy for
the domain must be applied consistently between those training the users to
populate labels and those creating authorization information if an
automated, label-based access control decision function is to work.  

Weeding out inconsistent application of semantic content is resulting in
significant cultural change.  

I would be grateful if the extension of the attribute definition allows the
use of a trigraph.  It will be another element of information that needs to
be profiled, but that's always the impact of using flexible standards.

Sandi
-----Original Message-----
From: Paul Koning [mailto:[email-masked]]
Sent: Tuesday, November 02, 1999 3:00 PM
To: [email-masked]
Cc: [email-masked]; [email-masked]; [email-masked];
[email-masked]; [email-masked]
Subject: RE: QC certificates and Nationality

Another way to look at the digraph vs. trigraph issue: given that the
draft refers to the ISO standard, and the latest rev of that standard
has both digraph and trigraph country codes, the obvious thing to do
is to track that standard and support both.

Of course, that does pose an interesting issue.  If a cert shows
citizenship with a digraph country code and a security label has a
trigraph, is that a mismatch?  

If yes, that means that you have to use a single form consistently
across your entire organization -- trigraph or digraph, whichever you
like, but only one.  Is that an acceptable operational restriction?

If no, then you have to implement the conversion anyway, so you can
test for equality between a digraph and a trigraph country code.

	paul

------_=_NextPart_001_01BF256E.37CCF534
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Diso-8859-1">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2232.0">
<TITLE>RE: QC certificates and Nationality</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=3D2>One of the painful lessons we have learned is that =
the security policy for the domain must be applied consistently between =
those training the users to populate labels and those creating =
authorization information if an automated, label-based access control =
decision function is to work.&nbsp; </FONT></P>

<P><FONT SIZE=3D2>Weeding out inconsistent application of semantic =
content is resulting in significant cultural change.&nbsp; </FONT>
</P>

<P><FONT SIZE=3D2>I would be grateful if the extension of the attribute =
definition allows the use of a trigraph.&nbsp; It will be another =
element of information that needs to be profiled, but that's always the =
impact of using flexible standards.</FONT></P>

<P><FONT SIZE=3D2>Sandi</FONT>
<BR><FONT SIZE=3D2>-----Original Message-----</FONT>
<BR><FONT SIZE=3D2>From: Paul Koning [<A =
HREF=3D"mailto:[email-masked]">mailto:[email-masked]</A>]</FONT>
<BR><FONT SIZE=3D2>Sent: Tuesday, November 02, 1999 3:00 PM</FONT>
<BR><FONT SIZE=3D2>To: [email-masked]</FONT>
<BR><FONT SIZE=3D2>Cc: [email-masked]; [email-masked]; =
[email-masked];</FONT>
<BR><FONT SIZE=3D2>[email-masked]; [email-masked]</FONT>
<BR><FONT SIZE=3D2>Subject: RE: QC certificates and Nationality</FONT>
</P>
<BR>

<P><FONT SIZE=3D2>Another way to look at the digraph vs. trigraph =
issue: given that the</FONT>
<BR><FONT SIZE=3D2>draft refers to the ISO standard, and the latest rev =
of that standard</FONT>
<BR><FONT SIZE=3D2>has both digraph and trigraph country codes, the =
obvious thing to do</FONT>
<BR><FONT SIZE=3D2>is to track that standard and support both.</FONT>
</P>

<P><FONT SIZE=3D2>Of course, that does pose an interesting issue.&nbsp; =
If a cert shows</FONT>
<BR><FONT SIZE=3D2>citizenship with a digraph country code and a =
security label has a</FONT>
<BR><FONT SIZE=3D2>trigraph, is that a mismatch?&nbsp; </FONT>
</P>

<P><FONT SIZE=3D2>If yes, that means that you have to use a single form =
consistently</FONT>
<BR><FONT SIZE=3D2>across your entire organization -- trigraph or =
digraph, whichever you</FONT>
<BR><FONT SIZE=3D2>like, but only one.&nbsp; Is that an acceptable =
operational restriction?</FONT>
</P>

<P><FONT SIZE=3D2>If no, then you have to implement the conversion =
anyway, so you can</FONT>
<BR><FONT SIZE=3D2>test for equality between a digraph and a trigraph =
country code.</FONT>
</P>

<P>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT =
SIZE=3D2>paul</FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01BF256E.37CCF534--

Date: Tue, 2 Nov 1999 14:59:30 -0500
From: Paul Koning <[email-masked]>
To: [email-masked]
Cc: [email-masked], [email-masked], [email-masked], [email-masked], [email-masked]
Subject: RE: QC certificates and Nationality

Another way to look at the digraph vs. trigraph issue: given that the
draft refers to the ISO standard, and the latest rev of that standard
has both digraph and trigraph country codes, the obvious thing to do
is to track that standard and support both.

Of course, that does pose an interesting issue.  If a cert shows
citizenship with a digraph country code and a security label has a
trigraph, is that a mismatch?  

If yes, that means that you have to use a single form consistently
across your entire organization -- trigraph or digraph, whichever you
like, but only one.  Is that an acceptable operational restriction?

If no, then you have to implement the conversion anyway, so you can
test for equality between a digraph and a trigraph country code.

	paul

From: "Miklos, Sue A." <[email-masked]>
To: "'Petra Barzin (Gloeckner)'" <[email-masked]>
Cc: Russ Housley <[email-masked]>, [email-masked], "'SEIS-List'" <[email-masked]>, Stefan Santesson <[email-masked]>
Subject: RE: QC certificates and Nationality
Date: Tue, 2 Nov 1999 14:48:32 -0500 

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01BF256B.42040E96
Content-Type: text/plain;
	charset="iso-8859-1"

Petra,

The answer to the tri- versus di-graph is a bit detailed.  Trigraphs are
believed to be more intuitive for an operator to determine which nation is
referenced, as opposed to digraphs.  Thus, several security policies now
mandate the use of the trigraph when populating the "Release To" field in a
security label, or when populating the nationality (or multiples thereof) of
an authorization (or 'clearance') attribute.  Implementation plans
(including training classes, etc.) are well underway.  Therefore, going back
and re-writing policy to reflect a digraph is not an acceptable alternative.

>From an information management perspective, the idea of maintaining (yet
another) piece of code that translates digraphs to trigraphs every time the
"Release To" field is used, or the authorization authority populates the
nationality field in an attribute, adds to the configuration management
difficulties associated with implementing a security policy.  This piece of
code could reside in up to millions of nodes (clients, servers, gateway
devices, etc.)

Writing the translation code, distributing it (securely) and ensuring that
all components were on the same version is going to be difficult enough for
the access control decision function algorithm. We would like to avoid
(wherever possible) extending the information management space to semantic
content.  

We would like to use existing information management processes to the
greatest extent possible.  A majority opinion holds that ISO does the
information maintenance quite well and at a reasonable cost when compared to
the security domain managers maintaining the conversion tables approach.
ISO rapidly conveys changes when a nation is 'born' or 'renamed'. Thus, an
operations manual can be upgraded much more quickly and at a lower cost than
any installed module that performs conversions.  The cost of ISO membership
and subsequent re-distribution of changes is minimal in the overall scheme.

An additional aspect is associated with performance impacts.  When one adds
up all the processing associated with integrity and access control, it gets
becomes noticeable.  Any area where 'translation' or additional lookup can
be optimized is useful.

If you see any other way out of this 'challenge' or flaws in the thinking,
please respond!

Regards,
Sandi

-----Original Message-----
From: Petra Barzin (Gloeckner) [mailto:[email-masked]]
Sent: Tuesday, November 02, 1999 12:55 PM
To: Miklos, Sue A.
Cc: Russ Housley; [email-masked]; 'SEIS-List'; Stefan Santesson
Subject: Re: QC certificates and Nationality

Hi Sandi,

the definition of our countryOfCitizenship attribute fulfils your first 
requirement. But why would you want to use trigraphs? The two letter 
codes cover all countries, don't they? 
If your application needs the three letter codes, you can easily map 
the two letter codes to the respective three letter codes.

Regards - Petra

> "Miklos, Sue A." wrote:
> 
> All,
> 
> I would like to request the attribute that represents a subject's
> nationality be structured so that dual citizenship is allowed (default
> Multivalued, which I believe is supported by countryOfCitizenship and,
> that this attribute be populated with the ISO-3166-1 (trigraph) if
> that is consistent with the domain using this piece of information.
> 
> I have requirements for both.  That is, I have a requirement for an
> attribute that can indicate a subject is a citizen of both Country A
> and Country B (country of domicile is not relevant at this point) and,
> that the citizenship be indicated with a trigraph (USA, CAN, NZL,
> etc.)
> 
> Regards,
> Sandi Miklos
> 
> -----Original Message-----
> From: Petra Barzin (Gloeckner) [mailto:[email-masked]]
> Sent: Tuesday, November 02, 1999 4:32 AM
> To: Russ Housley
> Cc: [email-masked]; 'SEIS-List'; Stefan Santesson
> Subject: Re: QC certificates and Nationality
> 
> Russ Housley wrote:
> >
> > What goes into the QC when a person is a citizen of more than one
> country?
> >
> > Russ
> 
> Hello Russ,
> 
> very good point! The wording in chapter 3.2.1 doesn't fit to the
> definition of the attribute.
> 
> Right now, you have to add the attribute multiple times. I suggest
> that
> we replace the definition by the following:
> 
> countryOfCitizenship  ATTRIBUTE ::= {
>         WITH SYNTAX   SEQUENCE OF PrintableString(SIZE (2))
>                             -- IS 3166 codes only
> 
>         ID            id-at-countryOfCitizenship }
> 
> countryOfResidence    ATTRIBUTE ::= {
>         WITH SYNTAX   SEQUENCE OF PrintableString(SIZE (2))
>                             -- IS 3166 codes only
> 
>         ID            id-at-countryOfResidence }
> 
> 
> Best regards - Petra

------_=_NextPart_001_01BF256B.42040E96
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Diso-8859-1">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2232.0">
<TITLE>RE: QC certificates and Nationality</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=3D2>Petra,</FONT>
</P>

<P><FONT SIZE=3D2>The answer to the tri- versus di-graph is a bit =
detailed.&nbsp; Trigraphs are believed to be more intuitive for an =
operator to determine which nation is referenced, as opposed to =
digraphs.&nbsp; Thus, several security policies now mandate the use of =
the trigraph when populating the &quot;Release To&quot; field in a =
security label, or when populating the nationality (or multiples =
thereof) of an authorization (or 'clearance') attribute.&nbsp; =
Implementation plans (including training classes, etc.) are well =
underway.&nbsp; Therefore, going back and re-writing policy to reflect =
a digraph is not an acceptable alternative.</FONT></P>

<P><FONT SIZE=3D2>From an information management perspective, the idea =
of maintaining (yet another) piece of code that translates digraphs to =
trigraphs every time the &quot;Release To&quot; field is used, or the =
authorization authority populates the nationality field in an =
attribute, adds to the configuration management difficulties associated =
with implementing a security policy.&nbsp; This piece of code could =
reside in up to millions of nodes (clients, servers, gateway devices, =
etc.)</FONT></P>

<P><FONT SIZE=3D2>Writing the translation code, distributing it =
(securely) and ensuring that all components were on the same version is =
going to be difficult enough for the access control decision function =
algorithm. We would like to avoid (wherever possible) extending the =
information management space to semantic content.&nbsp; </FONT></P>

<P><FONT SIZE=3D2>We would like to use existing information management =
processes to the greatest extent possible.&nbsp; A majority opinion =
holds that ISO does the information maintenance quite well and at a =
reasonable cost when compared to the security domain managers =
maintaining the conversion tables approach.&nbsp; ISO rapidly conveys =
changes when a nation is 'born' or 'renamed'. Thus, an operations =
manual can be upgraded much more quickly and at a lower cost than any =
installed module that performs conversions.&nbsp; The cost of ISO =
membership and subsequent re-distribution of changes is minimal in the =
overall scheme.</FONT></P>

<P><FONT SIZE=3D2>An additional aspect is associated with performance =
impacts.&nbsp; When one adds up all the processing associated with =
integrity and access control, it gets becomes noticeable.&nbsp; Any =
area where 'translation' or additional lookup can be optimized is =
useful.</FONT></P>

<P><FONT SIZE=3D2>If you see any other way out of this 'challenge' or =
flaws in the thinking, please respond!</FONT>
</P>

<P><FONT SIZE=3D2>Regards,</FONT>
<BR><FONT SIZE=3D2>Sandi</FONT>
</P>

<P><FONT SIZE=3D2>-----Original Message-----</FONT>
<BR><FONT SIZE=3D2>From: Petra Barzin (Gloeckner) [<A =
HREF=3D"mailto:[email-masked]">mailto:[email-masked]</A>]</FONT>
<BR><FONT SIZE=3D2>Sent: Tuesday, November 02, 1999 12:55 PM</FONT>
<BR><FONT SIZE=3D2>To: Miklos, Sue A.</FONT>
<BR><FONT SIZE=3D2>Cc: Russ Housley; [email-masked]; 'SEIS-List'; =
Stefan Santesson</FONT>
<BR><FONT SIZE=3D2>Subject: Re: QC certificates and Nationality</FONT>
</P>
<BR>

<P><FONT SIZE=3D2>Hi Sandi,</FONT>
</P>

<P><FONT SIZE=3D2>the definition of our countryOfCitizenship attribute =
fulfils your first </FONT>
<BR><FONT SIZE=3D2>requirement. But why would you want to use =
trigraphs? The two letter </FONT>
<BR><FONT SIZE=3D2>codes cover all countries, don't they? </FONT>
<BR><FONT SIZE=3D2>If your application needs the three letter codes, =
you can easily map </FONT>
<BR><FONT SIZE=3D2>the two letter codes to the respective three letter =
codes.</FONT>
</P>

<P><FONT SIZE=3D2>Regards - Petra</FONT>
</P>

<P><FONT SIZE=3D2>&gt; &quot;Miklos, Sue A.&quot; wrote:</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; All,</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; I would like to request the attribute that =
represents a subject's</FONT>
<BR><FONT SIZE=3D2>&gt; nationality be structured so that dual =
citizenship is allowed (default</FONT>
<BR><FONT SIZE=3D2>&gt; Multivalued, which I believe is supported by =
countryOfCitizenship and,</FONT>
<BR><FONT SIZE=3D2>&gt; that this attribute be populated with the =
ISO-3166-1 (trigraph) if</FONT>
<BR><FONT SIZE=3D2>&gt; that is consistent with the domain using this =
piece of information.</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; I have requirements for both.&nbsp; That is, I =
have a requirement for an</FONT>
<BR><FONT SIZE=3D2>&gt; attribute that can indicate a subject is a =
citizen of both Country A</FONT>
<BR><FONT SIZE=3D2>&gt; and Country B (country of domicile is not =
relevant at this point) and,</FONT>
<BR><FONT SIZE=3D2>&gt; that the citizenship be indicated with a =
trigraph (USA, CAN, NZL,</FONT>
<BR><FONT SIZE=3D2>&gt; etc.)</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; Regards,</FONT>
<BR><FONT SIZE=3D2>&gt; Sandi Miklos</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; -----Original Message-----</FONT>
<BR><FONT SIZE=3D2>&gt; From: Petra Barzin (Gloeckner) [<A =
HREF=3D"mailto:[email-masked]">mailto:[email-masked]</A>]</FONT>
<BR><FONT SIZE=3D2>&gt; Sent: Tuesday, November 02, 1999 4:32 AM</FONT>
<BR><FONT SIZE=3D2>&gt; To: Russ Housley</FONT>
<BR><FONT SIZE=3D2>&gt; Cc: [email-masked]; 'SEIS-List'; Stefan =
Santesson</FONT>
<BR><FONT SIZE=3D2>&gt; Subject: Re: QC certificates and =
Nationality</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; Russ Housley wrote:</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; What goes into the QC when a person is a =
citizen of more than one</FONT>
<BR><FONT SIZE=3D2>&gt; country?</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; Russ</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; Hello Russ,</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; very good point! The wording in chapter 3.2.1 =
doesn't fit to the</FONT>
<BR><FONT SIZE=3D2>&gt; definition of the attribute.</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; Right now, you have to add the attribute =
multiple times. I suggest</FONT>
<BR><FONT SIZE=3D2>&gt; that</FONT>
<BR><FONT SIZE=3D2>&gt; we replace the definition by the =
following:</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; countryOfCitizenship&nbsp; ATTRIBUTE ::=3D =
{</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
WITH SYNTAX&nbsp;&nbsp; SEQUENCE OF PrintableString(SIZE (2))</FONT>
<BR><FONT =
SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; -- IS 3166 codes only</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
ID&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
id-at-countryOfCitizenship }</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; countryOfResidence&nbsp;&nbsp;&nbsp; ATTRIBUTE =
::=3D {</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
WITH SYNTAX&nbsp;&nbsp; SEQUENCE OF PrintableString(SIZE (2))</FONT>
<BR><FONT =
SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; -- IS 3166 codes only</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
ID&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
id-at-countryOfResidence }</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; Best regards - Petra</FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01BF256B.42040E96--

From: "Jorge M. Vargas" <[email-masked]>
To: "Ietf-Pkix" <[email-masked]>
Subject: "List-Unsubscribe:"
Date: Tue, 2 Nov 1999 14:37:01 -0500
Importance: High

"List-Unsubscribe:"

Date: Tue, 02 Nov 1999 11:52:15 -0700
From: "Bob Jueneman" <[email-masked]>
To: <[email-masked]>, <[email-masked]>, <[email-masked]>
Cc: <[email-masked]>, <[email-masked]>
Subject: RE: NR, redux, again.

Mike,

Some of us, at least, would like to go substantially beyond the
traditional technical/syntactical validation of NR, which you have stated 
reasonably well.  And that, of course, is the primary issue.

In particular, there is the question of conscious INTENT or volition --
did I really mean to affix my legally binding signature to this document, or 
did some automaton get carried away and apply my signature to 
something I personally never approved? (Consider the S/MIME v3 
digitally signed receipt for a message as an example of a protocol 
that involves a digital signature, but not necessarily a signature 
that represents either approval of the contents, or even volition.)

In addition, even if volition were present, is the key management, etc., 
associated with that signature of sufficient strength that I the user
would wish to have the risk associated with being legally bound by
that signature, even one nanosecond from now (i.e., during the
certificate validity period), much less 40 years from now?

To my way of thinking, these issues are far more important to establishing
the long-term legal validity of my signature on a contract than the fact that 
the certificate wasn't revoked. After all, I would only have reason to revoke
my key if I suspected that it had been compromised, and it would be
an unusually stupid attacker who would compromise my key and let me 
know about it.

In addition, just because the certificate was revoked doesn't mean that 
my signature wasn't valid, if it can be proven that I in fact did sign the 
document in question, presumably by some other, more conventional 
forensic or testimonial methods.

So, as Ed and others have already pointed out, the convention technical
definition is neither necessary nor sufficient to establish nonrepudiation.

What we really have to deal with are two issues:

1.  Who bears the burden of proof with respect to a challenged signature, 
under what circumstances, and

2.  Who bears the risk of loss if it can reasonably be established that the 
subject of the certificate in fact did NOT sign the document.

Unless or until we can answer those questions, nonrepudiation is just
a technical artifact -- not much more than a convenience or an inconvenience,
depending on whose side you are on.

Bob

>>> MHenry <[email-masked]> 11/02/99 11:32AM >>>
Tom,
Is there an agreed opon list of what must be archived in order to 
support NR for a signature? It would seem that the list must include: the
original document, the signature in question (in case there are advances in 
computing or algorithms to attack the cryptographic primitives used),
the certificate used to compute the signature, all certs used to sign that
cert, the CRLs for all certs involved.

Mike Henry
Performance Engineering Corporation
> -----Original Message-----
> From:	[email-masked] [SMTP:[email-masked]] 
> Sent:	Tuesday, November 02, 1999 12:23 PM
> To:	Tony Bartoletti
> Cc:	Bob Jueneman; [email-masked]; [email-masked] 
> Subject:	Re: NR, redux, again.
> 
> (snip)
> All,
> 
> I think we have long agreed that a single NR-bit is of very limited
> utility in conveying the range of qualities we may need to assert in
> non-repudiation.  (Ed Gerck's taxonomy and Tom Gindin's codification
> are certainly a solid representation of this range.)  In particular,
> as Bob reminds us, there is no a-priori reason to assume that NR is
> strictly (or even best) the job of the CA.
> 
> As a exercise, it may be useful to imagine that you are going to set
> yourself up as an "Full-Serve Digital NR Service" but you are NOT a CA.
> Of course, you will be involved with digital documents, signatures,
> certificates, independent time-stamps, and countless other concerns.
> Now the question to ask is "What, if anything, would you want a given
> certificate's NR-bit to signify?"  Of what utility is it to you?
> 
> Being a full NR service, I imagine you will certainly be archiving
> relevant objects as a matter of course, so do you care if the CA is
> providing (redundant) long-term storage?  I doubt so.  Hence the
> association of cert NR-bit with cert "lifetime" is misplaced.
> 
> [Tom Gindin]   The CA is the logical candidate to provide long-term
> storage
> for CRL's in those cases where NR is supported.  Because a revocation may
> carry a claim about "invalidityDate", the NR service cannot be sure when
> it
> has sufficient evidence that the subject of the certificate for the
> signing
> key pair will not claim that the signature was invalid because of key
> compromise - simply having a CRL dated later than the signature is not
> enough.  However, this is not an issue with certificate lifetime.  I know
> of no other long-term storage that any NR service can expect from the CA.
> 
> I can understand why some folks (CAs) would like to limit the NR-bit
> to such a simple notion.  It is "do-able", and they are under pressure
> to "do NR" from some quarters.
> 
> [Tom Gindin]   CRL archiving is all the CA needs to do to support NR.
> That
> does not mean that it is all that must be done for NR.
> 
> Comments?
> 
> ___tony___
> 
> Tony Bartoletti                                             LL
> IOWA Center                                              LL LL
> Lawrence Livermore National Laboratory                LL LL LL
> PO Box 808, L - 089                                   LL LL LL
> Livermore, CA 94551-9900                              LL LL LLLLLLLL
> phone: 925-422-3881   fax: 925-423-8081               LL LLLLLLLL
> email: [email-masked]                                   LLLLLLLL
> 
> 

From: MHenry <[email-masked]>
To: "'Bob Jueneman'" <[email-masked]>, Tony Bartoletti <[email-masked]>, MHenry <[email-masked]>, "[email-masked]'" <[email-masked]>
Cc: [email-masked], [email-masked]
Subject: RE: NR, redux, again.
Date: Tue, 2 Nov 1999 14:26:23 -0500 

Bob,
I followed your and Ed Gerck's arguments closely during the earlier
discussion. I was quickly persuaded that your analysis of the issue
was correct. 
I have to make recommendations to a client as to what must be 
archived in order to support NR. The objects that listed previously
 appear to support  the "traditional/technical/syntactical " concept of NR.
What additional objects should be archived in order to support your
evolving concept of NR?

Mike

> -----Original Message-----
> From:	Bob Jueneman [SMTP:[email-masked]]
> Sent:	Tuesday, November 02, 1999 1:52 PM
> To:	Tony Bartoletti; [email-masked]; [email-masked]'
> Cc:	[email-masked]; [email-masked]
> Subject:	RE: NR, redux, again.
> 
> Mike,
> 
> Some of us, at least, would like to go substantially beyond the
> traditional technical/syntactical validation of NR, which you have stated 
> reasonably well.  And that, of course, is the primary issue.
> 
> In particular, there is the question of conscious INTENT or volition --
> did I really mean to affix my legally binding signature to this document,
> or 
> did some automaton get carried away and apply my signature to 
> something I personally never approved? (Consider the S/MIME v3 
> digitally signed receipt for a message as an example of a protocol 
> that involves a digital signature, but not necessarily a signature 
> that represents either approval of the contents, or even volition.)
> 
> In addition, even if volition were present, is the key management, etc., 
> associated with that signature of sufficient strength that I the user
> would wish to have the risk associated with being legally bound by
> that signature, even one nanosecond from now (i.e., during the
> certificate validity period), much less 40 years from now?
> 
> To my way of thinking, these issues are far more important to establishing
> the long-term legal validity of my signature on a contract than the fact
> that 
> the certificate wasn't revoked. After all, I would only have reason to
> revoke
> my key if I suspected that it had been compromised, and it would be
> an unusually stupid attacker who would compromise my key and let me 
> know about it.
> 
> In addition, just because the certificate was revoked doesn't mean that 
> my signature wasn't valid, if it can be proven that I in fact did sign the
> 
> document in question, presumably by some other, more conventional 
> forensic or testimonial methods.
> 
> So, as Ed and others have already pointed out, the convention technical
> definition is neither necessary nor sufficient to establish
> nonrepudiation.
> 
> What we really have to deal with are two issues:
> 
> 1.  Who bears the burden of proof with respect to a challenged signature, 
> under what circumstances, and
> 
> 2.  Who bears the risk of loss if it can reasonably be established that
> the 
> subject of the certificate in fact did NOT sign the document.
> 
> Unless or until we can answer those questions, nonrepudiation is just
> a technical artifact -- not much more than a convenience or an
> inconvenience,
> depending on whose side you are on.
> 
> Bob
> 
> 
> 
> >>> MHenry <[email-masked]> 11/02/99 11:32AM >>>
> Tom,
> Is there an agreed opon list of what must be archived in order to 
> support NR for a signature? It would seem that the list must include: the
> original document, the signature in question (in case there are advances
> in 
> computing or algorithms to attack the cryptographic primitives used),
> the certificate used to compute the signature, all certs used to sign that
> cert, the CRLs for all certs involved.
> 
> Mike Henry
> Performance Engineering Corporation
> > -----Original Message-----
> > From:	[email-masked] [SMTP:[email-masked]] 
> > Sent:	Tuesday, November 02, 1999 12:23 PM
> > To:	Tony Bartoletti
> > Cc:	Bob Jueneman; [email-masked]; [email-masked] 
> > Subject:	Re: NR, redux, again.
> > 
> > (snip)
> > All,
> > 
> > I think we have long agreed that a single NR-bit is of very limited
> > utility in conveying the range of qualities we may need to assert in
> > non-repudiation.  (Ed Gerck's taxonomy and Tom Gindin's codification
> > are certainly a solid representation of this range.)  In particular,
> > as Bob reminds us, there is no a-priori reason to assume that NR is
> > strictly (or even best) the job of the CA.
> > 
> > As a exercise, it may be useful to imagine that you are going to set
> > yourself up as an "Full-Serve Digital NR Service" but you are NOT a CA.
> > Of course, you will be involved with digital documents, signatures,
> > certificates, independent time-stamps, and countless other concerns.
> > Now the question to ask is "What, if anything, would you want a given
> > certificate's NR-bit to signify?"  Of what utility is it to you?
> > 
> > Being a full NR service, I imagine you will certainly be archiving
> > relevant objects as a matter of course, so do you care if the CA is
> > providing (redundant) long-term storage?  I doubt so.  Hence the
> > association of cert NR-bit with cert "lifetime" is misplaced.
> > 
> > [Tom Gindin]   The CA is the logical candidate to provide long-term
> > storage
> > for CRL's in those cases where NR is supported.  Because a revocation
> may
> > carry a claim about "invalidityDate", the NR service cannot be sure when
> > it
> > has sufficient evidence that the subject of the certificate for the
> > signing
> > key pair will not claim that the signature was invalid because of key
> > compromise - simply having a CRL dated later than the signature is not
> > enough.  However, this is not an issue with certificate lifetime.  I
> know
> > of no other long-term storage that any NR service can expect from the
> CA.
> > 
> > I can understand why some folks (CAs) would like to limit the NR-bit
> > to such a simple notion.  It is "do-able", and they are under pressure
> > to "do NR" from some quarters.
> > 
> > [Tom Gindin]   CRL archiving is all the CA needs to do to support NR.
> > That
> > does not mean that it is all that must be done for NR.
> > 
> > Comments?
> > 
> > ___tony___
> > 
> > Tony Bartoletti                                             LL
> > IOWA Center                                              LL LL
> > Lawrence Livermore National Laboratory                LL LL LL
> > PO Box 808, L - 089                                   LL LL LL
> > Livermore, CA 94551-9900                              LL LL LLLLLLLL
> > phone: 925-422-3881   fax: 925-423-8081               LL LLLLLLLL
> > email: [email-masked]                                   LLLLLLLL
> > 
> > 

Date: Tue, 02 Nov 1999 11:19:08 -0800
To: <[email-masked]>
From: Paul Hoffman / IMC <[email-masked]>
Subject: Re: 

At 01:39 PM 11/2/99 -0500, Dan Carson wrote:
>REMOVE

Let me try to head of the inevitable spate of people sending such messages 
to the mailing list: please don't. To be removed from the mailing list, 
send a message to:
      [email-masked]
with the single word
      unsubscribe
in the body of the message. Those are the instructions you were given when 
you subscribed, and that is also what will happen if you select the 
"List-Unsubscribe:" header that appears at the top of each message.

If you need personal assistance, feel free to contact me directly. Please 
don't waste everyone's time by sending these messages to the whole list. 
Thanks!

--Paul Hoffman, Director
--Internet Mail Consortium

Date: Tue, 02 Nov 1999 11:15:21 -0800
To: [email-masked]
From: Tony Bartoletti <[email-masked]>
Subject: Re: NR, redux, again.
Cc: "Bob Jueneman" <[email-masked]>, [email-masked], [email-masked]

At 12:23 PM 11/2/99 -0500, [email-masked] wrote:
>
>[Tom Gindin]   CRL archiving is all the CA needs to do to support NR.  That
>does not mean that it is all that must be done for NR.

Hmmm.  Regarding the CA, that depends on what one expects from NR.

Question:  What exactly does CRL archiving do for you?
Answer:    You can establish that CA-x held Cert-y valid at time t.
           Would you need to have your own timestamped archive of the
           the CA's (public) CRL-signing key taken while it was itself
           valid, to be more comfortable?

If this is exactly what the "NR-bit" will imply, then it should be
called the "CRL-Archive-bit" and the debate about its implications
will be greatly reduced.

But I am missing something here.  To "NR" a transaction, I will need the
(supposedly) signed elements of the transaction to be timestamped and
archived at (near?) the time of transaction, true?  In particular, the
NR-service (at the outset) would test that the supposed EE-signature
actually verifies with a cert valid according to a current CRL.
(Else a revoked and "discarded key" might be used to forge a pre-dated
element.)  But if the NR-service must archive "some" elements at/near
the transaction time, then why not the relevant CRL itself?

Still, I ask myself "Is this all that I want from a CA in support of an
NR-transaction?"  Would I not want some "better" assurance, or evidence
that the EE who was issued this key was who they claimed to be?

Put another way, if I were a sloppy CA, handing out certs blindly,
(and my CP/CPS admits as much) but I dutifully archive my CRL's,
would my signing of an NR-bit on a cert be of any real value to
the individual (RP) who wants a transaction to be NR?  Would not
the RP be laughed out of court once the CP/CPS was entered into
evidence?  And contrastingly, if the CP/CPS were strong, wouldn't
that document need to be timestamped/archived circa the transaction?

___tony___  

Tony Bartoletti                                             LL
IOWA Center                                              LL LL
Lawrence Livermore National Laboratory                LL LL LL
PO Box 808, L - 089                                   LL LL LL
Livermore, CA 94551-9900                              LL LL LLLLLLLL
phone: 925-422-3881   fax: 925-423-8081               LL LLLLLLLL
email: [email-masked]                                   LLLLLLLL

From: "Jorge M. Vargas" <[email-masked]>
To: "Ietf-Pkix" <[email-masked]>
Date: Tue, 2 Nov 1999 13:49:28 -0500
Importance: High

REMOVE

From: "Dan Carson" <[email-masked]>
To: <[email-masked]>
Subject: 
Date: Tue, 2 Nov 1999 13:39:17 -0500
Importance: Normal

REMOVE

From: MHenry <[email-masked]>
To: "[email-masked]'" <[email-masked]>, Tony Bartoletti <[email-masked]>
Cc: Bob Jueneman <[email-masked]>, [email-masked], [email-masked]
Subject: RE: NR, redux, again.
Date: Tue, 2 Nov 1999 13:32:29 -0500 

Tom,
Is there an agreed opon list of what must be archived in order to 
support NR for a signature? It would seem that the list must include: the
original document, the signature in question (in case there are advances in 
computing or algorithms to attack the cryptographic primitives used),
the certificate used to compute the signature, all certs used to sign that
cert, the CRLs for all certs involved.

Mike Henry
Performance Engineering Corporation
> -----Original Message-----
> From:	[email-masked] [SMTP:[email-masked]]
> Sent:	Tuesday, November 02, 1999 12:23 PM
> To:	Tony Bartoletti
> Cc:	Bob Jueneman; [email-masked]; [email-masked]
> Subject:	Re: NR, redux, again.
> 
> (snip)
> All,
> 
> I think we have long agreed that a single NR-bit is of very limited
> utility in conveying the range of qualities we may need to assert in
> non-repudiation.  (Ed Gerck's taxonomy and Tom Gindin's codification
> are certainly a solid representation of this range.)  In particular,
> as Bob reminds us, there is no a-priori reason to assume that NR is
> strictly (or even best) the job of the CA.
> 
> As a exercise, it may be useful to imagine that you are going to set
> yourself up as an "Full-Serve Digital NR Service" but you are NOT a CA.
> Of course, you will be involved with digital documents, signatures,
> certificates, independent time-stamps, and countless other concerns.
> Now the question to ask is "What, if anything, would you want a given
> certificate's NR-bit to signify?"  Of what utility is it to you?
> 
> Being a full NR service, I imagine you will certainly be archiving
> relevant objects as a matter of course, so do you care if the CA is
> providing (redundant) long-term storage?  I doubt so.  Hence the
> association of cert NR-bit with cert "lifetime" is misplaced.
> 
> [Tom Gindin]   The CA is the logical candidate to provide long-term
> storage
> for CRL's in those cases where NR is supported.  Because a revocation may
> carry a claim about "invalidityDate", the NR service cannot be sure when
> it
> has sufficient evidence that the subject of the certificate for the
> signing
> key pair will not claim that the signature was invalid because of key
> compromise - simply having a CRL dated later than the signature is not
> enough.  However, this is not an issue with certificate lifetime.  I know
> of no other long-term storage that any NR service can expect from the CA.
> 
> I can understand why some folks (CAs) would like to limit the NR-bit
> to such a simple notion.  It is "do-able", and they are under pressure
> to "do NR" from some quarters.
> 
> [Tom Gindin]   CRL archiving is all the CA needs to do to support NR.
> That
> does not mean that it is all that must be done for NR.
> 
> Comments?
> 
> ___tony___
> 
> Tony Bartoletti                                             LL
> IOWA Center                                              LL LL
> Lawrence Livermore National Laboratory                LL LL LL
> PO Box 808, L - 089                                   LL LL LL
> Livermore, CA 94551-9900                              LL LL LLLLLLLL
> phone: 925-422-3881   fax: 925-423-8081               LL LLLLLLLL
> email: [email-masked]                                   LLLLLLLL
> 
> 

Date: Tue, 02 Nov 1999 18:45:25 +0100
From: "Petra Barzin (Gloeckner)" <[email-masked]>
To: Russ Housley <[email-masked]>, [email-masked], "'SEIS-List'" <[email-masked]>, Stefan Santesson <[email-masked]>
Subject: Re: QC certificates and Nationality

This is a cryptographically signed message in MIME format.

--------------ms9E334005D11BEAF704F3B3CD
Content-Type: multipart/mixed;
 boundary="------------BE401B15FBCB568730279157"

This is a multi-part message in MIME format.
--------------BE401B15FBCB568730279157
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Sorry, I've to correct my last statement. In the QC we are using the 
Attribute definition (in contrast to the AttributeTypeAndValue 
definition being used in a DName):

	personalDataAttributes	SEQUENCE SIZE (1..MAX) OF Attribute
							  ^^^^^^^^^

I just read the respective part of the X.501 standard where Attribute is 
defined. It is indeed multivalued, i.e. multiple values can be used:

Attribute ::= SEQUENCE {
    type      ATTRIBUTE.&id({SupportedAttributes}),
    values    SET SIZE (1..MAX) OF
ATTRIBUTE.&Type({SupportedAttributes}{@type})}
	      ^^^

If the same attribute would be used in a DName it would be only 
single-valued, i.e. you would have to use the attribute multiple times:

AttributeTypeAndValue ::= SEQUENCE{
    type    ATTRIBUTE.&id({SupportedAttributes}),
    values  ATTRIBUTE.&Type({SupportedAttributes}{@type})}

Sorry for the confusion. 
Best regards - Petra

"Petra Barzin (Gloeckner)" wrote:
> 
> Russ Housley wrote:
> >
> > What goes into the QC when a person is a citizen of more than one country?
> >
> > Russ
> 
> Hello Russ,
> 
> very good point! The wording in chapter 3.2.1 doesn't fit to the
> definition of the attribute.
> 
> Right now, you have to add the attribute multiple times. I suggest that
> we replace the definition by the following:
> 
> countryOfCitizenship  ATTRIBUTE ::= {
>         WITH SYNTAX   SEQUENCE OF PrintableString(SIZE (2))
>                                         -- IS 3166 codes only
>         ID            id-at-countryOfCitizenship }
> 
> countryOfResidence    ATTRIBUTE ::= {
>         WITH SYNTAX   SEQUENCE OF PrintableString(SIZE (2))
>                                         -- IS 3166 codes only
>         ID            id-at-countryOfResidence }
> 
> 
> Best regards - Petra
--------------BE401B15FBCB568730279157
Content-Type: text/x-vcard; charset=us-ascii;
 name="barzin.vcf"
Content-Transfer-Encoding: 7bit
Content-Description: Card for Petra Barzin (Gloeckner)
Content-Disposition: attachment;
 filename="barzin.vcf"

begin:vcard 
n:Barzin;Petra
tel;fax: (+49) 6151/82 89 7 - 26
tel;work:(+49) 6151/82 89 7 - 30
x-mozilla-html:FALSE
url:www.secude.com
org:<hr size=1><p align=right><b><font color=green>SECUDE</font></b> <i>Sicherheitstechnologie<br>Informationssysteme GmbH</i>
adr:;;Landwehrstr. 50a;Darmstadt;;D-64293;Germany
version:2.1
email;internet:[email-masked]
fn:Petra Barzin
end:vcard

--------------BE401B15FBCB568730279157--

--------------ms9E334005D11BEAF704F3B3CD
Content-Type: application/x-pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature

--------------ms9E334005D11BEAF704F3B3CD--

Date: Tue, 02 Nov 1999 18:54:59 +0100
From: "Petra Barzin (Gloeckner)" <[email-masked]>
To: "Miklos, Sue A." <[email-masked]>
CC: Russ Housley <[email-masked]>, [email-masked], "'SEIS-List'" <[email-masked]>, Stefan Santesson <[email-masked]>
Subject: Re: QC certificates and Nationality

This is a cryptographically signed message in MIME format.

--------------msAA155E49984B012B5EE4A4B4
Content-Type: multipart/mixed;
 boundary="------------C22A23579330612FB0B47FAE"

This is a multi-part message in MIME format.
--------------C22A23579330612FB0B47FAE
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Hi Sandi,

the definition of our countryOfCitizenship attribute fulfils your first 
requirement. But why would you want to use trigraphs? The two letter 
codes cover all countries, don't they? 
If your application needs the three letter codes, you can easily map 
the two letter codes to the respective three letter codes.

Regards - Petra

> "Miklos, Sue A." wrote:
> 
> All,
> 
> I would like to request the attribute that represents a subject's
> nationality be structured so that dual citizenship is allowed (default
> Multivalued, which I believe is supported by countryOfCitizenship and,
> that this attribute be populated with the ISO-3166-1 (trigraph) if
> that is consistent with the domain using this piece of information.
> 
> I have requirements for both.  That is, I have a requirement for an
> attribute that can indicate a subject is a citizen of both Country A
> and Country B (country of domicile is not relevant at this point) and,
> that the citizenship be indicated with a trigraph (USA, CAN, NZL,
> etc.)
> 
> Regards,
> Sandi Miklos
> 
> -----Original Message-----
> From: Petra Barzin (Gloeckner) [mailto:[email-masked]]
> Sent: Tuesday, November 02, 1999 4:32 AM
> To: Russ Housley
> Cc: [email-masked]; 'SEIS-List'; Stefan Santesson
> Subject: Re: QC certificates and Nationality
> 
> Russ Housley wrote:
> >
> > What goes into the QC when a person is a citizen of more than one
> country?
> >
> > Russ
> 
> Hello Russ,
> 
> very good point! The wording in chapter 3.2.1 doesn't fit to the
> definition of the attribute.
> 
> Right now, you have to add the attribute multiple times. I suggest
> that
> we replace the definition by the following:
> 
> countryOfCitizenship  ATTRIBUTE ::= {
>         WITH SYNTAX   SEQUENCE OF PrintableString(SIZE (2))
>                             -- IS 3166 codes only
> 
>         ID            id-at-countryOfCitizenship }
> 
> countryOfResidence    ATTRIBUTE ::= {
>         WITH SYNTAX   SEQUENCE OF PrintableString(SIZE (2))
>                             -- IS 3166 codes only
> 
>         ID            id-at-countryOfResidence }
> 
> 
> Best regards - Petra
--------------C22A23579330612FB0B47FAE
Content-Type: text/x-vcard; charset=us-ascii;
 name="barzin.vcf"
Content-Transfer-Encoding: 7bit
Content-Description: Card for Petra Barzin (Gloeckner)
Content-Disposition: attachment;
 filename="barzin.vcf"

begin:vcard 
n:Barzin;Petra
tel;fax: (+49) 6151/82 89 7 - 26
tel;work:(+49) 6151/82 89 7 - 30
x-mozilla-html:FALSE
url:www.secude.com
org:<hr size=1><p align=right><b><font color=green>SECUDE</font></b> <i>Sicherheitstechnologie<br>Informationssysteme GmbH</i>
adr:;;Landwehrstr. 50a;Darmstadt;;D-64293;Germany
version:2.1
email;internet:[email-masked]
fn:Petra Barzin
end:vcard

--------------C22A23579330612FB0B47FAE--

--------------msAA155E49984B012B5EE4A4B4
Content-Type: application/x-pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature

--------------msAA155E49984B012B5EE4A4B4--

Date: Tue, 2 Nov 1999 12:26:11 -0500 (EST)
From: "David M. Balenson" <[email-masked]>
To: [email-masked]
Subject: ANNOUNCE: ISOC Netw. & Distr. Sys. Security Symp. (NDSS 2000)

                  R E G I S T E R   N O W ! !

THE INTERNET SOCIETY'S
Year 2000 NETWORK AND DISTRIBUTED SYSTEM SECURITY (NDSS) SYMPOSIUM
February 2-4, 2000
Catamaran Resort Hotel, San Diego, California
General Chair:   Steve Welke, Trusted Computer Solutions
Program Chairs:  Gene Tsudik, USC/Information Sciences Institute
		 Avi Rubin, AT&T Labs - Research

ONLINE INFORMATION AND REGISTRATION:  http://www.isoc.org/ndss2000
EARLY REGISTRATION DISCOUNT DEADLINE:  January 6, 2000

The 7th annual NDSS Symposium brings together researchers,
implementers, and users of network and distributed system security
technologies to discuss today's important security issues and
challenges.  The Symposium provides a mix of technical papers and
panel presentations that describe promising new approaches to
security problems that are practical and, to the extent possible,
have been implemented.  NDSS fosters the exchange of technical
information and encourages the Internet community to deploy available
security technologies and develop new solutions to unsolved problems.

KEYNOTE SPEAKER: Gene Spafford, Professor of Computer Sciences at
Purdue University, an expert in information security, computer crime
investigation and information ethics.  Spaf (as he is known to his
friends, colleagues, and students) is director of the Purdue CERIAS
(Center for Education and Research in Information Assurance and
Security), and was the founder and director of the (now superseded)
COAST Laboratory. 

THIS YEAR'S TOPICS INCLUDE:
- Automated Detection of Buffer Overrun Vulnerabilities
- User-Level Infrastructure for System Call Interposition
- Optimized Group Rekey for Group Communication Systems
- IPSec-based Host Architecture for Secure  Internet Multicast
- The Economics of Security
- Automatic Generation of Security Protocols
- Security Protocols for SPKI-based Delegation Systems
- Secure Border Gateway Protocol (S-BGP)
- Analysis of a Fair Exchange Protocol
- Secure Password-Based Protocols for TLS
- Chameleon Signatures
- Lightweight Tool for Detecting Web Server Attacks
- Adaptive and Agile Applications Using Intrusion Detection
- Secure Virtual Enclaves
- Encrypted rlogin Connections Created With Kerberos IV
- Accountability and Control of Process Creation in Metasystems
- Red Teaming and Network Security

PRE-CONFERENCE TECHNICAL TUTORIALS:
- Network Security Protocol Standards, Dr. Stephen T. Kent
- Deployed and Emerging Security Systems for the Internet, Dr. Radia
  Perlman and Charlie Kaufman
- Mobile Code Security and Java 2 Architecture, Dr. Gary McGraw
- Cryptography 101, Dr. Aviel D. Rubin
- Public Key Infrastructure - The Truth and How to Find It, Dr. Daniel
  E. Geer, Jr.
- Intrusion Detection Research, Instructor TBD

FOR MORE INFORMATION contact the Internet Society:
  Internet Society, 11150 Sunset Hills Road, Reston, VA, 20190 USA
  Phone: +1-703-326-9880         Fax: +1-703-326-9881
  E-mail: [email-masked]   URL: http://www.isoc.org/ndss2000/

SPONSORSHIP OPPORTUNITIES AVAILABLE!  Take advantage of this high
visibility event.  Contact Carla Rosenfeld at the Internet Society
at +1-703-326-9880 or send e-mail to [email-masked].

THE INTERNET SOCIETY is a non-governmental organization for global
cooperation and coordination for the Internet and its
internetworking technologies and applications.

From: [email-masked]
To: Tony Bartoletti <[email-masked]>
cc: "Bob Jueneman" <[email-masked]>, [email-masked], [email-masked]
Date: Tue, 2 Nov 1999 12:23:06 -0500
Subject: Re: NR, redux, again.

(snip)
All,

I think we have long agreed that a single NR-bit is of very limited
utility in conveying the range of qualities we may need to assert in
non-repudiation.  (Ed Gerck's taxonomy and Tom Gindin's codification
are certainly a solid representation of this range.)  In particular,
as Bob reminds us, there is no a-priori reason to assume that NR is
strictly (or even best) the job of the CA.

As a exercise, it may be useful to imagine that you are going to set
yourself up as an "Full-Serve Digital NR Service" but you are NOT a CA.
Of course, you will be involved with digital documents, signatures,
certificates, independent time-stamps, and countless other concerns.
Now the question to ask is "What, if anything, would you want a given
certificate's NR-bit to signify?"  Of what utility is it to you?

Being a full NR service, I imagine you will certainly be archiving
relevant objects as a matter of course, so do you care if the CA is
providing (redundant) long-term storage?  I doubt so.  Hence the
association of cert NR-bit with cert "lifetime" is misplaced.

[Tom Gindin]   The CA is the logical candidate to provide long-term storage
for CRL's in those cases where NR is supported.  Because a revocation may
carry a claim about "invalidityDate", the NR service cannot be sure when it
has sufficient evidence that the subject of the certificate for the signing
key pair will not claim that the signature was invalid because of key
compromise - simply having a CRL dated later than the signature is not
enough.  However, this is not an issue with certificate lifetime.  I know
of no other long-term storage that any NR service can expect from the CA.

I can understand why some folks (CAs) would like to limit the NR-bit
to such a simple notion.  It is "do-able", and they are under pressure
to "do NR" from some quarters.

[Tom Gindin]   CRL archiving is all the CA needs to do to support NR.  That
does not mean that it is all that must be done for NR.

Comments?

___tony___

Tony Bartoletti                                             LL
IOWA Center                                              LL LL
Lawrence Livermore National Laboratory                LL LL LL
PO Box 808, L - 089                                   LL LL LL
Livermore, CA 94551-9900                              LL LL LLLLLLLL
phone: 925-422-3881   fax: 925-423-8081               LL LLLLLLLL
email: [email-masked]                                   LLLLLLLL

From: "Miklos, Sue A." <[email-masked]>
To: "'Petra Barzin (Gloeckner)'" <[email-masked]>, Russ Housley <[email-masked]>
Cc: [email-masked], "'SEIS-List'" <[email-masked]>, Stefan Santesson <[email-masked]>
Subject: RE: QC certificates and Nationality
Date: Tue, 2 Nov 1999 09:21:35 -0500 

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01BF253D.9601E4C4
Content-Type: text/plain;
	charset="iso-8859-1"

All, 

I would like to request the attribute that represents a subject's
nationality be structured so that dual citizenship is allowed (default
Multivalued, which I believe is supported by countryOfCitizenship and, that
this attribute be populated with the ISO-3166-1 (trigraph) if that is
consistent with the domain using this piece of information.

I have requirements for both.  That is, I have a requirement for an
attribute that can indicate a subject is a citizen of both Country A and
Country B (country of domicile is not relevant at this point) and, that the
citizenship be indicated with a trigraph (USA, CAN, NZL, etc.)

Regards,
Sandi Miklos

-----Original Message-----
From: Petra Barzin (Gloeckner) [mailto:[email-masked]]
Sent: Tuesday, November 02, 1999 4:32 AM
To: Russ Housley
Cc: [email-masked]; 'SEIS-List'; Stefan Santesson
Subject: Re: QC certificates and Nationality

Russ Housley wrote:
> 
> What goes into the QC when a person is a citizen of more than one country?
> 
> Russ

Hello Russ,

very good point! The wording in chapter 3.2.1 doesn't fit to the 
definition of the attribute.

Right now, you have to add the attribute multiple times. I suggest that
we replace the definition by the following:

countryOfCitizenship  ATTRIBUTE ::= {
	WITH SYNTAX   SEQUENCE OF PrintableString(SIZE (2)) 
					-- IS 3166 codes only
	ID            id-at-countryOfCitizenship }

countryOfResidence    ATTRIBUTE ::= {
	WITH SYNTAX   SEQUENCE OF PrintableString(SIZE (2)) 
					-- IS 3166 codes only
	ID            id-at-countryOfResidence }

Best regards - Petra

------_=_NextPart_001_01BF253D.9601E4C4
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Diso-8859-1">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2232.0">
<TITLE>RE: QC certificates and Nationality</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=3D2>All, </FONT>
</P>

<P><FONT SIZE=3D2>I would like to request the attribute that represents =
a subject's nationality be structured so that dual citizenship is =
allowed (default Multivalued, which I believe is supported by =
countryOfCitizenship and, that this attribute be populated with the =
ISO-3166-1 (trigraph) if that is consistent with the domain using this =
piece of information.</FONT></P>

<P><FONT SIZE=3D2>I have requirements for both.&nbsp; That is, I have a =
requirement for an attribute that can indicate a subject is a citizen =
of both Country A and Country B (country of domicile is not relevant at =
this point) and, that the citizenship be indicated with a trigraph =
(USA, CAN, NZL, etc.)</FONT></P>

<P><FONT SIZE=3D2>Regards,</FONT>
<BR><FONT SIZE=3D2>Sandi Miklos</FONT>
</P>

<P><FONT SIZE=3D2>-----Original Message-----</FONT>
<BR><FONT SIZE=3D2>From: Petra Barzin (Gloeckner) [<A =
HREF=3D"mailto:[email-masked]">mailto:[email-masked]</A>]</FONT>
<BR><FONT SIZE=3D2>Sent: Tuesday, November 02, 1999 4:32 AM</FONT>
<BR><FONT SIZE=3D2>To: Russ Housley</FONT>
<BR><FONT SIZE=3D2>Cc: [email-masked]; 'SEIS-List'; Stefan =
Santesson</FONT>
<BR><FONT SIZE=3D2>Subject: Re: QC certificates and Nationality</FONT>
</P>
<BR>

<P><FONT SIZE=3D2>Russ Housley wrote:</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; What goes into the QC when a person is a =
citizen of more than one country?</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; Russ</FONT>
</P>

<P><FONT SIZE=3D2>Hello Russ,</FONT>
</P>

<P><FONT SIZE=3D2>very good point! The wording in chapter 3.2.1 doesn't =
fit to the </FONT>
<BR><FONT SIZE=3D2>definition of the attribute.</FONT>
</P>

<P><FONT SIZE=3D2>Right now, you have to add the attribute multiple =
times. I suggest that</FONT>
<BR><FONT SIZE=3D2>we replace the definition by the following:</FONT>
</P>

<P><FONT SIZE=3D2>countryOfCitizenship&nbsp; ATTRIBUTE ::=3D {</FONT>
<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT SIZE=3D2>WITH =
SYNTAX&nbsp;&nbsp; SEQUENCE OF PrintableString(SIZE (2)) </FONT>
<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; &nbsp; =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT SIZE=3D2>-- IS 3166 =
codes only</FONT></P>

<P>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT =
SIZE=3D2>ID&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&=
nbsp; id-at-countryOfCitizenship }</FONT>
</P>

<P><FONT SIZE=3D2>countryOfResidence&nbsp;&nbsp;&nbsp; ATTRIBUTE ::=3D =
{</FONT>
<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT SIZE=3D2>WITH =
SYNTAX&nbsp;&nbsp; SEQUENCE OF PrintableString(SIZE (2)) </FONT>
<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; &nbsp; =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT SIZE=3D2>-- IS 3166 =
codes only</FONT></P>

<P>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT =
SIZE=3D2>ID&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&=
nbsp; id-at-countryOfResidence }</FONT>
<BR><FONT SIZE=3D2>&nbsp;</FONT>
</P>

<P><FONT SIZE=3D2>Best regards - Petra</FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01BF253D.9601E4C4--

From: [email-masked]
To: [email-masked], [email-masked]
Cc: [email-masked], [email-masked], [email-masked]
Subject: RE: QC certificates and Nationality
Date: Tue, 2 Nov 1999 08:39:05 -0500 

I would like to offer the following observation.

Since an ATTRIBUTE is multi-valued by default, there is nothing wrong with
countryOfCitizenship below. The problem seems to be that Name is comprised
of single-valued attribute (i.e., AttributeTypeAndValue), not multi-valued
attributes (i.e., Attribute).

Unfortunately, I do not have a simple solution. I am not comfortable
suggesting Name be changed.

Frank

-----Original Message-----
From: Petra Barzin (Gloeckner) [mailto:[email-masked]]
Sent: Tuesday, November 02, 1999 4:32 AM
To: Russ Housley
Cc: [email-masked]; 'SEIS-List'; Stefan Santesson
Subject: Re: QC certificates and Nationality

Russ Housley wrote:
> 
> What goes into the QC when a person is a citizen of more than one country?
> 
> Russ

Hello Russ,

very good point! The wording in chapter 3.2.1 doesn't fit to the 
definition of the attribute.

Right now, you have to add the attribute multiple times. I suggest that
we replace the definition by the following:

countryOfCitizenship  ATTRIBUTE ::= {
	WITH SYNTAX   SEQUENCE OF PrintableString(SIZE (2)) 
					-- IS 3166 codes only
	ID            id-at-countryOfCitizenship }

countryOfResidence    ATTRIBUTE ::= {
	WITH SYNTAX   SEQUENCE OF PrintableString(SIZE (2)) 
					-- IS 3166 codes only
	ID            id-at-countryOfResidence }

Best regards - Petra

Date: Tue, 02 Nov 1999 10:31:39 +0100
From: "Petra Barzin (Gloeckner)" <[email-masked]>
To: Russ Housley <[email-masked]>
CC: [email-masked], "'SEIS-List'" <[email-masked]>, Stefan Santesson <[email-masked]>
Subject: Re: QC certificates and Nationality

This is a cryptographically signed message in MIME format.

--------------ms84753ED393EB948AD194E8F1
Content-Type: multipart/mixed;
 boundary="------------3F67062FBC2AFD569FF1791E"

This is a multi-part message in MIME format.
--------------3F67062FBC2AFD569FF1791E
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Russ Housley wrote:
> 
> What goes into the QC when a person is a citizen of more than one country?
> 
> Russ

Hello Russ,

very good point! The wording in chapter 3.2.1 doesn't fit to the 
definition of the attribute.

Right now, you have to add the attribute multiple times. I suggest that
we replace the definition by the following:

countryOfCitizenship  ATTRIBUTE ::= {
	WITH SYNTAX   SEQUENCE OF PrintableString(SIZE (2)) 
					-- IS 3166 codes only
	ID            id-at-countryOfCitizenship }

countryOfResidence    ATTRIBUTE ::= {
	WITH SYNTAX   SEQUENCE OF PrintableString(SIZE (2)) 
					-- IS 3166 codes only
	ID            id-at-countryOfResidence }

Best regards - Petra
--------------3F67062FBC2AFD569FF1791E
Content-Type: text/x-vcard; charset=us-ascii;
 name="barzin.vcf"
Content-Transfer-Encoding: 7bit
Content-Description: Card for Petra Barzin (Gloeckner)
Content-Disposition: attachment;
 filename="barzin.vcf"

begin:vcard 
n:Barzin;Petra
tel;fax: (+49) 6151/82 89 7 - 26
tel;work:(+49) 6151/82 89 7 - 30
x-mozilla-html:FALSE
url:www.secude.com
org:<hr size=1><p align=right><b><font color=green>SECUDE</font></b> <i>Sicherheitstechnologie<br>Informationssysteme GmbH</i>
adr:;;Landwehrstr. 50a;Darmstadt;;D-64293;Germany
version:2.1
email;internet:[email-masked]
fn:Petra Barzin
end:vcard

--------------3F67062FBC2AFD569FF1791E--

--------------ms84753ED393EB948AD194E8F1
Content-Type: application/x-pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature

--------------ms84753ED393EB948AD194E8F1--

Date: Tue, 02 Nov 1999 10:50:28 +0800
From: "Xiong Shao Jun" <[email-masked]>
Organization: China Merchants Bank
To: [email-masked]
Subject: Re: directory entry with NULL DN

Thanks for your responses. I think I may have to development some
non-standard
way to solve the problem.

Xiong Shaojun
China Merchants Bank

Xiong Shao Jun wrote:

> Hi, there. I posted a mail a few days ago, but received no reply.
> I have some questions about rfc2587. If a PKI subject has null
> DN in certificate, how can it have an entry in LDAP?
>
> Thanx in advance.
>
> Xiong Shaojun
> China Merchants Bank

From: "Amit Kapoor" <[email-masked]>
To: "PKIX" <[email-masked]>
Subject: String representation of GeneralName
Date: Mon, 1 Nov 1999 14:34:12 -0800
Importance: Normal

This is a multi-part message in MIME format.

------=_NextPart_000_001E_01BF2476.29A7B1E0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit

	We have written a draft to document a string
	representation of GeneralName.  We have submitted
	the draft to be published, but in case people need
	to access it earlier, try:

	http://www.trustpoint.com/draft-generalname.txt

	Our thinking is to merge this with the next revision
	of RFC2459.

	cheers-

Amit

-----------------------------------------------------
Certificate Authority: http://www.smeme.com
CA root : http://www.smeme.com/faq_operational.html#16
-----------------------------------------------------
 
------=_NextPart_000_001E_01BF2476.29A7B1E0
Content-Type: application/x-pkcs7-signature;
	name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment;
	filename="smime.p7s"

------=_NextPart_000_001E_01BF2476.29A7B1E0--

Date: Mon, 01 Nov 1999 11:53:42 -0800
From: Ed Gerck <[email-masked]>
To: Sean Turner <[email-masked]>
CC: Alfred Arsenault <[email-masked]>, IETF-PXIX <[email-masked]>
Subject: Re: lifetime versus NR, Re: Comments on the PKIX Roadmap

Sean Turner wrote:

> We'll update the NR discussion in the draft roadmap, but could you enumerate your other
> concerns?  I think most of the ones I've seen so far dealt specifically with the NR bit
> discussion.

The NR discussion involved not only the question of multiple NR meanings, but also the
ordering of NR meanings in "strength", the encoding of NR meanings in keyUsage bits
and/or in policy extensions, the independence/dependence of NR upon CAs, and the
perception that "intent" was not the issue in NR at all -- since NR can make a latter
provably false act to be binding (e.g., a false signature that cannot be distinguished from
a true signature when presented).

Besides, the CRL and the timestamp discussions had also IMO some interesting points
which I missed in the new roadmap.  If this would be useful, I could review them in some
time and present a list -- however, their main dialogue parties could do this much better
and faster, I believe.

Cheers,

Ed Gerck

Date: Mon, 01 Nov 1999 11:15:02 -0800
To: "Bob Jueneman" <[email-masked]>, <[email-masked]>
From: Tony Bartoletti <[email-masked]>
Subject: Re: NR, redux, again.
Cc: <[email-masked]>

At 09:57 AM 11/1/99 -0700, Bob Jueneman wrote:
>>>> Oscar Jacobsson <[email-masked]> 11/01/99 09:46AM >>>
>Bob Jueneman wrote:
>> Then, once it becomes obvious that a single bit is not sufficient
>> to represent all of the different and useful notions that are at
>> least close to NR, we can them make progress in defining those
>> addition bits or states.
>
>Mr. Jueneman, list:
>
>This might well constitute sticking my neck out too far, but since the
>certificatePolicies extension has room for more than one
>PolicyInformation SEQUENCE, could not the PKIX working group try working
>out a set of the most common conceptions of the usage of the NR bit and
>define CertPolicyId's for them that conformant CAs could add to their
>own?
>
>The combination of NR-specific policyIdentifier and presence/absence of
>NR-bit should hopefully be sufficient to represent at least the
>different notions present in the PKIX working group.
>
>Just a thought.
>
>//oscar
>
>Oscar, that's a thought, and one of a number of possibilities.
>
>But one of the most important issues that your suggestion brings up
>is whether NR has anything to do with a CA  AT ALL, and therefore
>whether it is appropriate to represent in a CertPolicyId extension.
>
>Bob

All,

I think we have long agreed that a single NR-bit is of very limited
utility in conveying the range of qualities we may need to assert in
non-repudiation.  (Ed Gerck's taxonomy and Tom Gindin's codification
are certainly a solid representation of this range.)  In particular,
as Bob reminds us, there is no a-priori reason to assume that NR is
strictly (or even best) the job of the CA.

As a exercise, it may be useful to imagine that you are going to set
yourself up as an "Full-Serve Digital NR Service" but you are NOT a CA.
Of course, you will be involved with digital documents, signatures,
certificates, independent time-stamps, and countless other concerns.
Now the question to ask is "What, if anything, would you want a given
certificate's NR-bit to signify?"  Of what utility is it to you?

Being a full NR service, I imagine you will certainly be archiving
relevant objects as a matter of course, so do you care if the CA is
providing (redundant) long-term storage?  I doubt so.  Hence the
association of cert NR-bit with cert "lifetime" is misplaced.

I can understand why some folks (CAs) would like to limit the NR-bit
to such a simple notion.  It is "do-able", and they are under pressure
to "do NR" from some quarters.

Comments?

___tony___

Tony Bartoletti                                             LL
IOWA Center                                              LL LL
Lawrence Livermore National Laboratory                LL LL LL
PO Box 808, L - 089                                   LL LL LL
Livermore, CA 94551-9900                              LL LL LLLLLLLL
phone: 925-422-3881   fax: 925-423-8081               LL LLLLLLLL
email: [email-masked]                                   LLLLLLLL

Date: Mon, 01 Nov 1999 13:52:10 -0500
From: Sean Turner <[email-masked]>
Organization: IECA, Inc.
To: Ed Gerck <[email-masked]>
CC: Alfred Arsenault <[email-masked]>, IETF-PXIX <[email-masked]>
Subject: Re: lifetime versus NR, Re: Comments on the PKIX Roadmap

Ed Gerck wrote:
...snip

> .
> There are other problems with the new roadmap (see my previous msgs) and problems
> which I did not address either --- and which IMO seriously undermine its usefulness
> to reflect what this WG discussed and what the protocols are for.  Two of its key
> purposes -- and that is why I suggested it should be recalled and redone.  It may be
> that the new PKIX roadmap  "captured the WG's feelings from around mid '98
> timeframe" as Sean Turner has mentioned today in this list -- but, aren't we
> around end '99 timeframe?

We'll update the NR discussion in the draft roadmap, but could you enumerate your other
concerns?  I think most of the ones I've seen so far dealt specifically with the NR bit
discussion.

Cheers,

spt

Date: Mon, 01 Nov 1999 13:48:18 -0500
From: Sean Turner <[email-masked]>
Organization: IECA, Inc.
To: Ed Gerck <[email-masked]>
CC: Bob Jueneman <[email-masked]>, Alfred Arsenault <[email-masked]>, IETF-PXIX <[email-masked]>
Subject: Re: NR, redux, again.

Ed Gerck wrote:
...snip

>
> but, since "once it becomes obvious" may take some time, I think
> that Tom's RFC could provide a useful bridge in the meantime. I
> believe that this was Tom's intention. Which is another reason to
> mention that RFC in the roadmap, as it distills if not the solution at
> least IMO most of the WG's reasonings on the way to a solution [*].
>

The next version of the roadmap will capture this.

spt

Date: Mon, 01 Nov 1999 09:32:29 -0800
From: Ed Gerck <[email-masked]>
To: Bob Jueneman <[email-masked]>
CC: Alfred Arsenault <[email-masked]>, Sean Turner <[email-masked]>, IETF-PXIX <[email-masked]>
Subject: Re: NR, redux, again.

Bob Jueneman wrote:

> I agree with Ed that there have been a multiplicity of meanings
> proposed for the NR bit, and as yet no clear consensus.

Thank you for making my words clearer. The first WG consensus
was that setting the NR-bit is neither necessary nor sufficient to
define the provision of NR services. From this first consensus
emerged a multiplicity of meanings, for which there was no clear
consensus -- but it was recognized that the solution does not have
to be either/or (i.e., we could have two, three or more aceptable and
properly discriminated NR meanings).

The problem is to enumerate these meanings in a order relation
of "strength" and to map them to on/off states of bits.

There are at present two enumerations of these NR meanings,
and how they could be mapped to the states of on/off bits
in the keyUsage byte. The approach by Tom Ginding with a
proposed RFC and two NR states defined by the NR bit, and
 my own enumeration with four states of DS/NR defined by four
states of the DS/NR bits.

These efforts should be mentioned in the roadmap, at least as
"work in progress" -- caused by the first consensus.

The second WG consensus which the roadmap failed to
mention was that the NR definition MUST be changed, as Bob says:

> Yet is it clear, I believe, that this matter simply MUST be resolved,
> one way or the other (or the other, or the other).

I also agree with Bob that just one bit is not enough:

> Then, once it becomes obvious that a single bit is not sufficient
> to represent all of the different and useful notions that are at
> least close to NR, we can them make progress in defining those
> addition bits or states.

but, since "once it becomes obvious" may take some time, I think
that Tom's RFC could provide a useful bridge in the meantime. I
believe that this was Tom's intention. Which is another reason to
mention that RFC in the roadmap, as it distills if not the solution at
least IMO most of the WG's reasonings on the way to a solution [*].

Cheers,

Ed Gerck

[*] As commented in the book "Hare Brain, Tortoise Mind" by Guy
Claxton, the NR issue exemplifies the need for the Hare Brain in us to
have an RFC that can be used while the Tortoise Mind in us continues
to work on making progress towards a more comprehensive solution.

Date: Mon, 01 Nov 1999 18:16:50 +0100
From: Oscar Jacobsson <[email-masked]>
Organization: Celo Communications AB
To: Bob Jueneman <[email-masked]>
CC: [email-masked]
Subject: Re: NR, redux, again.

This is a cryptographically signed message in MIME format.

--------------ms6C6041554D2FA7F5AEAB1D34
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Bob Jueneman wrote:
> Oscar, that's a thought, and one of a number of possibilities.
> 
> But one of the most important issues that your suggestion brings up
> is whether NR has anything to do with a CA  AT ALL, and therefore
> whether it is appropriate to represent in a CertPolicyId extension.

True.

I am, however, regretfully ignorant regarding the requirements existing
and emerging digital signature legislation might set on the presence or
absence of keyUsage bits in end-entity certificates. There may, for all
I know, exist Certification Authorities that are legally bound to set,
and thus applications legally bound to interpret, the non-repudiation
bit in a certain fashion.

//oscar
--------------ms6C6041554D2FA7F5AEAB1D34
Content-Type: application/x-pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature

--------------ms6C6041554D2FA7F5AEAB1D34--

From: "Miklos, Sue A." <[email-masked]>
To: "'Sean Turner'" <[email-masked]>, PKIX <[email-masked]>
Subject: RE: Comments on draft-ietf-pkix-ldap-v3-01.txt
Date: Mon, 1 Nov 1999 12:08:22 -0500 

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01BF248B.B46D0662
Content-Type: text/plain;
	charset="iso-8859-1"

May i suggest:

attributeAuthorityRevocationList ATTRIBUTE ::= {
WITH SYNTAX CertificateList
EQUALITY MATCHING RULE certificationListExactMatch
ID id-at-attributeAuthorityRevocationList }

for the attr.cert revocation list

and

pmiAA OBJECT-CLASS ::= {
-- a PMI AA
SUBCLASS OF {top}
KIND auxiliary
MAY CONTAIN {aACertificate |
attributeCertificateRevocationList |
attributeAuthorityRevocationList}
ID id-oc-pmiAA
}

for the attr.auth's object class?

------_=_NextPart_001_01BF248B.B46D0662
Content-Type: text/html;
	charset="iso-8859-1"

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1">
<META NAME="Generator" CONTENT="MS Exchange Server version 5.5.2232.0">
<TITLE>RE: Comments on draft-ietf-pkix-ldap-v3-01.txt</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=2>May i suggest:</FONT>
</P>

<P><FONT SIZE=2>attributeAuthorityRevocationList ATTRIBUTE ::= {</FONT>
<BR><FONT SIZE=2>WITH SYNTAX CertificateList</FONT>
<BR><FONT SIZE=2>EQUALITY MATCHING RULE certificationListExactMatch</FONT>
<BR><FONT SIZE=2>ID id-at-attributeAuthorityRevocationList }</FONT>
</P>
<BR>

<P><FONT SIZE=2>for the attr.cert revocation list</FONT>
</P>

<P><FONT SIZE=2>and</FONT>
</P>

<P><FONT SIZE=2>pmiAA OBJECT-CLASS ::= {</FONT>
<BR><FONT SIZE=2>-- a PMI AA</FONT>
<BR><FONT SIZE=2>SUBCLASS OF {top}</FONT>
<BR><FONT SIZE=2>KIND auxiliary</FONT>
<BR><FONT SIZE=2>MAY CONTAIN {aACertificate |</FONT>
<BR><FONT SIZE=2>attributeCertificateRevocationList |</FONT>
<BR><FONT SIZE=2>attributeAuthorityRevocationList}</FONT>
<BR><FONT SIZE=2>ID id-oc-pmiAA</FONT>
<BR><FONT SIZE=2>}</FONT>
</P>

<P><FONT SIZE=2>for the attr.auth's object class?</FONT>
</P>
<BR>

</BODY>
</HTML>
------_=_NextPart_001_01BF248B.B46D0662--

Date: Mon, 01 Nov 1999 09:57:12 -0700
From: "Bob Jueneman" <[email-masked]>
To: <[email-masked]>
Cc: <[email-masked]>
Subject: Re: NR, redux, again.

>>> Oscar Jacobsson <[email-masked]> 11/01/99 09:46AM >>>
Bob Jueneman wrote:
> Then, once it becomes obvious that a single bit is not sufficient
> to represent all of the different and useful notions that are at
> least close to NR, we can them make progress in defining those
> addition bits or states.

Mr. Jueneman, list:

This might well constitute sticking my neck out too far, but since the
certificatePolicies extension has room for more than one
PolicyInformation SEQUENCE, could not the PKIX working group try working
out a set of the most common conceptions of the usage of the NR bit and
define CertPolicyId's for them that conformant CAs could add to their
own?

The combination of NR-specific policyIdentifier and presence/absence of
NR-bit should hopefully be sufficient to represent at least the
different notions present in the PKIX working group.

Just a thought.

//oscar

Oscar, that's a thought, and one of a number of possibilities.

But one of the most important issues that your suggestion brings up
is whether NR has anything to do with a CA  AT ALL, and therefore
whether it is appropriate to represent in a CertPolicyId extension.

Bob

Date: Mon, 01 Nov 1999 17:46:00 +0100
From: Oscar Jacobsson <[email-masked]>
Organization: Celo Communications AB
To: Bob Jueneman <[email-masked]>
CC: [email-masked]
Subject: Re: NR, redux, again.

This is a cryptographically signed message in MIME format.

--------------ms64B73D047A0E9FB74982D396
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Bob Jueneman wrote:
> Then, once it becomes obvious that a single bit is not sufficient
> to represent all of the different and useful notions that are at
> least close to NR, we can them make progress in defining those
> addition bits or states.

Mr. Jueneman, list:

This might well constitute sticking my neck out too far, but since the
certificatePolicies extension has room for more than one
PolicyInformation SEQUENCE, could not the PKIX working group try working
out a set of the most common conceptions of the usage of the NR bit and
define CertPolicyId's for them that conformant CAs could add to their
own?

The combination of NR-specific policyIdentifier and presence/absence of
NR-bit should hopefully be sufficient to represent at least the
different notions present in the PKIX working group.

Just a thought.

//oscar
--------------ms64B73D047A0E9FB74982D396
Content-Type: application/x-pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature

--------------ms64B73D047A0E9FB74982D396--

Date: Mon, 01 Nov 1999 09:25:10 -0700
From: "Bob Jueneman" <[email-masked]>
To: <[email-masked]>, <[email-masked]>
Cc: <[email-masked]>, <[email-masked]>
Subject: NR, redux, again.

I agree with Ed that there have been a multiplicity of meanings 
proposed for the NR bit, and as yet no clear consensus. And that
despite the fact that the decedent horse has been well and
truly flogged.

Yet is it clear, I believe, that this matter simply MUST be resolved,
one way or the other (or the other, or the other).  Not everyone 
is going to be happy with the outcome, in all probability, but
if we can at least define the rules of the road, both subscribers
and relying parties will know whether to accept or reject a 
certificate that contains the NR bit.

The Washington meeting offers a fortuitous opportunity
to address this issue, in that the ABA Information Security committee
will have been meeting Monday - Wednesday, and an informal 
joint meeting has been proposed for Thursday.

I'm not certain what the agenda for that meeting is supposed to be --
I expect it will probably revolve around the work the ISC has been doing to 
define PKI evaluation guidelines -- but it would be a shame if we didn't
get the technologists and the attorneys together and try to hammer
out some consensus, even if it takes until midnight.

Then, once it becomes obvious that a single bit is not sufficient
to represent all of the different and useful notions that are at
least close to NR, we can them make progress in defining those
addition bits or states.

Bob

>>> Ed Gerck <[email-masked]> 10/31/99 01:59AM >>>

Alfred Arsenault wrote:

> Ed,
>
>         What was the "consensus" of this WG on the meaning of
> "non-repudiation"?

Wading through the messages in the archives it is possible to see that this
WG reached clear consensus on several NR items. For example, that NR is
not simply the setting of a bit -- in fact, this WG's  *unanimity* (!!) on NR was
that setting the NR-bit is neither necessary nor sufficient to define the
provision of NR services.

Based on this 100% consensual understanding,  this WG considered various
possibilities for defining the provision of NR services in a technical protocol,
and several clearly distinct modes of NR emerged -- I counted four main modes
(see archives).  Some of these NR modes were detailed in an effort by Tom Gindin
...that  is not even  *cited* in the roadmap .... with a proposed RFC... but which
was nonetheless extensively discussed in this WG and is archived at the IETF.
Can we NR that RFC? ;-))

Thus, reading the roadmap I felt a warp effect --  how could the roadmap ignore
these points of consensus and actions including a proposed RFC and, instead,
come up with an equivalence between NR and lifetime which was not discussed
at all? And, which is 100% redundant with the notion of lifetime itself -- after all,
if we want to signal a short lifetime there is a very well defined field for this in
PKIX that has nothing to do with NR.  Besides, the roadmap confused
"authenticated connection" (which authentication is ephemeral by definition and
lasts as long as the connection itself) with "signed object" (a certificate) which
can last much longer than even its signature lifetime (when providing support
for signature verification as in... NR ).

There are other problems with the new roadmap (see my previous msgs) and problems
which I did not address either --- and which IMO seriously undermine its usefulness
to reflect what this WG discussed and what the protocols are for.  Two of its key
purposes -- and that is why I suggested it should be recalled and redone.  It may be
that the new PKIX roadmap  "captured the WG's feelings from around mid '98
timeframe" as Sean Turner has mentioned today in this list -- but, aren't we
around end '99 timeframe?

Cheers,

Ed Gerck

From: Anders Rundgren <[email-masked]>
To: "[email-masked]" <[email-masked]>, "'Stefan Santesson'" <[email-masked]>, "'SEIS-List'" <[email-masked]>
Cc: "Magnus (RSA)" <[email-masked]>
Subject: RE: QC comparisons are DEADLY serious!
Date: Mon, 1 Nov 1999 11:23:38 +0100

Stefan,
Comments in line

>What you describe is another issue. Comparing the subjects name against an
>access control database may be a desired function. 

Can't say that I fully understand the value of unique identities in digital certificates if they
cannot be used by computers.

<snip>

>It should also be clear that it is NOT a function of the QC profile to
>guarantee that two certificates for the same person will be considered to
>match the same entity in an access control database. This must be resolved
>by other means.

I noted that QC "bans" such use which was the whole reason for bringing this up.

May I suggest an extension to the QC draft that specifically addresses this issue?

Slight puke-warning!

As the dnQualifier seems to be reserved for a particular purpose and also have
an arbitrary syntax it seems that dnQualifier is not a good candidate for access-control.

Therefore I would like to see a new "subject item" named something like staticUniqueIdentity that if
defined in a certificate, indicates that the CA indeed has the capability to (long-term) keep track
of its subscribers.   Some preliminary rules to support this:

16 decimal digits.  No more, no less.   Like VISA.  Why? to allow verbal communication of
 "digital identity" with ease.  Compatible with current systems after slight "translations".  16 digits
is enough for a 100-billion terrestrial population (Yuck!)  for thousands of years.  Interoperability is IMO
more important than "style" which is the reason for this admittedly rigid specification.

The staticUniqueIdentity is guaranteed to be unique for a certain CA

If staticUniqueIdentity is defined, other attributes and names are only of informational
purposes (for human RP's) and should NOT be used to create a unique electronic identity.
This allows a CA to manufacture certificates of different "weight" without screwing up identity.

>But I promise I will bring this up in Washington to check others view.

Thanx!

/Anders

From: "Andy Dowling" <[email-masked]>
To: "Stephen Farrell (Baltimore)" <[email-masked]>
Cc: <[email-masked]>, <[email-masked]>
Subject: AC Pull with multiple profiles
Date: Mon, 1 Nov 1999 09:59:25 -0000

Hi Folks,

it seems that theres an obvious (?) limitation with the pull model when
dealing
with multiple profiles (i.e. a subject owns multiple ACs, according to
certain profiles).

That is, for a subject that owns multiple ACs, how can the server know which
AC to pull
from the AC repository for a given client request? The client *could*
specify a profile for the
server to use in it's LAAP request as a part of client-server exchanges, but
this would make
it qualify as a push model as well...?

If this is a downside to the pull model, then perhaps it could be mentioned
as such in the draft(s).

Cheers,

Andy

-----
Andy Dowling
SSE (A Siemens Company)
Fitzwilliam Court, Leeson Close,
Dublin 2, Ireland

E-Mail:  [email-masked]
Web: http://www.sse.ie
Phone: +353 1 216 2021
Fax:   +353 1 216 2082

Date: Mon, 01 Nov 1999 09:38:12 +0100
To: "Anders Rundgren" <[email-masked]>, <[email-masked]>
From: Stefan Santesson <[email-masked]>
Subject: Re: QC comparisons are DEADLY serious!
Cc: "Magnus (RSA)" <[email-masked]>

Anders,

What you describe is another issue. Comparing the subjects name against an
access control database may be a desired function. 

It should be noted though that in this case it is up to the local policy of
the relying party (and the content of the certificate) to decide if a new
certificate match a specific entity in the database (matching the old
certificate). 

It should also be clear that it is NOT a function of the QC profile to
guarantee that two certificates for the same person will be considered to
match the same entity in an access control database. This must be resolved
by other means.

But I promise I will bring this up in Washington to check others view.

/Stefan 

At 03:20 PM 10/30/99 +0100, Anders Rundgren wrote:
>Stefan, 
>
>I strongly disagree on your conclusions regarding certificate comparisons. 
>Rather, I consider the possibility to compare certificates from a certain 
>issuer and CPS 
>to be a major "quality" property that deserves a section of its own. 
>
>To give an example. If you have a QC issued by a TTP (ID-certificates that 
>will only be used within the issuer's own domain are pretty uninteresting)
and 
>your bank accepts that certificate in conjunction with its Internet-bank it 
>is VERY interesting for BOTH the bank (RP) and for the customer (Subscriber) 
>to know what will happen the day you log in with a renewed certificate. 
>IN ADVANCE. 
>
>So what you describe as a "minor issue" is for some people a FUNDAMENTAL 
>ISSUE that the QC draft IMLHO must address in much more serious way than in 
>V02. 
>
>Anders
>
>
>
>-----Original Message-----
>From: Stefan Santesson <[email-masked]>
>To: Anders Rundgren <[email-masked]>; 'SEIS-List' 
><[email-masked]>; [email-masked] <[email-masked]>
>Date: Friday, October 29, 1999 23:09
>Subject: SEIS: Re: QC certificates MAY CERTAINLY be compared!
>
>
>>--- Message on the SEIS mailing list ([email-masked])
>>
>>Anders,
>>
>>Thank you, I have noticed your comment.
>>
>>The security considerations section contains CONSIDERATIONS for the general
>>case and I still believe in the intent behind this sentence, as a good
>>general guidance to implementations. 
>>
>>Setting up implementations with the intent to compare two qualified
>>certificates to see if they represent the same person IS generally a bad
>>service that shouldn't be performed. Since in the general case, you will
>>have clear risk of misleading results.
>>
>>Well, if you leave the general case and go into speciffic cases such as
>>comparing SEIS certificates within a local region (such as Sweden), then
>>there will allways be cases where some security considerations does not
>>apply (such as this particular one).
>>
>>I think this is a minor issue within the security consideration section
>>which does not affect the implementation of the profile. Shure there are an
>>even better way of expressing the original intent behind that sentence. But
>>on the other hand,  there will allways be a better way of everything.
>>
>>I think the present description is good enough. Can you live with it ?
>>
>>/Stefan
>>
>>At 17:55 1999-10-25 +0100, Anders Rundgren wrote:
>>>Stefan,
>>>I have said it before and I say it again.  The following QC-statement is 
>>>higly doubtful:
>>>
>>>"Comparing two qualified certificates to determine if they represent
>>> the same physical entity may provide misleading results and should
>>> not be performed"
>>>
>>>As you know our famous (?) SEIS-card does indeed allow certificates to
>>>be compared for subject identity.   That is IMO the whole (and only) point 
>>>with *real* ID-cards!
>>>
>>>So this is a statement of the CPS.  Not of the draft.
>>>
>>>
>>>
>>>BTW, why no explicit support for "container ID" (card serial) as most QCs 
>>>will be
>>>put in smart cards?  It was in SEIS already.
>>>
>>>
>>>Anders
>>>
>>>
>>>-----Original Message-----
>>>From: Stefan Santesson <[email-masked]>
>>>To: [email-masked] <[email-masked]>
>>>Date: Monday, October 25, 1999 14:14
>>>Subject: New submitted draft for Qualified Certificates
>>>
>>>
>>>>All,
>>>>
>>>>A new draft for a Qualified Certificates Profile was submitted friday 22.
>>>>
>>>>The new draft can be obtained from:
>>>>http://www.accurata.se/QC/documents/draft-ietf-pkix-qc-02.txt
>>>>
>>>>The QC website has been udated accrodingly:
>>>>http://www.accurata.se/QC/
>>>>
>>>>See also under settled topics to obtain information about major
>>>>considerations since the last draft.
>>>>
>>>>/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
>>>>-------------------------------------------------------------------
>>>> 
>>
>>
>>----------------- SEIS mailing list ([email-masked])
>>Info about this list: http://www.nc-forum.com/seis
>>SEIS Contact: [email-masked]
>>
>>

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