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

["Anders Rundgren" <[e-mail]>]

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





Received: from caesar.udac.se (caesar.udac.se [193.44.79.10]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id XAA08357 for <[e-mail]>; Tue, 30 Nov 1999 23:48:51 -0800 (PST)
Received: from mega (t3o69p44.telia.com [62.20.145.44]) by caesar.udac.se (8.7.3/NetworkC-1) with SMTP id IAA13327; Wed, 1 Dec 1999 08:46:14 +0100
Message-ID: <005401bf3bd8$bd5df790$[e-mail]>
From: "Anders Rundgren" <[e-mail]>
To: "Charles Moore" <[e-mail]>, "'Tony Bartoletti'" <[e-mail]>, "'Stefan Santesson'" <[e-mail]>, <[e-mail]>
Cc: "David P. Kemp" <[e-mail]>
Subject: Re: unqualified topic - not solved yet.
Date: Wed, 1 Dec 1999 08:47:44 -0000
MIME-Version: 1.0
Content-Type: text/plain; charset="windows-1252"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 4.72.3110.5
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by ns.secondary.com id XAA08360

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



Received: from ozspyrusmail.spyrus.com.au (fwuser@[203.46.55.130]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id VAA03494 for <[e-mail]>; Tue, 30 Nov 1999 21:57:25 -0800 (PST)
Message-ID: <917ACEDEAC7DD211A0660080C890305F093ADE@OZSPYRUSMAIL>
From: Charles Moore <[e-mail]>
To: "'Anders Rundgren'" <[e-mail]>, Charles Moore <[e-mail]>, "'Tony Bartoletti'" <[e-mail]>, "'Stefan Santesson'" <[e-mail]>, [e-mail]
Cc: "David P. Kemp" <[e-mail]>
Subject: RE: unqualified topic - not solved yet.
Date: Wed, 1 Dec 1999 16:02:04 +1000 
MIME-Version: 1.0
Content-Type: text/plain; charset="windows-1252"

-----Original Message-----
From: Anders Rundgren [mailto:[e-mail]]
Sent: Wednesday, 1 December 1999 16:36
To: Charles Moore; 'Tony Bartoletti'; 'Stefan Santesson';
[e-mail]
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


Received: from caesar.udac.se (caesar.udac.se [193.44.79.10]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id VAA03052 for <[e-mail]>; Tue, 30 Nov 1999 21:37:08 -0800 (PST)
Received: from mega (t1o69p85.telia.com [62.20.144.85]) by caesar.udac.se (8.7.3/NetworkC-1) with SMTP id GAA07374; Wed, 1 Dec 1999 06:34:23 +0100
Message-ID: <003301bf3bc6$51b038d0$[e-mail]>
From: "Anders Rundgren" <[e-mail]>
To: "Charles Moore" <[e-mail]>, "'Tony Bartoletti'" <[e-mail]>, "'Stefan Santesson'" <[e-mail]>, <[e-mail]>
Cc: "David P. Kemp" <[e-mail]>
Subject: Re: unqualified topic - not solved yet.
Date: Wed, 1 Dec 1999 06:35:52 -0000
MIME-Version: 1.0
Content-Type: text/plain; charset="windows-1252"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 4.72.3110.5
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by ns.secondary.com id VAA03054

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



Received: from caesar.udac.se (caesar.udac.se [193.44.79.10]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id TAA25905 for <[e-mail]>; Tue, 30 Nov 1999 19:59:49 -0800 (PST)
Received: from mega (t1o69p110.telia.com [62.20.144.110]) by caesar.udac.se (8.7.3/NetworkC-1) with SMTP id EAA57427; Wed, 1 Dec 1999 04:57:10 +0100
Message-ID: <002001bf3bb8$bce41a30$[e-mail]>
From: "Anders Rundgren" <[e-mail]>
To: "Denis Pinkas" <[e-mail]>, "Russ Housley" <[e-mail]>, "Tim Polk" <[e-mail]>, <[e-mail]>, "Tony Bartoletti" <[e-mail]>
Subject: Re: Server-signatures: Re: proposed key usaged text -- the final round
Date: Wed, 1 Dec 1999 04:58:39 -0000
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 4.72.3110.5
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by ns.secondary.com id TAA25913

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




Received: from poptop.llnl.gov (poptop.llnl.gov [128.115.18.65]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id SAA19993 for <[e-mail]>; Tue, 30 Nov 1999 18:19:36 -0800 (PST)
Received: from catalyst (catalyst.llnl.gov [128.115.223.61]) by poptop.llnl.gov (8.8.8/LLNL-3.0.2/pop.llnl.gov-5.1) with SMTP id SAA07904; Tue, 30 Nov 1999 18:21:38 -0800 (PST)
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.3 (32)
Date: Tue, 30 Nov 1999 18:21:16 -0800
To: "Anders Rundgren" <[e-mail]>, "Denis Pinkas" <[e-mail]>, "Russ Housley" <[e-mail]>, "Tim Polk" <[e-mail]>, <[e-mail]>
From: Tony Bartoletti <[e-mail]>
Subject: Re: Server-signatures: Re: proposed key usaged text -- the final round
In-Reply-To: <001f01bf3980$267a9c70$[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"

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: [phone]   fax: [phone]               LL LLLLLLLL
email: [e-mail]                                   LLLLLLLL


Received: from ozspyrusmail.spyrus.com.au (fwuser@[203.46.55.130]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id SAA19452 for <[e-mail]>; Tue, 30 Nov 1999 18:12:15 -0800 (PST)
Message-ID: <917ACEDEAC7DD211A0660080C890305F093ADC@OZSPYRUSMAIL>
From: Charles Moore <[e-mail]>
To: "'Tony Bartoletti'" <[e-mail]>, "'Stefan Santesson'" <[e-mail]>, [e-mail]
Cc: "David P. Kemp" <[e-mail]>
Subject: RE: unqualified topic - not solved yet.
Date: Wed, 1 Dec 1999 12:16:34 +1000 
MIME-Version: 1.0
Content-Type: text/plain; charset="windows-1252"

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


Received: from poptop.llnl.gov (poptop.llnl.gov [128.115.18.65]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id RAA18215 for <[e-mail]>; Tue, 30 Nov 1999 17:33:24 -0800 (PST)
Received: from catalyst (catalyst.llnl.gov [128.115.223.61]) by poptop.llnl.gov (8.8.8/LLNL-3.0.2/pop.llnl.gov-5.1) with SMTP id RAA26537; Tue, 30 Nov 1999 17:35:33 -0800 (PST)
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.3 (32)
Date: Tue, 30 Nov 1999 17:35:11 -0800
To: Charles Moore <[e-mail]>, "'Stefan Santesson'" <[e-mail]>, [e-mail]
From: Tony Bartoletti <[e-mail]>
Subject: RE: unqualified topic - not solved yet.
Cc: "David P. Kemp" <[e-mail]>
In-Reply-To: <917ACEDEAC7DD211A0660080C890305F093ADA@OZSPYRUSMAIL>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"

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: [phone]   fax: [phone]               LL LLLLLLLL
email: [e-mail]                                   LLLLLLLL


Received: from ozspyrusmail.spyrus.com.au (fwuser@[203.46.55.130]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id QAA17535 for <[e-mail]>; Tue, 30 Nov 1999 16:48:03 -0800 (PST)
Message-ID: <917ACEDEAC7DD211A0660080C890305F093ADA@OZSPYRUSMAIL>
From: Charles Moore <[e-mail]>
To: "'Stefan Santesson'" <[e-mail]>, Charles Moore <[e-mail]>, [e-mail]
Cc: "David P. Kemp" <[e-mail]>
Subject: RE: unqualified topic - not solved yet.
Date: Wed, 1 Dec 1999 10:52:40 +1000 
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"

comments in line...

-----Original Message-----
From: Stefan Santesson [mailto:[e-mail]]
Sent: Wednesday, 1 December 1999 10:20
To: Charles Moore; [e-mail]
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" <[e-mail]>
>> 
>> 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                <[e-mail]>
Accurata AB                     http://www.accurata.se
Slagthuset                      Tel. [phone]              
211 20  Malmö                   Fax. [phone]              
Sweden                        Mobile [phone]

PGP fingerprint: 89BC 6C79 5B3D 591B 8547  1512 7D11 DBF4 528F 29A0
-------------------------------------------------------------------


Received: from popmail.inbox.se (popmail.inbox.se [193.12.72.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id QAA16951 for <[e-mail]>; Tue, 30 Nov 1999 16:17:04 -0800 (PST)
Received: from stefan2 (accurata.inbox.se [193.12.72.24]) by popmail.inbox.se (8.9.3/8.9.3) with SMTP id BAA29616; Wed, 1 Dec 1999 01:19:21 +0100
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 
Date: Wed, 01 Dec 1999 01:19:54 +0100
To: "Charles Moore" <[e-mail]>, [e-mail]
From: Stefan Santesson <[e-mail]>
Subject: Re: dnQualifier topic - not solved yet.
Cc: "David P. Kemp" <[e-mail]>
In-Reply-To: <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by ns.secondary.com id QAA16952

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" <[e-mail]>
>> 
>> 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                <[e-mail]>
Accurata AB                     http://www.accurata.se
Slagthuset                      Tel. [phone]              
211 20  Malmö                   Fax. [phone]              
Sweden                        Mobile [phone]

PGP fingerprint: 89BC 6C79 5B3D 591B 8547  1512 7D11 DBF4 528F 29A0
-------------------------------------------------------------------


Received: from stingray.missi.ncsc.mil (stingray.missi.ncsc.mil [144.51.50.20]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id PAA16373 for <[e-mail]>; Tue, 30 Nov 1999 15:48:25 -0800 (PST)
Received: from stingray.missi.ncsc.mil (root@localhost) by stingray.missi.ncsc.mil with ESMTP id SAA09476 for <[e-mail]>; Tue, 30 Nov 1999 18:51:18 -0500 (EST)
Received: from missi.ncsc.mil (depot.missi.ncsc.mil [144.51.60.1]) by stingray.missi.ncsc.mil with ESMTP id SAA09472 for <[e-mail]>; Tue, 30 Nov 1999 18:51:17 -0500 (EST)
Received: from ara.missi.ncsc.mil (ara.missi.ncsc.mil [144.51.58.9]) by missi.ncsc.mil (8.8.8/8.8.8) with ESMTP id SAA21102 for <[e-mail]>; Tue, 30 Nov 1999 18:50:31 -0500 (EST)
Received: from ara.missi.ncsc.mil (ara.missi.ncsc.mil [144.51.58.9]) by ara.missi.ncsc.mil (8.9.1b+Sun/8.9.1) with SMTP id SAA18995 for <[e-mail]>; Tue, 30 Nov 1999 18:46:00 -0500 (EST)
Message-Id: <[e-mail]>
Date: Tue, 30 Nov 1999 18:46:00 -0500 (EST)
From: "David P. Kemp" <[e-mail]>
Reply-To: "David P. Kemp" <[e-mail]>
Subject: Re: dnQualifier topic - not solved yet.
To: [e-mail]
MIME-Version: 1.0
Content-Type: TEXT/plain; charset=us-ascii
Content-MD5: B3GtiSM9PZk0CksDnq/KWA==
X-Mailer: dtmail 1.3.0 CDE Version 1.3 SunOS 5.7 sun4u sparc

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




Received: from caladan.verisign.com (caladan.verisign.com [205.180.232.21]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id PAA16098 for <[e-mail]>; Tue, 30 Nov 1999 15:36:06 -0800 (PST)
Received: from postal-gw1.verisign.com (gateway.verisign.com [208.206.241.87]) by caladan.verisign.com (8.9.3/BCH1.7) with ESMTP id PAA01256; Tue, 30 Nov 1999 15:35:31 -0800 (PST)
Received: by postal-gw1.verisign.com with Internet Mail Service (5.5.2650.21) id <X89T0DBB>; Tue, 30 Nov 1999 15:37:22 -0800
Message-ID: <[e-mail]>
From: Alex Deacon <[e-mail]>
To: "'Bill Price'" <[e-mail]>, [e-mail], [e-mail]
Cc: [e-mail]
Subject: RE: Unknown private verisign extension
Date: Tue, 30 Nov 1999 15:37:26 -0800
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain; charset="iso-8859-1"

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:[e-mail]]
Sent: Tuesday, November 23, 1999 2:27 PM
To: [e-mail]; [e-mail]
Cc: [e-mail]
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: [e-mail] [mailto:[e-mail]]
> Sent: Wednesday, November 24, 1999 4:20 AM
> To: [e-mail]
> Cc: [e-mail]
> Subject: Re: Unknown private verisign extension
>
>
> [cc'd to PKIX for comment]
>
> [e-mail] 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.
>


Received: from ozspyrusmail.spyrus.com.au (fwuser@[203.46.55.130]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id LAA13113 for <[e-mail]>; Tue, 30 Nov 1999 11:43:22 -0800 (PST)
Message-ID: <001701bf3b6b$7e73c900$[e-mail]>
From: "Charles Moore" <[e-mail]>
To: <[e-mail]>, "Stefan Santesson" <[e-mail]>
References: <[e-mail]>
Subject: Re: dnQualifier topic - not solved yet.
Date: Wed, 1 Dec 1999 05:45:23 +1000
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 8bit

----- Original Message -----
From: Stefan Santesson <[e-mail]>
To: <[e-mail]>
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                <[e-mail]>
Accurata AB                     http://www.accurata.se
Slagthuset                      Tel. [phone]
211 20  Malmö                   Fax. [phone]
Sweden                        Mobile [phone]

PGP fingerprint: 89BC 6C79 5B3D 591B 8547  1512 7D11 DBF4 528F 29A0
-------------------------------------------------------------------




Received: from dfw-smtpout4.email.verio.net (dfw-smtpout4-ext.email.verio.net [129.250.36.44]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id LAA12326 for <[e-mail]>; Tue, 30 Nov 1999 11:01:17 -0800 (PST)
Received: from dfw-mmp2.email.verio.net ([129.250.38.62]) by dfw-smtpout4.email.verio.net (Netscape Messaging Server 4.05) with ESMTP id FM0YA900.U0R for <[e-mail]>; Tue, 30 Nov 1999 19:03:45 +0000 
Received: from nma.com ([209.21.28.76]) by dfw-mmp2.email.verio.net (Netscape Messaging Server 4.05) with ESMTP id FM0YDD00.DXU; Tue, 30 Nov 1999 19:05:37 +0000 
Message-ID: <[e-mail]>
Date: Tue, 30 Nov 1999 11:03:52 -0800
From: Ed Gerck <[e-mail]>
X-Mailer: Mozilla 4.7 [en]C-CCK-MCD {Sony}  (Win98; I)
X-Accept-Language: en
MIME-Version: 1.0
To: Peter Williams <[e-mail]>, "[e-mail]" <[e-mail]>
Subject: Re: non-repudiation, was Re: proposed key usage text
References: <[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

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




Received: from tholian.securitydynamics.com (tholian.securid.com [204.167.112.129]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id IAA09995 for <[e-mail]>; Tue, 30 Nov 1999 08:33:48 -0800 (PST)
Received: from sdtihq24.securitydynamics.com by tholian.securitydynamics.com via smtpd (for mail.imc.org [208.184.76.43]) with SMTP; 30 Nov 1999 16:34:31 UT
Received: from exna00.securitydynamics.com (exna00.securitydynamics.com [10.2.1.110]) by sdtihq24.securid.com (Pro-8.9.3/Pro-8.9.3) with ESMTP id LAA12805; Tue, 30 Nov 1999 11:35:23 -0500 (EST)
Received: by exna00.securitydynamics.com with Internet Mail Service (5.5.2448.0) id <W2NXADYX>; Tue, 30 Nov 1999 11:36:56 -0500
Message-ID: <[e-mail]>
From: "Linn, John" <[e-mail]>
To: "'Tim Polk'" <[e-mail]>, "Linn, John" <[e-mail]>, "'Russ Housley'" <[e-mail]>, [e-mail]
Subject: RE: proposed key usaged text -- the final round
Date: Tue, 30 Nov 1999 11:42:39 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2448.0)
Content-Type: text/plain; charset="iso-8859-1"

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

-----Original Message-----
From: Tim Polk [mailto:[e-mail]]
Sent: Tuesday, November 30, 1999 9:37 AM
To: Linn, John; 'Russ Housley'; [e-mail]
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 

> 

>



Received: from csmes.ncsl.nist.gov (csmes.ncsl.nist.gov [129.6.54.2]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id GAA08059 for <[e-mail]>; Tue, 30 Nov 1999 06:30:54 -0800 (PST)
Received: from st12.ncsl.nist.gov (st12.ncsl.nist.gov [129.6.54.66]) by csmes.ncsl.nist.gov (8.9.3+Sun/8.6.4jck0) with SMTP id JAA18058; Tue, 30 Nov 1999 09:32:27 -0500 (EST)
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32)
Date: Tue, 30 Nov 1999 09:36:33 -0500
To: "Linn, John" <[e-mail]>, "'Russ Housley'" <[e-mail]>, [e-mail]
From: Tim Polk <[e-mail]>
Subject: RE: proposed key usaged text -- the final round
In-Reply-To: <[e-mail] mics.com>
Mime-Version: 1.0
Content-Type: text/enriched; charset="us-ascii"

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

>

>


Received: from dazzler.ndhm.gtegsc.com (dazzler.ndhm.gtegsc.com [155.95.230.163]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id GAA07541 for <[e-mail]>; Tue, 30 Nov 1999 06:04:50 -0800 (PST)
Received: (from jsaylor@localhost) by dazzler.ndhm.gtegsc.com (8.9.3/8.9.3) id JAA09828; Tue, 30 Nov 1999 09:05:05 -0500 (EST)
Sender: [e-mail]
To: Stefan Santesson <[e-mail]>
Cc: [e-mail]
Subject: Re: dnQualifier topic - not solved yet.
References: <[e-mail]>
Organization: CyberTrust
From: John Saylor <[e-mail]>
Date: 30 Nov 1999 09:05:05 -0500
In-Reply-To: Stefan Santesson's message of "Tue, 30 Nov 1999 13:41:36 +0100"
Message-ID: <[e-mail]>
Lines: 31
User-Agent: Gnus/5.070099 (Pterodactyl Gnus v0.99) XEmacs/21.1 (20 Minutes to Nikko)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii

Hi

>>>>> "SS" == Stefan Santesson <[e-mail]> 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



Received: from popmail.inbox.se (popmail.inbox.se [193.12.72.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id EAA06427 for <[e-mail]>; Tue, 30 Nov 1999 04:38:47 -0800 (PST)
Received: from stefan2 (accurata.inbox.se [193.12.72.24]) by popmail.inbox.se (8.9.3/8.9.3) with SMTP id NAA19198 for <[e-mail]>; Tue, 30 Nov 1999 13:41:11 +0100
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 
Date: Tue, 30 Nov 1999 13:41:36 +0100
To: [e-mail]
From: Stefan Santesson <[e-mail]>
Subject: Re: dnQualifier topic - not solved yet.
In-Reply-To: <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by ns.secondary.com id EAA06429

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                <[e-mail]>
Accurata AB                     http://www.accurata.se
Slagthuset                      Tel. [phone]              
211 20  Malmö                   Fax. [phone]              
Sweden                        Mobile [phone]

PGP fingerprint: 89BC 6C79 5B3D 591B 8547  1512 7D11 DBF4 528F 29A0
-------------------------------------------------------------------


Received: from seine.valicert.com (corporate-gw.valicert.com [63.65.221.2]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id DAA05888 for <[e-mail]>; Tue, 30 Nov 1999 03:52:41 -0800 (PST)
Received: by seine.valicert.com with Internet Mail Service (5.5.2650.21) id <WZF04J2T>; Tue, 30 Nov 1999 03:51:07 -0800
Message-ID: <[e-mail]>
From: Peter Williams <[e-mail]>
To: Ed Gerck <[e-mail]>, "David P. Kemp" <[e-mail]>
Cc: [e-mail]
Subject: RE: non-repudiation, was Re: proposed key usage text
Date: Tue, 30 Nov 1999 03:51:06 -0800
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain; charset="iso-8859-1"

> -----Original Message-----
> From: Ed Gerck [mailto:[e-mail]]
> Sent: Thursday, November 18, 1999 2:12 PM
> To: David P. Kemp
> Cc: [e-mail]
> 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 <[e-mail]>
> > >
> > > 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
> 


Received: from seine.valicert.com (corporate-gw.valicert.com [63.65.221.2]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id CAA01076 for <[e-mail]>; Tue, 30 Nov 1999 02:33:41 -0800 (PST)
Received: by seine.valicert.com with Internet Mail Service (5.5.2650.21) id <WZF04JGL>; Tue, 30 Nov 1999 02:32:06 -0800
Message-ID: <[e-mail]>
From: Peter Williams <[e-mail]>
To: Ed Gerck <[e-mail]>
Cc: [e-mail]
Subject: RE: proposed key usaged text -- the final round
Date: Tue, 30 Nov 1999 02:32:05 -0800
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain; charset="iso-8859-1"

> -----Original Message-----
> From: Ed Gerck [mailto:[e-mail]]
> Sent: Thursday, November 25, 1999 10:01 AM
> Cc: Russ Housley; [e-mail]; [e-mail]
> 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
> 
> 


Received: from ozspyrusmail.spyrus.com.au (fwuser@[203.46.55.130]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id OAA04488 for <[e-mail]>; Mon, 29 Nov 1999 14:43:15 -0800 (PST)
Message-ID: <917ACEDEAC7DD211A0660080C890305F093AD0@OZSPYRUSMAIL>
From: Charles Moore <[e-mail]>
To: "'Anders Rundgren'" <[e-mail]>, Charles Moore <[e-mail]>, [e-mail], Stefan Santesson <[e-mail]>
Subject: RE: dnQualifier topic - not solved yet.
Date: Tue, 30 Nov 1999 08:47:33 +1000
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"

-----Original Message-----
From: Anders Rundgren [mailto:[e-mail]]
Sent: Tuesday, 30 November 1999 8:59
To: Charles Moore; [e-mail]; 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



Received: from caesar.udac.se (caesar.udac.se [193.44.79.10]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id OAA03639 for <[e-mail]>; Mon, 29 Nov 1999 14:00:11 -0800 (PST)
Received: from mega (t4o69p115.telia.com [62.20.145.235]) by caesar.udac.se (8.7.3/NetworkC-1) with SMTP id WAA43401; Mon, 29 Nov 1999 22:57:36 +0100
Message-ID: <004e01bf3abd$5546da80$[e-mail]>
From: "Anders Rundgren" <[e-mail]>
To: "Charles Moore" <[e-mail]>, <[e-mail]>, "Stefan Santesson" <[e-mail]>
Subject: Re: dnQualifier topic - not solved yet.
Date: Mon, 29 Nov 1999 22:59:03 -0000
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 4.72.3110.5
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by ns.secondary.com id OAA03640

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




Received: from tholian.securitydynamics.com (tholian.securid.com [204.167.112.129]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id NAA03205 for <[e-mail]>; Mon, 29 Nov 1999 13:39:51 -0800 (PST)
Received: from sdtihq24.securitydynamics.com by tholian.securitydynamics.com via smtpd (for mail.imc.org [208.184.76.43]) with SMTP; 29 Nov 1999 21:40:30 UT
Received: from exna00.securitydynamics.com (exna00.securitydynamics.com [10.2.1.110]) by sdtihq24.securid.com (Pro-8.9.3/Pro-8.9.3) with ESMTP id QAA16550; Mon, 29 Nov 1999 16:42:08 -0500 (EST)
Received: by exna00.securitydynamics.com with Internet Mail Service (5.5.2448.0) id <W2NW098H>; Mon, 29 Nov 1999 16:43:40 -0500
Message-ID: <[e-mail]>
From: "Linn, John" <[e-mail]>
To: "'Russ Housley'" <[e-mail]>, [e-mail]
Cc: [e-mail]
Subject: RE: proposed key usaged text -- the final round
Date: Mon, 29 Nov 1999 16:49:23 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2448.0)
Content-Type: text/plain; charset="iso-8859-1"

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


Received: from ozspyrusmail.spyrus.com.au (fwuser@[203.46.55.130]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id NAA02811 for <[e-mail]>; Mon, 29 Nov 1999 13:19:41 -0800 (PST)
Message-ID: <000901bf3aaf$c533d720$[e-mail]>
From: "Charles Moore" <[e-mail]>
To: <[e-mail]>, "Stefan Santesson" <[e-mail]>
References: <[e-mail]> <[e-mail]>
Subject: Re: dnQualifier topic - not solved yet.
Date: Tue, 30 Nov 1999 07:21:39 +1000
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 8bit

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 <[e-mail]>
To: <[e-mail]>
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                <[e-mail]>
Accurata AB                     http://www.accurata.se
Slagthuset                      Tel. [phone]
211 20  Malmö                   Fax. [phone]
Sweden                        Mobile [phone]

PGP fingerprint: 89BC 6C79 5B3D 591B 8547  1512 7D11 DBF4 528F 29A0
-------------------------------------------------------------------




Received: from popmail.inbox.se (popmail.inbox.se [193.12.72.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id MAA02069 for <[e-mail]>; Mon, 29 Nov 1999 12:21:37 -0800 (PST)
Received: from stefan2 (accurata.inbox.se [193.12.72.24]) by popmail.inbox.se (8.9.3/8.9.3) with SMTP id VAA07842 for <[e-mail]>; Mon, 29 Nov 1999 21:23:59 +0100
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 
X-Priority: 1 (Highest)
Date: Mon, 29 Nov 1999 21:24:30 +0100
To: [e-mail]
From: Stefan Santesson <[e-mail]>
Subject: dnQualifier topic - not solved yet.
In-Reply-To: <[e-mail]>
References: <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by ns.secondary.com id MAA02070

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                <[e-mail]>
Accurata AB                     http://www.accurata.se
Slagthuset                      Tel. [phone]              
211 20  Malmö                   Fax. [phone]              
Sweden                        Mobile [phone]

PGP fingerprint: 89BC 6C79 5B3D 591B 8547  1512 7D11 DBF4 528F 29A0
-------------------------------------------------------------------


Received: from caesar.udac.se (caesar.udac.se [193.44.79.10]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id AAA00293 for <[e-mail]>; Sun, 28 Nov 1999 00:09:57 -0800 (PST)
Received: from mega (t4o69p119.telia.com [62.20.145.239]) by caesar.udac.se (8.7.3/NetworkC-1) with SMTP id JAA13370; Sun, 28 Nov 1999 09:07:09 +0100
Message-ID: <001f01bf3980$267a9c70$[e-mail]>
From: "Anders Rundgren" <[e-mail]>
To: "Denis Pinkas" <[e-mail]>, "Russ Housley" <[e-mail]>, "Tim Polk" <[e-mail]>, <[e-mail]>
Subject: Server-signatures: Re: proposed key usaged text -- the final round
Date: Sun, 28 Nov 1999 09:08:32 -0000
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 4.72.3110.5
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by ns.secondary.com id AAA00294

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



Received: from csmes.ncsl.nist.gov (csmes.ncsl.nist.gov [129.6.54.2]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id NAA16731 for <[e-mail]>; Fri, 26 Nov 1999 13:28:30 -0800 (PST)
Received: from st12.ncsl.nist.gov (st12.ncsl.nist.gov [129.6.54.66]) by csmes.ncsl.nist.gov (8.9.3+Sun/8.6.4jck0) with SMTP id QAA00537; Fri, 26 Nov 1999 16:29:46 -0500 (EST)
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32)
Date: Fri, 26 Nov 1999 16:22:33 -0500
To: Denis Pinkas <[e-mail]>, Russ Housley <[e-mail]>
From: Tim Polk <[e-mail]>
Subject: Re: proposed key usaged text -- the final round
Cc: [e-mail]
In-Reply-To: <[e-mail]>
References: <[e-mail]>
Mime-Version: 1.0
Content-Type: text/enriched; charset="us-ascii"

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





Received: from csmes.ncsl.nist.gov (csmes.ncsl.nist.gov [129.6.54.2]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id LAA15873 for <[e-mail]>; Fri, 26 Nov 1999 11:20:55 -0800 (PST)
Received: from st12.ncsl.nist.gov (st12.ncsl.nist.gov [129.6.54.66]) by csmes.ncsl.nist.gov (8.6.12/8.6.4jck0) with SMTP id OAA23821; Fri, 26 Nov 1999 14:22:51 -0500
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32)
Date: Fri, 26 Nov 1999 14:27:04 -0500
To: "Aram Perez" <[e-mail]>, [e-mail]
From: Tim Polk <[e-mail]>
Subject: Re: proposed key usaged text -- the final round
Cc: [e-mail]
In-Reply-To: <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"

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! 


Received: from dfw-smtpout3.email.verio.net (dfw-smtpout3-ext.email.verio.net [129.250.36.43]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id JAA15578 for <[e-mail]>; Thu, 25 Nov 1999 09:58:26 -0800 (PST)
Received: from dfw-mmp4.email.verio.net ([129.250.38.64]) by dfw-smtpout3.email.verio.net (Netscape Messaging Server 4.05) with ESMTP id FLRM0M00.THN for <[e-mail]>; Thu, 25 Nov 1999 18:00:22 +0000 
Received: from nma.com ([209.21.28.107]) by dfw-mmp4.email.verio.net (Netscape Messaging Server 4.05) with ESMTP id FLRM0300.6OD; Thu, 25 Nov 1999 18:00:03 +0000 
Message-ID: <[e-mail]>
Date: Thu, 25 Nov 1999 10:01:02 -0800
From: Ed Gerck <[e-mail]>
X-Mailer: Mozilla 4.7 [en]C-CCK-MCD {Sony}  (Win98; I)
X-Accept-Language: en
MIME-Version: 1.0
CC: Russ Housley <[e-mail]>, [e-mail], [e-mail]
Subject: Re: proposed key usaged text -- the final round
References: <[e-mail]> <[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

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




Received: from florida.melco.co.jp (florida.melco.co.jp [192.218.140.46]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id EAA11873 for <[e-mail]>; Thu, 25 Nov 1999 04:23:43 -0800 (PST)
Received: by florida.melco.co.jp (3.7W-florida) id VAA08586; Thu, 25 Nov 1999 21:25:43 +0900 (JST)
Received: by mailgw.melco.co.jp (3.7W-mailgw) id VAA13527; Thu, 25 Nov 1999 21:25:43 +0900 (JST)
Received: by inetgw.melco.co.jp (8.8.8+2.7Wbeta7/3.7W-inetgw) id VAA04283; Thu, 25 Nov 1999 21:25:42 +0900 (JST)
Received: from islgw.isl.melco.co.jp by elgw.isl.melco.co.jp (8.8.8/3.6W) id VAA18620; Thu, 25 Nov 1999 21:26:09 +0900 (JST)
Received: from iss.isl.melco.co.jp by islgw.isl.melco.co.jp (8.8.8/3.6W) id VAA24306; Thu, 25 Nov 1999 21:28:58 +0900 (JST)
Received: from belize by iss.isl.melco.co.jp (1.38.193.4/3.6W) id AA26263; Thu, 25 Nov 1999 21:25:39 +0900
Message-Id: <0a0001bf373f$ef488d80$78054a0a@belize>
From: "Hiroyuki Sakakibara" <[e-mail]>
To: "Khaja E. Ahmed" <[e-mail]>, <[e-mail]>
Subject: RE: Question:Authority Information Access
Date: Thu, 25 Nov 1999 21:23:51 +0900
Mime-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-Msmail-Priority: Normal
X-Mailer: Microsoft Outlook Express 4.72.3612.1700
X-Mimeole: Produced By Microsoft MimeOLE V4.72.3612.1700

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:[e-mail]]
>> Sent: Tuesday, November 23, 1999 7:02 PM
>> To: [e-mail]
>> 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: [phone]
>> FAX: [phone]
>> ==========================================
>>
>
>




Received: from popmail.inbox.se (popmail.inbox.se [193.12.72.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id DAA11355 for <[e-mail]>; Thu, 25 Nov 1999 03:30:22 -0800 (PST)
Received: from best-laptop (lon-c45-009-vty8.as.wcom.net [195.232.6.8]) by popmail.inbox.se (8.9.3/8.9.3) with SMTP id MAA22127; Thu, 25 Nov 1999 12:31:44 +0100
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 
Date: Thu, 25 Nov 1999 06:32:59 -0500
To: Russ Housley <[e-mail]>, [e-mail]
From: Stefan Santesson <[e-mail]>
Subject: Re: proposed key usaged text -- the final round
Cc: [e-mail]
In-Reply-To: <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"

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.



Received: from clbull.frcl.bull.fr (clbull.frcl.bull.fr [129.182.8.31]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id CAA08573 for <[e-mail]>; Thu, 25 Nov 1999 02:51:11 -0800 (PST)
Received: from bull.net (frcls6118.frcl.bull.fr [129.182.109.213]) by clbull.frcl.bull.fr (8.9.2/8.9.1) with ESMTP id LAA20412; Thu, 25 Nov 1999 11:52:14 +0100
Message-ID: <[e-mail]>
Date: Thu, 25 Nov 1999 11:52:00 +0100
From: Denis Pinkas <[e-mail]>
Organization: Bull
X-Mailer: Mozilla 4.06 [fr] (Win95; I)
MIME-Version: 1.0
To: Russ Housley <[e-mail]>
CC: [e-mail], [e-mail]
Subject: Re: proposed key usaged text -- the final round
References: <[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

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" <[e-mail]>
  > 
  > 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.


Received: from s2.smtp.oleane.net (s2.smtp.oleane.net [195.25.12.6]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id BAA07631; Thu, 25 Nov 1999 01:47:27 -0800 (PST)
Received: from Dell  (dyn-1-1-020.Vin.dialup.oleane.fr [195.25.4.20])  by s2.smtp.oleane.net  with SMTP id KAA75105; Thu, 25 Nov 1999 10:48:42 +0100 (CET)
Message-ID: <011701bf372a$15705260$[e-mail]>
From: "Peter Lewis" <[e-mail]>
To: <[e-mail]>
Subject: IPSec 2000 
Date: Thu, 25 Nov 1999 10:47:18 +0100
Organization: Upperside
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_0112_01BF3732.7200A2C0"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.00.2314.1300
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300

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



Received: from dfw-smtpout4.email.verio.net (dfw-smtpout4-ext.email.verio.net [129.250.36.44]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id OAA15197 for <[e-mail]>; Wed, 24 Nov 1999 14:36:58 -0800 (PST)
Received: from dfw-mmp3.email.verio.net ([129.250.38.63]) by dfw-smtpout4.email.verio.net (Netscape Messaging Server 4.05) with ESMTP id FLQ48T00.414 for <[e-mail]>; Wed, 24 Nov 1999 22:38:53 +0000 
Received: from nma.com ([209.21.28.95]) by dfw-mmp3.email.verio.net (Netscape Messaging Server 4.05) with ESMTP id FLQ47S00.V7U; Wed, 24 Nov 1999 22:38:16 +0000 
Message-ID: <[e-mail]>
Date: Wed, 24 Nov 1999 14:39:36 -0800
From: Ed Gerck <[e-mail]>
X-Mailer: Mozilla 4.7 [en]C-CCK-MCD {Sony}  (Win98; I)
X-Accept-Language: en
MIME-Version: 1.0
To: Russ Housley <[e-mail]>
CC: [e-mail], [e-mail]
Subject: Re: proposed key usaged text -- the final round
References: <[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

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.



Received: from mail-out2.apple.com (mail-out2.apple.com [17.254.0.51]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id NAA14491 for <[e-mail]>; Wed, 24 Nov 1999 13:35:15 -0800 (PST)
Received: from mailgate2.apple.com ([17.129.100.225]) by mail-out2.apple.com (8.9.3/8.9.3) with ESMTP id NAA24529 for <[e-mail]>; Wed, 24 Nov 1999 13:37:09 -0800 (PST)
Received: from scv3.apple.com (scv3.apple.com) by mailgate2.apple.com (Content Technologies SMTPRS 2.0.15) with ESMTP id <[e-mail]> for <[e-mail]>; Wed, 24 Nov 1999 13:37:03 -0800
Received: from [17.205.41.166] (aram1.apple.com [17.205.41.166]) by scv3.apple.com (8.9.3/8.9.3) with ESMTP id NAA20359 for <[e-mail]>; Wed, 24 Nov 1999 13:36:41 -0800 (PST)
Message-Id: <[e-mail]>
X-Mailer: Microsoft Outlook Express Macintosh Edition - 4.5 (0410)
Date: Wed, 24 Nov 1999 13:35:39 -0800
Subject: Re: proposed key usaged text -- the final round
From: "Aram Perez" <[e-mail]>
To: [e-mail]
MIME-Version: 1.0
X-Priority: 3
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit

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!


Received: from mail.spyrus.com (mail.spyrus.com [207.212.34.20]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id MAA13731 for <[e-mail]>; Wed, 24 Nov 1999 12:42:39 -0800 (PST)
Received: from rhousley_laptop.spyrus.com ([209.172.119.101]) by mail.spyrus.com (8.9.3/8.9.3) with ESMTP id MAA18102; Wed, 24 Nov 1999 12:43:17 -0800 (PST)
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58 
Date: Wed, 24 Nov 1999 15:43:37 -0500
To: [e-mail]
From: Russ Housley <[e-mail]>
Subject: proposed key usaged text -- the final round
Cc: [e-mail]
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed

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.




Received: from kekec.e5.ijs.si (IDENT:[e-mail] [193.138.1.2]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id XAA01231 for <[e-mail]>; Tue, 23 Nov 1999 23:34:13 -0800 (PST)
From: [e-mail]
Received: (qmail 31337 invoked by uid 507); 24 Nov 1999 07:36:00 -0000
Message-ID: <[e-mail]>
Subject: inhibitAnyPolicy extension
To: [e-mail]
Date: Wed, 24 Nov 1999 08:36:00 +0100 (CET)
X-Mailer: ELM [version 2.5 PL0pre8]
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

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
[e-mail]
http://www.e5.ijs.si



Received: from ext-mail.valicert.com (ns1.valicert.com [63.65.221.10]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id TAA24624 for <[e-mail]>; Tue, 23 Nov 1999 19:39:30 -0800 (PST)
Received: from mercury (root@[63.65.221.8]) by ext-mail.valicert.com (8.9.3/8.9.3) with SMTP id TAA05169; Tue, 23 Nov 1999 19:41:07 -0800 (PST)
From: "Khaja E. Ahmed" <[e-mail]>
To: "Hiroyuki Sakakibara" <[e-mail]>, <[e-mail]>
Subject: RE: Question:Authority Information Access
Date: Tue, 23 Nov 1999 19:36:47 -0800
Message-ID: <000201bf362d$22f56900$[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0
X-Mimeole: Produced By Microsoft MimeOLE V5.00.2014.211
Importance: Normal
In-Reply-To: <008a01bf3628$36165c10$78054a0a@belize>

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:[e-mail]]
> Sent: Tuesday, November 23, 1999 7:02 PM
> To: [e-mail]
> 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: [phone]
> FAX: [phone]
> ==========================================
>



Received: from florida.melco.co.jp (florida.melco.co.jp [192.218.140.46]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id TAA22671 for <[e-mail]>; Tue, 23 Nov 1999 19:01:38 -0800 (PST)
Received: by florida.melco.co.jp (3.7W-florida) id MAA23496; Wed, 24 Nov 1999 12:02:52 +0900 (JST)
Received: by mailgw.melco.co.jp (3.7W-mailgw) id MAA22807; Wed, 24 Nov 1999 12:04:31 +0900 (JST)
Received: by inetgw.melco.co.jp (8.8.8+2.7Wbeta7/3.7W-inetgw) id MAA02158; Wed, 24 Nov 1999 12:05:21 +0900 (JST)
Received: from islgw.isl.melco.co.jp by elgw.isl.melco.co.jp (8.8.8/3.6W) id MAA14552; Wed, 24 Nov 1999 12:03:49 +0900 (JST)
Received: from iss.isl.melco.co.jp by islgw.isl.melco.co.jp (8.8.8/3.6W) id MAA01993; Wed, 24 Nov 1999 12:06:34 +0900 (JST)
Received: from belize by iss.isl.melco.co.jp (1.38.193.4/3.6W) id AA24487; Wed, 24 Nov 1999 12:03:19 +0900
Message-Id: <008a01bf3628$36165c10$78054a0a@belize>
From: "Hiroyuki Sakakibara" <[e-mail]>
To: <[e-mail]>
Subject: Question:Authority Information Access
Date: Wed, 24 Nov 1999 12:01:31 +0900
Mime-Version: 1.0
Content-Type: text/plain; charset="iso-2022-jp"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-Msmail-Priority: Normal
X-Mailer: Microsoft Outlook Express 4.72.3612.1700
X-Mimeole: Produced By Microsoft MimeOLE V4.72.3612.1700

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: [phone]
FAX: [phone]
==========================================




Received: from popmail.inbox.se (popmail.inbox.se [193.12.72.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id PAA15616 for <[e-mail]>; Tue, 23 Nov 1999 15:46:27 -0800 (PST)
Received: from best-laptop (mfs-pci-bqm-vty89.as.wcom.net [212.211.16.89]) by popmail.inbox.se (8.9.3/8.9.3) with SMTP id AAA00730; Wed, 24 Nov 1999 00:48:13 +0100
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 
Date: Tue, 23 Nov 1999 18:49:27 -0500
To: Jyri =?iso-8859-1?Q?T=E4htinen?= <[e-mail]>, [e-mail]
From: Stefan Santesson <[e-mail]>
Subject: Re: We have to choose serialNumber instead of dnQualifier  NOW!!!
Cc: [e-mail], [e-mail], [e-mail], [e-mail], [e-mail], [e-mail], [e-mail], [e-mail]
In-Reply-To: <[e-mail]>
References: <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by ns.secondary.com id PAA15617

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



Received: from mtk-mail1.mitretek.org (mtk-mail1.mitretek.org [206.241.50.65]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id OAA14591 for <[e-mail]>; Tue, 23 Nov 1999 14:25:15 -0800 (PST)
Received: from mail1.mitretek.org (mail1.mitretek.org [206.241.49.31]) by mtk-mail1.mitretek.org (8.8.6/8.7.3/Mitretek.0) with ESMTP id RAA08263; Tue, 23 Nov 1999 17:26:42 -0500 (EST)
Received: from bprice ([206.241.171.134]) by mail1.mitretek.org (Lotus Domino Release 5.0.1) with SMTP id 1999112317263022:12429 ; Tue, 23 Nov 1999 17:26:30 -0500 
From: "Bill Price" <[e-mail]>
To: <[e-mail]>, <[e-mail]>
Cc: <[e-mail]>
Subject: RE: Unknown private verisign extension
Date: Tue, 23 Nov 1999 17:26:38 -0500
Message-ID: <003d01bf3601$ceaee9a0$[e-mail]>
MIME-Version: 1.0
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook 8.5, Build 4.71.2377.0
In-Reply-To: <[e-mail]>
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600
Importance: Normal
X-MIMETrack: Itemize by SMTP Server on Mail1/Mitretek Systems(Release 5.0.1|July 16, 1999) at 11/23/99 05:26:30 PM, Serialize by Router on Mail1/Mitretek Systems(Release 5.0.1|July 16, 1999) at 11/23/99 05:26:31 PM, Serialize complete at 11/23/99 05:26:31 PM
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="iso-8859-1"

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: [e-mail] [mailto:[e-mail]]
> Sent: Wednesday, November 24, 1999 4:20 AM
> To: [e-mail]
> Cc: [e-mail]
> Subject: Re: Unknown private verisign extension
>
>
> [cc'd to PKIX for comment]
>
> [e-mail] 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.
>



Received: from seine.valicert.com (corporate-gw.valicert.com [63.65.221.2]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id OAA14203 for <[e-mail]>; Tue, 23 Nov 1999 14:02:08 -0800 (PST)
Received: by seine.valicert.com with Internet Mail Service (5.5.2650.21) id <WZF04CS3>; Tue, 23 Nov 1999 14:00:23 -0800
Message-ID: <[e-mail]>
From: Peter Williams <[e-mail]>
To: [e-mail], =?iso-8859-1?Q?Jyri_T=E4htinen?= <[e-mail]>
Cc: [e-mail]
Subject: RE: We have to choose serialNumber instead of dnQualifier  NOW!!!
Date: Tue, 23 Nov 1999 14:00:22 -0800
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by ns.secondary.com id OAA14204

> -----Original Message-----
> From: Magnus Nystrom [mailto:[e-mail]]
> 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
> 


Received: from sphinx.Gsu.EDU ([e-mail] [131.96.1.22]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id NAA13945 for <[e-mail]>; Tue, 23 Nov 1999 13:50:14 -0800 (PST)
Received: from ectfilent1 ([131.96.159.145]) by sphinx.Gsu.EDU (8.9.3/8.9.3-GSU-MOD-3) with SMTP id QAA12032; Tue, 23 Nov 1999 16:07:00 -0500 (EST)
Message-ID: <006001bf35f7$74cdc5a0$[e-mail]>
Reply-To: "Winchel 'Todd' Vincent, III" <[e-mail]>
From: "Winchel 'Todd' Vincent, III" <[e-mail]>
To: "Tim Moses" <[e-mail]>, <[e-mail]>, <[e-mail]>
References:  <[e-mail]>
Subject: Re:      Re: Certificate Policy vs Certification Practice .. where are the             boundaries? ... what belongs where?
Date: Tue, 23 Nov 1999 16:08:31 -0500
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.00.2314.1300
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300

> 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



Received: from gandalf.trustpoint.com (IDENT:[e-mail] [216.100.231.61]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id MAA13152; Tue, 23 Nov 1999 12:45:44 -0800 (PST)
Received: from himansu (himansu [192.168.42.5]) by gandalf.trustpoint.com (8.8.7/8.8.7) with SMTP id MAA16772; Tue, 23 Nov 1999 12:47:29 -0800
From: "John C. Kennedy" <[e-mail]>
To: "Russ Housley" <[e-mail]>
Cc: <[e-mail]>, <[e-mail]>, <[e-mail]>, <[e-mail]>, <[e-mail]>, <[e-mail]>, <[e-mail]>, <[e-mail]>, "Elaine Barker" <[e-mail]>, "Sharon Keller" <[e-mail]>, "Simon Blake-Wilson" <[e-mail]>, "Phil Griffin" <[e-mail]>
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
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
In-reply-to: <[e-mail]>
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300

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:[e-mail]]
> Sent: Tuesday, November 23, 1999 6:18 AM
> To: John C. Kennedy
> Cc: [e-mail]; [e-mail]; [e-mail];
> [e-mail]; [e-mail]; [e-mail];
> [e-mail]; [e-mail]; [e-mail];
> [e-mail]; 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



Received: from mail-out2.apple.com (mail-out2.apple.com [17.254.0.51]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id LAA12095 for <[e-mail]>; Tue, 23 Nov 1999 11:38:37 -0800 (PST)
Received: from mailgate1.apple.com (A17-128-100-225.apple.com [17.128.100.225]) by mail-out2.apple.com (8.9.3/8.9.3) with ESMTP id LAA00447 for <[e-mail]>; Tue, 23 Nov 1999 11:40:31 -0800 (PST)
Received: from scv3.apple.com (scv3.apple.com) by mailgate1.apple.com (mailgate1.apple.com- SMTPRS 2.0.15) with ESMTP id <[e-mail]> for <[e-mail]>; Tue, 23 Nov 1999 11:40:26 -0800
Received: from [17.205.41.166] (aram1.apple.com [17.205.41.166]) by scv3.apple.com (8.9.3/8.9.3) with ESMTP id LAA24816 for <[e-mail]>; Tue, 23 Nov 1999 11:40:21 -0800 (PST)
Message-Id: <[e-mail]>
X-Mailer: Microsoft Outlook Express Macintosh Edition - 4.5 (0410)
Date: Tue, 23 Nov 1999 11:40:14 -0800
Subject: Re: NR Signing-Entity vs Certificate-Subject
From: "Aram Perez" <[e-mail]>
To: PKIX <[e-mail]>
MIME-Version: 1.0
X-Priority: 3
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit

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


Received: from dfw-smtpout3.email.verio.net (dfw-smtpout3-ext.email.verio.net [129.250.36.43]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id LAA11912 for <[e-mail]>; Tue, 23 Nov 1999 11:36:30 -0800 (PST)
Received: from dfw-mmp1.email.verio.net ([129.250.38.61]) by dfw-smtpout3.email.verio.net (Netscape Messaging Server 4.05) with ESMTP id FLO17Y00.3PD for <[e-mail]>; Tue, 23 Nov 1999 19:38:22 +0000 
Received: from nma.com ([209.21.28.113]) by dfw-mmp1.email.verio.net (Netscape Messaging Server 4.05) with ESMTP id FLO17C00.H01; Tue, 23 Nov 1999 19:38:00 +0000 
Message-ID: <[e-mail]>
Date: Tue, 23 Nov 1999 11:39:03 -0800
From: Ed Gerck <[e-mail]>
X-Mailer: Mozilla 4.7 [en]C-CCK-MCD {Sony}  (Win98; I)
X-Accept-Language: en
MIME-Version: 1.0
To: "David P. Kemp" <[e-mail]>
CC: [e-mail]
Subject: Re: NR Signing-Entity vs Certificate-Subject
References: <[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

"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



Received: from hoemlsrv.firewall.lucent.com (hoemail1.lucent.com [192.11.226.161]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id LAA11650 for <[e-mail]>; Tue, 23 Nov 1999 11:29:04 -0800 (PST)
Received: from hoemlsrv.firewall.lucent.com (localhost [127.0.0.1]) by hoemlsrv.firewall.lucent.com (Pro-8.9.3/8.9.3) with ESMTP id OAA11681 for <[e-mail]>; Tue, 23 Nov 1999 14:30:58 -0500 (EST)
Received: from anuxc.mv.lucent.com (h135-13-160-12.lucent.com [135.13.160.12]) by hoemlsrv.firewall.lucent.com (Pro-8.9.3/8.9.3) with ESMTP id OAA11666; Tue, 23 Nov 1999 14:30:57 -0500 (EST)
Received: from irg-pc by anuxc.mv.lucent.com (8.8.8+Sun/EMS-1.5 sol2) id OAA28494; Tue, 23 Nov 1999 14:28:56 -0500 (EST)
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 
Date: Tue, 23 Nov 1999 14:30:47 -0500
To: Eric Murray <[e-mail]>
From: Irene Gassko <[e-mail]>
Subject: Re: NR Signing-Entity vs Certificate-Subject
Cc: Aram Perez <[e-mail]>, [e-mail]
In-Reply-To: <[e-mail]>
References: <[e-mail]> <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"

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:	[phone]
Room 30-2-A31			 e-mail: 	[e-mail]
N. Andover, MA 01845		 fax: 	[phone]


Received: from slack.lne.com (NoBody@[209.157.136.83]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id LAA11301 for <[e-mail]>; Tue, 23 Nov 1999 11:18:19 -0800 (PST)
Received: (from ericm@localhost) by slack.lne.com (8.9.0/8.9.0) id LAA06748; Tue, 23 Nov 1999 11:19:30 -0800
Message-ID: <[e-mail]>
Date: Tue, 23 Nov 1999 11:19:29 -0800
From: Eric Murray <[e-mail]>
To: Aram Perez <[e-mail]>
Cc: [e-mail]
Subject: Re: NR Signing-Entity vs Certificate-Subject
References: <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Mailer: Mutt 0.76
In-Reply-To: <[e-mail]>; from Aram Perez on Tue, Nov 23, 1999 at 10:53:14AM -0800

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


Received: from dfw-smtpout4.email.verio.net (dfw-smtpout4-ext.email.verio.net [129.250.36.44]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id LAA11031 for <[e-mail]>; Tue, 23 Nov 1999 11:06:17 -0800 (PST)
Received: from dfw-mmp4.email.verio.net ([129.250.38.64]) by dfw-smtpout4.email.verio.net (Netscape Messaging Server 4.05) with ESMTP id FLNZS400.70D for <[e-mail]>; Tue, 23 Nov 1999 19:07:16 +0000 
Received: from nma.com ([209.21.28.113]) by dfw-mmp4.email.verio.net (Netscape Messaging Server 4.05) with ESMTP id FLNZRL00.GZ1 for <[e-mail]>; Tue, 23 Nov 1999 19:06:57 +0000 
Message-ID: <[e-mail]>
Date: Tue, 23 Nov 1999 11:07:58 -0800
From: Ed Gerck <[e-mail]>
X-Mailer: Mozilla 4.7 [en]C-CCK-MCD {Sony}  (Win98; I)
X-Accept-Language: en
MIME-Version: 1.0
To: "[e-mail]" <[e-mail]>
Subject: Re: NR Signing-Entity vs Certificate-Subject
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

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


Received: from mail-out2.apple.com (mail-out2.apple.com [17.254.0.51]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id KAA10756 for <[e-mail]>; Tue, 23 Nov 1999 10:55:22 -0800 (PST)
Received: from mailgate1.apple.com (A17-128-100-225.apple.com [17.128.100.225]) by mail-out2.apple.com (8.9.3/8.9.3) with ESMTP id KAA20160 for <[e-mail]>; Tue, 23 Nov 1999 10:57:16 -0800 (PST)
Received: from scv2.apple.com (scv2.apple.com) by mailgate1.apple.com (mailgate1.apple.com- SMTPRS 2.0.15) with ESMTP id <[e-mail]> for <[e-mail]>; Tue, 23 Nov 1999 10:53:15 -0800
Received: from [17.205.41.166] (aram1.apple.com [17.205.41.166]) by scv2.apple.com (8.9.3/8.9.3) with ESMTP id KAA16691 for <[e-mail]>; Tue, 23 Nov 1999 10:53:15 -0800 (PST)
Message-Id: <[e-mail]>
X-Mailer: Microsoft Outlook Express Macintosh Edition - 4.5 (0410)
Date: Tue, 23 Nov 1999 10:53:14 -0800
Subject: Re: NR Signing-Entity vs Certificate-Subject
From: "Aram Perez" <[e-mail]>
To: [e-mail]
MIME-Version: 1.0
X-Priority: 3
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit

Dave Kemp wrote:

> 
>> From: Ed Gerck <[e-mail]>
> 
>> 
>> >   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


Received: from poptop.llnl.gov (poptop.llnl.gov [128.115.18.65]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id KAA10478 for <[e-mail]>; Tue, 23 Nov 1999 10:48:25 -0800 (PST)
Received: from catalyst (catalyst.llnl.gov [128.115.223.61]) by poptop.llnl.gov (8.8.8/LLNL-3.0.2/pop.llnl.gov-5.1) with SMTP id KAA18420; Tue, 23 Nov 1999 10:50:16 -0800 (PST)
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.3 (32)
Date: Tue, 23 Nov 1999 10:50:01 -0800
To: "David P. Kemp" <[e-mail]>, [e-mail]
From: Tony Bartoletti <[e-mail]>
Subject: Re: NR Signing-Entity vs Certificate-Subject
In-Reply-To: <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"

At 10:45 AM 11/23/1999 -0500, David P. Kemp wrote:
>
>> From: "David P. Kemp" <[e-mail]>
>> 
>> > From: Tony Bartoletti <[e-mail]>
>> > 
>> > 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: [phone]   fax: [phone]               LL LLLLLLLL
email: [e-mail]                                   LLLLLLLL


Received: from stingray.missi.ncsc.mil (stingray.missi.ncsc.mil [144.51.50.20]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id KAA09925 for <[e-mail]>; Tue, 23 Nov 1999 10:24:36 -0800 (PST)
Received: from stingray.missi.ncsc.mil (root@localhost) by stingray.missi.ncsc.mil with ESMTP id NAA05001 for <[e-mail]>; Tue, 23 Nov 1999 13:26:52 -0500 (EST)
Received: from missi.ncsc.mil (depot.missi.ncsc.mil [144.51.60.1]) by stingray.missi.ncsc.mil with ESMTP id NAA04995 for <[e-mail]>; Tue, 23 Nov 1999 13:26:52 -0500 (EST)
Received: from ara.missi.ncsc.mil (ara.missi.ncsc.mil [144.51.58.9]) by missi.ncsc.mil (8.8.8/8.8.8) with ESMTP id NAA06093 for <[e-mail]>; Tue, 23 Nov 1999 13:26:09 -0500 (EST)
Received: from ara.missi.ncsc.mil (ara.missi.ncsc.mil [144.51.58.9]) by ara.missi.ncsc.mil (8.9.1b+Sun/8.9.1) with SMTP id NAA17340 for <[e-mail]>; Tue, 23 Nov 1999 13:21:48 -0500 (EST)
Message-Id: <[e-mail]>
Date: Tue, 23 Nov 1999 13:21:48 -0500 (EST)
From: "David P. Kemp" <[e-mail]>
Reply-To: "David P. Kemp" <[e-mail]>
Subject: Re: NR Signing-Entity vs Certificate-Subject
To: [e-mail]
MIME-Version: 1.0
Content-Type: TEXT/plain; charset=us-ascii
Content-MD5: ARSI8URk5DRAgbgo7FzZaw==
X-Mailer: dtmail 1.3.0 CDE Version 1.3 SunOS 5.7 sun4u sparc

> From: Ed Gerck <[e-mail]>

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




Received: from dfw-smtpout3.email.verio.net (dfw-smtpout3-ext.email.verio.net [129.250.36.43]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id KAA09470 for <[e-mail]>; Tue, 23 Nov 1999 10:01:43 -0800 (PST)
Received: from dfw-mmp2.email.verio.net ([129.250.38.62]) by dfw-smtpout3.email.verio.net (Netscape Messaging Server 4.05) with ESMTP id FLNWTZ00.EIB for <[e-mail]>; Tue, 23 Nov 1999 18:03:35 +0000 
Received: from nma.com ([209.21.28.113]) by dfw-mmp2.email.verio.net (Netscape Messaging Server 4.05) with ESMTP id FLNWWX00.D61 for <[e-mail]>; Tue, 23 Nov 1999 18:05:21 +0000 
Message-ID: <[e-mail]>
Date: Tue, 23 Nov 1999 10:04:16 -0800
From: Ed Gerck <[e-mail]>
X-Mailer: Mozilla 4.7 [en]C-CCK-MCD {Sony}  (Win98; I)
X-Accept-Language: en
MIME-Version: 1.0
To: "[e-mail]" <[e-mail]>
Subject: signing entity in X.509
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

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




Received: from hoemlsrv.firewall.lucent.com (hoemail1.lucent.com [192.11.226.161]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id JAA08668 for <[e-mail]>; Tue, 23 Nov 1999 09:08:54 -0800 (PST)
Received: from hoemlsrv.firewall.lucent.com (localhost [127.0.0.1]) by hoemlsrv.firewall.lucent.com (Pro-8.9.3/8.9.3) with ESMTP id MAA14456 for <[e-mail]>; Tue, 23 Nov 1999 12:10:47 -0500 (EST)
Received: from anuxc.mv.lucent.com (h135-13-160-12.lucent.com [135.13.160.12]) by hoemlsrv.firewall.lucent.com (Pro-8.9.3/8.9.3) with ESMTP id MAA14438 for <[e-mail]>; Tue, 23 Nov 1999 12:10:47 -0500 (EST)
Received: from irg-pc by anuxc.mv.lucent.com (8.8.8+Sun/EMS-1.5 sol2) id MAA23441; Tue, 23 Nov 1999 12:09:21 -0500 (EST)
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 
Date: Tue, 23 Nov 1999 12:11:11 -0500
To: "[e-mail]" <[e-mail]>
From: Irene Gassko <[e-mail]>
Subject: Re: NR Signing-Entity vs Certificate-Subject
In-Reply-To: <[e-mail]>
References: <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"

>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:	[phone]
Room 30-2-A31			 e-mail: 	[e-mail]
N. Andover, MA 01845		 fax: 	[phone]


Received: from dfw-smtpout4.email.verio.net (dfw-smtpout4-ext.email.verio.net [129.250.36.44]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id IAA08148 for <[e-mail]>; Tue, 23 Nov 1999 08:36:02 -0800 (PST)
Received: from dfw-mmp1.email.verio.net ([129.250.38.61]) by dfw-smtpout4.email.verio.net (Netscape Messaging Server 4.05) with ESMTP id FLNSV600.ATY for <[e-mail]>; Tue, 23 Nov 1999 16:37:54 +0000 
Received: from nma.com ([209.21.28.123]) by dfw-mmp1.email.verio.net (Netscape Messaging Server 4.05) with ESMTP id FLNSUK00.N04 for <[e-mail]>; Tue, 23 Nov 1999 16:37:32 +0000 
Message-ID: <[e-mail]>
Date: Tue, 23 Nov 1999 08:38:35 -0800
From: Ed Gerck <[e-mail]>
X-Mailer: Mozilla 4.7 [en]C-CCK-MCD {Sony}  (Win98; I)
X-Accept-Language: en
MIME-Version: 1.0
To: "[e-mail]" <[e-mail]>
Subject: Re: Unknown private verisign extension
References: <[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Peter Gutmann wrote:

> [cc'd to PKIX for comment]
>
> [e-mail] 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




Received: from dfw-smtpout3.email.verio.net (dfw-smtpout3-ext.email.verio.net [129.250.36.43]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id IAA07945 for <[e-mail]>; Tue, 23 Nov 1999 08:33:59 -0800 (PST)
Received: from dfw-mmp2.email.verio.net ([129.250.38.62]) by dfw-smtpout3.email.verio.net (Netscape Messaging Server 4.05) with ESMTP id FLNSQA00.QKV for <[e-mail]>; Tue, 23 Nov 1999 16:34:58 +0000 
Received: from nma.com ([209.21.28.123]) by dfw-mmp2.email.verio.net (Netscape Messaging Server 4.05) with ESMTP id FLNST800.53Y for <[e-mail]>; Tue, 23 Nov 1999 16:36:44 +0000 
Message-ID: <[e-mail]>
Date: Tue, 23 Nov 1999 08:35:17 -0800
From: Ed Gerck <[e-mail]>
X-Mailer: Mozilla 4.7 [en]C-CCK-MCD {Sony}  (Win98; I)
X-Accept-Language: en
MIME-Version: 1.0
To: "[e-mail]" <[e-mail]>
Subject: Re: NR Signing-Entity vs Certificate-Subject
References: <[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

"David P. Kemp" wrote:

> > From: Tony Bartoletti <[e-mail]>
> >
> > 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



Received: from stingray.missi.ncsc.mil (stingray.missi.ncsc.mil [144.51.50.20]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id HAA05356 for <[e-mail]>; Tue, 23 Nov 1999 07:48:39 -0800 (PST)
Received: from stingray.missi.ncsc.mil (root@localhost) by stingray.missi.ncsc.mil with ESMTP id KAA10777 for <[e-mail]>; Tue, 23 Nov 1999 10:50:55 -0500 (EST)
Received: from missi.ncsc.mil (depot.missi.ncsc.mil [144.51.60.1]) by stingray.missi.ncsc.mil with ESMTP id KAA10770 for <[e-mail]>; Tue, 23 Nov 1999 10:50:55 -0500 (EST)
Received: from ara.missi.ncsc.mil (ara.missi.ncsc.mil [144.51.58.9]) by missi.ncsc.mil (8.8.8/8.8.8) with ESMTP id KAA03715 for <[e-mail]>; Tue, 23 Nov 1999 10:50:12 -0500 (EST)
Received: from ara.missi.ncsc.mil (ara.missi.ncsc.mil [144.51.58.9]) by ara.missi.ncsc.mil (8.9.1b+Sun/8.9.1) with SMTP id KAA17308 for <[e-mail]>; Tue, 23 Nov 1999 10:45:51 -0500 (EST)
Message-Id: <[e-mail]>
Date: Tue, 23 Nov 1999 10:45:51 -0500 (EST)
From: "David P. Kemp" <[e-mail]>
Reply-To: "David P. Kemp" <[e-mail]>
Subject: Re: NR Signing-Entity vs Certificate-Subject
To: [e-mail]
MIME-Version: 1.0
Content-Type: TEXT/plain; charset=us-ascii
Content-MD5: GA0mr1RANSncdiNFwHP8Xg==
X-Mailer: dtmail 1.3.0 CDE Version 1.3 SunOS 5.7 sun4u sparc

> From: "David P. Kemp" <[e-mail]>
> 
> > From: Tony Bartoletti <[e-mail]>
> > 
> > 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.



Received: from dfw-smtpout3.email.verio.net (dfw-smtpout3-ext.email.verio.net [129.250.36.43]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id HAA04248 for <[e-mail]>; Tue, 23 Nov 1999 07:31:35 -0800 (PST)
Received: from dfw-mmp1.email.verio.net ([129.250.38.61]) by dfw-smtpout3.email.verio.net (Netscape Messaging Server 4.05) with ESMTP id FLNPVS00.0CW for <[e-mail]>; Tue, 23 Nov 1999 15:33:28 +0000 
Received: from nma.com ([209.21.28.123]) by dfw-mmp1.email.verio.net (Netscape Messaging Server 4.05) with ESMTP id FLNPV600.6JW; Tue, 23 Nov 1999 15:33:06 +0000 
Message-ID: <[e-mail]>
Date: Tue, 23 Nov 1999 07:34:08 -0800
From: Ed Gerck <[e-mail]>
X-Mailer: Mozilla 4.7 [en]C-CCK-MCD {Sony}  (Win98; I)
X-Accept-Language: en
MIME-Version: 1.0
To: Russ Housley <[e-mail]>
CC: [e-mail]
Subject: Re: MOTION ON NR
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

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




Received: from mail.student.auckland.ac.nz (mail.student.auckland.ac.nz [130.216.35.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id HAA03333 for <[e-mail]>; Tue, 23 Nov 1999 07:18:10 -0800 (PST)
Received: from cs26.cs.auckland.ac.nz ([e-mail] [130.216.36.9]) by mail.student.auckland.ac.nz (8.9.3/8.8.6/cs-master) with SMTP id EAA17266; Wed, 24 Nov 1999 04:20:00 +1300 (NZDT) (sender [e-mail])
Received: by cs26.cs.auckland.ac.nz (relaymail v0.9) id <94337040130439>; Wed, 24 Nov 1999 04:20:01 (NZDT)
From: [e-mail] (Peter Gutmann)
To: [e-mail]
Subject: Re: Unknown private verisign extension
Cc: [e-mail]
Sender: [e-mail]
Reply-To: [e-mail]
X-Charge-To: pgut001
X-Authenticated: relaymail v0.9 on cs26.cs.auckland.ac.nz
Date: Wed, 24 Nov 1999 04:20:01 (NZDT)
Message-ID: <[e-mail]>

[cc'd to PKIX for comment]

[e-mail] 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.



Received: from stingray.missi.ncsc.mil (stingray.missi.ncsc.mil [144.51.50.20]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id HAA02502 for <[e-mail]>; Tue, 23 Nov 1999 07:02:45 -0800 (PST)
Received: from stingray.missi.ncsc.mil (root@localhost) by stingray.missi.ncsc.mil with ESMTP id KAA02943 for <[e-mail]>; Tue, 23 Nov 1999 10:05:00 -0500 (EST)
Received: from missi.ncsc.mil (depot.missi.ncsc.mil [144.51.60.1]) by stingray.missi.ncsc.mil with ESMTP id KAA02939 for <[e-mail]>; Tue, 23 Nov 1999 10:04:59 -0500 (EST)
Received: from ara.missi.ncsc.mil (ara.missi.ncsc.mil [144.51.58.9]) by missi.ncsc.mil (8.8.8/8.8.8) with ESMTP id KAA02873 for <[e-mail]>; Tue, 23 Nov 1999 10:04:16 -0500 (EST)
Received: from ara.missi.ncsc.mil (ara.missi.ncsc.mil [144.51.58.9]) by ara.missi.ncsc.mil (8.9.1b+Sun/8.9.1) with SMTP id JAA17296 for <[e-mail]>; Tue, 23 Nov 1999 09:59:56 -0500 (EST)
Message-Id: <[e-mail]>
Date: Tue, 23 Nov 1999 09:59:56 -0500 (EST)
From: "David P. Kemp" <[e-mail]>
Reply-To: "David P. Kemp" <[e-mail]>
Subject: Re: NR Signing-Entity vs Certificate-Subject
To: [e-mail]
MIME-Version: 1.0
Content-Type: TEXT/plain; charset=us-ascii
Content-MD5: hUkSvMfJTtqqLjrThnRqaQ==
X-Mailer: dtmail 1.3.0 CDE Version 1.3 SunOS 5.7 sun4u sparc

> From: Tony Bartoletti <[e-mail]>
> 
> 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".



Received: from mail.spyrus.com (mail.spyrus.com [207.212.34.20]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id GAA01762; Tue, 23 Nov 1999 06:36:33 -0800 (PST)
Received: from rhousley_laptop.spyrus.com ([209.172.119.101]) by mail.spyrus.com (8.9.3/8.9.3) with ESMTP id GAA20082; Tue, 23 Nov 1999 06:36:17 -0800 (PST)
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58 
Date: Tue, 23 Nov 1999 09:18:21 -0500
To: "John C. Kennedy" <[e-mail]>
From: Russ Housley <[e-mail]>
Subject: RE: FIPS 186 and X9.42: One of these things is not like the other
Cc: <[e-mail]>, <[e-mail]>, <[e-mail]>, <[e-mail]>, <[e-mail]>, <[e-mail]>, <[e-mail]>, <[e-mail]>, <[e-mail]>, <[e-mail]>, "Elaine Barker" <[e-mail]>, "Sharon Keller" <[e-mail]>, "Simon Blake-Wilson" <[e-mail]>, "Phil Griffin" <[e-mail]>
In-Reply-To: <[e-mail]>
References: <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed

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



Received: from mail.spyrus.com (mail.spyrus.com [207.212.34.20]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id GAA01676 for <[e-mail]>; Tue, 23 Nov 1999 06:36:20 -0800 (PST)
Received: from rhousley_laptop.spyrus.com ([209.172.119.101]) by mail.spyrus.com (8.9.3/8.9.3) with ESMTP id GAA20093; Tue, 23 Nov 1999 06:36:24 -0800 (PST)
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58 
Date: Tue, 23 Nov 1999 09:27:30 -0500
To: Tony Bartoletti <[e-mail]>
From: Russ Housley <[e-mail]>
Subject: Re: MOTION ON NR
Cc: Ed Gerck <[e-mail]>, "[e-mail]" <[e-mail]>, Nicholas Bohm <[e-mail]>
In-Reply-To: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed

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: [phone]   fax: [phone]               LL LLLLLLLL
>email: [e-mail]                                   LLLLLLLL



Received: from mail.spyrus.com (mail.spyrus.com [207.212.34.20]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id GAA01535 for <[e-mail]>; Tue, 23 Nov 1999 06:35:56 -0800 (PST)
Received: from rhousley_laptop.spyrus.com ([209.172.119.101]) by mail.spyrus.com (8.9.3/8.9.3) with ESMTP id GAA20096; Tue, 23 Nov 1999 06:36:25 -0800 (PST)
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58 
Date: Tue, 23 Nov 1999 09:31:02 -0500
To: [e-mail]
From: Russ Housley <[e-mail]>
Subject: Re: MOTION ON NR
Cc: [e-mail]
In-Reply-To: <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed

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, [e-mail] 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



Received: from mail.spyrus.com (mail.spyrus.com [207.212.34.20]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id GAA01512 for <[e-mail]>; Tue, 23 Nov 1999 06:35:54 -0800 (PST)
Received: from rhousley_laptop.spyrus.com ([209.172.119.101]) by mail.spyrus.com (8.9.3/8.9.3) with ESMTP id GAA20099; Tue, 23 Nov 1999 06:36:27 -0800 (PST)
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58 
Date: Tue, 23 Nov 1999 09:33:30 -0500
To: Paul Koning <[e-mail]>
From: Russ Housley <[e-mail]>
Subject: Re: MOTION ON NR
Cc: [e-mail]
In-Reply-To: <[e-mail]>
References: <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed

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



Received: from mail.spyrus.com (mail.spyrus.com [207.212.34.20]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id GAA01494 for <[e-mail]>; Tue, 23 Nov 1999 06:35:47 -0800 (PST)
Received: from rhousley_laptop.spyrus.com ([209.172.119.101]) by mail.spyrus.com (8.9.3/8.9.3) with ESMTP id GAA20088; Tue, 23 Nov 1999 06:36:22 -0800 (PST)
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58 
Date: Tue, 23 Nov 1999 09:25:47 -0500
To: Ed Gerck <[e-mail]>
From: Russ Housley <[e-mail]>
Subject: Re: MOTION ON NR
Cc: [e-mail]
In-Reply-To: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed

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



Received: from karon.dynas.se (karon.dynas.se [192.71.43.4]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id FAA00547 for <[e-mail]>; Tue, 23 Nov 1999 05:17:34 -0800 (PST)
Received: (qmail 31546 invoked from network); 23 Nov 1999 13:19:13 -0000
Received: from spirit.sto.dynas.se (HELO spirit.dynas.se) (172.16.1.10) by karon.sto.dynas.se with SMTP; 23 Nov 1999 13:19:13 -0000
Received: (qmail 3947 invoked from network); 23 Nov 1999 13:19:12 -0000
Received: from mnystrom-lap.nordic-dhcp.dynas.se (10.129.12.146) by spirit.dynas.se with SMTP; 23 Nov 1999 13:19:12 -0000
Date: Tue, 23 Nov 1999 14:18:38 +0100 (W. Europe Standard Time)
From: Magnus Nystrom <[e-mail]>
Reply-To: [e-mail]
To: Jyri =?iso-8859-1?Q?T=E4htinen?= <[e-mail]>
cc: Stefan Santesson <[e-mail]>, [e-mail], Ella Paton Bassett <[e-mail]>, [e-mail], [e-mail], [e-mail], [e-mail], [e-mail], [e-mail], [e-mail], [e-mail], [e-mail], [e-mail], [e-mail], [e-mail], [e-mail], [e-mail], [e-mail], [e-mail], [e-mail]
Subject: Re: We have to choose serialNumber instead of dnQualifier  NOW!!!
In-Reply-To: <[e-mail]>
Message-ID: <[e-mail]>
X-X-Sender: magnus@[172.16.1.10]
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=ISO-8859-1
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from QUOTED-PRINTABLE to 8bit by ns.secondary.com id FAA00552

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



Received: from smtp1.kolumbus.fi (smtp1.kolumbus.fi [193.229.0.36]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id EAA29951 for <[e-mail]>; Tue, 23 Nov 1999 04:43:23 -0800 (PST)
Received: from hpy.fi (hpy-1-254.hepunet.fi [194.136.227.254]) by smtp1.kolumbus.fi (8.9.0/8.9.0) with ESMTP id OAA23911; Tue, 23 Nov 1999 14:44:57 +0200 (EET)
Message-ID: <[e-mail]>
Date: Tue, 23 Nov 1999 14:46:46 +0200
From: Jyri =?iso-8859-1?Q?T=E4htinen?= <[e-mail]>
Organization: Helsinki Telephone Corporation, Kolumbus Services
X-Mailer: Mozilla 4.7 [en] (WinNT; I)
X-Accept-Language: en
MIME-Version: 1.0
To: [e-mail]
CC: Stefan Santesson <[e-mail]>, [e-mail], Ella Paton Bassett <[e-mail]>, [e-mail], [e-mail], [e-mail], [e-mail], [e-mail], [e-mail], [e-mail], [e-mail], [e-mail], [e-mail], [e-mail], [e-mail], [e-mail], [e-mail], [e-mail], [e-mail], [e-mail]
Subject: Re: We have to choose serialNumber instead of dnQualifier  NOW!!!
References: <[e-mail]>
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit

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    [phone]
> > >  Kolumbus Services                Mobile phone [phone]
> > >  Asemapäällikönkatu 2 (PAD510)    Fax          [phone]
> > >  P.O.Box 133                      E-mail       [e-mail]
> > >  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: [e-mail]
> > >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                <[e-mail]>
> > Accurata AB                     http://www.accurata.se
> > Slagthuset                      Tel. [phone]
> > 211 20  Malmö                   Fax. [phone]
> > Sweden                        Mobile [phone]
> >
> > PGP fingerprint: 89BC 6C79 5B3D 591B 8547  1512 7D11 DBF4 528F 29A0
> > -------------------------------------------------------------------
> >
> 
> -- Magnus
> Magnus Nystrom          Email: [e-mail]
> RSA Laboratories

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


Received: from smtp1.kolumbus.fi (smtp1.kolumbus.fi [193.229.0.36]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id DAA29212 for <[e-mail]>; Tue, 23 Nov 1999 03:24:17 -0800 (PST)
Received: from hpy.fi (hpy-1-254.hepunet.fi [194.136.227.254]) by smtp1.kolumbus.fi (8.9.0/8.9.0) with ESMTP id NAA18415; Tue, 23 Nov 1999 13:26:03 +0200 (EET)
Message-ID: <[e-mail]>
Date: Tue, 23 Nov 1999 13:28:43 +0200
From: Jyri =?iso-8859-1?Q?T=E4htinen?= <[e-mail]>
Organization: Helsinki Telephone Corporation, Kolumbus Services
X-Mailer: Mozilla 4.7 [en] (WinNT; I)
X-Accept-Language: en
MIME-Version: 1.0
To: Juergen Brauckmann <[e-mail]>
CC: [e-mail]
Subject: Re: We have to choose serialNumber instead of dnQualifier NOW!!!
References: <[e-mail]> <3.0.5.32.19991123104012.009b7690@callisto>
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit

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:[e-mail]
> 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    [phone]
  Kolumbus Services                Mobile phone [phone]
  Asemapäällikönkatu 2 (PAD510)    Fax          [phone] 
  P.O.Box 133                      E-mail       [e-mail]
  FIN-00521 HELSINKI               <PGP available on request>
 --------------------------------  - - - - - - - - - - - - - - - - - - -


Received: from mystic1.trustcenter.de ([e-mail] [193.194.157.34]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id BAA23428 for <[e-mail]>; Tue, 23 Nov 1999 01:44:36 -0800 (PST)
Received: by mystic1.trustcenter.de; id KAA18618; Tue, 23 Nov 1999 10:41:16 +0100 (MET)
Received: from nodnsquery(192.168.200.3) by mystic1.trustcenter.de via smap (V5.0) id xma018614; Tue, 23 Nov 99 10:40:34 +0100
Received: from ew-jbr (titan.trustcenter.de [192.168.200.244]) by callisto.trustcenter.de (8.9.3/8.9.3) with SMTP id KAA25490; Tue, 23 Nov 1999 10:40:59 +0100 (MET)
Message-Id: <3.0.5.32.19991123104012.009b7690@callisto>
X-Sender: jbr@callisto
X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32)
Date: Tue, 23 Nov 1999 10:40:12 +0100
To: [e-mail], [e-mail]
From: Juergen Brauckmann <[e-mail]>
Subject: Re: We have to choose serialNumber instead of dnQualifier  NOW!!!
In-Reply-To: <[e-mail] >
References: <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by ns.secondary.com id BAA23429

>> 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:[e-mail]
20097 Hamburg 		    http://www.trustcenter.de	



Received: from karon.dynas.se (karon.dynas.se [192.71.43.4]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id BAA22524 for <[e-mail]>; Tue, 23 Nov 1999 01:00:01 -0800 (PST)
Received: (qmail 29550 invoked from network); 23 Nov 1999 09:01:52 -0000
Received: from spirit.sto.dynas.se (HELO spirit.dynas.se) (172.16.1.10) by karon.sto.dynas.se with SMTP; 23 Nov 1999 09:01:52 -0000
Received: (qmail 14527 invoked from network); 23 Nov 1999 09:01:47 -0000
Received: from mnystrom-lap.nordic-dhcp.dynas.se (10.129.12.146) by spirit.dynas.se with SMTP; 23 Nov 1999 09:01:47 -0000
Date: Tue, 23 Nov 1999 10:01:15 +0100 (W. Europe Standard Time)
From: Magnus Nystrom <[e-mail]>
Reply-To: [e-mail]
To: Stefan Santesson <[e-mail]>
cc: [e-mail], Ella Paton Bassett <[e-mail]>, [e-mail], [e-mail], [e-mail], [e-mail], [e-mail], [e-mail], [e-mail], [e-mail], [e-mail], [e-mail], [e-mail], [e-mail]
Subject: Re: We have to choose serialNumber instead of dnQualifier  NOW!!!
In-Reply-To: <[e-mail]>
Message-ID: <[e-mail]>
X-X-Sender: magnus@[172.16.1.10]
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=ISO-8859-1
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from QUOTED-PRINTABLE to 8bit by ns.secondary.com id BAA22525

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    [phone]
> >  Kolumbus Services                Mobile phone [phone]
> >  Asemapäällikönkatu 2 (PAD510)    Fax          [phone] 
> >  P.O.Box 133                      E-mail       [e-mail]
> >  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: [e-mail]
> >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                <[e-mail]>
> Accurata AB                     http://www.accurata.se
> Slagthuset                      Tel. [phone]              
> 211 20  Malmö                   Fax. [phone]              
> Sweden                        Mobile [phone]
> 
> PGP fingerprint: 89BC 6C79 5B3D 591B 8547  1512 7D11 DBF4 528F 29A0
> -------------------------------------------------------------------
> 

-- Magnus
Magnus Nystrom		Email: [e-mail]
RSA Laboratories



Received: from tycho.ncsc.mil (tarius.tycho.ncsc.mil [144.51.3.1]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id SAA04401 for <[e-mail]>; Mon, 22 Nov 1999 18:37:48 -0800 (PST)
Received: from zanyclown.tycho.ncsc.mil (zanyclown.tycho.ncsc.mil [144.51.3.100]) by tycho.ncsc.mil (8.9.1/8.9.1) with ESMTP id VAA18178 for <[e-mail]>; Mon, 22 Nov 1999 21:38:03 -0500 (EST)
Received: by zanyclown-14.alpha.ncsc.mil with Internet Mail Service (5.5.2448.0) id <XM1XZJZV>; Mon, 22 Nov 1999 21:36:53 -0500
Message-ID: <[e-mail]>
From: "Gary W. Seehousz" <[e-mail]>
To: "'[e-mail]'" <[e-mail]>
Subject: unsubscribe
Date: Mon, 22 Nov 1999 21:36:52 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2448.0)
Content-Type: text/plain; charset="iso-8859-1"

unsubscribe


Received: from poptop.llnl.gov (poptop.llnl.gov [128.115.18.65]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id SAA04350 for <[e-mail]>; Mon, 22 Nov 1999 18:37:33 -0800 (PST)
Received: from catalyst (catalyst.llnl.gov [128.115.223.61]) by poptop.llnl.gov (8.8.8/LLNL-3.0.2/pop.llnl.gov-5.1) with SMTP id SAA01259; Mon, 22 Nov 1999 18:39:22 -0800 (PST)
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.3 (32)
Date: Mon, 22 Nov 1999 18:39:07 -0800
To: [e-mail]
From: Tony Bartoletti <[e-mail]>
Subject: Re: MOTION ON NR
Cc: "[e-mail]" <[e-mail]>, [e-mail], Ed Gerck <[e-mail]>, Tim Polk <[e-mail]>
In-Reply-To: <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"

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: [phone]   fax: [phone]               LL LLLLLLLL
email: [e-mail]                                   LLLLLLLL


Received: from poptop.llnl.gov (poptop.llnl.gov [128.115.18.65]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id RAA01078 for <[e-mail]>; Mon, 22 Nov 1999 17:31:33 -0800 (PST)
Received: from catalyst (catalyst.llnl.gov [128.115.223.61]) by poptop.llnl.gov (8.8.8/LLNL-3.0.2/pop.llnl.gov-5.1) with SMTP id RAA17221; Mon, 22 Nov 1999 17:33:20 -0800 (PST)
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.3 (32)
Date: Mon, 22 Nov 1999 17:33:06 -0800
To: [e-mail]
From: Tony Bartoletti <[e-mail]>
Subject: Re: NR Signing-Entity vs Certificate-Subject
Cc: "[e-mail]" <[e-mail]>
In-Reply-To: <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"

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: [phone]   fax: [phone]               LL LLLLLLLL
email: [e-mail]                                   LLLLLLLL


Received: from dfw-smtpout3.email.verio.net (dfw-smtpout3-ext.email.verio.net [129.250.36.43]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id RAA01034 for <[e-mail]>; Mon, 22 Nov 1999 17:28:54 -0800 (PST)
Received: from dfw-mmp3.email.verio.net ([129.250.38.63]) by dfw-smtpout3.email.verio.net (Netscape Messaging Server 4.05) with ESMTP id FLMMV400.NBF for <[e-mail]>; Tue, 23 Nov 1999 01:30:40 +0000 
Received: from nma.com ([209.21.28.111]) by dfw-mmp3.email.verio.net (Netscape Messaging Server 4.05) with ESMTP id FLMMTZ00.IH1; Tue, 23 Nov 1999 01:29:59 +0000 
Message-ID: <[e-mail]>
Date: Mon, 22 Nov 1999 17:31:15 -0800
From: Ed Gerck <[e-mail]>
X-Mailer: Mozilla 4.7 [en]C-CCK-MCD {Sony}  (Win98; I)
X-Accept-Language: en
MIME-Version: 1.0
To: [e-mail]
CC: Tony Bartoletti <[e-mail]>, "[e-mail]" <[e-mail]>
Subject: Re: NR Signing-Entity vs Certificate-Subject
References: <[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

[e-mail] 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




Received: from dfw-smtpout1.email.verio.net (dfw-smtpout1-ext.email.verio.net [129.250.36.41]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id PAA29673 for <[e-mail]>; Mon, 22 Nov 1999 15:46:55 -0800 (PST)
Received: from dfw-mmp2.email.verio.net ([129.250.38.62]) by dfw-smtpout1.email.verio.net (Netscape Messaging Server 4.05) with ESMTP id FLMI5800.S2J for <[e-mail]>; Mon, 22 Nov 1999 23:48:44 +0000 
Received: from nma.com ([209.21.28.111]) by dfw-mmp2.email.verio.net (Netscape Messaging Server 4.05) with ESMTP id FLMI8600.NWD; Mon, 22 Nov 1999 23:50:30 +0000 
Message-ID: <[e-mail]>
Date: Mon, 22 Nov 1999 15:49:21 -0800
From: Ed Gerck <[e-mail]>
X-Mailer: Mozilla 4.7 [en]C-CCK-MCD {Sony}  (Win98; I)
X-Accept-Language: en
MIME-Version: 1.0
To: Tony Bartoletti <[e-mail]>, "[e-mail]" <[e-mail]>
Subject: Re: MOTION ON NR
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

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



Received: from e3.ny.us.ibm.com (e3.ny.us.ibm.com [32.97.182.103]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id PAA29416 for <[e-mail]>; Mon, 22 Nov 1999 15:35:23 -0800 (PST)
From: [e-mail]
Received: from northrelay02.pok.ibm.com (northrelay02.pok.ibm.com [9.117.200.22]) by e3.ny.us.ibm.com (8.9.3/8.9.3) with ESMTP id SAA367926; Mon, 22 Nov 1999 18:36:23 -0500
Received: from D51MTA05.pok.ibm.com (d51mta05.pok.ibm.com [9.117.200.33]) by northrelay02.pok.ibm.com (8.8.8m2/NCO v2.06) with SMTP id SAA121222; Mon, 22 Nov 1999 18:37:11 -0500
Received: by D51MTA05.pok.ibm.com(Lotus SMTP MTA v4.6.5  (863.2 5-20-1999))  id 85256831.0081BBB4 ; Mon, 22 Nov 1999 18:37:01 -0500
X-Lotus-FromDomain: IBMUS
To: Tony Bartoletti <[e-mail]>
cc: "[e-mail]" <[e-mail]>
Message-ID: <[e-mail]>
Date: Mon, 22 Nov 1999 18:37:06 -0500
Subject: Re: NR Signing-Entity vs Certificate-Subject
Mime-Version: 1.0
Content-type: text/plain; charset=us-ascii
Content-Disposition: inline

     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 <[e-mail]> on 11/22/99 05:59:33 PM

To:   "[e-mail]" <[e-mail]>
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: [phone]   fax: [phone]               LL LLLLLLLL
email: [e-mail]                                   LLLLLLLL




Received: from poptop.llnl.gov (poptop.llnl.gov [128.115.18.65]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id OAA28721 for <[e-mail]>; Mon, 22 Nov 1999 14:57:58 -0800 (PST)
Received: from catalyst (catalyst.llnl.gov [128.115.223.61]) by poptop.llnl.gov (8.8.8/LLNL-3.0.2/pop.llnl.gov-5.1) with SMTP id OAA04916 for <[e-mail]>; Mon, 22 Nov 1999 14:59:48 -0800 (PST)
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.3 (32)
Date: Mon, 22 Nov 1999 14:59:33 -0800
To: "[e-mail]" <[e-mail]>
From: Tony Bartoletti <[e-mail]>
Subject: NR Signing-Entity vs Certificate-Subject
In-Reply-To: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"

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: [phone]   fax: [phone]               LL LLLLLLLL
email: [e-mail]                                   LLLLLLLL


Received: from mail.student.auckland.ac.nz (mail.student.auckland.ac.nz [130.216.35.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id OAA28287; Mon, 22 Nov 1999 14:37:45 -0800 (PST)
Received: from cs26.cs.auckland.ac.nz ([e-mail] [130.216.36.9]) by mail.student.auckland.ac.nz (8.9.3/8.8.6/cs-master) with SMTP id LAA25088; Tue, 23 Nov 1999 11:39:09 +1300 (NZDT) (sender [e-mail])
Received: by cs26.cs.auckland.ac.nz (relaymail v0.9) id <94331035024854>; Tue, 23 Nov 1999 11:39:10 (NZDT)
From: [e-mail] (Peter Gutmann)
To: [e-mail], [e-mail], [e-mail], [e-mail], [e-mail]
Subject: Re: FIPS 186 and X9.42: One of these things is not like the other
Sender: [e-mail]
Reply-To: [e-mail]
X-Charge-To: pgut001
X-Authenticated: relaymail v0.9 on cs26.cs.auckland.ac.nz
Date: Tue, 23 Nov 1999 11:39:10 (NZDT)
Message-ID: <[e-mail]>

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

Russ Housley <[e-mail]> 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.




Received: from dfw7-1.relay.mail.uu.net (dfw7-1.relay.mail.uu.net [199.171.54.106]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id OAA28066 for <[e-mail]>; Mon, 22 Nov 1999 14:31:28 -0800 (PST)
Received: from xedia.com by dfw7sosrv11.alter.net with SMTP  (peer crosschecked as: madway.xedia.com [198.202.232.199]) id QQhqmk04732 for <[e-mail]>; Mon, 22 Nov 1999 22:33:12 GMT
Received: from tonga.xedia.com by xedia.com (4.1/SMI-4.1) id AA04217; Mon, 22 Nov 99 17:31:04 EST
Received: by tonga.xedia.com (SMI-8.6/SMI-SVR4) id RAA18787; Mon, 22 Nov 1999 17:33:10 -0500
Date: Mon, 22 Nov 1999 17:33:10 -0500
Message-Id: <[e-mail]>
From: Paul Koning <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
To: [e-mail]
Subject: Re: MOTION ON NR
References: <[e-mail]>
X-Mailer: VM 6.34 under 20.3 "Vatican City" XEmacs  Lucid

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


Received: from ponyexpress6.csc.com (ponyexpress6.csc.com [208.219.64.207]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id OAA27849 for <[e-mail]>; Mon, 22 Nov 1999 14:26:06 -0800 (PST)
From: [e-mail]
Received: from va-fch31.csc.com ([20.1.107.9] helo=csc.com) by ponyexpress6.csc.com with smtp (Exim 2.12 #1) id 11q1vg-0002Mm-01 for [e-mail]; Mon, 22 Nov 1999 17:27:24 -0500
Received: by csc.com(Lotus SMTP MTA v4.6.5  (863.2 5-20-1999))  id 85256831.007B5F8E ; Mon, 22 Nov 1999 17:27:33 -0500
X-Lotus-FromDomain: CSC
To: [e-mail]
Message-ID: <[e-mail]>
Date: Mon, 22 Nov 1999 17:23:15 -0500
Subject: Re: MOTION ON NR
Mime-Version: 1.0
Content-type: text/plain; charset=us-ascii
Content-Disposition: inline

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




Received: from poptop.llnl.gov (poptop.llnl.gov [128.115.18.65]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id OAA27467 for <[e-mail]>; Mon, 22 Nov 1999 14:07:26 -0800 (PST)
Received: from catalyst (catalyst.llnl.gov [128.115.223.61]) by poptop.llnl.gov (8.8.8/LLNL-3.0.2/pop.llnl.gov-5.1) with SMTP id OAA05858; Mon, 22 Nov 1999 14:09:06 -0800 (PST)
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.3 (32)
Date: Mon, 22 Nov 1999 14:08:52 -0800
To: Russ Housley <[e-mail]>
From: Tony Bartoletti <[e-mail]>
Subject: Re: MOTION ON NR
Cc: Ed Gerck <[e-mail]>, "[e-mail]" <[e-mail]>, Nicholas Bohm <[e-mail]>
In-Reply-To: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"

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: [phone]   fax: [phone]               LL LLLLLLLL
email: [e-mail]                                   LLLLLLLL


Received: from dfw-smtpout4.email.verio.net (dfw-smtpout4-ext.email.verio.net [129.250.36.44]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id OAA27219 for <[e-mail]>; Mon, 22 Nov 1999 14:00:21 -0800 (PST)
Received: from dfw-mmp2.email.verio.net ([129.250.38.62]) by dfw-smtpout4.email.verio.net (Netscape Messaging Server 4.05) with ESMTP id FLMD7800.PFP for <[e-mail]>; Mon, 22 Nov 1999 22:01:56 +0000 
Received: from nma.com ([209.21.28.76]) by dfw-mmp2.email.verio.net (Netscape Messaging Server 4.05) with ESMTP id FLMD9I00.1LT; Mon, 22 Nov 1999 22:03:18 +0000 
Message-ID: <[e-mail]>
Date: Mon, 22 Nov 1999 14:02:09 -0800
From: Ed Gerck <[e-mail]>
X-Mailer: Mozilla 4.7 [en]C-CCK-MCD {Sony}  (Win98; I)
X-Accept-Language: en
MIME-Version: 1.0
To: Russ Housley <[e-mail]>, Tony Bartoletti <[e-mail]>, "[e-mail]" <[e-mail]>
Subject: Re: MOTION ON NR
References: <[e-mail]> <[e-mail]> <[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

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



Received: from caesar.udac.se (caesar.udac.se [193.44.79.10]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id NAA26740 for <[e-mail]>; Mon, 22 Nov 1999 13:40:14 -0800 (PST)
Received: from mega (t2o69p100.telia.com [62.20.144.220]) by caesar.udac.se (8.7.3/NetworkC-1) with SMTP id WAA50993; Mon, 22 Nov 1999 22:37:27 +0100
Message-ID: <005f01bf353a$53803670$[e-mail]>
From: "Anders Rundgren" <[e-mail]>
To: <[e-mail]>
Cc: <[e-mail]>, "Ella Paton Bassett" <[e-mail]>, <[e-mail]>, <[e-mail]>, <[e-mail]>, <[e-mail]>, <[e-mail]>, <[e-mail]>, <[e-mail]>, <[e-mail]>, <[e-mail]>, "Stefan Santesson" <[e-mail]>
Subject: Re: We have to choose serialNumber instead of dnQualifier NOW!!!
Date: Mon, 22 Nov 1999 22:38:32 -0000
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 4.72.3110.5
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by ns.secondary.com id NAA26741

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



Received: from gandalf.trustpoint.com (IDENT:[e-mail] [216.100.231.61]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id MAA25898; Mon, 22 Nov 1999 12:50:32 -0800 (PST)
Received: from himansu (himansu [192.168.42.5]) by gandalf.trustpoint.com (8.8.7/8.8.7) with SMTP id MAA09550; Mon, 22 Nov 1999 12:52:06 -0800
From: "John C. Kennedy" <[e-mail]>
To: "Russ Housley" <[e-mail]>
Cc: <[e-mail]>, <[e-mail]>, <[e-mail]>, <[e-mail]>, <[e-mail]>, <[e-mail]>, <[e-mail]>, <[e-mail]>, <[e-mail]>, <[e-mail]>, "Elaine Barker" <[e-mail]>, "Sharon Keller" <[e-mail]>, "Simon Blake-Wilson" <[e-mail]>, "Phil Griffin" <[e-mail]>
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
MIME-Version: 1.0
Message-ID: <[e-mail]>
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_0056_01BF34E9.03F25260"
Importance: Normal
In-Reply-To: <[e-mail]>
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300

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
[e-mail]


> -----Original Message-----
> From: Russ Housley [mailto:[e-mail]]

> 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
> >[e-mail]
> >
> >
> >
> >-----Original Message-----
> >From: [e-mail] [mailto:[e-mail]]
> >Sent: Sunday, November 21, 1999 1:58 PM
> >To: [e-mail]; [e-mail]
> >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"

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIGhzCCAo8w
ggH6oAMCAQICFQDZ+E/k9gGxjXStLkDx9Qm6iCXqjTALBgkqhkiG9w0BAQUwNTEWMBQGA1UEAxMN
U01lbWUgUm9vdCBDQTEOMAwGA1UEChMFU01lbWUxCzAJBgNVBAYTAlVTMB4XDTk5MDYyNDIzNDQw
OFoXDTE0MDYyNDIzNDQwOFowNTEWMBQGA1UEAxMNU01lbWUgUm9vdCBDQTEOMAwGA1UEChMFU01l
bWUxCzAJBgNVBAYTAlVTMIGdMAsGCSqGSIb3DQEBAQOBjQAwgYkCgYEAoh2u/ZzVrjTtXzowWcH1
vVHqUSJRsAF+TunEsqbZsn755D6Y0xe2ruYlNMEW7sExSoUYPQNR7cTQWwcFSyE3FtDhGGkYUt5O
UgPXZ5HVuG/Q4UwocCbOx4CIIfNJJevfEw9MvthYugg2J13XBW5iUonP5aY5rO6VrQedIa1+q8kC
AwEAAaOBoDCBnTAPBgNVHRMBAf8EBTADAQH/MB8GA1UdIwQYMBaAFNn4T+T2AbGNdK0uQPH1CbqI
JeqNMB0GA1UdDgQWBBTZ+E/k9gGxjXStLkDx9Qm6iCXqjTAOBgNVHQ8BAf8EBAMCAP4wJwYDVR0l
BCAwHgYIKwYBBQUHAwIGCCsGAQUFBwMDBggrBgEFBQcDBDARBglghkgBhvhCAQEEBAMCALcwCwYJ
KoZIhvcNAQEFA4GBAJLpYU+A1SKEVesAvpylZ//Fhq/fOZrVnxBgEVHC0RpLMnlPG/Y2XaZqmr42
bIwvqZ50m6R5o41mob2N4a78ty30kAOLEvsxFaK06iezfHFJGn9TbLPEi2BTaIWCJv77skLSVjUe
zzm5JAmaKwJ3txI6s4sbM6/rrnQ2oPa2/n+JMIID8DCCA1ugAwIBAgIVANnXVOID136qfHqgNaDC
u+cYaTDNMAsGCSqGSIb3DQEBBTA1MRYwFAYDVQQDEw1TTWVtZSBSb290IENBMQ4wDAYDVQQKEwVT
TWVtZTELMAkGA1UEBhMCVVMwHhcNOTkwODI1MDEzNjEyWhcNMDAwODI1MDEzNjEyWjBkMQswCQYD
VQQGEwJVUzETMBEGA1UEChMKVHJ1c3Rwb2ludDEYMBYGA1UEAxMPSm9obiBDLiBLZW5uZWR5MSYw
JAYJKoZIhvcNAQkBFhdqa2VubmVkeUB0cnVzdHBvaW50LmNvbTCBnzANBgkqhkiG9w0BAQEFAAOB
jQAwgYkCgYEAm/78rZZNYaJ67AZjKMwFb3ky+57qdCpI0oAbPpQQqYJOAzm0f2Y4Nlz3QMC0scMp
lGvIpxr8qwMoPIReFo+X4e7QiyumvXfNkKSgFw43rA6ne0zACHX7dbx0U4c6NLLDYer+3lFAGe8M
9y2ICgWk9aBnRaPaUKKIJhDpp4zEepMCAwEAAaOCAc8wggHLMB0GA1UdDgQWBBRBz7sIilZiDESP
GwAbpRjKtTIrajAhBgNVHSMEGgQYMBaAFNn4T+T2AbGNdK0uQPH1CbqIJeqNMA4GA1UdDwEB/wQE
AwIA+DAnBgNVHSUEIDAeBggrBgEFBQcDAgYIKwYBBQUHAwMGCCsGAQUFBwMEMBEGCWCGSAGG+EIB
AQQEAwIAsDAiBgNVHREEGzAZgRdqa2VubmVkeUB0cnVzdHBvaW50LmNvbTBRBgNVHSAESjBIMEYG
CCsGBAGYVB4BMDowOAYIKwYBBQUHAgEWLGh0dHA6Ly93d3cuc21lbWUuY29tL3NlcnZpY2VhZ3Jl
ZW1lbnRfMS5odG1sMEQGCWCGSAGG+EIBAwQ3FjVodHRwOi8vd3d3LnNtZW1lLmNvbS9zZXJ2bGV0
cy9zbWVtZV9jYS9jaGVja19yZXZva2VkPzBBBglghkgBhvhCAQcENBYyaHR0cDovL3d3dy5zbWVt
ZS5jb20vc2VydmxldHMvc21lbWVfY2EvcmVuZXdfY2VydD8wOwYJYIZIAYb4QgEIBC4WLGh0dHA6
Ly93d3cuc21lbWUuY29tL3NlcnZpY2VhZ3JlZW1lbnRfMS5odG1sMAsGCSqGSIb3DQEBBQOBgQB3
OYc+W2F6MemxaU4Udxf7CRVZ/fR8/zEs+mpb9WIT2Dsft7XRVKP/XWZeQwx5iBoFOaU6/Xf3yqr4
k6nqhEoj1sPYD5QuTS9M/NhPYovbyf/zzUcXGTV+JRK6TgTMbIbfyuMDfBKKfHXIv5gmJfZUCNhY
N8C00T8yX9sEVYpzfzGCAg4wggIKAgEBME4wNTEWMBQGA1UEAxMNU01lbWUgUm9vdCBDQTEOMAwG
A1UEChMFU01lbWUxCzAJBgNVBAYTAlVTAhUA2ddU4gPXfqp8eqA1oMK75xhpMM0wCQYFKw4DAhoF
AKCCARYwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNOTkxMTIyMjA1
NjM4WjAjBgkqhkiG9w0BCQQxFgQUG7z6EA/nfah6ILD1P+sSefziq/AwWAYJKoZIhvcNAQkPMUsw
STAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgwBwYF
Kw4DAhowCgYIKoZIhvcNAgUwXQYJKwYBBAGCNxAEMVAwTjA1MRYwFAYDVQQDEw1TTWVtZSBSb290
IENBMQ4wDAYDVQQKEwVTTWVtZTELMAkGA1UEBhMCVVMCFQDZ11TiA9d+qnx6oDWgwrvnGGkwzTAN
BgkqhkiG9w0BAQEFAASBgHwXLP1sgy74hdtWvoz4y9Z2lt4LTBnorA5tLYxSD3XMKSmaPvNr8/b4
rS5foo+1N5YyVBy+G/MDwM21PeyUZeneUwJ+XJaZOLRLavB2z7diCcuDd3A1nY/xPRoTQfsK587o
Yoad3QzhM3tgTFSZg+OLV72KiwfSgKX+3YH/hb0yAAAAAAAA

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



Received: from eng1.certicom.com (mailhost.certicom.com [209.121.99.2]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id MAA25398; Mon, 22 Nov 1999 12:23:44 -0800 (PST)
Received: from domino2.certicom.com (domino2.certicom.com [10.0.1.25]) by eng1.certicom.com (8.8.7/8.8.7) with SMTP id PAA28840; Mon, 22 Nov 1999 15:29:15 -0500 (EST) (envelope-from [e-mail])
Received: by domino2.certicom.com(Lotus SMTP MTA v4.6.4  (830.2 3-23-1999))  id 85256831.006FFF43 ; Mon, 22 Nov 1999 15:23:18 -0500
X-Lotus-FromDomain: CERTICOM
From: "Don Johnson" <[e-mail]>
To: "John C. Kennedy" <[e-mail]>
cc: [e-mail], [e-mail], [e-mail], [e-mail], [e-mail], [e-mail], [e-mail], [e-mail], [e-mail], [e-mail], "Elaine Barker" <[e-mail]>, "Sharon Keller" <[e-mail]>, "Simon Blake-Wilson" <[e-mail]>, [e-mail]
Message-ID: <[e-mail]>
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
Mime-Version: 1.0
Content-type: multipart/mixed;  Boundary="0__=ACDP3UzyXR808KoURSahabzWVpJ5vRGS4kMPU5dQEQ0kvhjbvaZoHErM"
Content-Disposition: inline

--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" <[e-mail]> on 11/22/99 03:08:47 PM

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

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:[e-mail]]
Sent: Monday, November 22, 1999 6:36 AM
To: John C. Kennedy
Cc: [e-mail]; [e-mail]; [e-mail];
[e-mail]; [e-mail]; [e-mail];
[e-mail]; [e-mail]; [e-mail];
[e-mail]; 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" <[e-mail]> on 11/21/99 04:17:21 AM

To:   [e-mail], [e-mail], [e-mail],
      [e-mail]
cc:   [e-mail], [e-mail], Don
      Johnson/Certicom@Certicom, [e-mail], [e-mail],
      [e-mail], [e-mail]

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
[e-mail]



-----Original Message-----
From: [e-mail] [mailto:[e-mail]]
Sent: Sunday, November 21, 1999 1:58 PM
To: [e-mail]; [e-mail]
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

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIGhzCCAo8w
ggH6oAMCAQICFQDZ+E/k9gGxjXStLkDx9Qm6iCXqjTALBgkqhkiG9w0BAQUwNTEWMBQGA1UEAxMN
U01lbWUgUm9vdCBDQTEOMAwGA1UEChMFU01lbWUxCzAJBgNVBAYTAlVTMB4XDTk5MDYyNDIzNDQw
OFoXDTE0MDYyNDIzNDQwOFowNTEWMBQGA1UEAxMNU01lbWUgUm9vdCBDQTEOMAwGA1UEChMFU01l
bWUxCzAJBgNVBAYTAlVTMIGdMAsGCSqGSIb3DQEBAQOBjQAwgYkCgYEAoh2u/ZzVrjTtXzowWcH1
vVHqUSJRsAF+TunEsqbZsn755D6Y0xe2ruYlNMEW7sExSoUYPQNR7cTQWwcFSyE3FtDhGGkYUt5O
UgPXZ5HVuG/Q4UwocCbOx4CIIfNJJevfEw9MvthYugg2J13XBW5iUonP5aY5rO6VrQedIa1+q8kC
AwEAAaOBoDCBnTAPBgNVHRMBAf8EBTADAQH/MB8GA1UdIwQYMBaAFNn4T+T2AbGNdK0uQPH1CbqI
JeqNMB0GA1UdDgQWBBTZ+E/k9gGxjXStLkDx9Qm6iCXqjTAOBgNVHQ8BAf8EBAMCAP4wJwYDVR0l
BCAwHgYIKwYBBQUHAwIGCCsGAQUFBwMDBggrBgEFBQcDBDARBglghkgBhvhCAQEEBAMCALcwCwYJ
KoZIhvcNAQEFA4GBAJLpYU+A1SKEVesAvpylZ//Fhq/fOZrVnxBgEVHC0RpLMnlPG/Y2XaZqmr42
bIwvqZ50m6R5o41mob2N4a78ty30kAOLEvsxFaK06iezfHFJGn9TbLPEi2BTaIWCJv77skLSVjUe
zzm5JAmaKwJ3txI6s4sbM6/rrnQ2oPa2/n+JMIID8DCCA1ugAwIBAgIVANnXVOID136qfHqgNaDC
u+cYaTDNMAsGCSqGSIb3DQEBBTA1MRYwFAYDVQQDEw1TTWVtZSBSb290IENBMQ4wDAYDVQQKEwVT
TWVtZTELMAkGA1UEBhMCVVMwHhcNOTkwODI1MDEzNjEyWhcNMDAwODI1MDEzNjEyWjBkMQswCQYD
VQQGEwJVUzETMBEGA1UEChMKVHJ1c3Rwb2ludDEYMBYGA1UEAxMPSm9obiBDLiBLZW5uZWR5MSYw
JAYJKoZIhvcNAQkBFhdqa2VubmVkeUB0cnVzdHBvaW50LmNvbTCBnzANBgkqhkiG9w0BAQEFAAOB
jQAwgYkCgYEAm/78rZZNYaJ67AZjKMwFb3ky+57qdCpI0oAbPpQQqYJOAzm0f2Y4Nlz3QMC0scMp
lGvIpxr8qwMoPIReFo+X4e7QiyumvXfNkKSgFw43rA6ne0zACHX7dbx0U4c6NLLDYer+3lFAGe8M
9y2ICgWk9aBnRaPaUKKIJhDpp4zEepMCAwEAAaOCAc8wggHLMB0GA1UdDgQWBBRBz7sIilZiDESP
GwAbpRjKtTIrajAhBgNVHSMEGgQYMBaAFNn4T+T2AbGNdK0uQPH1CbqIJeqNMA4GA1UdDwEB/wQE
AwIA+DAnBgNVHSUEIDAeBggrBgEFBQcDAgYIKwYBBQUHAwMGCCsGAQUFBwMEMBEGCWCGSAGG+EIB
AQQEAwIAsDAiBgNVHREEGzAZgRdqa2VubmVkeUB0cnVzdHBvaW50LmNvbTBRBgNVHSAESjBIMEYG
CCsGBAGYVB4BMDowOAYIKwYBBQUHAgEWLGh0dHA6Ly93d3cuc21lbWUuY29tL3NlcnZpY2VhZ3Jl
ZW1lbnRfMS5odG1sMEQGCWCGSAGG+EIBAwQ3FjVodHRwOi8vd3d3LnNtZW1lLmNvbS9zZXJ2bGV0
cy9zbWVtZV9jYS9jaGVja19yZXZva2VkPzBBBglghkgBhvhCAQcENBYyaHR0cDovL3d3dy5zbWVt
ZS5jb20vc2VydmxldHMvc21lbWVfY2EvcmVuZXdfY2VydD8wOwYJYIZIAYb4QgEIBC4WLGh0dHA6
Ly93d3cuc21lbWUuY29tL3NlcnZpY2VhZ3JlZW1lbnRfMS5odG1sMAsGCSqGSIb3DQEBBQOBgQB3
OYc+W2F6MemxaU4Udxf7CRVZ/fR8/zEs+mpb9WIT2Dsft7XRVKP/XWZeQwx5iBoFOaU6/Xf3yqr4
k6nqhEoj1sPYD5QuTS9M/NhPYovbyf/zzUcXGTV+JRK6TgTMbIbfyuMDfBKKfHXIv5gmJfZUCNhY
N8C00T8yX9sEVYpzfzGCAg4wggIKAgEBME4wNTEWMBQGA1UEAxMNU01lbWUgUm9vdCBDQTEOMAwG
A1UEChMFU01lbWUxCzAJBgNVBAYTAlVTAhUA2ddU4gPXfqp8eqA1oMK75xhpMM0wCQYFKw4DAhoF
AKCCARYwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNOTkxMTIyMjAw
ODAwWjAjBgkqhkiG9w0BCQQxFgQUBdgjSDcpnR2EJcDFK2skB/DlnoEwWAYJKoZIhvcNAQkPMUsw
STAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgwBwYF
Kw4DAhowCgYIKoZIhvcNAgUwXQYJKwYBBAGCNxAEMVAwTjA1MRYwFAYDVQQDEw1TTWVtZSBSb290
IENBMQ4wDAYDVQQKEwVTTWVtZTELMAkGA1UEBhMCVVMCFQDZ11TiA9d+qnx6oDWgwrvnGGkwzTAN
BgkqhkiG9w0BAQEFAASBgDZrQXq3paFT0/wSmjF07F1aFaSLQDaVMzPFcaDkEiXIAMneugvSdduZ
o/W6+y9R89kXdg9DJyGTym1wDe0fR3l9zbraPCh/U4jmU15SpoVyftjdWpZDwWdb43x4im44uXxj
xuc9jnthCBqtWlsqtfo9ue0jBaYy0wB7QjmfOanKAAAAAAAA

--0__=ACDP3UzyXR808KoURSahabzWVpJ5vRGS4kMPU5dQEQ0kvhjbvaZoHErM--



Received: from Newman.GSC.GTE.Com ([e-mail] [192.160.62.66] (may be forged)) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id MAA25202 for <[e-mail]>; Mon, 22 Nov 1999 12:19:35 -0800 (PST)
Received: from gscex01.gsc.gte.com ("port 3329"@gscex01.ndhm.gsc.gte.com [155.95.162.170]) by Newman.GSC.GTE.Com (PMDF V5.2-30 #29038) with ESMTP id <[e-mail]> for [e-mail]; Mon, 22 Nov 1999 12:37:23 -0400
Received: by GSCEX01.gsc.gte.com with Internet Mail Service (5.5.2448.0) id <XDAVGA5L>; Mon, 22 Nov 1999 12:37:20 -0500
Content-return: allowed
Date: Mon, 22 Nov 1999 12:37:18 -0500
From: "Heimberg, Jim" <[e-mail]>
Subject: RE: proposed key usage text
To: "'Russ Housley'" <[e-mail]>, Stefan Santesson <[e-mail]>
Cc: Aram Perez <[e-mail]>, [e-mail]
Message-id: <[e-mail]>
MIME-version: 1.0
X-Mailer: Internet Mail Service (5.5.2448.0)
Content-type: text/plain;	charset="iso-8859-1"

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:[e-mail]]
Sent: Monday, November 22, 1999 11:31 AM
To: Stefan Santesson
Cc: Aram Perez; [e-mail]
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



Received: from gandalf.trustpoint.com (IDENT:[e-mail] [216.100.231.61]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id MAA24796; Mon, 22 Nov 1999 12:02:29 -0800 (PST)
Received: from himansu (himansu [192.168.42.5]) by gandalf.trustpoint.com (8.8.7/8.8.7) with SMTP id MAA09227; Mon, 22 Nov 1999 12:03:40 -0800
From: "John C. Kennedy" <[e-mail]>
To: "Don Johnson" <[e-mail]>
Cc: <[e-mail]>, <[e-mail]>, <[e-mail]>, <[e-mail]>, <[e-mail]>, <[e-mail]>, <[e-mail]>, <[e-mail]>, <[e-mail]>, <[e-mail]>, "Elaine Barker" <[e-mail]>, "Sharon Keller" <[e-mail]>, "Simon Blake-Wilson" <[e-mail]>, "Phil Griffin" <[e-mail]>
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
MIME-Version: 1.0
Message-ID: <[e-mail]>
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_003E_01BF34E2.38788920"
Importance: Normal
In-Reply-To: <[e-mail]>
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300

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:[e-mail]]
Sent: Monday, November 22, 1999 6:36 AM
To: John C. Kennedy
Cc: [e-mail]; [e-mail]; [e-mail];
[e-mail]; [e-mail]; [e-mail];
[e-mail]; [e-mail]; [e-mail];
[e-mail]; 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" <[e-mail]> on 11/21/99 04:17:21 AM

To:   [e-mail], [e-mail], [e-mail],
      [e-mail]
cc:   [e-mail], [e-mail], Don
      Johnson/Certicom@Certicom, [e-mail], [e-mail],
      [e-mail], [e-mail]

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
[e-mail]



-----Original Message-----
From: [e-mail] [mailto:[e-mail]]
Sent: Sunday, November 21, 1999 1:58 PM
To: [e-mail]; [e-mail]
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"

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIGhzCCAo8w
ggH6oAMCAQICFQDZ+E/k9gGxjXStLkDx9Qm6iCXqjTALBgkqhkiG9w0BAQUwNTEWMBQGA1UEAxMN
U01lbWUgUm9vdCBDQTEOMAwGA1UEChMFU01lbWUxCzAJBgNVBAYTAlVTMB4XDTk5MDYyNDIzNDQw
OFoXDTE0MDYyNDIzNDQwOFowNTEWMBQGA1UEAxMNU01lbWUgUm9vdCBDQTEOMAwGA1UEChMFU01l
bWUxCzAJBgNVBAYTAlVTMIGdMAsGCSqGSIb3DQEBAQOBjQAwgYkCgYEAoh2u/ZzVrjTtXzowWcH1
vVHqUSJRsAF+TunEsqbZsn755D6Y0xe2ruYlNMEW7sExSoUYPQNR7cTQWwcFSyE3FtDhGGkYUt5O
UgPXZ5HVuG/Q4UwocCbOx4CIIfNJJevfEw9MvthYugg2J13XBW5iUonP5aY5rO6VrQedIa1+q8kC
AwEAAaOBoDCBnTAPBgNVHRMBAf8EBTADAQH/MB8GA1UdIwQYMBaAFNn4T+T2AbGNdK0uQPH1CbqI
JeqNMB0GA1UdDgQWBBTZ+E/k9gGxjXStLkDx9Qm6iCXqjTAOBgNVHQ8BAf8EBAMCAP4wJwYDVR0l
BCAwHgYIKwYBBQUHAwIGCCsGAQUFBwMDBggrBgEFBQcDBDARBglghkgBhvhCAQEEBAMCALcwCwYJ
KoZIhvcNAQEFA4GBAJLpYU+A1SKEVesAvpylZ//Fhq/fOZrVnxBgEVHC0RpLMnlPG/Y2XaZqmr42
bIwvqZ50m6R5o41mob2N4a78ty30kAOLEvsxFaK06iezfHFJGn9TbLPEi2BTaIWCJv77skLSVjUe
zzm5JAmaKwJ3txI6s4sbM6/rrnQ2oPa2/n+JMIID8DCCA1ugAwIBAgIVANnXVOID136qfHqgNaDC
u+cYaTDNMAsGCSqGSIb3DQEBBTA1MRYwFAYDVQQDEw1TTWVtZSBSb290IENBMQ4wDAYDVQQKEwVT
TWVtZTELMAkGA1UEBhMCVVMwHhcNOTkwODI1MDEzNjEyWhcNMDAwODI1MDEzNjEyWjBkMQswCQYD
VQQGEwJVUzETMBEGA1UEChMKVHJ1c3Rwb2ludDEYMBYGA1UEAxMPSm9obiBDLiBLZW5uZWR5MSYw
JAYJKoZIhvcNAQkBFhdqa2VubmVkeUB0cnVzdHBvaW50LmNvbTCBnzANBgkqhkiG9w0BAQEFAAOB
jQAwgYkCgYEAm/78rZZNYaJ67AZjKMwFb3ky+57qdCpI0oAbPpQQqYJOAzm0f2Y4Nlz3QMC0scMp
lGvIpxr8qwMoPIReFo+X4e7QiyumvXfNkKSgFw43rA6ne0zACHX7dbx0U4c6NLLDYer+3lFAGe8M
9y2ICgWk9aBnRaPaUKKIJhDpp4zEepMCAwEAAaOCAc8wggHLMB0GA1UdDgQWBBRBz7sIilZiDESP
GwAbpRjKtTIrajAhBgNVHSMEGgQYMBaAFNn4T+T2AbGNdK0uQPH1CbqIJeqNMA4GA1UdDwEB/wQE
AwIA+DAnBgNVHSUEIDAeBggrBgEFBQcDAgYIKwYBBQUHAwMGCCsGAQUFBwMEMBEGCWCGSAGG+EIB
AQQEAwIAsDAiBgNVHREEGzAZgRdqa2VubmVkeUB0cnVzdHBvaW50LmNvbTBRBgNVHSAESjBIMEYG
CCsGBAGYVB4BMDowOAYIKwYBBQUHAgEWLGh0dHA6Ly93d3cuc21lbWUuY29tL3NlcnZpY2VhZ3Jl
ZW1lbnRfMS5odG1sMEQGCWCGSAGG+EIBAwQ3FjVodHRwOi8vd3d3LnNtZW1lLmNvbS9zZXJ2bGV0
cy9zbWVtZV9jYS9jaGVja19yZXZva2VkPzBBBglghkgBhvhCAQcENBYyaHR0cDovL3d3dy5zbWVt
ZS5jb20vc2VydmxldHMvc21lbWVfY2EvcmVuZXdfY2VydD8wOwYJYIZIAYb4QgEIBC4WLGh0dHA6
Ly93d3cuc21lbWUuY29tL3NlcnZpY2VhZ3JlZW1lbnRfMS5odG1sMAsGCSqGSIb3DQEBBQOBgQB3
OYc+W2F6MemxaU4Udxf7CRVZ/fR8/zEs+mpb9WIT2Dsft7XRVKP/XWZeQwx5iBoFOaU6/Xf3yqr4
k6nqhEoj1sPYD5QuTS9M/NhPYovbyf/zzUcXGTV+JRK6TgTMbIbfyuMDfBKKfHXIv5gmJfZUCNhY
N8C00T8yX9sEVYpzfzGCAg4wggIKAgEBME4wNTEWMBQGA1UEAxMNU01lbWUgUm9vdCBDQTEOMAwG
A1UEChMFU01lbWUxCzAJBgNVBAYTAlVTAhUA2ddU4gPXfqp8eqA1oMK75xhpMM0wCQYFKw4DAhoF
AKCCARYwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNOTkxMTIyMjAw
ODAwWjAjBgkqhkiG9w0BCQQxFgQUBdgjSDcpnR2EJcDFK2skB/DlnoEwWAYJKoZIhvcNAQkPMUsw
STAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgwBwYF
Kw4DAhowCgYIKoZIhvcNAgUwXQYJKwYBBAGCNxAEMVAwTjA1MRYwFAYDVQQDEw1TTWVtZSBSb290
IENBMQ4wDAYDVQQKEwVTTWVtZTELMAkGA1UEBhMCVVMCFQDZ11TiA9d+qnx6oDWgwrvnGGkwzTAN
BgkqhkiG9w0BAQEFAASBgDZrQXq3paFT0/wSmjF07F1aFaSLQDaVMzPFcaDkEiXIAMneugvSdduZ
o/W6+y9R89kXdg9DJyGTym1wDe0fR3l9zbraPCh/U4jmU15SpoVyftjdWpZDwWdb43x4im44uXxj
xuc9jnthCBqtWlsqtfo9ue0jBaYy0wB7QjmfOanKAAAAAAAA

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



Received: from mail.spyrus.com (mail.spyrus.com [207.212.34.20]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id LAA24493; Mon, 22 Nov 1999 11:57:54 -0800 (PST)
Received: from rhousley_laptop.spyrus.com ([209.172.119.101]) by mail.spyrus.com (8.9.3/8.9.3) with ESMTP id LAA04995; Mon, 22 Nov 1999 11:57:47 -0800 (PST)
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58 
Date: Mon, 22 Nov 1999 14:56:30 -0500
To: "Don Johnson" <[e-mail]>
From: Russ Housley <[e-mail]>
Subject: RE: FIPS 186 and X9.42: One of these things is not like the other
Cc: "John C. Kennedy" <[e-mail]>, [e-mail], [e-mail], [e-mail], [e-mail], [e-mail], [e-mail], [e-mail], [e-mail], [e-mail], Elaine Barker <[e-mail]>, Sharon Keller <[e-mail]>, "Simon Blake-Wilson" <[e-mail]>, "Phil Griffin" <[e-mail]>
In-Reply-To: <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed

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 <[e-mail]> on 11/22/99 01:50:56 PM
>
>To:   Don Johnson/Certicom@Certicom
>cc:   "John C. Kennedy" <[e-mail]>, [e-mail],
>       [e-mail], [e-mail], [e-mail],
>       [e-mail], [e-mail], [e-mail], 
> [e-mail],
>       [e-mail], Elaine Barker <[e-mail]>, 
> Sharon
>       Keller <[e-mail]>, Simon Blake-Wilson/Certicom@Certicom, "Phil
>       Griffin" <[e-mail]>
>
>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
>
>



Received: from mail.spyrus.com (mail.spyrus.com [207.212.34.20]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id LAA24427 for <[e-mail]>; Mon, 22 Nov 1999 11:57:44 -0800 (PST)
Received: from rhousley_laptop.spyrus.com ([209.172.119.101]) by mail.spyrus.com (8.9.3/8.9.3) with ESMTP id LAA04991; Mon, 22 Nov 1999 11:57:46 -0800 (PST)
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58 
Date: Mon, 22 Nov 1999 14:44:54 -0500
To: Tony Bartoletti <[e-mail]>
From: Russ Housley <[e-mail]>
Subject: Re: MOTION ON NR
Cc: Ed Gerck <[e-mail]>, "[e-mail]" <[e-mail]>, Nicholas Bohm <[e-mail]>
In-Reply-To: <[e-mail]>
References: <[e-mail]> <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed

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: [phone]   fax: [phone]               LL LLLLLLLL
>email: [e-mail]                                   LLLLLLLL



Received: from dfw-smtpout3.email.verio.net (dfw-smtpout3-ext.email.verio.net [129.250.36.43]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id LAA24156 for <[e-mail]>; Mon, 22 Nov 1999 11:48:37 -0800 (PST)
Received: from dfw-mmp4.email.verio.net ([129.250.38.64]) by dfw-smtpout3.email.verio.net (Netscape Messaging Server 4.05) with ESMTP id FLM74000.EKA for <[e-mail]>; Mon, 22 Nov 1999 19:50:24 +0000 
Received: from nma.com ([209.21.28.76]) by dfw-mmp4.email.verio.net (Netscape Messaging Server 4.05) with ESMTP id FLM73H00.72W; Mon, 22 Nov 1999 19:50:05 +0000 
Message-ID: <[e-mail]>
Date: Mon, 22 Nov 1999 11:51:02 -0800
From: Ed Gerck <[e-mail]>
X-Mailer: Mozilla 4.7 [en]C-CCK-MCD {Sony}  (Win98; I)
X-Accept-Language: en
MIME-Version: 1.0
To: Tony Bartoletti <[e-mail]>
CC: Russ Housley <[e-mail]>, "[e-mail]" <[e-mail]>, Nicholas Bohm <[e-mail]>
Subject: Re: MOTION ON NR
References: <[e-mail]> <[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

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




Received: from dfw-smtpout1.email.verio.net (dfw-smtpout1-ext.email.verio.net [129.250.36.41]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id LAA23879 for <[e-mail]>; Mon, 22 Nov 1999 11:41:01 -0800 (PST)
Received: from dfw-mmp4.email.verio.net ([129.250.38.64]) by dfw-smtpout1.email.verio.net (Netscape Messaging Server 4.05) with ESMTP id FLM6QN00.5B6 for <[e-mail]>; Mon, 22 Nov 1999 19:42:23 +0000 
Received: from nma.com ([209.21.28.76]) by dfw-mmp4.email.verio.net (Netscape Messaging Server 4.05) with ESMTP id FLM6Q100.3XI; Mon, 22 Nov 1999 19:42:01 +0000 
Message-ID: <[e-mail]>
Date: Mon, 22 Nov 1999 11:42:58 -0800
From: Ed Gerck <[e-mail]>
X-Mailer: Mozilla 4.7 [en]C-CCK-MCD {Sony}  (Win98; I)
X-Accept-Language: en
MIME-Version: 1.0
To: Russ Housley <[e-mail]>
CC: "[e-mail]" <[e-mail]>, Nicholas Bohm <[e-mail]>
Subject: Re: MOTION ON NR
References: <[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

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



Received: from poptop.llnl.gov (poptop.llnl.gov [128.115.18.65]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id LAA23576 for <[e-mail]>; Mon, 22 Nov 1999 11:32:07 -0800 (PST)
Received: from catalyst (catalyst.llnl.gov [128.115.223.61]) by poptop.llnl.gov (8.8.8/LLNL-3.0.2/pop.llnl.gov-5.1) with SMTP id LAA09285; Mon, 22 Nov 1999 11:33:44 -0800 (PST)
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.3 (32)
Date: Mon, 22 Nov 1999 11:33:30 -0800
To: Irene Gassko <[e-mail]>
From: Tony Bartoletti <[e-mail]>
Subject: Re: MOTION ON NR
Cc: Russ Housley <[e-mail]>, Ed Gerck <[e-mail]>, "[e-mail]" <[e-mail]>, Nicholas Bohm <[e-mail]>
In-Reply-To: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"

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:	[phone]
>Room 30-2-A31			 e-mail: 	[e-mail]
>N. Andover, MA 01845		 fax: 	[phone]
>
>

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: [phone]   fax: [phone]               LL LLLLLLLL
email: [e-mail]                                   LLLLLLLL


Received: from eng1.certicom.com (mailhost.certicom.com [209.121.99.2]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id LAA23063; Mon, 22 Nov 1999 11:16:25 -0800 (PST)
Received: from domino2.certicom.com (domino2.certicom.com [10.0.1.25]) by eng1.certicom.com (8.8.7/8.8.7) with SMTP id OAA12997; Mon, 22 Nov 1999 14:21:52 -0500 (EST) (envelope-from [e-mail])
Received: by domino2.certicom.com(Lotus SMTP MTA v4.6.4  (830.2 3-23-1999))  id 85256831.0069D4E2 ; Mon, 22 Nov 1999 14:15:57 -0500
X-Lotus-FromDomain: CERTICOM
From: "Don Johnson" <[e-mail]>
To: Russ Housley <[e-mail]>
cc: "John C. Kennedy" <[e-mail]>, [e-mail], [e-mail], [e-mail], [e-mail], [e-mail], [e-mail], [e-mail], [e-mail], [e-mail], Elaine Barker <[e-mail]>, Sharon Keller <[e-mail]>, "Simon Blake-Wilson" <[e-mail]>, "Phil Griffin" <[e-mail]>
Message-ID: <[e-mail]>
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
Mime-Version: 1.0
Content-type: text/plain; charset=us-ascii
Content-Disposition: inline

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 <[e-mail]> on 11/22/99 01:50:56 PM

To:   Don Johnson/Certicom@Certicom
cc:   "John C. Kennedy" <[e-mail]>, [e-mail],
      [e-mail], [e-mail], [e-mail],
      [e-mail], [e-mail], [e-mail], [e-mail],
      [e-mail], Elaine Barker <[e-mail]>, Sharon
      Keller <[e-mail]>, Simon Blake-Wilson/Certicom@Certicom, "Phil
      Griffin" <[e-mail]>

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






Received: from eng1.certicom.com (mailhost.certicom.com [209.121.99.2]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id LAA23064; Mon, 22 Nov 1999 11:16:25 -0800 (PST)
Received: from domino2.certicom.com (domino2.certicom.com [10.0.1.25]) by eng1.certicom.com (8.8.7/8.8.7) with SMTP id OAA13000; Mon, 22 Nov 1999 14:21:52 -0500 (EST) (envelope-from [e-mail])
Received: by domino2.certicom.com(Lotus SMTP MTA v4.6.4  (830.2 3-23-1999))  id 85256831.0069D4A8 ; Mon, 22 Nov 1999 14:15:57 -0500
X-Lotus-FromDomain: CERTICOM
From: "Don Johnson" <[e-mail]>
To: Russ Housley <[e-mail]>
cc: "John C. Kennedy" <[e-mail]>, [e-mail], [e-mail], [e-mail], [e-mail], [e-mail], [e-mail], [e-mail], [e-mail], [e-mail], Elaine Barker <[e-mail]>, Sharon Keller <[e-mail]>, "Simon Blake-Wilson" <[e-mail]>, "Phil Griffin" <[e-mail]>
Message-ID: <[e-mail]>
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
Mime-Version: 1.0
Content-type: text/plain; charset=us-ascii
Content-Disposition: inline

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 <[e-mail]> on 11/22/99 01:50:56 PM

To:   Don Johnson/Certicom@Certicom
cc:   "John C. Kennedy" <[e-mail]>, [e-mail],
      [e-mail], [e-mail], [e-mail],
      [e-mail], [e-mail], [e-mail], [e-mail],
      [e-mail], Elaine Barker <[e-mail]>, Sharon
      Keller <[e-mail]>, Simon Blake-Wilson/Certicom@Certicom, "Phil
      Griffin" <[e-mail]>

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






Received: from ihemlsrv.firewall.lucent.com (ihemail1.lucent.com [192.11.222.161]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id LAA22855 for <[e-mail]>; Mon, 22 Nov 1999 11:12:42 -0800 (PST)
Received: from ihemlsrv.firewall.lucent.com (localhost [127.0.0.1]) by ihemlsrv.firewall.lucent.com (Pro-8.9.3/8.9.3) with ESMTP id OAA28723 for <[e-mail]>; Mon, 22 Nov 1999 14:14:31 -0500 (EST)
Received: from anuxc.mv.lucent.com (h135-13-160-12.lucent.com [135.13.160.12]) by ihemlsrv.firewall.lucent.com (Pro-8.9.3/8.9.3) with ESMTP id OAA28701; Mon, 22 Nov 1999 14:14:30 -0500 (EST)
Received: from irg-pc by anuxc.mv.lucent.com (8.8.8+Sun/EMS-1.5 sol2) id OAA24114; Mon, 22 Nov 1999 14:13:03 -0500 (EST)
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 
Date: Mon, 22 Nov 1999 14:14:47 -0500
To: Tony Bartoletti <[e-mail]>
From: Irene Gassko <[e-mail]>
Subject: Re: MOTION ON NR
Cc: Russ Housley <[e-mail]>, Ed Gerck <[e-mail]>, "[e-mail]" <[e-mail]>, Nicholas Bohm <[e-mail]>
In-Reply-To: <[e-mail]>
References: <[e-mail]> <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"

"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: [phone]   fax: [phone]               LL LLLLLLLL
>email: [e-mail]                                   LLLLLLLL

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


Received: from poptop.llnl.gov (poptop.llnl.gov [128.115.18.65]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id KAA22432 for <[e-mail]>; Mon, 22 Nov 1999 10:53:46 -0800 (PST)
Received: from catalyst (catalyst.llnl.gov [128.115.223.61]) by poptop.llnl.gov (8.8.8/LLNL-3.0.2/pop.llnl.gov-5.1) with SMTP id KAA15209; Mon, 22 Nov 1999 10:55:28 -0800 (PST)
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.3 (32)
Date: Mon, 22 Nov 1999 10:55:14 -0800
To: Russ Housley <[e-mail]>, Ed Gerck <[e-mail]>
From: Tony Bartoletti <[e-mail]>
Subject: Re: MOTION ON NR
Cc: "[e-mail]" <[e-mail]>, Nicholas Bohm <[e-mail]>
In-Reply-To: <[e-mail]>
References: <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"

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: [phone]   fax: [phone]               LL LLLLLLLL
email: [e-mail]                                   LLLLLLLL


Received: from mail.spyrus.com (mail.spyrus.com [207.212.34.20]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id KAA22235; Mon, 22 Nov 1999 10:50:56 -0800 (PST)
Received: from rhousley_laptop.spyrus.com ([209.172.119.101]) by mail.spyrus.com (8.9.3/8.9.3) with ESMTP id KAA03222; Mon, 22 Nov 1999 10:50:44 -0800 (PST)
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58 
Date: Mon, 22 Nov 1999 13:50:56 -0500
To: "Don Johnson" <[e-mail]>
From: Russ Housley <[e-mail]>
Subject: RE: FIPS 186 and X9.42: One of these things is not like the other
Cc: "John C. Kennedy" <[e-mail]>, [e-mail], [e-mail], [e-mail], [e-mail], [e-mail], [e-mail], [e-mail], [e-mail], [e-mail], Elaine Barker <[e-mail]>, Sharon Keller <[e-mail]>, "Simon Blake-Wilson" <[e-mail]>, "Phil Griffin" <[e-mail]>
In-Reply-To: <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed

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


Received: from dfw-smtpout2.email.verio.net (dfw-smtpout2-ext.email.verio.net [129.250.36.42]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id KAA22067 for <[e-mail]>; Mon, 22 Nov 1999 10:47:55 -0800 (PST)
Received: from dfw-mmp4.email.verio.net ([129.250.38.64]) by dfw-smtpout2.email.verio.net (Netscape Messaging Server 4.05) with ESMTP id FLM4AV00.9H3 for <[e-mail]>; Mon, 22 Nov 1999 18:49:43 +0000 
Received: from nma.com ([209.21.28.85]) by dfw-mmp4.email.verio.net (Netscape Messaging Server 4.05) with ESMTP id FLM4AB00.2ZD; Mon, 22 Nov 1999 18:49:23 +0000 
Message-ID: <[e-mail]>
Date: Mon, 22 Nov 1999 10:50:20 -0800
From: Ed Gerck <[e-mail]>
X-Mailer: Mozilla 4.7 [en]C-CCK-MCD {Sony}  (Win98; I)
X-Accept-Language: en
MIME-Version: 1.0
To: Stefan Santesson <[e-mail]>
CC: Aram Perez <[e-mail]>, [e-mail]
Subject: DS and NR bit combinations, Re: proposed key usage text
References: <[e-mail]> <[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

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



Received: from poptop.llnl.gov (poptop.llnl.gov [128.115.18.65]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id KAA21747 for <[e-mail]>; Mon, 22 Nov 1999 10:34:55 -0800 (PST)
Received: from catalyst (catalyst.llnl.gov [128.115.223.61]) by poptop.llnl.gov (8.8.8/LLNL-3.0.2/pop.llnl.gov-5.1) with SMTP id KAA03572; Mon, 22 Nov 1999 10:36:22 -0800 (PST)
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.3 (32)
Date: Mon, 22 Nov 1999 10:36:08 -0800
To: [e-mail]
From: Tony Bartoletti <[e-mail]>
Subject: Re: NR-Bit Truth-In-Advertising
Cc: Tim Polk <[e-mail]>, [e-mail]
In-Reply-To: <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"

At 10:32 PM 11/19/1999 -0500, [e-mail] 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: [phone]   fax: [phone]               LL LLLLLLLL
email: [e-mail]                                   LLLLLLLL


Received: from mail-out2.apple.com (mail-out2.apple.com [17.254.0.51]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id JAA20856 for <[e-mail]>; Mon, 22 Nov 1999 09:34:10 -0800 (PST)
Received: from mailgate1.apple.com (A17-128-100-225.apple.com [17.128.100.225]) by mail-out2.apple.com (8.9.3/8.9.3) with ESMTP id JAA19008 for <[e-mail]>; Mon, 22 Nov 1999 09:35:58 -0800 (PST)
Received: from scv3.apple.com (scv3.apple.com) by mailgate1.apple.com (mailgate1.apple.com- SMTPRS 2.0.15) with ESMTP id <[e-mail]> for <[e-mail]>; Mon, 22 Nov 1999 09:35:54 -0800
Received: from [17.205.41.166] (aram1.apple.com [17.205.41.166]) by scv3.apple.com (8.9.3/8.9.3) with ESMTP id JAA24480 for <[e-mail]>; Mon, 22 Nov 1999 09:35:49 -0800 (PST)
Message-Id: <[e-mail]>
X-Mailer: Microsoft Outlook Express Macintosh Edition - 4.5 (0410)
Date: Mon, 22 Nov 1999 09:35:42 -0800
Subject: Re: proposed key usage text
From: "Aram Perez" <[e-mail]>
To: PKIX <[e-mail]>
MIME-Version: 1.0
X-Priority: 3
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit

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


Received: from mail-out1.apple.com (mail-out1.apple.com [17.254.0.52]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id JAA20556 for <[e-mail]>; Mon, 22 Nov 1999 09:19:40 -0800 (PST)
Received: from mailgate1.apple.com (A17-128-100-225.apple.com [17.128.100.225]) by mail-out1.apple.com (8.9.3/8.9.3) with ESMTP id JAA11010 for <[e-mail]>; Mon, 22 Nov 1999 09:21:29 -0800 (PST)
Received: from scv2.apple.com (scv2.apple.com) by mailgate1.apple.com (mailgate1.apple.com- SMTPRS 2.0.15) with ESMTP id <[e-mail]> for <[e-mail]>; Mon, 22 Nov 1999 09:21:21 -0800
Received: from [17.205.41.166] (aram1.apple.com [17.205.41.166]) by scv2.apple.com (8.9.3/8.9.3) with ESMTP id JAA08457 for <[e-mail]>; Mon, 22 Nov 1999 09:21:20 -0800 (PST)
Message-Id: <[e-mail]>
X-Mailer: Microsoft Outlook Express Macintosh Edition - 4.5 (0410)
Date: Mon, 22 Nov 1999 09:21:20 -0800
Subject: Re: proposed key usage text
From: "Aram Perez" <[e-mail]>
To: PKIX <[e-mail]>
MIME-Version: 1.0
X-Priority: 3
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit

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


Received: from mail-out1.apple.com (mail-out1.apple.com [17.254.0.52]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id JAA20349 for <[e-mail]>; Mon, 22 Nov 1999 09:13:58 -0800 (PST)
Received: from mailgate1.apple.com (A17-128-100-225.apple.com [17.128.100.225]) by mail-out1.apple.com (8.9.3/8.9.3) with ESMTP id JAA09625 for <[e-mail]>; Mon, 22 Nov 1999 09:15:40 -0800 (PST)
Received: from scv2.apple.com (scv2.apple.com) by mailgate1.apple.com (mailgate1.apple.com- SMTPRS 2.0.15) with ESMTP id <[e-mail]> for <[e-mail]>; Mon, 22 Nov 1999 09:14:25 -0800
Received: from [17.205.41.166] (aram1.apple.com [17.205.41.166]) by scv2.apple.com (8.9.3/8.9.3) with ESMTP id JAA07369 for <[e-mail]>; Mon, 22 Nov 1999 09:14:24 -0800 (PST)
Message-Id: <[e-mail]>
X-Mailer: Microsoft Outlook Express Macintosh Edition - 4.5 (0410)
Date: Mon, 22 Nov 1999 09:14:24 -0800
Subject: Re: proposed key usage text
From: "Aram Perez" <[e-mail]>
To: PKIX <[e-mail]>
MIME-Version: 1.0
X-Priority: 3
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit

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


Received: from stingray.missi.ncsc.mil (stingray.missi.ncsc.mil [144.51.50.20]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id IAA19743 for <[e-mail]>; Mon, 22 Nov 1999 08:36:23 -0800 (PST)
Received: from stingray.missi.ncsc.mil (root@localhost) by stingray.missi.ncsc.mil with ESMTP id LAA04811; Mon, 22 Nov 1999 11:36:10 -0500 (EST)
Received: from missi.ncsc.mil (depot.missi.ncsc.mil [144.51.60.1]) by stingray.missi.ncsc.mil with ESMTP id LAA04804; Mon, 22 Nov 1999 11:36:09 -0500 (EST)
Received: from ara.missi.ncsc.mil (ara.missi.ncsc.mil [144.51.58.9]) by missi.ncsc.mil (8.8.8/8.8.8) with ESMTP id LAA19269; Mon, 22 Nov 1999 11:35:25 -0500 (EST)
Received: from ara.missi.ncsc.mil (ara.missi.ncsc.mil [144.51.58.9]) by ara.missi.ncsc.mil (8.9.1b+Sun/8.9.1) with SMTP id LAA16947; Mon, 22 Nov 1999 11:31:07 -0500 (EST)
Message-Id: <[e-mail]>
Date: Mon, 22 Nov 1999 11:31:07 -0500 (EST)
From: "David P. Kemp" <[e-mail]>
Reply-To: "David P. Kemp" <[e-mail]>
Subject: Re: We have to choose serialNumber instead of dnQualifier NOW!!!
To: [e-mail], [e-mail]
Cc: [e-mail], [e-mail], [e-mail], [e-mail], [e-mail], [e-mail], [e-mail], [e-mail], [e-mail], [e-mail], [e-mail], [e-mail], [e-mail]
MIME-Version: 1.0
Content-Type: TEXT/plain; charset=us-ascii
Content-MD5: h/8toLjue5Ovq8uOF9WUAw==
X-Mailer: dtmail 1.3.0 CDE Version 1.3 SunOS 5.7 sun4u sparc

> From: Magnus Nystrom <[e-mail]>
> 
> 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.




Received: from mail.spyrus.com (mail.spyrus.com [207.212.34.20]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id IAA19570 for <[e-mail]>; Mon, 22 Nov 1999 08:34:24 -0800 (PST)
Received: from rhousley_laptop.spyrus.com ([209.172.119.101]) by mail.spyrus.com (8.9.3/8.9.3) with ESMTP id IAA00335; Mon, 22 Nov 1999 08:34:21 -0800 (PST)
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58 
X-Priority: 1 (Highest)
Date: Mon, 22 Nov 1999 11:34:40 -0500
To: Stefan Santesson <[e-mail]>
From: Russ Housley <[e-mail]>
Subject: Re: We have to choose serialNumber instead of dnQualifier NOW!!!
Cc: [e-mail], [e-mail], Ella Paton Bassett <[e-mail]>, [e-mail], [e-mail], [e-mail], [e-mail], [e-mail], [e-mail], [e-mail], [e-mail], [e-mail], [e-mail]
In-Reply-To: <[e-mail]>
References: <[e-mail] > <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"; format=flowed
Content-Transfer-Encoding: 8bit

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                <[e-mail]>
>Accurata AB                     http://www.accurata.se
>Slagthuset                      Tel. [phone]
>211 20  Malmö                   Fax. [phone]
>Sweden                        Mobile [phone]
>
>PGP fingerprint: 89BC 6C79 5B3D 591B 8547  1512 7D11 DBF4 528F 29A0
>-------------------------------------------------------------------



Received: from mail.spyrus.com (mail.spyrus.com [207.212.34.20]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id IAA19394 for <[e-mail]>; Mon, 22 Nov 1999 08:31:09 -0800 (PST)
Received: from rhousley_laptop.spyrus.com ([209.172.119.101]) by mail.spyrus.com (8.9.3/8.9.3) with ESMTP id IAA00191; Mon, 22 Nov 1999 08:31:07 -0800 (PST)
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58 
Date: Mon, 22 Nov 1999 11:31:24 -0500
To: Stefan Santesson <[e-mail]>
From: Russ Housley <[e-mail]>
Subject: Re: proposed key usage text
Cc: "Aram Perez" <[e-mail]>, [e-mail]
In-Reply-To: <[e-mail]>
References: <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed

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




Received: from mail.spyrus.com (mail.spyrus.com [207.212.34.20]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id IAA18807; Mon, 22 Nov 1999 08:06:00 -0800 (PST)
Received: from rhousley_laptop.spyrus.com ([209.172.119.101]) by mail.spyrus.com (8.9.3/8.9.3) with ESMTP id IAA29659; Mon, 22 Nov 1999 08:05:52 -0800 (PST)
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58 
Date: Mon, 22 Nov 1999 11:00:16 -0500
To: "John C. Kennedy" <[e-mail]>
From: Russ Housley <[e-mail]>
Subject: RE: FIPS 186 and X9.42: One of these things is not like the other
Cc: <[e-mail]>, <[e-mail]>, <[e-mail]>, <[e-mail]>, <[e-mail]>, <[e-mail]>, <[e-mail]>, <[e-mail]>, <[e-mail]>, <[e-mail]>
In-Reply-To: <[e-mail]>
References: <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed

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
>[e-mail]
>
>
>
>-----Original Message-----
>From: [e-mail] [mailto:[e-mail]]
>Sent: Sunday, November 21, 1999 1:58 PM
>To: [e-mail]; [e-mail]
>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.



Received: from aunt15.ausys.se (void1.ausys.se [62.20.78.253]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id IAA18732 for <[e-mail]>; Mon, 22 Nov 1999 08:05:23 -0800 (PST)
Received: by aunt15.ausys.se with Internet Mail Service (5.5.2650.21) id <WCBX6AV0>; Mon, 22 Nov 1999 17:06:23 +0100
Message-ID: <[e-mail]>
From: Hans Nilsson <[e-mail]>
To: "'[e-mail]'" <[e-mail]>, Stefan Santesson <[e-mail]>, [e-mail]
Cc: [e-mail], [e-mail], [e-mail]
Subject: RE: We have to choose serialNumber instead of dnQualifier NOW!!!
Date: Mon, 22 Nov 1999 17:06:23 +0100
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain; charset="iso-8859-1"

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:[e-mail]]
Sent: den 22 november 1999 13:40
To: Stefan Santesson
Cc: [e-mail]; Ella Paton Bassett; [e-mail];
[e-mail]; [e-mail]; [e-mail];
[e-mail]; [e-mail];
[e-mail]; [e-mail]; [e-mail];
[e-mail]; [e-mail]
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: [e-mail]
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



Received: from mail.spyrus.com (mail.spyrus.com [207.212.34.20]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id HAA18124 for <[e-mail]>; Mon, 22 Nov 1999 07:29:48 -0800 (PST)
Received: from rhousley_laptop.spyrus.com ([209.172.119.101]) by mail.spyrus.com (8.9.3/8.9.3) with ESMTP id HAA29063; Mon, 22 Nov 1999 07:30:19 -0800 (PST)
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58 
Date: Mon, 22 Nov 1999 10:30:38 -0500
To: Ed Gerck <[e-mail]>
From: Russ Housley <[e-mail]>
Subject: Re: MOTION ON NR
Cc: "[e-mail]" <[e-mail]>, Nicholas Bohm <[e-mail]>
In-Reply-To: <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed

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.



Received: from popmail.inbox.se (popmail.inbox.se [193.12.72.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id GAA17654 for <[e-mail]>; Mon, 22 Nov 1999 06:54:54 -0800 (PST)
Received: from stefan2 (accurata.inbox.se [193.12.72.24]) by popmail.inbox.se (8.9.3/8.9.3) with SMTP id PAA13548; Mon, 22 Nov 1999 15:56:34 +0100
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 
Date: Mon, 22 Nov 1999 15:57:04 +0100
To: [e-mail]
From: Stefan Santesson <[e-mail]>
Subject: Re: We have to choose serialNumber instead of dnQualifier NOW!!!
Cc: [e-mail], Ella Paton Bassett <[e-mail]>, [e-mail], [e-mail], [e-mail], [e-mail], [e-mail], [e-mail], [e-mail], [e-mail], [e-mail], [e-mail], [e-mail], [e-mail]
In-Reply-To: <[e-mail] >
References: <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by ns.secondary.com id GAA17656

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    [phone]
>  Kolumbus Services                Mobile phone [phone]
>  Asemapäällikönkatu 2 (PAD510)    Fax          [phone] 
>  P.O.Box 133                      E-mail       [e-mail]
>  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: [e-mail]
>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                <[e-mail]>
Accurata AB                     http://www.accurata.se
Slagthuset                      Tel. [phone]              
211 20  Malmö                   Fax. [phone]              
Sweden                        Mobile [phone]

PGP fingerprint: 89BC 6C79 5B3D 591B 8547  1512 7D11 DBF4 528F 29A0
-------------------------------------------------------------------


Received: from eng1.certicom.com (mailhost.certicom.com [209.121.99.2]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id GAA17380; Mon, 22 Nov 1999 06:44:13 -0800 (PST)
Received: from domino2.certicom.com (domino2.certicom.com [10.0.1.25]) by eng1.certicom.com (8.8.7/8.8.7) with SMTP id JAA06563; Mon, 22 Nov 1999 09:49:12 -0500 (EST) (envelope-from [e-mail])
Received: by domino2.certicom.com(Lotus SMTP MTA v4.6.4  (830.2 3-23-1999))  id 85256831.0050DC08 ; Mon, 22 Nov 1999 09:43:12 -0500
X-Lotus-FromDomain: CERTICOM
From: "Don Johnson" <[e-mail]>
To: "John C. Kennedy" <[e-mail]>
cc: [e-mail], [e-mail], [e-mail], [e-mail], [e-mail], [e-mail], [e-mail], [e-mail], [e-mail], [e-mail], Elaine Barker <[e-mail]>, Sharon Keller <[e-mail]>, "Simon Blake-Wilson" <[e-mail]>, "Phil Griffin" <[e-mail]>
Message-ID: <[e-mail]>
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
Mime-Version: 1.0
Content-type: text/plain; charset=us-ascii
Content-Disposition: inline

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" <[e-mail]> on 11/21/99 04:17:21 AM

To:   [e-mail], [e-mail], [e-mail],
      [e-mail]
cc:   [e-mail], [e-mail], Don
      Johnson/Certicom@Certicom, [e-mail], [e-mail],
      [e-mail], [e-mail]

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
[e-mail]



-----Original Message-----
From: [e-mail] [mailto:[e-mail]]
Sent: Sunday, November 21, 1999 1:58 PM
To: [e-mail]; [e-mail]
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.







Received: from karon.dynas.se (karon.dynas.se [192.71.43.4]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id EAA15986 for <[e-mail]>; Mon, 22 Nov 1999 04:39:41 -0800 (PST)
Received: (qmail 19106 invoked from network); 22 Nov 1999 12:40:59 -0000
Received: from spirit.sto.dynas.se (HELO spirit.dynas.se) (172.16.1.10) by karon.sto.dynas.se with SMTP; 22 Nov 1999 12:40:59 -0000
Received: (qmail 3140 invoked from network); 22 Nov 1999 12:40:57 -0000
Received: from storas05.dynas.se (HELO MNYSTROM-LAP) (10.129.29.105) by spirit.dynas.se with SMTP; 22 Nov 1999 12:40:57 -0000
Date: Mon, 22 Nov 1999 13:40:24 +0100 (W. Europe Standard Time)
From: Magnus Nystrom <[e-mail]>
Reply-To: [e-mail]
To: Stefan Santesson <[e-mail]>
cc: [e-mail], Ella Paton Bassett <[e-mail]>, [e-mail], [e-mail], [e-mail], [e-mail], [e-mail], [e-mail], [e-mail], [e-mail], [e-mail], [e-mail], [e-mail]
Subject: Re: We have to choose serialNumber instead of dnQualifier NOW!!!
In-Reply-To: <[e-mail]>
Message-ID: <[e-mail]>
X-X-Sender: magnus@[172.16.1.10]
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII

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: [e-mail]
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




Received: from popmail.inbox.se (popmail.inbox.se [193.12.72.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id DAA15315 for <[e-mail]>; Mon, 22 Nov 1999 03:42:55 -0800 (PST)
Received: from stefan2 (accurata.inbox.se [193.12.72.24]) by popmail.inbox.se (8.9.3/8.9.3) with SMTP id MAA10320; Mon, 22 Nov 1999 12:44:24 +0100
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 
Date: Mon, 22 Nov 1999 12:44:53 +0100
To: Ed Gerck <[e-mail]>
From: Stefan Santesson <[e-mail]>
Subject: Re: proposed key usage text
Cc: Aram Perez <[e-mail]>, [e-mail]
In-Reply-To: <[e-mail]>
References: <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by ns.secondary.com id DAA15316

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                <[e-mail]>
Accurata AB                     http://www.accurata.se
Slagthuset                      Tel. [phone]              
211 20  Malmö                   Fax. [phone]              
Sweden                        Mobile [phone]

PGP fingerprint: 89BC 6C79 5B3D 591B 8547  1512 7D11 DBF4 528F 29A0
-------------------------------------------------------------------


Received: from popmail.inbox.se (popmail.inbox.se [193.12.72.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id DAA15072 for <[e-mail]>; Mon, 22 Nov 1999 03:27:03 -0800 (PST)
Received: from stefan2 (accurata.inbox.se [193.12.72.24]) by popmail.inbox.se (8.9.3/8.9.3) with SMTP id MAA10136; Mon, 22 Nov 1999 12:28:22 +0100
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 
X-Priority: 1 (Highest)
Date: Mon, 22 Nov 1999 12:28:51 +0100
To: [e-mail], [e-mail], Ella Paton Bassett <[e-mail]>
From: Stefan Santesson <[e-mail]>
Subject: We have to choose serialNumber instead of dnQualifier NOW!!!
Cc: [e-mail], [e-mail], [e-mail], [e-mail], [e-mail], [e-mail], [e-mail], [e-mail], [e-mail], [e-mail], [e-mail]
In-Reply-To: <[e-mail] >
References: <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by ns.secondary.com id DAA15073

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                <[e-mail]>
Accurata AB                     http://www.accurata.se
Slagthuset                      Tel. [phone]              
211 20  Malmö                   Fax. [phone]              
Sweden                        Mobile [phone]

PGP fingerprint: 89BC 6C79 5B3D 591B 8547  1512 7D11 DBF4 528F 29A0
-------------------------------------------------------------------


Received: from dfw-smtpout1.email.verio.net (dfw-smtpout1-ext.email.verio.net [129.250.36.41]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id CAA12027 for <[e-mail]>; Mon, 22 Nov 1999 02:08:31 -0800 (PST)
Received: from dfw-mmp3.email.verio.net ([129.250.38.63]) by dfw-smtpout1.email.verio.net (Netscape Messaging Server 4.05) with ESMTP id FLLG9100.H4Y for <[e-mail]>; Mon, 22 Nov 1999 10:10:13 +0000 
Received: from nma.com ([209.21.28.71]) by dfw-mmp3.email.verio.net (Netscape Messaging Server 4.05) with ESMTP id FLLG8100.TN9; Mon, 22 Nov 1999 10:09:37 +0000 
Message-ID: <[e-mail]>
Date: Mon, 22 Nov 1999 02:10:47 -0800
From: Ed Gerck <[e-mail]>
X-Mailer: Mozilla 4.7 [en]C-CCK-MCD {Sony}  (Win98; I)
X-Accept-Language: en
MIME-Version: 1.0
To: Stefan Santesson <[e-mail]>
CC: Aram Perez <[e-mail]>, [e-mail]
Subject: Re: proposed key usage text
References: <[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

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



Received: from popmail.inbox.se (popmail.inbox.se [193.12.72.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id BAA11695 for <[e-mail]>; Mon, 22 Nov 1999 01:45:13 -0800 (PST)
Received: from stefan2 (accurata.inbox.se [193.12.72.24]) by popmail.inbox.se (8.9.3/8.9.3) with SMTP id KAA08280; Mon, 22 Nov 1999 10:46:47 +0100
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 
Date: Mon, 22 Nov 1999 10:47:16 +0100
To: "Aram Perez" <[e-mail]>, [e-mail]
From: Stefan Santesson <[e-mail]>
Subject: Re: proposed key usage text
In-Reply-To: <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by ns.secondary.com id BAA11696

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. [phone] , Mobile [phone]   |
|  [e-mail] , http://www.accurata.se  |
-------------------------------------------------


Received: from mail01-ewr.pilot.net (mail-ewr-1.pilot.net [206.98.230.18]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id QAA29658 for <[e-mail]>; Sun, 21 Nov 1999 16:02:15 -0800 (PST)
From: [e-mail]
Received: from mailgw.firstdata.com ([204.48.27.166]) by mail01-ewr.pilot.net with ESMTP id TAA07581 for <[e-mail]>; Sun, 21 Nov 1999 19:04:00 -0500 (EST)
Received: from lnsunr02.firstdata.com ([206.201.60.104]) by mailgw.firstdata.com with SMTP id TAA23191 for <[e-mail]>; Sun, 21 Nov 1999 19:03:59 -0500 (EST)
Received: by lnsunr02.firstdata.com(Lotus SMTP MTA v4.6.5  (863.2 5-20-1999))  id 85256831.000014AD ; Sun, 21 Nov 1999 19:00:52 -0500
X-Lotus-FromDomain: FDC
To: [e-mail]
Message-ID: <[e-mail]>
Date: Sun, 21 Nov 1999 16:02:20 -0800
Subject: somewhat related timer discussion with geoplex
Mime-Version: 1.0
Content-type: text/plain; charset=us-ascii
Content-Disposition: inline

From: Anne & Lynn Wheeler <[e-mail]>
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 <[e-mail]>
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


[e-mail] 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   | [e-mail], [e-mail]
 http://www.garlic.com/~lynn/ http://www.adcomsys.net/lynn/






Received: from gandalf.trustpoint.com (IDENT:[e-mail] [216.100.231.61]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id NAA28554; Sun, 21 Nov 1999 13:36:53 -0800 (PST)
Received: from himansu (himansu [192.168.42.5]) by gandalf.trustpoint.com (8.8.7/8.8.7) with SMTP id NAA06054; Sun, 21 Nov 1999 13:38:17 -0800
From: "John C. Kennedy" <[e-mail]>
To: "Ben Laurie" <[e-mail]>
Cc: <[e-mail]>, <[e-mail]>, <[e-mail]>, <[e-mail]>, <[e-mail]>, <[e-mail]>, <[e-mail]>, <[e-mail]>
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
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300
In-Reply-To: <[e-mail]>
Disposition-Notification-To: "John C. Kennedy" <[e-mail]>

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
[e-mail]

-----Original Message-----
From: Ben Laurie [mailto:[e-mail]]
Sent: Sunday, November 21, 1999 2:44 AM
To: John C. Kennedy
Cc: [e-mail]; [e-mail]; [e-mail];
[e-mail]; [e-mail]; [e-mail];
[e-mail]; [e-mail]; [e-mail]; [e-mail];
[e-mail]
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



Received: from eastwood.aldigital.algroup.co.uk (eastwood.aldigital.algroup.co.uk [194.128.162.193]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id CAA21093; Sun, 21 Nov 1999 02:48:17 -0800 (PST)
Received: from freeby.ben.algroup.co.uk (freeby.ben.algroup.co.uk [193.133.15.6]) by eastwood.aldigital.algroup.co.uk (8.8.8/8.6.12) with ESMTP id KAA09568; Sun, 21 Nov 1999 10:45:36 GMT
Received: from algroup.co.uk (naughty.ben.algroup.co.uk [193.133.15.107]) by freeby.ben.algroup.co.uk (8.6.12/8.6.12) with ESMTP id KAA06724; Sun, 21 Nov 1999 10:44:26 GMT
Message-ID: <[e-mail]>
Date: Sun, 21 Nov 1999 10:44:17 +0000
From: Ben Laurie <[e-mail]>
Organization: A.L. Group plc
X-Mailer: Mozilla 4.7 [en] (WinNT; I)
MIME-Version: 1.0
To: "John C. Kennedy" <[e-mail]>
CC: [e-mail], [e-mail], [e-mail], [e-mail], [e-mail], [e-mail], [e-mail], [e-mail], [e-mail], [e-mail], [e-mail]
Subject: Re: FIPS 186 and X9.42: One of these things is not like the other
References: <[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

"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


Received: from gandalf.trustpoint.com (IDENT:[e-mail] [216.100.231.61]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id BAA19840; Sun, 21 Nov 1999 01:10:44 -0800 (PST)
Received: from himansu (himansu [192.168.42.5]) by gandalf.trustpoint.com (8.8.7/8.8.7) with SMTP id BAA04256; Sun, 21 Nov 1999 01:12:16 -0800
From: "John C. Kennedy" <[e-mail]>
To: <[e-mail]>, <[e-mail]>, <[e-mail]>, <[e-mail]>
Cc: <[e-mail]>, <[e-mail]>, <[e-mail]>, <[e-mail]>, <[e-mail]>, <[e-mail]>, <[e-mail]>
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
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300
In-Reply-To: <[e-mail]>

(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
[e-mail]



-----Original Message-----
From: [e-mail] [mailto:[e-mail]]
Sent: Sunday, November 21, 1999 1:58 PM
To: [e-mail]; [e-mail]
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.



Received: from mail.student.auckland.ac.nz (mail.student.auckland.ac.nz [130.216.35.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id QAA04480; Sat, 20 Nov 1999 16:56:37 -0800 (PST)
Received: from cs26.cs.auckland.ac.nz ([e-mail] [130.216.36.9]) by mail.student.auckland.ac.nz (8.9.3/8.8.6/cs-master) with SMTP id NAA05024; Sun, 21 Nov 1999 13:58:13 +1300 (NZDT) (sender [e-mail])
Received: by cs26.cs.auckland.ac.nz (relaymail v0.9) id <94314589412790>; Sun, 21 Nov 1999 13:58:14 (NZDT)
From: [e-mail] (Peter Gutmann)
To: [e-mail], [e-mail]
Subject: FIPS 186 and X9.42: One of these things is not like the other
Sender: [e-mail]
Reply-To: [e-mail]
X-Charge-To: pgut001
X-Authenticated: relaymail v0.9 on cs26.cs.auckland.ac.nz
Date: Sun, 21 Nov 1999 13:58:14 (NZDT)
Message-ID: <[e-mail]>

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.



Received: from dfw-smtpout2.email.verio.net (dfw-smtpout2-ext.email.verio.net [129.250.36.42]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id NAA02583 for <[e-mail]>; Sat, 20 Nov 1999 13:54:55 -0800 (PST)
Received: from dfw-mmp4.email.verio.net ([129.250.38.64]) by dfw-smtpout2.email.verio.net (Netscape Messaging Server 4.05) with ESMTP id FLINM900.FW8 for <[e-mail]>; Sat, 20 Nov 1999 21:56:33 +0000 
Received: from nma.com ([209.21.28.69]) by dfw-mmp4.email.verio.net (Netscape Messaging Server 4.05) with ESMTP id FLINLP00.KSG for <[e-mail]>; Sat, 20 Nov 1999 21:56:13 +0000 
Message-ID: <[e-mail]>
Date: Sat, 20 Nov 1999 13:57:04 -0800
From: Ed Gerck <[e-mail]>
X-Mailer: Mozilla 4.7 [en]C-CCK-MCD {Sony}  (Win98; I)
X-Accept-Language: en
MIME-Version: 1.0
To: "[e-mail]" <[e-mail]>
Subject: Re: MOTION ON NR
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

[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 <[e-mail]>


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


Received: from dfw-smtpout3.email.verio.net (dfw-smtpout3-ext.email.verio.net [129.250.36.43]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id JAA00630 for <[e-mail]>; Sat, 20 Nov 1999 09:52:53 -0800 (PST)
Received: from dfw-mmp3.email.verio.net ([129.250.38.63]) by dfw-smtpout3.email.verio.net (Netscape Messaging Server 4.05) with ESMTP id FLICEV00.HWW for <[e-mail]>; Sat, 20 Nov 1999 17:54:31 +0000 
Received: from nma.com ([209.21.28.102]) by dfw-mmp3.email.verio.net (Netscape Messaging Server 4.05) with ESMTP id FLICDU00.EIQ; Sat, 20 Nov 1999 17:53:54 +0000 
Message-ID: <[e-mail]>
Date: Sat, 20 Nov 1999 09:55:00 -0800
From: Ed Gerck <[e-mail]>
X-Mailer: Mozilla 4.7 [en]C-CCK-MCD {Sony}  (Win98; I)
X-Accept-Language: en
MIME-Version: 1.0
To: "[e-mail]" <[e-mail]>, Nicholas Bohm <[e-mail]>
Subject: MOTION ON NR
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

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.


Received: from imo21.mx.aol.com (imo21.mx.aol.com [152.163.225.65]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id IAA29877 for <[e-mail]>; Sat, 20 Nov 1999 08:28:04 -0800 (PST)
From: [e-mail]
Received: from [e-mail] by imo21.mx.aol.com (mail_out_v24.4.) id s.0.70fd7dcc (3860); Sat, 20 Nov 1999 11:28:30 -0500 (EST)
Message-ID: <[e-mail]>
Date: Sat, 20 Nov 1999 11:28:29 EST
Subject: Passage of Electronic Signature/Electronic Commerce Bill
To: [e-mail], [e-mail]
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Windows AOL sub 45

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.



Received: from mail01-ewr.pilot.net (mail-ewr-1.pilot.net [206.98.230.18]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id IAA29668 for <[e-mail]>; Sat, 20 Nov 1999 08:13:56 -0800 (PST)
From: [e-mail]
Received: from mailgw.firstdata.com ([204.48.27.166]) by mail01-ewr.pilot.net with ESMTP id LAA28732; Sat, 20 Nov 1999 11:15:34 -0500 (EST)
Received: from lnsunr02.firstdata.com ([206.201.60.104]) by mailgw.firstdata.com with SMTP id LAA08722; Sat, 20 Nov 1999 11:15:33 -0500 (EST)
Received: by lnsunr02.firstdata.com(Lotus SMTP MTA v4.6.5  (863.2 5-20-1999))  id 8525682F.0059067D ; Sat, 20 Nov 1999 11:12:23 -0500
X-Lotus-FromDomain: FDC
To: "Todd Glassey @ GMTsw" <[e-mail]>
cc: [e-mail]
Message-ID: <[e-mail]>
Date: Sat, 20 Nov 1999 08:13:16 -0800
Subject: Re: Certifiedtime.com
Mime-Version: 1.0
Content-type: text/plain; charset=us-ascii
Content-Disposition: inline

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.




Received: from antiochus-fe0.ultra.net (antiochus-fe0.ultra.net [146.115.8.188]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id HAA29083 for <[e-mail]>; Sat, 20 Nov 1999 07:07:15 -0800 (PST)
Received: from DSA (dcbaxter.ultranet.com [146.115.251.52]) by antiochus-fe0.ultra.net (8.8.8/ult/n20340/mtc.v2) with SMTP id KAA20439 for <[e-mail]>; Sat, 20 Nov 1999 10:08:51 -0500 (EST)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID: <14390.47459.169000.755486@DSA>
Date: Sat, 20 Nov 1999 10:08:19 -0500 ()
From: Anne Anderson <[e-mail]>
To: [e-mail]
Subject: PKIX compliance tests
X-Mailer: VM 6.63 under Emacs 19.34.1
Reply-To: Anne Anderson <[e-mail]>

Does anyone know of test suites to test for PKIX compliance?

Anne
-- 
Anne Anderson         email: [e-mail]
28 Minuteman Road
Acton, MA 01720-3840



Received: from e2.ny.us.ibm.com (e2.ny.us.ibm.com [32.97.182.102]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id TAA12475 for <[e-mail]>; Fri, 19 Nov 1999 19:31:14 -0800 (PST)
From: [e-mail]
Received: from northrelay02.pok.ibm.com (northrelay02.pok.ibm.com [9.117.200.22]) by e2.ny.us.ibm.com (8.9.3/8.9.3) with ESMTP id WAA227568; Fri, 19 Nov 1999 22:32:01 -0500
Received: from D51MTA05.pok.ibm.com (d51mta05.pok.ibm.com [9.117.200.33]) by northrelay02.pok.ibm.com (8.8.8m2/NCO v2.06) with SMTP id WAA32506; Fri, 19 Nov 1999 22:32:36 -0500
Received: by D51MTA05.pok.ibm.com(Lotus SMTP MTA v4.6.5  (863.2 5-20-1999))  id 8525682F.00137607 ; Fri, 19 Nov 1999 22:32:33 -0500
X-Lotus-FromDomain: IBMUS
To: Tony Bartoletti <[e-mail]>
cc: Tim Polk <[e-mail]>, [e-mail]
Message-ID: <[e-mail]>
Date: Fri, 19 Nov 1999 22:32:32 -0500
Subject: Re: NR-Bit Truth-In-Advertising
Mime-Version: 1.0
Content-type: text/plain; charset=us-ascii
Content-Disposition: inline

     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 <[e-mail]> on 11/19/99 09:51:28 PM

To:   Tim Polk <[e-mail]>, [e-mail]
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: [phone]   fax: [phone]               LL LLLLLLLL
email: [e-mail]                                   LLLLLLLL





Received: from poptop.llnl.gov (poptop.llnl.gov [128.115.18.65]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id SAA09551 for <[e-mail]>; Fri, 19 Nov 1999 18:50:06 -0800 (PST)
Received: from catalyst (catalyst.llnl.gov [128.115.223.61]) by poptop.llnl.gov (8.8.8/LLNL-3.0.2/pop.llnl.gov-5.1) with SMTP id SAA05860; Fri, 19 Nov 1999 18:51:40 -0800 (PST)
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.3 (32)
Date: Fri, 19 Nov 1999 18:51:28 -0800
To: Tim Polk <[e-mail]>, [e-mail]
From: Tony Bartoletti <[e-mail]>
Subject: NR-Bit Truth-In-Advertising
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"

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: [phone]   fax: [phone]               LL LLLLLLLL
email: [e-mail]                                   LLLLLLLL


Received: from dfw-smtpout1.email.verio.net (dfw-smtpout1-ext.email.verio.net [129.250.36.41]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id QAA03958 for <[e-mail]>; Fri, 19 Nov 1999 16:53:01 -0800 (PST)
Received: from dfw-mmp3.email.verio.net ([129.250.38.63]) by dfw-smtpout1.email.verio.net (Netscape Messaging Server 4.05) with ESMTP id FLH16Z00.9N4 for <[e-mail]>; Sat, 20 Nov 1999 00:54:35 +0000 
Received: from nma.com ([209.21.28.71]) by dfw-mmp3.email.verio.net (Netscape Messaging Server 4.05) with ESMTP id FLH15Z00.MHP; Sat, 20 Nov 1999 00:53:59 +0000 
Message-ID: <[e-mail]>
Date: Fri, 19 Nov 1999 16:55:02 -0800
From: Ed Gerck <[e-mail]>
X-Mailer: Mozilla 4.7 [en]C-CCK-MCD {Sony}  (Win98; I)
X-Accept-Language: en
MIME-Version: 1.0
To: Al Arsenault <[e-mail]>
CC: "David P. Kemp" <[e-mail]>, [e-mail]
Subject: Re: non-ephemeral vs. non-repudiation, was Re: proposed key usage text
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

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



Received: from poptop.llnl.gov (poptop.llnl.gov [128.115.18.65]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id QAA03312 for <[e-mail]>; Fri, 19 Nov 1999 16:23:09 -0800 (PST)
Received: from catalyst (catalyst.llnl.gov [128.115.223.61]) by poptop.llnl.gov (8.8.8/LLNL-3.0.2/pop.llnl.gov-5.1) with SMTP id QAA23993; Fri, 19 Nov 1999 16:24:34 -0800 (PST)
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.3 (32)
Date: Fri, 19 Nov 1999 16:24:22 -0800
To: Al Arsenault <[e-mail]>, Ed Gerck <[e-mail]>
From: Tony Bartoletti <[e-mail]>
Subject: Re: non-ephemeral vs. non-repudiation, was Re: proposed key usagetext
Cc: [e-mail], "David P. Kemp" <[e-mail]>, [e-mail]
In-Reply-To: <[e-mail]>
References: <[e-mail]> <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"

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: [phone]   fax: [phone]               LL LLLLLLLL
email: [e-mail]                                   LLLLLLLL


Received: from crack.x509.com ([e-mail] [199.175.150.1]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id QAA03023 for <[e-mail]>; Fri, 19 Nov 1999 16:14:27 -0800 (PST)
Received: from xcert.com (saxifrage.x509.com [199.175.148.75]) by crack.x509.com (8.9.3/XCERT) with ESMTP id QAA13749 for <[e-mail]>; Fri, 19 Nov 1999 16:16:02 -0800 (PST)
Sender: [e-mail]
Message-ID: <[e-mail]>
Date: Fri, 19 Nov 1999 17:26:16 -0800
From: Marc Branchaud <[e-mail]>
Organization: Xcert International Inc.
X-Mailer: Mozilla 4.7 [en] (X11; U; Linux 2.2.10 i686)
X-Accept-Language: en, fr
MIME-Version: 1.0
To: [e-mail]
Subject: Re: proposed key usage text
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

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


Received: from seine.valicert.com (corporate-gw.valicert.com [63.65.221.2]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id PAA02152 for <[e-mail]>; Fri, 19 Nov 1999 15:37:25 -0800 (PST)
Received: by seine.valicert.com with Internet Mail Service (5.5.2650.21) id <WZF0T923>; Fri, 19 Nov 1999 15:35:35 -0800
Message-ID: <[e-mail]>
From: Peter Williams <[e-mail]>
To: "Todd Glassey @ GMTsw" <[e-mail]>, [e-mail]
Subject: RE: Certifiedtime.com
Date: Fri, 19 Nov 1999 15:35:31 -0800
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain; charset="iso-8859-1"

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:[e-mail]]
> Sent: Friday, November 19, 1999 3:18 PM
> To: [e-mail]
> Cc: [e-mail]
> 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" <[e-mail]>
> To: <[e-mail]>
> Cc: <[e-mail]>
> 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
> 


Received: from poptop.llnl.gov (poptop.llnl.gov [128.115.18.65]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id PAA01865 for <[e-mail]>; Fri, 19 Nov 1999 15:28:21 -0800 (PST)
Received: from catalyst (catalyst.llnl.gov [128.115.223.61]) by poptop.llnl.gov (8.8.8/LLNL-3.0.2/pop.llnl.gov-5.1) with SMTP id PAA26530; Fri, 19 Nov 1999 15:29:54 -0800 (PST)
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.3 (32)
Date: Fri, 19 Nov 1999 15:29:43 -0800
To: [e-mail], [e-mail]
From: Tony Bartoletti <[e-mail]>
Subject: Re: proposed key usage text
In-Reply-To: <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"

At 06:02 PM 11/19/1999 -0500, [e-mail] 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: [phone]   fax: [phone]               LL LLLLLLLL
email: [e-mail]                                   LLLLLLLL


Received: from www.certifeidtime.com. (test.glassey.com [207.126.98.130] (may be forged)) by ns.secondary.com (8.9.3/8.9.3) with SMTP id PAA01546 for <[e-mail]>; Fri, 19 Nov 1999 15:18:06 -0800 (PST)
Received: from gw by www.certifeidtime.com. (SMI-8.6/SMI-SVR4) id PAA21235; Fri, 19 Nov 1999 15:19:17 -0800
Message-ID: <034901bf32e4$73477b60$[e-mail]>
From: "Todd Glassey @ GMTsw" <[e-mail]>
To: <[e-mail]>
Cc: <[e-mail]>
References: <[e-mail]> <030a01bf32c4$eeef1d10$[e-mail]>
Subject: Re: Certifiedtime.com
Date: Fri, 19 Nov 1999 15:18:19 -0800
Organization: GMTsw
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.00.2919.5600
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.5600

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" <[e-mail]>
To: <[e-mail]>
Cc: <[e-mail]>
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



Received: from poptop.llnl.gov (poptop.llnl.gov [128.115.18.65]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id OAA00122 for <[e-mail]>; Fri, 19 Nov 1999 14:54:02 -0800 (PST)
Received: from catalyst (catalyst.llnl.gov [128.115.223.61]) by poptop.llnl.gov (8.8.8/LLNL-3.0.2/pop.llnl.gov-5.1) with SMTP id OAA07265; Fri, 19 Nov 1999 14:55:30 -0800 (PST)
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.3 (32)
Date: Fri, 19 Nov 1999 14:55:19 -0800
To: Marc Branchaud <[e-mail]>, [e-mail]
From: Tony Bartoletti <[e-mail]>
Subject: Re: proposed key usage text
In-Reply-To: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"

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: [phone]   fax: [phone]               LL LLLLLLLL
email: [e-mail]                                   LLLLLLLL


Received: from mail.rdc1.md.home.com ([e-mail] [24.2.2.66]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id OAA29707 for <[e-mail]>; Fri, 19 Nov 1999 14:39:28 -0800 (PST)
Received: from home.com ([24.4.133.54]) by mail.rdc1.md.home.com (InterMail v4.01.01.00 201-229-111) with ESMTP id <[e-mail]>; Fri, 19 Nov 1999 14:41:02 -0800
Message-ID: <[e-mail]>
Date: Fri, 19 Nov 1999 17:37:42 -0500
From: Al Arsenault <[e-mail]>
Organization: @Home Network
X-Mailer: Mozilla 4.61 [en]C-AtHome0407  (Win95; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Ed Gerck <[e-mail]>
CC: [e-mail], "David P. Kemp" <[e-mail]>, [e-mail]
Subject: Re: non-ephemeral vs. non-repudiation, was Re: proposed key usagetext
References: <[e-mail]> <[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

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


Received: from mail.rdc1.md.home.com ([e-mail] [24.2.2.66]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id OAA29425 for <[e-mail]>; Fri, 19 Nov 1999 14:30:36 -0800 (PST)
Received: from home.com ([24.4.133.54]) by mail.rdc1.md.home.com (InterMail v4.01.01.00 201-229-111) with ESMTP id <[e-mail]>; Fri, 19 Nov 1999 14:32:10 -0800
Message-ID: <[e-mail]>
Date: Fri, 19 Nov 1999 17:28:50 -0500
From: Al Arsenault <[e-mail]>
Organization: @Home Network
X-Mailer: Mozilla 4.61 [en]C-AtHome0407  (Win95; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Tony Bartoletti <[e-mail]>
CC: [e-mail], Tim Polk <[e-mail]>, [e-mail]
Subject: Re: proposed key usage text
References: <[e-mail]> <[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

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


Received: from mail.rdc1.md.home.com ([e-mail] [24.2.2.66]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id OAA29211 for <[e-mail]>; Fri, 19 Nov 1999 14:24:17 -0800 (PST)
Received: from home.com ([24.4.133.54]) by mail.rdc1.md.home.com (InterMail v4.01.01.00 201-229-111) with ESMTP id <[e-mail]>; Fri, 19 Nov 1999 14:25:51 -0800
Message-ID: <[e-mail]>
Date: Fri, 19 Nov 1999 17:22:31 -0500
From: Al Arsenault <[e-mail]>
Organization: @Home Network
X-Mailer: Mozilla 4.61 [en]C-AtHome0407  (Win95; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Aram Perez <[e-mail]>
CC: [e-mail]
Subject: Re: proposed key usage text
References: <[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

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.


Received: from mail.rdc1.md.home.com ([e-mail] [24.2.2.66]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id OAA29006 for <[e-mail]>; Fri, 19 Nov 1999 14:17:25 -0800 (PST)
Received: from home.com ([24.4.133.54]) by mail.rdc1.md.home.com (InterMail v4.01.01.00 201-229-111) with ESMTP id <[e-mail]>; Fri, 19 Nov 1999 14:18:59 -0800
Message-ID: <[e-mail]>
Date: Fri, 19 Nov 1999 17:15:39 -0500
From: Al Arsenault <[e-mail]>
Organization: @Home Network
X-Mailer: Mozilla 4.61 [en]C-AtHome0407  (Win95; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Ed Gerck <[e-mail]>
CC: "David P. Kemp" <[e-mail]>, [e-mail]
Subject: Re: non-ephemeral vs. non-repudiation, was Re: proposed key usage text
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

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


Received: from crack.x509.com ([e-mail] [199.175.150.1]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id NAA28309 for <[e-mail]>; Fri, 19 Nov 1999 13:37:03 -0800 (PST)
Received: from xcert.com (saxifrage.x509.com [199.175.148.75]) by crack.x509.com (8.9.3/XCERT) with ESMTP id NAA07933 for <[e-mail]>; Fri, 19 Nov 1999 13:38:35 -0800 (PST)
Sender: [e-mail]
Message-ID: <[e-mail]>
Date: Fri, 19 Nov 1999 14:48:49 -0800
From: Marc Branchaud <[e-mail]>
Organization: Xcert International Inc.
X-Mailer: Mozilla 4.7 [en] (X11; U; Linux 2.2.10 i686)
X-Accept-Language: en, fr
MIME-Version: 1.0
To: [e-mail]
Subject: Re: proposed key usage text
References: <[e-mail]> <[e-mail]> <[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

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


Received: from dfw-smtpout1.email.verio.net (dfw-smtpout1-ext.email.verio.net [129.250.36.41]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id NAA28270 for <[e-mail]>; Fri, 19 Nov 1999 13:36:56 -0800 (PST)
Received: from dfw-mmp2.email.verio.net ([129.250.38.62]) by dfw-smtpout1.email.verio.net (Netscape Messaging Server 4.05) with ESMTP id FLGS4000.8HN for <[e-mail]>; Fri, 19 Nov 1999 21:38:24 +0000 
Received: from nma.com ([209.21.28.93]) by dfw-mmp2.email.verio.net (Netscape Messaging Server 4.05) with ESMTP id FLGS6X00.0C6; Fri, 19 Nov 1999 21:40:09 +0000 
Message-ID: <[e-mail]>
Date: Fri, 19 Nov 1999 13:38:24 -0800
From: Ed Gerck <[e-mail]>
X-Mailer: Mozilla 4.7 [en]C-CCK-MCD {Sony}  (Win98; I)
X-Accept-Language: en
MIME-Version: 1.0
To: [e-mail]
CC: Al Arsenault <[e-mail]>, "David P. Kemp" <[e-mail]>, [e-mail]
Subject: Re: non-ephemeral vs. non-repudiation, was Re: proposed key usagetext
References: <[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

[e-mail] 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



Received: from netscape.com (h-205-217-237-46.netscape.com [205.217.237.46]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id NAA28005 for <[e-mail]>; Fri, 19 Nov 1999 13:25:34 -0800 (PST)
Received: from tintin.mcom.com (tintin.mcom.com [205.217.233.42]) by netscape.com (8.8.5/8.8.5) with ESMTP id NAA26565 for <[e-mail]>; Fri, 19 Nov 1999 13:25:42 -0800 (PST)
Received: from netscape.com ([208.12.62.70]) by tintin.mcom.com (Netscape Messaging Server 4.1) with ESMTP id FLGRKE00.7DV; Fri, 19 Nov 1999 13:26:38 -0800 
Sender: [e-mail] (Terry Hayes)
Message-ID: <[e-mail]>
Date: Fri, 19 Nov 1999 13:26:37 -0800
From: Terry Hayes <[e-mail]>
X-Mailer: Mozilla 4.7 [en] (X11; U; SunOS 5.6 sun4u)
X-Accept-Language: en
MIME-Version: 1.0
To: Marc Branchaud <[e-mail]>
CC: [e-mail]
Subject: Re: proposed key usage text
References: <[e-mail]> <[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

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



Received: from cerebus.i-cube.com (cerebus.i-cube.com [208.229.128.138]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id MAA26750 for <[e-mail]>; Fri, 19 Nov 1999 12:06:04 -0800 (PST)
From: [e-mail]
Received: (from uucp@localhost) by cerebus.i-cube.com (8.9.1/8.8.7) id PAA03624; Fri, 19 Nov 1999 15:18:30 -0500 (EST)
Received: from vinci.i-cube.com(10.1.10.25) via SMTP by ifw.i-cube.com, id smtpd003612; Fri Nov 19 15:18:25 1999
Received: by vinci.i-cube.com(Lotus SMTP MTA v4.6.5  (863.2 5-20-1999))  id 8525682E.006E94FE ; Fri, 19 Nov 1999 15:07:50 -0500
X-Lotus-FromDomain: ICUBE
To: [e-mail]
cc: Ed Gerck <[e-mail]>, [e-mail]
Message-ID: <[e-mail]>
Date: Fri, 19 Nov 1999 15:19:09 -0500
Subject: Re: non-ephemeral vs. non-repudiation, was Re: proposed key usage text
Mime-Version: 1.0
Content-type: text/plain; charset=us-ascii
Content-Disposition: inline

>      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




Received: from crack.x509.com ([e-mail] [199.175.150.1]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id MAA26754 for <[e-mail]>; Fri, 19 Nov 1999 12:06:05 -0800 (PST)
Received: from xcert.com (saxifrage.x509.com [199.175.148.75]) by crack.x509.com (8.9.3/XCERT) with ESMTP id MAA05388 for <[e-mail]>; Fri, 19 Nov 1999 12:07:35 -0800 (PST)
Sender: [e-mail]
Message-ID: <[e-mail]>
Date: Fri, 19 Nov 1999 13:17:44 -0800
From: Marc Branchaud <[e-mail]>
Organization: Xcert International Inc.
X-Mailer: Mozilla 4.7 [en] (X11; U; Linux 2.2.10 i686)
X-Accept-Language: en, fr
MIME-Version: 1.0
To: [e-mail]
Subject: Re: proposed key usage text
References: <[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

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


[e-mail] 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


Received: from e4.ny.us.ibm.com (e4.ny.us.ibm.com [32.97.182.104]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id LAA26215 for <[e-mail]>; Fri, 19 Nov 1999 11:51:22 -0800 (PST)
From: [e-mail]
Received: from northrelay02.pok.ibm.com (northrelay02.pok.ibm.com [9.117.200.22]) by e4.ny.us.ibm.com (8.9.3/8.9.3) with ESMTP id OAA419630; Fri, 19 Nov 1999 14:52:07 -0500
Received: from D51MTA05.pok.ibm.com (d51mta05.pok.ibm.com [9.117.200.33]) by northrelay02.pok.ibm.com (8.8.8m2/NCO v2.06) with SMTP id OAA97262; Fri, 19 Nov 1999 14:52:52 -0500
Received: by D51MTA05.pok.ibm.com(Lotus SMTP MTA v4.6.5  (863.2 5-20-1999))  id 8525682E.006D34F0 ; Fri, 19 Nov 1999 14:52:49 -0500
X-Lotus-FromDomain: IBMUS
To: Al Arsenault <[e-mail]>
cc: Ed Gerck <[e-mail]>, "David P. Kemp" <[e-mail]>, [e-mail]
Message-ID: <[e-mail]>
Date: Fri, 19 Nov 1999 14:52:32 -0500
Subject: Re: non-ephemeral vs. non-repudiation, was Re: proposed key usage text
Mime-Version: 1.0
Content-type: text/plain; charset=us-ascii
Content-Disposition: inline

     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 <[e-mail]> on 11/18/99 09:36:43 PM

To:   Ed Gerck <[e-mail]>
cc:   "David P. Kemp" <[e-mail]>, [e-mail]
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)




Received: from poptop.llnl.gov (poptop.llnl.gov [128.115.18.65]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id LAA26171 for <[e-mail]>; Fri, 19 Nov 1999 11:50:19 -0800 (PST)
Received: from catalyst (catalyst.llnl.gov [128.115.223.61]) by poptop.llnl.gov (8.8.8/LLNL-3.0.2/pop.llnl.gov-5.1) with SMTP id LAA21819; Fri, 19 Nov 1999 11:41:19 -0800 (PST)
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.3 (32)
Date: Fri, 19 Nov 1999 11:41:08 -0800
To: Al Arsenault <[e-mail]>
From: Tony Bartoletti <[e-mail]>
Subject: Re: proposed key usage text
Cc: [e-mail], Tim Polk <[e-mail]>, [e-mail]
In-Reply-To: <[e-mail]>
References: <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"

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: [phone]   fax: [phone]               LL LLLLLLLL
email: [e-mail]                                   LLLLLLLL


Received: from www.certifeidtime.com. (test.glassey.com [207.126.98.130] (may be forged)) by ns.secondary.com (8.9.3/8.9.3) with SMTP id LAA24486 for <[e-mail]>; Fri, 19 Nov 1999 11:32:42 -0800 (PST)
Received: from gw by www.certifeidtime.com. (SMI-8.6/SMI-SVR4) id LAA21048; Fri, 19 Nov 1999 11:33:43 -0800
Message-ID: <030a01bf32c4$eeef1d10$[e-mail]>
From: "Todd Glassey @ GMTsw" <[e-mail]>
To: <[e-mail]>
Cc: <[e-mail]>
References: <[e-mail]>
Subject: Certifiedtime.com
Date: Fri, 19 Nov 1999 11:32:43 -0800
Organization: GMTsw
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.00.2919.5600
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.5600

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




Received: from flash.securant.com (flash.sys.sirrus.com [206.234.199.130]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id KAA18010 for <[e-mail]>; Fri, 19 Nov 1999 10:22:00 -0800 (PST)
Received: from snagglepuss ([206.234.199.189]) by flash.securant.com (8.9.3/8.8.5) with SMTP id KAA07660 for <[e-mail]>; Fri, 19 Nov 1999 10:28:48 -0800
Reply-To: <[e-mail]>
From: "Jeffrey Hyman" <[e-mail]>
To: <[e-mail]>
Subject: unsubscribe
Date: Fri, 19 Nov 1999 10:21:21 -0800
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.2106.4

unsubscribe


Received: from flash.securant.com (flash.sys.sirrus.com [206.234.199.130]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id KAA17914 for <[e-mail]>; Fri, 19 Nov 1999 10:11:58 -0800 (PST)
Received: from snagglepuss ([206.234.199.189]) by flash.securant.com (8.9.3/8.8.5) with SMTP id KAA07536 for <[e-mail]>; Fri, 19 Nov 1999 10:18:45 -0800
Reply-To: <[e-mail]>
From: "Jeffrey Hyman" <[e-mail]>
To: <[e-mail]>
Subject: UNSUBSCRIBE
Date: Fri, 19 Nov 1999 10:11:18 -0800
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.2106.4
In-Reply-To: <[e-mail]>

UNSUBSCRIBE


Received: from mail02-ewr.pilot.net (mail-ewr-2.pilot.net [206.98.230.16]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id JAA17056 for <[e-mail]>; Fri, 19 Nov 1999 09:05:32 -0800 (PST)
From: [e-mail]
Received: from mailgw.firstdata.com ([204.48.27.166]) by mail02-ewr.pilot.net with ESMTP id MAA07081; Fri, 19 Nov 1999 12:07:05 -0500 (EST)
Received: from lnsunr02.firstdata.com ([206.201.60.104]) by mailgw.firstdata.com with SMTP id MAA28105; Fri, 19 Nov 1999 12:07:04 -0500 (EST)
Received: by lnsunr02.firstdata.com(Lotus SMTP MTA v4.6.5  (863.2 5-20-1999))  id 8525682E.005DBE73 ; Fri, 19 Nov 1999 12:03:56 -0500
X-Lotus-FromDomain: FDC
To: "Aram Perez" <[e-mail]>
cc: [e-mail]
Message-ID: <[e-mail]>
Date: Fri, 19 Nov 1999 09:02:34 -0800
Subject: Re: proposed key usage text
Mime-Version: 1.0
Content-type: text/plain; charset=us-ascii
Content-Disposition: inline

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




Received: from mail-out1.apple.com (mail-out1.apple.com [17.254.0.52]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id IAA16270 for <[e-mail]>; Fri, 19 Nov 1999 08:20:14 -0800 (PST)
Received: from mailgate1.apple.com (A17-128-100-225.apple.com [17.128.100.225]) by mail-out1.apple.com (8.9.3/8.9.3) with ESMTP id IAA21123 for <[e-mail]>; Fri, 19 Nov 1999 08:21:47 -0800 (PST)
Received: from scv3.apple.com (scv3.apple.com) by mailgate1.apple.com (mailgate1.apple.com- SMTPRS 2.0.15) with ESMTP id <[e-mail]> for <[e-mail]>; Fri, 19 Nov 1999 08:21:44 -0800
Received: from [17.219.25.199] ([17.219.25.199]) by scv3.apple.com (8.9.3/8.9.3) with ESMTP id IAA10788 for <[e-mail]>; Fri, 19 Nov 1999 08:21:43 -0800 (PST)
Message-Id: <[e-mail]>
X-Mailer: Microsoft Outlook Express Macintosh Edition - 4.5 (0410)
Date: Fri, 19 Nov 1999 08:21:41 -0800
Subject: Re: proposed key usage text
From: "Aram Perez" <[e-mail]>
To: [e-mail]
MIME-Version: 1.0
X-Priority: 3
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit

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


Received: from dfw-smtpout2.email.verio.net (dfw-smtpout2-ext.email.verio.net [129.250.36.42]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id HAA15714 for <[e-mail]>; Fri, 19 Nov 1999 07:47:37 -0800 (PST)
Received: from dfw-mmp1.email.verio.net ([129.250.38.61]) by dfw-smtpout2.email.verio.net (Netscape Messaging Server 4.05) with ESMTP id FLGBXY00.ADV for <[e-mail]>; Fri, 19 Nov 1999 15:49:10 +0000 
Received: from nma.com ([209.21.28.118]) by dfw-mmp1.email.verio.net (Netscape Messaging Server 4.05) with ESMTP id FLGBXD00.T6L; Fri, 19 Nov 1999 15:48:49 +0000 
Message-ID: <[e-mail]>
Date: Fri, 19 Nov 1999 07:49:16 -0800
From: Ed Gerck <[e-mail]>
X-Mailer: Mozilla 4.7 [en]C-CCK-MCD {Sony}  (Win98; I)
X-Accept-Language: en
MIME-Version: 1.0
To: Russ Housley <[e-mail]>
CC: Stefan Santesson <[e-mail]>, [e-mail]
Subject: Re: non-repudiation, was Re: proposed key usage text
References: <[e-mail]> <[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

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.



Received: from mail.spyrus.com (mail.spyrus.com [207.212.34.20]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id GAA14732 for <[e-mail]>; Fri, 19 Nov 1999 06:48:57 -0800 (PST)
Received: from rhousley_laptop.spyrus.com ([209.172.119.101]) by mail.spyrus.com (8.9.3/8.9.3) with ESMTP id GAA19374; Fri, 19 Nov 1999 06:48:44 -0800 (PST)
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58 
Date: Fri, 19 Nov 1999 09:32:55 -0500
To: Ed Gerck <[e-mail]>
From: Russ Housley <[e-mail]>
Subject: Re: non-repudiation, was Re: proposed key usage text
Cc: Stefan Santesson <[e-mail]>, [e-mail]
In-Reply-To: <[e-mail]>
References: <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed

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



Received: from mail.spyrus.com (mail.spyrus.com [207.212.34.20]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id GAA14212 for <[e-mail]>; Fri, 19 Nov 1999 06:20:01 -0800 (PST)
Received: from rhousley_laptop.spyrus.com ([209.172.119.101]) by mail.spyrus.com (8.9.3/8.9.3) with ESMTP id GAA18934; Fri, 19 Nov 1999 06:20:25 -0800 (PST)
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58 
Date: Fri, 19 Nov 1999 09:15:13 -0500
To: [e-mail]
From: Russ Housley <[e-mail]>
Subject: Re: proposed key usage text
Cc: [e-mail]
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed

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


Received: from bastion4.mail.sprint.com (bastion4.mail.sprint.com [208.4.28.132]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id GAA13898 for <[e-mail]>; Fri, 19 Nov 1999 06:13:17 -0800 (PST)
Received: from sii01.mail.sprint.com by bastion4.mail.sprint.com with ESMTP for [e-mail]; Fri, 19 Nov 1999 08:14:09 -0600
Received: from [144.223.128.84] by sii01.mail.sprint.com with ESMTP; Fri, 19 Nov 1999 08:14:04 -0600
Received: from kcopmp04.corp.sprint.com (kcopmp04 [144.223.148.133]) by kcopmh01.corp.sprint.com (8.8.6 (PHNE_17135)/8.8.6) with ESMTP id IAA28183 for <[e-mail]>; Fri, 19 Nov 1999 08:14:03 -0600 (CST)
From: Steve Cummings <[e-mail]>
Received: from localhost (root@localhost) by kcopmp04.corp.sprint.com (8.8.6 (PHNE_17190)/8.8.6) with ESMTP id IAA12220 for <[e-mail]>; Fri, 19 Nov 1999 08:14:02 -0600 (CST)
X-OpenMail-Hops: 1
Date: Fri, 19 Nov 1999 08:14:01 -0600
Message-Id: <H00012d106627196.0943020839.kcopmp04@MHS>
Subject: subscribe
TO: [e-mail]
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="openmail-part-166c861d-00000001"

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



Received: from NotesSmtp.eycan.com (mail2.eycan.com [209.226.9.197]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id GAA13789 for <[e-mail]>; Fri, 19 Nov 1999 06:11:15 -0800 (PST)
From: [e-mail]
Received: by NotesSmtp.eycan.com(Lotus SMTP MTA v1.2  (600.1 3-26-1998))  id 8525682E.004E0501 ; Fri, 19 Nov 1999 09:12:10 -0500
X-Lotus-FromDomain: EY-CANADA@INTERNET
To: [e-mail]
Message-ID: <[e-mail]>
Date: Tue, 16 Nov 1999 18:11:43 -0500
Subject: remove


Received: from ext-mail.valicert.com (ns1.valicert.com [63.65.221.10]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id AAA05124 for <[e-mail]>; Fri, 19 Nov 1999 00:49:38 -0800 (PST)
Received: from mercury (root@[63.65.221.8]) by ext-mail.valicert.com (8.9.3/8.9.3) with SMTP id AAA17397 for <[e-mail]>; Fri, 19 Nov 1999 00:51:09 -0800 (PST)
From: "Khaja E. Ahmed" <[e-mail]>
To: <[e-mail]>
Subject: ANSI X9.79 - CA Control Objectives.
Date: Fri, 19 Nov 1999 00:47:29 -0800
Message-ID: <000a01bf326a$b6867310$[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2014.211
Importance: Normal
In-Reply-To: <001401bf2aea$05f88470$[e-mail]>

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




Received: from dfw-smtpout1.email.verio.net (dfw-smtpout1-ext.email.verio.net [129.250.36.41]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id XAA01298 for <[e-mail]>; Thu, 18 Nov 1999 23:07:14 -0800 (PST)
Received: from dfw-mmp2.email.verio.net ([129.250.38.62]) by dfw-smtpout1.email.verio.net (Netscape Messaging Server 4.05) with ESMTP id FLFNUK00.GX8 for <[e-mail]>; Fri, 19 Nov 1999 07:08:44 +0000 
Received: from nma.com ([209.21.28.126]) by dfw-mmp2.email.verio.net (Netscape Messaging Server 4.05) with ESMTP id FLFNEO00.F1W; Fri, 19 Nov 1999 06:59:12 +0000 
Message-ID: <[e-mail]>
Date: Thu, 18 Nov 1999 22:57:34 -0800
From: Ed Gerck <[e-mail]>
X-Mailer: Mozilla 4.7 [en]C-CCK-MCD {Sony}  (Win98; I)
X-Accept-Language: en
MIME-Version: 1.0
To: Al Arsenault <[e-mail]>
CC: "David P. Kemp" <[e-mail]>, [e-mail]
Subject: Re: non-ephemeral vs. non-repudiation, was Re: proposed key usage text
References: <[e-mail]> <[e-mail]> <[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

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



Received: from mail.rdc1.md.home.com ([e-mail] [24.2.2.66]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id TAA19212 for <[e-mail]>; Thu, 18 Nov 1999 19:13:47 -0800 (PST)
Received: from home.com ([24.4.133.54]) by mail.rdc1.md.home.com (InterMail v4.01.01.00 201-229-111) with ESMTP id <[e-mail]>; Thu, 18 Nov 1999 19:15:17 -0800
Message-ID: <[e-mail]>
Date: Thu, 18 Nov 1999 22:11:56 -0500
From: Al Arsenault <[e-mail]>
Organization: @Home Network
X-Mailer: Mozilla 4.61 [en]C-AtHome0407  (Win95; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Tony Bartoletti <[e-mail]>
CC: [e-mail], Tim Polk <[e-mail]>, [e-mail]
Subject: Re: proposed key usage text
References: <[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

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


Received: from mail.rdc1.md.home.com ([e-mail] [24.2.2.66]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id SAA17207 for <[e-mail]>; Thu, 18 Nov 1999 18:56:00 -0800 (PST)
Received: from home.com ([24.4.133.54]) by mail.rdc1.md.home.com (InterMail v4.01.01.00 201-229-111) with ESMTP id <[e-mail]>; Thu, 18 Nov 1999 18:57:30 -0800
Message-ID: <[e-mail]>
Date: Thu, 18 Nov 1999 21:54:10 -0500
From: Al Arsenault <[e-mail]>
Organization: @Home Network
X-Mailer: Mozilla 4.61 [en]C-AtHome0407  (Win95; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Peter Williams <[e-mail]>
CC: Russ Housley <[e-mail]>, "'[e-mail]'" <[e-mail]>
Subject: Re: Forward-dated entries in a CRL
References: <[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

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.


Received: from mail.rdc1.md.home.com ([e-mail] [24.2.2.66]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id SAA15600 for <[e-mail]>; Thu, 18 Nov 1999 18:38:34 -0800 (PST)
Received: from home.com ([24.4.133.54]) by mail.rdc1.md.home.com (InterMail v4.01.01.00 201-229-111) with ESMTP id <[e-mail]>; Thu, 18 Nov 1999 18:40:04 -0800
Message-ID: <[e-mail]>
Date: Thu, 18 Nov 1999 21:36:43 -0500
From: Al Arsenault <[e-mail]>
Organization: @Home Network
X-Mailer: Mozilla 4.61 [en]C-AtHome0407  (Win95; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Ed Gerck <[e-mail]>
CC: "David P. Kemp" <[e-mail]>, [e-mail]
Subject: Re: non-ephemeral vs. non-repudiation, was Re: proposed key usage text
References: <[e-mail]> <[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

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


Received: from po1.bbn.com (PO1.BBN.COM [192.1.50.38]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id QAA09873 for <[e-mail]>; Thu, 18 Nov 1999 16:34:25 -0800 (PST)
Received: from [171.78.30.108] (comsecpb.bbn.com [171.78.30.108]) by po1.bbn.com (8.9.1/8.9.1) with ESMTP id TAA23907; Thu, 18 Nov 1999 19:35:53 -0500 (EST)
Mime-Version: 1.0
X-Sender: [e-mail]
Message-Id: <v04220800b45a4baa0110@[171.78.30.108]>
In-Reply-To: <[e-mail]>
References: <[e-mail]>		 <[e-mail]> <v0422080bb45a18600123@[171.78.30.108]>	 <[e-mail]> <v04220816b45a31f0f36c@[171.78.30.108]> <[e-mail]>
Date: Thu, 18 Nov 1999 19:35:40 -0500
To: Ed Gerck <[e-mail]>
From: Stephen Kent <[e-mail]>
Subject: Re: non-ephemeral vs. non-repudiation, was Re: proposed keyusagetext
Cc: [e-mail]
Content-Type: text/plain; charset="us-ascii" ; format="flowed"

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


Received: from seine.valicert.com (corporate-gw.valicert.com [63.65.221.2]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id QAA09658 for <[e-mail]>; Thu, 18 Nov 1999 16:30:30 -0800 (PST)
Received: by seine.valicert.com with Internet Mail Service (5.5.2650.21) id <WZF0T7RF>; Thu, 18 Nov 1999 16:28:39 -0800
Message-ID: <[e-mail]>
From: Peter Williams <[e-mail]>
To: Ed Gerck <[e-mail]>
Cc: [e-mail]
Subject: RE: non-repudiation, was Re: proposed key usage text
Date: Thu, 18 Nov 1999 16:28:37 -0800
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain; charset="iso-8859-1"

This mail discusses NR. You are warned to
pass by, if you have real work to do.

> -----Original Message-----
> From: Ed Gerck [mailto:[e-mail]]
> Sent: Thursday, November 18, 1999 2:12 PM
> To: David P. Kemp
> Cc: [e-mail]
> 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 <[e-mail]>
> > >
> > > 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
> 


Received: from dfw-smtpout1.email.verio.net (dfw-smtpout1-ext.email.verio.net [129.250.36.41]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id QAA09393 for <[e-mail]>; Thu, 18 Nov 1999 16:23:00 -0800 (PST)
Received: from dfw-mmp4.email.verio.net ([129.250.38.64]) by dfw-smtpout1.email.verio.net (Netscape Messaging Server 4.05) with ESMTP id FLF54U00.LO9 for <[e-mail]>; Fri, 19 Nov 1999 00:24:30 +0000 
Received: from nma.com ([209.21.28.94]) by dfw-mmp4.email.verio.net (Netscape Messaging Server 4.05) with ESMTP id FLF54900.NC1; Fri, 19 Nov 1999 00:24:09 +0000 
Message-ID: <[e-mail]>
Date: Thu, 18 Nov 1999 16:24:45 -0800
From: Ed Gerck <[e-mail]>
X-Mailer: Mozilla 4.7 [en]C-CCK-MCD {Sony}  (Win98; I)
X-Accept-Language: en
MIME-Version: 1.0
To: Stephen Kent <[e-mail]>
CC: [e-mail]
Subject: Re: non-ephemeral vs. non-repudiation, was Re: proposed keyusagetext
References: <[e-mail]>	 <[e-mail]> <v0422080bb45a18600123@[171.78.30.108]> <[e-mail]> <v04220816b45a31f0f36c@[171.78.30.108]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

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



Received: from po1.bbn.com (PO1.BBN.COM [192.1.50.38]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id QAA08929 for <[e-mail]>; Thu, 18 Nov 1999 16:06:45 -0800 (PST)
Received: from [171.78.30.108] (comsecpb.bbn.com [171.78.30.108]) by po1.bbn.com (8.9.1/8.9.1) with ESMTP id TAA22288; Thu, 18 Nov 1999 19:08:12 -0500 (EST)
Mime-Version: 1.0
X-Sender: [e-mail]
Message-Id: <v04220816b45a31f0f36c@[171.78.30.108]>
In-Reply-To: <[e-mail]>
References: <[e-mail]>	 <[e-mail]> <v0422080bb45a18600123@[171.78.30.108]> <[e-mail]>
Date: Thu, 18 Nov 1999 17:46:52 -0500
To: Ed Gerck <[e-mail]>
From: Stephen Kent <[e-mail]>
Subject: Re: non-ephemeral vs. non-repudiation, was Re: proposed key usagetext
Cc: [e-mail]
Content-Type: text/plain; charset="us-ascii" ; format="flowed"

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



Received: from dfw-smtpout4.email.verio.net (dfw-smtpout4-ext.email.verio.net [129.250.36.44]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id OAA07366 for <[e-mail]>; Thu, 18 Nov 1999 14:25:52 -0800 (PST)
Received: from dfw-mmp1.email.verio.net ([129.250.38.61]) by dfw-smtpout4.email.verio.net (Netscape Messaging Server 4.05) with ESMTP id FLEZNK00.P2I for <[e-mail]>; Thu, 18 Nov 1999 22:26:08 +0000 
Received: from nma.com ([209.21.28.123]) by dfw-mmp1.email.verio.net (Netscape Messaging Server 4.05) with ESMTP id FLEZN000.0BK; Thu, 18 Nov 1999 22:25:48 +0000 
Message-ID: <[e-mail]>
Date: Thu, 18 Nov 1999 14:26:25 -0800
From: Ed Gerck <[e-mail]>
X-Mailer: Mozilla 4.7 [en]C-CCK-MCD {Sony}  (Win98; I)
X-Accept-Language: en
MIME-Version: 1.0
To: Stephen Kent <[e-mail]>
CC: [e-mail]
Subject: Re: non-ephemeral vs. non-repudiation, was Re: proposed key usagetext
References: <[e-mail]> <[e-mail]> <v0422080bb45a18600123@[171.78.30.108]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

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



Received: from dfw-smtpout3.email.verio.net (dfw-smtpout3-ext.email.verio.net [129.250.36.43]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id OAA07024 for <[e-mail]>; Thu, 18 Nov 1999 14:10:40 -0800 (PST)
Received: from dfw-mmp3.email.verio.net ([129.250.38.63]) by dfw-smtpout3.email.verio.net (Netscape Messaging Server 4.05) with ESMTP id FLEZ0900.3SO for <[e-mail]>; Thu, 18 Nov 1999 22:12:09 +0000 
Received: from nma.com ([209.21.28.123]) by dfw-mmp3.email.verio.net (Netscape Messaging Server 4.05) with ESMTP id FLEYZ800.MAI; Thu, 18 Nov 1999 22:11:32 +0000 
Message-ID: <[e-mail]>
Date: Thu, 18 Nov 1999 14:12:25 -0800
From: Ed Gerck <[e-mail]>
X-Mailer: Mozilla 4.7 [en]C-CCK-MCD {Sony}  (Win98; I)
X-Accept-Language: en
MIME-Version: 1.0
To: "David P. Kemp" <[e-mail]>
CC: [e-mail]
Subject: Re: non-repudiation, was Re: proposed key usage text
References: <[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

"David P. Kemp" wrote:

> > Date: Thu, 18 Nov 1999 12:02:54 -0800
> > From: Ed Gerck <[e-mail]>
> >
> > 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



Received: from po1.bbn.com (PO1.BBN.COM [192.1.50.38]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id NAA05938 for <[e-mail]>; Thu, 18 Nov 1999 13:14:10 -0800 (PST)
Received: from [171.78.30.108] (comsecpb.bbn.com [171.78.30.108]) by po1.bbn.com (8.9.1/8.9.1) with ESMTP id QAA03542; Thu, 18 Nov 1999 16:15:37 -0500 (EST)
Mime-Version: 1.0
X-Sender: [e-mail]
Message-Id: <v0422080bb45a18600123@[171.78.30.108]>
In-Reply-To: <[e-mail]>
References: <[e-mail]> <[e-mail]>
Date: Thu, 18 Nov 1999 15:59:22 -0500
To: Ed Gerck <[e-mail]>
From: Stephen Kent <[e-mail]>
Subject: Re: non-ephemeral vs. non-repudiation, was Re: proposed key usage text
Cc: [e-mail]
Content-Type: text/plain; charset="us-ascii" ; format="flowed"

Ed,

>"David P. Kemp" wrote:
>
>  > > From: Stefan Santesson <[e-mail]>
>  > >
>  > > 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



Received: from stingray.missi.ncsc.mil (stingray.missi.ncsc.mil [144.51.50.20]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id MAA05552 for <[e-mail]>; Thu, 18 Nov 1999 12:59:03 -0800 (PST)
Received: from stingray.missi.ncsc.mil (root@localhost) by stingray.missi.ncsc.mil with ESMTP id QAA28669 for <[e-mail]>; Thu, 18 Nov 1999 16:00:55 -0500 (EST)
Received: from missi.ncsc.mil (depot.missi.ncsc.mil [144.51.60.1]) by stingray.missi.ncsc.mil with ESMTP id QAA28665 for <[e-mail]>; Thu, 18 Nov 1999 16:00:54 -0500 (EST)
Received: from ara.missi.ncsc.mil (ara.missi.ncsc.mil [144.51.58.9]) by missi.ncsc.mil (8.8.8/8.8.8) with ESMTP id QAA19773 for <[e-mail]>; Thu, 18 Nov 1999 16:00:11 -0500 (EST)
Received: from ara.missi.ncsc.mil (ara.missi.ncsc.mil [144.51.58.9]) by ara.missi.ncsc.mil (8.9.1b+Sun/8.9.1) with SMTP id PAA15630 for <[e-mail]>; Thu, 18 Nov 1999 15:56:01 -0500 (EST)
Message-Id: <[e-mail]>
Date: Thu, 18 Nov 1999 15:56:01 -0500 (EST)
From: "David P. Kemp" <[e-mail]>
Reply-To: "David P. Kemp" <[e-mail]>
Subject: Re: non-repudiation, was Re: proposed key usage text
To: [e-mail]
MIME-Version: 1.0
Content-Type: TEXT/plain; charset=us-ascii
Content-MD5: w9BrEK2NZfEmSX0AOEfQbg==
X-Mailer: dtmail 1.3.0 CDE Version 1.3 SunOS 5.7 sun4u sparc

> Date: Thu, 18 Nov 1999 12:02:54 -0800
> From: Ed Gerck <[e-mail]>
> 
> 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.




Received: from flash.securant.com (flash.sys.sirrus.com [206.234.199.130]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id MAA04922 for <[e-mail]>; Thu, 18 Nov 1999 12:15:44 -0800 (PST)
Received: from snagglepuss ([206.234.199.189]) by flash.securant.com (8.9.3/8.8.5) with SMTP id MAA31832 for <[e-mail]>; Thu, 18 Nov 1999 12:22:31 -0800
Reply-To: <[e-mail]>
From: "Jeffrey Hyman" <[e-mail]>
To: <[e-mail]>
Subject: usubscribe
Date: Thu, 18 Nov 1999 12:15:02 -0800
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.2106.4
In-Reply-To: <[e-mail]>

unsubscribe



Received: from poptop.llnl.gov (poptop.llnl.gov [128.115.18.65]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id MAA04702 for <[e-mail]>; Thu, 18 Nov 1999 12:11:21 -0800 (PST)
Received: from catalyst (catalyst.llnl.gov [128.115.223.61]) by poptop.llnl.gov (8.8.8/LLNL-3.0.2/pop.llnl.gov-5.1) with SMTP id MAA15451; Thu, 18 Nov 1999 12:12:39 -0800 (PST)
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.3 (32)
Date: Thu, 18 Nov 1999 12:12:28 -0800
To: [e-mail], [e-mail]
From: Tony Bartoletti <[e-mail]>
Subject: Re: proposed key usage text
In-Reply-To: <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"

At 04:26 PM 11/18/1999, Peter Gutmann wrote:
>Tony Bartoletti <[e-mail]> 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: [phone]   fax: [phone]               LL LLLLLLLL
email: [e-mail]                                   LLLLLLLL


Received: from dfw-smtpout3.email.verio.net (dfw-smtpout3-ext.email.verio.net [129.250.36.43]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id MAA04350 for <[e-mail]>; Thu, 18 Nov 1999 12:01:09 -0800 (PST)
Received: from dfw-mmp1.email.verio.net ([129.250.38.61]) by dfw-smtpout3.email.verio.net (Netscape Messaging Server 4.05) with ESMTP id FLET0D00.0MO for <[e-mail]>; Thu, 18 Nov 1999 20:02:37 +0000 
Received: from nma.com ([209.21.28.77]) by dfw-mmp1.email.verio.net (Netscape Messaging Server 4.05) with ESMTP id FLESZT00.396; Thu, 18 Nov 1999 20:02:17 +0000 
Message-ID: <[e-mail]>
Date: Thu, 18 Nov 1999 12:02:54 -0800
From: Ed Gerck <[e-mail]>
X-Mailer: Mozilla 4.7 [en]C-CCK-MCD {Sony}  (Win98; I)
X-Accept-Language: en
MIME-Version: 1.0
To: Stefan Santesson <[e-mail]>
CC: [e-mail]
Subject: Re: non-repudiation, was Re: proposed key usage text
References: <[e-mail]> <[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

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



Received: from popmail.inbox.se (popmail.inbox.se [193.12.72.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id LAA03779 for <[e-mail]>; Thu, 18 Nov 1999 11:34:02 -0800 (PST)
Received: from foo.telia.se (t4o68p73.telia.com [62.20.139.193]) by popmail.inbox.se (8.9.3/8.9.3) with SMTP id UAA14050; Thu, 18 Nov 1999 20:35:26 +0100
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 
Date: Thu, 18 Nov 1999 20:37:09 +0100
To: Ed Gerck <[e-mail]>
From: Stefan Santesson <[e-mail]>
Subject: Re: non-repudiation, was Re: proposed key usage text
Cc: [e-mail]
In-Reply-To: <[e-mail]>
References: <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"

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



Received: from seine.valicert.com (corporate-gw.valicert.com [63.65.221.2]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id LAA03135 for <[e-mail]>; Thu, 18 Nov 1999 11:06:34 -0800 (PST)
Received: by seine.valicert.com with Internet Mail Service (5.5.2650.21) id <WZF0T609>; Thu, 18 Nov 1999 11:04:41 -0800
Message-ID: <[e-mail]>
From: Peter Williams <[e-mail]>
To: Russ Housley <[e-mail]>
Cc: "'[e-mail]'" <[e-mail]>
Subject: RE: Forward-dated entries in a CRL
Date: Thu, 18 Nov 1999 11:04:40 -0800
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain; charset="iso-8859-1"

> -----Original Message-----
> From: Russ Housley [mailto:[e-mail]]
> Sent: Thursday, November 18, 1999 6:05 AM
> To: Salz, Rich
> Cc: '[e-mail]'
> 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?
> 


Received: from dfw-smtpout4.email.verio.net (dfw-smtpout4-ext.email.verio.net [129.250.36.44]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id JAA01804 for <[e-mail]>; Thu, 18 Nov 1999 09:56:11 -0800 (PST)
Received: from dfw-mmp3.email.verio.net ([129.250.38.63]) by dfw-smtpout4.email.verio.net (Netscape Messaging Server 4.05) with ESMTP id FLEN8400.3VJ for <[e-mail]>; Thu, 18 Nov 1999 17:57:40 +0000 
Received: from nma.com ([209.21.28.64]) by dfw-mmp3.email.verio.net (Netscape Messaging Server 4.05) with ESMTP id FLEN7400.A5N; Thu, 18 Nov 1999 17:57:04 +0000 
Message-ID: <[e-mail]>
Date: Thu, 18 Nov 1999 09:57:57 -0800
From: Ed Gerck <[e-mail]>
X-Mailer: Mozilla 4.7 [en]C-CCK-MCD {Sony}  (Win98; I)
X-Accept-Language: en
MIME-Version: 1.0
To: "David P. Kemp" <[e-mail]>
CC: [e-mail]
Subject: non-ephemeral vs. non-repudiation, was Re: proposed key usage text
References: <[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

"David P. Kemp" wrote:

> > From: Stefan Santesson <[e-mail]>
> >
> > 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



Received: from dfw-smtpout3.email.verio.net (dfw-smtpout3-ext.email.verio.net [129.250.36.43]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id JAA00551 for <[e-mail]>; Thu, 18 Nov 1999 09:00:21 -0800 (PST)
Received: from dfw-mmp4.email.verio.net ([129.250.38.64]) by dfw-smtpout3.email.verio.net (Netscape Messaging Server 4.05) with ESMTP id FLEKJG00.DJ1 for <[e-mail]>; Thu, 18 Nov 1999 16:59:40 +0000 
Received: from nma.com ([209.21.28.64]) by dfw-mmp4.email.verio.net (Netscape Messaging Server 4.05) with ESMTP id FLEKIV00.Q5C; Thu, 18 Nov 1999 16:59:19 +0000 
Message-ID: <[e-mail]>
Date: Thu, 18 Nov 1999 08:59:44 -0800
From: Ed Gerck <[e-mail]>
X-Mailer: Mozilla 4.7 [en]C-CCK-MCD {Sony}  (Win98; I)
X-Accept-Language: en
MIME-Version: 1.0
To: Stefan Santesson <[e-mail]>
CC: [e-mail]
Subject: non-repudiation, was Re: proposed key usage text
References: <[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

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




Received: from uhura.concentric.net (uhura.concentric.net [206.173.118.93]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id HAA29257 for <[e-mail]>; Thu, 18 Nov 1999 07:59:34 -0800 (PST)
Received: from cliff.concentric.net (cliff.concentric.net [206.173.118.90]) by uhura.concentric.net (8.9.1a/(98/12/15 5.12)) id LAA22015; Thu, 18 Nov 1999 11:00:35 -0500 (EST) [1-800-745-2747 The Concentric Network]
Errors-To: <[e-mail]>
Received: from concentric.net (ts023d27.par-nj.concentric.net [216.112.172.135]) by cliff.concentric.net (8.9.1a) id LAA15751; Thu, 18 Nov 1999 11:00:32 -0500 (EST)
Message-ID: <[e-mail]>
Date: Thu, 18 Nov 1999 11:01:16 -0500
From: "Charles R. Merrill" <[e-mail]>
X-Mailer: Mozilla 4.61 [en]C-CCK-MCD {TLC;RETAIL}  (Win98; U)
X-Accept-Language: en
MIME-Version: 1.0
To: "Winchel 'Todd' Vincent, III" <[e-mail]>
CC: [e-mail], [e-mail], [e-mail], ABA ISC Mailing List <[e-mail]>
Subject: Re: Certificate Policy vs Certification Practice .. where are the  boundaries? ... what belongs where?
References: <[e-mail]> <003201bf3198$69707170$0a01a8c0@pabdec300ntw>
Content-Type: multipart/mixed; boundary="------------63220A28F6DA8646CE20844F"

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



[e-mail] wrote:

> The following is being forwarded to the pkix4 mailing list.
> Message originally sent by "Winchel 'Todd' Vincent, III" <[e-mail]>
> ---------------------------------------------------------------------------
>
> 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,
> [e-mail]) . . . (not the PKIX list, [e-mail]) . . .
> 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: [phone]
> Fax: [phone]
> Email: [e-mail]
> 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:[phone]
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:[e-mail]
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--



Received: from fwma1.certco.com (fwma1.certco.com [208.222.33.4]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id HAA28373 for <[e-mail]>; Thu, 18 Nov 1999 07:09:40 -0800 (PST)
Received: from haggis.ma.certco.com (haggis.ma.certco.com [10.200.200.20]) by fwma1.certco.com (Postfix) with ESMTP id 0EB3615532; Thu, 18 Nov 1999 10:10:37 -0500 (EST)
Received: from macertco-srv1.ma.certco.com (macertco-srv1.ma.certco.com [10.200.200.42]) by haggis.ma.certco.com (Postfix) with ESMTP id 93A5D7C052; Thu, 18 Nov 1999 10:10:37 -0500 (EST)
Received: by macertco-srv1.ma.certco.com with Internet Mail Service (5.5.2448.0) id <W0L0RG61>; Thu, 18 Nov 1999 10:09:27 -0500
Message-ID: <[e-mail]>
From: "Salz, Rich" <[e-mail]>
To: "'Sharon Boeyen'" <[e-mail]>, "'[e-mail]'" <[e-mail]>
Subject: RE: Forward-dated entries in a CRL
Date: Thu, 18 Nov 1999 10:09:22 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2448.0)
Content-Type: text/plain; charset="iso-8859-1"

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$
 


Received: from e3.ny.us.ibm.com (e3.ny.us.ibm.com [32.97.182.103]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id GAA27508 for <[e-mail]>; Thu, 18 Nov 1999 06:34:16 -0800 (PST)
From: [e-mail]
Received: from northrelay02.pok.ibm.com (northrelay02.pok.ibm.com [9.117.200.22]) by e3.ny.us.ibm.com (8.9.3/8.9.3) with ESMTP id JAA179994 for <[e-mail]>; Thu, 18 Nov 1999 09:34:55 -0500
Received: from D51MTA04.pok.ibm.com (d51mta04.pok.ibm.com [9.117.200.32]) by northrelay02.pok.ibm.com (8.8.8m2/NCO v2.06) with SMTP id JAA37264 for <[e-mail]>; Thu, 18 Nov 1999 09:35:41 -0500
Received: by D51MTA04.pok.ibm.com(Lotus SMTP MTA v4.6.5  (863.2 5-20-1999))  id 8525682D.00502B34 ; Thu, 18 Nov 1999 09:35:39 -0500
X-Lotus-FromDomain: IBMUS
To: [e-mail]
Message-ID: <[e-mail]>
Date: Thu, 18 Nov 1999 09:30:37 -0500
Subject: RFC 2527 Revision: What's going on and how to subscribe
Mime-Version: 1.0
Content-type: text/plain; charset=us-ascii
Content-Disposition: inline

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: [phone], Tie 549-9651
E-mail: [e-mail]

*
**
*** "The present never ages. Each moment is like a snowflake, unique,
unspoiled, unrepeatable and can be appreciated in its surprisingness." Gail
Sheeny
**
*




Received: from stingray.missi.ncsc.mil (stingray.missi.ncsc.mil [144.51.50.20]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id GAA27237 for <[e-mail]>; Thu, 18 Nov 1999 06:23:08 -0800 (PST)
Received: from stingray.missi.ncsc.mil (root@localhost) by stingray.missi.ncsc.mil with ESMTP id JAA08784 for <[e-mail]>; Thu, 18 Nov 1999 09:24:58 -0500 (EST)
Received: from missi.ncsc.mil (depot.missi.ncsc.mil [144.51.60.1]) by stingray.missi.ncsc.mil with ESMTP id JAA08780 for <[e-mail]>; Thu, 18 Nov 1999 09:24:58 -0500 (EST)
Received: from ara.missi.ncsc.mil (ara.missi.ncsc.mil [144.51.58.9]) by missi.ncsc.mil (8.8.8/8.8.8) with ESMTP id JAA09737 for <[e-mail]>; Thu, 18 Nov 1999 09:24:15 -0500 (EST)
Received: from ara.missi.ncsc.mil (ara.missi.ncsc.mil [144.51.58.9]) by ara.missi.ncsc.mil (8.9.1b+Sun/8.9.1) with SMTP id JAA15471 for <[e-mail]>; Thu, 18 Nov 1999 09:20:04 -0500 (EST)
Message-Id: <[e-mail]>
Date: Thu, 18 Nov 1999 09:20:04 -0500 (EST)
From: "David P. Kemp" <[e-mail]>
Reply-To: "David P. Kemp" <[e-mail]>
Subject: Re: proposed key usage text
To: [e-mail]
MIME-Version: 1.0
Content-Type: TEXT/plain; charset=us-ascii
Content-MD5: t6JZub/puT+DcaikVyTGXg==
X-Mailer: dtmail 1.3.0 CDE Version 1.3 SunOS 5.7 sun4u sparc

> From: Stefan Santesson <[e-mail]>
> 
> 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" <[e-mail]>
> 
> 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.



Received: from mail.spyrus.com (mail.spyrus.com [207.212.34.20]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id GAA26970 for <[e-mail]>; Thu, 18 Nov 1999 06:15:32 -0800 (PST)
Received: from rhousley_laptop.spyrus.com ([209.172.119.101]) by mail.spyrus.com (8.9.3/8.9.3) with ESMTP id GAA27039; Thu, 18 Nov 1999 06:15:54 -0800 (PST)
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58 
Date: Thu, 18 Nov 1999 09:04:34 -0500
To: "Salz, Rich" <[e-mail]>
From: Russ Housley <[e-mail]>
Subject: Re: Forward-dated entries in a CRL
Cc: "'[e-mail]'" <[e-mail]>
In-Reply-To: <[e-mail] rtco.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed

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?



Received: from gatekeeper.entrust.com (gatekeeper.entrust.com [204.101.128.170]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id FAA26416 for <[e-mail]>; Thu, 18 Nov 1999 05:45:28 -0800 (PST)
Received: 	id IAA13787; Thu, 18 Nov 1999 08:42:51 -0500
Received: by gateway id <XD3R0RVQ>; Thu, 18 Nov 1999 08:45:39 -0500
Message-ID: <[e-mail]>
From: Sharon Boeyen <[e-mail]>
To: "'Salz, Rich'" <[e-mail]>, "'[e-mail]'" <[e-mail]>
Subject: RE: Forward-dated entries in a CRL
Date: Thu, 18 Nov 1999 08:45:38 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2448.0)
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01BF31CB.3305A1F4"

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:[e-mail]]
Sent: Tuesday, November 16, 1999 12:12 PM
To: '[e-mail]'
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:[e-mail]">mailto:[e-mail]</A>]</FONT>
<BR><FONT SIZE=3D2>Sent: Tuesday, November 16, 1999 12:12 PM</FONT>
<BR><FONT SIZE=3D2>To: '[e-mail]'</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--


Received: from popmail.inbox.se (popmail.inbox.se [193.12.72.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id AAA18443 for <[e-mail]>; Thu, 18 Nov 1999 00:43:29 -0800 (PST)
Received: from stefan2 (accurata.inbox.se [193.12.72.24]) by popmail.inbox.se (8.9.3/8.9.3) with SMTP id JAA04554 for <[e-mail]>; Thu, 18 Nov 1999 09:44:51 +0100
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 
Date: Thu, 18 Nov 1999 09:45:22 +0100
To: [e-mail]
From: Stefan Santesson <[e-mail]>
Subject: Re: proposed key usage text
In-Reply-To: <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by ns.secondary.com id AAA18450

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 <[e-mail]> 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                <[e-mail]>
Accurata AB                     http://www.accurata.se
Slagthuset                      Tel. [phone]              
211 20  Malmö                   Fax. [phone]              
Sweden                        Mobile [phone]

PGP fingerprint: 89BC 6C79 5B3D 591B 8547  1512 7D11 DBF4 528F 29A0
-------------------------------------------------------------------


Received: from mail3.atl.bellsouth.net (mail3.atl.bellsouth.net [205.152.0.38]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id XAA15727 for <[e-mail]>; Wed, 17 Nov 1999 23:45:25 -0800 (PST)
Received: from pabdec300ntw (adsl-79-140-219.atl.bellsouth.net [216.79.140.219]) by mail3.atl.bellsouth.net (3.3.5alt/0.75.2) with SMTP id CAA18285; Thu, 18 Nov 1999 02:44:49 -0500 (EST)
Message-ID: <003201bf3198$69707170$0a01a8c0@pabdec300ntw>
From: "Winchel 'Todd' Vincent, III" <[e-mail]>
To: <[e-mail]>, <[e-mail]>, <[e-mail]>, "ABA ISC Mailing List" <[e-mail]>
References: <[e-mail]>
Subject: Re: Certificate Policy vs Certification Practice .. where are the boundaries? ... what belongs where?
Date: Thu, 18 Nov 1999 02:42:06 -0500
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.00.2314.1300
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300

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,
[e-mail]) . . . (not the PKIX list, [e-mail]) . . .
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: [phone]
Fax: [phone]
Email: [e-mail]
Web: http://e-ct-file.gsu.edu/
Legal XML: http://www.legalxml.org/







Received: from e1.ny.us.ibm.com (e1.ny.us.ibm.com [32.97.182.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id VAA11906 for <[e-mail]>; Wed, 17 Nov 1999 21:50:01 -0800 (PST)
From: [e-mail]
Received: from northrelay02.pok.ibm.com (northrelay02.pok.ibm.com [9.117.200.22]) by e1.ny.us.ibm.com (8.9.3/8.9.3) with ESMTP id AAA464972 for <[e-mail]>; Thu, 18 Nov 1999 00:50:39 -0500
Received: from D51MTA04.pok.ibm.com (d51mta04.pok.ibm.com [9.117.200.32]) by northrelay02.pok.ibm.com (8.8.8m2/NCO v2.06) with SMTP id AAA218996 for <[e-mail]>; Thu, 18 Nov 1999 00:51:20 -0500
Received: by D51MTA04.pok.ibm.com(Lotus SMTP MTA v4.6.5  (863.2 5-20-1999))  id 8525682D.00202A20 ; Thu, 18 Nov 1999 00:51:19 -0500
X-Lotus-FromDomain: IBMUS
To: [e-mail]
Message-ID: <[e-mail]>
Date: Thu, 18 Nov 1999 00:51:11 -0500
Subject: RFC 2527 Revision: What's going on and how to subscribe
Mime-Version: 1.0
Content-type: text/plain; charset=iso-8859-1
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by ns.secondary.com id VAA11907

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 ([e-mail]).

Editorial Committee:
|--------------------------+--------------------------->
|                          |                           |
| Name                     | Organization              |
|                          |                           |
|--------------------------+--------------------------->
  >-----------------------------|
  |                             |
  | Email                       |
  |                             |
  >-----------------------------|
|--------------------------+--------------------------->
|                          |                           |
| Warwick Ford             | VeriSign                  |
|                          |                           |
|--------------------------+--------------------------->
  >-----------------------------|
  |                             |
  | [e-mail]          |
  |                             |
  >-----------------------------|
|--------------------------+--------------------------->
|                          |                           |
| Santosh Chokhani         | CygnaCom                  |
|                          |                           |
|--------------------------+--------------------------->
  >-----------------------------|
  |                             |
  | [e-mail]       |
  |                             |
  >-----------------------------|
|--------------------------+--------------------------->
|                          |                           |
| Charles Merrill          | McCarter & English        |
|                          |                           |
|--------------------------+--------------------------->
  >-----------------------------|
  |                             |
  | [e-mail]     |
  |                             |
  >-----------------------------|
|--------------------------+--------------------------->
|                          |                           |
| Michael Power            | Government of Canada      |
|                          |                           |
|--------------------------+--------------------------->
  >-----------------------------|
  |                             |
  | [e-mail] |
  |                             |
  |                             |
  >-----------------------------|
|--------------------------+--------------------------->
|                          |                           |
| Juan Rodiriguez-Torrent  | IBM                       |
|                          |                           |
|--------------------------+--------------------------->
  >-----------------------------|
  |                             |
  | [e-mail]          |
  |                             |
  >-----------------------------|
|--------------------------+--------------------------->
|                          |                           |
| Randy V. Sabett          | SPYRUS, Inc.              |
|                          |                           |
|--------------------------+--------------------------->
  >-----------------------------|
  |                             |
  | [e-mail]          |
  |                             |
  >-----------------------------|



To join the PKIX4 mailing list, send a request to [e-mail]
with ?subscribe pkix4? in the body of the message or to
[e-mail] 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: [phone], Tie 549-9651
E-mail: [e-mail]

*
**
*** "The present never ages. Each moment is like a snowflake, unique,
unspoiled, unrepeatable and can be appreciated in its surprisingness." Gail
Sheeny
**
*




Received: from mail.student.auckland.ac.nz (mail.student.auckland.ac.nz [130.216.35.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id TAA01657 for <[e-mail]>; Wed, 17 Nov 1999 19:25:14 -0800 (PST)
Received: from cs26.cs.auckland.ac.nz ([e-mail] [130.216.36.9]) by mail.student.auckland.ac.nz (8.9.3/8.8.6/cs-master) with SMTP id QAA04075 for <[e-mail]>; Thu, 18 Nov 1999 16:26:37 +1300 (NZDT) (sender [e-mail])
Received: by cs26.cs.auckland.ac.nz (relaymail v0.9) id <94289559822295>; Thu, 18 Nov 1999 16:26:38 (NZDT)
From: [e-mail] (Peter Gutmann)
To: [e-mail]
Subject: Re: proposed key usage text
Sender: [e-mail]
Reply-To: [e-mail]
X-Charge-To: pgut001
X-Authenticated: relaymail v0.9 on cs26.cs.auckland.ac.nz
Date: Thu, 18 Nov 1999 16:26:38 (NZDT)
Message-ID: <[e-mail]>

Tony Bartoletti <[e-mail]> 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.



Received: from poptop.llnl.gov (poptop.llnl.gov [128.115.18.65]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id SAA26159 for <[e-mail]>; Wed, 17 Nov 1999 18:31:25 -0800 (PST)
Received: from catalyst (catalyst.llnl.gov [128.115.223.61]) by poptop.llnl.gov (8.8.8/LLNL-3.0.2/pop.llnl.gov-5.1) with SMTP id SAA07074; Wed, 17 Nov 1999 18:32:42 -0800 (PST)
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.3 (32)
Date: Wed, 17 Nov 1999 18:32:32 -0800
To: [e-mail], Tim Polk <[e-mail]>
From: Tony Bartoletti <[e-mail]>
Subject: Re: proposed key usage text
Cc: [e-mail]
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"

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: [phone]   fax: [phone]               LL LLLLLLLL
email: [e-mail]                                   LLLLLLLL


Received: from poptop.llnl.gov (poptop.llnl.gov [128.115.18.65]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id RAA20696 for <[e-mail]>; Wed, 17 Nov 1999 17:21:05 -0800 (PST)
Received: from catalyst (catalyst.llnl.gov [128.115.223.61]) by poptop.llnl.gov (8.8.8/LLNL-3.0.2/pop.llnl.gov-5.1) with SMTP id RAA20266; Wed, 17 Nov 1999 17:22:27 -0800 (PST)
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.3 (32)
Date: Wed, 17 Nov 1999 17:22:17 -0800
To: [e-mail], Tim Polk <[e-mail]>
From: Tony Bartoletti <[e-mail]>
Subject: Re: proposed key usage text
Cc: [e-mail]
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"

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: [phone]   fax: [phone]               LL LLLLLLLL
email: [e-mail]                                   LLLLLLLL


Received: from e4.ny.us.ibm.com (e4.ny.us.ibm.com [32.97.182.104]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id QAA19326 for <[e-mail]>; Wed, 17 Nov 1999 16:59:21 -0800 (PST)
From: [e-mail]
Received: from northrelay02.pok.ibm.com (northrelay02.pok.ibm.com [9.117.200.22]) by e4.ny.us.ibm.com (8.9.3/8.9.3) with ESMTP id TAA398640; Wed, 17 Nov 1999 19:59:58 -0500
Received: from D51MTA05.pok.ibm.com (d51mta05.pok.ibm.com [9.117.200.33]) by northrelay02.pok.ibm.com (8.8.8m2/NCO v2.06) with SMTP id UAA140612; Wed, 17 Nov 1999 20:00:33 -0500
Received: by D51MTA05.pok.ibm.com(Lotus SMTP MTA v4.6.5  (863.2 5-20-1999))  id 8525682D.00058A2B ; Wed, 17 Nov 1999 20:00:30 -0500
X-Lotus-FromDomain: IBMUS
To: Tony Bartoletti <[e-mail]>
cc: Tim Polk <[e-mail]>, [e-mail]
Message-ID: <[e-mail]>
Date: Wed, 17 Nov 1999 20:00:33 -0500
Subject: Re: proposed key usage text
Mime-Version: 1.0
Content-type: text/plain; charset=us-ascii
Content-Disposition: inline

     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 <[e-mail]> on 11/17/99 06:49:55 PM

To:   Tom Gindin/Watson/IBM@IBMUS, Tim Polk <[e-mail]>
cc:   [e-mail]
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: [phone]   fax: [phone]               LL LLLLLLLL
email: [e-mail]                                   LLLLLLLL





Received: from poptop.llnl.gov (poptop.llnl.gov [128.115.18.65]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id PAA16081 for <[e-mail]>; Wed, 17 Nov 1999 15:48:43 -0800 (PST)
Received: from catalyst (catalyst.llnl.gov [128.115.223.61]) by poptop.llnl.gov (8.8.8/LLNL-3.0.2/pop.llnl.gov-5.1) with SMTP id PAA10890; Wed, 17 Nov 1999 15:50:04 -0800 (PST)
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.3 (32)
Date: Wed, 17 Nov 1999 15:49:55 -0800
To: [e-mail], Tim Polk <[e-mail]>
From: Tony Bartoletti <[e-mail]>
Subject: Re: proposed key usage text
Cc: [e-mail]
In-Reply-To: <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"

[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: [phone]   fax: [phone]               LL LLLLLLLL
email: [e-mail]                                   LLLLLLLL


Received: from mail.student.auckland.ac.nz (mail.student.auckland.ac.nz [130.216.35.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id NAA13706 for <[e-mail]>; Wed, 17 Nov 1999 13:33:09 -0800 (PST)
Received: from cs26.cs.auckland.ac.nz ([e-mail] [130.216.36.9]) by mail.student.auckland.ac.nz (8.9.3/8.8.6/cs-master) with SMTP id KAA21575; Thu, 18 Nov 1999 10:34:31 +1300 (NZDT) (sender [e-mail])
Received: by cs26.cs.auckland.ac.nz (relaymail v0.9) id <94287447221113>; Thu, 18 Nov 1999 10:34:32 (NZDT)
From: [e-mail] (Peter Gutmann)
To: [e-mail], [e-mail]
Subject: Re: correction, was Re: proposed key usage text
Sender: [e-mail]
Reply-To: [e-mail]
X-Charge-To: pgut001
X-Authenticated: relaymail v0.9 on cs26.cs.auckland.ac.nz
Date: Thu, 18 Nov 1999 10:34:32 (NZDT)
Message-ID: <[e-mail]>

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



Received: from e2.ny.us.ibm.com (e2.ny.us.ibm.com [32.97.182.102]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id NAA13350 for <[e-mail]>; Wed, 17 Nov 1999 13:19:32 -0800 (PST)
From: [e-mail]
Received: from northrelay02.pok.ibm.com (northrelay02.pok.ibm.com [9.117.200.22]) by e2.ny.us.ibm.com (8.9.3/8.9.3) with ESMTP id QAA06326; Wed, 17 Nov 1999 16:20:07 -0500
Received: from D51MTA05.pok.ibm.com (d51mta05.pok.ibm.com [9.117.200.33]) by northrelay02.pok.ibm.com (8.8.8m2/NCO v2.06) with SMTP id QAA122498; Wed, 17 Nov 1999 16:20:53 -0500
Received: by D51MTA05.pok.ibm.com(Lotus SMTP MTA v4.6.5  (863.2 5-20-1999))  id 8525682C.0075409D ; Wed, 17 Nov 1999 16:20:42 -0500
X-Lotus-FromDomain: IBMUS
To: Tim Polk <[e-mail]>
cc: [e-mail]
Message-ID: <[e-mail]>
Date: Wed, 17 Nov 1999 16:20:25 -0500
Subject: Re: proposed key usage text
Mime-Version: 1.0
Content-type: text/plain; charset=us-ascii
Content-Disposition: inline

     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




Received: from e4.ny.us.ibm.com (e4.ny.us.ibm.com [32.97.182.104]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id NAA13114 for <[e-mail]>; Wed, 17 Nov 1999 13:14:34 -0800 (PST)
From: [e-mail]
Received: from northrelay02.pok.ibm.com (northrelay02.pok.ibm.com [9.117.200.22]) by e4.ny.us.ibm.com (8.9.3/8.9.3) with ESMTP id QAA210548; Wed, 17 Nov 1999 16:15:09 -0500
Received: from D51MTA05.pok.ibm.com (d51mta05.pok.ibm.com [9.117.200.33]) by northrelay02.pok.ibm.com (8.8.8m2/NCO v2.06) with SMTP id QAA154256; Wed, 17 Nov 1999 16:15:55 -0500
Received: by D51MTA05.pok.ibm.com(Lotus SMTP MTA v4.6.5  (863.2 5-20-1999))  id 8525682C.0074CD9E ; Wed, 17 Nov 1999 16:15:48 -0500
X-Lotus-FromDomain: IBMUS
To: Ed Gerck <[e-mail]>
cc: Aram Perez <[e-mail]>, [e-mail]
Message-ID: <[e-mail]>
Date: Wed, 17 Nov 1999 16:15:04 -0500
Subject: Re: correction, was Re: proposed key usage text
Mime-Version: 1.0
Content-type: text/plain; charset=us-ascii
Content-Disposition: inline

     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




Received: from dfw-smtpout3.email.verio.net (dfw-smtpout3-ext.email.verio.net [129.250.36.43]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id MAA12039 for <[e-mail]>; Wed, 17 Nov 1999 12:30:24 -0800 (PST)
Received: from dfw-mmp3.email.verio.net ([129.250.38.63]) by dfw-smtpout3.email.verio.net (Netscape Messaging Server 4.05) with ESMTP id FLCZP000.VB8 for <[e-mail]>; Wed, 17 Nov 1999 20:31:48 +0000 
Received: from nma.com ([209.21.28.99]) by dfw-mmp3.email.verio.net (Netscape Messaging Server 4.05) with ESMTP id FLCZNZ00.PP0; Wed, 17 Nov 1999 20:31:11 +0000 
Message-ID: <[e-mail]>
Date: Wed, 17 Nov 1999 12:32:07 -0800
From: Ed Gerck <[e-mail]>
X-Mailer: Mozilla 4.7 [en]C-CCK-MCD {Sony}  (Win98; I)
X-Accept-Language: en
MIME-Version: 1.0
To: Aram Perez <[e-mail]>, "[e-mail]" <[e-mail]>
Subject: Re: correction, was Re: proposed key usage text
References: <[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

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




Received: from dfw-smtpout3.email.verio.net (dfw-smtpout3-ext.email.verio.net [129.250.36.43]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id MAA11357 for <[e-mail]>; Wed, 17 Nov 1999 12:10:42 -0800 (PST)
Received: from dfw-mmp2.email.verio.net ([129.250.38.62]) by dfw-smtpout3.email.verio.net (Netscape Messaging Server 4.05) with ESMTP id FLCYS600.N62 for <[e-mail]>; Wed, 17 Nov 1999 20:12:06 +0000 
Received: from nma.com ([209.21.28.99]) by dfw-mmp2.email.verio.net (Netscape Messaging Server 4.05) with ESMTP id FLCYV200.22K; Wed, 17 Nov 1999 20:13:50 +0000 
Message-ID: <[e-mail]>
Date: Wed, 17 Nov 1999 12:12:26 -0800
From: Ed Gerck <[e-mail]>
X-Mailer: Mozilla 4.7 [en]C-CCK-MCD {Sony}  (Win98; I)
X-Accept-Language: en
MIME-Version: 1.0
To: Aram Perez <[e-mail]>, [e-mail]
Subject: correction, was Re: proposed key usage text
References: <[e-mail]> <[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

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



Received: from mail.student.auckland.ac.nz (mail.student.auckland.ac.nz [130.216.35.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id MAA11138 for <[e-mail]>; Wed, 17 Nov 1999 12:07:30 -0800 (PST)
Received: from cs26.cs.auckland.ac.nz ([e-mail] [130.216.36.9]) by mail.student.auckland.ac.nz (8.9.3/8.8.6/cs-master) with SMTP id JAA18334 for <[e-mail]>; Thu, 18 Nov 1999 09:08:52 +1300 (NZDT) (sender [e-mail])
Received: by cs26.cs.auckland.ac.nz (relaymail v0.9) id <94286933220625>; Thu, 18 Nov 1999 09:08:52 (NZDT)
From: [e-mail] (Peter Gutmann)
To: [e-mail]
Subject: Should we make the cert Validity field optional?
Sender: [e-mail]
Reply-To: [e-mail]
X-Charge-To: pgut001
X-Authenticated: relaymail v0.9 on cs26.cs.auckland.ac.nz
Date: Thu, 18 Nov 1999 09:08:52 (NZDT)
Message-ID: <[e-mail]>

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



Received: from dfw-smtpout2.email.verio.net (dfw-smtpout2-ext.email.verio.net [129.250.36.42]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id LAA09694 for <[e-mail]>; Wed, 17 Nov 1999 11:21:01 -0800 (PST)
Received: from dfw-mmp1.email.verio.net ([129.250.38.61]) by dfw-smtpout2.email.verio.net (Netscape Messaging Server 4.05) with ESMTP id FLCWH900.S7R for <[e-mail]>; Wed, 17 Nov 1999 19:22:21 +0000 
Received: from nma.com ([209.21.28.99]) by dfw-mmp1.email.verio.net (Netscape Messaging Server 4.05) with ESMTP id FLCWGP00.3WN; Wed, 17 Nov 1999 19:22:01 +0000 
Message-ID: <[e-mail]>
Date: Wed, 17 Nov 1999 11:22:40 -0800
From: Ed Gerck <[e-mail]>
X-Mailer: Mozilla 4.7 [en]C-CCK-MCD {Sony}  (Win98; I)
X-Accept-Language: en
MIME-Version: 1.0
To: Aram Perez <[e-mail]>
CC: [e-mail]
Subject: Re: proposed key usage text
References: <[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

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



Received: from doggate.exchange.microsoft.com (doggate.exchange.microsoft.com [131.107.88.55]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id KAA08970 for <[e-mail]>; Wed, 17 Nov 1999 10:51:05 -0800 (PST)
Received: by doggate.exchange.microsoft.com with Internet Mail Service (5.5.2232.9) id <XB2W23T4>; Wed, 17 Nov 1999 10:51:59 -0800
Message-ID: <[e-mail]>
From: "Trevor Freeman (Exchange)" <[e-mail]>
To: "Pkix List (E-mail)" <[e-mail]>
Subject: RE: Associating symmetric algorithms with a public key
Date: Wed, 17 Nov 1999 10:51:56 -0800
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2232.9)
Content-Type: text/plain

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?


Received: from dfssl.exchange.microsoft.com (dfssl.exchange.microsoft.com [131.107.88.59]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id KAA08642 for <[e-mail]>; Wed, 17 Nov 1999 10:41:17 -0800 (PST)
Received: by dfssl with Internet Mail Service (5.5.2650.21) id <W8XXMRHP>; Wed, 17 Nov 1999 10:42:10 -0800
Message-ID: <[e-mail]>
From: "Trevor Freeman (Exchange)" <[e-mail]>
To: Bob Jueneman <[e-mail]>, [e-mail]
Subject: RE: Associating symmetric algorithms with a public key
Date: Wed, 17 Nov 1999 10:42:08 -0800
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01BF312B.73941002"

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:[e-mail]]
Sent: Tuesday, November 16, 1999 7:53 AM
To: Trevor Freeman (Exchange); [e-mail]
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)" <[e-mail]> 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:[e-mail]">mailto:[e-mail]</A>]</F=
ONT>
<BR><FONT SIZE=3D2>Sent: Tuesday, November 16, 1999 7:53 AM</FONT>
<BR><FONT SIZE=3D2>To: Trevor Freeman (Exchange); =
[e-mail]</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;[e-mail]&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--


Received: from mail-out2.apple.com (mail-out2.apple.com [17.254.0.51]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id KAA08262 for <[e-mail]>; Wed, 17 Nov 1999 10:31:04 -0800 (PST)
Received: from mailgate1.apple.com (A17-128-100-225.apple.com [17.128.100.225]) by mail-out2.apple.com (8.9.3/8.9.3) with ESMTP id KAA14138 for <[e-mail]>; Wed, 17 Nov 1999 10:32:27 -0800 (PST)
Received: from scv2.apple.com (scv2.apple.com) by mailgate1.apple.com (mailgate1.apple.com- SMTPRS 2.0.15) with ESMTP id <[e-mail]> for <[e-mail]>; Wed, 17 Nov 1999 10:32:27 -0800
Received: from [17.205.41.166] (aram1.apple.com [17.205.41.166]) by scv2.apple.com (8.9.3/8.9.3) with ESMTP id KAA04846 for <[e-mail]>; Wed, 17 Nov 1999 10:32:21 -0800 (PST)
Message-Id: <[e-mail]>
X-Mailer: Microsoft Outlook Express Macintosh Edition - 4.5 (0410)
Date: Wed, 17 Nov 1999 10:32:22 -0800
Subject: Re: proposed key usage text
From: "Aram Perez" <[e-mail]>
To: [e-mail]
MIME-Version: 1.0
X-Priority: 3
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit

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


Received: from seine.valicert.com (corporate-gw.valicert.com [63.65.221.2]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id KAA07948 for <[e-mail]>; Wed, 17 Nov 1999 10:27:26 -0800 (PST)
Received: by seine.valicert.com with Internet Mail Service (5.5.2650.21) id <WZF0T5FJ>; Wed, 17 Nov 1999 10:25:32 -0800
Message-ID: <[e-mail]>
From: Peter Williams <[e-mail]>
To: Paul Koning <[e-mail]>
Cc: [e-mail]
Subject: RE: Associating symmetric algorithms with a public key
Date: Wed, 17 Nov 1999 10:25:32 -0800
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain; charset="iso-8859-1"

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:[e-mail]]
> Sent: Wednesday, November 17, 1999 9:49 AM
> To: [e-mail]
> Cc: [e-mail]
> Subject: RE: Associating symmetric algorithms with a public key
> 
> 
> >>>>> "Peter" == Peter Williams <[e-mail]> 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
> 


Received: from wuher.cygnacom.com (endor.cygnacom.com [205.177.169.102]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id KAA07803 for <[e-mail]>; Wed, 17 Nov 1999 10:23:00 -0800 (PST)
Received: by WUHER with Internet Mail Service (5.0.1460.8) id <WVVY58T6>; Wed, 17 Nov 1999 13:19:58 -0500
Message-ID: <51BF55C30B4FD1118B4900207812701E4D580C@WUHER>
From: Santosh Chokhani <[e-mail]>
To: "'David P. Kemp'" <[e-mail]>, [e-mail]
Subject: RE: Associating symmetric algorithms with a public key
Date: Wed, 17 Nov 1999 13:19:55 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.0.1460.8)
Content-Type: text/plain

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:[e-mail]]
Sent: Wednesday, November 17, 1999 9:14 AM
To: [e-mail]
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)" <[e-mail]>
> To: "'Stephen Kent'" <[e-mail]>
> Cc: "Pkix List (E-mail)" <[e-mail]>
> 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


Received: from dfw7-1.relay.mail.uu.net (dfw7-1.relay.mail.uu.net [199.171.54.106]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id JAA07192 for <[e-mail]>; Wed, 17 Nov 1999 09:48:04 -0800 (PST)
Received: from xedia.com by dfw7sosrv11.alter.net with SMTP  (peer crosschecked as: madway.xedia.com [198.202.232.199]) id QQhptf17211; Wed, 17 Nov 1999 17:49:26 GMT
Received: from tonga.xedia.com by xedia.com (4.1/SMI-4.1) id AA12592; Wed, 17 Nov 99 12:47:20 EST
Received: by tonga.xedia.com (SMI-8.6/SMI-SVR4) id MAA22945; Wed, 17 Nov 1999 12:49:24 -0500
Date: Wed, 17 Nov 1999 12:49:24 -0500
Message-Id: <[e-mail]>
From: Paul Koning <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
To: [e-mail]
Cc: [e-mail]
Subject: RE: Associating symmetric algorithms with a public key
References: <[e-mail]>
X-Mailer: VM 6.34 under 20.3 "Vatican City" XEmacs  Lucid

>>>>> "Peter" == Peter Williams <[e-mail]> 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


Received: from seine.valicert.com (corporate-gw.valicert.com [63.65.221.2]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id JAA06735 for <[e-mail]>; Wed, 17 Nov 1999 09:28:28 -0800 (PST)
Received: by seine.valicert.com with Internet Mail Service (5.5.2650.21) id <WZF0T5BM>; Wed, 17 Nov 1999 09:26:35 -0800
Message-ID: <[e-mail]>
From: Peter Williams <[e-mail]>
To: Paul Koning <[e-mail]>
Cc: [e-mail]
Subject: RE: Associating symmetric algorithms with a public key
Date: Wed, 17 Nov 1999 09:26:34 -0800
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain; charset="iso-8859-1"

> -----Original Message-----
> From: Paul Koning [mailto:[e-mail]]
> Sent: Wednesday, November 17, 1999 6:42 AM
> To: [e-mail]
> Cc: [e-mail]; [e-mail]
> Subject: RE: Associating symmetric algorithms with a public key
> 
> 
> >>>>> "Stephen" == Stephen Kent <[e-mail]> 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
> 


Received: from csmes.ncsl.nist.gov (csmes.ncsl.nist.gov [129.6.54.2]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id IAA05985 for <[e-mail]>; Wed, 17 Nov 1999 08:45:02 -0800 (PST)
Received: from st12.ncsl.nist.gov (st12.ncsl.nist.gov [129.6.54.66]) by csmes.ncsl.nist.gov (8.6.12/8.6.4jck0) with SMTP id LAA16356 for <[e-mail]>; Wed, 17 Nov 1999 11:47:07 -0500
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32)
Date: Wed, 17 Nov 1999 11:50:51 -0500
To: [e-mail]
From: Tim Polk <[e-mail]>
Subject: proposed key usage text
Mime-Version: 1.0
Content-Type: text/enriched; charset="us-ascii"

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


Received: from po1.bbn.com (PO1.BBN.COM [192.1.50.38]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id HAA05161 for <[e-mail]>; Wed, 17 Nov 1999 07:53:37 -0800 (PST)
Received: from [171.78.30.108] (comsecpb.bbn.com [171.78.30.108]) by po1.bbn.com (8.9.1/8.9.1) with ESMTP id KAA00599; Wed, 17 Nov 1999 10:54:52 -0500 (EST)
Mime-Version: 1.0
X-Sender: [e-mail]
Message-Id: <v04220802b4587e910ed0@[171.78.30.108]>
In-Reply-To:  <[e-mail]>
References:  <[e-mail]>
Date: Wed, 17 Nov 1999 10:54:20 -0500
To: "Trevor Freeman (Exchange)" <[e-mail]>
From: Stephen Kent <[e-mail]>
Subject: RE: Associating symmetric algorithms with a public key
Cc: "Pkix List (E-mail)" <[e-mail]>
Content-Type: text/plain; charset="us-ascii" ; format="flowed"

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


Received: from prv-mail20.provo.novell.com (prv-mail20.provo.novell.com [137.65.82.195]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id HAA04728 for <[e-mail]>; Wed, 17 Nov 1999 07:37:45 -0800 (PST)
Received: from INET-PRV-Message_Server by prv-mail20.provo.novell.com with Novell_GroupWise; Wed, 17 Nov 1999 08:38:38 -0700
Message-Id: <[e-mail]>
X-Mailer: Novell GroupWise Internet Agent 5.5.2.1
Date: Tue, 16 Nov 1999 08:52:31 -0700
From: "Bob Jueneman" <[e-mail]>
To: <[e-mail]>, <[e-mail]>
Subject: Re: Associating symmetric algorithms with a public key
Mime-Version: 1.0
Content-Type: multipart/mixed; boundary="=_471E40EE.EA8BCDBD"

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)" <[e-mail]> 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"

QkVHSU46VkNBUkQNClZFUlNJT046Mi4xDQpYLUdXVFlQRTpVU0VSDQpGTjpSb2JlcnQgUi4gSnVl
bmVtYW4NClRFTDtXT1JLOjgwMS04NjEtNzM4Nw0KT1JHOk5vdmVsbCwgSW5jLjtOZXR3b3JrIFNl
Y3VyaXR5IERldmVsb3BtZW50DQpURUw7UFJFRjtGQVg6ODAxLTg2MS0yNTIyDQpFTUFJTDtXT1JL
O1BSRUY7TkdXOkJKVUVORU1BTkBub3ZlbGwuY29tDQpOOkp1ZW5lbWFuO0JvYg0KVElUTEU6Q29u
c3VsdGFudCBFbmdpbmVlcg0KQURSO0lOVEw7V09SSztQQVJDRUw7UE9TVEFMOjtQUlYtRjMzMTsx
MjIgRS4gMTcwMCBTb3V0aDtQcm92bztVdGFoOzg0NjA2O1VTQQ0KTEFCRUw7SU5UTDtXT1JLO1BB
UkNFTDtQT1NUQUw7RU5DT0RJTkc9UVVPVEVELVBSSU5UQUJMRTpSb2JlcnQgUi4gSnVlbmVtYW49
MEE9DQpQUlYtRjMzMT0wQT0NCjEyMiBFLiAxNzAwIFNvdXRoPTBBPQ0KUHJvdm8sIFV0YWggIDg0
NjA2PTBBPQ0KVVNBDQpMQUJFTDtET007V09SSztQQVJDRUw7UE9TVEFMO0VOQ09ESU5HPVFVT1RF
RC1QUklOVEFCTEU6Um9iZXJ0IFIuIEp1ZW5lbWFuPTBBPQ0KUFJWLUYzMzE9MEE9DQoxMjIgRS4g
MTcwMCBTb3V0aD0wQT0NClByb3ZvLCBVdGFoICA4NDYwNg0KVEVMO0hPTUU6MS04MDEtNzY1LTQz
NzgNClRFTDtDRUxMOjEtODAxLTM2MS0xNDEwDQpURUw7UFJFRjoxLTgwMS04NjEtNzM4NywgMS04
MDAtNDUzLTEyNjcNClgtR1dVU0VSSUQ6QkpVRU5FTUFODQpFTkQ6VkNBUkQNCg0K

--=_471E40EE.EA8BCDBD--


Received: from balinese.baltimore.ie ([e-mail] [194.125.215.8]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id GAA04042 for <[e-mail]>; Wed, 17 Nov 1999 06:58:09 -0800 (PST)
Received: by balinese.baltimore.ie; id OAA04693; Wed, 17 Nov 1999 14:59:26 GMT
Received: from unknown(192.168.20.10) by balinese.baltimore.ie via smap (V4.2) id xma004686; Wed, 17 Nov 99 14:59:24 GMT
Received: from ocelot.baltimore.ie (IDENT:[e-mail] [192.168.21.10]) by bobcat.baltimore.ie (8.9.3/8.9.3) with ESMTP id OAA21162 for <[e-mail]>; Wed, 17 Nov 1999 14:59:24 GMT
Received: from ocelot.baltimore.ie (afarrell@localhost [127.0.0.1]) by ocelot.baltimore.ie (8.8.7/8.8.7) with ESMTP id OAA11304 for <[e-mail]>; Wed, 17 Nov 1999 14:59:23 GMT
Message-Id: <[e-mail]>
To: [e-mail]
Subject: Re: Associating symmetric algorithms with a public key 
In-Reply-To: Your message of "Mon, 15 Nov 1999 16:03:10 PST." <[e-mail]> 
Date: Wed, 17 Nov 1999 14:59:23 +0000
From: Andrew Farrell <[e-mail]>

In message <[e-mail]>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.


Received: from dfw7-1.relay.mail.uu.net (dfw7-1.relay.mail.uu.net [199.171.54.106]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id GAA03614 for <[e-mail]>; Wed, 17 Nov 1999 06:40:27 -0800 (PST)
Received: from xedia.com by dfw7sosrv11.alter.net with SMTP  (peer crosschecked as: madway.xedia.com [198.202.232.199]) id QQhpss23167; Wed, 17 Nov 1999 14:41:48 GMT
Received: from tonga.xedia.com by xedia.com (4.1/SMI-4.1) id AA08973; Wed, 17 Nov 99 09:39:43 EST
Received: by tonga.xedia.com (SMI-8.6/SMI-SVR4) id JAA22782; Wed, 17 Nov 1999 09:41:47 -0500
Date: Wed, 17 Nov 1999 09:41:47 -0500
Message-Id: <[e-mail]>
From: Paul Koning <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
To: [e-mail]
Cc: [e-mail], [e-mail]
Subject: RE: Associating symmetric algorithms with a public key
References: <[e-mail]> <v04220808b457a2daf4ce@[171.78.30.108]>
X-Mailer: VM 6.34 under 20.3 "Vatican City" XEmacs  Lucid

>>>>> "Stephen" == Stephen Kent <[e-mail]> 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


Received: from fwma1.certco.com (fwma1.certco.com [208.222.33.4]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id GAA03302 for <[e-mail]>; Wed, 17 Nov 1999 06:27:45 -0800 (PST)
Received: from haggis.ma.certco.com (unknown [10.200.200.20]) by fwma1.certco.com (Postfix) with ESMTP for <[e-mail]> id 0CCB315558; Tue, 16 Nov 1999 12:12:57 -0500 (EST)
Received: from macertco-srv1.ma.certco.com (macertco-srv1.ma.certco.com [10.200.200.42]) by haggis.ma.certco.com (Postfix) with ESMTP id E83907C052 for <[e-mail]>; Tue, 16 Nov 1999 12:12:56 -0500 (EST)
Received: by macertco-srv1.ma.certco.com with Internet Mail Service (5.5.2448.0) id <W0L0RGS0>; Tue, 16 Nov 1999 12:11:50 -0500
Message-ID: <[e-mail]>
From: "Salz, Rich" <[e-mail]>
To: "'[e-mail]'" <[e-mail]>
Subject: Forward-dated entries in a CRL
Date: Tue, 16 Nov 1999 12:11:49 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2448.0)
Content-Type: text/plain; charset="iso-8859-1"

Is it legal to put future date in the revocationDate
field of a revokedCertificates entry?


Received: from stingray.missi.ncsc.mil (stingray.missi.ncsc.mil [144.51.50.20]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id GAA02941 for <[e-mail]>; Wed, 17 Nov 1999 06:17:22 -0800 (PST)
Received: from stingray.missi.ncsc.mil (root@localhost) by stingray.missi.ncsc.mil with ESMTP id JAA12254 for <[e-mail]>; Wed, 17 Nov 1999 09:19:07 -0500 (EST)
Received: from missi.ncsc.mil (depot.missi.ncsc.mil [144.51.60.1]) by stingray.missi.ncsc.mil with ESMTP id JAA12250 for <[e-mail]>; Wed, 17 Nov 1999 09:19:07 -0500 (EST)
Received: from ara.missi.ncsc.mil (ara.missi.ncsc.mil [144.51.58.9]) by missi.ncsc.mil (8.8.8/8.8.8) with ESMTP id JAA27029 for <[e-mail]>; Wed, 17 Nov 1999 09:18:24 -0500 (EST)
Received: from ara.missi.ncsc.mil (ara.missi.ncsc.mil [144.51.58.9]) by ara.missi.ncsc.mil (8.9.1b+Sun/8.9.1) with SMTP id JAA14863 for <[e-mail]>; Wed, 17 Nov 1999 09:14:17 -0500 (EST)
Message-Id: <[e-mail]>
Date: Wed, 17 Nov 1999 09:14:16 -0500 (EST)
From: "David P. Kemp" <[e-mail]>
Reply-To: "David P. Kemp" <[e-mail]>
Subject: RE: Associating symmetric algorithms with a public key
To: [e-mail]
MIME-Version: 1.0
Content-Type: TEXT/plain; charset=us-ascii
Content-MD5: +5bwVP/McXNb8ROMXWDiMg==
X-Mailer: dtmail 1.3.0 CDE Version 1.3 SunOS 5.7 sun4u sparc

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)" <[e-mail]>
> To: "'Stephen Kent'" <[e-mail]>
> Cc: "Pkix List (E-mail)" <[e-mail]>
> 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



Received: from ietf.org (odin.ietf.org [132.151.1.176]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id DAA00985 for <[e-mail]>; Wed, 17 Nov 1999 03:58:04 -0800 (PST)
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA17233; Wed, 17 Nov 1999 06:59:24 -0500 (EST)
Message-Id: <[e-mail]>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Cc: [e-mail]
From: [e-mail]
Reply-to: [e-mail]
Subject: I-D ACTION:draft-ietf-pkix-generalname-00.txt
Date: Wed, 17 Nov 1999 06:59:23 -0500
Sender: [e-mail]

--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:
	[e-mail].
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="[e-mail]"

Content-Type: text/plain
Content-ID:	<[e-mail]>

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:	<[e-mail]>

--OtherAccess--

--NextPart--




Received: from popmail.inbox.se (popmail.inbox.se [193.12.72.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id AAA25156 for <[e-mail]>; Wed, 17 Nov 1999 00:20:04 -0800 (PST)
Received: from stefan2 (accurata.inbox.se [193.12.72.24]) by popmail.inbox.se (8.9.3/8.9.3) with SMTP id JAA22949; Wed, 17 Nov 1999 09:21:18 +0100
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 
Date: Wed, 17 Nov 1999 09:21:51 +0100
To: "Manger, James" <[e-mail]>, [e-mail]
From: Stefan Santesson <[e-mail]>
Subject: RE: PKIX: Use of dnQualifier must be settled
In-Reply-To: <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by ns.secondary.com id AAA25159

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:[e-mail]]
>> 
>> 	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                <[e-mail]>
Accurata AB                     http://www.accurata.se
Slagthuset                      Tel. [phone]              
211 20  Malmö                   Fax. [phone]              
Sweden                        Mobile [phone]

PGP fingerprint: 89BC 6C79 5B3D 591B 8547  1512 7D11 DBF4 528F 29A0
-------------------------------------------------------------------


Received: from doggate.exchange.microsoft.com (doggate.exchange.microsoft.com [131.107.88.55]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id RAA07062 for <[e-mail]>; Tue, 16 Nov 1999 17:19:19 -0800 (PST)
Received: by doggate.exchange.microsoft.com with Internet Mail Service (5.5.2232.9) id <XB2W2J04>; Tue, 16 Nov 1999 17:19:49 -0800
Message-ID: <[e-mail]>
From: "Trevor Freeman (Exchange)" <[e-mail]>
To: "'Stephen Kent'" <[e-mail]>
Cc: "Pkix List (E-mail)" <[e-mail]>
Subject: RE: Associating symmetric algorithms with a public key
Date: Tue, 16 Nov 1999 17:19:46 -0800
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2232.9)
Content-Type: text/plain

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:[e-mail]]
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


Received: from mailo.vtcif.telstra.com.au (mailo.vtcif.telstra.com.au [202.12.144.17]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id QAA06447 for <[e-mail]>; Tue, 16 Nov 1999 16:36:10 -0800 (PST)
Received: (from uucp@localhost) by mailo.vtcif.telstra.com.au (8.8.2/8.6.9) id LAA06406; Wed, 17 Nov 1999 11:36:58 +1100 (EST)
Received: from maili.vtcif.telstra.com.au(202.12.142.17) via SMTP by mailo.vtcif.telstra.com.au, id smtpd0JpkrQ; Wed Nov 17 11:36:10 1999
Received: (from uucp@localhost) by maili.vtcif.telstra.com.au (8.8.2/8.6.9) id LAA21697; Wed, 17 Nov 1999 11:36:10 +1100 (EST)
Received: from mail.cdn.telstra.com.au(144.135.138.138) via SMTP by maili.vtcif.telstra.com.au, id smtpd0dSWNz; Wed Nov 17 11:33:11 1999
Received: from ntmsg0133.corpmail.telstra.com.au ([192.74.168.111]) by mail.cdn.telstra.com.au (8.8.2/8.6.9) with ESMTP id LAA09966; Wed, 17 Nov 1999 11:33:09 +1100 (EST)
Message-Id: <[e-mail]>
Received: by NTMSG0133 with Internet Mail Service (5.5.2650.21) id <W07HKDVH>; Wed, 17 Nov 1999 11:32:53 +1100
From: "Manger, James" <[e-mail]>
To: [e-mail]
Cc: "Kesterson, Hoyt" <[e-mail]>
Subject: RE: PKIX: Use of dnQualifier must be settled
Date: Wed, 17 Nov 1999 11:31:37 +1100
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: multipart/mixed; boundary="----_=_NextPart_000_01BF3093.4778CA8C"

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:[e-mail]]
> 
> 	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

eJ8+IjYAAQaQCAAEAAAAAAABAAEAAQeQBgAIAAAA5AQAAAAAAADoAAEIgAcAGAAAAElQTS5NaWNy
b3NvZnQgTWFpbC5Ob3RlADEIAQSAAQAtAAAAUkU6IFBLSVg6IFVzZSBvZiBkblF1YWxpZmllciBt
dXN0IGJlIHNldHRsZWQAIg8BCYABACEAAAAzMDBBOTAxNjZBOUNEMzExQkQ0RDAwMTA0QjA4REJG
MQAKBwEggAMADgAAAM8HCwARAAsAIAAyAAMAUgEBBYADAA4AAADPBwsAEQALAB8AJQADAEQBAQ2A
BAACAAAAAgACAAEDkAYA1AsAAB4AAAADAC4AAAAAAEAAOQAw0qMbkzC/AR4AcAABAAAAIwAAAFVz
ZSBvZiBkblF1YWxpZmllciBtdXN0IGJlIHNldHRsZWQAAAIBcQABAAAAGwAAAAG/MEWJ0u8cRqWc
MBHTrnkACMckrdIADTSNfQACAQkQAQAAAFkIAABVCAAAfw8AAExaRnWd1/HxAwAKAHJjcGcxMjX+
MgD/AgYCpAPkBesCgwBQEwNUAgBjaArAc2V0/jIGAAbDAoMOUAPVBxMCg5YzED8RRzQTz2Y1A8UR
AgBwcnES4nN0ZbptAoB9CoAIzwnZOxoPPQ4wNQKACoEOcQtgbmcoMzA4AFBoBbB6ZNRvYwAAKhJV
IAKRHhBebB5FCvsTsgwBYwBAIBAxLiBJA6B0aGWAIFguNTAwIARiOGwsIAIQBcAAcHkgNQqxdA3g
dQtgBcBvYt5qBZAFQCFRGhAgBAAi0P0aEGMEACIgIsACICFwI5WpCfB0ciLAWyGSMSJAMDcuM10k
UCE0RGn9JKF0BbAiwCEgImEAwCMQEQIgIEJhErAgKERQSUIpLgqFMiEAVJ8hYQuAGOACMCiib2Yh
hSskYSfQIBKAdiFwYSB7AJAdEGwnYSlQIkAFoG10cG8SsGQrAgOBIsBznxjDBCAAcC2gErBydiyB
+S3kYXALUA3gKIMEICZD0jAiQDZdKYYzKhQpQcskUgWwZwBwaXotkSjwZyxBJgAJ4CAtJz8oSFTz
M6IpMVQpM9MogCRTIvJvKJItkSpxK+BkBAAjEG5xI9FuYW0vQgWgKoF41nQEICFgbC2gYiLAOADP
DpAkIQIwNDBTQTCFJpFWMSbCKYY0IQBFANBonyXVA/AhUCcWMkRhZDix/zgRJCE5wyUxIkAuwgIg
JQT/IkA6sSYwC0YWkiCFOxsfz38g0AqFCodA/yoyIfMsYHTudQbQLLAEIHchYAOgBGC/JDE2cSrx
JUEJwAhgcD0gzwBwOWEr0QOBYWcqUihIvyJjLGYjlCEARNcgSUYFsZcLgBjQAHBjP3F0dyvg9y0y
EsAvQnAdgCVBLTIy0edHEkjhK8JwdQJgBAA8sP4oJxEhlDgANGRPoTYwLFB8YnUscQeQJHFO8wbg
b7prP4EgLLAywAMgZjRQ8m1IyHJ1A6AsUECCNnPfUJFJAiFhUYYEICYu8QUA/xLACsAlESsgT0gu
wixRNJDoY2tiA2BrBJBIyFBm/1lDJIEN4AeRLzAsUCGTS8H0QWwDIDRIZE/ISWUhUfs0UCOAdwOg
OrIiQFJwBUD/IUIvsVyxT+Ml4k+iImIhUg5zOKAlVgQgKGUuZ78hAE9HKXdEf0F7UWFvB5F0bm8F
QHNIoC1gACAgviI4AgUQX2EtkWCVIiJA/0dBJDE6GF0FSWU6GEnaAaD/CGAj4yUjJeNLwTCkX/Je
wPcuoiXVK9FiIXAaEC/0MxL/BGAdEBjQLeRfCCFRKQEKwP1PInBPoisRJTIAwD6ybHXDJvAx5E4g
UXUHQAaQ/wiRIpACQGdESMEEICpxA2C8ZHVNwDMlIuNUEXMG8H9fcCiiK9E9USRyI5AssG3/S8E0
QDo7BaAjQC2gLAMLgP8OcE5wekFgb2F7PSNrwi8w/wbwKIEvUSGUOeE+UDgAL1HbdkEEkC1AgnO7
dgdAClA/d2RsZE+hS8EqMCRhZ2m/LCBWVHr3A2E6DjoZTgQgP3bgX6Vom3r2PXhjbVtJ/iBVMASB
TYJZAkeTLTIssN908Xbvd/UkUiMwcjpiJQH/bqAvQg5wLCAZoE5wOcMDkXMhlE4QcmsvQkhzS8FJ
v2rCdYUEIGbwA3EnEWl6ov90I2ggNeORAVIhNnNxUlKA+zeDOPJqVTAj0CiiPTJVUv+FEF9EcVJm
MiLiKwI0A4UQf4GGB4AScT6RVHAAwCURYv9b4XTxIVIlQC2RImJzunCWfyRhThB5oicRZjBIwYzS
IP+TwDghVEAwJCJTGhEOgD6Bny9Rc7pzMGPtQ18gSI2h/mYjQCUBd6OCBCxQOQWZL/9LwaDYNzBf
8YVBULBtojZ073yRM0EOcACQZzdySpQsIP8mEToYi6ZH4x2AObAvQhjw6QtQb3kJ4C8jMFlBB4CU
ci8yoS9VMGlxgHHvkjEusi0SAIBlqvGMoiJA/yRhZjIv0QNgW3GYYnt2fWHzPsFjbT0+NDCdYpjC
B+D/dIcrtKjxKSBbcQIwAaAssM82MKsyImKp9nMvqWazcK8yoaVVktM4kWKmYHUIYP+HAyxQggKT
c6JzYmQypSiD9yJAk8AFEHM4AJPzY14KhX0hIVJSgAQgoNBSgCyweT4nBCA5QDigijEtID1Y4lgj
gD1BY2GxSHFtse+FQaSSfnAzUjIu0UCCsrO7vCkIYD0GEEcBS8FOK+D/c7GY4iuzl2JJoCJAjWGQ
8X8rIKSREoAzUn9/YnBL0EL/ZkA8sLyDeTQDkZMRYUjCv7tTQQWQYcU1OfECICc4ce+Y8jfUtTSY
YmU8ksQRiRH/eudQ4JYzOfI3kaXTyCKcEv9m4BoQbXIwIi9RPaSSEG+D/TqjIilwc1+AJsjqLqIi
wI+GrcRYgyPKAyAqKno2P0jh09A6o7kfCqkwADM2Pw6wZGx38RjgI9HWDTIxw9cBVEAtMTQ0DrAM
0KfaAwtVFOIxONgHLdwnr2Pt2zUMMNgWRgNhOt0uB9gWDIK6m1tTTVRQhjp84bsiQHNweVUg/4Fw
LTGettYNAcHXL9g0ISD/PsEkkQGQKJMg0MTxZjJuof8FoTRiztaSAcTybqPM5W9W3171LsKamRoQ
ZnBsasI4gv9PIcEzgXJNIruV3wAo8GZw72GxNnO8EiJAT7x0dSJH8f5kLLA/BjqicJe3W0hhB9H/
hUOSoldiAiC+JHUifmEJgN/O1bBCNvch4KZgaOeT8vf/XLFYEu8TvGT34b+VdRMEYP8sIMiTmKQH
4Dqxj4Ka1R2A/05wNmR3oz5QnBIHgDqBmuT/OoHHVCKi7ILA2SmG1n/lL1//HwAnIEUBLRyBAATg
AAAAAwD9P1IDAAAeAEIQAQAAAC8AAAA8NC4xLjE5OTkxMTE2MTUwNzU5LjAwZDJkNmIwQG1haWwu
YWNjdXJhdGEuc2U+AAADACYAAAAAAAMANgAAAAAAHgAxQAEAAAAQAAAASk1BTkdFUjI5Mjg4RUYz
AAMAGkAAAAAAHgAwQAEAAAAQAAAASk1BTkdFUjI5Mjg4RUYzAAMAGUAAAAAAAgH5PwEAAABnAAAA
AAAAANynQMjAQhAatLkIACsv4YIBAAAABgAAAC9PPVRFTFNUUkEvT1U9UUxEIEtJTkdTRk9SRC1T
TUlUSC9DTj1NUyBNQUlMIFJFQ0lQSUVOVFMvQ049Sk1BTkdFUjI5Mjg4RUYzAAAeAPg/AQAAAA4A
AABNYW5nZXIsIEphbWVzAAAAHgA4QAEAAAAQAAAASk1BTkdFUjI5Mjg4RUYzAAIB+z8BAAAAZwAA
AAAAAADcp0DIwEIQGrS5CAArL+GCAQAAAAYAAAAvTz1URUxTVFJBL09VPVFMRCBLSU5HU0ZPUkQt
U01JVEgvQ049TVMgTUFJTCBSRUNJUElFTlRTL0NOPUpNQU5HRVIyOTI4OEVGMwAAHgD6PwEAAAAO
AAAATWFuZ2VyLCBKYW1lcwAAAB4AOUABAAAAEAAAAEpNQU5HRVIyOTI4OEVGMwBAAAcwEAMHXHow
vwFAAAgwjMp4R5MwvwEeAD0AAQAAAAUAAABSRTogAAAAAB4AHQ4BAAAAKQAAAFBLSVg6IFVzZSBv
ZiBkblF1YWxpZmllciBtdXN0IGJlIHNldHRsZWQAAAAACwApAAAAAAALACMAAAAAAAMABhBe9/Rp
AwAHENYJAAADABAQAAAAAAMAERADAAAAHgAIEAEAAABlAAAAMUlOVEhFWDUwME1PREVMLEZPUkFO
WVBBUlRJQ1VMQVJPQkpFQ1RUSEVSRUlTUFJFQ0lTRUxZT05FT0JKRUNURU5UUllYNTAxLDczSU5U
SEVESVJFQ1RPUllJTkZPUk1BVElPTgAAAADZ2Q==

------_=_NextPart_000_01BF3093.4778CA8C--


Received: from po1.bbn.com (PO1.BBN.COM [192.1.50.38]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id QAA05997 for <[e-mail]>; Tue, 16 Nov 1999 16:12:34 -0800 (PST)
Received: from [171.78.30.108] (comsecpb.bbn.com [171.78.30.108]) by po1.bbn.com (8.9.1/8.9.1) with ESMTP id TAA20074; Tue, 16 Nov 1999 19:13:52 -0500 (EST)
Mime-Version: 1.0
X-Sender: [e-mail]
Message-Id: <v04220808b457a2daf4ce@[171.78.30.108]>
In-Reply-To:  <[e-mail]>
References:  <[e-mail]>
Date: Tue, 16 Nov 1999 19:14:26 -0500
To: "Trevor Freeman (Exchange)" <[e-mail]>
From: Stephen Kent <[e-mail]>
Subject: RE: Associating symmetric algorithms with a public key
Cc: "Pkix List (E-mail)" <[e-mail]>
Content-Type: text/plain; charset="us-ascii" ; format="flowed"

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


Received: from dfssl.exchange.microsoft.com (dfssl.exchange.microsoft.com [131.107.88.59]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id OAA04092 for <[e-mail]>; Tue, 16 Nov 1999 14:14:19 -0800 (PST)
Received: by dfssl with Internet Mail Service (5.5.2650.21) id <W8XXL61K>; Tue, 16 Nov 1999 14:14:48 -0800
Message-ID: <[e-mail]>
From: "Trevor Freeman (Exchange)" <[e-mail]>
To: "'Paul Koning'" <[e-mail]>
Cc: [e-mail]
Subject: RE: Associating symmetric algorithms with a public key
Date: Tue, 16 Nov 1999 14:14:46 -0800
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01BF307F.FE1BC1B8"

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


Received: from dfw7-1.relay.mail.uu.net (dfw7-1.relay.mail.uu.net [199.171.54.106]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id NAA03465 for <[e-mail]>; Tue, 16 Nov 1999 13:33:48 -0800 (PST)
Received: from xedia.com by dfw7sosrv11.alter.net with SMTP  (peer crosschecked as: madway.xedia.com [198.202.232.199]) id QQhpqc16364; Tue, 16 Nov 1999 21:35:05 GMT
Received: from tonga.xedia.com by xedia.com (4.1/SMI-4.1) id AA29303; Tue, 16 Nov 99 16:33:01 EST
Received: by tonga.xedia.com (SMI-8.6/SMI-SVR4) id QAA21544; Tue, 16 Nov 1999 16:35:04 -0500
Date: Tue, 16 Nov 1999 16:35:04 -0500
Message-Id: <[e-mail]>
From: Paul Koning <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
To: [e-mail]
Cc: [e-mail]
Subject: RE: Associating symmetric algorithms with a public key
References: <[e-mail]>
X-Mailer: VM 6.34 under 20.3 "Vatican City" XEmacs  Lucid

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


Received: from doggate.exchange.microsoft.com (doggate.exchange.microsoft.com [131.107.88.55]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id NAA03129 for <[e-mail]>; Tue, 16 Nov 1999 13:19:09 -0800 (PST)
Received: by doggate.exchange.microsoft.com with Internet Mail Service (5.5.2232.9) id <WMKC8L04>; Tue, 16 Nov 1999 13:19:21 -0800
Message-ID: <[e-mail]>
From: "Trevor Freeman (Exchange)" <[e-mail]>
To: "'Paul Koning'" <[e-mail]>
Cc: [e-mail]
Subject: RE: Associating symmetric algorithms with a public key
Date: Tue, 16 Nov 1999 10:56:34 -0800
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2232.9)
Content-Type: text/plain; charset="windows-1252"

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:[e-mail]]
Sent: Tuesday, November 16, 1999 10:20 AM
To: Trevor Freeman (Exchange)
Cc: [e-mail]
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


Received: from mail.spyrus.com (mail.spyrus.com [207.212.34.20]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id MAA02080 for <[e-mail]>; Tue, 16 Nov 1999 12:02:56 -0800 (PST)
Received: from rhousley_laptop.spyrus.com ([209.172.119.101]) by mail.spyrus.com (8.9.3/8.9.3) with ESMTP id MAA24807; Tue, 16 Nov 1999 12:02:28 -0800 (PST)
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58 
Date: Tue, 16 Nov 1999 14:57:43 -0500
To: Stefan Santesson <[e-mail]>
From: Russ Housley <[e-mail]>
Subject: Re: Use of dnQualifier must be settled
Cc: [e-mail], Sean Turner <[e-mail]>, "Manger, James" <[e-mail]>, "Kesterson, Hoyt" <[e-mail]>, "David P. Kemp" <[e-mail]>, Anders Rundgren <[e-mail]>, "Ella P. Gardner" <[e-mail]>, "'wford'" <[e-mail]>, "'wpolk'" <[e-mail]>, "'[e-mail]'" <[e-mail]>, "'Magnus Nyström'" <[e-mail]>
In-Reply-To: <[e-mail]>
References: <[e-mail]> <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"; format=flowed
Content-Transfer-Encoding: 8bit

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                <[e-mail]>
>Accurata AB                     http://www.accurata.se
>Slagthuset                      Tel. [phone]
>211 20  Malmö                   Fax. [phone]
>Sweden                        Mobile [phone]
>
>PGP fingerprint: 89BC 6C79 5B3D 591B 8547  1512 7D11 DBF4 528F 29A0
>-------------------------------------------------------------------



Received: from dfw7-1.relay.mail.uu.net (dfw7-1.relay.mail.uu.net [199.171.54.106]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id KAA00467 for <[e-mail]>; Tue, 16 Nov 1999 10:18:43 -0800 (PST)
Received: from xedia.com by dfw7sosrv11.alter.net with SMTP  (peer crosschecked as: madway.xedia.com [198.202.232.199]) id QQhppp29059; Tue, 16 Nov 1999 18:20:00 GMT
Received: from tonga.xedia.com by xedia.com (4.1/SMI-4.1) id AA25537; Tue, 16 Nov 99 13:17:56 EST
Received: by tonga.xedia.com (SMI-8.6/SMI-SVR4) id NAA21337; Tue, 16 Nov 1999 13:19:59 -0500
Date: Tue, 16 Nov 1999 13:19:59 -0500
Message-Id: <[e-mail]>
From: Paul Koning <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
To: [e-mail]
Cc: [e-mail]
Subject: Re: Associating symmetric algorithms with a public key
References: <[e-mail]>
X-Mailer: VM 6.34 under 20.3 "Vatican City" XEmacs  Lucid

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


Received: from dfssl.exchange.microsoft.com (dfssl.exchange.microsoft.com [131.107.88.59]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id JAA29895 for <[e-mail]>; Tue, 16 Nov 1999 09:57:31 -0800 (PST)
Received: by dfssl with Internet Mail Service (5.5.2650.21) id <W8XXLRWQ>; Tue, 16 Nov 1999 09:57:49 -0800
Message-ID: <[e-mail]>
From: "Trevor Freeman (Exchange)" <[e-mail]>
To: "'[e-mail]'" <[e-mail]>
Cc: "Pkix List (E-mail)" <[e-mail]>
Subject: RE: Associating symmetric algorithms with a public key
Date: Tue, 16 Nov 1999 09:57:47 -0800
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01BF305C.17F75D78"

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:[e-mail]]
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) [phone]
61 Fitzwilliam Lane,                    fax: [phone]
Dublin 2.                mailto:[e-mail]
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:[e-mail]">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) [phone]</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: [phone] =
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:[e-mail]">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--


Received: from smtpproxy1.mitre.org (mbunix.mitre.org [129.83.20.100]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id HAA27800 for <[e-mail]>; Tue, 16 Nov 1999 07:33:32 -0800 (PST)
Received: from avsrv1.mitre.org (avsrv1.mitre.org [129.83.20.58]) by smtpproxy1.mitre.org (8.9.3/8.9.3) with ESMTP id KAA07026; Tue, 16 Nov 1999 10:33:17 -0500 (EST)
Received: from MAILHUB1 (mailhub1.mitre.org [129.83.20.31]) by smtpsrv1.mitre.org (8.9.3/8.9.3) with ESMTP id KAA19741; Tue, 16 Nov 1999 10:31:08 -0500 (EST)
Received: from mm60206-lptp.mitre.org (128.29.105.60) by mailhub1.mitre.org with SMTP id 2052025; Tue, 16 Nov 1999 10:33:05 EST
Message-ID: <[e-mail]>
Date: Tue, 16 Nov 1999 10:31:20 -0500
From: Ella Paton Bassett <[e-mail]>
Organization: The MITRE Corporation
X-Mailer: Mozilla 4.61 [en]C-19990607M  (Win95; U)
X-Accept-Language: en
MIME-Version: 1.0
To: David Boyce <[e-mail]>
CC: Stefan Santesson <[e-mail]>, [e-mail], Sean Turner <[e-mail]>, "Manger, James" <[e-mail]>, "Kesterson, Hoyt" <[e-mail]>, "David P. Kemp" <[e-mail]>, Anders Rundgren <[e-mail]>, "'housley'" <[e-mail]>, "'wford'" <[e-mail]>, "'wpolk'" <[e-mail]>, "'[e-mail]'" <[e-mail]>, "'Magnus Nystr m'" <[e-mail]>
Subject: Re: Use of dnQualifier must be settled
References: <[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

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



Received: from woozle.isode.com (woozle.isode.com [193.133.227.19]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id HAA27570 for <[e-mail]>; Tue, 16 Nov 1999 07:26:45 -0800 (PST)
Received: from MessagingDirect.com (actually dougal.isode.com)  by woozle.isode.com (local) with ESMTP; Tue, 16 Nov 1999 15:27:03 +0000
X-Mailer: exmh version 2.0.2 2/24/98
To: Stefan Santesson <[e-mail]>
cc: [e-mail], Sean Turner <[e-mail]>, "Manger, James" <[e-mail]>, "Kesterson, Hoyt" <[e-mail]>, "David P. Kemp" <[e-mail]>, Anders Rundgren <[e-mail]>, "Ella P. Gardner" <[e-mail]>, "'housley'" <[e-mail]>, "'wford'" <[e-mail]>, "'wpolk'" <[e-mail]>, "'[e-mail]'" <[e-mail]>, =?iso-8859-1?Q?=22=27Magnus_Nystr m=27=22?= <[e-mail]>
Subject: Re: Use of dnQualifier must be settled 
In-reply-to: Your message of "Tue, 16 Nov 1999 16:00:47 +0100." <[e-mail]> 
Date: Tue, 16 Nov 1999 15:27:01 +0000
Message-ID: <[e-mail]>
From: David Boyce <[e-mail]>
MIME-version: 1.0
Content-type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by ns.secondary.com id HAA27571

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:	[phone]		 Richmond, Surrey, ENGLAND
Email:	[e-mail]	 WWW: http://www.MessagingDirect.com/




Received: from popmail.inbox.se (popmail.inbox.se [193.12.72.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id GAA27103 for <[e-mail]>; Tue, 16 Nov 1999 06:59:04 -0800 (PST)
Received: from stefan2 (accurata.inbox.se [193.12.72.24]) by popmail.inbox.se (8.9.3/8.9.3) with SMTP id QAA14666; Tue, 16 Nov 1999 16:00:15 +0100
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 
Date: Tue, 16 Nov 1999 16:00:47 +0100
To: [e-mail]
From: Stefan Santesson <[e-mail]>
Subject: Use of dnQualifier must be settled
Cc: Sean Turner <[e-mail]>, "Manger, James" <[e-mail]>, "Kesterson, Hoyt" <[e-mail]>, "David P. Kemp" <[e-mail]>, Anders Rundgren <[e-mail]>, "Ella P. Gardner" <[e-mail]>, "'housley'" <[e-mail]>, "'wford'" <[e-mail]>, "'wpolk'" <[e-mail]>, "'[e-mail]'" <[e-mail]>, =?iso-8859-1?Q?=22=27Magnus_Nyström=27=22?= <[e-mail]>
In-Reply-To: <[e-mail]>
References: <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by ns.secondary.com id GAA27104

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                <[e-mail]>
Accurata AB                     http://www.accurata.se
Slagthuset                      Tel. [phone]              
211 20  Malmö                   Fax. [phone]              
Sweden                        Mobile [phone]

PGP fingerprint: 89BC 6C79 5B3D 591B 8547  1512 7D11 DBF4 528F 29A0
-------------------------------------------------------------------


Received: from balinese.baltimore.ie ([e-mail] [194.125.215.8]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id DAA22159 for <[e-mail]>; Tue, 16 Nov 1999 03:06:26 -0800 (PST)
Received: by balinese.baltimore.ie; id LAA20110; Tue, 16 Nov 1999 11:07:38 GMT
Received: from unknown(192.168.20.10) by balinese.baltimore.ie via smap (V4.2) id xma020085; Tue, 16 Nov 99 11:07:31 GMT
Received: from baltimore.ie (lease157-21.baltimore.ie [192.168.21.157]) by bobcat.baltimore.ie (8.9.3/8.9.3) with ESMTP id LAA15365; Tue, 16 Nov 1999 11:07:30 GMT
Message-ID: <[e-mail]>
Date: Tue, 16 Nov 1999 11:12:41 +0000
From: Stephen Farrell <[e-mail]>
Reply-To: [e-mail]
Organization: Baltimore Technologies Ltd.
X-Mailer: Mozilla 4.6 [en] (WinNT; I)
X-Accept-Language: en
MIME-Version: 1.0
To: "Trevor Freeman (Exchange)" <[e-mail]>
CC: "Pkix List (E-mail)" <[e-mail]>
Subject: Re: Associating symmetric algorithms with a public key
References: <[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

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) [phone]
61 Fitzwilliam Lane,                    fax: [phone]
Dublin 2.                mailto:[e-mail]
Ireland                             http://www.baltimore.com


Received: from Newman.GSC.GTE.Com ([e-mail] [192.160.62.66] (may be forged)) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id QAA24545 for <[e-mail]>; Mon, 15 Nov 1999 16:39:37 -0800 (PST)
Received: from gscex01.gsc.gte.com ("port 4145"@gscex01.ndhm.gsc.gte.com [155.95.162.170]) by Newman.GSC.GTE.Com (PMDF V5.2-30 #29038) with ESMTP id <[e-mail]> for [e-mail]; Mon, 15 Nov 1999 19:40:50 -0400 (EDT)
Received: by GSCEX01.gsc.gte.com with Internet Mail Service (5.5.2448.0) id <W8T1DG9T>; Mon, 15 Nov 1999 19:40:48 -0500
Content-return: allowed
Date: Mon, 15 Nov 1999 19:40:47 -0500
From: "Sweigert, David" <[e-mail]>
Subject: RE: Licensed Certification Authorities in USA
To: [e-mail], Sungjin Lee <[e-mail]>, [e-mail]
Message-id: <[e-mail]>
MIME-version: 1.0
X-Mailer: Internet Mail Service (5.5.2448.0)
Content-type: multipart/mixed;	boundary="----_=_NextPart_000_01BF2FCB.3981520A"

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:[e-mail]]
Sent: Tuesday, November 09, 1999 9:52 AM
To: Sweigert, David; Sungjin Lee; [e-mail]
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:[e-mail]]
Sent: Tuesday, November 09, 1999 7:06 AM
To: Sungjin Lee; [e-mail]
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:[e-mail]]
Sent: Tuesday, November 09, 1999 6:21 AM
To: [e-mail]
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"

JVBERi0xLjIgDSXi48/TDQogDTggMCBvYmoNPDwNL0xlbmd0aCA5IDAgUg0vRmlsdGVyIC9MWldE
ZWNvZGUgDT4+DXN0cmVhbQ0KgBxEANGo0GAuGQ0EAwhYgFo3GouGY2EEThEKG40HAuGsUMZtgYvN
JtGIgIhvBsBADWVuZHN0cmVhbQ1lbmRvYmoNOSAwIG9iag00OA1lbmRvYmoNNiAwIG9iag08PA0v
VHlwZSAvWE9iamVjdA0vU3VidHlwZSAvSW1hZ2UNL05hbWUgL2ltMQ0vRmlsdGVyIC9DQ0lUVEZh
eERlY29kZSANL1dpZHRoIDIyNTENL0hlaWdodCAzMTQNL0JpdHNQZXJDb21wb25lbnQgMQ0vQ29s
b3JTcGFjZSAvRGV2aWNlR3JheQ0vTGVuZ3RoIDcgMCBSDS9EZWNvZGVQYXJtcyA8PA0vSyAtMSAv
Q29sdW1ucyAyMjUxDT4+DT4+DXN0cmVhbQ0K/5ASBop1TWEGCByAlFedPBwg0UFCvTetbkBqlvBE
QmtkdOIpGrxcEXUp5IKEhERYfeHQW81KQGjalbMSQlyeyUdbqVTKHfItlw+eaw2E70y6hYKmTvSS
IxPaKRdDoJkIugQT/SuQG6oEYel6SLuSqI/kxO3vpYc4bH1bLi8VjD+SapivqGnCYLXzQ7lZ/asu
+rwy+LYYUGE9P9Noe9q9vvuWPzlUgNFJ1/1oGgsMYTdW100s1CpyA20FiDYrilBKDJhQUIkhvfrN
AcnIjQTLztERQzCgsP4f7iMXLIupLgeBOTUBgKabvYg9bV9JWbromlSkOt6BhNq6jcOGGCemmO0p
EwH09CwUUHmigheiKjqCaUOk9BN2EQMDAOrW9IuA3OZEg0xxSM58IIN2EyTBuXyOGi0jgj0USvFA
iGAhBcIDjIPLp6BUm2iXDkoCg2nF9NpXBAiIpFDkQZRbkYEg9W7sIECIMIIMMVDCCfSCvoECOoNI
MGlu9YbxCI9CG1oHWdMO+D+EESAwRw0gYbeFYJ6aJE3QQIoDOGQ1EA2GFCQ9CmG1CCBNkCHBhhsU
CvSVpBAgiH4OkDBsOr6CbSCQKEdyEHCCIUcMMGwgSekm0gggnJj2kTdMG2U4UvdJRSCBBhjYqoYY
aCp9I/sIIIJsOWPaljhhuFvRPWnCCCCIJNhjaGoMMGwlJ0RCegW0hSCBA2fC0NhsNUmmR/qGG6OJ
BBAmDejcXRsMGBtiqcb7sUmEkGcEYjQ0mGGHppPVNKggmxFQRH7b07fSD4SCDPgqkfk4Vww2kibt
+jrsMJIJByGpghh1YcNhqk2wT07EJIIg8EC45Djtt1YtvSbryYRmnSSQSCVGcIjlbIg7bpXF6TTa
SQcg7hIkOCTQppg2EzWGG3Ce9J7CSRDNsKhCGIMQhbbFEh9fauggggkoRDKTgi+R620Ewxem6OYp
IKFIZ4m43zD2yPQ2HT+GKUJJCraoNJh7I4bt7010iV0gxxT7VsN2nww1SQSJOQz8CDFR0GU7bsei
dNpJJBBBEnEIHeER4W3DZFt6sMUkkCBLIZpggYisj5t3B+CbSSwQRY6RDQMNxMhsWRx224K9W0qQ
hKkQYEYM6A7BArttjR2UBuO6CQ1hBcHJ5giPBtsmIPLUFhKFUkoInF88YPVO22ne8oVJdL8GDftt
trBEf8p6DSVJBHF/hkXIvbkxCPEUkkugv9t43b+l6oL/m4PZePq2zU76R5UEQ0DpaX/hvFoMK2n+
k0pEdLVL/2+hboP66STC6r/7e07RnFfSOapaSpL/22nbdB+g+6TVRX/7ZAwOW99r3WsR1//ILj3b
uw1y0irjSSVf/2l03yKfsG+kkv/2CuLbh3wQYNpJSGgdr//2RwrbmpBB/Bj16//bsjhbYSa9oo2k
kQSx//9oW5PhWu0mH4Sr//9wYTfpww0lCWv/4INuxry0izgx0giMcsd//7U49uQxUeMs5AJi2kkv
//9JkdlzI+Rx8IRln8FGZhztAISgHIoGDsXByaBgiYIU5EuC5FwXBkIHqlev/7V2hBts1UzClTA4
JAahFgNyGFIsCGwpLApmCuRQIRcOSAOAQMkwOCGEIuHIGFIqBxggZViggZGw2AiDdVIooDKgQEDC
BggYIgoGgww0lCM+CI/b//2ur6X5BsEv693hB/d+E0wQYQMJphB6DCBqEGEG3VLS///sOO27/w/p
69LCD9JfQegwmEHhB4TTVNBo0VSSS27//8M46g90vw/StfrQf1+nhBoNPT0GEHhBhPDXSCXsjhP/
68I472/8P6v+sJ/SfEPVMIPTwnaqnQpJJUrh//6VjDKdp4S/f71/3//oNO9PTT0GmW6ql6QSWL//
1sMXTuiRfh//9YT+vvTTXT00NU0GlSpBKw///htLfT/f1aX+n6p9+iGh6IZ4eiDFvRAjHIPMg3II
Mc5Bf2W4moPWqUEU8xv//1rfv//f/5Bip//IEHeEQwhyCaNEH0eiDkeQcigQNIg+lEE0acdYhJbZ
If//aRepXbo3hvyFWCFLhyEWa6/6BA3/fCD8EDaCDwg+gg3oIN0HhBtJ8MNUgglVsj3/96Io+w+I
QPOq/lWC/78hNz8hVgIPIVZ6yF2MTek9N030303vCbQQbCBmoL0EEtsf//yx1thttN7/hv+6/6b/
+n6bSdJ+n0E9OvT0D0oQSyx23//i44b+1BP+H/1/0n/vpvp+69IN+2oen7cOuklht//9u3bueA1h
/2/2//p/16fVun30vSevdJ8H6QWrf//VoN1fDFV/b/69en/kIP++v/9/90ungiPjSFBDd//1t1C+
01/f//9K//69Xrq+r6f/7Lda+giKPbf/+jgjhU/DX/b/bS///Sb9/v+v9K9/XhrSLHV3//6wQQhb
dijv////9P//X01rrpNe1e0tC9Ukt///FW79iP9/3X/X/79vxHG/HxfFcm2tqqVW3f/6CWwe2v7f
91/9/pP/qoS/714f1QTTf//kPFQ9uP+/9f/r6//oEgv/eCqiFxaSS2///0gRH2/NL//sf//2rf/g
oL/sPBeOsMd7//wRHsXdPX+/9f9f9f/gkCX6w8jYbNroIm6krY//+3dut////X19L/fkGRXJMC/I
Mh8gy0IZw5MAXkGRuq1wSSTv//+RH+7/79WvrH/Sb++yIDLIQMv/ZAx0qAzLB+KSW3//WPLk/kP/
v+/+v/f/goJf8g0DwSy3Vp9LiG3//Fvt+C//0v10vX//CCCX+xhBd9Ukg///HfbMB//61/r6r/9B
IIL/DhLQNfhIf/+3vH/f1/C4X6p//QSX+6CwtLQ3//3///CT+lgvhVv/0CCBfuHQLpfRBH//ohi+
tyJOdf/flWGevBcEvBd//QKC/wdAqD9UETHb//0E0PmSf/xUhRHisF4qv/0CQL/KsMqCZCJOH1CC
t/Ef0P4eQVtSClV5Blrt1+d1Bl+t+vIQxkNAGQzmeQhjyESIiYEIhoAvBF0PhUWOYe+I+yY5Edv3
/+tepBSFlIKVa+QUi3W+iDAkQX2/r8lIeQwJ8R9Li3hB1f7dr/8J/hZEga+qb/75BBYF6/ugXrFK
zDuxGQvjnH9pf/rrrIEGpwl++/hILf/em/1svPCiyOC/c4///f+CXX/91VXft0SD4X9Vh3IkZ1WC
JDj8R//br3hBcNJv+9aq7r1QPyDF617HKdGFlB63lQv/3dcPCC7/tLesgxMgxPXv/W19AiPoN4u8
oO1ZCxzRE5f/h/+gXe/rdrr9t+/f7a/SoPNlqn2/8f/5CpL/IUm9AuQitrffv+6+vaX/0W6w/eQz
j/fU+XMOQo7X//5GgRtLyBg+iDQJ8gYYr9YcNf+G2ltr+raluFt/Y1UNBhdVS1/kKpkKseQizb/w
3IVaIZYvw+3w6ttK0rSu/tJtX7S/0Q4+wYQtNrXIo9tnjyEz//fX35BQVkKs265C7GQlDtddYbaW
2t9q2r18kPesWCuqZh1dj81//Xt3Xt6IZwrh1+1g2wkw1bSkDFAwlwwlaUMJQwkW4Eq/WCI+GgaJ
at9YiL///+7//Bfa3wYJSGXQGEoYSgwsNgwXYMFYYKwwrBgsnX/SW3oqyNCFhWLIcdr//1/tffQL
334+NjY9j2KYMui4MMUxQW//vIzL/k6as52R8jzv9//769+v6+pCD2qra+I6aSKAX4/aJ+P0SGUM
Rf9f/7v/fX3t9btNNSEHtbCadp0/q8EUPu03NFyI9+xU6r+v7df9e6/IkL2nap2sO004bfk36O+o
1poLJ9mHshIO/aJPX/X+v//1f1u0wmt2tppphQRdfv7b2wgwgwnXW7jsYv////0RMT/fw1hw0Gg1
hwwsMJoMINCMpRtj7rDiIaVjkK41b/r+2l/6/pfsLcMIMJhbtbCBgmEGEPst0t0k55U8e0aL////
//94hhCHDCDCBhCHBgsGEGEDCDC7ba4oGhCkPFwyFHCVYZI0v6X9///6vgyIpIqAhKwhKQgNFQEy
NCEECEsFIUMmw49vdXJe0z9CoM46RDY/i6/pful/6/15NzQQREQg+23uGq2pommt0l8H/////+v+
n22x/CI4ZaYqu18jhD/X1br17/1b9e23sEIizT6ul2x/pf6/XpfX+ic28mP7szA/TWDI8HrDf9fS
/13/Wr+E37bbFgiGo4tBx0F2/6X8fr2l+r/9222yB4buwZDQODTDSIR14Yf8JeFa9dtfC1fpPtht
5Y5BSHEER2iDA5DjnHIUfhJUW/b/gl4S/CXa+kv5ZCRf93scbUR0lVLhh5BSQQNwxyBuGNrsqwzy
BvqGEpA30kwDH/DI6re3d2QJBzQLe69LSb/XXxWwwXjpuQNzcvjb72Hdx3bG0kkl3+umuuQ2Qul/
XXt3bdHHEER60kq8EF+F19YYr9/Wwvdt7NBDVcw6kC7qI9JaIYn66/64XftsMJbb23bIZsflDkUd
B9fzQIQn+un4W10l+8U/b+23GNLpUlrCJcvwuFXWGuq/n1XJjhtttvIGBw3dJGHgjjkhxpKugf+F
18Lrhbfi1dl5/tkCIZHd8fyCyOukuQY0f4Lgn4LDC4S/hhbt2223MO3bfkh0iBA5EHWkvnQOv5DT
F8g2qi4LDC5DaBr8e23t3suKRzv+ccchR1Uk5N0l0qlOKss/AXLYMe3vdvZdtkd2R4j6VL61IEOt
V6B2FLOcMW3ZHdv7M7d9/FCtLpE3JutKqSw4PHt2yO7du3vfxUPVJIJBJJeq4jb72yO27bt73ox/
ow9VpKd0klqvbbI7d7d33bjkUfSMPSSpBBdVVJKqkBhVdsXdt3tt/0n0gvSqEkklXqtPuWPbI9u3
v/Usf/Faql6pJLUgMT6tu2R29t/7v6GNUqVJUElrSrNayWvt3sj227/GGIRHYjVJJJVS+uEH3dtu
3bd/bjjPhFSpUlSSSVb132R59vf25Y5AgdoJLSQSpaWiY6pabCe3bbb27uQ47GCBMjojwLVJKlSW
kgv7Y2yY7bbt2/ZDuyOMIhBxjEaVUkuktJJNFOjCsF4bfbbfFEbt2QwONkx2qpLpdJe8dojabbbt
vt2wmHboGRXZmGekkqVJCgkkPELw27bbe3CJQ2+YdsqLDRFetUtVMP9OE9tsjztu42+/DFiKRnFJ
JJJKhSSpwm3tkft2V5J3vvCqkWOHVL8w66KINQrsNsj73mNW234hGyRFdJVql6SSSWEGwoIiPvYt
txCIx2779kdG9+pY40kq41S2pNQGCkDCt227bGG27uQg7lXHkx6SSCvrSSSUIt2S0DwS63thEfuS
hvvhCELjTdLxoJUvqn+Shvttkfi2232Qo6MTNeOkkW/XSSXzi7YVpt2yCDtt3wiIOyOwmg4RHV+l
pRSMOlruH50yP9q27Zidu2RR2R7neDYOMw4pKpnesdL7rcfFbYZJ7t+rYLQiHdJ0kkopBJKkECI/
r9sMK3Ydtt9kcN4ozP1QpJJUWOkYfVKP/yIOtsNu7bdtu8qGIVBTD9f0kkl20l02hb2273RY97zE
OYkKWkFSpVFLXH3Cabb7bbcNtv3aYMKr0pbjVGH0uwvBomK223+2/cO4NsNKKSSSSSSpKwYR1y+v
QIG7b22yOG2266T2kjD0kkoilpxj7EJt7bvbbxGmmIRQ5xxCS6pUYdJK3S6bbdt2jO3bdNBEfL96
UaVSQ+q17k/dtu2Kg22xz4EKbaEJFjqgi3ow4pIJE/ZdX6Cd227QbbciD8bed0kqVIUkunEGH9bb
bbDgm7aJPehBBY2ErVZhxSSV8Jbhbe8lgbb/5zBRiEixxSQQ0krmt1+9htC3tmROLNpYSWkiY5x0
kkxTYr+9yO224S7SUHlQkkqSSSSw/2dUYVK2223sYWvxYhTDikFFJJBvW4/bbBtsNuCkfvSNoJoJ
egRTlDpJJh1/al9tw23sEEPrWQnQlSFiGlSOmG0vh6V2222wwq48k4ZnUtBJBJAgbGt7YXDbbdsa
u6OOkHSCRY6UEUOkkgm16CYpbbd3xHq00EsR0qouA3XB2qbbbbgk+gRQ4bFIJEY6FBIJBBw1200k
2G22HSdNlw7SUWEkkg2RGtiGC2222Id/2kEWPSXeST8VbbcO2CBClxCRFHSSCStVu22HBhhSDd9L
CCSO4IjhEt0vs5sNtg6MJj9pJWEl9raMO02w2xF0kwmISVJeH9Jiw22UCQhWggkglfBLftthpECB
mSHVQkr2vJfSVsMMaOi2E4hJIkJ0hWwWQTjkBhtEIOCNNcQqCCSbevaBJhthqLemCQSQVw0u7glY
YYMKcRxkfphqEElsUt7CVtgwmmCGKbEIIKGGvhQqDDDBgm1aFJYYJblPFBMMMRHCCCsmF4ukfgww
yGtqEErXsVBNsOgggjpMzuS2qihYYYcIJJVtYRIeGGGQ1HCBBN7aVJkflVBgxBBBHX9t6CnQwwwY
IIJW9t5AYsLuGwYMEEEkG/6b6DBhgyCmQF3vBQVtZY7DBkgFQEFviNhhikg2DIgZBq1BbfekmwYM
jERw4IIp5WOgg6TYZCggJf41lIHIqCXTkYpAYspcGQXBgnt7ilZEgVyom+ggdLIuGoCboG6wuQQF
ASi4TWkjpCESQbI8gNj1CBpW29Q3QQbt6BEfhA2wkid3OLxG0GGFSDZ2azpt12KSbPV2F17C+9jY
rOPGryKC3BQiIUQ9aRGGYQQdsKrj+ELl27s8mECB/0Rj0g3M70x5AbX/UE6Te26tfSVL/bsLUEDf
hl/0tbiFfbSjr3w2wU8hjVrS/9whuxU18e9hjw0o715SeVEMFT3qwgTiI+64w5AaJJBm1d+9ON2w
kgqoGRsdnKKGqkVgxhhQRH7QuGERfF+Ghx52pFn1PsWDjB9aqdl1WjtOQPb3uSIj5VUwxwUZIRFE
F4pSZBUFaDQVeL+2umQ1dfGwVptaDCw1FoGCeLjH/ABABA1lbmRzdHJlYW0NZW5kb2JqDTcgMCBv
YmoNNTE5NA1lbmRvYmoNMTIgMCBvYmoNPDwNL0xlbmd0aCAxMyAwIFINL0ZpbHRlciAvTFpXRGVj
b2RlIA0+Pg1zdHJlYW0NCoAURADSEVAaNxkLhkNBANRwOBdCBAICoRAaMBBGIwcjPAxeRowMRlEy
oZovJDHGZIdxAKInExTFDVJxaMxhCoZFCIII/IRmLhzI4pJpuMBoMhzKBALaKNhkMZXLSMbzkIDS
bTaZTIaTCdDKIDkZTYZTCc6+IJiVJmMxqNxcMxtKp1GRcMBiMKEVJTTLrSJyVJYKCcbzsZTaYjLV
buLBAMRzj7TMxaMhwNbfcRaNByLhsOJJO6KMBnUIpe6KMhkM6iKCoaK+Rq1iTCbBAUjLZjlhRAQj
eYTkZBAdDeZDCeRAYTcbjedTcY61Vjoc+OcDgcsJsxAbzNwddkQaLYlkxpQLjc6KNRnedNdYRf8D
1TecDec+wYuMQuLiTSczHrhAJA8vkFoQOY4ArMSMo0jcOYxOQNYQCCI7GCa5g0v6xgjsSNrkDyHY
QCIMo6ui/oyu8jDxIivLQKUvi7By9yWvwN0HwixgjDlBwzDqOQ6QxDUOQ85DgCmOkLDRIo3I6KA5
DSqg0q9J8ICEJ0ICaKQnv+N42K3JIWRMpaFvIz66BgGAavKvSltOGjPIowMiSNJCOiCMg2wU/Y6R
xIoyjW5DhKpKUqCDK0sCRLUuDOxggynKsryzLcFI6JwXCsF0vJkmkwok8y+hsv71qNM7VyFQNGyx
GUH0nSrGNm2jtQgNo5q834wjaxjWq+Jwyjo1w5DZIQ5w8sj+uCN6wV2MMFQIOEvxQHM0J3FoZsqp
Sisc1U3Ja4TGoSGoQDgxLnDcOjsu3XivjsN85KtccEVk6VXiSMgy3GOQ6jmxgmCYIbGV0lgsqoNd
+jLf+A1YNwyWbTUVTIGIcKS0s1LrabSMBbVjXoM4wjOr9lDCMd1rK44QOdHg0jNCyuyaNzjxENEn
Do41lDGN7kjLkGVhAO8njQEGUDc5Axq42khYU8dnzG0+kYjFs2TbiwUOUN2f6DobgxxBePyLmrpV
JdVe2PX6vOBrQ0jtJ40tuFzvPDhcxxaGIb4rUC8YqwIgjoOmPtc4D9u4r7eN8MgTukJ7fsTsOVST
Yrub9sua7XTDwJGzLNs7t6ihoG9qtXvG9P6rNxu8IqDICA1lbmRzdHJlYW0NZW5kb2JqDTEzIDAg
b2JqDTgxNg1lbmRvYmoNNCAwIG9iag08PA0vVHlwZSAvUGFnZQ0vUGFyZW50IDUgMCBSDS9SZXNv
dXJjZXMgPDwNL0ZvbnQgPDwNL0YwIDEwIDAgUiANPj4NL1hPYmplY3QgPDwNL2ltMSA2IDAgUiAN
Pj4NL1Byb2NTZXQgMiAwIFINPj4NL0NvbnRlbnRzIFsgOCAwIFIgMTIgMCBSICBdDT4+DWVuZG9i
ag0xNyAwIG9iag08PA0vTGVuZ3RoIDE4IDAgUg0vRmlsdGVyIC9MWldEZWNvZGUgDT4+DXN0cmVh
bQ0KgBCKgNGQ4HAuGQ0EA3Gg2F0KEBUIgNGAgisVORnEANF5GGIgGIyEERM0UkZUMcWk53EAoFsg
EAtFMRNQNFsMFw2hQtGIxGAuGI2k5EEEdioxGYuHMikk2n4wGwwGsnlNPGlIlctIxFIhFKRBJggK
RFKdeKxFEBTLJTKhFJszKk1ng3Fw3oQtGg5nI4ocWF1SG4zqkxp92qcRlgoIRhPJlORpOZjNBlEB
IPJwN8vOpuMggK2OMppNxzMRhNxrEBBI9wmtRhE7oIuGtCiNEp42GsfiMpFtPHA0wWIlpNzZpyQs
EBHxxt0x51k2pN3GdJkN9p8Jwe9v/AphUxJEMp1OmRyYgxen1OrmlOpV32OzvvaGFI2kowl/qX1x
JGOWmNYzDqOQ6OQ5Q5OYNznPWFoaoOvgWumoDuqI+SfO63inhgHKshQKY6OMNEPDcjQoMeN7Hjo0
I6NSIQnNSJopCeyo3jYMjRDO58HhoFwZpEniHPg2r7hgGAaQtIQYsO7yWw7D8Qo0IIyDa0TIDo/s
PDKNbTDoN8TRXFogxfGIkRnGsROeG4YoRBz3vq2y/x47Knty7rEiDFkXRhGUaRsEAnBcKwXTOvaY
zY6y/hqGa+N3ITAw3O0vzC8z/T7P9AwUGafuxHzZTavwYR43T7Pk3LgyUFAgjYNgQDeMzUjaOcUD
kMgwja5AqPKJwyjoyY5DY0wyDnHE0Lq6TqQkwk4r+GKDQ2J9ZMc1I4DgOQ3jtPgnDfDwxjKOYQS2
EAixEMIzso0U+jeNzStPPggjHD1rSvYL1wbByrzVQypPnZKoBzUrEsWxrHvIyjLMwzTOM80DRNJS
bVBALgURwn4ZrtRT7Iq4QUC4GQZBmIQkCtHE0hrkkjY1jgaOep6gohUSnhnIFTC4FLkDCEAzRM0I
zjcEF1DXG1hR6hL2vjlYYSM+UMw3EwztMNI9DDD10BAOY6jENQy3dbw3288rztRMc9xEEAhjeNo4
Oa1OtYhiSEKCG7Bp+GIchvJLE43juPiHtQ6ZE2WS7jDe8ZS9cMBplsLr/jr9Jbmea4Q8DxYHlSY6
GG9jwwHL68To9mYzr704fiMFN9NG4r+Gwbw1jO8BnyLxskymv79kgayNjGZZRtr5hn1eXPxRHBJn
X6021EE+RINMTDTFHmS9PExTJPm2dJHYYcvwPWY4GdH8oFuh81QykKWwdTzD2nAUXk6E5U/AabhR
b5Y73275p4sm3ZKMp1hKw0ywlpLgcnnpgTy2FMoZzkKPeg95yzmE3u2X2DVw6G4DLXUq48zsCoCI
xdAn5QByGfAgDQ9JsYY2zNoDc/5bod3mBoXMrsMsDEdPhSChQGyoXOKfVCYkNoZWnNjVY112QSG9
rtQHCIMIdjKByDKHEOq3EUGdhgeYN4YVZI4BkUoHMEFFu4buxwGTuykPwd+kNkiG1uhhWktQOwYV
VGbDItAObWWpM8BoxAMbM2IA4ZnDIuqxz5AzBi4hTxIU6EtiDFNvTfHRHVCqC4KYLghguYeQluCy
zgR4j0CiPgKWZggeJHNdzymeMcBqa9VarZFRViugqLIOYtu3cFGB9rHUiPlXkXEkz34ZqdkCDV3x
VVlOpQ2FIMoZw6q+jqCALMjSRSTCMC4KUlJTGvk+t+JgdAwrmDqHBrZIIslTDgY5bYbkVSJPKHZb
KfDRKxihLkmpFZeR/aKm8GSSZhO8X8S1cwSY4zmDkHUOZyAmBMCGchXJLAsomDXQgMtCqGOib9IK
LjF5Zsdd26lk0/gy0AoE+iipKX1uEl0fJujp3rg3Ys/WDE36OtNXI11agdQzhoj9DQiUhUir7Omy
0xNHKPRpYQtlXgIA3LohC1UMQcw0o1itCoEC5gwyjbGGGNIIFtoCDSGY4zUZSSgPFCNE4eaJPVZI
Xl7LuWOhDCC4OPp6wikDICANZW5kc3RyZWFtDWVuZG9iag0xOCAwIG9iag0xNDM5DWVuZG9iag0x
NCAwIG9iag08PA0vVHlwZSAvUGFnZQ0vUGFyZW50IDUgMCBSDS9SZXNvdXJjZXMgPDwNL0ZvbnQg
PDwNL0YwIDEwIDAgUiANL0YxIDE1IDAgUiANPj4NL1Byb2NTZXQgMiAwIFINPj4NL0NvbnRlbnRz
IDE3IDAgUg0+Pg1lbmRvYmoNMjAgMCBvYmoNPDwNL0xlbmd0aCAyMSAwIFINL0ZpbHRlciAvTFpX
RGVjb2RlIA0+Pg1zdHJlYW0NCoAMBBAoEcjOIAaNxkLhkNBAMxkORcNRkIBiNIcMBcORsIDkZRAZ
gaQioDRkOBxDIcNxoNhdDhAVCIDReRhjForMZFApiY4GIJidxAKBaIIqLRTMTUDRaMhiMY3R4xUI
7MSIIJrAhiM6jQCpOxcMBqOBzXp8LY0MBuOJvQaHQCESCsLBARDKdToczGaJAQjCbjXdL+ZBAQSE
TsKTSkTxBgxAabyIDmdTEczSZDSYTkaTKcxAbDSczoZcIYTEbztIM0ZaSVKWLRpYRwIBrE5zMqwR
oFKRjVa+DZ4VJ9waEKBjraXAqbCxhs6tua1XBzt7AMBkNxnZhBaLDLRrXuLfI+YTNozkIDGbzYbD
KYzoadSbDzHjKZjKco/hDob8bnuQpi0hwhTtOIoYuBkGQZicN73jMNIxr+vL/haqAaws26fBRA6G
v+tIZhusqeu2tIahutoqOKFygCMN6PjSM43BAMS/jWOa6Mmvb+w67beom3yrxIGaYOFEawoU3ziw
XBsHwjGwQDaML5jKNwzjCM6QDTGI4PuNrQssMT2RlGksoOML3PgyDOM9LIQDovgQCqNzINIEApjo
MLRjm/4qBUgawhgGgbu07jrBnEMUKGzCPvc+U2jQOQ3jqM40MbOAXCnFQxDkv8cxaxsrjcMY8xUw
qQxaMsXxjGbASeOrRLoNA3juMrUjkulF1Q1M9z7QjsQxPyxSG4s3L6N7NDJCaFhyHKKQI8EDQQGU
JrSGQbO/ES0rU7K3BQzw4M3Twwjhb7UDCNgQDqNwyPuyT2veN8YhoLgUDGLgU3mHF7Ta/kpyrK7H
xjYk4Tk0bCTtPDO13YDr1/QiW2Eoc3UhSVKDCEA3XhVY1skyjLMwzT5zZMz3jtNLO0dPDGo+9A2D
eOYy0aj42YQ/T+Y1MlSCTgI0NDhVCKfIaz2ytdn3oMOXrpJQ0wdCA3MiNAwtS+g4jqzuCsbcdIDt
c10XVdmXzPeAQXlel7XxfQ3jNRy+iQIbCvdfefWo50iWylGi37K0sZ2kFyDhl06ZHND35PNmBTjO
eDTvPNHYnSYQCTdenDlVzG3UEEGPFhS0ho69BrSGwY0O4uMDdjWOMqy7Ms3k79hBcmS3XtY25eNj
Us9KA8DSNo6jakL2d0MQ0tAOmQxi0XKPcOrNyptY0jluU/0Nz6whiGtt0QFHIymOnKDmFuZZoxsz
5Lwg51JFjzjh5e/5ez200c0PMDlddbPo+yP1D1r+cF8s1PROs9ZAif0EtFPSuoOp7k6BiPm0ppiT
WVN7NG15mr912Ouf6yYz0BwyQJauxJSKk4AFOaCsA6xtzivbcm5VTzmV2BVUuip0rN3mnpDaHAv6
agXH/Nic1HhLgao/YWDRE7QjugzewcUoAQQ5svDoCAMieGLGrP65htQSl0kgBmDAujollmCcupsw
CZIoRSgjFV+BdgxhlDaGJdgMwYxdWWSlCcPTZm1Wac8rIIDeG+J2s5bi0ilHANoSglRXirx7K2V0
nRwDuvULEdNorhk3uIauwdxibIDhuXcGlsQdzIKUQcG5ThmVzmOdLKOUrXHul/Dm4JeBnjBo7Kab
EjkiITImkgtWJJQ4XHnfC1eDL5odyDBitWQ8eDbyJN1HwFxvSvR/Ww0U48gwWg1NiQ07cW5Dx6mb
IuSUjVCERUEth6pYmitKjXFZtbr1IPtXMYIMwZkWmYealk8zVk6JbDkHOWLlnMLjRaHRdJkD5n7Q
mgOWpG4hJBhKr1arRTJhiS7E+GwbXuJOagZ6NyU3XmUNAHMvhhF5g2Icf9BJsUBnBSAWEGpapAPZ
CMaQ+65j/hFJLFsl0twbIJBcDcjsRCGGzI0gNlZIiSANSESmbVPTazLkIiJn84XsggP+VwjtLFgA
xbocNooUgyhnNCeam9OQalQBwQ6npXKgNjJdD6opFajkjpyDkG5XanEMkQgAsKH3sHDeqWxopRgZ
AsBwDYjq84vA5bMClUgVC+ITIgbUGxs6FoDOeWkGNbapIesq0U99GFTHnQcaCGobw20YacZ6jYIA
yh4Dg880kYD9JvCEsZ+gILWwHY8fdOjAm/MuptIM5RDaGS4ODEYGDokkFDMcuZc9F6Mn0jWfBOib
DQKTie/BgQZmRotM9E60abmALtbCvFea9V7goXyUm7lkbiHbuNZg3ChI4LXbq9WAq3C4tuCCe6Yp
rpCULlvZksJTqupFUAic4pcS5gglBeQ/ad7oyxPUZd8TR4nPvbUCREp33hHrk8G4FlKAclQmOT/A
x1gbzlSIw4Gzoy3vyYE2BeBhGZkGatHU2RtDbS4j3H2aNUW6tFkFgIpqApHgtm5Nqbx0ZGG/Q8DO
/FyiKYuOLdIOQY5TJijG81FqVU5B6TxiO8oR0uF/DzbSgNNXGKaU4XxNaMQnBlKEFlFpgZaXGwKb
hEhTpIIml6CjOud885sCGzxCAZw3l0CTiJjBoc2F/U+lNUV5QmMuMKlRmBnS6BDXM0tFqcgw4BKX
Qq+cy2F2Cs6d07DRS7F4L1bZGhdMIqUwm1y3mF4ozCiaGUyL8ASEKIdiE0C8C6Y0vhkjVEtqGvVS
FJAiFzQUY5SuaI9FqKMZby7DQg+YYc5kXejFNmaA5JQDcqMoGsS8l7L6jTbLkz1GeYkGU1l8bL6q
Q8DnBKhAa4yW6x11TIMvI1vK4dgidJMaecsYQN8/GESyRlGJHKbNCggzwHLPW+M+bPBgoaIuCix6
D4vxkwPDVKkfW+Z17mZWpNpaY3tOulAjcUNCenT+oZ6By1JqYhJR9U3Ir6Dmv/IgcX4OKYYxAQTF
BP1tKFfeFN4z+NBr1wOv9g4dmxsV4ex8SGP3psspdOAGkBANZW5kc3RyZWFtDWVuZG9iag0yMSAw
IG9iag0yMTI1DWVuZG9iag0xOSAwIG9iag08PA0vVHlwZSAvUGFnZQ0vUGFyZW50IDUgMCBSDS9S
ZXNvdXJjZXMgPDwNL0ZvbnQgPDwNL0YwIDEwIDAgUiANL0YxIDE1IDAgUiANPj4NL1Byb2NTZXQg
MiAwIFINPj4NL0NvbnRlbnRzIDIwIDAgUg0+Pg1lbmRvYmoNMjMgMCBvYmoNPDwNL0xlbmd0aCAy
NCAwIFINL0ZpbHRlciAvTFpXRGVjb2RlIA0+Pg1zdHJlYW0NCoAQioDRkOBwLhkNBANxoNhdChAV
CIDRgIIrFTkZxADReRhiIBiMhBETNFJGVDHFpOdxAKBaIBmIBaKYiagaLRkMRtMoaLhrO4iRBBHY
qMRmLhzIpJFBcMBkMhvJ5SLRhTRoMRzK5abDDGTKczoIDGbzabTKcjGaTCbBAYjCbjWaTdGjfGbe
aT0YToaTebhBcoiaDKICcZTpgjlXDcZDmLpGQSEThAQSaUifYr6dDkbzYc5oVJtFZwNKRQIlFqaM
6jEanVRhP6UVJYKDmZTsZb8ZDKcDeczSdLqeb+brBvzre76c+GICSbDZcjeaeVbzIIL7g7HZbPab
Xbbea+XhZYWbqa8dn9DMoSLhvsaFrhmOIhKJlrhqN9Ns8hksplhAITvsIFwrMctY5je6w4LOvSvr
aOS3jGwTlMAITeuANwWBAJowjmOYwwiOrajoOg5h29CTNG0qTve1IYNM1qrByHCtBQIY0DSMYwjO
N8Mua543OjErCDK8bywy8QQPIOQ1h2EAoN/EgxDqjI0QyKDcOIPI2Dsu4wya6gQCmMq9DoNgyhZE
7RPW9sVtQGAZoaqT6qaGr4xoK8ORuucLy+xYQR03C0wawAgzKt46DDDIjjKuozrVJomrUNo0wyIw
2LqNIyS8EAkDfEMLwyKgyjxDk+jJNL1NIHLTRYGAaBwmLWTnFwbhrGgmN6ya5jLMzpz8Ka3hAI0H
jctI5rHDIhrWNIzLqNy1BdE82RTNigzc1TYxg14bPm2Yiw+NDCDevYzRxQ8/s7BDcDPQEJr8MIQD
cOo2jEs7rDNeK+rcuC5I1D69js3400GN0Thbab11XNqqKahMXzc19upaw7BirZ46DK6op0RjDGxO
IqBoCA1lbmRzdHJlYW0NZW5kb2JqDTI0IDAgb2JqDTY1MQ1lbmRvYmoNMjIgMCBvYmoNPDwNL1R5
cGUgL1BhZ2UNL1BhcmVudCA1IDAgUg0vUmVzb3VyY2VzIDw8DS9Gb250IDw8DS9GMCAxMCAwIFIg
DS9GMSAxNSAwIFIgDT4+DS9Qcm9jU2V0IDIgMCBSDT4+DS9Db250ZW50cyAyMyAwIFINPj4NZW5k
b2JqDTI2IDAgb2JqDTw8DS9MZW5ndGggMjcgMCBSDS9GaWx0ZXIgL0xaV0RlY29kZSANPj4Nc3Ry
ZWFtDQqADAQQKBHIziAGjcZC4ZDQQDMZDkXDUZCAYjSHDAXDkbCA5GUQGYGkIqA0ZDgcQyHDcaDY
XQ4QFQiA0XkYYxaKzGRQKYmOBiCYncQCgWiCHC0UzE1A0WjIYjGNxUWxioR2YkQQTWBDEZ1GgFSd
i4YRcb1+fC2NDAZjMc1+hCigEIwm41iA3mYQEE2mU5GkxmEQE4qCATCApkEWCAhmgwnI2G86HQy4
knG85HQ0YrGm82Gk3GHE3MyYo0nQ0mK5mvKC4gi4WUkqUup2IcCAaxOczKskaBSkY1awA2eFSfcO
3jPYUuBU2FjDa1fd1uujnc2EYQ22z0QWixVS3UMnGWhFnLarA+IQeQ5ebGHaQGE4HDO3/TG83HMQ
HAym4yZ6DjEMozMskDMJAJ4zDMvyQLuEECuS4Ttt+ibgKwtIYBqGqzO2tKGrKoKhiGN42jgOg5M4
Ni+LsvECsUOo5I+NwxjzBo3hAzz3DmOkbP4NKPjGOg2RmzwQCSMj9xKOo5hcr40JAxYwjmkAmrmx
jIrnB4qBVDaxKem7tO4GDnS8Ki3rkujKPQ9TzPC8bysTHwyjS9zRxY+A4RMOwwjZFUGya882vWww
6DCyQQTMNb/SxLUwLHDMvrSGIbw9MihiIMo4MaOi9jdHQ6RrG4yxzHb+x9IEhDdIkjU4OUkyWEEH
oaGgXNq4cKrEGYcJg4ifw+FApjKMsHiKkoZ0i7oQBkGYbhcGKKhkjTfoGFyFI8kCRJIBq12XZ1cQ
mr6ZzBXDn13SCOO+uAmDKyMUjNEw2hAKEliszwxyOxT7MeNzXqUpgZBtWVzBbCQawpLbr4JDULX/
c9LDgOo6RmKY6v0vtOP3VUdQZQ45zRQC6inQdC0O/wQYbTNNjoxNPBAKT7T0MkHuXgeCrStYZw1M
CKUdSgUCHJcpjyvjEipP0nyiEEpjdKtB1RQ7EjJQgytGIM7jTPYcsSGIc62EAuBRB+BBdYqKYTc4
uBlZMHhmjFmI7WuDWa3KzwtSa36MkF03WOVhJKGkJIdZ6Vo1hCNWoj6QpHvocJdc1ntujFvqYqEM
bI7TjKHs6G7AtNzcssQbhtca3i4FMl7Bv1ZWpgSXYQ6Dh7nLjqXPIsj1Y/Ayjw/UfvwyEmjkEAqh
cKcljHES9jkMY0z0EDULo/DRJDAY0jPVHm0QNyDssM65jSPVCDS+z8U9mMI9ZgswWe7NyLEse6qH
KIyrrO08eXdsRBB+Y36rqNqjOOobFCGWRmGFh4aDLGlDSqFGiO0cI6SG7RVaSX8H8UUtItSuWcFp
Bq6Bc5+3thnJAkMj8ADJGjDCj9OUCFQguQerI5z5VvOudirp2EFzgFvKAEEEAbg6htQA79Bgbj7P
WZI8VEb3IFBjRcjBUxdmKP8CHDoOYeUchlDa+JKq1Ugl2Dc6c2htjcLfOiCA3xwCdtlV6DR8hzIv
nQK0RY6Z1ThFiBkDVMcNSMM3V6w4MR8wQBrDKjMMYcg8okDeGcOR8A0QDP4flPAaUjI2YwaWAcBU
jl+e+fYECUQ5B2QU+JGqUT+F8efBRfjMnzRiQ4U6DJ3SuLnTgnKUifAyooR+iYNxfgQRGDaHWXJ9
HwH3hZKc2wOSuwchkWNZsrS1AwV0W8KCJg4BvSi1OFEnjTKhb4QkhZDQQA2BySkhwMTnEvVotMir
h1rklIurKbwNiWKzXGuBCxEJmLRV7BBJB+A0vPBAGoN5nkdHuU4i494bT7EHMqaZBJf1OSlNG71F
MvC+PJT02B1RDZ0SqjoDiPSu0wA0Buzst71qIPRI+9N6pqWSPae494+swlYLFbE26MS4QaUfOKly
Oy5ygBVlG79Fid39TUT0YmfTtgQB3De/+EyP4vQvNu5U3Ub4ylfjO5Zc5yF+HMW2bUFoMyNA0nnG
MrhXidRzLHBhR6t5kM8Sgn0kAZzHmoT2qxFAbQwvXIO9B4plj+mfNM9h5gbwyIzQE78wAbl1VMUC
gxBJn0YvKDZGujS1JkgxBw+qGquExlvM8jk0rD5gxYUJUupobKno6rjFGk6BSPhiRnUST0kZOSeX
qfhIwc6VNSgWe4voZkZmWsswBmkdAYs7jwDB9wKICIFU5JhQqLJISXYgnyJSOURSzeKfwOsKLCWR
LnRZPb0IhBuvFZOi8xCmupNyVikNmH1nXdEUNEpcw5wnpi7y4FckiMWDlYy1kjaJO/c2QwlEaGeO
ZBm/o/bYHJoYbkRYiYM4buYbQQ7A516csJfZT1XstQyy3PtLrAVjg1pKK+jW2l1bikbuOWOe1bS1
TeV6gVo9t5P1IYxUp6BpT8YnPKnxTBly/BpUxYMg96byI7tEHS0j4WugoQdeyy970ItiuThNy4KM
GYbKdZyCx17m1JgkFOKhkg24QInhLBTo8Msxjo36ZlOaPujKTUypwILSGdD0SA/oZzSvLXrkahrU
aT6B0Gnu3j1FCUGPxIMMrUWYZWuNTdSANjgQ1OvhfKgaETB1DOZlFiSUFl4j5H6QEgpCSGkRIoPM
wzYoQvbRuZOFtNsGQxfUFASVUGAijJvNMVs+W8sJqmXWq5d6tU9q8OEizQy7REpgNyM4QWMkSZI/
DXjLI2eeHPRtjAyOkxe503Raac65TADYk65zAbIJ9qsF7VU8qF2UphHsEzRkf0FFUOW37/S+DSHE
OpIMDx1dlVpXuDA3h32xhsHINadQWdBZ/DE3kGIs3uGFHuL75K2mcuOGs8DclvDuaUzOwDWoPX+t
5t+6I6zMBspGny8C+71JBquk+8I/yBee4cwCUWMl4P6ggvi9gxMPi1pSqJtap5Yqs22rCEOFM8jV
V0G1Y6wVinNGKN9Z+EnBQtuaGpJ9eV6QL2iTCewzS+hRlIzFp6HPMJBqZOiNT9yDkLgM0aRu9IkB
BiLEkv+PZY3RK/GnWaSFDl5wKYD4VXQ6L3uAMMIPAox2Zb62T+D8qZL8/8xsjk5P82V3NAAIO/eZ
0rrNYYDSAg1lbmRzdHJlYW0NZW5kb2JqDTI3IDAgb2JqDTIyMjUNZW5kb2JqDTI1IDAgb2JqDTw8
DS9UeXBlIC9QYWdlDS9QYXJlbnQgNSAwIFINL1Jlc291cmNlcyA8PA0vRm9udCA8PA0vRjAgMTAg
MCBSIA0vRjEgMTUgMCBSIA0+Pg0vUHJvY1NldCAyIDAgUg0+Pg0vQ29udGVudHMgMjYgMCBSDT4+
DWVuZG9iag0yOSAwIG9iag08PA0vTGVuZ3RoIDMwIDAgUg0vRmlsdGVyIC9MWldEZWNvZGUgDT4+
DXN0cmVhbQ0KgAwEECgRyM4gBo3GQuGQ0EAyGIzFw2EAxGkOGAuHMUORlEBmBpCKgNGQ4HEMhw3G
g2F0OEBUIgNF5GGMVGQgl8ggUvMcDnBUO4gFAtEA1EAtFMvNQNFsQGMam4tGo1G4uGs3l5EEEzgU
RqE/nQuGAyG43n89FsZGErHM/oIon5ojxzMpuMhlOVJKlLpsaHNXs8+l9vLgyw16pdqGYxts8o9q
GoxmuDoRzEBwOpiNhpnprMp5EBtMOgMUeMJ0OhhMdyMggOhv11yEBkNJnNOpNhs0Bz2puMutMZvN
ptOpuzmnNJvNwsEBvvNKpg0sQ4otWrEwrZGgUnGMUnINnZUnvht41xHgo+G6c/rVcisSHPXsNjHH
e8WPsQ0G/UygoOjZI6MYyjSOy8OaMzYo8NoyjmOYwjPBTRuaMTUjSN0EhAui7Lw86+hyv7rvGtyh
MKw7oIyGK1v4+60hcGKGxGFDLMwzTOBAzzQDMOThBAMLLsyzYxt086BBa7qrPsrUUBkGCjMdFqIh
ysz+jCOwwjSNgws0jwyNPLQwroFzzukGDqSMlgaySgaxIhJ0WLUGgYSmoChLij0AwHAo5R6Ng5tg
MYwwu4I3DMNI5Da2LTwxBcGwejw7zAEA3DeOk+DovDfx6M1Lz224QUgyzeDO3wyQ7MjqBq6z2Oy7
cXPsnTAvIoQbSI9KFzLVb3K8+KwPAsTJRWtDFMnOgUDE0DgjaOAwjlCyDv/BUGQdCAQTxAlMtfDC
7jGOQ8jhS7Wz03jlQPRdpUc1wyjwOlazPJFVrUsk3WE/IbTmt4yja0oyLu1sLW02rbjCNkMt6046
o7MUTqKHKJBvNV4hpYl6LWGYZxi5TdBBY4QNuyzgjkjo5jg5TaDcg8aSDG7PhcnAgjY/43jqM40R
6y9mytS+VtBQN/Dpj7nZFki7WddqGo1iCxBskrAxbMrrrflMbRxHqO2qMss3A5kfDhnDTo9qlADd
SdKjMMswDSzTSS4vFrtbHUeY9ozpIVeD8hmxs36UxcY5BoWS2dH8as7li4jqObmDuNEsNNm8Ca/n
bQ8PSrS5Xb4QUHQq7jcOg04HjY87npFV6dJuLyetUoxjaHMOFZY3NA/9FDSy3WI62w505TMOoyGQ
a14x1ZBREoZjeO7fOevamTgGyXPveO6v7EqHDfBHWapZdDOZ1lk9f0LoQ9EFYxjEoZSJFyS7zeiL
BxYi3xnIDOdF6LsLUG2LaatQcd9GOw0CxtCJd3BJBY0lVK6WUtqfNuGhmSlQ1BlDessORtA9OBe4
cpzRdXOsDNuaB6qCXREbbsWsGx9kRH9e6oF77ynwmAMc8Mwz5kTliKmiE/CciLoxRm15nSOGFPKS
K0d+iSj8v0YpCV5xbwgutWVCpDJdWTEHR8GJw6FlpRMOIcZQDnVyBcBQecGUJVXGCOw05OKwYyL4
BcGeH5SwikjYsSchwNQaA5BcDMiiTIxkZbq1YkBIgGgzBqSdNJRQakZRWTFpzvmJprBgk1vJb2to
/DkatMBHjnF3DkFwpIb09I9QvBEuqHSSksBmVFo8IisxkYoYw+y+A2BlDGHRHcWlJBlDoHc5wawQ
GbM8hgJLnC8G+UqtlQKlC5J7g1B0EDh0GMdZ+61QgaXNwbYI11x8PTPvzOvEQtacn8w0Q+6s2BtD
bG4Y0qJC7rFGLTI8aVwKGg6MtBBEuczAmCTqYO1Z2jNnusiLoa1nsIWkgwO685ikgpXlCLqtxby4
AQLiOTKF6xsp2roWy4ozjNVPT9NOak1Zv56BUNlMsOhoFrB2gsXKbkI00vqhuw99xQp7zoN2b1TN
F1qLQQvM52pskNSalIX6Fzz3yQxfODAGauHUQ0h1ANqZnzXTllkt1y7rKasDoI6ReK840mVYMHRh
AZY2gNKoC4HBGIRmLdO3pJqTUYk4CTRVO8sk8oGDmHUMaAkGhmDqbk0C2w3l3p+XOsNY4FH/QxUF
Dj4CFofqLCdYr5XzgyqXQgyqpj1qpqKe07QIDuKvPRC88z4AasOIoC2pZKFc2fV2fJX1Sn7zhSaV
NGLUnCB5e2gCuy109tigAj1BtYzWuymLRZc61FQOYI6181sVWTwgYWU06Uqn6w0hy8GHUULGwsse
+KF9lIZ21hs04lUSTKuOZy2Blh5zJKphzZybqrLQRjO+eGyRb1aPgBoRKHNqnevOs8V0+FsC1VMr
cWRqBQgqGwcqmCvJHbihoUVOy5Kj1ImqrEwOdMGnQIYMwHJkgclwIdbrdR0cq3Ug4q804GZZbtob
DkcyBgdwyp6t3XVAVvnJO5mkoVQ6ibjkemxetnYL7cOReynuZypbpxCvmYpObFE04LP8bCdUoDW2
CgFhZRq1J+nFDSHEOrWDQO8IZZd8b0jDPFeOb9DpTyp2RIqVaPFR0YZooMYa2k4D+scdZiHEdELG
BynoEGreKixEKpg04+NMwUBDiW12T01Jnn/o9cMOSgUBYfdpXlwOegYg4ymY/PAM6ssEQFiQNKhY
toMziVaGpgc5Z3zZnl8DqTGZ9BvW0t+q3OhmDzSvCtLDoRvAaQENZW5kc3RyZWFtDWVuZG9iag0z
MCAwIG9iag0xOTEwDWVuZG9iag0yOCAwIG9iag08PA0vVHlwZSAvUGFnZQ0vUGFyZW50IDUgMCBS
DS9SZXNvdXJjZXMgPDwNL0ZvbnQgPDwNL0YwIDEwIDAgUiANL0YxIDE1IDAgUiANPj4NL1Byb2NT
ZXQgMiAwIFINPj4NL0NvbnRlbnRzIDI5IDAgUg0+Pg1lbmRvYmoNMzMgMCBvYmoNPDwNL0xlbmd0
aCAzNCAwIFINL0ZpbHRlciAvTFpXRGVjb2RlIA0+Pg1zdHJlYW0NCoAMBBAoEcjOIAaNxkLhkNBA
NBgORcORkIBiNIcMImNhAcjKIDMDSEVAaMhwOIZDhuNBsLocICoRAaLyMMYtFZhIYFMDHAxBMDuI
BQLRBHBaKZgagaLRkMRjE4qLRmNqfOJiIJpAhiM6hPypOhcMK3Np4IBbGhgMxkM69QRRPygYTkdD
SYzScDDdDebhAab4dDRHySZDKbjocjqcxAUzyczoZTbfcUYTsYTSbDCYjZH72bDyIDobxAb4MYTc
aT1eTTe8VoDReRBcjLSCpShaNLCOBANRcNasRKwRoFKBjHJyDZ2VJ7ybcN9pSoFTIWMN1MOBWYtX
IpXrAMBqORvXp7Z7CNxwObbQsKZzCZzKZBAcDkaTbcsvn79ro+YsTfjKObFDeMz4jkN47DSMi/IO
My/NMuwwjYEA5jKOUDjG/4WNij0JDqMQ1DKMY6NAN7nuQszit64yrvIsQZRU8a0BgG0VLcjwzjqz
C9L40z4DKPAwjbBsdBAMTPjCEAzwNCg3DawsRDCOrANINI6Pwv7AjSOQQDQN8mhAMY3jqww5DzDM
eRKKgVIGsKXuUsy0O+qy3MA2EmjLEULrmyy+DKNg0jONIxMvKjPjG+bHvmMMMjmOoxjQ2LFSC042
jqyIxjCOEqQgjoyjiOssshJzJjc+DCDEOk0TVFgYhvF83rCsUaKEOTVDcg9DSpCg0jCFyfiCEC4r
muq7tNJ42Dm0VKMc2Izo8j7QyI/cw1JIjPsAwTCTGxLRjhClajPVM1hgGCVvFV4YRdWQUMQzdRx6
PEQSij88jpPb4rkui7LxIb22dJrDDnXoQCNBo3QfCK/MdKkotWNzFDvMI2PgNw31QpIGzTc603NV
YbTkoQxI+j1PVA+FoDgOo5UcMMJtivg3juN0KDmNC7r6w0KP/ET8sHJzEMVaGQzBL0j2DfNiMMF0
Stw6kTpaGsVOBGKL44tAZRk9K32BfFhrxgAQPqz75QNBFsZ8xIWo9HL3wlCkLP+0Y3M9EcvsS0Mm
jloDXxE147Nni7bty3bet+4Lhhc4ruRMsrmKEHESuiGTpuqq7sK2rrjrRVlXRYqfKLdfoy7ZoNpT
E+EitiOA4T9S7NI/scDjnhsAwHa4QZ7bUA27Wi6VsjscbhHktspv7axMFsUagrzgVWG4a6rWFWaz
2Qz5lkzA9Tsb5V2x+6sdLsKWZf1RYEKnsdww9tjf3dv9/drYjYNmYXDqzvegtLwazo2u2LoDROwb
K7dbL6Q5tpT6XltiE0Kl1bgZ1axoj+OyZkgAECTkqBpQwhxRykFwudLUuZzSbS3JgDkHA0hqjWJm
WoklvwckmJOU2aQ9hpzUo6DnCpibFW6BuLyylTbu1kMOfKYGDrVinQgVgx8FD6GfrcW870g67Hgr
UDG3Z8CWnQqha+xBHB8D6hrI+GUMMG4qvfbw/QsIMgauURgmx55QChJgTHGMOgdUINzI8HOEzDlA
mbJAaSCrDmUoKNcbBKhintmVe7GA/BiowBwTwXtBkA1dhsaUxdphunkNPaiucpxVo2rjc+UIrz2H
1xPkJFJ2h+oBNnMUYwxxkAQRcYkgRshhJCpPS+l1rxn21B5QUiVwLTTeG+eW4YEBxEVE6hA1kHLk
CzOScEdaZDlztuZjSDQthZUWTajeFQtxezYggQSoBeqEV6BpQYpd7oaUAB1bY6horXF9LFlmxE+D
fWRIgTC3kj57U9rLWvNCTaKZjuaBwm2UIM1Wv6no0hEUDi+u1ew0OXp8WUsrQmfA00FQ8OrWGiIO
5claGGM+GZApkXbP7nqYZpZaQXA2k0RemKbTrnCJu4o5Jy2shcBRHJ3s8AyAuqIFwFMwiIFcpkbs
HJuCGzHcsdoqx3Y1lkTciwG4N5tzgVmn0MplTDIEDTIoj8jAXsoM0XUEEjF7pZMkCBMQaVPJ9SMg
AN6DzHnwDulRR7tkmoAPaR9CapEKUEIaRug5YQZlifuDQHNW3QLUhbOqYDvg6x7U5XOgT2DKp+QS
lU0aA1GQbnKpqdCFC6TrgQwGwxuCFWJLEDGUC57FwiKEE5is6i6v9ZcfBipgUtIMh4waSrN2FR1h
svdYU9YoM3lZExbcsDHhttbYiaiLLHnocZT0FAXHJAzpZRAOcwing1vNbO7rkgaTCI0qwky5ru1H
YuDkjQOSOHJalYqrL92oXaq4W+Wh8FDRie7XGudYqyVrDKHms6HXWYKbEZZvMfw5Q4Mkox4ptpMu
DmNNQ7EyqdTNjgCg5zgAcEtJOWaxZKaoU4mtVM5CsL/ShJNEq0s50v2ot1OyBpfGQmvDYgNASGU+
p/j6vOKzeG9GwqArREMs6+TjvC15ERobq32tgDGhL96GLqI8hesbZncl9kpaBKC1zDW7SHApt9rG
LgyBuRq19+FxHetmiwhttmtBFjGo/Kc9sAmxyeyw2NSHBTFcLh9xEy3FpucaChx7gF001xURqp+H
sXVSp1jKNi5wZX+RqGWEzsjQpkwpKzG6m502qMfktnbfNCTuwwGRDKJbF5yIrnQtGW7t4jDSC4Ms
l3jBFJJQwheWAa2OBcVMiwN02JrtehskJIwGgzvobsGpGnKEyc1Neq5aAZ68v+hlKk94utgT2vU/
IYZhAzVYC6hpTDcZYuu1a97jFYbMxGGQvJmWWLzL3uo07vi/BmNIfVIc4nbGOh7Kt2yYQ6cMVIgr
IlH2SoZkAR4Owb4wBkura+akIcuQf33kbHGq81NwTpq94ZitZVCbpGVu7M2BZ/a+hBZG5pa2TDNS
c0mV5OuaXQ/fT+ejAJZPgXhYXKrOIQQQoS0M5OTaqx1qxuHL3RmiWvW7mUV13IZsuXvj7hUYoz6J
GtrLI54LLQFKzo4cukr4TLuhsSBUDy4o6j6kBdqRUkWLXVujtrO9PtB22gbF3I7zk653Dujms9dy
VMLY4OfGk92PQ3Ed3nJAgcgmwqj9wbA1sgULVNp1hdWzc8ZVhGgbEZthu6hS59srqLhQ/Khk1jrJ
DD3Wu5/13GgpKHNILFnjTDN1ojFrh3EuZxFf+Z7F9iANICANZW5kc3RyZWFtDWVuZG9iag0zNCAw
IG9iag0yMjc1DWVuZG9iag0zMSAwIG9iag08PA0vVHlwZSAvUGFnZQ0vUGFyZW50IDMyIDAgUg0v
UmVzb3VyY2VzIDw8DS9Gb250IDw8DS9GMCAxMCAwIFIgDS9GMSAxNSAwIFIgDT4+DS9Qcm9jU2V0
IDIgMCBSDT4+DS9Db250ZW50cyAzMyAwIFINPj4NZW5kb2JqDTM4IDAgb2JqDTw8DS9MZW5ndGgg
MzkgMCBSDS9GaWx0ZXIgL0xaV0RlY29kZSANPj4Nc3RyZWFtDQqADAQQKBHIziAGjcZC4ZDQQDMb
jYXDgQDEaQ4YC4cjYQHIyiAzA0hFQGjIcDiGQ4bjSJQ4QFQiA0XkYYxUZCCXyGBS8xwOcFQ7iAUC
0QDcQC0Uy81A0WjIYxwWjMcwuXTAQTOBDGbzkGiguCgXWExm83HQ0m46mUyFwU0kqUuBC2ni4YRS
XkSrkasjONVsqSEWxkYDEZjWfz3A3QYDWjS+gigwm4yCA6Ggym4QWQ2HkQHU4ZQ3iAwm03nWy5kz
ZTLCA4HU5GM0GE52oQHcwnI5ZE6HkXTggiAobezGM0nDdaownQQGk5nO0nPRW64Ue5jWOXeB3SLY
aeUfBDOIT/HmQ0mc0nQwmwQGMynKzGY0mPkx+xnU2ZOPGY67PQcvmrS0Tatu3Kys4O7zjQjoyjmO
AyjG5Q6NCMIQPI8z0PU9j3DS+D5DoMrpAaKgVOyGAZIUw7vLoliqseMw3jk0Q3M5EAaIXE6dqsma
bsIvqfp1FEcMeMSyDDEETImjCfrwrCKr4qcfKYwQYyexyhBBEC+I5HEliNHcnL8nTFMaKieyCoT4
DJD6lJKjKTp87EmR5Ki/yiugZho7kyRIGIahm8UrI82SyN6l7ViTNKyjk/YQCmPI5w8NratK+4QD
YNI2vO1SPjCM4zo8M75tE0jTOUN4zRAFochrFTqIk60lRSGDBxQxLBhwmsqhQ2zcN0NMFuQ5UJuD
DTiOM042jCzjYjsj7SjpR7IvINyDuTGLOLIj6zDbTbJUk+wyRAuLquuq1ahkGU/O6wQYBnXCgKEj
w4jqNKPBAMowtg4DhPi4rjwi1g30e9Y3jYNj5ty9UDsqEFDsuOlFOhf6x2ZGDzuhXcCN3EERVjdE
8zLP4UDKPA4YC1wyhdECUKfVoXVe7DBIaHNaMEi93MenAjRfew8NGOA2DKFl9WJfqyuhZDODgOQ3
jsNM0hAOdkPc9bbjI6CxrKMKzrOg8KvO9L1va974vmOdUZWjlVhqv0uIFtEoRxkFchiGFwqPc66L
tHK9SbHquXMusgMVllc2jqGpOU+Q5Pxe80jliLQsqMt6PW/cI23x+UzXt65Vdci8Zrj9YhtGuQpw
Ijy6/DGxQ3skPOg5jnNoMTOWFfdi39CXK0eN/MNFeuvQuzeoPKN3Zjzs4XZZtW2Lzt3lXJH91ZCG
IY7spqF8DOG+TlME6sGi+aMUGm9MfyWhuHorlYVBPz2H9NjDpVCFhzVS/bld6vXOGVwroGr9XxAw
BuDlm5QjoBvDuZhpQaQ7KhDWGV2q3TbqbDGWMNqxlfGTdodFNa4nPKwO+nMxBggag4RYUJ4LYEMt
jQ6R92JaYNGcYaok/ahAqGrhS6tDSHGyn+dlDFhiiGHn7Y2iNWoMAbMzO6rUrS6X8h3UmZOFaGzO
GVWq+5276j/IxNEHUyqLw0h6No+9fj8TlmYfPDOIZ0FGqPDKG2IqJDCpjhG/4GkSn8uGishA1cC4
GoeBBA8zh+3joBjI7g06/4cvDDm8U5az2ww7dcr85kcV1g4idHVEoN08mPNMGleQZXhmyDmG84h8
zJvsU0+iMpumhOSI9BsMMXjLFldc1yVbTmHHnWualyUcYjukSAyGQ76nNFvAaQJ/5fCIwgO0DNck
mgZkmZCxR1qHQ0lkRjKlAZujOLxOfJAjx7IGG0DM0tSIY3LO9Pa1csiGQ3S4hy9chpGnPp7BqVWa
RLGQxTh46+H0MAQQbDfLCVkiJIFnlXGpiCjFHKQUIEkzAYQyHkLMWQFk9AaAuROzA7T91YrtL8Y+
Yr8WjrJNY0tprT51O8cwxdBCAVLKYQ8fgyIZ1mmplKGYOiu1uGTNi4un1Gp7KwVrJlPb2n8zgXpO
ZndLXLztP7F4NKloxULiFQ2NtEEjA5L5NR5isEmNvK43FN7+W6Pzq8QwihUSMkNrE9xL6UImEWgD
AJ8pQqGKLigt+lLTJdS5DdOc2UQ0HsnJAblbcUA5BrNqgihQdw0HxQTSU3TZoOt3o2RuZxg21wBT
vCdXUUTRIPNEdAIYQToOGaVYBp5HmDU1age1pp7A5w2j6HJS5tzOH6Dcg+bJmFTRBYcxColHVysx
T44JWS6GQ19UoGJbKErTGylWqgGILl22femrkLi5wZqohIVK5id0xmPaXQWSMLDk3Bi7F+3TGk1m
JboDSOiJAcA1k6UK79cLhxpqyourcb2hI0BiDe7SWrOwmmGrkNILmUIgCKSR8gOQXNpjvgkiuCAY
EYo4TdepISRgNBrEjC5Dr9JtSU99KdIAUUZvmDRO4LiHFNs3PdmKJbQA5tFC+eTqUL3rmvD1f9lm
jLAXstAMSlg5vtNWtAOii7h5GkgbK47zYj3LiWlIG95yhWpdhGhQ2AY2UPjfNu98tTh3tWmSCp86
6XmoaE4bKmYcYTILjPWzh2Ijg3b1Jp6tosAXFwFmZSL55dS2N2aig76rbpGBvW9JNHkSgzz+rHGT
priQ0tWGyUq3lKFfDSWzJJ6MlnMDQ8l5bLnm1jeg3DBtaHrXzBkDZ7NbQZ6SriXtvydM+wBK1SMo
ThlkFnPRQp84b0Gm5LNm1RTQDoBnaYe2eObdB6codG4NrQizhjDYHVaRB5f2ZxtUXSleIAomZCpi
eIbQ66HQcGieJ8j1VMI8tvI6LkYQ5yFP9X7hqCmWRhBZkrxsj3/Mtlezutb7q1TxHgx+Aw2g7BBq
LUZSTSTxQjwN3rPw0mRPZQMzmdbHsLfPxJ+ZGn7axMff1/l811g1XdoAGkBQUQH2Xmwg+z0F4SJI
QEANZW5kc3RyZWFtDWVuZG9iag0zOSAwIG9iag0yMDczDWVuZG9iag0zNSAwIG9iag08PA0vVHlw
ZSAvUGFnZQ0vUGFyZW50IDMyIDAgUg0vUmVzb3VyY2VzIDw8DS9Gb250IDw8DS9GMCAxMCAwIFIg
DS9GMSAxNSAwIFIgDS9GMiAzNiAwIFIgDT4+DS9Qcm9jU2V0IDIgMCBSDT4+DS9Db250ZW50cyAz
OCAwIFINPj4NZW5kb2JqDTQxIDAgb2JqDTw8DS9MZW5ndGggNDIgMCBSDS9GaWx0ZXIgL0xaV0Rl
Y29kZSANPj4Nc3RyZWFtDQqADAQQKBHIziAGjcZC4ZDQQDIbDOGDgQDEaQ4YC4cjYQHIyiAzA0hF
QGjIcDiGQ4bjQbC6HCAqEQGi8jDGKjIQTCQwKYGOBzkqHcQCgWiCKC0UzA1A0WjIYDcXDiHC0a0+
oy+YiCaQIYxIczidA2MjAYDSbT0QC2xjIZjOgUIUUA0R8wmM6Gk7Gm7mU5iA3mYQE433czGkxmE3
HS+4gyCAkmQy4k5HW+nc3nU2Y0xR82Gk23oy406G8QHA5G+8mQ0m6DnS50kqUsWygYxwai4a2Cs1
ujC7a0Cd0CfTyg0MYjLYUuBU2FjCKTAiVojVyvbqdi4YDOT8K02Ma8/iig05DE3o8iAwnXXZG74e
7m83eg3Y2PGwwnTQiA5mU5Xkxr4EDIDmMY5DSzbGjCMTUDKFycsEwjDMQxT5DI5KxLS2rcI46Duu
wsoau4tTsIsG63qGx72MmyrLsyEA3MG0rTtSugQDOyL+DCNgQMjAg8jg974jeOUdjYMq7NONzDBA
Nq+DmMMbP0/j/DKFi/DlCwqBUgbsBo7MQu8HMQJguDEPOO4wjkOUJPOv4QPWEA6vm/g2Dy1aDsKN
zEDGNMcytFz4TxPU+R0Ok1DdJy7DS+AQM2Og7jKyMsS1EQYLY8Dhw8lkTBQMbKNHJg5MqNA3v2ED
xvYvQ0wBNC6PUubyvc/LXNOOozjRNy5zhUs2zfFDJMoEApjyOb8DaF0LNojgWra3zdOjSiIBy7ix
qfEsxqGnLjhAKoXCmFwhwaLiGxKGKpBmLlOC4FN0BxdVjqUplkhA27cqA6LeXksLiOHTau2Q31lB
k5rwXu6aKuq4CmLGGKv02nMLKgnDiOisbtKxflrhQKdIQsIqSBwqCOOOGKGIejLfoyhSOo+kKRga
GKrBvkWBBcGysJlfcOhhhjdLgm4QXAIwXClBuBNuk10DFdV0ItdQdhBCyLJbmyfw5aExCpTCyO/T
YhT0EAnjcj4hyEOEhPvRQ3SqJI3DHd7YgbjyShqGiXJvkicBiGqJI5lKcI8kCRJJLqKOOheqOgsT
sBqGtpLRSgbhqs7wyqHC3CM0McR0KS+SkMsLWWGbb5lebcWc6SBXyKjgrQ4i4ItCzl5o517dRg6N
OtxSyBtrCfavazwiEzEiru+IbUrKvjo5pgchyG+naheCLIx2tqIbadNiHVIx7LjqSBlDPr5huuqB
o29tb9lfA5ciGSBnkQYJb2nErXhkvy4GPJrh5KKcwyCanNudP6R94QbHiGrXmDAGqVXJECeYDgGS
7nQLlBys1eYOSJOkQ4wt0T9zsgyeAmQ+abkjBoSSYdHSxDGJoDIHNp5jAQLoDTDNdSSz4F6SECB7
kBj7uaZWHEOoaSPJMMSYuEaTwzkeDPD12JaSGkaQ2VlSj+S3OPWoDdxx4UzppTWjsPDZg5h1cAGa
HIUE0HtDSHBCRfYEK9PIoVYCwliBlWMhYGb4ILL0dOvhgDCWcuuOMcheCy48LaWWRl66HDeFddxH
5xYNlLs6g0eEKB/DPhzDmgYNJnQ6JsMAFA08YD8hBUSXkvYc3vEJIW9dmxKGVFOIXHdLbKoxuCZe
RclIIAbAyaOvZhSIzdO+iuz0obG1EqLBougMbSwULtKSrxXIQgkBDBBKQOiMTUKnL6a4+56FGGID
WCBUZmU7Q6DeG2NQbg8ugZUU1urKmrLUKlB5mB4C4BtDCHlKody9K3TeEIN8LHQELeavV1qm1xMC
dih5/MHinRVPCYsOBpjUI5SqZGJaUIEJlPRKU8yuJuz/oCHIxpkD8ByM+2KbYb4mzuig9VxciWsy
SN+xkzcOg2KkDKnRlZ9j8GiNIGKcCdm3lLBiDcjLVGJpbZ2W2D0d2sM+JhNGkZjTTBlLyZcOdPA0
BhMWq5IQaQ9H5qEG6cM4zVGsdAvKPTtY+U1dWheg7GV/SDNqQsGhRwZyIZu7aRjDSwlqnoDiKJcH
uToMQqovqcX/pRmOfGZK6V1zNhrNCAk05ql2TcaQus16vNACDEaqyMlTqmjeealsTyN0wUqDSiEw
kuQdYyek9asG0KLP2f0wyAIEPcDc2Kx4IJ+GuNLPmIgdAWn1h6giEZgy5pDUC21QdqZ3unWgztaa
HgYRZLgoUxCiEgF9t8GQOpdj8oLSHTtIyhYbk+bEo5IQaw51FJKDclFSnaqUfjPSWTGS5QEqrOKz
6L5r1XqyZROla4+1tkUwZ1TrKZyABQ7CQcICM15LTXslzBK/MIsCtQGjwLYM7fMpu2io0C1jM1OC
cQb5yGsnNYhJKALGH8sckAEFkZl2TmdZujtni+hDtCn6iiM7qAungVktdq4rJcO2xlU55ZOnoVcq
g9zaUo26P/Gw+NvrgY4uGrdF4brop7T7d5Q9nW03zyPkzJSI77VPhCic+NJpLGrnKHcuZ60hmIx+
Xij4abxU5P3Ty5VP8fVlDWnZKtIoWIUVw59eDsrq2sOy71nTAs5qcMuHJCdOQ3zhNHcLPdz4Y4Th
roovqNmxQAp5kW0qb6KSiMbblKcLtTwRKTqrNsUWKHYJNB7EMxAUasc1q+0hkMs63pBZ5wAbw4I4
SAjmnkOQzJxsftQ84czSSZM+fZIeoz15HyTr8sgM8RaZBldwoes6da1SlbsxdK0dxAjTpENtxdPG
GMwminij4DY+1hsrWUod369tYSbdKlMQ7sBRrbeTT4croXPrucGq0b6uPPwMj/EMt7NPQ4DbipjE
hliTtqnty8fbjXg3IgINZW5kc3RyZWFtDWVuZG9iag00MiAwIG9iag0yMDQ5DWVuZG9iag00MCAw
IG9iag08PA0vVHlwZSAvUGFnZQ0vUGFyZW50IDMyIDAgUg0vUmVzb3VyY2VzIDw8DS9Gb250IDw8
DS9GMCAxMCAwIFIgDS9GMSAxNSAwIFIgDT4+DS9Qcm9jU2V0IDIgMCBSDT4+DS9Db250ZW50cyA0
MSAwIFINPj4NZW5kb2JqDTQ0IDAgb2JqDTw8DS9MZW5ndGggNDUgMCBSDS9GaWx0ZXIgL0xaV0Rl
Y29kZSANPj4Nc3RyZWFtDQqADAQQKBHIziAGjcZC4ZDQQDQYDkXDkZCAYjSHDCJjYQHIyiAzA0hF
QGjIcDiGQ4bjQbC6HCAqEQGi8jDGLRWYSGBTAxwMQTA7iAUC0QDkQC0UzA1A0WjIYDcXDiHC0ZjY
YwyfzEQTSBDEZxOcFSQi2NDAYxSs0EUT+klSl1CKzutWUZ1Ksz25WopmUy22lkWSDioRy618bxyn
C4YxyNQqOx+QyMGjGni7DiC6jWsTCZXKe2QXWa0UChCC/A2v4yskSB6GzWHP2WnS8qWonGE6Gk3m
4wmwQEM3nU5GkynIQEE5nM3mM07jdG4QHYXCAhG8wnIyCA3mYQEc3nbim43nI59ruHQ0R8jGUycX
eiApGU58XwafAZMY1eq5gcYaOBoGKUBmuLLIqjyQJEkiFJSzAcsasKZK4ECUMWrKdLunzSBQGIat
OgSmoWGAcNWrYjK6r7RrEBq6LsnihCmPI5joMo2vtBSFoazAbLgh6NQG1rHQOyKSPyhYasIGyUBs
2iZNAGAYBqGsMScrwbrSoQWBAGsKiMhjshiGQZBzLMwBnKwuBQIgXCG6YhjSOTprOG4ai4FLphAJ
LoDCMgyDS3Ldyy9CPuq67sjaMI8tOFqIBdH4WsWF0jxIssoJtF0nIaGcrhQMbdjmNL2uMMI3Dy7V
BOMMQw0+8r0NwED2jbTw6Dk3D5BBVo6Vu9IQDgOQ3jgN75uyMIxtyO0/VKNFVBAMMPKPSFJM4o9K
TnKayvzK0NI9VTdjCMQ2I+8YQDGNlgo/To3DcMtiue7TjI8NjnU8NA0jhW43hBVI3DWNI3IPcVDt
4M9+3+410VmN42DZgjTioFTWsox1Lo1MEl03fQ1jnO7Thor640m0K6tovFNr2vqlAa+78s0jDMBi
qAaoqxMKwex8EMkrzNMJAKNtXFdrNCs6wrU02UNTDKtScGYZqNF1rhpbLaqFQjsBAKY6VqNoyjdX
L4jPQuCPgMozjreM/ugLMbMnpisBnl9I5kGaNIzAubSG1AbIlnaUByjjORW0Mw6aKjYtCGgZUtqQ
USyGijPXUL368NMZOLCYYBtRUxKg/dHpbaOk2uG8R4m1yL03NCzqlOod6KtwGowl2kNZJyI5HabX
Bz0fFL2MbhT84jyzyMg6xkOVSuQ5TmXk6DpOo62qu27rvvC8by+jQQQce9w2bU/KW4tuSNb6/m5y
BAzIQShMcIckzNRamPAcvKXSRFw9Nvi+Y5PBq0YxnGrKD7oLRySYGjsSTlRfM3Z9JiyrgwfYDh9y
TCmGyaWhhSiAFNuMSSCAKoLgpnTKcDdLLiAYKPJsG5SIIHUO5BonUFyigcEaYs51SLfi5tANE0M0
rrS3lYLkaxFjti8ovL42owQLjEI7Ki+xihjG6pCgWZUy4Mm8kMd0Z01xK4cRUhs0QJ4QwhwcDcHA
Oq33JnpOynlGYclehlWMR8Jkbo1qvVqdkJQdV1EWBimR3INXWGnaWQsk7snbwORFBZwKFUNBQV+2
U66WU8hjhfAAkhGIZPsiUXYG8DW6JBfQZJLZV4NxUIkSZnyVEUskQ0CxRTHSJMtM0zFEiEkKQ2Qu
i5DbmGUIfTCaGK6JUTlgQs/GKimn6A0Sipsuz2laG+fwfRQbZVwG5OgDQHBNoVu5hcaeWqz3PQ2d
mpR8b9CIxdh2DVEYQQ2nTjunAEAMjsmnBy0eH5rQYNMcS4VKB/VNhODe1g4atgoRlYWGN7sWgZAz
gKY6CBLpOvnZuSQGQNZXvsKqYqcEE2gg3cHPos0xnFQqIalZt0KgUTwBAexOLuQczbZQo+I5FZYo
QmAhOjEwzPNILUy+blN0QS+lmiYiyKCwk6cC5eHDTHdNEJgrudRxQ0hjVGdQ65xzknLOa2dLIZlx
BlDwGENocFwJZWUeU8SMzsq4V0R9yYcw6qjDGuE7ifWBtYe5S+btM6gkCm6Tln7TlNoBWdT+Q60k
JFemFX5ihizYO3ZybQtVcQ5G5DNVFWp5QxKlCGcgEDk4eFMP0hyxsQwUBcTCDNDxroKv0TC/NxSo
zehvDOcFVi+FZp7d+t031krKWWbOrxX1cTkq2jwqFrAa2tr5UTLub0NUSO0ajPpMEOgUVnOu8AEA
d0/BoMeHMOC61ch0XwGQ5YdWtNcPLV5dYda0XZu2ry5Kozsr9DXJN1yj1IpRsaVcGp+0NWmRzZ8G
YNSoF2nrEGCzJYiyUde3KoCATNQOnfE2BMUDJTII0jlAJLZrM+LLf210+iFNRaIEQNNdTeqKTMiO
Gjn5wmuZa/Qi9S0X4nN4HQ4RHwjh1VAGVha6g5yQDdVwOSh7fu8d8HSzQbw2htT8jMMqWQirgWKr
4N1UTf5Ma0HKuKzA3BksGtCcE9iLz5kK0ukBak85EyMu0Ki6w0HiXKGdUuJljqfUA1a8C7XohTOY
1vLt8iYZwzlbIPKWannDqkG5hrD0qOfo9f5xQQqqvIqw8tLIcDpg1IcmgIIdQzpxj432lzrpu4tz
HdCxqVLqE/0ovs8qyn9hkVoGa9s041vWO4v1hDw12G7XcCDXBxddGPDMcXQC4ToBiDKsoNh3Hrnp
TfDCm9erDVCr6iqnNpCzscnvEjFjM8x2HqKA20qnDdzUDrSoFwLk6yt2/BuikBcAlasPUSnDIUwQ
4BrhJDSvVfrmOy/lY9wlmW1MeHHHiB1BJvuAd9ya7V+rMBBd5dZzWFh6PYSA8c65AA3ZhTJuFe6b
SK21glDSHMVcg5GVRucv972J204Gksx6Eqb1exnLx2WMAgDQwlPq/lx5MDgqO7GsiPrl6FwBY57b
5nta4shZl7D09Rqk2ewZDW6rSLo7ZJ1/bqcEqirbia6F1a/Ohdo9AIDxZDX7XDjCt1aBuDmsRs55
V0a+vbZlXSbzs9Fsndi+XWYCzjLm4ae+/Ac2uLVw04wbw7nQtun1s572MNh0EuDL/mF2LHNyfJO4
Rqu1frDWNfKo+daCYx4TrboHcO6o8DmyBQufhs6CQdTtYejK2OuR8MPVDxhp41WlfHTMe9sn+ddU
vYuDXiXG8S8WW2NMcZ4pKeqmNIT2cv7MtdTWT33rzyPa9fKb2K5Q4oxcrTKOx5cS7mFQrEIpqMk/
2EhQZMScUr5cB5uKXWeMs64Q9+UE6sVq4qxsNwxyesOgsqN4DceUN8XE7bAY7gPevId6vODoDm9Y
/wxeSezMSoBwuoyIrWXya2DKsqVy2i78V4Ou8++mZQZe3oIyuegu68aexo+6TyXcVCXuOiqgDMVK
DDAMDOxuxyO0T1BYu+DkBaVSWE2oQq2s3s2w/K5OsA5SBuUUMWJakO/aw6/GqG5kLGWuBshso8io
U3AsvMa2DoSzCE/8VKDa+hB8OHCBBIx66iyU/4exCUOUOgU/CIbCexDTAwTuCoPTA2poLo38cIkK
canMBQ/0I+4I4275CEs2vc7WI84sWLB6x8vAysyxEHDWPKs8DMjw7QN6DY+WDSycXiOMvE9Y8MiA
tVDK/slMQ0exEi4qmg55CC+QoAVK7Uu5E0u/E4+c6LCVCYVU43FEvQvsKWxWbqwOhwaEU2LYrw2q
/FCk/I5Mlu/QBw5WI0Uk/a3qNY5i/kfiMWuizOooZLFYDTFdFUSyYwVYVo8oOfFSWSDCf3Dut642
8c+eRkyY2JB6PRBW8BBcV0V81ADRFi1SdCxCkKLMxIKEewrarfAcrk2EjlIIei14V870z4OM2GPI
/4I82OI9IzGeNQLqKiRGwOZC0434JZGsTwT0T4tyDdHm9RA1GxChG1HNCnG6r/EY24BybUICDWVu
ZHN0cmVhbQ1lbmRvYmoNNDUgMCBvYmoNMjgzMA1lbmRvYmoNNDMgMCBvYmoNPDwNL1R5cGUgL1Bh
Z2UNL1BhcmVudCAzMiAwIFINL1Jlc291cmNlcyA8PA0vRm9udCA8PA0vRjAgMTAgMCBSIA0vRjEg
MTUgMCBSIA0+Pg0vUHJvY1NldCAyIDAgUg0+Pg0vQ29udGVudHMgNDQgMCBSDT4+DWVuZG9iag00
NyAwIG9iag08PA0vTGVuZ3RoIDQ4IDAgUg0vRmlsdGVyIC9MWldEZWNvZGUgDT4+DXN0cmVhbQ0K
gAwEECgRyM4gBo3GQuGQ0EA0GQ2Fw0HAgGI0hwwFw5GwgORlEBmBpCKgNGQ4GguG0OG40iUOEBUI
gNF5GGMWGQgmMigUxMcDnRUO4gFAti0CFopmJqBotGQxhcOFoziAuhVBIggmsCqFBkQoLgoF1jMZ
vNx0NJuOplMhcFNKKlMpAxiQwisxrNbiwzjc5ndNjQwGoyvxUn+BGYzoNDFBjOpzOhvNplORzEB0
NBhOggOeUO0gzEgOB1ORwN+dEBvMwgtJ0ORvMh1Mdpg+hEGOyGSymXN+p0JyEBiMJuNeWN/AzBpO
RkuFyEAtuguGsdvEDFwwGQwG9Bn4txA5HOLohwMJytBlyx3NOYEB3NBpMZoy5okG4yOT4GdMvF3g
gMjejEx60vQOYXJ05oGhmGC+Bmjqepk60FpQ7igJixgpjKMsECKkoZhuGqVBBBocxC7IXLo6yro+
kKRw6HMQBujsPBi66YJkBsHu6wIYhywrGBBBC+QcrDnsDD8bMO67px8ogmjGJgytgEA7QMIw3tIz
ENxdEkGxEG0SI6GIYI0iqNRUkCRJIhKFobEQapSiisMA64ZBmm6fQjBbwwsognM0NKzDCNgQCE4Y
1tS1YpjpAwmSuNI5y1NaGIcGYar4GCHIuHDrzKqycxXNKSsIjQZpzSs4LvG7vOvBTtzxHYYhq8QU
BYnCciqFwpwMwYcVrSyHLCGIcBwG63B2EAniGIYQCSs7KDgj60M+EEoDoOjdicN4XQQ6CKU457ou
nIjA0xPbDSLOgaTuoSiBtMVao/aDWrY1g3BALceR66DwMUKg5OGOYzN2IS0jIyguhBZQkBAIy2QN
QriNpakDCkMo4QMLiIo6HAZhYjAcQQuaJXE6tV0xLtX3TGzGLCJ4x0WEFeos8AZLdbalgbTcUOhk
bqQhHYb1THVWVddgUJ0Ko3YM5D6BBpI0jM4424SyT8NnQWqYNWowuDQz5s0EAwjGMeLDoy2uPiMo
x0PqLgYM0w5vXbmdI7EDByIvW6K9HEKQexjs5C57CW+6q9Bivke73cgZVlPGTKforGDu8t/rOyzI
vmkAyX+O8M664mvs3QVB4K47OsnyzU3s2207XsMVjOMq1QHrelczwOeOlnyssRw8KZMGrBVm4XQU
eEA2DSMIxDY0DettzYw86kHibY4/M7CNsrrPRHr9bQ44DYx4QDKPA4dkzuz9sNjTjpBAqBVPKOd+
wKT1Sxl5o+yDWNW4d6v+ZUMrqDNlme6fR1zkzLNtdiGRAyQGcEnRITlB7vFWITVerNDCGmcIcQSu
4iZDnGJCIqiZFCZlPpoRagkHCNCOuMRAV0vCcwYI8MKT9WkDi4kJIYhVCDJgaF2QoCgMoLgzs3hz
BwGawwXQjUsSqEZGoSqeI9ChNUP1NvyhcicwpM0dsoXOyZUr9iiK1CcC4LKBlcBDBdGoEDGQaHbB
oU47S3DEkSKu7lkjP0lA2MU45IwNXGtGLCk4JZaQ3BlDyzMHIMWbIIb1Hh3cPGhwzcSnxo8OCmA3
h3BNCMSUkQ8QuhlSKxESomXFCRB0UlQQpTFJpGIIDCRbRwnRF780arEVmtQMq1jdhmNe1MK4aQ2P
IDC1MISBgjvIDIwYNytVkrLCCHNuJkDhmbCIcptRkQ5K1DIZpegRG1K7BZHRuxOZyt4CMQJvRf0c
ygKIU93Dg4gOFnSXsvrikakQlsDCPjKyiI8BwDVY6QUQEnh5BRWMXjDqzP0pGVp0icnZUyp1M6LE
1FQnOdlEBGE5TtZNDSXKQUQycMDCtn1C5LKCDmG+hwMkSFdolLAhapUUwnosSVWKNKOUag+nJkx2
pP0fWFLkILY2ynDbI9wKYaQzhuM0aQkARw6nlmqhmBMvwQBFeQGcNLy6o1TcrNpbgN4IrgZ6kSj8
+wYSVaMs0yB6w6loLMHNWoRQ8HxOG7EEFRTNsVDYgZbKBqXAsBtHxWq+AcscX2hNfzAGBHAYI0pg
7DGHAgQwGOIxzpIVoaBWowiswmMUYsxgFDCi3RtY0zEGgLAcOMa2Zu1oLAYo8jaChDAcGYA5Vqvm
RgKVjq4V1LoMIZy11KDCHY2ikGcPvXRDOFdarZqzmjStq9cg3V0ssEVZa2QW18UAvZaq15tr3oAD
Kxa/XKsBYGwWybDYGWWnCxN9z8FyQWi+/SV8lmKsXtraYpTGbCggBuDdjxULX4CV68EgRYQgrQsF
bpmbHGbE6CEa8NZlAWsGUEbsOYdQxNxDI8kOQaT0KIvmhEp9J7mxWeG14NAbw2YhDcQcsobTyBux
I2cNlKwQGZWmtAN9yGDBkM5UypwdKoAguJVRZx6LMs5ROR2zZ1aPI7rYj+TEOoJLjgrJ9vxRIMyj
k0mFTBKoQRQlTRVUIDaHyvTEXVVJM6P1shsrVBEmstslMDixPEQoiZPg5bMlL8kxEpJXLDNFNYp0
3zYpWLRR84UdToDJosk11LmMZGSM0aI16dtRG9mJU5+FhDDac4eRCwhitPIMMchQ3SHkSvkHMjWc
AtBsQtYYIJzz0nVlFxTfVZmEcCDWJSbdeT2rYTw68rZ90u0wUTU7n1D4vxixLGuN8ckeSuWiQ4bJ
EhhrifQs58JvPXDTMwtAdJEmqNuY8+5lH0nMZwUghpG5I5V2XYlWYbizH2N0ZVeptyzSHZfd89p6
z5GhOU2HcJxw0h6Xo9424YQ5nvxmSEOobuC1zyeupGiXddoQbzr6dmwJLOA1rx4FyXdRKTnQVxxB
hdlILUtPtN8gTGMQP5tF6mPcYYyxoZLbGJaVG9x8SB9fFwxIZXtuAzHDuIZEcwo/DsGoc700Hvc6
6Y2hXNSYChuNTanuwrBVXEvU5pFr4BuwzpjsRnn3i5nhZrrHG7uG7Js3ASy6vmzd+eJKSr5U63WT
ZoN11uS4Q9ful17Hvc7aaQ9eOcngxIU7qg9zVMQ1uarGXNe9pGs7SxJrnYcj5JyXWFzzkw5VhcuZ
l9utW9chLzPWdYVCecmaNPDWpdE4HPQURPOJWp6uHnuX9x7fetzzaMbb0nYyQbsdZu7f7/nTeiNu
ZQtAZtyLXyJ4/t+6zgdOxfiMPTEjQ9/il4I7ANFzaWXUrPxd6jgbsf7xlsh5mofbXp949ciXjPxO
8D4IGgqGmuqA6mJOeuij2nKJqrlOrnBOsrOFWE7PkIZgZtngUDMGwPmMjDdoEGwumg4MgF5NynzD
KoCOpmlHTDQGmv+N1DUvwuGvyE/oCCwjjpxt5wIP0oelyDwK1Aco+mjGoHrvmskEVnjAxNvumnYi
zlawNDNjbO7ntjMsiGxMkGsPxOHQXnMQrHVDggyjMg2DVjVP0H5P1DtP2uvPDP4GmgwwRDXwSFrg
QQTKVg3NTHbQOKmjdwqHjgygzmsAxw3GxP+j+vSMnkGkQFMPLqfgcQ0qPkFvOlmnjqmA0IBjVjQj
Om5tfPZPhNekUOSoLuTgZFIiAg1lbmRzdHJlYW0NZW5kb2JqDTQ4IDAgb2JqDTI1ODQNZW5kb2Jq
DTQ2IDAgb2JqDTw8DS9UeXBlIC9QYWdlDS9QYXJlbnQgMzIgMCBSDS9SZXNvdXJjZXMgPDwNL0Zv
bnQgPDwNL0YwIDEwIDAgUiANL0YxIDE1IDAgUiANPj4NL1Byb2NTZXQgMiAwIFINPj4NL0NvbnRl
bnRzIDQ3IDAgUg0+Pg1lbmRvYmoNNTAgMCBvYmoNPDwNL0xlbmd0aCA1MSAwIFINL0ZpbHRlciAv
TFpXRGVjb2RlIA0+Pg1zdHJlYW0NCoAMBBAoEcjOIAaNxkLhkNBAMhyNhdDhiNIcMBdERAcjKIDM
DSEVAaMhwNBcNocNxpEocICoRAaLyMMRAMRkIJdH4FLjHA5wVDuIBQLZrNBaKZcagaLRkMJNDRAL
RpKhdCp+RBBMoEMRnGZvOQbGBgMhkNp/PRbYhoMRxP6CKJwQRAYjCbjWIDSczmdTSboOYRAczSZz
cYTodY4IDOdTCcrqdDLHbyIDYaTCYjZHTobxAdDRkr0dTKchAbzNnc/gTKY8QaToedLpNcc6QVKU
LRwLhjZhqLhrX5fWSNAtzu5/OrPPpdbxkM9rSoFTIWMLbLqxWprXRzwJ0LhgMY1PKjYhmOOrQKEd
McbjmZtGIDCZzKbjpHjfpLrsDYb71qMMjYyr2Ng6Dmjw5DeNr4LmjgwjGNDStO/MINRAKOjuxr1j
oNMArmPLnrCqLdt8szrIG7ySPOtC1POt7PI6ui7BcnEPhq3LqOU4LyJK5KdvQFApsjD4ipEriMBm
m7mhu3UkIw4yMKsxKPpCBoYhqjAaLa5rchrEiXqWsTwOAnoUBYEEPyUm8eqwtLvBpG7xBQMoXDOF
0hSIGslBtLIZyUmyHyas0npvKKQSIG8lR3LURqusMTvA5M2KcGKaOWoUyicFwsxkKoXCHTsZC4ho
bhAHAWhmGAbC4FA0C4pFVCaMYlr6Nwytg8AchzVs6qSpYcyUi0QolLirxM78uxU7wZt+tyhLiOUN
DGzIQBouTTQoEAqjcNIzPvBIhwQNrRjGyw2BBb4yDLMq+o9Bo6TK+YxjexD4w5GA1wKzcPtw3TeN
84DruHUl+OPEDxR65gaQ+6KyO88+AK27TuUaGAaorSCxBvVFmBRdA7DK/Y4PgNwyBANowr6OmTjc
EF4jbcI5XGMI2DY2EGDmN7Cswjo5tW1rXhAOEDjGMoyMRAMyr3Bz4NpXjoxFYcS0iGNRvFSKxuAt
+ZDO+7XDQNsCvu0sXNJeA5DyOENZwEGOjToY5zLbj8DrFz6bawy+oPFy8XRuuf2s1g5s3l+mNsBo
qBU8cThnHjvBg8uNs8/71LqOY2tcEA7jSxPJvY9zZPY9Q6jHtL2M6zm9XtGUzV4kiJRvNVivKloq
J7g6hSAMs7AbZTcyOmuMhc80/4HQUAI9Qvdhu3Msd+hffOtL7vTC5MydXws0RxNa1Tf2ihTlOndP
K3s9d+jHhKb4iq0GjspJFNzex3qfnX/iYYPD7tIxRjdL0zTdPqeBAqEqa0wWhBKOrxUwMyulmBa0
9LpWC1A2Byxc7wNgbKUR8U0m6r1YqzVqTVXCuQUq7cKcWBkDliI9WQd87bG0Zq8ew7BHTs3asbdw
7oHCeTspKBuWZ9CTn1PGfalQGEPCzFcByQxRiYILQUccjWFyflPBGBcFJGRZDekkVUGJVqqgZRdB
QGmMSrQdvWKUlWJKgViNSBrBNqpYnHOLUqCgIRjVaB0PrHUuzYDThGP2HINIZAwplCSG4McJClJD
JGDZJQM4jp8KrEclDwS2vFUIlMGiRyGEUBnEl+h5JHRON+ixSwIAbk0CM0Q0bMl9SOIEb1ZaJTsQ
mYJCpHBzAasKKiwx7jDzslelq9KKEb1kg1Y2FJCocmPAgCEHVmYZUNMrJQW1VR4AcA1jICAJ4Qwh
rYDcHAOpmC8mfZJIUyAcmgzQDTMsJk0JztrMM0QEATTGtKLKCyXUDVhQPcSDBxyKZblCmsQuXUbS
uw9hS41x8xCxxyR8hcOSGUNtvQUvZoCBw7SBbwgowRhDDNGMUYxDJkWSh1cCCBj0gAzGwb1IE+aG
m/GnRdPkhpGZ+P5eU4yfwOEulvcA4I97QQ30ZDJRulrIz7s8XCfQ2JgTBraL8tcvrgQ5OidJIh3a
VpKPZRxCt6cc4zFLlpLBf5wjiMDLA7YFBzZWg0IWVZUxGCoSyYCVyYBYGrUOq8DZrBQgjGIbGG0+
66W90vNcbAMLczPt1DG3dtTPJlNtQ4Y0jpdS8H0DKGcxy5Q4GNPqtZkwbqWGOqK6SVjTZdkmfvBA
7yVljz9glKQFC9qNhmDrIZ0gc3VBBDGvEOVRS/M0TKvZApdWSUWDQG8NlwCDsts6tpDgaAwzLY6x
8N4cGiU0JMVZqMTInOOr6Chm4cA0F5WhPFki4TPBvDIgVuJ8LFWGsbNFvJqaXN9Ng3+k1QA5XFZG
CANzOKfoING4Q6FqabUJp3DSfoMqERzcifVzgc12lzpMX1ALYDSMtDbbduxkHMNdWvRZsNyLlXMZ
Ygi56HrUFMu3WVMBK4nQKtkZ5A4dQzoPY+as9TOG2slDK5Spob2xuZZ46qelokJouZ4fB0c6zXUT
PgYm68q7TMzxY4Vhdqp+FqT9QwGxTmN3GI9bfJ7OGZM0qc5YNhjXTLXqEHA/k8l25QQ1ZO/4ZQ4l
8ZDcRkVxy6l3uTctvF2ogolPISSUV4bnF1ylZ1Z7bZnGNzUHdj65TN0XqHS7OCB85M8ZJZCjLbnV
BGbCGUPAYQ2hwMzcPQOBkQYuwTohZIOK9T9TxMaOeZMTaEqjo26CBWTMoZUYEPLgQytfzfjt0aB1
tWNyxfBul58QUzxbTW7iOXpbZhXI52Zb770wvyae7F/WcIFPmGdejJF1hjI5aXP7awyhicvY236Z
bEuCvQZ3S572TIOwxoa1bicHI7YMxtVSoTmhBCoE1fQMTfA1li90FHCmEwIjhBirwOLwqtTLclcJ
c9At43xf9zLmz1ntPfhPOu58Qmeqk6A1zcw0s4qxW4lklYUxOq+j6sK+zjVkWJLOtAVDkRzIavot
bvSb1xk30OurEZgz/jc/gsSNYMFvj0vfeOvcUbAykzJm4INmY92fmmxF8bGTxqk3zcSEOBZdWSsr
RbVEfblZu6XdrOFaZnZW5nmDekHGrLvmTdzRN6mNZJSlbeH+asr1FZJfBn7EEc0Ntl7T0ix3f6q1
mxTXA9Ty0zUKohmjOMvQcY+/zJMiGfNIGLC6tC9IBqwkfiCO4Zc8hbWBfVY1/dQrOcatLGwZS5V5
IogIDWVuZHN0cmVhbQ1lbmRvYmoNNTEgMCBvYmoNMjI2MQ1lbmRvYmoNNDkgMCBvYmoNPDwNL1R5
cGUgL1BhZ2UNL1BhcmVudCAzMiAwIFINL1Jlc291cmNlcyA8PA0vRm9udCA8PA0vRjAgMTAgMCBS
IA0vRjEgMTUgMCBSIA0+Pg0vUHJvY1NldCAyIDAgUg0+Pg0vQ29udGVudHMgNTAgMCBSDT4+DWVu
ZG9iag01NCAwIG9iag08PA0vTGVuZ3RoIDU1IDAgUg0vRmlsdGVyIC9MWldEZWNvZGUgDT4+DXN0
cmVhbQ0KgAwEECgRyM4gBo3GQuGQ0EAxGwxFw1GUPGkOGAuHI2EByMogMwNIRUBoyHA0Fw2hw3Gg
2F0OEBUIgNF5GGMPisxkMCmJjgYgmJ3EAoFs4EAtFMxNQNFoyGEohtHGwwHMpoEyEE1gQxGcanJU
kItjIwGI5r9CFFApJUpY3hk/mJEgYuGAzk9Xn08KloKZlMtrpZFkg4t0crg1FwzjlOF0QucKjsfk
MjBoxGFuG+GxQuHFXmd6n1iulls9DEGABtdjl6uWisgyr+hseXq9oIZoMJzj5MMp0OhlOWowWVGM
SxUPGeI443jI11YuyEekEikgxHESs3Il2duINsYx514o9jGY07l7oY7EBPIZDEBDN5uMhpOhp+Jh
NggIJwOByN47PwEAnDeFwQBkGwbhALgUCUMI3QKGIZBYh4chyHAuBSFzUBayyqhszrEIozysiMgQ
cMajidO88S9LRA7UROxymoWGDzrkrTkK8q6wu+7KgtM06lISt7WLmuq7p6uD0BQvq/yE4bCKs4sT
s6xjHIy6LJOoyrLugwzGKi7rZzCKjZLoGTHR+tMIveFwjBcKUCtgxCTQWMUMQWGUMBBBwyQUFAYh
pDEChAKr5OAEApDKM46jYML6viEAswmMIQDFBw1hANA3jY+Y3DPDbkomisQq/G8ShBGMUrBFckxa
oYZBu1AaLqlLOqajM0qxHE2RUFEFjG+L6jcOoyjIF1kQxDdaNVEAcqgmFd1QrkdRU74ZpvJLXBmG
QZtqoYqDQj4hDeMI5T8Nw3t+OcJjaN6PP+4EJjo3A6BAOY6Uej9LjcNY5z4+QQDdR77YG/N+X8yI
xjKNw6DYPNNDCO19r8NzUIEpqUI3EbvuK8Vtrrb4UDCOt6XeNI9WMEA6DfPgx3s3L3iDf8+hA/r/
jSMiP5zhj6jpiGSXpno0jHglIt0OQ7aIMt/jSNwQWCNw3DLl+C4uo6GuhU0jIbBNtLGGgZhzkQ7v
oNCQadBwxjTAOa3SNwzbSN21wCOg5QcOYw6q+N/6iMg65flV4jkEAyjZqm7PjomBN6O9339DUhBo
ikUSUuTQPG0cfSXIK2KZVQQVLEccdBa2RRfIQWouhwWhmjLzdHaau83HjRhq88zBgutorQITc8Fp
+hJBd9Fjfpwz3ncQQXJc0/aiMY2DrnV/3pR+XWGg+Y0qIYg4AMl2+Jq+M61jnbWj3Ly1WtAz4Y4D
8YfSmS3FhuiYJT+V+Vnn6Z+EA3jM1AOq+A3htOA30+Lf2qv3biwNubbD8p9fE1ljZcUjHlNi5kGA
NTysibfAttUDmVt3Dc3lvcI0+HSb0fVpR9WmP4esuYj70A3m6YeZFRxv0/MsUsph44IGyr0ac/hJ
znmMNZMhBQ1yaGvJlSMDAGQNWRQEQdD1/y93EMFBAoIFAY08AoQuUmKrwghBIPcEFl7kXPGQfHBM
rB3waxQa+XQ8sSy0MzBAfMOYY4Am6T8GEMS8UJhJZ0w0OUAXvICXUGluLRWGs0DYHNlrNw4QzI/D
phgZwwvsBA05DcaojNbO+YRj55AbtjTUpVYgbQxKIirCkNMKw0wtZiHBcy9pWsBiC1FqcJYfNmiE
GlwkkpKJ+e49eV59JYhzQLBFjSq3LpnV7Ew1ytHeLgXEbqY0sIWtOeg9Ij6Cw0p7ZuwsOYc3jrzh
EHMNp9HsKUYDAIOUPQyKPlQ1RpjeQ5MQDMu+Zj5IkGzJbKM0dAU1PCDeHB9ykGnxheVIJnshV/hT
DyvgMobUJhzcA2dmJ8wzn0QCwsOR9ZFr6XYZEOKxV8L/n2cFIURZmvlLqdagUGVspLYnPGkdCn+v
/o5R4/NIKRP1XXO5Pwd1zQif4R6k7TA6BzPVOCcJSWdMTDZQeHsEKWtYJREcrBriuU1dyDAiMUVz
BrN7D2SAZg6VGhQwE3C562Efl3Pdc0+l3xCf7Qhu9OqGEfodISAM/Y2TPNfKaaR5E0MiolRQNp6m
a1Qqi1CAYcGHw9h+Gh8Abj6MnU/URwrcF3trfu8JYIbIbvuPzJNfDx5+1csIXWwzuVu01LRUoOsw
KKs9ZpOUN7dIcS9XpJuQbPmIVsqRMlQgSWnhhDIfOhUgbh0Qh8G9RoZLBTOa4yGONsI4JLqZH4Ng
aQ5tnoPQmHsk7wtraYhOcaxg6kepKzVRjPLwtTpVXd4Vf27SGsWb8NsaCl0un9V0saqy8l0Voect
C4VxrlXOhshaFURKuZEFw2AMmLmjNhTNbE1QUL/UUoyG8WAss2OBOupsO1+qaU4p4g6wQ2y0s1C2
HTN2lM6jvPS69MINWxgwDdbDIr2zlquwGea+YQt4nXkRo5wGlTkkOGZvQabwwsX/OBub0cXL3f9W
uGD3rWygTODaC80wa4ereGSuKe6V14yHOZ+7NW7ZKvFOZSMVYPQNPwhNhE53+uEaofGAbRMdwUNm
oGmZTn1FDyOGGz0llPyZZ3ctqs2l/ketPDllobQwhrz83qk8wM/BiP9WaeNnc/xWaS0S1lWXx2uS
MhF88GFsaLBQGUPBv4RsFX/FUMZHrnUXoynxf9qnsWStMvpu8D2Arus0yzU+L1OWn2XoXAhdC6xL
LyyK21uICSNwAA0HBXSTOWuztrWiFWRFAxCo1ozT8Sn4khiYOWKF/sIxYp2HuMMZTJZWy2S+kpNs
WdS6B0UFHSOVdNhRNSsThEkICA1lbmRzdHJlYW0NZW5kb2JqDTU1IDAgb2JqDTIwMDgNZW5kb2Jq
DTUyIDAgb2JqDTw8DS9UeXBlIC9QYWdlDS9QYXJlbnQgNTMgMCBSDS9SZXNvdXJjZXMgPDwNL0Zv
bnQgPDwNL0YwIDEwIDAgUiANL0YxIDE1IDAgUiANPj4NL1Byb2NTZXQgMiAwIFINPj4NL0NvbnRl
bnRzIDU0IDAgUg0+Pg1lbmRvYmoNNTcgMCBvYmoNPDwNL0xlbmd0aCA1OCAwIFINL0ZpbHRlciAv
TFpXRGVjb2RlIA0+Pg1zdHJlYW0NCoAMBBAoEcjOIAaNxkLhkNBAMxkNxcMRkIBiNIcMBcORsIDk
ZRAZgaQioDRkOBoLhtDhuNBsLocICoRAaLyMMYtFZlIoFMjHAxBMjuIBQLYsMxALRTMjUDRaMopM
KTGIWMBxQZmIJtAopWJEKC4KBdYzGbzcdDSbjqZTIXBTSypTYELRjL6tWCJWiNXBnG50VJ4LhhLh
zWJ+LY0MBsNpxQqJZTacDCbjyIDaYcqZDKdjKbDecBBkzIIDnnTYIDQYTkZDvqpBotIbzMdNbHxA
dNSdBAaTmIM0czSZzdbNCbjJcLlSbqLhrHZlecSMubhqTiYxV8cKMucjWZTpxDMbzltzRIDgcjeY
zKc+AboPsDocsmczbvOBZhBspDacmYzSMI2BYEAxMmNa0jPATxBAMqyjcN76jG5AGioFSBsEGakJ
86rBBqGS/qGFAyDCOgwwE2DLsyzbOs+4rRtKNjTjOMrhvk044DqOQ4De0rUNU1jXNiEDPPc0Lejm
OoxjQEEZRpAEJQpDYYBmG4auoxIYhxDIqRBG8cx2kDUtW2qQDIN71hBBzdQaOa0DoOrvss8SQNwy
aHoEOAyjk9SzvyMzyJAss2T64o8yfCsroa6jEQuuqsS4MIxjWMMZNG2QzTzA4XKDCQYhijSMrxC0
pJRK1HKIKYyjLCQipLLCFpWEEPI06YZI1RqNIUjyQJEkiTBgharw8v6aUWGFPMLDViqtLUQJyEAh
hcIwXClTUPBqhgcLCMS3LCi63BdCS6Q8qS6Je6bnyiGIcr+w6ey2oigq7aFpWpWLpIYGKwjDbgUB
lb9whwiaO2vDtQq2EGA0anYG3cn93RAk8JYSjqnqq7Cs4OGK+3Wr2GQuG+L3bDgb1MFCgicN60DM
NIxsmOjexRBb3UmkC0t9EYwhA870vW9r3uNm8SNu+Q3Po+w0vxSC0DsNK0PWFmAYEEGCWGvSBYnj
uGqA7IZBzCS53Gu90Yzja/pFZQaXZdMquytIxjYOoyQPP7fRUzw4DbGbdNgOcAJA/Uwx+22+Nk2j
XQFLsj5c243vI3j8tXPOvuVcznKzYqL2QKmRBgwdmKIsw2MqOnGtwkAyjw78+SPJLQjHpemjTM8g
OG9T2NV0fGzwOT6t102dPR3b893EekDdQfTUNdIZsbzcosV5sQCSzSzjkOreimPM2DKNtNBBlGVZ
Zlzeth6e9et8g2Dnxo2+vNSzDJJHfPKNLxxFoWd9tn3lOiG22POWKDQGrJDsmwfuzk+J8z6nseM6
52DTkjB1DEGpBjvnSnlNibNMaLUepiSAGwNLvXilmDm/wwSnYCQAMSDMGDmkQINRIWk4jNgpBlDO
HUNkI3jhZXAUxhjUwcl9Bu5Y6CjEtOcBqDB/6IG3BpeoiQ07Sg0tMggeREZoTbO1Z67hxjdEGvxd
eoNOsUoqOjNybs3rb0vuicmU8lJHFQrKJOopK6sDskfhyd80bpEBoFUypxToLgZkdXcXlZQNnNOc
Io59kwIHzPVevBx8AaWVstLOb01JnFdHnPW3o4idH5hlMqHcN8ODjw+Ba1hqjBi9sIakwtrTDyiM
RlQp4vpFQWwsIYTFjErWNF+ayhdkKUYBofKIjMM7NDdvHd+GEMjci0FmQBA6KbsUzuhMqzZBrtZo
vHDu01JTpn6rPCDNSKjsnyHGjaQ0jcRFRGDkSlEhr0SiSklMmhlLMpkoymWaRJCSoyTWSMGUyR8k
4IKDDQU3QZj0BtT/OMIc5aAwQU1OslKuV0GJha5ZzhJ2LogknJV8ZoX1ONkyoBB7vY9RWlC0FnL+
WetzgMzhocCmjlmotO1UMdZ4rFkHPQFFE50KDpC+KS8HJHnxeugJtzcG5JEMmZVnaOjSmjM0Zxu7
eU+IKb6Gxv4Zqc0YKyldjiyYVqkOy4GDbhINOHBBN9GAIDIBwdFW+cDdAhBvR8uEhYOQcsFQ1LIs
CwmvmChbHQwRJ5jAoN6R+G8eXjTplOXGH8bqdLocwlKxDnQcQuKIWk76OSPokm6HN7wSXjwgDOGg
3R+nfhuRGjir6f0eTOmg8aadQmnt0DM0qlif1Cw+bBRdqtGgbwpo6Daj89ZShsNGGKlBxn5HEmxP
2bcFYGzfNw3SiM5qBKDqS+hFtOY4UZsNIOzaHrlgoqLJZl6JmgIANOyk8p47euvN6foj5ZTVoCd/
XlH1cizNvbimeUFtDXuvmrBCsNxTBA0BhciYlfmSpARnXMMJ7DiXaDQzaZuCpzpnk40yUoc660JZ
2Zy58ZiQYANWgO4NlLh2XrHCcHLzXOAzSyyWx0OIdOQiwzUNx/onzTj4793cCzgBiq9OS70VT9Xh
kiaLBtO7EgyiOlEGgMYllEvbSM0V/r6hlPCR9ExtsktHyYSAOpxk8gghrY/H8PEJAzBoVeVbY5Wt
YlgqVrjXofKsAaQEDWVuZHN0cmVhbQ1lbmRvYmoNNTggMCBvYmoNMTgxNA1lbmRvYmoNNTYgMCBv
YmoNPDwNL1R5cGUgL1BhZ2UNL1BhcmVudCA1MyAwIFINL1Jlc291cmNlcyA8PA0vRm9udCA8PA0v
RjAgMTAgMCBSIA0vRjEgMTUgMCBSIA0+Pg0vUHJvY1NldCAyIDAgUg0+Pg0vQ29udGVudHMgNTcg
MCBSDT4+DWVuZG9iag02MCAwIG9iag08PA0vTGVuZ3RoIDYxIDAgUg0vRmlsdGVyIC9MWldEZWNv
ZGUgDT4+DXN0cmVhbQ0KgAwEECgRyM4gBo3GQuGQ0EAxGg3FwzG0PGkOGAuHMVORlEBmBpCKgNGQ
4GguG0OG40GwuhwgKhEBovIwxh4yEEwkECmBjgc5Kh3EAoFsWEAtFMwNQNFoyGEnhtHGwyGYuG8V
mBEEE0gQxqo5nE6pkZGAyGw5oE+sgwG43oFCFE5GM4KouKYuIYuEBchtuGMmGZcFBjLgpwQ4woup
JUpYtHAuGMVGouGthmNbI0Cx+RoE7tM/mFwGYwxdLzcVpsLGA4oFarkPr+WkAtsgxsFvoc50sJhm
gy9kGcmz88oNDKZlMu7IsjHESioxp8oh1OyEVjMKEEdj8hkfQiVXh4wlur1oNtY1tE9o9kGQ1m2h
3NzEF5IwuKV6GXthg2wRixLdhaGbJsqEEBss1zMhA07OvM4bcBQGYYt2gQahwx6oqyzCutjBjzve
KifNoFyyhoGcHieOg0DKOT5jeNw5jSMkVjCOg0xcOblJGhSGIcs7HocGIYok4Trpw7SQJEBqIKhH
qVhdCzyxEp6WOHEb2pe4oUCSNwQDeOUZRYOg3hAMI4DgOQ3jsj0Uo8Nw3xqMYyjmFgQTYEAhDeMM
vzINg5zGNo6jmOgQRkOkVjaNI3TWNEaTrFUAOwpqTuxDK1hzEz1SkkoaweOEVjNLw2jCN04y6M1H
I9M43jgN45jKMkyDHGo7DTGs5BAMQ8hAJ03jSMw0jHUY6DnMg3VgJMZDcOg5UCEEABiiYYwI9TiL
gviqQnEYcvTED1sgv7LLhYMuI6MM/DcMIxDYPMJqOhqNKw38RrZbkQvYG8PrgMSPDKPFPVlV86zH
VQyDrUt90VX9h4FVAQDgOt1WAEC9YpR1GjeOo6DuMo0jONGHVbGF1I8MIyTUOVXXbSSrQPbwYBhT
FuykyNwqGMozDMMtZTmEA54Nj9zBAOtjDqjwxxdONlDlGkbS4N9To7Pw6jlOOeRkMdy1dWEvaENw
zDCNMWaONtPRrGsXBZlV3o21qBxHIN43tEbRtY+DBxcMw2WBhenhBRNDajYc6a5oepWNXFRjXRKD
zOMNZWBOTFKUploBryzLLVB9rho3YZByx7WOIrUpKfzGXWlB6ciDYg4T1Qe+1rYgyjsMI2DrpkXV
NAEFwNtrXwWsTiczuzRwBzyMpSo7Rx530Eq8jTZPNK1p5ksiLywuE2Vcj/HTFlE6TtPE9Vho8Xxj
FdiTtX90VINPa2LWFRXQM8V/cNjszljGqVvp+1JO2xSqVgaIfbkU8GbMS4K8Rqr9cbC1RqwTY2Fn
rEEYBkfcHINKck6QPYazdnKsmGrLVGHN7rTQQB3YwGxWCjE1JdS4z4MYaH/Msba6QtqDm7NRf01V
yRjAGkpImTh0RvoCm2Lc3YoCKk7p5T2m5Qz6VGKDDK45j8ClfLAWECBUTf2wIvBAsEOCtX3hlDiH
UNLtA2BlWUwxNjuzqoFMoy138b3gw4SyhFAANSWmcQCRkGjdTLmveebd4KVgbqcUy9YG0R0sxgjE
/eNKak+sWUHCgOsKlcEeI7GVsLAW+hhBAXUu7iA3OKDcQdLwZ1RhpD07gNxek7rmk8lx2obIZqUX
kWVz5n0pA0W49mJTX2dqmfw0dL6dFEhjdtBaU8X28PnWU/YEC/QwqIXQ2dcgZVWBygc4d9aowxv2
hnACXJ+YCMugHAgoaiVQByVFNiCYYlEB0UMrBXKu1ewMWEzx8MTIVtBfLMoOqMoIRRI+omcE0oHy
3ZabUzkiW5nkbs/IML9IMPvfLBVGc2FiJ6aMjcNKgo1SVVq0BMyaI0TETsqpVkJA2Q9KWpFta8St
Hsj1Lx60f0HhUiU+JPajFiLBI6GaS665nPmTAwGlbIQ0hiDS3oOiukUqNWRSNZic1IE4ZXLimrb2
YU4SsDmRCWYrT6WUzyDkEWxKBTEG19EzpLqwX7S1RYZQ2quDYmp9KY07QYDmGtYjfQyxpVkmgNyw
Jx00bcDAucgICgzZqChv6K04hwmxMhZSn0VxqTjBubzS6Bq4V0qujbi34MOdcsANLrUazNUSmRno
eaRBtkpQxtpawcOmU0StTtKHzrEgsGeR8X0VwLixPBVwclaNVI+1yESL4So3qOwVgDW2TpdU8G6x
Nt15rbrBLpfLNrCLLRcxJRTGkvWABA3oNddQQJbcBeeWFPCPU+n/UGj1RA2VGoy+cjtBTkuTIFVu
hq8waW6PYDN7BQ6WKtffa9vTHnXqne1JqkN6q0xKVY3qcKt4OKqTiwVqMlGG1VaUoG7aGVNEQSqy
8/KDwp2yUNbSS0mFAprT+rVjqNCPQwY/X6wF86ez+BBE5W9U1BqjS6QaVcrZsW2gCWUHE55eg3nU
CjGs9l+YRqbGlhi+2xskBAFC1M4XWxrtenbEyy1m4xtnC6oyvm/KDVUrRGSOMBLuf/Yp6xtrvg2S
Cg+b77X33JuXBpvyxCOhnkvjxWEHJqTWYDPeUAZ00orDdW6NYYWMhoS8rVXVr3Ygg09W5HIDSAgN
ZW5kc3RyZWFtDWVuZG9iag02MSAwIG9iag0xODY1DWVuZG9iag01OSAwIG9iag08PA0vVHlwZSAv
UGFnZQ0vUGFyZW50IDUzIDAgUg0vUmVzb3VyY2VzIDw8DS9Gb250IDw8DS9GMCAxMCAwIFIgDS9G
MSAxNSAwIFIgDT4+DS9Qcm9jU2V0IDIgMCBSDT4+DS9Db250ZW50cyA2MCAwIFINPj4NZW5kb2Jq
DTYzIDAgb2JqDTw8DS9MZW5ndGggNjQgMCBSDS9GaWx0ZXIgL0xaV0RlY29kZSANPj4Nc3RyZWFt
DQqADAQQKBHIziAGjcZC4ZDQQDIZjAXDEbCAYjSHRIcxU5GUQGYGkIqA0ZDgaC4bQ4bjQbC6HCAq
EQGi8jDGLDIQTCQQKYGOBzkqHcQCgWxYaiAWimYGoGi0ZDCTw2kDUaRqKzAiCCaQIYjMXDmcToGx
IYDIc0ee0iyDQcDegUIUTknG86GkzGkxmE3HQ5iA0GE7R40m4yXgwnQymQQHS/nTFmiPEkyGW9nI
630pnk54g2iA033B4+PHA5G8xmU5303maP4Mwmw0nrBmelFSmC0cROKjUXDWwzGtEaBbmKUCd0Cf
Tyg0MZjLa0yBU6FjAcUCs1uLV6wcaxi6oDGbWkW2QbDAZ2+hmm+CA3nAynLD7MQZY2agWZ43GM2H
XCm6DsYjzEDGNA3MMNgQDm9wxrswy6jeNy+jMN45NFBDNM4+69MUOYwjaOD6uesakIo3qruAsgYu
o5C1O886YLgKAwjkusFjgvTHQ0EAxsuOg3ja94QDCM6OjLH69jmFygMgEAhDfGTFL+vq8o6Mw6jY
Ng8vmMo7DSMo7sS0UQioFUWLKGIcxWsiyrdF6hskyg6MszELyLEKnK+s7fuS9AUC4GU/xDFDzRW8
bvLMtDlhQvoyPgMzHPa974v8+crNRILCSDIYyyLOA5wzTC5rqu68yOvzADLMUyTUG7qvEsgZTZRI
xx8Nr1MQxUehA0g3y4ycKiMxNIwOKTUPewIQMyzcihAO71DRCq7jc14QMCOQ5jTB72NZAFUoHFoa
0Qn1ChgqlYrhSD4LrSb6UsLgUMG/T+PlADFjLAcCrzA8E3tBi8wdCAuKVHMOQ8+oQRjGa8DTGy90
uMlu3GGYazQtMUBtcyhx2zcfSBIUiSM9bSWxClc1mNsjQXSd0PjB8kUCEGJq8G8TKzFFwUIsgZhp
jAUVmOrKjy+8fjK9dawKNo6s6vI4PVabNw1J9PYdUy+jCEGjDTpDOjZB4zhaxA5M6yYxDpl6nJOj
brTLck9TKi8+XS2ckhBN7KsvqdQ37G+qjYOY3vwxFMVyy6Pb8OA0M/GjDzAMY5DyOEeyGMPDrxsy
GhchW1XGsu23GGOeR+xg3jIvtcjnTY1sXv7KDmOqOwr08djk9UstWEDCjPpsDtPhNR8XqvBb+MIy
PbHC/DSM40Sxy20ZpMoZu3itDT52PXI80q6BAIYg3re4364M48hd5nMN+rPPBg8IqXFNQc/UuAkj
dIIyMLf8Mr6Ny6TAMIxV4Mp92EI0YW3tqbGkeo/WsswN6VjFBieuGUOIdQ0kdVw6svZ73yNpKwt5
zj6n2HeBoV1Phg1ch3dmHRwKOkHpxDCGM9ZjDDo6RkGVKqV0smTWigFJaVT8r/akR1BLLQ0hiDSb
Aup9mphzVme58jmYNoobeq5FoMETLnNYbB/kRXaLaQqR0+odkbq6RlEd4BiiOwRgnDoj0AWFMMRw
piAzHGSN/ZMh8PMGXnLjKeS99cHH0m/Lgs0xiFWVrqIOuw1RrG6pxbvA5CTr0AJZhmro96tYUJgV
yjZhKNXFn4TCUtETZ3yuaVeDFVsfU1Ayiqm4ybdk5rKDa+OUCKSJHVOUzWEBZmcHeBsDJ95QychF
has93DukdHvVEg0wRqQ6pgDFJJg8Y42xhDvAsNhijBmFX8qiUBuDdMwN6+Y4Jw5vliOUntNoKDmp
2LASghwLSIkulOdc4R2Svm/J2d4GMuopHml8nyGBjl6EdRql1hrtl6O8mTNtq4YUsv5MdF52r8qE
zIb0YgEDPz6mpi6vxpicImziRQxKXc/meBwdcgMMLp2qoIDLJqTod0ZHwL2lkMxpTOr0jZJxhpn3
WrzSXQqi4ZUkx4lId4GAOUXR9c2DliiiQjOuQA2FCb/26StkYX1XYcA30sdUCBdwaWAggNQHR/hs
A5rPNhJY1T8gyzDmjJuAZe07ELqcb5NKfE/KAlAWs5tJZex8LhVqDFfSkOXiccCPQMFYnJqQDFRB
cIWIQhav9qaQlNBnpjTNG6WQyh4q46116OQ2oPPUhOslcKd1zbLN2uyea8zpr2c6vpDCIx8J8oqo
0T59MTpKxKX7PUfIfDSXo06zFnGidOCCtZ6mpVhrEUqM8EnX2rjc6Vv6u1ekeVmldxZ8EDumXs9a
kLak1A1RNB8spbKAGQgmsyzlNayWgq69ZqdpUCo9QpHWLB+SPSCWe61AcKrvNgWndONLIFPW7RPU
ip1JSzXBRzdC6NDYSBhNC1aOpHTIIQDSscMK8pDIWlgY+GM1YGNXtNfqT5tpQ2InEeOksprIlDeG
ZAjt/ouXWgIrleki05HsPc3FdalYyvdQIgZBFZjCNRlli46Ll4NWKfbelteUy4BUSWk1J6WlZhnQ
KHpS1AQQBuDKs5IFCXHOQDe5JyhPnQhodGX1IqHw3h5mclnIBl7ywbc25/GYN8agofyhQvTtap0u
dlFsOadGlF6V0aW7aQQxN+P3RhXaArLJCwwhCgSS3ZhzDW/h/TD5QBFJGQENZW5kc3RyZWFtDWVu
ZG9iag02NCAwIG9iag0xODY2DWVuZG9iag02MiAwIG9iag08PA0vVHlwZSAvUGFnZQ0vUGFyZW50
IDUzIDAgUg0vUmVzb3VyY2VzIDw8DS9Gb250IDw8DS9GMCAxMCAwIFIgDS9GMSAxNSAwIFIgDT4+
DS9Qcm9jU2V0IDIgMCBSDT4+DS9Db250ZW50cyA2MyAwIFINPj4NZW5kb2JqDTY2IDAgb2JqDTw8
DS9MZW5ndGggNjcgMCBSDS9GaWx0ZXIgL0xaV0RlY29kZSANPj4Nc3RyZWFtDQqADAQQKBHIziAG
jcZC4ZDQQDMaDYXDAcCAYjSHDAXDkbCA5GUQGYGkIqA0ZDgaC4bQ4bxEXQ4QFQiA0XkYYxYZCCYy
KBTExwOdFQ7iAUC2LR0WimYmoGi0ZDCUw0QC0aDIaxOYTIQTWBDEZxuczumxoYDCV0Gfi2yDGT0G
hiigmiQEI3mE5GQQG43nQynMQHQ0GE6CAkmQym46HI637A37Dmcwmcy3gwm4QGk3YY4YfDYgQHA6
mI2GmfmExmM3nXEZiDmY0nI20oqUwWjgXDGO1ca2GtVwQbbcUGeWigTG3jMZ7KmQKnQuKUEiVsjV
2vjneTyJjAbjXiWqJjIbDe3UQ6G8QajMnUx4MwiDDHQwmk2ZOPGk5msQZUwmw8nP7BAN4zL+uTCM
6xLFhAKb+r4NoXJ0Jo3o+N47DKOQWBAJy9jS1wxsqOg5uUBrmNwFwao6mLou8sochm7qyBgHIcvG
FDAwo/Izo++jyr+j7BQKw8Dr8MMhBAObQv8Mg0rsPKQwiz46jkOA3jmvsAQEwC5iQIYQCC9cLsqM
kQioFSprXE0XOyGcTqEojCyAxTGSG843jaNo0jovi8R2zAxjYOrDPyz45Qm+w0jeyzMPyN0mPQxL
TMGO87jRQMKMzJzAMFMUyLIGbwTQGAahiirjKIOFBjsNLDL9Kg5VQMcqtRCiPrwMUmSwEAhMq/Ap
wrVyQCHOg4MrJkusGLgULYEAqhcKYXCHBwuIa8VRBsm8Qow2znp6rTvBiGKoOJba3jKOkQiKkrdo
1ToQKsr4bIrb6JoqjSFI8kCRJIhKFqkGQZttM8URE24Yt24gUSoONzJKhSGIdfobtunNRBdet6Jy
j6QpGkoco0jl2X9Es1pnFSvJun0yuzasZhcLilMxJMOjo1kBx9W83MROAWo+NjBPoN7NjkwVDDcv
0A5owdKjJJ1IjYNgQDEkEjDENQyvWv43xCFuJ3rrSJYBblOVDcKJ4JGVSBRW4yjwMM7DdoVD0UvC
PjOOuePKOUmDCOrAQjO8maNW66LsMgXRC4CkRJr8UxfdeT5JNa3p1DOZQ5D04xs1E6zvPOjryMtJ
QrDENcqxC/L0OUf5xBGmacj9TL7IGs8OEDdN46LfdmsVtp/cSiIhELmBk51Rt66aLOq66xom62xu
0tuz0wwfArqu+soXGOC5P3oUWj4XgOyGOzCotKyBlb0ZyEOFTQm/crQH2C8w1V6/PQOeZDpvcqsq
EDOQjKgbUgPucmhs0jlnrEbBy9l8ZxU2PceEDJ4BU3EsiZQjAHD4neETBuDk8TZ0nM3SDAd7BvHe
Ize7BApbAgYHIRa44shuzuNnL8+sMh6kPoAdQqxXxflavvBAEYyaFX2hSdgq0kCCn7BlDal8zLnn
QByU0QNshWXyETOQbwt8A3SQ3dO6lIIIHWGXMzAUvkYlFN/SuXI14IA2l2DWuRmYZQzBmQjDdJ0b
S+BySUGwOYLIooqIomuKoMFvuQKI59LDqEIvtaXHpPBh0LvRh9EAwzQWnREh1EdBcSj8hzSMR9or
qDGn5fUqdn0UIUpjilIRginwZnaRm/0OSVE9IESoGNKDfkLhmNUetoZ+5dQ4f5HNqrMlKl9aLGkk
ENIbShSKr00hfY/ovKsp83EHYGoBDMhU+kPYtQFdLMKECcHCwpIEDVFjFIKSABnBiCrBIWwNDCGJ
CYZUHExQI25/DGHAFySofU+5fj/l6MGkmYhHzEIXDQG8O4ZVZS7UGG1AaUyQI7DuGg0gaIIlOJSx
5FEFTtPEkGt4rJbw2oRoq0FJLMlDvtDErpmbP4hUsaIfljDakpS0jMXsuTqI6GwDnPcKiBHBF3f4
HgzZ60QTmKmQ1ijtpVgyJap8iMhgUUvDcGumJBjKhpD02+mr9VUoVZnRdclPWrn5asnIIYQS/I7P
0fwPRIEOkfl401WxcqN1Oo8Vp8oOIYwLRUDQG82C3pDDmG8MaSnOR6oDExPR5qHH7Dqz085do5N1
P5GAuUiaJz/scGtITGKxRJM8pEwFeyUr1o+49T8K4sHkjU6hKRo7FpVZ20INxB0dq3lvLkOkaDzm
LPLAB1BmKfx4aG3FAFngyGCDDOU2YDSqm2LOttxZ32vwZLKWds5cQyuyNublEtUHcXjOEiJcKMzk
NZKqRoGhFQWyvJe8R27xivFgvS+WdtVAZsmgbUVWgZTR0OSrJJIwY1J1xP6/qJtk0/VgL8Hc1IbC
8J2ZkZCMqt7QudUeay1VTzoVRtZYIshEaSlETke2tsYMKtyL63UwaiTVWJNUrSmFu1BYffndIphJ
yUkOdriO85wXdXrbO7+FJTi2EvKnfS+ORL8PIv2d9lULisA1niW+oZc3qGUj4eaUddbM14Tm0Ssa
s4fOZM2/cNKNo5TbqU+5LDWWuVOxK4uaz4i3vrpyfue830OzhaU/EwcuA5UIDpZtR8nQQVtoEZZW
4VQ3J3PoFM+BfI+txxDX27MrISUgeIW9+odU61gzogTPyU324UbqXhPiPZ/5sjhTSMyt42hyjeYO
n+jwg4hzzBUp8VJVyEtiweaGPSdBJMsGEMlK2hyRqJl/Q2BzAvSQJONBESEGYu1eZ9CuGNOzrLWS
i15z2z6CctcynjoQoF2ZlYtYU4VEs2QMnBBMm6JI71pGW1CkwymmUnu2VF03g2rqhOybFIwa2BLe
jt9aqFAYtTAvZux9IdTRreeaXD9k6IVqDuPEcgAcahZJgCLLo5wQ3Rq1HTKOtr5nSNqfW0/ZlqDz
+07V2FiQmmPkneyytzFkgQCwoBpAQA1lbmRzdHJlYW0NZW5kb2JqDTY3IDAgb2JqDTIwODQNZW5k
b2JqDTY1IDAgb2JqDTw8DS9UeXBlIC9QYWdlDS9QYXJlbnQgNTMgMCBSDS9SZXNvdXJjZXMgPDwN
L0ZvbnQgPDwNL0YwIDEwIDAgUiANL0YxIDE1IDAgUiANPj4NL1Byb2NTZXQgMiAwIFINPj4NL0Nv
bnRlbnRzIDY2IDAgUg0+Pg1lbmRvYmoNNjkgMCBvYmoNPDwNL0xlbmd0aCA3MCAwIFINL0ZpbHRl
ciAvTFpXRGVjb2RlIA0+Pg1zdHJlYW0NCoAMBBAoEcjOIAaNxkLhkNBAMRmMBcOIeNIdEhyNhAcj
KIDMDSEVAaMhwNBcNocNxoNhdDhAVCIDReRhjDxkIJfH4FLzHA5wVDuIBQLYeNxALRTLzUDRaMhh
JobR5REhnN5eRBBM4FEBcOasVI+LYkMBjXp/QRROKSVKWN4ZPqvAxcMBnJZ/PZ3QKEUzKZbXSyLI
hxbo0MafJ4dThcMY1EoVG47H5CDcNbhvhRhLBhFKvTLHZa/PRQLBBf4Tb7zWLFcxpm7vQjKLjOLt
NgcoMZNGYfh5QIMVjLlj45HpBIogNcXN8Nms5MM9c9Br9HpaVp5vqaPY5JzbxcxhupfaCEYTdPSe
bo6Qzecjh6zCdDSbzdteMNIXVd3Jt6MRlyJI4KbuGySRBkGzCN25ifpi7Qate1anvss6hNIuwjDK
MgyjkMI2BAKQyjnDI7I6IQ6jYNgyvgNwQBqGoZhALgULKHIcC4FLaOqFqyuQGaNOQGqvqwrQQBwx
aNJyBq8rxCQUBmGrTIEGocSIqK4yErizSPB6nhzBzPhpFzwqEOg0I6JI3DpDL0DoEDyDIEA3zHDM
3jgMsVDLE4xjoOT5DSns1Du9Y1jmjz1hAMQ6jmNL0DmOYWjoN4W0PRNF0HO4yzzPY3T7J6joarsj
JguSyBg0LsrmGQcpcvQUDGN42jbDIxjK0k2zZEw3qDVo2jg8g0w+EFHsgMg61lYEyWBDQ3DmMM8v
jFVWjmOlBjDRg3jGNL3wuEA7jTMdOKakzHriz66S7U4cwbMIUDIN9FIPSVFQ+OYXJ/Y4hDeMI5Td
DY5jfQ0719EVBzG94QVbZQ61e99nTeM1jI6OE9vbZcOUBEoyW/TzwVCsbNu5U1SOatE6jQ8lizjN
gxDSNlujzhoQCdOA0jNPryWlYF/VhFGHhA9EL0GN+HTiNI5YNRFH1gOV5pxM02DIMlu2cFmM3DIF
RKdj8H1UtFqZ5e98zdiIyjs+NEDZl2S0GN04Qu0k4uHfOIDqMWWJ6MU6jLmmb2Du4QQwOQ0xFNwz
T2NuqU/BWQO+oyecVdElzoOQ227FKDjGMI4W7DYQDbfI1xRgd/DfyNshBftjYKMTyDXd03oNXo9Y
W+VB8vFXO8/w9xY5U4bS5xutBsmt1PbNEz2xE2XYjoPNbojtFYEOlYTPQdFZ6+XVDd1g3ctV1eU1
X9a8JVwQcjyY6crw+NqxjobVLB7+62oXse0g71jP2HZWVnFbDZa3StDaKRxfodQ5KyeoiplDnQ3H
oaKnFlzB1Et/f23d3LVixn2cYFQnqD3gu+VWG0N60QQN5ZotdOqaw7pkRUHNYgaAQPPQ+9GE60w3
L7Wa7NNhw4IBpWjCdWkB1jQ8YMtRWa21uhofSqA1THS7O/XIyJMSxyOInDszZgzsw0t/fyoMOsNU
5MoCEEgIYIAgp5RuWwkb7S5kUR81ZISRDgJHSSXBVaTTTI5ByWMigLSIkMVUkEIxWwZldK+WEz4O
EwQacUd9JZ40QJuPkzwMx6wyhnXa9tNkNX+JvbeR5ZjN2gmQVavpty9l8L6BA2mO5j1wOIXGd4sq
5lSAxeEqtDCaHJLxTcwRNcEGEudPhJGULKHlMTc27UyC1D5Bhboy5voZQ8J0TytpR8FXEsdlpLIp
0iS0PKWGsVu56G9OhZ4HBubdXUJrDeHUOgdwyhpDPC48jyW2PGc2GEMiImlEdhIpeUDQkyRJmudA
GktYNljBnQlyDEoQobXpGQMco2oPbbOaR1Uj03oqQ2hxlAZpPtAYcRyiUpURynTc2lvyKEMuTPQx
g6pApWu6iWdAGcHqDneRakuXjPHVBsZMR2UM5m6J9hemdDMMZPJ5PWwNkqa4wUmc40eK6yospyi7
BJONAi4paljE46AN5uFCmKnJRS10MJngm6t1q0U2tgZeiCG6KgaIwDGjVGCNCkzDXtGKiCa4hUeD
se55s1pXlkBi1mhEtWuSah3D2tC3ExpsDg8qKobIzmAJEQENZW5kc3RyZWFtDWVuZG9iag03MCAw
IG9iag0xNDkyDWVuZG9iag02OCAwIG9iag08PA0vVHlwZSAvUGFnZQ0vUGFyZW50IDUzIDAgUg0v
UmVzb3VyY2VzIDw8DS9Gb250IDw8DS9GMCAxMCAwIFIgDS9GMSAxNSAwIFIgDT4+DS9Qcm9jU2V0
IDIgMCBSDT4+DS9Db250ZW50cyA2OSAwIFINPj4NZW5kb2JqDTczIDAgb2JqDTw8DS9MZW5ndGgg
NzQgMCBSDS9GaWx0ZXIgL0xaV0RlY29kZSANPj4Nc3RyZWFtDQqADAQQKBHIziAGjcZC4ZDQQDEa
DcXDMbQ8aQ4YC4cxU5GUQGYGkIqA0ZDgaC4bQ4bjQbC6HCAqEQGi8jDGHjIQTCQQKYGOBzkqHcQC
gWw8cCAWimYGoGi0ZDCTw2kDYZDMXDeKzAiCCaQIY1YczidA2MjAYjKbT2kWUZ1+gUIUTkrG86Gk
3QczG85CA6Gg0nMQGEx3U3m4dTkhmgwmk5G0wm4QEeOmU3HM4Y8WCArGkxx7E4vG48QEYywY6nPC
5nHmSlFSmC0cC4YxUai4a2KY1wjQLY7OgTugT6eUGhxTW0yBU6FjCj1rdV6wbidi4YVQb8G19QcD
Ec2+hkc3nbSm69YAlmU2GwynnMk316XVG4yZE5GE2mzOGgXceyCAahyqysKAra2Bi661OGuAhsKM
Y2NONLCv4IqRoUhiHBsHLYwuhaMKunCOo+kKRogqMLpWFwcOamKmrKGIYBq7AWrK5kDuIFAhDCOY
yvmwq+DQjy8o6M43rsg7VsC9MfSAwQ6MAN4zBAjoxr0MjMr6jwhDeMI5PmxQ5v4FqFKQhsPQGgbq
RfGC1Rk6iGxquAyDKOjSjau0dx8MI6SUEA4DkN44DeOYwjYEA5jQN46jY+YxDK+MutKMoxDyEC/t
UOE+vDHYXKBH4QSzLbWKWpqFhyHLbuxBKhi4GVWP4jKqqg7AUS/UTkzIjczLKGwbRUn02OYrMbDD
S8/DtQdKMAywyjGNIzM5QY2UnKb5DSwg3TvHspjaOD8MezoQUkEAnLpZtnjdJoQDvao0SRQkr1dM
aTzE50ZhrXrshgGU1RtbU6joNrKXQx040oyFp2uwcIMhdS+z28i6s6ObMrtBo6jJIs937auAXPWj
XP6pyT1w51fhgGcYxaqjvBRi45jG08dPmu0fL+EEqPgwL5YywuL2tZM5I+vWG5mvua5uOVNphTtP
y5MFSVM3DhZXVdW1qhgZ1itVZ3hkMy3o6iz6jfC2pfG04zmxq7TzhUkNRZFCjqMQ1WXPQ6Dfdud2
pn1C6BIOhsgKQyjPRO1x6LIWa5W9gwJNCw5RNqTZXikHYuu8fUCj2Zx1hLCsBVjauvI/PoYGouBQ
MYuKVJ4QcDwY2cKyAshB0yzhAIYXCMFwpU30Yb8TeTcK3X4aBzsrhOprDcLh0V9dJ03UBT1NHL5u
8r09LWm1EpyNahVGp1YGUwLKGUM1RsDq5WwAwjqvq9WrSe7SiMo4jqxiPDmOox3YNo34vZwY3YM2
Dk78jTi0zlQBgjVXxZT/ndJgXBtCdQ3QBdW9ZJgaQ7LVDSGVJyUAwrgMeGsECh1FMYW0ZcNyky9M
5hUlBaqyW4hzDSxdLcG31MeOQvFrxuUZvEcevkGhaUbPWaYfNZx8jAMIg4oIOT8G7mUfwiCE63Q3
LfYYGgzMK34p9DKeJc4IIuo5bYk9KyP4CMjNyr87i+2pQPKGpiDMMnOs2ShEQJAQwQBBMGzk+cRH
sKhY+9tUqp0EPfaqx9lMCmxn/fS/J1zsH1M6aOYAv7+EdwEXnDxNAMYhQLTayZlaVyOh1PkaVpIV
Efo6BAxpf7AZInzWmz1hT6kQJxDKwCPrd1GSrZ5BpzsZ4DFlBocyH6wS4BpW25hmTCw5QacsuGPy
oGCy8Dcwhay6V1qUXREdyoZ5XggTisyOQblHGqhwyBMkmXGHVBnA4KknjmFtfS/mLAIDHKTl2ZRI
JnZlp8T8Z1HaRTASkTiXtYa3FnhiPUCB14dz9qiTE12NDwkZlVh+bOdxcJUM1UwoBQShFDLQBAw9
cBHlpv4DaY5OZ83XtoTwZAvpk57GFL6+oMzaEwURnS8GA6rF7vDeUUN6wZQzBmbpBgjwZE8kegqX
5JyXGcSkPUHOGD+k+GlQgzIwAZQ8JzlKfOYCZmSr6ouDZN5Q0gggSG/2Vb65VTQaXH+AS4H4KdoO
n5PoaalmjR2aVY7gUdByPEp6EJqmEl3kxTxX5/1gvHgQ2UuAcA6hyfwY9urd04nqDPUs+b632zND
oHmh7H6dMigNYsij5mTEXZWEKFVUC91NSxXJ1Z4DxByPJZRxCoi0EEVy8gGdP4GMnjcXGolRmE2D
XGeINqjC9ouMydxUtozXm9NobanhXQQXWN+f2QtxTjPaKobIioLQam1uybsh50buozkyT4FDpoZB
nWuGR1KEiRkBDWVuZHN0cmVhbQ1lbmRvYmoNNzQgMCBvYmoNMTYyNA1lbmRvYmoNNzEgMCBvYmoN
PDwNL1R5cGUgL1BhZ2UNL1BhcmVudCA3MiAwIFINL1Jlc291cmNlcyA8PA0vRm9udCA8PA0vRjAg
MTAgMCBSIA0vRjEgMTUgMCBSIA0+Pg0vUHJvY1NldCAyIDAgUg0+Pg0vQ29udGVudHMgNzMgMCBS
DT4+DWVuZG9iag03NiAwIG9iag08PA0vTGVuZ3RoIDc3IDAgUg0vRmlsdGVyIC9MWldEZWNvZGUg
DT4+DXN0cmVhbQ0KgBCKgNGQ4GguGw0EA3Gg2F0KEBUIgNGAgisVORnEANF5GGIgGIyEERM0UkZU
McWk53EAoFsgHIgFopiJqBotG41F0GmUNFw1G0nIggjsVGIzFw5kUkBooL9PqFRqVTqk0Kk2GY4h
EKFoyg45oMRoYtGAuGAwG0xiMpslmkIzlctKRvMRlOR0EBkMpWFwgIxyNN2OZvN1WmwtGYyh8yGM
OoFCmVls9pk9syVvuIoIJzwZjNJhOhlEBTMpjORlOhhOR5EBvMwgOho0RCN+qMmGBpFgcBANZW5k
c3RyZWFtDWVuZG9iag03NyAwIG9iag0yMTINZW5kb2JqDTc1IDAgb2JqDTw8DS9UeXBlIC9QYWdl
DS9QYXJlbnQgNzIgMCBSDS9SZXNvdXJjZXMgPDwNL0ZvbnQgPDwNL0YwIDEwIDAgUiANL0YxIDE1
IDAgUiANPj4NL1Byb2NTZXQgMiAwIFINPj4NL0NvbnRlbnRzIDc2IDAgUg0+Pg1lbmRvYmoNMTAg
MCBvYmoNPDwNL1R5cGUgL0ZvbnQNL1N1YnR5cGUgL1RydWVUeXBlDS9OYW1lIC9GMA0vQmFzZUZv
bnQgL1RpbWVzTmV3Um9tYW4NL0ZpcnN0Q2hhciAzMg0vTGFzdENoYXIgMjU1DS9XaWR0aHMgWyAy
NjAgMzIwIDQwMCA1MDAgNTAwIDg0MCA3NjAgMTYwIDM0MCAzNDAgNTAwIDU2MCAyNjAgMzQwIDI2
MCAyODAgDTUwMCA1MDAgNTAwIDUwMCA1MDAgNTAwIDUwMCA1MDAgNTAwIDUwMCAyODAgMjYwIDU2
MCA1NjAgNTYwIDQyMCANOTAwIDcwMCA2NjAgNjYwIDcyMCA2MjAgNTQwIDcyMCA3MjAgMzQwIDM4
MCA3MDAgNjAwIDg4MCA3MjAgNzIwIA01NjAgNzIwIDY2MCA1NjAgNjIwIDcyMCA3MjAgOTIwIDcy
MCA3MjAgNjAwIDM0MCAyODAgMzQwIDQ2MCA1MDAgDTMyMCA0NDAgNDgwIDQ0MCA1MDAgNDQwIDMw
MCA1MDAgNDgwIDI0MCAyNDAgNTAwIDI0MCA3NDAgNDgwIDUyMCANNTAwIDUwMCAzNDAgMzgwIDMw
MCA1MDAgNDgwIDcyMCA0ODAgNDYwIDQ0MCA0ODAgMjAwIDQ4MCA1NDAgNzgwIA01NjAgNzgwIDU2
MCA1NjAgNTYwIDU2MCA1NjAgNTYwIDU2MCA1NjAgNTYwIDU2MCA1NjAgNzgwIDU2MCA3ODAgDTc4
MCA1NjAgNTYwIDU2MCA1NjAgNTYwIDU2MCA1NjAgNTYwIDU2MCA1NjAgNTYwIDU2MCA3ODAgNTYw
IDU2MCANMjYwIDMyMCA1MDAgNTAwIDUwMCA1MDAgMjAwIDUwMCAzMjAgNzYwIDI2MCA0ODAgNTYw
IDM0MCA3NjAgNTAwIA0zODAgNTQwIDMwMCAyODAgMzAwIDU4MCA0NDAgMjYwIDMwMCAzMDAgMzIw
IDQ4MCA3NjAgNzYwIDc2MCA0MDAgDTcwMCA3MDAgNzAwIDcwMCA3MDAgNzAwIDkwMCA2NjAgNjIw
IDYyMCA2MjAgNjIwIDM0MCAzNDAgMzQwIDM0MCANNzIwIDcyMCA3MjAgNzIwIDcyMCA3MjAgNzIw
IDU2MCA3MjAgNzIwIDcyMCA3MjAgNzIwIDcyMCA1NjAgNTIwIA00NDAgNDQwIDQ0MCA0NDAgNDQw
IDQ0MCA2NjAgNDQwIDQ0MCA0NDAgNDQwIDQ0MCAyNDAgMjQwIDI0MCAyNDAgDTUwMCA0ODAgNTIw
IDUyMCA1MjAgNTIwIDUyMCA1NDAgNTAwIDUwMCA1MDAgNTAwIDUwMCA0NjAgNTAwIDQ2MCANXQ0v
RW5jb2RpbmcgL1dpbkFuc2lFbmNvZGluZw0vRm9udERlc2NyaXB0b3IgMTEgMCBSDT4+DWVuZG9i
ag0xMSAwIG9iag08PA0vVHlwZSAvRm9udERlc2NyaXB0b3INL0ZvbnROYW1lIC9UaW1lc05ld1Jv
bWFuDS9GbGFncyAzNA0vRm9udEJCb3ggWyAtMjUwIC0yMTYgMTEwNCAxMDQwIF0NL01pc3NpbmdX
aWR0aCAzNDANL1N0ZW1WIDczDS9TdGVtSCA3Mw0vSXRhbGljQW5nbGUgMA0vQ2FwSGVpZ2h0IDg5
MQ0vWEhlaWdodCA0NDYNL0FzY2VudCA4OTENL0Rlc2NlbnQgLTIxNg0vTGVhZGluZyAxNDkNL01h
eFdpZHRoIDkyMA0vQXZnV2lkdGggNDAxDT4+DWVuZG9iag0xNSAwIG9iag08PA0vVHlwZSAvRm9u
dA0vU3VidHlwZSAvVHJ1ZVR5cGUNL05hbWUgL0YxDS9CYXNlRm9udCAvQ291cmllck5ldw0vRmly
c3RDaGFyIDMyDS9MYXN0Q2hhciAyNTUNL1dpZHRocyBbIDYwMCA2MDAgNjAwIDYwMCA2MDAgNjAw
IDYwMCA2MDAgNjAwIDYwMCA2MDAgNjAwIDYwMCA2MDAgNjAwIDYwMCANNjAwIDYwMCA2MDAgNjAw
IDYwMCA2MDAgNjAwIDYwMCA2MDAgNjAwIDYwMCA2MDAgNjAwIDYwMCA2MDAgNjAwIA02MDAgNjAw
IDYwMCA2MDAgNjAwIDYwMCA2MDAgNjAwIDYwMCA2MDAgNjAwIDYwMCA2MDAgNjAwIDYwMCA2MDAg
DTYwMCA2MDAgNjAwIDYwMCA2MDAgNjAwIDYwMCA2MDAgNjAwIDYwMCA2MDAgNjAwIDYwMCA2MDAg
NjAwIDYwMCANNjAwIDYwMCA2MDAgNjAwIDYwMCA2MDAgNjAwIDYwMCA2MDAgNjAwIDYwMCA2MDAg
NjAwIDYwMCA2MDAgNjAwIA02MDAgNjAwIDYwMCA2MDAgNjAwIDYwMCA2MDAgNjAwIDYwMCA2MDAg
NjAwIDYwMCA2MDAgNjAwIDYwMCA2MDAgDTYwMCA2MDAgNjAwIDYwMCA2MDAgNjAwIDYwMCA2MDAg
NjAwIDYwMCA2MDAgNjAwIDYwMCA2MDAgNjAwIDYwMCANNjAwIDYwMCA2MDAgNjAwIDYwMCA2MDAg
NjAwIDYwMCA2MDAgNjAwIDYwMCA2MDAgNjAwIDYwMCA2MDAgNjAwIA02MDAgNjAwIDYwMCA2MDAg
NjAwIDYwMCA2MDAgNjAwIDYwMCA2MDAgNjAwIDYwMCA2MDAgNjAwIDYwMCA2MDAgDTYwMCA2MDAg
NjAwIDYwMCA2MDAgNjAwIDYwMCA2MDAgNjAwIDYwMCA2MDAgNjAwIDYwMCA2MDAgNjAwIDYwMCAN
NjAwIDYwMCA2MDAgNjAwIDYwMCA2MDAgNjAwIDYwMCA2MDAgNjAwIDYwMCA2MDAgNjAwIDYwMCA2
MDAgNjAwIA02MDAgNjAwIDYwMCA2MDAgNjAwIDYwMCA2MDAgNjAwIDYwMCA2MDAgNjAwIDYwMCA2
MDAgNjAwIDYwMCA2MDAgDTYwMCA2MDAgNjAwIDYwMCA2MDAgNjAwIDYwMCA2MDAgNjAwIDYwMCA2
MDAgNjAwIDYwMCA2MDAgNjAwIDYwMCANNjAwIDYwMCA2MDAgNjAwIDYwMCA2MDAgNjAwIDYwMCA2
MDAgNjAwIDYwMCA2MDAgNjAwIDYwMCA2MDAgNjAwIA1dDS9FbmNvZGluZyAvV2luQW5zaUVuY29k
aW5nDS9Gb250RGVzY3JpcHRvciAxNiAwIFINPj4NZW5kb2JqDTE2IDAgb2JqDTw8DS9UeXBlIC9G
b250RGVzY3JpcHRvcg0vRm9udE5hbWUgL0NvdXJpZXJOZXcNL0ZsYWdzIDM0DS9Gb250QkJveCBb
IC0yNTAgLTMwMCA3MjAgMTAwMCBdDS9NaXNzaW5nV2lkdGggNjAwDS9TdGVtViAxMDkNL1N0ZW1I
IDEwOQ0vSXRhbGljQW5nbGUgMA0vQ2FwSGVpZ2h0IDgzMw0vWEhlaWdodCA0MTcNL0FzY2VudCA4
MzMNL0Rlc2NlbnQgLTMwMA0vTGVhZGluZyAxMzMNL01heFdpZHRoIDYwMA0vQXZnV2lkdGggNjAw
DT4+DWVuZG9iag0zNiAwIG9iag08PA0vVHlwZSAvRm9udA0vU3VidHlwZSAvVHJ1ZVR5cGUNL05h
bWUgL0YyDS9CYXNlRm9udCAvVGltZXNOZXdSb21hbixJdGFsaWMNL0ZpcnN0Q2hhciAzMg0vTGFz
dENoYXIgMjU1DS9XaWR0aHMgWyAyNTggMjkzIDM5NiA1MTcgNTAwIDc3NSA3MjQgMjI0IDMxMCAz
MjcgNTAwIDY3MiAyNTggMzI3IDI1OCAyNzUgDTUwMCA1MDAgNTAwIDUwMCA1MDAgNTAwIDUwMCA1
MDAgNTAwIDUwMCAzMjcgMzI3IDY3MiA2NzIgNjcyIDUwMCANOTEzIDYwMyA2MDMgNjcyIDcyNCA2
MDMgNTg2IDcyNCA3MjQgMzI3IDQ0OCA2NzIgNTUxIDgyNyA2NzIgNzI0IA01ODYgNzI0IDYwMyA1
MDAgNTUxIDcyNCA1ODYgODEwIDYwMyA1MzQgNTUxIDM5NiAyNzUgMzk2IDQxMyA1MDAgDTM0NCA1
MDAgNTAwIDQ0OCA1MDAgNDQ4IDI3NSA1MDAgNTAwIDI3NSAyNzUgNDQ4IDI3NSA3MjQgNTAwIDUw
MCANNTAwIDUwMCAzOTYgMzk2IDI3NSA1MDAgNDQ4IDYzNyA0NDggNDQ4IDM5NiAzOTYgMjc1IDM5
NiA1MzQgNzc1IA02NzIgNzc1IDY3MiA2NzIgNjcyIDY3MiA2NzIgNjcyIDY3MiA2NzIgNjcyIDY3
MiA2NzIgNzc1IDY3MiA3NzUgDTc3NSA2NzIgNjcyIDY3MiA2NzIgNjcyIDY3MiA2NzIgNjcyIDY3
MiA2NzIgNjcyIDY3MiA3NzUgNjcyIDY3MiANMjU4IDM2MiA1MDAgNTAwIDQ4MiA1MDAgMjc1IDUw
MCAyOTMgNzI0IDI3NSA1MDAgNjcyIDMyNyA3NzUgNTAwIA0zOTYgNTUxIDMxMCAyOTMgMzQ0IDU2
OCA1MTcgMjU4IDMyNyAyOTMgMzEwIDUwMCA3NTggNzU4IDc1OCA1MDAgDTYwMyA2MDMgNjAzIDYw
MyA2MDMgNjAzIDg5NiA2NzIgNjAzIDYwMyA2MDMgNjAzIDMyNyAzMjcgMzI3IDMyNyANNzI0IDY3
MiA3MjQgNzI0IDcyNCA3MjQgNzI0IDY3MiA3MjQgNzI0IDcyNCA3MjQgNzI0IDUzNCA2MDMgNTAw
IA01MDAgNTAwIDUwMCA1MDAgNTAwIDUwMCA2NzIgNDQ4IDQ0OCA0NDggNDQ4IDQ0OCAyNzUgMjc1
IDI3NSAyNzUgDTUwMCA1MDAgNTAwIDUwMCA1MDAgNTAwIDUwMCA1NTEgNTAwIDUwMCA1MDAgNTAw
IDUwMCA0NDggNTAwIDQ0OCANXQ0vRW5jb2RpbmcgL1dpbkFuc2lFbmNvZGluZw0vRm9udERlc2Ny
aXB0b3IgMzcgMCBSDT4+DWVuZG9iag0zNyAwIG9iag08PA0vVHlwZSAvRm9udERlc2NyaXB0b3IN
L0ZvbnROYW1lIC9UaW1lc05ld1JvbWFuLEl0YWxpYw0vRmxhZ3MgOTgNL0ZvbnRCQm94IFsgLTI1
MCAtMjE2IDEwOTcgMTA0MCBdDS9NaXNzaW5nV2lkdGggMzk3DS9TdGVtViA3Mw0vU3RlbUggNzMN
L0l0YWxpY0FuZ2xlIC0xMQ0vQ2FwSGVpZ2h0IDg5MQ0vWEhlaWdodCA0NDYNL0FzY2VudCA4OTEN
L0Rlc2NlbnQgLTIxNg0vTGVhZGluZyAxNDkNL01heFdpZHRoIDkxNA0vQXZnV2lkdGggNDAyDT4+
DWVuZG9iag0yIDAgb2JqDVsgL1BERiAvVGV4dCAvSW1hZ2VCICBdDWVuZG9iag01IDAgb2JqDTw8
DS9LaWRzIFs0IDAgUiAxNCAwIFIgMTkgMCBSIDIyIDAgUiAyNSAwIFIgMjggMCBSIF0NL0NvdW50
IDYNL1R5cGUgL1BhZ2VzDS9QYXJlbnQgNzggMCBSDT4+DWVuZG9iag0zMiAwIG9iag08PA0vS2lk
cyBbMzEgMCBSIDM1IDAgUiA0MCAwIFIgNDMgMCBSIDQ2IDAgUiA0OSAwIFIgXQ0vQ291bnQgNg0v
VHlwZSAvUGFnZXMNL1BhcmVudCA3OCAwIFINPj4NZW5kb2JqDTUzIDAgb2JqDTw8DS9LaWRzIFs1
MiAwIFIgNTYgMCBSIDU5IDAgUiA2MiAwIFIgNjUgMCBSIDY4IDAgUiBdDS9Db3VudCA2DS9UeXBl
IC9QYWdlcw0vUGFyZW50IDc4IDAgUg0+Pg1lbmRvYmoNNzIgMCBvYmoNPDwNL0tpZHMgWzcxIDAg
UiA3NSAwIFIgXQ0vQ291bnQgMg0vVHlwZSAvUGFnZXMNL1BhcmVudCA3OCAwIFINPj4NZW5kb2Jq
DTc4IDAgb2JqDTw8DS9LaWRzIFs1IDAgUiAzMiAwIFIgNTMgMCBSIDcyIDAgUiBdDS9Db3VudCAy
MA0vVHlwZSAvUGFnZXMNL01lZGlhQm94IFsgMCAwIDYxMiA3OTIgXQ0+Pg1lbmRvYmoNMSAwIG9i
ag08PA0vQ3JlYXRvciAoV29yZFBlcmZlY3QpDS9DcmVhdGlvbkRhdGUgKEQ6MTk5OTExMTAxNzA5
MTkpDS9UaXRsZSAoKQ0vQXV0aG9yICgpDS9Qcm9kdWNlciAoQWNyb2JhdCBQREZXcml0ZXIgMy4w
MmI1IGZvciBXaW5kb3dzIE5UKQ0vS2V5d29yZHMgKCkNL1N1YmplY3QgKCkNPj4NZW5kb2JqDTMg
MCBvYmoNPDwNL1BhZ2VzIDc4IDAgUg0vVHlwZSAvQ2F0YWxvZw0+Pg1lbmRvYmoNeHJlZg0wIDc5
DTAwMDAwMDAwMDAgNjU1MzUgZiANMDAwMDA1MTA2NiAwMDAwMCBuIA0wMDAwMDUwNTEwIDAwMDAw
IG4gDTAwMDAwNTEyNDEgMDAwMDAgbiANMDAwMDAwNjUxMyAwMDAwMCBuIA0wMDAwMDUwNTQ5IDAw
MDAwIG4gDTAwMDAwMDAxNTkgMDAwMDAgbiANMDAwMDAwNTU4MSAwMDAwMCBuIA0wMDAwMDAwMDE5
IDAwMDAwIG4gDTAwMDAwMDAxNDEgMDAwMDAgbiANMDAwMDA0NjQ1MiAwMDAwMCBuIA0wMDAwMDQ3
NTQwIDAwMDAwIG4gDTAwMDAwMDU2MDEgMDAwMDAgbiANMDAwMDAwNjQ5MyAwMDAwMCBuIA0wMDAw
MDA4MjA3IDAwMDAwIG4gDTAwMDAwNDc4MDEgMDAwMDAgbiANMDAwMDA0ODg4NiAwMDAwMCBuIA0w
MDAwMDA2NjcxIDAwMDAwIG4gDTAwMDAwMDgxODYgMDAwMDAgbiANMDAwMDAxMDU2MiAwMDAwMCBu
IA0wMDAwMDA4MzQwIDAwMDAwIG4gDTAwMDAwMTA1NDEgMDAwMDAgbiANMDAwMDAxMTQ0MiAwMDAw
MCBuIA0wMDAwMDEwNjk1IDAwMDAwIG4gDTAwMDAwMTE0MjIgMDAwMDAgbiANMDAwMDAxMzg5NyAw
MDAwMCBuIA0wMDAwMDExNTc1IDAwMDAwIG4gDTAwMDAwMTM4NzYgMDAwMDAgbiANMDAwMDAxNjAz
NyAwMDAwMCBuIA0wMDAwMDE0MDMwIDAwMDAwIG4gDTAwMDAwMTYwMTYgMDAwMDAgbiANMDAwMDAx
ODU0MiAwMDAwMCBuIA0wMDAwMDUwNjU3IDAwMDAwIG4gDTAwMDAwMTYxNzAgMDAwMDAgbiANMDAw
MDAxODUyMSAwMDAwMCBuIA0wMDAwMDIwODQ2IDAwMDAwIG4gDTAwMDAwNDkxNDUgMDAwMDAgbiAN
MDAwMDA1MDI0MCAwMDAwMCBuIA0wMDAwMDE4Njc2IDAwMDAwIG4gDTAwMDAwMjA4MjUgMDAwMDAg
biANMDAwMDAyMzEzOCAwMDAwMCBuIA0wMDAwMDIwOTkyIDAwMDAwIG4gDTAwMDAwMjMxMTcgMDAw
MDAgbiANMDAwMDAyNjE5OSAwMDAwMCBuIA0wMDAwMDIzMjcyIDAwMDAwIG4gDTAwMDAwMjYxNzgg
MDAwMDAgbiANMDAwMDAyOTAxNCAwMDAwMCBuIA0wMDAwMDI2MzMzIDAwMDAwIG4gDTAwMDAwMjg5
OTMgMDAwMDAgbiANMDAwMDAzMTUwNiAwMDAwMCBuIA0wMDAwMDI5MTQ4IDAwMDAwIG4gDTAwMDAw
MzE0ODUgMDAwMDAgbiANMDAwMDAzMzc0NSAwMDAwMCBuIA0wMDAwMDUwNzY3IDAwMDAwIG4gDTAw
MDAwMzE2NDAgMDAwMDAgbiANMDAwMDAzMzcyNCAwMDAwMCBuIA0wMDAwMDM1NzkwIDAwMDAwIG4g
DTAwMDAwMzM4NzkgMDAwMDAgbiANMDAwMDAzNTc2OSAwMDAwMCBuIA0wMDAwMDM3ODg2IDAwMDAw
IG4gDTAwMDAwMzU5MjQgMDAwMDAgbiANMDAwMDAzNzg2NSAwMDAwMCBuIA0wMDAwMDM5OTgzIDAw
MDAwIG4gDTAwMDAwMzgwMjAgMDAwMDAgbiANMDAwMDAzOTk2MiAwMDAwMCBuIA0wMDAwMDQyMjk4
IDAwMDAwIG4gDTAwMDAwNDAxMTcgMDAwMDAgbiANMDAwMDA0MjI3NyAwMDAwMCBuIA0wMDAwMDQ0
MDIxIDAwMDAwIG4gDTAwMDAwNDI0MzIgMDAwMDAgbiANMDAwMDA0NDAwMCAwMDAwMCBuIA0wMDAw
MDQ1ODc2IDAwMDAwIG4gDTAwMDAwNTA4NzcgMDAwMDAgbiANMDAwMDA0NDE1NSAwMDAwMCBuIA0w
MDAwMDQ1ODU1IDAwMDAwIG4gDTAwMDAwNDYzMTggMDAwMDAgbiANMDAwMDA0NjAxMCAwMDAwMCBu
IA0wMDAwMDQ2Mjk4IDAwMDAwIG4gDTAwMDAwNTA5NTkgMDAwMDAgbiANdHJhaWxlcg08PA0vU2l6
ZSA3OQ0vUm9vdCAzIDAgUg0vSW5mbyAxIDAgUg0vSUQgWzw0NWRkOTMyNGFiOWJkM2NmYTIwYzA4
MDMxODlhMDQ1ZT48NDVkZDkzMjRhYjliZDNjZmEyMGMwODAzMTg5YTA0NWU+XQ0+Pg1zdGFydHhy
ZWYNNTEyOTENJSVFT0YN

------_=_NextPart_000_01BF2FCB.3981520A--


Received: from dfssl.exchange.microsoft.com (dfssl.exchange.microsoft.com [131.107.88.59]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id QAA23723 for <[e-mail]>; Mon, 15 Nov 1999 16:02:18 -0800 (PST)
Received: by dfssl with Internet Mail Service (5.5.2650.21) id <W8XXLB51>; Mon, 15 Nov 1999 16:03:10 -0800
Message-ID: <[e-mail]>
From: "Trevor Freeman (Exchange)" <[e-mail]>
To: "Pkix List (E-mail)" <[e-mail]>
Subject: Associating symmetric algorithms with a public key
Date: Mon, 15 Nov 1999 16:03:10 -0800
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01BF2FC5.F81EE3E0"

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


Received: from po1.bbn.com (PO1.BBN.COM [192.1.50.38]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id PAA23061 for <[e-mail]>; Mon, 15 Nov 1999 15:26:32 -0800 (PST)
Received: from [171.78.30.108] (comsecpb.bbn.com [171.78.30.108]) by po1.bbn.com (8.9.1/8.9.1) with ESMTP id SAA01451; Mon, 15 Nov 1999 18:27:04 -0500 (EST)
Mime-Version: 1.0
X-Sender: [e-mail]
Message-Id: <v04220800b456404dde58@[171.78.30.108]>
In-Reply-To: <047e01bf2e42$3113be80$[e-mail]>
References: <[e-mail]> <047e01bf2e42$3113be80$[e-mail]>
Date: Mon, 15 Nov 1999 18:27:34 -0500
To: "Todd Glassey @ GMTsw" <[e-mail]>
From: Stephen Kent <[e-mail]>
Subject: Re: Timestamp: 04: comments
Cc: <[e-mail]>
Content-Type: text/plain; charset="us-ascii" ; format="flowed"

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


Received: from eastwood.aldigital.algroup.co.uk (eastwood.aldigital.algroup.co.uk [194.128.162.193]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id OAA22285 for <[e-mail]>; Mon, 15 Nov 1999 14:34:25 -0800 (PST)
Received: from freeby.ben.algroup.co.uk (freeby.ben.algroup.co.uk [193.133.15.6]) by eastwood.aldigital.algroup.co.uk (8.8.8/8.6.12) with ESMTP id WAA14335; Mon, 15 Nov 1999 22:35:23 GMT
Received: from algroup.co.uk (naughty.ben.algroup.co.uk [193.133.15.107]) by freeby.ben.algroup.co.uk (8.6.12/8.6.12) with ESMTP id WAA25398; Mon, 15 Nov 1999 22:35:49 GMT
Message-ID: <[e-mail]>
Date: Mon, 15 Nov 1999 22:35:23 +0000
From: Ben Laurie <[e-mail]>
Organization: A.L. Group plc
X-Mailer: Mozilla 4.7 [en] (WinNT; I)
MIME-Version: 1.0
To: [e-mail]
CC: [e-mail]
Subject: Re: Extension Order
References: <[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Peter Gutmann wrote:
> 
> "Scott, Greg" <[e-mail]> 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


Received: from mail.student.auckland.ac.nz (mail.student.auckland.ac.nz [130.216.35.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id OAA22051 for <[e-mail]>; Mon, 15 Nov 1999 14:29:40 -0800 (PST)
Received: from cs26.cs.auckland.ac.nz ([e-mail] [130.216.36.9]) by mail.student.auckland.ac.nz (8.9.3/8.8.6/cs-master) with SMTP id LAA16196 for <[e-mail]>; Tue, 16 Nov 1999 11:30:52 +1300 (NZDT) (sender [e-mail])
Received: by cs26.cs.auckland.ac.nz (relaymail v0.9) id <94270505222001>; Tue, 16 Nov 1999 11:30:52 (NZDT)
From: [e-mail] (Peter Gutmann)
To: [e-mail]
Subject: Re:  Extension Order
Sender: [e-mail]
Reply-To: [e-mail]
X-Charge-To: pgut001
X-Authenticated: relaymail v0.9 on cs26.cs.auckland.ac.nz
Date: Tue, 16 Nov 1999 11:30:52 (NZDT)
Message-ID: <[e-mail]>

"Scott, Greg" <[e-mail]> 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.



Received: from rbhub101.chamb.disa.mil (rbhub101.chamb.disa.mil [209.22.120.24]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id MAA20652 for <[e-mail]>; Mon, 15 Nov 1999 12:43:29 -0800 (PST)
Received: by rbhub101.chamb.disa.mil with Internet Mail Service (5.5.2650.10) id <W8QF7QKJ>; Mon, 15 Nov 1999 15:44:29 -0500
Message-ID: <[e-mail]>
From: "Scott, Greg" <[e-mail]>
To: "'[e-mail]'" <[e-mail]>
Subject:  Extension Order
Date: Mon, 15 Nov 1999 15:44:28 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.10)
Content-Type: text/plain; charset="iso-8859-1"

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/


Received: from stingray.missi.ncsc.mil (stingray.missi.ncsc.mil [144.51.50.20]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id HAA16576 for <[e-mail]>; Mon, 15 Nov 1999 07:40:22 -0800 (PST)
Received: from stingray.missi.ncsc.mil (root@localhost) by stingray.missi.ncsc.mil with ESMTP id KAA22118 for <[e-mail]>; Mon, 15 Nov 1999 10:41:56 -0500 (EST)
Received: from missi.ncsc.mil (depot.missi.ncsc.mil [144.51.60.1]) by stingray.missi.ncsc.mil with ESMTP id KAA22109 for <[e-mail]>; Mon, 15 Nov 1999 10:41:55 -0500 (EST)
Received: from ara.missi.ncsc.mil (ara.missi.ncsc.mil [144.51.58.9]) by missi.ncsc.mil (8.8.8/8.8.8) with ESMTP id KAA03818 for <[e-mail]>; Mon, 15 Nov 1999 10:41:13 -0500 (EST)
Received: from ara.missi.ncsc.mil (ara.missi.ncsc.mil [144.51.58.9]) by ara.missi.ncsc.mil (8.9.1b+Sun/8.9.1) with SMTP id KAA14127 for <[e-mail]>; Mon, 15 Nov 1999 10:37:10 -0500 (EST)
Message-Id: <[e-mail]>
Date: Mon, 15 Nov 1999 10:37:10 -0500 (EST)
From: "David P. Kemp" <[e-mail]>
Reply-To: "David P. Kemp" <[e-mail]>
Subject: Re: dnQualifier
To: [e-mail]
MIME-Version: 1.0
Content-Type: TEXT/plain; charset=us-ascii
Content-MD5: SAjDAETjCeP4QBFzfYDxwg==
X-Mailer: dtmail 1.3.0 CDE Version 1.3 SunOS 5.7 sun4u sparc

> Date: Wed, 10 Nov 1999 13:36:52 -0500
> From: schaen <[e-mail]>
> 
> 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" <[e-mail]>
> 
> 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.



Received: from exchsvr1.entegrity.com (exchsvr1.entegrity.com [207.215.19.3]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id HAA15962 for <[e-mail]>; Mon, 15 Nov 1999 07:15:47 -0800 (PST)
Received: from DHARTER (d5-s58-90-telehouse.mistral.co.uk [195.184.228.90]) by exchsvr1.entegrity.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2448.0) id WZB3FZSD; Mon, 15 Nov 1999 07:21:09 -0800
Received: by DHARTER with Microsoft Mail id <01BF2F7C.3A3B2CB0@DHARTER>; Mon, 15 Nov 1999 15:15:18 -0000
Message-ID: <01BF2F7C.3A3B2CB0@DHARTER>
From: Darren Harter <[e-mail]>
To: "'[e-mail]'" <[e-mail]>, "[e-mail]" <[e-mail]>
Subject: RE: ASN.1 question to PKIHeader in CMP (RFC 2510) 
Date: Mon, 15 Nov 1999 15:15:10 -0000
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by ns.secondary.com id HAA15963

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: [phone]
Fax: [phone]
Cell: [phone]
Mail: <mailto:[e-mail]>
Web: <http://www.entegrity.com>


-----Original Message-----
From:	Anette Byskov [SMTP:[e-mail]]
Sent:	15 November 1999 14:31
To:	[e-mail]
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:  [phone]                Klostergade 28
Fax:    [phone]                DK-8000 Aarhus C
http://www.cryptomathic.dk/            Denmark


Received: from bbmail1-out.unisys.com (bbmail1-out.unisys.com [192.63.108.40]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id GAA15390 for <[e-mail]>; Mon, 15 Nov 1999 06:57:17 -0800 (PST)
Received: from trsvrbk.tr.unisys.com (trsvrbk.tr.unisys.com [192.63.236.1]) by bbmail1-out.unisys.com (8.9.3/8.9.3) with ESMTP id OAA01140; Mon, 15 Nov 1999 14:57:15 GMT
Received: from US-TR-EXCH-1.tr.unisys.com by trsvrbk.tr.unisys.com (8.8.5/8.8.5) id OAA29660 ; Mon, 15 Nov 1999 14:58:39 GMT
Received: by us-tr-exch-1.tr.unisys.com with Internet Mail Service (5.5.2650.21) id <VZZJ7Y9K>; Mon, 15 Nov 1999 09:58:24 -0500
Message-ID: <[e-mail]>
From: "Salter, Thomas A" <[e-mail]>
To: [e-mail], [e-mail]
Subject: RE: ASN.1 question to PKIHeader in CMP (RFC 2510) 
Date: Mon, 15 Nov 1999 09:58:24 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain; charset="iso-8859-1"

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:[e-mail]]
 > Sent: Monday, November 15, 1999 9:31 AM
 > To: [e-mail]
 > 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:  [phone]                Klostergade 28
 > Fax:    [phone]                DK-8000 Aarhus C
 > http://www.cryptomathic.dk/            Denmark
 > 


Received: from wafw.bear.com (wafw.bear.com [207.162.228.3]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id GAA15102 for <[e-mail]>; Mon, 15 Nov 1999 06:50:23 -0800 (PST)
Received: from bear.com (localhost [127.0.0.1]) by wafw.bear.com (8.9.3/8.9.2) with SMTP id JAA04086 for <[e-mail]>; Mon, 15 Nov 1999 09:51:06 -0500 (EST)
Received: by whmsx9.is.bear.com with Internet Mail Service (5.5.2448.0) id <WVB684C4>; Mon, 15 Nov 1999 09:54:54 -0500
Message-ID: <[e-mail]>
From: "Luo, Feng (Exchange)" <[e-mail]>
To: "'[e-mail]'" <[e-mail]>
Subject: FW: Check this out quickly and respond!
Date: Mon, 15 Nov 1999 09:52:40 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2448.0)
Content-Type: multipart/mixed; boundary="----_=_NextPart_000_01BF2F79.5EC9E060"

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:[e-mail]]
> Sent:	Monday, November 15, 1999 9:40 AM
> To:	'[e-mail]'
> Subject:	FW: Check this out quickly and respond!
> 
> 
> 
> > -----Original Message-----
> > From:	Jennifer Yan [SMTP:[e-mail]]
> > Sent:	Saturday, November 13, 1999 7:59 PM
> > To:	[e-mail]
> > 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: <[e-mail]>
From: Yue Wu <[e-mail]>
To: [e-mail]
Cc: [e-mail]
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: [e-mail]
>To: [e-mail], [e-mail], [e-mail]
>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:   [e-mail], 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, [e-mail],
>       [e-mail], [e-mail]
>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
>---------------------------
>
>
>[e-mail] 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 ---------------------------
>
>
>[e-mail] on 11/11/99 09:17:46 AM
>To:   [e-mail], [e-mail], [e-mail], John
>       Elliott/MCS/Price Waterhouse, Anita C. Pompilio/North York 
>ON/C&L/CA,
>       [e-mail], [e-mail], [e-mail],
>       [e-mail], [e-mail], [e-mail],
>       [e-mail]
>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: [phone]        Fax: [phone]
>
>
>
>
>Chris Pompilio
>Vice President
>Aon Re Canada
>Toronto
>Phone: [phone]        Fax: [phone]
>
>
>
>
>
>
>----------------------------------------------------------------
>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--



Received: from www.cryptomathic.dk (cryptomathic.cryptomathic.dk [194.239.238.251]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id GAA14687 for <[e-mail]>; Mon, 15 Nov 1999 06:27:04 -0800 (PST)
Received: from cryptomathic.dk (fw.cryptomathic.dk [10.0.1.1]) by www.cryptomathic.dk (8.9.3/8.9.3) with ESMTP id PAA30099 for <[e-mail]>; Mon, 15 Nov 1999 15:37:16 +0100
Message-ID: <[e-mail]>
Date: Mon, 15 Nov 1999 15:30:39 +0100
From: Anette Byskov <[e-mail]>
Reply-To: [e-mail]
Organization: Cryptomathic
X-Mailer: Mozilla 4.6 [en] (WinNT; I)
X-Accept-Language: en
MIME-Version: 1.0
To: [e-mail]
Subject: ASN.1 question to PKIHeader in CMP (RFC 2510) 
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

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:  [phone]                Klostergade 28
Fax:    [phone]                DK-8000 Aarhus C
http://www.cryptomathic.dk/            Denmark


Received: from www.certifeidtime.com. (test.glassey.com [207.126.98.130] (may be forged)) by ns.secondary.com (8.9.3/8.9.3) with SMTP id RAA24365 for <[e-mail]>; Sat, 13 Nov 1999 17:47:13 -0800 (PST)
Received: from gw by www.certifeidtime.com. (SMI-8.6/SMI-SVR4) id RAA16383; Sat, 13 Nov 1999 17:47:47 -0800
Message-ID: <047e01bf2e42$3113be80$[e-mail]>
From: "Todd Glassey @ GMTsw" <[e-mail]>
To: "Manger, James" <[e-mail]>, <[e-mail]>
References: <[e-mail]>
Subject: Re: Timestamp: 04: comments
Date: Sat, 13 Nov 1999 17:46:50 -0800
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.00.2919.5600
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.5600

----- Original Message -----
From: "Manger, James" <[e-mail]>
To: <[e-mail]>
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



Received: from NotesSmtp.eycan.com (mail2.eycan.com [209.226.9.197]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id LAA21990 for <[e-mail]>; Sat, 13 Nov 1999 11:52:25 -0800 (PST)
From: [e-mail]
Received: by NotesSmtp.eycan.com(Lotus SMTP MTA v1.2  (600.1 3-26-1998))  id 85256828.006D354A ; Sat, 13 Nov 1999 14:52:50 -0500
X-Lotus-FromDomain: EY-CANADA@INTERNET
To: [e-mail]
Message-ID: <[e-mail]>
Date: Sat, 13 Nov 1999 12:41:19 -0500
Subject: Unsubscribe
Mime-Version: 1.0
Content-type: text/plain; charset=us-ascii
Content-Disposition: inline

Unsubscribe




Bernard Hervault <[e-mail]> on 11/12/99 03:12:32 AM

Please respond to [e-mail]

To:   "[e-mail]" <[e-mail]>
cc:    (bcc: Cam F Johnston/Audit/ErnstYoung/CA)
Subject:  Unsubscribe




unsubscribe

--
______________________________________________________
Bernard Hervault - Email: <[e-mail]>
ETIAM "Cooperative medical imaging products"
20 rue du Pr.  Jean PECKER - 35000 RENNES - France -
Tel: [phone] - Fax: [phone]
Web:  http://www.etiam.com
______________________________________________________










Received: from caesar.udac.se (caesar.udac.se [193.44.79.10]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id BAA13813 for <[e-mail]>; Sat, 13 Nov 1999 01:36:05 -0800 (PST)
Received: from mega (t3o69p98.telia.com [62.20.145.98]) by caesar.udac.se (8.7.3/NetworkC-1) with SMTP id KAA49721 for <[e-mail]>; Sat, 13 Nov 1999 10:33:11 +0100
Message-ID: <00b501bf2dc2$93d9e7e0$[e-mail]>
From: "Anders Rundgren" <[e-mail]>
To: "PKIX-List" <[e-mail]>
Subject: Stupid Q. re. PKCs and Directories
Date: Sat, 13 Nov 1999 10:33:50 -0000
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 4.72.3110.5
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by ns.secondary.com id BAA13814

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




Received: from caesar.udac.se (caesar.udac.se [193.44.79.10]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id XAA10848 for <[e-mail]>; Fri, 12 Nov 1999 23:39:22 -0800 (PST)
Received: from mega (t4o69p112.telia.com [62.20.145.232]) by caesar.udac.se (8.7.3/NetworkC-1) with SMTP id IAA07355; Sat, 13 Nov 1999 08:36:19 +0100
Message-ID: <007201bf2db2$45f27750$[e-mail]>
From: "Anders Rundgren" <[e-mail]>
To: "PKIX-List" <[e-mail]>, <[e-mail]>
Subject: Re: dnQualifier
Date: Sat, 13 Nov 1999 08:36:57 -0000
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 4.72.3110.5
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by ns.secondary.com id XAA10849

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




Received: from smtpproxy1.mitre.org (mbunix.mitre.org [129.83.20.100]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id NAA21634 for <[e-mail]>; Fri, 12 Nov 1999 13:45:30 -0800 (PST)
Received: from avsrv1.mitre.org (avsrv1.mitre.org [129.83.20.58]) by smtpproxy1.mitre.org (8.9.3/8.9.3) with ESMTP id QAA12870 for <[e-mail]>; Fri, 12 Nov 1999 16:46:28 -0500 (EST)
Received: from MAILHUB2 (mailhub2.mitre.org [129.83.221.18]) by smtpsrv1.mitre.org (8.9.3/8.9.3) with ESMTP id QAA21617 for <[e-mail]>; Fri, 12 Nov 1999 16:44:32 -0500 (EST)
Received: from mwestc012-mwmp1port9.mitre.org (128.29.250.9) by mailhub2.mitre.org with SMTP id 2017504; Fri, 12 Nov 1999 16:46:25 EST
Message-ID: <[e-mail]>
Date: Fri, 12 Nov 1999 16:41:19 -0500
From: "Ella P. Gardner" <[e-mail]>
Organization: The MITRE Corporation
X-Mailer: Mozilla 4.5 [en]C-19990120M  (Win95; U)
X-Accept-Language: en
MIME-Version: 1.0
To: [e-mail]
Subject: dnQualifier
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

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



Received: from po1.bbn.com (PO1.BBN.COM [192.1.50.38]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id MAA20924 for <[e-mail]>; Fri, 12 Nov 1999 12:43:59 -0800 (PST)
Received: from [171.78.30.108] (comsecpb.bbn.com [171.78.30.108]) by po1.bbn.com (8.9.1/8.9.1) with ESMTP id PAA21593 for <[e-mail]>; Fri, 12 Nov 1999 15:44:56 -0500 (EST)
Mime-Version: 1.0
X-Sender: [e-mail] (Unverified)
Message-Id: <v04220800b4522c77f5fd@[171.78.30.108]>
In-Reply-To: <01BF2D42.BF20EA00@HYDRA>
References: <01BF2D42.BF20EA00@HYDRA>
Date: Fri, 12 Nov 1999 15:45:24 -0500
To: [e-mail]
From: Stephen Kent <[e-mail]>
Subject: draft PKIX meeting minutes
Content-Type: multipart/alternative; boundary="============_-1269682966==_ma============"

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


Received: from caesar.udac.se (caesar.udac.se [193.44.79.10]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id KAA19358 for <[e-mail]>; Fri, 12 Nov 1999 10:23:31 -0800 (PST)
Received: from HYDRA ([195.198.186.73]) by caesar.udac.se (8.7.3/NetworkC-1) with SMTP id TAA41651; Fri, 12 Nov 1999 19:20:36 +0100
Received: by HYDRA with Microsoft Mail id <01BF2D42.BF20EA00@HYDRA>; Fri, 12 Nov 1999 19:18:48 +0100
Message-ID: <01BF2D42.BF20EA00@HYDRA>
From: Anders Rundgren <[e-mail]>
To: "[e-mail]" <[e-mail]>, "'David P. Kemp'" <[e-mail]>
Subject: RE: Use of dnQualifier in the QC profile
Date: Fri, 12 Nov 1999 19:18:47 +0100
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit

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




Received: from stingray.missi.ncsc.mil (stingray.missi.ncsc.mil [144.51.50.20]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id IAA18088 for <[e-mail]>; Fri, 12 Nov 1999 08:47:21 -0800 (PST)
Received: from stingray.missi.ncsc.mil (root@localhost) by stingray.missi.ncsc.mil with ESMTP id LAA01037 for <[e-mail]>; Fri, 12 Nov 1999 11:48:41 -0500 (EST)
Received: from missi.ncsc.mil (depot.missi.ncsc.mil [144.51.60.1]) by stingray.missi.ncsc.mil with ESMTP id LAA01033 for <[e-mail]>; Fri, 12 Nov 1999 11:48:41 -0500 (EST)
Received: from ara.missi.ncsc.mil (ara.missi.ncsc.mil [144.51.58.9]) by missi.ncsc.mil (8.8.8/8.8.8) with ESMTP id LAA16714 for <[e-mail]>; Fri, 12 Nov 1999 11:47:59 -0500 (EST)
Received: from ara.missi.ncsc.mil (ara.missi.ncsc.mil [144.51.58.9]) by ara.missi.ncsc.mil (8.9.1b+Sun/8.9.1) with SMTP id LAA13382 for <[e-mail]>; Fri, 12 Nov 1999 11:44:01 -0500 (EST)
Message-Id: <[e-mail]>
Date: Fri, 12 Nov 1999 11:44:01 -0500 (EST)
From: "David P. Kemp" <[e-mail]>
Reply-To: "David P. Kemp" <[e-mail]>
Subject: Re: Use of dnQualifier in the QC profile
To: [e-mail]
MIME-Version: 1.0
Content-Type: TEXT/plain; charset=us-ascii
Content-MD5: ThtX2DDHjmONt6t9+Bgyxg==
X-Mailer: dtmail 1.3.0 CDE Version 1.3 SunOS 5.7 sun4u sparc

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: <[e-mail]>
> From: Stefan Santesson <[e-mail]>
> 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
>  
> 
> 



Received: from relay4.mail.uk.psi.net (relay4.mail.uk.psi.net [154.32.111.6]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id FAA15375 for <[e-mail]>; Fri, 12 Nov 1999 05:18:03 -0800 (PST)
Received: from mailhost.baltimore.com ([195.152.140.4] helo=stonewall.baltimore.com) by relay4.mail.uk.psi.net with smtp (Exim 2.12 #2) id 11mGZq-00005w-00 for [e-mail]; Fri, 12 Nov 1999 13:17:27 +0000
From: Farrukh Ahmad <[e-mail]>
Message-ID: <[e-mail]>
To: [e-mail]
Subject: RE: Model PKI Disclosure Statement (PDS)
Date: Fri, 12 Nov 1999 13:18:15 -0000
Importance: low
X-Priority: 5
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2448.0)
Content-Type: text/plain; charset="iso-8859-1"

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:[e-mail]]
Sent: 11 November 1999 01:09
To: [e-mail]
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


Received: from CarlCox.iway.fr (carlcox.iway.fr [194.98.0.128]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id AAA06116 for <[e-mail]>; Fri, 12 Nov 1999 00:14:26 -0800 (PST)
Received: from etiam.com (1cust37.tnt1.dial.ren1.fr.uu.net [212.155.1.37]) by CarlCox.iway.fr (8.8.7/8.8.7) with ESMTP id JAA7637463 for <[e-mail]>; Fri, 12 Nov 1999 09:15:16 +0100 (MET)
Message-ID: <[e-mail]>
Date: Fri, 12 Nov 1999 09:12:32 +0100
From: Bernard Hervault <[e-mail]>
Reply-To: [e-mail]
Organization: Etiam
X-Mailer: Mozilla 4.6 [en] (Win95; I)
X-Accept-Language: en
MIME-Version: 1.0
To: "[e-mail]" <[e-mail]>
Subject: Unsubscribe
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

unsubscribe

--
______________________________________________________
Bernard Hervault - Email: <[e-mail]>
ETIAM "Cooperative medical imaging products"
20 rue du Pr.  Jean PECKER - 35000 RENNES - France -
Tel: [phone] - Fax: [phone]
Web:  http://www.etiam.com
______________________________________________________




Received: from drawbridge.ascend.com (drawbridge.ascend.com [198.4.92.1]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id VAA29906 for <[e-mail]>; Thu, 11 Nov 1999 21:54:34 -0800 (PST)
Received: from fw-ext.ascend.com (fw-ext [198.4.92.5]) by drawbridge.ascend.com (8.9.1a/8.9.1) with SMTP id VAA15334 for <[e-mail]>; Thu, 11 Nov 1999 21:49:58 -0800 (PST)
Received: from russet.ascend.com by fw-ext.ascend.com via smtpd (for drawbridge.ascend.com [198.4.92.1]) with SMTP; 12 Nov 1999 05:55:31 UT
Received: from porky (porky.ascend.com [192.207.23.83]) by russet.ascend.com (8.9.1a/8.9.1) with ESMTP id VAA29172 for <[e-mail]>; Thu, 11 Nov 1999 21:55:30 -0800 (PST)
Received: from ascend.com by ascend.com
Reply-To: <[e-mail]>
From: "Kirby Russell" <[e-mail]>
To: <[e-mail]>
Date: Thu, 11 Nov 1999 21:55:38 -0800
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="Windows-1252"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200

unsubscribe


Received: from caesar.udac.se (caesar.udac.se [193.44.79.10]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id UAA26277 for <[e-mail]>; Thu, 11 Nov 1999 20:29:24 -0800 (PST)
Received: from mega (t2o69p26.telia.com [62.20.144.146]) by caesar.udac.se (8.7.3/NetworkC-1) with SMTP id FAA16343; Fri, 12 Nov 1999 05:26:10 +0100
Message-ID: <003501bf2cce$83717840$[e-mail]>
From: "Anders Rundgren" <[e-mail]>
To: "Stefan Santesson" <[e-mail]>, <[e-mail]>
Cc: "Warwick Ford" <[e-mail]>
Subject: Use of dnQualifier in QC/2459   {Re: Use of dnQualifier in the QC profile}
Date: Fri, 12 Nov 1999 05:26:45 -0000
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 4.72.3110.5
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by ns.secondary.com id UAA26282

>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



Received: from popmail.inbox.se (popmail.inbox.se [193.12.72.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id UAA26190 for <[e-mail]>; Thu, 11 Nov 1999 20:29:01 -0800 (PST)
Received: from best-laptop (mid-qbu-nql-vty12.as.wcom.net [216.192.104.12]) by popmail.inbox.se (8.9.3/8.9.3) with SMTP id FAA29322; Fri, 12 Nov 1999 05:29:48 +0100
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 
Date: Thu, 11 Nov 1999 21:50:18 -0500
To: [e-mail]
From: Stefan Santesson <[e-mail]>
Subject: Re: Use of dnQualifier in the QC profile
Cc: [e-mail]
In-Reply-To: <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"

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, [e-mail] 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



Received: from e4.ny.us.ibm.com (e4.ny.us.ibm.com [32.97.182.104]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id PAA05883 for <[e-mail]>; Thu, 11 Nov 1999 15:03:28 -0800 (PST)
From: [e-mail]
Received: from southrelay02.raleigh.ibm.com (southrelay02.raleigh.ibm.com [9.37.3.209]) by e4.ny.us.ibm.com (8.9.3/8.9.3) with ESMTP id SAA189710; Thu, 11 Nov 1999 18:03:36 -0500
Received: from D51MTA05.pok.ibm.com (d51mta05.pok.ibm.com [9.117.200.33]) by southrelay02.raleigh.ibm.com (8.8.8m2/NCO v2.06) with SMTP id SAA56874; Thu, 11 Nov 1999 18:04:10 -0500
Received: by D51MTA05.pok.ibm.com(Lotus SMTP MTA v4.6.5  (863.2 5-20-1999))  id 85256826.007E9F54 ; Thu, 11 Nov 1999 18:03:03 -0500
X-Lotus-FromDomain: IBMUS
To: Stefan Santesson <[e-mail]>
cc: [e-mail]
Message-ID: <[e-mail]>
Date: Thu, 11 Nov 1999 18:02:45 -0500
Subject: Re: Use of dnQualifier in the QC profile
Mime-Version: 1.0
Content-type: text/plain; charset=us-ascii
Content-Disposition: inline

     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




Received: from prv-mail20.provo.novell.com (prv-mail20.provo.novell.com [137.65.82.195]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id OAA05377 for <[e-mail]>; Thu, 11 Nov 1999 14:51:31 -0800 (PST)
Received: from INET-PRV-Message_Server by prv-mail20.provo.novell.com with Novell_GroupWise; Thu, 11 Nov 1999 15:51:28 -0700
Message-Id: <[e-mail]>
X-Mailer: Novell GroupWise Internet Agent 5.5.2.1
Date: Thu, 11 Nov 1999 15:51:33 -0700
From: "Bob Jueneman" <[e-mail]>
To: <[e-mail]>, <[e-mail]>
Subject: Re: Update of the QC personalData issue
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by ns.secondary.com id OAA05378

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 <[e-mail]> 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




Received: from crack.x509.com ([e-mail] [199.175.150.1]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id OAA04396 for <[e-mail]>; Thu, 11 Nov 1999 14:15:11 -0800 (PST)
Received: from home.x509.com (home.x509.com [199.175.150.4]) by crack.x509.com (8.9.3/XCERT) with ESMTP id OAA02440 for <[e-mail]>; Thu, 11 Nov 1999 14:16:05 -0800 (PST)
Date: Thu, 11 Nov 1999 14:16:05 -0800 (PST)
From: Marc Branchaud <[e-mail]>
X-Sender: [e-mail]
To: [e-mail]
Subject: Re: Update of the QC personalData issue
In-Reply-To: <[e-mail]>
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII

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



Received: from popmail.inbox.se (popmail.inbox.se [193.12.72.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id OAA04190 for <[e-mail]>; Thu, 11 Nov 1999 14:12:00 -0800 (PST)
Received: from best-laptop (dhcp22-fh72.fh.ietf.innovationslab.net [130.128.22.72]) by popmail.inbox.se (8.9.3/8.9.3) with SMTP id XAA27484 for <[e-mail]>; Thu, 11 Nov 1999 23:12:52 +0100
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 
Date: Thu, 11 Nov 1999 17:13:18 -0500
To: <[e-mail]>
From: Stefan Santesson <[e-mail]>
Subject: Use of dnQualifier in the QC profile
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"

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
 




Received: from smtp-out1.bellatlantic.net (smtp-out1.bellatlantic.net [199.45.39.156]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id NAA02782 for <[e-mail]>; Thu, 11 Nov 1999 13:13:03 -0800 (PST)
Received: from ieca.com (adsl-151-200-26-46.bellatlantic.net [151.200.26.46]) by smtp-out1.bellatlantic.net (8.9.1/8.9.1) with ESMTP id QAA26333; Thu, 11 Nov 1999 16:11:55 -0500 (EST)
Message-ID: <[e-mail]>
Date: Thu, 11 Nov 1999 16:06:27 -0500
From: Sean Turner <[e-mail]>
Organization: IECA, Inc.
X-Mailer: Mozilla 4.7 [en] (Win98; U)
X-Accept-Language: en
MIME-Version: 1.0
To: "Manger, James" <[e-mail]>
CC: [e-mail], "Kesterson, Hoyt" <[e-mail]>, Stefan Santesson <[e-mail]>
Subject: Re: dnQualifier is used incorrectly
References: <[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

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



Received: from NotesSmtp.eycan.com (mail2.eycan.com [209.226.9.197]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id GAA19837 for <[e-mail]>; Thu, 11 Nov 1999 06:22:34 -0800 (PST)
From: [e-mail]
Received: by NotesSmtp.eycan.com(Lotus SMTP MTA v1.2  (600.1 3-26-1998))  id 85256826.004EFB2A ; Thu, 11 Nov 1999 09:22:41 -0500
X-Lotus-FromDomain: EY-CANADA@INTERNET
To: [e-mail]
Message-ID: <[e-mail]>
Date: Thu, 11 Nov 1999 09:01:04 -0500
Subject: unsubscribe
Mime-Version: 1.0
Content-type: text/plain; charset=us-ascii
Content-Disposition: inline

unsubscribe




Received: from mail0.sse.ie (mail0.sse.ie [193.120.32.47]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id EAA18170 for <[e-mail]>; Thu, 11 Nov 1999 04:20:26 -0800 (PST)
Received: from mail0.sse.ie (actually localhost) by mail0.sse.ie; Thu, 11 Nov 1999 12:22:36 +0000
Received: from bowsy (bowsy.sse.ie [193.120.32.196]) by mail0.sse.ie (8.9.1a/8.9.1) with SMTP id MAA25991; Thu, 11 Nov 1999 12:22:23 GMT
Message-ID: <020301bf2c3f$28194610$[e-mail]>
From: "Andy Dowling" <[e-mail]>
To: "Stephen Farrell (Baltimore)" <[e-mail]>, "Russell Housley" <[e-mail]>
Cc: <[e-mail]>
Subject: Policy Authority Control
Date: Thu, 11 Nov 1999 12:20:23 -0000
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.00.2314.1300
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300
Content-Transfer-Encoding: 7bit

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:  [e-mail]
Web: http://www.sse.ie
Phone: [phone]
Fax:   [phone]



Received: from mail0.sse.ie (mail0.sse.ie [193.120.32.47]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id BAA12361 for <[e-mail]>; Thu, 11 Nov 1999 01:14:59 -0800 (PST)
Received: from mail0.sse.ie (actually localhost) by mail0.sse.ie; Thu, 11 Nov 1999 09:15:36 +0000
Received: from bowsy (bowsy.sse.ie [193.120.32.196]) by mail0.sse.ie (8.9.1a/8.9.1) with SMTP id JAA16365; Thu, 11 Nov 1999 09:15:28 GMT
Message-ID: <015e01bf2c25$05989100$[e-mail]>
From: "Andy Dowling" <[e-mail]>
To: <[e-mail]>
Cc: "Stephen Farrell (Baltimore)" <[e-mail]>
Subject: AC ASN.1
Date: Thu, 11 Nov 1999 09:13:28 -0000
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.00.2314.1300
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300
Content-Transfer-Encoding: 7bit

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:  [e-mail]
Web: http://www.sse.ie
Phone: [phone]
Fax:   [phone]



Received: from mail0.sse.ie (mail0.sse.ie [193.120.32.47]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id AAA11822 for <[e-mail]>; Thu, 11 Nov 1999 00:59:38 -0800 (PST)
Received: from mail0.sse.ie (actually localhost) by mail0.sse.ie; Thu, 11 Nov 1999 09:02:04 +0000
Received: from bowsy (bowsy.sse.ie [193.120.32.196]) by mail0.sse.ie (8.9.1a/8.9.1) with SMTP id JAA15814; Thu, 11 Nov 1999 09:02:01 GMT
Message-ID: <013e01bf2c23$24451d50$[e-mail]>
From: "Andy Dowling" <[e-mail]>
To: <[e-mail]>
Cc: <[e-mail]>, <[e-mail]>, "xme" <[e-mail]>
References: <01c601bf21e5$f9c09b00$[e-mail]> <[e-mail]>
Subject: Re: LAAP performance issues
Date: Thu, 11 Nov 1999 09:00:01 -0000
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.00.2314.1300
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300
Content-Transfer-Encoding: 7bit

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




Received: from caesar.udac.se (caesar.udac.se [193.44.79.10]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id AAA09897 for <[e-mail]>; Thu, 11 Nov 1999 00:21:34 -0800 (PST)
Received: from HYDRA ([195.198.186.73]) by caesar.udac.se (8.7.3/NetworkC-1) with SMTP id JAA57374; Thu, 11 Nov 1999 09:18:36 +0100
Received: by HYDRA with Microsoft Mail id <01BF2C25.79962B80@HYDRA>; Thu, 11 Nov 1999 09:16:45 +0100
Message-ID: <01BF2C25.79962B80@HYDRA>
From: Anders Rundgren <[e-mail]>
To: "[e-mail]" <[e-mail]>, "'Stefan Santesson'" <[e-mail]>, "'Warwick Ford'" <[e-mail]>
Cc: =?iso-8859-1?Q?=27Magnus_Nystr=F6m=27?= <[e-mail]>
Subject: QC/Son-of-2459  "key-container-info"
Date: Thu, 11 Nov 1999 09:16:44 +0100
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by ns.secondary.com id AAA09899

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:[e-mail]]
Sent:  Wednesday, November 03, 1999 10:36
To:  Anders Rundgren; [e-mail]; 'SEIS-List'
Subject:  SEIS:  Re: QC Container-ID (card serial)

--- Message on the SEIS mailing list ([e-mail])

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                <[e-mail]>
Accurata AB                     http://www.accurata.se
Slagthuset                      Tel. [phone]              
211 20  Malmö                   Fax. [phone]              
Sweden                        Mobile [phone]

PGP fingerprint: 89BC 6C79 5B3D 591B 8547  1512 7D11 DBF4 528F 29A0
-------------------------------------------------------------------


----------------- SEIS mailing list ([e-mail])
Info about this list: http://www.nc-forum.com/seis
SEIS Contact: [e-mail]




Received: from caesar.udac.se (caesar.udac.se [193.44.79.10]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id WAA06894 for <[e-mail]>; Wed, 10 Nov 1999 22:51:26 -0800 (PST)
Received: from mega (t2o69p76.telia.com [62.20.144.196]) by caesar.udac.se (8.7.3/NetworkC-1) with SMTP id HAA54283; Thu, 11 Nov 1999 07:48:24 +0100
Message-ID: <004201bf2c19$35ed4550$[e-mail]>
From: "Anders Rundgren" <[e-mail]>
To: "Stefan Santesson" <[e-mail]>, <[e-mail]>
Cc: "Magnus (RSA)" <[e-mail]>, "Warwick Ford" <[e-mail]>
Subject: Static Identifiers {Re: Update of the QC personalData issue}
Date: Thu, 11 Nov 1999 07:48:57 -0000
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 4.72.3110.5
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by ns.secondary.com id WAA06895

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



Received: from dfw-smtpout4.email.verio.net (dfw-smtpout4-ext.email.verio.net [129.250.36.44]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id UAA00318 for <[e-mail]>; Wed, 10 Nov 1999 20:32:40 -0800 (PST)
Received: from dfw-mmp2.email.verio.net ([129.250.38.62]) by dfw-smtpout4.email.verio.net (Netscape Messaging Server 4.05) with ESMTP id FL0NBV00.7IY for <[e-mail]>; Thu, 11 Nov 1999 04:33:31 +0000 
Received: from nma.com ([209.21.28.100]) by dfw-mmp2.email.verio.net (Netscape Messaging Server 4.05) with ESMTP id FL0NEO00.OCZ for <[e-mail]>; Thu, 11 Nov 1999 04:35:12 +0000 
Message-ID: <[e-mail]>
Date: Wed, 10 Nov 1999 20:33:29 -0800
From: Ed Gerck <[e-mail]>
X-Mailer: Mozilla 4.7 [en]C-CCK-MCD {Sony}  (Win98; I)
X-Accept-Language: en
MIME-Version: 1.0
To: "[e-mail]" <[e-mail]>
Subject: Re: Model PKI Disclosure Statement (PDS)
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

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


Received: from webo.vtcif.telstra.com.au (webo.vtcif.telstra.com.au [202.12.144.19]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id SAA22597 for <[e-mail]>; Wed, 10 Nov 1999 18:49:54 -0800 (PST)
Received: (from uucp@localhost) by webo.vtcif.telstra.com.au (8.8.2/8.6.9) id NAA24349 for <[e-mail]>; Thu, 11 Nov 1999 13:50:13 +1100 (EST)
Received: from maili.vtcif.telstra.com.au(202.12.142.17) via SMTP by webo.vtcif.telstra.com.au, id smtpdOM.KU_; Thu Nov 11 13:49:43 1999
Received: (from uucp@localhost) by maili.vtcif.telstra.com.au (8.8.2/8.6.9) id NAA13152 for <[e-mail]>; Thu, 11 Nov 1999 13:49:42 +1100 (EST)
Received: from mail.cdn.telstra.com.au(144.135.138.138) via SMTP by maili.vtcif.telstra.com.au, id smtpdozIhY_; Thu Nov 11 13:48:04 1999
Received: from v300x-nm02.corpmail.telstra.com.au (v300x-nm02.corpmail.telstra.com.au [172.172.2.13]) by mail.cdn.telstra.com.au (8.8.2/8.6.9) with ESMTP id NAA25501 for <[e-mail]>; Thu, 11 Nov 1999 13:48:03 +1100 (EST)
Message-Id: <[e-mail]>
Received: by v300x-nm02.corpmail.telstra.com.au with Internet Mail Service (5.5.2448.0) id <WVH223AT>; Thu, 11 Nov 1999 13:39:38 +1100
From: "Manger, James" <[e-mail]>
To: [e-mail]
Subject: dnQualifier is used incorrectly
Date: Thu, 11 Nov 1999 11:24:10 +1100
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2448.0)
Content-Type: multipart/mixed; boundary="----_=_NextPart_000_01BF2BED.FEC6EAE0"

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

eJ8+IicCAQaQCAAEAAAAAAABAAEAAQeQBgAIAAAA5AQAAAAAAADoAAEIgAcAGAAAAElQTS5NaWNy
b3NvZnQgTWFpbC5Ob3RlADEIAQSAAQAgAAAAZG5RdWFsaWZpZXIgaXMgdXNlZCBpbmNvcnJlY3Rs
eQAPDAEJgAEAIQAAADhCQjM5RTU4QkQ5N0QzMTFCRDRBMDAxMDRCMDhEQkYxAEAHASCAAwAOAAAA
zwcLAAsADQAnACUABABJAQEFgAMADgAAAM8HCwALAAsAGAAKAAQAHQEBDYAEAAIAAAACAAIAAQOQ
BgDMCQAAHgAAAAMALgAAAAAAQAA5AMDIHhPbK78BHgBwAAEAAAAoAAAAUUMgVUlEIHN1cHBvcnQg
bXVzdCBkZXBhcnQgZnJvbSBSRkMyNDU5AAIBcQABAAAAGwAAAAG/J7PCdXYHioqTohHTrnkACMck
rdIBBvDz2gACAQkQAQAAAFoGAABWBgAAcQwAAExaRnVe1rPIAwAKAHJjcGcxMjX+MgD/AgYCpAPk
BesCgwBQEwNUAgBjaArAc2V0/jIGAAbDAoMOUAPVBxMCgzIzE89mNAPFAgBwckJxEuJzdGVtAoB9
twqACM8J2TsYXw4wNRlzPQ4gOBisF4EOYgtgbmcoMzA4AFBoBbB6ZNRvYwAAKhJVIAKRHbBebB3l
CvsU4gwBYwBAII5JBUAEACCwbmFwFrAObxawBzAXMCB0byBxHSBsZCADkRdAC1BvOnkJ4C8HgAbQ
BJAvY451FyADcASQIG51IzIDIkAEIGEgZG5RdT8HQAaQCJEiQAJABRBidQ0hoXYHQApQLiAgV4Jo
CfAgbXVsdAUg0mwhsGRpGGBjIdAIgZUEIGUA0Ggh8GF2IbBjIlICMHJ5IAIQBcB0kSbAIHNhB4Ag
cASQMnMCICAoBbEpIWl0xHkpKbNETiAk+CeQ8SoBYmlnJQAXMAQgKcL3KSIoESaBQSu8JjMg4SeQ
8mMtI3doDeAogCeWKWC3JLArwRhgZiphIcEsJAD+bwVAMEQqVQuAJKIwtiaB6kkDoGYA0HQyICnC
DnHLC4ArMGkqkW9mK7wqAPcXECm4L0RzHSAnECIwI0D+ICOQCYApcwdAAyAttTNE3GdpKMADoDOq
TSERC4AeZylwA2EniyHRQ0Fz9zIgKzAgsmMnYArBKcAhkP8rfzgWLJo94ASQJzAlQC/k3wQBClAi
MCHRKc5iKWAnkN8OkASQKSE9MiaBVCnWLn//OA8zUjlhQP844UNhOkY9QLdEZT7vIiFpDnArEWYp
YI8pwj1AMiQpw3ViaifBZi4KhQqFRXgqECdROl8KhS5QBaAikABweTIgRu8DYAJAJ2BDYUwHcCsw
CYDPPXE90UfESMR0dz0jTXbpRJJUciORTUwiUVcEIH9QDzixO8IxQk7WDIIDMHsBPeAgIkFVIiAv
3zXQV4BUv1fAJNoiU2cjlU1XwFwcIlLmU3UqUUn+RFPfVO9V/1cPWB9ZL1wlq1s5TYxTFzBwJsIm
ZOLJNJBuJwQgcXUyUAeR/yNAF/AH4ArAQNFPgSdgFzDubDEhBUAEcGQwISswKIDvKcIn8TpgIQBs
MiBlcEHgnxhgZ7E1NijAMiBYLg5AvjA1LT6vJZdNfWT2S0PyZzbiPXEDoCdSTsAr4EP8IFVccUHg
ISAYASbxFyAPNSEKsQVAPANSRkMy4DQ1OScsTYwK9CUgfDM2DrALVROyICMS4CL8Li4fbw5QITEX
MCfQIIC/ZoIIkCjBPl8lQwDAaweR/wRgZwESsACAKNEkkk9yAiDvQ/I14SSwFzByUMBpQQfw/yvA
MiB4UT4BcXE8AynDAZD/L7BxAAuAe3MwqATwJsAAwH8mgHeQUkA4UgdAKoBM8Wf+ZweQeGJ4UyDC
LVQEYHFxPyEaJZgkgweABiI14WV43xawB5BeoyKGIIBEMiAKsL55A2A5YSQUMiASwGMuIv8BgCRS
OWA003pxJBQwIUPReyRxAJBne0BHIynChPEt7WrhMGsgUkByIiEh0Shh53flKNIHQG9nCGAoMUOx
+TSyaS4mcDTRIeBAKyoQ+wIgO+BkIZABoCSALZd4JNlQwGdoZ/EpwXID8SGw9ziRS3Qv4Gx113UK
de13Fv8Kj3TaIHBkiGXBBgItMSqCv2+Dcv90D5Mvdk93Ui0UMP8lpgQgKYKE2SSwIWEmMCGh/0t0
K0AqsJqfEuB1wCaAm9/7dvgk2SmgjxLgoaOh73bp/kiJUinCOMF+gyTpA/A5Yf84kQWgAIAlsAtx
QgQiBDiw/wMAZiCR1iVDa/VNBWhTiiX/ErF7g0ePSJlJoaRvm6l1Bb+Uz5Xflupg8TwwauR8IICg
U08vSUVwcDlysAg0LTZwQDE5OTODTtazJTUuMi44K7t/UrlsbyXUK0AqUCnwKlBj/10ULJk7wguA
KYEAwDWTi5J/aCBCJmnRvUEowSyRvVJ1/wQAJsAiMCEAKiF7kikFNDL/IKUXMC+wQgQ4mjmWJsBL
Qvkm6URTPVAwNYAEkSgoo/8px8CyfKEvsHgkKzAEIC9E/ziRKcc6GcVROQ8h0TBEgYR/vbkSgGZy
JtG+kQmATX1b/criPSuwMLcXBBQwgOACMH8yII+hkkJnsn66BJAowHIWXbMlF4EA1AAAAAMA/T9S
AwAAHgBCEAEAAAAxAAAAPDAwNDgwMWJmMjdiYiQzMWYzNGY2MCQwMjAwMDBjMEBtZWdhLnZpbmNl
bnQuc2U+AAAAAAMAJgAAAAAAAwA2AAAAAAAeADFAAQAAABAAAABKTUFOR0VSMjkyODhFRjMAAwAa
QAAAAAAeADBAAQAAABAAAABKTUFOR0VSMjkyODhFRjMAAwAZQAAAAAACAfk/AQAAAGcAAAAAAAAA
3KdAyMBCEBq0uQgAKy/hggEAAAAGAAAAL089VEVMU1RSQS9PVT1RTEQgS0lOR1NGT1JELVNNSVRI
L0NOPU1TIE1BSUwgUkVDSVBJRU5UUy9DTj1KTUFOR0VSMjkyODhFRjMAAB4A+D8BAAAADgAAAE1h
bmdlciwgSmFtZXMAAAAeADhAAQAAABAAAABKTUFOR0VSMjkyODhFRjMAAgH7PwEAAABnAAAAAAAA
ANynQMjAQhAatLkIACsv4YIBAAAABgAAAC9PPVRFTFNUUkEvT1U9UUxEIEtJTkdTRk9SRC1TTUlU
SC9DTj1NUyBNQUlMIFJFQ0lQSUVOVFMvQ049Sk1BTkdFUjI5Mjg4RUYzAAAeAPo/AQAAAA4AAABN
YW5nZXIsIEphbWVzAAAAHgA5QAEAAAAQAAAASk1BTkdFUjI5Mjg4RUYzAEAABzAw2EGGzyu/AUAA
CDDg6sb+7Su/AR4APQABAAAAAQAAAAAAAAAeAB0OAQAAACAAAABkblF1YWxpZmllciBpcyB1c2Vk
IGluY29ycmVjdGx5AAsAKQAAAAAACwAjAAAAAAADAAYQcyrF/AMABxB4BwAAAwAQEAAAAAADABEQ
AQAAAB4ACBABAAAAZQAAAElUSVNJTkFQUFJPUFJJQVRFVE9IT0xEQU5FTVBMT1lFRS9NRU1CRVIv
Q1VTVE9NRVJOVU1CRVJBU0FETlFVQUxJRklFUkFUVFJJQlVURVZBTFVFV0hFTk1VTFRJUExFRElS
RUMAAAAAjgM=

------_=_NextPart_000_01BF2BED.FEC6EAE0--


Received: from mailo.vtcif.telstra.com.au (mailo.vtcif.telstra.com.au [202.12.144.17]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id SAA19804 for <[e-mail]>; Wed, 10 Nov 1999 18:12:37 -0800 (PST)
Received: (from uucp@localhost) by mailo.vtcif.telstra.com.au (8.8.2/8.6.9) id NAA19679 for <[e-mail]>; Thu, 11 Nov 1999 13:12:56 +1100 (EST)
Received: from maili.vtcif.telstra.com.au(202.12.142.17) via SMTP by mailo.vtcif.telstra.com.au, id smtpd0QyOHr; Thu Nov 11 13:12:05 1999
Received: (from uucp@localhost) by maili.vtcif.telstra.com.au (8.8.2/8.6.9) id NAA27607 for <[e-mail]>; Thu, 11 Nov 1999 13:12:02 +1100 (EST)
Received: from mail.cdn.telstra.com.au(144.135.138.138) via SMTP by maili.vtcif.telstra.com.au, id smtpd0fUNGX; Thu Nov 11 13:11:12 1999
Received: from v300x-nm02.corpmail.telstra.com.au (v300x-nm02.corpmail.telstra.com.au [172.172.2.13]) by mail.cdn.telstra.com.au (8.8.2/8.6.9) with ESMTP id NAA27772 for <[e-mail]>; Thu, 11 Nov 1999 13:11:12 +1100 (EST)
Message-Id: <[e-mail]>
Received: by v300x-nm02.corpmail.telstra.com.au with Internet Mail Service (5.5.2448.0) id <WVH22KX2>; Thu, 11 Nov 1999 13:02:47 +1100
From: "Manger, James" <[e-mail]>
To: "'[e-mail]'" <[e-mail]>
Subject: PKIX: employee/member/customer/org number attributes
Date: Thu, 11 Nov 1999 12:41:46 +1100
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2448.0)
Content-Type: text/plain

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


Received: from popmail.inbox.se (popmail.inbox.se [193.12.72.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id RAA18106 for <[e-mail]>; Wed, 10 Nov 1999 17:38:41 -0800 (PST)
Received: from best-laptop (dhcp22-fh72.fh.ietf.innovationslab.net [130.128.22.72]) by popmail.inbox.se (8.9.3/8.9.3) with SMTP id CAA13595; Thu, 11 Nov 1999 02:39:29 +0100
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 
Date: Wed, 10 Nov 1999 20:39:34 -0500
To: "Anders Rundgren" <[e-mail]>, <[e-mail]>
From: Stefan Santesson <[e-mail]>
Subject: Re: QC container ID support
In-Reply-To: <00b001bf2bc0$d30b94d0$[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"

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



Received: from popmail.inbox.se (popmail.inbox.se [193.12.72.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id RAA17636 for <[e-mail]>; Wed, 10 Nov 1999 17:07:39 -0800 (PST)
Received: from best-laptop (dhcp22-fh72.fh.ietf.innovationslab.net [130.128.22.72]) by popmail.inbox.se (8.9.3/8.9.3) with SMTP id CAA13457 for <[e-mail]>; Thu, 11 Nov 1999 02:08:27 +0100
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 
Date: Wed, 10 Nov 1999 20:08:45 -0500
To: <[e-mail]>
From: Stefan Santesson <[e-mail]>
Subject: Model PKI Disclosure Statement (PDS)
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"

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


Received: from smtp-out1.bellatlantic.net (smtp-out1.bellatlantic.net [199.45.39.156]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id PAA15873 for <[e-mail]>; Wed, 10 Nov 1999 15:09:52 -0800 (PST)
Received: from ieca.com (adsl-151-200-26-46.bellatlantic.net [151.200.26.46]) by smtp-out1.bellatlantic.net (8.9.1/8.9.1) with ESMTP id SAA11926; Wed, 10 Nov 1999 18:08:35 -0500 (EST)
Message-ID: <[e-mail]>
Date: Wed, 10 Nov 1999 18:03:02 -0500
From: Sean Turner <[e-mail]>
Organization: IECA, Inc.
X-Mailer: Mozilla 4.7 [en] (Win98; U)
X-Accept-Language: en
MIME-Version: 1.0
To: [e-mail]
CC: [e-mail], [e-mail]
Subject: Re: LAAP performance issues
References: <01c601bf21e5$f9c09b00$[e-mail]> <[e-mail]> <[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

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) [phone]
> 61 Fitzwilliam Lane,                    fax: [phone]
> Dublin 2.                mailto:[e-mail]
> Ireland                             http://www.baltimore.com



Received: from popmail.inbox.se (popmail.inbox.se [193.12.72.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id PAA15689 for <[e-mail]>; Wed, 10 Nov 1999 15:07:16 -0800 (PST)
Received: from best-laptop (atl-tgn-ydu-vty19.as.wcom.net [216.192.187.19]) by popmail.inbox.se (8.9.3/8.9.3) with SMTP id AAA12847 for <[e-mail]>; Thu, 11 Nov 1999 00:08:01 +0100
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 
Date: Wed, 10 Nov 1999 18:08:21 -0500
To: <[e-mail]>
From: Stefan Santesson <[e-mail]>
Subject: Update of the QC personalData issue (errata)
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"

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


Received: from popmail.inbox.se (popmail.inbox.se [193.12.72.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id OAA15356 for <[e-mail]>; Wed, 10 Nov 1999 14:53:48 -0800 (PST)
Received: from best-laptop (atl-tgn-ydu-vty19.as.wcom.net [216.192.187.19]) by popmail.inbox.se (8.9.3/8.9.3) with SMTP id XAA12743 for <[e-mail]>; Wed, 10 Nov 1999 23:54:18 +0100
Message-Id: <[e-mail]>
X-Sender: [e-mail] (Unverified)
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 
Date: Wed, 10 Nov 1999 17:54:23 -0500
To: <[e-mail]>
From: Stefan Santesson <[e-mail]>
Subject: Update of the QC personalData issue
In-Reply-To: <00b001bf2bc0$d30b94d0$[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"

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


Received: from caesar.udac.se (caesar.udac.se [193.44.79.10]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id MAA11842 for <[e-mail]>; Wed, 10 Nov 1999 12:18:47 -0800 (PST)
Received: from mega (t4o69p91.telia.com [62.20.145.211]) by caesar.udac.se (8.7.3/NetworkC-1) with SMTP id VAA48814; Wed, 10 Nov 1999 21:15:42 +0100
Message-ID: <00b001bf2bc0$d30b94d0$[e-mail]>
From: "Anders Rundgren" <[e-mail]>
To: "'SEIS-List'" <[e-mail]>, "'Stefan Santesson'" <[e-mail]>, <[e-mail]>
Cc: "Magnus (RSA)" <[e-mail]>
Subject: QC container ID support
Date: Wed, 10 Nov 1999 21:16:15 -0000
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 4.72.3110.5
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by ns.secondary.com id MAA11844

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




Received: from atdev1.alphatrust.com ([209.39.43.35]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id LAA11227 for <[e-mail]>; Wed, 10 Nov 1999 11:33:29 -0800 (PST)
Received: by ATDEV1 with Internet Mail Service (5.5.2448.0) id <VWDA82R2>; Wed, 10 Nov 1999 13:37:22 -0600
Message-ID: <9E60D6A452AAD211904E00105A1973FD072949@ATDEV1>
From: "Bill Brice (listserv)" <[e-mail]>
To: "'[e-mail]'" <[e-mail]>, Stephen Kent <[e-mail]>
Cc: "David P. Kemp" <[e-mail]>, [e-mail]
Subject: Re: QC UID support must depart from RFC2459
Date: Wed, 10 Nov 1999 13:37:16 -0600
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2448.0)
Content-Type: text/plain; charset="windows-1252"

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:[e-mail]]
Sent: Wednesday, November 10, 1999 12:37 PM
To: Stephen Kent
Cc: David P. Kemp; [e-mail]
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



Received: from smtpproxy1.mitre.org (mbunix.mitre.org [129.83.20.100]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id KAA10275 for <[e-mail]>; Wed, 10 Nov 1999 10:32:02 -0800 (PST)
Received: from avsrv1.mitre.org (avsrv1.mitre.org [129.83.20.58]) by smtpproxy1.mitre.org (8.9.3/8.9.3) with ESMTP id NAA28103; Wed, 10 Nov 1999 13:32:49 -0500 (EST)
Received: from MAILHUB2 (mailhub2.mitre.org [129.83.221.18]) by smtpsrv1.mitre.org (8.9.3/8.9.3) with ESMTP id NAA05372; Wed, 10 Nov 1999 13:30:55 -0500 (EST)
Received: from lepton.mitre.org (128.29.166.226) by mailhub2.mitre.org with SMTP id 2004163; Wed, 10 Nov 1999 13:32:46 EST
Message-ID: <[e-mail]>
Date: Wed, 10 Nov 1999 13:36:52 -0500
From: schaen <[e-mail]>
Reply-To: [e-mail]
Organization: MITRE
X-Mailer: Mozilla 4.7 [en] (WinNT; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Stephen Kent <[e-mail]>
CC: "David P. Kemp" <[e-mail]>, [e-mail]
Subject: DOD Plans [was: Re: QC UID support must depart from RFC2459]
References: <[e-mail]> <v04220808b44f456d1657@[128.33.238.32]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

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




Received: from po1.bbn.com (PO1.BBN.COM [192.1.50.38]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id IAA07998 for <[e-mail]>; Wed, 10 Nov 1999 08:14:40 -0800 (PST)
Received: from [128.33.238.32] (TC052.BBN.COM [128.33.238.52]) by po1.bbn.com (8.9.1/8.9.1) with ESMTP id LAA20266; Wed, 10 Nov 1999 11:15:05 -0500 (EST)
Mime-Version: 1.0
Message-Id: <v04220807b44f40d70162@[128.33.238.32]>
In-Reply-To: <003901bf2b53$56f3ee50$[e-mail]>
References: <003901bf2b53$56f3ee50$[e-mail]>
Date: Wed, 10 Nov 1999 10:50:05 -0500
To: "Anders Rundgren" <[e-mail]>
From: Stephen Kent <[e-mail]>
Subject: Re: QC: VERISIGN uses UIDs!
Cc: "Stefan Santesson" <[e-mail]>, "'SEIS-List'" <[e-mail]>, <[e-mail]>
Content-Type: text/plain; charset="us-ascii" ; format="flowed"

>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



Received: from po1.bbn.com (PO1.BBN.COM [192.1.50.38]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id IAA07961 for <[e-mail]>; Wed, 10 Nov 1999 08:14:31 -0800 (PST)
Received: from [128.33.238.32] (TC052.BBN.COM [128.33.238.52]) by po1.bbn.com (8.9.1/8.9.1) with ESMTP id LAA20280; Wed, 10 Nov 1999 11:15:15 -0500 (EST)
Mime-Version: 1.0
Message-Id: <v04220808b44f456d1657@[128.33.238.32]>
In-Reply-To: <[e-mail]>
References: <[e-mail]>
Date: Wed, 10 Nov 1999 11:14:07 -0500
To: "David P. Kemp" <[e-mail]>
From: Stephen Kent <[e-mail]>
Subject: Re: QC UID support must depart from RFC2459
Cc: [e-mail]
Content-Type: text/plain; charset="us-ascii" ; format="flowed"

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


Received: from popmail.inbox.se (popmail.inbox.se [193.12.72.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id HAA07395 for <[e-mail]>; Wed, 10 Nov 1999 07:49:27 -0800 (PST)
Received: from best-laptop (dhcp22-fh72.fh.ietf.innovationslab.net [130.128.22.72]) by popmail.inbox.se (8.9.3/8.9.3) with SMTP id QAA09079; Wed, 10 Nov 1999 16:50:10 +0100
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 
Date: Wed, 10 Nov 1999 10:50:21 -0500
To: "David P. Kemp" <[e-mail]>, [e-mail]
From: Stefan Santesson <[e-mail]>
Subject: Re: QC UID support must depart from RFC2459
Cc: "Anders Rundgren" <[e-mail]>
In-Reply-To: <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"

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" <[e-mail]>
>> From: Stephen Kent <[e-mail]>
>> 
>> 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
>>



Received: from po1.bbn.com (PO1.BBN.COM [192.1.50.38]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id HAA06613 for <[e-mail]>; Wed, 10 Nov 1999 07:22:12 -0800 (PST)
Received: from [128.33.238.32] (TC032.BBN.COM [128.33.238.32]) by po1.bbn.com (8.9.1/8.9.1) with ESMTP id KAA11747; Wed, 10 Nov 1999 10:22:36 -0500 (EST)
Mime-Version: 1.0
Message-Id: <v04220801b44f36708e36@[128.33.238.97]>
In-Reply-To: <[e-mail]>
References: <[e-mail]>
Date: Wed, 10 Nov 1999 10:12:00 -0500
To: "Bob Jueneman" <[e-mail]>
From: Stephen Kent <[e-mail]>
Subject: Re: QC: VERISIGN uses UIDs!
Cc: <[e-mail]>, <[e-mail]>
Content-Type: text/plain; charset="us-ascii" ; format="flowed"

>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



Received: from stargate.zergo.com.au (IDENT:[e-mail] [203.2.208.130]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id HAA06581 for <[e-mail]>; Wed, 10 Nov 1999 07:21:53 -0800 (PST)
Received: from sydneymail1.baltimore.com.au (sydneymail1.jp.zergo.com.au [192.168.71.5]) by stargate.zergo.com.au (8.9.1/8.8.7) with ESMTP id BAA11061 for <[e-mail]>; Thu, 11 Nov 1999 01:25:43 +1100
Received: by sydneymail1.jp.zergo.com.au with Internet Mail Service (5.5.2448.0) id <WTACY0QB>; Thu, 11 Nov 1999 02:23:16 +1100
Message-ID: <[e-mail]>
From: Michael Zolotarev <[e-mail]>
To: "'[e-mail]'" <[e-mail]>
Subject: IMPORTANT info for those who is staying in OMNI Shoreham. Please  read.
Date: Thu, 11 Nov 1999 02:23:15 +1100
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2448.0)
Content-Type: text/plain

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


Received: from stingray.missi.ncsc.mil (stingray.missi.ncsc.mil [144.51.50.20]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id GAA05321 for <[e-mail]>; Wed, 10 Nov 1999 06:06:48 -0800 (PST)
Received: from stingray.missi.ncsc.mil (root@localhost) by stingray.missi.ncsc.mil with ESMTP id JAA04052 for <[e-mail]>; Wed, 10 Nov 1999 09:07:57 -0500 (EST)
Received: from missi.ncsc.mil (depot.missi.ncsc.mil [144.51.60.1]) by stingray.missi.ncsc.mil with ESMTP id JAA04048 for <[e-mail]>; Wed, 10 Nov 1999 09:07:57 -0500 (EST)
Received: from ara.missi.ncsc.mil (ara.missi.ncsc.mil [144.51.58.9]) by missi.ncsc.mil (8.8.8/8.8.8) with ESMTP id JAA17625 for <[e-mail]>; Wed, 10 Nov 1999 09:07:16 -0500 (EST)
Received: from ara.missi.ncsc.mil (ara.missi.ncsc.mil [144.51.58.9]) by ara.missi.ncsc.mil (8.9.1b+Sun/8.9.1) with SMTP id JAA13133 for <[e-mail]>; Wed, 10 Nov 1999 09:03:22 -0500 (EST)
Message-Id: <[e-mail]>
Date: Wed, 10 Nov 1999 09:03:22 -0500 (EST)
From: "David P. Kemp" <[e-mail]>
Reply-To: "David P. Kemp" <[e-mail]>
Subject: Re: QC UID support must depart from RFC2459
To: [e-mail]
MIME-Version: 1.0
Content-Type: TEXT/plain; charset=us-ascii
Content-MD5: 6xR/2+AUBBMMLcR1heSRIQ==
X-Mailer: dtmail 1.3.0 CDE Version 1.3 SunOS 5.7 sun4u sparc

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" <[e-mail]>
> From: Stephen Kent <[e-mail]>
> 
> 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
>



Received: from imo11.mx.aol.com (imo11.mx.aol.com [198.81.17.1]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id FAA04537 for <[e-mail]>; Wed, 10 Nov 1999 05:23:48 -0800 (PST)
From: [e-mail]
Received: from [e-mail] by imo11.mx.aol.com (mail_out_v23.6.) id 8ZUFa03765 (4599); Wed, 10 Nov 1999 08:23:19 -0500 (EST)
Message-ID: <[e-mail]>
Date: Wed, 10 Nov 1999 08:23:19 EST
Subject: Re: QC: VERISIGN uses UIDs!
To: [e-mail], [e-mail], [e-mail], [e-mail]
CC: [e-mail]
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: AOL 4.0 for Windows 95 sub 26

Guys,

I think this discussion needs to be taken off line!

Charlie


Received: from aunt15.ausys.se (void1.ausys.se [62.20.78.253]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id BAA26919 for <[e-mail]>; Wed, 10 Nov 1999 01:34:18 -0800 (PST)
Received: by aunt15.ausys.se with Internet Mail Service (5.5.2650.21) id <WCBXZAKN>; Wed, 10 Nov 1999 10:34:29 +0100
Message-ID: <[e-mail]>
From: Simon Tardell <[e-mail]>
To: "'Michael Zolotarev'" <[e-mail]>
Cc: "'[e-mail]'" <[e-mail]>
Subject: RE: Timestamp: 04: comments
Date: Wed, 10 Nov 1999 10:35:48 +0100
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain; charset="iso-8859-1"

> > 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,
[e-mail]
voice [phone], cell [phone], fax [phone]
European IT-prize grand winners 1998 -- http://www.it-prize.org
AU-System Group Swedish IT-company of the year 1999



 


Received: from caesar.udac.se (caesar.udac.se [193.44.79.10]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id XAA21735 for <[e-mail]>; Tue, 9 Nov 1999 23:15:04 -0800 (PST)
Received: from mega (t1o69p31.telia.com [62.20.144.31]) by caesar.udac.se (8.7.3/NetworkC-1) with SMTP id IAA01641; Wed, 10 Nov 1999 08:12:00 +0100
Message-ID: <003901bf2b53$56f3ee50$[e-mail]>
From: "Anders Rundgren" <[e-mail]>
To: "Stefan Santesson" <[e-mail]>, "'SEIS-List'" <[e-mail]>, <[e-mail]>
Cc: "Warwick Ford" <[e-mail]>
Subject: Re: QC: VERISIGN uses UIDs!
Date: Wed, 10 Nov 1999 08:12:31 -0000
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 4.72.3110.5
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by ns.secondary.com id XAA21736

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





Received: from prv-mail20.provo.novell.com (prv-mail20.provo.novell.com [137.65.82.195]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id TAA08533 for <[e-mail]>; Tue, 9 Nov 1999 19:45:51 -0800 (PST)
Received: from INET-PRV-Message_Server by prv-mail20.provo.novell.com with Novell_GroupWise; Tue, 09 Nov 1999 20:45:36 -0700
Message-Id: <[e-mail]>
X-Mailer: Novell GroupWise Internet Agent 5.5.2.1
Date: Tue, 09 Nov 1999 20:45:41 -0700
From: "Bob Jueneman" <[e-mail]>
To: <[e-mail]>, <[e-mail]>
Cc: <[e-mail]>
Subject: Re: QC: VERISIGN uses UIDs!
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by ns.secondary.com id TAA08535

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 <[e-mail]> 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



Received: from prv-mail20.provo.novell.com (prv-mail20.provo.novell.com [137.65.82.195]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id SAA02808 for <[e-mail]>; Tue, 9 Nov 1999 18:52:29 -0800 (PST)
Received: from INET-PRV-Message_Server by prv-mail20.provo.novell.com with Novell_GroupWise; Tue, 09 Nov 1999 19:52:26 -0700
Message-Id: <[e-mail]>
X-Mailer: Novell GroupWise Internet Agent 5.5.2.1
Date: Tue, 09 Nov 1999 19:52:29 -0700
From: "Bob Jueneman" <[e-mail]>
To: <[e-mail]>, <[e-mail]>, <[e-mail]>
Subject: RE: Licensed Certification Authorities in USA
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by ns.secondary.com id SAA02810

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" <[e-mail]> 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:[e-mail]] 
Sent: Tuesday, November 09, 1999 6:21 AM
To: [e-mail] 
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.



Received: from po1.bbn.com (PO1.BBN.COM [192.1.50.38]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id QAA25278 for <[e-mail]>; Tue, 9 Nov 1999 16:00:40 -0800 (PST)
Received: from [128.33.238.97] (TC097.BBN.COM [128.33.238.97]) by po1.bbn.com (8.9.1/8.9.1) with ESMTP id TAA05739; Tue, 9 Nov 1999 19:01:08 -0500 (EST)
Mime-Version: 1.0
X-Sender: [e-mail] (Unverified)
Message-Id: <v04220801b44e5001a4c2@[128.33.238.48]>
In-Reply-To: <001f01bf2935$319272f0$[e-mail]>
References: <001f01bf2935$319272f0$[e-mail]>
Date: Tue, 9 Nov 1999 17:29:24 -0500
To: "Anders Rundgren" <[e-mail]>
From: Stephen Kent <[e-mail]>
Subject: Re: QC: VERISIGN uses UIDs!
Cc: "'SEIS-List'" <[e-mail]>, <[e-mail]>
Content-Type: text/plain; charset="us-ascii" ; format="flowed"

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


Received: from stargate.zergo.com.au (IDENT:[e-mail] [203.2.208.130]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id NAA21363 for <[e-mail]>; Tue, 9 Nov 1999 13:12:33 -0800 (PST)
Received: from sydneymail1.baltimore.com.au (sydneymail1.jp.zergo.com.au [192.168.71.5]) by stargate.zergo.com.au (8.9.1/8.8.7) with ESMTP id HAA04149; Wed, 10 Nov 1999 07:16:18 +1100
Received: by sydneymail1.jp.zergo.com.au with Internet Mail Service (5.5.2448.0) id <WRKZPR44>; Wed, 10 Nov 1999 08:13:48 +1100
Message-ID: <[e-mail]>
From: Michael Zolotarev <[e-mail]>
To: "'Simon Tardell'" <[e-mail]>
Cc: [e-mail]
Subject: RE: Timestamp: 04: comments
Date: Wed, 10 Nov 1999 08:13:47 +1100
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2448.0)
Content-Type: text/plain

	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.




Received: from caesar.udac.se (caesar.udac.se [193.44.79.10]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id KAA18742 for <[e-mail]>; Tue, 9 Nov 1999 10:42:34 -0800 (PST)
Received: from mega (t1o69p17.telia.com [62.20.144.17]) by caesar.udac.se (8.7.3/NetworkC-1) with SMTP id TAA39927; Tue, 9 Nov 1999 19:38:08 +0100
Message-ID: <001401bf2aea$05f88470$[e-mail]>
From: "Anders Rundgren" <[e-mail]>
To: "Stephen Kent" <[e-mail]>, "'SEIS-List'" <[e-mail]>, "'Stefan Santesson'" <[e-mail]>, <[e-mail]>
Subject: Re: QC UID support must depart from RFC2459
Date: Tue, 9 Nov 1999 19:38:38 -0000
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 4.72.3110.5
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by ns.secondary.com id KAA18744

> Stephen Kent <[e-mail]>
>
>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



Received: from aunt15.ausys.se (void1.ausys.se [62.20.78.253]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id IAA16425 for <[e-mail]>; Tue, 9 Nov 1999 08:59:19 -0800 (PST)
Received: by aunt15.ausys.se with Internet Mail Service (5.5.2650.21) id <WCBXY75L>; Tue, 9 Nov 1999 17:59:23 +0100
Message-ID: <[e-mail]>
From: Simon Tardell <[e-mail]>
To: 
Cc: [e-mail]
Subject: RE: Timestamp: 04: comments
Date: Tue, 9 Nov 1999 18:00:30 +0100 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain; charset="iso-8859-1"

> > 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
[e-mail], http://www.iD2tech.com
voice [phone], cell [phone], fax [phone]
European IT-prize grand winners 1998 -- http://www.it-prize.org
AU-System Group Swedish IT-company of the year 1999



Received: from edelweb.fr (edelweb.fr [193.51.12.16]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id IAA14690 for <[e-mail]>; Tue, 9 Nov 1999 08:23:58 -0800 (PST)
Received: from champagne.edelweb.fr (localhost.edelweb.fr [127.0.0.1]) by edelweb.fr with ESMTP id RAA12278; Tue, 9 Nov 1999 17:24:25 +0100 (MET)
Received: from champagne.edelweb.fr (champagne.edelweb.fr [193.51.14.161]) by edelweb.fr (nospam/1.1); Tue, 9 Nov 1999 17:24:24 +0100 (MET)
Received: from emeriau.edelweb.fr (emeriau.edelweb.fr [193.51.14.5]) by champagne.edelweb.fr (8.7.6/8.6.6) with ESMTP id RAA12910; Tue, 9 Nov 1999 17:24:20 +0100 (MET)
From: Peter Sylvester <[e-mail]>
Received: (sylvest@localhost) by emeriau.edelweb.fr (8.7.6/8.6.6) id RAA04883; Tue, 9 Nov 1999 17:24:20 +0100 (MET)
Date: Tue, 9 Nov 1999 17:24:20 +0100 (MET)
Message-Id: <[e-mail]>
To: [e-mail], [e-mail]
Subject: Re: Timestamp: 04: comments
Cc: [e-mail]

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



 

 
 


Received: from dfw7-1.relay.mail.uu.net (dfw7-1.relay.mail.uu.net [199.171.54.106]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id HAA12576 for <[e-mail]>; Tue, 9 Nov 1999 07:17:30 -0800 (PST)
Received: from xedia.com by dfw7sosrv11.alter.net with SMTP  (peer crosschecked as: madway.xedia.com [198.202.232.199]) id QQhoph00257; Tue, 9 Nov 1999 15:17:55 GMT
Received: from tonga.xedia.com by xedia.com (4.1/SMI-4.1) id AA21451; Tue, 9 Nov 99 10:15:53 EST
Received: by tonga.xedia.com (SMI-8.6/SMI-SVR4) id KAA17650; Tue, 9 Nov 1999 10:17:53 -0500
Date: Tue, 9 Nov 1999 10:17:53 -0500
Message-Id: <[e-mail]>
From: Paul Koning <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
To: [e-mail]
Cc: [e-mail]
Subject: Re: Timestamp: 04: comments
References: <[e-mail]>
X-Mailer: VM 6.34 under 20.3 "Vatican City" XEmacs  Lucid

>>>>> Manger, James <[e-mail]> 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


Received: from mtiwmhc07.worldnet.att.net (mtiwmhc07.worldnet.att.net [204.127.131.42]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id GAA11704 for <[e-mail]>; Tue, 9 Nov 1999 06:49:35 -0800 (PST)
Received: from S1 ([12.64.117.168]) by mtiwmhc07.worldnet.att.net (InterMail v03.02.07.07 118-134) with SMTP id <19991109144936.JKRL23762@S1>; Tue, 9 Nov 1999 14:49:36 +0000
Reply-To: <[e-mail]>
From: "Russ Savage" <[e-mail]>
To: "Sweigert, David" <[e-mail]>, "Sungjin Lee" <[e-mail]>, <[e-mail]>
Subject: RE: Licensed Certification Authorities in USA
Date: Tue, 9 Nov 1999 07:51:57 -0700
Message-ID: <001501bf2ac1$f826a480$[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3155.0
Importance: Normal
In-Reply-To: <[e-mail]>

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:[e-mail]]
Sent: Tuesday, November 09, 1999 7:06 AM
To: Sungjin Lee; [e-mail]
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:[e-mail]]
Sent: Tuesday, November 09, 1999 6:21 AM
To: [e-mail]
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.



Received: from Newman.GSC.GTE.Com (Unknown.GSC.GTE.Com [192.160.62.66] (may be forged)) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id GAA09764 for <[e-mail]>; Tue, 9 Nov 1999 06:05:38 -0800 (PST)
Received: from gscex01.gsc.gte.com ("port 1248"@gscex01.ndhm.gsc.gte.com [155.95.162.170]) by Newman.GSC.GTE.Com (PMDF V5.2-30 #29038) with ESMTP id <[e-mail]> for [e-mail]; Tue, 9 Nov 1999 09:06:08 -0400 (EDT)
Received: by GSCEX01.gsc.gte.com with Internet Mail Service (5.5.2448.0) id <V7Z3F0GX>; Tue, 09 Nov 1999 09:06:08 -0500
Content-return: allowed
Date: Tue, 09 Nov 1999 09:06:07 -0500
From: "Sweigert, David" <[e-mail]>
Subject: RE: Licensed Certification Authorities in USA
To: Sungjin Lee <[e-mail]>, [e-mail]
Message-id: <[e-mail]>
MIME-version: 1.0
X-Mailer: Internet Mail Service (5.5.2448.0)
Content-type: text/plain;	charset="KS_C_5601-1987"

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:[e-mail]]
Sent: Tuesday, November 09, 1999 6:21 AM
To: [e-mail]
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.


Received: from ns.koscom.co.kr (ns.koscom.co.kr [128.134.148.66]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id DAA06584 for <[e-mail]>; Tue, 9 Nov 1999 03:21:23 -0800 (PST)
Received: from koscom.co.kr ([128.134.151.24]) by ns.koscom.co.kr (8.9.1/8.9.1) with ESMTP id UAA20423 for <[e-mail]>; Tue, 9 Nov 1999 20:11:34 +0900 (KST)
Message-ID: <[e-mail]>
Date: Tue, 09 Nov 1999 20:21:20 +0900
From: Sungjin Lee <[e-mail]>
X-Mailer: Mozilla 4.7 [en] (Win98; I)
X-Accept-Language: en
MIME-Version: 1.0
To: [e-mail]
Subject: Licensed Certification Authorities in USA
Content-Type: text/plain; charset=EUC-KR
Content-Transfer-Encoding: 7bit

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.


Received: from po1.bbn.com (PO1.BBN.COM [192.1.50.38]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id SAA29585 for <[e-mail]>; Mon, 8 Nov 1999 18:40:13 -0800 (PST)
Received: from [128.33.238.48] (TC048.BBN.COM [128.33.238.48]) by po1.bbn.com (8.9.1/8.9.1) with ESMTP id VAA23931; Mon, 8 Nov 1999 21:40:40 -0500 (EST)
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
X-Sender: [e-mail] (Unverified)
Message-Id: <v04020a06b44ca6da6a58@[128.33.238.177]>
In-Reply-To: <004801bf27bb$31f34f60$[e-mail]>
Date: Mon, 8 Nov 1999 11:13:37 -0500
To: "Anders Rundgren" <[e-mail]>
From: Stephen Kent <[e-mail]>
Subject: Re: QC UID support must depart from RFC2459
Cc: "'SEIS-List'" <[e-mail]>, "'Stefan Santesson'" <[e-mail]>, <[e-mail]>

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


Received: from po1.bbn.com (PO1.BBN.COM [192.1.50.38]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id SAA29555 for <[e-mail]>; Mon, 8 Nov 1999 18:40:06 -0800 (PST)
Received: from [128.33.238.48] (TC048.BBN.COM [128.33.238.48]) by po1.bbn.com (8.9.1/8.9.1) with ESMTP id VAA23921; Mon, 8 Nov 1999 21:40:22 -0500 (EST)
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
X-Sender: [e-mail] (Unverified)
Message-Id: <v04020a05b44ca5eb31f0@[128.33.238.177]>
In-Reply-To: <000c01bf2698$b2746440$[e-mail]>
Date: Mon, 8 Nov 1999 11:11:18 -0500
To: "Anders Rundgren" <[e-mail]>
From: Stephen Kent <[e-mail]>
Subject: RE: QC comparisons are DEADLY serious!
Cc: <[e-mail]>, "'Stefan Santesson'" <[e-mail]>, "'SEIS-List'" <[e-mail]>

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


Received: from smtp-out2.bellatlantic.net (smtp-out2.bellatlantic.net [199.45.39.157]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id QAA22856 for <[e-mail]>; Mon, 8 Nov 1999 16:44:43 -0800 (PST)
Received: from ieca.com (adsl-151-200-26-46.bellatlantic.net [151.200.26.46]) by smtp-out2.bellatlantic.net (8.9.1/8.9.1) with ESMTP id TAA23744; Mon, 8 Nov 1999 19:50:42 -0500 (EST)
Message-ID: <[e-mail]>
Date: Mon, 08 Nov 1999 19:35:15 -0500
From: Sean Turner <[e-mail]>
Organization: IECA, Inc.
X-Mailer: Mozilla 4.7 [en] (Win98; U)
X-Accept-Language: en
MIME-Version: 1.0
To: [e-mail]
CC: PKIX <[e-mail]>
Subject: Re: Comments on draft-ietf-pkix-ac509prof-01.txt
References: <[e-mail]> <[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

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) [phone]
> 61 Fitzwilliam Lane,                    fax: [phone]
> Dublin 2.                mailto:[e-mail]
> Ireland                             http://www.baltimore.com

Cheers,

spt



Received: from mailo.vtcif.telstra.com.au (mailo.vtcif.telstra.com.au [202.12.144.17]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id QAA20913 for <[e-mail]>; Mon, 8 Nov 1999 16:12:13 -0800 (PST)
Received: (from uucp@localhost) by mailo.vtcif.telstra.com.au (8.8.2/8.6.9) id LAA22238 for <[e-mail]>; Tue, 9 Nov 1999 11:12:21 +1100 (EST)
Received: from maili.vtcif.telstra.com.au(202.12.142.17) via SMTP by mailo.vtcif.telstra.com.au, id smtpd0sfCqQ; Tue Nov  9 11:11:31 1999
Received: (from uucp@localhost) by maili.vtcif.telstra.com.au (8.8.2/8.6.9) id LAA12009 for <[e-mail]>; Tue, 9 Nov 1999 11:11:29 +1100 (EST)
Received: from mail.cdn.telstra.com.au(144.135.138.138) via SMTP by maili.vtcif.telstra.com.au, id smtpd0QKkII; Tue Nov  9 11:10:25 1999
Received: from v300x-nm02.corpmail.telstra.com.au (v300x-nm02.corpmail.telstra.com.au [172.172.2.13]) by mail.cdn.telstra.com.au (8.8.2/8.6.9) with ESMTP id LAA12894 for <[e-mail]>; Tue, 9 Nov 1999 11:10:24 +1100 (EST)
Message-Id: <[e-mail]>
Received: by v300x-nm02.corpmail.telstra.com.au with Internet Mail Service (5.5.2448.0) id <WPL0X7NX>; Tue, 9 Nov 1999 11:01:56 +1100
From: "Manger, James" <[e-mail]>
To: [e-mail]
Subject: Timestamp: 04: comments
Date: Tue, 9 Nov 1999 11:02:40 +1100 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2448.0)
Content-Type: multipart/mixed; boundary="----_=_NextPart_000_01BF2A45.9FB25FB0"

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

eJ8+IjoAAQaQCAAEAAAAAAABAAEAAQeQBgAIAAAA5AQAAAAAAADoAAEIgAcAGAAAAElQTS5NaWNy
b3NvZnQgTWFpbC5Ob3RlADEIAQSAAQAYAAAAVGltZXN0YW1wOiAwNDogY29tbWVudHMAMggBCYAB
ACEAAAA5RUMzNTI0NUMzOENEMzExQkQ0MDAwMTA0QjA4REJGMQAUBwEggAMADgAAAM8HCwAJAAsA
AQAzAAIAKwEBBYADAA4AAADPBwsACQALAAIAKAACACEBAQ2ABAACAAAAAgACAAEDkAYA/AcAAB4A
AAADAC4AAAAAAEAAOQBQ5De9RSq/AR4AcAABAAAACgAAAFNlbWFudGljcwAAAAIBcQABAAAAGwAA
AAG/HNGq4EJivcSIwBHTgR0ACMckQzgBBHsmmgACAQkQAQAAALsEAAC3BAAAcgcAAExaRnXZKm1o
AwAKAHJjcGcxMjX+MgD/AgYCpAPkBesCgwBQEwNUAgBjaArAc2V0/jIGAAbDAoMOUAPVBxMCg/oz
E819CoAIzwnZAoAKgYMOcQtgbmczMDgAUEJoBbB6ZG9jAAAq7RJVIAKRGXBsGaUK+xTiMwHQFDBj
YwhwANB5OiEKhVdoeSAEACAxBiASsAWgbmQgdGgEZSAOcWF1bHQ/MCAgVGgdURKwZW1HBCADkQrA
Yml0HFBykR0wZmlnCHBlLh7SRwSQHjAdUW5vIBbAYVJzAiAgdx0hYxZQY7ZrBCAD8GwDIBKAdh4w
vx4QHVEA0Bw0HUAAgHQh0Fkd8G9mH5EdMG8eEXL1INFJJPB5CGAhsiMAHTB+dwBwBUAdgR+QBCAe
GSwMIHUSsB4DQVNOLmUdgXkCMGF4HgAhoHP+cAWQBpAdMCOCHJYMgiPICFswXRwHIERFRrBBVUxU
HZUqcDEKhWJJHZB1Z2cHkAVAazUJ4HALgGceAyBwZWw7JMEFMGkCIAdAKCBidZ8FQAPwHhAhgh5V
IHYHQP8KUCWkAaASsAIwKCAhkSSA/mEkkAeAJtEdUQDADnAycfcIYAVAI9coEuApkC7QBjEzA1Ie
A3NhB4Ae4FNB7yJgA5EkgCLyYh4wB4AAcN0vEWYekCaBBaBtCrEJgOwpLgqFCoVUNYIcliEB/x4A
B3IBkDjANWQdQh4SBGBbLqEHcHAWYSbCZiHQdPsgpyGxcQpQLqEpJR1RHnDdBcBsB5AEIDz4KCAA
IyH3IXMdoQhxdB0wIeAh8CnwPzNRHfAw0yAAOSAe0FJl/wWwBIEeBBxQAYApjDsfIGHjEqAoEWdp
di8SIAAfIecpNABwHfBleAtTLxYSsPsDgTAQYzXBBbEh0BJwL4T/JaIfsT/AM1EFwB2hMBIoIOcO
cQuANDEgcANgKZAWMf9Jwz51LxJLEDs3OT0GYgdA/SGAdQbQBJA6fzuJIZAH4PtBAksQIgRgIZAp
kAMANwDfJnILgAUAIdEvESIvhUgC/1LhJIAFEEuwJoFTH1QlL4R6IiggZSNQA6AeEAhgZ/8xAB4S
SzRBBTfVJUQeAQOR/0dTVZNWCEHDHeVJ0QeABcD/PDIFEEcAUBEpkQDALtBbVf9V6h1AJPAeEgQB
ClAFwA5w6wCQFsBzOT1ONoFQrzuDZQCQZ0xgcichcTaCKLck4CSQSvRyLoAvhCkdQv5pDnBJcS+R
HfALgF2yC1D7VoEkkDpm41EyO+NStB8ADwIwV/Fm8QORRVNTQ/EEkHRJRB+QMKAeIEly70JjM1Be
0TCRZSggSAJm8e9j1ErgAhAg0UQgAEoxL1Q3RpMmYVJxKDCSGSBuJ/8FQD5yYQFl8Ej0HcNIAm91
z0UkHwALIDk9RXhk4QCQ+wIgKndFWDkhkQUBauIDIP9IQHMWH8EeM0xRHfAmAjdEf0xgQoEpkjNC
IiEzUB+TcP9nVDAhHZBYgS/BGSAk0AOgmRbAY2VG9AORdW56kbJvY/BpekKBdQ9uINH+QhLAS1M3
UiggJOA9kEnx/0hRXEJ1hh/wZ2BB0V3xSwEAU0VRVUVOQ0X4IE9GFDBreCRpcvg5NgUV4QCEEAAD
AP0/UgMAAB4AQhABAAAAJgAAADwwMDIwMDFiZjFjY2UkOGQzNDAyZTAkMTE0NmQ4ZDFATWlrZT4A
AAADACYAAAAAAAMANgAAAAAAHgAxQAEAAAAQAAAASk1BTkdFUjI5Mjg4RUYzAAMAGkAAAAAAHgAw
QAEAAAAQAAAASk1BTkdFUjI5Mjg4RUYzAAMAGUAAAAAAAgH5PwEAAABnAAAAAAAAANynQMjAQhAa
tLkIACsv4YIBAAAABgAAAC9PPVRFTFNUUkEvT1U9UUxEIEtJTkdTRk9SRC1TTUlUSC9DTj1NUyBN
QUlMIFJFQ0lQSUVOVFMvQ049Sk1BTkdFUjI5Mjg4RUYzAAAeAPg/AQAAAA4AAABNYW5nZXIsIEph
bWVzAAAAHgA4QAEAAAAQAAAASk1BTkdFUjI5Mjg4RUYzAAIB+z8BAAAAZwAAAAAAAADcp0DIwEIQ
GrS5CAArL+GCAQAAAAYAAAAvTz1URUxTVFJBL09VPVFMRCBLSU5HU0ZPUkQtU01JVEgvQ049TVMg
TUFJTCBSRUNJUElFTlRTL0NOPUpNQU5HRVIyOTI4OEVGMwAAHgD6PwEAAAAOAAAATWFuZ2VyLCBK
YW1lcwAAAB4AOUABAAAAEAAAAEpNQU5HRVIyOTI4OEVGMwBAAAcwsAR7l+MgvwFAAAgwsF+yn0Uq
vwEeAD0AAQAAAAEAAAAAAAAAHgAdDgEAAAAYAAAAVGltZXN0YW1wOiAwNDogY29tbWVudHMACwAp
AAAAAAALACMAAAAAAAMABhA/5ekVAwAHEP8EAAADABAQAAAAAAMAERABAAAAHgAIEAEAAABlAAAA
QUNDVVJBQ1k6V0hZSVMxU0VDT05EVEhFREVGQVVMVD9USElTU0VFTVNBTkFSQklUUkFSWUZJR1VS
RVRIRVJFSVNOT1JFQVNPTldIWUNMT0NLU1dJTExIQVZFVEhJU0FDQ1VSQQAAAAD/Ng==

------_=_NextPart_000_01BF2A45.9FB25FB0--


Received: from vasfw03.fdic.gov (vasfw03.fdic.gov [192.147.69.46]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id LAA03667 for <[e-mail]>; Mon, 8 Nov 1999 11:33:32 -0800 (PST)
Received: by vasfw03.fdic.gov; id OAA27046; Mon, 8 Nov 1999 14:33:36 -0500
Received: from s00exc101(151.174.4.145) by vasfw03.fdic.gov via smap (V4.2) id xma026940; Mon, 8 Nov 99 14:32:52 -0500
Received: by s00exc101.fdic.gov with Internet Mail Service (5.5.2448.0) id <WP93P3K1>; Mon, 8 Nov 1999 14:33:01 -0500
Message-ID: <[e-mail]>
From: "Patterson, G. Shaun" <[e-mail]>
To: "'[e-mail]'" <[e-mail]>
Date: Mon, 8 Nov 1999 14:32:51 -0500 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2448.0)
Content-Type: text/plain; charset="iso-8859-1"

subscribe


Received: from vasfw03.fdic.gov (vasfw03.fdic.gov [192.147.69.46]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id KAA02241 for <[e-mail]>; Mon, 8 Nov 1999 10:06:12 -0800 (PST)
Received: by vasfw03.fdic.gov; id NAA07132; Mon, 8 Nov 1999 13:06:06 -0500
Received: from s00exc101(151.174.4.145) by vasfw03.fdic.gov via smap (V4.2) id xma007056; Mon, 8 Nov 99 13:05:05 -0500
Received: by s00exc101.fdic.gov with Internet Mail Service (5.5.2448.0) id <WP93PJ18>; Mon, 8 Nov 1999 13:05:16 -0500
Message-ID: <[e-mail]>
From: "Patterson, G. Shaun" <[e-mail]>
To: "'[e-mail]'" <[e-mail]>
Date: Mon, 8 Nov 1999 13:05:05 -0500 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2448.0)
Content-Type: text/plain; charset="iso-8859-1"

suscribe


Received: from gnasher.sol.co.uk (gnasher.sol.co.uk [194.247.65.2]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id JAA01722 for <[e-mail]>; Mon, 8 Nov 1999 09:38:14 -0800 (PST)
Received: from npwork2 (e2h1p187.scotland.net [148.176.237.188]) by gnasher.sol.co.uk (8.8.5/8.8.5) with SMTP id RAA20504; Mon, 8 Nov 1999 17:38:43 GMT
From: "Nick Pope" <[e-mail]>
To: "DENIS PINKAS" <[e-mail]>, "IETF-PXIX" <[e-mail]>
Cc: "JOHN ROSS" <[e-mail]>
Subject: time-stamp ASN.1 module
Date: Mon, 8 Nov 1999 17:44:20 -0000
Message-ID: <000801bf2a10$e33ad430$0500000a@npwork2>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3

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



Received: from balinese.baltimore.ie ([e-mail] [194.125.215.8]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id FAA27171 for <[e-mail]>; Mon, 8 Nov 1999 05:49:48 -0800 (PST)
Received: by balinese.baltimore.ie; id NAA19059; Mon, 8 Nov 1999 13:50:21 GMT
Received: from unknown(192.168.20.10) by balinese.baltimore.ie via smap (V4.2) id xma019005; Mon, 8 Nov 99 13:49:51 GMT
Received: from baltimore.ie ([192.168.20.119]) by bobcat.baltimore.ie (8.9.3/8.9.3) with ESMTP id NAA11124; Mon, 8 Nov 1999 13:49:42 GMT
Message-ID: <[e-mail]>
Date: Sun, 07 Nov 1999 17:06:41 +0000
From: Stephen Farrell <[e-mail]>
Reply-To: [e-mail]
Organization: Baltimore Technologies Ltd.
X-Mailer: Mozilla 4.6 [en] (WinNT; I)
X-Accept-Language: en
MIME-Version: 1.0
To: "Linn, John" <[e-mail]>
CC: [e-mail], xme <[e-mail]>
Subject: Re: I-D ACTION:draft-ietf-pkix-laap-00.txt
References: <[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

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) [phone]
61 Fitzwilliam Lane,                    fax: [phone]
Dublin 2.                mailto:[e-mail]
Ireland                             http://www.baltimore.com



Received: from balinese.baltimore.ie ([e-mail] [194.125.215.8]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id FAA27172 for <[e-mail]>; Mon, 8 Nov 1999 05:49:48 -0800 (PST)
Received: by balinese.baltimore.ie; id NAA19060; Mon, 8 Nov 1999 13:50:21 GMT
Received: from unknown(192.168.20.10) by balinese.baltimore.ie via smap (V4.2) id xma018962; Mon, 8 Nov 99 13:49:25 GMT
Received: from baltimore.ie ([192.168.20.119]) by bobcat.baltimore.ie (8.9.3/8.9.3) with ESMTP id NAA11086; Mon, 8 Nov 1999 13:49:09 GMT
Message-ID: <[e-mail]>
Date: Sun, 07 Nov 1999 16:57:59 +0000
From: Stephen Farrell <[e-mail]>
Reply-To: [e-mail]
Organization: Baltimore Technologies Ltd.
X-Mailer: Mozilla 4.6 [en] (WinNT; I)
X-Accept-Language: en
MIME-Version: 1.0
To: Sean Turner <[e-mail]>
CC: [e-mail], [e-mail], xme <[e-mail]>
Subject: Re: LAAP performance issues
References: <01c601bf21e5$f9c09b00$[e-mail]> <[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

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) [phone]
61 Fitzwilliam Lane,                    fax: [phone]
Dublin 2.                mailto:[e-mail]
Ireland                             http://www.baltimore.com




Received: from balinese.baltimore.ie ([e-mail] [194.125.215.8]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id FAA27037 for <[e-mail]>; Mon, 8 Nov 1999 05:48:48 -0800 (PST)
Received: by balinese.baltimore.ie; id NAA18917; Mon, 8 Nov 1999 13:49:20 GMT
Received: from unknown(192.168.20.10) by balinese.baltimore.ie via smap (V4.2) id xma018850; Mon, 8 Nov 99 13:48:50 GMT
Received: from baltimore.ie ([192.168.20.119]) by bobcat.baltimore.ie (8.9.3/8.9.3) with ESMTP id NAA11034; Mon, 8 Nov 1999 13:48:32 GMT
Message-ID: <[e-mail]>
Date: Sun, 07 Nov 1999 16:52:58 +0000
From: Stephen Farrell <[e-mail]>
Reply-To: [e-mail]
Organization: Baltimore Technologies Ltd.
X-Mailer: Mozilla 4.6 [en] (WinNT; I)
X-Accept-Language: en
MIME-Version: 1.0
To: Denis Pinkas <[e-mail]>
CC: IETF-PXIX <[e-mail]>, xme <[e-mail]>
Subject: Re: Comments on ac509prof-01
References: <[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

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) [phone]
61 Fitzwilliam Lane,                    fax: [phone]
Dublin 2.                mailto:[e-mail]
Ireland                             http://www.baltimore.com




Received: from balinese.baltimore.ie ([e-mail] [194.125.215.8]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id FAA27038 for <[e-mail]>; Mon, 8 Nov 1999 05:48:48 -0800 (PST)
Received: by balinese.baltimore.ie; id NAA18922; Mon, 8 Nov 1999 13:49:21 GMT
Received: from unknown(192.168.20.10) by balinese.baltimore.ie via smap (V4.2) id xma018878; Mon, 8 Nov 99 13:49:05 GMT
Received: from baltimore.ie ([192.168.20.119]) by bobcat.baltimore.ie (8.9.3/8.9.3) with ESMTP id NAA11079; Mon, 8 Nov 1999 13:48:56 GMT
Message-ID: <[e-mail]>
Date: Sun, 07 Nov 1999 16:56:17 +0000
From: Stephen Farrell <[e-mail]>
Reply-To: [e-mail]
Organization: Baltimore Technologies Ltd.
X-Mailer: Mozilla 4.6 [en] (WinNT; I)
X-Accept-Language: en
MIME-Version: 1.0
To: Andy Dowling <[e-mail]>
CC: [e-mail], [e-mail], xme <[e-mail]>
Subject: Re: LAAP performance issues
References: <01c601bf21e5$f9c09b00$[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

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) [phone]
61 Fitzwilliam Lane,                    fax: [phone]
Dublin 2.                mailto:[e-mail]
Ireland                             http://www.baltimore.com




Received: from caladan.verisign.com (caladan.verisign.com [205.180.232.21]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id OAA12839 for <[e-mail]>; Sun, 7 Nov 1999 14:55:12 -0800 (PST)
Received: from mentat.verisign.com by caladan.verisign.com (8.8.5/BCH1.5) id OAA12209; Sun, 7 Nov 1999 14:53:15 -0800 (PST)
Received: from newman.verisign.com by mentat.verisign.com (8.8.5/BCH1.0) id OAA01910; Sun, 7 Nov 1999 14:54:28 -0800 (PST)
Received: by newman.verisign.com with Internet Mail Service (5.5.2448.0) id <WKTYYTWZ>; Sun, 7 Nov 1999 14:55:10 -0800
Message-ID: <[e-mail]>
From: Warwick Ford <[e-mail]>
To: [e-mail]
Subject: Washington PKIX Agenda
Date: Sun, 7 Nov 1999 14:55:05 -0800 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2448.0)
Content-Type: text/plain; charset="ISO-8859-1"

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       [e-mail]         Fax [phone]
---------------------------------------------------------------------



Received: from caesar.udac.se (caesar.udac.se [193.44.79.10]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id GAA09686 for <[e-mail]>; Sun, 7 Nov 1999 06:34:30 -0800 (PST)
Received: from mega (t2o69p53.telia.com [62.20.144.173]) by caesar.udac.se (8.7.3/NetworkC-1) with SMTP id PAA47476; Sun, 7 Nov 1999 15:31:15 +0100
Message-ID: <001f01bf2935$319272f0$[e-mail]>
From: "Anders Rundgren" <[e-mail]>
To: "'SEIS-List'" <[e-mail]>, "'Stefan Santesson'" <[e-mail]>, <[e-mail]>
Cc: "Magnus (RSA)" <[e-mail]>, "Phillip M Hallam-Baker" <[e-mail]>, <[e-mail]>
Subject: QC: VERISIGN uses UIDs!
Date: Sun, 7 Nov 1999 15:31:41 -0000
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 4.72.3110.5
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by ns.secondary.com id GAA09687

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 <[e-mail]>
To: 'SEIS-List' <[e-mail]>; 'Stefan Santesson' <[e-mail]>; [e-mail] <[e-mail]>
Cc: Magnus (RSA) <[e-mail]>
Date: Friday, November 05, 1999 17:27
Subject: QC UID support must depart from RFC2459


>
>>Stephen Kent <[e-mail]>
>>
>>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
>
>
>
>



Received: from csmes.ncsl.nist.gov (csmes.ncsl.nist.gov [129.6.54.2]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id MAA25954 for <[e-mail]>; Sat, 6 Nov 1999 12:29:02 -0800 (PST)
Received: from st26.ncsl.nist.gov (st26.ncsl.nist.gov [129.6.54.72]) by csmes.ncsl.nist.gov (8.6.12/8.6.4jck0) with ESMTP id PAA00420; Sat, 6 Nov 1999 15:00:00 -0500
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58 
Date: Sat, 06 Nov 1999 14:59:11 -0500
To: [e-mail], [e-mail]
From: "David A. Cooper" <[e-mail]>
Subject: FYI: Announcement of a security requirements document for CAs
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"

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



Received: from dfw7-1.relay.mail.uu.net (dfw7-1.relay.mail.uu.net [199.171.54.106]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id NAA02544 for <[e-mail]>; Fri, 5 Nov 1999 13:05:25 -0800 (PST)
Received: from xedia.com by dfw7sosrv11.alter.net with SMTP  (peer crosschecked as: madway.xedia.com [198.202.232.199]) id QQhobk01654; Fri, 5 Nov 1999 21:05:39 GMT
Received: from tonga.xedia.com by xedia.com (4.1/SMI-4.1) id AA15754; Fri, 5 Nov 99 16:03:36 EST
Received: by tonga.xedia.com (SMI-8.6/SMI-SVR4) id QAA10722; Fri, 5 Nov 1999 16:05:34 -0500
Date: Fri, 5 Nov 1999 16:05:34 -0500
Message-Id: <[e-mail]>
From: Paul Koning <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
To: [e-mail]
Cc: [e-mail]
Subject: RE: PKIX: String representation of GeneralName
References: <[e-mail]>
X-Mailer: VM 6.34 under 20.3 "Vatican City" XEmacs  Lucid

>>>>> "Manger" == Manger, James <[e-mail]> 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


Received: from gatekeeper.entrust.com (gatekeeper.entrust.com [204.101.128.170]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id MAA02160 for <[e-mail]>; Fri, 5 Nov 1999 12:56:09 -0800 (PST)
Received: 	id PAA07108; Fri, 5 Nov 1999 15:52:03 -0500
Received: by gateway id <43HHRH11>; Fri, 5 Nov 1999 15:54:47 -0500
Message-ID: <[e-mail]>
From: Carlisle Adams <[e-mail]>
To: "'[e-mail]'" <[e-mail]>
Cc: [e-mail]
Subject: RE: Last Call: Diffie-Hellman Proof-of-Possession Algorithms to P roposed Standard
Date: Fri, 5 Nov 1999 15:54:47 -0500 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2448.0)
Content-Type: text/plain

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:[e-mail]]
> Reply To: 	[e-mail]
> Sent: 	Wednesday, October 13, 1999 7:32 AM
> To: 	IETF-Announce
> Cc: 	[e-mail]
> 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
> [e-mail] or [e-mail] mailing lists by October 27, 1999.
> 
> Files can be obtained via
> http://www.ietf.org/internet-drafts/draft-ietf-pkix-dhpop-02.txt
> 
> 


Received: from gandalf.trustpoint.com (IDENT:[e-mail] [216.100.231.61]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id MAA02126 for <[e-mail]>; Fri, 5 Nov 1999 12:56:01 -0800 (PST)
Received: from mobile (mobile [192.168.42.7]) by gandalf.trustpoint.com (8.8.7/8.8.7) with SMTP id MAA30284 for <[e-mail]>; Fri, 5 Nov 1999 12:56:25 -0800
From: "Amit Kapoor" <[e-mail]>
To: "PKIX" <[e-mail]>
Subject: FW: PKIX: String representation of GeneralName
Date: Fri, 5 Nov 1999 12:50:52 -0800
Message-ID: <002b01bf27cf$72ba9fd0$[e-mail]>
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="----=_NextPart_000_002C_01BF278C.64975FD0"
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.2106.4
Importance: Normal
X-MS-TNEF-Correlator: 0000000019D988B397A6D211BD3100104BF22416E4BD2A00

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:"[e-mail]"

	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:[e-mail]]
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"

eJ8+IjQUAQaQCAAEAAAAAAABAAEAAQeQBgAIAAAA5AQAAAAAAADoAAEIgAcAGAAAAElQTS5NaWNy
b3NvZnQgTWFpbC5Ob3RlADEIAQ2ABAACAAAAAgACAAEIAAUABAAAAAAAAAAAAAEJAAQAAgAAAAAA
AAABBoADAA4AAADPBwsABQAMADIAAAAFACkBAQOQBgBwBAAAKgAAAAsAAgABAAAACwAjAAAAAAAD
ACYAAAAAAAsAKQAAAAAACwArAAAAAAADAC4AAAAAAAMANgAAAAAAHgBNAAEAAAABAAAAAAAAAB4A
cAABAAAAJQAAAFN0cmluZyByZXByZXNlbnRhdGlvbiBvZiBHZW5lcmFsTmFtZQAAAAACAXEAAQAA
ACUAAAABvyS6qbRXAIkpkKwR0654AAjHJK3SAGZe1msAXNuNIAABwsAgAAAACwAXDAAAAAACAR0M
AQAAABkAAABTTVRQOkFNSVRAVFJVU1RQT0lOVC5DT00AAAAACwABDgAAAABAAAYOAExdU88nvwEC
AQoOAQAAABgAAAAAAAAAGdmIs5em0hG9MQAQS/IkFsKAAAALAB8OAQAAAAMABhAAAAAAAwAHEAAA
AAAeAAgQAQAAAAIAAAAEAAAAAwAQECh8ygADABEQoKDKAAsAAYAIIAYAAAAAAMAAAAAAAABGAAAA
AAOFAAAAAAAAAwADgAggBgAAAAAAwAAAAAAAAEYAAAAAEIUAAAAAAAADAAeACCAGAAAAAADAAAAA
AAAARgAAAABShQAAPBgAAB4ACIAIIAYAAAAAAMAAAAAAAABGAAAAAFSFAAABAAAABAAAADguNQAL
AAyACCAGAAAAAADAAAAAAAAARgAAAAAGhQAAAAAAAAMADYAIIAYAAAAAAMAAAAAAAABGAAAAAAGF
AAAAAAAACwAWgAggBgAAAAAAwAAAAAAAAEYAAAAADoUAAAAAAAADABeACCAGAAAAAADAAAAAAAAA
RgAAAAARhQAAAAAAAAMAGYAIIAYAAAAAAMAAAAAAAABGAAAAABiFAAAAAAAAHgAogAggBgAAAAAA
wAAAAAAAAEYAAAAANoUAAAEAAAABAAAAAAAAAB4AKYAIIAYAAAAAAMAAAAAAAABGAAAAADeFAAAB
AAAAAQAAAAAAAAAeACqACCAGAAAAAADAAAAAAAAARgAAAAA4hQAAAQAAAAEAAAAAAAAACwAygAgg
BgAAAAAAwAAAAAAAAEYAAAAAgoUAAAEAAAALADSACyAGAAAAAADAAAAAAAAARgAAAAAAiAAAAAAA
AAsANoALIAYAAAAAAMAAAAAAAABGAAAAAAWIAAAAAAAAAgH4DwEAAAAQAAAAGdmIs5em0hG9MQAQ
S/IkFgIB+g8BAAAAEAAAABnZiLOXptIRvTEAEEvyJBYCAfsPAQAAAIgAAAAAAAAAOKG7EAXlEBqh
uwgAKypWwgAAUFNUUFJYLkRMTAAAAAAAAAAATklUQfm/uAEAqgA32W4AAABDOlxXSU5OVFxQcm9m
aWxlc1xBZG1pbmlzdHJhdG9yXEFwcGxpY2F0aW9uIERhdGFcTWljcm9zb2Z0XE91dGxvb2tcb3V0
bG9vay5wc3QAAwD+DwUAAAADAA00/TcAAAIBfwABAAAAMQAAADAwMDAwMDAwMTlEOTg4QjM5N0E2
RDIxMUJEMzEwMDEwNEJGMjI0MTZFNEJEMkEwMAAAAAAFqg==

------=_NextPart_000_002C_01BF278C.64975FD0--



Received: from gandalf.trustpoint.com (IDENT:[e-mail] [216.100.231.61]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id MAA01839 for <[e-mail]>; Fri, 5 Nov 1999 12:40:19 -0800 (PST)
Received: from mobile (mobile [192.168.42.7]) by gandalf.trustpoint.com (8.8.7/8.8.7) with SMTP id MAA30195 for <[e-mail]>; Fri, 5 Nov 1999 12:40:42 -0800
From: "Amit Kapoor" <[e-mail]>
To: "PKIX" <[e-mail]>
Subject: FW: PKIX: String representation of GeneralName
Date: Fri, 5 Nov 1999 12:35:10 -0800
Message-ID: <002701bf27cd$40f9e0c0$[e-mail]>
MIME-Version: 1.0
Content-Type: application/x-pkcs7-mime; name="smime.p7m"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7m"
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.2106.4
Importance: Normal

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAaCAJIAEDE1JTUUt
VmVyc2lvbgQCOiAEAzEuMAQCDQoEDENvbnRlbnQtVHlwZQQCOiAED211bHRpcGFydC9taXhlZAQE
Ow0KCQQIYm91bmRhcnkEAT0EASIEKS0tLS09X05leHRQYXJ0XzAwMF8wMDIwXzAxQkYyNzhBLjMx
RDc4MDQwBAEiBAINCgQJWC1NaW1lT0xFBAI6IAQqUHJvZHVjZWQgQnkgTWljcm9zb2Z0IE1pbWVP
TEUgVjQuNzIuMjEwNi40BAINCgQUWC1NUy1UTkVGLUNvcnJlbGF0b3IEAjogBDAwMDAwMDAwMDE5
RDk4OEIzOTdBNkQyMTFCRDMxMDAxMDRCRjIyNDE2MDRCRDJBMDAEAg0KBAINCgQuVGhpcyBpcyBh
IG11bHRpLXBhcnQgbWVzc2FnZSBpbiBNSU1FIGZvcm1hdC4NCgQCDQoEAi0tBCktLS0tPV9OZXh0
UGFydF8wMDBfMDAyMF8wMUJGMjc4QS4zMUQ3ODA0MAQCDQoEDENvbnRlbnQtVHlwZQQCOiAECnRl
eHQvcGxhaW4EBDsNCgkEB2NoYXJzZXQEAT0EASIECmlzby04ODU5LTEEASIEAg0KBBlDb250ZW50
LVRyYW5zZmVyLUVuY29kaW5nBAI6IAQEN2JpdAQCDQoEAg0KBIINKQ0KSGkgSmFtZXMsDQoNCglZ
b3UgYXJlIHJpZ2h0LCBpbiB0aGF0IHRoZXJlIGlzIGEgc3RhbmRhcmRpemVkIHN0cmluZyByZXBy
ZXNlbnRhdGlvbiBmb3INCmFueSBBU04uMSBvYmplY3QuICBIb3dldmVyDQoJaGVyZSBhcmUgb3Vy
IHJlYXNvbnMgZm9yIG5vdCB1c2luZyBpdCwgYW5kIEkgYmVsaWV2ZSB5b3VyIGV4YW1wbGVzDQpk
ZW1vbnN0cmF0ZSB0aGUgc2FtZToNCg0KMS4JSXQgaXMgbm90IHVzZXIgcmVhZGFibGUgYXMgaW4g
dGhlIElQQWRkcmVzcy4gIEkgdGhpbmsgaXQgd2lsbCBiZSBhIHdlZQ0KYml0IGRpZmZpY3VsdCBm
b3Igc29tZW9uZQ0KCXRvIHRyYW5zbGF0ZSB0aGUgaGV4IGZvcm0gdG8gdGhlIHN0YW5kYXJkIGFu
ZCBtb3JlIGZyaWVuZGx5IGRvdHRlZCBmb3JtLg0KMi4JRE4gbmFtZSByZXByZXNlbnRhdGlvbi4g
KEJUVywgdGhhbmtzIHRvIFRvbSBHaW5kaW5ASUJNLCB3ZSBoYXZlIGNoYW5nZWQNCnRvIFJGQyAy
MjUzIGZvciBVVEY4IHN1cHBvcnQpDQoNCglJbnN0ZWFkIG9mIHRyeWluZyB0byBtaXggYW5kIG1h
dGNoIHR3byBzZXBhcmF0ZSBzY2hlbWVzLCB3ZSB0cmllZCB0byBjb21lDQp1cCB3aXRoIG9uZSBz
aW5nbGUNCglzY2VuYXJpby4gICBXZSBhbHNvIGFkZGVkICJpbnR1aXRpdmUgZm9ybWF0IiBhcyBv
bmUgb2YgdGhlIGdvYWxzIHVwZnJvbnQuDQpZb3UgaGF2ZQ0KCWFsc28gcHJvcG9zZWQgdGhlIHNh
bWUgdG8gc29tZSBleHRlbnQsIGFuZCB3aGF0IHdlIGFyZSBkaXNhZ3JlZWluZyBvbiBpcw0Kd2hp
Y2ggaXMNCgltb3JlICJpbnR1aXRpdmUiLg0KDQoJcmVnYXJkcw0KDQpBbWl0DQoNCi0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tDQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LQ0KDQoNCkFtaXQsDQoNClRoZXJlIGlzIGFscmVhZHkgYSBzdGFuZGFyZGl6ZWQgc3RyaW5nIHJl
cHJlc2VudGF0aW9uIG9mIEdlbmVyYWxOYW1lDQp2YWx1ZXMuICBJdCBpcyBBU04uMSB2YWx1ZSBu
b3RhdGlvbi4gIEFzIHN0YXRlZCBpbiB0aGUgWC42ODAgc3VtbWFyeSwNCkFTTi4xIHByb3ZpZGVz
ICJhIG5vdGF0aW9uIC4uIGZvciBzcGVjaWZ5aW5nIHZhbHVlcyBvZiB0aGVzZSBbQVNOLjFdDQp0
eXBlcyIuICBBbG1vc3QgYWxsIHNwZWNpZmljYXRpb25zIGRlZmluaW5nIEFTTi4xIHR5cGVzIGFs
c28gdXNlIHZhbHVlDQpub3RhdGlvbiB0byBkZWZpbmUgc29tZSB2YWx1ZXMsIGUuZy4gb2JqZWN0
IGlkZW50aWZpZXIgdmFsdWVzLCB2ZXJzaW9uDQp2YWx1ZXMsIGRlZmF1bHQgdmFsdWVzLCBhbGdv
cml0aG0gaWRlbnRpZmllciB2YWx1ZXMgZXRjLg0KDQpCZWxvdyBhcmUgdGhlIGV4YW1wbGVzIGZy
b20geW91ciBkcmFmdCBpbiB2YWx1ZSBub3RhdGlvbjoNCg0KCXJmYzgyMk5hbWU6ImFtaXRAdHJ1
c3Rwb2ludC5jb20iDQoNCglkTlNOYW1lOiJnYW5kYWxmLnRydXN0cG9pbnQuY29tIg0KDQoJdW5p
Zm9ybVJlc291cmNlSWRlbnRpZmllcjoiaHR0cDovL3d3dy50cnVzdHBvaW50LmNvbS8iDQoNCglp
UEFkZHJlc3M6J0MwQTgwMDBBJ0gNCg0KCXJlZ2lzdGVyZWRJZDp7IDEgMiAzIDQgNSA2IH0NCg0K
VmFsdWUgbm90YXRpb24gbG9va3MgdmVyeSBzaW1pbGFyIHRvIHRoZSBub3RhdGlvbiBpbiBkcmFm
dC1nZW5lcmFsbmFtZS50eHQNCmZvciBtb3N0IGdlbmVyYWwgbmFtZSBjaG9pY2VzLiAgVGhlIG1h
am9yIGV4Y2VwdGlvbiBpcyBkaXJlY3RvcnkgbmFtZS4gIEENCmRpcmVjdG9yeSBuYW1lIGhhcyBz
dWNoIGEgcmljaCBzeW50YXggKGFuIG9yZGVyZWQgY29sbGVjdGlvbiBvZiBsZXZlbHMsDQplYWNo
IHdpdGggMSBvciBtb3JlIHZhbHVlcywgZWFjaCB2YWx1ZSB3aXRoIGFuIGFyYml0cmFyeSB0eXBl
KSB0aGF0IGl0IGlzDQphbHdheXMgZ29pbmcgdG8gYmUgYXdrd2FyZCB0byBkZXZpc2UgYSBodW1h
bi1mcmllbmRseSBub3RhdGlvbiBmb3IgYWxsDQpwb3NzaWJsZSB2YWx1ZXMuICBTbyBpdCBpcyBw
cm9iYWJseSByZWFzb25hYmxlIHRvIHVzZSBSRkMgMTc3OSBbRE5dIGZvcg0KdGhpcyBjaG9pY2U6
DQoNCglkaXJlY3RvcnlOYW1lOkNOPUFtaXQgS2Fwb29yLCBPPVRydXN0cG9pbnQsIEw9TW91bnRh
aW4gVmlldywNClNUPUNhbGlmb3JuaWEsIEM9VVMNCg0KWW91ciBsYWJlbHMgKGUuZy4gIm1haWwi
LCAiaXAiKSBtYXkgc2VlbSBlYXNpZXIgdGhhbiB0aGUgdmFsdWUgbm90YXRpb24NCmxhYmVscyAo
ZS5nLiAicmZjODIyTmFtZSIsICJpUEFkZHJlc3MiKSBidXQgdGhlIGxhdGVyIG1hdGNoIHByZWNp
c2VseSAmDQpvYnZpb3VzbHkgdG8gZmllbGRzIGluIHRoZSB0eXBlIGRlZmluaXRpb24uICBZb3Ug
Z2V0IHZhbHVlIG5vdGF0aW9uIGZvcg0KZnJlZSB3aGVuZXZlciBhIG5ldyBBU04uMSB0eXBlIGlz
IGRlZmluZWQuICBWYWx1ZSBub3RhdGlvbiBvZmZlcnMgYQ0Kbm90YXRpb24gZm9yIGFsbCB0aGUg
R2VuZXJhbE5hbWUgY2hvaWNlcyAoZS5nLiBvdGhlck5hbWUpLCBub3QganVzdCB0aGUgNg0KeW91
ciBkcmFmdCBsaXN0cy4gIFZhbHVlIG5vdGF0aW9uIG9mZmVycyBhIG5vdGF0aW9uIGZvciBhbGwg
cG9zc2libGUNCnZhbHVlcyAoZS5nLiB2YWx1ZXMgd2l0aCB1bnVzdWFsIG9yIHVucHJpbnRhYmxl
IGNoYXJhY3RlcnMpLiAgSXQgaXMgbGlrZWx5DQp0aGF0IGFueW9uZSB3YW50aW5nIGEgdGV4dCBy
ZXByZXNlbnRhdGlvbiBmb3IgR2VuZXJhbE5hbWUgdmFsdWVzIHRvZGF5DQp3aWxsIHdhbnQgYSB0
ZXh0IHJlcHJlc2VudGF0aW9uIGZvciB2YWx1ZXMgb2YgYW5vdGhlciBBU04uMSB0eXBlIHRvbW9y
cm93DQpzbyB2YWx1ZSBub3RhdGlvbiwgd2hpY2ggd29ya3MgZm9yIGFsbCBBU04uMSB0eXBlcywg
aXMgcHJlZmVyYWJsZS4NCg0KLS0tLS0tLS0tLQ0KRnJvbTogCUFtaXQgS2Fwb29yW1NNVFA6YW1p
dEB0cnVzdHBvaW50LmNvbV0NClNlbnQ6IAlUdWVzZGF5LCAyIE5vdmVtYmVyIDE5OTkgOTozNA0K
VG86IAlQS0lYDQpTdWJqZWN0OiAJU3RyaW5nIHJlcHJlc2VudGF0aW9uIG9mIEdlbmVyYWxOYW1l
DQoNCmEgZHJhZnQgdG8gZG9jdW1lbnQgYSBzdHJpbmcgcmVwcmVzZW50YXRpb24gb2YgR2VuZXJh
bE5hbWUNCg0KCWh0dHA6Ly93d3cudHJ1c3Rwb2ludC5jb20vZHJhZnQtZ2VuZXJhbG5hbWUudHh0
DQoNCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
DQpDZXJ0aWZpY2F0ZSBBdXRob3JpdHk6IGh0dHA6Ly93d3cuc21lbWUuY29tDQpDQSByb290IDog
aHR0cDovL3d3dy5zbWVtZS5jb20vZmFxX29wZXJhdGlvbmFsLmh0bWwjMTYNCi0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQoNCgQCDQoEAi0tBCkt
LS0tPV9OZXh0UGFydF8wMDBfMDAyMF8wMUJGMjc4QS4zMUQ3ODA0MAQCDQoEDENvbnRlbnQtVHlw
ZQQCOiAEE2FwcGxpY2F0aW9uL21zLXRuZWYEBDsNCgkEBG5hbWUEAT0EASIEC3dpbm1haWwuZGF0
BAEiBAINCgQZQ29udGVudC1UcmFuc2Zlci1FbmNvZGluZwQCOiAEBmJhc2U2NAQCDQoEE0NvbnRl
bnQtRGlzcG9zaXRpb24EAjogBAphdHRhY2htZW50BAQ7DQoJBAhmaWxlbmFtZQQBPQQBIgQLd2lu
bWFpbC5kYXQEASIEAg0KBAINCgSCBmJlSjgrSWdnVUFRYVFDQUFFQUFBQUFBQUJBQUVBQVFlUUJn
QUlBQUFBNUFRQUFBQUFBQURvQUFFSWdBY0FHQUFBQUVsUVRTNU5hV055DQpiM052Wm5RZ1RXRnBi
QzVPYjNSbEFERUlBUTJBQkFBQ0FBQUFBZ0FDQUFFSUFBVUFCQUFBQUFBQUFBQUFBQUVKQUFRQUFn
QUFBQUFBDQpBQUFCQm9BREFBNEFBQURQQndzQUJRQU1BQ01BQUFBRkFCb0JBUU9RQmdBUUJBQUFK
QUFBQUFzQUFnQUJBTklBQ3dBakFBQUFBQkFEDQpBQ1lBQUFBQUFBc0FLUUFBQUFBUUN3QXJBQUFB
M2FNREFDNEFBQUFBQUFNQU5nQUFBQUFBSGdCTkFBRUFBQUFCQUFBQUFBQUFBQjRBDQpjQUFCQUFB
QUpRQUFBRk4wY21sdVp5QnlaWEJ5WlhObGJuUmhkR2x2YmlCdlppQkhaVzVsY21Gc1RtRnRaUUFB
QUFBQ0FYRUFBUUFBDQpBQ0FBQUFBQnZ5UzZxYlJYQUlrcGtLd1IwNjU0QUFqSEpLM1NBR1plMW1z
QVhOdU5JQXNBRnd3QUFBQUFDd0FCRGdBQTBnQkFBQVlPDQpBRExzT3MwbnZ3RUNBUW9PQVFBQUFC
Z0FBQUFBQUFBQUdkbUlzNWVtMGhHOU1RQVFTL0lrRnNLQUFBQUxBQUdBQ0NBR0FBQUFBQURBDQpB
QUFBQUFBQVJnQUFBQUFEaFFBQUFBRGRvd01BQTRBSUlBWUFBQUFBQU1BQUFBQUFBQUJHQUFBQUFC
Q0ZBQUFBQUFBQUF3QUhnQWdnDQpCZ0FBQUFBQXdBQUFBQUFBQUVZQUFBQUFVb1VBQUR3WUFBQWVB
QWlBQ0NBR0FBQUFBQURBQUFBQUFBQUFSZ0FBQUFCVWhRQUFBUUFBDQpBQVFBQUFBNExqVUFDd0FN
Z0FnZ0JnQUFBQUFBd0FBQUFBQUFBRVlBQUFBQUJvVUFBQUFBQndBREFBMkFDQ0FHQUFBQUFBREFB
QUFBDQpBQUFBUmdBQUFBQUJoUUFBQUFBQUFBc0FGb0FJSUFZQUFBQUFBTUFBQUFBQUFBQkdBQUFB
QUE2RkFBQUFBQUFBQXdBWGdBZ2dCZ0FBDQpBQUFBd0FBQUFBQUFBRVlBQUFBQUVZVUFBQUFBQUFB
REFCbUFDQ0FHQUFBQUFBREFBQUFBQUFBQVJnQUFBQUFZaFFBQUFBQUFBQjRBDQpLSUFJSUFZQUFB
QUFBTUFBQUFBQUFBQkdBQUFBQURhRkFBQUJBQUFBQVFBQUFBQUFBQUFlQUNtQUNDQUdBQUFBQUFE
QUFBQUFBQUFBDQpSZ0FBQUFBM2hRQUFBUUFBQUFFQUFBQUFBQUFBSGdBcWdBZ2dCZ0FBQUFBQXdB
QUFBQUFBQUVZQUFBQUFPSVVBQUFFQUFBQUJBQUFBDQpBQUFBQUFzQU1vQUlJQVlBQUFBQUFNQUFB
QUFBQUFCR0FBQUFBSUtGQUFBQkFOSUFDd0EwZ0FzZ0JnQUFBQUFBd0FBQUFBQUFBRVlBDQpBQUFB
QUlnQUFBQUE5QThMQURhQUN5QUdBQUFBQUFEQUFBQUFBQUFBUmdBQUFBQUZpQUFBQUFBakFBSUIr
QThCQUFBQUVBQUFBQm5aDQppTE9YcHRJUnZURUFFRXZ5SkJZQ0Fmb1BBUUFBQUJBQUFBQVoyWWl6
bDZiU0ViMHhBQkJMOGlRV0FnSDdEd0VBQUFDSUFBQUFBQUFBDQpBRGlodXhBRjVSQWFvYnNJQUNz
cVZzSUFBRkJUVkZCU1dDNUVURXdBQUFBQUFBQUFBRTVKVkVINXY3Z0JBS29BTjlsdUFBQUFRenBj
DQpWMGxPVGxSY1VISnZabWxzWlhOY1FXUnRhVzVwYzNSeVlYUnZjbHhCY0hCc2FXTmhkR2x2YmlC
RVlYUmhYRTFwWTNKdmMyOW1kRnhQDQpkWFJzYjI5clhHOTFkR3h2YjJzdWNITjBBQU1BL2c4RkFB
QUFBd0FOTlAwM0FRQUxBQjhPQUFCaGJRSUJmd0FCQUFBQU1RQUFBREF3DQpNREF3TURBd01UbEVP
VGc0UWpNNU4wRTJSREl4TVVKRU16RXdNREV3TkVKR01qSTBNVFl3TkVKRU1rRXdNQUFBQUFDV3BB
PT0NCgQCDQoEAi0tBCktLS0tPV9OZXh0UGFydF8wMDBfMDAyMF8wMUJGMjc4QS4zMUQ3ODA0MAQC
LS0EAg0KBAAAAAAAAACgggPUMIID0DCCAzugAwIBAgIURDjWK6ClGkPVXNGYVBlCeQlSTo4wCwYJ
KoZIhvcNAQEFMDUxFjAUBgNVBAMTDVNNZW1lIFJvb3QgQ0ExDjAMBgNVBAoTBVNNZW1lMQswCQYD
VQQGEwJVUzAeFw05OTA2MjgwMDMwMTdaFw0wNDA2MjgwMDMwMTdaME8xEzARBgNVBAoTClRydXN0
cG9pbnQxFDASBgNVBAMTC0FtaXQgS2Fwb29yMSIwIAYJKoZIhvcNAQkBFhNhbWl0QHRydXN0cG9p
bnQuY29tMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQCz8zlEiT35ROp2ukb9RoU6PFN8KztL
2QIm0euhGANLdKz54q35F77o0ufGbdL6mzM4M6uCUvCfX35lunfJ5VcyxpgvL370nBybSX7BAYOT
wqHzFQDUxCyxVpb2tZqa0C9Bj4yN7hIcGNdrIIg/Igwnb1imTj0/W8pu6qAsH9lAUQIDAQABo4IB
xTCCAcEwHQYDVR0OBBYEFGjUHzBDwqMT3RoXzGLIEqx1cxzfMCEGA1UdIwQaBBgwFoAU2fhP5PYB
sY10rS5A8fUJuogl6o0wDgYDVR0PAQH/BAQDAgD4MCcGA1UdJQQgMB4GCCsGAQUFBwMCBggrBgEF
BQcDAwYIKwYBBQUHAwQwEQYJYIZIAYb4QgEBBAQDAgCwMB4GA1UdEQQXMBWBE2FtaXRAdHJ1c3Rw
b2ludC5jb20wTwYDVR0gBEgwRjBEBggrBgQBmFQeATA4MDYGCCsGAQUFBwIBFipodHRwOi8vd3d3
LnNtZW1lLmNvbS9zZXJ2aWNlYWdyZWVtZW50Lmh0bWwwQwYJYIZIAYb4QgEDBDYWNGh0dHA6Ly93
d3cuc21lbWUuY29tL3NlcnZsZXRzL3NtZW1lX2NhL2NoZWNrX3Jldm9rZWQwQAYJYIZIAYb4QgEH
BDMWMWh0dHA6Ly93d3cuc21lbWUuY29tL3NlcnZsZXRzL3NtZW1lX2NhL3JlbmV3X2NlcnQwOQYJ
YIZIAYb4QgEIBCwWKmh0dHA6Ly93d3cuc21lbWUuY29tL3NlcnZpY2VhZ3JlZW1lbnQuaHRtbDAL
BgkqhkiG9w0BAQUDgYEAVLvo3UPaiCgAQBQFXxvr+yQkG6O7zYydoqH1GUnt6UWKTDA8Z71IRuU+
1un/5BsO0BUiLCY4gTVc8RmLRxZ8tOI/ylrQFEGXkfjX1qgh96hlOxnPhHsTt4Z3uuwrft3IHMpu
eqKjafMk2HHsUkkOQDtVqMluGTy12RZEvoiPKZAxggH9MIIB+QIBATBNMDUxFjAUBgNVBAMTDVNN
ZW1lIFJvb3QgQ0ExDjAMBgNVBAoTBVNNZW1lMQswCQYDVQQGEwJVUwIURDjWK6ClGkPVXNGYVBlC
eQlSTo4wCQYFKw4DAhoFAKCCAQYwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0B
CQUxDxcNOTkxMTA1MjAzNTA5WjAjBgkqhkiG9w0BCQQxFgQU533VUTBPrNUALv7uoueiGhc8wnUw
SQYJKoZIhvcNAQkPMTwwOjAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwBwYFKw4DAgcwBwYF
Kw4DAhowCgYIKoZIhvcNAgUwXAYJKwYBBAGCNxAEMU8wTTA1MRYwFAYDVQQDEw1TTWVtZSBSb290
IENBMQ4wDAYDVQQKEwVTTWVtZTELMAkGA1UEBhMCVVMCFEQ41iugpRpD1VzRmFQZQnkJUk6OMA0G
CSqGSIb3DQEBAQUABIGAZFpaiIPEzQdPBnxGrdgzagM3VOl12l4KwAV9R2wVqaHzOy0XdyVaxRrO
Rtt6ynBV3154rpWNVsfj5+yNE5Z2rHh51+nW1dRgD9aQrJz2diB5yCHIBmZA66w6ps9r+nWkGkYI
eALbfwHA7gnCHk0d9aiqItv53IGO6q0dVGEVyvoAAAAAAAA=



Received: from caesar.udac.se (caesar.udac.se [193.44.79.10]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id JAA28471 for <[e-mail]>; Fri, 5 Nov 1999 09:28:46 -0800 (PST)
Received: from mega (t4o69p108.telia.com [62.20.145.228]) by caesar.udac.se (8.7.3/NetworkC-1) with SMTP id SAA41370; Fri, 5 Nov 1999 18:25:33 +0100
Message-ID: <004801bf27bb$31f34f60$[e-mail]>
From: "Anders Rundgren" <[e-mail]>
To: "'SEIS-List'" <[e-mail]>, "'Stefan Santesson'" <[e-mail]>, <[e-mail]>
Cc: "Magnus (RSA)" <[e-mail]>
Subject: QC UID support must depart from RFC2459
Date: Fri, 5 Nov 1999 18:25:52 -0000
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 4.72.3110.5
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by ns.secondary.com id JAA28472

>Stephen Kent <[e-mail]>
>
>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





Received: from email3.etsi.org (email3.etsi.fr [212.234.161.24]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id IAA27041 for <[e-mail]>; Fri, 5 Nov 1999 08:14:05 -0800 (PST)
Received: by EMAIL3 with Internet Mail Service (5.5.2448.0) id <VMT5HZY9>; Fri, 5 Nov 1999 16:15:05 -0000
Message-ID: <7B7F473688DBD211B56C00805F85906C6767E1@EMAIL2>
From: Scott Cadzow <[e-mail]>
To: "'Phillip M Hallam-Baker'" <[e-mail]>, [e-mail]
Subject: RE: Possible patent issue with UTCTime hack
Date: Fri, 5 Nov 1999 16:13:43 -0000 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2448.0)
Content-Type: text/plain; charset="iso-8859-1"

If it is fundemental it may not be enforcable as a patent. Consider the
wheel.

-----Original Message-----
From: Phillip M Hallam-Baker [mailto:[e-mail]]
Sent: 05 November 1999 17:11
To: [e-mail]
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


Received: from caladan.verisign.com (caladan.verisign.com [205.180.232.21]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id IAA26804 for <[e-mail]>; Fri, 5 Nov 1999 08:10:00 -0800 (PST)
Received: from mentat.verisign.com by caladan.verisign.com (8.8.5/BCH1.5) id IAA15547; Fri, 5 Nov 1999 08:07:52 -0800 (PST)
Received: from newman.verisign.com by mentat.verisign.com (8.8.5/BCH1.0) id IAA28428; Fri, 5 Nov 1999 08:09:08 -0800 (PST)
Received: from pbaker-pc.verisign.com ([192.168.7.110]) by newman.verisign.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2448.0) id W1MMD7G8; Fri, 5 Nov 1999 08:09:46 -0800
From: "Phillip M Hallam-Baker" <[e-mail]>
To: <[e-mail]>
Subject: RE: Possible patent issue with UTCTime hack
Date: Fri, 5 Nov 1999 11:11:18 -0500
Message-ID: <002101bf27a8$64df2d80$[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3
In-Reply-To: <[e-mail]>
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


Received: from prserv.net (out5.prserv.net [165.87.194.243]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id GAA24942 for <[e-mail]>; Fri, 5 Nov 1999 06:03:03 -0800 (PST)
Received: from ibm.net ([32.97.110.73]) by prserv.net (out5) with SMTP id <19991105140312243071uco8e>; Fri, 5 Nov 1999 14:03:12 +0000
Message-ID: <[e-mail]>
Date: Fri, 05 Nov 1999 09:06:40 -0500
From: Mike Williams <[e-mail]>
X-Mailer: Mozilla 4.5 [en] (Win98; U)
X-Accept-Language: en
MIME-Version: 1.0
To: pkix <[e-mail]>
Subject: Agenda for wg
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Is the agenda for the pkix wg meeting available yet?



Received: from getafix.fcpl.co.in (getafix.fcpl.co.in [196.1.104.8]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id FAA24311 for <[e-mail]>; Fri, 5 Nov 1999 05:13:55 -0800 (PST)
Received: from Risk.fcpl.co.in ([196.1.104.25]) by getafix.fcpl.co.in (post.office MTA v2.0 0613 ID# 291-17719) with SMTP id AAA96; Fri, 5 Nov 1999 18:48:06 +0530
Message-ID: <002b01bf2790$7bb9a0c0$[e-mail]>
From: "Parag Namjoshi" <[e-mail]>
To: "Denis Pinkas" <[e-mail]>
Cc: "IETF-PXIX" <[e-mail]>
References: <[e-mail]> <[e-mail]> <009001bf26c1$103f7100$[e-mail]> <[e-mail]>
Subject: Re: Comments on ETNRT
Date: Fri, 5 Nov 1999 18:50:08 +0530
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.00.2314.1300
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300

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




Received: from sfemail.bankofamerica.com (sfemail.bankofamerica.com [171.159.64.14]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id RAA17257; Thu, 4 Nov 1999 17:01:37 -0800 (PST)
Received: from sfimail.bankofamerica.com (sfimail.bankofamerica.com [171.182.72.13]) by sfemail.bankofamerica.com (8.9.1/8.9.1) with ESMTP id RAA10243; Thu, 4 Nov 1999 17:01:21 -0800 (PST)
Received: from smtpsw03 (smtpsw03.bankofamerica.com [165.48.14.143]) by sfimail.bankofamerica.com (8.9.1/8.9.1) with ESMTP id RAA17141; Thu, 4 Nov 1999 17:01:23 -0800 (PST)
Date: Thu, 04 Nov 1999 17:02:46 -0800
From: Mack Hicks <[e-mail]>
Subject: Real Life Example - RFC822 in a mergered firm
Cc: [e-mail], [e-mail]
Message-id: <[e-mail]>
MIME-version: 1.0
X-Mailer: Mozilla 4.6 [en] (WinNT; U)
Content-type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms90BE228F95E2D9D1FFFEC207"
X-Accept-Language: en
References: <[e-mail]>

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
     [e-mail]
internally.

But you can all call me: Mack
See you in DC.

--
-------------------------------------------------------------------
Mack Hicks, SVP     [e-mail]  ;-)
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

MIIKqAYJKoZIhvcNAQcCoIIKmTCCCpUCAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC
CDQwggT+MIIEZ6ADAgECAhBX6XsSCzdMQqrLlRj8TZyCMA0GCSqGSIb3DQEBBAUAMIHMMRcw
FQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29y
azFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5
IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRp
dmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkMB4XDTk5MDgyNjAwMDAw
MFoXDTAwMDgyNTIzNTk1OVowggEZMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UE
CxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9y
ZXBvc2l0b3J5L1JQQSBJbmNvcnAuIGJ5IFJlZi4sTElBQi5MVEQoYyk5ODEeMBwGA1UECxMV
UGVyc29uYSBOb3QgVmFsaWRhdGVkMTMwMQYDVQQLEypEaWdpdGFsIElEIENsYXNzIDEgLSBO
ZXRzY2FwZSBGdWxsIFNlcnZpY2UxEzARBgNVBAMUCk1hY2sgSGlja3MxKzApBgkqhkiG9w0B
CQEWHG1hY2suaGlja3NAYmFua29mYW1lcmljYS5jb20wgZ8wDQYJKoZIhvcNAQEBBQADgY0A
MIGJAoGBAMJPErtnuX1efSb0Oig/IuB0TJ46Gt9R+oz74ai7mgfI1HvqdNlSP7LA3pPJsOf2
rwDux/4/g3nHjPyT2GQCuxPYDsRuLsW9A+fxqTSGb0g05iOm9i6a555/CjXPXSQVD5DrRPTl
ozim/4sEPVQ6CsgkNJOyCV+cOrw6oypr9l9TAgMBAAGjggGPMIIBizAJBgNVHRMEAjAAMIGs
BgNVHSAEgaQwgaEwgZ4GC2CGSAGG+EUBBwEBMIGOMCgGCCsGAQUFBwIBFhxodHRwczovL3d3
dy52ZXJpc2lnbi5jb20vQ1BTMGIGCCsGAQUFBwICMFYwFRYOVmVyaVNpZ24sIEluYy4wAwIB
ARo9VmVyaVNpZ24ncyBDUFMgaW5jb3JwLiBieSByZWZlcmVuY2UgbGlhYi4gbHRkLiAoYyk5
NyBWZXJpU2lnbjARBglghkgBhvhCAQEEBAMCB4AwgYYGCmCGSAGG+EUBBgMEeBZ2ZDQ2NTJi
ZDYzZjIwNDcwMjkyOTg3NjNjOWQyZjI3NTA2OWM3MzU5YmVkMWIwNTlkYTc1YmM0YmM5NzAx
NzQ3ZGE1ZDNmMjE0MWJlYWRiMmJkMmU4OTIxZmE5NmFmMmQwMTE0OTk3YTFiMjQ2ZjRmM2Vh
NDUwYzAzBgNVHR8ELDAqMCigJqAkhiJodHRwOi8vY3JsLnZlcmlzaWduLmNvbS9jbGFzczEu
Y3JsMA0GCSqGSIb3DQEBBAUAA4GBAI134mwkOQpKdM8R8JXXNi1h0zL764AowM7zYu5zyHRP
eKdcjW+npKn1KRblonVDbwRvFs7vothdfM3UdUlc2juny5upPK5W06Ws9RT9co36Fv0Dyn5o
ch2rRoW+LdIhA9axMzDvdCocQ3O0pNnwCJrqdF+8VGcu2nJJEUCfroboMIIDLjCCApegAwIB
AgIRANJ2Lo0UDD19sqglXa/uDXUwDQYJKoZIhvcNAQECBQAwXzELMAkGA1UEBhMCVVMxFzAV
BgNVBAoTDlZlcmlTaWduLCBJbmMuMTcwNQYDVQQLEy5DbGFzcyAxIFB1YmxpYyBQcmltYXJ5
IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTk4MDUxMjAwMDAwMFoXDTA4MDUxMjIzNTk1
OVowgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVz
dCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIElu
Y29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAx
IENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQwgZ8wDQYJ
KoZIhvcNAQEBBQADgY0AMIGJAoGBALtaRIoEFrtV/QN6ii2UTxV4NrgNSrJvnFS/vOh3Kp25
8Gi7ldkxQXB6gUu5SBNWLccI4YRCq8CikqtEXKpC8IIOAukv+8I7u77JJwpdtrA2QjO1blSI
T4dKvxna+RXoD4e2HOPMxpqOf2okkuP84GW6p7F+78nbN2rISsgJBuSZAgMBAAGjfDB6MBEG
CWCGSAGG+EIBAQQEAwIBBjBHBgNVHSAEQDA+MDwGC2CGSAGG+EUBBwEBMC0wKwYIKwYBBQUH
AgEWH3d3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEwDwYDVR0TBAgwBgEB/wIBADAL
BgNVHQ8EBAMCAQYwDQYJKoZIhvcNAQECBQADgYEAiLg3O93alDcAraqf4YEBcR6Sam0v9vGd
08pkONwbmAwHhluFFWoPuUmFpJXxF31ntH8tLN2aQp7DPrSOquULBt7yVir6M8e+GddTTMO9
yOMXtaRJQmPswqYXD11YGkk8kFxVo2UgAP0YIOVfgqaxqJLFWGrBjQM868PNBaKQrm4xggI8
MIICOAIBATCB4TCBzDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlT
aWduIFRydXN0IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9y
eS9SUEEgSW5jb3JwLiBCeSBSZWYuLExJQUIuTFREKGMpOTgxSDBGBgNVBAMTP1ZlcmlTaWdu
IENsYXNzIDEgQ0EgSW5kaXZpZHVhbCBTdWJzY3JpYmVyLVBlcnNvbmEgTm90IFZhbGlkYXRl
ZAIQV+l7Egs3TEKqy5UY/E2cgjAJBgUrDgMCGgUAoIGxMBgGCSqGSIb3DQEJAzELBgkqhkiG
9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTk5MTEwNTAxMDI0NlowIwYJKoZIhvcNAQkEMRYEFFkR
008ZA9l0BZrSz92iskGLVuFQMFIGCSqGSIb3DQEJDzFFMEMwCgYIKoZIhvcNAwcwDgYIKoZI
hvcNAwICAgCAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgFAMA0GCCqGSIb3DQMCAgEoMA0GCSqG
SIb3DQEBAQUABIGAtk3TpjR8BGvWPVpyHklbolfhSrYP2Z2ghIX+LG3O1aJVUMDXO2ybxLYx
RPDeC9YKUoxTYAdGBOjx4sLLBjbKOgk9WIOFoaLux0u1Rky7sDIZ+KAAmsyzuwtgsbU+jnGV
b2bl2aSK3rLOZ/iwQy6znE4zW0tkXHKEvXLwvGdr3gA=
--------------ms90BE228F95E2D9D1FFFEC207--



Received: from stargate.zergo.com.au (IDENT:[e-mail] [203.2.208.130]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id PAA15981; Thu, 4 Nov 1999 15:45:26 -0800 (PST)
Received: from sydneymail1.baltimore.com.au (sydneymail1.jp.zergo.com.au [192.168.71.5]) by stargate.zergo.com.au (8.9.1/8.8.7) with ESMTP id KAA17613; Fri, 5 Nov 1999 10:48:11 +1100
Received: by sydneymail1.jp.zergo.com.au with Internet Mail Service (5.5.2448.0) id <WHJPWN7G>; Fri, 5 Nov 1999 10:46:25 +1100
Message-ID: <[e-mail]>
From: Greg Colla <[e-mail]>
To: [e-mail], [e-mail]
Subject: RE: Comparing rfc822 addresses to certificates
Date: Fri, 5 Nov 1999 10:46:24 +1100 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2448.0)
Content-Type: text/plain; charset="iso-8859-1"

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:[e-mail]]
Sent: Friday, November 05, 1999 5:35 AM
To: [e-mail]; [e-mail]
Cc: [e-mail]
Subject: Comparing rfc822 addresses to certificates


>[e-mail] 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" <[e-mail]> , in part
because
>>most e-mail packages would just as easily accept "President William
Jefferson
>>Clinton" <[e-mail]>. 
>
>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:

[e-mail] 

Steve [e-mail] 

Stephen [e-mail] 

Also,

Bob Jueneman <[e-mail]>

"Robert R. Jueneman" <[e-mail]> 

Robert "R." (Bob) Jueneman (the one who is not the 
horse thief) <[e-mail]> 

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) <[e-mail]> 

and then it will compare just the <[e-mail]> 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


Received: from edelweb.fr (edelweb.fr [193.51.12.16]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id LAA11847 for <[e-mail]>; Thu, 4 Nov 1999 11:20:41 -0800 (PST)
Received: from champagne.edelweb.fr (localhost.edelweb.fr [127.0.0.1]) by edelweb.fr with ESMTP id UAA12866; Thu, 4 Nov 1999 20:20:46 +0100 (MET)
Received: from champagne.edelweb.fr (champagne.edelweb.fr [193.51.14.161]) by edelweb.fr (nospam/1.1); Thu, 4 Nov 1999 20:20:45 +0100 (MET)
Received: from emeriau.edelweb.fr (emeriau.edelweb.fr [193.51.14.5]) by champagne.edelweb.fr (8.7.6/8.6.6) with ESMTP id UAA13681; Thu, 4 Nov 1999 20:20:45 +0100 (MET)
From: Peter Sylvester <[e-mail]>
Received: (sylvest@localhost) by emeriau.edelweb.fr (8.7.6/8.6.6) id UAA03046; Thu, 4 Nov 1999 20:20:44 +0100 (MET)
Date: Thu, 4 Nov 1999 20:20:44 +0100 (MET)
Message-Id: <[e-mail]>
To: [e-mail], [e-mail]
Subject: RE: QC certificates and Nationality
Cc: [e-mail]

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





Received: from prv-mail20.provo.novell.com (prv-mail20.provo.novell.com [137.65.82.195]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id KAA10812; Thu, 4 Nov 1999 10:35:15 -0800 (PST)
Received: from INET-PRV-Message_Server by prv-mail20.provo.novell.com with Novell_GroupWise; Thu, 04 Nov 1999 11:35:03 -0700
Message-Id: <[e-mail]>
X-Mailer: Novell GroupWise Internet Agent 5.5.2.1
Date: Thu, 04 Nov 1999 11:34:54 -0700
From: "Bob Jueneman" <[e-mail]>
To: <[e-mail]>, <[e-mail]>
Cc: <[e-mail]>
Subject: Comparing rfc822 addresses to certificates
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by ns.secondary.com id KAB10813

>[e-mail] 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" <[e-mail]> , in part because
>>most e-mail packages would just as easily accept "President William Jefferson
>>Clinton" <[e-mail]>. 
>
>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:

[e-mail] 

Steve [e-mail] 

Stephen [e-mail] 

Also,

Bob Jueneman <[e-mail]>

"Robert R. Jueneman" <[e-mail]> 

Robert "R." (Bob) Jueneman (the one who is not the 
horse thief) <[e-mail]> 

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) <[e-mail]> 

and then it will compare just the <[e-mail]> 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


Received: from mail.student.auckland.ac.nz (mail.student.auckland.ac.nz [130.216.35.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id KAA10078 for <[e-mail]>; Thu, 4 Nov 1999 10:00:08 -0800 (PST)
Received: from cs26.cs.auckland.ac.nz ([e-mail] [130.216.36.9]) by mail.student.auckland.ac.nz (8.9.3/8.8.6/cs-master) with SMTP id HAA10900 for <[e-mail]>; Fri, 5 Nov 1999 07:00:24 +1300 (NZDT) (sender [e-mail])
Received: by cs26.cs.auckland.ac.nz (relaymail v0.9) id <94173842416782>; Fri, 5 Nov 1999 07:00:24 (NZDT)
From: [e-mail] (Peter Gutmann)
To: [e-mail]
Subject: RE: QC certificates and Nationality
Sender: [e-mail]
Reply-To: [e-mail]
X-Charge-To: pgut001
X-Authenticated: relaymail v0.9 on cs26.cs.auckland.ac.nz
Date: Fri, 5 Nov 1999 07:00:24 (NZDT)
Message-ID: <[e-mail]>

"David P. Kemp" <[e-mail]>

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




Received: from stingray.missi.ncsc.mil (stingray.missi.ncsc.mil [144.51.50.20]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id JAA09472 for <[e-mail]>; Thu, 4 Nov 1999 09:32:39 -0800 (PST)
Received: from stingray.missi.ncsc.mil (root@localhost) by stingray.missi.ncsc.mil with ESMTP id MAA19038 for <[e-mail]>; Thu, 4 Nov 1999 12:33:19 -0500 (EST)
Received: from missi.ncsc.mil (depot.missi.ncsc.mil [144.51.60.1]) by stingray.missi.ncsc.mil with ESMTP id MAA19034 for <[e-mail]>; Thu, 4 Nov 1999 12:33:18 -0500 (EST)
Received: from ara.missi.ncsc.mil (ara.missi.ncsc.mil [144.51.58.9]) by missi.ncsc.mil (8.8.8/8.8.8) with ESMTP id MAA28532 for <[e-mail]>; Thu, 4 Nov 1999 12:32:38 -0500 (EST)
Received: from ara.missi.ncsc.mil (ara.missi.ncsc.mil [144.51.58.9]) by ara.missi.ncsc.mil (8.9.1b+Sun/8.9.1) with SMTP id MAA11298 for <[e-mail]>; Thu, 4 Nov 1999 12:28:56 -0500 (EST)
Message-Id: <[e-mail]>
Date: Thu, 4 Nov 1999 12:28:56 -0500 (EST)
From: "David P. Kemp" <[e-mail]>
Reply-To: "David P. Kemp" <[e-mail]>
Subject: RE: QC certificates and Nationality
To: [e-mail]
MIME-Version: 1.0
Content-Type: TEXT/plain; charset=us-ascii
Content-MD5: LGD9w2seCyBZ3b5OzQI0rQ==
X-Mailer: dtmail 1.3.0 CDE Version 1.3 SunOS 5.7 sun4u sparc

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



Received: from prv-mail20.provo.novell.com (prv-mail20.provo.novell.com [137.65.82.195]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id IAA08679 for <[e-mail]>; Thu, 4 Nov 1999 08:44:14 -0800 (PST)
Received: from INET-PRV-Message_Server by prv-mail20.provo.novell.com with Novell_GroupWise; Thu, 04 Nov 1999 09:44:02 -0700
Message-Id: <[e-mail]>
X-Mailer: Novell GroupWise Internet Agent 5.5.2.1
Date: Thu, 04 Nov 1999 09:43:48 -0700
From: "Bob Jueneman" <[e-mail]>
To: <[e-mail]>, <[e-mail]>
Subject: RE: QC certificates and Nationality
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by ns.secondary.com id IAA08680

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" <[e-mail]> 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



Received: from e2.ny.us.ibm.com (e2.ny.us.ibm.com [32.97.182.102]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id IAA08085 for <[e-mail]>; Thu, 4 Nov 1999 08:17:02 -0800 (PST)
From: [e-mail]
Received: from northrelay02.pok.ibm.com (northrelay02.pok.ibm.com [9.117.200.22]) by e2.ny.us.ibm.com (8.9.3/8.9.3) with ESMTP id LAA331762; Thu, 4 Nov 1999 11:16:31 -0500
Received: from D51MTA10.pok.ibm.com (d51mta10.pok.ibm.com [9.117.200.38]) by northrelay02.pok.ibm.com (8.8.8m2/NCO v2.06) with SMTP id LAA46256; Thu, 4 Nov 1999 11:17:13 -0500
Received: by D51MTA10.pok.ibm.com(Lotus SMTP MTA v4.6.5  (863.2 5-20-1999))  id 8525681F.00597251 ; Thu, 4 Nov 1999 11:16:59 -0500
X-Lotus-FromDomain: IBMUS
To: [e-mail]
cc: [e-mail]
Message-ID: <[e-mail]>
Date: Thu, 4 Nov 1999 11:16:26 -0500
Subject: Re: How to identify certs to users
Mime-Version: 1.0
Content-type: text/plain; charset=us-ascii
Content-Disposition: inline

     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




Received: from stingray.missi.ncsc.mil (stingray.missi.ncsc.mil [144.51.50.20]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id HAA07320 for <[e-mail]>; Thu, 4 Nov 1999 07:32:37 -0800 (PST)
Received: from stingray.missi.ncsc.mil (root@localhost) by stingray.missi.ncsc.mil with ESMTP id KAA12370 for <[e-mail]>; Thu, 4 Nov 1999 10:33:16 -0500 (EST)
Received: from missi.ncsc.mil (depot.missi.ncsc.mil [144.51.60.1]) by stingray.missi.ncsc.mil with ESMTP id KAA12366 for <[e-mail]>; Thu, 4 Nov 1999 10:33:16 -0500 (EST)
Received: from ara.missi.ncsc.mil (ara.missi.ncsc.mil [144.51.58.9]) by missi.ncsc.mil (8.8.8/8.8.8) with ESMTP id KAA26485 for <[e-mail]>; Thu, 4 Nov 1999 10:32:36 -0500 (EST)
Received: from ara.missi.ncsc.mil (ara.missi.ncsc.mil [144.51.58.9]) by ara.missi.ncsc.mil (8.9.1b+Sun/8.9.1) with SMTP id KAA11278 for <[e-mail]>; Thu, 4 Nov 1999 10:28:53 -0500 (EST)
Message-Id: <[e-mail]>
Date: Thu, 4 Nov 1999 10:28:53 -0500 (EST)
From: "David P. Kemp" <[e-mail]>
Reply-To: "David P. Kemp" <[e-mail]>
Subject: RE: QC certificates and Nationality
To: [e-mail]
MIME-Version: 1.0
Content-Type: TEXT/plain; charset=us-ascii
Content-MD5: FBOaP8rcPVKEdx+F6exPbw==
X-Mailer: dtmail 1.3.0 CDE Version 1.3 SunOS 5.7 sun4u sparc

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



Received: from edelweb.fr (edelweb.fr [193.51.12.16]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id HAA07000 for <[e-mail]>; Thu, 4 Nov 1999 07:23:54 -0800 (PST)
Received: from champagne.edelweb.fr (localhost.edelweb.fr [127.0.0.1]) by edelweb.fr with ESMTP id QAA09129; Thu, 4 Nov 1999 16:24:09 +0100 (MET)
Received: from champagne.edelweb.fr (champagne.edelweb.fr [193.51.14.161]) by edelweb.fr (nospam/1.1); Thu, 4 Nov 1999 16:24:09 +0100 (MET)
Received: from emeriau.edelweb.fr (emeriau.edelweb.fr [193.51.14.5]) by champagne.edelweb.fr (8.7.6/8.6.6) with ESMTP id QAA11929; Thu, 4 Nov 1999 16:24:08 +0100 (MET)
From: Peter Sylvester <[e-mail]>
Received: (sylvest@localhost) by emeriau.edelweb.fr (8.7.6/8.6.6) id QAA02999; Thu, 4 Nov 1999 16:24:08 +0100 (MET)
Date: Thu, 4 Nov 1999 16:24:08 +0100 (MET)
Message-Id: <[e-mail]>
To: [e-mail]
Subject: Re: Comments on the PKIX Roadmap
Cc: [e-mail]

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




Received: from mail.student.auckland.ac.nz (mail.student.auckland.ac.nz [130.216.35.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id GAA06465 for <[e-mail]>; Thu, 4 Nov 1999 06:53:44 -0800 (PST)
Received: from cs26.cs.auckland.ac.nz ([e-mail] [130.216.36.9]) by mail.student.auckland.ac.nz (8.9.3/8.8.6/cs-master) with SMTP id DAA08788; Fri, 5 Nov 1999 03:53:45 +1300 (NZDT) (sender [e-mail])
Received: by cs26.cs.auckland.ac.nz (relaymail v0.9) id <94172722407201>; Fri, 5 Nov 1999 03:53:44 (NZDT)
From: [e-mail] (Peter Gutmann)
To: [e-mail], [e-mail]
Subject: Re: QC comparisons are DEADLY serious!
Sender: [e-mail]
Reply-To: [e-mail]
X-Charge-To: pgut001
X-Authenticated: relaymail v0.9 on cs26.cs.auckland.ac.nz
Date: Fri, 5 Nov 1999 03:53:44 (NZDT)
Message-ID: <[e-mail]>

Stephen Kent <[e-mail]> 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.



Received: from clbull.frcl.bull.fr (clbull.frcl.bull.fr [129.182.8.31]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id GAA06218 for <[e-mail]>; Thu, 4 Nov 1999 06:46:28 -0800 (PST)
Received: from bull.net (frcls6118.frcl.bull.fr [129.182.109.213]) by clbull.frcl.bull.fr (8.9.2/8.9.1) with ESMTP id PAA43452; Thu, 4 Nov 1999 15:45:36 +0100
Message-ID: <[e-mail]>
Date: Thu, 04 Nov 1999 15:45:21 +0100
From: Denis Pinkas <[e-mail]>
Organization: Bull
X-Mailer: Mozilla 4.06 [fr] (Win95; I)
MIME-Version: 1.0
To: Parag Namjoshi <[e-mail]>
CC: IETF-PXIX <[e-mail]>
Subject: Comments on ETNPT
References: <[e-mail]> <[e-mail]> <009001bf26c1$103f7100$[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

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.


Received: from clbull.frcl.bull.fr (clbull.frcl.bull.fr [129.182.8.31]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id GAA05745 for <[e-mail]>; Thu, 4 Nov 1999 06:21:47 -0800 (PST)
Received: from bull.net (frcls6118.frcl.bull.fr [129.182.109.213]) by clbull.frcl.bull.fr (8.9.2/8.9.1) with ESMTP id PAA31680; Thu, 4 Nov 1999 15:21:09 +0100
Message-ID: <[e-mail]>
Date: Thu, 04 Nov 1999 15:20:55 +0100
From: Denis Pinkas <[e-mail]>
Organization: Bull
X-Mailer: Mozilla 4.06 [fr] (Win95; I)
MIME-Version: 1.0
To: Sean Turner <[e-mail]>
CC: IETF-PXIX <[e-mail]>
Subject: Re: Comments on the PKIX Roadmap
References: <[e-mail]> <[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

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


Received: from getafix.fcpl.co.in (getafix.fcpl.co.in [196.1.104.8]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id EAA03714 for <[e-mail]>; Thu, 4 Nov 1999 04:29:07 -0800 (PST)
Received: from Risk.fcpl.co.in ([196.1.104.25]) by getafix.fcpl.co.in (post.office MTA v2.0 0613 ID# 291-17719) with SMTP id AAA191; Thu, 4 Nov 1999 18:03:29 +0530
Message-ID: <009001bf26c1$103f7100$[e-mail]>
From: "Parag Namjoshi" <[e-mail]>
To: "Sean Turner" <[e-mail]>, "Denis Pinkas" <[e-mail]>
Cc: "IETF-PXIX" <[e-mail]>
References: <[e-mail]> <[e-mail]>
Subject: Re: Comments on the PKIX Roadmap
Date: Thu, 4 Nov 1999 18:05:22 +0530
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.00.2314.1300
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300

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





Received: from caesar.udac.se (caesar.udac.se [193.44.79.10]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id WAA27049 for <[e-mail]>; Wed, 3 Nov 1999 22:50:36 -0800 (PST)
Received: from mega (t3o69p56.telia.com [62.20.145.56]) by caesar.udac.se (8.7.3/NetworkC-1) with SMTP id HAA45241; Thu, 4 Nov 1999 07:46:08 +0100
Message-ID: <000c01bf2698$b2746440$[e-mail]>
From: "Anders Rundgren" <[e-mail]>
To: "Stephen Kent" <[e-mail]>, <[e-mail]>, "'Stefan Santesson'" <[e-mail]>, "'SEIS-List'" <[e-mail]>, "Magnus (RSA)" <[e-mail]>
Subject: RE: QC comparisons are DEADLY serious!
Date: Thu, 4 Nov 1999 07:46:24 -0000
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 4.72.3110.5
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by ns.secondary.com id WAA27050

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




Received: from po1.bbn.com (PO1.BBN.COM [192.1.50.38]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id TAA21867 for <[e-mail]>; Wed, 3 Nov 1999 19:44:41 -0800 (PST)
Received: from [128.33.238.74] (TC074.BBN.COM [128.33.238.74]) by po1.bbn.com (8.9.1/8.9.1) with ESMTP id WAA10975; Wed, 3 Nov 1999 22:44:38 -0500 (EST)
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Message-Id: <v04020a04b446b0331b26@[128.33.238.74]>
In-Reply-To: <003c01bf2612$c50be0a0$[e-mail]>
References: <04b001bf257f$40a14b90$[e-mail]> <[e-mail]>
Date: Wed, 3 Nov 1999 22:46:55 -0500
To: "Todd Glassey @ GMT" <[e-mail]>, "Michael Duren" <[e-mail]>
From: Stephen Kent <[e-mail]>
Subject: Re: Timestamping Standards.
Cc: <[e-mail]>

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


Received: from po1.bbn.com (PO1.BBN.COM [192.1.50.38]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id TAA21387 for <[e-mail]>; Wed, 3 Nov 1999 19:31:19 -0800 (PST)
Received: from [128.33.238.74] (TC074.BBN.COM [128.33.238.74]) by po1.bbn.com (8.9.1/8.9.1) with ESMTP id WAA10337; Wed, 3 Nov 1999 22:31:11 -0500 (EST)
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Message-Id: <v04020a02b446ae7bb39e@[128.33.238.74]>
In-Reply-To: <00b501bf2614$71467eb0$[e-mail]>
References: <[e-mail]>
Date: Wed, 3 Nov 1999 22:32:31 -0500
To: "Todd Glassey @ GMT" <[e-mail]>
From: Stephen Kent <[e-mail]>
Subject: Re: Possible patent issue with UTCTime hack
Cc: <[e-mail]>

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


Received: from po1.bbn.com (PO1.BBN.COM [192.1.50.38]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id TAA21302 for <[e-mail]>; Wed, 3 Nov 1999 19:31:01 -0800 (PST)
Received: from [128.33.238.74] (TC074.BBN.COM [128.33.238.74]) by po1.bbn.com (8.9.1/8.9.1) with ESMTP id WAA10327; Wed, 3 Nov 1999 22:31:08 -0500 (EST)
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Message-Id: <v04020a01b446ab31ecc3@[128.33.238.74]>
In-Reply-To: <01BF245B.8C005880@HYDRA>
Date: Wed, 3 Nov 1999 22:20:00 -0500
To: Anders Rundgren <[e-mail]>
From: Stephen Kent <[e-mail]>
Subject: RE: QC comparisons are DEADLY serious!
Cc: "[e-mail]" <[e-mail]>, "'Stefan Santesson'" 	 <[e-mail]>, "'SEIS-List'" <[e-mail]>, "Magnus (RSA)" <[e-mail]>

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


Received: from mail.student.auckland.ac.nz (mail.student.auckland.ac.nz [130.216.35.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id TAA20844 for <[e-mail]>; Wed, 3 Nov 1999 19:11:07 -0800 (PST)
Received: from cs26.cs.auckland.ac.nz ([e-mail] [130.216.36.9]) by mail.student.auckland.ac.nz (8.9.3/8.8.6/cs-master) with SMTP id QAA19171 for <[e-mail]>; Thu, 4 Nov 1999 16:11:18 +1300 (NZDT) (sender [e-mail])
Received: by cs26.cs.auckland.ac.nz (relaymail v0.9) id <94168507825082>; Thu, 4 Nov 1999 16:11:18 (NZDT)
From: [e-mail] (Peter Gutmann)
To: [e-mail]
Subject: Re: How to identify certs to users
Sender: [e-mail]
Reply-To: [e-mail]
X-Charge-To: pgut001
X-Authenticated: relaymail v0.9 on cs26.cs.auckland.ac.nz
Date: Thu, 4 Nov 1999 16:11:18 (NZDT)
Message-ID: <[e-mail]>

[e-mail] 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" <[e-mail]> , in part because
>most e-mail packages would just as easily accept "President William Jefferson
>Clinton" <[e-mail]>.

D'you mean they'll accept that as an rfc822Name?  Are they supposed to do that?

Peter.



Received: from Newman.GSC.GTE.Com (Unknown.GSC.GTE.Com [192.160.62.66] (may be forged)) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id SAA20037 for <[e-mail]>; Wed, 3 Nov 1999 18:30:30 -0800 (PST)
Received: from gscex02.gsc.gte.com ("port 3810"@gscex02.winnt.chnt.gsc.gte.com [131.131.133.151]) by Newman.GSC.GTE.Com (PMDF V5.2-30 #29038) with ESMTP id <[e-mail]> for [e-mail]; Wed, 3 Nov 1999 21:30:41 -0400 (EDT)
Received: by gscex02.winnt.chnt.gsc.gte.com with Internet Mail Service (5.5.2448.0)	id <V7G6FV70>; Wed, 03 Nov 1999 21:30:46 -0500
Content-return: allowed
Date: Wed, 03 Nov 1999 21:30:38 -0500
From: "Sweigert, David" <[e-mail]>
Subject: NIST key-based management ANSI X9.44
To: [e-mail], [e-mail], [e-mail]
Message-id: <[e-mail]>
MIME-version: 1.0
MIME-version: 1.0
X-MIMEOLE: Produced By Microsoft MimeOLE V4.72.3155.0
X-Mailer: Internet Mail Service (5.5.2448.0)
Content-type: multipart/signed; boundary="----=_NextPart_000_0029_01BF2640.19A3F080"; protocol="application/x-pkcs7-signature";	micalg=SHA-1

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 [phone];
Fax [phone], or email [e-mail].

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 [phone];</FONT>
<BR><FONT SIZE=3D2>Fax [phone], or email =
[e-mail].</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"

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIH9jCCAy4w
ggKXoAMCAQICEQDSdi6NFAw9fbKoJV2v7g11MA0GCSqGSIb3DQEBAgUAMF8xCzAJBgNVBAYTAlVT
MRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjE3MDUGA1UECxMuQ2xhc3MgMSBQdWJsaWMgUHJpbWFy
eSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTAeFw05ODA1MTIwMDAwMDBaFw0wODA1MTIyMzU5NTla
MIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0
d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5
IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRpdmlk
dWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkMIGfMA0GCSqGSIb3DQEBAQUAA4GN
ADCBiQKBgQC7WkSKBBa7Vf0DeootlE8VeDa4DUqyb5xUv7zodyqdufBou5XZMUFweoFLuUgTVi3H
COGEQqvAopKrRFyqQvCCDgLpL/vCO7u+yScKXbawNkIztW5UiE+HSr8Z2vkV6A+HthzjzMaajn9q
JJLj/OBluqexfu/J2zdqyErICQbkmQIDAQABo3wwejARBglghkgBhvhCAQEEBAMCAQYwRwYDVR0g
BEAwPjA8BgtghkgBhvhFAQcBATAtMCsGCCsGAQUFBwIBFh93d3cudmVyaXNpZ24uY29tL3JlcG9z
aXRvcnkvUlBBMA8GA1UdEwQIMAYBAf8CAQAwCwYDVR0PBAQDAgEGMA0GCSqGSIb3DQEBAgUAA4GB
AIi4Nzvd2pQ3AK2qn+GBAXEekmptL/bxndPKZDjcG5gMB4ZbhRVqD7lJhaSV8Rd9Z7R/LSzdmkKe
wz60jqrlCwbe8lYq+jPHvhnXU0zDvcjjF7WkSUJj7MKmFw9dWBpJPJBcVaNlIAD9GCDlX4KmsaiS
xVhqwY0DPOvDzQWikK5uMIIEwDCCBCmgAwIBAgIQUtDEuxEPkZyITAh1+InOPTANBgkqhkiG9w0B
AQQFADCBzDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0
IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEgSW5jb3Jw
LiBCeSBSZWYuLExJQUIuTFREKGMpOTgxSDBGBgNVBAMTP1ZlcmlTaWduIENsYXNzIDEgQ0EgSW5k
aXZpZHVhbCBTdWJzY3JpYmVyLVBlcnNvbmEgTm90IFZhbGlkYXRlZDAeFw05OTA2MjUwMDAwMDBa
Fw0wMDA2MjQyMzU5NTlaMIIBHzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZl
cmlTaWduIFRydXN0IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9y
eS9SUEEgSW5jb3JwLiBieSBSZWYuLExJQUIuTFREKGMpOTgxHjAcBgNVBAsTFVBlcnNvbmEgTm90
IFZhbGlkYXRlZDE0MDIGA1UECxMrRGlnaXRhbCBJRCBDbGFzcyAxIC0gTWljcm9zb2Z0IEZ1bGwg
U2VydmljZTEaMBgGA1UEAxQRRGF2aWQgRy4gU3dlaWdlcnQxKTAnBgkqhkiG9w0BCQEWGmRhdmlk
LnN3ZWlnZXJ0QGdzYy5ndGUuY29tMFwwDQYJKoZIhvcNAQEBBQADSwAwSAJBAJWvi792ZtTq32zO
assoDDTAYvwq2xb3FWGw5JtBlH1NmKUZeQPreM9VO9vg4A2GzLVua9ub+8sQ7TeMnXnRZacCAwEA
AaOCAY8wggGLMAkGA1UdEwQCMAAwgawGA1UdIASBpDCBoTCBngYLYIZIAYb4RQEHAQEwgY4wKAYI
KwYBBQUHAgEWHGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9DUFMwYgYIKwYBBQUHAgIwVjAVFg5W
ZXJpU2lnbiwgSW5jLjADAgEBGj1WZXJpU2lnbidzIENQUyBpbmNvcnAuIGJ5IHJlZmVyZW5jZSBs
aWFiLiBsdGQuIChjKTk3IFZlcmlTaWduMBEGCWCGSAGG+EIBAQQEAwIHgDCBhgYKYIZIAYb4RQEG
AwR4FnZkNDY1MmJkNjNmMjA0NzAyOTI5ODc2M2M5ZDJmMjc1MDY5YzczNTliZWQxYjA1OWRhNzVi
YzRiYzk3MDE3NDdkYTVkM2YyMTQxYmVhZGIyYmQyZTg5MjE0YWM2YmY1ZDExMTQ5OWRhM2I5NDdm
NGYzZWE0NTY0MDMGA1UdHwQsMCowKKAmoCSGImh0dHA6Ly9jcmwudmVyaXNpZ24uY29tL2NsYXNz
MS5jcmwwDQYJKoZIhvcNAQEEBQADgYEAU1i8lnqI3rxU8RHflaJMIsLecB+uCekSlXmBYoNjDLXQ
q2zdwNX67YFT3PiCqrSn+tDyDeJW1WNDXUt7alzfAwIqi541oEWosvXuN3xt5EZkyopZQJS7wI9U
H6yo36pyFQqCnoiDmSCVBvSVp6wWLPJf32/UaNYD93AHlBYph9AxggLSMIICzgIBATCB4TCBzDEX
MBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsx
RjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEgSW5jb3JwLiBCeSBSZWYu
LExJQUIuTFREKGMpOTgxSDBGBgNVBAMTP1ZlcmlTaWduIENsYXNzIDEgQ0EgSW5kaXZpZHVhbCBT
dWJzY3JpYmVyLVBlcnNvbmEgTm90IFZhbGlkYXRlZAIQUtDEuxEPkZyITAh1+InOPTAJBgUrDgMC
GgUAoIIBhzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw05OTExMDQw
MjEyMTNaMCMGCSqGSIb3DQEJBDEWBBSCZJ5IL1I56piNOYq/7zU5RjvfrjAzBgkqhkiG9w0BCQ8x
JjAkMA0GCCqGSIb3DQMCAgEoMAcGBSsOAwIaMAoGCCqGSIb3DQIFMIHyBgkrBgEEAYI3EAQxgeQw
geEwgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBO
ZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4g
QnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2
aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQCEFLQxLsRD5GciEwIdfiJzj0w
DQYJKoZIhvcNAQEBBQAEQI/oHWk/ZQDddumvSjuy6sThN6rmSkO3yegC639pqD31pkG6bvF/1XIh
38GgT9SSV9BiE/mvt9iH9QvXuHH9Jk0AAAAAAAA=

------=_NextPart_000_0029_01BF2640.19A3F080--



Received: from mailo.vtcif.telstra.com.au (mailo.vtcif.telstra.com.au [202.12.144.17]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id RAA18590 for <[e-mail]>; Wed, 3 Nov 1999 17:07:08 -0800 (PST)
Received: (from uucp@localhost) by mailo.vtcif.telstra.com.au (8.8.2/8.6.9) id MAA12924 for <[e-mail]>; Thu, 4 Nov 1999 12:06:52 +1100 (EST)
Received: from maili.vtcif.telstra.com.au(202.12.142.17) via SMTP by mailo.vtcif.telstra.com.au, id smtpdYkIeV_; Thu Nov  4 12:06:27 1999
Received: (from uucp@localhost) by maili.vtcif.telstra.com.au (8.8.2/8.6.9) id MAA19903 for <[e-mail]>; Thu, 4 Nov 1999 12:06:26 +1100 (EST)
Received: from mail.cdn.telstra.com.au(144.135.138.138) via SMTP by maili.vtcif.telstra.com.au, id smtpd0ZHNOt; Thu Nov  4 12:05:21 1999
Received: from v300x-nm02.corpmail.telstra.com.au (v300x-nm02.corpmail.telstra.com.au [172.172.2.13]) by mail.cdn.telstra.com.au (8.8.2/8.6.9) with ESMTP id MAA17859 for <[e-mail]>; Thu, 4 Nov 1999 12:04:57 +1100 (EST)
Message-Id: <[e-mail]>
Received: by v300x-nm02.corpmail.telstra.com.au with Internet Mail Service (5.5.2448.0) id <V7A72R1J>; Thu, 4 Nov 1999 11:56:42 +1100
From: "Manger, James" <[e-mail]>
To: PKIX <[e-mail]>
Subject: RE: PKIX: String representation of GeneralName
Date: Thu, 4 Nov 1999 12:00:20 +1100 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2448.0)
Content-Type: multipart/mixed; boundary="----_=_NextPart_000_01BF265F.72AB6250"

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:"[e-mail]"

	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:[e-mail]]
> 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

eJ8+IisAAQaQCAAEAAAAAAABAAEAAQeQBgAIAAAA5AQAAAAAAADoAAEIgAcAGAAAAElQTS5NaWNy
b3NvZnQgTWFpbC5Ob3RlADEIAQSAAQAvAAAAUkU6IFBLSVg6IFN0cmluZyByZXByZXNlbnRhdGlv
biBvZiBHZW5lcmFsTmFtZQBlEAEJgAEAIQAAADNFNEYyNEM2Mzg5MkQzMTFCRDQ1MDAxMDRCMDhE
QkYxAAsHASCAAwAOAAAAzwcLAAQACwA4ACUABABRAQEFgAMADgAAAM8HCwAEAAwAAAAUAAQACQEB
DYAEAAIAAAACAAIAAQOQBgDwCQAAHgAAAAMALgAAAAAAQAA5AAB0jvdfJr8BHgBwAAEAAAAlAAAA
U3RyaW5nIHJlcHJlc2VudGF0aW9uIG9mIEdlbmVyYWxOYW1lAAAAAAIBcQABAAAAGwAAAAG/JLqp
tFcAiSmQrBHTrngACMckrdIAZl7WawACAQkQAQAAAGkGAABlBgAAMAwAAExaRnUHdOsyAwAKAHJj
cGcxMjX+MgD/AgYCpAPkBesCgwBQEwNUAgBjaArAc2V0/jIGAAbDAoMOUAPVBxMCg7IzE89mNBA/
EUc1A8URAgBwcnES4nN0ZbptAoB9CoAIzwnZOxoPPQ4wNQKACoEOcQtgbmcoMzA4AFBoBbB6ZNRv
YwAAKhJVIAKRHhDebB5FCvsTsgwBYwBAFDAwbWl0LAqFCoVUaGkEkGUgBAAgB0AaEGG0ZHkioCAY
0ABwZAsRvGl6CYAjQQUQHRAgGhBPGGAHkAnwAZB0aQIgIHBvZiBHCfAEkAdATjJhB4AgdgdAClBz
LhggIEkFQCKBQVNOxi4g0CZzIG5vJRQm0T5BBCAjURjgJAALgCB0gSIwIFguNjgwI0DEdW0AwHJ5
LCdVGGDYb3ZpDnAEICIjMCgmnCAuJtACEAXAc3AFkH0GkHkkUiZ0JXIpoRKwICpbJ2NdKZB5LQBz
Iv0oomwEYBjQIqEDICz0DeD/JSMEIA5xC4AkUidkLyMiofBzbyB1LnEnzCmQMtAfMVMiYDLAJkcq
sGUuZ/Em0G9iagWQJxEOcAIw9zChBJA1B3YEkACQJVE1FnEOcWF1bAVANRYHQGdzBbAhEGhtNk8E
IBLAY/IuIUxCZRmgB+AKwCJgeSmiZXgmMAtQB5EDUiB+eQhhMUAl8AGAKWInzDqPIUwMgiSAEmA4
MjImIjY6K8AhAUAkMDLwdHCSbwuAdC4FoG0iP/9ZQQBkTidwQZNnI3JsbGYuQj9DT3UDACyxbcZS
B5AIYWNlSTZnQcCCaAJAcDovL3dJoA1FXS9GT0DxaVBBZAM+cAeQczonQzBBYyoQTQBBJ0hK70EB
ZR5nBAAY4BoRSHA6XHsGICDQEuAzIDQgNdwgNgMwHIIheVYzTBmg/G9rBCA3gSMQAJAhAAtgPwXA
NCEpoiv3KXE+cy1n7SXEbiYxRVB4BUAssi/T/1UFKBAmMhJwRcBIUCbCIiH5VjBhagWxPUBIUAUw
VDP9MTFpGhA2IAWwIxBVcyix7VltIBKAKOF1EnAjIQUQiVvxc3klAXggKAOR/wWwBIEj8RmBPZA2
ICVFPZD/N4AysDVxANBcAAPwKaBPgf9WEyJRNRdfMifEX3MDkQrA3mIhECXwUsEvIikpkSUg5yJw
JxMHQHdhGMBWgEXBiyRwNCFiImBhd2tj4N8LIDQUK2AucSMwaCpQAHDuLQNQCJAjgGxZ8SwGLLK3
MCJFsAQQaQJgJllTMtD7Y2QrMWIBoGbxItEywFVwR2iCNCEy8lJGQ0+AN+Q3OS6QRE4vACyyKaA/
IoFXZD/vRCJZhkGDQ07iPSDyIEthRbAFsCqwGE89VEV3KrBMPU1XCGAlASlxVgiQdyqwU7hUPUMH
QEeiAwBhKrDQQz1VUyFMWT4yC2BvZMAysFzwNZMiAMADECL1KrAiBSAiYvAAwFLRCeD/OgBqgTbC
YxEphDM9dNxBKOd180wmdlFidQVAKaILYP9O4VgxO1BcACSxLSASsGbx7iY10StgCGBzZvE0ITax
/GxkBCApdS8iMUUoZXSB/1aBOOVnHANQCeBfYCIwJdB/N4EjISXQB+Ax6FkzNGNk9ybRUV0lgGY3
kYLSZz4por8luldldTUoMCIxJiIpKrD5KCEgakWBKZNQMD4pcsD/GNAmwoTPhd9nzy20dUQtpfdf
c0eAMvB1VuEFsUeAGGCfRdFq0xJyANBO4XMpJtf9csBrfSJjEwBwPiA0kWPg/zaBJGEjMBjgVdEk
nSyyJb//BCA0ICOQIxAD8DAxlKKVH/+NyC2oAHCJM4M6NCBgEQNgvwfgMsEnzCqwglBcUncFsP9S
cY4mMekqsGmzDoAl4WiBNzt2CvRywDFM8QIAaS34MTQ0DrAM0KKDC1miAP8KoANgGOA2IQqHC2QW
EqP5vi2mh6Svo9MMMKQmRgNhHjqlD6Q1QNNvuVtTTdhUUDpB7wNwXacvqD3vBmACMKlvqntUJqGY
ESqwPRLgTitQGPBkwAXAMTnBswAgOTozNK2fqD0MVG+v36p7UEtJWLuzj66udTXzta+qe1MkP+Ul
T2WhHTM2oycU4gwB/6QtIzA+dDQiHdAqULzhIyP/vD+9T21/QQC/fSCxDGAZ8POkJR7gbmskAEk/
SkdUr39Vsr9/pE2+7yBFzD0ZMQABz/AAAAADAP0/UgMAAB4AQhABAAAANwAAADwwMDIzMDFiZjI0
YjkkMzgzYzAzMzAkMDcyYWE4YzBAbW9iaWxlLnRydXN0cG9pbnQuY29tPgAAAwAmAAAAAAADADYA
AAAAAB4AMUABAAAAEAAAAEpNQU5HRVIyOTI4OEVGMwADABpAAAAAAB4AMEABAAAAEAAAAEpNQU5H
RVIyOTI4OEVGMwADABlAAAAAAAIB+T8BAAAAZwAAAAAAAADcp0DIwEIQGrS5CAArL+GCAQAAAAYA
AAAvTz1URUxTVFJBL09VPVFMRCBLSU5HU0ZPUkQtU01JVEgvQ049TVMgTUFJTCBSRUNJUElFTlRT
L0NOPUpNQU5HRVIyOTI4OEVGMwAAHgD4PwEAAAAOAAAATWFuZ2VyLCBKYW1lcwAAAB4AOEABAAAA
EAAAAEpNQU5HRVIyOTI4OEVGMwACAfs/AQAAAGcAAAAAAAAA3KdAyMBCEBq0uQgAKy/hggEAAAAG
AAAAL089VEVMU1RSQS9PVT1RTEQgS0lOR1NGT1JELVNNSVRIL0NOPU1TIE1BSUwgUkVDSVBJRU5U
Uy9DTj1KTUFOR0VSMjkyODhFRjMAAB4A+j8BAAAADgAAAE1hbmdlciwgSmFtZXMAAAAeADlAAQAA
ABAAAABKTUFOR0VSMjkyODhFRjMAQAAHMABMDSVUJr8BQAAIMFBiq3JfJr8BHgA9AAEAAAAFAAAA
UkU6IAAAAAAeAB0OAQAAACsAAABQS0lYOiBTdHJpbmcgcmVwcmVzZW50YXRpb24gb2YgR2VuZXJh
bE5hbWUAAAsAKQAAAAAACwAjAAAAAAADAAYQsSWjPAMABxDvBgAAAwAQEAAAAAADABEQAQAAAB4A
CBABAAAAZQAAAEFNSVQsVEhFUkVJU0FMUkVBRFlBU1RBTkRBUkRJWkVEU1RSSU5HUkVQUkVTRU5U
QVRJT05PRkdFTkVSQUxOQU1FVkFMVUVTSVRJU0FTTjFWQUxVRU5PVEFUSU9OQVNTVEFURUQAAAAA
mPk=

------_=_NextPart_000_01BF265F.72AB6250--


Received: from smtp-out1.bellatlantic.net (smtp-out1.bellatlantic.net [199.45.39.156]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id PAA17330 for <[e-mail]>; Wed, 3 Nov 1999 15:39:14 -0800 (PST)
Received: from ieca.com (adsl-151-200-26-46.bellatlantic.net [151.200.26.46]) by smtp-out1.bellatlantic.net (8.9.1/8.9.1) with ESMTP id SAA00817; Wed, 3 Nov 1999 18:37:44 -0500 (EST)
Message-ID: <[e-mail]>
Date: Wed, 03 Nov 1999 18:32:15 -0500
From: Sean Turner <[e-mail]>
Organization: IECA, Inc.
X-Mailer: Mozilla 4.7 [en] (Win98; U)
X-Accept-Language: en
MIME-Version: 1.0
To: PKIX <[e-mail]>
Subject: Comments on draft-ietf-pkix-qc-02.txt
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

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



Received: from prv-mail20.provo.novell.com (prv-mail20.provo.novell.com [137.65.82.195]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id PAA17139 for <[e-mail]>; Wed, 3 Nov 1999 15:36:24 -0800 (PST)
From: [e-mail]
Message-Id: <[e-mail]>
Received: from INET-PRV-Message_Server by prv-mail20.provo.novell.com with Novell_GroupWise; Wed, 03 Nov 1999 15:02:02 -0700
Mime-Version: 1.0
Date: Wed, 3 Nov 1999 15:01:00 -0600
X-Mailer: Groupwise 5.5.2.1
Subject: Re: How to identify certs to users
To: [e-mail], [e-mail]
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="____CPILXLVTUCRBHLFGCTCY____"

--____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" <[e-mail]> ,
in part because most e-mail packages would just as easily accept=20
"President William Jefferson Clinton" <[e-mail]>.

(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
[e-mail]
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:[phone]
EMAIL;WORK;PREF;NGW:[e-mail]
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

MIILzgYJKoZIhvcNAQcCoIILvzCCC7sCAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCCCh8w
ggUIMIID8KADAgECAhoCFAAAABQ0/V7yZC4krZCad8s8I/9yAgID2jANBgkqhkiG9w0BAQUFADAy
MRswGQYDVQQLExJOb3ZlbGwgRW1wbG95ZWUgQ0ExEzARBgNVBAoUCk5PVkVMTF9JTkMwHhcNOTkx
MDA5MTcyMDAwWhcNMDkxMDA5MTcyMDAwWjAyMRswGQYDVQQLExJOb3ZlbGwgRW1wbG95ZWUgQ0Ex
EzARBgNVBAoUCk5PVkVMTF9JTkMwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDFXNJ5
6dllO0vfXHFpTJKFXsPp4/ODFGguxqQOt/gRB+jEILRth9kko6r1DRMVtdJ3vYFxujArU9E1dEUL
mf12vQOHveLyiu3+2QWFoWxGMRzdeziJkB5lk8noS3yhCCBoEOh+8UZ8xbeXRiBE9Trn4e5mojH8
+ao7khHpd5tw2MbfDgEh7ngp0jg7ZvLUz/UW4ki8em35g3KC3UFdUO/q+V/n2NUqnpgUH2bkpoib
kSMjwAfVn50B1PpK/MJMGvtYGiVtTvq6VKDR+wa8WC7uVEQiPbEiH8KOKd9fFBCsZvd12fbfUeNI
FmrnNkk5Ob/p/GRKrppExWbGueulpBExAgMBAAGjggIOMIICCjAKBgNVHQ4EAwQBATAMBgNVHSME
BTADgAEBMA8GA1UdEwEBAAQFMAMBAf8wDgYDVR0PAQEABAQDAgEGMIIBywYLYIZIAYb4NwEJBAEB
AQAEggG3MIIBswQCAQABAf8THU5vdmVsbCBTZWN1cml0eSBBdHRyaWJ1dGUodG0pFkNodHRwOi8v
ZGV2ZWxvcGVyLm5vdmVsbC5jb20vcmVwb3NpdG9yeS9hdHRyaWJ1dGVzL2NlcnRhdHRyc192MTAu
aHRtMIIBRKAaAQEAMAgwBgIBAQIBRjAIMAYCAQECAQoCAWmhGgEBADAIMAYCAQECAUYwCDAGAgEB
AgEKAgFpogYCARgBAf+jggEAoFoCAQICAgD/AgEAAw0AgAAAAAAAAAAAAAAAAwkAgAAAAAAAAAAw
GDAQAgEAAgh//////////wEBAAIEBvDfSDAYMBACAQACCH//////////AQEAAgQG8N9IMFKhUgIB
AgICAP8CAQADDQBAAAAAAAAAAAAAAAADCQBAAAAAAAAAADAVMBACAQACCH//////////AQEAAgEU
MBUwEAIBAAIIf/////////8BAQACARSiTjBMAgECAgIA/wIBAAMNAID//////////////wMJAID/
////////MBIwEAIBAAIIf/////////8BAf8wEjAQAgEAAgh//////////wEB/zANBgkqhkiG9w0B
AQUFAAOCAQEAaiESm7ALSKkCI86jYyeRPzNazTY4f0GepqTPidwM546hDZKxkFfKjop9nhZDEg0S
xj69kL7mlqowVlU6dgoEPgqwPglP0jBO60EyzqjorrVbnpuSNUVoY+6OyymyrdNrx2DGTBTqsI/i
urILrt1V2b8ioTAWSp9lHr5LxAOxQgTeNMMI/b5B0sTlAlwBNbn2K1b11EfYdxSmkQZfsQVCmfKl
8y2xqF7X2+W45Zgdev0/JQxCXlRVoGEMbshs7V5AECg9qezn9dTyfCX1nS+YoLkJf0khv2MrcfrN
1SG2EGusV2NVDxCdXFuLhyWxwAxVLoI5LNIMLFa4P8vAinCxJTCCBQ8wggP3oAMCAQICGgIUAAAA
FDT9XvJkLiStkJp3yzwj/3ICAgTqMA0GCSqGSIb3DQEBBQUAMDIxGzAZBgNVBAsTEk5vdmVsbCBF
bXBsb3llZSBDQTETMBEGA1UEChQKTk9WRUxMX0lOQzAeFw05OTEwMDkxODE4MDBaFw0wMTEwMDkx
ODE4MDBaMEIxEjAQBgNVBAMTCUJKdWVuZW1hbjENMAsGA1UECxMETlNSRDEMMAoGA1UECxMDUFJW
MQ8wDQYDVQQKEwZOb3ZlbGwwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC3eHuGT669
GWzGuMYSIvezmPdEFF0nbdlhqv0KwebG5WHi4TiLyX7s8l6+0CQRAF9rFQhEdh7I2lti9hgrNOjo
4SZvxU0PstQcN9ad6usXMzHBa36Xj31kJUhguKEKpCaUYGmWPcq6ehLcuxTv0nuq1QvAGTIqjCT5
y/tpSwo2nXpb9UXOEpZg8CmL6OTKj44cAmHzPk6dElXxF7SjnhkNOYNvwgs/Afa+7iOX0Lv6vTYJ
eaz1eklKMSoJf5mZ/EZfJjUkf5jDRdIb5Rog2/HWMEsBvP2vgiBrV1nwVFGBkpfs1qwq0A7h3UdG
bm8NlzgFMs2lltqtONbGiZK5UMoDAgMBAAGjggIFMIICATAMBgNVHSMEBTADgAEBMCIGA1UdEQEB
AAQYMBaBFEJKVUVORU1BTkBub3ZlbGwuY29tMIIBywYLYIZIAYb4NwEJBAEBAQAEggG3MIIBswQC
AQABAf8THU5vdmVsbCBTZWN1cml0eSBBdHRyaWJ1dGUodG0pFkNodHRwOi8vZGV2ZWxvcGVyLm5v
dmVsbC5jb20vcmVwb3NpdG9yeS9hdHRyaWJ1dGVzL2NlcnRhdHRyc192MTAuaHRtMIIBRKAaAQEA
MAgwBgIBAQIBRjAIMAYCAQECAQoCAWmhGgEBADAIMAYCAQECAUYwCDAGAgEBAgEKAgFpogYCARQB
Af+jggEAoFoCAQICAgD/AgEAAw0AgAAAAAAAAAAAAAAAAwkAgAAAAAAAAAAwGDAQAgEAAgh/////
/////wEBAAIEBvDfSDAYMBACAQACCH//////////AQEAAgQG8N9IMFKhUgIBAgICAP8CAQADDQBA
AAAAAAAAAAAAAAADCQBAAAAAAAAAADAVMBACAQACCH//////////AQEAAgEUMBUwEAIBAAIIf///
//////8BAQACARSiTjBMAgECAgEAAgIA/wMNAIAAAAAAAAAAAAAAAAMJAIAAAAAAAAAAMBIwEAIB
AAIIf/////////8BAQAwEjAQAgEAAgh//////////wEBADANBgkqhkiG9w0BAQUFAAOCAQEAiEId
iox84BfJlz8suOJdTEwkuJsT1AbsLBwWzEpwfBS5FRGglOyKwlj8Fq+bFmgnBX//wbW4gjutgAEu
w8fXGUaQ9d2qwUn06Ta8C8AeBr7XmxrHe1Hs4YBQfqtVpdbZDasgeOhJhKSAMmIbv7jajwI9oZ93
aS5w/ArkTGFm+hpexZsSHtTjcKFAQ977M+QwbnilmnBfPYiQk+y/uGcAeJqJRnmzbfrbmzlpsyqg
yJENC+zD4O5tq9Gn53pHpG1EnjX/ZN3+jM0HKIc/rDuQ+yQ4e3LReenrRbmAoDlD5krF2sfFXphb
P86HUMcytbnXDgBbtKYdVtH/kDDMHCMQBTGCAXcwggFzAgEBMFAwMjEbMBkGA1UECxMSTm92ZWxs
IEVtcGxveWVlIENBMRMwEQYDVQQKFApOT1ZFTExfSU5DAhoCFAAAABQ0/V7yZC4krZCad8s8I/9y
AgIE6jAJBgUrDgMCGgUAMA0GCSqGSIb3DQEBAQUABIIBADC0Ip7sKonrU98EHMFIMkX+R07b13JJ
F01xbdiGC8htY0p2CueKNWt5wVBM1FJ0B8G/9AbpThwxTwM21EV+NDZZm8gi+fX7bg5SLgl01rhC
U9lxuyrhbSi5M5f0uTRrCHQ9PH7i1csXnFcapkJnkqV+9Jv/a1y6ZVuJGeBpBVchlEnpCiycEbbU
6en7Ehif1qnekbW59NwKyHoAgTQYhWwogD2y2nd1I4VvaX7Tpjt0Vec8GVMwTWfVItiAxgsMnCw9
CwY2jTvKCTh8p/CFORAmdszbzq7YDyCCUHsqaAoXNYcLqmYB0ek8C1JFsJMT5ljp47Iq9HwaD+n6
RQGdaf8=

--____CPILXLVTUCRBHLFGCTCY____--


Received: from smtp-out1.bellatlantic.net (smtp-out1.bellatlantic.net [199.45.39.156]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id PAA16613 for <[e-mail]>; Wed, 3 Nov 1999 15:11:01 -0800 (PST)
Received: from ieca.com (adsl-151-200-26-46.bellatlantic.net [151.200.26.46]) by smtp-out1.bellatlantic.net (8.9.1/8.9.1) with ESMTP id SAA14728; Wed, 3 Nov 1999 18:09:26 -0500 (EST)
Message-ID: <[e-mail]>
Date: Wed, 03 Nov 1999 18:03:59 -0500
From: Sean Turner <[e-mail]>
Organization: IECA, Inc.
X-Mailer: Mozilla 4.7 [en] (Win98; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Denis Pinkas <[e-mail]>
CC: IETF-PXIX <[e-mail]>
Subject: Re: Comments on the PKIX Roadmap
References: <[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

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



Received: from www.certifeidtime.com. (test.glassey.com [207.126.98.130] (may be forged)) by ns.secondary.com (8.9.3/8.9.3) with SMTP id MAA14692 for <[e-mail]>; Wed, 3 Nov 1999 12:48:08 -0800 (PST)
Received: from gw by www.certifeidtime.com. (SMI-8.6/SMI-SVR4) id MAA08512; Wed, 3 Nov 1999 12:48:58 -0800
Message-ID: <017301bf263c$b96fac20$[e-mail]>
From: "Todd Glassey @ GMT" <[e-mail]>
To: "Michael Duren" <[e-mail]>, "Denis Pinkas" <[e-mail]>
Cc: <[e-mail]>
References: <010401bf261e$743a10a0$1146d8d1@Mike>
Subject: Timestamping vs timesetting...
Date: Wed, 3 Nov 1999 12:48:02 -0800
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.00.2919.5600
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.5600

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" <[e-mail]>
To: "Denis Pinkas" <[e-mail]>; "Todd Glassey @ GMT"
<[e-mail]>
Cc: <[e-mail]>
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 <[e-mail]>
> To: Todd Glassey @ GMT <[e-mail]>
> Cc: [e-mail] <[e-mail]>
> 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" <[e-mail]>
> >> To: "Todd Glassey @ GMT" <[e-mail]>
> >> Cc: <[e-mail]>; <[e-mail]>
> >> 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
> >> >
> >
>
>



Received: from tholian.securitydynamics.com (tholian.securid.com [204.167.112.129]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id MAA14322 for <[e-mail]>; Wed, 3 Nov 1999 12:32:59 -0800 (PST)
Received: from sdtihq24.securitydynamics.com by tholian.securitydynamics.com via smtpd (for mail.imc.org [208.184.76.43]) with SMTP; 3 Nov 1999 20:31:49 UT
Received: from exna00.securitydynamics.com (exna00.securitydynamics.com [10.2.1.110]) by sdtihq24.securid.com (Pro-8.9.3/Pro-8.9.3) with ESMTP id PAA09086 for <[e-mail]>; Wed, 3 Nov 1999 15:27:15 -0500 (EST)
Received: by exna00.securitydynamics.com with Internet Mail Service (5.5.2448.0) id <WF09ZBBW>; Wed, 3 Nov 1999 15:34:50 -0500
Message-ID: <[e-mail]>
From: "Linn, John" <[e-mail]>
To: [e-mail]
Subject: RE: I-D ACTION:draft-ietf-pkix-laap-00.txt
Date: Wed, 3 Nov 1999 15:40:07 -0500 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2448.0)
Content-Type: text/plain; charset="iso-8859-1"

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: [e-mail] [mailto:[e-mail]]
> Sent: Wednesday, October 13, 1999 6:54 AM
> Cc: [e-mail]
> 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:
> 	[e-mail].
> 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.
> 


Received: from ns.webway.se (ns.webway.se [194.52.11.51]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id KAA12056 for <[e-mail]>; Wed, 3 Nov 1999 10:02:19 -0800 (PST)
Received: (from kpk-list@localhost) by ns.webway.se (8.9.3/8.9.3) id SAA20123; Wed, 3 Nov 1999 18:30:17 +0100 (MET)
Resent-Date: Wed, 3 Nov 1999 18:30:14 +0100 (MET)
Date: Wed, 3 Nov 1999 18:30:27 +0100 (MET)
From: Stefan Kelm <[e-mail]>
Message-Id: <[e-mail]>
To: [e-mail]
Cc: [e-mail], [e-mail]
Reply-To: [e-mail]
X-Sun-Charset: US-ASCII
Resent-Message-ID: <"_tMd6.A.N6E.mEHI4"@ns>
Resent-From: [e-mail]
X-listadress: [e-mail]
X-Mailing-List: <[e-mail]> archive/latest/441
X-Loop: [e-mail]
Precedence: list
Resent-Sender: [e-mail]
X-From: SEIS-listan <[e-mail]>
Subject: SEIS:  Re: Fresh version of the EU draft Electronic Signature directive

--- Message on the SEIS mailing list ([e-mail])

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 [e-mail]" or via key server
DFN-PCA                                                      <[e-mail]>
Vogt-Koelln-Str. 30                               http://www.pca.dfn.de/~kelm/
22527 Hamburg (Germany)                   Tel: [phone] / Fax: -2241


----------------- SEIS mailing list ([e-mail])
Info about this list: http://www.nc-forum.com/seis
SEIS Contact: [e-mail]



Received: from dfw-smtpout1.email.verio.net (dfw-smtpout1-ext.email.verio.net [129.250.36.41]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id JAA11846 for <[e-mail]>; Wed, 3 Nov 1999 09:59:00 -0800 (PST)
Received: from dfw-mmp4.email.verio.net ([129.250.38.64]) by dfw-smtpout1.email.verio.net (Netscape Messaging Server 4.05) with ESMTP id FKMVAK00.6PD for <[e-mail]>; Wed, 3 Nov 1999 17:59:08 +0000 
Received: from nma.com ([209.21.28.123]) by dfw-mmp4.email.verio.net (Netscape Messaging Server 4.05) with ESMTP id FKMV9V00.CP9 for <[e-mail]>; Wed, 3 Nov 1999 17:58:43 +0000 
Message-ID: <[e-mail]>
Date: Wed, 03 Nov 1999 09:59:13 -0800
From: Ed Gerck <[e-mail]>
X-Mailer: Mozilla 4.7 [en]C-CCK-MCD {Sony}  (Win98; I)
X-Accept-Language: en
MIME-Version: 1.0
CC: [e-mail]
Subject: [junk] Re: auto subscribe
References: <[e-mail]> <[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

[e-mail] wrote:

> WARNING:
>         Please try to use '[e-mail]'
>         the next time when issuing (un)subscribe requests.
>
> You have added to the subscriber list of:
>
>         [e-mail]
>
> the following mail address:
>
>         [e-mail]
>
> 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




Received: from ns.webway.se (ns.webway.se [194.52.11.51]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id JAA11533 for <[e-mail]>; Wed, 3 Nov 1999 09:47:21 -0800 (PST)
From: [e-mail]
Received: (from kpk-list@localhost) by ns.webway.se (8.9.3/8.9.3) id SAA20179 for [e-mail]; Wed, 3 Nov 1999 18:45:11 +0100 (MET)
Date: Wed, 3 Nov 1999 18:45:11 +0100 (MET)
Message-Id: <[e-mail]>
To: [e-mail]
Subject: Re: unsubscribe [e-mail]
References: <[e-mail]>
In-Reply-To: <[e-mail]>
X-Loop: [e-mail]
Precedence: junk

                 32752 [e-mail]
[e-mail]

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 [e-mail]  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 <[e-mail]>; 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: <[e-mail]>
>To: [e-mail]
>From: [e-mail]
>Subject: unsubscribe [e-mail]
>
>unsubscribe [e-mail]
>


Received: from ns.webway.se (ns.webway.se [194.52.11.51]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id JAA11200 for <[e-mail]>; Wed, 3 Nov 1999 09:34:57 -0800 (PST)
Received: (from kpk-list@localhost) by ns.webway.se (8.9.3/8.9.3) id SAA20123; Wed, 3 Nov 1999 18:30:17 +0100 (MET)
Resent-Date: Wed, 3 Nov 1999 18:30:14 +0100 (MET)
Date: Wed, 3 Nov 1999 18:30:27 +0100 (MET)
From: Stefan Kelm <[e-mail]>
Message-Id: <[e-mail]>
To: [e-mail]
Cc: [e-mail], [e-mail]
Reply-To: [e-mail]
X-Sun-Charset: US-ASCII
Resent-Message-ID: <"_tMd6.A.N6E.mEHI4"@ns>
Resent-From: [e-mail]
X-listadress: [e-mail]
X-Mailing-List: <[e-mail]> archive/latest/441
X-Loop: [e-mail]
Precedence: list
Resent-Sender: [e-mail]
X-From: SEIS-listan <[e-mail]>
Subject: SEIS:  Re: Fresh version of the EU draft Electronic Signature directive

--- Message on the SEIS mailing list ([e-mail])

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 [e-mail]" or via key server
DFN-PCA                                                      <[e-mail]>
Vogt-Koelln-Str. 30                               http://www.pca.dfn.de/~kelm/
22527 Hamburg (Germany)                   Tel: [phone] / Fax: -2241


----------------- SEIS mailing list ([e-mail])
Info about this list: http://www.nc-forum.com/seis
SEIS Contact: [e-mail]



Received: from ns.webway.se (ns.webway.se [194.52.11.51]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id JAA11012 for <[e-mail]>; Wed, 3 Nov 1999 09:32:24 -0800 (PST)
From: [e-mail]
Received: by ns.webway.se (8.9.3/8.9.3) id SAA20101 for [e-mail]; Wed, 3 Nov 1999 18:30:12 +0100 (MET)
Date: Wed, 3 Nov 1999 18:30:12 +0100 (MET)
Message-Id: <[e-mail]>
To: [e-mail]
Subject: Re: auto subscribe
References: <[e-mail]>
In-Reply-To: <[e-mail]>
X-Loop: [e-mail]

WARNING:
	Please try to use '[e-mail]'
	the next time when issuing (un)subscribe requests.

You have added to the subscriber list of:

	[e-mail]

the following mail address:

	[e-mail]

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 [e-mail]  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 <[e-mail]>; 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 <[e-mail]>
>Message-Id: <[e-mail]>
>To: [e-mail]
>Cc: [e-mail], [e-mail]
>Reply-To: [e-mail]
>X-Sun-Charset: US-ASCII
>Subject: auto subscribe
>


Received: from procert.cert.dfn.de ([e-mail] [134.100.14.1]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id JAA10821 for <[e-mail]>; Wed, 3 Nov 1999 09:30:34 -0800 (PST)
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 <[e-mail]>
Message-Id: <[e-mail]>
To: [e-mail]
Subject: Re: Fresh version of the EU draft Electronic Signature directive
Cc: [e-mail], [e-mail]
Reply-To: [e-mail]
X-Sun-Charset: US-ASCII

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 [e-mail]" or via key server
DFN-PCA                                                      <[e-mail]>
Vogt-Koelln-Str. 30                               http://www.pca.dfn.de/~kelm/
22527 Hamburg (Germany)                   Tel: [phone] / Fax: -2241


Received: from emerald.lightlink.com ([e-mail] [205.232.34.14]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id JAA10379 for <[e-mail]>; Wed, 3 Nov 1999 09:17:44 -0800 (PST)
Received: from Mike ([209.216.70.17]) by emerald.lightlink.com (8.8.8/8.8.8) with ESMTP id MAA14597; Wed, 3 Nov 1999 12:17:36 -0500
Message-ID: <010401bf261e$743a10a0$1146d8d1@Mike>
Reply-To: "Michael Duren" <[e-mail]>
From: "Michael Duren" <[e-mail]>
To: "Denis Pinkas" <[e-mail]>, "Todd Glassey @ GMT" <[e-mail]>
Cc: <[e-mail]>
Subject: Re: Timestamping Standards.
Date: Wed, 3 Nov 1999 12:11:10 -0500
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 4.72.3110.1
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3

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 <[e-mail]>
To: Todd Glassey @ GMT <[e-mail]>
Cc: [e-mail] <[e-mail]>
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" <[e-mail]>
>> To: "Todd Glassey @ GMT" <[e-mail]>
>> Cc: <[e-mail]>; <[e-mail]>
>> 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
>> >
>



Received: from Default (ip12.proper.com [165.227.249.12]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id JAA10240 for <[e-mail]>; Wed, 3 Nov 1999 09:09:36 -0800 (PST)
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.1 
Date: Wed, 03 Nov 1999 09:09:59 -0800
To: [e-mail]
From: Paul Hoffman / IMC <[e-mail]>
Subject: Re: US relaxed export policy - When/IF and how?
In-Reply-To: <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed

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



Received: from mail.student.auckland.ac.nz (mail.student.auckland.ac.nz [130.216.35.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id IAA09557 for <[e-mail]>; Wed, 3 Nov 1999 08:32:48 -0800 (PST)
Received: from cs26.cs.auckland.ac.nz ([e-mail] [130.216.36.9]) by mail.student.auckland.ac.nz (8.9.3/8.8.6/cs-master) with SMTP id FAA16327 for <[e-mail]>; Thu, 4 Nov 1999 05:32:59 +1300 (NZDT) (sender [e-mail])
Received: by cs26.cs.auckland.ac.nz (relaymail v0.9) id <94164677922053>; Thu, 4 Nov 1999 05:32:59 (NZDT)
From: [e-mail] (Peter Gutmann)
To: [e-mail]
Subject: Re: US relaxed export policy - When/IF and how?
Sender: [e-mail]
Reply-To: [e-mail]
X-Charge-To: pgut001
X-Authenticated: relaymail v0.9 on cs26.cs.auckland.ac.nz
Date: Thu, 4 Nov 1999 05:32:59 (NZDT)
Message-ID: <[e-mail]>

"Bob Jueneman" <[e-mail]> 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.



Received: from clbull.frcl.bull.fr (clbull.frcl.bull.fr [129.182.8.31]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id IAA09178 for <[e-mail]>; Wed, 3 Nov 1999 08:17:35 -0800 (PST)
Received: from bull.net (frcls6118.frcl.bull.fr [129.182.109.213]) by clbull.frcl.bull.fr (8.9.2/8.9.1) with ESMTP id RAA41072; Wed, 3 Nov 1999 17:17:21 +0100
Message-ID: <[e-mail]>
Date: Wed, 03 Nov 1999 17:17:09 +0100
From: Denis Pinkas <[e-mail]>
Organization: Bull
X-Mailer: Mozilla 4.06 [fr] (Win95; I)
MIME-Version: 1.0
To: "Todd Glassey @ GMT" <[e-mail]>
CC: [e-mail]
Subject: Re: Timestamping Standards.
References: <04b001bf257f$40a14b90$[e-mail]> <[e-mail]> <003c01bf2612$c50be0a0$[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

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" <[e-mail]>
> To: "Todd Glassey @ GMT" <[e-mail]>
> Cc: <[e-mail]>; <[e-mail]>
> 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
> >


Received: from prv-mail20.provo.novell.com (prv-mail20.provo.novell.com [137.65.82.195]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id IAA08871 for <[e-mail]>; Wed, 3 Nov 1999 08:07:11 -0800 (PST)
Received: from INET-PRV-Message_Server by prv-mail20.provo.novell.com with Novell_GroupWise; Wed, 03 Nov 1999 08:40:22 -0700
Message-Id: <[e-mail]>
X-Mailer: Novell GroupWise Internet Agent 5.5.2.1
Date: Wed, 03 Nov 1999 08:40:13 -0700
From: "Bob Jueneman" <[e-mail]>
To: <[e-mail]>, <[e-mail]>
Subject: Re: US relaxed export policy - When/IF and how?
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by ns.secondary.com id IAA08872

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 <[e-mail]> 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






Received: from mail.student.auckland.ac.nz (mail.student.auckland.ac.nz [130.216.35.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id HAA08446 for <[e-mail]>; Wed, 3 Nov 1999 07:59:45 -0800 (PST)
Received: from cs26.cs.auckland.ac.nz ([e-mail] [130.216.36.9]) by mail.student.auckland.ac.nz (8.9.3/8.8.6/cs-master) with SMTP id EAA16682 for <[e-mail]>; Thu, 4 Nov 1999 04:59:56 +1300 (NZDT) (sender [e-mail])
Received: by cs26.cs.auckland.ac.nz (relaymail v0.9) id <94164479521882>; Thu, 4 Nov 1999 04:59:55 (NZDT)
From: [e-mail] (Peter Gutmann)
To: [e-mail]
Subject: How to identify certs to users
Sender: [e-mail]
Reply-To: [e-mail]
X-Charge-To: pgut001
X-Authenticated: relaymail v0.9 on cs26.cs.auckland.ac.nz
Date: Thu, 4 Nov 1999 04:59:55 (NZDT)
Message-ID: <[e-mail]>

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.



Received: from www.certifeidtime.com. (test.glassey.com [207.126.98.130] (may be forged)) by ns.secondary.com (8.9.3/8.9.3) with SMTP id HAA08379 for <[e-mail]>; Wed, 3 Nov 1999 07:59:35 -0800 (PST)
Received: from gw by www.certifeidtime.com. (SMI-8.6/SMI-SVR4) id IAA08216; Wed, 3 Nov 1999 08:00:39 -0800
Message-ID: <00b501bf2614$71467eb0$[e-mail]>
From: "Todd Glassey @ GMT" <[e-mail]>
To: "Marc Branchaud" <[e-mail]>, <[e-mail]>
References: <[e-mail]>
Subject: Re: Possible patent issue with UTCTime hack
Date: Wed, 3 Nov 1999 07:59:41 -0800
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.00.2919.5600
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.5600

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" <[e-mail]>
To: <[e-mail]>
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
>



Received: from www.certifeidtime.com. (test.glassey.com [207.126.98.130] (may be forged)) by ns.secondary.com (8.9.3/8.9.3) with SMTP id HAA08017 for <[e-mail]>; Wed, 3 Nov 1999 07:47:35 -0800 (PST)
Received: from gw by www.certifeidtime.com. (SMI-8.6/SMI-SVR4) id HAA08182; Wed, 3 Nov 1999 07:48:40 -0800
Message-ID: <003c01bf2612$c50be0a0$[e-mail]>
From: "Todd Glassey @ GMT" <[e-mail]>
To: "Denis Pinkas" <[e-mail]>
Cc: <[e-mail]>, <[e-mail]>
References: <04b001bf257f$40a14b90$[e-mail]> <[e-mail]>
Subject: Re: Timestamping Standards.
Date: Wed, 3 Nov 1999 07:47:43 -0800
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.00.2919.5600
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.5600

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" <[e-mail]>
To: "Todd Glassey @ GMT" <[e-mail]>
Cc: <[e-mail]>; <[e-mail]>
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
>



Received: from dfw7-1.relay.mail.uu.net (dfw7-1.relay.mail.uu.net [199.171.54.106]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id HAA07513 for <[e-mail]>; Wed, 3 Nov 1999 07:24:21 -0800 (PST)
Received: from xedia.com by dfw7sosrv11.alter.net with SMTP  (peer crosschecked as: host199.xedia.com [198.202.232.199] (may be forged)) id QQhntd13347; Wed, 3 Nov 1999 15:24:28 GMT
Received: from tonga.xedia.com by xedia.com (4.1/SMI-4.1) id AA09105; Wed, 3 Nov 99 10:22:30 EST
Received: by tonga.xedia.com (SMI-8.6/SMI-SVR4) id KAA17888; Wed, 3 Nov 1999 10:24:27 -0500
Date: Wed, 3 Nov 1999 10:24:27 -0500
Message-Id: <[e-mail]>
From: Paul Koning <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
To: [e-mail]
Cc: [e-mail]
Subject: Re: US relaxed export policy - When/IF and how?
References: <01BF2612.CEE56470@HYDRA>
X-Mailer: VM 6.34 under 20.3 "Vatican City" XEmacs  Lucid

>>>>> "Anders" == Anders Rundgren <[e-mail]> 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


Received: from caesar.udac.se (caesar.udac.se [193.44.79.10]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id GAA07031 for <[e-mail]>; Wed, 3 Nov 1999 06:53:15 -0800 (PST)
Received: from HYDRA ([195.198.186.74]) by caesar.udac.se (8.7.3/NetworkC-1) with SMTP id PAA47303 for <[e-mail]>; Wed, 3 Nov 1999 15:50:05 +0100
Received: by HYDRA with Microsoft Mail id <01BF2612.CEE56470@HYDRA>; Wed, 3 Nov 1999 15:48:01 +0100
Message-ID: <01BF2612.CEE56470@HYDRA>
From: Anders Rundgren <[e-mail]>
To: "'[e-mail]'" <[e-mail]>
Subject: US relaxed export policy - When/IF and how?
Date: Wed, 3 Nov 1999 15:47:59 +0100
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit

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





Received: from crcst348.netaddress.usa.net (crcst348.netaddress.usa.net [204.68.23.93]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id GAA06192 for <[e-mail]>; Wed, 3 Nov 1999 06:21:49 -0800 (PST)
Received: (qmail 198 invoked from network); 3 Nov 1999 14:20:35 -0000
Received: from www0b.netaddress.usa.net (204.68.24.31) by outbound.netaddress.usa.net with SMTP; 3 Nov 1999 14:20:35 -0000
Received: (qmail 21855 invoked by uid 60001); 3 Nov 1999 14:22:01 -0000
Message-ID: <[e-mail]>
Received: from 204.68.24.31 by www0b for [198.202.232.217] via web-mailer(M3.3.1.96) on Wed Nov  3 14:22:01 GMT 1999
Date:  3 Nov 99 06:22:01 PST
From: Eric Bomarsi <[e-mail]>
To: [e-mail]
Subject: PKI Software
X-Mailer: USANET web-mailer (M3.3.1.96)
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by ns.secondary.com id GAA06193

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.


Received: from stingray.missi.ncsc.mil (stingray.missi.ncsc.mil [144.51.50.20]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id FAA05404 for <[e-mail]>; Wed, 3 Nov 1999 05:43:49 -0800 (PST)
Received: from stingray.missi.ncsc.mil (root@localhost) by stingray.missi.ncsc.mil with ESMTP id IAA26553 for <[e-mail]>; Wed, 3 Nov 1999 08:44:23 -0500 (EST)
Received: from missi.ncsc.mil (depot.missi.ncsc.mil [144.51.60.1]) by stingray.missi.ncsc.mil with ESMTP id IAA26526 for <[e-mail]>; Wed, 3 Nov 1999 08:44:21 -0500 (EST)
Received: from mimesweeper.missi.ncsc.mil (mimesweeper.missi.ncsc.mil [144.51.60.2]) by missi.ncsc.mil (8.8.8/8.8.8) with ESMTP id IAA18816 for <[e-mail]>; Wed, 3 Nov 1999 08:43:41 -0500 (EST)
Received: from avenger.missi.ncsc.mil (avenger53.missi.ncsc.mil) by mimesweeper.missi.ncsc.mil (Content Technologies SMTPRS 2.0.15) with ESMTP id <[e-mail]>; Wed, 03 Nov 1999 08:44:11 -0500
Received: by avenger54.missi.ncsc.mil with Internet Mail Service (5.5.2232.9) id <TZ046R4B>; Wed, 3 Nov 1999 08:44:13 -0500
Message-Id: <[e-mail]>
From: "Miklos, Sue A." <[e-mail]>
To: "'Stefan Santesson'" <[e-mail]>, "'Bob Jueneman'" <[e-mail]>, "'[e-mail]'" <[e-mail]>
Cc: "'[e-mail]'" <[e-mail]>, "'[e-mail]'" <[e-mail]>
Subject: error in previous post
Date: Wed, 3 Nov 1999 08:44:11 -0500 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2232.9)
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01BF2601.82C57B4A"

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


Received: from stingray.missi.ncsc.mil (stingray.missi.ncsc.mil [144.51.50.20]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id FAA05031 for <[e-mail]>; Wed, 3 Nov 1999 05:30:44 -0800 (PST)
Received: from stingray.missi.ncsc.mil (root@localhost) by stingray.missi.ncsc.mil with ESMTP id IAA25633 for <[e-mail]>; Wed, 3 Nov 1999 08:31:18 -0500 (EST)
Received: from missi.ncsc.mil (depot.missi.ncsc.mil [144.51.60.1]) by stingray.missi.ncsc.mil with ESMTP id IAA25583 for <[e-mail]>; Wed, 3 Nov 1999 08:31:13 -0500 (EST)
Received: from mimesweeper.missi.ncsc.mil (mimesweeper.missi.ncsc.mil [144.51.60.2]) by missi.ncsc.mil (8.8.8/8.8.8) with ESMTP id IAA18619 for <[e-mail]>; Wed, 3 Nov 1999 08:30:32 -0500 (EST)
Received: from avenger.missi.ncsc.mil (avenger53.missi.ncsc.mil) by mimesweeper.missi.ncsc.mil (Content Technologies SMTPRS 2.0.15) with ESMTP id <[e-mail]>; Wed, 03 Nov 1999 08:30:16 -0500
Received: by avenger54.missi.ncsc.mil with Internet Mail Service (5.5.2232.9) id <TZ046RS4>; Wed, 3 Nov 1999 08:30:18 -0500
Message-Id: <[e-mail]>
From: "Miklos, Sue A." <[e-mail]>
To: "'Stefan Santesson'" <[e-mail]>, Bob Jueneman <[e-mail]>, [e-mail]
Cc: [e-mail], [e-mail]
Subject: RE: QC certificates and Nationality
Date: Wed, 3 Nov 1999 08:30:17 -0500 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2232.9)
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01BF25FF.9176BA8E"

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:[e-mail]]
Sent: Wednesday, November 03, 1999 7:12 AM
To: Bob Jueneman; [e-mail]; [e-mail]
Cc: [e-mail]; [e-mail]
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." <[e-mail]> 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:[e-mail]] 
>Sent: Tuesday, November 02, 1999 12:55 PM
>To: Miklos, Sue A.
>Cc: Russ Housley; [e-mail]; '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:[e-mail]] 
>> Sent: Tuesday, November 02, 1999 4:32 AM
>> To: Russ Housley
>> Cc: [e-mail]; '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                <[e-mail]>
Accurata AB                     http://www.accurata.se
Slagthuset                      Tel. [phone]              
211 20  Malmö                   Fax. [phone]              
Sweden                        Mobile [phone]

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:[e-mail]">mailto:[e-mail]</A>]</FONT>=

<BR><FONT SIZE=3D2>Sent: Wednesday, November 03, 1999 7:12 AM</FONT>
<BR><FONT SIZE=3D2>To: Bob Jueneman; [e-mail]; =
[e-mail]</FONT>
<BR><FONT SIZE=3D2>Cc: [e-mail]; [e-mail]</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;[e-mail]&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:[e-mail]">mailto:[e-mail]</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; [e-mail]; =
'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:[e-mail]">mailto:[e-mail]</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: [e-mail]; '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;[e-mail]&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 [phone]</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--


Received: from aunt15.ausys.se (void1.ausys.se [62.20.78.253]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id EAA04201 for <[e-mail]>; Wed, 3 Nov 1999 04:37:48 -0800 (PST)
Received: by aunt15.ausys.se with Internet Mail Service (5.5.2650.21) id <WCBXX83X>; Wed, 3 Nov 1999 13:37:26 +0100
Message-ID: <[e-mail]>
From: Simon Corell <[e-mail]>
To: "'Anders Rundgren'" <[e-mail]>, Stefan Santesson <[e-mail]>, [e-mail], "'SEIS-List'" <[e-mail]>
Subject: RE: SEIS:  QC Container-ID (card serial)
Date: Wed, 3 Nov 1999 13:37:25 +0100 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by ns.secondary.com id EAA04202

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: [phone], Mobile: [phone], Fax: [phone]
mail to: [e-mail], http://www.iD2tech.com

> iD2 - Securing the Internet economy
> 

-----Original Message-----
From: Anders Rundgren [mailto:[e-mail]]
Sent: den 3 november 1999 08:54
To: Stefan Santesson; [e-mail]; 'SEIS-List'
Subject: SEIS: QC Container-ID (card serial)


--- Message on the SEIS mailing list ([e-mail])

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 ([e-mail])
Info about this list: http://www.nc-forum.com/seis
SEIS Contact: [e-mail]


Received: from caesar.udac.se (caesar.udac.se [193.44.79.10]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id EAA03960 for <[e-mail]>; Wed, 3 Nov 1999 04:30:11 -0800 (PST)
Received: from HYDRA ([195.198.186.74]) by caesar.udac.se (8.7.3/NetworkC-1) with SMTP id NAA58993; Wed, 3 Nov 1999 13:26:54 +0100
Received: by HYDRA with Microsoft Mail id <01BF25FE.CDD766F0@HYDRA>; Wed, 3 Nov 1999 13:24:49 +0100
Message-ID: <01BF25FE.CDD766F0@HYDRA>
From: Anders Rundgren <[e-mail]>
To: "'Juergen Brauckmann'" <[e-mail]>, "'[e-mail]'" <[e-mail]>
Cc: =?iso-8859-1?Q?=27Magnus_Nystr=F6m=27?= <[e-mail]>, "'Stefan Santesson'" <[e-mail]>
Subject: RE: QC Container-ID (card serial)
Date: Wed, 3 Nov 1999 13:24:48 +0100
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit

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




Received: from popmail.inbox.se (popmail.inbox.se [193.12.72.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id EAA03636 for <[e-mail]>; Wed, 3 Nov 1999 04:11:15 -0800 (PST)
Received: from stefan2 (accurata.inbox.se [193.12.72.24]) by popmail.inbox.se (8.9.3/8.9.3) with SMTP id NAA05285; Wed, 3 Nov 1999 13:11:11 +0100
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 
Date: Wed, 03 Nov 1999 13:11:39 +0100
To: "Bob Jueneman" <[e-mail]>, <[e-mail]>, <[e-mail]>
From: Stefan Santesson <[e-mail]>
Subject: RE: QC certificates and Nationality
Cc: <[e-mail]>, <[e-mail]>
In-Reply-To: <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by ns.secondary.com id EAA03637

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." <[e-mail]> 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:[e-mail]] 
>Sent: Tuesday, November 02, 1999 12:55 PM
>To: Miklos, Sue A.
>Cc: Russ Housley; [e-mail]; '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:[e-mail]] 
>> Sent: Tuesday, November 02, 1999 4:32 AM
>> To: Russ Housley
>> Cc: [e-mail]; '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                <[e-mail]>
Accurata AB                     http://www.accurata.se
Slagthuset                      Tel. [phone]              
211 20  Malmö                   Fax. [phone]              
Sweden                        Mobile [phone]

PGP fingerprint: 89BC 6C79 5B3D 591B 8547  1512 7D11 DBF4 528F 29A0
-------------------------------------------------------------------


Received: from mystic1 (firewall-user@[193.194.157.34]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id DAA02056 for <[e-mail]>; Wed, 3 Nov 1999 03:10:12 -0800 (PST)
Received: by mystic1; id MAA14831; Wed, 3 Nov 1999 12:09:38 +0100 (MET)
Received: from nodnsquery(192.168.200.3) by mystic1.tc-trustcenter.com via smap (V5.0) id xma014823; Wed, 3 Nov 99 12:09:35 +0100
Received: from ew-jbr (titan.tc-trustcenter.com [192.168.200.244]) by callisto.tc-trustcenter.com (8.9.3/8.9.3) with SMTP id MAA05988 for <[e-mail]>; Wed, 3 Nov 1999 12:10:00 +0100 (MET)
Message-Id: <3.0.5.32.19991103120922.009d1e00@callisto>
X-Sender: jbr@callisto
X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32)
Date: Wed, 03 Nov 1999 12:09:22 +0100
To: [e-mail]
From: Juergen Brauckmann <[e-mail]>
Subject: Re: QC Container-ID (card serial)
In-Reply-To: <01BF25EF.15A26940@HYDRA>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"

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:[e-mail]
Am Werder 1    		    http://www.trustcenter.de	
21073 Hamburg


Received: from popmail.inbox.se (popmail.inbox.se [193.12.72.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id CAA00223 for <[e-mail]>; Wed, 3 Nov 1999 02:45:47 -0800 (PST)
Received: from stefan2 (accurata.inbox.se [193.12.72.24]) by popmail.inbox.se (8.9.3/8.9.3) with SMTP id LAA03658; Wed, 3 Nov 1999 11:45:56 +0100
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 
Date: Wed, 03 Nov 1999 11:46:25 +0100
To: Anders Rundgren <[e-mail]>, Anders Rundgren </o=Jaybis.AB/ou=JAYBIS/cn=Recipients/cn=[e-mail]>, "[e-mail]" <[e-mail]>, "'SEIS-List'" <[e-mail]>
From: Stefan Santesson <[e-mail]>
Subject: Re: QC Container-ID (card serial)
In-Reply-To: <01BF25EF.15A26940@HYDRA>
Mime-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by ns.secondary.com id CAA00224

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                <[e-mail]>
Accurata AB                     http://www.accurata.se
Slagthuset                      Tel. [phone]              
211 20  Malmö                   Fax. [phone]              
Sweden                        Mobile [phone]

PGP fingerprint: 89BC 6C79 5B3D 591B 8547  1512 7D11 DBF4 528F 29A0
-------------------------------------------------------------------


Received: from caesar.udac.se (caesar.udac.se [193.44.79.10]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id CAA29884 for <[e-mail]>; Wed, 3 Nov 1999 02:37:34 -0800 (PST)
Received: from HYDRA ([195.198.186.74]) by caesar.udac.se (8.7.3/NetworkC-1) with SMTP id LAA30488; Wed, 3 Nov 1999 11:34:23 +0100
Received: by HYDRA with Microsoft Mail id <01BF25EF.15A26940@HYDRA>; Wed, 3 Nov 1999 11:32:18 +0100
Message-ID: <01BF25EF.15A26940@HYDRA>
From: Anders Rundgren <[e-mail]>
To: Anders Rundgren </o=Jaybis.AB/ou=JAYBIS/cn=Recipients/cn=[e-mail]>, "[e-mail]" <[e-mail]>, "'SEIS-List'" <[e-mail]>, "'Stefan Santesson'" <[e-mail]>
Subject: Re: QC Container-ID (card serial)
Date: Wed, 3 Nov 1999 11:32:16 +0100
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit

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



Received: from popmail.inbox.se (popmail.inbox.se [193.12.72.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id CAA29309 for <[e-mail]>; Wed, 3 Nov 1999 02:02:41 -0800 (PST)
Received: from stefan2 (accurata.inbox.se [193.12.72.24]) by popmail.inbox.se (8.9.3/8.9.3) with SMTP id LAA02810; Wed, 3 Nov 1999 11:02:53 +0100
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 
Date: Wed, 03 Nov 1999 11:03:21 +0100
To: <[e-mail]>, "'SEIS-List'" <[e-mail]>
From: Stefan Santesson <[e-mail]>
Subject: Fresh version of the EU draft Electronic Signature directive
Mime-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by ns.secondary.com id CAA29310

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                <[e-mail]>
Accurata AB                     http://www.accurata.se
Slagthuset                      Tel. [phone]              
211 20  Malmö                   Fax. [phone]              
Sweden                        Mobile [phone]

PGP fingerprint: 89BC 6C79 5B3D 591B 8547  1512 7D11 DBF4 528F 29A0
-------------------------------------------------------------------


Received: from popmail.inbox.se (popmail.inbox.se [193.12.72.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id BAA28842 for <[e-mail]>; Wed, 3 Nov 1999 01:35:00 -0800 (PST)
Received: from stefan2 (accurata.inbox.se [193.12.72.24]) by popmail.inbox.se (8.9.3/8.9.3) with SMTP id KAA02209; Wed, 3 Nov 1999 10:35:05 +0100
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 
Date: Wed, 03 Nov 1999 10:35:33 +0100
To: "Anders Rundgren" <[e-mail]>, <[e-mail]>, "'SEIS-List'" <[e-mail]>
From: Stefan Santesson <[e-mail]>
Subject: Re: QC Container-ID (card serial)
In-Reply-To: <003801bf25d0$a653fa90$[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by ns.secondary.com id BAA28843

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                <[e-mail]>
Accurata AB                     http://www.accurata.se
Slagthuset                      Tel. [phone]              
211 20  Malmö                   Fax. [phone]              
Sweden                        Mobile [phone]

PGP fingerprint: 89BC 6C79 5B3D 591B 8547  1512 7D11 DBF4 528F 29A0
-------------------------------------------------------------------


Received: from clbull.frcl.bull.fr (clbull.frcl.bull.fr [129.182.8.31]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id BAA28421 for <[e-mail]>; Wed, 3 Nov 1999 01:10:49 -0800 (PST)
Received: from bull.net (frcls6118.frcl.bull.fr [129.182.109.213]) by clbull.frcl.bull.fr (8.9.2/8.9.1) with ESMTP id KAA42670; Wed, 3 Nov 1999 10:10:18 +0100
Message-ID: <[e-mail]>
Date: Wed, 03 Nov 1999 10:10:08 +0100
From: Denis Pinkas <[e-mail]>
Organization: Bull
X-Mailer: Mozilla 4.06 [fr] (Win95; I)
MIME-Version: 1.0
To: "Todd Glassey @ GMT" <[e-mail]>
CC: [e-mail], [e-mail]
Subject: Re: Timestamping Standards.
References: <04b001bf257f$40a14b90$[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

> 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


Received: from caesar.udac.se (caesar.udac.se [193.44.79.10]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id WAA26247 for <[e-mail]>; Tue, 2 Nov 1999 22:57:26 -0800 (PST)
Received: from mega (t3o69p48.telia.com [62.20.145.48]) by caesar.udac.se (8.7.3/NetworkC-1) with SMTP id HAA18626; Wed, 3 Nov 1999 07:54:11 +0100
Message-ID: <003801bf25d0$a653fa90$[e-mail]>
From: "Anders Rundgren" <[e-mail]>
To: "Stefan Santesson" <[e-mail]>, <[e-mail]>, "'SEIS-List'" <[e-mail]>
Subject: QC Container-ID (card serial)
Date: Wed, 3 Nov 1999 07:54:24 -0000
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 4.72.3110.5
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by ns.secondary.com id WAA26248

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




Received: from shell.nl ([e-mail] [134.146.4.10]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id RAA15688 for <[e-mail]>; Tue, 2 Nov 1999 17:58:25 -0800 (PST)
Received: by shell.nl; id CAA05864; Wed, 3 Nov 1999 02:58:32 +0100 (MET)
Received: from rijpats6104.scis.shell.nl(145.26.80.33) by charon-3.shell.nl via smap (4.1) id xma005768; Wed, 3 Nov 99 02:58:12 +0100
Received: by rijpats6104.scis.shell.nl with Internet Mail Service (5.5.2650.10) id <WD0S8AB7>; Wed, 3 Nov 1999 02:58:11 +0100
Message-ID: <91F077611570D211B0B40008C7244B3301B88CDE@LDMS6001>
From: "Lunow, Pauwl PB SSI-TSIS" <[e-mail]>
To: "'Bob Jueneman'" <[e-mail]>
Cc: [e-mail]
Subject: RE: QC certificates and Nationality
Date: Wed, 3 Nov 1999 02:58:05 +0100 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.10)
Content-Type: text/plain; charset="iso-8859-1"

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:[e-mail]]
Sent: 02 November 1999 19:42
To: [e-mail]; [e-mail]
Cc: [e-mail]; [e-mail]; [e-mail];
[e-mail]
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." <[e-mail]> 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:[e-mail]] 
Sent: Tuesday, November 02, 1999 12:55 PM
To: Miklos, Sue A.
Cc: Russ Housley; [e-mail]; '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:[e-mail]] 
> Sent: Tuesday, November 02, 1999 4:32 AM
> To: Russ Housley
> Cc: [e-mail]; '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


Received: from prv-mail20.provo.novell.com (prv-mail20.provo.novell.com [137.65.82.195]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id RAA15410 for <[e-mail]>; Tue, 2 Nov 1999 17:47:46 -0800 (PST)
Received: from INET-PRV-Message_Server by prv-mail20.provo.novell.com with Novell_GroupWise; Tue, 02 Nov 1999 18:42:19 -0700
Message-Id: <[e-mail]>
X-Mailer: Novell GroupWise Internet Agent 5.5.2.1
Date: Tue, 02 Nov 1999 18:42:10 -0700
From: "Bob Jueneman" <[e-mail]>
To: <[e-mail]>, <[e-mail]>
Cc: <[e-mail]>, <[e-mail]>, <[e-mail]>, <[e-mail]>
Subject: RE: QC certificates and Nationality
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by ns.secondary.com id RAA15412

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." <[e-mail]> 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:[e-mail]] 
Sent: Tuesday, November 02, 1999 12:55 PM
To: Miklos, Sue A.
Cc: Russ Housley; [e-mail]; '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:[e-mail]] 
> Sent: Tuesday, November 02, 1999 4:32 AM
> To: Russ Housley
> Cc: [e-mail]; '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


Received: from mail.student.auckland.ac.nz (mail.student.auckland.ac.nz [130.216.35.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id RAA15058 for <[e-mail]>; Tue, 2 Nov 1999 17:33:14 -0800 (PST)
Received: from cs26.cs.auckland.ac.nz ([e-mail] [130.216.36.9]) by mail.student.auckland.ac.nz (8.9.3/8.8.6/cs-master) with SMTP id OAA20185 for <[e-mail]>; Wed, 3 Nov 1999 14:33:22 +1300 (NZDT) (sender [e-mail])
Received: by cs26.cs.auckland.ac.nz (relaymail v0.9) id <94159280218781>; Wed, 3 Nov 1999 14:33:22 (NZDT)
From: [e-mail] (Peter Gutmann)
To: [e-mail]
Subject: Re: Possible patent issue with UTCTime hack
Sender: [e-mail]
Reply-To: [e-mail]
X-Charge-To: pgut001
X-Authenticated: relaymail v0.9 on cs26.cs.auckland.ac.nz
Date: Wed, 3 Nov 1999 14:33:22 (NZDT)
Message-ID: <[e-mail]>

Marc Branchaud <[e-mail]> 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.




Received: from consensus.com (mail.consensus.com [157.22.240.7]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id RAA14749 for <[e-mail]>; Tue, 2 Nov 1999 17:23:09 -0800 (PST)
Received: from haruspex (157.22.240.51) by consensus.com with SMTP (Eudora Internet Mail Server 1.2); Tue, 2 Nov 1999 18:07:35 -0700
From: "Tim Dierks" <[e-mail]>
To: <[e-mail]>
Subject: RE: Possible patent issue with UTCTime hack
Date: Tue, 2 Nov 1999 17:24:51 -0800
Message-ID: <006901bf259a$3a00de70$[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook 8.5, Build 4.71.2232.26
In-Reply-To: <[e-mail]>
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3
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
[e-mail]
510.780.5409 [Hayward] -- 905.501.3791 [Mississauga]

> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]]On Behalf
> Of Marc Branchaud
> Sent: Tuesday, November 02, 1999 5:47 PM
> To: [e-mail]
> 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
>



Received: from mailext04.compaq.com (mailext04.compaq.com [207.18.199.42]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id QAA14181 for <[e-mail]>; Tue, 2 Nov 1999 16:46:40 -0800 (PST)
Received: from mailint12.im.hou.compaq.com (mailint12.compaq.com [207.18.199.190]) by mailext04.compaq.com (Postfix) with ESMTP id 0ECFB104B90; Tue,  2 Nov 1999 18:46:50 -0600 (CST)
Received: by mailint12.im.hou.compaq.com (Postfix, from userid 12345) id 458084FB06; Tue,  2 Nov 1999 18:46:43 -0600 (CST)
Received: from exccup-gh01.mis.tandem.com (exccup-gh01.mis.tandem.com [130.252.226.241]) by mailint12.im.hou.compaq.com (Postfix) with ESMTP id 0FCA84C902; Tue,  2 Nov 1999 18:46:43 -0600 (CST)
Received: by exccup-gh01.mis.tandem.com with Internet Mail Service (5.5.2559.0) id <WD84KP6W>; Tue, 2 Nov 1999 16:46:49 -0800
Message-ID: <[e-mail]>
From: "Kurn, David" <[e-mail]>
To: "'Marc Branchaud'" <[e-mail]>, [e-mail]
Subject: RE: Possible patent issue with UTCTime hack
Date: Tue, 2 Nov 1999 16:46:37 -0800 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2559.0)
Content-Type: text/plain; charset="iso-8859-1"

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:[e-mail]]
Sent: Tuesday, November 02, 1999 5:47 PM
To: [e-mail]
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


Received: from crack.x509.com ([e-mail] [199.175.150.1]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id QAA13958 for <[e-mail]>; Tue, 2 Nov 1999 16:36:54 -0800 (PST)
Received: from xcert.com (saxifrage.x509.com [199.175.148.75]) by crack.x509.com (8.9.3/XCERT) with ESMTP id QAA16350 for <[e-mail]>; Tue, 2 Nov 1999 16:37:03 -0800 (PST)
Sender: [e-mail]
Message-ID: <[e-mail]>
Date: Tue, 02 Nov 1999 17:47:05 -0800
From: Marc Branchaud <[e-mail]>
Organization: Xcert International Inc.
X-Mailer: Mozilla 4.7 [en] (X11; U; Linux 2.2.10 i686)
X-Accept-Language: en, fr
MIME-Version: 1.0
To: [e-mail]
Subject: Possible patent issue with UTCTime hack
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

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


Received: from www.certifeidtime.com. (test.glassey.com [207.126.98.130] (may be forged)) by ns.secondary.com (8.9.3/8.9.3) with SMTP id OAA11571 for <[e-mail]>; Tue, 2 Nov 1999 14:11:41 -0800 (PST)
Received: from gw by www.certifeidtime.com. (SMI-8.6/SMI-SVR4) id OAA07609; Tue, 2 Nov 1999 14:12:46 -0800
Message-ID: <04b001bf257f$40a14b90$[e-mail]>
From: "Todd Glassey @ GMT" <[e-mail]>
To: <[e-mail]>, <[e-mail]>
Subject: Timestamping Standards.
Date: Tue, 2 Nov 1999 14:11:45 -0800
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.00.2919.5600
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.5600

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



Received: from stingray.missi.ncsc.mil (stingray.missi.ncsc.mil [144.51.50.20]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id MAA09933 for <[e-mail]>; Tue, 2 Nov 1999 12:09:29 -0800 (PST)
Received: from stingray.missi.ncsc.mil (root@localhost) by stingray.missi.ncsc.mil with ESMTP id PAA05549 for <[e-mail]>; Tue, 2 Nov 1999 15:09:58 -0500 (EST)
Received: from missi.ncsc.mil (depot.missi.ncsc.mil [144.51.60.1]) by stingray.missi.ncsc.mil with ESMTP id PAA05524 for <[e-mail]>; Tue, 2 Nov 1999 15:09:56 -0500 (EST)
Received: from mimesweeper.missi.ncsc.mil (mimesweeper.missi.ncsc.mil [144.51.60.2]) by missi.ncsc.mil (8.8.8/8.8.8) with ESMTP id PAA11899 for <[e-mail]>; Tue, 2 Nov 1999 15:09:17 -0500 (EST)
Received: from avenger.missi.ncsc.mil (avenger53.missi.ncsc.mil) by mimesweeper.missi.ncsc.mil (Content Technologies SMTPRS 2.0.15) with ESMTP id <[e-mail]>; Tue, 02 Nov 1999 15:09:50 -0500
Received: by avenger54.missi.ncsc.mil with Internet Mail Service (5.5.2232.9) id <TZ046QLS>; Tue, 2 Nov 1999 15:09:50 -0500
Message-Id: <[e-mail]>
From: "Miklos, Sue A." <[e-mail]>
To: "'Paul Koning'" <[e-mail]>
Cc: [e-mail], [e-mail], [e-mail], [e-mail], [e-mail]
Subject: RE: QC certificates and Nationality
Date: Tue, 2 Nov 1999 15:09:48 -0500 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2232.9)
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01BF256E.37CCF534"

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:[e-mail]]
Sent: Tuesday, November 02, 1999 3:00 PM
To: [e-mail]
Cc: [e-mail]; [e-mail]; [e-mail];
[e-mail]; [e-mail]
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:[e-mail]">mailto:[e-mail]</A>]</FONT>
<BR><FONT SIZE=3D2>Sent: Tuesday, November 02, 1999 3:00 PM</FONT>
<BR><FONT SIZE=3D2>To: [e-mail]</FONT>
<BR><FONT SIZE=3D2>Cc: [e-mail]; [e-mail]; =
[e-mail];</FONT>
<BR><FONT SIZE=3D2>[e-mail]; [e-mail]</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--


Received: from dfw7-1.relay.mail.uu.net (dfw7-1.relay.mail.uu.net [199.171.54.106]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id LAA09655 for <[e-mail]>; Tue, 2 Nov 1999 11:59:55 -0800 (PST)
Received: from xedia.com by dfw7sosrv11.alter.net with SMTP  (peer crosschecked as: madway.xedia.com [198.202.232.199]) id QQhnqd15882; Tue, 2 Nov 1999 19:59:31 GMT
Received: from tonga.xedia.com by xedia.com (4.1/SMI-4.1) id AA26332; Tue, 2 Nov 99 14:57:33 EST
Received: by tonga.xedia.com (SMI-8.6/SMI-SVR4) id OAA16203; Tue, 2 Nov 1999 14:59:30 -0500
Date: Tue, 2 Nov 1999 14:59:30 -0500
Message-Id: <[e-mail]>
From: Paul Koning <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
To: [e-mail]
Cc: [e-mail], [e-mail], [e-mail], [e-mail], [e-mail]
Subject: RE: QC certificates and Nationality
References: <[e-mail]>
X-Mailer: VM 6.34 under 20.3 "Vatican City" XEmacs  Lucid

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


Received: from stingray.missi.ncsc.mil (stingray.missi.ncsc.mil [144.51.50.20]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id LAA09361 for <[e-mail]>; Tue, 2 Nov 1999 11:48:26 -0800 (PST)
Received: from stingray.missi.ncsc.mil (root@localhost) by stingray.missi.ncsc.mil with ESMTP id OAA04220 for <[e-mail]>; Tue, 2 Nov 1999 14:48:55 -0500 (EST)
Received: from missi.ncsc.mil (depot.missi.ncsc.mil [144.51.60.1]) by stingray.missi.ncsc.mil with ESMTP id OAA04197 for <[e-mail]>; Tue, 2 Nov 1999 14:48:54 -0500 (EST)
Received: from mimesweeper.missi.ncsc.mil (mimesweeper.missi.ncsc.mil [144.51.60.2]) by missi.ncsc.mil (8.8.8/8.8.8) with ESMTP id OAA11497 for <[e-mail]>; Tue, 2 Nov 1999 14:48:14 -0500 (EST)
Received: from avenger.missi.ncsc.mil (avenger53.missi.ncsc.mil) by mimesweeper.missi.ncsc.mil (Content Technologies SMTPRS 2.0.15) with ESMTP id <[e-mail]>; Tue, 02 Nov 1999 14:48:39 -0500
Received: by avenger54.missi.ncsc.mil with Internet Mail Service (5.5.2232.9) id <TZ046Q2R>; Tue, 2 Nov 1999 14:48:39 -0500
Message-Id: <[e-mail]>
From: "Miklos, Sue A." <[e-mail]>
To: "'Petra Barzin (Gloeckner)'" <[e-mail]>
Cc: Russ Housley <[e-mail]>, [e-mail], "'SEIS-List'" <[e-mail]>, Stefan Santesson <[e-mail]>
Subject: RE: QC certificates and Nationality
Date: Tue, 2 Nov 1999 14:48:32 -0500 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2232.9)
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01BF256B.42040E96"

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:[e-mail]]
Sent: Tuesday, November 02, 1999 12:55 PM
To: Miklos, Sue A.
Cc: Russ Housley; [e-mail]; '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:[e-mail]]
> Sent: Tuesday, November 02, 1999 4:32 AM
> To: Russ Housley
> Cc: [e-mail]; '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:[e-mail]">mailto:[e-mail]</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; [e-mail]; '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:[e-mail]">mailto:[e-mail]</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: [e-mail]; '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--


Received: from CALI.norma.net (root@[209.64.35.35]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id LAA09140 for <[e-mail]>; Tue, 2 Nov 1999 11:42:25 -0800 (PST)
Received: from gmvd.norma.net ([209.64.35.238] (may be forged)) by CALI.norma.net with SMTP (8.8.6 (PHNE_14041)/8.7.1) id OAA25256 for <[e-mail]>; Tue, 2 Nov 1999 14:27:48 -0500 (SAT)
From: "Jorge M. Vargas" <[e-mail]>
To: "Ietf-Pkix" <[e-mail]>
Subject: "List-Unsubscribe:"
Date: Tue, 2 Nov 1999 14:37:01 -0500
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="Windows-1252"
Content-Transfer-Encoding: 7bit
X-Priority: 1 (Highest)
X-MSMail-Priority: High
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300
Importance: High

"List-Unsubscribe:"


Received: from prv-mail20.provo.novell.com (prv-mail20.provo.novell.com [137.65.82.195]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id LAA08914 for <[e-mail]>; Tue, 2 Nov 1999 11:36:23 -0800 (PST)
Received: from INET-PRV-Message_Server by prv-mail20.provo.novell.com with Novell_GroupWise; Tue, 02 Nov 1999 12:15:33 -0700
Message-Id: <[e-mail]>
X-Mailer: Novell GroupWise Internet Agent 5.5.2.1
Date: Tue, 02 Nov 1999 11:52:15 -0700
From: "Bob Jueneman" <[e-mail]>
To: <[e-mail]>, <[e-mail]>, <[e-mail]>
Cc: <[e-mail]>, <[e-mail]>
Subject: RE: NR, redux, again.
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by ns.secondary.com id LAA08915

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 <[e-mail]> 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:	[e-mail] [SMTP:[e-mail]] 
> Sent:	Tuesday, November 02, 1999 12:23 PM
> To:	Tony Bartoletti
> Cc:	Bob Jueneman; [e-mail]; [e-mail] 
> 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: [phone]   fax: [phone]               LL LLLLLLLL
> email: [e-mail]                                   LLLLLLLL
> 
> 


Received: from exchng-fairfax.p-e-c.com (exchng-fairfax.pec.com [204.254.216.13]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id LAA08611 for <[e-mail]>; Tue, 2 Nov 1999 11:25:52 -0800 (PST)
Received: by EXCHNG-FAIRFAX with Internet Mail Service (5.0.1460.8) id <VTYA8VJ2>; Tue, 2 Nov 1999 14:26:26 -0500
Message-ID: <186F6BB05130D311902F0008C7F450FD9308CA@EXCHNG-FAIRFAX>
From: MHenry <[e-mail]>
To: "'Bob Jueneman'" <[e-mail]>, Tony Bartoletti <[e-mail]>, MHenry <[e-mail]>, "'[e-mail]'" <[e-mail]>
Cc: [e-mail], [e-mail]
Subject: RE: NR, redux, again.
Date: Tue, 2 Nov 1999 14:26:23 -0500 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.0.1460.8)
Content-Type: text/plain; charset="iso-8859-1"

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:[e-mail]]
> Sent:	Tuesday, November 02, 1999 1:52 PM
> To:	Tony Bartoletti; [e-mail]; '[e-mail]'
> Cc:	[e-mail]; [e-mail]
> 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 <[e-mail]> 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:	[e-mail] [SMTP:[e-mail]] 
> > Sent:	Tuesday, November 02, 1999 12:23 PM
> > To:	Tony Bartoletti
> > Cc:	Bob Jueneman; [e-mail]; [e-mail] 
> > 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: [phone]   fax: [phone]               LL LLLLLLLL
> > email: [e-mail]                                   LLLLLLLL
> > 
> > 


Received: from Default (ip12.proper.com [165.227.249.12]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id LAA08311 for <[e-mail]>; Tue, 2 Nov 1999 11:19:13 -0800 (PST)
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.1 
Date: Tue, 02 Nov 1999 11:19:08 -0800
To: <[e-mail]>
From: Paul Hoffman / IMC <[e-mail]>
Subject: Re: 
In-Reply-To: <000201bf2561$928246d0$[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed

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:
      [e-mail]
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



Received: from poptop.llnl.gov (poptop.llnl.gov [128.115.18.65]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id LAA08105 for <[e-mail]>; Tue, 2 Nov 1999 11:15:13 -0800 (PST)
Received: from catalyst (catalyst.llnl.gov [128.115.223.61]) by poptop.llnl.gov (8.8.8/LLNL-3.0.2/pop.llnl.gov-5.1) with SMTP id LAA17164; Tue, 2 Nov 1999 11:15:16 -0800 (PST)
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.3 (32)
Date: Tue, 02 Nov 1999 11:15:21 -0800
To: [e-mail]
From: Tony Bartoletti <[e-mail]>
Subject: Re: NR, redux, again.
Cc: "Bob Jueneman" <[e-mail]>, [e-mail], [e-mail]
In-Reply-To: <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"

At 12:23 PM 11/2/99 -0500, [e-mail] 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: [phone]   fax: [phone]               LL LLLLLLLL
email: [e-mail]                                   LLLLLLLL


Received: from CALI.norma.net (root@[209.64.35.35]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id KAA07669 for <[e-mail]>; Tue, 2 Nov 1999 10:55:12 -0800 (PST)
Received: from gmvd.norma.net ([209.64.35.238] (may be forged)) by CALI.norma.net with SMTP (8.8.6 (PHNE_14041)/8.7.1) id NAA22580 for <[e-mail]>; Tue, 2 Nov 1999 13:40:15 -0500 (SAT)
From: "Jorge M. Vargas" <[e-mail]>
To: "Ietf-Pkix" <[e-mail]>
Date: Tue, 2 Nov 1999 13:49:28 -0500
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="Windows-1252"
Content-Transfer-Encoding: 7bit
X-Priority: 1 (Highest)
X-MSMail-Priority: High
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300
Importance: High

REMOVE


Received: from server1 ([216.51.48.2]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id KAA07182 for <[e-mail]>; Tue, 2 Nov 1999 10:39:45 -0800 (PST)
Received: from dev69 ([216.51.48.3] (may be forged)) by server1 (2.5 Build 2640 (Berkeley 8.8.6)/8.8.4) with SMTP id NAA00021 for <[e-mail]>; Tue, 02 Nov 1999 13:41:15 -0500
From: "Dan Carson" <[e-mail]>
To: <[e-mail]>
Subject: 
Date: Tue, 2 Nov 1999 13:39:17 -0500
Message-ID: <000201bf2561$928246d0$[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2910.0)
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300

REMOVE


Received: from exchng-fairfax.p-e-c.com (exchng-fairfax.pec.com [204.254.216.13]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id KAA06901 for <[e-mail]>; Tue, 2 Nov 1999 10:31:55 -0800 (PST)
Received: by EXCHNG-FAIRFAX with Internet Mail Service (5.0.1460.8) id <VTYA840J>; Tue, 2 Nov 1999 13:32:32 -0500
Message-ID: <186F6BB05130D311902F0008C7F450FD9308C9@EXCHNG-FAIRFAX>
From: MHenry <[e-mail]>
To: "'[e-mail]'" <[e-mail]>, Tony Bartoletti <[e-mail]>
Cc: Bob Jueneman <[e-mail]>, [e-mail], [e-mail]
Subject: RE: NR, redux, again.
Date: Tue, 2 Nov 1999 13:32:29 -0500 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.0.1460.8)
Content-Type: text/plain

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:	[e-mail] [SMTP:[e-mail]]
> Sent:	Tuesday, November 02, 1999 12:23 PM
> To:	Tony Bartoletti
> Cc:	Bob Jueneman; [e-mail]; [e-mail]
> 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: [phone]   fax: [phone]               LL LLLLLLLL
> email: [e-mail]                                   LLLLLLLL
> 
> 


Received: from sonne.darmstadt.gmd.de (sonne.darmstadt.gmd.de [141.12.62.20]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id KAA06283 for <[e-mail]>; Tue, 2 Nov 1999 10:03:15 -0800 (PST)
Received: from secude.com (ip27.secude.com [141.12.207.27]) by sonne.darmstadt.gmd.de (8.8.8/8.8.5) with ESMTP id SAA29858; Tue, 2 Nov 1999 18:37:12 +0100 (MET)
Message-ID: <[e-mail]>
Date: Tue, 02 Nov 1999 18:45:25 +0100
From: "Petra Barzin (Gloeckner)" <[e-mail]>
X-Mailer: Mozilla 4.61 [en] (WinNT; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Russ Housley <[e-mail]>, [e-mail], "'SEIS-List'" <[e-mail]>, Stefan Santesson <[e-mail]>
Subject: Re: QC certificates and Nationality
References: <[e-mail]> <[e-mail]>
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms9E334005D11BEAF704F3B3CD"

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: [phone] - 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:[e-mail]
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

MIIFGQYJKoZIhvcNAQcCoIIFCjCCBQYCAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC
AzIwggMuMIICFqADAgECAgE5MA0GCSqGSIb3DQEBBQUAMFAxCzAJBgNVBAYTAkRFMRQwEgYD
VQQKEwtTRUNVREUgR21iSDErMCkGA1UECxMiU0VDVURFIFRydXN0RmFjdG9yeSBJbmRpdmlk
dWFscyBDQTAeFw05OTA3MTMwOTQ2MTBaFw0wMTA3MTQxMTQ2MTBaMDoxCzAJBgNVBAYTAkRF
MRQwEgYDVQQKEwtTRUNVREUgR21iSDEVMBMGA1UEAxMMUGV0cmEgQmFyemluMIGfMA0GCSqG
SIb3DQEBAQUAA4GNADCBiQKBgQD/xTznxvh0jx9ffLhG0SWKXScaWO58cCykwVI8V6yCKawh
yBDOErlcC8CtMRiP50iYY5KF3i3dcKsFEkdPwx1/8YSja8/0Ao03llO7go1FyFiGiZ5BJrdU
6X/eieShI3J72pwa1Rwb1Oj6G1mhlj9xFDoACypSucXguNsQAxN/awIDAQABo4GsMIGpMA4G
A1UdDwEB/wQEAwID+DAcBgNVHREEFTATgRFiYXJ6aW5Ac2VjdWRlLmNvbTBYBgNVHRIEUTBP
gRd0cnVzdGZhY3RvcnlAc2VjdWRlLmNvbYY0aHR0cDovL3d3dy5zZWN1ZGUuY29tL3RydXN0
ZmFjdG9yeS9pbmRpdmlkdWFsc2NhLmNydDAMBgNVHRMBAf8EAjAAMBEGCWCGSAGG+EIBAQQE
AwIAoDANBgkqhkiG9w0BAQUFAAOCAQEArB/E9eylaBJul4O69g4aFsrKHMuIiijNNYGDGV8i
RkcY8mw+K7y9o7+7wbkcCEFBsfhwaog6tN9u18t8RwCjprHzKVgK+QWlpOEmGyUVT443U1Ju
necYCmyBhFlCqmeco7UN9nLDZ26rq6zTuP/Pl3wsx4QjNcsmEPLP57x1cny4HFPg7+uHCR7z
FjDgjJIBWSl5dIT9+ORwiFuaRJKBVx+5KIJdIJhWPev6dVjCJw516VIWPjrVmGNPb8dq8tfg
+iC2tLKzGgnVMRnMakMvUGUEyFOR3azN+HW13eG9Kj1Cc3yuTI2UEImmuW6fKfrGTDMinVHT
YdcrT+11mu0dkDGCAa8wggGrAgEBMFUwUDELMAkGA1UEBhMCREUxFDASBgNVBAoTC1NFQ1VE
RSBHbWJIMSswKQYDVQQLEyJTRUNVREUgVHJ1c3RGYWN0b3J5IEluZGl2aWR1YWxzIENBAgE5
MAkGBSsOAwIaBQCggbEwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUx
DxcNOTkxMTAyMTc0NTI4WjAjBgkqhkiG9w0BCQQxFgQU6wSe0AJL/Fig7t6D1BKCKaYN2zww
UgYJKoZIhvcNAQkPMUUwQzAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwBwYFKw4DAgcw
DQYIKoZIhvcNAwICAUAwDQYIKoZIhvcNAwICASgwDQYJKoZIhvcNAQEBBQAEgYDxmgrLKp1R
Qj/LGCgeD7jvrVb5wR1hXMBHV2rb6N3qNgeXKmc3yzFV+ny/WgkKjF7OsLWayj/79u4LKVlU
nbZJ9nQsfOHMKclxYRcmfemCF9e6TMdX7Rr9hju2RuzgztglzSBNIKzaC1Iomu0mbPFfamJd
mOrw25mXhzPh+2Ka8g==
--------------ms9E334005D11BEAF704F3B3CD--



Received: from sonne.darmstadt.gmd.de (sonne.darmstadt.gmd.de [141.12.62.20]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id JAA05913 for <[e-mail]>; Tue, 2 Nov 1999 09:50:05 -0800 (PST)
Received: from secude.com (ip27.secude.com [141.12.207.27]) by sonne.darmstadt.gmd.de (8.8.8/8.8.5) with ESMTP id SAA00290; Tue, 2 Nov 1999 18:46:48 +0100 (MET)
Message-ID: <[e-mail]>
Date: Tue, 02 Nov 1999 18:54:59 +0100
From: "Petra Barzin (Gloeckner)" <[e-mail]>
X-Mailer: Mozilla 4.61 [en] (WinNT; U)
X-Accept-Language: en
MIME-Version: 1.0
To: "Miklos, Sue A." <[e-mail]>
CC: Russ Housley <[e-mail]>, [e-mail], "'SEIS-List'" <[e-mail]>, Stefan Santesson <[e-mail]>
Subject: Re: QC certificates and Nationality
References: <[e-mail]>
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------msAA155E49984B012B5EE4A4B4"

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:[e-mail]]
> Sent: Tuesday, November 02, 1999 4:32 AM
> To: Russ Housley
> Cc: [e-mail]; '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: [phone] - 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:[e-mail]
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

MIIFGQYJKoZIhvcNAQcCoIIFCjCCBQYCAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC
AzIwggMuMIICFqADAgECAgE5MA0GCSqGSIb3DQEBBQUAMFAxCzAJBgNVBAYTAkRFMRQwEgYD
VQQKEwtTRUNVREUgR21iSDErMCkGA1UECxMiU0VDVURFIFRydXN0RmFjdG9yeSBJbmRpdmlk
dWFscyBDQTAeFw05OTA3MTMwOTQ2MTBaFw0wMTA3MTQxMTQ2MTBaMDoxCzAJBgNVBAYTAkRF
MRQwEgYDVQQKEwtTRUNVREUgR21iSDEVMBMGA1UEAxMMUGV0cmEgQmFyemluMIGfMA0GCSqG
SIb3DQEBAQUAA4GNADCBiQKBgQD/xTznxvh0jx9ffLhG0SWKXScaWO58cCykwVI8V6yCKawh
yBDOErlcC8CtMRiP50iYY5KF3i3dcKsFEkdPwx1/8YSja8/0Ao03llO7go1FyFiGiZ5BJrdU
6X/eieShI3J72pwa1Rwb1Oj6G1mhlj9xFDoACypSucXguNsQAxN/awIDAQABo4GsMIGpMA4G
A1UdDwEB/wQEAwID+DAcBgNVHREEFTATgRFiYXJ6aW5Ac2VjdWRlLmNvbTBYBgNVHRIEUTBP
gRd0cnVzdGZhY3RvcnlAc2VjdWRlLmNvbYY0aHR0cDovL3d3dy5zZWN1ZGUuY29tL3RydXN0
ZmFjdG9yeS9pbmRpdmlkdWFsc2NhLmNydDAMBgNVHRMBAf8EAjAAMBEGCWCGSAGG+EIBAQQE
AwIAoDANBgkqhkiG9w0BAQUFAAOCAQEArB/E9eylaBJul4O69g4aFsrKHMuIiijNNYGDGV8i
RkcY8mw+K7y9o7+7wbkcCEFBsfhwaog6tN9u18t8RwCjprHzKVgK+QWlpOEmGyUVT443U1Ju
necYCmyBhFlCqmeco7UN9nLDZ26rq6zTuP/Pl3wsx4QjNcsmEPLP57x1cny4HFPg7+uHCR7z
FjDgjJIBWSl5dIT9+ORwiFuaRJKBVx+5KIJdIJhWPev6dVjCJw516VIWPjrVmGNPb8dq8tfg
+iC2tLKzGgnVMRnMakMvUGUEyFOR3azN+HW13eG9Kj1Cc3yuTI2UEImmuW6fKfrGTDMinVHT
YdcrT+11mu0dkDGCAa8wggGrAgEBMFUwUDELMAkGA1UEBhMCREUxFDASBgNVBAoTC1NFQ1VE
RSBHbWJIMSswKQYDVQQLEyJTRUNVREUgVHJ1c3RGYWN0b3J5IEluZGl2aWR1YWxzIENBAgE5
MAkGBSsOAwIaBQCggbEwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUx
DxcNOTkxMTAyMTc1NTAyWjAjBgkqhkiG9w0BCQQxFgQUb082ht6opVjyVNxXUdYaNuxpa2ow
UgYJKoZIhvcNAQkPMUUwQzAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwBwYFKw4DAgcw
DQYIKoZIhvcNAwICAUAwDQYIKoZIhvcNAwICASgwDQYJKoZIhvcNAQEBBQAEgYDScmnRujPh
0AC9/u66B/y/0sRu61/JhQ8+/vKiXuKVx6giJp4mEQKskv/wsz89C1tVQ0Cehc15btsqfIGE
wZN7kxuoLuWwBcldSNPkV9d3QG0qmd0EdB+KPEmQGvHumrYBbM35Kfw0RKnLRYs71oeOwfTe
zk5nYYOKUApOE5migw==
--------------msAA155E49984B012B5EE4A4B4--



Received: from relay.gw.tislabs.com ([e-mail] [192.94.214.100]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id JAA05443 for <[e-mail]>; Tue, 2 Nov 1999 09:28:01 -0800 (PST)
Received: by relay.gw.tislabs.com; id MAA07070; Tue, 2 Nov 1999 12:37:42 -0500 (EST)
Received: from clipper.gw.tislabs.com(10.33.1.2) by relay.gw.tislabs.com via smap (4.1) id xma007036; Tue, 2 Nov 99 12:37:13 -0500
Received: (from balenson@localhost) by clipper.gw.tislabs.com (8.9.3/8.9.1) id MAA25839 for [e-mail]; Tue, 2 Nov 1999 12:26:11 -0500 (EST)
Date: Tue, 2 Nov 1999 12:26:11 -0500 (EST)
From: "David M. Balenson" <[e-mail]>
Message-Id: <[e-mail]>
To: [e-mail]
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: [phone]         Fax: [phone]
  E-mail: [e-mail]   URL: http://www.isoc.org/ndss2000/

SPONSORSHIP OPPORTUNITIES AVAILABLE!  Take advantage of this high
visibility event.  Contact Carla Rosenfeld at the Internet Society
at [phone] or send e-mail to [e-mail].

THE INTERNET SOCIETY is a non-governmental organization for global
cooperation and coordination for the Internet and its
internetworking technologies and applications.



Received: from e3.ny.us.ibm.com (e3.ny.us.ibm.com [32.97.182.103]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id JAA05243 for <[e-mail]>; Tue, 2 Nov 1999 09:23:39 -0800 (PST)
From: [e-mail]
Received: from northrelay02.pok.ibm.com (northrelay02.pok.ibm.com [9.117.200.22]) by e3.ny.us.ibm.com (8.9.3/8.9.3) with ESMTP id MAA246562; Tue, 2 Nov 1999 12:22:59 -0500
Received: from D51MTA05.pok.ibm.com (d51mta05.pok.ibm.com [9.117.200.33]) by northrelay02.pok.ibm.com (8.8.8m2/NCO v2.06) with SMTP id MAA113904; Tue, 2 Nov 1999 12:23:38 -0500
Received: by D51MTA05.pok.ibm.com(Lotus SMTP MTA v4.6.5  (863.2 5-20-1999))  id 8525681D.005F889D ; Tue, 2 Nov 1999 12:23:28 -0500
X-Lotus-FromDomain: IBMUS
To: Tony Bartoletti <[e-mail]>
cc: "Bob Jueneman" <[e-mail]>, [e-mail], [e-mail]
Message-ID: <[e-mail]>
Date: Tue, 2 Nov 1999 12:23:06 -0500
Subject: Re: NR, redux, again.
Mime-Version: 1.0
Content-type: text/plain; charset=us-ascii
Content-Disposition: inline

(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: [phone]   fax: [phone]               LL LLLLLLLL
email: [e-mail]                                   LLLLLLLL





Received: from stingray.missi.ncsc.mil (stingray.missi.ncsc.mil [144.51.50.20]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id HAA03369 for <[e-mail]>; Tue, 2 Nov 1999 07:36:47 -0800 (PST)
Received: from stingray.missi.ncsc.mil (root@localhost) by stingray.missi.ncsc.mil with ESMTP id KAA13762 for <[e-mail]>; Tue, 2 Nov 1999 10:37:16 -0500 (EST)
Received: from missi.ncsc.mil (depot.missi.ncsc.mil [144.51.60.1]) by stingray.missi.ncsc.mil with ESMTP id KAA13737 for <[e-mail]>; Tue, 2 Nov 1999 10:37:14 -0500 (EST)
Received: from mimesweeper.missi.ncsc.mil (mimesweeper.missi.ncsc.mil [144.51.60.2]) by missi.ncsc.mil (8.8.8/8.8.8) with ESMTP id KAA06394 for <[e-mail]>; Tue, 2 Nov 1999 10:36:34 -0500 (EST)
Received: from avenger.missi.ncsc.mil (avenger53.missi.ncsc.mil) by mimesweeper.missi.ncsc.mil (Content Technologies SMTPRS 2.0.15) with ESMTP id <[e-mail]>; Tue, 02 Nov 1999 09:21:44 -0500
Received: by avenger54.missi.ncsc.mil with Internet Mail Service (5.5.2232.9) id <TZ046NXP>; Tue, 2 Nov 1999 09:21:44 -0500
Message-Id: <[e-mail]>
From: "Miklos, Sue A." <[e-mail]>
To: "'Petra Barzin (Gloeckner)'" <[e-mail]>, Russ Housley <[e-mail]>
Cc: [e-mail], "'SEIS-List'" <[e-mail]>, Stefan Santesson <[e-mail]>
Subject: RE: QC certificates and Nationality
Date: Tue, 2 Nov 1999 09:21:35 -0500 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2232.9)
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01BF253D.9601E4C4"

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:[e-mail]]
Sent: Tuesday, November 02, 1999 4:32 AM
To: Russ Housley
Cc: [e-mail]; '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:[e-mail]">mailto:[e-mail]</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: [e-mail]; '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--


Received: from btec-fw.certco.com (btec-fw.certco.com [209.2.102.3]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id FAA01698 for <[e-mail]>; Tue, 2 Nov 1999 05:38:40 -0800 (PST)
From: [e-mail]
Received: from nycertco-srv1.ny.certco.com (nycertco-srv1.certco.com [10.100.24.12]) by btec-fw.certco.com (Postfix) with ESMTP id A29C232DDD; Tue,  2 Nov 1999 08:38:17 -0500 (EST)
Received: by nycertco-srv1.certco.com with Internet Mail Service (5.5.2448.0) id <V674Y23C>; Tue, 2 Nov 1999 08:39:06 -0500
Message-ID: <[e-mail]>
To: [e-mail], [e-mail]
Cc: [e-mail], [e-mail], [e-mail]
Subject: RE: QC certificates and Nationality
Date: Tue, 2 Nov 1999 08:39:05 -0500 
X-Mailer: Internet Mail Service (5.5.2448.0)

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:[e-mail]]
Sent: Tuesday, November 02, 1999 4:32 AM
To: Russ Housley
Cc: [e-mail]; '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


Received: from sonne.darmstadt.gmd.de (sonne.darmstadt.gmd.de [141.12.62.20]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id BAA26279 for <[e-mail]>; Tue, 2 Nov 1999 01:30:40 -0800 (PST)
Received: from secude.com (ip27.secude.com [141.12.207.27]) by sonne.darmstadt.gmd.de (8.8.8/8.8.5) with ESMTP id KAA00062; Tue, 2 Nov 1999 10:23:24 +0100 (MET)
Message-ID: <[e-mail]>
Date: Tue, 02 Nov 1999 10:31:39 +0100
From: "Petra Barzin (Gloeckner)" <[e-mail]>
X-Mailer: Mozilla 4.61 [en] (WinNT; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Russ Housley <[e-mail]>
CC: [e-mail], "'SEIS-List'" <[e-mail]>, Stefan Santesson <[e-mail]>
Subject: Re: QC certificates and Nationality
References: <[e-mail]>
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms84753ED393EB948AD194E8F1"

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: [phone] - 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:[e-mail]
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

MIIFGQYJKoZIhvcNAQcCoIIFCjCCBQYCAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC
AzIwggMuMIICFqADAgECAgE5MA0GCSqGSIb3DQEBBQUAMFAxCzAJBgNVBAYTAkRFMRQwEgYD
VQQKEwtTRUNVREUgR21iSDErMCkGA1UECxMiU0VDVURFIFRydXN0RmFjdG9yeSBJbmRpdmlk
dWFscyBDQTAeFw05OTA3MTMwOTQ2MTBaFw0wMTA3MTQxMTQ2MTBaMDoxCzAJBgNVBAYTAkRF
MRQwEgYDVQQKEwtTRUNVREUgR21iSDEVMBMGA1UEAxMMUGV0cmEgQmFyemluMIGfMA0GCSqG
SIb3DQEBAQUAA4GNADCBiQKBgQD/xTznxvh0jx9ffLhG0SWKXScaWO58cCykwVI8V6yCKawh
yBDOErlcC8CtMRiP50iYY5KF3i3dcKsFEkdPwx1/8YSja8/0Ao03llO7go1FyFiGiZ5BJrdU
6X/eieShI3J72pwa1Rwb1Oj6G1mhlj9xFDoACypSucXguNsQAxN/awIDAQABo4GsMIGpMA4G
A1UdDwEB/wQEAwID+DAcBgNVHREEFTATgRFiYXJ6aW5Ac2VjdWRlLmNvbTBYBgNVHRIEUTBP
gRd0cnVzdGZhY3RvcnlAc2VjdWRlLmNvbYY0aHR0cDovL3d3dy5zZWN1ZGUuY29tL3RydXN0
ZmFjdG9yeS9pbmRpdmlkdWFsc2NhLmNydDAMBgNVHRMBAf8EAjAAMBEGCWCGSAGG+EIBAQQE
AwIAoDANBgkqhkiG9w0BAQUFAAOCAQEArB/E9eylaBJul4O69g4aFsrKHMuIiijNNYGDGV8i
RkcY8mw+K7y9o7+7wbkcCEFBsfhwaog6tN9u18t8RwCjprHzKVgK+QWlpOEmGyUVT443U1Ju
necYCmyBhFlCqmeco7UN9nLDZ26rq6zTuP/Pl3wsx4QjNcsmEPLP57x1cny4HFPg7+uHCR7z
FjDgjJIBWSl5dIT9+ORwiFuaRJKBVx+5KIJdIJhWPev6dVjCJw516VIWPjrVmGNPb8dq8tfg
+iC2tLKzGgnVMRnMakMvUGUEyFOR3azN+HW13eG9Kj1Cc3yuTI2UEImmuW6fKfrGTDMinVHT
YdcrT+11mu0dkDGCAa8wggGrAgEBMFUwUDELMAkGA1UEBhMCREUxFDASBgNVBAoTC1NFQ1VE
RSBHbWJIMSswKQYDVQQLEyJTRUNVREUgVHJ1c3RGYWN0b3J5IEluZGl2aWR1YWxzIENBAgE5
MAkGBSsOAwIaBQCggbEwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUx
DxcNOTkxMTAyMDkzMTQyWjAjBgkqhkiG9w0BCQQxFgQUIyNe2ZRifMpV/1UXsL49kfb8Dx8w
UgYJKoZIhvcNAQkPMUUwQzAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwBwYFKw4DAgcw
DQYIKoZIhvcNAwICAUAwDQYIKoZIhvcNAwICASgwDQYJKoZIhvcNAQEBBQAEgYBzcZKITZDx
GSPfl+vYBu4urbtLja6hX5UkLkZ1Shzua50FnqUr55xfbziB3KUyFUemB0hx9fJbsyCaXxOb
wWjfwqUPidtfkwVzusJ6LQ/AykhLyxSGuHYy5zKZAKWqNycBm1gHidtaOXtox6uBAiP6tg60
XWK81qfZBup+htB5Fw==
--------------ms84753ED393EB948AD194E8F1--



Received: from ns.cmbchina.com ([202.96.161.112]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id TAA09874 for <[e-mail]>; Mon, 1 Nov 1999 19:41:58 -0800 (PST)
Received: from cmbchina.com ([10.1.4.27]) by ns.cmbchina.com (Netscape Messaging Server 3.01)  with ESMTP id AAA28216 for <[e-mail]>; Tue, 2 Nov 1999 10:50:33 -0800
Message-ID: <[e-mail]>
Date: Tue, 02 Nov 1999 10:50:28 +0800
From: "Xiong Shao Jun" <[e-mail]>
Organization: China Merchants Bank
X-Mailer: Mozilla 4.04 [en] (Win95; I)
MIME-Version: 1.0
To: [e-mail]
Subject: Re: directory entry with NULL DN
References: <[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

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





Received: from gandalf.trustpoint.com (IDENT:[e-mail] [216.100.231.61]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id OAA02479 for <[e-mail]>; Mon, 1 Nov 1999 14:39:30 -0800 (PST)
Received: from mobile (mobile [192.168.42.7]) by gandalf.trustpoint.com (8.8.7/8.8.7) with SMTP id OAA12378 for <[e-mail]>; Mon, 1 Nov 1999 14:39:34 -0800
From: "Amit Kapoor" <[e-mail]>
To: "PKIX" <[e-mail]>
Subject: String representation of GeneralName
Date: Mon, 1 Nov 1999 14:34:12 -0800
MIME-Version: 1.0
Message-ID: <002301bf24b9$383c0330$[e-mail]>
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0
Content-Type: multipart/signed; boundary="----=_NextPart_000_001E_01BF2476.29A7B1E0"; protocol="application/x-pkcs7-signature"; micalg=SHA-1
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.2106.4
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"

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIID1DCCA9Aw
ggM7oAMCAQICFEQ41iugpRpD1VzRmFQZQnkJUk6OMAsGCSqGSIb3DQEBBTA1MRYwFAYDVQQDEw1T
TWVtZSBSb290IENBMQ4wDAYDVQQKEwVTTWVtZTELMAkGA1UEBhMCVVMwHhcNOTkwNjI4MDAzMDE3
WhcNMDQwNjI4MDAzMDE3WjBPMRMwEQYDVQQKEwpUcnVzdHBvaW50MRQwEgYDVQQDEwtBbWl0IEth
cG9vcjEiMCAGCSqGSIb3DQEJARYTYW1pdEB0cnVzdHBvaW50LmNvbTCBnzANBgkqhkiG9w0BAQEF
AAOBjQAwgYkCgYEAs/M5RIk9+UTqdrpG/UaFOjxTfCs7S9kCJtHroRgDS3Ss+eKt+Re+6NLnxm3S
+pszODOrglLwn19+Zbp3yeVXMsaYLy9+9Jwcm0l+wQGDk8Kh8xUA1MQssVaW9rWamtAvQY+Mje4S
HBjXayCIPyIMJ29Ypk49P1vKbuqgLB/ZQFECAwEAAaOCAcUwggHBMB0GA1UdDgQWBBRo1B8wQ8Kj
E90aF8xiyBKsdXMc3zAhBgNVHSMEGgQYMBaAFNn4T+T2AbGNdK0uQPH1CbqIJeqNMA4GA1UdDwEB
/wQEAwIA+DAnBgNVHSUEIDAeBggrBgEFBQcDAgYIKwYBBQUHAwMGCCsGAQUFBwMEMBEGCWCGSAGG
+EIBAQQEAwIAsDAeBgNVHREEFzAVgRNhbWl0QHRydXN0cG9pbnQuY29tME8GA1UdIARIMEYwRAYI
KwYEAZhUHgEwODA2BggrBgEFBQcCARYqaHR0cDovL3d3dy5zbWVtZS5jb20vc2VydmljZWFncmVl
bWVudC5odG1sMEMGCWCGSAGG+EIBAwQ2FjRodHRwOi8vd3d3LnNtZW1lLmNvbS9zZXJ2bGV0cy9z
bWVtZV9jYS9jaGVja19yZXZva2VkMEAGCWCGSAGG+EIBBwQzFjFodHRwOi8vd3d3LnNtZW1lLmNv
bS9zZXJ2bGV0cy9zbWVtZV9jYS9yZW5ld19jZXJ0MDkGCWCGSAGG+EIBCAQsFipodHRwOi8vd3d3
LnNtZW1lLmNvbS9zZXJ2aWNlYWdyZWVtZW50Lmh0bWwwCwYJKoZIhvcNAQEFA4GBAFS76N1D2ogo
AEAUBV8b6/skJBuju82MnaKh9RlJ7elFikwwPGe9SEblPtbp/+QbDtAVIiwmOIE1XPEZi0cWfLTi
P8pa0BRBl5H419aoIfeoZTsZz4R7E7eGd7rsK37dyBzKbnqio2nzJNhx7FJJDkA7VajJbhk8tdkW
RL6IjymQMYIB/TCCAfkCAQEwTTA1MRYwFAYDVQQDEw1TTWVtZSBSb290IENBMQ4wDAYDVQQKEwVT
TWVtZTELMAkGA1UEBhMCVVMCFEQ41iugpRpD1VzRmFQZQnkJUk6OMAkGBSsOAwIaBQCgggEGMBgG
CSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTk5MTEwMTIyMzQxMVowIwYJ
KoZIhvcNAQkEMRYEFJRfxunwfqtWaK93Kgpza3FVloaRMEkGCSqGSIb3DQEJDzE8MDowCgYIKoZI
hvcNAwcwDgYIKoZIhvcNAwICAgCAMAcGBSsOAwIHMAcGBSsOAwIaMAoGCCqGSIb3DQIFMFwGCSsG
AQQBgjcQBDFPME0wNTEWMBQGA1UEAxMNU01lbWUgUm9vdCBDQTEOMAwGA1UEChMFU01lbWUxCzAJ
BgNVBAYTAlVTAhREONYroKUaQ9Vc0ZhUGUJ5CVJOjjANBgkqhkiG9w0BAQEFAASBgJEceAHMpp4k
BJ2FtzVfQ/xfwDaUzjH4sVKwwdI/3bTL+3z6DJ+0P4GDaUTHrSVWZjHvxNHhUohvLAnOKZV7EcBw
hQv0Q3+ea8FwGZHNxjrvkVQd/txugkkYqrlZ9ItyMWoxokMvohA1JJaqt8lRmhaLaIe7vdDjjTrP
y3CIDC3cAAAAAAAA

------=_NextPart_000_001E_01BF2476.29A7B1E0--



Received: from dfw-smtpout3.email.verio.net (dfw-smtpout3-ext.email.verio.net [129.250.36.43]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id LAA00295 for <[e-mail]>; Mon, 1 Nov 1999 11:54:40 -0800 (PST)
Received: from dfw-mmp4.email.verio.net ([129.250.38.64]) by dfw-smtpout3.email.verio.net (Netscape Messaging Server 4.05) with ESMTP id FKJBB400.MNP for <[e-mail]>; Mon, 1 Nov 1999 19:54:40 +0000 
Received: from nma.com ([209.21.28.86]) by dfw-mmp4.email.verio.net (Netscape Messaging Server 4.05) with ESMTP id FKJBAF00.UJL; Mon, 1 Nov 1999 19:54:15 +0000 
Message-ID: <[e-mail]>
Date: Mon, 01 Nov 1999 11:53:42 -0800
From: Ed Gerck <[e-mail]>
X-Mailer: Mozilla 4.7 [en]C-CCK-MCD {Sony}  (Win98; I)
X-Accept-Language: en
MIME-Version: 1.0
To: Sean Turner <[e-mail]>
CC: Alfred Arsenault <[e-mail]>, IETF-PXIX <[e-mail]>
Subject: Re: lifetime versus NR, Re: Comments on the PKIX Roadmap
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

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



Received: from poptop.llnl.gov (poptop.llnl.gov [128.115.18.65]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id LAA29577 for <[e-mail]>; Mon, 1 Nov 1999 11:14:58 -0800 (PST)
Received: from catalyst (catalyst.llnl.gov [128.115.223.61]) by poptop.llnl.gov (8.8.8/LLNL-3.0.2/pop.llnl.gov-5.1) with SMTP id LAA09629; Mon, 1 Nov 1999 11:14:56 -0800 (PST)
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.3 (32)
Date: Mon, 01 Nov 1999 11:15:02 -0800
To: "Bob Jueneman" <[e-mail]>, <[e-mail]>
From: Tony Bartoletti <[e-mail]>
Subject: Re: NR, redux, again.
Cc: <[e-mail]>
In-Reply-To: <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"

At 09:57 AM 11/1/99 -0700, Bob Jueneman wrote:
>>>> Oscar Jacobsson <[e-mail]> 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: [phone]   fax: [phone]               LL LLLLLLLL
email: [e-mail]                                   LLLLLLLL


Received: from smtp-out1.bellatlantic.net (smtp-out1.bellatlantic.net [199.45.39.156]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id LAA29214 for <[e-mail]>; Mon, 1 Nov 1999 11:07:41 -0800 (PST)
Received: from ieca.com (adsl-151-200-26-46.bellatlantic.net [151.200.26.46]) by smtp-out1.bellatlantic.net (8.9.1/8.9.1) with ESMTP id OAA10093; Mon, 1 Nov 1999 14:03:27 -0500 (EST)
Message-ID: <[e-mail]>
Date: Mon, 01 Nov 1999 13:52:10 -0500
From: Sean Turner <[e-mail]>
Organization: IECA, Inc.
X-Mailer: Mozilla 4.7 [en] (Win98; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Ed Gerck <[e-mail]>
CC: Alfred Arsenault <[e-mail]>, IETF-PXIX <[e-mail]>
Subject: Re: lifetime versus NR, Re: Comments on the PKIX Roadmap
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

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





Received: from smtp-out2.bellatlantic.net (smtp-out2.bellatlantic.net [199.45.39.157]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id LAA29179 for <[e-mail]>; Mon, 1 Nov 1999 11:06:19 -0800 (PST)
Received: from ieca.com (adsl-151-200-26-46.bellatlantic.net [151.200.26.46]) by smtp-out2.bellatlantic.net (8.9.1/8.9.1) with ESMTP id OAA02605; Mon, 1 Nov 1999 14:10:14 -0500 (EST)
Message-ID: <[e-mail]>
Date: Mon, 01 Nov 1999 13:48:18 -0500
From: Sean Turner <[e-mail]>
Organization: IECA, Inc.
X-Mailer: Mozilla 4.7 [en] (Win98; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Ed Gerck <[e-mail]>
CC: Bob Jueneman <[e-mail]>, Alfred Arsenault <[e-mail]>, IETF-PXIX <[e-mail]>
Subject: Re: NR, redux, again.
References: <[e-mail]> <[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

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





Received: from dfw-smtpout2.email.verio.net (dfw-smtpout2-ext.email.verio.net [129.250.36.42]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id JAA27663 for <[e-mail]>; Mon, 1 Nov 1999 09:33:18 -0800 (PST)
Received: from dfw-mmp4.email.verio.net ([129.250.38.64]) by dfw-smtpout2.email.verio.net (Netscape Messaging Server 4.05) with ESMTP id FKJ4RL00.8KQ for <[e-mail]>; Mon, 1 Nov 1999 17:33:21 +0000 
Received: from nma.com ([209.21.28.66]) by dfw-mmp4.email.verio.net (Netscape Messaging Server 4.05) with ESMTP id FKJ4QU00.AFA; Mon, 1 Nov 1999 17:32:54 +0000 
Message-ID: <[e-mail]>
Date: Mon, 01 Nov 1999 09:32:29 -0800
From: Ed Gerck <[e-mail]>
X-Mailer: Mozilla 4.7 [en]C-CCK-MCD {Sony}  (Win98; I)
X-Accept-Language: en
MIME-Version: 1.0
To: Bob Jueneman <[e-mail]>
CC: Alfred Arsenault <[e-mail]>, Sean Turner <[e-mail]>, IETF-PXIX <[e-mail]>
Subject: Re: NR, redux, again.
References: <[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

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.



Received: from ns.celocom.se ([212.209.40.66]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id JAA27278 for <[e-mail]>; Mon, 1 Nov 1999 09:17:38 -0800 (PST)
Received: by ns.celocom.se; id SAA08621; Mon, 1 Nov 1999 18:42:03 +0100 (CET)
Received: from zap.celocom.se(10.10.10.1) by ns.celocom.se via smap (4.1) id xma008611; Mon, 1 Nov 99 18:41:56 +0100
Received: from celocom.com (kenny.celocom.se [10.10.10.129]) by zap.celocom.se (8.8.7/8.8.7) with ESMTP id SAA12934; Mon, 1 Nov 1999 18:04:20 +0100
Message-ID: <[e-mail]>
Date: Mon, 01 Nov 1999 18:16:50 +0100
From: Oscar Jacobsson <[e-mail]>
Organization: Celo Communications AB
X-Mailer: Mozilla 4.7 [en] (WinNT; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Bob Jueneman <[e-mail]>
CC: [e-mail]
Subject: Re: NR, redux, again.
References: <[e-mail]>
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms6C6041554D2FA7F5AEAB1D34"

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

MIIIaAYJKoZIhvcNAQcCoIIIWTCCCFUCAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC
BhQwggLTMIICPKADAgECAgMA1fMwDQYJKoZIhvcNAQEEBQAwgbkxCzAJBgNVBAYTAlpBMRUw
EwYDVQQIEwxXZXN0ZXJuIENhcGUxFDASBgNVBAcTC0R1cmJhbnZpbGxlMRowGAYDVQQKExFU
aGF3dGUgQ29uc3VsdGluZzEpMCcGA1UECxMgVGhhd3RlIFBGIFJTQSBJSyAxOTk4LjkuMTYg
MTc6NTUxNjA0BgNVBAMTLVRoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBSU0EgSXNzdWVyIDE5
OTguOS4xNjAeFw05OTA0MzAwOTI3NDRaFw0wMDA0MjkwOTI3NDRaME0xHzAdBgNVBAMTFlRo
YXd0ZSBGcmVlbWFpbCBNZW1iZXIxKjAoBgkqhkiG9w0BCQEWG29zY2FyLmphY29ic3NvbkBj
ZWxvY29tLmNvbTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAtxcLv9YFkhCOY3lduKOK
yqKJeHS+DXnCuq31SwxUXzV5vPCtj3RimmykqpdG9CaqoLhwILZzNYWgPrgDvulp6FKtG5Cu
gEB9OyB72Msh8cW/hPqEECFh6SClNEgulVHRUf2LSB+oN4no9hlvcYJSNYcjVAafhKvdsR19
zElRKbsCAwEAAaNUMFIwEQYJYIZIAYb4QgEBBAQDAgWgMA4GA1UdDwEB/wQEAwIFoDAMBgNV
HRMBAf8EAjAAMB8GA1UdIwQYMBaAFP4+YJxrjA+w2DPGysYeWLBxOLXgMA0GCSqGSIb3DQEB
BAUAA4GBAKIk/XQru7z/NrP1xoM5I4LnR6HiJ1XdJ9NDAleZbNbiZS2vupN3c+WjRqmkXqQ9
eUb2SAw0rqY+tLg+ZYw2uSkksaYouuoc8ZruHz/Vnow8oW2Myln2pCkxp4KCW6zOMacL0X8C
N/sIQj39PnrjoqBgUR+uT19xFKVV0TuoOWHaMIIDOTCCAqKgAwIBAgIBCjANBgkqhkiG9w0B
AQQFADCB0TELMAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJ
Q2FwZSBUb3duMRowGAYDVQQKExFUaGF3dGUgQ29uc3VsdGluZzEoMCYGA1UECxMfQ2VydGlm
aWNhdGlvbiBTZXJ2aWNlcyBEaXZpc2lvbjEkMCIGA1UEAxMbVGhhd3RlIFBlcnNvbmFsIEZy
ZWVtYWlsIENBMSswKQYJKoZIhvcNAQkBFhxwZXJzb25hbC1mcmVlbWFpbEB0aGF3dGUuY29t
MB4XDTk4MDkxNjE3NTUzNFoXDTAwMDkxNTE3NTUzNFowgbkxCzAJBgNVBAYTAlpBMRUwEwYD
VQQIEwxXZXN0ZXJuIENhcGUxFDASBgNVBAcTC0R1cmJhbnZpbGxlMRowGAYDVQQKExFUaGF3
dGUgQ29uc3VsdGluZzEpMCcGA1UECxMgVGhhd3RlIFBGIFJTQSBJSyAxOTk4LjkuMTYgMTc6
NTUxNjA0BgNVBAMTLVRoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBSU0EgSXNzdWVyIDE5OTgu
OS4xNjCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAxKXl1NTQXwgC7gchfSS/q2uOHusg
BwIVhGuP0JMkHxud7miyuSxP6ZNnFxAXHqH5Q0EjuTCqdpe78+f9gcC1MYv2plAmVPKVKOsZ
pB6XHrDiuJvBBJoy0DwJbE/kNU/wdr8AEwNPRQhg8/y00JABihLJnLp/UuoqkzU2PDzkNS8C
AwEAAaM3MDUwEgYDVR0TAQH/BAgwBgEB/wIBADAfBgNVHSMEGDAWgBRyScJzNMZV9At2coF+
d/SH58ayDjANBgkqhkiG9w0BAQQFAAOBgQAsx4IfAUM+B4/uaVypZIL4wJatkyvLm1DXQJqB
wrqmdp08lUDcVcHhVYJ5qwopptUM4VcoPo/5u9XfDZNYqlsti48z5N1YFTV2chUpvUL0WpIL
d1+dJ9uaLU4bggaO0o1Wu5Xe2wxlBd6VngLdUxe+vvxrwxoiehQrYb3Cn156WjGCAhwwggIY
AgEBMIHBMIG5MQswCQYDVQQGEwJaQTEVMBMGA1UECBMMV2VzdGVybiBDYXBlMRQwEgYDVQQH
EwtEdXJiYW52aWxsZTEaMBgGA1UEChMRVGhhd3RlIENvbnN1bHRpbmcxKTAnBgNVBAsTIFRo
YXd0ZSBQRiBSU0EgSUsgMTk5OC45LjE2IDE3OjU1MTYwNAYDVQQDEy1UaGF3dGUgUGVyc29u
YWwgRnJlZW1haWwgUlNBIElzc3VlciAxOTk4LjkuMTYCAwDV8zAJBgUrDgMCGgUAoIGxMBgG
CSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTk5MTEwMTE3MTY1MVow
IwYJKoZIhvcNAQkEMRYEFGCrzZ4TtUqZz8utbLpxrEYhH6l7MFIGCSqGSIb3DQEJDzFFMEMw
CgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgFAMA0G
CCqGSIb3DQMCAgEoMA0GCSqGSIb3DQEBAQUABIGAhZZZoI6Ny9sQYTS9814JsnGIuHUtHfKx
wUlbC3sgBSJXPZXlu6k5h5HBhTV/6n7vkrop+hrQXGNI8i2+YIw6uw4+fkgkP1zzztARtGN+
AGWc3dIYgUtacVhlO6KJI5YRwab/KHyy0hetr1ItRU9tJuE00qh9TvwXAme4hIzvn/0=
--------------ms6C6041554D2FA7F5AEAB1D34--



Received: from stingray.missi.ncsc.mil (stingray.missi.ncsc.mil [144.51.50.20]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id JAA27000 for <[e-mail]>; Mon, 1 Nov 1999 09:08:05 -0800 (PST)
Received: from stingray.missi.ncsc.mil (root@localhost) by stingray.missi.ncsc.mil with ESMTP id MAA08361 for <[e-mail]>; Mon, 1 Nov 1999 12:08:29 -0500 (EST)
Received: from missi.ncsc.mil (depot.missi.ncsc.mil [144.51.60.1]) by stingray.missi.ncsc.mil with ESMTP id MAA08350 for <[e-mail]>; Mon, 1 Nov 1999 12:08:28 -0500 (EST)
Received: from mimesweeper.missi.ncsc.mil (mimesweeper.missi.ncsc.mil [144.51.60.2]) by missi.ncsc.mil (8.8.8/8.8.8) with ESMTP id MAA20049 for <[e-mail]>; Mon, 1 Nov 1999 12:07:49 -0500 (EST)
Received: from avenger.missi.ncsc.mil (avenger53.missi.ncsc.mil) by mimesweeper.missi.ncsc.mil (Content Technologies SMTPRS 2.0.15) with ESMTP id <[e-mail]>; Mon, 01 Nov 1999 12:08:10 -0500
Received: by avenger54.missi.ncsc.mil with Internet Mail Service (5.5.2232.9) id <TZ046MBQ>; Mon, 1 Nov 1999 12:08:23 -0500
Message-Id: <[e-mail]>
From: "Miklos, Sue A." <[e-mail]>
To: "'Sean Turner'" <[e-mail]>, PKIX <[e-mail]>
Subject: RE: Comments on draft-ietf-pkix-ldap-v3-01.txt
Date: Mon, 1 Nov 1999 12:08:22 -0500 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2232.9)
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01BF248B.B46D0662"

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


Received: from prv-mail20.provo.novell.com (prv-mail20.provo.novell.com [137.65.82.195]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id IAA26650 for <[e-mail]>; Mon, 1 Nov 1999 08:57:54 -0800 (PST)
Received: from INET-PRV-Message_Server by prv-mail20.provo.novell.com with Novell_GroupWise; Mon, 01 Nov 1999 09:57:23 -0700
Message-Id: <[e-mail]>
X-Mailer: Novell GroupWise Internet Agent 5.5.2.1
Date: Mon, 01 Nov 1999 09:57:12 -0700
From: "Bob Jueneman" <[e-mail]>
To: <[e-mail]>
Cc: <[e-mail]>
Subject: Re: NR, redux, again.
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by ns.secondary.com id IAA26651

>>> Oscar Jacobsson <[e-mail]> 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



Received: from ns.celocom.se ([212.209.40.66]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id IAA26310 for <[e-mail]>; Mon, 1 Nov 1999 08:47:38 -0800 (PST)
Received: by ns.celocom.se; id SAA06346; Mon, 1 Nov 1999 18:12:02 +0100 (CET)
Received: from zap.celocom.se(10.10.10.1) by ns.celocom.se via smap (4.1) id xma006190; Mon, 1 Nov 99 18:11:02 +0100
Received: from celocom.com (kenny.celocom.se [10.10.10.129]) by zap.celocom.se (8.8.7/8.8.7) with ESMTP id RAA31965; Mon, 1 Nov 1999 17:33:25 +0100
Message-ID: <[e-mail]>
Date: Mon, 01 Nov 1999 17:46:00 +0100
From: Oscar Jacobsson <[e-mail]>
Organization: Celo Communications AB
X-Mailer: Mozilla 4.7 [en] (WinNT; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Bob Jueneman <[e-mail]>
CC: [e-mail]
Subject: Re: NR, redux, again.
References: <[e-mail]>
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms64B73D047A0E9FB74982D396"

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

MIIIaAYJKoZIhvcNAQcCoIIIWTCCCFUCAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC
BhQwggLTMIICPKADAgECAgMA1fMwDQYJKoZIhvcNAQEEBQAwgbkxCzAJBgNVBAYTAlpBMRUw
EwYDVQQIEwxXZXN0ZXJuIENhcGUxFDASBgNVBAcTC0R1cmJhbnZpbGxlMRowGAYDVQQKExFU
aGF3dGUgQ29uc3VsdGluZzEpMCcGA1UECxMgVGhhd3RlIFBGIFJTQSBJSyAxOTk4LjkuMTYg
MTc6NTUxNjA0BgNVBAMTLVRoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBSU0EgSXNzdWVyIDE5
OTguOS4xNjAeFw05OTA0MzAwOTI3NDRaFw0wMDA0MjkwOTI3NDRaME0xHzAdBgNVBAMTFlRo
YXd0ZSBGcmVlbWFpbCBNZW1iZXIxKjAoBgkqhkiG9w0BCQEWG29zY2FyLmphY29ic3NvbkBj
ZWxvY29tLmNvbTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAtxcLv9YFkhCOY3lduKOK
yqKJeHS+DXnCuq31SwxUXzV5vPCtj3RimmykqpdG9CaqoLhwILZzNYWgPrgDvulp6FKtG5Cu
gEB9OyB72Msh8cW/hPqEECFh6SClNEgulVHRUf2LSB+oN4no9hlvcYJSNYcjVAafhKvdsR19
zElRKbsCAwEAAaNUMFIwEQYJYIZIAYb4QgEBBAQDAgWgMA4GA1UdDwEB/wQEAwIFoDAMBgNV
HRMBAf8EAjAAMB8GA1UdIwQYMBaAFP4+YJxrjA+w2DPGysYeWLBxOLXgMA0GCSqGSIb3DQEB
BAUAA4GBAKIk/XQru7z/NrP1xoM5I4LnR6HiJ1XdJ9NDAleZbNbiZS2vupN3c+WjRqmkXqQ9
eUb2SAw0rqY+tLg+ZYw2uSkksaYouuoc8ZruHz/Vnow8oW2Myln2pCkxp4KCW6zOMacL0X8C
N/sIQj39PnrjoqBgUR+uT19xFKVV0TuoOWHaMIIDOTCCAqKgAwIBAgIBCjANBgkqhkiG9w0B
AQQFADCB0TELMAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJ
Q2FwZSBUb3duMRowGAYDVQQKExFUaGF3dGUgQ29uc3VsdGluZzEoMCYGA1UECxMfQ2VydGlm
aWNhdGlvbiBTZXJ2aWNlcyBEaXZpc2lvbjEkMCIGA1UEAxMbVGhhd3RlIFBlcnNvbmFsIEZy
ZWVtYWlsIENBMSswKQYJKoZIhvcNAQkBFhxwZXJzb25hbC1mcmVlbWFpbEB0aGF3dGUuY29t
MB4XDTk4MDkxNjE3NTUzNFoXDTAwMDkxNTE3NTUzNFowgbkxCzAJBgNVBAYTAlpBMRUwEwYD
VQQIEwxXZXN0ZXJuIENhcGUxFDASBgNVBAcTC0R1cmJhbnZpbGxlMRowGAYDVQQKExFUaGF3
dGUgQ29uc3VsdGluZzEpMCcGA1UECxMgVGhhd3RlIFBGIFJTQSBJSyAxOTk4LjkuMTYgMTc6
NTUxNjA0BgNVBAMTLVRoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBSU0EgSXNzdWVyIDE5OTgu
OS4xNjCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAxKXl1NTQXwgC7gchfSS/q2uOHusg
BwIVhGuP0JMkHxud7miyuSxP6ZNnFxAXHqH5Q0EjuTCqdpe78+f9gcC1MYv2plAmVPKVKOsZ
pB6XHrDiuJvBBJoy0DwJbE/kNU/wdr8AEwNPRQhg8/y00JABihLJnLp/UuoqkzU2PDzkNS8C
AwEAAaM3MDUwEgYDVR0TAQH/BAgwBgEB/wIBADAfBgNVHSMEGDAWgBRyScJzNMZV9At2coF+
d/SH58ayDjANBgkqhkiG9w0BAQQFAAOBgQAsx4IfAUM+B4/uaVypZIL4wJatkyvLm1DXQJqB
wrqmdp08lUDcVcHhVYJ5qwopptUM4VcoPo/5u9XfDZNYqlsti48z5N1YFTV2chUpvUL0WpIL
d1+dJ9uaLU4bggaO0o1Wu5Xe2wxlBd6VngLdUxe+vvxrwxoiehQrYb3Cn156WjGCAhwwggIY
AgEBMIHBMIG5MQswCQYDVQQGEwJaQTEVMBMGA1UECBMMV2VzdGVybiBDYXBlMRQwEgYDVQQH
EwtEdXJiYW52aWxsZTEaMBgGA1UEChMRVGhhd3RlIENvbnN1bHRpbmcxKTAnBgNVBAsTIFRo
YXd0ZSBQRiBSU0EgSUsgMTk5OC45LjE2IDE3OjU1MTYwNAYDVQQDEy1UaGF3dGUgUGVyc29u
YWwgRnJlZW1haWwgUlNBIElzc3VlciAxOTk4LjkuMTYCAwDV8zAJBgUrDgMCGgUAoIGxMBgG
CSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTk5MTEwMTE2NDYwMlow
IwYJKoZIhvcNAQkEMRYEFCE4zcVJxyZpQHA8LCHFvlSN5xByMFIGCSqGSIb3DQEJDzFFMEMw
CgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgFAMA0G
CCqGSIb3DQMCAgEoMA0GCSqGSIb3DQEBAQUABIGArNGtffK+C3wboMM1J2Os93FmqteH3de1
DxtF6ZQEQEM4AgOWAHHxHBqIaOkF8dyiKQD74QJvxjF0FFXSJ6AxKrriSAf9KrGQBKe31Vc2
ftRDN6yoyF3Ht37P9yYDy1pV8fPfcsK5DsJpVzHQrpjXx1ExuosZc62KZn3VjqeqLxY=
--------------ms64B73D047A0E9FB74982D396--



Received: from prv-mail20.provo.novell.com (prv-mail20.provo.novell.com [137.65.82.195]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id IAA25836 for <[e-mail]>; Mon, 1 Nov 1999 08:25:49 -0800 (PST)
Received: from INET-PRV-Message_Server by prv-mail20.provo.novell.com with Novell_GroupWise; Mon, 01 Nov 1999 09:25:13 -0700
Message-Id: <[e-mail]>
X-Mailer: Novell GroupWise Internet Agent 5.5.2.1
Date: Mon, 01 Nov 1999 09:25:10 -0700
From: "Bob Jueneman" <[e-mail]>
To: <[e-mail]>, <[e-mail]>
Cc: <[e-mail]>, <[e-mail]>
Subject: NR, redux, again.
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by ns.secondary.com id IAA25837

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 <[e-mail]> 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





Received: from caesar.udac.se (caesar.udac.se [193.44.79.10]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id CAA17701 for <[e-mail]>; Mon, 1 Nov 1999 02:29:03 -0800 (PST)
Received: from HYDRA ([195.198.186.77]) by caesar.udac.se (8.7.3/NetworkC-1) with SMTP id LAA39722; Mon, 1 Nov 1999 11:25:48 +0100
Received: by HYDRA with Microsoft Mail id <01BF245B.8C005880@HYDRA>; Mon, 1 Nov 1999 11:23:39 +0100
Message-ID: <01BF245B.8C005880@HYDRA>
From: Anders Rundgren <[e-mail]>
To: "[e-mail]" <[e-mail]>, "'Stefan Santesson'" <[e-mail]>, "'SEIS-List'" <[e-mail]>
Cc: "Magnus (RSA)" <[e-mail]>
Subject: RE: QC comparisons are DEADLY serious!
Date: Mon, 1 Nov 1999 11:23:38 +0100
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit

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




Received: from mail0.sse.ie (mail0.sse.ie [193.120.32.47]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id BAA17114 for <[e-mail]>; Mon, 1 Nov 1999 01:59:43 -0800 (PST)
Received: from mail0.sse.ie (actually localhost) by mail0.sse.ie; Mon, 1 Nov 1999 10:01:52 +0000
Received: from bowsy (bowsy.sse.ie [193.120.32.196]) by mail0.sse.ie (8.9.1a/8.9.1) with SMTP id KAA01570; Mon, 1 Nov 1999 10:01:49 GMT
Message-ID: <03e501bf244f$c8728d30$[e-mail]>
From: "Andy Dowling" <[e-mail]>
To: "Stephen Farrell (Baltimore)" <[e-mail]>
Cc: <[e-mail]>, <[e-mail]>
Subject: AC Pull with multiple profiles
Date: Mon, 1 Nov 1999 09:59:25 -0000
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.00.2314.1300
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300
Content-Transfer-Encoding: 7bit

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:  [e-mail]
Web: http://www.sse.ie
Phone: [phone]
Fax:   [phone]



Received: from popmail.inbox.se (popmail.inbox.se [193.12.72.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id AAA16267 for <[e-mail]>; Mon, 1 Nov 1999 00:37:49 -0800 (PST)
Received: from stefan2 (accurata.inbox.se [193.12.72.24]) by popmail.inbox.se (8.9.3/8.9.3) with SMTP id JAA01160; Mon, 1 Nov 1999 09:37:44 +0100
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 
Date: Mon, 01 Nov 1999 09:38:12 +0100
To: "Anders Rundgren" <[e-mail]>, <[e-mail]>
From: Stefan Santesson <[e-mail]>
Subject: Re: QC comparisons are DEADLY serious!
Cc: "Magnus (RSA)" <[e-mail]>
In-Reply-To: <002001bf22e1$db5ffc30$[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by ns.secondary.com id AAA16268

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 <[e-mail]>
>To: Anders Rundgren <[e-mail]>; 'SEIS-List' 
><[e-mail]>; [e-mail] <[e-mail]>
>Date: Friday, October 29, 1999 23:09
>Subject: SEIS: Re: QC certificates MAY CERTAINLY be compared!
>
>
>>--- Message on the SEIS mailing list ([e-mail])
>>
>>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 <[e-mail]>
>>>To: [e-mail] <[e-mail]>
>>>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                <[e-mail]>
>>>>Accurata AB                     http://www.accurata.se
>>>>Slagthuset                      Tel. [phone]              
>>>>211 20  Malmö                   Fax. [phone]              
>>>>Sweden                        Mobile [phone]
>>>>
>>>>PGP fingerprint: 89BC 6C79 5B3D 591B 8547  1512 7D11 DBF4 528F 29A0
>>>>-------------------------------------------------------------------
>>>> 
>>
>>
>>----------------- SEIS mailing list ([e-mail])
>>Info about this list: http://www.nc-forum.com/seis
>>SEIS Contact: [e-mail]
>>
>>

-------------------------------------------------------------------
Stefan Santesson                <[e-mail]>
Accurata AB                     http://www.accurata.se
Slagthuset                      Tel. [phone]              
211 20  Malmö                   Fax. [phone]              
Sweden                        Mobile [phone]

PGP fingerprint: 89BC 6C79 5B3D 591B 8547  1512 7D11 DBF4 528F 29A0
-------------------------------------------------------------------