Re: Multi-national company listing issues

[Stephen Kent <[e-mail]>]

Tony,

Ideally it would be the case that a party constructing a name under the
C=US arc would be registered, but this is the exception rather than the
rule.

steve



Received: from po1.bbn.com (PO1.BBN.COM [192.1.50.38]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id TAA18938 for <[e-mail]>; Tue, 31 Aug 1999 19:11:33 -0700 (PDT)
Received: from [128.33.238.47] (TC047.BBN.COM [128.33.238.47]) by po1.bbn.com (8.9.1/8.9.1) with ESMTP id WAA15695; Tue, 31 Aug 1999 22:13:36 -0400 (EDT)
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Message-Id: <v04020a15b3f1edd11300@[128.89.0.111]>
In-Reply-To: <[e-mail]>
References: <[e-mail]>
Date: Tue, 31 Aug 1999 22:14:25 -0400
To: Tony Bartoletti <[e-mail]>
From: Stephen Kent <[e-mail]>
Subject: Re: Multi-national company listing issues
Cc: <[e-mail]>

Tony,

Ideally it would be the case that a party constructing a name under the
C=US arc would be registered, but this is the exception rather than the
rule.

steve


Received: from center.kisa.or.kr (ns.kisa.or.kr [203.233.150.11]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id SAA13033 for <[e-mail]>; Tue, 31 Aug 1999 18:07:37 -0700 (PDT)
Received: from kisa.or.kr ([203.233.151.93]) by center.kisa.or.kr (8.8.8H1/8.8.8) with ESMTP id KAA10108 for <[e-mail]>; Wed, 1 Sep 1999 10:04:54 +0900 (KST)
Message-ID: <[e-mail]>
Date: Wed, 01 Sep 1999 10:10:44 +0900
From: =?iso-8859-1?Q?=BF=C0=B0=E6=C8=F1?= <[e-mail]>
X-Mailer: Mozilla 4.5 [en] (Win98; I)
X-Accept-Language: en
MIME-Version: 1.0
To: [e-mail]
Subject: Re: New Microsoft cert extension?
References: <[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 8bit

PRIVATE ENTERPRISE NUMBERS
 SMI Network Management Private Enterprise Codes:
Prefix: iso.org.dod.internet.private.enterprise (1.3.6.1.4.1)

This file is
          ftp://ftp.isi.edu/in-notes/iana/assignments/enterprise-numbers

Decimal   Name                                                References
-------   ----                                                ----------
  311   Microsoft             John M. Ballard   [e-mail]


Try to mail to the address above.

If you get the answer, please let me know.



Marc Branchaud wrote:

> Found an extension with this OID in a Win2K cert: 1.3.6.1.4.1.311.21.1.
> Here's what it looks like from Peter Gutmann's dumpasn1:
>
>  576 30   16:         SEQUENCE {
>  578 06    9:           OBJECT IDENTIFIER '1 3 6 1 4 1 311 21 1'
>  589 04    3:           OCTET STRING, encapsulates {
>  591 02    1:               INTEGER 0
>             :               }
>             :           }
>
> I believe that 1.3.6.1.4.1.311 belongs to Microsoft, but does anyone
> know what this extension is?
>
>                 Marc



Received: from ext-mail.valicert.com (ns1.valicert.com [63.65.221.10]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id SAA12375 for <[e-mail]>; Tue, 31 Aug 1999 18:01:52 -0700 (PDT)
Received: from int-mail.valicert.com (corporate-gw.valicert.com [63.65.221.2]) by ext-mail.valicert.com (8.9.3/8.9.3) with ESMTP id SAA20504; Tue, 31 Aug 1999 18:04:02 -0700 (PDT)
Received: from rsalaptop ([192.168.3.230]) by int-mail.valicert.com (8.9.3/8.9.3) with SMTP id SAA27016; Tue, 31 Aug 1999 18:04:02 -0700 (PDT)
From: "Peter Williams" <[e-mail]>
To: "Russ Housley" <[e-mail]>, <[e-mail]>
Subject: RE: End-Entity Certificate Policies
Date: Tue, 31 Aug 1999 18:05:19 -0700
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="----=_NextPart_000_0026_01BEF3DB.62E03200"
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]>
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300
Importance: Normal

This is a multi-part message in MIME format.

------=_NextPart_000_0026_01BEF3DB.62E03200
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit

 I vote no on both propositions, I suggest
alternative bug fixes be found.

Breaking today's infrastructure to fix
a problem in a theoretical part of X.509 which
has never been deployed to Internet
users is just not fair on the CA
community, their now millions
of users, and hundred thousand odd
commercial customers.




> -----Original Message-----
> From: Russ Housley [mailto:[e-mail]]
> Sent: Tuesday, August 31, 1999 1:57 PM
> To: [e-mail]
> Subject: End-Entity Certificate Policies
>
>
> Tim Polk and I got together today to discuss the changes needed
> to address
> the policy mapping bug (as discussed at the Oslo meeting).  As
> part of this
> discussion, we discussed the certificate policy extension.
>
> We believe that a CA certificate may contain one or more
> certificate policy
> OID.  On the other hand, we believe that an end-entity certificate
> containing a certificate policy extension must  contain a single
> certificate policy OID.  RFC 2459 says:
>
>     The certificate policies extension contains a sequence of one or more
>     policy information terms, each of which consists of an object
>     identifier (OID) and optional qualifiers.  These policy information
>     terms indicate the policy under which the certificate has been issued
>     and the purposes for which the certificate may be used.  Optional
>     qualifiers, which may be present, are not expected to change the
>     definition of the policy.
>
> We would like to add words to make it more clear that an end-entity
> certificate may only contain a single certificate policy OID.  The
> explanation of this extension's purpose in a CA certificate was
> not spelled
> out, so we propose to fix that too.  Our proposed text is:
>
>     The certificate policies extension contains a sequence of one or more
>     policy information terms, each of which consists of an object
>     identifier (OID) and optional qualifiers.  In an end-entity
> certificate,
>     these policy information terms indicate the single policy under which
>     the certificate has been issued and the purposes for which
> the certificate
>     may be used.  In a CA certificate,  these policy information terms
>     limit the set of policies for certification paths which include this
>     certificate.  Optional qualifiers, which may be present, are not
>     expected to change the definition of the policy.
>
> Does anyone disagree?
>
> Tim and I also discussed certificate policy qualifiers.  Tim and I agree
> that certificate policy qualifiers should only appear in end-entity
> certificates.  That is, we agree that certificate policy qualifier should
> never appear in a CA certificate.  Does anyone (besides Mike
> Baum) disagree?
>
> Russ
>

------=_NextPart_000_0026_01BEF3DB.62E03200
Content-Type: application/pkix-cert;
	name="verisign.cer"
Content-Transfer-Encoding: base64
Content-Disposition: attachment;
	filename="verisign.cer"

MIIDLjCCApegAwIBAgIRANJ2Lo0UDD19sqglXa/uDXUwDQYJKoZIhvcNAQECBQAwXzELMAkGA1UE
BhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMTcwNQYDVQQLEy5DbGFzcyAxIFB1YmxpYyBQ
cmltYXJ5IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTk4MDUxMjAwMDAwMFoXDTA4MDUxMjIz
NTk1OVowgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVz
dCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29y
cC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIElu
ZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQwgZ8wDQYJKoZIhvcNAQEB
BQADgY0AMIGJAoGBALtaRIoEFrtV/QN6ii2UTxV4NrgNSrJvnFS/vOh3Kp258Gi7ldkxQXB6gUu5
SBNWLccI4YRCq8CikqtEXKpC8IIOAukv+8I7u77JJwpdtrA2QjO1blSIT4dKvxna+RXoD4e2HOPM
xpqOf2okkuP84GW6p7F+78nbN2rISsgJBuSZAgMBAAGjfDB6MBEGCWCGSAGG+EIBAQQEAwIBBjBH
BgNVHSAEQDA+MDwGC2CGSAGG+EUBBwEBMC0wKwYIKwYBBQUHAgEWH3d3dy52ZXJpc2lnbi5jb20v
cmVwb3NpdG9yeS9SUEEwDwYDVR0TBAgwBgEB/wIBADALBgNVHQ8EBAMCAQYwDQYJKoZIhvcNAQEC
BQADgYEAiLg3O93alDcAraqf4YEBcR6Sam0v9vGd08pkONwbmAwHhluFFWoPuUmFpJXxF31ntH8t
LN2aQp7DPrSOquULBt7yVir6M8e+GddTTMO9yOMXtaRJQmPswqYXD11YGkk8kFxVo2UgAP0YIOVf
gqaxqJLFWGrBjQM868PNBaKQrm4=

------=_NextPart_000_0026_01BEF3DB.62E03200--



Received: from caladan.verisign.com (caladan.verisign.com [205.180.232.21]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id RAA11720 for <[e-mail]>; Tue, 31 Aug 1999 17:49:53 -0700 (PDT)
Received: from mentat.verisign.com by caladan.verisign.com (8.8.5/BCH1.5) id RAA08135; Tue, 31 Aug 1999 17:50:01 -0700 (PDT)
Received: from newman.verisign.com by mentat.verisign.com (8.8.5/BCH1.0) id RAA16771; Tue, 31 Aug 1999 17:51:31 -0700 (PDT)
Received: by newman.verisign.com with Internet Mail Service (5.5.2448.0) id <RKAYDVSS>; Tue, 31 Aug 1999 17:51:32 -0700
Message-ID: <[e-mail]>
From: Michael Myers <[e-mail]>
To: "'Russ Housley'" <[e-mail]>, [e-mail]
Subject: RE: End-Entity Certificate Policies
Date: Tue, 31 Aug 1999 17:51:22 -0700
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2448.0)
Content-Type: text/plain; charset="iso-8859-1"

Russ,

I agree with your proposal for a single policy OID in an end-entity
certificate.  This is the only way I've seen it used.  Might I suggest
however a refinement of the proposed text.

An organization could operate under a single policy in accordance ". . .
these policy information terms indicate the single policy under which . . ."
but represent this single policy as ". . . a sequence of one or more . . .
terms" (that is, more than one OID) and yet defensibly conform to the
standard.

Text along the lines "SHALL include a single policy OID" would sharpen the
requirement and so prevent this interpretation.

I must disagree though regarding the exclusion of certificate policy
qualifiers in CA certs.  Consider the CPS pointer.  A CA cert and entity
cert whose signature validates using that CA cert may need to point to
different CPSs.  This situation may occur in cross certification / hub
certification / bridge certification contexts (choose a favorite term).

Mike



> -----Original Message-----
> From: Russ Housley [mailto:[e-mail]]
> Sent: Tuesday, August 31, 1999 1:57 PM
> To: [e-mail]
> Subject: End-Entity Certificate Policies
> 
> 
> Tim Polk and I got together today to discuss the changes 
> needed to address 
> the policy mapping bug (as discussed at the Oslo meeting).  
> As part of this 
> discussion, we discussed the certificate policy extension.
> 
> We believe that a CA certificate may contain one or more 
> certificate policy 
> OID.  On the other hand, we believe that an end-entity certificate 
> containing a certificate policy extension must  contain a single 
> certificate policy OID.  RFC 2459 says:
> 
>     The certificate policies extension contains a sequence of 
> one or more
>     policy information terms, each of which consists of an object
>     identifier (OID) and optional qualifiers.  These policy 
> information
>     terms indicate the policy under which the certificate has 
> been issued
>     and the purposes for which the certificate may be used.  Optional
>     qualifiers, which may be present, are not expected to change the
>     definition of the policy.
> 
> We would like to add words to make it more clear that an end-entity 
> certificate may only contain a single certificate policy OID.  The 
> explanation of this extension's purpose in a CA certificate 
> was not spelled 
> out, so we propose to fix that too.  Our proposed text is:
> 
>     The certificate policies extension contains a sequence of 
> one or more
>     policy information terms, each of which consists of an object
>     identifier (OID) and optional qualifiers.  In an 
> end-entity certificate,
>     these policy information terms indicate the single policy 
> under which
>     the certificate has been issued and the purposes for 
> which the certificate
>     may be used.  In a CA certificate,  these policy information terms
>     limit the set of policies for certification paths which 
> include this
>     certificate.  Optional qualifiers, which may be present, are not
>     expected to change the definition of the policy.
> 
> Does anyone disagree?
> 
> Tim and I also discussed certificate policy qualifiers.  Tim 
> and I agree 
> that certificate policy qualifiers should only appear in end-entity 
> certificates.  That is, we agree that certificate policy 
> qualifier should 
> never appear in a CA certificate.  Does anyone (besides Mike 
> Baum) disagree?
> 
> Russ
> 


Received: from public.uni-hamburg.de (public.rrz.uni-hamburg.de [134.100.32.55]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id PAA10063 for <[e-mail]>; Tue, 31 Aug 1999 15:40:05 -0700 (PDT)
Received: from max2-039.public.uni-hamburg.de (max2-039.public.uni-hamburg.de [134.100.45.39]) by public.uni-hamburg.de (8.8.8/8.8.8) with SMTP id AAA33640; Wed, 1 Sep 1999 00:42:00 +0200
Received: id <m11Lwiz-000QfrC@epsilon>; Wed, 1 Sep 1999 00:49:57 +0200 (CEST) 
Message-Id: <m11Lwiz-000QfrC@epsilon>
Date: Wed, 1 Sep 1999 00:49:57 +0200 (CEST)
From: [e-mail] (Bodo Moeller)
To: [e-mail]
Cc: "Bob Blakley" <[e-mail]>, (To:) "Tony Bartoletti" <[e-mail]>
Subject: Re: What non-repudiation is not and the PA bit, was Re: To Be,or NR To Be ...
In-Reply-To: <048801bee9c7$30307b80$[e-mail]>
References: <048801bee9c7$30307b80$[e-mail]>

Bob Blakley <[e-mail]>:
> Tony Bartoletti <[e-mail]>:
>> Bob Blakley <[e-mail]>:

>>> [...] SET has a mode in which my name & credit card number
>>> are not divulged to the merchant -- all the merchant gets is a NR token
>>> demonstrating to the cardholder's bank (the issuer) that it should pay
>>> the merchant's bank (the acquirer) the sum listed in the token from the
>>> account (which the issuer is able to extract from the token).

>>> In this scenario, when the merchant receives the token, not only is
>>> there no *proof* of authentication, there's no authentication, and in
>>> fact there's not even any identification.  Yet there IS non-repudiation
>>> evidence, and the merchant *can* use this evidence.

>> When you say there is no authentication/(or even identification), I believe
>> you must be using these terms in the limited sense "this was demonstrably
>> signed by Tony."  I tend to apply the terms authentication and identity
>> a bit more broadly, even in the PKI context.

> [...] the merchant doesn't get my identity, or have it proven to
> him.  So no authentication has taken place, and nothing is proven
> (neither authentication nor anything else) to the merchant.  [...]

This is again "authentication" in the limited sense that implies
identification, which seems to be the only disagreement here (in the
parts that I quoted).  But the merchant certainly knows in some sense
that the signature is "authentic", which is the point in providing a
signature in the first place: Even if they cannot determine the
signer's identity as it would appear in typical naming schemes
(e.g. name and address), they know that it's a genuine signature from
someone.  Thus, using the term "authentication" seems appropriate.
(If one wanted to be etymologically correct, however, one could not
even speak of a "signature" here because signatures are really about
identity.)

The word "proof" in "proof of authentication" refers not to the
relying party's being able to convince *themself* of the authenticity,
but to their ability to deliver such proof *to others* (i.e. this is
about what is, if just cryptographical aspects are considered, the
essential difference between digital signatures and symmetric
authentication -- the relying party can fake symmetric authenticators,
but not digital signatures).


Received: from public.uni-hamburg.de (public.rrz.uni-hamburg.de [134.100.32.55]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id PAA09606 for <[e-mail]>; Tue, 31 Aug 1999 15:08:37 -0700 (PDT)
Received: from max2-039.public.uni-hamburg.de (max2-039.public.uni-hamburg.de [134.100.45.39]) by public.uni-hamburg.de (8.8.8/8.8.8) with SMTP id AAA15672; Wed, 1 Sep 1999 00:10:19 +0200
Received: id <m11Lvqh-000QdzC@epsilon>; Tue, 31 Aug 1999 23:53:51 +0200 (CEST) 
Message-Id: <m11Lvqh-000QdzC@epsilon>
Date: Tue, 31 Aug 1999 23:53:51 +0200 (CEST)
From: [e-mail] (Bodo Moeller)
To: [e-mail]
Cc: "Bob Blakley" <[e-mail]>, "Bob Jueneman" <[e-mail]>
Subject: Re: NR -- what the real issues are, and  a proposal
In-Reply-To: <037701bee9be$b751c500$[e-mail]>
References: <037701bee9be$b751c500$[e-mail]>

Bob Blakley <[e-mail]>:

>> [...]

> I think this is a good choice of semantics for the key usage bit,
> but I have some questions about how it's implemented.  [...]
> You clearly don't want a CA to be creating certs. with this bit set
> and handing them out to people without prior authorization, [...]
> I think people are going to want to have a record that they
> authorized the creation of such a liability-bearing instrument [...]

If you want to be able to convince entities other than the CA itself
that some signature made with a certified key is non-reputable (in
whatever sense) for the certificate subject, then you *must* require
the CA's keeping records of certificate applications.  If the CA
cannot provide record that indeed Bob requested a certificate for what
ostensibly is Bob's signing key, then -- assuming that we can take for
granted that neither the CA nor Bob fell victim to some attack --
others (the relying party; the judge who may have to resolve a
dispute) cannot tell if it's Bob or the CA who is trying to cheat.
In other words, then everything boils down to whether the CA is
considered trustworthy.

Of course this applies to NR bits just as well as to subject DNs --

> Perhaps we'd have to look at a two-stage process, whereby a
> non-binding cert would be generated and distributed, and then a
> request for a binding cert would be generated and signed using the
> non-binding cert...

If your are worried about a CA setting the NR bit in your certificate
against your will, then exactly the same fears should be evoked by the
scenario where the CA first creates a non-NR cert that merely has your
name in it while the key is held by someone else, and then in stage
two creates a NR cert according to the second request.  The two-stage
procedure is just overhead.

Bodo M"oller
<[e-mail]>


Received: from mail.spyrus.com (mail.spyrus.com [207.212.34.20]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id NAA08395 for <[e-mail]>; Tue, 31 Aug 1999 13:58:31 -0700 (PDT)
Received: from rhousley_laptop.spyrus.com ([209.172.119.101]) by mail.spyrus.com (8.9.3/8.9.3) with ESMTP id NAA08633 for <[e-mail]>; Tue, 31 Aug 1999 13:54:24 -0700 (PDT)
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58 
Date: Tue, 31 Aug 1999 16:56:31 -0400
To: [e-mail]
From: Russ Housley <[e-mail]>
Subject: End-Entity Certificate Policies
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed

Tim Polk and I got together today to discuss the changes needed to address 
the policy mapping bug (as discussed at the Oslo meeting).  As part of this 
discussion, we discussed the certificate policy extension.

We believe that a CA certificate may contain one or more certificate policy 
OID.  On the other hand, we believe that an end-entity certificate 
containing a certificate policy extension must  contain a single 
certificate policy OID.  RFC 2459 says:

    The certificate policies extension contains a sequence of one or more
    policy information terms, each of which consists of an object
    identifier (OID) and optional qualifiers.  These policy information
    terms indicate the policy under which the certificate has been issued
    and the purposes for which the certificate may be used.  Optional
    qualifiers, which may be present, are not expected to change the
    definition of the policy.

We would like to add words to make it more clear that an end-entity 
certificate may only contain a single certificate policy OID.  The 
explanation of this extension's purpose in a CA certificate was not spelled 
out, so we propose to fix that too.  Our proposed text is:

    The certificate policies extension contains a sequence of one or more
    policy information terms, each of which consists of an object
    identifier (OID) and optional qualifiers.  In an end-entity certificate,
    these policy information terms indicate the single policy under which
    the certificate has been issued and the purposes for which the certificate
    may be used.  In a CA certificate,  these policy information terms
    limit the set of policies for certification paths which include this
    certificate.  Optional qualifiers, which may be present, are not
    expected to change the definition of the policy.

Does anyone disagree?

Tim and I also discussed certificate policy qualifiers.  Tim and I agree 
that certificate policy qualifiers should only appear in end-entity 
certificates.  That is, we agree that certificate policy qualifier should 
never appear in a CA certificate.  Does anyone (besides Mike Baum) disagree?

Russ



Received: from e3.ny.us.ibm.com (e3.ny.us.ibm.com [32.97.182.103]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id NAA08070 for <[e-mail]>; Tue, 31 Aug 1999 13:45:19 -0700 (PDT)
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 QAA280494; Tue, 31 Aug 1999 16:47:02 -0400
Received: from D51MTA05.pok.ibm.com (d51mta05.pok.ibm.com [9.117.200.33]) by northrelay02.pok.ibm.com (8.8.8m2/NCO v2.04) with SMTP id QAA173318; Tue, 31 Aug 1999 16:47:26 -0400
Received: by D51MTA05.pok.ibm.com(Lotus SMTP MTA v4.6.4  (830.2 3-23-1999))  id 852567DE.0072309B ; Tue, 31 Aug 1999 16:47:15 -0400
X-Lotus-FromDomain: IBMUS
To: "Aram Perez" <[e-mail]>
cc: [e-mail]
Message-ID: <[e-mail]>
Date: Tue, 31 Aug 1999 16:46:07 -0400
Subject: Re: New Internet Draft on Non-Repudiation Requirements
Mime-Version: 1.0
Content-type: text/plain; charset=us-ascii
Content-Disposition: inline

"Aram Perez" <[e-mail]> on 08/31/99 04:09:21 PM

To:   [e-mail]
cc:
Subject:  Re: New Internet Draft on Non-Repudiation Requirements





Tom Gindin wrote:

I haven't reviewed your document yet, but I have one question/comment
below...

>      I think that we should remember that the NR bit is supposed to cause CRL
> archiving  as well.  In any case, while I haven't seen the official
announcement
> yet, my new "Technical NR Requirements" draft is available at
> http://www.ietf.org/internet-drafts/draft-gindin-pkix-technr-00.txt or in the
> "internet-drafts" directory on the usual shadow sites as
> draft-gindin-pkix-technr-00.txt
>
>      Subsequent review of this draft has suggested a new addition to the set
of
> requirements for "1-way" NR, as follows:
>
> 3.4  The relying party should create, and save with the data submitted, a
> package containing a current time stamp signed by an independent authority.
> This object signed by the independent authority should include, in addition to
> the time stamp, one of the following: a countersignature created by the
> relying party,

Does the certificate for this countersignature have the NR bit set? If yes,
do you need another countersignature with NR, etc, etc.? If no, is the
countersignature repudiable?

[Tom Gindin]   Yes, the certificate for the relying party's countersignature
should have the NR bit set.  However, this does not mean that you need yet
another countersignature.  Just because a signature is created using an
NR-capable certificate doesn't mean that it invokes this full service in all
cases, or else someone (and I don't know who it would be) would have to check
the relying party's CRL, for example.


Regards,
Aram Perez


> a copy of the "signature block" of the submitted document,
> or the entire submitted document.
>
>
>           Tom Gindin
>
>
> Stephen Kent <[e-mail]> on 08/31/99 10:20:13 AM
>
> To:   "Aram Perez" <[e-mail]>
> cc:   [e-mail]
> Subject:  Re: Deprecate the NR bit?
>
>
>
>
>
> At 8:53 AM -0700 8/30/99, Aram Perez wrote:
>
>>Ron Ramsay wrote:
>>
>>> Except that the NR bit cannot be added to the certificate by the
>>> application!
>>
>>But the application can add a much better indicator to the data that needs
>>to be part of the evidence that supports non-repudiation as has been
>>proposed on this mailing list.
>
> Not all applications may be trusted to properly assert invocation  of NR
> services.  By including the NR bit in a cert, we have a (potentially)
> higher assurance mechanism that can allow or prohibit an application from
> invoking NR services.  For example, if one provides an application with
> access to certs ONLY with NR=0, we can ensure that these apps cannot assert
> that they are acting in an NR capacity on behalf of the user. This is a
> very useful security facility and a good reason to keep the NR bit.
>
> Steve
>
>
>






Received: from tomcat.sac.verio.net ([e-mail] [209.162.64.15]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id NAA07739 for <[e-mail]>; Tue, 31 Aug 1999 13:30:30 -0700 (PDT)
Received: from nma.com (pm04-27.sac.verio.net [209.162.64.140]) by tomcat.sac.verio.net (8.9.1a/8.9.1) with ESMTP id NAA00558; Tue, 31 Aug 1999 13:28:52 -0700 (PDT)
Message-ID: <[e-mail]>
Date: Tue, 31 Aug 1999 13:26:10 -0700
From: Ed Gerck <[e-mail]>
X-Mailer: Mozilla 4.61 [en]C-CCK-MCD {Sony}  (Win98; I)
X-Accept-Language: en
MIME-Version: 1.0
To: [e-mail]
CC: Stephen Kent <[e-mail]>, Aram Perez <[e-mail]>, [e-mail]
Subject: Re: New Internet Draft on Non-Repudiation Requirements
References: <[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

[e-mail] wrote:

>      my new "Technical NR Requirements" draft is available at
> http://www.ietf.org/internet-drafts/draft-gindin-pkix-technr-00.txt or in the
> "internet-drafts" directory on the usual shadow sites as
> draft-gindin-pkix-technr-00.txt
>
>      Subsequent review of this draft has suggested a new addition to the set of
> requirements for "1-way" NR, as follows:
>
> 3.4  The relying party should create, and save with the data submitted, a
> package containing a current time stamp signed by an independent authority.
> This object signed by the independent authority should include, in addition to
> the time stamp, one of the following: a countersignature created by the relying
> party, a copy of the "signature block" of the submitted document, or the entire
> submitted document.

I believe your draft, even without the addition (which has its pros and cons IMO),
is indeed working to fill the gap you mention in it:

 "Extensive discussions in the PKIX WG have revealed that the description of
 the non-repudiation service contained in this passage is not widely enough
 understood or agreed upon to characterize any given service as providing or
 not providing a non-repudiation service."

In regard to the name of that bit, keeping it as "non-repudiation" is now IMO
not so misleading because the context is clear.  I am also glad you focused
on "what", "how" and "when" instead of "who" and "why" and that you clearly
state what non-repudiation would really be if taken to task:

 "a full non-repudiation service which is intended to prevent all possible
 repudiations of a signed object or document."

which helps the reader to differentiate what PKIX NR is not.

I have no comments and congratulations.

Cheers,

Ed Gerck



Received: from tomcat.sac.verio.net ([e-mail] [209.162.64.15]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id NAA07386 for <[e-mail]>; Tue, 31 Aug 1999 13:08:24 -0700 (PDT)
Received: from nma.com (pm04-27.sac.verio.net [209.162.64.140]) by tomcat.sac.verio.net (8.9.1a/8.9.1) with ESMTP id NAA25928 for <[e-mail]>; Tue, 31 Aug 1999 13:10:31 -0700 (PDT)
Message-ID: <[e-mail]>
Date: Tue, 31 Aug 1999 13:07:50 -0700
From: Ed Gerck <[e-mail]>
X-Mailer: Mozilla 4.61 [en]C-CCK-MCD {Sony}  (Win98; I)
X-Accept-Language: en
MIME-Version: 1.0
CC: [e-mail]
Subject: Real-world issues, Re: Deprecate the NR bit?
References: <v04020a08b3f193956436@[128.89.0.111]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Stephen Kent wrote:

> Not all applications may be trusted to properly assert invocation  of NR
> services.

Failure of NR services  (whatever "NR services" is understood to be, from
the options mentioned here) will  however flow back only to the
relying-party *if* the relying-party uses an application that causes that
failure by improperly asserting invocation of "NR services" -- which is
what you mention above.

Therefore, in the case you mention, both the cert  issuer and the cert subject
will be *relieved* of any "NR services" obligations -- which means that
is irrelevant to either of them whether the relying-party fails or not fails
to use an application that can "be trusted to properly assert invocation of
NR services".

This logic applies also when the issuer entity has a second hat as one of
the relying-parties -- for example, when the CA is internal to a company
and has the responsibility of selecting the application that will be
used to validate the certs at the workstations, because in this case the CA
is not acting as an issuer in this second role but as a relying-party to the
issuer and its failure in this second role cannot taint its first role as an
issuer.

Thus, the case you mention is moot in real-world cases -- it is the
relying-party's responsibility to select its applications, and also to use
them properly.

> By including the NR bit in a cert, we have a (potentially)
> higher assurance mechanism that can allow or prohibit an application from
> invoking NR services.

Agreed 100%. Whatever "NR services" is.  But that decision (to allow or
prohibit) can fall on the relying-party itself, on the cert issuer, on the cert
subject or on a fourth-party (validation service, etc.).   Thus, what you
mention needs to be expressively qualified -- either in the spec or in the
CPS, or in both (with default to CPS). I prefer the last option, for reasons
already mentioned.

Without qualification, what you mention is thus too ambiguous to be
useful in the real-world.  And, illegal if there was no previous provable consent
based on clear text with a choice not to use it.

>  For example, if one provides an application with
> access to certs ONLY with NR=0, we can ensure that these apps cannot assert
> that they are acting in an NR capacity on behalf of the user.

In your example, "one provides an application with access to certs ONLY
with NR=0" is a trust statement.  Someone trusts that "ONLY" -- either the
"one" that provided (e.g., a sysadmin) or the relying-party itself.  However,
what happens if that application may not in fact be properly trusted in the
real-workd operational context? Then, we are back to paragraph one.   So,
"we can ensure" nothing.

Again, it is the relying-party's responsibility to select its applications, and
also to use them properly.

> This is a very useful security facility and a good reason to keep the NR bit.

Not by this reason, though, as above.

Further, I think that is becoming increasingly clear by these and previous examples
that there is no real-world use model behind the "NR services" defined in PKIX.
And I say this not as an argument to deprecate the "NR bit" (which would be the
worse choice IMO) but as a strong argument to say the least about it in the spec
itself and leave the CPS as the authoritative source -- possibly with a simple
and clear default behavior in the spec if the CPS does not mention it.

To be fully backward and forward compatible  is not easy in this case but
suggestions were already presented.

BTW, as a side remark but also a real-world issue, it may be time for IETF to
also consider WG-authored RFCs and STDs -- which would avoid the problem
of one or a few authors being  confronted with the unfair pain of changing
their own words based on a large WG's work with many more eyes.   It is hard
to imagine RFCs on important and wide-reaching subjects that can really be
attributed to one person nowadays, even though this was possible some
Internet-years ago with John Postel and others.   If decisions are made by or
imply consensus and if there is wide  participation, attribution of RFCs to the
WG should afford more flexibility and actually reflect that participation.  One
recent example where this is being applied quite successfully in a difficult
subject can be seen in NSI's Registry Advisory  Board where I participate
and we decided to use anonymous attributions in the Meeting Minutes in
order to stress that they are the result of group work and to keep positions
flexible -- nonetheless, we can keep track of what has been decided and why.
The mechanism of group-authored text can be extended even to list discussions
as one Internet WG used in order to enhance the flow of ideas, by anonymizing
email addresses. Group-authored text can also be reduced in RFCs by selecting
one or two WG members as editors of contributions but not as writers.

Cheers,

Ed Gerck



Received: from mail-out2.apple.com (mail-out2.apple.com [17.254.0.51]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id NAA07225 for <[e-mail]>; Tue, 31 Aug 1999 13:07:20 -0700 (PDT)
Received: from mailgate2.apple.com ([17.129.100.225]) by mail-out2.apple.com (8.9.3/8.9.3) with ESMTP id NAA11135 for <[e-mail]>; Tue, 31 Aug 1999 13:09:27 -0700 (PDT)
Received: from scv4.apple.com (scv4.apple.com) by mailgate2.apple.com (Content Technologies SMTPRS 2.0.15) with ESMTP id <[e-mail]> for <[e-mail]>; Tue, 31 Aug 1999 13:09:22 -0700
Received: from [17.205.41.166] (aram1.apple.com [17.205.41.166]) by scv4.apple.com (8.9.3/8.9.3) with ESMTP id NAA12650 for <[e-mail]>; Tue, 31 Aug 1999 13:09:21 -0700
Message-Id: <[e-mail]>
X-Mailer: Microsoft Outlook Express Macintosh Edition - 4.5 (0410)
Date: Tue, 31 Aug 1999 13:09:21 -0700
Subject: Re: New Internet Draft on Non-Repudiation Requirements
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

Tom Gindin wrote:

I haven't reviewed your document yet, but I have one question/comment
below...

>      I think that we should remember that the NR bit is supposed to cause CRL
> archiving  as well.  In any case, while I haven't seen the official
announcement
> yet, my new "Technical NR Requirements" draft is available at
> http://www.ietf.org/internet-drafts/draft-gindin-pkix-technr-00.txt or in the
> "internet-drafts" directory on the usual shadow sites as
> draft-gindin-pkix-technr-00.txt
>
>      Subsequent review of this draft has suggested a new addition to the set
of
> requirements for "1-way" NR, as follows:
>
> 3.4  The relying party should create, and save with the data submitted, a
> package containing a current time stamp signed by an independent authority.
> This object signed by the independent authority should include, in addition to
> the time stamp, one of the following: a countersignature created by the
> relying party,

Does the certificate for this countersignature have the NR bit set? If yes,
do you need another countersignature with NR, etc, etc.? If no, is the
countersignature repudiable?

Regards,
Aram Perez


> a copy of the "signature block" of the submitted document,
> or the entire submitted document.
>
>
>           Tom Gindin
>
>
> Stephen Kent <[e-mail]> on 08/31/99 10:20:13 AM
>
> To:   "Aram Perez" <[e-mail]>
> cc:   [e-mail]
> Subject:  Re: Deprecate the NR bit?
>
>
>
>
>
> At 8:53 AM -0700 8/30/99, Aram Perez wrote:
>
>>Ron Ramsay wrote:
>>
>>> Except that the NR bit cannot be added to the certificate by the
>>> application!
>>
>>But the application can add a much better indicator to the data that needs
>>to be part of the evidence that supports non-repudiation as has been
>>proposed on this mailing list.
>
> Not all applications may be trusted to properly assert invocation  of NR
> services.  By including the NR bit in a cert, we have a (potentially)
> higher assurance mechanism that can allow or prohibit an application from
> invoking NR services.  For example, if one provides an application with
> access to certs ONLY with NR=0, we can ensure that these apps cannot assert
> that they are acting in an NR capacity on behalf of the user. This is a
> very useful security facility and a good reason to keep the NR bit.
>
> Steve
>
>
>



Received: from e2.ny.us.ibm.com (e2.ny.us.ibm.com [32.97.182.102]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id MAA06568 for <[e-mail]>; Tue, 31 Aug 1999 12:32:19 -0700 (PDT)
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 PAA33760; Tue, 31 Aug 1999 15:33:58 -0400
Received: from D51MTA05.pok.ibm.com (d51mta05.pok.ibm.com [9.117.200.33]) by northrelay02.pok.ibm.com (8.8.8m2/NCO v2.04) with SMTP id PAA275666; Tue, 31 Aug 1999 15:34:21 -0400
Received: by D51MTA05.pok.ibm.com(Lotus SMTP MTA v4.6.4  (830.2 3-23-1999))  id 852567DE.006B829B ; Tue, 31 Aug 1999 15:34:17 -0400
X-Lotus-FromDomain: IBMUS
To: Stephen Kent <[e-mail]>
cc: "Aram Perez" <[e-mail]>, [e-mail]
Message-ID: <[e-mail]>
Date: Tue, 31 Aug 1999 15:33:06 -0400
Subject: New Internet Draft on Non-Repudiation Requirements
Mime-Version: 1.0
Content-type: text/plain; charset=us-ascii
Content-Disposition: inline

     I think that we should remember that the NR bit is supposed to cause CRL
archiving  as well.  In any case, while I haven't seen the official announcement
yet, my new "Technical NR Requirements" draft is available at
http://www.ietf.org/internet-drafts/draft-gindin-pkix-technr-00.txt or in the
"internet-drafts" directory on the usual shadow sites as
draft-gindin-pkix-technr-00.txt

     Subsequent review of this draft has suggested a new addition to the set of
requirements for "1-way" NR, as follows:

3.4  The relying party should create, and save with the data submitted, a
package containing a current time stamp signed by an independent authority.
This object signed by the independent authority should include, in addition to
the time stamp, one of the following: a countersignature created by the relying
party, a copy of the "signature block" of the submitted document, or the entire
submitted document.


          Tom Gindin


Stephen Kent <[e-mail]> on 08/31/99 10:20:13 AM

To:   "Aram Perez" <[e-mail]>
cc:   [e-mail]
Subject:  Re: Deprecate the NR bit?





At 8:53 AM -0700 8/30/99, Aram Perez wrote:

>Ron Ramsay wrote:
>
>> Except that the NR bit cannot be added to the certificate by the
>> application!
>
>But the application can add a much better indicator to the data that needs
>to be part of the evidence that supports non-repudiation as has been
>proposed on this mailing list.

Not all applications may be trusted to properly assert invocation  of NR
services.  By including the NR bit in a cert, we have a (potentially)
higher assurance mechanism that can allow or prohibit an application from
invoking NR services.  For example, if one provides an application with
access to certs ONLY with NR=0, we can ensure that these apps cannot assert
that they are acting in an NR capacity on behalf of the user. This is a
very useful security facility and a good reason to keep the NR bit.

Steve





Received: from po1.bbn.com (PO1.BBN.COM [192.1.50.38]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id LAA04933 for <[e-mail]>; Tue, 31 Aug 1999 11:33:10 -0700 (PDT)
Received: from [128.89.0.111] (YAKOV.BBN.COM [128.89.0.111]) by po1.bbn.com (8.9.1/8.9.1) with ESMTP id OAA05315; Tue, 31 Aug 1999 14:35:10 -0400 (EDT)
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Message-Id: <v04020a08b3f193956436@[128.89.0.111]>
In-Reply-To: <[e-mail]>
Date: Tue, 31 Aug 1999 10:20:13 -0400
To: "Aram Perez" <[e-mail]>
From: Stephen Kent <[e-mail]>
Subject: Re: Deprecate the NR bit?
Cc: [e-mail]

At 8:53 AM -0700 8/30/99, Aram Perez wrote:

>Ron Ramsay wrote:
>
>> Except that the NR bit cannot be added to the certificate by the
>> application!
>
>But the application can add a much better indicator to the data that needs
>to be part of the evidence that supports non-repudiation as has been
>proposed on this mailing list.

Not all applications may be trusted to properly assert invocation  of NR
services.  By including the NR bit in a cert, we have a (potentially)
higher assurance mechanism that can allow or prohibit an application from
invoking NR services.  For example, if one provides an application with
access to certs ONLY with NR=0, we can ensure that these apps cannot assert
that they are acting in an NR capacity on behalf of the user. This is a
very useful security facility and a good reason to keep the NR bit.

Steve


Received: from mail.spyrus.com (mail.spyrus.com [207.212.34.20]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id LAA04653 for <[e-mail]>; Tue, 31 Aug 1999 11:20:09 -0700 (PDT)
Received: from rhousley_laptop.spyrus.com ([209.172.119.101]) by mail.spyrus.com (8.9.3/8.9.3) with ESMTP id LAA03378; Tue, 31 Aug 1999 11:15:49 -0700 (PDT)
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58 
Date: Tue, 31 Aug 1999 14:18:48 -0400
To: [e-mail]
From: Russ Housley <[e-mail]>
Subject: Re: Comments on RFC 2459
Cc: [e-mail]
In-Reply-To: <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed

Wei-Ching:

RFC 2459 mandates the use of the key indentifier.  The 
authorityCertIssuer/authorityCertSerialNumner may also be present.

So, I do not see a problem.

Russ


At 11:35 AM 8/31/99 +0800, [e-mail] wrote:
>I have some comments on sec 4.2.1.2 of the rfc 2459.
>
>It says to facilitate chain building, the subject key identifier extenion
>must appear in all conforming CA certificates. In fact, it is not always
>true. If the CA issuers the certificates, and use the authorityCertIssuer +
>
>authorityCertIssuerSerialNumber as these cetificates' authority key
>identifier extenion, then the CA certificte need not include the subject
>key identifier, because the information is included in its basic
>certificate
>fields.
>
>I think the subject key identifier must be included in CA certificate only
>if the CA issuers the certificates, and use keyIdentifier as these
>cetificates'
>authority key identifier extenion.
>
>Regards
>
>Wei-Ching Su
>
>Senior Engineer
>FISC (Financial Information Service Co., LTD.)
>Taipei, Taiwan
>



Received: from dfw7-1.relay.mail.uu.net (dfw7-1.relay.mail.uu.net [199.171.54.106]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id KAA04309 for <[e-mail]>; Tue, 31 Aug 1999 10:58:22 -0700 (PDT)
Received: from xedia.com by dfw7sosrv11.alter.net with SMTP  (peer crosschecked as: madway.xedia.com [198.202.232.199]) id QQherg14521; Tue, 31 Aug 1999 18:00:30 GMT
Received: from tonga.xedia.com by xedia.com (4.1/SMI-4.1) id AA21666; Tue, 31 Aug 99 13:58:55 EDT
Received: by tonga.xedia.com (SMI-8.6/SMI-SVR4) id OAA05226; Tue, 31 Aug 1999 14:00:29 -0400
Date: Tue, 31 Aug 1999 14:00:29 -0400
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: Multi-national company listing issues
References: <[e-mail]>
X-Mailer: VM 6.34 under 20.3 "Vatican City" XEmacs  Lucid

>>>>> "Bob" == Bob Jueneman <[e-mail]> writes:

 >> All,
 >> 
 >> Just an observation:) I get a strange sense of Deja Vu here.
 >> 
 >> As Paul Koning remarked, in the US at least, the designation
 >> "C=US" means "The party in question paid ANSI the required fee, so
 >> ANSI registered the entry under 'US'" (loosely paraphrased)."

 Bob> Well, that really isn't true, at least in any realistic sense.

 Bob> I believe that it is very important to distinguish between
 Bob> ANSI's role as a registration authority OIDs under the joint
 Bob> ISO-CCITT registration arc, versus the semantics of "country" in
 Bob> either a DIT or a certificate.

 Bob> Speaking of deja vu all over again, the original RSA Commercial
 Bob> Hierarchy CA, circa the early '90s, required the following:

 Bob> 1.  If an organization was to be listed at the country level,
 Bob> e.g., c=US, o=Novell, then that organization had to been
 Bob> registered with ANSI and obtained an OID and name listing
 Bob> (approximately $2000).  There name registration procedure did
 Bob> not provide any kind of guarantee of exclusivity, and in
 Bob> particular ANSI does not assume any liability for the
 Bob> correctness or right to use of a name, but procedurally it was
 Bob> pretty good.

But doesn't that match what Tony said?  If you obtained both a name
and OID registration from ANSI, you'd live under C=US, O=<that name>.
And given ANSI's documented registration practices, the semantics of
"C=US" in this case are "ANSI registered this name" and in particular
no implication about the location, place of incorporation, or any
other geographic attribute of the organization itself.

It may be that there is an expectation that names of this form do have 
such a semantic, but if so, that expectation is not fulfilled by
current ANSI practice.  (I have seen some indication, though I don't
have specifics, that registrars in other countries have similar
approaches as ANSI.)

	paul


Received: from prv-mail20.provo.novell.com (prv-mail20.provo.novell.com [137.65.82.195]) by mail.proper.com (8.9.3/8.9.3) with SMTP id KAA29743 for <[e-mail]>; Tue, 31 Aug 1999 10:01:45 -0700 (PDT)
Received: from INET-PRV-Message_Server by prv-mail20.provo.novell.com with Novell_GroupWise; Tue, 31 Aug 1999 11:03:23 -0600
Message-Id: <[e-mail]>
X-Mailer: Novell GroupWise 5.5.2
Date: Tue, 31 Aug 1999 11:03:17 -0600
From: "Bob Jueneman" <[e-mail]>
To: <[e-mail]>
Cc: <[e-mail]>
Subject: Re: Multi-national company listing issues
Mime-Version: 1.0
Content-Type: multipart/mixed; boundary="=_5204A4CB.7E1F7D2D"

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.

--=_5204A4CB.7E1F7D2D
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

>All,
>
>Just an observation:)  I get a strange sense of Deja Vu here.
>
>As Paul Koning remarked, in the US at least, the designation
>"C=3DUS" means "The party in question paid ANSI the required fee,
>so ANSI registered the entry under 'US'" (loosely paraphrased)."

Well, that really isn't true, at least in any realistic sense.

I believe that it is very important to distinguish between ANSI's role
as a registration authority OIDs under the joint ISO-CCITT registration =
arc,
versus the semantics of "country" in either a DIT or a certificate.

Speaking of deja vu all over again, the original RSA Commercial Hierarchy
CA, circa the early '90s, required the following:

1.  If an organization was to be listed at the country level, e.g., =
c=3DUS, o=3DNovell,
then that organization had to been registered with ANSI and obtained an
OID and name listing (approximately $2000).  There name registration =
procedure=20
did not provide any kind of guarantee of exclusivity, and in particular =
ANSI does not assume any liability for the correctness or right to use of =
a name, but procedurally it was pretty good.

2.  If an organization was not listed at the country level, the stateOrProv=
ince attribute had to be listed immediately under the country, and the =
organization had to provide suitable proof of the fact that it was =
listed/chartered/incorporated in that state. =20

3.  If an organization was not incorporated or otherwise chartered in some =
state,
the qualification had to extend down to the municipality level, expressed =
as locality.

All of this seemed very reasonable, although it was in no way required by =
ISO, CCITT, or ANSI itself, but rather by the CA, as a condition of =
registration.

Where this began to fall apart was when it was observed that many, many =
organizations simply didn't organize their directories that way, and =
weren't going to change.  And back then, in the X.509 v1 days, there were =
no convenient alternatives.

Now, of course, we have subjectAltName, and my recommendation would be =
that we strongly suggest if not require this DIT structure and registration=
 requirement as a subjectAltName of any certificate issued to an "organizat=
ional person" or other corporate entity.

But I give up on tying to harmonize the Subject DN -- it's too late.  If =
we are going to be able to store and retrieve certificates, and authenticat=
e users to a directory based on their certificate, a one-to-one mapping =
between the DN in the certificate and the DN in the directory is about the =
only reasonable way to progress.

Robert R. Jueneman
Security Architect
Network Security Development
Novell, Inc.
122 East 1700 South
Provo, UT 84606
[e-mail]
1-801-861-7387


--=_5204A4CB.7E1F7D2D
Content-Type: text/x-vcard
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment; filename="Bob Jueneman.vcf"

BEGIN:VCARD
VERSION:2.1
X-GWTYPE:USER
FN:Robert R. Jueneman
TEL;WORK:1-801-861-7387, 1-800-453-1267
ORG:Novell, Inc.;Network Security Development
TEL;PREF;FAX:[phone]
EMAIL;WORK;PREF;NGW:[e-mail]
N:Jueneman;Robert
TITLE:Security Architect
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


--=_5204A4CB.7E1F7D2D--


Received: from mail.vpnc.org (mail.vpnc.org [165.227.249.9]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id JAA27675 for <[e-mail]>; Tue, 31 Aug 1999 09:28:19 -0700 (PDT)
Received: from aum (ip11.proper.com [165.227.249.11]) by mail.vpnc.org (8.9.3/8.9.0) with ESMTP id JAA10588; Tue, 31 Aug 1999 09:28:19 -0700 (PDT)
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58 
Date: Tue, 31 Aug 1999 09:29:08 -0700
To: Alan Lloyd <[e-mail]>, [e-mail]
From: Paul Hoffman / VPNC <[e-mail]>
Subject: RE: SCVP-01
In-Reply-To: <D1A949D4508DD1119C8100400533BEDC107847@DSG1>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed

At 05:21 PM 8/31/1999 +1000, Alan Lloyd wrote:
>         snip
> > Yes, we could put in a bunch of changes in OCSP to make it
> > work, but you would end up changing the semantics of a large
> > part of OCSP.
> >
>         its best to add a few features to a trusted transport that
>serves a common operational function (cert status and validation) than
>reinvent the whole box and dice again - re key management, protocol hddr
>formats, routing references, etc, etc - and also introduce compatibility
>and interoperability when both technologies are used in the same
>operational system.

Yes, that's probably true. SCVP doesn't do any of that. This seems like a 
red herring.

>         One only has to think of the customer and what they want...
>simpler systems, less code changes, less protocols, less databases and
>less configuration and more capability and trust  -  to see what the
>logical answer is..

Yes, that's probably true. Do you think that adding the SCVP functionality 
to OCSP would not involve more complicated systems and more code changes? 
Of course, it is one more protocol, but if you're talking bits on the wire, 
the SVCP request and response are carried on the same protocols as OCSP. I 
don't know what you mean by more databases or more configuration. If you 
want to get the functionality of SCVP in OCSP, you'll need to have the same 
databases and configuration, and the same capability and trust.

Or are you saying that none of the SCVP features are desired by anyone?

>         Why does OCSP and LDAP have extensions... Its not so we can
>ignore them and produce another YAP with optional extensions. that wont
>be used...

Correct. OSCP extensions can be used to extend OCSP. What we are proposing 
does not fit into the semantics of OCSP. There are two possible solutions: 
extend the semantics of OCSP, or create a different protocol that does what 
you want without forcing a change in an existing protocol. SCVP uses the 
latter approach.

If you think it should use the former, I extend the same suggestion that I 
extended to Mike Myers: do the work of changing the OCSP spec to include 
the SCVP functionality and show it to the group. I sincerely think that you 
will not find it easy, and that OCSP developers will find it as hard (or 
even harder) to shoehorn in your changes to OCSP extension mechanism as 
they would to use the SCVP request and response format. I could be wrong 
about this, and would be happy to admit so if your draft looks easier than 
SCVP. But Ambarish and I really looked at this before we created our own 
format.

--Paul Hoffman, Director
--VPN Consortium


Received: from homebase.htt-consult.com (homebase.htt-consult.com [208.235.169.130]) by mail.proper.com (8.9.3/8.9.3) with SMTP id HAA25703 for <[e-mail]>; Tue, 31 Aug 1999 07:47:00 -0700 (PDT)
Received: from rgm ([208.235.169.131]) by homebase.htt-consult.com ; Tue, 31 Aug 1999 10:49:18 -0500
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 
Date: Tue, 31 Aug 1999 10:47:09 -0400
To: "Miklos, Sue A." <[e-mail]>, "'Tony Bartoletti'" <[e-mail]>, Bob Jueneman <[e-mail]>, [e-mail]
From: Robert Moskowitz <[e-mail]>
Subject: RE: Multi-national company listing issues
Cc: [e-mail], [e-mail], [e-mail], [e-mail], [e-mail], [e-mail]
In-Reply-To: <[e-mail] c.mil>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"

At 10:33 AM 8/31/1999 -0400, Miklos, Sue A. wrote: 


>
> "Upon approval of ISO/IEC 9834-7 | ITU-T Rec. 666, ANSI agreed to apply to
> become the registration authority.  However, a complete set of procedures has
> yet to be developed, and the application to ISO, IEC & ITU-T has not yet been
> submitted."
>
> note that this standard deals with registration of multi-national
> organizations (use of the O= component) for those organizations/coalitions,
> etc. who do not populate, or ignore, the C= component.


One of these eons...  Sigh.  Like this is a new business invention.


Robert Moskowitz
ICSA
Security Interest EMail: [e-mail]


Received: from stingray.missi.ncsc.mil (stingray.missi.ncsc.mil [144.51.50.20]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id HAA25361 for <[e-mail]>; Tue, 31 Aug 1999 07:32:01 -0700 (PDT)
Received: from stingray.missi.ncsc.mil (root@localhost) by stingray.missi.ncsc.mil with ESMTP id KAA16912 for <[e-mail]>; Tue, 31 Aug 1999 10:34:13 -0400 (EDT)
Received: from missi.ncsc.mil (depot.missi.ncsc.mil [144.51.60.1]) by stingray.missi.ncsc.mil with ESMTP id KAA16848 for <[e-mail]>; Tue, 31 Aug 1999 10:34:07 -0400 (EDT)
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 KAA06578 for <[e-mail]>; Tue, 31 Aug 1999 10:33:54 -0400 (EDT)
Received: from avenger.missi.ncsc.mil (avenger58.missi.ncsc.mil) by mimesweeper.missi.ncsc.mil (Content Technologies SMTPRS 2.0.15) with ESMTP id <[e-mail]>; Tue, 31 Aug 1999 10:33:44 -0400
Received: by avenger54.missi.ncsc.mil with Internet Mail Service (5.5.2232.9) id <Q2Z2H4F7>; Tue, 31 Aug 1999 10:33:55 -0400
Message-Id: <[e-mail]>
From: "Miklos, Sue A." <[e-mail]>
To: "'Tony Bartoletti'" <[e-mail]>, Bob Jueneman <[e-mail]>, [e-mail]
Cc: [e-mail], [e-mail], [e-mail], [e-mail], [e-mail], [e-mail], [e-mail]
Subject: RE: Multi-national company listing issues
Date: Tue, 31 Aug 1999 10:33:46 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2232.9)
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01BEF3BD.DA297F56"

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_01BEF3BD.DA297F56
Content-Type: text/plain;
	charset="iso-8859-1"

excerpt from exchange w/ANSI...

"Upon approval of ISO/IEC 9834-7 | ITU-T Rec. 666, ANSI agreed to apply to
become the registration authority.  However, a complete set of procedures
has yet to be developed, and the application to ISO, IEC & ITU-T has not yet
been submitted."

note that this standard deals with registration of multi-national
organizations (use of the O= component) for those organizations/coalitions,
etc. who do not populate, or ignore, the C= component.

Sandi

-----Original Message-----
From: Tony Bartoletti [mailto:[e-mail]]
Sent: Monday, August 30, 1999 8:53 PM
To: Bob Jueneman; [e-mail]
Cc: [e-mail]; [e-mail];
[e-mail]; [e-mail];
[e-mail]; [e-mail];
[e-mail]
Subject: Re: Multi-national company listing issues


All,

Just an observation:)  I get a strange sense of Deja Vu here.

As Paul Koning remarked, in the US at least, the designation
"C=US" means "The party in question paid ANSI the required fee,
so ANSI registered the entry under 'US'" (loosely paraphrased)."

So, if you want more specifics, consult ANSI's "RPS" (Registration
Practices Statement.)  OK, I'm making that part up, its a take-off
on "CPS", for those who don't get it otherwise :)

___tony___


At 05:27 PM 8/30/99 -0600, Bob Jueneman wrote:
>Ed,
>
>I used a conventional X.400 representational shorthand for 
>the attribute called "country"  I would always assume that 
>localization of any display code would translate that 
>appropriately, if that was felt to be necessary.
>
>Bob
>
>
>
>>>> Ed Gerck <[e-mail]> 08/27/99 11:01AM >>>
> Bob Jueneman <[e-mail]> wrote:
>
>> For example, is "C=" the country where the parent is located,
>> where the subsidiary is located, where the tiny field office is
>> located, where they are incorporated (think of a ship with
>> Liberian registry), etc., etc.?
>>
>> In the case of an individual user, is the country where he was
>> born (or adopted)? Where he is currently a citizen (what about
>> dual citizenship, stateless persons, and nomads)?  Where he
>> maintains a residence (or maybe a domicile)?  Where he works (I
>> assume some people work in one country and sleep in another,
>> every day)?
>
>Bob:
>
>What is the meaning of "C=string"?
>
>There are two ways to solve this. One, is to proceed with the hierarchical
>type structure as a taxonomy and provide all the possible ramifications --
>clearly, with very little chance of satisfying even just the majority of
cases.
>The other way is to renounce the concept (wrong, anyway) of "denotational
>syntax", treat the hierarchical structure as an an ontology and consider
all
>qualifiers from the syntactic point of view, as "names".  With this
approach,
>the meaning of "C=string" is now clear:
>
>"C" and "string" are specified, and "C" stands in equivalence with "string"
>
>Here, "C" is a name -- a quite arbitrary designation that is simply
formally
>defined and may (or not) have a mnemonic purpose or be expressed in
>a human language.  In other words, "C" is just a pointer, a handle in an
>hierarchical ontology (not in a taxonomy).  OTOH, "string" may be either
>a name or a record as usual, where records refer mainly to physical
>quantities (e.g., geographical data, network addresses, port numbers,
>service designations, company names, etc.) designated in a materially
>pre-defined form.  The  map and query methods of a database can then
>relate names to records in a variety of relationships according to local
>need, such as one-to-one, many-to-one, one-to-many or many-to-many.
>The database can also follow a variety of models such as hierarchical,
>network, relational, distributed hierarchical, etc.
>
>What is required to do this? Nothing, just renounce the taxonomy and
>employ the same hierarchical structure already in place in X.500 or
>LDAP or whatever is being used.  Even the same relational tables
>if a relational database model is followed.
>
>But, where is the meaning of "C" denoted?  Not, in "C" itself but in the
>trusted context -- where it is anyway defined.  For example, "C" is
>meaningless in German as an abbreviation for Country -- it is the trusted
>context which says so (but, with all the ambiguities you point out and
>which are basically irresolvable).
>
>The integration of different trusted contexts becomes then a problem,
>but one which I believe is being increasingly solved in database theory
>-- for example, with meta-directory approaches.
>
>Of course, denotational syntax also "works" one may say -- but only in a
>parochial environment where the trusted context is implicitly known.  Since
>we are past this stage in the Internet, the fact that syntax and semantics
>are independent variables can no longer be ignored and must be either
>properly handled or threatens to overwhelm.
>
>Cheers,
>
>Ed Gerck
>
>
>
>

------_=_NextPart_001_01BEF3BD.DA297F56
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: Multi-national company listing issues</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=3D2>excerpt from exchange w/ANSI...</FONT>
</P>

<P><FONT SIZE=3D2>&quot;Upon approval of ISO/IEC 9834-7 | ITU-T Rec. =
666, ANSI agreed to apply to become the registration authority.&nbsp; =
However, a complete set of procedures has yet to be developed, and the =
application to ISO, IEC &amp; ITU-T has not yet been =
submitted.&quot;</FONT></P>

<P><FONT SIZE=3D2>note that this standard deals with registration of =
multi-national organizations (use of the O=3D component) for those =
organizations/coalitions, etc. who do not populate, or ignore, the C=3D =
component.</FONT></P>

<P><FONT SIZE=3D2>Sandi</FONT>
</P>

<P><FONT SIZE=3D2>-----Original Message-----</FONT>
<BR><FONT SIZE=3D2>From: Tony Bartoletti [<A =
HREF=3D"mailto:[e-mail]">mailto:[e-mail]</A>]</FONT>
<BR><FONT SIZE=3D2>Sent: Monday, August 30, 1999 8:53 PM</FONT>
<BR><FONT SIZE=3D2>To: Bob Jueneman; [e-mail]</FONT>
<BR><FONT SIZE=3D2>Cc: [e-mail]; =
[e-mail];</FONT>
<BR><FONT SIZE=3D2>[e-mail]; [e-mail];</FONT>
<BR><FONT SIZE=3D2>[e-mail]; =
[e-mail];</FONT>
<BR><FONT SIZE=3D2>[e-mail]</FONT>
<BR><FONT SIZE=3D2>Subject: Re: Multi-national company listing =
issues</FONT>
</P>
<BR>

<P><FONT SIZE=3D2>All,</FONT>
</P>

<P><FONT SIZE=3D2>Just an observation:)&nbsp; I get a strange sense of =
Deja Vu here.</FONT>
</P>

<P><FONT SIZE=3D2>As Paul Koning remarked, in the US at least, the =
designation</FONT>
<BR><FONT SIZE=3D2>&quot;C=3DUS&quot; means &quot;The party in question =
paid ANSI the required fee,</FONT>
<BR><FONT SIZE=3D2>so ANSI registered the entry under 'US'&quot; =
(loosely paraphrased).&quot;</FONT>
</P>

<P><FONT SIZE=3D2>So, if you want more specifics, consult ANSI's =
&quot;RPS&quot; (Registration</FONT>
<BR><FONT SIZE=3D2>Practices Statement.)&nbsp; OK, I'm making that part =
up, its a take-off</FONT>
<BR><FONT SIZE=3D2>on &quot;CPS&quot;, for those who don't get it =
otherwise :)</FONT>
</P>

<P><FONT SIZE=3D2>___tony___</FONT>
</P>
<BR>

<P><FONT SIZE=3D2>At 05:27 PM 8/30/99 -0600, Bob Jueneman wrote:</FONT>
<BR><FONT SIZE=3D2>&gt;Ed,</FONT>
<BR><FONT SIZE=3D2>&gt;</FONT>
<BR><FONT SIZE=3D2>&gt;I used a conventional X.400 representational =
shorthand for </FONT>
<BR><FONT SIZE=3D2>&gt;the attribute called &quot;country&quot;&nbsp; I =
would always assume that </FONT>
<BR><FONT SIZE=3D2>&gt;localization of any display code would translate =
that </FONT>
<BR><FONT SIZE=3D2>&gt;appropriately, if that was felt to be =
necessary.</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;</FONT>
<BR><FONT SIZE=3D2>&gt;</FONT>
<BR><FONT SIZE=3D2>&gt;&gt;&gt;&gt; Ed Gerck &lt;[e-mail]&gt; =
08/27/99 11:01AM &gt;&gt;&gt;</FONT>
<BR><FONT SIZE=3D2>&gt; Bob Jueneman &lt;[e-mail]&gt; =
wrote:</FONT>
<BR><FONT SIZE=3D2>&gt;</FONT>
<BR><FONT SIZE=3D2>&gt;&gt; For example, is &quot;C=3D&quot; the =
country where the parent is located,</FONT>
<BR><FONT SIZE=3D2>&gt;&gt; where the subsidiary is located, where the =
tiny field office is</FONT>
<BR><FONT SIZE=3D2>&gt;&gt; located, where they are incorporated (think =
of a ship with</FONT>
<BR><FONT SIZE=3D2>&gt;&gt; Liberian registry), etc., etc.?</FONT>
<BR><FONT SIZE=3D2>&gt;&gt;</FONT>
<BR><FONT SIZE=3D2>&gt;&gt; In the case of an individual user, is the =
country where he was</FONT>
<BR><FONT SIZE=3D2>&gt;&gt; born (or adopted)? Where he is currently a =
citizen (what about</FONT>
<BR><FONT SIZE=3D2>&gt;&gt; dual citizenship, stateless persons, and =
nomads)?&nbsp; Where he</FONT>
<BR><FONT SIZE=3D2>&gt;&gt; maintains a residence (or maybe a =
domicile)?&nbsp; Where he works (I</FONT>
<BR><FONT SIZE=3D2>&gt;&gt; assume some people work in one country and =
sleep in another,</FONT>
<BR><FONT SIZE=3D2>&gt;&gt; every day)?</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;What is the meaning of =
&quot;C=3Dstring&quot;?</FONT>
<BR><FONT SIZE=3D2>&gt;</FONT>
<BR><FONT SIZE=3D2>&gt;There are two ways to solve this. One, is to =
proceed with the hierarchical</FONT>
<BR><FONT SIZE=3D2>&gt;type structure as a taxonomy and provide all the =
possible ramifications --</FONT>
<BR><FONT SIZE=3D2>&gt;clearly, with very little chance of satisfying =
even just the majority of cases.</FONT>
<BR><FONT SIZE=3D2>&gt;The other way is to renounce the concept (wrong, =
anyway) of &quot;denotational</FONT>
<BR><FONT SIZE=3D2>&gt;syntax&quot;, treat the hierarchical structure =
as an an ontology and consider all</FONT>
<BR><FONT SIZE=3D2>&gt;qualifiers from the syntactic point of view, as =
&quot;names&quot;.&nbsp; With this approach,</FONT>
<BR><FONT SIZE=3D2>&gt;the meaning of &quot;C=3Dstring&quot; is now =
clear:</FONT>
<BR><FONT SIZE=3D2>&gt;</FONT>
<BR><FONT SIZE=3D2>&gt;&quot;C&quot; and &quot;string&quot; are =
specified, and &quot;C&quot; stands in equivalence with =
&quot;string&quot;</FONT>
<BR><FONT SIZE=3D2>&gt;</FONT>
<BR><FONT SIZE=3D2>&gt;Here, &quot;C&quot; is a name -- a quite =
arbitrary designation that is simply formally</FONT>
<BR><FONT SIZE=3D2>&gt;defined and may (or not) have a mnemonic purpose =
or be expressed in</FONT>
<BR><FONT SIZE=3D2>&gt;a human language.&nbsp; In other words, =
&quot;C&quot; is just a pointer, a handle in an</FONT>
<BR><FONT SIZE=3D2>&gt;hierarchical ontology (not in a taxonomy).&nbsp; =
OTOH, &quot;string&quot; may be either</FONT>
<BR><FONT SIZE=3D2>&gt;a name or a record as usual, where records refer =
mainly to physical</FONT>
<BR><FONT SIZE=3D2>&gt;quantities (e.g., geographical data, network =
addresses, port numbers,</FONT>
<BR><FONT SIZE=3D2>&gt;service designations, company names, etc.) =
designated in a materially</FONT>
<BR><FONT SIZE=3D2>&gt;pre-defined form.&nbsp; The&nbsp; map and query =
methods of a database can then</FONT>
<BR><FONT SIZE=3D2>&gt;relate names to records in a variety of =
relationships according to local</FONT>
<BR><FONT SIZE=3D2>&gt;need, such as one-to-one, many-to-one, =
one-to-many or many-to-many.</FONT>
<BR><FONT SIZE=3D2>&gt;The database can also follow a variety of models =
such as hierarchical,</FONT>
<BR><FONT SIZE=3D2>&gt;network, relational, distributed hierarchical, =
etc.</FONT>
<BR><FONT SIZE=3D2>&gt;</FONT>
<BR><FONT SIZE=3D2>&gt;What is required to do this? Nothing, just =
renounce the taxonomy and</FONT>
<BR><FONT SIZE=3D2>&gt;employ the same hierarchical structure already =
in place in X.500 or</FONT>
<BR><FONT SIZE=3D2>&gt;LDAP or whatever is being used.&nbsp; Even the =
same relational tables</FONT>
<BR><FONT SIZE=3D2>&gt;if a relational database model is =
followed.</FONT>
<BR><FONT SIZE=3D2>&gt;</FONT>
<BR><FONT SIZE=3D2>&gt;But, where is the meaning of &quot;C&quot; =
denoted?&nbsp; Not, in &quot;C&quot; itself but in the</FONT>
<BR><FONT SIZE=3D2>&gt;trusted context -- where it is anyway =
defined.&nbsp; For example, &quot;C&quot; is</FONT>
<BR><FONT SIZE=3D2>&gt;meaningless in German as an abbreviation for =
Country -- it is the trusted</FONT>
<BR><FONT SIZE=3D2>&gt;context which says so (but, with all the =
ambiguities you point out and</FONT>
<BR><FONT SIZE=3D2>&gt;which are basically irresolvable).</FONT>
<BR><FONT SIZE=3D2>&gt;</FONT>
<BR><FONT SIZE=3D2>&gt;The integration of different trusted contexts =
becomes then a problem,</FONT>
<BR><FONT SIZE=3D2>&gt;but one which I believe is being increasingly =
solved in database theory</FONT>
<BR><FONT SIZE=3D2>&gt;-- for example, with meta-directory =
approaches.</FONT>
<BR><FONT SIZE=3D2>&gt;</FONT>
<BR><FONT SIZE=3D2>&gt;Of course, denotational syntax also =
&quot;works&quot; one may say -- but only in a</FONT>
<BR><FONT SIZE=3D2>&gt;parochial environment where the trusted context =
is implicitly known.&nbsp; Since</FONT>
<BR><FONT SIZE=3D2>&gt;we are past this stage in the Internet, the fact =
that syntax and semantics</FONT>
<BR><FONT SIZE=3D2>&gt;are independent variables can no longer be =
ignored and must be either</FONT>
<BR><FONT SIZE=3D2>&gt;properly handled or threatens to =
overwhelm.</FONT>
<BR><FONT SIZE=3D2>&gt;</FONT>
<BR><FONT SIZE=3D2>&gt;Cheers,</FONT>
<BR><FONT SIZE=3D2>&gt;</FONT>
<BR><FONT SIZE=3D2>&gt;Ed Gerck</FONT>
<BR><FONT SIZE=3D2>&gt;</FONT>
<BR><FONT SIZE=3D2>&gt;</FONT>
<BR><FONT SIZE=3D2>&gt;</FONT>
<BR><FONT SIZE=3D2>&gt;</FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01BEF3BD.DA297F56--


Received: from ext-mail.valicert.com (ns1.valicert.com [63.65.221.10]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id GAA24903 for <[e-mail]>; Tue, 31 Aug 1999 06:51:11 -0700 (PDT)
Received: from int-mail.valicert.com (corporate-gw.valicert.com [63.65.221.2]) by ext-mail.valicert.com (8.9.3/8.9.3) with ESMTP id GAA16402; Tue, 31 Aug 1999 06:53:19 -0700 (PDT)
Received: from rsalaptop (1Cust166.tnt5.sfo1.da.uu.net [208.250.194.166]) by int-mail.valicert.com (8.9.3/8.9.3) with SMTP id GAA29737; Tue, 31 Aug 1999 06:53:15 -0700 (PDT)
From: "Peter Williams" <[e-mail]>
To: "Alan Lloyd" <[e-mail]>
Cc: <[e-mail]>
Subject: RE: SCVP-01
Date: Tue, 31 Aug 1999 06:54:30 -0700
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
In-Reply-To: <D1A949D4508DD1119C8100400533BEDC107847@DSG1>
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300

Speaking as an security engineer, reading the communities
SCVP review material:

(a) SCVP is an example of a server-side processing; there
have been objections to that idea, per se, in PKIX,
on telco and moore's law grounds, and on the grounds
that cheap/simple devices are soon to be no more.

(b) SCVP is involved with cert policy handling, and the
remote handling of policy has been been objected to.

(c) SCVP is involved in path construction, per relying-party,
and the directory-manufacturers (Novell, for one) seem to
envisage problems building Internet-scale solutions.

(d) SCVP is mainly an information object specification,
and should be reusable in alternative application contexts
(e.g. LDAP, and DCS).

(e) some have suggested that we confuse the semantics
of OCSP (delivery of status of the certificate record
in the certificate management repository), with
SCVP's delivery of validity status of a given chain.


I was disappointed in the Microsoft message: other
parties in Microsoft are more properly supporting
delegation of policy handling to policy servers. There
is an IETF WG dedicated to the framework for delegation, and
SCVP should be seen as consistent with that general
effort, in relation to its behavior of enabling
a server to handle the relying-parties automated
policy decisions concerning path construction, and
path processing.

I was disappointed by the Novell message: I would have
expected directory folk to leap at the chance to have
servers, or remote clients gatewaying SVCP to
LDAP(s), engage in searching out certificate paths between
two nodes in a DIT. SCVP is not intended to
be a directory protocol. But, the required directory
need not be a enterprise-class solution: SCVP implementations
may exploit scalable multicast conferencing directories,
or secure-DNS, and just avoid client/server designs.

Carlisle's ambiguous message should be dealt with by
the reference to IETF Policy WG. Delegated processing
to policy servers is something which many customers/vendors
are requesting. This is particularly true at
the IPSEC level. There is a long tradition of using
third-party servers to manage bilateral security contexts
in the layer 3 world.

DCS. There was consideration of using DCS as the vehicle
by which to introduce validation checking into PKIX: we
were halted in our tracks when the authors required things be
tied to the ISO NR framework.  Sensibly, Ambarish heeded the
simplicity goal, and chose not to be tied to a heavy-weight
concept.  We can recall, that DCS extension can
easily wrap the SCVP ASN.1 info object and thereby incorporate
the standard validation protocol into DCS, for the NR-grade
certificate handling. Presumably, the NR requirements
will add to SCVP requirements for remote path processing,
as to-be-specified in the DCS draft.

OCSP: the status of a certificate record in a repository
is the certificate issuer's very narrow view on the world.
SCVP looks at the relying-parties view, and asks the question,
"for a path of my choosing, and policy constraints
of my selection, is the user certificate valid in that
context, and the context of previous transaction knowledge
available to the policy/validation server?". Confusing
cert status with path validity will get us nowhere; the
whole point is to separate these, so that relying-party control of security
context formation is obtained, removing mandatory issuer-based controls and
consequential over-dependence on
critical status servers.

Offline Processing by simple clients: there is a spectrum
of router equipment; from that with 0 persistent memory,
cheaper models which can perhaps store a small db of trusted keys on a 40M
PCMCIA drive, to high-end stuff. Clients must be
able to form contexts in the absence of policy/SCVP servers,
when they can at least rely on previous chain validation,
as stored in the trusted key cache.  Details for this
design were specified in PEM; its nothing new. Noone
is suggesting that SCVP server has to be pinged each and
every time a security decision is required, unless the client
is  really dumb agent of the highly-controlling CA (Blacker/Caneware like),
or memoryless.

Policy WG, and reuse: I would like to see the SCVP
specification take component form, enabling its
object to be reused in the extension mechanisms of other
suitable value-adding services, including CMP and DCS. Once
this is achieved, Id like to see the ability of PKIX-LDAP
store the SVCP result as an attribute, to instrument
the write-through caching; but more on this later,
perhaps.

Peter.

> -----Original Message-----
> From: Alan Lloyd [mailto:[e-mail]]
> Sent: Tuesday, August 31, 1999 12:21 AM
> To: 'Ambarish Malpani'; 'Salz, Rich'
> Cc: [e-mail]
> Subject: RE: SCVP-01
>
>
> 	snip
> > Yes, we could put in a bunch of changes in OCSP to make it
> > work, but you would end up changing the semantics of a large
> > part of OCSP.
> >
> 	its best to add a few features to a trusted transport that
> serves a common operational function (cert status and validation) than
> reinvent the whole box and dice again - re key management, protocol hddr
> formats, routing references, etc, etc - and also introduce compatibility
> and interoperability when both technologies are used in the same
> operational system.
>
> 	One only has to think of the customer and what they want...
> simpler systems, less code changes, less protocols, less databases and
> less configuration and more capability and trust  -  to see what the
> logical answer is..
>
> 	Why does OCSP and LDAP have extensions... Its not so we can
> ignore them and produce another YAP with optional extensions. that wont
> be used...
>
> 	Just my own views - but I do see a lot of customers and
> operational systems :-)
>
> 	regards alan
>



Received: from dsg1.OpenDirectory.com.au ([203.108.249.145]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id AAA19136 for <[e-mail]>; Tue, 31 Aug 1999 00:19:36 -0700 (PDT)
Received: by DSG1 with Internet Mail Service (5.0.1458.49) id <R6XH216S>; Tue, 31 Aug 1999 17:21:23 +1000
Message-ID: <D1A949D4508DD1119C8100400533BEDC107847@DSG1>
From: Alan Lloyd <[e-mail]>
To: "'Ambarish Malpani'" <[e-mail]>, "'Salz, Rich'" <[e-mail]>
Cc: [e-mail]
Subject: RE: SCVP-01
Date: Tue, 31 Aug 1999 17:21:23 +1000
X-Priority: 3
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.0.1458.49)
Content-Type: text/plain

	snip
> Yes, we could put in a bunch of changes in OCSP to make it
> work, but you would end up changing the semantics of a large
> part of OCSP.
> 
	its best to add a few features to a trusted transport that
serves a common operational function (cert status and validation) than
reinvent the whole box and dice again - re key management, protocol hddr
formats, routing references, etc, etc - and also introduce compatibility
and interoperability when both technologies are used in the same
operational system. 

	One only has to think of the customer and what they want...
simpler systems, less code changes, less protocols, less databases and
less configuration and more capability and trust  -  to see what the
logical answer is..

	Why does OCSP and LDAP have extensions... Its not so we can
ignore them and produce another YAP with optional extensions. that wont
be used...

	Just my own views - but I do see a lot of customers and
operational systems :-)

	regards alan



Received: from mail.fisc.com.tw (mail.fisc.com.tw [203.66.154.1]) by mail.proper.com (8.9.3/8.9.3) with SMTP id UAA17267 for <[e-mail]>; Mon, 30 Aug 1999 20:34:13 -0700 (PDT)
From: [e-mail]
Received: by mail.fisc.com.tw(Lotus SMTP MTA v4.6.2  (693.3 8-11-1998))  id 482567DE.0013CC1A ; Tue, 31 Aug 1999 11:36:14 +0800
X-Lotus-FromDomain: FISC
To: [e-mail]
Message-ID: <[e-mail]>
Date: Tue, 31 Aug 1999 11:35:11 +0800
Subject: Comments on RFC 2459
Mime-Version: 1.0
Content-type: text/plain; charset=us-ascii
Content-Disposition: inline

I have some comments on sec 4.2.1.2 of the rfc 2459.

It says to facilitate chain building, the subject key identifier extenion
must appear in all conforming CA certificates. In fact, it is not always
true. If the CA issuers the certificates, and use the authorityCertIssuer +

authorityCertIssuerSerialNumber as these cetificates' authority key
identifier extenion, then the CA certificte need not include the subject
key identifier, because the information is included in its basic
certificate
fields.

I think the subject key identifier must be included in CA certificate only
if the CA issuers the certificates, and use keyIdentifier as these
cetificates'
authority key identifier extenion.

Regards

Wei-Ching Su

Senior Engineer
FISC (Financial Information Service Co., LTD.)
Taipei, Taiwan





Received: from poptop.llnl.gov (poptop.llnl.gov [128.115.18.65]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id RAA12863 for <[e-mail]>; Mon, 30 Aug 1999 17:50:56 -0700 (PDT)
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 RAA11397; Mon, 30 Aug 1999 17:52:42 -0700 (PDT)
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.3 (32)
Date: Mon, 30 Aug 1999 17:52:47 -0700
To: "Bob Jueneman" <[e-mail]>, <[e-mail]>
From: Tony Bartoletti <[e-mail]>
Subject: Re: Multi-national company listing issues
Cc: <[e-mail]>, <[e-mail]>, <[e-mail]>, <[e-mail]>, <[e-mail]>, <[e-mail]>, <[e-mail]>
In-Reply-To: <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"

All,

Just an observation:)  I get a strange sense of Deja Vu here.

As Paul Koning remarked, in the US at least, the designation
"C=US" means "The party in question paid ANSI the required fee,
so ANSI registered the entry under 'US'" (loosely paraphrased)."

So, if you want more specifics, consult ANSI's "RPS" (Registration
Practices Statement.)  OK, I'm making that part up, its a take-off
on "CPS", for those who don't get it otherwise :)

___tony___


At 05:27 PM 8/30/99 -0600, Bob Jueneman wrote:
>Ed,
>
>I used a conventional X.400 representational shorthand for 
>the attribute called "country"  I would always assume that 
>localization of any display code would translate that 
>appropriately, if that was felt to be necessary.
>
>Bob
>
>
>
>>>> Ed Gerck <[e-mail]> 08/27/99 11:01AM >>>
> Bob Jueneman <[e-mail]> wrote:
>
>> For example, is "C=" the country where the parent is located,
>> where the subsidiary is located, where the tiny field office is
>> located, where they are incorporated (think of a ship with
>> Liberian registry), etc., etc.?
>>
>> In the case of an individual user, is the country where he was
>> born (or adopted)? Where he is currently a citizen (what about
>> dual citizenship, stateless persons, and nomads)?  Where he
>> maintains a residence (or maybe a domicile)?  Where he works (I
>> assume some people work in one country and sleep in another,
>> every day)?
>
>Bob:
>
>What is the meaning of "C=string"?
>
>There are two ways to solve this. One, is to proceed with the hierarchical
>type structure as a taxonomy and provide all the possible ramifications --
>clearly, with very little chance of satisfying even just the majority of cases.
>The other way is to renounce the concept (wrong, anyway) of "denotational
>syntax", treat the hierarchical structure as an an ontology and consider all
>qualifiers from the syntactic point of view, as "names".  With this approach,
>the meaning of "C=string" is now clear:
>
>"C" and "string" are specified, and "C" stands in equivalence with "string"
>
>Here, "C" is a name -- a quite arbitrary designation that is simply formally
>defined and may (or not) have a mnemonic purpose or be expressed in
>a human language.  In other words, "C" is just a pointer, a handle in an
>hierarchical ontology (not in a taxonomy).  OTOH, "string" may be either
>a name or a record as usual, where records refer mainly to physical
>quantities (e.g., geographical data, network addresses, port numbers,
>service designations, company names, etc.) designated in a materially
>pre-defined form.  The  map and query methods of a database can then
>relate names to records in a variety of relationships according to local
>need, such as one-to-one, many-to-one, one-to-many or many-to-many.
>The database can also follow a variety of models such as hierarchical,
>network, relational, distributed hierarchical, etc.
>
>What is required to do this? Nothing, just renounce the taxonomy and
>employ the same hierarchical structure already in place in X.500 or
>LDAP or whatever is being used.  Even the same relational tables
>if a relational database model is followed.
>
>But, where is the meaning of "C" denoted?  Not, in "C" itself but in the
>trusted context -- where it is anyway defined.  For example, "C" is
>meaningless in German as an abbreviation for Country -- it is the trusted
>context which says so (but, with all the ambiguities you point out and
>which are basically irresolvable).
>
>The integration of different trusted contexts becomes then a problem,
>but one which I believe is being increasingly solved in database theory
>-- for example, with meta-directory approaches.
>
>Of course, denotational syntax also "works" one may say -- but only in a
>parochial environment where the trusted context is implicitly known.  Since
>we are past this stage in the Internet, the fact that syntax and semantics
>are independent variables can no longer be ignored and must be either
>properly handled or threatens to overwhelm.
>
>Cheers,
>
>Ed Gerck
>
>
>
>


Received: from prv-mail20.provo.novell.com (prv-mail20.provo.novell.com [137.65.82.195]) by mail.proper.com (8.9.3/8.9.3) with SMTP id QAA12213 for <[e-mail]>; Mon, 30 Aug 1999 16:31:29 -0700 (PDT)
Received: from INET-PRV-Message_Server by prv-mail20.provo.novell.com with Novell_GroupWise; Mon, 30 Aug 1999 17:27:21 -0600
Message-Id: <[e-mail]>
X-Mailer: Novell GroupWise 5.5.2
Date: Mon, 30 Aug 1999 17:27:14 -0600
From: "Bob Jueneman" <[e-mail]>
To: <[e-mail]>
Cc: <[e-mail]>, <[e-mail]>, <[e-mail]>, <[e-mail]>, <[e-mail]>, <[e-mail]>, <[e-mail]>
Subject: Re: Multi-national company listing issues
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 mail.proper.com id QAA12214

Ed,

I used a conventional X.400 representational shorthand for 
the attribute called "country"  I would always assume that 
localization of any display code would translate that 
appropriately, if that was felt to be necessary.

Bob



>>> Ed Gerck <[e-mail]> 08/27/99 11:01AM >>>
 Bob Jueneman <[e-mail]> wrote:

> For example, is "C=" the country where the parent is located,
> where the subsidiary is located, where the tiny field office is
> located, where they are incorporated (think of a ship with
> Liberian registry), etc., etc.?
>
> In the case of an individual user, is the country where he was
> born (or adopted)? Where he is currently a citizen (what about
> dual citizenship, stateless persons, and nomads)?  Where he
> maintains a residence (or maybe a domicile)?  Where he works (I
> assume some people work in one country and sleep in another,
> every day)?

Bob:

What is the meaning of "C=string"?

There are two ways to solve this. One, is to proceed with the hierarchical
type structure as a taxonomy and provide all the possible ramifications --
clearly, with very little chance of satisfying even just the majority of cases.
The other way is to renounce the concept (wrong, anyway) of "denotational
syntax", treat the hierarchical structure as an an ontology and consider all
qualifiers from the syntactic point of view, as "names".  With this approach,
the meaning of "C=string" is now clear:

"C" and "string" are specified, and "C" stands in equivalence with "string"

Here, "C" is a name -- a quite arbitrary designation that is simply formally
defined and may (or not) have a mnemonic purpose or be expressed in
a human language.  In other words, "C" is just a pointer, a handle in an
hierarchical ontology (not in a taxonomy).  OTOH, "string" may be either
a name or a record as usual, where records refer mainly to physical
quantities (e.g., geographical data, network addresses, port numbers,
service designations, company names, etc.) designated in a materially
pre-defined form.  The  map and query methods of a database can then
relate names to records in a variety of relationships according to local
need, such as one-to-one, many-to-one, one-to-many or many-to-many.
The database can also follow a variety of models such as hierarchical,
network, relational, distributed hierarchical, etc.

What is required to do this? Nothing, just renounce the taxonomy and
employ the same hierarchical structure already in place in X.500 or
LDAP or whatever is being used.  Even the same relational tables
if a relational database model is followed.

But, where is the meaning of "C" denoted?  Not, in "C" itself but in the
trusted context -- where it is anyway defined.  For example, "C" is
meaningless in German as an abbreviation for Country -- it is the trusted
context which says so (but, with all the ambiguities you point out and
which are basically irresolvable).

The integration of different trusted contexts becomes then a problem,
but one which I believe is being increasingly solved in database theory
-- for example, with meta-directory approaches.

Of course, denotational syntax also "works" one may say -- but only in a
parochial environment where the trusted context is implicitly known.  Since
we are past this stage in the Internet, the fact that syntax and semantics
are independent variables can no longer be ignored and must be either
properly handled or threatens to overwhelm.

Cheers,

Ed Gerck




Received: from mail.vpnc.org (mail.vpnc.org [165.227.249.9]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id NAA10320 for <[e-mail]>; Mon, 30 Aug 1999 13:39:02 -0700 (PDT)
Received: from aum (ip11.proper.com [165.227.249.11]) by mail.vpnc.org (8.9.3/8.9.0) with ESMTP id NAA06221; Mon, 30 Aug 1999 13:38:50 -0700 (PDT)
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58 
Date: Mon, 30 Aug 1999 13:40:26 -0700
To: "Salz, Rich" <[e-mail]>, "'Ambarish Malpani'" <[e-mail]>
From: Paul Hoffman / VPNC <[e-mail]>
Subject: RE: SCVP-01
Cc: [e-mail]
In-Reply-To: <[e-mail] rtco.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed

At 04:15 PM 8/30/1999 -0400, Salz, Rich wrote:
>Since this WG is based on the premise of using X509 certs, those VPN
>vendors that will never use certs (as opposed to waiting until things get
>"eaiser") are out of scope here.

Sorry for not being clearer in the previous message. All the vendors who 
don't use certs today *want to use certs*. There are no IPsec vendors that 
I know of that say "we never want to use certs". There are many who are 
saying "gee, um, we'll have that Real Soon Now".

>But the OCSP protocol doesn't need certs.  It needs a DN and two key hashes.
>Why not just define an OCSP critical extension that says "verify this cert,
>and verify up the chain as well."  The footprint for a dedicated DER parser
>that knew how to generate only those requests, and parse only well-formed
>replies, would be pretty small.
>
>Why won't that work?

As I've said earlier on this list, the OCSP protocol would have to be 
rewritten to allow this. The semantics in the protocol were purposely 
restricted not to do this. However, it is more than just rewriting OCSP and 
having it recycle at Proposed Standard. SCVP has many features in the 
request and response that give much more granularity than what you propose, 
as well as other features such as passing back the information needed by a 
client to validate.

If it's desired, we could eliminate some features from SCVP to make it 
simpler, possibly simple enough to fit inside an OCSP extension.

--Paul Hoffman, Director
--VPN Consortium


Received: from ext-mail.valicert.com (ns1.valicert.com [63.65.221.10]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id NAA10305 for <[e-mail]>; Mon, 30 Aug 1999 13:38:11 -0700 (PDT)
Received: from int-mail.valicert.com (corporate-gw.valicert.com [63.65.221.2]) by ext-mail.valicert.com (8.9.3/8.9.3) with ESMTP id NAA12586; Mon, 30 Aug 1999 13:40:11 -0700 (PDT)
Received: from rhone (rhone.valicert.com [192.168.3.128]) by int-mail.valicert.com (8.9.3/8.9.3) with SMTP id NAA15376; Mon, 30 Aug 1999 13:40:11 -0700 (PDT)
From: "Ambarish Malpani" <[e-mail]>
To: "'Salz, Rich'" <[e-mail]>
Cc: <[e-mail]>
Subject: RE: SCVP-01
Date: Mon, 30 Aug 1999 13:43:20 -0700
Message-ID: <008101bef328$4bf5e480$[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
Importance: Normal
In-Reply-To: <[e-mail]>

Hi Rich,
    The OCSP protocol needs a serial number and the hashes of
the issuer's DN and public key.

Anyway, to answer your bigger question: No, that wouldn't
work because OCSP does need you (the client) to form the chain
(since you need to include the hash of the CA's public
key with the request). If you can't create at least the
first link in the chain, you can't make the request.

If we took out the CA's public key from the request, you
open yourself up the the situation, where a client can't
uniquely identify the CA it is talking about (since 2 CA's
could have the same DN). Also, if the client doesn't have the
CA's public key, it can't verify the signature on the cert,
which leaves it open to a slew of other attacks.

Yes, we could put in a bunch of changes in OCSP to make it
work, but you would end up changing the semantics of a large
part of OCSP.

Hope this clarifies things.

Regards,
Ambarish

---------------------------------------------------------------------
Ambarish Malpani
Architect                                                650.567.5457
ValiCert, Inc.                                  [e-mail]
1215 Terra Bella Ave.                         http://www.valicert.com
Mountain View, CA 94043-1833


> -----Original Message-----
> From: Salz, Rich [mailto:[e-mail]]
> Sent: Monday, August 30, 1999 1:16 PM
> To: 'Paul Hoffman / VPNC'; 'Ambarish Malpani'
> Cc: [e-mail]
> Subject: RE: SCVP-01
> 
> 
> Since this WG is based on the premise of using X509 certs, those VPN
> vendors that will never use certs (as opposed to waiting 
> until things get
> "eaiser") are out of scope here.
> 
> But the OCSP protocol doesn't need certs.  It needs a DN and 
> two key hashes.
> Why not just define an OCSP critical extension that says 
> "verify this cert,
> and verify up the chain as well."  The footprint for a 
> dedicated DER parser
> that knew how to generate only those requests, and parse only 
> well-formed
> replies, would be pretty small.
> 
> Why won't that work?
> 


Received: from fwma1.certco.com (fwma1.certco.com [208.222.33.4]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id NAA09915 for <[e-mail]>; Mon, 30 Aug 1999 13:14:44 -0700 (PDT)
Received: from haggis.ma.certco.com (haggis.ma.certco.com [10.200.200.20]) by fwma1.certco.com (Postfix) with ESMTP id 1496A15534; Mon, 30 Aug 1999 16:16:12 -0400 (EDT)
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 2C58E7C0A0; Mon, 30 Aug 1999 16:16:11 -0400 (EDT)
Received: by macertco-srv1.ma.certco.com with Internet Mail Service (5.5.2232.9) id <R69HSRPZ>; Mon, 30 Aug 1999 16:15:44 -0400
Message-ID: <[e-mail]>
From: "Salz, Rich" <[e-mail]>
To: "'Paul Hoffman / VPNC'" <[e-mail]>, "'Ambarish Malpani'" <[e-mail]>
Cc: [e-mail]
Subject: RE: SCVP-01
Date: Mon, 30 Aug 1999 16:15:42 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2232.9)
Content-Type: text/plain; charset="iso-8859-1"

Since this WG is based on the premise of using X509 certs, those VPN
vendors that will never use certs (as opposed to waiting until things get
"eaiser") are out of scope here.

But the OCSP protocol doesn't need certs.  It needs a DN and two key hashes.
Why not just define an OCSP critical extension that says "verify this cert,
and verify up the chain as well."  The footprint for a dedicated DER parser
that knew how to generate only those requests, and parse only well-formed
replies, would be pretty small.

Why won't that work?


Received: from Newman.GSC.GTE.Com ([e-mail] [207.175.88.67]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id MAA08937 for <[e-mail]>; Mon, 30 Aug 1999 12:22:47 -0700 (PDT)
Received: from gscex01.gsc.gte.com ("port 2475"@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, 30 Aug 1999 15:24:35 -0400 (EDT)
Received: by gscex01.ndhm.gsc.gte.com with Internet Mail Service (5.5.2448.0) id <QJJBVXMS>; Mon, 30 Aug 1999 15:24:31 -0400
Content-return: allowed
Date: Mon, 30 Aug 1999 15:24:30 -0400
From: "Sweigert, David" <[e-mail]>
Subject: RE: Multi-national company listing issues
To: Robert Moskowitz <[e-mail]>, Paul Koning <[e-mail]>, [e-mail]
Cc: [e-mail], [e-mail], [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"

Thanks for the response.

Extremely helpful.

Dave

-----Original Message-----
From: Robert Moskowitz [mailto:[e-mail]]
Sent: Friday, August 27, 1999 11:02 AM
To: Paul Koning; [e-mail]
Cc: [e-mail]; Sweigert, David; [e-mail];
[e-mail]; [e-mail]
Subject: Re: Multi-national company listing issues


At 10:48 AM 8/27/1999 -0400, Paul Koning wrote:
>
>If you want to obtain an NSAP address block (for ATM for example) one
>easy way is to get it under the DCC (Data Country Code) branch of the
>NSAP space.  Those are administered by national bodies in various
>countries; in the USA that is ANSI.
>
>ANSI will assign a block under its DCC code to anyone who hands over
>the $1000.  The fact that your entry appears under the code that
>represents "USA" means simply that the assignment was made by the USA
>registrar.  It has NO other meaning.  In particular, it doesn't mean
>*any* of the things you suggested above.  (I suppose another way to
>put it is "it's totally useless"...)
>
This is what GM supposedly did, according to my friend, but he quoted a
$1200 fee.  Maybe it came down.  GM basically ignores everything about
o=GeneralMotors.


Robert Moskowitz
ICSA
Security Interest EMail: [e-mail]


Received: from proxy3.ba.best.com ([e-mail] [206.184.139.14]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id KAA07230 for <[e-mail]>; Mon, 30 Aug 1999 10:42:30 -0700 (PDT)
Received: from [207.21.138.187] (oak-alg-gw3-60.ncal.verio.com [207.21.138.187]) by proxy3.ba.best.com (8.9.3/8.9.2/best.out) with ESMTP id KAA20218 for <[e-mail]>; Mon, 30 Aug 1999 10:43:57 -0700 (PDT)
Message-Id: <[e-mail]>
X-Mailer: Microsoft Outlook Express for Macintosh - 4.0c (197) 
Date: Mon, 30 Aug 1999 10:45:40 -0700
Subject: COMMERCIAL: Internet Security Conference
From: "Bill Gram-Reefer" <[e-mail]>
To: [e-mail]
Mime-version: 1.0
X-Priority: 3
Content-type: text/plain; charset="ISO-8859-1"
Content-transfer-encoding: 7bit

Please be advised registration is now open for The Internet Security
Conference (TISC) to be held in Boston, October 11-15. Please see
http://tisc.corecom.com for more detail.


Received: from mail.vpnc.org (mail.vpnc.org [165.227.249.9]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id JAA06427 for <[e-mail]>; Mon, 30 Aug 1999 09:46:29 -0700 (PDT)
Received: from aum (ip11.proper.com [165.227.249.11]) by mail.vpnc.org (8.9.3/8.9.0) with ESMTP id JAA05654; Mon, 30 Aug 1999 09:45:56 -0700 (PDT)
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58 
Date: Mon, 30 Aug 1999 09:47:42 -0700
To: Carlisle Adams <[e-mail]>, "'Ambarish Malpani'" <[e-mail]>
From: Paul Hoffman / VPNC <[e-mail]>
Subject: RE: SCVP-01
Cc: [e-mail], [e-mail]
In-Reply-To: <[e-mail] .com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed

At 12:12 PM 8/30/1999 -0400, Carlisle Adams wrote:
>Not exactly what we were all looking for (i.e., "concrete details regarding
>who does need this").  I understand that you may not be at liberty to share
>any specific names, but even some generalities might help.

Oh, good, that's the easy part. :-)

>   For example,
>what you've said above ("people who want to use public key cryptography
>without the overhead of understanding all of PKIX") suggests that for the
>people you've spoken with this is an understanding or complexity issue,
>rather than a footprint issue.  Is that true, or is it both, or are there
>other motivators as well?

I'll speak for my interest in helping to start the SCVP work wearing my 
VPNC hat. In speaking to VPN vendors, I heard two things that bothered me:

- some still don't handle certs at all because PKIX is too difficult

- of those that do handle certs, some do it very poorly (this can be easily 
shown in the interop testing in the VPN world)

Both groups want an easier way to handle certs. Clearly, anyone who can 
write an IPsec implementation can probably also write a PKIX 
implementation, but they don't want to waste the resources to learn the 
intricacies of path validation (and the well-known divergences from 2459 in 
the real world) and to write code for it. Thus, to use your phrase, it is 
both an understanding and complexity issue.

>I initially had the impression that the driver was very constrained devices;

It could be for that as well, but that is by no means its only target 
market. We've been saying that over and over, and thought we had made that 
clearer in the -01 draft than in the -00 draft.

>now I'm wondering if a more accurate picture is that the devices are
>sufficiently powerful but those doing implementations don't really want to
>understand all of PKIX.

"want to" or need to. And, there is still the two other main areas where 
SCVP could be useful:

- An organization that wants to centralize validation policy can require 
that all clients use SVCP and a particular server, and then put the policy 
on that one server. The only other option for such an organization is to 
only use clients that have configurable policy in the clients' validation 
stack; you can easily guess how few clients meet that criteria.

- To aid clients in collecting validation information. The concept of "just 
use LDAP to get the certs in the chain" assumes both that this will work, 
and that using successive LDAP queries is efficient for long chains. 
Neither assumption may be true. A single call to a server that spends its 
time looking to fill in interesting chains and making sure that the certs 
that it caches are up-to-date, well-formed, and (by the way) not revoked 
seems like a better way to do things even for very able clients.

>You're right; no argument here.  However, this does not necessarily make
>SCVP the right answer, since (as Mary-Ellen has pointed out) a
>sufficiently-powerful library with a sufficiently-simple API brings the same
>benefit.

I agree. If we believe that such a library will be generally available, 
correct, and configurable, then an external protocol won't be needed. I'm 
not sure we can assume that (or, to be fair, that the work we put into 
making the protocol will be worth the effort if such libraries proliferate).

--Paul Hoffman, Director
--VPN Consortium


Received: from gatekeeper.entrust.com (gatekeeper.entrust.com [204.101.128.170]) by mail.proper.com (8.9.3/8.9.3) with SMTP id JAA06020 for <[e-mail]>; Mon, 30 Aug 1999 09:12:31 -0700 (PDT)
Received: 	id MAA11423; Mon, 30 Aug 1999 12:10:01 -0400
Received: by gateway id <NP65M54X>; Mon, 30 Aug 1999 12:12:38 -0400
Message-ID: <[e-mail]>
From: Carlisle Adams <[e-mail]>
To: "'Ambarish Malpani'" <[e-mail]>
Cc: [e-mail], [e-mail]
Subject: RE: SCVP-01
Date: Mon, 30 Aug 1999 12:12:35 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2448.0)
Content-Type: text/plain

Hi Ambarish,

> > 
> > While I believe they exist, my impression is that we're still 
> > waiting to
> > hear from this "particular set of users" to confirm that the 
> > functionality
> > embodied in SCVP is a legitimate requirement.  Don's "group" 
> > has stated that
> > they don't need this (at least at the moment).  Do we have 
> > concrete details
> > regarding who does need this?
> 
> I have had conversations with people who are interested in this.
> Also, we have had quite a few of our customers use our tookit
> to do OCSP, but really wanted SCVP-like functionality. Yes, there
> are such people, unfortunately, most of them do not read the
> PKIX list - they belong to my first group of users - people
> who want to user public key cryptography without the overhead
> of understanding all of PKIX.
 
Not exactly what we were all looking for (i.e., "concrete details regarding
who does need this").  I understand that you may not be at liberty to share
any specific names, but even some generalities might help.  For example,
what you've said above ("people who want to use public key cryptography
without the overhead of understanding all of PKIX") suggests that for the
people you've spoken with this is an understanding or complexity issue,
rather than a footprint issue.  Is that true, or is it both, or are there
other motivators as well?

I initially had the impression that the driver was very constrained devices;
now I'm wondering if a more accurate picture is that the devices are
sufficiently powerful but those doing implementations don't really want to
understand all of PKIX.

In any case, a better understanding of the real requirements would be
helpful.

> The "on the other hand" case
> you are talking about is right on - yes, I am talking about
> a cert processing policy, that needs to be implemented (correctly)
> on every client desktop - SCVP. However, I am relatively sure
> you won't argue that correctly implementing SCVP is quite a
> bit easier than correctly implementing PKIX Part 1(2459),
> LDAP Op Protocol (2559), OCSP (2560), LDAP Schema for PKIX(2587),
> LDAP (1777), ...
 
You're right; no argument here.  However, this does not necessarily make
SCVP the right answer, since (as Mary-Ellen has pointed out) a
sufficiently-powerful library with a sufficiently-simple API brings the same
benefit.

Carlisle.



Received: from gatekeeper.entrust.com (gatekeeper.entrust.com [204.101.128.170]) by mail.proper.com (8.9.3/8.9.3) with SMTP id IAA05698 for <[e-mail]>; Mon, 30 Aug 1999 08:53:02 -0700 (PDT)
Received: 	id LAA01621; Mon, 30 Aug 1999 11:50:18 -0400
Received: by gateway id <NP65M5PD>; Mon, 30 Aug 1999 11:52:55 -0400
Message-ID: <[e-mail]>
From: Carlisle Adams <[e-mail]>
To: "'[e-mail]'" <[e-mail]>, Ambarish Malpani <[e-mail]>, "'Ron Ramsay'" <[e-mail]>
Cc: [e-mail]
Subject: RE: apologies and comments on SCVP
Date: Mon, 30 Aug 1999 11:52:49 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2448.0)
Content-Type: text/plain

Hi Ron,

> ----------
> From: 	Ron Ramsay[SMTP:[e-mail]]
> Sent: 	Sunday, August 29, 1999 9:15 PM
> To: 	'[e-mail]'; Ambarish Malpani
> Cc: 	[e-mail]
> Subject: 	RE: apologies and comments on SCVP
> 
> But a library will require that each client collect CRLs, that each
> client be configured with the business/trust rules, etc. This sounds
> like a significant systems administration problem.
 
Not if the library does all this.  Then the only question is whether the
client acquires this functionality via a protocol or via a library with an
API (note that the library may achieve this essentially by itself or by a
protocol exchange with an SCVP server; this is invisible to the client).

Either mechanism (protocol or API) removes the complexity from the client,
so this is not the basis for the choice.  It may be argued that a library
requires a larger footprint than a protocol engine, but even this is not
necessarily true (since, as mentioned above, the library may perform the
validation by using a protocol to an external server), so this cannot be the
basis for the choice.

Ultimately, what it comes down to (it seems to me) is how many "things"
(applications, operating system, other protocol engines, etc.) on the client
platform need this functionality.  If the answer is "more than one", then
the library/API is probably a better architectural model than having each of
these "things" implement its own protocol engine for validation.  A single
library called by all these "things" is likely to be a smaller footprint
overall than multiple instances of a validation protocol.  If, on the other
hand, the answer is "one" (i.e., a totally dedicated, single-use device)
then it probably makes little difference, although the straight protocol
would have a slightly smaller code size than the protocol with an API
wrapper and might be preferable...

Carlisle.

> > -----Original Message-----
> > From:	[e-mail] [SMTP:[e-mail]]
> > Sent:	Friday, August 27, 1999 9:55 PM
> > To:	Ambarish Malpani
> > Cc:	[e-mail]
> > Subject:	RE: apologies and comments on SCVP
> > 
> > Hi Ambarish,
> > 
> > > ClientType1 basically wants to be able to use public key
> > > cryptography (and the PKIX infrastructure), without needing to
> > > understand all of PKIX part1, OCSP, LDAP etc. It is outsourcing
> > > the task of checking cert status, cert expiry, policy management
> > > etc to the SCVP server. The main question ClientType1 is asking
> > > is: "Hey, I got this cert, can I use it for application X?".
> > > The minimal response the server needs to provide is a signed
> > > yes/no. If you throw away all the extra stuff, you essentially
> > > have the client sending in a cert and getting back a yes/no
> > > answer.
> > 
> > Why is the best answer to this need a protocol instead of a library?
> > It
> > seems if this is a technical need, you could craft a nice library with
> > simple APIs to do this.
> >      Mez
> 


Received: from mail-out2.apple.com (mail-out2.apple.com [17.254.0.51]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id IAA05549 for <[e-mail]>; Mon, 30 Aug 1999 08:51:17 -0700 (PDT)
Received: from mailgate1.apple.com (A17-128-100-225.apple.com [17.128.100.225]) by mail-out2.apple.com (8.8.5/8.8.5) with ESMTP id IAA22014 for <[e-mail]>; Mon, 30 Aug 1999 08:53:19 -0700
Received: from scv1.apple.com (scv1.apple.com) by mailgate1.apple.com (mailgate1.apple.com- SMTPRS 2.0.15) with ESMTP id <[e-mail]> for <[e-mail]>; Mon, 30 Aug 1999 08:53:12 -0700
Received: from [17.219.25.199] ([17.219.25.199]) by scv1.apple.com (8.9.3/8.9.3) with ESMTP id IAA27891 for <[e-mail]>; Mon, 30 Aug 1999 08:53:11 -0700 (PDT)
Message-Id: <[e-mail]>
X-Mailer: Microsoft Outlook Express Macintosh Edition - 4.5 (0410)
Date: Mon, 30 Aug 1999 08:53:08 -0700
Subject: Re: Deprecate the NR bit?
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

Ron Ramsay wrote:

> Except that the NR bit cannot be added to the certificate by the
> application!

But the application can add a much better indicator to the data that needs
to be part of the evidence that supports non-repudiation as has been
proposed on this mailing list.

[snip]

Regards,
Aram Perez


Received: from dfw7-1.relay.mail.uu.net (dfw7-1.relay.mail.uu.net [199.171.54.106]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id GAA04041 for <[e-mail]>; Mon, 30 Aug 1999 06:36:32 -0700 (PDT)
Received: from xedia.com by dfw7sosrv11.alter.net with SMTP  (peer crosschecked as: madway.xedia.com [198.202.232.199]) id QQhemw04665; Mon, 30 Aug 1999 13:38:24 GMT
Received: from tonga.xedia.com by xedia.com (4.1/SMI-4.1) id AA02936; Mon, 30 Aug 99 09:36:49 EDT
Received: by tonga.xedia.com (SMI-8.6/SMI-SVR4) id JAA01873; Mon, 30 Aug 1999 09:38:22 -0400
Date: Mon, 30 Aug 1999 09:38:22 -0400
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: Deprecate the NR bit?
References: <D1A949D4508DD1119C8100400533BEDC151950@DSG1>
X-Mailer: VM 6.34 under 20.3 "Vatican City" XEmacs  Lucid

>>>>> "Ron" == Ron Ramsay <[e-mail]> writes:

 Ron> Except that the NR bit cannot be added to the certificate by the
 Ron> application!

When I said "put it in the application" that also meant "put it in the 
application protocol",  i.e., not in the cert.

	paul


Received: from popmail.inbox.se (popmail.inbox.se [193.12.72.101]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id FAA03311 for <[e-mail]>; Mon, 30 Aug 1999 05:27:34 -0700 (PDT)
Received: from stefan2 (accurata.inbox.se [193.12.72.24]) by popmail.inbox.se (8.9.3/8.9.3) with SMTP id OAA02165; Mon, 30 Aug 1999 14:29:28 +0200
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 
Date: Mon, 30 Aug 1999 14:29:47 +0200
To: [e-mail], "[e-mail]"@popmail.inbox.se, [e-mail]
From: Stefan Santesson <[e-mail]>
Subject: Re: Pseudonym in Subject DN (in QC certificates)
Cc: [e-mail], Hans Nilsson<[e-mail]>, [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 mail.proper.com id FAA03312

Bob,

Inclusion of new attributes are always a delicate matter that needs to be
handled with care. But I believe that in this case we have crossed the line
where it can be a legitimate step.

The fact is that in order to meet the EU-directive, we have to deal with
inclusion of pseudonym in the subject field.

Using the commonName attribute imposes weakness in the structure by
stretching current definitions. With the support from RSA and many
representative vendors in Europe I think we should do the step and include
the pseudonym attribute. I think we have the backup to get necessary
support for this move.

Of course this will effect implementations, but implementers of this
specification must be aware of this and act accordingly when they are
working with pseudonym names.

/Stefan

At 07:00 PM 8/26/99 -0600, [e-mail] wrote:
>Stefan,
>
>I haven't commented on the proposed pseudonym attribute, having 
>been busy trying to wrestle the "NR" alligator.
>
>But I believe that defining a single attribute for pseudonym would be 
>WRONG. Instead, I believe that we need a continuum of certificate 
>classes that range from a complete pseudonym (the subscriber was 
>wearing gloves when he pulled the handle on the certificate vending 
>machine, to avoid leaving fingerprints), all the way up to a certificate 
>that is issued as an act of state by a sovereign government, plus
>everything in between.
>
>Once you define an attribute for a pseudonym, then when someone 
>comes along and needs to identify an individual whose identity is 
>known by the CA but not disclosed in the certificate, or by a 
>publicly-held and audited corporation, or a Licensed CA, or 
>a State or Province, etc., etc., then the temptation will be to 
>define yet another attribute.  This way lies madness, not to mention
>a complete lack of interoperability.
>
>I really believe that a somewhat sparsely populated list of certificate 
>classes that identify the amount of due diligence that is invested into
>the identity of the subscriber is a better way to go. Please see Appendix 
>D, page 57, of our Novell Security Attributes document, available
>at http://developer.novell.com/repository/attributes/certattrs_)v10.htm 
>for more details and a reasonably well worked out list of such classes.
>I would, of course, be happy to entertain suggestions for revisions and 
>additions to that list.
>
>Bob
>
>
>>>> Stefan Santesson <[e-mail]> 08/26/99 07:41AM >>>
>Regarding new attributes in the subject field in Qualified Certificates.
>
>I've had several off list discussions regarding the pseudonym attribute in
>the subject field of QC.
>
>Everybody except one has been in favour of adding this attribute in the
>subject field.
>
>Pros are:
>- Makes it easier to meet the EU directive directly by using just the
>subject field without bending current X.509 definitions.
>- Clearly defines when a name is based on a pseudonym
>- RSA has offered to include this (and other PersonalData) attributes in
PKCS#9
>
>Cons are:
>- Will require definition of new object classes for directory systems when
>this attribute is used.
>
>The cons are more and more fading away. Magnus Nyström at RSA wrote to me:
>
>"Well, yes, one have to include this new attribute in the definition of a 
> new object class, or extend the definition of an existing class if one
> would like this to work well. But that was also my original intention - to
> include them in the 'pkcsEntity' auxiliary object class that is being
> defined in PKCS #9. Further, most directory products does support changes
> to the schema, and there are already several proposals being made in
> this area, e.g.:
>
> -Netscape's draft about "inetOrgPerson", published as
>  'draft-smith-ldap-inetorgperson-03.txt'; and
> -Chadwick's draft regarding ldapv3 and PKIX
>  (draft-ietf-pkix-ldap-v3-01.txt) which incorporates the 'pmiUser' object
>  class which I doubt many directory products have built-in support for
>  today.
> -RSA Laboratories "pkcsEntity" auxiliary object class, being defined in
>  PKCS #9 v.2."
>
>Taking this into consideration I think that we should go forward and
>include the pseudonym attribute.
>This will force us to expand the set of supported attributes compared to
>RFC 2459 and also to add matching rules for this attribute. we will also
>have to remove the option to allow a pseudonym to be stored in the
>commonName attribute and instead say that this attribute SHALL be used to
>store the subjects registered name in a preferred presentation format.
>Nicknames and spelling other than the registered names are allowed as long
>as they are related to the persons registered name.
>
>Another consideration is to add the title attribute as a role attribute
>since role has repeatedly become an issue within these types of
>certificates. The text should declare that when this attribute is present
>it SHALL define a role of the subject. I believe that this is consistent
>with the attribute definition in X.520. This attribute is further already
>on the list of supported attributes in RFC 2459.
>
>Finally we should assign an OID to be optionally included in the
>qcStatements extension, which declare that a certificate is compliant with
>syntax and semantics definitions of this specification. Otherwise there
>will be no way for a relying party to tell whether the certificate is
>compliant with these definitions other than by understanding present policy
>OID:s.
>
>So if no serious objections are raised, I would like to go forward and
>update the specification according to this proposal.
>
>/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
>-------------------------------------------------------------------
>

-------------------------------------------------------------------
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 mail.proper.com (8.9.3/8.9.3) with ESMTP id BAA28802 for <[e-mail]>; Mon, 30 Aug 1999 01:21:35 -0700 (PDT)
Received: from stefan2 (accurata.inbox.se [193.12.72.24]) by popmail.inbox.se (8.9.3/8.9.3) with SMTP id KAA30621; Mon, 30 Aug 1999 10:23:24 +0200
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 
Date: Mon, 30 Aug 1999 10:23:43 +0200
To: Paul Koning <[e-mail]>, [e-mail]
From: Stefan Santesson <[e-mail]>
Subject: RE: Deprecate the NR bit?
Cc: [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 mail.proper.com id BAA28803

Paul,

X.509 (and thus also RFC 2459) does define semantics for the NR bit, up to
a certain point.

X.509 Annex B, section B1 defines the service non-repudiation as:
"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."

As RFC 2459 is a profile of X.509, this definition applies to RFC 2459 as well.

Now, this level of definition is not sufficient for all higher level
contexts but that doesn't make it useless. It just means that the full
semantics of this bit (service) must be combined with some policy
definitions (implicit or explicit). It still work fine as a switch saying
that 1)the basic definition above and 2)these higher level policy
definitions, apply to this cert.

And actually this is also the case with other key-usage bits as well as
other parts of X.509 certificates.

So what I mean is that PKIX should not go into more detail than what X.509
already does. In fact, doing so would be incompatible with X.509, and that
would be to go against the PKIX charter.

/Stefan

At 01:43 PM 8/27/99 -0400, Paul Koning wrote:
>Let me see if I understand this.
>
>Stefan says that PKIX can't, and shouldn't try to, provide a common
>understanding of what NR is.  
>
>Stefan and John both say that the semantics of the NR bit aren't
>defined in PKIX, they are defined by what lives above and vary
>depending on what lives above.
>
>And David says that they have semantics for the bit but they are
>different. 
>
>So in summary, PKIX can define the bit but it can't define what it
>means, and if you ask what it means you will get either no answer or a 
>variable answer.
>
>That does suggest to me the bit doesn't belong here.  Let it go into
>the applications that have a defined semantic, with a name appropriate 
>for its meaning, and a definition of its meaning.
>
>	paul
>
>>>>>> "Fillingham," == Fillingham, David W <[e-mail]> writes:
>
> Fillingham,> I agree with John and Stefan that the NR bit not be
> Fillingham,> deprecated, for the reasons they indicate, and because
> Fillingham,> the current draft DoD Certificate Policy has slightly
> Fillingham,> different requirements for certificate generation and
> Fillingham,> management for digital signature certificates that do or
> Fillingham,> do not assert the non-repudiation key usage bit.
>
> >> ---------- From: Linn, John[SMTP:[e-mail]] Sent:
> >> Friday, August 27, 1999 12:38 PM To: 'Stefan Santesson' Cc:
> >> '[e-mail]' Subject: RE: Deprecate the NR bit?
> >> 
> >> I agree with Stefan.  While an NR bit is appropriately sourced
> >> within a PKIX infrastructure (representing, in a protected manner,
> >> an assertion by an issuing CA), it's primarily consumed above the
> >> infrastructure.  Its consumption and semantics will depend on
> >> operational environments and their policies.
> >> 
> >> Consensus hasn't yet become apparent on identifying all of the
> >> characteristics which PKI-supported NR services might possess, or
> >> in organizing those characteristics into an ordering. 
>
>> From: Stefan Santesson [mailto:[e-mail]]
>>
>> I must admit that I have not followed everything said
>> regarding the NR-bit
>> on this list, but I'm not surprised that PKIX can't provide a common
>> understanding on what NR is in detail.
>>
>> In fact I don't think PKIX should even try to do that, other
>> than in the
>> very general context that has already been done in RFC 2459.
>>
>> This does not mean that the bit is useless and should be
>> deprecated. The NR
>> bit belongs in a much wider context totally above the PKIX
>> level. The fact
>> is also that the NR-bit is used in many higher level context
>> with success.
>> If you would deprecate the bit you would force them to be
>> non-compliant to
>> PKIX.
>>
>> It is up to higher level of system design to provide the
>> exact semantics of
>> this bit, presumably in combination with some defined
>> electronic signature
>> policy. And then its up to the lawyers and judges to judge
>> the outcome of
>> this higher level context.

-------------------------------------------------------------------
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 dsg1.OpenDirectory.com.au ([203.108.249.145]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id SAA23508 for <[e-mail]>; Sun, 29 Aug 1999 18:19:15 -0700 (PDT)
Received: by DSG1 with Internet Mail Service (5.0.1458.49) id <R6XH21RT>; Mon, 30 Aug 1999 11:21:13 +1000
Message-ID: <D1A949D4508DD1119C8100400533BEDC151950@DSG1>
From: Ron Ramsay <[e-mail]>
To: "'Paul Koning'" <[e-mail]>, [e-mail]
Cc: [e-mail], [e-mail], [e-mail]
Subject: RE: Deprecate the NR bit?
Date: Mon, 30 Aug 1999 11:21:12 +1000
X-Priority: 3
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.0.1458.49)
Content-Type: text/plain

Except that the NR bit cannot be added to the certificate by the
application!

I think PKIX has to say something about the NR bit even if the
interpretation is finally left to the application.

> -----Original Message-----
> From:	Paul Koning [SMTP:[e-mail]]
> Sent:	Saturday, August 28, 1999 3:43 AM
> To:	[e-mail]
> Cc:	[e-mail]; [e-mail];
> [e-mail]
> Subject:	RE: Deprecate the NR bit?
> 
> Let me see if I understand this.
> 
> Stefan says that PKIX can't, and shouldn't try to, provide a common
> understanding of what NR is.  
> 
> Stefan and John both say that the semantics of the NR bit aren't
> defined in PKIX, they are defined by what lives above and vary
> depending on what lives above.
> 
> And David says that they have semantics for the bit but they are
> different. 
> 
> So in summary, PKIX can define the bit but it can't define what it
> means, and if you ask what it means you will get either no answer or a
> 
> variable answer.
> 
> That does suggest to me the bit doesn't belong here.  Let it go into
> the applications that have a defined semantic, with a name appropriate
> 
> for its meaning, and a definition of its meaning.
> 
> 	paul
> 
> >>>>> "Fillingham," == Fillingham, David W <[e-mail]>
> writes:
> 
>  Fillingham,> I agree with John and Stefan that the NR bit not be
>  Fillingham,> deprecated, for the reasons they indicate, and because
>  Fillingham,> the current draft DoD Certificate Policy has slightly
>  Fillingham,> different requirements for certificate generation and
>  Fillingham,> management for digital signature certificates that do or
>  Fillingham,> do not assert the non-repudiation key usage bit.
> 
>  >> ---------- From: Linn, John[SMTP:[e-mail]] Sent:
>  >> Friday, August 27, 1999 12:38 PM To: 'Stefan Santesson' Cc:
>  >> '[e-mail]' Subject: RE: Deprecate the NR bit?
>  >> 
>  >> I agree with Stefan.  While an NR bit is appropriately sourced
>  >> within a PKIX infrastructure (representing, in a protected manner,
>  >> an assertion by an issuing CA), it's primarily consumed above the
>  >> infrastructure.  Its consumption and semantics will depend on
>  >> operational environments and their policies.
>  >> 
>  >> Consensus hasn't yet become apparent on identifying all of the
>  >> characteristics which PKI-supported NR services might possess, or
>  >> in organizing those characteristics into an ordering. 
> 
> > From: Stefan Santesson [mailto:[e-mail]]
> >
> > I must admit that I have not followed everything said
> > regarding the NR-bit
> > on this list, but I'm not surprised that PKIX can't provide a common
> > understanding on what NR is in detail.
> >
> > In fact I don't think PKIX should even try to do that, other
> > than in the
> > very general context that has already been done in RFC 2459.
> >
> > This does not mean that the bit is useless and should be
> > deprecated. The NR
> > bit belongs in a much wider context totally above the PKIX
> > level. The fact
> > is also that the NR-bit is used in many higher level context
> > with success.
> > If you would deprecate the bit you would force them to be
> > non-compliant to
> > PKIX.
> >
> > It is up to higher level of system design to provide the
> > exact semantics of
> > this bit, presumably in combination with some defined
> > electronic signature
> > policy. And then its up to the lawyers and judges to judge
> > the outcome of
> > this higher level context.


Received: from dsg1.OpenDirectory.com.au ([203.108.249.145]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id SAA23076 for <[e-mail]>; Sun, 29 Aug 1999 18:13:35 -0700 (PDT)
Received: by DSG1 with Internet Mail Service (5.0.1458.49) id <R6XH21R3>; Mon, 30 Aug 1999 11:15:31 +1000
Message-ID: <D1A949D4508DD1119C8100400533BEDC15194F@DSG1>
From: Ron Ramsay <[e-mail]>
To: "'[e-mail]'" <[e-mail]>, Ambarish Malpani <[e-mail]>
Cc: [e-mail]
Subject: RE: apologies and comments on SCVP
Date: Mon, 30 Aug 1999 11:15:30 +1000
X-Priority: 3
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.0.1458.49)
Content-Type: text/plain

But a library will require that each client collect CRLs, that each
client be configured with the business/trust rules, etc. This sounds
like a significant systems administration problem.

> -----Original Message-----
> From:	[e-mail] [SMTP:[e-mail]]
> Sent:	Friday, August 27, 1999 9:55 PM
> To:	Ambarish Malpani
> Cc:	[e-mail]
> Subject:	RE: apologies and comments on SCVP
> 
> Hi Ambarish,
> 
> > ClientType1 basically wants to be able to use public key
> > cryptography (and the PKIX infrastructure), without needing to
> > understand all of PKIX part1, OCSP, LDAP etc. It is outsourcing
> > the task of checking cert status, cert expiry, policy management
> > etc to the SCVP server. The main question ClientType1 is asking
> > is: "Hey, I got this cert, can I use it for application X?".
> > The minimal response the server needs to provide is a signed
> > yes/no. If you throw away all the extra stuff, you essentially
> > have the client sending in a cert and getting back a yes/no
> > answer.
> 
> Why is the best answer to this need a protocol instead of a library?
> It
> seems if this is a technical need, you could craft a nice library with
> simple APIs to do this.
>      Mez


Received: from letterbox.cs.auckland.ac.nz (letterbox.cs.auckland.ac.nz [130.216.35.1]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id MAA29237 for <[e-mail]>; Sat, 28 Aug 1999 12:44:35 -0700 (PDT)
Received: from kakapo.cs.auckland.ac.nz (kakapo.cs.auckland.ac.nz [130.216.34.10]) by letterbox.cs.auckland.ac.nz (8.8.6/8.8.6/cs-master) with ESMTP id HAA21815; Sun, 29 Aug 1999 07:46:27 +1200 (sender [e-mail])
Received: (from pgut001@localhost) by kakapo.cs.auckland.ac.nz (8.8.6/8.8.6/cs-slave) id HAA21298; Sun, 29 Aug 1999 07:46:16 +1200 (NZST) (sender [e-mail])
Date: Sun, 29 Aug 1999 07:46:16 +1200 (NZST)
Message-ID: <[e-mail]>
From: [e-mail] (Peter Gutmann)
To: [e-mail]
Subject: Re: Multi-national company listing issues
Cc: [e-mail]

>I posted the following (modulo a few changes) to the ABA Information Security
>Committee list in response to David's request on this subject to that group:

It's kind of difficult to reply to that since I agree with everything in it.
All I can say is <aol>me too</aol>.

Peter.


Received: from dsg1.OpenDirectory.com.au ([203.108.249.145]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id HAA25601 for <[e-mail]>; Sat, 28 Aug 1999 07:18:06 -0700 (PDT)
Received: by DSG1 with Internet Mail Service (5.0.1458.49) id <RX4Y296V>; Sun, 29 Aug 1999 00:19:50 +1000
Message-ID: <D1A949D4508DD1119C8100400533BEDC15D7FD@DSG1>
From: Alan Lloyd <[e-mail]>
To: "'Sweigert, David '" <[e-mail]>, "'[e-mail] '" <[e-mail]>, "'[e-mail] '" <[e-mail]>, "'Robert Moskowitz '" <[e-mail]>
Subject: RE: More problems with OCSP
Date: Sun, 29 Aug 1999 00:19:48 +1000
X-Priority: 3
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.0.1458.49)
Content-Type: text/plain

Dear all, my last response re - "what are you building this with" let me
explain.

LDAP servers - generally like their namespace to the root - the world is
theirs. This creates a few inteconnectivity problems to say the least
when one tries to group these things as a collective.
 And, if you want to have authenticated users on a multi - LDAP server
system - referrals become useless and you have to replicate everything
to everywhere.. 
So if you build a system with LDAP servers like this.. what you call
things under the root does not matter - Country can be WW or XX, Org can
be under this and a persons entry can be unique and exist as replicated
entries all over. However, an new namespace just means that each server,
just grows and grows as do the replication effort -so a wall will be hit
at some time.

If you want to build a real distributed directory system then a few
options can be taken up if LDAP/DAP accessed X.500 distributed
directories are used. In addition one builds these things knowing that
at some point in time the system will grow with other DSAs/ servers (via
DSP) or as with us subordinate LDAP servers (if OD DXserver is used).
ie these additions can have different namespace (ownership). 

So when dealing with scaleable distributed directory systems the naming
and knowledge  issues become more exact, the operational backbone issues
re multi master, caching, load balancing, alternates and fault
tolerance,etc all require consideration.

In addition the schema needs to be thought through a bit more as do the
requirements for distributed searching and domain based and subtree
based access control regimes.

I see a number of LDAP server naming approaches and schemas get put
together - "easily",  simply because the directory in this case  is
isolated. So no operational and scaling rules apply re additional
namespace and cross DSA searching. However, I have also seen this come
undone for the same reason. ie we need to connect server a with server b
and get distributed searches going and common access controls - and with
system reliability  addressed.

I think its very bad in directory system design to quote country and
organisational level name and schema design - without operational,
system and inteconnectivity issues defined. Because done in isolation -
just means that external operational, commercial and technical issues
wont be addressed.!

There are of course - some whojust want an isolated LDAP directory
server - with replicate everything to everywhere..However, there arnt
too many that want a isolated PABX - are there?

Just thoughts and regards alan






----------
From: Robert Moskowitz
To: Sweigert, David; Alan Lloyd; '[e-mail]';
[e-mail]; [e-mail]
Sent: 8/27/99 4:06:39 AM
Subject: RE: More problems with OCSP

At 06:28 PM 8/24/1999 -0400, Sweigert, David wrote:

If I remember correctly, GM goes by country and then function.

Chrysler went by function and then country (don't know what DCX will
do).

So do what ever you want.  Either will work for your client, neither
will
work for a global lookup.

>
>As anyone grappling with the problem of defining a directory
information
>tree for a multi-national company.  In other words, how do divisions in
>the UK and US relate in the DIT if both divisions are within one
corporate
>organization; say MARKETING.
>
>Would this be appropriate:
>
>c=US
>o=GlobalCorp
>ou=Marketing
>
>and
>
>c=UK
>o=GlobalCorp
>ou=Marketing
>
>
>Any thoughts on this ?
>
>Dave Sweigert

Robert Moskowitz
ICSA
Security Interest EMail: [e-mail]



Received: from crack.x509.com (crack.x509.com [199.175.150.1]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id RAA16142 for <[e-mail]>; Fri, 27 Aug 1999 17:06:44 -0700 (PDT)
Received: from xcert.com (saxifrage.x509.com [199.175.148.75]) by crack.x509.com (8.9.3/XCERT) with ESMTP id RAA16122 for <[e-mail]>; Fri, 27 Aug 1999 17:07:45 -0700 (PDT)
Sender: [e-mail]
Message-ID: <[e-mail]>
Date: Fri, 27 Aug 1999 17:10:45 -0700
From: Marc Branchaud <[e-mail]>
Organization: Xcert International Inc.
X-Mailer: Mozilla 4.61 [en] (X11; U; Linux 2.2.10 i686)
X-Accept-Language: en, fr
MIME-Version: 1.0
To: [e-mail]
Subject: New Microsoft cert extension?
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Found an extension with this OID in a Win2K cert: 1.3.6.1.4.1.311.21.1. 
Here's what it looks like from Peter Gutmann's dumpasn1:

 576 30   16:         SEQUENCE {
 578 06    9:           OBJECT IDENTIFIER '1 3 6 1 4 1 311 21 1'
 589 04    3:           OCTET STRING, encapsulates {
 591 02    1:               INTEGER 0
            :               }
            :           }

I believe that 1.3.6.1.4.1.311 belongs to Microsoft, but does anyone
know what this extension is?

		Marc


Received: from poptop.llnl.gov (poptop.llnl.gov [128.115.18.65]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id QAA15878 for <[e-mail]>; Fri, 27 Aug 1999 16:56:08 -0700 (PDT)
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 QAA14124; Fri, 27 Aug 1999 16:57:56 -0700 (PDT)
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.3 (32)
Date: Fri, 27 Aug 1999 16:58:03 -0700
To: [e-mail]
From: Tony Bartoletti <[e-mail]>
Subject: Re: Elaborate and clarify the technical NR service definition
Cc: [e-mail]
In-Reply-To: <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"

At 06:59 PM 8/27/99 -0400, [e-mail] wrote:
>     Thanks for the help.  I guess the first sentence should probably read
>"signed by the private key corresponding to the specified valid certificate", or
>something like that.
>
>          Tom Gindin

Yes, that would be clear.  And I stress that the "disclaimer" should make
clear that BOTH "real owner" AND "real signer" are beyond scope.

A picture is worth a thousand bytes :)


                                   (Domain of Tech NR Service)
                                  -----------------------------
                --> CA ----------|--> CRLs      (TimeStamps?)  |
              /       \          |                             |
      (PERP-1)         ----------|--> Cert(OWNER,PublicKey)    |
              \                  |                             |
                --> PrivateKey   |    Object     Signature     |
                         \        ------|--------^-------------
                          \             |       /
                           -----------> (PERP-2)

A "Full NR Service" would hope to establish "PERP-1 = OWNER = PERP-2".
The CA is (CPS-variably) responsible for "PERP-1 = OWNER".  And we
entertain notions such as pin-activated tamperproof smartcards and
subscriber-due-care to approach "OWNER = PERP-2".

___tony___ (with too much time on his hands:)



 


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 e2.ny.us.ibm.com (e2.ny.us.ibm.com [32.97.182.102]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id PAA15147 for <[e-mail]>; Fri, 27 Aug 1999 15:58:51 -0700 (PDT)
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 TAA232168; Fri, 27 Aug 1999 19:00:16 -0400
Received: from D51MTA05.pok.ibm.com (d51mta05.pok.ibm.com [9.117.200.33]) by northrelay02.pok.ibm.com (8.8.8m2/NCO v2.04) with SMTP id TAA112086; Fri, 27 Aug 1999 19:00:38 -0400
Received: by D51MTA05.pok.ibm.com(Lotus SMTP MTA v4.6.4  (830.2 3-23-1999))  id 852567DA.007E6407 ; Fri, 27 Aug 1999 19:00:31 -0400
X-Lotus-FromDomain: IBMUS
To: Tony Bartoletti <[e-mail]>
cc: [e-mail]
Message-ID: <[e-mail]>
Date: Fri, 27 Aug 1999 18:59:23 -0400
Subject: Re: Elaborate and clarify the technical NR service definition
Mime-Version: 1.0
Content-type: text/plain; charset=us-ascii
Content-Disposition: inline

     Thanks for the help.  I guess the first sentence should probably read
"signed by the private key corresponding to the specified valid certificate", or
something like that.

          Tom Gindin




Received: from poptop.llnl.gov (poptop.llnl.gov [128.115.18.65]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id PAA14888 for <[e-mail]>; Fri, 27 Aug 1999 15:46:45 -0700 (PDT)
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 PAA15337; Fri, 27 Aug 1999 15:48:28 -0700 (PDT)
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.3 (32)
Date: Fri, 27 Aug 1999 15:48:36 -0700
To: [e-mail], [e-mail]
From: Tony Bartoletti <[e-mail]>
Subject: Re: Elaborate and clarify the technical NR service definition
In-Reply-To: <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"

At 03:41 PM 8/27/99 -0400, [e-mail] wrote:
>     In the interest of clarifying the discussion over what the NR bit is good
>for, I am preparing an Internet-Draft on the requirements of the technical NR
>service.  I have had some encouragement on this, although this is my personal
>responsibility and does not necessarily represent the views of my employer or of
>those who think such a draft would be helpful.  The scope of this draft will be
>limited to the technical requirements of NR and deliberately exclude
>considerations of what is necessary for the execution of a legal contract.  I
>hope that many of the participants in this discussion will be willing to help
>clarify or debate the requirements in this posting.
>     To give an idea of what the draft will and will not cover, here is my
>paragraph on scope, which is mainly a set of limitations:
>     The technical nonRepudiation service (hereinafter NR service) is expected
>to provide evidence that a given object was signed by the possessor of a given
>valid certificate.  It is not anticipated that the use of the NR service will
>ordinarily constitute execution of a contract, or acceptance of any other legal
>obligation.  It is anticipated that the use of this service in accepting legal
>obligations will be the subject of legislation or judicial decision in various
>jurisdictions, which are likely to lay additional technical burdens upon the
>provision of such a service to such an extent as to constitute another, larger
>service which need not be the same in all jurisdictions.  It is outside the
>scope of the definition of this service to provide evidence that the signer and
>the holder of the signing certificate are the same, that the signer has been
>adequately informed of the content which is signed, that the signer is not
>acting under duress, etc.
>
>          Tom Gindin

Tom,

The scope-paragraph contains four sentences, of which the middle two might
be better in a second paragraph.

But, this also brings sentences 1 and 4 into close proximity, where the
terms "signed by", "possessor", "signer" and "holder" become confused.

In particular, (1) says the service is expected to provide evidence that a
particular object:

    "was signed by the possessor of a given valid certificate"

but (4) says it is outside the scope of the service to provide evidence
that:

    "the signer and holder of the signing certificate are the same".

In other words, this description of a Technical NR Service might say
"independent of whether the "signer" and "holder" are the same, will
provide evidence of "signed by the possessor".

Indeed, there are 3 possible parties at work as the "ostensible" subscriber.
These are (my terminology):

   SubscriberInFact:
        The person who presented themselves as "X" to the CA in order to
        receive a certificate "owned by X"

   SubscriberOfRecord:
        The person named as subscriber in the certificate.  That is, the
        "X" in "owned by X"

   ActiveSigner:
        The person actually effecting a signature to occur, in particular
        independent of whether or not they are the "owner".

Note that if person Y poses as person X, to get a "cert named X", and then
has the secret key stolen and used by a person Z, then all three of these
entities may be different people.

I'm not saying that my terminology is best, but we need to be clear on
these three possible roles, so we can state what is meant by your sentences
(1) and (4) taken together.

I believe the simplest form of a "Technical NR Service" would be to
provide (long term) evidence that an object was signed with a key that
was CA-certified as "owned by X" and valid at the time of signature.

And then stress that such evidence is not (in general) sufficient to
establish either that "X wielded the key" nor that "X owned the key".
Indeed, X could have died in 1923.

___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 popmail.inbox.se (popmail.inbox.se [193.12.72.101]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id PAA14682 for <[e-mail]>; Fri, 27 Aug 1999 15:42:37 -0700 (PDT)
Received: from foo.telia.se (t4o68p13.telia.com [62.20.139.133]) by popmail.inbox.se (8.9.3/8.9.3) with SMTP id AAA16224; Sat, 28 Aug 1999 00:44:24 +0200
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 
Date: Sat, 28 Aug 1999 00:45:42 +0200
To: [e-mail], [e-mail]
From: Stefan Santesson <[e-mail]>
Subject: Re: Pseudonym in Subject DN (in QC certificates)
In-Reply-To: <[e-mail]>
References: <[e-mail]> <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"

Yes David, That's actually what i meant but maybe didn't express very clearly.

/Stefan

At 20:11 1999-08-27 +0100, David Chadwick wrote:
>Stefan wrote
>
>> Taking this into consideration I think that we should go forward and
>> include the pseudonym attribute.
>> This will force us to expand the set of supported attributes compared to
>> RFC 2459 and also to add matching rules for this attribute.
>
>You do not need to define any new matching rules if you make the 
>syntax of pseudonyms the same as commonName, and use the 
>same matching rules as for commonName. Then all you are doing is 
>attaching a new meaning to the value that was previously called a 
>commonName but was really a pseudonym in disguise.
>
>David
>***************************************************
>
>David Chadwick
>IS Institute, University of Salford, Salford M5 4WT
>Tel [phone]  Fax [phone]
>Mobile [phone]
>*NEW* Email [e-mail] *NEW*
>Home Page  http://www.salford.ac.uk/its024/chadwick.htm
>Understanding X.500  http://www.salford.ac.uk/its024/X500.htm
>X.500/LDAP Seminars http://www.salford.ac.uk/its024/seminars.htm
>Entrust key validation string MLJ9-DU5T-HV8J
>
>***************************************************



Received: from over.ny.us.ibm.com (over.ny.us.ibm.com [32.97.182.111]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id OAA13800 for <[e-mail]>; Fri, 27 Aug 1999 14:13:49 -0700 (PDT)
From: [e-mail]
Received: from e1.ny.us.ibm.com (s1 [10.0.3.101]) by admin.ny.us.ibm.com (8.9.3/8.9.3) with ESMTP id PAA18932 for <[e-mail]>; Fri, 27 Aug 1999 15:43:37 -0400
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 PAA271654 for <[e-mail]>; Fri, 27 Aug 1999 15:42:20 -0400
Received: from D51MTA05.pok.ibm.com (d51mta05.pok.ibm.com [9.117.200.33]) by northrelay02.pok.ibm.com (8.8.8m2/NCO v2.04) with SMTP id PAA135538 for <[e-mail]>; Fri, 27 Aug 1999 15:42:42 -0400
Received: by D51MTA05.pok.ibm.com(Lotus SMTP MTA v4.6.4  (830.2 3-23-1999))  id 852567DA.006C467D ; Fri, 27 Aug 1999 15:42:39 -0400
X-Lotus-FromDomain: IBMUS
To: [e-mail]
Message-ID: <[e-mail]>
Date: Fri, 27 Aug 1999 15:41:26 -0400
Subject: Elaborate and clarify the technical NR service definition
Mime-Version: 1.0
Content-type: text/plain; charset=us-ascii
Content-Disposition: inline

     In the interest of clarifying the discussion over what the NR bit is good
for, I am preparing an Internet-Draft on the requirements of the technical NR
service.  I have had some encouragement on this, although this is my personal
responsibility and does not necessarily represent the views of my employer or of
those who think such a draft would be helpful.  The scope of this draft will be
limited to the technical requirements of NR and deliberately exclude
considerations of what is necessary for the execution of a legal contract.  I
hope that many of the participants in this discussion will be willing to help
clarify or debate the requirements in this posting.
     To give an idea of what the draft will and will not cover, here is my
paragraph on scope, which is mainly a set of limitations:
     The technical nonRepudiation service (hereinafter NR service) is expected
to provide evidence that a given object was signed by the possessor of a given
valid certificate.  It is not anticipated that the use of the NR service will
ordinarily constitute execution of a contract, or acceptance of any other legal
obligation.  It is anticipated that the use of this service in accepting legal
obligations will be the subject of legislation or judicial decision in various
jurisdictions, which are likely to lay additional technical burdens upon the
provision of such a service to such an extent as to constitute another, larger
service which need not be the same in all jurisdictions.  It is outside the
scope of the definition of this service to provide evidence that the signer and
the holder of the signing certificate are the same, that the signer has been
adequately informed of the content which is signed, that the signer is not
acting under duress, etc.

          Tom Gindin




Received: from metis.salford.ac.uk (metis.salford.ac.uk [146.87.232.15]) by mail.proper.com (8.9.3/8.9.3) with SMTP id MAA11463 for <[e-mail]>; Fri, 27 Aug 1999 12:09:55 -0700 (PDT)
Received: (qmail 14302 invoked by alias); 27 Aug 1999 19:11:43 -0000
Message-ID: <[e-mail]>
Received: (qmail 14289 invoked from network); 27 Aug 1999 19:11:43 -0000
Received: from unknown (HELO dwc-acer) (146.87.80.54) by metis.salford.ac.uk with SMTP; 27 Aug 1999 19:11:43 -0000
From: "David Chadwick" <[e-mail]>
Organization: University of Salford
To: Stefan Santesson <[e-mail]>, [e-mail]
Date: Fri, 27 Aug 1999 20:11:45 +0100
MIME-Version: 1.0
Content-type: text/plain; charset=US-ASCII
Content-transfer-encoding: 7BIT
Subject: Re: Pseudonym in Subject DN (in QC certificates)
Reply-to: [e-mail]
Priority: normal
In-reply-to: <[e-mail]>
References: <[e-mail]>
X-mailer: Pegasus Mail for Win32 (v3.01d)

Stefan wrote

> Taking this into consideration I think that we should go forward and
> include the pseudonym attribute.
> This will force us to expand the set of supported attributes compared to
> RFC 2459 and also to add matching rules for this attribute.

You do not need to define any new matching rules if you make the 
syntax of pseudonyms the same as commonName, and use the 
same matching rules as for commonName. Then all you are doing is 
attaching a new meaning to the value that was previously called a 
commonName but was really a pseudonym in disguise.

David
***************************************************

David Chadwick
IS Institute, University of Salford, Salford M5 4WT
Tel [phone]  Fax [phone]
Mobile [phone]
*NEW* Email [e-mail] *NEW*
Home Page  http://www.salford.ac.uk/its024/chadwick.htm
Understanding X.500  http://www.salford.ac.uk/its024/X500.htm
X.500/LDAP Seminars http://www.salford.ac.uk/its024/seminars.htm
Entrust key validation string MLJ9-DU5T-HV8J

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


Received: from tomcat.sac.verio.net ([e-mail] [209.162.64.15]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id LAA09890 for <[e-mail]>; Fri, 27 Aug 1999 11:50:05 -0700 (PDT)
Received: from nma.com (pm02-46.sac.verio.net [209.162.64.65]) by tomcat.sac.verio.net (8.9.1a/8.9.1) with ESMTP id LAA13477; Fri, 27 Aug 1999 11:51:39 -0700 (PDT)
Message-ID: <[e-mail]>
Date: Fri, 27 Aug 1999 11:51:43 -0700
From: Ed Gerck <[e-mail]>
X-Mailer: Mozilla 4.61 [en]C-CCK-MCD {Sony}  (Win98; I)
X-Accept-Language: en
MIME-Version: 1.0
To: Peter Williams <[e-mail]>
CC: "Fillingham, David W." <[e-mail]>, "'Stefan Santesson'" <[e-mail]>, "'Linn, John'" <[e-mail]>, [e-mail]
Subject: Re: Deprecate the NR bit?
References: <[e-mail]>
Content-Type: multipart/alternative; boundary="------------7024FBEE77A600A10D92B498"

--------------7024FBEE77A600A10D92B498
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit



Peter Williams wrote:
 I agree we should not deprecate the bit; there are coherentapplication contexts, including NATO X.400 secure inter-personaland organizational messaging service, and Authenticode. Neitherof these contexts deviate from the ISO NR definitions and intent.

Yes, IMO deprecating the NR bit would mean more uncertainty than
the intersubjective understanding already achieved.
 We should remove any "mandatory requirement" foruse of the NR-bit in IETF std protocols/profiles, however.

Yes, as well as (in a minimalistic edit) change "falsely denying"
to "deny" in 2459. Use of the NR bit should always be an operationalchoice; it is helpful if operational context(s)is/are signaled in the enhancedKeyUsage field.

Yes, agreed also.
 Any PKIX language which implies a dependency betweenuse of the NR bit and any other key usage bit, should beignored for the purpose of compliance testing.

Yes, and I suggest the same should be applied to all other bits
in the keyUsage field.

Cheers,

Ed Gerck

--------------7024FBEE77A600A10D92B498
Content-Type: text/html; charset=us-ascii
Content-Transfer-Encoding: 7bit

<!doctype html public "-//w3c//dtd html 4.0 transitional//en">
<html>
&nbsp;<font color="#000099"></font>
<p><font face="Arial,Helvetica"><font color="#3333FF">Peter Williams wrote:</font></font>
<br><font color="#3333FF"></font>&nbsp;<font face="Arial"><font color="#0000FF"><font size=-1>I
agree we should not deprecate the bit; there are coherent</font></font></font><font face="Arial"><font color="#0000FF"><font size=-1>application
contexts, including NATO X.400 secure inter-personal</font></font></font><font face="Arial"><font color="#0000FF"><font size=-1>and
organizational messaging service, and Authenticode. Neither</font></font></font><font face="Arial"><font color="#0000FF"><font size=-1>of
these contexts deviate from the ISO NR definitions and intent.</font></font></font><font face="Arial"><font color="#0000FF"><font size=-1></font></font></font>
<p><font face="Arial"><font color="#CC0000"><font size=-1>Yes, IMO deprecating
the NR bit would mean more uncertainty than</font></font></font>
<br><font face="Arial"><font color="#CC0000"><font size=-1>the intersubjective
understanding already achieved.</font></font></font>
<br><font face="Arial"><font color="#0000FF"><font size=-1></font></font></font>&nbsp;<font face="Arial"><font color="#0000FF"><font size=-1>We
should remove any "mandatory requirement" for</font></font></font><font face="Arial"><font color="#0000FF"><font size=-1>use
of the NR-bit in IETF std protocols/profiles, however.</font></font></font><font face="Arial"><font color="#0000FF"><font size=-1></font></font></font>
<p><font face="Arial"><font color="#CC0000"><font size=-1>Yes, as well
as (in a minimalistic edit) change "falsely denying"</font></font></font>
<br><font face="Arial"><font color="#CC0000"><font size=-1>to "deny" in
2459.</font></font></font>&nbsp;<font face="Arial"><font color="#0000FF"><font size=-1>Use
of the NR bit should always be an operational</font></font></font><font face="Arial"><font color="#0000FF"><font size=-1>choice;
it is helpful if operational context(s)</font></font></font><font face="Arial"><font color="#0000FF"><font size=-1>is/are
signaled in the enhancedKeyUsage field.</font></font></font><font face="Arial"><font color="#0000FF"><font size=-1></font></font></font>
<p><font face="Arial"><font color="#CC0000"><font size=-1>Yes, agreed also.</font></font></font>
<br><font face="Arial"><font color="#0000FF"><font size=-1></font></font></font>&nbsp;<font face="Arial"><font color="#0000FF"><font size=-1>Any
PKIX language which implies a dependency between</font></font></font><font face="Arial"><font color="#0000FF"><font size=-1>use
of the NR bit and any other key usage bit, should be</font></font></font><font face="Arial"><font color="#0000FF"><font size=-1>ignored
for the purpose of compliance testing.</font></font></font><font face="Arial"><font color="#0000FF"><font size=-1></font></font></font>
<p><font face="Arial"><font color="#CC0000"><font size=-1>Yes, and I suggest
the same should be applied to all other bits</font></font></font>
<br><font face="Arial"><font color="#CC0000"><font size=-1>in the keyUsage
field.</font></font></font><font face="Arial"><font color="#CC0000"><font size=-1></font></font></font>
<p><font face="Arial"><font color="#CC0000"><font size=-1>Cheers,</font></font></font><font face="Arial"><font color="#CC0000"><font size=-1></font></font></font>
<p><font face="Arial"><font color="#CC0000"><font size=-1>Ed Gerck</font></font></font></html>

--------------7024FBEE77A600A10D92B498--



Received: from rbhub101.chamb.disa.mil (rbhub101.chamb.disa.mil [209.22.120.24]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id LAA08851 for <[e-mail]>; Fri, 27 Aug 1999 11:15:56 -0700 (PDT)
Received: by rbhub101.chamb.disa.mil with Internet Mail Service (5.5.2650.10) id <R3HZFYW2>; Fri, 27 Aug 1999 14:18:43 -0400
Message-ID: <[e-mail]>
From: "Flanigan, Bill" <[e-mail]>
To: "'Fillingham, David'" <[e-mail]>
Cc: "'[e-mail]'" <[e-mail]>
Subject: RE: Deprecate the NR bit?
Date: Fri, 27 Aug 1999 14:19:55 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.10)
Content-Type: text/plain; charset="iso-8859-1"

Dave,

	I think if you were to remove the NR bit from (or set it to zero in)
the Basic Identity cert, you would still have a Basic Identity cert at the
apps level.  Also, if you add the NR bit to (or set it to one in) the Email
cert, wouldn't you still have an Email cert at the apps level?

Bill

> ----------
> From: 	Fillingham,  David W.[SMTP:[e-mail]]
> Sent: 	Friday, August 27, 1999 12:50 PM
> To: 	'Stefan Santesson'; 'Linn, John'
> Cc: 	'[e-mail]'
> Subject: 	RE: Deprecate the NR bit?
> 
> I agree with John and Stefan that the NR bit not be deprecated, for the
> reasons they indicate, and because the current draft DoD Certificate
> Policy has slightly different requirements for certificate generation and
> management for digital signature certificates that do or do not assert the
> non-repudiation key usage bit.
> 
> Dave Fillingham 
> 
> 	---------- 
> From:   Linn, John[SMTP:[e-mail]] 
> Sent:   Friday, August 27, 1999 12:38 PM 
> To:     'Stefan Santesson' 
> Cc:     '[e-mail]' 
> Subject:        RE: Deprecate the NR bit? 
> 
> 	I agree with Stefan.  While an NR bit is appropriately sourced
> within a PKIX 
> infrastructure (representing, in a protected manner, an assertion by an 
> issuing CA), it's primarily consumed above the infrastructure.  Its 
> consumption and semantics will depend on operational environments and
> their 
> policies.  
> 
> 	Consensus hasn't yet become apparent on identifying all of the 
> characteristics which PKI-supported NR services might possess, or in 
> organizing those characteristics into an ordering.  In advance of that 
> process (which could be slow to converge), I think that PKIX should retain
> 
> RFC-2459's current treatment of the bit.  I believe the binary switch is 
> useful and appropriate to distinguish between classes of intended usages; 
> this seems a valuable first-level indicator which may be appropriately 
> complemented in future by additional, finer-grained attributes. 
> 
> 	--jl 
> 
> 	> -----Original Message----- 
> > From: Stefan Santesson [ mailto:[e-mail]] 
> > Sent: Friday, August 27, 1999 10:05 AM 
> > To: William Flanigan; Bob Jueneman 
> > Cc: [e-mail]; [e-mail] 
> > Subject: Re: Deprecate the NR bit? 
> > 
> > 
> > I must admit that I have not followed everything said 
> > regarding the NR-bit 
> > on this list, but I'm not surprised that PKIX can't provide a common 
> > understanding on what NR is in detail. 
> > 
> > In fact I don't think PKIX should even try to do that, other 
> > than in the 
> > very general context that has already been done in RFC 2459. 
> > 
> > This does not mean that the bit is useless and should be 
> > deprecated. The NR 
> > bit belongs in a much wider context totally above the PKIX 
> > level. The fact 
> > is also that the NR-bit is used in many higher level context 
> > with success. 
> > If you would deprecate the bit you would force them to be 
> > non-compliant to 
> > PKIX. 
> > 
> > It is up to higher level of system design to provide the 
> > exact semantics of 
> > this bit, presumably in combination with some defined 
> > electronic signature 
> > policy. And then its up to the lawyers and judges to judge 
> > the outcome of 
> > this higher level context. 
> > 
> > So I would rather deprecate this discussion within PKIX then 
> > deprecate the bit. 
> > 
> > /Stefan 
> > 
> > At 09:39 AM 8/27/99 -0400, William Flanigan wrote: 
> > >Now, this makes sense!  What do others feel? 
> > > 
> > >Bob Jueneman wrote: 
> > > 
> > >[snip] 
> > >> 
> > >> My sense is that tempers are fraying, everyone's patience 
> > is wearing 
> > >> decidedly thin, and that the group is getting quite 
> > frustrated by the 
> > >> fact that we haven't been able to identify any single, reasonably 
> > >> simple definition for what we mean by NR. 
> > >> 
> > >> If that is the case, I believe we should deprecate the NR 
> > bit within 
> > >> PKIX, and then charter another WG to explore the 
> > interaction between 
> > >> the certificate contents, application (as opposed to 
> > protocol) behavior, 
> > >> and the business and legal issues involved with signed documents. 
> > >> 
> > >> Bob 
> > 
> > ------------------------------------------------------------------- 
> > 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 po1.bbn.com (PO1.BBN.COM [192.1.50.38]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id KAA07526 for <[e-mail]>; Fri, 27 Aug 1999 10:57:18 -0700 (PDT)
Received: from [128.89.0.110] (COSMEC.BBN.COM [128.89.0.110]) by po1.bbn.com (8.9.1/8.9.1) with ESMTP id NAA22068; Fri, 27 Aug 1999 13:58:09 -0400 (EDT)
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
X-Sender: [e-mail]
Message-Id: <v04020a01b3ec809bc982@[128.89.0.110]>
In-Reply-To: <[e-mail]>
References: <[e-mail]>
Date: Fri, 27 Aug 1999 13:52:17 -0400
To: William Flanigan <[e-mail]>
From: Stephen Kent <[e-mail]>
Subject: Re: Deprecate the NR bit?
Cc: Bob Jueneman <[e-mail]>, [e-mail], [e-mail]

Bill,

>Now, this makes sense!  What do others feel?
>
>Bob Jueneman wrote:
>
>[snip]
>>
>> My sense is that tempers are fraying, everyone's patience is wearing
>> decidedly thin, and that the group is getting quite frustrated by the
>> fact that we haven't been able to identify any single, reasonably
>> simple definition for what we mean by NR.
>>
>> If that is the case, I believe we should deprecate the NR bit within
>> PKIX, and then charter another WG to explore the interaction between
>> the certificate contents, application (as opposed to protocol) behavior,
>> and the business and legal issues involved with signed documents.
>>
>> Bob

No.

Steve


Received: from poptop.llnl.gov (poptop.llnl.gov [128.115.18.65]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id KAA07151 for <[e-mail]>; Fri, 27 Aug 1999 10:55:44 -0700 (PDT)
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 KAA10310; Fri, 27 Aug 1999 10:57:02 -0700 (PDT)
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.3 (32)
Date: Fri, 27 Aug 1999 10:57:05 -0700
To: "Peter Williams" <[e-mail]>, "Fillingham,  David W." <[e-mail]>, "'Stefan Santesson'" <[e-mail]>, "'Linn, John'" <[e-mail]>
From: Tony Bartoletti <[e-mail]>
Subject: RE: Deprecate the NR bit?
Cc: <[e-mail]>
In-Reply-To: <[e-mail]>
References: <[e-mail]>
Mime-Version: 1.0
Content-Type: text/enriched; charset="us-ascii"

Peter,


I think you've struck the best compromise that can be reached

on this issue.


___tony___


At 10:27 AM 8/27/99 -0700, Peter Williams wrote: 

<excerpt>

<fontfamily><param>Arial</param><color><param>0000,0000,ffff</param>I
agree we should not deprecate the bit; there are coherent

application contexts, including NATO X.400 secure inter-personal

and organizational messaging service,  and Authenticode. Neither

of these contexts deviate from the ISO NR definitions and intent.

</color></fontfamily><bigger>  

</bigger><fontfamily><param>Arial</param><color><param>0000,0000,ffff</param>We
should remove any "mandatory requirement" for

use of the NR-bit in IETF std protocols/profiles, however.

</color></fontfamily><bigger>  

</bigger><fontfamily><param>Arial</param><color><param>0000,0000,ffff</param>Use
of the NR bit should always be an operational 

choice; it is helpful if operational context(s)

is/are signaled in the enhancedKeyUsage field.

</color></fontfamily><bigger>  

</bigger><fontfamily><param>Arial</param><color><param>0000,0000,ffff</param>Any
PKIX language which implies a dependency between

use of the NR bit and any other key usage bit, should be

ignored for the purpose of compliance testing.

</color></fontfamily></excerpt>



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 dfw7-1.relay.mail.uu.net (dfw7-1.relay.mail.uu.net [199.171.54.106]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id KAA05599 for <[e-mail]>; Fri, 27 Aug 1999 10:41:34 -0700 (PDT)
Received: from xedia.com by dfw7sosrv11.alter.net with SMTP  (peer crosschecked as: madway.xedia.com [198.202.232.199]) id QQheck29393; Fri, 27 Aug 1999 17:43:21 GMT
Received: from tonga.xedia.com by xedia.com (4.1/SMI-4.1) id AA09736; Fri, 27 Aug 99 13:41:48 EDT
Received: by tonga.xedia.com (SMI-8.6/SMI-SVR4) id NAA15089; Fri, 27 Aug 1999 13:43:19 -0400
Date: Fri, 27 Aug 1999 13:43:19 -0400
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]
Subject: RE: Deprecate the NR bit?
References: <[e-mail]>
X-Mailer: VM 6.34 under 20.3 "Vatican City" XEmacs  Lucid

Let me see if I understand this.

Stefan says that PKIX can't, and shouldn't try to, provide a common
understanding of what NR is.  

Stefan and John both say that the semantics of the NR bit aren't
defined in PKIX, they are defined by what lives above and vary
depending on what lives above.

And David says that they have semantics for the bit but they are
different. 

So in summary, PKIX can define the bit but it can't define what it
means, and if you ask what it means you will get either no answer or a 
variable answer.

That does suggest to me the bit doesn't belong here.  Let it go into
the applications that have a defined semantic, with a name appropriate 
for its meaning, and a definition of its meaning.

	paul

>>>>> "Fillingham," == Fillingham, David W <[e-mail]> writes:

 Fillingham,> I agree with John and Stefan that the NR bit not be
 Fillingham,> deprecated, for the reasons they indicate, and because
 Fillingham,> the current draft DoD Certificate Policy has slightly
 Fillingham,> different requirements for certificate generation and
 Fillingham,> management for digital signature certificates that do or
 Fillingham,> do not assert the non-repudiation key usage bit.

 >> ---------- From: Linn, John[SMTP:[e-mail]] Sent:
 >> Friday, August 27, 1999 12:38 PM To: 'Stefan Santesson' Cc:
 >> '[e-mail]' Subject: RE: Deprecate the NR bit?
 >> 
 >> I agree with Stefan.  While an NR bit is appropriately sourced
 >> within a PKIX infrastructure (representing, in a protected manner,
 >> an assertion by an issuing CA), it's primarily consumed above the
 >> infrastructure.  Its consumption and semantics will depend on
 >> operational environments and their policies.
 >> 
 >> Consensus hasn't yet become apparent on identifying all of the
 >> characteristics which PKI-supported NR services might possess, or
 >> in organizing those characteristics into an ordering. 

> From: Stefan Santesson [mailto:[e-mail]]
>
> I must admit that I have not followed everything said
> regarding the NR-bit
> on this list, but I'm not surprised that PKIX can't provide a common
> understanding on what NR is in detail.
>
> In fact I don't think PKIX should even try to do that, other
> than in the
> very general context that has already been done in RFC 2459.
>
> This does not mean that the bit is useless and should be
> deprecated. The NR
> bit belongs in a much wider context totally above the PKIX
> level. The fact
> is also that the NR-bit is used in many higher level context
> with success.
> If you would deprecate the bit you would force them to be
> non-compliant to
> PKIX.
>
> It is up to higher level of system design to provide the
> exact semantics of
> this bit, presumably in combination with some defined
> electronic signature
> policy. And then its up to the lawyers and judges to judge
> the outcome of
> this higher level context.


Received: from ext-mail.valicert.com (ns1.valicert.com [63.65.221.10]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id KAA05301 for <[e-mail]>; Fri, 27 Aug 1999 10:24:52 -0700 (PDT)
Received: from int-mail.valicert.com (corporate-gw.valicert.com [63.65.221.2]) by ext-mail.valicert.com (8.9.3/8.9.3) with ESMTP id KAA02300; Fri, 27 Aug 1999 10:26:41 -0700 (PDT)
Received: from rsalaptop (1Cust87.tnt8.sfo3.da.uu.net [63.23.23.87]) by int-mail.valicert.com (8.9.3/8.9.3) with SMTP id KAA00466; Fri, 27 Aug 1999 10:26:31 -0700 (PDT)
From: "Peter Williams" <[e-mail]>
To: "Fillingham,  David W." <[e-mail]>, "'Stefan Santesson'" <[e-mail]>, "'Linn, John'" <[e-mail]>
Cc: <[e-mail]>
Subject: RE: Deprecate the NR bit?
Date: Fri, 27 Aug 1999 10:27:26 -0700
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_000B_01BEF076.C2471C80"
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
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_000B_01BEF076.C2471C80
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 8bit

RE: Deprecate the NR bit?I agree we should not deprecate the bit; there are
coherent
application contexts, including NATO X.400 secure inter-personal
and organizational messaging service,  and Authenticode. Neither
of these contexts deviate from the ISO NR definitions and intent.

We should remove any "mandatory requirement" for
use of the NR-bit in IETF std protocols/profiles, however.

Use of the NR bit should always be an operational
choice; it is helpful if operational context(s)
is/are signaled in the enhancedKeyUsage field.

Any PKIX language which implies a dependency between
use of the NR bit and any other key usage bit, should be
ignored for the purpose of compliance testing.
  -----Original Message-----
  From: Fillingham, David W. [mailto:[e-mail]]
  Sent: Friday, August 27, 1999 9:51 AM
  To: 'Stefan Santesson'; 'Linn, John'
  Cc: '[e-mail]'
  Subject: RE: Deprecate the NR bit?


  I agree with John and Stefan that the NR bit not be deprecated, for the
reasons they indicate, and because the current draft DoD Certificate Policy
has slightly different requirements for certificate generation and
management for digital signature certificates that do or do not assert the
non-repudiation key usage bit.

  Dave Fillingham

    ----------
    From:   Linn, John[SMTP:[e-mail]]
    Sent:   Friday, August 27, 1999 12:38 PM
    To:     'Stefan Santesson'
    Cc:     '[e-mail]'
    Subject:        RE: Deprecate the NR bit?

    I agree with Stefan.  While an NR bit is appropriately sourced within a
PKIX
    infrastructure (representing, in a protected manner, an assertion by an
    issuing CA), it's primarily consumed above the infrastructure.  Its
    consumption and semantics will depend on operational environments and
their
    policies.

    Consensus hasn't yet become apparent on identifying all of the
    characteristics which PKI-supported NR services might possess, or in
    organizing those characteristics into an ordering.  In advance of that
    process (which could be slow to converge), I think that PKIX should
retain
    RFC-2459's current treatment of the bit.  I believe the binary switch is
    useful and appropriate to distinguish between classes of intended
usages;
    this seems a valuable first-level indicator which may be appropriately
    complemented in future by additional, finer-grained attributes.

    --jl

    > -----Original Message-----
    > From: Stefan Santesson [mailto:[e-mail]]
    > Sent: Friday, August 27, 1999 10:05 AM
    > To: William Flanigan; Bob Jueneman
    > Cc: [e-mail]; [e-mail]
    > Subject: Re: Deprecate the NR bit?
    >
    >
    > I must admit that I have not followed everything said
    > regarding the NR-bit
    > on this list, but I'm not surprised that PKIX can't provide a common
    > understanding on what NR is in detail.
    >
    > In fact I don't think PKIX should even try to do that, other
    > than in the
    > very general context that has already been done in RFC 2459.
    >
    > This does not mean that the bit is useless and should be
    > deprecated. The NR
    > bit belongs in a much wider context totally above the PKIX
    > level. The fact
    > is also that the NR-bit is used in many higher level context
    > with success.
    > If you would deprecate the bit you would force them to be
    > non-compliant to
    > PKIX.
    >
    > It is up to higher level of system design to provide the
    > exact semantics of
    > this bit, presumably in combination with some defined
    > electronic signature
    > policy. And then its up to the lawyers and judges to judge
    > the outcome of
    > this higher level context.
    >
    > So I would rather deprecate this discussion within PKIX then
    > deprecate the bit.
    >
    > /Stefan
    >
    > At 09:39 AM 8/27/99 -0400, William Flanigan wrote:
    > >Now, this makes sense!  What do others feel?
    > >
    > >Bob Jueneman wrote:
    > >
    > >[snip]
    > >>
    > >> My sense is that tempers are fraying, everyone's patience
    > is wearing
    > >> decidedly thin, and that the group is getting quite
    > frustrated by the
    > >> fact that we haven't been able to identify any single, reasonably
    > >> simple definition for what we mean by NR.
    > >>
    > >> If that is the case, I believe we should deprecate the NR
    > bit within
    > >> PKIX, and then charter another WG to explore the
    > interaction between
    > >> the certificate contents, application (as opposed to
    > protocol) behavior,
    > >> and the business and legal issues involved with signed documents.
    > >>
    > >> Bob
    >
    > -------------------------------------------------------------------
    > 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_000_000B_01BEF076.C2471C80
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><TITLE>RE: Deprecate the NR bit?</TITLE>
<META content=3D"text/html; charset=3Diso-8859-1" =
http-equiv=3DContent-Type>
<META content=3D"MSHTML 5.00.2614.3401" name=3DGENERATOR></HEAD>
<BODY>
<DIV><FONT color=3D#0000ff face=3DArial size=3D2><SPAN =
class=3D250042117-27081999>I=20
agree we should not deprecate the bit; there are =
coherent</SPAN></FONT></DIV>
<DIV><FONT color=3D#0000ff face=3DArial size=3D2><SPAN=20
class=3D250042117-27081999>application contexts, including NATO X.400 =
secure=20
inter-personal</SPAN></FONT></DIV>
<DIV><FONT color=3D#0000ff face=3DArial size=3D2><SPAN =
class=3D250042117-27081999>and=20
organizational </SPAN></FONT><FONT color=3D#0000ff face=3DArial =
size=3D2><SPAN=20
class=3D250042117-27081999>messaging =
service,&nbsp;&nbsp;</SPAN></FONT><FONT=20
color=3D#0000ff face=3DArial size=3D2><SPAN =
class=3D250042117-27081999>and Authenticode.=20
Neither</SPAN></FONT></DIV>
<DIV><FONT color=3D#0000ff face=3DArial size=3D2><SPAN =
class=3D250042117-27081999>of=20
these contexts deviate from the ISO NR definitions and=20
intent.</SPAN></FONT></DIV>
<DIV><FONT color=3D#0000ff face=3DArial size=3D2><SPAN=20
class=3D250042117-27081999></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT color=3D#0000ff face=3DArial size=3D2><SPAN =
class=3D250042117-27081999>We=20
should remove any "mandatory requirement" for</SPAN></FONT></DIV>
<DIV><FONT color=3D#0000ff face=3DArial size=3D2><SPAN =
class=3D250042117-27081999>use of=20
the NR-bit in IETF std protocols/profiles, however.</SPAN></FONT></DIV>
<DIV><FONT color=3D#0000ff face=3DArial size=3D2><SPAN=20
class=3D250042117-27081999></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT color=3D#0000ff face=3DArial size=3D2><SPAN =
class=3D250042117-27081999>Use of=20
the NR bit should always be an operational </SPAN></FONT></DIV>
<DIV><FONT color=3D#0000ff face=3DArial size=3D2><SPAN=20
class=3D250042117-27081999>choice; it is helpful if operational=20
context(s)</SPAN></FONT></DIV>
<DIV><FONT color=3D#0000ff face=3DArial size=3D2><SPAN =
class=3D250042117-27081999>is/are=20
signaled in the enhancedKeyUsage field.</SPAN></FONT></DIV>
<DIV><FONT color=3D#0000ff face=3DArial size=3D2><SPAN=20
class=3D250042117-27081999></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT color=3D#0000ff face=3DArial size=3D2><SPAN =
class=3D250042117-27081999>Any=20
PKIX language which implies a dependency between</SPAN></FONT></DIV>
<DIV><FONT color=3D#0000ff face=3DArial size=3D2><SPAN =
class=3D250042117-27081999>use of=20
the NR bit and any other key usage bit, should be</SPAN></FONT></DIV>
<DIV><FONT color=3D#0000ff face=3DArial size=3D2><SPAN=20
class=3D250042117-27081999>ignored for the purpose of compliance=20
testing.</SPAN></FONT></DIV>
<BLOCKQUOTE=20
style=3D"BORDER-LEFT: #0000ff 2px solid; MARGIN-LEFT: 5px; PADDING-LEFT: =
5px">
  <DIV align=3Dleft class=3DOutlookMessageHeader dir=3Dltr><FONT =
face=3DTahoma=20
  size=3D2>-----Original Message-----<BR><B>From:</B> Fillingham, David =
W.=20
  [mailto:[e-mail]]<BR><B>Sent:</B> Friday, August 27, =
1999 9:51=20
  AM<BR><B>To:</B> 'Stefan Santesson'; 'Linn, John'<BR><B>Cc:</B>=20
  '[e-mail]'<BR><B>Subject:</B> RE: Deprecate the NR=20
  bit?<BR><BR></DIV></FONT>
  <P><FONT color=3D#0000ff face=3DArial size=3D2>I agree with John and =
Stefan that the=20
  NR bit not be deprecated, for the reasons they indicate, and because =
the=20
  current draft DoD Certificate Policy has slightly different =
requirements for=20
  certificate generation and management for digital signature =
certificates that=20
  do or do not assert the non-repudiation key usage bit.</FONT></P>
  <P><FONT color=3D#0000ff face=3DArial size=3D2>Dave Fillingham</FONT> =
</P>
  <UL>
    <P><FONT face=3D"MS Sans Serif" size=3D1>----------</FONT> =
<BR><B><FONT=20
    face=3D"MS Sans Serif" size=3D1>From:</FONT></B> &nbsp; <FONT=20
    face=3D"MS Sans Serif" size=3D1>Linn,=20
    John[SMTP:[e-mail]]</FONT> <BR><B><FONT=20
    face=3D"MS Sans Serif" size=3D1>Sent:</FONT></B> &nbsp; <FONT=20
    face=3D"MS Sans Serif" size=3D1>Friday, August 27, 1999 12:38 =
PM</FONT>=20
    <BR><B><FONT face=3D"MS Sans Serif" size=3D1>To:</FONT></B> =
&nbsp;&nbsp;&nbsp;=20
    <FONT face=3D"MS Sans Serif" size=3D1>'Stefan Santesson'</FONT> =
<BR><B><FONT=20
    face=3D"MS Sans Serif" size=3D1>Cc:</FONT></B> &nbsp;&nbsp;&nbsp; =
<FONT=20
    face=3D"MS Sans Serif" size=3D1>'[e-mail]'</FONT> =
<BR><B><FONT=20
    face=3D"MS Sans Serif" size=3D1>Subject:</FONT></B>=20
    &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT face=3D"MS Sans Serif" =
size=3D1>RE:=20
    Deprecate the NR bit?</FONT> </P>
    <P><FONT face=3DArial size=3D2>I agree with Stefan.&nbsp; While an =
NR bit is=20
    appropriately sourced within a PKIX</FONT> <BR><FONT face=3DArial=20
    size=3D2>infrastructure (representing, in a protected manner, an =
assertion by=20
    an</FONT> <BR><FONT face=3DArial size=3D2>issuing CA), it's =
primarily consumed=20
    above the infrastructure.&nbsp; Its</FONT> <BR><FONT face=3DArial=20
    size=3D2>consumption and semantics will depend on operational =
environments and=20
    their</FONT> <BR><FONT face=3DArial size=3D2>policies.&nbsp; =
</FONT></P>
    <P><FONT face=3DArial size=3D2>Consensus hasn't yet become apparent =
on=20
    identifying all of the</FONT> <BR><FONT face=3DArial =
size=3D2>characteristics=20
    which PKI-supported NR services might possess, or in</FONT> =
<BR><FONT=20
    face=3DArial size=3D2>organizing those characteristics into an =
ordering.&nbsp;=20
    In advance of that</FONT> <BR><FONT face=3DArial size=3D2>process =
(which could=20
    be slow to converge), I think that PKIX should retain</FONT> =
<BR><FONT=20
    face=3DArial size=3D2>RFC-2459's current treatment of the bit.&nbsp; =
I believe=20
    the binary switch is</FONT> <BR><FONT face=3DArial size=3D2>useful =
and=20
    appropriate to distinguish between classes of intended =
usages;</FONT>=20
    <BR><FONT face=3DArial size=3D2>this seems a valuable first-level =
indicator=20
    which may be appropriately</FONT> <BR><FONT face=3DArial =
size=3D2>complemented=20
    in future by additional, finer-grained attributes. </FONT></P>
    <P><FONT face=3DArial size=3D2>--jl</FONT> </P>
    <P><FONT face=3DArial size=3D2>&gt; -----Original =
Message-----</FONT> <BR><FONT=20
    face=3DArial size=3D2>&gt; From: Stefan Santesson [</FONT><U><FONT =
color=3D#0000ff=20
    face=3DArial size=3D2><A=20
    =
href=3D"mailto:[e-mail]">mailto:[e-mail]</A></FONT></=
U><FONT=20
    face=3DArial size=3D2>]</FONT> <BR><FONT face=3DArial size=3D2>&gt; =
Sent: Friday,=20
    August 27, 1999 10:05 AM</FONT> <BR><FONT face=3DArial size=3D2>&gt; =
To: William=20
    Flanigan; Bob Jueneman</FONT> <BR><FONT face=3DArial size=3D2>&gt; =
Cc:=20
    [e-mail]; [e-mail]</FONT> <BR><FONT =
face=3DArial=20
    size=3D2>&gt; Subject: Re: Deprecate the NR bit?</FONT> <BR><FONT =
face=3DArial=20
    size=3D2>&gt; </FONT><BR><FONT face=3DArial size=3D2>&gt; =
</FONT><BR><FONT=20
    face=3DArial size=3D2>&gt; I must admit that I have not followed =
everything said=20
    </FONT><BR><FONT face=3DArial size=3D2>&gt; regarding the =
NR-bit</FONT>=20
    <BR><FONT face=3DArial size=3D2>&gt; on this list, but I'm not =
surprised that=20
    PKIX can't provide a common</FONT> <BR><FONT face=3DArial =
size=3D2>&gt;=20
    understanding on what NR is in detail.</FONT> <BR><FONT face=3DArial =

    size=3D2>&gt; </FONT><BR><FONT face=3DArial size=3D2>&gt; In fact I =
don't think=20
    PKIX should even try to do that, other </FONT><BR><FONT face=3DArial =

    size=3D2>&gt; than in the</FONT> <BR><FONT face=3DArial =
size=3D2>&gt; very general=20
    context that has already been done in RFC 2459.</FONT> <BR><FONT =
face=3DArial=20
    size=3D2>&gt; </FONT><BR><FONT face=3DArial size=3D2>&gt; This does =
not mean that=20
    the bit is useless and should be </FONT><BR><FONT face=3DArial =
size=3D2>&gt;=20
    deprecated. The NR</FONT> <BR><FONT face=3DArial size=3D2>&gt; bit =
belongs in a=20
    much wider context totally above the PKIX </FONT><BR><FONT =
face=3DArial=20
    size=3D2>&gt; level. The fact</FONT> <BR><FONT face=3DArial =
size=3D2>&gt; is also=20
    that the NR-bit is used in many higher level context =
</FONT><BR><FONT=20
    face=3DArial size=3D2>&gt; with success.</FONT> <BR><FONT =
face=3DArial size=3D2>&gt;=20
    If you would deprecate the bit you would force them to be =
</FONT><BR><FONT=20
    face=3DArial size=3D2>&gt; non-compliant to</FONT> <BR><FONT =
face=3DArial=20
    size=3D2>&gt; PKIX.</FONT> <BR><FONT face=3DArial size=3D2>&gt; =
</FONT><BR><FONT=20
    face=3DArial size=3D2>&gt; It is up to higher level of system design =
to provide=20
    the </FONT><BR><FONT face=3DArial size=3D2>&gt; exact semantics =
of</FONT>=20
    <BR><FONT face=3DArial size=3D2>&gt; this bit, presumably in =
combination with=20
    some defined </FONT><BR><FONT face=3DArial size=3D2>&gt; electronic=20
    signature</FONT> <BR><FONT face=3DArial size=3D2>&gt; policy. And =
then its up to=20
    the lawyers and judges to judge </FONT><BR><FONT face=3DArial =
size=3D2>&gt; the=20
    outcome of</FONT> <BR><FONT face=3DArial size=3D2>&gt; this higher =
level=20
    context.</FONT> <BR><FONT face=3DArial size=3D2>&gt; =
</FONT><BR><FONT face=3DArial=20
    size=3D2>&gt; So I would rather deprecate this discussion within =
PKIX then=20
    </FONT><BR><FONT face=3DArial size=3D2>&gt; deprecate the =
bit.</FONT> <BR><FONT=20
    face=3DArial size=3D2>&gt; </FONT><BR><FONT face=3DArial =
size=3D2>&gt;=20
    /Stefan</FONT> <BR><FONT face=3DArial size=3D2>&gt; </FONT><BR><FONT =
face=3DArial=20
    size=3D2>&gt; At 09:39 AM 8/27/99 -0400, William Flanigan =
wrote:</FONT>=20
    <BR><FONT face=3DArial size=3D2>&gt; &gt;Now, this makes =
sense!&nbsp; What do=20
    others feel?</FONT> <BR><FONT face=3DArial size=3D2>&gt; &gt;</FONT> =
<BR><FONT=20
    face=3DArial size=3D2>&gt; &gt;Bob Jueneman wrote:</FONT> <BR><FONT =
face=3DArial=20
    size=3D2>&gt; &gt;</FONT> <BR><FONT face=3DArial size=3D2>&gt; =
&gt;[snip]</FONT>=20
    <BR><FONT face=3DArial size=3D2>&gt; &gt;&gt; </FONT><BR><FONT =
face=3DArial=20
    size=3D2>&gt; &gt;&gt; My sense is that tempers are fraying, =
everyone's=20
    patience </FONT><BR><FONT face=3DArial size=3D2>&gt; is =
wearing</FONT> <BR><FONT=20
    face=3DArial size=3D2>&gt; &gt;&gt; decidedly thin, and that the =
group is=20
    getting quite </FONT><BR><FONT face=3DArial size=3D2>&gt; frustrated =
by=20
    the</FONT> <BR><FONT face=3DArial size=3D2>&gt; &gt;&gt; fact that =
we haven't=20
    been able to identify any single, reasonably</FONT> <BR><FONT =
face=3DArial=20
    size=3D2>&gt; &gt;&gt; simple definition for what we mean by =
NR.</FONT>=20
    <BR><FONT face=3DArial size=3D2>&gt; &gt;&gt; </FONT><BR><FONT =
face=3DArial=20
    size=3D2>&gt; &gt;&gt; If that is the case, I believe we should =
deprecate the=20
    NR </FONT><BR><FONT face=3DArial size=3D2>&gt; bit within</FONT> =
<BR><FONT=20
    face=3DArial size=3D2>&gt; &gt;&gt; PKIX, and then charter another =
WG to explore=20
    the </FONT><BR><FONT face=3DArial size=3D2>&gt; interaction =
between</FONT>=20
    <BR><FONT face=3DArial size=3D2>&gt; &gt;&gt; the certificate =
contents,=20
    application (as opposed to </FONT><BR><FONT face=3DArial =
size=3D2>&gt; protocol)=20
    behavior,</FONT> <BR><FONT face=3DArial size=3D2>&gt; &gt;&gt; and =
the business=20
    and legal issues involved with signed documents.</FONT> <BR><FONT =
face=3DArial=20
    size=3D2>&gt; &gt;&gt; </FONT><BR><FONT face=3DArial size=3D2>&gt; =
&gt;&gt;=20
    Bob</FONT> <BR><FONT face=3DArial size=3D2>&gt; </FONT><BR><FONT =
face=3DArial=20
    size=3D2>&gt;=20
    =
-------------------------------------------------------------------</FONT=
>=20
    <BR><FONT face=3DArial size=3D2>&gt; Stefan=20
    =
Santesson&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;=20
    &lt;[e-mail]&gt;</FONT> <BR><FONT face=3DArial =
size=3D2>&gt; Accurata=20
    =
AB&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</FONT><U>=20
    <FONT color=3D#0000ff face=3DArial size=3D2><A =
href=3D"http://www.accurata.se"=20
    target=3D_blank>http://www.accurata.se</A></FONT></U> <BR><FONT =
face=3DArial=20
    size=3D2>&gt;=20
    =
Slagthuset&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
    Tel. +46-40=20
    =
108588&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&=
nbsp;&nbsp;=20
    </FONT><BR><FONT face=3DArial size=3D2>&gt; 211 20&nbsp;=20
    =
Malm=F6&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
    Fax. +46-40=20
    =
150790&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&=
nbsp;&nbsp;=20
    </FONT><BR><FONT face=3DArial size=3D2>&gt;=20
    =
Sweden&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&=
nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
    Mobile [phone]</FONT> <BR><FONT face=3DArial size=3D2>&gt;=20
    </FONT><BR><FONT face=3DArial size=3D2>&gt; PGP fingerprint: 89BC =
6C79 5B3D 591B=20
    8547&nbsp; 1512 7D11 DBF4 528F 29A0</FONT> <BR><FONT face=3DArial =
size=3D2>&gt;=20
    =
-------------------------------------------------------------------</FONT=
>=20
    <BR><FONT face=3DArial size=3D2>&gt; =
</FONT></P></UL></BLOCKQUOTE></BODY></HTML>

------=_NextPart_000_000B_01BEF076.C2471C80--



Received: from tomcat.sac.verio.net ([e-mail] [209.162.64.15]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id KAA03563 for <[e-mail]>; Fri, 27 Aug 1999 10:00:26 -0700 (PDT)
Received: from nma.com (pm04-40.sac.verio.net [209.162.64.153]) by tomcat.sac.verio.net (8.9.1a/8.9.1) with ESMTP id KAA13406; Fri, 27 Aug 1999 10:01:43 -0700 (PDT)
Message-ID: <[e-mail]>
Date: Fri, 27 Aug 1999 10:01:47 -0700
From: Ed Gerck <[e-mail]>
X-Mailer: Mozilla 4.61 [en]C-CCK-MCD {Sony}  (Win98; I)
X-Accept-Language: en
MIME-Version: 1.0
CC: [e-mail], [e-mail], [e-mail], [e-mail], [e-mail], [e-mail], [e-mail], Paul Koning <[e-mail]>
Subject: Re: Multi-national company listing issues
References: <[e-mail]> <[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

 Bob Jueneman <[e-mail]> wrote:

> For example, is "C=" the country where the parent is located,
> where the subsidiary is located, where the tiny field office is
> located, where they are incorporated (think of a ship with
> Liberian registry), etc., etc.?
>
> In the case of an individual user, is the country where he was
> born (or adopted)? Where he is currently a citizen (what about
> dual citizenship, stateless persons, and nomads)?  Where he
> maintains a residence (or maybe a domicile)?  Where he works (I
> assume some people work in one country and sleep in another,
> every day)?

Bob:

What is the meaning of "C=string"?

There are two ways to solve this. One, is to proceed with the hierarchical
type structure as a taxonomy and provide all the possible ramifications --
clearly, with very little chance of satisfying even just the majority of cases.
The other way is to renounce the concept (wrong, anyway) of "denotational
syntax", treat the hierarchical structure as an an ontology and consider all
qualifiers from the syntactic point of view, as "names".  With this approach,
the meaning of "C=string" is now clear:

"C" and "string" are specified, and "C" stands in equivalence with "string"

Here, "C" is a name -- a quite arbitrary designation that is simply formally
defined and may (or not) have a mnemonic purpose or be expressed in
a human language.  In other words, "C" is just a pointer, a handle in an
hierarchical ontology (not in a taxonomy).  OTOH, "string" may be either
a name or a record as usual, where records refer mainly to physical
quantities (e.g., geographical data, network addresses, port numbers,
service designations, company names, etc.) designated in a materially
pre-defined form.  The  map and query methods of a database can then
relate names to records in a variety of relationships according to local
need, such as one-to-one, many-to-one, one-to-many or many-to-many.
The database can also follow a variety of models such as hierarchical,
network, relational, distributed hierarchical, etc.

What is required to do this? Nothing, just renounce the taxonomy and
employ the same hierarchical structure already in place in X.500 or
LDAP or whatever is being used.  Even the same relational tables
if a relational database model is followed.

But, where is the meaning of "C" denoted?  Not, in "C" itself but in the
trusted context -- where it is anyway defined.  For example, "C" is
meaningless in German as an abbreviation for Country -- it is the trusted
context which says so (but, with all the ambiguities you point out and
which are basically irresolvable).

The integration of different trusted contexts becomes then a problem,
but one which I believe is being increasingly solved in database theory
-- for example, with meta-directory approaches.

Of course, denotational syntax also "works" one may say -- but only in a
parochial environment where the trusted context is implicitly known.  Since
we are past this stage in the Internet, the fact that syntax and semantics
are independent variables can no longer be ignored and must be either
properly handled or threatens to overwhelm.

Cheers,

Ed Gerck



Received: from stingray.missi.ncsc.mil (stingray-ext.missi.ncsc.mil [144.51.50.20]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id JAA02541 for <[e-mail]>; Fri, 27 Aug 1999 09:49:05 -0700 (PDT)
Received: from stingray.missi.ncsc.mil (root@localhost) by stingray.missi.ncsc.mil with ESMTP id MAA12719 for <[e-mail]>; Fri, 27 Aug 1999 12:50:58 -0400 (EDT)
Received: from missi.ncsc.mil (depot.missi.ncsc.mil [144.51.60.1]) by stingray.missi.ncsc.mil with ESMTP id MAA12707 for <[e-mail]>; Fri, 27 Aug 1999 12:50:56 -0400 (EDT)
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 MAA10148 for <[e-mail]>; Fri, 27 Aug 1999 12:50:43 -0400 (EDT)
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]>; Fri, 27 Aug 1999 12:50:38 -0400
Received: by avenger54.missi.ncsc.mil with Internet Mail Service (5.5.2232.9) id <Q2Z2HPFG>; Fri, 27 Aug 1999 12:50:43 -0400
Message-Id: <[e-mail]>
From: "Fillingham,  David W." <[e-mail]>
To: "'Stefan Santesson'" <[e-mail]>, "'Linn, John'" <[e-mail]>
Cc: "'[e-mail]'" <[e-mail]>
Subject: RE: Deprecate the NR bit?
Date: Fri, 27 Aug 1999 12:50:42 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2232.9)
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01BEF0AC.4D5E6C6C"

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_01BEF0AC.4D5E6C6C
Content-Type: text/plain;
	charset="iso-8859-1"

I agree with John and Stefan that the NR bit not be deprecated, for the
reasons they indicate, and because the current draft DoD Certificate Policy
has slightly different requirements for certificate generation and
management for digital signature certificates that do or do not assert the
non-repudiation key usage bit.

Dave Fillingham

> ----------
> From: 	Linn, John[SMTP:[e-mail]]
> Sent: 	Friday, August 27, 1999 12:38 PM
> To: 	'Stefan Santesson'
> Cc: 	'[e-mail]'
> Subject: 	RE: Deprecate the NR bit?
> 
> I agree with Stefan.  While an NR bit is appropriately sourced within a
> PKIX
> infrastructure (representing, in a protected manner, an assertion by an
> issuing CA), it's primarily consumed above the infrastructure.  Its
> consumption and semantics will depend on operational environments and
> their
> policies.  
> 
> Consensus hasn't yet become apparent on identifying all of the
> characteristics which PKI-supported NR services might possess, or in
> organizing those characteristics into an ordering.  In advance of that
> process (which could be slow to converge), I think that PKIX should retain
> RFC-2459's current treatment of the bit.  I believe the binary switch is
> useful and appropriate to distinguish between classes of intended usages;
> this seems a valuable first-level indicator which may be appropriately
> complemented in future by additional, finer-grained attributes. 
> 
> --jl
> 
> > -----Original Message-----
> > From: Stefan Santesson [mailto:[e-mail]]
> > Sent: Friday, August 27, 1999 10:05 AM
> > To: William Flanigan; Bob Jueneman
> > Cc: [e-mail]; [e-mail]
> > Subject: Re: Deprecate the NR bit?
> > 
> > 
> > I must admit that I have not followed everything said 
> > regarding the NR-bit
> > on this list, but I'm not surprised that PKIX can't provide a common
> > understanding on what NR is in detail.
> > 
> > In fact I don't think PKIX should even try to do that, other 
> > than in the
> > very general context that has already been done in RFC 2459.
> > 
> > This does not mean that the bit is useless and should be 
> > deprecated. The NR
> > bit belongs in a much wider context totally above the PKIX 
> > level. The fact
> > is also that the NR-bit is used in many higher level context 
> > with success.
> > If you would deprecate the bit you would force them to be 
> > non-compliant to
> > PKIX.
> > 
> > It is up to higher level of system design to provide the 
> > exact semantics of
> > this bit, presumably in combination with some defined 
> > electronic signature
> > policy. And then its up to the lawyers and judges to judge 
> > the outcome of
> > this higher level context.
> > 
> > So I would rather deprecate this discussion within PKIX then 
> > deprecate the bit.
> > 
> > /Stefan
> > 
> > At 09:39 AM 8/27/99 -0400, William Flanigan wrote:
> > >Now, this makes sense!  What do others feel?
> > >
> > >Bob Jueneman wrote:
> > >
> > >[snip]
> > >> 
> > >> My sense is that tempers are fraying, everyone's patience 
> > is wearing
> > >> decidedly thin, and that the group is getting quite 
> > frustrated by the
> > >> fact that we haven't been able to identify any single, reasonably
> > >> simple definition for what we mean by NR.
> > >> 
> > >> If that is the case, I believe we should deprecate the NR 
> > bit within
> > >> PKIX, and then charter another WG to explore the 
> > interaction between
> > >> the certificate contents, application (as opposed to 
> > protocol) behavior,
> > >> and the business and legal issues involved with signed documents.
> > >> 
> > >> Bob
> > 
> > -------------------------------------------------------------------
> > 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_01BEF0AC.4D5E6C6C
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: Deprecate the NR bit?</TITLE>
</HEAD>
<BODY>

<P><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Arial">I agree with John =
and Stefan that the NR bit not be deprecated, for the reasons they =
indicate, and because the current draft DoD Certificate Policy has =
slightly different requirements for certificate generation and =
management for digital signature certificates that do or do not assert =
the non-repudiation key usage bit.</FONT></P>

<P><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Arial">Dave =
Fillingham</FONT>
</P>
<UL>
<P><FONT SIZE=3D1 FACE=3D"MS Sans Serif">----------</FONT>
<BR><B><FONT SIZE=3D1 FACE=3D"MS Sans Serif">From:</FONT></B> &nbsp; =
<FONT SIZE=3D1 FACE=3D"MS Sans Serif">Linn, =
John[SMTP:[e-mail]]</FONT>
<BR><B><FONT SIZE=3D1 FACE=3D"MS Sans Serif">Sent:</FONT></B> &nbsp; =
<FONT SIZE=3D1 FACE=3D"MS Sans Serif">Friday, August 27, 1999 12:38 =
PM</FONT>
<BR><B><FONT SIZE=3D1 FACE=3D"MS Sans Serif">To:</FONT></B> =
&nbsp;&nbsp;&nbsp; <FONT SIZE=3D1 FACE=3D"MS Sans Serif">'Stefan =
Santesson'</FONT>
<BR><B><FONT SIZE=3D1 FACE=3D"MS Sans Serif">Cc:</FONT></B> =
&nbsp;&nbsp;&nbsp; <FONT SIZE=3D1 FACE=3D"MS Sans =
Serif">'[e-mail]'</FONT>
<BR><B><FONT SIZE=3D1 FACE=3D"MS Sans Serif">Subject:</FONT></B> =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT SIZE=3D1 FACE=3D"MS Sans =
Serif">RE: Deprecate the NR bit?</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">I agree with Stefan.&nbsp; While an NR =
bit is appropriately sourced within a PKIX</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">infrastructure (representing, in a =
protected manner, an assertion by an</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">issuing CA), it's primarily consumed =
above the infrastructure.&nbsp; Its</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">consumption and semantics will depend =
on operational environments and their</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">policies.&nbsp; </FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">Consensus hasn't yet become apparent =
on identifying all of the</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">characteristics which PKI-supported =
NR services might possess, or in</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">organizing those characteristics into =
an ordering.&nbsp; In advance of that</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">process (which could be slow to =
converge), I think that PKIX should retain</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">RFC-2459's current treatment of the =
bit.&nbsp; I believe the binary switch is</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">useful and appropriate to distinguish =
between classes of intended usages;</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">this seems a valuable first-level =
indicator which may be appropriately</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">complemented in future by additional, =
finer-grained attributes. </FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">--jl</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">&gt; -----Original Message-----</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; From: Stefan Santesson =
[</FONT><U><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Arial"><A =
HREF=3D"mailto:[e-mail]">mailto:[e-mail]</A></FONT><=
/U><FONT SIZE=3D2 FACE=3D"Arial">]</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; Sent: Friday, August 27, 1999 =
10:05 AM</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; To: William Flanigan; Bob =
Jueneman</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; Cc: [e-mail]; =
[e-mail]</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; Subject: Re: Deprecate the NR =
bit?</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; </FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; </FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; I must admit that I have not =
followed everything said </FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; regarding the NR-bit</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; on this list, but I'm not =
surprised that PKIX can't provide a common</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; understanding on what NR is in =
detail.</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; </FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; In fact I don't think PKIX =
should even try to do that, other </FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; than in the</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; very general context that has =
already been done in RFC 2459.</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; </FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; This does not mean that the bit =
is useless and should be </FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; deprecated. The NR</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; bit belongs in a much wider =
context totally above the PKIX </FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; level. The fact</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; is also that the NR-bit is used =
in many higher level context </FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; with success.</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; If you would deprecate the bit =
you would force them to be </FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; non-compliant to</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; PKIX.</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; </FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; It is up to higher level of =
system design to provide the </FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; exact semantics of</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; this bit, presumably in =
combination with some defined </FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; electronic signature</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; policy. And then its up to the =
lawyers and judges to judge </FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; the outcome of</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; this higher level =
context.</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; </FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; So I would rather deprecate this =
discussion within PKIX then </FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; deprecate the bit.</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; </FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; /Stefan</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; </FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; At 09:39 AM 8/27/99 -0400, =
William Flanigan wrote:</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; &gt;Now, this makes sense!&nbsp; =
What do others feel?</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; &gt;</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; &gt;Bob Jueneman wrote:</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; &gt;</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; &gt;[snip]</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; &gt;&gt; </FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; &gt;&gt; My sense is that =
tempers are fraying, everyone's patience </FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; is wearing</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; &gt;&gt; decidedly thin, and =
that the group is getting quite </FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; frustrated by the</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; &gt;&gt; fact that we haven't =
been able to identify any single, reasonably</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; &gt;&gt; simple definition for =
what we mean by NR.</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; &gt;&gt; </FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; &gt;&gt; If that is the case, I =
believe we should deprecate the NR </FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; bit within</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; &gt;&gt; PKIX, and then charter =
another WG to explore the </FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; interaction between</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; &gt;&gt; the certificate =
contents, application (as opposed to </FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; protocol) behavior,</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; &gt;&gt; and the business and =
legal issues involved with signed documents.</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; &gt;&gt; </FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; &gt;&gt; Bob</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; </FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; =
-------------------------------------------------------------------</FON=
T>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; 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 FACE=3D"Arial">&gt; Accurata =
AB&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</FONT><U> <FONT =
COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Arial"><A =
HREF=3D"http://www.accurata.se" =
TARGET=3D"_blank">http://www.accurata.se</A></FONT></U>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; =
Slagthuset&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&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 FACE=3D"Arial">&gt; 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 FACE=3D"Arial">&gt; =
Sweden&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
 Mobile [phone]</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; </FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; PGP fingerprint: 89BC 6C79 5B3D =
591B 8547&nbsp; 1512 7D11 DBF4 528F 29A0</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; =
-------------------------------------------------------------------</FON=
T>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; </FONT>
</P>
</UL>
</BODY>
</HTML>
------_=_NextPart_001_01BEF0AC.4D5E6C6C--


Received: from www.elftech.com (router1.cm2.com [207.195.131.22] (may be forged)) by mail.proper.com (8.9.3/8.9.3) with ESMTP id JAA01472 for <[e-mail]>; Fri, 27 Aug 1999 09:35:24 -0700 (PDT)
From: [e-mail]
Subject: Re: Deprecate the NR bit?
To: [e-mail]
Cc: [e-mail]
X-Mailer: Lotus Notes Release 5.0  March 30, 1999
Date: Fri, 27 Aug 1999 16:36:14 GMT
Message-ID: <[e-mail]>
X-Priority: 3 (Normal)
X-MIMETrack: Serialize by Router on Stratos/LXN(Release 5.0a |May 4, 1999) at 08/27/99 09:34:49 AM
MIME-Version: 1.0
Content-type: text/plain; charset=us-ascii

I concur that it is at a higher level that the application of the NR bit
must be determined, but without deprecating it. The general context in
RFC2459 provides a workable starting point for a much broader discussion
context which involves digital signatures, legal intent, legal identity,
and eventually case law.

JohnDavid

Bob Jueneman wrote:

[snip]
>
> My sense is that tempers are fraying, everyone's patience is wearing
> decidedly thin, and that the group is getting quite frustrated by the
> fact that we haven't been able to identify any single, reasonably
> simple definition for what we mean by NR.
>
> If that is the case, I believe we should deprecate the NR bit within
> PKIX, and then charter another WG to explore the interaction between
> the certificate contents, application (as opposed to protocol) behavior,
> and the business and legal issues involved with signed documents.
>
> Bob

--------------------------
Dr. JohnDavid Hascup            [e-mail]
Internet Systems Administrator  http://www.elftech.com
ELF Technologies                Tel. [phone]
Mercer Island, WA               Fax. [phone]






Received: from tholian.securitydynamics.com (tholian.securid.com [204.167.112.129]) by mail.proper.com (8.9.3/8.9.3) with SMTP id JAA01043 for <[e-mail]>; Fri, 27 Aug 1999 09:30:48 -0700 (PDT)
Received: from sdtihq24.securitydynamics.com by tholian.securitydynamics.com via smtpd (for imc.org [206.184.129.134]) with SMTP; 27 Aug 1999 16:32:07 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 MAA02804; Fri, 27 Aug 1999 12:28:15 -0400 (EDT)
Received: by exna00.securitydynamics.com with Internet Mail Service (5.5.2232.9) id <RR6A2JZN>; Fri, 27 Aug 1999 12:34:20 -0400
Message-ID: <[e-mail]>
From: "Linn, John" <[e-mail]>
To: "'Stefan Santesson'" <[e-mail]>
Cc: "'[e-mail]'" <[e-mail]>
Subject: RE: Deprecate the NR bit?
Date: Fri, 27 Aug 1999 12:38:25 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2232.9)
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by mail.proper.com id JAA01046

I agree with Stefan.  While an NR bit is appropriately sourced within a PKIX
infrastructure (representing, in a protected manner, an assertion by an
issuing CA), it's primarily consumed above the infrastructure.  Its
consumption and semantics will depend on operational environments and their
policies.  

Consensus hasn't yet become apparent on identifying all of the
characteristics which PKI-supported NR services might possess, or in
organizing those characteristics into an ordering.  In advance of that
process (which could be slow to converge), I think that PKIX should retain
RFC-2459's current treatment of the bit.  I believe the binary switch is
useful and appropriate to distinguish between classes of intended usages;
this seems a valuable first-level indicator which may be appropriately
complemented in future by additional, finer-grained attributes. 

--jl

> -----Original Message-----
> From: Stefan Santesson [mailto:[e-mail]]
> Sent: Friday, August 27, 1999 10:05 AM
> To: William Flanigan; Bob Jueneman
> Cc: [e-mail]; [e-mail]
> Subject: Re: Deprecate the NR bit?
> 
> 
> I must admit that I have not followed everything said 
> regarding the NR-bit
> on this list, but I'm not surprised that PKIX can't provide a common
> understanding on what NR is in detail.
> 
> In fact I don't think PKIX should even try to do that, other 
> than in the
> very general context that has already been done in RFC 2459.
> 
> This does not mean that the bit is useless and should be 
> deprecated. The NR
> bit belongs in a much wider context totally above the PKIX 
> level. The fact
> is also that the NR-bit is used in many higher level context 
> with success.
> If you would deprecate the bit you would force them to be 
> non-compliant to
> PKIX.
> 
> It is up to higher level of system design to provide the 
> exact semantics of
> this bit, presumably in combination with some defined 
> electronic signature
> policy. And then its up to the lawyers and judges to judge 
> the outcome of
> this higher level context.
> 
> So I would rather deprecate this discussion within PKIX then 
> deprecate the bit.
> 
> /Stefan
> 
> At 09:39 AM 8/27/99 -0400, William Flanigan wrote:
> >Now, this makes sense!  What do others feel?
> >
> >Bob Jueneman wrote:
> >
> >[snip]
> >> 
> >> My sense is that tempers are fraying, everyone's patience 
> is wearing
> >> decidedly thin, and that the group is getting quite 
> frustrated by the
> >> fact that we haven't been able to identify any single, reasonably
> >> simple definition for what we mean by NR.
> >> 
> >> If that is the case, I believe we should deprecate the NR 
> bit within
> >> PKIX, and then charter another WG to explore the 
> interaction between
> >> the certificate contents, application (as opposed to 
> protocol) behavior,
> >> and the business and legal issues involved with signed documents.
> >> 
> >> Bob
> 
> -------------------------------------------------------------------
> 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 edelweb.fr (edelweb.fr [193.51.12.16]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id JAA28764 for <[e-mail]>; Fri, 27 Aug 1999 09:14:44 -0700 (PDT)
Received: from champagne.edelweb.fr (localhost.edelweb.fr [127.0.0.1]) by edelweb.fr with ESMTP id SAA16303; Fri, 27 Aug 1999 18:16:25 +0200 (MET DST)
Received: from champagne.edelweb.fr (champagne.edelweb.fr [193.51.14.161]) by edelweb.fr (nospam/1.1); Fri, 27 Aug 1999 18:16:25 +0200 (MET DST)
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 SAA10849; Fri, 27 Aug 1999 18:16:24 +0200 (MET DST)
From: Peter Sylvester <[e-mail]>
Received: (sylvest@localhost) by emeriau.edelweb.fr (8.7.6/8.6.6) id SAA05002; Fri, 27 Aug 1999 18:16:24 +0200 (MET DST)
Date: Fri, 27 Aug 1999 18:16:24 +0200 (MET DST)
Message-Id: <[e-mail]>
To: [e-mail]
Subject: RE: apologies and comments on SCVP
Cc: [e-mail]

I think that some of the SCVP discussion are like arguing
how to use a special version of a car, about your capablities
to drive, traffic jams, etc but your real intention is to find
an appropriate way to get somewhere.  

A user or even a client may not be interested per se in a
certificate chain or tree, the end application may need
a decision whether a given signature on a document is good
or whether a user is allowed to sign with its signature cert, 
or whether an encryption cert is good. These technical terms here
are in fact wrong, the user want to know who has signed a doc
and whether the signer was authorised, or to be sure that
he can exchange data in a confidential way with some partner etc.

> 
> So by and large, the CPU speed for such applications is irrelevant, 
> and it is very difficult to imagine an application that couldn't verify 
> a digital signature faster than it could send it off to a server to be
> done for it. So all really talking about is the amount of memory that is
> required, and it cost.
... 
> 
> Now of course, people probably have more memory in a digital watch than
> we used to have in mainframes back then, and a single chip contains 
> 1 to 4 megabytes or more, with very little discount for less memory.
> 
> So I'm still curious to learn exactly what kinds of applications really need 
> these functions, and what the business justification is.

The assumption is that the knowledge of how to validate a chain, the
cert chain, and the local company trusted root's and policies are
not available to the client. As soon as some online verification
is necessary, a one-shot proxy type doesn't seem such a bad idea.  

> 
> 
> > ClientType1 basically wants to be able to use public key
> > cryptography (and the PKIX infrastructure), without needing to
> > understand all of PKIX part1, OCSP, LDAP etc. It is outsourcing
> > the task of checking cert status, cert expiry, policy management
> > etc to the SCVP server. The main question ClientType1 is asking
> > is: "Hey, I got this cert, can I use it for application X?".
> > The minimal response the server needs to provide is a signed
> > yes/no. If you throw away all the extra stuff, you essentially
> > have the client sending in a cert and getting back a yes/no
> > answer.
> 
> Why is the best answer to this need a protocol instead of a library? It
> seems if this is a technical need, you could craft a nice library with
> simple APIs to do this.

I wonder whether someone remembers the discussion more than
a year ago about 'positive answers from OCSP'. There had
been several people who wanted a little bit more work to be
done by OCSP, especially the question of the availability 
of the signing CA cert. 

In fact, it is easy to slightly misuse OCSP and implement
whatever logic you want in the server. One could think about 
a kind of OCSP proxy or broker. 

OCSP provides an extension mecanism, thus the basic answer
of the OCSP would be the certificate chain, and in some
extension, the broker would return the actual responses
from other OCSP servers. 

In order to be syntactically conformant, a client can
always use a fake signing cert hash (or, in order to
be able to detect it, the cert of its broker.)

I gave up trying to ask extensions for OCSP shortly after
September last year after having read the DCS draft. 
 

Have fun.
Peter Sylvester


 



Received: from stingray.missi.ncsc.mil (stingray-ext.missi.ncsc.mil [144.51.50.20]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id JAA27443 for <[e-mail]>; Fri, 27 Aug 1999 09:02:17 -0700 (PDT)
Received: from stingray.missi.ncsc.mil (root@localhost) by stingray.missi.ncsc.mil with ESMTP id MAA04053 for <[e-mail]>; Fri, 27 Aug 1999 12:04:10 -0400 (EDT)
Received: from missi.ncsc.mil (depot.missi.ncsc.mil [144.51.60.1]) by stingray.missi.ncsc.mil with ESMTP id MAA04049 for <[e-mail]>; Fri, 27 Aug 1999 12:04:09 -0400 (EDT)
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 MAA09554 for <[e-mail]>; Fri, 27 Aug 1999 12:03:56 -0400 (EDT)
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 MAA28466 for <[e-mail]>; Fri, 27 Aug 1999 12:02:26 -0400 (EDT)
Message-Id: <[e-mail]>
Date: Fri, 27 Aug 1999 12:02:26 -0400 (EDT)
From: "David P. Kemp" <[e-mail]>
Reply-To: "David P. Kemp" <[e-mail]>
Subject: Re: Multi-national company listing issues
To: [e-mail]
MIME-Version: 1.0
Content-Type: TEXT/plain; charset=us-ascii
Content-MD5: o4iAj09EUO7Jpww2edk+hQ==
X-Mailer: dtmail 1.3.0 CDE Version 1.3 SunOS 5.7 sun4u sparc

> From: Paul Koning <[e-mail]>
> 
>  Bob> In other words, does country= qualify the organization or
>  Bob> person, or the location, or what?
> 
> There's one data point that might help.
> 
> If you want to obtain an NSAP address block (for ATM for example) one
> easy way is to get it under the DCC (Data Country Code) branch of the
> NSAP space.  Those are administered by national bodies in various
> countries; in the USA that is ANSI.
> 
> ANSI will assign a block under its DCC code to anyone who hands over
> the $1000.  The fact that your entry appears under the code that
> represents "USA" means simply that the assignment was made by the USA
> registrar.  It has NO other meaning.  In particular, it doesn't mean
> *any* of the things you suggested above.


The problem with the Subject field of a certificate is that we have
chosen to overload it with multiple purposes:

  1) a globally-unique, heirarchically registered identifier
  2) purely descriptive attributes (OU, L, SP, physical mail address, etc)
      intended for human consumption
  3) attributes that in addition to their uniqueness or descriptive
      properties are also interpreted by machine (email address for
      mail delivery, C as an indicator of nationality for purposes of
      restricting access, or even worse, a parenthetical (U) as part of
      a Common Name to indicate a security clearance level!)

As Bob Moskowitz said:

> So do what ever you want.  Either will work for your client, neither will
> work for a global lookup.

or in other words, we reap what we have sown.  Since clear guidelines
for populating and using the Subject field are not established, people
do whatever works for them.  Using "whatever works locally" is not the
optimum approach for achieving global interoperability.  "C" can be
the identifier of a registrar (ANSI in the case of C=US), or it can
be citizenship of a person, or it can be country of incorporation for
a person's employer, but it can't simultaneously be more than one of
these.

Last year there was a long discussion on using subject names in the form
of email addresses.  That works great as long as everyone understands
that "[e-mail]" is the name of a subject, and not necessarily the
place where joe's email is sent from or ultimately delivered to.

Personally, I would prefer the Subject DN to be exclusively a sequence
of registrar identifiers followed by a unique subject identifier, with
all other information in Subject Altname and Subject Directory
Attributes.  But that isn't the way most certs are issued today.



Received: from meridianus.com (209.249.223.39.has.no.reverse [209.249.223.39] (may be forged)) by mail.proper.com (8.9.3/8.9.3) with ESMTP id IAA25181 for <[e-mail]>; Fri, 27 Aug 1999 08:30:27 -0700 (PDT)
Received: from PC1 by  meridianus.com (8.8.8+Sun/SMI-SVR4) id JAA05421; Fri, 27 Aug 1999 09:25:16 -0700 (PDT)
Message-ID: <02b401bef0a3$80351310$[e-mail]>
From: "todd Glassey" <[e-mail]>
To: "William Flanigan" <[e-mail]>, "Bob Jueneman" <[e-mail]>
Cc: <[e-mail]>, <[e-mail]>
References: <[e-mail]> <[e-mail]>
Subject: Re: Deprecate the NR bit?
Date: Fri, 27 Aug 1999 08:47:18 -0700
Organization: Meridianus/GMT
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.2918.2701
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2918.2701

Bob, I heartily agree! and this is easily a posture that the proposed WG on
e-tokens could take up as Evidentiary Process models and proposed use
models. Part of its applicability statements that are mandated with this
WG's submissions, this could easily fit in well here with a "recommended use
model" for such technologies.

I applaud the sense of unloading the use specific issues from the core
enablement so that the use models, the reason for the protocol's existing in
the first place, can finally be defined.

Seems to me that building the Cart before the Horse and spending all this
time arguing about whether the horse has three or four legs is all that we
have accomplished so far.

Lets pull up to 50,000 and look at what we are trying to accomplish so that
the total bounding of the use of the NR bit and the whole protocol can be
evaluated as to what it actually accomplishes and how it does that.

Todd
----- Original Message -----
From: William Flanigan <[e-mail]>
To: Bob Jueneman <[e-mail]>
Cc: <[e-mail]>; <[e-mail]>
Sent: Friday, August 27, 1999 6:39 AM
Subject: Re: Deprecate the NR bit?


> Now, this makes sense!  What do others feel?
>
> Bob Jueneman wrote:
>
> [snip]
> >
> > My sense is that tempers are fraying, everyone's patience is wearing
> > decidedly thin, and that the group is getting quite frustrated by the
> > fact that we haven't been able to identify any single, reasonably
> > simple definition for what we mean by NR.
> >
> > If that is the case, I believe we should deprecate the NR bit within
> > PKIX, and then charter another WG to explore the interaction between
> > the certificate contents, application (as opposed to protocol) behavior,
> > and the business and legal issues involved with signed documents.
> >
> > Bob
>



Received: from prv-mail20.provo.novell.com (prv-mail20.provo.novell.com [137.65.82.195]) by mail.proper.com (8.9.3/8.9.3) with SMTP id IAA24387 for <[e-mail]>; Fri, 27 Aug 1999 08:24:21 -0700 (PDT)
Received: from INET-PRV-Message_Server by prv-mail20.provo.novell.com with Novell_GroupWise; Fri, 27 Aug 1999 09:25:32 -0600
Message-Id: <[e-mail]>
X-Mailer: Novell GroupWise 5.5.2
Date: Fri, 27 Aug 1999 09:25:22 -0600
From: "Bob Jueneman" <[e-mail]>
To: <[e-mail]>
Cc: <[e-mail]>, <[e-mail]>, <[e-mail]>, <[e-mail]>, <[e-mail]>, <[e-mail]>
Subject: Citizenship of multi--national company employees  (Was: RE: Multi-national company listing issues)
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 mail.proper.com id IAA24391

Hmm. Let's see.

I've got a  "gastarbeiter" (temporary worker) working for Daimler-Chrysler
(who must have an incredible headache trying to sort out all of these
issues) who is working in Munich but who lives across the border in Austria
where houses are cheaper.

This worker's mother was Czechoslovakian and his father a citizen of the 
Georgian Republic of the old USSR, but he happened to
have been born in the UK while they were in school, after which they 
moved to Turkey. And just for the sake of argument lets say that the 
laws are such that he could claim citizenship in all three countries. 
But because he is an Orthodox Jew, he could also claim to be an Israeli
citizen. Unfortunately, he was drafted into the Turkish army, and as a result
effectively renounced his citizenship in the other countries at least as 
far as they were concerned.

Now, of course, Czechoslovakia no longer exists, so he is a stateless person until
he goes through the immigration process and becomes naturalized somewhere,
if he ever does.

Now tell me again what this has to do with his Distinguished Name?

My point is that citizenship is a (potentially multi-valued) attribute of a person,
and as a result is not well suited to being a name qualifier.

So "country=" should NOT imply citizenship.  Nor should it imply country-in-which-
an-organization-is-incorporated, nor a number of other things, either.

Country should be a qualifier for "stateOrProvince" or locality, exclusively.  If 
someone wants to know some other interesting fact, such as citizenship,
they should INVENT A NEW ATTRIBUTE, and not overburden the semantics 
of existing ones.

And generally, such interesting facts have relatively little reason to be in the DN.
It's arguable whether they should even be in the certificate. countryOfResidence
might make some sense, if you want to know where to send the sheriff to arrest
someone who defrauded you with his digital signature.

<Rant Off> :-)

Regards,

Bob


>>> "Flanigan, Bill" <[e-mail]> 08/27/99 06:04AM >>>
Bob,

	What about citizenship?  Where might it go?  Just in the DN?  So
that it can be
automated (and standard)?

Bill

> ----------
> From: 	Bob Jueneman[SMTP:[e-mail]] 
> Sent: 	Thursday, August 26, 1999 9:29 PM
> To: 	[e-mail]; [e-mail];
> [e-mail]; [e-mail];
> [e-mail]; [e-mail] 
> Subject: 	Multi-national company listing issues
> 
[snip]

> 3. Specify anything else you think might be useful to put in the
> certificate 
> in subjectAlternateNames, including e-mail names, organizational 
> names, etc., whether they are mapped to your directory or not.  Then
> specify
> aliases or whatever other database construct works in your directory
> to facilitate looking up entities by those names as required..
> 
[snip]

> Bob
> 
[snip]





Received: from homebase.htt-consult.com (homebase.htt-consult.com [208.235.169.130]) by mail.proper.com (8.9.3/8.9.3) with SMTP id IAA22299 for <[e-mail]>; Fri, 27 Aug 1999 08:02:47 -0700 (PDT)
Received: from rgm ([208.235.169.131]) by homebase.htt-consult.com ; Fri, 27 Aug 1999 11:04:44 -0500
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 
Date: Fri, 27 Aug 1999 11:01:45 -0400
To: Paul Koning <[e-mail]>, [e-mail]
From: Robert Moskowitz <[e-mail]>
Subject: Re: Multi-national company listing issues
Cc: [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"

At 10:48 AM 8/27/1999 -0400, Paul Koning wrote:
>
>If you want to obtain an NSAP address block (for ATM for example) one
>easy way is to get it under the DCC (Data Country Code) branch of the
>NSAP space.  Those are administered by national bodies in various
>countries; in the USA that is ANSI.
>
>ANSI will assign a block under its DCC code to anyone who hands over
>the $1000.  The fact that your entry appears under the code that
>represents "USA" means simply that the assignment was made by the USA
>registrar.  It has NO other meaning.  In particular, it doesn't mean
>*any* of the things you suggested above.  (I suppose another way to
>put it is "it's totally useless"...)
>
This is what GM supposedly did, according to my friend, but he quoted a
$1200 fee.  Maybe it came down.  GM basically ignores everything about
o=GeneralMotors.


Robert Moskowitz
ICSA
Security Interest EMail: [e-mail]


Received: from prv-mail20.provo.novell.com (prv-mail20.provo.novell.com [137.65.82.195]) by mail.proper.com (8.9.3/8.9.3) with SMTP id HAA21140 for <[e-mail]>; Fri, 27 Aug 1999 07:48:46 -0700 (PDT)
Received: from INET-PRV-Message_Server by prv-mail20.provo.novell.com with Novell_GroupWise; Fri, 27 Aug 1999 08:49:57 -0600
Message-Id: <[e-mail]>
X-Mailer: Novell GroupWise 5.5.2
Date: Fri, 27 Aug 1999 08:49:53 -0600
From: "Bob Jueneman" <[e-mail]>
To: <[e-mail]>, <[e-mail]>
Cc: <[e-mail]>
Subject: RE: apologies and comments on SCVP
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 mail.proper.com id HAA21141

Nicely put, Mary Ellen, and a fair question.

It reminds me of some of the early SPKI justification, which put
a very high value on ease of implementation, as though Internet
protocols and applications were still being written by slave-labor 
grad students with few if any tools (such as ASN.1 compilers
or libraries).

Protocols are very expensive.  They take network resources,
where someone, at least, is effectively paying by the bit,
over and over again.  And protocols necessarily introduce
latency into the World Wide Wait-a-little-longer. And they burden
servers or other concentration points with computational demands
that are expensive and not easily met.

Libraries, on the other hand, are purchased, not rented, and after
depreciating the NRE are quite economical.  And because 
those libraries only have to service one human user, who can
only push the bottoms so fast, they really don't have to be all that
speedy. (I remember when I thought that 1200 baud was incredibly
fast, because I had difficulty keeping up with the incoming messages 
on the screen.)

So by and large, the CPU speed for such applications is irrelevant, 
and it is very difficult to imagine an application that couldn't verify 
a digital signature faster than it could send it off to a server to be
done for it. So all really talking about is the amount of memory that is
required, and it cost.

More than 30 years ago, one of my IBM-SRI instructors was preaching 
that despite the fact that IBM priced their machines as a percentage of 
component cost, and therefore adding more memory added a lot to the 
price of a computer, the development cost of trying to shoehorn applications
into too small memories was a lot more costly.

Now of course, people probably have more memory in a digital watch than
we used to have in mainframes back then, and a single chip contains 
1 to 4 megabytes or more, with very little discount for less memory.

So I'm still curious to learn exactly what kinds of applications really need 
these functions, and what the business justification is.

Bob

>>> <[e-mail]> 08/27/99 05:54AM >>>
Hi Ambarish,

> ClientType1 basically wants to be able to use public key
> cryptography (and the PKIX infrastructure), without needing to
> understand all of PKIX part1, OCSP, LDAP etc. It is outsourcing
> the task of checking cert status, cert expiry, policy management
> etc to the SCVP server. The main question ClientType1 is asking
> is: "Hey, I got this cert, can I use it for application X?".
> The minimal response the server needs to provide is a signed
> yes/no. If you throw away all the extra stuff, you essentially
> have the client sending in a cert and getting back a yes/no
> answer.

Why is the best answer to this need a protocol instead of a library? It
seems if this is a technical need, you could craft a nice library with
simple APIs to do this.
     Mez




Received: from dfw7-1.relay.mail.uu.net (dfw7-1.relay.mail.uu.net [199.171.54.106]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id HAA20907 for <[e-mail]>; Fri, 27 Aug 1999 07:47:24 -0700 (PDT)
Received: from xedia.com by dfw7sosrv11.alter.net with SMTP  (peer crosschecked as: madway.xedia.com [198.202.232.199]) id QQhebz00393; Fri, 27 Aug 1999 14:48:58 GMT
Received: from tonga.xedia.com by xedia.com (4.1/SMI-4.1) id AA06794; Fri, 27 Aug 99 10:47:25 EDT
Received: by tonga.xedia.com (SMI-8.6/SMI-SVR4) id KAA14213; Fri, 27 Aug 1999 10:48:57 -0400
Date: Fri, 27 Aug 1999 10:48:57 -0400
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], [e-mail]
Subject: Re: Multi-national company listing issues
References: <[e-mail]>
X-Mailer: VM 6.34 under 20.3 "Vatican City" XEmacs  Lucid

>>>>> "Bob" == Bob Jueneman <[e-mail]> writes:

 Bob> For example, is "C=" the country where the parent is located,
 Bob> where the subsidiary is located, where the tiny field office is
 Bob> located, where they are incorporated (think of a ship with
 Bob> Liberian registry), etc., etc.?

 Bob> In the case of an individual user, is the country where he was
 Bob> born (or adopted)? Where he is currently a citizen (what about
 Bob> dual citizenship, stateless persons, and nomads)?  Where he
 Bob> maintains a residence (or maybe a domicile)?  Where he works (I
 Bob> assume some people work in one country and sleep in another,
 Bob> every day)?

 Bob> In other words, does country= qualify the organization or
 Bob> person, or the location, or what?

There's one data point that might help.

If you want to obtain an NSAP address block (for ATM for example) one
easy way is to get it under the DCC (Data Country Code) branch of the
NSAP space.  Those are administered by national bodies in various
countries; in the USA that is ANSI.

ANSI will assign a block under its DCC code to anyone who hands over
the $1000.  The fact that your entry appears under the code that
represents "USA" means simply that the assignment was made by the USA
registrar.  It has NO other meaning.  In particular, it doesn't mean
*any* of the things you suggested above.  (I suppose another way to
put it is "it's totally useless"...)

	paul


Received: from popmail.inbox.se (popmail.inbox.se [193.12.72.101]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id HAA17080 for <[e-mail]>; Fri, 27 Aug 1999 07:03:18 -0700 (PDT)
Received: from stefan2 (accurata.inbox.se [193.12.72.24]) by popmail.inbox.se (8.9.3/8.9.3) with SMTP id QAA12056; Fri, 27 Aug 1999 16:04:47 +0200
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 
Date: Fri, 27 Aug 1999 16:05:07 +0200
To: William Flanigan <[e-mail]>, Bob Jueneman <[e-mail]>
From: Stefan Santesson <[e-mail]>
Subject: Re: Deprecate the NR bit?
Cc: [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 mail.proper.com id HAA17081

I must admit that I have not followed everything said regarding the NR-bit
on this list, but I'm not surprised that PKIX can't provide a common
understanding on what NR is in detail.

In fact I don't think PKIX should even try to do that, other than in the
very general context that has already been done in RFC 2459.

This does not mean that the bit is useless and should be deprecated. The NR
bit belongs in a much wider context totally above the PKIX level. The fact
is also that the NR-bit is used in many higher level context with success.
If you would deprecate the bit you would force them to be non-compliant to
PKIX.

It is up to higher level of system design to provide the exact semantics of
this bit, presumably in combination with some defined electronic signature
policy. And then its up to the lawyers and judges to judge the outcome of
this higher level context.

So I would rather deprecate this discussion within PKIX then deprecate the bit.

/Stefan

At 09:39 AM 8/27/99 -0400, William Flanigan wrote:
>Now, this makes sense!  What do others feel?
>
>Bob Jueneman wrote:
>
>[snip]
>> 
>> My sense is that tempers are fraying, everyone's patience is wearing
>> decidedly thin, and that the group is getting quite frustrated by the
>> fact that we haven't been able to identify any single, reasonably
>> simple definition for what we mean by NR.
>> 
>> If that is the case, I believe we should deprecate the NR bit within
>> PKIX, and then charter another WG to explore the interaction between
>> the certificate contents, application (as opposed to protocol) behavior,
>> and the business and legal issues involved with signed documents.
>> 
>> Bob

-------------------------------------------------------------------
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 gatekeeper.entrust.com (gatekeeper.entrust.com [204.101.128.170]) by mail.proper.com (8.9.3/8.9.3) with SMTP id GAA15849 for <[e-mail]>; Fri, 27 Aug 1999 06:49:29 -0700 (PDT)
Received: 	id JAA25223; Fri, 27 Aug 1999 09:44:06 -0400
Received: by gateway id <NP65MQYT>; Fri, 27 Aug 1999 09:46:45 -0400
Message-ID: <[e-mail]>
From: Sharon Boeyen <[e-mail]>
To: "'[e-mail]'" <[e-mail]>, Hans Nilsson <[e-mail]>
Cc: [e-mail]
Subject: RE: CRL version number discrepancy
Date: Fri, 27 Aug 1999 09:46:43 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2448.0)
Content-Type: text/plain; charset="iso-8859-1"

Here are the details from the X.509 side:

This correction to X.509 is being made, as agreed at the April 1999 meeting,
through defect report DR 220. The nature of the defect is described as:

"The current text requires that, if no extensions defined as critical are
included 
in a CRL, the version element be absent from that CRL. While this may be
helpful 
in some environments where backward compatibility with version 1 CRLs, this
should 
not be mandatory behaviour. An issuer should be able to mark its CRL as v2 
regardless of whether or not critical extensions are present. Note that some

profiles (e.g. PKIX) require that all CRLs be v2."

The changes to the text are currently under ballot and contained in DTC 3 to

the 97 X.509 text and read as follows:

In Note 3, in the second sentence replace "shall be absent" with "may be
absent".

In Note 3, at the beginning of the 3rd sentence, replace "This may permit"
with 
"If version is absent, this may permit"

In Note 3, at the beginning of the 4th sentence, replace "An implementation
that 
supports version 2 (or greater) CRLs may" with "An implementation that
supports 
version 2 (or greater) CRLs, in the absence of version, may also" 

The ballot closes in early November and at this point we are not
anticipating
any problems with approval.

If anyone wants to see the documents themselves (defect report and DTC) here

are links to them:

ftp://ftp.bull.com/pub/OSIdirectory/DefectResolution/DefectReports/X.509/DR_
220
ftp://ftp.bull.com/pub/OSIdirectory/DefectResolution/DraftTechnicalCorrigend
a/X.509/8-DTC3(3rd).doc

Sharon
-----Original Message-----
From: [e-mail] [mailto:[e-mail]]
Sent: Wednesday, August 25, 1999 9:27 AM
To: Hans Nilsson
Cc: [e-mail]
Subject: Re: CRL version number discrepancy


actually we have had this debate. the text is correct in 509 but it was
considered an unnecessary complication in the pkix profile. the 509 text was
to
broaden the amount of interworking between different versions. i understood
the
pkix position to be that with minimal deployment of earlier versions, the
509
text didn't buy anything (other that possible confusion)

i (and the x500 group) considered the text still useful but decided to make
it
optional. the "shall" will be changed to a "may". this will allow a profile
to
broaden interaction if necessary. whatever pkix decides to do, there will be
no
conflict with the standard.

    hoyt




Hans Nilsson <[e-mail]> on 08/24/99 11:34:06 PM

To:   [e-mail]
cc:    (bcc: Hoyt Kesterson/US/BULL)
Subject:  CRL version number discrepancy




There is a discrepancy between X.509 and RFC 2459.

X.509 states:

If any extensions included in a CertificateList are defined as critical, the
version element of the CertificateList shall be present.  If no extensions
defined as critical are included, the version element shall be absent. This
may permit a implementation that only supports version 1 CRLs to still use
the CRL if in its examination of the revokedCertificates sequence in the
CRL, it does not encounter an extension. An implementation that supports
version 2 (or greater) CRLs may be able to optimize its processing if it can
determine early in processing that no critical extensions are present in the
CRL.

RFC 2459 states that:

Conforming CAs that issue CRLs MUST issue version 2 CRLs,

and, later,

When extensions are used, as required by this profile, this field MUST be
present and MUST specify version 2 (the integer value is 1.

The question is now:
When we issue CRLS with non-crictical extensions, should the version number
be omitted (according to X.509) or present and set to 2 (according to RFC
2459?

Until further notice, we regard X.509 as having precedence over RFC 2459. Is
this correct?

Regards
Hans Nilsson







Received: from rbhub101.chamb.disa.mil (rbhub101.chamb.disa.mil [209.22.120.24]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id GAA14121 for <[e-mail]>; Fri, 27 Aug 1999 06:38:39 -0700 (PDT)
Received: from ncr.disa.mil (cpkig19.ncr.disa.mil [164.117.206.180]) by rbhub101.chamb.disa.mil with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.10) id R3HZFQ54; Fri, 27 Aug 1999 09:41:11 -0400
Message-ID: <[e-mail]>
Date: Fri, 27 Aug 1999 09:39:57 -0400
From: William Flanigan <[e-mail]>
X-Mailer: Mozilla 4.61 [en] (WinNT; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Bob Jueneman <[e-mail]>
CC: [e-mail], [e-mail]
Subject: Re: Deprecate the NR bit?
References: <[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Now, this makes sense!  What do others feel?

Bob Jueneman wrote:

[snip]
> 
> My sense is that tempers are fraying, everyone's patience is wearing
> decidedly thin, and that the group is getting quite frustrated by the
> fact that we haven't been able to identify any single, reasonably
> simple definition for what we mean by NR.
> 
> If that is the case, I believe we should deprecate the NR bit within
> PKIX, and then charter another WG to explore the interaction between
> the certificate contents, application (as opposed to protocol) behavior,
> and the business and legal issues involved with signed documents.
> 
> Bob


Received: from rbhub100.chamb.disa.mil (rbhub100.chamb.disa.mil [209.22.120.23]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id EAA03337 for <[e-mail]>; Fri, 27 Aug 1999 04:59:30 -0700 (PDT)
Received: by rbhub100.chamb.disa.mil with Internet Mail Service (5.5.2650.10) id <RWBSC7Y9>; Fri, 27 Aug 1999 08:01:09 -0400
Message-ID: <[e-mail]>
From: "Flanigan, Bill" <[e-mail]>
To: "'Bob Jueneman'" <[e-mail]>
Cc: [e-mail], [e-mail], [e-mail], [e-mail], [e-mail], [e-mail]
Subject: Citizenship of multi--national company employees  (Was: RE: Multi -national company listing issues)
Date: Fri, 27 Aug 1999 08:04:50 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.10)
Content-Type: text/plain

Bob,

	What about citizenship?  Where might it go?  Just in the DN?  So
that it can be
automated (and standard)?

Bill

> ----------
> From: 	Bob Jueneman[SMTP:[e-mail]]
> Sent: 	Thursday, August 26, 1999 9:29 PM
> To: 	[e-mail]; [e-mail];
> [e-mail]; [e-mail];
> [e-mail]; [e-mail]
> Subject: 	Multi-national company listing issues
> 
[snip]

> 3. Specify anything else you think might be useful to put in the
> certificate 
> in subjectAlternateNames, including e-mail names, organizational 
> names, etc., whether they are mapped to your directory or not.  Then
> specify
> aliases or whatever other database construct works in your directory
> to facilitate looking up entities by those names as required..
> 
[snip]

> Bob
> 
[snip]




Received: from arista.iris.com (arista.iris.com [198.112.211.22]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id EAA03096 for <[e-mail]>; Fri, 27 Aug 1999 04:51:04 -0700 (PDT)
From: [e-mail]
Subject: RE: apologies and comments on SCVP
To: "Ambarish Malpani" <[e-mail]>
Cc: [e-mail]
X-Mailer: Lotus Notes Release 5.0.1 July 16, 1999
Message-ID: <[e-mail]>
Date: Fri, 27 Aug 1999 07:54:55 -0400
X-Priority: 3 (Normal)
X-MIMETrack: Serialize by Router on Arista/Iris(Build V5010621|June 21, 1999) at 08/27/99 07:52:52 AM
MIME-Version: 1.0
Content-type: text/plain; charset=us-ascii

Hi Ambarish,

> ClientType1 basically wants to be able to use public key
> cryptography (and the PKIX infrastructure), without needing to
> understand all of PKIX part1, OCSP, LDAP etc. It is outsourcing
> the task of checking cert status, cert expiry, policy management
> etc to the SCVP server. The main question ClientType1 is asking
> is: "Hey, I got this cert, can I use it for application X?".
> The minimal response the server needs to provide is a signed
> yes/no. If you throw away all the extra stuff, you essentially
> have the client sending in a cert and getting back a yes/no
> answer.

Why is the best answer to this need a protocol instead of a library? It
seems if this is a technical need, you could craft a nice library with
simple APIs to do this.
     Mez



Received: from ext-mail.valicert.com (ns1.valicert.com [63.65.221.10]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id UAA12916 for <[e-mail]>; Thu, 26 Aug 1999 20:32:02 -0700 (PDT)
Received: from int-mail.valicert.com (corporate-gw.valicert.com [63.65.221.2]) by ext-mail.valicert.com (8.9.3/8.9.3) with ESMTP id UAA00044; Thu, 26 Aug 1999 20:33:48 -0700 (PDT)
Received: from rhone (rhone.valicert.com [192.168.3.128]) by int-mail.valicert.com (8.9.3/8.9.3) with SMTP id UAA22560; Thu, 26 Aug 1999 20:33:44 -0700 (PDT)
From: "Ambarish Malpani" <[e-mail]>
To: <[e-mail]>, "'Alan Lloyd'" <[e-mail]>, <[e-mail]>
Subject: RE: apologies and comments on SCVP
Date: Thu, 26 Aug 1999 20:36:45 -0700
Message-ID: <00e101bef03d$637a8e00$[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
Importance: Normal
In-Reply-To: <[e-mail]>

Hi Tom,
    Fair question. I think I have tried to answer it before, let
me try again.

There are 2 application classes for SCVP:
1. ClientType1
2. ClientType2

(I have purposely chosen *not* to try and use more descriptive
names for the clients, to avoid digressive discussions).

ClientType1 basically wants to be able to use public key
cryptography (and the PKIX infrastructure), without needing to
understand all of PKIX part1, OCSP, LDAP etc. It is outsourcing
the task of checking cert status, cert expiry, policy management
etc to the SCVP server. The main question ClientType1 is asking
is: "Hey, I got this cert, can I use it for application X?".
The minimal response the server needs to provide is a signed
yes/no. If you throw away all the extra stuff, you essentially
have the client sending in a cert and getting back a yes/no
answer.

ClientType2, is basically getting the server to build all the
chains, get validation responses etc., but checks all the
responses itself - it isn't trusting the work done by the
server, but using it mainly as somebody to offload the work to,
which it then verifies.

My main push is for serving the needs of ClientType1, just
because I believe it opens up PKI to a lot more applications.

Now to get to your main question about what is the difference
between the OCSP and SCVP.

In OCSP, all you are getting is the status of a certificate.
The client *must* build the chain - because it needs to tell
the responder which CA it is talking about. So, OCSP requires
the client to do the chain building, cert date/signature checking,
policy checking etc. The main thing the responder is doing,
is telling you the status of the certificate.

Does this help clarify the differences?

Regards,
Ambarish

---------------------------------------------------------------------
Ambarish Malpani
Architect                                                650.567.5457
ValiCert, Inc.                                  [e-mail]
1215 Terra Bella Ave.                         http://www.valicert.com
Mountain View, CA 94043-1833


> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]]
> Sent: Thursday, August 26, 1999 8:07 AM
> To: Alan Lloyd; [e-mail]
> Subject: Re: apologies and comments on SCVP
> 
> 
>      Alan,
> 
>      I frequently feel that you are too strongly committed to 
> the idea that DAP
> is superior to LDAP.  I would agree that at this point, 
> LDAP's main advantage is
> not that it's lighter weight as a protocol but that it runs over a
> lighter-weight and more widely distributed protocol stack - 
> maybe we should call
> it TDAP for TCP/IP DAP, and also that a TDSP would help 
> matters greatly (and I
> don't mean one with OSI layers 5 and 6 intact running over 
> port 102 either).
>      However, I do think you have a strong point here.  What 
> are the functional
> and trust differences between OCSP and SCVP, and what will keep SCVP
> significantly lighter-weight than OCSP once the requirements 
> types start in on
> it?  Ambarish, could you explain this to us or to the group 
> as a whole?  If
> there are no good answers to this, why should we have a clone 
> of OCSP when there
> is no networking technology advantage such as LDAP has over 
> DAP to carry the new
> one to success?
> 
>           Tom Gindin
> 
> 


Received: from homebase.htt-consult.com (homebase.htt-consult.com [208.235.169.130]) by mail.proper.com (8.9.3/8.9.3) with SMTP id TAA07919 for <[e-mail]>; Thu, 26 Aug 1999 19:48:50 -0700 (PDT)
Received: from rgm ([208.235.169.131]) by homebase.htt-consult.com ; Thu, 26 Aug 1999 22:50:32 -0500
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 
Date: Thu, 26 Aug 1999 22:49:02 -0400
To: "Bob Jueneman" <[e-mail]>, "'[e-mail]'" <[e-mail]>, "Sweigert, David" <[e-mail]>, <[e-mail]>, "Alan Lloyd" <[e-mail]>, <[e-mail]>
From: Robert Moskowitz <[e-mail]>
Subject: Re: Multi-national company listing issues
In-Reply-To: <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"

At 07:29 PM 8/26/1999 -0600, Bob Jueneman wrote:
>
>For example, is "C=" the country where the parent
>is located, where the subsidiary is located, where the
>tiny field office is located, where they are incorporated 
>(think of a ship with Liberian registry), etc., etc.?
>
The directory person at GM (an old friend of mine) told me that GM went and
actually registered under C=US.  So the have C=US,O=GeneralMotors,OU(I
think)=DE(german divisions),OU=etc

And he can't change it.  This was set up long before he came on board.  It
is baked into so many systems...

Who was it that said, "if you want a clean slate, have a revolution'" ?


Robert Moskowitz
ICSA
Security Interest EMail: [e-mail]


Received: from prv-mail20.provo.novell.com (prv-mail20.provo.novell.com [137.65.82.195]) by mail.proper.com (8.9.3/8.9.3) with SMTP id TAA02888 for <[e-mail]>; Thu, 26 Aug 1999 19:05:39 -0700 (PDT)
Received: from INET-PRV-Message_Server by prv-mail20.provo.novell.com with Novell_GroupWise; Thu, 26 Aug 1999 20:06:39 -0600
Message-Id: <[e-mail]>
X-Mailer: Novell GroupWise 5.5.2
Date: Thu, 26 Aug 1999 19:29:05 -0600
From: "Bob Jueneman" <[e-mail]>
To: <[e-mail]>, <[e-mail]>, <[e-mail]>, <[e-mail]>, <[e-mail]>, <[e-mail]>
Subject: Multi-national company listing issues
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 mail.proper.com id TAA02889

I posted the following (modulo a few changes) to the 
ABA Information Security Committee list in response 
to David's request on this subject to that group:

David, having wrestled with these issues when I was 
still with GTE and involved with the NADF, and now 
even more that I am with Novell and tangentially involved 
with NDS, I wish you luck and a bottle of Excedrin.

This has been a train wreck about to happen for almost
ten years.  The semantics of the X.521 oxymoronic 
"useful definitions"  were completely inadequate even
when people were expecting the monopoly carriers to 
implement X.500, and they are even less helpful today,
when there is already a whole bunch of isolated island
directories that we would like to stitch together into
a certificate infrastructure.

For example, is "C=" the country where the parent
is located, where the subsidiary is located, where the
tiny field office is located, where they are incorporated 
(think of a ship with Liberian registry), etc., etc.?

In the case of an individual user, is the country where 
he was born (or adopted)? Where he is currently a citizen
(what about dual citizenship, stateless persons, and nomads)?
Where he maintains a residence (or maybe a domicile)?
Where he works (I assume some people work in one
country and sleep in another, every day)?

In other words, does country= qualify the organization 
or person, or the location, or what?

Nobody knows, and everyone does it differently.

If it matters, specify it in your CPS, since no one is going 
to read that anyway!

So here's my advice:

1.  Render unto Caesar that which is Caesar's. That is, let the system
administrator dictate what the DIT structure is going to look like,
since he will do what he wants to in any case.  Directory naming
is NOT based on legal principles, much less ISO recommendations,
but rather on physical connectivity and/ or organizational 
relationships that have relatively little to do with logic.  I wouldn't 
dare suggest that Novell change its internal directory structure, for
example, because even though I could certainly think of 
ways of improving it, it wouldn't be worth the effort.  And Novell
is only a 4000+ employee company -- think of GM, or the US Navy.
"Trying to change an already existing directory structure is like teaching
a pig to whistle. It's a waste of your time, and it annoys the pig."
In other words, "Fuggedaboudit"

2.  The DN in the certificate should be identical to the DN of the 
entity in the directory, even if this appears to be complete gibberish to 
someone on the outside of that organization's name space, e.g.,
"bjueneman.nsrd.prv.novell". This will at least simplify certificate 
mapping and retrieval within that directory.  Interconnections between
directories is probably going to have to be handled by some kind of a
meta-directory approach, or else by a URL-like directory qualification 
scheme.

3. Specify anything else you think might be useful to put in the certificate 
in subjectAlternateNames, including e-mail names, organizational 
names, etc., whether they are mapped to your directory or not.  Then specify
aliases or whatever other database construct works in your directory
to facilitate looking up entities by those names as required..

4. If it feels good, do it.  Don't let these issues get in the way 
of deploying a certificate infrastructure.

Trying to harmonize all of this stuff was too hard 10 years ago, 
and it's gotten harder yet since then. Computers are good at using 
databases to look up equivalences -- let's use them for that.

Bob




>>> Robert Moskowitz <[e-mail]> 08/26/99 12:06PM >>>
At 06:28 PM 8/24/1999 -0400, Sweigert, David wrote:

If I remember correctly, GM goes by country and then function.

Chrysler went by function and then country (don't know what DCX will do).

So do what ever you want.  Either will work for your client, neither will
work for a global lookup.

>
>As anyone grappling with the problem of defining a directory information
>tree for a multi-national company.  In other words, how do divisions in
>the UK and US relate in the DIT if both divisions are within one corporate
>organization; say MARKETING.
>
>Would this be appropriate:
>
>c=US
>o=GlobalCorp
>ou=Marketing
>
>and
>
>c=UK
>o=GlobalCorp
>ou=Marketing
>
>
>Any thoughts on this ?
>
>Dave Sweigert

Robert Moskowitz
ICSA
Security Interest EMail: [e-mail]


Received: from prv-mail20.provo.novell.com (prv-mail20.provo.novell.com [137.65.82.195]) by mail.proper.com (8.9.3/8.9.3) with SMTP id RAA20985 for <[e-mail]>; Thu, 26 Aug 1999 17:59:34 -0700 (PDT)
From: [e-mail]
Message-Id: <[e-mail]>
Received: from INET-PRV-Message_Server by prv-mail20.provo.novell.com with Novell_GroupWise; Thu, 26 Aug 1999 19:00:48 -0600
Mime-version: 1.0
Date: Thu, 26 Aug 1999 19:00:00 -0600
X-Mailer: Groupwise 5.5.2.1 (Beta)
Cc: [e-mail], Hans Nilsson<[e-mail]>, [e-mail], [e-mail]
Subject: Re: Pseudonym in Subject DN (in QC certificates)
To: "[e-mail]", [e-mail]
Content-type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="____UHWAGJANGVQPYREQXRLL____"

--____UHWAGJANGVQPYREQXRLL____
Content-type: text/plain; charset=iso-8859-1
Content-disposition: inline

Stefan,

I haven't commented on the proposed pseudonym attribute, having 
been busy trying to wrestle the "NR" alligator.

But I believe that defining a single attribute for pseudonym would be 
WRONG. Instead, I believe that we need a continuum of certificate 
classes that range from a complete pseudonym (the subscriber was 
wearing gloves when he pulled the handle on the certificate vending 
machine, to avoid leaving fingerprints), all the way up to a certificate 
that is issued as an act of state by a sovereign government, plus
everything in between.

Once you define an attribute for a pseudonym, then when someone 
comes along and needs to identify an individual whose identity is 
known by the CA but not disclosed in the certificate, or by a 
publicly-held and audited corporation, or a Licensed CA, or 
a State or Province, etc., etc., then the temptation will be to 
define yet another attribute.  This way lies madness, not to mention
a complete lack of interoperability.

I really believe that a somewhat sparsely populated list of certificate 
classes that identify the amount of due diligence that is invested into
the identity of the subscriber is a better way to go. Please see Appendix 
D, page 57, of our Novell Security Attributes document, available
at http://developer.novell.com/repository/attributes/certattrs_)v10.htm 
for more details and a reasonably well worked out list of such classes.
I would, of course, be happy to entertain suggestions for revisions and 
additions to that list.

Bob


>>> Stefan Santesson <[e-mail]> 08/26/99 07:41AM >>>
Regarding new attributes in the subject field in Qualified Certificates.

I've had several off list discussions regarding the pseudonym attribute in
the subject field of QC.

Everybody except one has been in favour of adding this attribute in the
subject field.

Pros are:
- Makes it easier to meet the EU directive directly by using just the
subject field without bending current X.509 definitions.
- Clearly defines when a name is based on a pseudonym
- RSA has offered to include this (and other PersonalData) attributes in PKCS#9

Cons are:
- Will require definition of new object classes for directory systems when
this attribute is used.

The cons are more and more fading away. Magnus Nyström at RSA wrote to me:

"Well, yes, one have to include this new attribute in the definition of a 
 new object class, or extend the definition of an existing class if one
 would like this to work well. But that was also my original intention - to
 include them in the 'pkcsEntity' auxiliary object class that is being
 defined in PKCS #9. Further, most directory products does support changes
 to the schema, and there are already several proposals being made in
 this area, e.g.:

 -Netscape's draft about "inetOrgPerson", published as
  'draft-smith-ldap-inetorgperson-03.txt'; and
 -Chadwick's draft regarding ldapv3 and PKIX
  (draft-ietf-pkix-ldap-v3-01.txt) which incorporates the 'pmiUser' object
  class which I doubt many directory products have built-in support for
  today.
 -RSA Laboratories "pkcsEntity" auxiliary object class, being defined in
  PKCS #9 v.2."

Taking this into consideration I think that we should go forward and
include the pseudonym attribute.
This will force us to expand the set of supported attributes compared to
RFC 2459 and also to add matching rules for this attribute. we will also
have to remove the option to allow a pseudonym to be stored in the
commonName attribute and instead say that this attribute SHALL be used to
store the subjects registered name in a preferred presentation format.
Nicknames and spelling other than the registered names are allowed as long
as they are related to the persons registered name.

Another consideration is to add the title attribute as a role attribute
since role has repeatedly become an issue within these types of
certificates. The text should declare that when this attribute is present
it SHALL define a role of the subject. I believe that this is consistent
with the attribute definition in X.520. This attribute is further already
on the list of supported attributes in RFC 2459.

Finally we should assign an OID to be optionally included in the
qcStatements extension, which declare that a certificate is compliant with
syntax and semantics definitions of this specification. Otherwise there
will be no way for a relying party to tell whether the certificate is
compliant with these definitions other than by understanding present policy
OID:s.

So if no serious objections are raised, I would like to go forward and
update the specification according to this proposal.

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

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

MIIJaQYJKoZIhvcNAQcCoIIJWjCCCVYCAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCCB6kw
ggMuMIICl6ADAgECAhEA0nYujRQMPX2yqCVdr+4NdTANBgkqhkiG9w0BAQIFADBfMQswCQYDVQQG
EwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xNzA1BgNVBAsTLkNsYXNzIDEgUHVibGljIFBy
aW1hcnkgQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkwHhcNOTgwNTEyMDAwMDAwWhcNMDgwNTEyMjM1
OTU5WjCBzDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0
IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEgSW5jb3Jw
LiBCeSBSZWYuLExJQUIuTFREKGMpOTgxSDBGBgNVBAMTP1ZlcmlTaWduIENsYXNzIDEgQ0EgSW5k
aXZpZHVhbCBTdWJzY3JpYmVyLVBlcnNvbmEgTm90IFZhbGlkYXRlZDCBnzANBgkqhkiG9w0BAQEF
AAOBjQAwgYkCgYEAu1pEigQWu1X9A3qKLZRPFXg2uA1Ksm+cVL+86HcqnbnwaLuV2TFBcHqBS7lI
E1YtxwjhhEKrwKKSq0RcqkLwgg4C6S/7wju7vsknCl22sDZCM7VuVIhPh0q/Gdr5FegPh7Yc48zG
mo5/aiSS4/zgZbqnsX7vyds3ashKyAkG5JkCAwEAAaN8MHowEQYJYIZIAYb4QgEBBAQDAgEGMEcG
A1UdIARAMD4wPAYLYIZIAYb4RQEHAQEwLTArBggrBgEFBQcCARYfd3d3LnZlcmlzaWduLmNvbS9y
ZXBvc2l0b3J5L1JQQTAPBgNVHRMECDAGAQH/AgEAMAsGA1UdDwQEAwIBBjANBgkqhkiG9w0BAQIF
AAOBgQCIuDc73dqUNwCtqp/hgQFxHpJqbS/28Z3TymQ43BuYDAeGW4UVag+5SYWklfEXfWe0fy0s
3ZpCnsM+tI6q5QsG3vJWKvozx74Z11NMw73I4xe1pElCY+zCphcPXVgaSTyQXFWjZSAA/Rgg5V+C
prGoksVYasGNAzzrw80FopCubjCCBHMwggPcoAMCAQICEF6mQzFngv6Wl+eGgC1QPt4wDQYJKoZI
hvcNAQEEBQAwgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBU
cnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIElu
Y29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENB
IEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQwHhcNOTkwNTExMDAw
MDAwWhcNMDAwNTEwMjM1OTU5WjCCARcxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQL
ExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9z
aXRvcnkvUlBBIEluY29ycC4gYnkgUmVmLixMSUFCLkxURChjKTk4MR4wHAYDVQQLExVQZXJzb25h
IE5vdCBWYWxpZGF0ZWQxNDAyBgNVBAsTK0RpZ2l0YWwgSUQgQ2xhc3MgMSAtIE1pY3Jvc29mdCBG
dWxsIFNlcnZpY2UxGDAWBgNVBAMUD1JvYmVydCBKdWVuZW1hbjEjMCEGCSqGSIb3DQEJARYUYmp1
ZW5lbWFuQG5vdmVsbC5jb20wgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBANW8HQNToKMy+VNz
L0IEq3SoWmSY2Qlsut0sMwe3fwzJR9DglDQApUf13tJZdU48ZNzRC16QkZs8nFM2gCyFAAv4QhfA
kYymhVqjrBiuNTs7K3O30W0ok6Nv6v/aokHIU6tAzLLuBMuayuN7sS58FDfcXwBvabN/ePIamR40
aQN5AgMBAAGjggEGMIIBAjAJBgNVHRMEAjAAMIGsBgNVHSAEgaQwgaEwgZ4GC2CGSAGG+EUBBwEB
MIGOMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vQ1BTMGIGCCsGAQUFBwIC
MFYwFRYOVmVyaVNpZ24sIEluYy4wAwIBARo9VmVyaVNpZ24ncyBDUFMgaW5jb3JwLiBieSByZWZl
cmVuY2UgbGlhYi4gbHRkLiAoYyk5NyBWZXJpU2lnbjARBglghkgBhvhCAQEEBAMCB4AwMwYDVR0f
BCwwKjAooCagJIYiaHR0cDovL2NybC52ZXJpc2lnbi5jb20vY2xhc3MxLmNybDANBgkqhkiG9w0B
AQQFAAOBgQBhbRmCI9CSHD2vYJOyQ9JsQ8NKDmTAKUY4qNwGXfsQcE+Wtr/vvhllfHscQ/JY4GM0
dvR2rYEq/I6nMk5Unlju527qbQYsVoA4FqRdcl1tGQRwBSsSPMS7qTmbnyujc1PA5dEjQRu9VVNj
pDiDc3nAcWFeb7SpjVmqzav5opJvizGCAYgwggGEAgEBMIHhMIHMMRcwFQYDVQQKEw5WZXJpU2ln
biwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZl
cmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFI
MEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29u
YSBOb3QgVmFsaWRhdGVkAhBepkMxZ4L+lpfnhoAtUD7eMAkGBSsOAwIaBQAwDQYJKoZIhvcNAQEB
BQAEgYByXYoAm7cG2Hjga/oB+n/rXyLPHgx1MDxsMvlyKJGzpbyLMU3/f4VSqiGiKQReLnMq2IWZ
Sd7uJ9B8jlRRWaAxtFcsaTEb4kknxle+TaIZS742iC18BcJlY0pEm/x8ynBh6QOvuIvF3Cq/otRd
zu8xk0DSOxDCPqRTdOTz9SJtpA==

--____UHWAGJANGVQPYREQXRLL____--


Received: from prv-mail20.provo.novell.com (prv-mail20.provo.novell.com [137.65.82.195]) by mail.proper.com (8.9.3/8.9.3) with SMTP id RAA20433 for <[e-mail]>; Thu, 26 Aug 1999 17:42:38 -0700 (PDT)
Received: from INET-PRV-Message_Server by prv-mail20.provo.novell.com with Novell_GroupWise; Thu, 26 Aug 1999 18:43:50 -0600
Message-Id: <[e-mail]>
X-Mailer: Novell GroupWise 5.5.2
Date: Thu, 26 Aug 1999 18:43:45 -0600
From: "Bob Jueneman" <[e-mail]>
To: <[e-mail]>, <[e-mail]>
Subject: Deprecate the NR bit?
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 mail.proper.com id RAA20434

Elliot,

I should have rechecked the text regarding the Critical bit.

As to the difference between "Alice" (what you call authentication,
which is semantically yet another deep pit) and the "Nancy Reagan"
bit, I would quibble just a bit.

What you call the "Alice" condition (NR=0) would seem to imply 
that the signature and certificate chain can be trusted for the 
duration of the certificate validity interval,, not just at the moment,
 assuming that the RP checks the CRL.  If the CRL says that 
everything is still fine, great.  Otherwise, the RP only knows that 
something may have gone wrong, but he may not know when.  
This is the retroactive "you should have gotten a timestamp on 
the signature and the next subsequent CRL to protect yourself"
condition.

The NR bit, and by implication the NR "service"  SEEMS to be 
promising that the RP doesn't have to worry, because the CA 
will keep the status of that certificate (not revoked prior to its 
expiration, or revoked as of date T for reason X) around in perpetuity.

My problem, among others having to do with user intent, etc., is that
I don't believe that such a service is credible. Seven years, just maybe,
but not much longer.  In any case, I believe that the Relying Party
is much better off archiving the CRLs along with the data itself,
than depending on the CA to still be around for that long.

My sense is that tempers are fraying, everyone's patience is wearing 
decidedly thin, and that the group is getting quite frustrated by the 
fact that we haven't been able to identify any single, reasonably 
simple definition for what we mean by NR.

If that is the case, I believe we should deprecate the NR bit within 
PKIX, and then charter another WG to explore the interaction between 
the certificate contents, application (as opposed to protocol) behavior,
and the business and legal issues involved with signed documents.

Bob


>>> Elliot Ginsburg <[e-mail]> 08/26/99 06:32AM >>>
Bob,

The reason I interpreted critical/non-critical the way I did is this
from X.509 keyUsage bit:
"This extension may, at the option of the certificate issuer, be either
critical or non-critical. 
If the extension is flagged critical, then the certificate shall be used
only for a purpose for which the corresponding key usage bit is set to
one. 
If the extension if flagged non-critical, then it indicates the intended
purpose or purposes of the key, and may be used in finding the correct
key/certificate of an entity that has multiple keys/certificates. It is
an advisory field and does not imply that usage of the key is restricted
to the purpose indicated. A bit set to zero indicates that the key is
not intended for that purpose. If all bits are zero, it indicates the
key is intended for some purpose other than those listed. "

As far as NR==0, here's what I meant. Since we can't agree on exactly
what NR means, we'll leave it to the replying party to know whether
he/she has access to a non-repudiation service.  But even if he/she
does, a cert with NR==0 can't be used for this purpose; a cert with
NR==1 is required. I don't think this is very interoperable across
security domains, however. 
Here's what I think the difference between authentication and NR is:
authentication lets me identify a transactor at this time;  NR, in
addition to the above, implies that I will be able to re-do that
authentication process, for that moment in time, for some significant
time into the future. NR probably requires archiving and the like,
although there are probably other ways to do it; authentication only
requires the ability to complete the validation in the present or near
present, not five years from now.
Yes, if we can't agree on what it means, then we should deprecate its
use.

Elliott N Ginsburg
CygnaCom Solutions
[e-mail] 
703-848-0883
703-848-0960(FAX)

> -----Original Message-----
> From:	Bob Jueneman [SMTP:[e-mail]] 
> Sent:	Wednesday, August 25, 1999 8:32 PM
> To:	[e-mail]; [e-mail] 
> Subject:	RE: Options, was Re: To Be, or NR To Be ...
> 
> Elliot,
> 
> A couple of observations.
> 
> First, I'm not sure that I agree that if the keyUsage extension is
> critical, 
> and NR==0, that you are forbidden to use "it" (whatever "it" might
> be).
> 
> I know that this issue has been discussed previously in conjunction
> with another
> attribute, and I may not be remembering it properly, but I thought
> that the 
> Critical bit merely meant "if you don't understand what this bit
> means, 
> you should reject the certificate"  That's not quite the same thing as
> 
> saying "if you do understand what this bit means, you are absolutely
> compelled to either do or not do that thing, under pain of ...?"
> 
> Secondly, although NR==0 clearly means, "you shouldn't assume that
> the NR property applies" it isn't clear that that is useful if I don't
> know what
> NR means.  What is the CA, the subscriber, and/or the relying party 
> supposed to do in that case?  It still isn't clear, and so it's an
> empty bag.
> Maybe NR means, 'hang your clothes on a hickory limb, and don't
> go near the water." :-)  I don't know what that means, either.
> 
> I am beginning to be of the opinion that we should deprecate the NR 
> bit entirely, and then define several new bits to define exactly what
> we 
> do mean, as I suggest under the "subdividing the NR bit" thread.
> 
> I certainly agree that "go read the CPS" adds little or nothing. Does
> NR==0 mean that I don't have to read the CPS?  If so, that would be 
> a very useful thing to have, but I don't think it means
> nonrepudiation. :-)
> 
> At this point, I am afraid that there is so much baggage, implied
> semantics,
> and past history in the name "nonrepudiation" that I don't think we
> will 
> ever achieve consensus.
> 
> There is a little bit of merit in Ed's Proof of Authentication label,
> but that doesn't
> really connote what I would like at least one of the bits to mean.
> And 
> "rebuttable presumption" also has some merit, and so does "intent to
> sign".
> 
> I think that everyone but Steve Kent believes that the name
> "nonrepudiation" 
> conveys something quite different than the current definition, which
> to my 
> mind at least is hopelessly vague and circular.  However, we have not 
> yet achieved consensus on one single definition of what it does mean, 
> in part, I think because there are multiple things going on that are
> all 
> interrelated, and a single bit is simply not sufficient to cover them
> all.
> 
> What do others thing about deprecating NR, and starting over with a 
> clean sheet of paper?
> 
> Bob
> >
> >
> >>>> Elliot Ginsburg <[e-mail]> 08/25/99 02:08PM >>>
> >I think everyone agrees that the keyUsage extension provides more
> >information than would be present without it. The discussion on this
> >list seems to be, exactly what information does it provide? Anyone
> have
> >a clear proposal to make for what it means, other than 'go read the
> >CPS', because this adds nothing.
> >
> >It seems easy to decide that NR==0 means 'don't use it for NR' (if
> >critical, you're forbidden to; if non-critical, you're advised not
> to).
> >But what exactly does NR==1 convey? From reading this list, I might
> >conclude it means 'you might want to use it for NR, depending on the
> >policy, your requirements, and the availability of NR services to
> you'.
> >While this doesn't do much, at least NR==0  is still very useful.
> >
> >Elliott N Ginsburg
> >CygnaCom Solutions
> >[e-mail] 
> >703-848-0883
> >703-848-0960(FAX)
> >
> >> -----Original Message-----
> >> From:	David P. Kemp [SMTP:[e-mail]] 
> >> Sent:	Wednesday, August 25, 1999 2:48 PM
> >> To:	[e-mail] 
> >> Subject:	Re: Options, was Re: To Be, or NR To Be ...
> >> 
> >> 
> >> > From: Tony Bartoletti <[e-mail]> 
> >> > 
> >> > In some ways, the NR-bit is like marketing bottles of wood
> alcohol
> >> that
> >> > are simply labeled "alcohol".  The designation is "not necessary"
> to
> >> those
> >> > that have performed investigation and use the liquid for cleaning
> >> purposes.
> >> > The designation is "not sufficient" for those who assume that the
> >> liquid
> >> > is grain alcohol and can be taken internally.
> >> 
> >> 
> >> Your position is that more information on the label is better?
> >> 
> >> What label should be attached to a key which is known to be
> relatively
> >> less suitable for supporting a NR process (perhaps because the
> binding
> >> between a single individual and a specific private key is weak or
> >> nonexistent) - "Key, NR=0", or simply "Key" ?
> >> 
> >> The "necessary and sufficient" line of reasoning is as bogus with
> >> respect to the NR bit as it is with respect to any other bit.  A
> >> necessary and sufficient statement says that the set of keys (or
> more
> >> generally, the set of technologies) which can support and will
> provide
> >> an XX operation is identical to the set of keys which have the XX
> bit
> >> asserted in a certificate.  No matter what you value you substitute
> >> for
> >> XX (digitalSignature, nonRepudiation, keyEncipherment, ...
> >> decipherOnly), the "necessary and sufficient" condition is patently
> >> false.  We have the keyUsage extension because a cert with it
> provides
> >> more information than a cert without it, not because the extension
> is
> >> either necessary or sufficient to achieve any particular security
> >> goal.
> >
> >
> >
> >


Received: from over.ny.us.ibm.com (over.ny.us.ibm.com [32.97.182.111]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id OAA16277 for <[e-mail]>; Thu, 26 Aug 1999 14:21:43 -0700 (PDT)
From: [e-mail]
Received: from ny.us.ibm.com. (s1 [10.0.3.101]) by admin.ny.us.ibm.com (8.9.3/8.9.3) with ESMTP id JAB31456; Thu, 26 Aug 1999 09:22:34 -0400
Received: from northrelay02.pok.ibm.com ([9.117.200.22]) by e1.ny.us.ibm.com (8.9.3/8.9.3) with ESMTP id OAA92476; Wed, 25 Aug 1999 14:50:28 -0400
Received: from D51MTA05.pok.ibm.com (d51mta05.pok.ibm.com [9.117.200.33]) by northrelay02.pok.ibm.com (8.8.8m2/NCO v2.04) with SMTP id OAA80952; Wed, 25 Aug 1999 14:49:59 -0400
Received: by D51MTA05.pok.ibm.com(Lotus SMTP MTA v4.6.4  (830.2 3-23-1999))  id 852567D8.00676DB9 ; Wed, 25 Aug 1999 14:49:42 -0400
X-Lotus-FromDomain: IBMUS
To: Ed Gerck <[e-mail]>
cc: Stephen Kent <[e-mail]>, [e-mail]
Message-ID: <[e-mail]>
Date: Wed, 25 Aug 1999 14:48:22 -0400
Subject: Re: Options, was Re: To Be, or NR To Be ...
Mime-Version: 1.0
Content-type: text/plain; charset=us-ascii
Content-Disposition: inline

(snip)
> Although I agreed that use of the NR bit is neither necessary nor
> sufficient, in isolation, I have also given many examples of where the bit
> of of significant benefit in an overall NR scheme.

I do not recall any use of the "NR bit" in isolation and I don't think it
would be usable either.  The statement that the NR bit is neither necessary nor
sufficient to provide NR services had no indeed no opposition in this WG --
and this statement simply proves that NR services are independent of such
NR bit, q.e.d.

[Tom Gindin]   I think this is a bit of an overstatement.  While there is no, or
very little, opposition to the statement that the NR bit is not sufficient for
the NR service, it is not clear that the bit is not necessary or at least highly
desirable for the service.  And, while "highly desirable" would leave the NR
service logically independent of the NR bit, this no more establishes the
uselessness of the NR bit than the usability of X.509v1 certificates for digital
signature establishes the uselessness of the digital signature bit.

(snip)




Received: from tomcat.sac.verio.net ([e-mail] [209.162.64.15]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id NAA15845 for <[e-mail]>; Thu, 26 Aug 1999 13:51:13 -0700 (PDT)
Received: from nma.com (pm02-06.sac.verio.net [209.162.64.25]) by tomcat.sac.verio.net (8.9.1a/8.9.1) with ESMTP id NAA24567 for <[e-mail]>; Thu, 26 Aug 1999 13:52:53 -0700 (PDT)
Message-ID: <[e-mail]>
Date: Thu, 26 Aug 1999 13:52:53 -0700
From: Ed Gerck <[e-mail]>
X-Mailer: Mozilla 4.61 [en]C-CCK-MCD {Sony}  (Win98; I)
X-Accept-Language: en
MIME-Version: 1.0
To: "[e-mail]" <[e-mail]>
Subject: Re: Options, was Re: To Be, or NR To Be ...
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Alfred Arsenault wrote:

> Ed,
>
>         Please accept my apologies if your feelings were hurt, but quite
> frankly I'm getting really tired of your continual twisting of my (and
> other people's words) to support whatever mindgame you have going on at
> the moment.

I regret that you interpret my messages as mindgames and that you choose 
to talk for others.  And, I also regret in the name of future dialogue 
that you have really not recalled your previous misstatements.  I also 
remind you that you have now more than two weeks of no-reply to my very
clear questions of August 11 -- even though you asked for them with the
now usual emphasis.

>               If you give me a signed certificate, and I want to determine if it is
> valid for my purposes as a relying party, I can get one of three
> results:
>         - yes, the certificate is valid;
>         - no, the certificate is invalid (for whatever reason, such as it
> expired, has been revoked, contains the wrong subject DN, etc.)
>         - I don't know; there's not enough information (because I can't trace
> back to a trust anchor, or I can't get the necessary CRL/OCSP response,
> etc.)

If you need to make a decision, it is always YES or NO.  A decision can't
be MAYBE or DON'T KNOW.

If I give you my signed certificate and you are going to decide whether to
rely on it in order to send me merchandise, then the "I don't know" case is NO.
However, if you need to rely on my certificate in order to send me a query
by email, then the "I don't know" case is YES.

Either way, the cert is verifiable because it is signed -- a value of either
YES or NO is assigned to the final state.

BTW, and that is what every browser does -- either the cert is accepted or
not according to the trust-points it has acquired, but a cert is always 
verifiable if signed.  Of course, you may argue that the  browser will not
be able to verify the cert if it is signed with a PGP syntax -- but, in 
fact, the browser is able, since it will refuse to accept the cert and the
final state in verification will be NO.

Cheers,

Ed Gerck


Received: from tomcat.sac.verio.net ([e-mail] [209.162.64.15]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id MAA13564 for <[e-mail]>; Thu, 26 Aug 1999 12:11:34 -0700 (PDT)
Received: from nma.com (pm03-41.sac.verio.net [209.162.64.107]) by tomcat.sac.verio.net (8.9.1a/8.9.1) with ESMTP id MAA28123; Thu, 26 Aug 1999 12:12:49 -0700 (PDT)
Message-ID: <[e-mail]>
Date: Thu, 26 Aug 1999 12:12:49 -0700
From: Ed Gerck <[e-mail]>
X-Mailer: Mozilla 4.61 [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: Options, was Re: To Be, or NR To Be ...
References: <[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

"David P. Kemp" wrote:

> Examining assumptions, clarifying language, and producing alternative
> interpretations is valuable up to a point.  But there is a point beyond
> which it is counterproductive.  I believe that when we have disagreement
> over the meaning of words like "false" and "deny" in the context of
> PKIX, we have crossed that point.

Dave:

Once I read a very interesting paper (forgot the URL) that began with the
eye-catching (approximate) phrase "My career in crime started four years
ago".  And went on to recount that Dean's tribulation with understanding
the crime of plagiarism and intellectual theft in university circles in his
"career (in understanding that) crime" before he could write rules to curb
that crime.  Likewise, my career in crime started 13 years ago and I guess
that some participants of this WG may count even twice or more time with
careers in crime.

Thus, I guess most of us can understand what was said next in that essay,
past these opening remarks.  The Dean explained what happened after
he understood the problems and wrote the rules. They were actually
applied to a high-visibility case that went to a court of law.  But, to his
surprise, the words that he had used rather at random when trying to
describe the various cases and definitions were taken to the letter by
lawyers and technical experts from both sides, who verified and derived
all types of conclusions and lack of conclusions in negative pregnants
from words he had simply jotted down on paper and had typed.

The lesson to our own careers in crime is that, yes, digital signature standards
will be picked apart -- and not only by implementers (resulting in potential
lack of interoperation as we just look at the various interpretations of the
NR bit we see here) but also by technical experts in various areas (forensic,
auditing, etc.) and by lawyers.

In this regard, even though I have no problems with the meaning of the
words "false and "denial" (and, thus, have not crossed that point which
you hold valuable), I do have serious objections to use both together in
"falsely denying" -- as in the present text.  It is either a prejudgement or a
misplaced statement of intent.

> It appears that only you believe that the keyUsage field must be
> interpreted as an interdependent unit instead of a collection of
> independent usages,

No, not even me!  I believe they should be fully independent.  I just
remarked (in reasoning by absurdum) that following your suggestion
that none of the eight bit definitions were "necessary and sufficient"
to define them (i.e., not just the NR bit had this problem) would lead to
interpret them together as octet-codes -- which would be very
confusing since for example the semantics would be elsewhere for those
240 or so undefined octet-codes.  Thus, I was denying the usefulness
of that suggestion -- IMO, all the eight bits must be defined with
necessary and sufficient clauses.

> and that the PKIX definition is incorrect and must be rewritten.

Rewritten in IMO in the following aspects, recalling that Dean's lesson
in his career in crime:

1.  rewritten to clarify the NR bit, also with a name change if the NR bit
continues to consider "non-repudiation" as "rebuttable presumption".

2. rewritten to lint those wordings which make the key usage bits dependent
from one another, though this was not intended in the mind of those that
wrote the spec.

3. rewritten with a revision of all possible logical cases that can arise from
key usage in the spec, verifying if they are coherent with one another *and*
if they are intended.

> The straightforward interpretation is that the
> bits are independent and can be set in any combination, subject to
> domain-dependent decisions concerning security assurance, usability,
> cost, etc.

This would be desirable, IMO.  And I see your table below as a step in the
direction of item (3) above.

> If we accept your interpretation that there are 4 flavors {A,B,C,D} of
> things that can be done with a digital signature algorithm that
> "support a nonrepudiation service", and assume that there are 7 other
> things {E,F,G,H,I,J,K} that can be done with a digital signature algorithm,
> two of which are signing key certs {F} and signing CRLs {G}, then the
> straightforward interpretation says that the keyUsage bits enable the
> digital signature "things" in an independent manner:
>
> keyUsage Bit         Things that can be done with digital signatures/keys
> DS NR KS CS          A B C D E F G H I J K    (.=No, Y=Yes)
> -----------          ---------------------
> 0  0  0  0           . . . . . . . . . . .
> 0  0  0  1           . . . . . . Y . . . .
> 0  0  1  0           . . . . . Y . . . . .
> 0  0  1  1           . . . . . Y Y . . . .
> 0  1  0  0           Y Y Y Y . . . . . . .
> 0  1  0  1           Y Y Y Y . . Y . . . .
> 1  0  0  0           . . . . Y . . Y Y Y Y
> 1  1  0  0           Y Y Y Y Y . . Y Y Y Y
> 1  1  1  1           Y Y Y Y Y Y Y Y Y Y Y
>

This is fine and may need just some tweaking. For example,  for a Y that is
critical versus a Y that is not critical -- so that a "don't care" condition ("X")
would be introduced. Further,  one must also define what happens when
you have "N" above.  This may seem trivial ("a cert with N is  required")
but anyone familiar with the null theory in relational databases will recognize
why I mentioned before that there are exactly three "flavors" of "off" (i.e., of N)
besides the trivial non-existence of Y (with a total of 4 different Ns) -- and
why they all need to be taken into account or we won't be able to represent
real-world cases just by considering N to be the absence of Y (one case of N).
Again, the Dean's lesson.

> If a consensus is later reached that there is a fifth digital signature
> thing {E} which supports non-repudiation, then thing E would be
> indicated by the NR bit instead of by the DS bit.  But that does not
> mean that the settings of the DS and NR bits have somehow become
> dependent; they can still be set in any combination, and they still
> legitimately signify sets of "things" as long as the things themselves
> are not mutually exclusive. (You can't, for example, define thing "C"
> as "not-K").

Yes, and I guess you mean "as long as the things themselves are
independent" -- since "mutually exclusive" is not the only dependency
that would break the encoding system depicted in your table. Then,
you can't really define thing "C" as "not-K" because C and K  are
unrelated.

I guess the issues are becoming clearer, though (as they say) there are
three things one should not watch as they are being made: sausages,
laws and standards ;-)  They will mostly taste fine afterwards, though.

Cheers,

Ed Gerck




Received: from homebase.htt-consult.com (homebase.htt-consult.com [208.235.169.130]) by mail.proper.com (8.9.3/8.9.3) with SMTP id LAA12512 for <[e-mail]>; Thu, 26 Aug 1999 11:35:32 -0700 (PDT)
Received: from rgm ([208.235.169.131]) by homebase.htt-consult.com ; Thu, 26 Aug 1999 14:37:55 -0500
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 
Date: Thu, 26 Aug 1999 14:36:52 -0400
To: [e-mail]
From: Robert Moskowitz <[e-mail]>
Subject: CMP virtual workshop
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"

I appologies for the lateness of this note.  I found it in my pending
folder, waiting to be sent :(

The 3rd CMP workshop will be next week, Aug 30th.  It will be virtual this
time, that is we all stay in our offices, but have blocked out the week to
work together.

Please contact me if you have running CMP code at any level of development.



Robert Moskowitz
ICSA
Security Interest EMail: [e-mail]


Received: from homebase.htt-consult.com (homebase.htt-consult.com [208.235.169.130]) by mail.proper.com (8.9.3/8.9.3) with SMTP id LAA11979 for <[e-mail]>; Thu, 26 Aug 1999 11:09:42 -0700 (PDT)
Received: from rgm ([208.235.169.131]) by homebase.htt-consult.com ; Thu, 26 Aug 1999 14:12:05 -0500
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 
Date: Thu, 26 Aug 1999 14:06:39 -0400
To: "Sweigert, David" <[e-mail]>, Alan Lloyd <[e-mail]>, "'[e-mail]'" <[e-mail]>, [e-mail], [e-mail]
From: Robert Moskowitz <[e-mail]>
Subject: RE: More problems with OCSP
In-Reply-To: <[e-mail] .gte.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"

At 06:28 PM 8/24/1999 -0400, Sweigert, David wrote:

If I remember correctly, GM goes by country and then function.

Chrysler went by function and then country (don't know what DCX will do).

So do what ever you want.  Either will work for your client, neither will
work for a global lookup.

>
>As anyone grappling with the problem of defining a directory information
>tree for a multi-national company.  In other words, how do divisions in
>the UK and US relate in the DIT if both divisions are within one corporate
>organization; say MARKETING.
>
>Would this be appropriate:
>
>c=US
>o=GlobalCorp
>ou=Marketing
>
>and
>
>c=UK
>o=GlobalCorp
>ou=Marketing
>
>
>Any thoughts on this ?
>
>Dave Sweigert

Robert Moskowitz
ICSA
Security Interest EMail: [e-mail]


Received: from honcho.austin.dascom.com (email.austin.dascom.com [206.196.73.5]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id KAA11419 for <[e-mail]>; Thu, 26 Aug 1999 10:44:34 -0700 (PDT)
Received: from austin.dascom.com by honcho.austin.dascom.com (8.8.8/SMI-SVR4) id MAA01465; Thu, 26 Aug 1999 12:42:43 -0500 (CDT)
Received: from dascom.com by austin.dascom.com (8.8.8/SMI-SVR4) id MAA02082; Thu, 26 Aug 1999 12:42:43 -0500 (CDT)
Message-ID: <[e-mail]>
Date: Thu, 26 Aug 1999 12:46:05 -0500
From: Ivan Milman <[e-mail]>
X-Mailer: Mozilla 4.61 [en] (WinNT; U)
X-Accept-Language: en
MIME-Version: 1.0
To: [e-mail]
Subject: Re: Options, was Re: To Be, or NR To Be ...
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

EG = Ed Gerck
AWA = Al Arsenault



EG> First, of course, a necessary and sufficient condition for a certificate to be
EG> verifiable is for it to be digitally signed.  So, I guess this much is OK and
EG> equivalent: "certificate is signed" <--> "certificate is verifiable".  A certificate
EG> is verifiable if and only if it is signed -- the "if" is a sufficient condition and
EG> the "only if" a necessary condition.

AWA>The fact that is certificate is signed does NOT make it verifiable.

EG> Yes it does, as verifiable as the signature allows it.  If a certificate
EG> IS signed THEN I affirm that this is equivalent to saying that the
EG> certificate is verifiable -- where, of course, "is verifiable" means that
EG> it CAN be verified.  And, of course, the fact that it CAN be verified
EG> does not mean that it MUST be verified.  Of course, it also depends
EG> if the available public-keys match the signature (maybe not, and maybe
EG> you need more keys), if the public-key that matches has not been
EG> revoked, etc.  But, nonetheless the certificate is verifiable and the
EG> result is either YES or NO -- if the certificate is signed.

Believe it or not, gents, I think you are in agreement here.  If we were to
say that a signature on a certificate is necessary but not sufficient for verification,
then I think everybody would be happy.  Ed seems to think so, by stating:

EG> Of course, it also depends
EG> if the available public-keys match the signature (maybe not, and maybe
EG> you need more keys), if the public-key that matches has not been
EG> revoked, etc.

and I'm pretty certain Al had similar statements in his original posting on this thread.

Thanks,
Ivan

Ivan M. Milman	Technical Director	DASCOM
email:  [e-mail]		phone: [phone], ext. 5014


Received: from mail.rdc1.md.home.com ([e-mail] [24.2.2.66]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id HAA08086 for <[e-mail]>; Thu, 26 Aug 1999 07:10:09 -0700 (PDT)
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, 26 Aug 1999 07:11:52 -0700
Message-ID: <[e-mail]>
Date: Thu, 26 Aug 1999 10:09:52 -0400
From: Alfred Arsenault <[e-mail]>
Organization: @Home Network
X-Mailer: Mozilla 4.5 [en]C-AtHome0405  (Win95; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Ed Gerck <[e-mail]>
CC: Ron Ramsay <[e-mail]>, "[e-mail]" <[e-mail]>
Subject: Re: Options, was Re: To Be, or NR To Be ...
References: <D1A949D4508DD1119C8100400533BEDC15193B@DSG1> <[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Sigh!!!

No, Ed, read my words carefully, and please don't twist them.

You asserted that bit_0 and bit_1 were not independent.

I demonstrated that under PKIX 2459, bit_0 and bit_1 meet all of the
definitions of independence.  

I noted that, if the CA agrees that a key in a certificate can be used
to digitally sign something in applications where some service ("FRED"
or non-repudiation, or...) is NOT provided, bit_0 should be set.

I also noted that, if the CA agrees that a key in a certificate can be
used to digitally sign something in applications where that service
("FRED" or non-repudiation or...) IS provided, bit_1 should be set.

If I wasn't clear enough before, I'll try to be clear now:

	RFC 2459 permits (does not prohibit, does not deprecate, pick whatever
words you want) PKIs that allow the same key to be used both in cases
where "FRED" is provided, and in cases where "FRED" is not provided.

Thus, we can have:

	bit_0 = 0 and bit_1 = 1; or
	bit_0 = 1 and bit_1 = 0; or
	bit_0 = 0 and bit_1 = 0; or
	bit_0 = 1 and bit_1 = 1

All combinations are allowed in PKIs compliant with RFC 2459, and thus
bit_0 and bit_1 are independent. (And if you want to get into the
strict  probabilistic definition of variable independence as noted in
either classical probability theory or in Bayesian statistics, we can
play that game, too, but I'd really rather not.)

That was the point I was trying to make.  That's how the spec should be
interpreted.  I haven't found anything in RFC 2459 that contradicts
this.

		Al Arsenault

-- speaking for myself, yada, yada, yada


Ed Gerck wrote:
> 
> Ron Ramsay wrote:
> 
> > But the bit doesn't say anything EXCEPT vanilla, it says STRAWBERRY!
> >
> > I'm going mad!! Stop! Stop! Stop!
> 
> ;-)  the slightly maddening point here is not what the NR bit says when it is "on"
> (there are at least 4 different flavors already named -- not just strawberry) nor what it
> says when it is "off" (there are at least 3 more flavors named) but what other
> bits can co-exist with the NR bit if one takes the spec to task, by what it says (but,
> what else would one do -- interpret the spec at will?).
> 
> And, this was brought up when I went on with Dave Kemp's suggestion that the
> spec was neither necessary nor sufficient to specify any key usage bit, not just
> the NR bit -- and pointed out that following Dave's suggestion would imply either
> that the spec is defining octet-codes that in most cases would be left open to the
> CPS (apparently, what Alfred also said when he interpreted the "bit_0 and bit_1"
> case to be provided outside of PKIX) or that the spec can indeed be interpreted
> at will.
> 
> The simple conclusion is that either the PKIX spec provides necessary and
> sufficient conditions in order to define the NR bit (and *all* other bits in the
> key usage field) or it will be very difficult to warrant interoperation with any
> other security spec or overlayed service that may rely on the semantics of
> such bits -- and I don't mean only IETF protocols but other protocols and
> also applications.   Interoperation is a basic tenet in the Internet but  we seem
> to be reaching a limit where matters need to be made clearer in order to define
> borders that, paradoxically, will afford interoperation by providing clear
> semantics.  To proceed otherwise is to go back to those "value add" services
> of the 80's, where splitting the market in incompatible networks/services was
> profitable. However, the Internet is becoming more transparent by the day
> and showcases a different paradigm -- that there is more value in
> interoperation, even with all the problems.
> 
> Cheers,
> 
> Ed Gerck


Received: from mail.rdc1.md.home.com ([e-mail] [24.2.2.66]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id GAA07728 for <[e-mail]>; Thu, 26 Aug 1999 06:58:02 -0700 (PDT)
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, 26 Aug 1999 06:59:44 -0700
Message-ID: <[e-mail]>
Date: Thu, 26 Aug 1999 09:57:44 -0400
From: Alfred Arsenault <[e-mail]>
Organization: @Home Network
X-Mailer: Mozilla 4.5 [en]C-AtHome0405  (Win95; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Ed Gerck <[e-mail]>
CC: "[e-mail]" <[e-mail]>
Subject: Re: Options, was Re: To Be, or NR To Be ...
References: <[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Ed,

	Please accept my apologies if your feelings were hurt, but quite
frankly I'm getting really tired of your continual twisting of my (and
other people's words) to support whatever mindgame you have going on at
the moment.

  	Now, on to the matter at hand:

	Do we have a different definition of "verifiable"?

	My dictionary provides as one definition of "verify" :  "to determine
or test the truth or accuracy of, as by comparison or investigation".  

	Thus, my definition of "verifiable" is that I can look at something
(test it, investigate it,...), and determine whether it is valid (true)
or not valid (false).

	If you give me a signed certificate, and I want to determine if it is
valid for my purposes as a relying party, I can get one of three
results:
	- yes, the certificate is valid;
	- no, the certificate is invalid (for whatever reason, such as it
expired, has been revoked, contains the wrong subject DN, etc.)
	- I don't know; there's not enough information (because I can't trace
back to a trust anchor, or I can't get the necessary CRL/OCSP response,
etc.)

	The existence of the "I don't know" answer means that a signed
certificate of and by itself cannot necessarly be verified (that is, I
can't always determine with certainty whether it's "true" or "false"),
and thus it is not "verifiable".

	The only thing you can test for certain about a signed certificate is
that the signature checks; i.e., the bits in the certificate, to the
degree of uncertainty inherent in public-key cryptography, are those
that went into the creation of the certificate.  If this is what you
mean by "verifiable", then yes, you're right, but that's IMNSHO a pretty
useless definition, because it reduces to "a certificate is signed IF
the certificate is signed".

	Now, if you have another definition of "verifiable", let's hear it.

			Al Arsenault

-- speaking only for myself, yada, yada, yada

Ed Gerck wrote:
> 
> Alfred Arsenaul wrote:
> 
> >Ed Gerck wrote:
> >>
> >>
> >>
> >>
> >> First, of course, a necessary and sufficient condition for a certificate to be
> >> verifiable is for it to be digitally signed.  So, I guess this much is OK and
> >> equivalent: "certificate is signed" <--> "certificate is verifiable".  A certificate
> >> is verifiable if and only if it is signed -- the "if" is a sufficient condition and
> >> the "only if" a necessary condition.
> >>
> >
> >AWA:  Bzzt!  Sorry, that is not correct, but thank you for playing
> >anyway.
> 
> Alfred:
> 
> I regret the nonsense you wrote above -- but I find it nonetheless fitting to
> this discussion.
> 
> >The fact that is certificate is signed does NOT make it verifiable.
> 
> Yes it does, as verifiable as the signature allows it.  If a certificate
> IS signed THEN I affirm that this is equivalent to saying that the
> certificate is verifiable -- where, of course, "is verifiable" means that
> it CAN be verified.  And, of course, the fact that it CAN be verified
> does not mean that it MUST be verified.  Of course, it also depends
> if the available public-keys match the signature (maybe not, and maybe
> you need more keys), if the public-key that matches has not been
> revoked, etc.  But, nonetheless the certificate is verifiable and the
> result is either YES or NO -- if the certificate is signed.
> 
> You are makling a simple confusion in logic and I suggest you re-read
> my message. It might be much more instructive than if I would try to
> explain it again.
> 
> And, please, next time you don't understand something, just please say what
> you don't understand.  There is no need to continue the tone I see in your
> message and which I surely expect you to recall in the name of civil discourse.
> 
> Cheers,
> 
> Ed Gerck


Received: from stingray.missi.ncsc.mil (stingray-ext.missi.ncsc.mil [144.51.50.20]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id GAA07376 for <[e-mail]>; Thu, 26 Aug 1999 06:45:38 -0700 (PDT)
Received: from stingray.missi.ncsc.mil (root@localhost) by stingray.missi.ncsc.mil with ESMTP id JAA11288 for <[e-mail]>; Thu, 26 Aug 1999 09:47:26 -0400 (EDT)
Received: from missi.ncsc.mil (depot.missi.ncsc.mil [144.51.60.1]) by stingray.missi.ncsc.mil with ESMTP id JAA11284 for <[e-mail]>; Thu, 26 Aug 1999 09:47:25 -0400 (EDT)
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 JAA27210 for <[e-mail]>; Thu, 26 Aug 1999 09:47:13 -0400 (EDT)
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 JAA28061 for <[e-mail]>; Thu, 26 Aug 1999 09:45:44 -0400 (EDT)
Message-Id: <[e-mail]>
Date: Thu, 26 Aug 1999 09:45:44 -0400 (EDT)
From: "David P. Kemp" <[e-mail]>
Reply-To: "David P. Kemp" <[e-mail]>
Subject: Re: Options, was Re: To Be, or NR To Be ...
To: [e-mail]
MIME-Version: 1.0
Content-Type: TEXT/plain; charset=us-ascii
Content-MD5: rl6xem5lLnLsD31T5niXqQ==
X-Mailer: dtmail 1.3.0 CDE Version 1.3 SunOS 5.7 sun4u sparc

> From: Ed Gerck <[e-mail]>
> 
> Ron Ramsay wrote:
> 
> > But the bit doesn't say anything EXCEPT vanilla, it says STRAWBERRY!
> >
> > I'm going mad!! Stop! Stop! Stop!
> 
> ;-)  the slightly maddening point here is not what the NR bit says when it is 
"on"
> (there are at least 4 different flavors already named -- not just strawberry) 
nor what it
> says when it is "off" (there are at least 3 more flavors named) but what other
> bits can co-exist with the NR bit if one takes the spec to task, by what it 
says (but,
> what else would one do -- interpret the spec at will?).


Ed,
  I disagree with Al's tone, and believe that we should always strive
for a civil discussion of ideas.  But it is a bit maddening that you
conjure up perverse definitions and interpretations, and then use them
to argue that the world can be nothing other than convoluted.
Your approach violates the principle of Ockham's Razor, under which
in the face of ambiguity, the simpler alternative is inherently
preferred.

Examining assumptions, clarifying language, and producing alternative
interpretations is valuable up to a point.  But there is a point beyond
which it is counterproductive.  I believe that when we have disagreement
over the meaning of words like "false" and "deny" in the context of
PKIX, we have crossed that point.

It appears that only you believe that the keyUsage field must be
interpreted as an interdependent unit instead of a collection of
independent usages, and that the PKIX definition is incorrect and
must be rewritten.  The straightforward interpretation is that the
bits are independent and can be set in any combination, subject to
domain-dependent decisions concerning security assurance, usability,
cost, etc.

If we accept your interpretation that there are 4 flavors {A,B,C,D} of
things that can be done with a digital signature algorithm that
"support a nonrepudiation service", and assume that there are 7 other
things {E,F,G,H,I,J,K} that can be done with a digital signature algorithm,
two of which are signing key certs {F} and signing CRLs {G}, then the
straightforward interpretation says that the keyUsage bits enable the
digital signature "things" in an independent manner:

keyUsage Bit         Things that can be done with digital signatures/keys
DS NR KS CS          A B C D E F G H I J K    (.=No, Y=Yes)
-----------          ---------------------
0  0  0  0           . . . . . . . . . . .
0  0  0  1           . . . . . . Y . . . .
0  0  1  0           . . . . . Y . . . . .
0  0  1  1           . . . . . Y Y . . . .
0  1  0  0           Y Y Y Y . . . . . . .
0  1  0  1           Y Y Y Y . . Y . . . .
1  0  0  0           . . . . Y . . Y Y Y Y
1  1  0  0           Y Y Y Y Y . . Y Y Y Y
1  1  1  1           Y Y Y Y Y Y Y Y Y Y Y

If a consensus is later reached that there is a fifth digital signature
thing {E} which supports non-repudiation, then thing E would be
indicated by the NR bit instead of by the DS bit.  But that does not
mean that the settings of the DS and NR bits have somehow become
dependent; they can still be set in any combination, and they still
legitimately signify sets of "things" as long as the things themselves
are not mutually exclusive. (You can't, for example, define thing "C"
as "not-K").




Received: from popmail.inbox.se (popmail.inbox.se [193.12.72.101]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id GAA07146 for <[e-mail]>; Thu, 26 Aug 1999 06:40:24 -0700 (PDT)
Received: from stefan2 (accurata.inbox.se [193.12.72.24]) by popmail.inbox.se (8.9.3/8.9.3) with SMTP id PAA31160; Thu, 26 Aug 1999 15:41:08 +0200
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 
Date: Thu, 26 Aug 1999 15:41:27 +0200
To: [e-mail]
From: Stefan Santesson <[e-mail]>
Subject: Re: Pseudonym in Subject DN (in QC certificates)
Cc: [e-mail], Hans Nilsson <[e-mail]>, [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 mail.proper.com id GAA07147

Regarding new attributes in the subject field in Qualified Certificates.

I've had several off list discussions regarding the pseudonym attribute in
the subject field of QC.

Everybody except one has been in favour of adding this attribute in the
subject field.

Pros are:
- Makes it easier to meet the EU directive directly by using just the
subject field without bending current X.509 definitions.
- Clearly defines when a name is based on a pseudonym
- RSA has offered to include this (and other PersonalData) attributes in PKCS#9

Cons are:
- Will require definition of new object classes for directory systems when
this attribute is used.

The cons are more and more fading away. Magnus Nyström at RSA wrote to me:

"Well, yes, one have to include this new attribute in the definition of a 
 new object class, or extend the definition of an existing class if one
 would like this to work well. But that was also my original intention - to
 include them in the 'pkcsEntity' auxiliary object class that is being
 defined in PKCS #9. Further, most directory products does support changes
 to the schema, and there are already several proposals being made in
 this area, e.g.:

 -Netscape's draft about "inetOrgPerson", published as
  'draft-smith-ldap-inetorgperson-03.txt'; and
 -Chadwick's draft regarding ldapv3 and PKIX
  (draft-ietf-pkix-ldap-v3-01.txt) which incorporates the 'pmiUser' object
  class which I doubt many directory products have built-in support for
  today.
 -RSA Laboratories "pkcsEntity" auxiliary object class, being defined in
  PKCS #9 v.2."

Taking this into consideration I think that we should go forward and
include the pseudonym attribute.
This will force us to expand the set of supported attributes compared to
RFC 2459 and also to add matching rules for this attribute. we will also
have to remove the option to allow a pseudonym to be stored in the
commonName attribute and instead say that this attribute SHALL be used to
store the subjects registered name in a preferred presentation format.
Nicknames and spelling other than the registered names are allowed as long
as they are related to the persons registered name.

Another consideration is to add the title attribute as a role attribute
since role has repeatedly become an issue within these types of
certificates. The text should declare that when this attribute is present
it SHALL define a role of the subject. I believe that this is consistent
with the attribute definition in X.520. This attribute is further already
on the list of supported attributes in RFC 2459.

Finally we should assign an OID to be optionally included in the
qcStatements extension, which declare that a certificate is compliant with
syntax and semantics definitions of this specification. Otherwise there
will be no way for a relying party to tell whether the certificate is
compliant with these definitions other than by understanding present policy
OID:s.

So if no serious objections are raised, I would like to go forward and
update the specification according to this proposal.

/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 dsg1.OpenDirectory.com.au ([203.108.249.145]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id GAA06471 for <[e-mail]>; Thu, 26 Aug 1999 06:02:18 -0700 (PDT)
Received: by DSG1 with Internet Mail Service (5.0.1458.49) id <RNJY4XHX>; Thu, 26 Aug 1999 23:03:41 +1000
Message-ID: <D1A949D4508DD1119C8100400533BEDC15D797@DSG1>
From: Alan Lloyd <[e-mail]>
To: "'[e-mail]'" <[e-mail]>
Subject: apologies and comments on SCVP
Date: Thu, 26 Aug 1999 23:03:39 +1000
X-Priority: 3
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.0.1458.49)
Content-Type: text/plain; charset="iso-8859-1"

Dear all, I was a bit soap boxish on my last email - apologies. May I
submit some personal comments on the draft. The detailed syntax of the
protocol is not of concern - that is always the easy bit. But the
approach of the PKIX group to having "standards" that people want to
build systems with, does.

The first issue is one of qualification of new protocols - well there
seems no engineering substance to them. The second is the logic that
promotes them..
eg.
1. A "process" is "complex" abstract statement ... eg X.500 directories
and processing certs..
2. We need another protocol to make the client simpler - but it is a
YAP.
The client now through this protocol (the YAP)  can now arry and do all
what the other protocols do..So it has by definition got more complex!

The issue is that why doesnt the group seek to provide one standard..
and I know this has been raised before.

My personal comments on the draft follow.

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

Abstract

The SCVP protocol allows a client to offload certificate handling to a
server. The server can give a variety of valuable information about the
certificate, such as whether or not the certificate is valid, a chain
to a trusted root, and so on.

AL: Please add: However, it the responsibility of the client (using out
of band mechanisms to validate the protocol signatures and keys of the
server - or not) to trust the server it requests this service of. In
addition if the client asks the server for all the path and validity
information such as CRLs, etc - the client could have used LDAP or DAP
for this purpose. Also the client will have to be fairly "complex" to
understand and process all its PKI information anyway.

--

1. Introduction

Certificate validation is a difficult problem. 

AL:I don't believe these "abstract" statements are a good rationale for
developing YAP!  Validation does rely on PKI capability so its not quite
right to say that because a key management function is more difficult
than a protocol definition - another protocol should be developed..

--
If certificate handling s to be widely deployed in a variety of
applications and environments, the amount of processing an application
needs to perform before it can accept a certificate must be reduced. 
There are a variety of applications that can use public key certificates
but are burdened by

AL : re ..read reason for LDAP vs X.500 "is big and complex" - we need
to re invent...!!! 
Can those proposing new protocols (YAPS) instead of using "abstract
words" like  "burden" , "complex", "overheads" and what 'applications
really want to do" cite product and development references, reality,
code sizes, performance reports and benchmarks.

--
the overhead of validating the certificates when all the application
really wants is the public key and name from the certificate,
 
AL: what is this "overhead".. someone said it was in DAP which is half
the size of LDAP!
--

and a
determination of whether or not the certificate may be used for a
particular purpose. There are other applications that can perform
certificate path validation but have no reliable method of obtaining a
current chain to a trusted root.

AL: How do we know this SCVP is trusted to the root.? What trust is
there in a server, when this spec in facts describes a zero trust
server.

AL: The majority of engineering in protocols, specifically applications
protocols is dealing with the information model they support (eg. PKI),
getting the transaction reliable ( time outs, sequences, recovery) and
if signed operations are used, getting the trust and key management of
them operational on a large scale. 
As we read through this spec, it seems that most of the transaction,
information (PKI) and key management issues of the protocol are covered
off in the OCSP spec - Is all we need to service the delta's of SCVP, is
a few extensions in OCSP to deal with: 
a) Asking for paths and crls in the response and:
b) the ability for a client to send its root information to the server?


----

1.1 SCVP overview and requirements

The primary goals of SCVP are to make it easier for applications to
deploy systems using a PKI and to allow centralization of administering
PKI policies. 

AL: This goal is not really met is it. Simply because SCVP permits the
client to do all its validation by pulling certs and crls. I assume when
people invest in a trusted protocol like this - they would be somewhat
exposed if they did not implement all of it. See "supplier and consumer
risks" section not written yet! In addition, the server end is a major
variable - trusted, untrusted, gives back certs or validates them, etc..

---

Parts of SCVP can be used by clients that do much of the
PKI processing themselves and simply want a useful but untrusted server
that will collect information for them. Other parts can be used by
clients that have complete trust in the server to both offload the work
of certificate validation and to ensure that policies are enforced in a
consistent fashion across an enterprise.

AL: Assumptions are made here - that in a mixed configuration of SCVP
clients talking to SCVP servers that in turn use OCSP upstream -
inconsistencies will apply.
Assumptions are also made that this simple client knows what the cert
path/validation system topology is - back to the message originators
root. This is somewhat difficult - (a new abstract word!)

A SMALL POINT TO THE PKIX GROUP... Is useful for the group to invent
protocols of similar transaction, information model (PKIs) and trust
(signed req/resps) facilities that do not inter-work or cause major
operational incompatabilities.


---
Untrusted SCVP servers can give client the certificate chains needed
for path validation. They can also give clients revocation information
such as CRLs and OCSP responses that the client can use in the client's
path validation. These services can be valuable to client systems that
do not include the protocols needed to find and download all of the
intermediate certificates, CRLs, and OCSP responses needed for the
client to perform complete path validation.

AL: The first para of the spec was: we need another protocol because
cert validation is complex and obviously OCSP was too complex to add a
few extensions to.
However, we now have the "simple" client validating everything including
upstream OCSP responses which can be signed I assume.. Therefore the
simple SCVP client has to validate the keys/sigs of the OCSP severs? And
their certs...
I do detect a dilemma and a paradox forming here.. 
Ie we need a simple protocol because a complex one is too complex but
the simple one can carry complex protocols for the client to process -
but that does not matter!

----
Trusted SCVP servers can perform full certificate validation for the
client. If a client uses these services, it inherently trusts the SCVP
server as much as it would its own path validation software (if it
contained such software). There are two main reasons that a client may
want to trust such an SCVP server:

- The client does not want to incur the overhead of including path
validation software and running it for each certificate it receives.

AL: However, it wishes to incur the protocol overhead of dealing with
signed transactions.

-----
- The client is in an enterprise that wants to centralize its PKI
validation policies, such as which root certificates are trusted and
which types of policy checking are performed during path validation.

This is achievable with other protocols such as LDAP, DAP (trusted
directories), and OCSP.


regards alan


Received: from solo.cygnacom.com (endor.cygnacom.com [205.177.169.102]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id FAA05845 for <[e-mail]>; Thu, 26 Aug 1999 05:24:26 -0700 (PDT)
Received: by SOLO with Internet Mail Service (5.0.1458.49) id <Q24N5AJG>; Thu, 26 Aug 1999 08:32:10 -0400
Message-ID: <F19999D192F6D211AA1700207810B434040988@SOLO>
From: Elliot Ginsburg <[e-mail]>
To: Bob Jueneman <[e-mail]>, Elliot Ginsburg <[e-mail]>, [e-mail]
Subject: RE: Options, was Re: To Be, or NR To Be ...
Date: Thu, 26 Aug 1999 08:32:08 -0400
X-Priority: 3
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.0.1458.49)
Content-Type: text/plain; charset="iso-8859-1"

Bob,

The reason I interpreted critical/non-critical the way I did is this
from X.509 keyUsage bit:
"This extension may, at the option of the certificate issuer, be either
critical or non-critical. 
If the extension is flagged critical, then the certificate shall be used
only for a purpose for which the corresponding key usage bit is set to
one. 
If the extension if flagged non-critical, then it indicates the intended
purpose or purposes of the key, and may be used in finding the correct
key/certificate of an entity that has multiple keys/certificates. It is
an advisory field and does not imply that usage of the key is restricted
to the purpose indicated. A bit set to zero indicates that the key is
not intended for that purpose. If all bits are zero, it indicates the
key is intended for some purpose other than those listed. "

As far as NR==0, here's what I meant. Since we can't agree on exactly
what NR means, we'll leave it to the replying party to know whether
he/she has access to a non-repudiation service.  But even if he/she
does, a cert with NR==0 can't be used for this purpose; a cert with
NR==1 is required. I don't think this is very interoperable across
security domains, however. 
Here's what I think the difference between authentication and NR is:
authentication lets me identify a transactor at this time;  NR, in
addition to the above, implies that I will be able to re-do that
authentication process, for that moment in time, for some significant
time into the future. NR probably requires archiving and the like,
although there are probably other ways to do it; authentication only
requires the ability to complete the validation in the present or near
present, not five years from now.
Yes, if we can't agree on what it means, then we should deprecate its
use.

Elliott N Ginsburg
CygnaCom Solutions
[e-mail]
703-848-0883
703-848-0960(FAX)

> -----Original Message-----
> From:	Bob Jueneman [SMTP:[e-mail]]
> Sent:	Wednesday, August 25, 1999 8:32 PM
> To:	[e-mail]; [e-mail]
> Subject:	RE: Options, was Re: To Be, or NR To Be ...
> 
> Elliot,
> 
> A couple of observations.
> 
> First, I'm not sure that I agree that if the keyUsage extension is
> critical, 
> and NR==0, that you are forbidden to use "it" (whatever "it" might
> be).
> 
> I know that this issue has been discussed previously in conjunction
> with another
> attribute, and I may not be remembering it properly, but I thought
> that the 
> Critical bit merely meant "if you don't understand what this bit
> means, 
> you should reject the certificate"  That's not quite the same thing as
> 
> saying "if you do understand what this bit means, you are absolutely
> compelled to either do or not do that thing, under pain of ...?"
> 
> Secondly, although NR==0 clearly means, "you shouldn't assume that
> the NR property applies" it isn't clear that that is useful if I don't
> know what
> NR means.  What is the CA, the subscriber, and/or the relying party 
> supposed to do in that case?  It still isn't clear, and so it's an
> empty bag.
> Maybe NR means, 'hang your clothes on a hickory limb, and don't
> go near the water." :-)  I don't know what that means, either.
> 
> I am beginning to be of the opinion that we should deprecate the NR 
> bit entirely, and then define several new bits to define exactly what
> we 
> do mean, as I suggest under the "subdividing the NR bit" thread.
> 
> I certainly agree that "go read the CPS" adds little or nothing. Does
> NR==0 mean that I don't have to read the CPS?  If so, that would be 
> a very useful thing to have, but I don't think it means
> nonrepudiation. :-)
> 
> At this point, I am afraid that there is so much baggage, implied
> semantics,
> and past history in the name "nonrepudiation" that I don't think we
> will 
> ever achieve consensus.
> 
> There is a little bit of merit in Ed's Proof of Authentication label,
> but that doesn't
> really connote what I would like at least one of the bits to mean.
> And 
> "rebuttable presumption" also has some merit, and so does "intent to
> sign".
> 
> I think that everyone but Steve Kent believes that the name
> "nonrepudiation" 
> conveys something quite different than the current definition, which
> to my 
> mind at least is hopelessly vague and circular.  However, we have not 
> yet achieved consensus on one single definition of what it does mean, 
> in part, I think because there are multiple things going on that are
> all 
> interrelated, and a single bit is simply not sufficient to cover them
> all.
> 
> What do others thing about deprecating NR, and starting over with a 
> clean sheet of paper?
> 
> Bob
> >
> >
> >>>> Elliot Ginsburg <[e-mail]> 08/25/99 02:08PM >>>
> >I think everyone agrees that the keyUsage extension provides more
> >information than would be present without it. The discussion on this
> >list seems to be, exactly what information does it provide? Anyone
> have
> >a clear proposal to make for what it means, other than 'go read the
> >CPS', because this adds nothing.
> >
> >It seems easy to decide that NR==0 means 'don't use it for NR' (if
> >critical, you're forbidden to; if non-critical, you're advised not
> to).
> >But what exactly does NR==1 convey? From reading this list, I might
> >conclude it means 'you might want to use it for NR, depending on the
> >policy, your requirements, and the availability of NR services to
> you'.
> >While this doesn't do much, at least NR==0  is still very useful.
> >
> >Elliott N Ginsburg
> >CygnaCom Solutions
> >[e-mail] 
> >703-848-0883
> >703-848-0960(FAX)
> >
> >> -----Original Message-----
> >> From:	David P. Kemp [SMTP:[e-mail]] 
> >> Sent:	Wednesday, August 25, 1999 2:48 PM
> >> To:	[e-mail] 
> >> Subject:	Re: Options, was Re: To Be, or NR To Be ...
> >> 
> >> 
> >> > From: Tony Bartoletti <[e-mail]> 
> >> > 
> >> > In some ways, the NR-bit is like marketing bottles of wood
> alcohol
> >> that
> >> > are simply labeled "alcohol".  The designation is "not necessary"
> to
> >> those
> >> > that have performed investigation and use the liquid for cleaning
> >> purposes.
> >> > The designation is "not sufficient" for those who assume that the
> >> liquid
> >> > is grain alcohol and can be taken internally.
> >> 
> >> 
> >> Your position is that more information on the label is better?
> >> 
> >> What label should be attached to a key which is known to be
> relatively
> >> less suitable for supporting a NR process (perhaps because the
> binding
> >> between a single individual and a specific private key is weak or
> >> nonexistent) - "Key, NR=0", or simply "Key" ?
> >> 
> >> The "necessary and sufficient" line of reasoning is as bogus with
> >> respect to the NR bit as it is with respect to any other bit.  A
> >> necessary and sufficient statement says that the set of keys (or
> more
> >> generally, the set of technologies) which can support and will
> provide
> >> an XX operation is identical to the set of keys which have the XX
> bit
> >> asserted in a certificate.  No matter what you value you substitute
> >> for
> >> XX (digitalSignature, nonRepudiation, keyEncipherment, ...
> >> decipherOnly), the "necessary and sufficient" condition is patently
> >> false.  We have the keyUsage extension because a cert with it
> provides
> >> more information than a cert without it, not because the extension
> is
> >> either necessary or sufficient to achieve any particular security
> >> goal.
> >
> >
> >
> >


Received: from ctron-dnm.ctron.com ([e-mail] [12.25.1.120]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id CAA01562 for <[e-mail]>; Thu, 26 Aug 1999 02:24:31 -0700 (PDT)
Received: (from uucp@localhost) by ctron-dnm.ctron.com (8.8.7/8.8.7) id FAA22354; Thu, 26 Aug 1999 05:28:04 -0400 (EDT)
Received: from roc-mail2.ctron.com(134.141.72.230) by ctron-dnm.ctron.com via smap (4.1) id xma022342; Thu, 26 Aug 99 05:27:29 -0400
Received: from new-exc1.ctron.com (NEW-EXC1 [134.141.200.123]) by roc-mail2.ctron.com (8.8.7/8.8.7) with ESMTP id FAA28623; Thu, 26 Aug 1999 05:31:55 -0400 (EDT)
Received: by new-exc1.ctron.com with Internet Mail Service (5.5.2448.0) id <Q4VZ5JCN>; Thu, 26 Aug 1999 10:25:01 +0100
Message-ID: <[e-mail]>
From: "Waters, Stephen" <[e-mail]>
To: Ambarish Malpani <[e-mail]>
Cc: [e-mail]
Subject: RE: SCVP-01
Date: Thu, 26 Aug 1999 10:25:00 +0100
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2448.0)
Content-Type: text/plain; charset="iso-8859-1"

>From a VPN point of view....

I don't see the need for SCVP for VPN Security Gateways (most of which have
the resource required to role their own validation), or for VPN-enabled
laptops.  

I guess if you had some tiny thing will limited mem/power, you may want it
to use something else (other than certificate processing) to enable trust.

This can be done by asking a globally reachable SVCP server to help you
understand that nasty certificate thing, or you just don't use them in the
first place.

For remote-tiny things, they have the ID of the server they need to connect
to, so all they really need is the servers public key. 

This seem another good application for the 'private public key' setup where
the client is only loaded with its private key, and the public key of the
server.  You would need to live with the risk of the server key
changing/being compromised and spoofed, but that doesn't seem so bad.

I can see that SCVP may be useful in linking complex user policy to
certificates, particularly at the application level. 

Would it not make good sense to role this functions in with OCSP? 

Steve.

 

-----Original Message-----
From: Ambarish Malpani [mailto:[e-mail]]
Sent: Wednesday, August 25, 1999 10:23 PM
To: 'Don Schmidt (Exchange)'; [e-mail]
Subject: RE: SCVP-01


Hi Don,
    Thanks for the feedback. I find your reaction to SCVP
perfectly reasonable. It will serve an important function for
a particular set of users and your group might not be one of
them.

Let me again specify the main benefits of this protocol, as I
see it:

- Allows applications that want to use public key cryptography
to leverage the Public Key Infrastructure (PKI) without needing
to understand its full complexity - SCVP lets you use certs
and does the work of chain building, policy management and
cert validation for you. This is both an issue of footprint
size/processing power *and* the engineering work that needs to
be done to understand PKIX.

- It allows for consistent/centrally managed cert policies,
rather than requiring the policies be implemented (correctly),
on every client desktop, across various different applications.

In some sense, you can think of the SCVP server as a remote
COM object, that is providing certain services for you - you
can choose to either use the service, or do all the work
yourself.

Don't know if this will make you look at it differently, hope
it does.

Regards,
Ambarish

---------------------------------------------------------------------
Ambarish Malpani
Architect                                                650.567.5457
ValiCert, Inc.                                  [e-mail]
1215 Terra Bella Ave.                         http://www.valicert.com
Mountain View, CA 94043-1833


> -----Original Message-----
> From: Don Schmidt (Exchange) [mailto:[e-mail]]
> Sent: Tuesday, August 24, 1999 1:00 PM
> To: 'Ambarish Malpani'; [e-mail]
> Subject: RE: SCVP-01
> 
> 
> Ambarish,
> 
> Since returning from Oslo, I have discussed SCVP with my 
> colleagues and have
> confirmed the position I presented during the PKIX session.  Microsoft
> currently has no plans to implement SCVP.  We are not aware 
> of any demand
> from our customers for such a protocol; whereas, we have 
> several PKI-based
> applications which must run when the client is offline as 
> well as online.
> But most important, we do not agree with the fundamental 
> justification for
> SCVP.  The primary rationale provided in Oslo was that server-based
> certificate validation is required by small devices which do NOT have
> adequate processing and memory capabilities to locally 
> validate certificate
> chains, but DO have readily available network connections to 
> offload this
> work to a server.  It has been our experience that the 
> opposite is true.
> Devices continually increase in processing power and memory 
> to whatever
> level is required, while connectivity continues to be a problem.
> Applications which require constant (or on demand) network 
> connectivity to a
> supporting server typically suffer performance problems and 
> frequently fail
> simply due to dropped packets or connections.
> 
> One might be tempted to negate the connectivity argument if 
> it is believed
> that SCVP is only intended for handheld communication devices 
> which must
> have connectivity to perform their primary function.  
> However, relying on a
> server will add another network hit for every call and 
> possibly introduce a
> performance bottleneck.  Furthermore, since these clients 
> will need to be
> able to perform rudimentary cracking of at least the end entity's
> certificate, it seems we might better spend our time defining 
> a profile that
> limited the chain depth for such devices.   
> 
> Finally SCVP introduces additional security problems that 
> must be addressed
> to make sure a rogue server cannot trick a client into 
> accepting an invalid
> certificate or chain.  Locating and authenticating such 
> servers could be a
> significant challenge for highly mobile users.  OCSP & DCS 
> already face
> these kinds of security issues.  Why solve the same problem 
> over and over in
> separate protocols?  If it can be demonstrated that there is 
> a customer
> demand for SCVP-type services, then it would seem prudent to 
> add them as an
> option to an existing server-centric protocol.
> 
> Don Schmidt
> Program Manager
> Microsoft Corp
> 
> 
> 
>  -----Original Message-----
> From: 	Ambarish Malpani [mailto:[e-mail]] 
> Sent:	Monday, August 23, 1999 11:58 AM
> To:	[e-mail]
> Subject:	SCVP-01
> 
> 
> Hi Guys,
>     I noticed that there hasn't been too much discussion of SCVP
> after the 01 draft came out. Paul and I have got a few comments
> offline, but there hasn't been much on the list. A few people
> expressed interest in getting implementations and I was
> wondering if we have already gone through the major changes
> stage and are winding down the changes that will be made to
> the spec.
> 
> Comments?
> 
> Regards,
> Ambarish
> 
> ---------------------------------------------------------------------
> Ambarish Malpani
> Architect                                                650.567.5457
> ValiCert, Inc.                                  [e-mail]
> 1215 Terra Bella Ave.                         http://www.valicert.com
> Mountain View, CA 94043-1833
> 


Received: from dsg1.OpenDirectory.com.au ([203.108.249.145]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id WAA26297 for <[e-mail]>; Wed, 25 Aug 1999 22:32:13 -0700 (PDT)
Received: by DSG1 with Internet Mail Service (5.0.1458.49) id <RNJY4XFB>; Thu, 26 Aug 1999 15:33:52 +1000
Message-ID: <D1A949D4508DD1119C8100400533BEDC10783B@DSG1>
From: Alan Lloyd <[e-mail]>
To: "'Sweigert, David'" <[e-mail]>, Alan Lloyd <[e-mail]>, "'[e-mail]'" <[e-mail]>, [e-mail], [e-mail]
Subject: RE: More problems with OCSP
Date: Thu, 26 Aug 1999 15:33:51 +1000
X-Priority: 3
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.0.1458.49)
Content-Type: text/plain

Sorry for the delay - can I ask what are you building this with?
Is an X.500 distributed system or LDAP servers - what are the backbone
features you are working with.

What reliability, ownership, DIT referential info and server
connectivity do you want. 

We have router DSAs etc that permit a range of backbone characteristics
(eg load balancing) - including interconnecting those free standing LDAP
servers.

I always try (in designing large scale directory systems)  address the
overall service issues, the capability requirements of the operational
directory system as input to the naming and schema strategy..Then make
this part of the operational design re DSA routers, DSA processes, DBs,
etc.

I am happy to discuss this off list.

regards (humble) alan

> -----Original Message-----
> From:	Sweigert, David 
> Sent:	Wednesday, August 25, 1999 8:28 AM
> To:	Alan Lloyd; '[e-mail]'; [e-mail];
> [e-mail]
> Subject:	RE: More problems with OCSP
> 
> 
> As anyone grappling with the problem of defining a directory
> information
> tree for a multi-national company.  In other words, how do divisions
> in
> the UK and US relate in the DIT if both divisions are within one
> corporate
> organization; say MARKETING.
> 
> Would this be appropriate:
> 
> c=US
> o=GlobalCorp
> ou=Marketing
> 
> and
> 
> c=UK
> o=GlobalCorp
> ou=Marketing
> 
> 
> Any thoughts on this ?
> 
> Dave Sweigert


Received: from dsg1.OpenDirectory.com.au ([203.108.249.145]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id WAA25875 for <[e-mail]>; Wed, 25 Aug 1999 22:11:30 -0700 (PDT)
Received: by DSG1 with Internet Mail Service (5.0.1458.49) id <RNJY4X16>; Thu, 26 Aug 1999 15:13:09 +1000
Message-ID: <D1A949D4508DD1119C8100400533BEDC107838@DSG1>
From: Alan Lloyd <[e-mail]>
To: "'Michael Zolotarev'" <[e-mail]>, Bob Jueneman <[e-mail]>, [e-mail], [e-mail]
Cc: [e-mail]
Subject: RE: SCVP-01
Date: Thu, 26 Aug 1999 15:13:08 +1000
X-Priority: 3
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.0.1458.49)
Content-Type: text/plain; charset="iso-8859-1"

May I add my humble observations - On the box again Alan :-) 
As we all know ( and I will use LDAP as an example) that the total basis
for LDAP was that X.500 was to complex and slow in terms of "protocols"
- And what was missed in the debate is that X.500 is about object
oriented name based transaction systems that applies distributed
management, distributed access controls, authentication distributed
knowledge, etc -  And by the way it also has three protocols for access,
distribution and replication with the information model.

	LDAP is founded on the X.500 directory information system
standards and some have implemented LDAP servers (non distributed desk
top style servers) with a very basic X.500 object model - And some have
built large scale load balancing, multi master, fault tolerant
infrastructure directory services 10's of millions of entries -
distributed, etc, etc that deal with global backbone issues, etc eg
International Orgs, etc. 

	Reality
	LDAP code base = 230kb appx
	DAP code base - (with 50% provided by an ASN.1 compiler -
automatically) = 130-KB
	X.500 full blown with a database 20-25mb (smaller than some word
processors!).

	Lesson - it took three years to re invent a protocol that was
invented 10 years earlier. The arguments abouts LDAP/X.500  size,
complexity, lightweight etc have evaporated from hype into the reality.
ie. can build a "just a protocol" that zero utility without a service
processing and information model - or one can build an information
system (with protocols)  that has commercial infrastructure utility.



	OCSP - the semantic of the protocol is to get a trusted response
from a trusted entity to validate a cert - 
	With all the bugs out of it and making sure the OCSP server can
scale, connect to large scale directories, works with operational and
busines policy elements - etc , the protocol and the distributed
information service (the directory, PKI/CA and business elements)  that
supports the protocol now has a wider commercial utility.

	eg. at the TCP/IP level the protocol issues was comms/networks.
At the application protocol levels, the issues are NOT comms - there are
the semantics of the transaction(s), the processing and the information
needed to support such ie - the design is a service issue with the
protocol being trivial.


	I would have hoped that using an argument - that a small
lightweight, trivial or nanotomic client that cannot validate a
certficate needs  Yet Another Protocol (YAP) is a debate not worth
having. eg. When that protocol when used by millions of mobile clients -
has to be supported in a sercure/pki directory distributed infrastucture
that underpins a commercial business model and investment. The issue
about the client protocol is about 0.0000000000000001% of the problem.

	ie lets have a new type of telephone call control  protocol ? -
but should we not see what dependency there is of this  in the telephone
system.

	If a client has to do a trusted transaction and sign and encrypt
as well as check and validate -the maths of PKI why cant it use OCSP?.
Is the semantic, functionality and processing of OCSP wrong?

	The best way to debate the YAP issues is with reality.

	ie (hypothetically)  SCVP and its server code is only 5 bytes
wheres OCSP  is a whopping 20kbytes - for the same functionality. That
might be worth investigating.. :-)) 


	Customers with tens and hundreds of databases - where that have
to replicate things to everywhere dont want more of the same - as they
get with LDAP servers.

	Customers who build PKIs are using distributed directory
infrastructureand policy based OCSP services  want stability in that - 
	Yet Another Protocol, with yet another PKI information model and
Yet Another Database  with possible replication expence is not
progressing things.

	 
	This YAP for the sake of YAP -because the the last YAP is to
big, slow and complex - is not useful . And "yet another database" for a
specialised function is also being taken off the customers buying list.

	Can someone list the functional and trust differences between
SVCP and OCSP to see what has value SVCP has?


	Thank you all for putting up with my own personal views.

	regards as always alan


> -----Original Message-----
> From:	Michael Zolotarev 
> Sent:	Thursday, August 26, 1999 12:31 PM
> To:	Bob Jueneman; [e-mail]; [e-mail]
> Cc:	[e-mail]
> Subject:	RE: SCVP-01
> 
> A short comment:
> 
> I've been closely looking into the WAP forum for the last couple
> months.
> Whatever commercialized and market-hyped the developments are there,
> it
> appears that a lot of the 'little box' vendors are joining the WAP
> forum.
> The list is impressive and growing fast. So it may worth considering
> their
> needs when contemplating about real world's business cases and
> requirements.
> 
> Being essentially a browser-based platform, a WAP device is driven by
> the
> application which is run by the WAP gateway/app_server. The gateway
> presumably would not have any troubles with performing PKI operations.
> 
> 
> The WAP is not the whole world, of course. However, I feel that there
> is a
> solid trend to produce either a "simple small device", or a
> "powerful_yet_small device". A 'simple small' device would use WAP or
> similar approach, and the other group would presumably be able to
> handle PKI
> itself. Communications, by the way, is not a problem for either group.
> 
> SCVP, as it seems, is trying to address the problems of what can be
> described as a 'middle group'. I'm not convinced that group has its
> evolution niche (except if you are in Kansas state :)).
> 
> Thinking about WAP (and other ultra-thin solutions), the question is
> which
> protocols would be required by the gateway/app_server. Would SCVP help
> there, or OCSP and other existing protocols suffice?
> 
> This is just my personal, marked-influenced opinion. Standard
> disclaimer
> follows here.
> 
> MichaelZ
> 
> 
> -----Original Message-----
> From: Bob Jueneman [mailto:[e-mail]]
> Sent: Thursday, August 26, 1999 10:46 AM
> To: [e-mail]; [e-mail]
> Cc: [e-mail]; [e-mail]
> Subject: RE: SCVP-01
> 
> 
> I might not agree with Microsoft all that often, but in this case I
> do. :-)
> 
> Maybe SCVP would be of some value in a digital phone that was somehow
> involved in processing certificate chains -- it would meet the
> criteria of
> presumably small footprint, yet have outbound network connectivity.  
> Other applications, such as pagers, pay-per-view set top boxes, 
> would not seem to have the necessary connectivity.
> 
> In addition, having been rather deeply involved in the cellular
> industry 
> for a while, I would be concerned about the burden such an approach
> would 
> place on the central servers. Generally, I would like to offload as
> much 
> of the processing to distributed silicon, where the MIPS and the
> memory 
> are much more available and less expensive, rather than burdening the
> central infrastructure.
> 
> I would be interested to understand real-world examples of where there
> is 
> a significant business case for this functionality. No offense
> intended, but
> 
> so far, I haven't seen that it is worth the WG bandwidth, frankly.
> 
> Bob
> 
> >>> Carlisle Adams <[e-mail]> 08/25/99 03:56PM >>>
> Hi Ambarish,
> 
> > ----------
> > From: 	Ambarish Malpani[SMTP:[e-mail]] 
> > Sent: 	Wednesday, August 25, 1999 5:23 PM
> > To: 	'Don Schmidt (Exchange)'; [e-mail] 
> > Subject: 	RE: SCVP-01
> > 
> > Hi Don,
> >     Thanks for the feedback. I find your reaction to SCVP
> > perfectly reasonable. It will serve an important function for
> > a particular set of users and your group might not be one of
> > them.
>  
> Observation #1:
> 
> Don's "group" seems to represent a reasonable fraction of the world's
> population...  :-)
> 
> While I believe they exist, my impression is that we're still waiting
> to
> hear from this "particular set of users" to confirm that the
> functionality
> embodied in SCVP is a legitimate requirement.  Don's "group" has
> stated that
> they don't need this (at least at the moment).  Do we have concrete
> details
> regarding who does need this?
> 
> > Let me again specify the main benefits of this protocol, as I
> > see it:
> > 
> > - Allows applications that want to use public key cryptography
> > to leverage the Public Key Infrastructure (PKI) without needing
> > to understand its full complexity - SCVP lets you use certs
> > and does the work of chain building, policy management and
> > cert validation for you. This is both an issue of footprint
> > size/processing power *and* the engineering work that needs to
> > be done to understand PKIX.
> > 
> > - It allows for consistent/centrally managed cert policies,
> > rather than requiring the policies be implemented (correctly),
> > on every client desktop, across various different applications.
> > 
> > In some sense, you can think of the SCVP server as a remote
> > COM object, that is providing certain services for you - you
> > can choose to either use the service, or do all the work
> > yourself.
>  
> Observation #2:
> 
> It strikes me that the above two paragraphs are somewhat antagonistic.
> If
> I, as a client device, "can choose to either use the service or do all
> the
> work myself", then there is no possibility of consistent /
> centrally-managed
> cert policies.  On the other hand, if devices do not have this choice
> (i.e.,
> if devices MUST off-load the validation work to the central server),
> then
> this itself is a cert processing policy that must be implemented
> (correctly)
> on every client desktop.  What problem, therefore, does SCVP solve?
> 
> 
> [Note:  don't take my observations above as necessarily "for" or
> "against"
> this functionality.  I would just like to make sure that we, as the
> PKIX
> group, are clear on what this protocol is trying to achieve and who
> the
> target audience is.]
> 
> Carlisle.


Received: from tomcat.sac.verio.net ([e-mail] [209.162.64.15]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id WAA25604 for <[e-mail]>; Wed, 25 Aug 1999 22:03:29 -0700 (PDT)
Received: from nma.com (pm03-02.sac.verio.net [209.162.64.68]) by tomcat.sac.verio.net (8.9.1a/8.9.1) with ESMTP id WAA14502; Wed, 25 Aug 1999 22:04:57 -0700 (PDT)
Message-ID: <[e-mail]>
Date: Wed, 25 Aug 1999 22:04:56 -0700
From: Ed Gerck <[e-mail]>
X-Mailer: Mozilla 4.61 [en]C-CCK-MCD {Sony}  (Win98; I)
X-Accept-Language: en
MIME-Version: 1.0
To: Ron Ramsay <[e-mail]>, "[e-mail]" <[e-mail]>
Subject: Options, was Re: To Be, or NR To Be ...
References: <D1A949D4508DD1119C8100400533BEDC15193B@DSG1>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Ron Ramsay wrote:

> But the bit doesn't say anything EXCEPT vanilla, it says STRAWBERRY!
>
> I'm going mad!! Stop! Stop! Stop!

;-)  the slightly maddening point here is not what the NR bit says when it is "on"
(there are at least 4 different flavors already named -- not just strawberry) nor what it
says when it is "off" (there are at least 3 more flavors named) but what other
bits can co-exist with the NR bit if one takes the spec to task, by what it says (but,
what else would one do -- interpret the spec at will?).

And, this was brought up when I went on with Dave Kemp's suggestion that the
spec was neither necessary nor sufficient to specify any key usage bit, not just
the NR bit -- and pointed out that following Dave's suggestion would imply either
that the spec is defining octet-codes that in most cases would be left open to the
CPS (apparently, what Alfred also said when he interpreted the "bit_0 and bit_1"
case to be provided outside of PKIX) or that the spec can indeed be interpreted
at will.

The simple conclusion is that either the PKIX spec provides necessary and
sufficient conditions in order to define the NR bit (and *all* other bits in the
key usage field) or it will be very difficult to warrant interoperation with any
other security spec or overlayed service that may rely on the semantics of
such bits -- and I don't mean only IETF protocols but other protocols and
also applications.   Interoperation is a basic tenet in the Internet but  we seem
to be reaching a limit where matters need to be made clearer in order to define
borders that, paradoxically, will afford interoperation by providing clear
semantics.  To proceed otherwise is to go back to those "value add" services
of the 80's, where splitting the market in incompatible networks/services was
profitable. However, the Internet is becoming more transparent by the day
and showcases a different paradigm -- that there is more value in
interoperation, even with all the problems.

Cheers,

Ed Gerck



Received: from stargate.zergo.com.au (IDENT:[e-mail] [203.2.208.130]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id VAA25396 for <[e-mail]>; Wed, 25 Aug 1999 21:58:13 -0700 (PDT)
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 PAA31869; Thu, 26 Aug 1999 15:00:50 +1000
Received: by sydneymail1.jp.zergo.com.au with Internet Mail Service (5.5.2448.0) id <RQHFN8BV>; Thu, 26 Aug 1999 14:59:35 +1000
Message-ID: <[e-mail]>
From: Michael Zolotarev <[e-mail]>
To: Ambarish Malpani <[e-mail]>, "'Bob Jueneman'" <[e-mail]>, [e-mail]
Cc: [e-mail]
Subject: RE: SCVP-01
Date: Thu, 26 Aug 1999 14:59:28 +1000
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2448.0)
Content-Type: text/plain; charset="iso-8859-1"

>The SCVP model is exactly like the WAP model. The SCVP server is your 'WAP
gateway', that does all the
>stuff that needs to be done with the certificate. The 'simple small device'
simply passes the cert to the SCVP server and >asks it whether it can rely
on this cert for a particular application.

>Am I missing something?

In WAP, a device talks exclusively to the WAP gateway, not to anything else.
And this is the only communication link required to run the WAP-driven
application on the device. The WAP Gateway will execute the PKI, if
necessary. It has enough computation power to do it, itself and/or with a
help of other protocols. So the device would not need to communicate with a
SCVP or other PKI services servers. If used at all, the SCVP would be
employed by the Gateway, not by the device. So the question is whether the
gateway would find the protocol useful, or not.

>P.S. Didn't quite catch the Kansas thing.
When I was writing about the "evolution niche", I've recalled that they had
just banned teaching the evolution theory as a compulsory subject in schools
in the state of Kansas. Could it be just Australian papers making a buzz
over it?

Regards
Michael


Received: from dsg1.OpenDirectory.com.au ([203.108.249.145]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id VAA24573 for <[e-mail]>; Wed, 25 Aug 1999 21:03:40 -0700 (PDT)
Received: by DSG1 with Internet Mail Service (5.0.1458.49) id <RNJY4X1J>; Thu, 26 Aug 1999 14:05:19 +1000
Message-ID: <D1A949D4508DD1119C8100400533BEDC15193C@DSG1>
From: Ron Ramsay <[e-mail]>
To: "'[e-mail]'" <[e-mail]>
Subject: RE: SCVP-01
Date: Thu, 26 Aug 1999 14:05:17 +1000
X-Priority: 3
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.0.1458.49)
Content-Type: text/plain; charset="iso-8859-1"

I think OCSP's scope is too narrow and that some business segments
actually expected that it was providing a validation service. I don't
have any evidence (that I can reveal) that users require a validation
service but, inasmuch as OCSP is perceived as useful, I think the next
step (of performing the validation) is also useful.

There was some debate about a suitable protocol but it was inconclusive.
SCVP is either a good first cut or a suitable straw man.

> -----Original Message-----
> From:	Bob Jueneman [SMTP:[e-mail]]
> Sent:	Thursday, August 26, 1999 10:46 AM
> To:	[e-mail]; [e-mail]
> Cc:	[e-mail]; [e-mail]
> Subject:	RE: SCVP-01
> 
> I might not agree with Microsoft all that often, but in this case I
> do. :-)
> 
> Maybe SCVP would be of some value in a digital phone that was somehow
> involved in processing certificate chains -- it would meet the
> criteria of
> presumably small footprint, yet have outbound network connectivity.  
> Other applications, such as pagers, pay-per-view set top boxes, 
> would not seem to have the necessary connectivity.
> 
> In addition, having been rather deeply involved in the cellular
> industry 
> for a while, I would be concerned about the burden such an approach
> would 
> place on the central servers. Generally, I would like to offload as
> much 
> of the processing to distributed silicon, where the MIPS and the
> memory 
> are much more available and less expensive, rather than burdening the
> central infrastructure.
> 
> I would be interested to understand real-world examples of where there
> is 
> a significant business case for this functionality. No offense
> intended, but 
> so far, I haven't seen that it is worth the WG bandwidth, frankly.
> 
> Bob
> 
> >>> Carlisle Adams <[e-mail]> 08/25/99 03:56PM >>>
> Hi Ambarish,
> 
> > ----------
> > From: 	Ambarish Malpani[SMTP:[e-mail]] 
> > Sent: 	Wednesday, August 25, 1999 5:23 PM
> > To: 	'Don Schmidt (Exchange)'; [e-mail] 
> > Subject: 	RE: SCVP-01
> > 
> > Hi Don,
> >     Thanks for the feedback. I find your reaction to SCVP
> > perfectly reasonable. It will serve an important function for
> > a particular set of users and your group might not be one of
> > them.
>  
> Observation #1:
> 
> Don's "group" seems to represent a reasonable fraction of the world's
> population...  :-)
> 
> While I believe they exist, my impression is that we're still waiting
> to
> hear from this "particular set of users" to confirm that the
> functionality
> embodied in SCVP is a legitimate requirement.  Don's "group" has
> stated that
> they don't need this (at least at the moment).  Do we have concrete
> details
> regarding who does need this?
> 
> > Let me again specify the main benefits of this protocol, as I
> > see it:
> > 
> > - Allows applications that want to use public key cryptography
> > to leverage the Public Key Infrastructure (PKI) without needing
> > to understand its full complexity - SCVP lets you use certs
> > and does the work of chain building, policy management and
> > cert validation for you. This is both an issue of footprint
> > size/processing power *and* the engineering work that needs to
> > be done to understand PKIX.
> > 
> > - It allows for consistent/centrally managed cert policies,
> > rather than requiring the policies be implemented (correctly),
> > on every client desktop, across various different applications.
> > 
> > In some sense, you can think of the SCVP server as a remote
> > COM object, that is providing certain services for you - you
> > can choose to either use the service, or do all the work
> > yourself.
>  
> Observation #2:
> 
> It strikes me that the above two paragraphs are somewhat antagonistic.
> If
> I, as a client device, "can choose to either use the service or do all
> the
> work myself", then there is no possibility of consistent /
> centrally-managed
> cert policies.  On the other hand, if devices do not have this choice
> (i.e.,
> if devices MUST off-load the validation work to the central server),
> then
> this itself is a cert processing policy that must be implemented
> (correctly)
> on every client desktop.  What problem, therefore, does SCVP solve?
> 
> 
> [Note:  don't take my observations above as necessarily "for" or
> "against"
> this functionality.  I would just like to make sure that we, as the
> PKIX
> group, are clear on what this protocol is trying to achieve and who
> the
> target audience is.]
> 
> Carlisle.
> 


Received: from ext-mail.valicert.com (ns1.valicert.com [63.65.221.10]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id UAA24146 for <[e-mail]>; Wed, 25 Aug 1999 20:54:59 -0700 (PDT)
Received: from int-mail.valicert.com (corporate-gw.valicert.com [63.65.221.2]) by ext-mail.valicert.com (8.9.3/8.9.3) with ESMTP id UAA24699; Wed, 25 Aug 1999 20:56:40 -0700 (PDT)
Received: from rhone (rhone.valicert.com [192.168.3.128]) by int-mail.valicert.com (8.9.3/8.9.3) with SMTP id UAA03208; Wed, 25 Aug 1999 20:20:40 -0700 (PDT)
From: "Ambarish Malpani" <[e-mail]>
To: "'Michael Zolotarev'" <[e-mail]>, "'Bob Jueneman'" <[e-mail]>, <[e-mail]>
Cc: <[e-mail]>
Subject: RE: SCVP-01
Date: Wed, 25 Aug 1999 20:23:38 -0700
Message-ID: <009c01beef72$63f5dcc0$[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
Importance: Normal
In-Reply-To: <[e-mail]>

Hi Michael,
    Thanks for the mail. The SCVP model is exactly like the WAP
model. The SCVP server is your 'WAP gateway', that does all the
stuff that needs to be done with the certificate. The 'simple
small device' simply passes the cert to the SCVP server and asks
it whether it can rely on this cert for a particular application.

Am I missing something?

Regards,
Ambarish

P.S. Didn't quite catch the Kansas thing.

---------------------------------------------------------------------
Ambarish Malpani
Architect                                                650.567.5457
ValiCert, Inc.                                  [e-mail]
1215 Terra Bella Ave.                         http://www.valicert.com
Mountain View, CA 94043-1833


> -----Original Message-----
> From: Michael Zolotarev [mailto:[e-mail]]
> Sent: Wednesday, August 25, 1999 7:31 PM
> To: Bob Jueneman; [e-mail]; [e-mail]
> Cc: [e-mail]
> Subject: RE: SCVP-01
> 
> 
> A short comment:
> 
> I've been closely looking into the WAP forum for the last 
> couple months.
> Whatever commercialized and market-hyped the developments are 
> there, it
> appears that a lot of the 'little box' vendors are joining 
> the WAP forum.
> The list is impressive and growing fast. So it may worth 
> considering their
> needs when contemplating about real world's business cases 
> and requirements.
> 
> Being essentially a browser-based platform, a WAP device is 
> driven by the
> application which is run by the WAP gateway/app_server. The gateway
> presumably would not have any troubles with performing PKI 
> operations. 
> 
> The WAP is not the whole world, of course. However, I feel 
> that there is a
> solid trend to produce either a "simple small device", or a
> "powerful_yet_small device". A 'simple small' device would use WAP or
> similar approach, and the other group would presumably be 
> able to handle PKI
> itself. Communications, by the way, is not a problem for either group.
> 
> SCVP, as it seems, is trying to address the problems of what can be
> described as a 'middle group'. I'm not convinced that group has its
> evolution niche (except if you are in Kansas state :)).
> 
> Thinking about WAP (and other ultra-thin solutions), the 
> question is which
> protocols would be required by the gateway/app_server. Would SCVP help
> there, or OCSP and other existing protocols suffice?
> 
> This is just my personal, marked-influenced opinion. Standard 
> disclaimer
> follows here.
> 
> MichaelZ
> 
> 
> -----Original Message-----
> From: Bob Jueneman [mailto:[e-mail]]
> Sent: Thursday, August 26, 1999 10:46 AM
> To: [e-mail]; [e-mail]
> Cc: [e-mail]; [e-mail]
> Subject: RE: SCVP-01
> 
> 
> I might not agree with Microsoft all that often, but in this 
> case I do. :-)
> 
> Maybe SCVP would be of some value in a digital phone that was somehow
> involved in processing certificate chains -- it would meet 
> the criteria of
> presumably small footprint, yet have outbound network connectivity.  
> Other applications, such as pagers, pay-per-view set top boxes, 
> would not seem to have the necessary connectivity.
> 
> In addition, having been rather deeply involved in the 
> cellular industry 
> for a while, I would be concerned about the burden such an 
> approach would 
> place on the central servers. Generally, I would like to 
> offload as much 
> of the processing to distributed silicon, where the MIPS and 
> the memory 
> are much more available and less expensive, rather than burdening the
> central infrastructure.
> 
> I would be interested to understand real-world examples of 
> where there is 
> a significant business case for this functionality. No 
> offense intended, but
> 
> so far, I haven't seen that it is worth the WG bandwidth, frankly.
> 
> Bob
> 
> >>> Carlisle Adams <[e-mail]> 08/25/99 03:56PM >>>
> Hi Ambarish,
> 
> > ----------
> > From: 	Ambarish Malpani[SMTP:[e-mail]] 
> > Sent: 	Wednesday, August 25, 1999 5:23 PM
> > To: 	'Don Schmidt (Exchange)'; [e-mail] 
> > Subject: 	RE: SCVP-01
> > 
> > Hi Don,
> >     Thanks for the feedback. I find your reaction to SCVP
> > perfectly reasonable. It will serve an important function for
> > a particular set of users and your group might not be one of
> > them.
>  
> Observation #1:
> 
> Don's "group" seems to represent a reasonable fraction of the world's
> population...  :-)
> 
> While I believe they exist, my impression is that we're still 
> waiting to
> hear from this "particular set of users" to confirm that the 
> functionality
> embodied in SCVP is a legitimate requirement.  Don's "group" 
> has stated that
> they don't need this (at least at the moment).  Do we have 
> concrete details
> regarding who does need this?
> 
> > Let me again specify the main benefits of this protocol, as I
> > see it:
> > 
> > - Allows applications that want to use public key cryptography
> > to leverage the Public Key Infrastructure (PKI) without needing
> > to understand its full complexity - SCVP lets you use certs
> > and does the work of chain building, policy management and
> > cert validation for you. This is both an issue of footprint
> > size/processing power *and* the engineering work that needs to
> > be done to understand PKIX.
> > 
> > - It allows for consistent/centrally managed cert policies,
> > rather than requiring the policies be implemented (correctly),
> > on every client desktop, across various different applications.
> > 
> > In some sense, you can think of the SCVP server as a remote
> > COM object, that is providing certain services for you - you
> > can choose to either use the service, or do all the work
> > yourself.
>  
> Observation #2:
> 
> It strikes me that the above two paragraphs are somewhat 
> antagonistic.  If
> I, as a client device, "can choose to either use the service 
> or do all the
> work myself", then there is no possibility of consistent / 
> centrally-managed
> cert policies.  On the other hand, if devices do not have 
> this choice (i.e.,
> if devices MUST off-load the validation work to the central 
> server), then
> this itself is a cert processing policy that must be 
> implemented (correctly)
> on every client desktop.  What problem, therefore, does SCVP solve?
> 
> 
> [Note:  don't take my observations above as necessarily "for" 
> or "against"
> this functionality.  I would just like to make sure that we, 
> as the PKIX
> group, are clear on what this protocol is trying to achieve 
> and who the
> target audience is.]
> 
> Carlisle.
> 


Received: from dsg1.OpenDirectory.com.au ([203.108.249.145]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id UAA24094 for <[e-mail]>; Wed, 25 Aug 1999 20:54:25 -0700 (PDT)
Received: by DSG1 with Internet Mail Service (5.0.1458.49) id <RNJY4X11>; Thu, 26 Aug 1999 13:55:42 +1000
Message-ID: <D1A949D4508DD1119C8100400533BEDC15193B@DSG1>
From: Ron Ramsay <[e-mail]>
To: "'Ed Gerck'" <[e-mail]>, Peter Williams <[e-mail]>
Cc: [e-mail]
Subject: RE: Options, was Re: To Be, or NR To Be ...
Date: Thu, 26 Aug 1999 13:55:40 +1000
X-Priority: 3
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.0.1458.49)
Content-Type: text/plain

But the bit doesn't say anything EXCEPT vanilla, it says STRAWBERRY!

I'm going mad!! Stop! Stop! Stop!

> -----Original Message-----
> From:	Ed Gerck [SMTP:[e-mail]]
> Sent:	Thursday, August 26, 1999 1:26 PM
> To:	Peter Williams
> Cc:	[e-mail]
> Subject:	Re: Options, was Re: To Be, or NR To Be ...
> 
> 
> 
> Peter Williams wrote:
> 
> >
> > > Thus, the value of bit 0 does not depend on the value of bit 1;
> they are
> > > in fact independent.
> >
> > That is quite correct. In PKIX, ISO NR and use of the NR bit
> > does not depend on use of a digital signature
> > mechanism (except as it is is to issue certs and CRLs.)
> 
> Peter:
> 
> If I say that  "I want an ice-cream other than vanilla", this means
> that I want ANY
> ice-cream EXCEPT vanilla.  Thus, when the spec says that bit_0 is TRUE
> when
> the subject public key is used with a digital signature mechanism to
> support
> security services OTHER THAN non-repudiation (bit 1), then the spec is
> saying
> that any service can be used with bit_0 EXCEPT non-repudiation.    For
> a logical
> derivation and further comments, please see [1].
> 
> Is the spec wrongly written in this regard?  Well, this much is
> certain because
> 2459 also says that it does not restrict the combinations of bits that
> may be
> set in an instantiation of the keyUsage extension -- which is in
> contradiction with
> the above.  Thus, either passage must be corrected; and this is NOT
> the only
> example (check the cRLSign bit for instance).
> 
> The assumption that the certificate can be used for signing (bit_0 =
> TRUE) also
> when "bit_1 = TRUE" due to system elements outside of those specified
> in PKIX
> is a simple fallacy because bit_1 is defined as a signed bit by the
> PKIX
> specification and cannot be asserted *after* bit_0 is signed.  The
> entire certificate is
> signed and "frozen" at the time of issuance and must thus conform to
> the spec at that
> time, which affirms that bit_0 is TRUE when the subject public key is
> used with a digital
> signature mechanism to support security services EXCEPT
> non-repudiation (bit_1).
> 
> Cheers,
> 
> Ed Gerck
> 
> 
> 
> [1]   As I quoted, the sentence in 2459 specifies:
> 
>        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)
> 
> Now, suppose I define two boolean variables A and B (where "bit_1"
> means both
> the service of "non-repudiation" and the bit that indicates the
> service):
> 
> A = (the subject public key is used with a digital signature mechanism
> to support ANY security services)
> B = (the subject public key is used with a digital signature mechanism
> to support security services other than bit_1)
> 
> which variables I define  to be TRUE if the subject public-key "IS"
> used in the context
> specified or FALSE if it is NOT used in that context.
> 
> The logical expression that is equivalent to the quoted phrase in 2459
> would read:
> 
> bit_0 =  A and not  (bit_1)
> 
> because, in logic notation,  B = A and not (bit_1).  The set of
> security services in A
> is larger than the set of security services in B -- because B excludes
> ("other than")
> the non-repudiation service.
> 
> In other words, 2459 says that bit_0 is asserted when a subject's
> public-key is used
> with a digital signature mechanism to support services which are in
> mathematical
> complement to non-repudiation.  Hence, bit_0 and bit_1 can't be TRUE
> at the same
> time if the spec text is correct.
> 


Received: from tomcat.sac.verio.net ([e-mail] [209.162.64.15]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id UAA23544 for <[e-mail]>; Wed, 25 Aug 1999 20:26:25 -0700 (PDT)
Received: from nma.com (pm02-21.sac.verio.net [209.162.64.40]) by tomcat.sac.verio.net (8.9.1a/8.9.1) with ESMTP id UAA26255; Wed, 25 Aug 1999 20:26:15 -0700 (PDT)
Message-ID: <[e-mail]>
Date: Wed, 25 Aug 1999 20:26:16 -0700
From: Ed Gerck <[e-mail]>
X-Mailer: Mozilla 4.61 [en]C-CCK-MCD {Sony}  (Win98; I)
X-Accept-Language: en
MIME-Version: 1.0
To: Peter Williams <[e-mail]>
CC: [e-mail]
Subject: Re: Options, was Re: To Be, or NR To Be ...
References: <[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Peter Williams wrote:

>
> > Thus, the value of bit 0 does not depend on the value of bit 1; they are
> > in fact independent.
>
> That is quite correct. In PKIX, ISO NR and use of the NR bit
> does not depend on use of a digital signature
> mechanism (except as it is is to issue certs and CRLs.)

Peter:

If I say that  "I want an ice-cream other than vanilla", this means that I want ANY
ice-cream EXCEPT vanilla.  Thus, when the spec says that bit_0 is TRUE when
the subject public key is used with a digital signature mechanism to support
security services OTHER THAN non-repudiation (bit 1), then the spec is saying
that any service can be used with bit_0 EXCEPT non-repudiation.    For a logical
derivation and further comments, please see [1].

Is the spec wrongly written in this regard?  Well, this much is certain because
2459 also says that it does not restrict the combinations of bits that may be
set in an instantiation of the keyUsage extension -- which is in contradiction with
the above.  Thus, either passage must be corrected; and this is NOT the only
example (check the cRLSign bit for instance).

The assumption that the certificate can be used for signing (bit_0 = TRUE) also
when "bit_1 = TRUE" due to system elements outside of those specified in PKIX
is a simple fallacy because bit_1 is defined as a signed bit by the PKIX
specification and cannot be asserted *after* bit_0 is signed.  The entire certificate is
signed and "frozen" at the time of issuance and must thus conform to the spec at that
time, which affirms that bit_0 is TRUE when the subject public key is used with a digital
signature mechanism to support security services EXCEPT non-repudiation (bit_1).

Cheers,

Ed Gerck



[1]   As I quoted, the sentence in 2459 specifies:

       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)

Now, suppose I define two boolean variables A and B (where "bit_1" means both
the service of "non-repudiation" and the bit that indicates the service):

A = (the subject public key is used with a digital signature mechanism to support ANY security services)
B = (the subject public key is used with a digital signature mechanism to support security services other than bit_1)

which variables I define  to be TRUE if the subject public-key "IS" used in the context
specified or FALSE if it is NOT used in that context.

The logical expression that is equivalent to the quoted phrase in 2459 would read:

bit_0 =  A and not  (bit_1)

because, in logic notation,  B = A and not (bit_1).  The set of security services in A
is larger than the set of security services in B -- because B excludes ("other than")
the non-repudiation service.

In other words, 2459 says that bit_0 is asserted when a subject's public-key is used
with a digital signature mechanism to support services which are in mathematical
complement to non-repudiation.  Hence, bit_0 and bit_1 can't be TRUE at the same
time if the spec text is correct.




Received: from stargate.zergo.com.au (IDENT:[e-mail] [203.2.208.130]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id TAA22871 for <[e-mail]>; Wed, 25 Aug 1999 19:28:41 -0700 (PDT)
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 MAA30452; Thu, 26 Aug 1999 12:32:14 +1000
Received: by sydneymail1.jp.zergo.com.au with Internet Mail Service (5.5.2448.0) id <RQHFN770>; Thu, 26 Aug 1999 12:30:57 +1000
Message-ID: <[e-mail]>
From: Michael Zolotarev <[e-mail]>
To: Bob Jueneman <[e-mail]>, [e-mail], [e-mail]
Cc: [e-mail]
Subject: RE: SCVP-01
Date: Thu, 26 Aug 1999 12:30:47 +1000
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2448.0)
Content-Type: text/plain; charset="iso-8859-1"

A short comment:

I've been closely looking into the WAP forum for the last couple months.
Whatever commercialized and market-hyped the developments are there, it
appears that a lot of the 'little box' vendors are joining the WAP forum.
The list is impressive and growing fast. So it may worth considering their
needs when contemplating about real world's business cases and requirements.

Being essentially a browser-based platform, a WAP device is driven by the
application which is run by the WAP gateway/app_server. The gateway
presumably would not have any troubles with performing PKI operations. 

The WAP is not the whole world, of course. However, I feel that there is a
solid trend to produce either a "simple small device", or a
"powerful_yet_small device". A 'simple small' device would use WAP or
similar approach, and the other group would presumably be able to handle PKI
itself. Communications, by the way, is not a problem for either group.

SCVP, as it seems, is trying to address the problems of what can be
described as a 'middle group'. I'm not convinced that group has its
evolution niche (except if you are in Kansas state :)).

Thinking about WAP (and other ultra-thin solutions), the question is which
protocols would be required by the gateway/app_server. Would SCVP help
there, or OCSP and other existing protocols suffice?

This is just my personal, marked-influenced opinion. Standard disclaimer
follows here.

MichaelZ


-----Original Message-----
From: Bob Jueneman [mailto:[e-mail]]
Sent: Thursday, August 26, 1999 10:46 AM
To: [e-mail]; [e-mail]
Cc: [e-mail]; [e-mail]
Subject: RE: SCVP-01


I might not agree with Microsoft all that often, but in this case I do. :-)

Maybe SCVP would be of some value in a digital phone that was somehow
involved in processing certificate chains -- it would meet the criteria of
presumably small footprint, yet have outbound network connectivity.  
Other applications, such as pagers, pay-per-view set top boxes, 
would not seem to have the necessary connectivity.

In addition, having been rather deeply involved in the cellular industry 
for a while, I would be concerned about the burden such an approach would 
place on the central servers. Generally, I would like to offload as much 
of the processing to distributed silicon, where the MIPS and the memory 
are much more available and less expensive, rather than burdening the
central infrastructure.

I would be interested to understand real-world examples of where there is 
a significant business case for this functionality. No offense intended, but

so far, I haven't seen that it is worth the WG bandwidth, frankly.

Bob

>>> Carlisle Adams <[e-mail]> 08/25/99 03:56PM >>>
Hi Ambarish,

> ----------
> From: 	Ambarish Malpani[SMTP:[e-mail]] 
> Sent: 	Wednesday, August 25, 1999 5:23 PM
> To: 	'Don Schmidt (Exchange)'; [e-mail] 
> Subject: 	RE: SCVP-01
> 
> Hi Don,
>     Thanks for the feedback. I find your reaction to SCVP
> perfectly reasonable. It will serve an important function for
> a particular set of users and your group might not be one of
> them.
 
Observation #1:

Don's "group" seems to represent a reasonable fraction of the world's
population...  :-)

While I believe they exist, my impression is that we're still waiting to
hear from this "particular set of users" to confirm that the functionality
embodied in SCVP is a legitimate requirement.  Don's "group" has stated that
they don't need this (at least at the moment).  Do we have concrete details
regarding who does need this?

> Let me again specify the main benefits of this protocol, as I
> see it:
> 
> - Allows applications that want to use public key cryptography
> to leverage the Public Key Infrastructure (PKI) without needing
> to understand its full complexity - SCVP lets you use certs
> and does the work of chain building, policy management and
> cert validation for you. This is both an issue of footprint
> size/processing power *and* the engineering work that needs to
> be done to understand PKIX.
> 
> - It allows for consistent/centrally managed cert policies,
> rather than requiring the policies be implemented (correctly),
> on every client desktop, across various different applications.
> 
> In some sense, you can think of the SCVP server as a remote
> COM object, that is providing certain services for you - you
> can choose to either use the service, or do all the work
> yourself.
 
Observation #2:

It strikes me that the above two paragraphs are somewhat antagonistic.  If
I, as a client device, "can choose to either use the service or do all the
work myself", then there is no possibility of consistent / centrally-managed
cert policies.  On the other hand, if devices do not have this choice (i.e.,
if devices MUST off-load the validation work to the central server), then
this itself is a cert processing policy that must be implemented (correctly)
on every client desktop.  What problem, therefore, does SCVP solve?


[Note:  don't take my observations above as necessarily "for" or "against"
this functionality.  I would just like to make sure that we, as the PKIX
group, are clear on what this protocol is trying to achieve and who the
target audience is.]

Carlisle.



Received: from tomcat.sac.verio.net ([e-mail] [209.162.64.15]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id TAA22621 for <[e-mail]>; Wed, 25 Aug 1999 19:14:31 -0700 (PDT)
Received: from nma.com (pm07-10.sac.verio.net [209.162.65.29]) by tomcat.sac.verio.net (8.9.1a/8.9.1) with ESMTP id TAA13239; Wed, 25 Aug 1999 19:16:10 -0700 (PDT)
Message-ID: <[e-mail]>
Date: Wed, 25 Aug 1999 19:16:11 -0700
From: Ed Gerck <[e-mail]>
X-Mailer: Mozilla 4.61 [en]C-CCK-MCD {Sony}  (Win98; I)
X-Accept-Language: en
MIME-Version: 1.0
To: "[e-mail]" <[e-mail]>, Alfred Arsenault <[e-mail]>
Subject: Re: Options, was Re: To Be, or NR To Be ... 
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Alfred Arsenaul wrote:

>Ed Gerck wrote:
>>
>>
>>
>>
>> First, of course, a necessary and sufficient condition for a certificate to be
>> verifiable is for it to be digitally signed.  So, I guess this much is OK and
>> equivalent: "certificate is signed" <--> "certificate is verifiable".  A certificate
>> is verifiable if and only if it is signed -- the "if" is a sufficient condition and
>> the "only if" a necessary condition.
>>
>
>AWA:  Bzzt!  Sorry, that is not correct, but thank you for playing
>anyway.

Alfred:

I regret the nonsense you wrote above -- but I find it nonetheless fitting to
this discussion.

>The fact that is certificate is signed does NOT make it verifiable.

Yes it does, as verifiable as the signature allows it.  If a certificate
IS signed THEN I affirm that this is equivalent to saying that the
certificate is verifiable -- where, of course, "is verifiable" means that
it CAN be verified.  And, of course, the fact that it CAN be verified
does not mean that it MUST be verified.  Of course, it also depends
if the available public-keys match the signature (maybe not, and maybe
you need more keys), if the public-key that matches has not been
revoked, etc.  But, nonetheless the certificate is verifiable and the
result is either YES or NO -- if the certificate is signed.

You are makling a simple confusion in logic and I suggest you re-read
my message. It might be much more instructive than if I would try to
explain it again.

And, please, next time you don't understand something, just please say what
you don't understand.  There is no need to continue the tone I see in your
message and which I surely expect you to recall in the name of civil discourse.

Cheers,

Ed Gerck



Received: from prv-mail20.provo.novell.com (prv-mail20.provo.novell.com [137.65.82.195]) by mail.proper.com (8.9.3/8.9.3) with SMTP id RAA21327 for <[e-mail]>; Wed, 25 Aug 1999 17:44:44 -0700 (PDT)
Received: from INET-PRV-Message_Server by prv-mail20.provo.novell.com with Novell_GroupWise; Wed, 25 Aug 1999 18:45:52 -0600
Message-Id: <[e-mail]>
X-Mailer: Novell GroupWise 5.5.2
Date: Wed, 25 Aug 1999 18:45:47 -0600
From: "Bob Jueneman" <[e-mail]>
To: <[e-mail]>, <[e-mail]>
Cc: <[e-mail]>, <[e-mail]>
Subject: RE: SCVP-01
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 mail.proper.com id RAA21328

I might not agree with Microsoft all that often, but in this case I do. :-)

Maybe SCVP would be of some value in a digital phone that was somehow
involved in processing certificate chains -- it would meet the criteria of
presumably small footprint, yet have outbound network connectivity.  
Other applications, such as pagers, pay-per-view set top boxes, 
would not seem to have the necessary connectivity.

In addition, having been rather deeply involved in the cellular industry 
for a while, I would be concerned about the burden such an approach would 
place on the central servers. Generally, I would like to offload as much 
of the processing to distributed silicon, where the MIPS and the memory 
are much more available and less expensive, rather than burdening the
central infrastructure.

I would be interested to understand real-world examples of where there is 
a significant business case for this functionality. No offense intended, but 
so far, I haven't seen that it is worth the WG bandwidth, frankly.

Bob

>>> Carlisle Adams <[e-mail]> 08/25/99 03:56PM >>>
Hi Ambarish,

> ----------
> From: 	Ambarish Malpani[SMTP:[e-mail]] 
> Sent: 	Wednesday, August 25, 1999 5:23 PM
> To: 	'Don Schmidt (Exchange)'; [e-mail] 
> Subject: 	RE: SCVP-01
> 
> Hi Don,
>     Thanks for the feedback. I find your reaction to SCVP
> perfectly reasonable. It will serve an important function for
> a particular set of users and your group might not be one of
> them.
 
Observation #1:

Don's "group" seems to represent a reasonable fraction of the world's
population...  :-)

While I believe they exist, my impression is that we're still waiting to
hear from this "particular set of users" to confirm that the functionality
embodied in SCVP is a legitimate requirement.  Don's "group" has stated that
they don't need this (at least at the moment).  Do we have concrete details
regarding who does need this?

> Let me again specify the main benefits of this protocol, as I
> see it:
> 
> - Allows applications that want to use public key cryptography
> to leverage the Public Key Infrastructure (PKI) without needing
> to understand its full complexity - SCVP lets you use certs
> and does the work of chain building, policy management and
> cert validation for you. This is both an issue of footprint
> size/processing power *and* the engineering work that needs to
> be done to understand PKIX.
> 
> - It allows for consistent/centrally managed cert policies,
> rather than requiring the policies be implemented (correctly),
> on every client desktop, across various different applications.
> 
> In some sense, you can think of the SCVP server as a remote
> COM object, that is providing certain services for you - you
> can choose to either use the service, or do all the work
> yourself.
 
Observation #2:

It strikes me that the above two paragraphs are somewhat antagonistic.  If
I, as a client device, "can choose to either use the service or do all the
work myself", then there is no possibility of consistent / centrally-managed
cert policies.  On the other hand, if devices do not have this choice (i.e.,
if devices MUST off-load the validation work to the central server), then
this itself is a cert processing policy that must be implemented (correctly)
on every client desktop.  What problem, therefore, does SCVP solve?


[Note:  don't take my observations above as necessarily "for" or "against"
this functionality.  I would just like to make sure that we, as the PKIX
group, are clear on what this protocol is trying to achieve and who the
target audience is.]

Carlisle.




Received: from prv-mail20.provo.novell.com (prv-mail20.provo.novell.com [137.65.82.195]) by mail.proper.com (8.9.3/8.9.3) with SMTP id RAA21065 for <[e-mail]>; Wed, 25 Aug 1999 17:31:18 -0700 (PDT)
Received: from INET-PRV-Message_Server by prv-mail20.provo.novell.com with Novell_GroupWise; Wed, 25 Aug 1999 18:32:28 -0600
Message-Id: <[e-mail]>
X-Mailer: Novell GroupWise 5.5.2
Date: Wed, 25 Aug 1999 18:32:24 -0600
From: "Bob Jueneman" <[e-mail]>
To: <[e-mail]>, <[e-mail]>
Subject: RE: Options, was Re: To Be, or NR To Be ...
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 mail.proper.com id RAA21066

Elliot,

A couple of observations.

First, I'm not sure that I agree that if the keyUsage extension is critical, 
and NR==0, that you are forbidden to use "it" (whatever "it" might be).

I know that this issue has been discussed previously in conjunction with another
attribute, and I may not be remembering it properly, but I thought that the 
Critical bit merely meant "if you don't understand what this bit means, 
you should reject the certificate"  That's not quite the same thing as 
saying "if you do understand what this bit means, you are absolutely
compelled to either do or not do that thing, under pain of ...?"

Secondly, although NR==0 clearly means, "you shouldn't assume that
the NR property applies" it isn't clear that that is useful if I don't know what
NR means.  What is the CA, the subscriber, and/or the relying party 
supposed to do in that case?  It still isn't clear, and so it's an empty bag.
Maybe NR means, 'hang your clothes on a hickory limb, and don't
go near the water." :-)  I don't know what that means, either.

I am beginning to be of the opinion that we should deprecate the NR 
bit entirely, and then define several new bits to define exactly what we 
do mean, as I suggest under the "subdividing the NR bit" thread.

I certainly agree that "go read the CPS" adds little or nothing. Does
NR==0 mean that I don't have to read the CPS?  If so, that would be 
a very useful thing to have, but I don't think it means nonrepudiation. :-)

At this point, I am afraid that there is so much baggage, implied semantics,
and past history in the name "nonrepudiation" that I don't think we will 
ever achieve consensus.

There is a little bit of merit in Ed's Proof of Authentication label, but that doesn't
really connote what I would like at least one of the bits to mean.  And 
"rebuttable presumption" also has some merit, and so does "intent to sign".

I think that everyone but Steve Kent believes that the name "nonrepudiation" 
conveys something quite different than the current definition, which to my 
mind at least is hopelessly vague and circular.  However, we have not 
yet achieved consensus on one single definition of what it does mean, 
in part, I think because there are multiple things going on that are all 
interrelated, and a single bit is simply not sufficient to cover them all.

What do others thing about deprecating NR, and starting over with a 
clean sheet of paper?

Bob
>
>
>>>> Elliot Ginsburg <[e-mail]> 08/25/99 02:08PM >>>
>I think everyone agrees that the keyUsage extension provides more
>information than would be present without it. The discussion on this
>list seems to be, exactly what information does it provide? Anyone have
>a clear proposal to make for what it means, other than 'go read the
>CPS', because this adds nothing.
>
>It seems easy to decide that NR==0 means 'don't use it for NR' (if
>critical, you're forbidden to; if non-critical, you're advised not to).
>But what exactly does NR==1 convey? From reading this list, I might
>conclude it means 'you might want to use it for NR, depending on the
>policy, your requirements, and the availability of NR services to you'.
>While this doesn't do much, at least NR==0  is still very useful.
>
>Elliott N Ginsburg
>CygnaCom Solutions
>[e-mail] 
>703-848-0883
>703-848-0960(FAX)
>
>> -----Original Message-----
>> From:	David P. Kemp [SMTP:[e-mail]] 
>> Sent:	Wednesday, August 25, 1999 2:48 PM
>> To:	[e-mail] 
>> Subject:	Re: Options, was Re: To Be, or NR To Be ...
>> 
>> 
>> > From: Tony Bartoletti <[e-mail]> 
>> > 
>> > In some ways, the NR-bit is like marketing bottles of wood alcohol
>> that
>> > are simply labeled "alcohol".  The designation is "not necessary" to
>> those
>> > that have performed investigation and use the liquid for cleaning
>> purposes.
>> > The designation is "not sufficient" for those who assume that the
>> liquid
>> > is grain alcohol and can be taken internally.
>> 
>> 
>> Your position is that more information on the label is better?
>> 
>> What label should be attached to a key which is known to be relatively
>> less suitable for supporting a NR process (perhaps because the binding
>> between a single individual and a specific private key is weak or
>> nonexistent) - "Key, NR=0", or simply "Key" ?
>> 
>> The "necessary and sufficient" line of reasoning is as bogus with
>> respect to the NR bit as it is with respect to any other bit.  A
>> necessary and sufficient statement says that the set of keys (or more
>> generally, the set of technologies) which can support and will provide
>> an XX operation is identical to the set of keys which have the XX bit
>> asserted in a certificate.  No matter what you value you substitute
>> for
>> XX (digitalSignature, nonRepudiation, keyEncipherment, ...
>> decipherOnly), the "necessary and sufficient" condition is patently
>> false.  We have the keyUsage extension because a cert with it provides
>> more information than a cert without it, not because the extension is
>> either necessary or sufficient to achieve any particular security
>> goal.
>
>
>
>



Received: from ext-mail.valicert.com (ns1.valicert.com [63.65.221.10]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id QAA20118 for <[e-mail]>; Wed, 25 Aug 1999 16:41:06 -0700 (PDT)
Received: from int-mail.valicert.com (corporate-gw.valicert.com [63.65.221.2]) by ext-mail.valicert.com (8.9.3/8.9.3) with ESMTP id QAA23759; Wed, 25 Aug 1999 16:42:47 -0700 (PDT)
Received: from rsalaptop ([192.168.3.230]) by int-mail.valicert.com (8.9.3/8.9.3) with SMTP id QAA00220; Wed, 25 Aug 1999 16:42:46 -0700 (PDT)
From: "Peter Williams" <[e-mail]>
To: "Alfred Arsenault" <[e-mail]>
Cc: <[e-mail]>
Subject: RE: Options, was Re: To Be, or NR To Be ...
Date: Wed, 25 Aug 1999 16:43:39 -0700
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]>

 
> Thus, the value of bit 0 does not depend on the value of bit 1; they are
> in fact independent.

That is quite correct. In PKIX, ISO NR and use of the NR bit
does not depend on use of a digital signature
mechanism (except as it is is to issue certs and CRLs.)



Received: from ext-mail.valicert.com (ns1.valicert.com [63.65.221.10]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id PAA18893 for <[e-mail]>; Wed, 25 Aug 1999 15:46:08 -0700 (PDT)
Received: from int-mail.valicert.com (corporate-gw.valicert.com [63.65.221.2]) by ext-mail.valicert.com (8.9.3/8.9.3) with ESMTP id PAA23412; Wed, 25 Aug 1999 15:47:48 -0700 (PDT)
Received: from rhone (rhone.valicert.com [192.168.3.128]) by int-mail.valicert.com (8.9.3/8.9.3) with SMTP id PAA29006; Wed, 25 Aug 1999 15:47:47 -0700 (PDT)
From: "Ambarish Malpani" <[e-mail]>
To: "'Carlisle Adams'" <[e-mail]>
Cc: <[e-mail]>, <[e-mail]>
Subject: RE: SCVP-01
Date: Wed, 25 Aug 1999 15:50:45 -0700
Message-ID: <008b01beef4c$451639b0$[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
Importance: Normal
In-Reply-To: <[e-mail]>

Hi Carlisle,
    Comments below:


---------------------------------------------------------------------
Ambarish Malpani
Architect                                                650.567.5457
ValiCert, Inc.                                  [e-mail]
1215 Terra Bella Ave.                         http://www.valicert.com
Mountain View, CA 94043-1833


> -----Original Message-----
> From: Carlisle Adams [mailto:[e-mail]]
> Sent: Wednesday, August 25, 1999 2:57 PM
> To: 'Ambarish Malpani'
> Cc: [e-mail]; '[e-mail]'
> Subject: RE: SCVP-01
> 
> 
> Hi Ambarish,
> 
> > ----------
> > From: 	Ambarish Malpani[SMTP:[e-mail]]
> > Sent: 	Wednesday, August 25, 1999 5:23 PM
> > To: 	'Don Schmidt (Exchange)'; [e-mail]
> > Subject: 	RE: SCVP-01
> > 
> > Hi Don,
> >     Thanks for the feedback. I find your reaction to SCVP
> > perfectly reasonable. It will serve an important function for
> > a particular set of users and your group might not be one of
> > them.
>  
> Observation #1:
> 
> Don's "group" seems to represent a reasonable fraction of the world's
> population...  :-)

I knews Microsoft was big - didn't realize it was that big :-)

> 
> While I believe they exist, my impression is that we're still 
> waiting to
> hear from this "particular set of users" to confirm that the 
> functionality
> embodied in SCVP is a legitimate requirement.  Don's "group" 
> has stated that
> they don't need this (at least at the moment).  Do we have 
> concrete details
> regarding who does need this?

I have had conversations with people who are interested in this.
Also, we have had quite a few of our customers use our tookit
to do OCSP, but really wanted SCVP-like functionality. Yes, there
are such people, unfortunately, most of them do not read the
PKIX list - they belong to my first group of users - people
who want to user public key cryptography without the overhead
of understanding all of PKIX.

> 
> > Let me again specify the main benefits of this protocol, as I
> > see it:
> > 
> > - Allows applications that want to use public key cryptography
> > to leverage the Public Key Infrastructure (PKI) without needing
> > to understand its full complexity - SCVP lets you use certs
> > and does the work of chain building, policy management and
> > cert validation for you. This is both an issue of footprint
> > size/processing power *and* the engineering work that needs to
> > be done to understand PKIX.
> > 
> > - It allows for consistent/centrally managed cert policies,
> > rather than requiring the policies be implemented (correctly),
> > on every client desktop, across various different applications.
> > 
> > In some sense, you can think of the SCVP server as a remote
> > COM object, that is providing certain services for you - you
> > can choose to either use the service, or do all the work
> > yourself.
>  
> Observation #2:
> 
> It strikes me that the above two paragraphs are somewhat 
> antagonistic.  If
> I, as a client device, "can choose to either use the service 
> or do all the
> work myself", then there is no possibility of consistent / 
> centrally-managed
> cert policies.  On the other hand, if devices do not have 
> this choice (i.e.,
> if devices MUST off-load the validation work to the central 
> server), then
> this itself is a cert processing policy that must be 
> implemented (correctly)
> on every client desktop.  What problem, therefore, does SCVP solve?

I was a little unclear in my last paragraph. The person making
the choice of whether their application does cert processing
itself, or relies on an SCVP server makes the decision while
developing the application. I do not see most applications
giving users the choice of either using a local implementation
of policy or talking to the server. The "on the other hand" case
you are talking about is right on - yes, I am talking about
a cert processing policy, that needs to be implemented (correctly)
on every client desktop - SCVP. However, I am relatively sure
you won't argue that correctly implementing SCVP is quite a
bit easier than correctly implementing PKIX Part 1(2459),
LDAP Op Protocol (2559), OCSP (2560), LDAP Schema for PKIX(2587),
LDAP (1777), ...
 


> 
> 
> [Note:  don't take my observations above as necessarily "for" 
> or "against"
> this functionality.  I would just like to make sure that we, 
> as the PKIX
> group, are clear on what this protocol is trying to achieve 
> and who the
> target audience is.]

Always a pleasure responding to your clarification mails :-)

> 
> Carlisle.
> 

Regards,
Ambarish



Received: from mail.rdc1.md.home.com ([e-mail] [24.2.2.66]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id PAA18314 for <[e-mail]>; Wed, 25 Aug 1999 15:33:51 -0700 (PDT)
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]>; Wed, 25 Aug 1999 15:35:31 -0700
Message-ID: <[e-mail]>
Date: Wed, 25 Aug 1999 18:33:34 -0400
From: Alfred Arsenault <[e-mail]>
Organization: @Home Network
X-Mailer: Mozilla 4.5 [en]C-AtHome0405  (Win95; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Ed Gerck <[e-mail]>
CC: "[e-mail]" <[e-mail]>
Subject: Re: Options, was Re: To Be, or NR To Be ...
References: <32648884.935605032017.JavaMail.brazil@brazil> <[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Ed Gerck wrote:
> 

>
> 
> First, of course, a necessary and sufficient condition for a certificate to be
> verifiable is for it to be digitally signed.  So, I guess this much is OK and
> equivalent: "certificate is signed" <--> "certificate is verifiable".  A certificate
> is verifiable if and only if it is signed -- the "if" is a sufficient condition and
> the "only if" a necessary condition.
>

AWA:  Bzzt!  Sorry, that is not correct, but thank you for playing
anyway.

The fact that is certificate is signed does NOT make it verifiable.  A
certificate is verifiable only if it is signed - that much is true
within the context of PKIX.  However, a signed certificate is not
necessarily verifiable - it might not be possible to construct a cert
path from the cert back to a trust point; revocation information may not
be available, etc.

 
> Next, we study the eight key usage bits defined in RFC 2459 and which define
> the purpose (e.g., encipherment, signature, certificate signing) of the key
> contained in the certificate, which may be:
> 
>            digitalSignature        (0),
>            nonRepudiation          (1),
>            keyEncipherment         (2),
>            dataEncipherment        (3),
>            keyAgreement            (4),
>            keyCertSign             (5),
>            cRLSign                 (6),
>            encipherOnly            (7),
>            decipherOnly            (8)
> 
> Now, we begin to read:
> 
>      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)
> 
> which means that the first two bits are not independent. So, you are right,
> if the meaning of bit 0 is going to depend on bit 1 and the state where both
> are set is undefined, why have them as two independent bits?    Indeed, who
> cares what is bitwise necessary and sufficient in the good old laws of logic
> representation, if those bits are not representing logical states?
> 

AWA: Once again, incorrect.  We've had this discussion numerous times
before.  Let's define some service, call it "FRED".  (I prefer to call
it "non-repudiation", but I'm trying to avoid getting wrapped up in that
mindgame for now.)

Bit 0 is to be set if the certificate is to be used for signing in cases
where "FRED" is not provided.

Bit 1 is to be set if the certificate is to be used for signing is cases
where "FRED" is provided.

If the certificate is to be used for signing in both cases (i.e., it's
okay to use this cert for signing when "FRED" is to be provided by
system elements outside of those specified in PKIX; and when "FRED" is
not provided in the system), then both bit 0 AND bit 1 can be set. 
Thus, the value of bit 0 does not depend on the value of bit 1; they are
in fact independent.

To quote from RFC 2459:

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


			Al Arsenault

--- speaking only for myself; yada, yada, yada


Received: from gatekeeper.entrust.com (gatekeeper.entrust.com [204.101.128.170]) by mail.proper.com (8.9.3/8.9.3) with SMTP id OAA17414 for <[e-mail]>; Wed, 25 Aug 1999 14:57:42 -0700 (PDT)
Received: 	id RAA03681; Wed, 25 Aug 1999 17:54:21 -0400
Received: by gateway id <NP65MHP6>; Wed, 25 Aug 1999 17:56:59 -0400
Message-ID: <[e-mail]>
From: Carlisle Adams <[e-mail]>
To: "'Ambarish Malpani'" <[e-mail]>
Cc: [e-mail], "'[e-mail]'" <[e-mail]>
Subject: RE: SCVP-01
Date: Wed, 25 Aug 1999 17:56:58 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2448.0)
Content-Type: text/plain

Hi Ambarish,

> ----------
> From: 	Ambarish Malpani[SMTP:[e-mail]]
> Sent: 	Wednesday, August 25, 1999 5:23 PM
> To: 	'Don Schmidt (Exchange)'; [e-mail]
> Subject: 	RE: SCVP-01
> 
> Hi Don,
>     Thanks for the feedback. I find your reaction to SCVP
> perfectly reasonable. It will serve an important function for
> a particular set of users and your group might not be one of
> them.
 
Observation #1:

Don's "group" seems to represent a reasonable fraction of the world's
population...  :-)

While I believe they exist, my impression is that we're still waiting to
hear from this "particular set of users" to confirm that the functionality
embodied in SCVP is a legitimate requirement.  Don's "group" has stated that
they don't need this (at least at the moment).  Do we have concrete details
regarding who does need this?

> Let me again specify the main benefits of this protocol, as I
> see it:
> 
> - Allows applications that want to use public key cryptography
> to leverage the Public Key Infrastructure (PKI) without needing
> to understand its full complexity - SCVP lets you use certs
> and does the work of chain building, policy management and
> cert validation for you. This is both an issue of footprint
> size/processing power *and* the engineering work that needs to
> be done to understand PKIX.
> 
> - It allows for consistent/centrally managed cert policies,
> rather than requiring the policies be implemented (correctly),
> on every client desktop, across various different applications.
> 
> In some sense, you can think of the SCVP server as a remote
> COM object, that is providing certain services for you - you
> can choose to either use the service, or do all the work
> yourself.
 
Observation #2:

It strikes me that the above two paragraphs are somewhat antagonistic.  If
I, as a client device, "can choose to either use the service or do all the
work myself", then there is no possibility of consistent / centrally-managed
cert policies.  On the other hand, if devices do not have this choice (i.e.,
if devices MUST off-load the validation work to the central server), then
this itself is a cert processing policy that must be implemented (correctly)
on every client desktop.  What problem, therefore, does SCVP solve?


[Note:  don't take my observations above as necessarily "for" or "against"
this functionality.  I would just like to make sure that we, as the PKIX
group, are clear on what this protocol is trying to achieve and who the
target audience is.]

Carlisle.



Received: from ext-mail.valicert.com (ns1.valicert.com [63.65.221.10]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id OAA16920 for <[e-mail]>; Wed, 25 Aug 1999 14:18:48 -0700 (PDT)
Received: from int-mail.valicert.com (corporate-gw.valicert.com [63.65.221.2]) by ext-mail.valicert.com (8.9.3/8.9.3) with ESMTP id OAA22807; Wed, 25 Aug 1999 14:20:28 -0700 (PDT)
Received: from rhone (rhone.valicert.com [192.168.3.128]) by int-mail.valicert.com (8.9.3/8.9.3) with SMTP id OAA27001; Wed, 25 Aug 1999 14:20:28 -0700 (PDT)
From: "Ambarish Malpani" <[e-mail]>
To: "'Don Schmidt (Exchange)'" <[e-mail]>, <[e-mail]>
Subject: RE: SCVP-01
Date: Wed, 25 Aug 1999 14:23:25 -0700
Message-ID: <008401beef40$11d798c0$[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
Importance: Normal
In-Reply-To: <[e-mail]>

Hi Don,
    Thanks for the feedback. I find your reaction to SCVP
perfectly reasonable. It will serve an important function for
a particular set of users and your group might not be one of
them.

Let me again specify the main benefits of this protocol, as I
see it:

- Allows applications that want to use public key cryptography
to leverage the Public Key Infrastructure (PKI) without needing
to understand its full complexity - SCVP lets you use certs
and does the work of chain building, policy management and
cert validation for you. This is both an issue of footprint
size/processing power *and* the engineering work that needs to
be done to understand PKIX.

- It allows for consistent/centrally managed cert policies,
rather than requiring the policies be implemented (correctly),
on every client desktop, across various different applications.

In some sense, you can think of the SCVP server as a remote
COM object, that is providing certain services for you - you
can choose to either use the service, or do all the work
yourself.

Don't know if this will make you look at it differently, hope
it does.

Regards,
Ambarish

---------------------------------------------------------------------
Ambarish Malpani
Architect                                                650.567.5457
ValiCert, Inc.                                  [e-mail]
1215 Terra Bella Ave.                         http://www.valicert.com
Mountain View, CA 94043-1833


> -----Original Message-----
> From: Don Schmidt (Exchange) [mailto:[e-mail]]
> Sent: Tuesday, August 24, 1999 1:00 PM
> To: 'Ambarish Malpani'; [e-mail]
> Subject: RE: SCVP-01
> 
> 
> Ambarish,
> 
> Since returning from Oslo, I have discussed SCVP with my 
> colleagues and have
> confirmed the position I presented during the PKIX session.  Microsoft
> currently has no plans to implement SCVP.  We are not aware 
> of any demand
> from our customers for such a protocol; whereas, we have 
> several PKI-based
> applications which must run when the client is offline as 
> well as online.
> But most important, we do not agree with the fundamental 
> justification for
> SCVP.  The primary rationale provided in Oslo was that server-based
> certificate validation is required by small devices which do NOT have
> adequate processing and memory capabilities to locally 
> validate certificate
> chains, but DO have readily available network connections to 
> offload this
> work to a server.  It has been our experience that the 
> opposite is true.
> Devices continually increase in processing power and memory 
> to whatever
> level is required, while connectivity continues to be a problem.
> Applications which require constant (or on demand) network 
> connectivity to a
> supporting server typically suffer performance problems and 
> frequently fail
> simply due to dropped packets or connections.
> 
> One might be tempted to negate the connectivity argument if 
> it is believed
> that SCVP is only intended for handheld communication devices 
> which must
> have connectivity to perform their primary function.  
> However, relying on a
> server will add another network hit for every call and 
> possibly introduce a
> performance bottleneck.  Furthermore, since these clients 
> will need to be
> able to perform rudimentary cracking of at least the end entity's
> certificate, it seems we might better spend our time defining 
> a profile that
> limited the chain depth for such devices.   
> 
> Finally SCVP introduces additional security problems that 
> must be addressed
> to make sure a rogue server cannot trick a client into 
> accepting an invalid
> certificate or chain.  Locating and authenticating such 
> servers could be a
> significant challenge for highly mobile users.  OCSP & DCS 
> already face
> these kinds of security issues.  Why solve the same problem 
> over and over in
> separate protocols?  If it can be demonstrated that there is 
> a customer
> demand for SCVP-type services, then it would seem prudent to 
> add them as an
> option to an existing server-centric protocol.
> 
> Don Schmidt
> Program Manager
> Microsoft Corp
> 
> 
> 
>  -----Original Message-----
> From: 	Ambarish Malpani [mailto:[e-mail]] 
> Sent:	Monday, August 23, 1999 11:58 AM
> To:	[e-mail]
> Subject:	SCVP-01
> 
> 
> Hi Guys,
>     I noticed that there hasn't been too much discussion of SCVP
> after the 01 draft came out. Paul and I have got a few comments
> offline, but there hasn't been much on the list. A few people
> expressed interest in getting implementations and I was
> wondering if we have already gone through the major changes
> stage and are winding down the changes that will be made to
> the spec.
> 
> Comments?
> 
> Regards,
> Ambarish
> 
> ---------------------------------------------------------------------
> Ambarish Malpani
> Architect                                                650.567.5457
> ValiCert, Inc.                                  [e-mail]
> 1215 Terra Bella Ave.                         http://www.valicert.com
> Mountain View, CA 94043-1833
> 


Received: from tomcat.sac.verio.net ([e-mail] [209.162.64.15]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id NAA15037 for <[e-mail]>; Wed, 25 Aug 1999 13:08:04 -0700 (PDT)
Received: from nma.com (pm02-19.sac.verio.net [209.162.64.38]) by tomcat.sac.verio.net (8.9.1a/8.9.1) with ESMTP id NAA15132 for <[e-mail]>; Wed, 25 Aug 1999 13:09:38 -0700 (PDT)
Message-ID: <[e-mail]>
Date: Wed, 25 Aug 1999 13:09:37 -0700
From: Ed Gerck <[e-mail]>
X-Mailer: Mozilla 4.61 [en]C-CCK-MCD {Sony}  (Win98; I)
X-Accept-Language: en
MIME-Version: 1.0
To: "[e-mail]" <[e-mail]>
Subject: Options, was Re: To Be, or NR To Be ...
References: <32648884.935605032017.JavaMail.brazil@brazil>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Dave Kemp wrote:

> What label should be attached to a key which is known to be relatively
> less suitable for supporting a NR process (perhaps because the binding
> between a single individual and a specific private key is weak or
> nonexistent) - "Key, NR=0", or simply "Key" ?

What do you mean when NR is "on"? What do you mean when NR is "off"?
These are the first two questions that need to be answered before setting
that bit "on" or "off".  And yet, these questions have at least 4 answers for
the first and 3 answers for the second -- as we have seen here.  Then, still,
one needs to specifi "who" sets or clears the NR bit -- the CA, the subscriber,
both, a fourth-party (eg, a validating service), etc.

Actually, in this case and using if I may Tony's analogy with a labeled bottle
of methanol that says "alcohol", we would have the label in one place and
the bottle in another ;-)

> The "necessary and sufficient" line of reasoning is as bogus with
> respect to the NR bit as it is with respect to any other bit.

Holy Aristoteles! I disagree, and let's just move ahead a bit (pun intended) and
see what other bits need to be changed ;-)

First, of course, a necessary and sufficient condition for a certificate to be
verifiable is for it to be digitally signed.  So, I guess this much is OK and
equivalent: "certificate is signed" <--> "certificate is verifiable".  A certificate
is verifiable if and only if it is signed -- the "if" is a sufficient condition and
the "only if" a necessary condition.

Next, we study the eight key usage bits defined in RFC 2459 and which define
the purpose (e.g., encipherment, signature, certificate signing) of the key
contained in the certificate, which may be:

           digitalSignature        (0),
           nonRepudiation          (1),
           keyEncipherment         (2),
           dataEncipherment        (3),
           keyAgreement            (4),
           keyCertSign             (5),
           cRLSign                 (6),
           encipherOnly            (7),
           decipherOnly            (8)


Now, we begin to read:

     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)

which means that the first two bits are not independent. So, you are right,
if the meaning of bit 0 is going to depend on bit 1 and the state where both
are set is undefined, why have them as two independent bits?    Indeed, who
cares what is bitwise necessary and sufficient in the good old laws of logic
representation, if those bits are not representing logical states?

But, after all, if 2459 predicates independent bits  with independent names
then a reader should assume they should be independent and represent
independent states, no?  Or, should one just have octet-codes -- where
many octet-codes  would be "not defined" and thus open to be defined
in the CPS?

It seems thus that there are more faults in this bit logic than the NR bit fuzzy
definition and non-descriptive name.  So, if your call is to use octet logic instead
of bit logic, then I think that 2459 should say so and clearly spell out the octet-codes
that are valid and for what purpose.  Then, those octect-codes should be necessary
and sufficient conditions for each purpose -- to say otherwise is to deny logical
equivalence to the purpose.

As another option, bit logic should be followed as implied in 2459 and the
bit-values should likewise be necessary and sufficient conditions for each purpose.

Cheers,

Ed Gerck



Received: from solo.cygnacom.com (endor.cygnacom.com [205.177.169.102]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id NAA14812 for <[e-mail]>; Wed, 25 Aug 1999 13:01:05 -0700 (PDT)
Received: by SOLO with Internet Mail Service (5.0.1458.49) id <Q24N5AH6>; Wed, 25 Aug 1999 16:08:38 -0400
Message-ID: <F19999D192F6D211AA1700207810B43403A5FF@SOLO>
From: Elliot Ginsburg <[e-mail]>
To: "David P. Kemp" <[e-mail]>, [e-mail]
Subject: RE: Options, was Re: To Be, or NR To Be ...
Date: Wed, 25 Aug 1999 16:08:36 -0400
X-Priority: 3
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.0.1458.49)
Content-Type: text/plain

I think everyone agrees that the keyUsage extension provides more
information than would be present without it. The discussion on this
list seems to be, exactly what information does it provide? Anyone have
a clear proposal to make for what it means, other than 'go read the
CPS', because this adds nothing.

It seems easy to decide that NR==0 means 'don't use it for NR' (if
critical, you're forbidden to; if non-critical, you're advised not to).
But what exactly does NR==1 convey? From reading this list, I might
conclude it means 'you might want to use it for NR, depending on the
policy, your requirements, and the availability of NR services to you'.
While this doesn't do much, at least NR==0  is still very useful.

Elliott N Ginsburg
CygnaCom Solutions
[e-mail]
703-848-0883
703-848-0960(FAX)

> -----Original Message-----
> From:	David P. Kemp [SMTP:[e-mail]]
> Sent:	Wednesday, August 25, 1999 2:48 PM
> To:	[e-mail]
> Subject:	Re: Options, was Re: To Be, or NR To Be ...
> 
> 
> > From: Tony Bartoletti <[e-mail]>
> > 
> > In some ways, the NR-bit is like marketing bottles of wood alcohol
> that
> > are simply labeled "alcohol".  The designation is "not necessary" to
> those
> > that have performed investigation and use the liquid for cleaning
> purposes.
> > The designation is "not sufficient" for those who assume that the
> liquid
> > is grain alcohol and can be taken internally.
> 
> 
> Your position is that more information on the label is better?
> 
> What label should be attached to a key which is known to be relatively
> less suitable for supporting a NR process (perhaps because the binding
> between a single individual and a specific private key is weak or
> nonexistent) - "Key, NR=0", or simply "Key" ?
> 
> The "necessary and sufficient" line of reasoning is as bogus with
> respect to the NR bit as it is with respect to any other bit.  A
> necessary and sufficient statement says that the set of keys (or more
> generally, the set of technologies) which can support and will provide
> an XX operation is identical to the set of keys which have the XX bit
> asserted in a certificate.  No matter what you value you substitute
> for
> XX (digitalSignature, nonRepudiation, keyEncipherment, ...
> decipherOnly), the "necessary and sufficient" condition is patently
> false.  We have the keyUsage extension because a cert with it provides
> more information than a cert without it, not because the extension is
> either necessary or sufficient to achieve any particular security
> goal.


Received: from gatekeeper.entrust.com (gatekeeper.entrust.com [204.101.128.170]) by mail.proper.com (8.9.3/8.9.3) with SMTP id MAA14002 for <[e-mail]>; Wed, 25 Aug 1999 12:24:43 -0700 (PDT)
Received: 	id PAA11436; Wed, 25 Aug 1999 15:22:06 -0400
Received: by gateway id <NP65MGRS>; Wed, 25 Aug 1999 15:24:45 -0400
Message-ID: <[e-mail]>
From: Carlisle Adams <[e-mail]>
To: "'[e-mail]'" <[e-mail]>
Cc: "'[e-mail]'" <[e-mail]>, "'[e-mail]'" <[e-mail]>, "'[e-mail]'" <[e-mail]>
Subject: RE: Cast5-MAC Algorithm
Date: Wed, 25 Aug 1999 15:24:44 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2448.0)
Content-Type: text/plain

Hi Timothy,

> -----Original Message-----
> From: Timothy Fisher [mailto:[e-mail]] 
> Sent: Wednesday, August 18, 1999 10:39 PM
> To: [e-mail]
> Cc: [e-mail]; [e-mail]
> Subject: Cast5-MAC Algorithm
> 
> Can anyone point me to a reference where I might be able to find
> implementation
> details for implementing the CAST5-MAC algorithm?
> I have looked at RFC2144 which is the RFC for CAST, but it does not
> contain details
> for implementing the MAC version of CAST.   That is what I am interested
> in.
> 
> If you can be of help, or point me to an appropriate
> reference/specification I would
> be greatful.
 
Doing a CAST5-MAC is identical to doing a MAC based upon any other symmetric
cipher.  Therefore, if you know how to do a DES-CBC-MAC, for example, then
simply do a CAST5-MAC the same way.  The "Handbook of Applied Cryptography"
book by Menezes, van Oorschot, and Vanstone gives a number of standards that
specify how to do symmetric-cipher-based MACs; common ones are ISO/IEC 9797
and ANSI X9.19.

Carlisle.



Received: from stingray.missi.ncsc.mil (stingray.missi.ncsc.mil [144.51.50.20]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id LAA12985 for <[e-mail]>; Wed, 25 Aug 1999 11:47:53 -0700 (PDT)
Received: from stingray.missi.ncsc.mil (root@localhost) by stingray.missi.ncsc.mil with ESMTP id OAA18432 for <[e-mail]>; Wed, 25 Aug 1999 14:49:31 -0400 (EDT)
Received: from missi.ncsc.mil (depot.missi.ncsc.mil [144.51.60.1]) by stingray.missi.ncsc.mil with ESMTP id OAA18428 for <[e-mail]>; Wed, 25 Aug 1999 14:49:30 -0400 (EDT)
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 OAA19628 for <[e-mail]>; Wed, 25 Aug 1999 14:49:18 -0400 (EDT)
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 OAA27580 for <[e-mail]>; Wed, 25 Aug 1999 14:47:50 -0400 (EDT)
Message-Id: <[e-mail]>
Date: Wed, 25 Aug 1999 14:47:50 -0400 (EDT)
From: "David P. Kemp" <[e-mail]>
Reply-To: "David P. Kemp" <[e-mail]>
Subject: Re: Options, was Re: To Be, or NR To Be ...
To: [e-mail]
MIME-Version: 1.0
Content-Type: TEXT/plain; charset=us-ascii
Content-MD5: HplfYrCoCik/FlfypI/2gA==
X-Mailer: dtmail 1.3.0 CDE Version 1.3 SunOS 5.7 sun4u sparc

> From: Tony Bartoletti <[e-mail]>
> 
> In some ways, the NR-bit is like marketing bottles of wood alcohol that
> are simply labeled "alcohol".  The designation is "not necessary" to those
> that have performed investigation and use the liquid for cleaning purposes.
> The designation is "not sufficient" for those who assume that the liquid
> is grain alcohol and can be taken internally.


Your position is that more information on the label is better?

What label should be attached to a key which is known to be relatively
less suitable for supporting a NR process (perhaps because the binding
between a single individual and a specific private key is weak or
nonexistent) - "Key, NR=0", or simply "Key" ?

The "necessary and sufficient" line of reasoning is as bogus with
respect to the NR bit as it is with respect to any other bit.  A
necessary and sufficient statement says that the set of keys (or more
generally, the set of technologies) which can support and will provide
an XX operation is identical to the set of keys which have the XX bit
asserted in a certificate.  No matter what you value you substitute for
XX (digitalSignature, nonRepudiation, keyEncipherment, ...
decipherOnly), the "necessary and sufficient" condition is patently
false.  We have the keyUsage extension because a cert with it provides
more information than a cert without it, not because the extension is
either necessary or sufficient to achieve any particular security
goal.



Received: from poptop.llnl.gov (poptop.llnl.gov [128.115.18.65]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id KAA11194 for <[e-mail]>; Wed, 25 Aug 1999 10:37:20 -0700 (PDT)
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 KAA17042; Wed, 25 Aug 1999 10:37:33 -0700 (PDT)
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.3 (32)
Date: Wed, 25 Aug 1999 10:37:39 -0700
To: Stephen Kent <[e-mail]>, Ed Gerck <[e-mail]>
From: Tony Bartoletti <[e-mail]>
Subject: Re: Options, was Re: To Be, or NR To Be ...
Cc: [e-mail]
In-Reply-To: <v04020a10b3e9a7af2a7f@[128.89.0.110]>
References: <[e-mail]> <v04020a0cb3e363e29bff@[128.89.0.110]> <[e-mail]> <v04020a01b3e318d1f67a@[128.89.0.110]> <v04020a12b3e384dd5ce6@[128.89.0.110]> <v04020a03b3e85d51e91b@[128.89.0.110]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"

At 11:10 AM 8/25/99 -0400, Stephen Kent wrote:
>Ed,
>
>Although I agreed that use of the NR bit is neither necessary nor
>sufficient, in isolation, I have also given many examples of where the bit
>of of significant benefit in an overall NR scheme.  I'll avoid continuing
>the debate of whether the PKIX notion of NR is corect or not, relative to
>your notion.
>
>Steve

In some ways, the NR-bit is like marketing bottles of wood alcohol that
are simply labeled "alcohol".  The designation is "not necessary" to those
that have performed investigation and use the liquid for cleaning purposes.
The designation is "not sufficient" for those who assume that the liquid
is grain alcohol and can be taken internally.

___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 po1.bbn.com (PO1.BBN.COM [192.1.50.38]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id KAA10845 for <[e-mail]>; Wed, 25 Aug 1999 10:24:24 -0700 (PDT)
Received: from [128.89.0.110] (COSMEC.BBN.COM [128.89.0.110]) by po1.bbn.com (8.9.1/8.9.1) with ESMTP id NAA07383; Wed, 25 Aug 1999 13:25:29 -0400 (EDT)
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
X-Sender: [e-mail]
Message-Id: <v04020a1db3e9cfef9ff7@[128.89.0.110]>
In-Reply-To: <[e-mail]>
References: <v04020a0cb3e363e29bff@[128.89.0.110]> 	    <[e-mail]> 	    <v04020a01b3e318d1f67a@[128.89.0.110]> 	    <v04020a12b3e384dd5ce6@[128.89.0.110]> 	    <v04020a03b3e85d51e91b@[128.89.0.110]> <v04020a10b3e9a7af2a7f@[128.89.0.110]>
Date: Wed, 25 Aug 1999 13:20:50 -0400
To: Ed Gerck <[e-mail]>
From: Stephen Kent <[e-mail]>
Subject: Re: Options, was Re: To Be, or NR To Be ...
Cc: [e-mail]

Ed,
>
>A short remark. In classical systems (e.g., as existing in single
>networks), security
>is localized and your approach might work with some success.  In internets, we
>deal with networks of networks -- where there is no common reporting point
>and no deterministic communication path, and where no one controls both
>ends of a communication channel.  That is why reliance on math (even
>asymmetric crypto) falls short for internet security -- so that protocols
>need to
>provide the "glue" for math to work.  This glue is simply missing if you don't
>address at least some of the other *relevant* security assurance issues --
>such
>as what MUST the system really do or MUST NOT really do when that NR bit
>is on/off, and what do these actions mean in a language that does not have
>to say
>that the bit name is not what the bit enables.

A response to your short remark: I've designed and developed Internet
security systems for over 20 years, before most people knew what the
Internet was.  I served on the IAB for over a decade, approving Internet
standards.  Don't presume to lecture me on what the Internet is or how to
secure communication in this environment.

As for the question of what the system MUST or MUST NOT do relative to the
NR bit, that is a local matter, in standards parlance.  What 2459 specifies
is the circumstances under which the bit should be asserted, but it imposes
no requirements on what the software operating on behalf of an RP MUST or
MUST NOT do.  That will be determined by locally-determined policies, maybe
with realtime human inputs, depending on the context. The extent to which
this can be automated will be a funciton not only of the features that we
establish in technical standards, but also the way in which CAs, users, and
RPs choose to take advantage of those features, including local laws and
personal risk tolerance.  We can't standardize much of this, certainly not
in the PKIX and IETF contexts.

<snip>

>> Although I agreed that use of the NR bit is neither necessary nor
>> sufficient, in isolation, I have also given many examples of where the bit
>> of of significant benefit in an overall NR scheme.
>
>I do not recall any use of the "NR bit" in isolation and I don't think it
>would be usable either.  The statement that the NR bit is neither
>necessary nor
>sufficient to provide NR services had no indeed no opposition in this WG --
>and this statement simply proves that NR services are independent of such
>NR bit, q.e.d.

Yes, one could offer NR irrespective of the use of the NR bit. One could
also do so independent of the use of certs and public key crypto.  So, ...

>In regard to your examples where the current description (and name) of the NR
>bit is of  "significant benefit" in an overall NR scheme, I recall that
>you have not
>replied when those examples were rebutted and parallel schemes could be shown
>where the NR bit was significantly ambiguous and even obscure in its usage.

Ed, at this point, I don't pay much attention to the lengthy messages you
are sending to the list.  Your arguments often employ terminology in a
fashion that is inconsistent with the generally accepted use in the PKI
arena, and in our standards in particular.  The arguments sometimes are
hard to follow (to understand their relevance to the technical focus of
this WG), often discuss legal issues that are outside the scope of this WG,
etc.  It's just not worth the time and effort.  Private communication with
several other folks who are normally substantative contributors to the list
confirms that they have adopted a similar response to your contributions,
i.e., they decline to devote any more time to responding to your postings.
So, don't interpret the lack of rebuttal to your extensive submissions as
acquiescence.

Steve


Received: from balinese.baltimore.ie ([e-mail] [194.125.215.8]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id JAA10103 for <[e-mail]>; Wed, 25 Aug 1999 09:43:08 -0700 (PDT)
Received: by balinese.baltimore.ie; id RAA24203; Wed, 25 Aug 1999 17:44:45 +0100 (GMT/IST)
Received: from bobcat.baltimore.ie(192.168.20.10) by balinese.baltimore.ie via smap (V4.2) id xma023582; Wed, 25 Aug 99 17:44:01 +0100
Received: from sage.baltimore.ie (IDENT:[e-mail] [192.168.21.125]) by bobcat.baltimore.ie (8.9.3/8.9.3) with ESMTP id RAA28132 for <[e-mail]>; Wed, 25 Aug 1999 17:44:01 +0100
Received: from sage.baltimore.ie (IDENT:keith@localhost [127.0.0.1]) by sage.baltimore.ie (8.9.3/8.9.3) with ESMTP id RAA29146 for <[e-mail]>; Wed, 25 Aug 1999 17:44:00 +0100
Message-Id: <[e-mail]>
To: [e-mail]
Subject: Re: multinational directories 
Date: Wed, 25 Aug 1999 17:44:00 +0100
From: Keith Brady <[e-mail]>

 "Stephen" == Stephen Kent <[e-mail]> writes:

Stephen> I find the locality attributes to be rather oddd in your
Stephen> examples. I didn't recall that X.521 endorsed the designation of
Stephen> a country as a "locale."

This is true but people typically ignore it. One of the specific client
cases used locale for the component countries of the UK (which, of course,
don't have 3166 country codes.) There was a lot of debate about whether to
use state-or-province name as the naming rule.

Given that the ITU's domain is itu.int, I would like to see how they
structure their DIT (or even X.400 addressing).

cheers,

Keith

[BTW: [e-mail] doesn't seem to work, service unavailable for some reason]




Received: from mail.vpnc.org (mail.vpnc.org [165.227.249.9]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id JAA09918 for <[e-mail]>; Wed, 25 Aug 1999 09:41:06 -0700 (PDT)
Received: from aum (ip11.proper.com [165.227.249.11]) by mail.vpnc.org (8.9.3/8.9.0) with ESMTP id JAA23289 for <[e-mail]>; Wed, 25 Aug 1999 09:41:16 -0700 (PDT)
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58 
Date: Wed, 25 Aug 1999 09:38:47 -0700
To: [e-mail]
From: Paul Hoffman / VPNC <[e-mail]>
Subject: RE: SCVP-01
In-Reply-To: <[e-mail] p.microsoft.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed

At 01:00 PM 8/24/1999 -0700, Don Schmidt (Exchange) wrote:
>But most important, we do not agree with the fundamental justification for
>SCVP.  The primary rationale provided in Oslo was that server-based
>certificate validation is required by small devices which do NOT have
>adequate processing and memory capabilities to locally validate certificate
>chains, but DO have readily available network connections to offload this
>work to a server.

As the -01 draft says very plainly, there are two broad uses for SCVP; you 
have named just one. The other, helping clients do their own validation, 
was heavily discussed in Oslo and made much more prominent throughout the 
-01 draft.

You may be right that no small Internet appliance will ever need a host to 
do its validation (although I question how any of us can predict the future 
desires and needs of Internet devices very well, given our abysmal past 
predictions). You will certainly be right if there is no standard way for 
these products to get the services they would need if they existed.

However, I'm quite skeptical of anyone who feels that a PKI user can always 
easily get all the needed chaining certificates and revocation information 
for path validation for all the partners whom they would want to 
authenticate. This will only work in a closed environment, probably with 
one root and path lengths of no more than 2 CAs, and clients that can use 
multiple retrieval protocols. Restricting PKI customers to this model 
doesn't serve their legitimate needs at all.

--Paul Hoffman, Director
--VPN Consortium


Received: from tomcat.sac.verio.net ([e-mail] [209.162.64.15]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id JAA09698 for <[e-mail]>; Wed, 25 Aug 1999 09:33:14 -0700 (PDT)
Received: from nma.com (pm08-19.sac.verio.net [209.162.65.85]) by tomcat.sac.verio.net (8.9.1a/8.9.1) with ESMTP id JAA19002; Wed, 25 Aug 1999 09:34:42 -0700 (PDT)
Message-ID: <[e-mail]>
Date: Wed, 25 Aug 1999 09:34:41 -0700
From: Ed Gerck <[e-mail]>
X-Mailer: Mozilla 4.61 [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: Options, was Re: To Be, or NR To Be ...
References: <v04020a0cb3e363e29bff@[128.89.0.110]>  <[e-mail]>  <v04020a01b3e318d1f67a@[128.89.0.110]>  <v04020a12b3e384dd5ce6@[128.89.0.110]>  <v04020a03b3e85d51e91b@[128.89.0.110]> <v04020a10b3e9a7af2a7f@[128.89.0.110]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Stephen Kent wrote:

> Ed Gerck wrote:
> >
> >The question is thus not whether math is the foundation for public-key
> >algorithms.  But, for example, who has the private-key or who/what do
> >you trust.  By promoting reliance on math, one promotes reliance on no
> >differential between user and attacker.  What you say is the same as those
> >that simply want  "more bits" in their keys but have their systems wide
> >open to ActiveX controls -- they also think that math does provide a
> >basis for security.
>
> I agree that the math foundation is but part of the system, and it is
> usually not the part that In would attack.  However, from a technical
> security perspective, we focus on standards that don't address all of the
> other security assurance issues.

Steve:

A short remark. In classical systems (e.g., as existing in single networks), security
is localized and your approach might work with some success.  In internets, we
deal with networks of networks -- where there is no common reporting point
and no deterministic communication path, and where no one controls both
ends of a communication channel.  That is why reliance on math (even
asymmetric crypto) falls short for internet security -- so that protocols need to
provide the "glue" for math to work.  This glue is simply missing if you don't
address at least some of the other *relevant* security assurance issues -- such
as what MUST the system really do or MUST NOT really do when that NR bit
is on/off, and what do these actions mean in a language that does not have to say
that the bit name is not what the bit enables.

> >But, it does not -- math is simply a tool to security.
>
> Agreed, modulo the choice of preposition.

Math is simply a tool to [achieve] security.  This simply stresses the notion
that use of math alone does not provide for security but may help to achieve
it. So, calling it "mathematical" does not equate to "secure", even if the
crypto is asymmetric.  Who is at the other side? Is that key really from the
sender? Is the key still valid? Questions soon appear and it becomes clear that
public-key cryptography has indeed solved the problem of public-key security
but not the problems of public-key acquisition, recognition, revocation,
distribution, re-distribution, validation and, most importantly, key-binding to
an identifier and/or key-attribution to a real-world entity. Communications can
yet not be verified, neither for origin authentication nor for data-integrity --
communications can be private but not yet secure. Of course, a private
communication with a thief is not secure just because it is private.
[http://www.mcg.org.br/whycert.htm]

> Although I agreed that use of the NR bit is neither necessary nor
> sufficient, in isolation, I have also given many examples of where the bit
> of of significant benefit in an overall NR scheme.

I do not recall any use of the "NR bit" in isolation and I don't think it
would be usable either.  The statement that the NR bit is neither necessary nor
sufficient to provide NR services had no indeed no opposition in this WG --
and this statement simply proves that NR services are independent of such
NR bit, q.e.d.

In regard to your examples where the current description (and name) of the NR
bit is of  "significant benefit" in an overall NR scheme, I recall that you have not
replied when those examples were rebutted and parallel schemes could be shown
where the NR bit was significantly ambiguous and even obscure in its usage.

> I'll avoid continuing the debate of whether the PKIX notion of NR is corect or not,
> relative to your notion.

I would not say this is "my" notion or "your" notion, Steve.  This seems not to be
a case for stressing sensus, but for stressing consensus.

Cheers,

Ed Gerck



Received: from balinese.baltimore.ie ([e-mail] [194.125.215.8]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id IAA08824 for <[e-mail]>; Wed, 25 Aug 1999 08:20:09 -0700 (PDT)
Received: by balinese.baltimore.ie; id QAA16076; Wed, 25 Aug 1999 16:21:42 +0100 (GMT/IST)
Received: from bobcat.baltimore.ie(192.168.20.10) by balinese.baltimore.ie via smap (V4.2) id xma016020; Wed, 25 Aug 99 16:21:07 +0100
Received: from sage.baltimore.ie (IDENT:[e-mail] [192.168.21.125]) by bobcat.baltimore.ie (8.9.3/8.9.3) with ESMTP id QAA23725 for <[e-mail]>; Wed, 25 Aug 1999 16:21:07 +0100
Received: from sage.baltimore.ie (IDENT:keith@localhost [127.0.0.1]) by sage.baltimore.ie (8.9.3/8.9.3) with ESMTP id QAA28941 for <[e-mail]>; Wed, 25 Aug 1999 16:21:06 +0100
Message-Id: <[e-mail]>
To: [e-mail]
Subject: Re: multinational directories 
Date: Wed, 25 Aug 1999 16:21:05 +0100
From: Keith Brady <[e-mail]>

 "John" == John Saylor <[e-mail]> writes:

John> I have run up against similar issues with clients and my experience
John> has been that the directory should mimic the organization. Generally
John> DITs are given starting with the country, but this does not have to
John> be so. In the case you give, I would organize the tree like this:

John> o=GlobalCorp ou=Marketing c=US

John> o=GlobalCorp ou=Marketing c=UK



Or you may wish to use something like:

o=GlobalCorp,ou=Marketing,l=US
o=GlobalCorp,ou=Marketing,l=GB

which follows the (non-normative) suggestions for structure rules in X.521
Annex-B and has been included in a lot of directories I have come across.
Indeed the above layout is derived from a specific client's requirements.

You should watch the GB vs UK thing too.

cheers,

Keith
--
Keith Brady,                                    Phone: [phone] 
Baltimore Technologies,                           Fax: [phone]
61-62 Fitzwilliam Lane,                      <http://www.baltimore.com>
Dublin 2, Ireland

--
Company Standard Disclaimer
--------------------------------------------------------------------------
The information contained in this message is confidential and is intended
for the addressee(s) only. If you have received this message in error or
there are any problems please notify the originator immediately. The
unauthorised use, disclosure, copying or alteration of this message is
strictly forbidden. This message and any attachments have been scanned for
viruses. Baltimore Technologies plc will not be liable for direct,
special, indirect or consequential damages arising from alteration of the
contents of this message by a third party or as a result of any virus
being passed on.
--------------------------------------------------------------------------


Received: from po1.bbn.com (PO1.BBN.COM [192.1.50.38]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id IAA08723 for <[e-mail]>; Wed, 25 Aug 1999 08:16:43 -0700 (PDT)
Received: from [128.89.0.110] (COSMEC.BBN.COM [128.89.0.110]) by po1.bbn.com (8.9.1/8.9.1) with ESMTP id LAA19080; Wed, 25 Aug 1999 11:17:33 -0400 (EDT)
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
X-Sender: [e-mail]
Message-Id: <v04020a10b3e9a7af2a7f@[128.89.0.110]>
In-Reply-To: <[e-mail]>
References: <v04020a0cb3e363e29bff@[128.89.0.110]> 	    <[e-mail]> 	    <v04020a01b3e318d1f67a@[128.89.0.110]> 	    <v04020a12b3e384dd5ce6@[128.89.0.110]> <v04020a03b3e85d51e91b@[128.89.0.110]>
Date: Wed, 25 Aug 1999 11:10:13 -0400
To: Ed Gerck <[e-mail]>
From: Stephen Kent <[e-mail]>
Subject: Re: Options, was Re: To Be, or NR To Be ...
Cc: [e-mail]

Ed,

>
>Math is not self-secure -- anything you can do in math the attacker can also.

But the math underlying cryptography, and public key cryptography in
particular, introduces an asymmetry into what the users must do vs. what an
attacker must do.  So, your statement above is true, but not relevant to
the question of the security of digital signatures, the foundation of PKI
crypto-security.

>The question is thus not whether math is the foundation for public-key
>algorithms.  But,
>for example, who has the private-key or who/what do you trust.  By promoting
>reliance on math, one promotes reliance on no differential between user and
>attacker.  What you say is the same as those that simply want  "more bits" in
>their keys but have their systems wide open to ActiveX controls -- they also
>think that math does provide a basis for security.

I agree that the math foundation is but part of the system, and it is
usually not the part that In would attack.  However, from a technical
security perspective, we focus on standards that don't address all of the
other security assurance issues.  We have promulgated such standards in the
past (e.g., the TCSEC, ITSEC, and now the Common Criteria) and even the
IETF has published informational documents such as the site security
handbook.  However, the focus of this WG is protocols (not that part 4 of
PKIX is informational, not standards track).

>But, it does not -- math is simply a tool to security.

Agreed, modulo the choice of preposition.

>> I'm sorry that you dislike the term "non repudiation" but we are NOT
>>changing
>> this "term of art" in this standards context.
>
>I do not dislike the term "non-repudiation" at all.  In fact, I think that
>the concept
>of non-repudiation can be very useful and even essential.  But when
>correctly used,
>not as a misnomer to indicate a "NR bit" that has a PKIX description which
>everyone
>(including you) agrees is neither necessary nor sufficient to indicate
>non-repudiation.  And in math, when A is neither necessary nor sufficient to B
>then this means that B exists independently of A.  In other words,
>non-repudiation
>does not depend on the state of  the NR-bit as it is described in
>2459/PKIX -- and
>this is both a mathematical and a technical affirmation one should not ignore.
>
>And, as I commented before, if the broken semantics of the NR bit  is not
>corrected
>(and there are three options to do this -- either delete it, or define it
>truly as
>non-repudiation, or rename and redefine it), then the market will be free to
>understand the NR bit in many different and conflicting ways -- if this
>list exchange
>in the past month can provide but a sample of them.  Which will be very much
>equivalent to deleting it from the spec because "hands off that NR bit"
>will be
>safer, also to the CAs.

Although I agreed that use of the NR bit is neither necessary nor
sufficient, in isolation, I have also given many examples of where the bit
of of significant benefit in an overall NR scheme.  I'll avoid continuing
the debate of whether the PKIX notion of NR is corect or not, relative to
your notion.

Steve


Received: from po1.bbn.com (PO1.BBN.COM [192.1.50.38]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id HAA06781 for <[e-mail]>; Wed, 25 Aug 1999 07:06:14 -0700 (PDT)
Received: from [128.89.0.110] (COSMEC.BBN.COM [128.89.0.110]) by po1.bbn.com (8.9.1/8.9.1) with ESMTP id KAA09708; Wed, 25 Aug 1999 10:07:41 -0400 (EDT)
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
X-Sender: [e-mail]
Message-Id: <v04020a0cb3e89bb92825@[128.89.0.110]>
In-Reply-To: <[e-mail]>
References: <v04020a02b3e85bf89830@[128.89.0.110]> <[e-mail]> <[e-mail]>
Date: Wed, 25 Aug 1999 10:01:07 -0400
To: Tony Bartoletti <[e-mail]>
From: Stephen Kent <[e-mail]>
Subject: Re: Subdividing the NR bit.
Cc: [e-mail]

Tony,

>Perhaps my emphasis upon automation is misplaced (caveat, I believe the
>future hold far more automation than we generally imagine.)
>
>As long as the RP will be expected to review the CPS prior to accepting
>a cert with a given subset of key-usage bits, then the NR-bit supports
>this use model, as you say.
>
>A burden, perhaps necessary, to place upon the RP.

Note that this is not a burden that has to be endured every time one
accepts signed data in an NR context.  There is a notion of evaluating the
CPS and associated policies once, and then being able to put in place rules
that embody the value judgement made by the individual who read the
material.

>(Aside - Does this model intentionally impede extended automation?)

The model I cite does not support completely automated RP processing, but
it is consistent with the level of due diligence currently exercised on a
bilateral basis in establishing business relationships.  I've spoken to a
number of attorneys working in the PKI arena, and many of them believe that
this is a reasonable goal for PKIs, and it would offer significant
benefits, even though it does not go all the way toward automating RP
processing.

>And there is no particular gain in adding additional key-usage bits
>(e.g., subdividing NR) if the bits do not distinguish an automatably
>distinct key-usage catagory.

Agreed.

>But does this provide sufficient guidance to the subscriber in wielding
>the keys in question?  Does software need know?  Am I promising intent?
>Am I declaring future denials apriori null and void?  Am I declaring
>only simple cognizance of the signing act?

These distinctions can be declared through policies and specified via OIDs,
at the discretion of the CA.

>I also suppose that the main motivation behind a revision of the NR
>(nomenclature or definition) comes from developers who must take their
>cues from the folks that give them requirements, those folks possessing
>varied/conflicting notions about the precise intent of the NR-bit setting.

Hopefully we have clarified this in our discussions, and maybe we can add
some text to 2459 to codify that clarification.

>The evidence of this list suggests at least some of these issues
>remain a concern.


Steve


Received: from us-phx1.az05.bull.com (us-phx1.az05.bull.com [141.112.40.1]) by mail.proper.com (8.9.3/8.9.3) with SMTP id GAA05740 for <[e-mail]>; Wed, 25 Aug 1999 06:26:39 -0700 (PDT)
From: [e-mail]
Received: by  us-phx1.az05.bull.com(Lotus SMTP MTA v4.6.4  (830.2 3-23-1999))  id 072567D8.0049F644 ; Wed, 25 Aug 1999 06:27:51 -0700
X-Lotus-FromDomain: BULL
To: Hans Nilsson <[e-mail]>
cc: [e-mail]
Message-ID: <072567D8.0049F5CB.00@ us-phx1.az05.bull.com>
Date: Wed, 25 Aug 1999 06:27:16 -0700
Subject: Re: CRL version number discrepancy
Mime-Version: 1.0
Content-type: text/plain; charset=us-ascii
Content-Disposition: inline

actually we have had this debate. the text is correct in 509 but it was
considered an unnecessary complication in the pkix profile. the 509 text was to
broaden the amount of interworking between different versions. i understood the
pkix position to be that with minimal deployment of earlier versions, the 509
text didn't buy anything (other that possible confusion)

i (and the x500 group) considered the text still useful but decided to make it
optional. the "shall" will be changed to a "may". this will allow a profile to
broaden interaction if necessary. whatever pkix decides to do, there will be no
conflict with the standard.

    hoyt




Hans Nilsson <[e-mail]> on 08/24/99 11:34:06 PM

To:   [e-mail]
cc:    (bcc: Hoyt Kesterson/US/BULL)
Subject:  CRL version number discrepancy




There is a discrepancy between X.509 and RFC 2459.

X.509 states:

If any extensions included in a CertificateList are defined as critical, the
version element of the CertificateList shall be present.  If no extensions
defined as critical are included, the version element shall be absent. This
may permit a implementation that only supports version 1 CRLs to still use
the CRL if in its examination of the revokedCertificates sequence in the
CRL, it does not encounter an extension. An implementation that supports
version 2 (or greater) CRLs may be able to optimize its processing if it can
determine early in processing that no critical extensions are present in the
CRL.

RFC 2459 states that:

Conforming CAs that issue CRLs MUST issue version 2 CRLs,

and, later,

When extensions are used, as required by this profile, this field MUST be
present and MUST specify version 2 (the integer value is 1.

The question is now:
When we issue CRLS with non-crictical extensions, should the version number
be omitted (according to X.509) or present and set to 2 (according to RFC
2459?

Until further notice, we regard X.509 as having precedence over RFC 2459. Is
this correct?

Regards
Hans Nilsson








Received: from Sonnet.GSC.GTE.Com ([e-mail] [204.152.26.66]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id FAA04041 for <[e-mail]>; Wed, 25 Aug 1999 05:28:40 -0700 (PDT)
Received: from saylorj ("port 1911"@SAYLORJ.ndhm.gsc.gte.com [155.95.230.14]) by Sonnet.GSC.GTE.Com (PMDF V5.2-30 #29038) with SMTP id <[e-mail]> for [e-mail]; Wed, 25 Aug 1999 08:30:02 -0400 (EDT)
Date: Wed, 25 Aug 1999 08:25:54 -0400
From: John Saylor <[e-mail]>
Subject: multinational directories
To: "Sweigert, David" <[e-mail]>, Alan Lloyd <[e-mail]>, [e-mail], [e-mail], [e-mail]
Message-id: <004201beeef5$8d1b5710$[e-mail]>
Organization: CyberTrust
MIME-version: 1.0
X-MIMEOLE: Produced By Microsoft MimeOLE V5.00.2314.1300
X-Mailer: Microsoft Outlook Express 5.00.2314.1300
Content-type: text/plain;	charset="iso-8859-1"
Content-transfer-encoding: 7bit
X-Priority: 3
X-MSMail-priority: Normal
References: <[e-mail]>

Hi

----- Original Message -----
From: Sweigert, David <[e-mail]>

> As anyone grappling with the problem of defining a directory
information
> tree for a multi-national company.  In other words, how do divisions
in
> the UK and US relate in the DIT if both divisions are within one
corporate
> organization; say MARKETING.

> Any thoughts on this ?

I have run up against similar issues with clients and my experience
has been that the directory should mimic the organization. Generally
DITs are given starting with the country, but this does not have to be
so. In the case you give, I would organize the tree like this:

o=GlobalCorp
ou=Marketing
c=US

o=GlobalCorp
ou=Marketing
c=UK

Because that matches the actual significance of the branches. If you
ever have any plans of joining the worlwide X.500 directory [as if
...], then this won't work. But if a directory is for use within a
company, then this will work just fine.

\js




Received: from edelweb.fr (edelweb.fr [193.51.12.16]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id CAA26529 for <[e-mail]>; Wed, 25 Aug 1999 02:56:59 -0700 (PDT)
Received: from champagne.edelweb.fr (localhost.edelweb.fr [127.0.0.1]) by edelweb.fr with ESMTP id LAA09913; Wed, 25 Aug 1999 11:58:31 +0200 (MET DST)
Received: from champagne.edelweb.fr (champagne.edelweb.fr [193.51.14.161]) by edelweb.fr (nospam/1.1); Wed, 25 Aug 1999 11:58:31 +0200 (MET DST)
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 LAA22313; Wed, 25 Aug 1999 11:58:30 +0200 (MET DST)
From: Peter Sylvester <[e-mail]>
Received: (sylvest@localhost) by emeriau.edelweb.fr (8.7.6/8.6.6) id LAA04136; Wed, 25 Aug 1999 11:58:30 +0200 (MET DST)
Date: Wed, 25 Aug 1999 11:58:30 +0200 (MET DST)
Message-Id: <[e-mail]>
To: [e-mail], [e-mail], [e-mail]
Subject: RE: SCVP-01

> 
> Ambarish,
> 
> Since returning from Oslo, I have discussed SCVP with my colleagues and have
> confirmed the position I presented during the PKIX session.  Microsoft
> currently has no plans to implement SCVP.  We are not aware of any demand
> from our customers for such a protocol; whereas, we have several PKI-based
> applications which must run when the client is offline as well as online.
The question is what can such an application really do in an offline way? 
You can validate a signature etc and then launch some action, create another
document in a work flow, but if you don't leave the virtual reality world, 
the effects of that application become only visible when you get online later.

> But most important, we do not agree with the fundamental justification for
> SCVP.  The primary rationale provided in Oslo was that server-based
> certificate validation is required by small devices which do NOT have
> adequate processing and memory capabilities to locally validate certificate
> chains, but DO have readily available network connections to offload this
> work to a server.  It has been our experience that the opposite is true.
> Devices continually increase in processing power and memory to whatever
> level is required, while connectivity continues to be a problem.
> Applications which require constant (or on demand) network connectivity to a
> supporting server typically suffer performance problems and frequently fail
> simply due to dropped packets or connections.
Processing power is indeed not really the problem 
(comparing a few octets doesn't require a supercomputer).

The interesting point though is configuration management of many clients, 
downloading and maintaining company policies and so on. For example, 
it easy to run a 'dumb' client WITHOUT any local configuration. 
The user has a smart card containing his own information (a signing key/cert)
and a certificate of his trustworthy server with the URL of the server. 

> 
> One might be tempted to negate the connectivity argument if it is believed
> that SCVP is only intended for handheld communication devices which must
> have connectivity to perform their primary function.  However, relying on a
> server will add another network hit for every call and possibly introduce a
> performance bottleneck.  Furthermore, since these clients will need to be
> able to perform rudimentary cracking of at least the end entity's
> certificate, it seems we might better spend our time defining a profile that
> limited the chain depth for such devices.  

One should distinguish between a communication protocol, and what a client
is supposed to do. Having a protocol doesn't mean that a client can implement
whatever appropriate strategy to use or to avoid the usage of that protocol.

If an adminstration requires youn to be present to show a document, 
performance bottlenecks don't count. The adminstration will not come
to your home just because you tell them that you are not able to
come to them. :-) 

If an important application requires online status checking of a cert
(why does OCSP exist??) then you need to be online....  
 
> 
> Finally SCVP introduces additional security problems that must be addressed
> to make sure a rogue server cannot trick a client into accepting an invalid
> certificate or chain.  Locating and authenticating such servers could be a
> significant challenge for highly mobile users.  OCSP & DCS already face
> these kinds of security issues.  Why solve the same problem over and over in
> separate protocols?  If it can be demonstrated that there is a customer
> demand for SCVP-type services, then it would seem prudent to add them as an
> option to an existing server-centric protocol.

I like one element of SCVP, the way to define data objects and high level 
abstract services without directly specifying them in whatever wire format. 

I would like to know what is missing in DCS to support SCV.
DCS works well in an environment of creating and validation CMS documents.
(If no storage of the tokens are needed the request/response do not even need
to be encapsulated in CMS but can just be transfered using something like
SSL/TLS or whetever lower layer protocol that allows mutual authentication.)
(All this is already mentioned in the DCS text, at least in the version that
 I have in my mind).
  
Have fun
Peter Sylvester 





Received: from s2.smtp.oleane.net (s2.smtp.oleane.net [195.25.12.6]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id BAA22758 for <[e-mail]>; Wed, 25 Aug 1999 01:40:37 -0700 (PDT)
Received: from nec.oleane.com  (dyn-1-1-221.Cor.dialup.oleane.fr [62.161.8.221])  by s2.smtp.oleane.net  with SMTP id KAA70623 for <[e-mail]>; Wed, 25 Aug 1999 10:42:13 +0200 (CEST)
Message-ID: <008901beeed5$e96afc20$[e-mail]>
From: "Peter lewis" <[e-mail]>
To: <[e-mail]>
Subject: From Firewalls to IPSec VPNs
Date: Wed, 25 Aug 1999 10:43:32 +0200
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.5
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3

Security services and protection mechanisms
IPv6 promises regarding IPSec
Certification infrastructure 
Standardization update
Case Studies: ISPs, carriers, private networks
AH and ESP protocols description
Possible future extensions and modifications of the IKE protocol
Complementarity between IPSec and firewalls
Global Site-to-Site IPSec VPN's with End-to-End SLA's
Managing widespread IPSEC virtual private networks
Solving IPSec VPNs scalability
Results of some interoperability tests
IPSec architectures and non-standardized aspects of IPSec
Adding IPSec VPN functions in an existing router network
Impact of fragmentation on the performance of IPSec coding

IPSEC 99 Conference
>From Firewall to IPSec VPNs

October 26, 27, 28, 29, 1999
Paris - France

More infos: www.upperside.fr/baipsec.htm



Sorry to post this message on the list.

Thanks



Received: from aunt15.ausys.se (void1.ausys.se [62.20.78.253]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id XAA15912 for <[e-mail]>; Tue, 24 Aug 1999 23:33:44 -0700 (PDT)
Received: by aunt15.ausys.se with Internet Mail Service (5.5.2448.0) id <RM0L30FK>; Wed, 25 Aug 1999 08:34:17 +0200
Message-ID: <[e-mail]>
From: Hans Nilsson <[e-mail]>
To: [e-mail]
Subject: CRL version number discrepancy
Date: Wed, 25 Aug 1999 08:34:06 +0200
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2448.0)
Content-Type: text/plain

There is a discrepancy between X.509 and RFC 2459.

X.509 states:

If any extensions included in a CertificateList are defined as critical, the
version element of the CertificateList shall be present.  If no extensions
defined as critical are included, the version element shall be absent. This
may permit a implementation that only supports version 1 CRLs to still use
the CRL if in its examination of the revokedCertificates sequence in the
CRL, it does not encounter an extension. An implementation that supports
version 2 (or greater) CRLs may be able to optimize its processing if it can
determine early in processing that no critical extensions are present in the
CRL.

RFC 2459 states that:

Conforming CAs that issue CRLs MUST issue version 2 CRLs, 

and, later,

When extensions are used, as required by this profile, this field MUST be
present and MUST specify version 2 (the integer value is 1.

The question is now:
When we issue CRLS with non-crictical extensions, should the version number
be omitted (according to X.509) or present and set to 2 (according to RFC
2459?

Until further notice, we regard X.509 as having precedence over RFC 2459. Is
this correct?

Regards
Hans Nilsson




Received: from ext-mail.valicert.com (ns1.valicert.com [63.65.221.10]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id PAA11471 for <[e-mail]>; Tue, 24 Aug 1999 15:31:42 -0700 (PDT)
Received: from int-mail.valicert.com (corporate-gw.valicert.com [63.65.221.2]) by ext-mail.valicert.com (8.9.3/8.9.3) with ESMTP id PAA18595; Tue, 24 Aug 1999 15:33:11 -0700 (PDT)
Received: from rhone (rhone.valicert.com [192.168.3.128]) by int-mail.valicert.com (8.9.3/8.9.3) with SMTP id PAA12117; Tue, 24 Aug 1999 15:33:10 -0700 (PDT)
From: "Ambarish Malpani" <[e-mail]>
To: "'Sweigert, David'" <[e-mail]>, "'Alan Lloyd'" <[e-mail]>, <[e-mail]>, <[e-mail]>
Subject: RE: More problems with OCSP
Date: Tue, 24 Aug 1999 15:36:06 -0700
Message-ID: <002d01beee81$0eb1d580$[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
Importance: Normal
In-Reply-To: <[e-mail]>

Hi Dave,
    How is this a problem with OCSP? (or is this a new thread
with an old subject)?

Regards,
Ambarish

---------------------------------------------------------------------
Ambarish Malpani
Architect                                                650.567.5457
ValiCert, Inc.                                  [e-mail]
1215 Terra Bella Ave.                         http://www.valicert.com
Mountain View, CA 94043-1833


> -----Original Message-----
> From: Sweigert, David [mailto:[e-mail]]
> Sent: Tuesday, August 24, 1999 3:28 PM
> To: Alan Lloyd; '[e-mail]'; [e-mail];
> [e-mail]
> Subject: RE: More problems with OCSP
> 
> 
> 
> As anyone grappling with the problem of defining a directory 
> information
> tree for a multi-national company.  In other words, how do 
> divisions in
> the UK and US relate in the DIT if both divisions are within 
> one corporate
> organization; say MARKETING.
> 
> Would this be appropriate:
> 
> c=US
> o=GlobalCorp
> ou=Marketing
> 
> and
> 
> c=UK
> o=GlobalCorp
> ou=Marketing
> 
> 
> Any thoughts on this ?
> 
> Dave Sweigert
> 


Received: from Newman.GSC.GTE.Com ([e-mail] [207.175.88.67]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id PAA11185 for <[e-mail]>; Tue, 24 Aug 1999 15:26:35 -0700 (PDT)
Received: from gscex01.gsc.gte.com ("port 1234"@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, 24 Aug 1999 18:28:01 -0400 (EDT)
Received: by gscex01.ndhm.gsc.gte.com with Internet Mail Service (5.5.2448.0) id <QJJBSJ9Q>; Tue, 24 Aug 1999 18:28:01 -0400
Content-return: allowed
Date: Tue, 24 Aug 1999 18:28:00 -0400
From: "Sweigert, David" <[e-mail]>
Subject: RE: More problems with OCSP
To: Alan Lloyd <[e-mail]>, "'[e-mail]'" <[e-mail]>, [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"

As anyone grappling with the problem of defining a directory information
tree for a multi-national company.  In other words, how do divisions in
the UK and US relate in the DIT if both divisions are within one corporate
organization; say MARKETING.

Would this be appropriate:

c=US
o=GlobalCorp
ou=Marketing

and

c=UK
o=GlobalCorp
ou=Marketing


Any thoughts on this ?

Dave Sweigert


Received: from Newman.GSC.GTE.Com ([e-mail] [207.175.88.67]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id PAA11102 for <[e-mail]>; Tue, 24 Aug 1999 15:25:54 -0700 (PDT)
Received: from gscex01.gsc.gte.com ("port 1198"@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, 24 Aug 1999 18:27:18 -0400 (EDT)
Received: by gscex01.ndhm.gsc.gte.com with Internet Mail Service (5.5.2448.0) id <QJJBSJ91>; Tue, 24 Aug 1999 18:27:18 -0400
Content-return: allowed
Date: Tue, 24 Aug 1999 18:27:18 -0400
From: "Sweigert, David" <[e-mail]>
Subject: RE: SCVP-01  and   A NEW WG - was Re: NR -- what the real issues	are, and  a proposal
To: Peter Sylvester <[e-mail]>, [e-mail], [e-mail]
Cc: [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"

As anyone grappling with the problem of defining a directory information
tree for a multi-national company.  In other words, how do divisions in
the UK and US relate in the DIT if both divisions are within one corporate
organization; say MARKETING.

Would this be appropriate:

c=US
o=GlobalCorp
ou=Marketing

and

c=UK
o=GlobalCorp
ou=Marketing


Any thoughts on this ?

Dave Sweigert


Received: from WDBY-V42.stpeter.stpaul.com (two.stpaul.com [207.77.220.22] (may be forged)) by mail.proper.com (8.9.3/8.9.3) with ESMTP id OAA10393 for <[e-mail]>; Tue, 24 Aug 1999 14:19:29 -0700 (PDT)
From: [e-mail]
Received: by WDBY-V42.stpeter.stpaul.com; id QAA07718; Tue, 24 Aug 1999 16:15:16 -0500 (CDT)
Received: from astpls86.stpaul.com(165.175.70.9) by WDBY-V42.stpeter.stpaul.com via smap (V4.2) id xmaa07709; Tue, 24 Aug 99 16:14:59 -0500
Received: by astpls86.stpaul.com(Lotus SMTP MTA v4.6.5  (863.2 5-20-1999))  id 862567D7.00753F40 ; Tue, 24 Aug 1999 16:20:39 -0500
X-Lotus-FromDomain: SPC
To: [e-mail]
Message-ID: <[e-mail]>
Date: Tue, 24 Aug 1999 16:19:54 -0500
Mime-Version: 1.0
Content-type: text/plain; charset=us-ascii
Content-Disposition: inline

unsubscribe ietf-pkix




Received: from doggate.exchange.microsoft.com (doggate.exchange.microsoft.com [131.107.88.55]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id MAA09356 for <[e-mail]>; Tue, 24 Aug 1999 12:59:17 -0700 (PDT)
Received: by doggate.exchange.microsoft.com with Internet Mail Service (5.5.2232.9) id <QGYGNZVW>; Tue, 24 Aug 1999 13:00:15 -0700
Message-ID: <[e-mail]>
From: "Don Schmidt (Exchange)" <[e-mail]>
To: "'Ambarish Malpani'" <[e-mail]>, [e-mail]
Subject: RE: SCVP-01
Date: Tue, 24 Aug 1999 13:00:08 -0700
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2232.9)
Content-Type: text/plain; charset="iso-8859-1"

Ambarish,

Since returning from Oslo, I have discussed SCVP with my colleagues and have
confirmed the position I presented during the PKIX session.  Microsoft
currently has no plans to implement SCVP.  We are not aware of any demand
from our customers for such a protocol; whereas, we have several PKI-based
applications which must run when the client is offline as well as online.
But most important, we do not agree with the fundamental justification for
SCVP.  The primary rationale provided in Oslo was that server-based
certificate validation is required by small devices which do NOT have
adequate processing and memory capabilities to locally validate certificate
chains, but DO have readily available network connections to offload this
work to a server.  It has been our experience that the opposite is true.
Devices continually increase in processing power and memory to whatever
level is required, while connectivity continues to be a problem.
Applications which require constant (or on demand) network connectivity to a
supporting server typically suffer performance problems and frequently fail
simply due to dropped packets or connections.

One might be tempted to negate the connectivity argument if it is believed
that SCVP is only intended for handheld communication devices which must
have connectivity to perform their primary function.  However, relying on a
server will add another network hit for every call and possibly introduce a
performance bottleneck.  Furthermore, since these clients will need to be
able to perform rudimentary cracking of at least the end entity's
certificate, it seems we might better spend our time defining a profile that
limited the chain depth for such devices.   

Finally SCVP introduces additional security problems that must be addressed
to make sure a rogue server cannot trick a client into accepting an invalid
certificate or chain.  Locating and authenticating such servers could be a
significant challenge for highly mobile users.  OCSP & DCS already face
these kinds of security issues.  Why solve the same problem over and over in
separate protocols?  If it can be demonstrated that there is a customer
demand for SCVP-type services, then it would seem prudent to add them as an
option to an existing server-centric protocol.

Don Schmidt
Program Manager
Microsoft Corp



 -----Original Message-----
From: 	Ambarish Malpani [mailto:[e-mail]] 
Sent:	Monday, August 23, 1999 11:58 AM
To:	[e-mail]
Subject:	SCVP-01


Hi Guys,
    I noticed that there hasn't been too much discussion of SCVP
after the 01 draft came out. Paul and I have got a few comments
offline, but there hasn't been much on the list. A few people
expressed interest in getting implementations and I was
wondering if we have already gone through the major changes
stage and are winding down the changes that will be made to
the spec.

Comments?

Regards,
Ambarish

---------------------------------------------------------------------
Ambarish Malpani
Architect                                                650.567.5457
ValiCert, Inc.                                  [e-mail]
1215 Terra Bella Ave.                         http://www.valicert.com
Mountain View, CA 94043-1833


Received: from aloe.us.pw.com (pw21.pw9.com [208.141.52.244]) by mail.proper.com (8.9.3/8.9.3) with SMTP id LAA08397 for <[e-mail]>; Tue, 24 Aug 1999 11:31:08 -0700 (PDT)
From: [e-mail]
Received: by aloe.us.pw.com; id OAA24368; Tue, 24 Aug 1999 14:26:25 -0400
Received: from palm.us.pw.com(10.9.16.43) by aloe.us.pw.com via smap (4.1) id xmaa12520; Tue, 24 Aug 99 14:13:11 -0400
Received: from intlnamsmtp10.us.pw.com by palm.us.pw.com (PMDF V5.1-12 #U3018) with SMTP id <[e-mail]> for [e-mail]; Tue, 24 Aug 1999 14:20:24 -0400 (EDT)
Received: by intlnamsmtp10.us.pw.com(Lotus SMTP MTA v1.2 hotfix6  (702.3 8-27-1998)) id 852567D7.00646ECB ; Tue, 24 Aug 1999 14:16:59 -0400
Date: Tue, 24 Aug 1999 14:14:07 -0400
Subject: subscribe
To: [e-mail]
Message-id: <[e-mail]>
MIME-version: 1.0
Content-type: text/plain; charset=us-ascii
Content-disposition: inline
X-Lotus-FromDomain: PRICE WATERHOUSE-US@INTL

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




Received: from poptop.llnl.gov (poptop.llnl.gov [128.115.18.65]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id LAA08158 for <[e-mail]>; Tue, 24 Aug 1999 11:20:31 -0700 (PDT)
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 LAA06743; Tue, 24 Aug 1999 11:21:52 -0700 (PDT)
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.3 (32)
Date: Tue, 24 Aug 1999 11:21:58 -0700
To: Stephen Kent <[e-mail]>
From: Tony Bartoletti <[e-mail]>
Subject: Re: Subdividing the NR bit.
Cc: [e-mail]
In-Reply-To: <v04020a02b3e85bf89830@[128.89.0.110]>
References: <[e-mail]> <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"

At 10:30 AM 8/24/99 -0400, Stephen Kent wrote:
>Tony,
>
><snip>
>
>>It seems that the NR-bit is a sort of arm-waving approach to covering many
>>unspecified things, such as "took extra care to ascertain real ownership",
>>"used a cleaner-room to generate certificate", "promise to archive for a
>>long, long, time."  But none of this is actually promised or specified.
>>Instead, they abide to sign "NR=1" where its meaning is "some of all of
>>the above, to some degree, (see CA/CPS for details)" which does not
>>automate well.  Beyond this, the only mechanical use of the NR-bit is
>>"not to be set in conjunction with bits x, y, or z" (something they DO
>>have control over, if they actually read what they sign.)
>
>I think part of the problem here is a presumption that one can automate all
>of the decision making process on the part of an RP.  I don't think this is
>realistic.  A more tractable model assumes that the RP makes a value
>judgement, perhaps based on reading the CPS for the CA in question, and
>then decides to accept certs that contain an appropriate policy OID and
>have the NR bit set to 1.  Use of the NR bit supports this use model, with
>no further enchacements.  The NR is useful in this context because it
>allows a user to have multiple certs under the same CA, perhaps under the
>same policy OID, and to segregate these by intended use.

Steve,

Perhaps my emphasis upon automation is misplaced (caveat, I believe the
future hold far more automation than we generally imagine.)

As long as the RP will be expected to review the CPS prior to accepting
a cert with a given subset of key-usage bits, then the NR-bit supports
this use model, as you say.

A burden, perhaps necessary, to place upon the RP.

(Aside - Does this model intentionally impede extended automation?)

And there is no particular gain in adding additional key-usage bits
(e.g., subdividing NR) if the bits do not distinguish an automatably
distinct key-usage catagory.

But does this provide sufficient guidance to the subscriber in wielding
the keys in question?  Does software need know?  Am I promising intent?
Am I declaring future denials apriori null and void?  Am I declaring
only simple cognizance of the signing act?
 
I also suppose that the main motivation behind a revision of the NR
(nomenclature or definition) comes from developers who must take their
cues from the folks that give them requirements, those folks possessing
varied/conflicting notions about the precise intent of the NR-bit setting.

The evidence of this list suggests at least some of these issues
remain a concern.

Regards,

___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 ext-mail.valicert.com (ns1.valicert.com [63.65.221.10]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id LAA07888 for <[e-mail]>; Tue, 24 Aug 1999 11:07:00 -0700 (PDT)
Received: from int-mail.valicert.com (corporate-gw.valicert.com [63.65.221.2]) by ext-mail.valicert.com (8.9.3/8.9.3) with ESMTP id LAA17115; Tue, 24 Aug 1999 11:08:32 -0700 (PDT)
Received: from rhone (rhone.valicert.com [192.168.3.128]) by int-mail.valicert.com (8.9.3/8.9.3) with SMTP id LAA07159; Tue, 24 Aug 1999 11:08:31 -0700 (PDT)
From: "Ambarish Malpani" <[e-mail]>
To: "'Peter Sylvester'" <[e-mail]>, <[e-mail]>
Cc: <[e-mail]>
Subject: RE: SCVP-01  and   A NEW WG - was Re: NR -- what the real issues are, and  a proposal
Date: Tue, 24 Aug 1999 11:11:27 -0700
Message-ID: <009101beee5c$15b68e40$[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
In-Reply-To: <[e-mail]>
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3

Hi Peter,
    What is cpkc?

Ambarish

---------------------------------------------------------------------
Ambarish Malpani
Architect                                                650.567.5457
ValiCert, Inc.                                  [e-mail]
1215 Terra Bella Ave.                         http://www.valicert.com
Mountain View, CA 94043-1833


> -----Original Message-----
> From: Peter Sylvester [mailto:[e-mail]]
> Sent: Tuesday, August 24, 1999 9:54 AM
> To: [e-mail]; [e-mail]
> Cc: [e-mail]
> Subject: SCVP-01 and A NEW WG - was Re: NR -- what the real 
> issues are,
> and a proposal
> 
> 
> 
> I would like to understand what is fundamentally missing in a DCSToken
> that you have in a BERT. (except some time expressed as a REAL). 
> 
> I would also like to understand what is fundamentally missing 
> in a DCS request for cpkc
> that is possible with SCVP (except some additional error codes). 
> 
> Regards
> 
> Peter Sylvester
> 


Received: from tomcat.sac.verio.net ([e-mail] [209.162.64.15]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id KAA07294 for <[e-mail]>; Tue, 24 Aug 1999 10:26:13 -0700 (PDT)
Received: from nma.com (pm05-24.sac.verio.net [209.162.64.184]) by tomcat.sac.verio.net (8.9.1a/8.9.1) with ESMTP id KAA04645; Tue, 24 Aug 1999 10:27:39 -0700 (PDT)
Message-ID: <[e-mail]>
Date: Tue, 24 Aug 1999 10:27:17 -0700
From: Ed Gerck <[e-mail]>
X-Mailer: Mozilla 4.61 [en]C-CCK-MCD {Sony}  (Win98; I)
X-Accept-Language: en
MIME-Version: 1.0
To: Stephen Kent <[e-mail]>
CC: [e-mail]
Subject: Options, was Re: To Be, or NR To Be ...
References: <v04020a0cb3e363e29bff@[128.89.0.110]>  <[e-mail]>  <v04020a01b3e318d1f67a@[128.89.0.110]>  <v04020a12b3e384dd5ce6@[128.89.0.110]> <v04020a03b3e85d51e91b@[128.89.0.110]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Stephen Kent wrote:

> Ed,
>
> >Mathematics does not provide security. The technical difference between
> >evidences of past actions (what you call NR)  based on strong crypto and,
> >for example, audit logs is none to me if Khadaffi provides both.
> >
> >Calling "evidences of past actions" by the name "non-repudiation" and
> >pretending they are more credible if based on certificates is simply arguing the
> >process when theattribution is at fault.
>
> Math does provide a basis for security; it the foundation for the public
> key crypto that underlies the focus of this WG.

Math is not self-secure -- anything you can do in math the attacker can also.  The
question is thus not whether math is the foundation for public-key algorithms.  But,
for example, who has the private-key or who/what do you trust.  By promoting
reliance on math, one promotes reliance on no differential between user and
attacker.  What you say is the same as those that simply want  "more bits" in
their keys but have their systems wide open to ActiveX controls -- they also
think that math does provide a basis for security.

But, it does not -- math is simply a tool to security.

> I'm sorry that you dislike the term "non repudiation" but we are NOT changing
> this "term of art" in this standards context.

I do not dislike the term "non-repudiation" at all.  In fact, I think that the concept
of non-repudiation can be very useful and even essential.  But when correctly used,
not as a misnomer to indicate a "NR bit" that has a PKIX description which everyone
(including you) agrees is neither necessary nor sufficient to indicate
non-repudiation.  And in math, when A is neither necessary nor sufficient to B
then this means that B exists independently of A.  In other words, non-repudiation
does not depend on the state of  the NR-bit as it is described in 2459/PKIX -- and
this is both a mathematical and a technical affirmation one should not ignore.

And, as I commented before, if the broken semantics of the NR bit  is not corrected
(and there are three options to do this -- either delete it, or define it truly as
non-repudiation, or rename and redefine it), then the market will be free to
understand the NR bit in many different and conflicting ways -- if this list exchange
in the past month can provide but a sample of them.  Which will be very much
equivalent to deleting it from the spec because "hands off that NR bit" will be
safer, also to the CAs.

So, doing what you propose is certainly one of the three options above. And,
not a bad one comparing how it was one month ago.

Cheers,

Ed Gerck



Received: from edelweb.fr (edelweb.fr [193.51.12.16]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id JAA06775 for <[e-mail]>; Tue, 24 Aug 1999 09:52:23 -0700 (PDT)
Received: from champagne.edelweb.fr (localhost.edelweb.fr [127.0.0.1]) by edelweb.fr with ESMTP id SAA00104; Tue, 24 Aug 1999 18:53:49 +0200 (MET DST)
Received: from champagne.edelweb.fr (champagne.edelweb.fr [193.51.14.161]) by edelweb.fr (nospam/1.1); Tue, 24 Aug 1999 18:53:49 +0200 (MET DST)
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 SAA16580; Tue, 24 Aug 1999 18:53:48 +0200 (MET DST)
From: Peter Sylvester <[e-mail]>
Received: (sylvest@localhost) by emeriau.edelweb.fr (8.7.6/8.6.6) id SAA03830; Tue, 24 Aug 1999 18:53:48 +0200 (MET DST)
Date: Tue, 24 Aug 1999 18:53:48 +0200 (MET DST)
Message-Id: <[e-mail]>
To: [e-mail], [e-mail]
Subject: SCVP-01  and   A NEW WG - was Re: NR -- what the real issues are, and  a proposal
Cc: [e-mail]

I would like to understand what is fundamentally missing in a DCSToken
that you have in a BERT. (except some time expressed as a REAL). 

I would also like to understand what is fundamentally missing in a DCS request for cpkc
that is possible with SCVP (except some additional error codes). 

Regards

Peter Sylvester


Received: from po1.bbn.com (PO1.BBN.COM [192.1.50.38]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id IAA05445 for <[e-mail]>; Tue, 24 Aug 1999 08:10:20 -0700 (PDT)
Received: from [128.89.0.110] (COSMEC.BBN.COM [128.89.0.110]) by po1.bbn.com (8.9.1/8.9.1) with ESMTP id LAA09782; Tue, 24 Aug 1999 11:11:47 -0400 (EDT)
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
X-Sender: [e-mail] (Unverified)
Message-Id: <v04020a03b3e85d51e91b@[128.89.0.110]>
In-Reply-To: <[e-mail]>
References: <v04020a0cb3e363e29bff@[128.89.0.110]> 	    <[e-mail]> 	    <v04020a01b3e318d1f67a@[128.89.0.110]> <v04020a12b3e384dd5ce6@[128.89.0.110]>
Date: Tue, 24 Aug 1999 10:33:34 -0400
To: Ed Gerck <[e-mail]>
From: Stephen Kent <[e-mail]>
Subject: Re: To Be, or NR To Be ...
Cc: [e-mail]

Ed,

>Mathematics does not provide security. The technical difference between
>evidences
>of past actions (what you call NR)  based on strong crypto and, for
>example, audit
>logs is none to me if Khadaffi provides both.
>
>Calling "evidences of past actions" by the name "non-repudiation" and
>pretending
>they are more credible if based on certificates is simply arguing the
>process when the
>attribution is at fault.

Math does provide a basis for security; it the foundation for the public
key crypto that underlies the focus of this WG.  I'm sorry that you dislike
the term "non repudiation" but we are NOT changing this "term of art" in
this standards context.

Steve


Received: from po1.bbn.com (PO1.BBN.COM [192.1.50.38]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id HAA04805 for <[e-mail]>; Tue, 24 Aug 1999 07:30:23 -0700 (PDT)
Received: from [128.89.0.110] (COSMEC.BBN.COM [128.89.0.110]) by po1.bbn.com (8.9.1/8.9.1) with ESMTP id KAA03454; Tue, 24 Aug 1999 10:31:45 -0400 (EDT)
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
X-Sender: [e-mail]
Message-Id: <v04020a02b3e85bf89830@[128.89.0.110]>
In-Reply-To: <[e-mail]>
References: <[e-mail]>
Date: Tue, 24 Aug 1999 10:30:55 -0400
To: Tony Bartoletti <[e-mail]>
From: Stephen Kent <[e-mail]>
Subject: Re: Subdividing the NR bit.
Cc: [e-mail]

Tony,

<snip>

>It seems that the NR-bit is a sort of arm-waving approach to covering many
>unspecified things, such as "took extra care to ascertain real ownership",
>"used a cleaner-room to generate certificate", "promise to archive for a
>long, long, time."  But none of this is actually promised or specified.
>Instead, they abide to sign "NR=1" where its meaning is "some of all of
>the above, to some degree, (see CA/CPS for details)" which does not
>automate well.  Beyond this, the only mechanical use of the NR-bit is
>"not to be set in conjunction with bits x, y, or z" (something they DO
>have control over, if they actually read what they sign.)

I think part of the problem here is a presumption that one can automate all
of the decision making process on the part of an RP.  I don't think this is
realistic.  A more tractable model assumes that the RP makes a value
judgement, perhaps based on reading the CPS for the CA in question, and
then decides to accept certs that contain an appropriate policy OID and
have the NR bit set to 1.  Use of the NR bit supports this use model, with
no further enchacements.  The NR is useful in this context because it
allows a user to have multiple certs under the same CA, perhaps under the
same policy OID, and to segregate these by intended use.

<snip>

Steve


Received: from meridianus.com (209.249.223.34.has.no.reverse [209.249.223.34] (may be forged)) by mail.proper.com (8.9.3/8.9.3) with ESMTP id HAA04574 for <[e-mail]>; Tue, 24 Aug 1999 07:24:09 -0700 (PDT)
Received: from PC1 by  meridianus.com (8.8.8+Sun/SMI-SVR4) id IAA02358; Tue, 24 Aug 1999 08:19:09 -0700 (PDT)
Message-ID: <012d01beee3e$a0752f50$[e-mail]>
From: "todd Glassey" <[e-mail]>
To: <[e-mail]>, <"[e-mail]"@mail.proper.com>, <[e-mail]>
Cc: <[e-mail]>
References: <[e-mail]>
Subject: A NEW WG - was Re: NR -- what the real issues are, and  a proposal
Date: Tue, 24 Aug 1999 07:40:34 -0700
Organization: Meridianus/GMT
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.2918.2701
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2918.2701

All - Defining a mechanism that can prove intent is only half the battle.
The real issue is how do you apply the intent models to a "signaling"
protocol which is essentially what the current TS Drafts refer to. The
reality is that the intent-conveyance is specific to the proofing model, and
not the protocol itself.

The questions are as they have always been:
o-    How do I prove that the digital event I wanted to do (or did) was and
is real, which is clearly an application level service.
o-    What in the PKI Process specifically mandates that we timestamp?, and
the answer is NOTHING!!!. Timestamping is an audit control feature to
provide a credible record of an event and also in some instances, control
signals for the systems that create and use the stamps or Marques.

So Timestamping is something that is done to enable the audit process. So
with that said. What is really needed here? The answer is once again the TST
or Token Standard. Nothing more. What timestamping should do is simply
create and manage tokens that represent events in cyberspace, not that tell
me whether a signature was valid at a particular time. Don't get me wrong,
the signature-temporal validation is a sub-component of the timestamping
process and very valuable. It's just that the timestamp is a much higher
level construct that the mere validation of a signature, and calling of the
validating of a signature as 'timestamping" is actually half the problem
here.

It's not. The timestamp is that token that is produced, and that is that.

Now as to how to proceed with this timestamping morass, I- yesterday
submitted a request to the IESG and the Security Area management that we
create a new, short lived WG specifically to support these efforts at the
Token Level. That is to say a WG Specific to the format and use of
watermarking/timestamping tokens themselves.

The proposed charter is as follows and I would suggest that we dropkick both
McNeil's and my BERT and the TS Effort into this group as part of
watermarking or at least move BERT and the TSToken portions of the Draft
Effort there.

- Todd

--------------
CHARTER
--------------
Audit and Commerce Event Representation Token Working Group (IETF-EToken)
Last Modified: Monday, August 23, 1999
Chair(s):
<TBA>
<TBA>

Security Area Director(s):
Jeffrey Schiller <[e-mail]>
Marcus Leech <[e-mail]>

Security Area Advisor:
Marcus Leech <[e-mail]>

Mailing Lists:
General Discussion:[e-mail]
To Subscribe: [e-mail]
In Body: (un)subscribe
Archive: send e-mail to [e-mail] with 'index' in
body

Description of Working Group:
As Electronic Commerce, and in fact, all forms of Digital
Transaction Processing evolve, and the legislative processes
begin to reinforce privacy and control of  information, some uniform
mechanisms for representing events need to be created.

These event representation templates are intended to create
a baseline for online processing systems and other facilities
designed in the IETF's WG's to interoperate at the event record
level. The will support a number of event types including Notarial,
Power of Attorney, and Financial Transaction Types. These efforts
will address Jurisdiction Setting in the event tokens, and as such
will solve such gating issues as how to implement taxation models
now impeding the rollout of Digital Commerce on a global basis.

This Working Group is intended to have a short lived and aggressive
lifeline such that it presents a set of Token Structure, Use Model
guidelines for using them, and systems recommendations in concert
with PKIX efforts to support those technologies further at the
application level.

Goals and Milestones:
Sep 99
Submit first Token Structure and Interoperability framework for
Event Tokens as I-D.

Nov 99
Submit First interoperability guidelines and statement for TS
Tokens and BERT vision use with the PKIX TS Protocol.

Dec 99
Financial Transactor Structure Draft - BERT II Tokens and
the TSTokens as Financial Services Carriers, supporting direct
commerce and taxation models - I-D

Mar 00
Submit Authentication Scheme Extensions to NTP to IESG for
consideration as an RFC

Internet-Drafts:

No Request For Comments

----- Original Message -----
From: Tim Dean <[e-mail]>
To: <"[e-mail]"@mail.proper.com>; <[e-mail]>
Cc: <[e-mail]>; <[e-mail]>
Sent: Tuesday, August 24, 1999 3:57 AM
Subject: RE: NR -- what the real issues are, and a proposal


> Rich,
>
> >Of course, ANSI X9.45 defines a useful (CMS signed) attribute
> >to indicate the purpose of a signature.  Could we overload this (or
> >define something new but similar) to indicate intent?  The
> >syntax was an OID, so doing this is pretty simple.  I'd be
> >glad to force this thru X9 if the IETF crowd is not interested.
>
> Speaking as one very small part of the "IETF crowd" we are very interested
in
> this. We have long believed that the ability to specify signature
semantics
> when signing messages would be a "Very Useful Thing". But we come at it
from a
> negative perspective - viz, there are many situations where signing
messages
> protects against real threats in the network but where the signing entity
does
> not wish to be encumbered by legal liabilities. Two examples are (1) a
human
> user who wants to protect herself against a law-suit (2) a machine which
has no
> understanding of its legal liabilities and can't easily be taken to court
;-).
> In the absence of anything better we created the "signature type"
attribute and
> put it in our Domsec draft in the S/MIME working group - which we hope to
> re-issue later on this year .  Would that be a suitable container for your
> OID(s)?
>
> Tim
>
> ____________________________________
> Tim Dean
> DERA
> E-mail: [e-mail]
> Web: http://www.dera.gov.uk/
> ____________________________________
>
>
SNIP



Received: from ns0.eris.dera.gov.uk (ns0.eris.dera.gov.uk [128.98.1.1]) by mail.proper.com (8.9.3/8.9.3) with SMTP id EAA02245 for <[e-mail]>; Tue, 24 Aug 1999 04:03:06 -0700 (PDT)
Received: (qmail 19227 invoked from network); 24 Aug 1999 11:04:33 -0000
Received: from unknown (HELO mail-relay.eris.dera.gov.uk) (128.98.2.7) by ns0.eris.dera.gov.uk with SMTP; 24 Aug 1999 11:04:33 -0000
Received: (qmail 4706 invoked from network); 24 Aug 1999 11:04:32 -0000
Received: from tdean.eris.dera.gov.uk (HELO tdean) (128.98.10.5) by mail-relay.eris.dera.gov.uk with SMTP; 24 Aug 1999 11:04:32 -0000
Received: by localhost with Microsoft MAPI; Tue, 24 Aug 1999 11:57:20 +0100
Message-ID: <[e-mail]>
From: Tim Dean <[e-mail]>
Reply-To: "[e-mail]" <[e-mail]>
To: "\"[e-mail]\"@mail.proper.com" <"[e-mail]"@mail.proper.com>, "'[e-mail]'" <[e-mail]>
Cc: "[e-mail]" <[e-mail]>, "[e-mail]" <[e-mail]>
Subject: RE: NR -- what the real issues are, and  a proposal
Date: Tue, 24 Aug 1999 11:57:19 +0100
Organization: DERA
X-Mailer: Microsoft Internet E-mail/MAPI - 8.0.0.4211
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit

Rich,

>Of course, ANSI X9.45 defines a useful (CMS signed) attribute
>to indicate the purpose of a signature.  Could we overload this (or
>define something new but similar) to indicate intent?  The
>syntax was an OID, so doing this is pretty simple.  I'd be
>glad to force this thru X9 if the IETF crowd is not interested.

Speaking as one very small part of the "IETF crowd" we are very interested in 
this. We have long believed that the ability to specify signature semantics 
when signing messages would be a "Very Useful Thing". But we come at it from a 
negative perspective - viz, there are many situations where signing messages 
protects against real threats in the network but where the signing entity does 
not wish to be encumbered by legal liabilities. Two examples are (1) a human 
user who wants to protect herself against a law-suit (2) a machine which has no 
understanding of its legal liabilities and can't easily be taken to court ;-). 
In the absence of anything better we created the "signature type" attribute and 
put it in our Domsec draft in the S/MIME working group - which we hope to 
re-issue later on this year .  Would that be a suitable container for your 
OID(s)?

Tim

____________________________________
Tim Dean
DERA
E-mail: [e-mail]
Web: http://www.dera.gov.uk/
____________________________________


----------
From: 	[e-mail][SMTP:[e-mail]]
Sent: 	19 August 1999 17:58
To: 	"[e-mail]"@mail.proper.com
Cc: 	[e-mail]; [e-mail]
Subject: 	Re: NR -- what the real issues are, and  a proposal

<<File: ATT00011.htm>>
>>> "Rich Ankney" <[e-mail]> 08/17/99 05:07PM >>>
Bob,

Thanks for finally posting all of the relevant stuff in one
message.  My first thought would be to minimize reliance
on the NR bit, i.e. follow Steve's suggestion that if it's
FALSE, you can't use the cert for NR, else you migbe able to.

Of course, ANSI X9.45 defines a useful (CMS signed) attribute
to indicate the purpose of a signature.  Could we overload this (or
define something new but similar) to indicate intent?  The
syntax was an OID, so doing this is pretty simple.  I'd be
glad to force this thru X9 if the IETF crowd is not interested.

Best regards,
Rich

PS: I sent this to you personally rather than to the list in case
you'd like to discuss the details.  If not, of course, feel free
to post your response to the list.



Hi, Rich,

I'll take you upon your offer to post your note to the list, and
I'll also comment in passing on some other contributions from
Ed, Tony, and Steve, recognizing that some other suggestions have
partially overtaken some of these ideas while I was preparing
this note and attending meetings. :-)

I agree with you regarding the case when the NR bit is off -- you
can't use the certificate for any nonrepudiation purpose in that case.
Perhaps I wasn't sufficiently clear in the proposal summary,
although I think I was in the more detailed text, where I said that the NR
bit has to be used to ENABLE the NR bit in the message itself.

If NR bit is off, any message signed with the key in that certificate
CANNOT intentionally or unintentionally be used for any legally
binding purpose -- you are denying, in advance, that that was
your intent, and signaling a prospective relying party that relying
on your signature and certificate would be repudiated in court, if
necessary, and hence such reliance would be quite unwise,
to say the least.

Why should you try to deny in advance something that might be
legally binding (to answer someone else's question)?  Because
you might be concerned about the possibility that your key might
be stolen, and that it might not be YOU that is signing in that fashion!

Obviously you know (or at least ought to know) the strengths and
weakness of your own key management system, and you might
very well decide that a given key/certificate was not sufficiently
well protected to be used for any legally binding purposes -- it would
just be too risky. Maybe your ordinary digital-signature-key-used-for-
network-logon-authentication-via-SSL is kept on your hard
drive with relatively weak password encryption, and your
nonrepudiation key/certificate is kept on a removable smart card.
(I think this is Ed's point -- that if I don't have the power to deny
a given capability in advance, it really isn't nonrepudiation -- it's
just an option that I can't control and hence can't be binding, since
it isn't voluntary.)

As I read Steve's note, I think he is in agreement with at least this point.

However, Steve, Tony, and even Ed then go down a path that I think is
highly questionable, and that is the CA-centric view of enabling
or disabling nonrepudiation within the CPS. Granted, if there is even
the faintest suggestion that the CA might be liable for the user's
actions with respect to his key and how they are used, then the
CA ought to be able to deny the user the ability to set the NR bit.
But it should do, obviously, by simply refusing to issue a certificate
containing that bit.  But whether the CA can impose other conditions
on the subscriber, or on the RP, in this particular area seems highly
doubtful, as I will explain. (And as I expect that you, Rich,
already know because of your banking involvement.)

There are three reasons why something like a NR bit should be in the
certificate, and not just rely on a certificate policy OID (or worse yet,
just a statement in the CPS itself.)

The first is a practical one -- very little RP software to date (none that I 
know of)
implements the policy OID constraint, and without that constraint there is no
enforcement.  In fact, I would bet that a lot of software would ignore the
constraint even if it were marked critical -- they certainly ignore a lot of 
other
critical attributes.

The second reason is more important.  Although I can, if I am the relying
party, choose a superior CA whose certificate specifies a policy OID 
constraint,
I am not required to do so. In fact, I can import and "trust" (accept as valid) 
a user's certificate directly, without relying on any intervening CA's 
certificate
at all.  I'm not quite certain whether a policyOID constraint can be placed on
the end-user's certificate -- can it? -- but even if it is it is far from 
obvious that
such a constraint is binding upon the application. What mechanisms are
postulated to tell the RP what particular policy OID the user feels like 
accepting
today?

So the relying party, or the relying party's IS department, may specify such a 
policy
constraint, BUT THEY ARE NOT REQUIRED TO DO SO.

Finally, as I believe I explained in a previous message, to the best of my
knowledge there is no legal way that I know of whereby the relying party
can be required to even read the CA's CPS prior to accepting a digital 
signature,
or more importantly why a CPS that reflects an agreement between the CA
and the subscriber would be binding upon the RP.

This is a contractual privity issue, and there simply isn't any way around it 
that
I know of -- a contract between A and B is not binding on C, even if there were 
also a contract between B and C.

So the only way that I know of to specify something of this type is in the 
defined
semantics of the attribute itself.  If the NR bit is now so hopeless confused 
that
someone could wriggle out of this definition, then we ought to define a new 
one,
perhaps intentToBeLegallyBound, and deprecate the old one. But I don't think we 
are there yet -- I think we can use the existing bit for this purpose, so long 
as we
recognize that it is the turning off of the bit that is really the most 
important thing.

With respect to the suggestion to define a new signedAttribute to be applied
to the message, Russ Housely indicates that would be outside of the current
SMIME WG's charter, but that the charter could be amended if there was
sufficient interest.

If we can get some reasonable consensus on the overall approach, I would
be happy to work with you, Rich, to perhaps define a joint IETF-SMIME and
 X9 contribution in this area.

Bob



-----Original Message-----
From: Bob Jueneman <[e-mail]>
To: [e-mail] <[e-mail]>
Date: Tuesday, August 17, 1999 5:39 PM
Subject: NR -- what the real issues are, and a proposal


>The message which follows is a rather lengthy attempt to recap of
>the last five years or so of technical/legal discussion regarding
>digital signatures, followed by a proposal for what to do to fix these
>problems.
>
>However, since many may want to skip the justification and cut t
>o the bottom line, I'll put the proposal up front, and then justify it:
>
>My proposal is that the text of the nonrepudiation key usage bit I
>n the PKIX RFC (and hopefully in X.509) be revised to unambiguously
>state that the defined semantics of this bit is to indicate the willingness
>of the subscriber to be legally bound by a digital signature which can be
>verified by a certificate that can be established to have been valid at the
>time of signature, where "valid" has the normal meaning of not expired, not
>revoked, etc., etc.
>
>In addition, I propose that we create an additional indicator of a
>human being's conscious and willful intent to be legally bound by
>a digital signature that would be applied on a message by message
>basis. This additional indicator would require, as an integral part of
>its semantic definition, that an explicit computer-to-human interaction
>be required to provide some reasonable level of ceremonial and due
>caution warning be provided to the user.  In addition, the semantics
>of this indicator should specify that its use must be ENABLED by the
>NR bit ( as redefined) in the certificate which includes the corresponding
>public key.  If the certificate does not have the bit turned on, the
>application is not obligated to request the ceremonial, due caution
>approval; and relying party software should ignore a per-message
>indicator even if present in that case.
>
>The obvious, but not necessarily the only, place to put such a message
>by message indicator would be in the Cryptographic Message Syntax
>used by S/MIME V3, in particular as a new signedAttribute.  Since
>signedAttributes is a SET of self-describing attributes, adding
>an additional one would be very simple.
>
>Now for the history lesson.
[snip]



Received: from ietf.org (odin.ietf.org [132.151.1.176]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id EAA02065 for <[e-mail]>; Tue, 24 Aug 1999 04:00:29 -0700 (PDT)
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA19812; Tue, 24 Aug 1999 07:01:30 -0400 (EDT)
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-ldap-v3-01.txt
Date: Tue, 24 Aug 1999 07:01:29 -0400
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		: Internet X.509 Public Key Infrastructure Operational  
                          Protocols - LDAPv3
	Author(s)	: D. Chadwick
	Filename	: draft-ietf-pkix-ldap-v3-01.txt
	Pages		: 9
	Date		: 23-Aug-99
	
This document describes the features of the Lightweight Directory 
Access Protocol v3 that are needed in order to support a public key 
infrastructure based on X.509 certificates and CRLs.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-pkix-ldap-v3-01.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-ldap-v3-01.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-ldap-v3-01.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-ldap-v3-01.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-pkix-ldap-v3-01.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 mail.proper.com (8.9.3/8.9.3) with ESMTP id CAA27985 for <[e-mail]>; Tue, 24 Aug 1999 02:23:11 -0700 (PDT)
Received: from stefan2 (accurata.inbox.se [193.12.72.24]) by popmail.inbox.se (8.9.3/8.9.3) with SMTP id LAA32179 for <[e-mail]>; Tue, 24 Aug 1999 11:24:38 +0200
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 
Date: Tue, 24 Aug 1999 11:24:57 +0200
To: [e-mail]
From: Stefan Santesson <[e-mail]>
Subject: Re: Pseudonym in Subject DN (in QC certificates)
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 mail.proper.com id CAA27987

Tom, David Magnus and Hans,

What are discussed here is problems in directories if we add a new
attribute for pseudonyms in the subject field and also the possibility to
use an "informational policy OID" to explain just the fact if the
commonName attribute contains a pseudonym.

Regarding the directory problem I would like to have your comments David to
what Tom writes below. Will we brake common object classes in directories
if we use pseudonym instead of commonName in the subject field. We have to
make sure that we don't introduce a new problem if we add this attribute. 

<snip>
>>[Tom Gindin]   I believe that defining a separate pseudonym attribute, and a
>>separate nickname attribute since nicknames are a subclass of pseudonyms
which
>>are much less misleading, would require the division of several existing
>object
>>classes into three, or a sizable change to their definitions.  Among the ones
>>getting this treatment would be person and its subclass organizationalPerson,
>>which are among the most widely deployed of all directory object classes.
>
>[Stefan Santesson] I interpret this as that your advise is to NOT
introduce these attributes
>in the subject field. Correct ?
>
>[Tom Gindin]   Correct.

Secondly I would like to comment on the policy OID issue.

<snip>
>[Tom Gindin]   While certification path processing ignores and is not
disturbed
>by informational policy OID's of the sort I suggested, the subject directory
>attributes approach might be less debatable.
>

Yes, you are right in theory. But I still interpret that you are braking
the implicit semantics of policy OID:s. What if an implementor tries to
detect this policy OID by including this OID in the list of accepted
policies. This will cause the user so accept all certificates which
contains this policy OID. So your way of handling this will introduce a new
detection mechanism where implementation errors are likely to occur. I
would never like to propose such overloading mechanism unless I'm 100% sure
that this will not cause conflicts, and I'm not.

In this case I would rather introduce this information in the qcStatements
extension where such informational policy OID:s can be placed without
trouble. It would be OK to put an OID here saying that this certificate
contains a pseudonym name of the subject. 


/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 tomcat.sac.verio.net ([e-mail] [209.162.64.15]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id UAA11790 for <[e-mail]>; Mon, 23 Aug 1999 20:24:19 -0700 (PDT)
Received: from nma.com (pm02-26.sac.verio.net [209.162.64.45]) by tomcat.sac.verio.net (8.9.1a/8.9.1) with ESMTP id UAA02600; Mon, 23 Aug 1999 20:25:48 -0700 (PDT)
Message-ID: <[e-mail]>
Date: Mon, 23 Aug 1999 20:25:45 -0700
From: Ed Gerck <[e-mail]>
X-Mailer: Mozilla 4.61 [en]C-CCK-MCD {Sony}  (Win98; I)
X-Accept-Language: en
MIME-Version: 1.0
To: [e-mail], "David P. Kemp" <[e-mail]>
Subject: Re: Definition of technical non-repudiation, was Re: NR -- what the real  issues are, and  a proposal
References: <[e-mail]> <[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

>> From: Ed Gerck <[e-mail]>
>>
>> Second, note that "false denial" or "fasely denying" is NOT present in the
>> defintion by Menezes, which is a problem (either as intent or as pre-defined
>> logical state) in the current PKIX definition.

David Kemp wrote:
>
>The rationale for this attention to the word "false" continues to elude
>me.

This is the legacy paragraph in 2459:

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

Here, we may agree that the word 'falsely' in "falsely denying" either means intent
or logic negation:

i. If it is logic negation than the service produces no information because the
denial was already known to be false before the "non-repudiation" service would
protect the r-p against it (and, btw, who verified it to be false before?).  Thus, the
"logic negation" use would need an omniscient and impartial overseer.  And,
following this thinking, if the denial were not false but truthful to that overseer
then it would be accepted as a valid repudiation -- which also shows that the system
does not provide for "non-repudiation" but for "rebuttable pressumption".

ii. If it is intent then the service does not apply to a protocol that only deals
with applications, not users.

Now, compare with the definition [HAC]:

"non-repudiation: preventing the denial of previous commitments or actions"

where there is no need for anyone to be a "tribunal over denials" before the service
is applied (because the r-p itself is the one that defines whether the act it needs to
rely upon is repudiable or not), nor there is any need to deal with the 'intent'
interpretation (not even the r-p needs to deal with it!).  This definition seems thus to be
precise, clear and verifier-centric (btw, what non-repudiation is all about).  And,
according to this definition, denials are always prevented when acts conform to the
system --  whether the acts are truthful or false, whether there was intent or not.
This is "non-repudiation" or "non-rebuttable pressumption".  The same when a
bank clears a check that has a signature that cannot be distinguished from yours
as seen in the bank's file and there was no previous instruction by you to either cancel
that check or the signature in the file.

Thus, when we define non-repudiation as preventing the denial of previous acts,
we are precisely stating that the denial of a previous act would become a falsity in
the system -- irrebuttable-- irrespective of the details or even intent of that act.

But, why can't we say the same the other way around?  Bet we can, but as oftentimes
happen, somethings get more complicated in positive logic:

non-repudiation: corroborating the complement of the denial of previous
                               commitments or actions.

So, I prefer the form used by Menezes and I see no need to make it more complicated.

But, the questions remain -- if the "NR bit" in PKIX is thus not a "non-repudiation"
thingy, then should we rename the PKIX NR thingy or should we change its definition?
And, what name/function should it have, and whether we should at all define bits that
have repudiable definitions  :-)


Cheers,

Ed Gerck







Received: from poptop.llnl.gov (poptop.llnl.gov [128.115.18.65]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id SAA23492 for <[e-mail]>; Mon, 23 Aug 1999 18:12:56 -0700 (PDT)
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 SAA00406; Mon, 23 Aug 1999 18:14:25 -0700 (PDT)
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.3 (32)
Date: Mon, 23 Aug 1999 18:14:32 -0700
To: [e-mail]
From: Tony Bartoletti <[e-mail]>
Subject: Re: Subdividing the NR bit.
Cc: [e-mail]
In-Reply-To: <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"

At 12:57 PM 8/23/99 -0400, [e-mail] wrote:

[snip]

>     A particular difficulty with the current definition is the phrase "protect
>against a false denial", since one can only protect against the consequences of
>a false denial by disproving it.  While I think that requirements might be more
>productive in this particular debate than definitions, I would still replace the
>which clause in NR's definition in 2459 ("which protects against the signing
>entity falsely denying some action, excluding certificate or CRL signing") by
>something like "which permits an independent third party to determine whether
>the signing entity has or has not signed some object, excluding certificates or
>CRL's, when presented with the apparent signature at a time removed from its
>creation".  In addition to the emphasis on what amount to legal claims in the
>current definition, it's almost a triple negative (against, falsely, and
>denial).

Agreed.  Hence my suggestion was to replace the current definition with

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

An improvement, but in the end still unsatisfactorily vague about
why the setting of this key should make any difference to anyone.

>     Here are my thoughts about the other repudiation techniques.
>
>     Repudiations #2 and #4 are active defenses, and require real evidence from
>the signer.  It is not our function here to ensure that a user of this service
>will win every lawsuit, just that they won't lose most of them because our
>definition was seriously inadequate.  As for repudiation #3, who set up the
>automated process?  If I set an agent to watch an auction on eBay and make bids,
>I am responsible for those bids - and if I'm remotely sane there will be a
>limit.  Repudiation #5 is another active defense, and may constitute a claim of
>fraud against the RP or of malpractice against a software provider.  Its
>threshold is probably lower than #2 and #4, though.  As for #6, it's a standard
>consumer protection claim today, and it won't disappear just because we go
>electronic.

I think the central point of all of this, is that the CA (where possible)
should not be signing an object whose terms it cannot control.  We all know
that if a certificate is fraudulently requested (say, I forge your driver's
license, know your VISA card number, whatever is required) then everything
else pretty much falls apart.  So the central role of the CA is to certify
the proper ownership of the keypair.  Beyond this, the CA could add bits
to indicate that it will archive in some manner, for whatever reason, and
may indicate many other things that are under its control.

It seems that the NR-bit is a sort of arm-waving approach to covering many
unspecified things, such as "took extra care to ascertain real ownership",
"used a cleaner-room to generate certificate", "promise to archive for a
long, long, time."  But none of this is actually promised or specified.
Instead, they abide to sign "NR=1" where its meaning is "some of all of
the above, to some degree, (see CA/CPS for details)" which does not
automate well.  Beyond this, the only mechanical use of the NR-bit is
"not to be set in conjunction with bits x, y, or z" (something they DO
have control over, if they actually read what they sign.)

As a relying party with a non-repudiation need, my interest in the
certificate qualities are going to be:

  (1) How sure can I be that the indicated key owner is accurate?
  (2) How far can I rely upon the future existence of evidences?

My need to rely upon the signer also being [willful, knowledgeable]
is acute, but can it be satisfied by a key-usage bit?  And is this
what many will expect when they see "NR"?

Until there is ubiquitous software that can tell the difference
between an Email and a Contract, reliably making the distinction
known to the operator, AND the CA has some way to ascertain at
the time of my signature that such software is in force, they
should not be providing a bit called "NR".  I prefer Ed's POA
(Proof of Authentication) bit as a more accurate description.

Better to certify the specifics under their control, and let others
decide if those specifics meet their conditions for use in their
particular sense of a non-repudiation service.


That's my two cents (and counting;)

___tony___

 
>Beyond this, I thought about a hierarchy of possible "repudiations"
>and wondered just what means would be needed (pre-sig and post-sig)
>to support (protect against) them:
>
>1.  Not My Key:  (argue a forged cert request)
>
>2.  Not My Usage:  (key compromised, etc.)
>
>3.  Not My Active Usage:  (Automated process made the signature)
>
>4.  Not My Willful Active Usage:  (gun to my head)
>
>5.  Not My Intent To Sign THAT:  (False Content Displayed for Signature)
>
>6.  Not My Intent To Be Bound:  (That was a Contract?)
>
>Now, in each case, imagine the NR-bit is set in the certificate, and
>the relying party duly gathers up all evidence for archive.  How much
>protection can this afford against each of these repudiations?
>
>For #1, I think that the RP should retrive and archive, from the CA,
>the photograph taken of the subscriber shaking hands with the CA President,
>a banner in the background stating "Another Fine Customer Purchases an
>NR Certificate, Public Key xxxxx, Date yyyyyy", such photograph digitally
>signed and cosigned by both the CA and subscriber keys, and perhaps
>digitally watermarked with these keys as well.  A voice-print of the
>subscriber reciting the CA/CPS verbatim would be another good piece
>of evidence to archive.


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 mail.proper.com (8.9.3/8.9.3) with ESMTP id OAA17929 for <[e-mail]>; Mon, 23 Aug 1999 14:30:21 -0700 (PDT)
Received: from stingray.missi.ncsc.mil (root@localhost) by stingray.missi.ncsc.mil with ESMTP id RAA29541 for <[e-mail]>; Mon, 23 Aug 1999 17:31:50 -0400 (EDT)
Received: from missi.ncsc.mil (depot.missi.ncsc.mil [144.51.60.1]) by stingray.missi.ncsc.mil with ESMTP id RAA29537 for <[e-mail]>; Mon, 23 Aug 1999 17:31:50 -0400 (EDT)
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 RAA27521 for <[e-mail]>; Mon, 23 Aug 1999 17:31:38 -0400 (EDT)
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 RAA26962 for <[e-mail]>; Mon, 23 Aug 1999 17:30:14 -0400 (EDT)
Message-Id: <[e-mail]>
Date: Mon, 23 Aug 1999 17:30:14 -0400 (EDT)
From: "David P. Kemp" <[e-mail]>
Reply-To: "David P. Kemp" <[e-mail]>
Subject: Re: Definition of technical non-repudiation
To: [e-mail]
MIME-Version: 1.0
Content-Type: TEXT/plain; charset=us-ascii
Content-MD5: boyMA2ZIySgyFO2Ayl+CRg==
X-Mailer: dtmail 1.3.0 CDE Version 1.3 SunOS 5.7 sun4u sparc

> From: Ed Gerck <[e-mail]>
> 
> Second, note that "false denial" or "fasely denying" is NOT present in the
> defintion by Menezes, which is a problem (either as intent or as pre-defined
> logical state) in the current PKIX definition.


The rationale for this attention to the word "false" continues to elude
me.

A "previous commitment or action" (Menezes) or "critical action" (Ford)
is a binary value -- the entity made the commitment / took the action, or
it did not.

A denial is a binary value - the entity denies the action, or does not.
We can use "assert" to refer to a claim in the opposite sense, yielding
the following results:

              |          Entity's claim:
Action:       |    Assert              Deny
---------     |----------------      ------------
Occurred      |  True Assertion      False Denial
Did not Occur |  False Assertion     True Denial


A successful false assertion (a false positive) is a Type I error; a
successful false denial (a false negative) is a Type II error; the goal
of system for verifying evidence should be an error rate of zero.  If
the system meets its goal, then it prevents an entity from successfully
falsely denying an action that did occur.

Or in other words, the evidence evaluation system "protects against
an entity falsely denying some action."  -- X.509

What precisely is wrong with that?  I believe the name for a system
that "protects" against an entity denying an action that did not occur
(i.e. a true denial) is: "a lynching".



Received: from ext-mail.valicert.com (ns1.valicert.com [63.65.221.10]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id NAA17409 for <[e-mail]>; Mon, 23 Aug 1999 13:47:29 -0700 (PDT)
Received: from int-mail.valicert.com (corporate-gw.valicert.com [63.65.221.2]) by ext-mail.valicert.com (8.9.3/8.9.3) with ESMTP id NAA13022; Mon, 23 Aug 1999 13:48:51 -0700 (PDT)
Received: from rsalaptop ([192.168.3.230]) by int-mail.valicert.com (8.9.3/8.9.3) with SMTP id NAA23430; Mon, 23 Aug 1999 13:48:11 -0700 (PDT)
From: "Peter Williams" <[e-mail]>
To: "Elliot Ginsburg" <[e-mail]>
Cc: <[e-mail]>
Subject: RE: To Be, or NR To Be ...
Date: Mon, 23 Aug 1999 13:49:47 -0700
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)
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300
Importance: Normal
In-Reply-To: <F19999D192F6D211AA1700207810B43403A5CB@SOLO>

Bundling NR services with a CA should be one option: it
is not realistic to require that only CAs be able
to provide access to a value-added NR service, once the
user has invoked a proof of origin/receipt service. Nor is
it reasonable to require CA performing the authentication
portion of a NR-grade security service to also
always offer the complete set of transactional
NR assurances.

In the NACHA CARAT PKI model, repository service providers (who
are distinct from the CA(s)) are sufficiently trustworthy to 
act as source of status information, and also act as one 
of the parties that a relying-party may use when
seeking technical and registry support in an NR dispute.

There are some CA service vendors who would like to outlaw
the NACHA model; the reasons seem mainly about competitive
marketing. I would encourage that the wider model be embraced,
understanding that a Repository and CA service may be
be co-located in a single provider.

If Tom and your material could be put together in an ID,
we may be on the way to an IETF specification of technical
NR, and the semantics of the NR bit, in the PKIX 2459 profile.

An evaluation of whether this will meet the PKIX-QC needs, 
where NR assurances must meet CEC (not merely PKIX technical) 
regulatory requirements, will have to wait a while.

> -----Original Message-----
> From: Elliot Ginsburg [mailto:[e-mail]]
> Sent: Monday, August 23, 1999 1:00 PM
> To: Tony Bartoletti; Elliot Ginsburg; tog; Stephen Kent
> Cc: [e-mail]
> Subject: RE: To Be, or NR To Be ...
> 
> 
> A security policy within a security domain is intended to give assurance
> to the consuming population that they can place a certain level of trust
> in the use of PKI credentials issued under this policy, providing that
> all parties adhere to the policy; remember that a policy has user and
> relying party obligations as well as CA obligations. Part of the
> obligation is to use the credentials for their intended use, as asserted
> in the cert. If you don't assume this obligation, you are in violation
> of this policy and you will be incurring a level of risk higher that
> what has been assured by this policy. 
> 
> Probably someone can say this better, but I think that is the gist of
> it.
> 
> Since we also have to deal with the difference between critical and
> non-critcial keyUsage, I'll try the following:
> 
> If NR==0 and keyUsage is marked critical, then it is a violation of this
> CAs policy to use this certificate for NR, and the level of risk
> incurred is undefined, and this CA is not liable for the consequences of
> this usage.
> 
> If NR==0 and keyUsage is marked non-critical, then this domain advises
> not using this cert for NR, because the incurred risk is higher than
> intended for this policy, but does not prohibit it's use; this must be a
> judgement of the user based on the nature and circumstances of its use.
> 
> If NR==1, and keyUsage is marked critical, then this CA intends this
> cert to be used as part of an NR service, and not for other uses, and
> warrants it only for NR use in accordance with the stated policy. (See
> section 12.2.2.2 for the guidance on using these bits in a mutually
> exclusive way. (3:50 PM 8/23/99DS is for other uses, and it may also
> need definitions like this).
> 
> If NR==1, and keyUsage is marked non-critical, then this CA intends this
> cert to be used as part of an NR service, and warrants it for that use
> in accordance with the stated policy, but does not prohibit it from
> other uses; it is, however, intended that other certs would be used for
> these other purposes.
> 
> This still leaves the question of what does non-repudiation mean. If we
> are willing to say that it implies that the CA offers the
> non-repudiation service (which I support), then it can be called NR.
> Otherwise, I agree with Ed that it needs to be renamed. 
> 
> What I'm most concerned with is that we agree on a very tight statement
> of semantics, regardless of how narrow or broad this statement is. (BTW,
> section 12.2.2 implies that authentication and integrity services are to
> be distinguished from NR service).
> 
> 
> 
> 
> 
> 
> Elliott N Ginsburg
> CygnaCom Solutions
> [e-mail]
> 703-848-0883
> 703-848-0960(FAX)
> 
> > -----Original Message-----
> > From:	Tony Bartoletti [SMTP:[e-mail]]
> > Sent:	Monday, August 23, 1999 2:12 PM
> > To:	Elliot Ginsburg; tog; Stephen Kent
> > Cc:	[e-mail]
> > Subject:	RE: To Be, or NR To Be ...
> > 
> > At 08:47 AM 8/23/99 -0400, Elliot Ginsburg wrote:
> > >Since the CA sets these bits, we have to decide what the CA is
> > asserting
> > >when it sets or doesn't set a bit. Just as we have decided that when
> > the
> > >CA asserts a policy OID, it is saying that it created this cert
> > >according to the named policies. When I use that cert, am I asserting
> > >something about policy because I used it? I don't know, but I do know
> > >that the CA did make an assertion.
> > >
> > >So what does the CA assert with the NR bit? One possibility has been
> > >mentioned already for the meaning of the CA setting the NR bit, and
> > that
> > >is whether this cert can be used for non-repudiation. Its one thing,
> > >when I get a message, to trust who sent it and the integrity of the
> > >content; its quite another to be able to verify this five years from
> > >now. So I, as a CA, might tell you that this cert is usable now, but
> > >don't come back to me in five years, because I do not run a
> > >non-repudiation service. Which would imply that if the NR is set,
> > there
> > >is an assertion that this cert was intended to be used for
> > >non-repudiation and can be relied on for that, however
> > non-repudiation
> > >was defined in the policies of the CA. As a relying party, I will not
> > >store this message away and assume I have proof of the signer's
> > actions
> > >if the NR bit is not set.
> > 
> > Elliot,
> > 
> > The point Ed Gerck was making (about 100 posts back;) was that the CA
> > can only say "I will/won't cooperate with the use of this cert for NR
> > purposes."  E.g., If the NR-bit is not set, we don't archive old
> > stuff.
> > 
> > But others that are party to the original transaction are still free
> > to archive the signing cert, CA cert, CA Public Key, CRL's etc., and
> > present them in court in the case of a dispute.  Who knows how far
> > this will get them.  But it has been written on occasion that if the
> > NR-bit is not set, then the CA is saying "you cannot use this cert for
> > NR", and that is not necessarily true.
> > 
> > I agree with you, as Ed has also stated, that the CA controls the cert
> > issuing process, and so it is the CA making an assertion, directly.
> > 
> > 
> > ___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 mail.proper.com (8.9.3/8.9.3) with ESMTP id NAA17044 for <[e-mail]>; Mon, 23 Aug 1999 13:28:51 -0700 (PDT)
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 NAA28921; Mon, 23 Aug 1999 13:30:18 -0700 (PDT)
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.3 (32)
Date: Mon, 23 Aug 1999 13:30:25 -0700
To: Ed Gerck <[e-mail]>, Aram Perez <[e-mail]>
From: Tony Bartoletti <[e-mail]>
Subject: Re: Definition of technical non-repudiation, was Re: NR -- what the real  issues are, and  a proposal
Cc: [e-mail]
In-Reply-To: <[e-mail]>
References: <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"

At 11:55 AM 8/23/99 -0700, Ed Gerck wrote:
>
>
>Aram Perez wrote:
>
>> Hi Ed,
>>
>> [snip]
>> >
>> > In a purely technical way, I agree with the definition of Menezes et al.
>> > in the HAC and I recently quoted it in an email to this WG [snipped]:
>> >
>> > begin quote----------------------------------------------------------
>> > Subject:  Re: Is this non-repudiation or NR, and why?
>> > Date: Thu, 19 Aug 1999 16:52:42 -0700
>> > From:  Ed Gerck <[e-mail]>
>> > ...
>> >
>> > To contrast, compare with Menezes et al., in HAC, page 3:
>> >
>> > "non-repudiation: preventing the denial of previous commitments or actions"
>> >
>> > which is both legally and technically possible (as a function of how it
>> > is done) and is in accord with the name -- non-repudiation. Note that
>> > there is no mention of intent.
>> > ....
>> > end quote------------------------------------------------------------
>>
>> I have problems with "preventing the denial". You can not prevent me from
>> denying anything. All you can do is disprove my denial. So I don't think
>> this is a definition of "technical non-repudiation".
>
>But there are several ways to prevent denial, both technically and legally,

Ed,

I'll bet that in the phrase "preventing a denial", it is assumed that the
term "denial" implies "successful denial".  We can always deny unsucessfully.
In this (common) sense, a "denial" is just an assertion, not an accomplishment.

I am sure that alot of thrashing about is caused by the confusion of terms
like "denial, the assertion" and "denial, the accomplishment".

___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 solo.cygnacom.com (endor.cygnacom.com [205.177.169.102]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id MAA16651 for <[e-mail]>; Mon, 23 Aug 1999 12:52:53 -0700 (PDT)
Received: by SOLO with Internet Mail Service (5.0.1458.49) id <Q24N5ACF>; Mon, 23 Aug 1999 16:00:19 -0400
Message-ID: <F19999D192F6D211AA1700207810B43403A5CB@SOLO>
From: Elliot Ginsburg <[e-mail]>
To: Tony Bartoletti <[e-mail]>, Elliot Ginsburg <[e-mail]>, tog <[e-mail]>, Stephen Kent <[e-mail]>
Cc: [e-mail]
Subject: RE: To Be, or NR To Be ...
Date: Mon, 23 Aug 1999 16:00:19 -0400
X-Priority: 3
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.0.1458.49)
Content-Type: text/plain; charset="iso-8859-1"

A security policy within a security domain is intended to give assurance
to the consuming population that they can place a certain level of trust
in the use of PKI credentials issued under this policy, providing that
all parties adhere to the policy; remember that a policy has user and
relying party obligations as well as CA obligations. Part of the
obligation is to use the credentials for their intended use, as asserted
in the cert. If you don't assume this obligation, you are in violation
of this policy and you will be incurring a level of risk higher that
what has been assured by this policy. 

Probably someone can say this better, but I think that is the gist of
it.

Since we also have to deal with the difference between critical and
non-critcial keyUsage, I'll try the following:

If NR==0 and keyUsage is marked critical, then it is a violation of this
CAs policy to use this certificate for NR, and the level of risk
incurred is undefined, and this CA is not liable for the consequences of
this usage.

If NR==0 and keyUsage is marked non-critical, then this domain advises
not using this cert for NR, because the incurred risk is higher than
intended for this policy, but does not prohibit it's use; this must be a
judgement of the user based on the nature and circumstances of its use.

If NR==1, and keyUsage is marked critical, then this CA intends this
cert to be used as part of an NR service, and not for other uses, and
warrants it only for NR use in accordance with the stated policy. (See
section 12.2.2.2 for the guidance on using these bits in a mutually
exclusive way. (3:50 PM 8/23/99DS is for other uses, and it may also
need definitions like this).

If NR==1, and keyUsage is marked non-critical, then this CA intends this
cert to be used as part of an NR service, and warrants it for that use
in accordance with the stated policy, but does not prohibit it from
other uses; it is, however, intended that other certs would be used for
these other purposes.

This still leaves the question of what does non-repudiation mean. If we
are willing to say that it implies that the CA offers the
non-repudiation service (which I support), then it can be called NR.
Otherwise, I agree with Ed that it needs to be renamed. 

What I'm most concerned with is that we agree on a very tight statement
of semantics, regardless of how narrow or broad this statement is. (BTW,
section 12.2.2 implies that authentication and integrity services are to
be distinguished from NR service).






Elliott N Ginsburg
CygnaCom Solutions
[e-mail]
703-848-0883
703-848-0960(FAX)

> -----Original Message-----
> From:	Tony Bartoletti [SMTP:[e-mail]]
> Sent:	Monday, August 23, 1999 2:12 PM
> To:	Elliot Ginsburg; tog; Stephen Kent
> Cc:	[e-mail]
> Subject:	RE: To Be, or NR To Be ...
> 
> At 08:47 AM 8/23/99 -0400, Elliot Ginsburg wrote:
> >Since the CA sets these bits, we have to decide what the CA is
> asserting
> >when it sets or doesn't set a bit. Just as we have decided that when
> the
> >CA asserts a policy OID, it is saying that it created this cert
> >according to the named policies. When I use that cert, am I asserting
> >something about policy because I used it? I don't know, but I do know
> >that the CA did make an assertion.
> >
> >So what does the CA assert with the NR bit? One possibility has been
> >mentioned already for the meaning of the CA setting the NR bit, and
> that
> >is whether this cert can be used for non-repudiation. Its one thing,
> >when I get a message, to trust who sent it and the integrity of the
> >content; its quite another to be able to verify this five years from
> >now. So I, as a CA, might tell you that this cert is usable now, but
> >don't come back to me in five years, because I do not run a
> >non-repudiation service. Which would imply that if the NR is set,
> there
> >is an assertion that this cert was intended to be used for
> >non-repudiation and can be relied on for that, however
> non-repudiation
> >was defined in the policies of the CA. As a relying party, I will not
> >store this message away and assume I have proof of the signer's
> actions
> >if the NR bit is not set.
> 
> Elliot,
> 
> The point Ed Gerck was making (about 100 posts back;) was that the CA
> can only say "I will/won't cooperate with the use of this cert for NR
> purposes."  E.g., If the NR-bit is not set, we don't archive old
> stuff.
> 
> But others that are party to the original transaction are still free
> to archive the signing cert, CA cert, CA Public Key, CRL's etc., and
> present them in court in the case of a dispute.  Who knows how far
> this will get them.  But it has been written on occasion that if the
> NR-bit is not set, then the CA is saying "you cannot use this cert for
> NR", and that is not necessarily true.
> 
> I agree with you, as Ed has also stated, that the CA controls the cert
> issuing process, and so it is the CA making an assertion, directly.
> 
> 
> ___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 tomcat.sac.verio.net ([e-mail] [209.162.64.15]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id MAA16304 for <[e-mail]>; Mon, 23 Aug 1999 12:30:06 -0700 (PDT)
Received: from nma.com (pm08-44.sac.verio.net [209.162.65.110]) by tomcat.sac.verio.net (8.9.1a/8.9.1) with ESMTP id MAA11976; Mon, 23 Aug 1999 12:30:37 -0700 (PDT)
Message-ID: <[e-mail]>
Date: Mon, 23 Aug 1999 12:30:39 -0700
From: Ed Gerck <[e-mail]>
X-Mailer: Mozilla 4.61 [en]C-CCK-MCD {Sony}  (Win98; I)
X-Accept-Language: en
MIME-Version: 1.0
To: Bob Jueneman <[e-mail]>
CC: [e-mail], [e-mail], [e-mail], [e-mail], [e-mail]
Subject: As proof of CA acts, not as NR, was Re: NR -- a CA guarantee to archive  certificate status?
References: <[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Bob Jueneman wrote:

> "In summary, we can see that the NR bit might reasonably be used to
> denote a certificate for which the CA has accepted the responsibility to
> archive the certificate status for a period of time after the expiration date.
>
> "However, issues of retention and access to such records for longer than
> about 10 years after the scheduled expiration date would make such a reliance
> problematic, given the vagaries of business and the lack of a statutory
> requirement for the transference of such records to another trusted third party."

I agree and, to be consistent and really solve the issue, I suggest that the name
NR bit needs to be changed to POA bit, as in "proofOfAuthentication bit".   This
is clearly not a "NR bit", whatever that might be.  This is a service which provides
various proofs of authentication acts done by the CA  (CA of subscriber, CA of
subscriber's private-key challenge response, CA of signing CAcertificate, CA of
cert issuance, CA of CRL, etc.)

As you say below,

> The biggest problem with the existing definition of the NR bit is that it
> ambiguously, and circularly, refers to a "non-repudiation service"
> without defining such a thing, or saying who has to do what, for whom,
> for how long, etc.

Let us not go into a worse mistake in the new incarnation of this issue,
by having a "NR bit" that  does not even refer to a "non-repudiation service"
and does not define such a thing, but bears the blame ;-) -- while it does a
whole lot of useful things (proof of CA authentication acts) that it would
not say.

Cheers,

Ed Gerck



Received: from prv-mail20.provo.novell.com (prv-mail20.provo.novell.com [137.65.82.195]) by mail.proper.com (8.9.3/8.9.3) with SMTP id LAA15616 for <[e-mail]>; Mon, 23 Aug 1999 11:54:05 -0700 (PDT)
Received: from INET-PRV-Message_Server by prv-mail20.provo.novell.com with Novell_GroupWise; Mon, 23 Aug 1999 12:54:58 -0600
Message-Id: <[e-mail]>
X-Mailer: Novell GroupWise 5.5.2
Date: Mon, 23 Aug 1999 12:54:50 -0600
From: "Bob Jueneman" <[e-mail]>
To: <[e-mail]>, <[e-mail]>, <[e-mail]>, <[e-mail]>
Cc: <[e-mail]>
Subject: NR -- a CA guarantee to archive certificate status?
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 mail.proper.com id LAA15617

I believe that we are making some progress, and at least
clarifying the definition.

Because of the length of this analysis I'll again state the conclusions, 
and then provide my analysis:

"In summary, we can see that the NR bit might reasonably be used to 
denote a certificate for which the CA has accepted the responsibility to
archive the certificate status for a period of time after the expiration date.

"However, issues of retention and access to such records for longer than 
about 10 years after the scheduled expiration date would make such a reliance
problematic, given the vagaries of business and the lack of a statutory 
requirement for the transference of such records to another trusted third party."

-------

The biggest problem with the existing definition of the NR bit is that it 
ambiguously, and circularly, refers to a "non-repudiation service" 
without defining such a thing, or saying who has to do what, for whom,
for how long, etc.

Elliot has proposed what I think is a very reasonable interpretation --
the CA by setting the NR bit is saying that it will maintain an archive of
the status of that certificate for some period of time beyond the expiration date.

If that is what is meant, and there is a reasonable consensus, that's 
fine with me -- we can then go on to argue the need for other 
mechanisms to deal with the issue of rebuttable presumption, etc.,which 
should almost certainly take the form of  additional keyUsage bits.

But back to the now simplified (or at least now understood) definition of 
NR as providing a CA archive for certificate status.  We would still have 
a few questions to deal with, and I would like to see some reasonable
minimum requirements stated so that as a relying party I don't have to go
read all of the text of a CA's CPS in order to know whether I have to 
archive the certificates myself. So please bear with me as I try to
determine whether such an approach is reasonable and practical.

1.  How long will the certificates be archived?  "In perpetuity" is a very long
time, but there isn't a statute of limitations for civil reliance.  In some cases, 
in particular wills and trusts, documents could be admitted into evidence 
50 years or more after they were signed. In the case of real property, the
issue could potentially go back much, much further. (In the 1940's my 
grandmother sued the town of Cape Girardeau, MO, for not complying 
with the terms of a bequest of a significant amount of land to the town
by one of my ancestors who founded the town in the late 1700's!  Since
the bequest stated that the land would revert to his heirs and successors,
she said in effect, either use it as intended, or it's mine!)

Storage keeps getting cheaper and cheaper, but keeping up with the 
progression of technology is the challenge -- as anyone who 
needs a quad-density  5-1/4" floppy disk reader would soon discover.
It sounds funny to say it in a digital age, but probably the safest form
of archive would be a journal printed on high-quality paper and stored 
in a secure repository.  The CA's working records would presumably
be stored on disk, and updated and copied each year to keep them 
refreshed.

Assuming that perhaps 10 to 20% of all certificates are revoked for some 
cause such as a change of name or address or business relationship,
all that needs to be stored is a once a year printout of the range of 
certificate serial numbers which expired during that year,  together 
with the serial number, date, and revocation reason code for those 
certificates which were revoked during that year.  

Assuming a 10 digit serial number, a three digit date, a 1 digit reason
code, and a space per revoked certificate, that's 15 characters each.
It would certainly be possible to print 10 such fields per line, and 100
lines per page using a small but readable font, or 1000 revoked 
certificates per single-sided page. A single ream of paper (500 sheets)
would therefore suffice to hold a million revoked certificates, out of say
5 to 10 million active certificates.  Even if a CA were to issue 100 million
certificates per year, this would only amount to about ten such books 
per year, or one case of copier paper per year.

Based on this analysis, it would appear that retaining such records for 
even one hundred years would not represent an unreasonable
burden on any CA who chooses to go into that business -- 100
boxes or cases of paper stacked five high and ten wide would fit 
in a small office with plenty of room left over.

2.  The next question is what happens to such records if a CA goes 
out of business, and how to locate a particular CA that issued a 
certificate 100 years ago, whether they are still in business or not,
since it is fairly likely that various mergers and acquisitions will have
caused the CA to change their name and address multiple times.

It's clear that a CA cannot be allowed to go out of business and have
the storage company trash all of the records for failure of the CA to 
pay their storage bills if we are to rely on this mechanism!

States such as Utah that have created some form of state licensure
for Certification Authorities have typically provided for the cessation of
activities by a licensed CA, either by having some other CA or 
repository pick up the responsibility, or having the State itself act as 
the repository of last resort.  Unfortunately, most states, including for 
example Illinois, make no provision for the continuing availability
of a CA's records, and without statutory authority the state would not
be compelled to accept such records -- and especially not for unlicenced 
CAs.

Even if the State were to take over such records, practical experience 
suggests that relying on the state to actually be able to find something 
in their archives might be problematic at best -- even birth certificates 
and land records are sometimes lost.

This suggests that although it seems quite reasonable and feasible for even 
a large CA, one with hundred of millions of certificates issued each year,
to securely archive the status of those certificates for up to 100 years, 
RELYING on such a CA to stay in business for that long, or to arrange for 
some other trusted party to take over the responsibility, may be rather
unrealistic.

That being the case, we probably need to think about significantly shorter 
times periods where the archive would be guaranteed, like perhaps 
10 years after the expiration date of a certificate.  It would not be unreasonable
to require an operational CA to deposit such records with a repository, with
the storage fees for the next 10 years paid in advance.

In all probability, 10 years would cover nearly all of the real needs for the 
certificate status as of a given point in time.  And any relying party who could
reasonably expect to have to rely on a digital signature for longer than 
that amount of time would have the alternative of archiving a current, 
timestamped CRL or OCSP response along with the document in question.

In summary, then, we can see that the NR bit might reasonably be used to 
denote a certificate for which the CA has accepted the responsibility to
archive the certificate status for a period of time after the expiration date.

However, issues of retention and access to such records for longer than 
about 10 years after the scheduled expiration date would make such a reliance
problematic, given the vagaries of business and the lack of a statutory 
requirement for the transference of such records to another trusted third party.

Comments?

Bob



Robert R. Jueneman
Security Architect
Network Security Development
Novell, Inc.
122 East 1700 South
Provo, UT 84606
[e-mail]
1-801-861-7387

>>> Elliot Ginsburg <[e-mail]> 08/23/99 06:47AM >>>
Since the CA sets these bits, we have to decide what the CA is asserting
when it sets or doesn't set a bit. Just as we have decided that when the
CA asserts a policy OID, it is saying that it created this cert
according to the named policies. When I use that cert, am I asserting
something about policy because I used it? I don't know, but I do know
that the CA did make an assertion.

So what does the CA assert with the NR bit? One possibility has been
mentioned already for the meaning of the CA setting the NR bit, and that
is whether this cert can be used for non-repudiation. Its one thing,
when I get a message, to trust who sent it and the integrity of the
content; its quite another to be able to verify this five years from
now. So I, as a CA, might tell you that this cert is usable now, but
don't come back to me in five years, because I do not run a
non-repudiation service. Which would imply that if the NR is set, there
is an assertion that this cert was intended to be used for
non-repudiation and can be relied on for that, however non-repudiation
was defined in the policies of the CA. As a relying party, I will not
store this message away and assume I have proof of the signer's actions
if the NR bit is not set.

Elliott N Ginsburg
CygnaCom Solutions
[e-mail] 
703-848-0883
703-848-0960(FAX)



Received: from tomcat.sac.verio.net ([e-mail] [209.162.64.15]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id LAA15485 for <[e-mail]>; Mon, 23 Aug 1999 11:53:41 -0700 (PDT)
Received: from nma.com (pm08-44.sac.verio.net [209.162.65.110]) by tomcat.sac.verio.net (8.9.1a/8.9.1) with ESMTP id LAA02820; Mon, 23 Aug 1999 11:55:03 -0700 (PDT)
Message-ID: <[e-mail]>
Date: Mon, 23 Aug 1999 11:55:06 -0700
From: Ed Gerck <[e-mail]>
X-Mailer: Mozilla 4.61 [en]C-CCK-MCD {Sony}  (Win98; I)
X-Accept-Language: en
MIME-Version: 1.0
To: Aram Perez <[e-mail]>
CC: [e-mail], "Flanigan, Bill" <[e-mail]>, "David P. Kemp" <[e-mail]>, "Tony Bartoletti <[e-mail], Graham Klyne" <[e-mail]>
Subject: Re: Definition of technical non-repudiation, was Re: NR -- what the real  issues are, and  a proposal
References: <[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Aram Perez wrote:

> Hi Ed,
>
> [snip]
> >
> > In a purely technical way, I agree with the definition of Menezes et al.
> > in the HAC and I recently quoted it in an email to this WG [snipped]:
> >
> > begin quote----------------------------------------------------------
> > Subject:  Re: Is this non-repudiation or NR, and why?
> > Date: Thu, 19 Aug 1999 16:52:42 -0700
> > From:  Ed Gerck <[e-mail]>
> > ...
> >
> > To contrast, compare with Menezes et al., in HAC, page 3:
> >
> > "non-repudiation: preventing the denial of previous commitments or actions"
> >
> > which is both legally and technically possible (as a function of how it
> > is done) and is in accord with the name -- non-repudiation. Note that
> > there is no mention of intent.
> > ....
> > end quote------------------------------------------------------------
>
> I have problems with "preventing the denial". You can not prevent me from
> denying anything. All you can do is disprove my denial. So I don't think
> this is a definition of "technical non-repudiation".

But there are several ways to prevent denial, both technically and legally,
so  I must take issue.  In the interest of dialogue, I need to point out first
that there is often a confusion between "non-repudiation proof" and
"repudiation of a proof" (copied from one of my previous msgs):

 Non-repudiation provides for means (e.g., a contract) which
 preempts repudiation claims if certain criteria are met.  However,
 non-repudiation can be repudiated either by disproving assumptions
 supposed to exist (e.g., that the contract is legal) or by proving acts
 supposed to be absent (e.g., a tort).  Aside from these two possibilities,
 non-repudiation can be enforced according to the criteria agreed
 to in the contract and cannot be repudiated, hence its name.

The same applies technically, where the assumptions supposed to exist
are modeled in the "trusted context" (hardware, software, etc.)
and the acts supposed to be absent are modeled in the "risk factors"
(virus, software error, etc.).  Thus, if what is described in "risk" does not
occur and what is described in "trust" occurs, then  the act is non-repudiable
for a previous act that is in accord to those trust and risk models -- the system
has sucessfully prevented the denial of a previous act.

Second, the impeding problem with "later" in the wording used in PKIX NR, which
is open-ended -- later, when? In five years or in 35 years as German law mandates
for business documents?  When the time arrow is reversed and we look into the past,
then this question is *simple* to answer -- because we know the current time where
non-repudiation is being warranted and we know when that event DID happen.
So, when we say that "a non-repudiation system prevents the denial of previous
acts" -- we are saying it about known acts and known time.  Thus, the two
time views are not equivalent at all.

For example, I grant non-repudiation of my signature to a bank in a check -- but
I grant it so that the bank can prevent my denial of checks I previously signed, not
so that the bank can prevent my later denial of checks.  In fact, I can sucessfully
denial any number of checks to the bank *after* I tell the bank my signature is no
longer valid.  So, I can *always* deny later acts, though I may not always deny
previous acts.

Last, note that "false denial" or "fasely denying" is NOT present in the
defintion by Menezes, which is a problem (either as intent or as pre-defined
logical state) in the current PKIX definition.

Cheers,

Ed Gerck



Received: from ext-mail.valicert.com (ns1.valicert.com [63.65.221.10]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id LAA15460 for <[e-mail]>; Mon, 23 Aug 1999 11:53:38 -0700 (PDT)
Received: from int-mail.valicert.com (corporate-gw.valicert.com [63.65.221.2]) by ext-mail.valicert.com (8.9.3/8.9.3) with ESMTP id LAA12217 for <[e-mail]>; Mon, 23 Aug 1999 11:55:02 -0700 (PDT)
Received: from rhone (rhone.valicert.com [192.168.3.128]) by int-mail.valicert.com (8.9.3/8.9.3) with SMTP id LAA21508 for <[e-mail]>; Mon, 23 Aug 1999 11:54:22 -0700 (PDT)
From: "Ambarish Malpani" <[e-mail]>
To: <[e-mail]>
Subject: SCVP-01
Date: Mon, 23 Aug 1999 11:57:59 -0700
Message-ID: <001f01beed99$6bfdd8d0$[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
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3

Hi Guys,
    I noticed that there hasn't been too much discussion of SCVP
after the 01 draft came out. Paul and I have got a few comments
offline, but there hasn't been much on the list. A few people
expressed interest in getting implementations and I was
wondering if we have already gone through the major changes
stage and are winding down the changes that will be made to
the spec.

Comments?

Regards,
Ambarish

---------------------------------------------------------------------
Ambarish Malpani
Architect                                                650.567.5457
ValiCert, Inc.                                  [e-mail]
1215 Terra Bella Ave.                         http://www.valicert.com
Mountain View, CA 94043-1833



Received: from poptop.llnl.gov (poptop.llnl.gov [128.115.18.65]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id LAA14763 for <[e-mail]>; Mon, 23 Aug 1999 11:11:46 -0700 (PDT)
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 LAA21088; Mon, 23 Aug 1999 11:12:29 -0700 (PDT)
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.3 (32)
Date: Mon, 23 Aug 1999 11:12:18 -0700
To: Elliot Ginsburg <[e-mail]>, tog <[e-mail]>, Stephen Kent <[e-mail]>
From: Tony Bartoletti <[e-mail]>
Subject: RE: To Be, or NR To Be ...
Cc: [e-mail]
In-Reply-To: <F19999D192F6D211AA1700207810B43403A5AF@SOLO>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"

At 08:47 AM 8/23/99 -0400, Elliot Ginsburg wrote:
>Since the CA sets these bits, we have to decide what the CA is asserting
>when it sets or doesn't set a bit. Just as we have decided that when the
>CA asserts a policy OID, it is saying that it created this cert
>according to the named policies. When I use that cert, am I asserting
>something about policy because I used it? I don't know, but I do know
>that the CA did make an assertion.
>
>So what does the CA assert with the NR bit? One possibility has been
>mentioned already for the meaning of the CA setting the NR bit, and that
>is whether this cert can be used for non-repudiation. Its one thing,
>when I get a message, to trust who sent it and the integrity of the
>content; its quite another to be able to verify this five years from
>now. So I, as a CA, might tell you that this cert is usable now, but
>don't come back to me in five years, because I do not run a
>non-repudiation service. Which would imply that if the NR is set, there
>is an assertion that this cert was intended to be used for
>non-repudiation and can be relied on for that, however non-repudiation
>was defined in the policies of the CA. As a relying party, I will not
>store this message away and assume I have proof of the signer's actions
>if the NR bit is not set.

Elliot,

The point Ed Gerck was making (about 100 posts back;) was that the CA
can only say "I will/won't cooperate with the use of this cert for NR
purposes."  E.g., If the NR-bit is not set, we don't archive old stuff.

But others that are party to the original transaction are still free
to archive the signing cert, CA cert, CA Public Key, CRL's etc., and
present them in court in the case of a dispute.  Who knows how far
this will get them.  But it has been written on occasion that if the
NR-bit is not set, then the CA is saying "you cannot use this cert for
NR", and that is not necessarily true.

I agree with you, as Ed has also stated, that the CA controls the cert
issuing process, and so it is the CA making an assertion, directly.


___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 mail.proper.com (8.9.3/8.9.3) with ESMTP id LAA14524 for <[e-mail]>; Mon, 23 Aug 1999 11:05:08 -0700 (PDT)
Received: from mailgate1.apple.com (A17-128-100-225.apple.com [17.128.100.225]) by mail-out2.apple.com (8.8.5/8.8.5) with ESMTP id LAA51910 for <[e-mail]>; Mon, 23 Aug 1999 11:06:37 -0700
Received: from scv1.apple.com (scv1.apple.com) by mailgate1.apple.com (mailgate1.apple.com- SMTPRS 2.0.15) with ESMTP id <[e-mail]>; Mon, 23 Aug 1999 11:02:18 -0700
Received: from [17.205.41.166] (aram1.apple.com [17.205.41.166]) by scv1.apple.com (8.9.3/8.9.3) with ESMTP id LAA16239; Mon, 23 Aug 1999 11:02:17 -0700 (PDT)
Message-Id: <[e-mail]>
X-Mailer: Microsoft Outlook Express Macintosh Edition - 4.5 (0410)
Date: Mon, 23 Aug 1999 11:02:17 -0700
Subject: Re: Definition of technical non-repudiation, was Re: NR -- what the real issues are, and  a proposal
From: "Aram Perez" <[e-mail]>
To: Ed Gerck <[e-mail]>
Cc: [e-mail], "Flanigan, Bill" <[e-mail]>, "David P. Kemp" <[e-mail]>, "Tony Bartoletti <[e-mail],Graham Klyne" <[e-mail]>
MIME-Version: 1.0
X-Priority: 3
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit

Hi Ed,

[snip]
> 
> In a purely technical way, I agree with the definition of Menezes et al.
> in the HAC and I recently quoted it in an email to this WG [snipped]:
>
> begin quote----------------------------------------------------------
> Subject:  Re: Is this non-repudiation or NR, and why?
> Date: Thu, 19 Aug 1999 16:52:42 -0700
> From:  Ed Gerck <[e-mail]>
> ...
>
> To contrast, compare with Menezes et al., in HAC, page 3:
>
> "non-repudiation: preventing the denial of previous commitments or actions"
>
> which is both legally and technically possible (as a function of how it
> is done) and is in accord with the name -- non-repudiation. Note that
> there is no mention of intent.
> ....
> end quote------------------------------------------------------------

I have problems with "preventing the denial". You can not prevent me from
denying anything. All you can do is disprove my denial. So I don't think
this is a definition of "technical non-repudiation".

[snip]

Regards,
Aram Perez


Received: from mail-out1.apple.com (mail-out1.apple.com [17.254.0.52]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id KAA13799 for <[e-mail]>; Mon, 23 Aug 1999 10:32:54 -0700 (PDT)
Received: from mailgate1.apple.com (A17-128-100-225.apple.com [17.128.100.225]) by mail-out1.apple.com (8.8.5/8.8.5) with ESMTP id KAA20964 for <[e-mail]>; Mon, 23 Aug 1999 10:34:19 -0700
Received: from scv1.apple.com (scv1.apple.com) by mailgate1.apple.com (mailgate1.apple.com- SMTPRS 2.0.15) with ESMTP id <[e-mail]> for <[e-mail]>; Mon, 23 Aug 1999 10:32:53 -0700
Received: from [17.205.41.166] (aram1.apple.com [17.205.41.166]) by scv1.apple.com (8.9.3/8.9.3) with ESMTP id KAA11437 for <[e-mail]>; Mon, 23 Aug 1999 10:32:52 -0700 (PDT)
Message-Id: <[e-mail]>
X-Mailer: Microsoft Outlook Express Macintosh Edition - 4.5 (0410)
Date: Mon, 23 Aug 1999 10:32:52 -0700
Subject: Re: Subdividing the NR bit.
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 Bob,

[snip (but only to keep the message short)] 
> Since I'm not a supporter of this meaning, I admit that I might be
> missing something.  But so far, within the restricted context of the
> traditional non-repudiation service, ignoring such issues as rebuttable
> presumptions of either burden of proof or risk of loss, or conscious intent,
> I can't think of anything this bit provides where it is either necessary
> or sufficient, whether it is set or not set.  And that is a long-winded
> way of spelling USELESS.

I couldn't have stated it better.

Regards,
Aram Perez

[snip]


Received: from tomcat.sac.verio.net ([e-mail] [209.162.64.15]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id JAA12479 for <[e-mail]>; Mon, 23 Aug 1999 09:04:54 -0700 (PDT)
Received: from nma.com (pm02-22.sac.verio.net [209.162.64.41]) by tomcat.sac.verio.net (8.9.1a/8.9.1) with ESMTP id JAA18848 for <[e-mail]>; Mon, 23 Aug 1999 09:06:21 -0700 (PDT)
Message-ID: <[e-mail]>
Date: Mon, 23 Aug 1999 09:06:26 -0700
From: Ed Gerck <[e-mail]>
X-Mailer: Mozilla 4.61 [en]C-CCK-MCD {Sony}  (Win98; I)
X-Accept-Language: en
MIME-Version: 1.0
To: "[e-mail]" <[e-mail]>
Subject: Re: What non-repudiation is not and the PA bit, was Re: To Be,or NR To  Be ...
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

[This dialogue corrects a mistatement in one of
my messages and is forwarded with permission
by David Boyce.  His original message is also
included below.]


David:

I agree with  you.  My only excuse is that it was a "humorous rendering" :-)

The problem of more than one public-key cert for one key is
a liability issue for the signer -- and always is, because if cert revocation
of one cert is already at most a probability (ie, you can never be certain
that all of your cert users received or have acessed or will acess your
cert revocation -- and no CA warrants it either) then for two certs or
more ... it simply gets worse.  This is even worse in consequences for NR certs
(whatever they are).  Also, since a signature may not include the key-usage
bits or may be verifiable regardless of the key usage bits it may embed,
it is not advisable at all to have the same key in common and in NR certs.

That said, I believe the following (still humorous and informal text) would
better express what IMO the current PKIX NR bit really is:

  We hereby declare that when the proofOfAuthentication [POA] bit is asserted
  in a certificate, any message verifiable with that certificate can be used
  as legal proof against us, but not otherwise.

Comments?


Cheers,

Ed Gerck


David Boyce wrote:

> Ed Gerck writes:
>
> >- We hereby declare that when the proofOfAuthentication bit is
> asserted in a
> >  certificate, any  message signed with the certificate can be used as legal
> >  proof against us, but not otherwise.
>
> Ed,
>
> keep up the good work!
>
> I'm sorry to be pedantic, but may I point out that there is a problem
> with the wording "any message signed with the certificate" which may be
> bigger than just requiring more precise text?
>
> A message is not *signed with* the certificate - it is *signed with* a
> private key which presumably corresponds to the public key contained in
> a claimed supporting certificate which has this 'PA' bit set.
>
> This may be a problem if that key pair may be represented in several
> certificates, some with the PA bit set and (at least one) unset.
>
> (I know use of the same key in several certs is discouraged, but it may
> still happen.)
>
> In these circumstances, a message which the originator signed with that
> private key and passing his non-PA certificate to support the signature,
> might have that certificate fraudulently switch with a PA certificate,
> thereby apparently giving the relying party legal proof not intended by
> the originator when he signed the message with that key.
>
> This same line of argument would apply to the NR bit, or any other
> semantic difference between two certificates representing the same key
> pair.
>
> Regards,
>
> David.
> --
> David Boyce
>
> MessagingDirect Ltd.
> Tel:    [phone]                 Richmond, Surrey, ENGLAND
> Email:  [e-mail]  WWW: http://www.MessagingDirect.com/


Received: from solo.cygnacom.com (endor.cygnacom.com [205.177.169.102]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id FAA09666 for <[e-mail]>; Mon, 23 Aug 1999 05:40:52 -0700 (PDT)
Received: by SOLO with Internet Mail Service (5.0.1458.49) id <Q24N5AAH>; Mon, 23 Aug 1999 08:48:01 -0400
Message-ID: <F19999D192F6D211AA1700207810B43403A5AF@SOLO>
From: Elliot Ginsburg <[e-mail]>
To: tog <[e-mail]>, Tony Bartoletti <[e-mail]>, Stephen Kent <[e-mail]>
Cc: [e-mail]
Subject: RE: To Be, or NR To Be ...
Date: Mon, 23 Aug 1999 08:47:59 -0400
X-Priority: 3
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.0.1458.49)
Content-Type: text/plain

Since the CA sets these bits, we have to decide what the CA is asserting
when it sets or doesn't set a bit. Just as we have decided that when the
CA asserts a policy OID, it is saying that it created this cert
according to the named policies. When I use that cert, am I asserting
something about policy because I used it? I don't know, but I do know
that the CA did make an assertion.

So what does the CA assert with the NR bit? One possibility has been
mentioned already for the meaning of the CA setting the NR bit, and that
is whether this cert can be used for non-repudiation. Its one thing,
when I get a message, to trust who sent it and the integrity of the
content; its quite another to be able to verify this five years from
now. So I, as a CA, might tell you that this cert is usable now, but
don't come back to me in five years, because I do not run a
non-repudiation service. Which would imply that if the NR is set, there
is an assertion that this cert was intended to be used for
non-repudiation and can be relied on for that, however non-repudiation
was defined in the policies of the CA. As a relying party, I will not
store this message away and assume I have proof of the signer's actions
if the NR bit is not set.



Elliott N Ginsburg
CygnaCom Solutions
[e-mail]
703-848-0883
703-848-0960(FAX)

> -----Original Message-----
> From:	tog [SMTP:[e-mail]]
> Sent:	Friday, August 20, 1999 4:57 PM
> To:	Tony Bartoletti; Stephen Kent
> Cc:	[e-mail]
> Subject:	Re: To Be, or NR To Be ...
> 
> 
> ----- Original Message -----
> From: Stephen Kent <[e-mail]>
> To: Tony Bartoletti <[e-mail]>
> Cc: <[e-mail]>
> Sent: Wednesday, August 18, 1999 7:25 AM
> Subject: Re: To Be, or NR To Be ...
> 
> 
> > Tony,
> >
> > >I don't claim to be expert on all the existing protocols.  But
> certainly
> > >there could arise protocols that provide for crypto-strength
> throughout.
> > >In such a case, it would seem that an "NR-authentication" might be
> required
> > >at the outset of the session, else the chain has no anchors.
> >
> > Usually, we provide NR only in the context of a specific
> application,
> > because the semantics of the application are an important part of
> NR.
> > Since one does all sorts of things during a "login session" it may
> be less
> > appropriate to suppoort NR at the Telnet level.  However, I don't
> dispute
> > your suggestion that it might be possible to fashion NR at this
> granularity.
> >
> > >But the entire discussion is still confused, I believe, by the
> often
> > >unspoken distinction between "repudiating that you took some
> action"
> > >versus "repudiating that you did so intentionally, understood your
> > >exposure to liability, etc."
> >
> > Agreed.
> 
> Actually the agrument seems to be based in whether the NR bit is a
> protocol
> flag to the application or for use within the protocol itself as part
> of the
> protocol process.
> 
> >
> 
> Todd
> 


Received: from praseodumium.btinternet.com (praseodumium.btinternet.com [194.73.73.82]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id KAA21637 for <[e-mail]>; Sat, 21 Aug 1999 10:50:02 -0700 (PDT)
Received: from [195.99.55.112] (helo=dwc-acer) by rhenium.btinternet.com with smtp (Exim 2.05 #1) id 11IE7t-0004rV-00 for [e-mail]; Sat, 21 Aug 1999 17:36:17 +0100
From: "David Chadwick" <[e-mail]>
Organization: University of Salford
To: [e-mail]
Date: Sat, 21 Aug 1999 17:31:24 +0100
MIME-Version: 1.0
Content-type: text/plain; charset=US-ASCII
Content-transfer-encoding: 7BIT
Subject: Revised version of LDAPv3 profile
Reply-to: [e-mail]
Priority: normal
X-mailer: Pegasus Mail for Win32 (v3.01d)
Message-Id: <[e-mail]>

Steve, Warwick

I have today asked the ID editor to publish the revised version of the 
LDAPv3 profile for PKIX. This document has had a substantial 
number of changes since the first version, and therefore I dont think 
it should go for last call just yet (as was suggested it might at the 
Oslo meeting). In particular, there has been a large new section 
added about schema issues. Various certificate and CRL matching 
rules have been added, as has a chunk about attribute certificates. 
Also changes have been made to accommodate the large number of 
comments from various people, especially Mark Wahl. Finally I have 
inserted a number of editors comments asking for views about a 
number of issues in the document, so these need to be resolved. So 
I await for comments on this version before preparing one for last 
call.

David
***************************************************

David Chadwick
IS Institute, University of Salford, Salford M5 4WT
Tel [phone]  Fax [phone]
Mobile [phone]
*NEW* Email [e-mail] *NEW*
Home Page  http://www.salford.ac.uk/its024/chadwick.htm
Understanding X.500  http://www.salford.ac.uk/its024/X500.htm
X.500/LDAP Seminars http://www.salford.ac.uk/its024/seminars.htm
Entrust key validation string MLJ9-DU5T-HV8J

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


Received: from tomcat.sac.verio.net ([e-mail] [209.162.64.15]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id SAA16353 for <[e-mail]>; Fri, 20 Aug 1999 18:39:31 -0700 (PDT)
Received: from nma.com (pm03-13.sac.verio.net [209.162.64.79]) by tomcat.sac.verio.net (8.9.1a/8.9.1) with ESMTP id SAA08683; Fri, 20 Aug 1999 18:40:33 -0700 (PDT)
Message-ID: <[e-mail]>
Date: Fri, 20 Aug 1999 18:40:33 -0700
From: Ed Gerck <[e-mail]>
X-Mailer: Mozilla 4.61 [en]C-CCK-MCD {Sony}  (Win98; I)
X-Accept-Language: en
MIME-Version: 1.0
To: Stephen Kent <[e-mail]>
CC: Tony Bartoletti <[e-mail]>, Peter Williams <[e-mail]>, [e-mail]
Subject: Re: To Be, or NR To Be ...
References: <v04020a0cb3e363e29bff@[128.89.0.110]>  <[e-mail]>  <v04020a01b3e318d1f67a@[128.89.0.110]> <v04020a12b3e384dd5ce6@[128.89.0.110]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Stephen Kent wrote:

> This WG establishes standards for public key crypto technology.  Thus, 2459
> and associated PKIX documents should always be interpreted in that context.
> As I mentioned in a recent response to Peter, other forms of NR evidence
> may be acceptable in a court, but that does not mean that we ought to
> endorse their use when we understand the technical differences between NR
> evidence based on strong crypto and, for example, audit logs.

Mathematics does not provide security. The technical difference between evidences
of past actions (what you call NR)  based on strong crypto and, for example, audit
logs is none to me if Khadaffi provides both.

Calling "evidences of past actions" by the name "non-repudiation" and pretending
they are more credible if based on certificates is simply arguing the process when the
attribution is at fault.

Cheers,

Ed Gerck



Received: from poptop.llnl.gov (poptop.llnl.gov [128.115.18.65]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id RAA09647 for <[e-mail]>; Fri, 20 Aug 1999 17:59:33 -0700 (PDT)
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 SAA08979; Fri, 20 Aug 1999 18:00:45 -0700 (PDT)
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.3 (32)
Date: Fri, 20 Aug 1999 18:00:36 -0700
To: [e-mail], [e-mail]
From: Tony Bartoletti <[e-mail]>
Subject: Re: Subdividing the NR bit.
Cc: [e-mail], Stephen Kent <[e-mail]>, [e-mail]
In-Reply-To: <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"

At 07:39 PM 8/20/99 -0400, [e-mail] wrote:
>     Here are two points where it might not be useless from a purely technical
>standpoint:
>
>1)   The passage from X.509 I quoted earlier about a CA's responsibility for
>archiving CRL's governing certificates explicitly refers to support for the NR
>service.  So one current technical use is: a CA is responsible for archiving all
>CRL's governing any NR certificates, or at least the last one prior to the
>expiration of any NR certificate.  This probably should be extended to hold a CA
>responsible for archiving any expired NR certificates as well as CRL's.
>
>2)   The NR bit might be held to govern whether a signature should ever be
>applied to a preservable, independently verifiable signature package.  I don't
>have any idea what technical NR means if it doesn't refer to the creation of
>such a package including signature (and perhaps to the verification of the
>package as well, but I see that as a subsequent step which is usually not
>invoked, although making it feasible is the motivation for the service in the
>first place).  Does anybody have any other idea what technical NR means?
>
>3)   Even if only #1 is applicable to NR certificates, it would be a
>considerable reason why nobody should rely on a non-NR certificates for a very
>high-value transaction where the signature is likely to be needed in court in
>the event of a dispute, unless the validity period runs beyond the local statute
>of limitations.
>
>          Tom Gindin

Tom,

I tend to agree.  So far, the only real description of "Technical NR"
I have seen is "You better archive/timestamp/notarize this stuff, 'cause
it may be important later."

Beyond this, I thought about a hierarchy of possible "repudiations"
and wondered just what means would be needed (pre-sig and post-sig)
to support (protect against) them:

1.  Not My Key:  (argue a forged cert request)

2.  Not My Usage:  (key compromised, etc.)

3.  Not My Active Usage:  (Automated process made the signature)

4.  Not My Willful Active Usage:  (gun to my head) 

5.  Not My Intent To Sign THAT:  (False Content Displayed for Signature)

6.  Not My Intent To Be Bound:  (That was a Contract?)

Now, in each case, imagine the NR-bit is set in the certificate, and
the relying party duly gathers up all evidence for archive.  How much
protection can this afford against each of these repudiations? 

For #1, I think that the RP should retrive and archive, from the CA,
the photograph taken of the subscriber shaking hands with the CA President,
a banner in the background stating "Another Fine Customer Purchases an
NR Certificate, Public Key xxxxx, Date yyyyyy", such photograph digitally
signed and cosigned by both the CA and subscriber keys, and perhaps
digitally watermarked with these keys as well.  A voice-print of the
subscriber reciting the CA/CPS verbatim would be another good piece
of evidence to archive.

Any Ideas about repudiations 2-6 ?

___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 mail.proper.com (8.9.3/8.9.3) with ESMTP id QAA08831 for <[e-mail]>; Fri, 20 Aug 1999 16:46:10 -0700 (PDT)
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 QAA14109; Fri, 20 Aug 1999 16:47:23 -0700 (PDT)
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.3 (32)
Date: Fri, 20 Aug 1999 16:47:14 -0700
To: Stephen Kent <[e-mail]>
From: Tony Bartoletti <[e-mail]>
Subject: RE: To Be, or NR To Be ...
Cc: "Peter Williams" <[e-mail]>, <[e-mail]>
In-Reply-To: <v04020a12b3e384dd5ce6@[128.89.0.110]>
References: <[e-mail]> <v04020a0cb3e363e29bff@[128.89.0.110]> <[e-mail]> <v04020a01b3e318d1f67a@[128.89.0.110]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"

At 06:28 PM 8/20/99 -0400, Stephen Kent wrote:
>Tony,
>
>>
>>from 2459:
>>
>>     "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."
>>
>>Steve,
>>
>>What part of the above definition for the nonRepudiation bit implies
>>a technical, crypto-based definition for NR?  And what exactly is a/the
>>crypto-based definition for NR, aside from DigSig-Strength-Authentication?
>
>This WG establishes standards for public key crypto technology.  Thus, 2459
>and associated PKIX documents should always be interpreted in that context.
>As I mentioned in a recent response to Peter, other forms of NR evidence
>may be acceptable in a court, but that does not mean that we ought to
>endorse their use when we understand the technical differences between NR
>evidence based on strong crypto and, for example, audit logs.

I agree that a distinction can be made between "PK-crypto-evidence" and
"other forms of NR evidence."  But I can only assume that the meaning of
the nonRepudiation bit is that it toggles "the protocol is obliged to
cooperate (cryptographically) with services that intend to provide for
(ostensibly cryptographic) non repudiation capabilities".

Unfortunately, saying that the NR-bit (cryptographically) toggles the
enablement of cryptographic NR services somewhere" isn't very helpful.
(Or, put another way, its *too* helpful, open to wide interpretation.)

>>I think the sub-phrase:
>>
>>  "protects against the signing entity falsely denying some action"
>>
>>is poor.  First, I would drop "falsely", since that is merely added
>>as a gratuitous "for instance, falsely".  Second, there needs to be a
>>clarification for what is meant by "some action".  In particular, it
>>should mean either "the act of having knowingly signed" or it should
>>mean "the intent to be bound to the terms contained under signature".
>>It should not be "take your pick".
>
>I tend to think of the action as knowlingly applied the signature, which is
>the technical aspect of the process analogous to a wet signature.  The
>second things cited above seems one step removed and is probably not best
>represented by a bit in a cert.

Then, as a first cut, I would replace the paragraph with:

   "The nonRepudiation bit is asserted when the subject public key is
    used to verify digital signatures within a cryptographic service
    which protects against the signing entity denying a cognizant role
    in the signature generation, excluding certificate or CRL signing."

Or, in a more positive form:

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

Of course, some may argue that "cognizant" should be replaced by one of
"active", "culpatory", etc.

Thoughts?

___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 tomcat.sac.verio.net ([e-mail] [209.162.64.15]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id PAA08288 for <[e-mail]>; Fri, 20 Aug 1999 15:53:02 -0700 (PDT)
Received: from nma.com (pm02-25.sac.verio.net [209.162.64.44]) by tomcat.sac.verio.net (8.9.1a/8.9.1) with ESMTP id PAA04821; Fri, 20 Aug 1999 15:53:58 -0700 (PDT)
Message-ID: <[e-mail]>
Date: Fri, 20 Aug 1999 15:53:57 -0700
From: Ed Gerck <[e-mail]>
X-Mailer: Mozilla 4.61 [en]C-CCK-MCD {Sony}  (Win98; I)
X-Accept-Language: en
MIME-Version: 1.0
To: Aram Perez <[e-mail]>
CC: [e-mail], "Flanigan, Bill" <[e-mail]>, "David P. Kemp" <[e-mail]>, "Tony Bartoletti <[e-mail],Graham Klyne" <[e-mail]>
Subject: Definition of technical non-repudiation, was Re: NR -- what the real  issues are, and  a proposal
References: <[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Aram Perez wrote:

> BTW, did anyone successfully define "technical non-repudiation" in a purely
> technical way or did I miss that also?

Yes, you did miss it, but since it may have been buried under an email delluge
and others have also asked the same, let me requote.  I have CC'd others that
may also find this of their interest, in a specific thread.

In a purely technical way, I agree with the definition of Menezes et al. in the
HAC and I recently quoted it in an email to this WG [snipped]:

begin quote----------------------------------------------------------
Subject:  Re: Is this non-repudiation or NR, and why?
Date: Thu, 19 Aug 1999 16:52:42 -0700
From:  Ed Gerck <[e-mail]>
...

To contrast, compare with Menezes et al., in HAC, page 3:

"non-repudiation: preventing the denial of previous commitments or actions"

which is both legally and technically possible (as a function of how it is done)
and is in accord with the name -- non-repudiation. Note that there is no mention
of intent.
....
end quote------------------------------------------------------------


I also note that the above definition uses the word *previous* --  which
is crucial to the whole concept of non-repudiation as understood in
business and is not  present in PKIX or ISO definitions.

Further, it also states that the objective of non-repudiation is to *prevent
denial* -- not put in place a system that would protect against a "false"
denial after the communication event took place (PKIX), nor define a
decision based on what is essentially a rebuttable presumption model
(Ford).

There are thus more than one type of "non-repudiation" at play here,
and I can distinguish 4 different types.  But what all those types of NR
are doing has a common aspect -- they all exist in order to deny
evidence,  not to corroborate evidence.  However, they are most
certainly different in how they handle this process and in what results
they may obtain, even if we just restrict ourselves to the technical
domain -- as the definition from Menezes shows.

Cheers,

Ed Gerck






Received: from prv-mail20.provo.novell.com (prv-mail20.provo.novell.com [137.65.82.195]) by mail.proper.com (8.9.3/8.9.3) with SMTP id PAA08036 for <[e-mail]>; Fri, 20 Aug 1999 15:40:20 -0700 (PDT)
Received: from INET-PRV-Message_Server by prv-mail20.provo.novell.com with Novell_GroupWise; Fri, 20 Aug 1999 16:41:04 -0600
Message-Id: <[e-mail]>
X-Mailer: Novell GroupWise 5.5.2
Date: Fri, 20 Aug 1999 16:40:57 -0600
From: "Bob Jueneman" <[e-mail]>
To: <[e-mail]>, <[e-mail]>
Cc: <[e-mail]>
Subject: Re: NR and Private Key Usage Period
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 mail.proper.com id PAA08037

Tom,

I think we are in violent agreement.

WRT to the PKUP of something other than a signing key, and in particular
and encryption (key exchange) key, I tend to regard the required life
of such keys as effectively infinite, at least if I ever want to be able to read 
my own mail in the future.  (Of course, in-house counsel who would like everyone
to trash all of their e-mail messages immediately after reading them, so that 
they don't end up as evidence in a Tobacco suit might disagree.)

BTW, your reply was interesting, since your mail package apparently 
included all of the original attachments, including my certificates, my 
.vcf file, and the original smime.p7s attachment containing my signature!

Your message showed up as with a  "signature not verified -- the message 
may have been tampered with" warning, with the certificate being mine.
Thanks for the nice test case!

What mail package are you using, including version and rev. level?

Bob

>>> <[e-mail]> 08/20/99 03:49PM >>>


[e-mail] on 08/20/99 04:54:00 PM

To:   "[e-mail]"@e1.ny.us.ibm.com, [e-mail] 
cc:
Subject:  Re: NR and Private Key Usage Period





Tom,

Unless I read your message too quickly, to my way of thinking
you have this exactly backwards.  The Private Key Usage
period was supposed to be shorter than, not longer than the
certificate validity.

[Tom Gindin]   You did read it too quickly, because I didn't say which of the
two periods was longer - I thought everybody understood that.  The idea was that
a certificate which was created with a private key usage period shorter than the
certificate validity would be usable for NR signatures only until the PKUP
expired, but that those signatures could be checked against CRL's until the
certificate itself expired.  It is true that X.509 section 11.2 has a note which
might require archiving of expired CRL's, but they wouldn't be available online
and the note's wording is fairly unhelpful: "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."  The emphasis on
CA-provided (not CA-certified) keys here might make this note inapplicable to
the case where the NR keys are generated by end-user clients.  This wording is
from the June 1997 version, and perhaps it has been replaced by something which
more obviously binds CA's which certify externally generated keys as NR ones.
If it hasn't been replaced, it should be.

If the current definition of NR means anything at all (which
isn't clear), then I would submit that it PROBABLY means that
that the signature is intended to endure and still be considered
valid long AFTER the certificate has been expired, or even
been revoked, so long as it can be established that it was valid
at the time of signing, e.g., with OCSP, CRLs plus notarized timestamps,
Papal archives, or whatever.

There is virtually no reason I can think of why the Private Key Usage
should extend beyond the expiration date of the certificate --
that just increases the risk of compromise with no concomitant
benefit.

What the Private Key Validity period should do, and the reason why
I am still opposed to deprecating it, is to set a time after which a signature
which was apparently created using a key that was supposedly zeroized
should be looked at with considerable scepticism, to say the least.

(For those who may have tuned in late -- the fact that a certificate has
expired or even been revoked does NOT ipso facto mean that the
signature is not legally binding -- it just means that it may be
more difficult to prove.)

Assuming that keys and certificates are relatively inexpensive, but that
validation of a signature once the certificate has expired is considerably
more expensive than during the validity period (because of the
additional archiving, etc., required), then from the user's perspective
what he would like to do is use short-lived keys and long-lived certificates.

Ignoring cryptanalytic attacks, zeroizing a key is the surest possible
way of protecting against a key compromise. So if a key management
system provides a way to automatically schedule a key for destruction
(or at least to remind the user to destroy it), that would be a Good Thing.

Once the key has been zeroized, from the user's perspective, and especially
from the Relying Party's perspective, the longer the certificate lifetime, the
better, since during the validity period it isn't necessary to have all of the
time stamped archives -- you can just query the CA to see whether
the key is still valid..  But from the CA's perspective, of course, this
isn't too good, because it increases the size of the CRL's.

[Tom Gindin]   This argument only applies to signing certificates, especially
NR, right?

Regards,

Bob

(P.S. -- this is a beta version of GroupWise 5.5 with S/MIME support.
If anyone notices anything wrong with the format, etc., please let
me know so we can fix it.)


Robert R. Jueneman
Security Architect
Network Security Development
Novell, Inc.
122 East 1700 South
Provo, UT 84606
[e-mail] 
1-801-861-7387

>>> <[e-mail]> 08/20/99 10:12AM >>>
     Today, Private Key Usage Period is recommended against by RFC 2459 (section
4.2.1.4).  Given that most of the scenarios for NR require that certificates be
valid at the time when a signature is to be checked by a third party, which may
be long after the object is signed, shouldn't Private Key Usage Period be used
with NR certificates?

     A possible new wording would be:
     The Private Key Usage Period extension should only be present in
certificates which possess a keyUsage extension with the nonRepudiation bit of
that extension set.

     Similar, but weaker, arguments would apply to permitting this extension
when the keyCertSign bit is set as well, since certificates may also be valid
for a long time.

          Tom Gindin





Received: from po1.bbn.com (PO1.BBN.COM [192.1.50.38]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id PAA07803 for <[e-mail]>; Fri, 20 Aug 1999 15:30:37 -0700 (PDT)
Received: from [128.89.0.110] (COSMEC.BBN.COM [128.89.0.110]) by po1.bbn.com (8.9.1/8.9.1) with ESMTP id SAA15115; Fri, 20 Aug 1999 18:31:42 -0400 (EDT)
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
X-Sender: [e-mail]
Message-Id: <v04020a12b3e384dd5ce6@[128.89.0.110]>
In-Reply-To: <[e-mail]>
References: <v04020a0cb3e363e29bff@[128.89.0.110]> <[e-mail]> <v04020a01b3e318d1f67a@[128.89.0.110]>
Date: Fri, 20 Aug 1999 18:28:25 -0400
To: Tony Bartoletti <[e-mail]>
From: Stephen Kent <[e-mail]>
Subject: RE: To Be, or NR To Be ...
Cc: "Peter Williams" <[e-mail]>, <[e-mail]>

Tony,

>
>from 2459:
>
>     "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."
>
>Steve,
>
>What part of the above definition for the nonRepudiation bit implies
>a technical, crypto-based definition for NR?  And what exactly is a/the
>crypto-based definition for NR, aside from DigSig-Strength-Authentication?

This WG establishes standards for public key crypto technology.  Thus, 2459
and associated PKIX documents should always be interpreted in that context.
As I mentioned in a recent response to Peter, other forms of NR evidence
may be acceptable in a court, but that does not mean that we ought to
endorse their use when we understand the technical differences between NR
evidence based on strong crypto and, for example, audit logs.

>I think the sub-phrase:
>
>  "protects against the signing entity falsely denying some action"
>
>is poor.  First, I would drop "falsely", since that is merely added
>as a gratuitous "for instance, falsely".  Second, there needs to be a
>clarification for what is meant by "some action".  In particular, it
>should mean either "the act of having knowingly signed" or it should
>mean "the intent to be bound to the terms contained under signature".
>It should not be "take your pick".

I tend to think of the action as knowlingly applied the signature, which is
the technical aspect of the process analogous to a wet signature.  The
second things cited above seems one step removed and is probably not best
represented by a bit in a cert.


Steve


Received: from prv-mail20.provo.novell.com (prv-mail20.provo.novell.com [137.65.82.195]) by mail.proper.com (8.9.3/8.9.3) with SMTP id PAA07581 for <[e-mail]>; Fri, 20 Aug 1999 15:22:37 -0700 (PDT)
From: [e-mail]
Message-Id: <[e-mail]>
Received: from INET-PRV-Message_Server by prv-mail20.provo.novell.com with Novell_GroupWise; Fri, 20 Aug 1999 16:23:10 -0600
Mime-version: 1.0
Date: Fri, 20 Aug 1999 16:23:00 -0600
X-Mailer: Groupwise 5.5.2.1 (Beta)
Cc: "Peter Williams <[e-mail]>"<"[e-mail]">, Stephen Kent<[e-mail]>
Subject: Subdividing the NR bit.
To: "[e-mail]", [e-mail]
Content-type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="____MKSPBLIILMQSLKEAQOPQ____"

--____MKSPBLIILMQSLKEAQOPQ____
Content-type: text/plain; charset=iso-8859-1
Content-disposition: inline

Tony, I was thinking about your classification of the uses 
of the NR bit some more yesterday and this morning, and 
my recent response to Tom Gundin and your message has 
crystallized my thinking some more.

I was already concerned about the possible dual meanings of 
NR bit, as that is generally not a good thing architecturally.

So let's temporarily set aside the issue of the "Rebuttable 
Presumption" or "intent" functions, and concentrate solely 
on the classical, DOD/ISO view of the "non-repudiation 
service" function.

Since that definition doesn't seem to lay any "thou shalt's" or "thou 
shalt not's" on me as a developer, I'm rather clueless as to 
exactly what I am supposed to do or not do when I see or
don't see such a bit.

But poor draftsmanship aside, what is it that we think it OUGHT
to do?

One possible meaning is:  This is a really big and important 
certificate, for really big and important messages, so anyone
who sees it ought to run off to the CA and gather up all of the 
CRLs for all of the CAs in the chain, get them timestamped, 
archive them along with the message, etc., especially since 
you might need to validate this signature some time after 
the certificate expires.

But Duh!  As a relying party, I can decide that for myself, 
whether the bit is turned on or not.  "Oh golly gee, this is a 
$1 million transaction that doesn't have the NR bit turned on.
Guess I ought to gather up all of the important evidence anyway."

Or, "This is just a receipt for a 25 cent candy bar. I don't know why 
NR bit was turned on, but I will have eaten the candy bar before 
I can gather up all of the evidence, so I'm not going to bother."

Net information content added -- zero. Nothing I couldn't have 
decided for myself, in either case.

So it doesn't help the relying party.  How about the subscriber?
Well, maybe.  Maybe he gathers up all such evidence for outgoing
messages that have the NR bit turned on in the certificate, just so
hell have it in case he needs it.  But there are surely other ways of 
doing this, including a bcc to an archive, and always gathering up a 
timestamped copy of your own CRL once a day.  Again, not 
very convincing, whether the bit is on or off.

So how about the CA?  Of course, I don't know why the CA 
was involved in this in the first place, unless they are offering 
to insure the transaction, in which case a policyOID is a much 
better mechanism (insured by whom, for how much, and with 
what provisos -- a bit much to cram into a single bit.)

Maybe they feel the need to do a better job of due diligence
for such a certificate? OK, but why the bit -- it's just a different 
certificate class.

Likewise, maybe it has something to do with the key strength, or how 
it's stored?  Again, a single bit is a lousy mechanism for such an issue.

Maybe it means that as a subscriber I should be really careful not to 
let anyone else have access to the key, but again, Duh.

Maybe it means that both the subscriber and the CA should make 
sure that the key isn't subject to key escrow or business key recovery.
But the DS bit would be sufficient for that, presumably -- a separate 
bit would not be required.

Since I'm not a supporter of this meaning, I admit that I might be 
missing something.  But so far, within the restricted context of the 
traditional non-repudiation service, ignoring such issues as rebuttable
presumptions of either burden of proof or risk of loss, or conscious intent,
I can't think of anything this bit provides where it is either necessary 
or sufficient, whether it is set or not set.  And that is a long-winded 
way of spelling USELESS.

But in this connection, Peter Williams proposed that:
>>>
>> In the specific case of the Authenticode example, I agree that it might be
>> reasonable to amend 2459 to allow the NR bit to be set as well as the DS
>> bit.
>
>This was discussed before, and the list agreed with
>my assertion then, as you evidently do now. Unaccountable
>offline msgs got the bit removed, presumably.

And Steve Kent responded:

>I don't recall that "the list agreed" on this topic, but then the length of
many of your messages precludes reading them to the end :-).  If the 2459
authors agree, then we're OK.

At the risk of getting both Peter and Steve irritated with me but perhaps
for different reasons, I'd like to understand what the NR bit is thought 
to accomplish, before we add it back in.

Unless someone can come up with something I've overlooked in this
area, I would propose that we nail this particular coffin shut, and 
move on to the intent to use and strength of key issues that Tony cites.

Bob


>>> Tony Bartoletti <[e-mail]> 08/20/99 01:21PM >>>
All,

There is a central point to this debate.  There appears to be two
distinct positions held, in particular to the meaning "NR-bit NOT SET".

Strength 0f Intent:
Some say this means "I signed it, I intended to sign it, but I do not
intend its use beyond pure authentication of data and sender, and that
specifically *I* am not signalling assent to be legally/contractually
bound by any terms contained in the data."

Strength Of Key-Binding:
Others say it means "I may not have signed it.  The key protections for
this key do not warrant any presumption that its use is restricted to
the individual given as the certified owner."  Its not a "strong-enough"
key for the purposes of NR.

Clearly, these two meanings are WORLDS apart, and cannot both be called
"the meaning of NR-bit NOT SET".

Part of the confusion is that these two meanings are not entirely
unrelated.  It would make no sense to assert "assent to legal binding"
with a key that is weakly-held.  In a sense,

  weakly-held-key < strongly-held-key < strongly-intended-signature

and some want "NR-bit 0" to disavow only "strongly-intended-signature"
while others argue it disavows "strongly-held-key", which then takes
"strongly-intended-signature" down with it.

There are probably good arguments for both positions.  But it is
clear to me that there cannot be ambiguity as to which of these
two positions is being asserted.

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

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

MIIJaQYJKoZIhvcNAQcCoIIJWjCCCVYCAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCCB6kw
ggMuMIICl6ADAgECAhEA0nYujRQMPX2yqCVdr+4NdTANBgkqhkiG9w0BAQIFADBfMQswCQYDVQQG
EwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xNzA1BgNVBAsTLkNsYXNzIDEgUHVibGljIFBy
aW1hcnkgQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkwHhcNOTgwNTEyMDAwMDAwWhcNMDgwNTEyMjM1
OTU5WjCBzDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0
IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEgSW5jb3Jw
LiBCeSBSZWYuLExJQUIuTFREKGMpOTgxSDBGBgNVBAMTP1ZlcmlTaWduIENsYXNzIDEgQ0EgSW5k
aXZpZHVhbCBTdWJzY3JpYmVyLVBlcnNvbmEgTm90IFZhbGlkYXRlZDCBnzANBgkqhkiG9w0BAQEF
AAOBjQAwgYkCgYEAu1pEigQWu1X9A3qKLZRPFXg2uA1Ksm+cVL+86HcqnbnwaLuV2TFBcHqBS7lI
E1YtxwjhhEKrwKKSq0RcqkLwgg4C6S/7wju7vsknCl22sDZCM7VuVIhPh0q/Gdr5FegPh7Yc48zG
mo5/aiSS4/zgZbqnsX7vyds3ashKyAkG5JkCAwEAAaN8MHowEQYJYIZIAYb4QgEBBAQDAgEGMEcG
A1UdIARAMD4wPAYLYIZIAYb4RQEHAQEwLTArBggrBgEFBQcCARYfd3d3LnZlcmlzaWduLmNvbS9y
ZXBvc2l0b3J5L1JQQTAPBgNVHRMECDAGAQH/AgEAMAsGA1UdDwQEAwIBBjANBgkqhkiG9w0BAQIF
AAOBgQCIuDc73dqUNwCtqp/hgQFxHpJqbS/28Z3TymQ43BuYDAeGW4UVag+5SYWklfEXfWe0fy0s
3ZpCnsM+tI6q5QsG3vJWKvozx74Z11NMw73I4xe1pElCY+zCphcPXVgaSTyQXFWjZSAA/Rgg5V+C
prGoksVYasGNAzzrw80FopCubjCCBHMwggPcoAMCAQICEF6mQzFngv6Wl+eGgC1QPt4wDQYJKoZI
hvcNAQEEBQAwgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBU
cnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIElu
Y29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENB
IEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQwHhcNOTkwNTExMDAw
MDAwWhcNMDAwNTEwMjM1OTU5WjCCARcxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQL
ExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9z
aXRvcnkvUlBBIEluY29ycC4gYnkgUmVmLixMSUFCLkxURChjKTk4MR4wHAYDVQQLExVQZXJzb25h
IE5vdCBWYWxpZGF0ZWQxNDAyBgNVBAsTK0RpZ2l0YWwgSUQgQ2xhc3MgMSAtIE1pY3Jvc29mdCBG
dWxsIFNlcnZpY2UxGDAWBgNVBAMUD1JvYmVydCBKdWVuZW1hbjEjMCEGCSqGSIb3DQEJARYUYmp1
ZW5lbWFuQG5vdmVsbC5jb20wgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBANW8HQNToKMy+VNz
L0IEq3SoWmSY2Qlsut0sMwe3fwzJR9DglDQApUf13tJZdU48ZNzRC16QkZs8nFM2gCyFAAv4QhfA
kYymhVqjrBiuNTs7K3O30W0ok6Nv6v/aokHIU6tAzLLuBMuayuN7sS58FDfcXwBvabN/ePIamR40
aQN5AgMBAAGjggEGMIIBAjAJBgNVHRMEAjAAMIGsBgNVHSAEgaQwgaEwgZ4GC2CGSAGG+EUBBwEB
MIGOMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vQ1BTMGIGCCsGAQUFBwIC
MFYwFRYOVmVyaVNpZ24sIEluYy4wAwIBARo9VmVyaVNpZ24ncyBDUFMgaW5jb3JwLiBieSByZWZl
cmVuY2UgbGlhYi4gbHRkLiAoYyk5NyBWZXJpU2lnbjARBglghkgBhvhCAQEEBAMCB4AwMwYDVR0f
BCwwKjAooCagJIYiaHR0cDovL2NybC52ZXJpc2lnbi5jb20vY2xhc3MxLmNybDANBgkqhkiG9w0B
AQQFAAOBgQBhbRmCI9CSHD2vYJOyQ9JsQ8NKDmTAKUY4qNwGXfsQcE+Wtr/vvhllfHscQ/JY4GM0
dvR2rYEq/I6nMk5Unlju527qbQYsVoA4FqRdcl1tGQRwBSsSPMS7qTmbnyujc1PA5dEjQRu9VVNj
pDiDc3nAcWFeb7SpjVmqzav5opJvizGCAYgwggGEAgEBMIHhMIHMMRcwFQYDVQQKEw5WZXJpU2ln
biwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZl
cmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFI
MEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29u
YSBOb3QgVmFsaWRhdGVkAhBepkMxZ4L+lpfnhoAtUD7eMAkGBSsOAwIaBQAwDQYJKoZIhvcNAQEB
BQAEgYCBlcHl36dyMCzweI7FvZxQIxJ8J+QPS+JYON3yUthaCIHripFEYBNmICn+QzMpeSdBBgb2
l8SOY/CsljUeCPEw+eSCyMIiR4B6qlOfOCp0jbtkfgMAgQDhg1XqpgMY/OzcLMNfnF1dHsBiK1xf
r1Hcy1fi89fW6to5v/JukBJiew==

--____MKSPBLIILMQSLKEAQOPQ____--


Received: from caladan.verisign.com (caladan.verisign.com [205.180.232.21]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id PAA07299 for <[e-mail]>; Fri, 20 Aug 1999 15:10:14 -0700 (PDT)
Received: from mentat.verisign.com by caladan.verisign.com (8.8.5/BCH1.5) id PAA25468; Fri, 20 Aug 1999 15:09:30 -0700 (PDT)
Received: from newman.verisign.com by mentat.verisign.com (8.8.5/BCH1.0) id PAA15582; Fri, 20 Aug 1999 15:10:54 -0700 (PDT)
Received: by newman.verisign.com with Internet Mail Service (5.5.2448.0) id <RFVV0JW9>; Fri, 20 Aug 1999 15:10:57 -0700
Message-ID: <[e-mail]>
From: Warwick Ford <[e-mail]>
To: "'[e-mail]'" <[e-mail]>
Subject: LAST CALL:draft-ietf-pkix-dhpop-01.txt
Date: Fri, 20 Aug 1999 15:10:56 -0700
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2448.0)
Content-Type: text/plain; charset="iso-8859-1"

This document is brought to your attention for 14-day PKIX WG Last Call....

-----Original Message-----
From: [e-mail] [mailto:[e-mail]]
Sent: Thursday, August 19, 1999 4:07 AM
Cc: [e-mail]
Subject: I-D ACTION:draft-ietf-pkix-dhpop-01.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		: Diffie-Hellman Proof-of-Possession Algorithms
	Author(s)	: H. Prafullchandra, J. Schaad
	Filename	: draft-ietf-pkix-dhpop-01.txt
	Pages		: 23
	Date		: 18-Aug-99
	
This document describes two methods for producing a signature from a
Diffie-Hellman key pair.  This behavior is needed for such
operations as creating a signature of a PKCS #10 certification
request.  These algorithms are designed to provide a proof-of-
possession rather than general purpose signing.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-pkix-dhpop-01.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-dhpop-01.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-dhpop-01.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 letterbox.cs.auckland.ac.nz (letterbox.cs.auckland.ac.nz [130.216.35.1]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id OAA06937 for <[e-mail]>; Fri, 20 Aug 1999 14:55:32 -0700 (PDT)
Received: from kakapo.cs.auckland.ac.nz (kakapo.cs.auckland.ac.nz [130.216.34.10]) by letterbox.cs.auckland.ac.nz (8.8.6/8.8.6/cs-master) with ESMTP id JAA09105; Sat, 21 Aug 1999 09:56:45 +1200 (sender [e-mail])
Received: (from pgut001@localhost) by kakapo.cs.auckland.ac.nz (8.8.6/8.8.6/cs-slave) id JAA14629; Sat, 21 Aug 1999 09:56:39 +1200 (NZST) (sender [e-mail])
Date: Sat, 21 Aug 1999 09:56:39 +1200 (NZST)
Message-ID: <[e-mail]>
From: [e-mail] (Peter Gutmann)
To: [e-mail], [e-mail]
Subject: Re: NR and Private Key Usage Period

[e-mail] writes:

>There is virtually no reason I can think of why the Private Key Usage should 
>extend beyond the expiration date of the certificate -- that just increases 
>the risk of compromise with no concomitant benefit.

There is one reason, but it's pretty specialised: You may want your private 
decryption key to stay around for a few days after the public portion has gone
to bignum heaven in order to allow messages in transit over the expiry time to
be decrypted.  This is probably easier than trying to juggle overlapping 
expiry dates for certs.

Peter.


Received: from e1.ny.us.ibm.com (e1.ny.us.ibm.com [32.97.182.101]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id OAA06709 for <[e-mail]>; Fri, 20 Aug 1999 14:49:11 -0700 (PDT)
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 RAA36588; Fri, 20 Aug 1999 17:49:58 -0400
Received: from D51MTA05.pok.ibm.com (d51mta05.pok.ibm.com [9.117.200.33]) by northrelay02.pok.ibm.com (8.8.8m2/NCO v2.04) with SMTP id RAA178826; Fri, 20 Aug 1999 17:50:18 -0400
Received: by D51MTA05.pok.ibm.com(Lotus SMTP MTA v4.6.4  (830.2 3-23-1999))  id 852567D3.0077F545 ; Fri, 20 Aug 1999 17:50:15 -0400
X-Lotus-FromDomain: IBMUS
To: [e-mail], [e-mail]
cc: [e-mail]
Message-ID: <[e-mail]>
Date: Fri, 20 Aug 1999 17:49:02 -0400
Subject: Re: NR and Private Key Usage Period
Mime-Version: 1.0
Content-type: multipart/mixed;  Boundary="0__=oyhsLd76eBszZHvSKe2qARxIC6Eny8oyRwHESDyA43fCrt8KzRKfSLpx"
Content-Disposition: inline

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



[e-mail] on 08/20/99 04:54:00 PM

To:   "[e-mail]"@e1.ny.us.ibm.com, [e-mail]
cc:
Subject:  Re: NR and Private Key Usage Period





Tom,

Unless I read your message too quickly, to my way of thinking
you have this exactly backwards.  The Private Key Usage
period was supposed to be shorter than, not longer than the
certificate validity.

[Tom Gindin]   You did read it too quickly, because I didn't say which of the
two periods was longer - I thought everybody understood that.  The idea was that
a certificate which was created with a private key usage period shorter than the
certificate validity would be usable for NR signatures only until the PKUP
expired, but that those signatures could be checked against CRL's until the
certificate itself expired.  It is true that X.509 section 11.2 has a note which
might require archiving of expired CRL's, but they wouldn't be available online
and the note's wording is fairly unhelpful: "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."  The emphasis on
CA-provided (not CA-certified) keys here might make this note inapplicable to
the case where the NR keys are generated by end-user clients.  This wording is
from the June 1997 version, and perhaps it has been replaced by something which
more obviously binds CA's which certify externally generated keys as NR ones.
If it hasn't been replaced, it should be.

If the current definition of NR means anything at all (which
isn't clear), then I would submit that it PROBABLY means that
that the signature is intended to endure and still be considered
valid long AFTER the certificate has been expired, or even
been revoked, so long as it can be established that it was valid
at the time of signing, e.g., with OCSP, CRLs plus notarized timestamps,
Papal archives, or whatever.

There is virtually no reason I can think of why the Private Key Usage
should extend beyond the expiration date of the certificate --
that just increases the risk of compromise with no concomitant
benefit.

What the Private Key Validity period should do, and the reason why
I am still opposed to deprecating it, is to set a time after which a signature
which was apparently created using a key that was supposedly zeroized
should be looked at with considerable scepticism, to say the least.

(For those who may have tuned in late -- the fact that a certificate has
expired or even been revoked does NOT ipso facto mean that the
signature is not legally binding -- it just means that it may be
more difficult to prove.)

Assuming that keys and certificates are relatively inexpensive, but that
validation of a signature once the certificate has expired is considerably
more expensive than during the validity period (because of the
additional archiving, etc., required), then from the user's perspective
what he would like to do is use short-lived keys and long-lived certificates.

Ignoring cryptanalytic attacks, zeroizing a key is the surest possible
way of protecting against a key compromise. So if a key management
system provides a way to automatically schedule a key for destruction
(or at least to remind the user to destroy it), that would be a Good Thing.

Once the key has been zeroized, from the user's perspective, and especially
from the Relying Party's perspective, the longer the certificate lifetime, the
better, since during the validity period it isn't necessary to have all of the
time stamped archives -- you can just query the CA to see whether
the key is still valid..  But from the CA's perspective, of course, this
isn't too good, because it increases the size of the CRL's.

[Tom Gindin]   This argument only applies to signing certificates, especially
NR, right?

Regards,

Bob

(P.S. -- this is a beta version of GroupWise 5.5 with S/MIME support.
If anyone notices anything wrong with the format, etc., please let
me know so we can fix it.)


Robert R. Jueneman
Security Architect
Network Security Development
Novell, Inc.
122 East 1700 South
Provo, UT 84606
[e-mail]
1-801-861-7387

>>> <[e-mail]> 08/20/99 10:12AM >>>
     Today, Private Key Usage Period is recommended against by RFC 2459 (section
4.2.1.4).  Given that most of the scenarios for NR require that certificates be
valid at the time when a signature is to be checked by a third party, which may
be long after the object is signed, shouldn't Private Key Usage Period be used
with NR certificates?

     A possible new wording would be:
     The Private Key Usage Period extension should only be present in
certificates which possess a keyUsage extension with the nonRepudiation bit of
that extension set.

     Similar, but weaker, arguments would apply to permitting this extension
when the keyCertSign bit is set as well, since certificates may also be valid
for a long time.

          Tom Gindin




--0__=oyhsLd76eBszZHvSKe2qARxIC6Eny8oyRwHESDyA43fCrt8KzRKfSLpx
Content-type: application/octet-stream; 
	name="Bob Jueneman.vcf"
Content-Disposition: attachment; filename="Bob Jueneman.vcf"
Content-transfer-encoding: base64

QkVHSU46VkNBUkQNClZFUlNJT046Mi4xDQpYLUdXVFlQRTpVU0VSDQpGTjpCb2IgSnVlbmVtYW4N
ClRFTDtXT1JLOjEtODAxLTg2MS03Mzg3LCAxLTgwMC00NTMtMTI2Nw0KT1JHOk5vdmVsbCwgSW5j
LjtOZXR3b3JrIFNlY3VyaXR5IERldmVsb3BtZW50DQpURUw7UFJFRjtGQVg6ODAxLTg2MS0yNTIy
DQpFTUFJTDtXT1JLO1BSRUY7TkdXOkJKVUVORU1BTkBub3ZlbGwuY29tDQpOOkp1ZW5lbWFuO1Jv
YmVydA0KVElUTEU6U2VjdXJpdHkgQXJjaGl0ZWN0DQpBRFI7SU5UTDtXT1JLO1BBUkNFTDtQT1NU
QUw6O1BSVi1GMzMxOzEyMiBFLiAxNzAwIFNvdXRoO1Byb3ZvO1V0YWg7ODQ2MDY7VVNBDQpMQUJF
TDtJTlRMO1dPUks7UEFSQ0VMO1BPU1RBTDtFTkNPRElORz1RVU9URUQtUFJJTlRBQkxFOkJvYiBK
dWVuZW1hbj0wQT0NClBSVi1GMzMxPTBBPQ0KMTIyIEUuIDE3MDAgU291dGg9MEE9DQpQcm92bywg
VXRhaCAgODQ2MDY9MEE9DQpVU0ENCkxBQkVMO0RPTTtXT1JLO1BBUkNFTDtQT1NUQUw7RU5DT0RJ
Tkc9UVVPVEVELVBSSU5UQUJMRTpCb2IgSnVlbmVtYW49MEE9DQpQUlYtRjMzMT0wQT0NCjEyMiBF
LiAxNzAwIFNvdXRoPTBBPQ0KUHJvdm8sIFV0YWggIDg0NjA2DQpURUw7SE9NRToxLTgwMS03NjUt
NDM3OA0KVEVMO0NFTEw6MS04MC0xLTM2MS0xNDEwDQpURUw7UFJFRjoxLTgwMS04NjEtNzM4Nywg
MS04MDAtNDUzLTEyNjcNClgtR1dVU0VSSUQ6QkpVRU5FTUFODQpFTkQ6VkNBUkQNCg0K

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

MIIJaQYJKoZIhvcNAQcCoIIJWjCCCVYCAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCCB6kw
ggMuMIICl6ADAgECAhEA0nYujRQMPX2yqCVdr+4NdTANBgkqhkiG9w0BAQIFADBfMQswCQYDVQQG
EwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xNzA1BgNVBAsTLkNsYXNzIDEgUHVibGljIFBy
aW1hcnkgQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkwHhcNOTgwNTEyMDAwMDAwWhcNMDgwNTEyMjM1
OTU5WjCBzDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0
IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEgSW5jb3Jw
LiBCeSBSZWYuLExJQUIuTFREKGMpOTgxSDBGBgNVBAMTP1ZlcmlTaWduIENsYXNzIDEgQ0EgSW5k
aXZpZHVhbCBTdWJzY3JpYmVyLVBlcnNvbmEgTm90IFZhbGlkYXRlZDCBnzANBgkqhkiG9w0BAQEF
AAOBjQAwgYkCgYEAu1pEigQWu1X9A3qKLZRPFXg2uA1Ksm+cVL+86HcqnbnwaLuV2TFBcHqBS7lI
E1YtxwjhhEKrwKKSq0RcqkLwgg4C6S/7wju7vsknCl22sDZCM7VuVIhPh0q/Gdr5FegPh7Yc48zG
mo5/aiSS4/zgZbqnsX7vyds3ashKyAkG5JkCAwEAAaN8MHowEQYJYIZIAYb4QgEBBAQDAgEGMEcG
A1UdIARAMD4wPAYLYIZIAYb4RQEHAQEwLTArBggrBgEFBQcCARYfd3d3LnZlcmlzaWduLmNvbS9y
ZXBvc2l0b3J5L1JQQTAPBgNVHRMECDAGAQH/AgEAMAsGA1UdDwQEAwIBBjANBgkqhkiG9w0BAQIF
AAOBgQCIuDc73dqUNwCtqp/hgQFxHpJqbS/28Z3TymQ43BuYDAeGW4UVag+5SYWklfEXfWe0fy0s
3ZpCnsM+tI6q5QsG3vJWKvozx74Z11NMw73I4xe1pElCY+zCphcPXVgaSTyQXFWjZSAA/Rgg5V+C
prGoksVYasGNAzzrw80FopCubjCCBHMwggPcoAMCAQICEF6mQzFngv6Wl+eGgC1QPt4wDQYJKoZI
hvcNAQEEBQAwgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBU
cnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIElu
Y29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENB
IEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQwHhcNOTkwNTExMDAw
MDAwWhcNMDAwNTEwMjM1OTU5WjCCARcxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQL
ExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9z
aXRvcnkvUlBBIEluY29ycC4gYnkgUmVmLixMSUFCLkxURChjKTk4MR4wHAYDVQQLExVQZXJzb25h
IE5vdCBWYWxpZGF0ZWQxNDAyBgNVBAsTK0RpZ2l0YWwgSUQgQ2xhc3MgMSAtIE1pY3Jvc29mdCBG
dWxsIFNlcnZpY2UxGDAWBgNVBAMUD1JvYmVydCBKdWVuZW1hbjEjMCEGCSqGSIb3DQEJARYUYmp1
ZW5lbWFuQG5vdmVsbC5jb20wgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBANW8HQNToKMy+VNz
L0IEq3SoWmSY2Qlsut0sMwe3fwzJR9DglDQApUf13tJZdU48ZNzRC16QkZs8nFM2gCyFAAv4QhfA
kYymhVqjrBiuNTs7K3O30W0ok6Nv6v/aokHIU6tAzLLuBMuayuN7sS58FDfcXwBvabN/ePIamR40
aQN5AgMBAAGjggEGMIIBAjAJBgNVHRMEAjAAMIGsBgNVHSAEgaQwgaEwgZ4GC2CGSAGG+EUBBwEB
MIGOMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vQ1BTMGIGCCsGAQUFBwIC
MFYwFRYOVmVyaVNpZ24sIEluYy4wAwIBARo9VmVyaVNpZ24ncyBDUFMgaW5jb3JwLiBieSByZWZl
cmVuY2UgbGlhYi4gbHRkLiAoYyk5NyBWZXJpU2lnbjARBglghkgBhvhCAQEEBAMCB4AwMwYDVR0f
BCwwKjAooCagJIYiaHR0cDovL2NybC52ZXJpc2lnbi5jb20vY2xhc3MxLmNybDANBgkqhkiG9w0B
AQQFAAOBgQBhbRmCI9CSHD2vYJOyQ9JsQ8NKDmTAKUY4qNwGXfsQcE+Wtr/vvhllfHscQ/JY4GM0
dvR2rYEq/I6nMk5Unlju527qbQYsVoA4FqRdcl1tGQRwBSsSPMS7qTmbnyujc1PA5dEjQRu9VVNj
pDiDc3nAcWFeb7SpjVmqzav5opJvizGCAYgwggGEAgEBMIHhMIHMMRcwFQYDVQQKEw5WZXJpU2ln
biwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZl
cmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFI
MEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29u
YSBOb3QgVmFsaWRhdGVkAhBepkMxZ4L+lpfnhoAtUD7eMAkGBSsOAwIaBQAwDQYJKoZIhvcNAQEB
BQAEgYAGRnr1NzX+dpjYJ0oLRF2dvaGJZPH4AwOldeiN89NqkM0CjSzJShoiEDRnuV0yyc8FwJ4m
AlUp3/LwyuRYSnGiGb/T90bFxVXOcWE4jXQZ7gin0i+VRg5zUgoMOCUCmedAFy1EzXwxc9bqak8l
MOGCqzmUBNzM+r7O/hDXRRqV8w==

--0__=oyhsLd76eBszZHvSKe2qARxIC6Eny8oyRwHESDyA43fCrt8KzRKfSLpx--



Received: from poptop.llnl.gov (poptop.llnl.gov [128.115.18.65]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id OAA06517 for <[e-mail]>; Fri, 20 Aug 1999 14:45:25 -0700 (PDT)
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 OAA17681; Fri, 20 Aug 1999 14:46:30 -0700 (PDT)
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.3 (32)
Date: Fri, 20 Aug 1999 14:46:22 -0700
To: "tog" <[e-mail]>, "Stephen Kent" <[e-mail]>
From: Tony Bartoletti <[e-mail]>
Subject: Re: To Be, or NR To Be ...
Cc: <[e-mail]>
In-Reply-To: <036901beeb4e$9455cce0$[e-mail]>
References: <v04020a16b3df92b9f0bd@[128.89.0.110]> <[e-mail]> <v04020a0db3df6342c8eb@[128.89.0.110]> <[e-mail]> <v04020a00b3e0715c457c@[128.89.0.110]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"

At 01:57 PM 8/20/99 -0700, tog wrote:

[snip]
>> >But the entire discussion is still confused, I believe, by the often
>> >unspoken distinction between "repudiating that you took some action"
>> >versus "repudiating that you did so intentionally, understood your
>> >exposure to liability, etc."
>>
>> Agreed.
>
>Actually the agrument seems to be based in whether the NR bit is a protocol
>flag to the application or for use within the protocol itself as part of the
>protocol process.
>
>>
>
>Todd

Agree also.  But since the cert is just another signed object, the
application layer is free to read it as well, or to listen to a provided
protocol flag.  At either level, it would be better to have a more
specific intent for the bit.  And unless its intent is better specified,
there will always wage debate over which layer is the intended endpoint.

___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 mail.proper.com (8.9.3/8.9.3) with ESMTP id OAA06127 for <[e-mail]>; Fri, 20 Aug 1999 14:23:18 -0700 (PDT)
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 OAA06809; Fri, 20 Aug 1999 14:24:28 -0700 (PDT)
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.3 (32)
Date: Fri, 20 Aug 1999 14:24:20 -0700
To: Stephen Kent <[e-mail]>, "Peter Williams" <[e-mail]>
From: Tony Bartoletti <[e-mail]>
Subject: RE: To Be, or NR To Be ...
Cc: <[e-mail]>
In-Reply-To: <v04020a0cb3e363e29bff@[128.89.0.110]>
References: <[e-mail]> <v04020a01b3e318d1f67a@[128.89.0.110]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"

At 04:12 PM 8/20/99 -0400, Stephen Kent wrote:
>Peter,
>
>Your long discussion of other asepcts of NR evidence for user sessions is
>consistent with my observation, and my rationale for NOT wanting to assert
>NR for such applications.

[snip]

>I beleive it is appropriate for this WG to stake a claim for the technical
>high ground in dealing with these issues, which translates into not
>endorsing use of the NR bit in these circumstances, and not modifying our
>technical, crypto-based definitions for NR.
>
>Steve

from 2459:

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

Steve,

What part of the above definition for the nonRepudiation bit implies
a technical, crypto-based definition for NR?  And what exactly is a/the
crypto-based definition for NR, aside from DigSig-Strength-Authentication?

I think the sub-phrase:

  "protects against the signing entity falsely denying some action"

is poor.  First, I would drop "falsely", since that is merely added
as a gratuitous "for instance, falsely".  Second, there needs to be a
clarification for what is meant by "some action".  In particular, it
should mean either "the act of having knowingly signed" or it should
mean "the intent to be bound to the terms contained under signature".
It should not be "take your pick".

If one or the other were settled upon, I think developers would have
a much better time forging software that enforces usage consistently,
(because sponsors could be more clear about the intended usage in the
software requirements.)

Otherwise, another bit is needed.

___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 po1.bbn.com (PO1.BBN.COM [192.1.50.38]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id OAA05958 for <[e-mail]>; Fri, 20 Aug 1999 14:20:53 -0700 (PDT)
Received: from [128.89.0.110] (COSMEC.BBN.COM [128.89.0.110]) by po1.bbn.com (8.9.1/8.9.1) with ESMTP id RAA10444; Fri, 20 Aug 1999 17:22:01 -0400 (EDT)
Mime-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
X-Sender: [e-mail]
Message-Id: <v04020a0eb3e370cfa5c4@[128.89.0.110]>
In-Reply-To: <[e-mail]>
References: <v04020a01b3e318d1f67a@[128.89.0.110]>
Date: Fri, 20 Aug 1999 17:17:25 -0400
To: "Peter Williams" <[e-mail]>
From: Stephen Kent <[e-mail]>
Subject: some comments on ISPs, wiretaps, etc.
Cc: <[e-mail]>
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by mail.proper.com id OAA05959

Peter,

>We know from US law, that CALEA-enforced ISP collection
>of packets represents effective timestamped records; and these
>include the cleartext initial handshake messages of the
>SSL connection establishment procedure. Nothing in ISO
>NR definitions requires timestamping be a cryptographic
>process; only that the binding of records/packets to time is
>assured. Pen-trap evidence has long relied upon the assurances
>of telephone company records, and (now) ISP records of packet
>flow/content, to bind time to peoples location and intent
>to communicate with another. Warrants may be required
>for the session content, but the cleartext connection data
>records are available without so much as a hassle.

There are a number of technical detail errors in the above paragraph.
First, CALEA in not in force yet.  Second, the terminology is
"pen-register" and "trap and trace."  Third, a warrant is required for this
sort of monitoring, but it is an easier warrant to get than the title III
warrant required for monitoring content.  Also, a title 3 warrant is very
hard to get and may be issued only for felonies enumerated in a list that
is very small.  For example, just breaking into a gov computer won't get a
judge to sign a title 3 warrant.  Then, of course, there are FISA warrants,
...

>On this basis, the initial packet of the SSL handshake
>procedure is effectively timestamped, TODAY; the 180 day records
>backup-capability obligation faced by American ISPs also provides
>infrastructure for effective data archival, for long-term NR
>records. The cryptographic security of the SSL handshake ensures
>that all SSL messages in the handshake protocol are
>irrefutably bound to a unique instance of the procedure, and
>the first record in that sequence is timestamped by
>the ISP, to all intents and purposes. The crypto process built
>into the handshake’s challenge-response of course provides assurance
>that the resulting agreement to SSL-conect is proof of a
>SSL-connection event. The potential NR services and
>required assurances derive from the trustworthy
>records environment, as described, as one would expect
>of any NR service option.

We are an American ISP and we DO NOT maintain a 180-day record of anything
more than some very minimal dial up access data items, NOT content. (I
verified my suspicion on this by checking with the folks who are
responsible for our operational security.)  Also, we do this only in our
role as a merchant, selling dialup access, in case of credit card
dispuites.  I'm not sure who you were thinking of here.  Maybe AOL, a
content provider, not an ISP?

> For both IPsec and SSL (with client certs), a user who is
>> successfully authenticated and granted access to a system must
>> have been an
>> authorized user at some time.
>
>This is a systems/communication usage of security, possibly
>requiring NR benefits. But this is not our concern, in this
>bind/login thread.  We are concerned merely with the undeniable
>“event” of binding ; the “I was undeniably here”, doctrine.
>This event is the foundation of trespass on networks, information
>or other property. By definition, if you trespass, you
>are not authorized; you may still be identified, however. And it is
>this implied lack of authorization, WITH strong
>identification, that one  seeks in the form of irrefutable
>evidence, to pursue a network property trespass case.

A user employing a cert for ID will be rejected as a prospective accessor
or a system or network unless the authentication exchange is valid AND the
user is authorized by the system/network.  Attackers don't usually try to
gain access using their real IDs.  So, the case of interest seems to be an
authorized user who later denies having used the resource in question in an
unauthorized fashion.

>
>So, what good is evidence that the user did
>> log in at some time, if we can't establish what time the login took place?
>
>As we know, effective NR requires records, binding time
>to the messages. We know the means by which this
>is performed is outside the definition of
>proof-grade security services, and is not limited to
>PKI techniques. We know this time assurance is available
>to day for US Internet packets from ISP records. Other
>comemrcial techniques may also come along, from TTP ISPs - wherein
>user IP data flows pass within virtual IP tunnels
>whose own IPSEC AH headers convey authoriative current time
>asserted by the tunnel-provider’s TTP routers. The outer
>tunnel, and its stored packets, constitue the electronic
>records for the tunneled data.

Oh, give me a break!  Again, as an ISP, I can assue you that we do not
envision wasting precious router resources doing anything of this sort.

>> I worry about the transition from crypto-strong evidence that a login took
>> place, to evidence (based on procedural security and minimal technical
>> safeguards) that the login in question is tied to a session during which
>> something unlawful happened.  I don't like to give technical
>> credibility to
>> the overall process when we know that there is a big disconnect
>> between the
>> potentially non-repudiable login vs. the audit trail that follows. This
>> sort of analysis underlies my contention that security protocols designed
>> for login do not necessarily contain the features we would want for NR.
>
>We must disgaree on this fun topic, and its at the model
>level. You evidently continue to concentrate on the resulting
>session, not the connection event. Trespass is concerned with
>the initial connection “event” (which is apparently not subject
>to 4th Amendment protections in the US.) This initial event
>may be the illegal or tortuous act, and accountability thereto
>requires no system-oriented audit trail or other
>session-data handling. What damage was done
>in the session is irrelevant, nor is the evidence (or lack
>thereof) relevant to a application layer-entity strong
>binding procedure (otherwise known as
>user/network login). You were there, and you
>were not supposed to be! What you did there,
>with or without authorization, is irrelevant
>for trespass.

See my note above, i.e., tresspassers don't use their own names when
trespassing!

>>
>> I agree with the notion that use of extended key usage bits can provide
>> better specification of the context in which a cert is intended
>> to be used.
>> That's precisely the reason for having this extension. I'm not
>> sure that we
>> have enough evidence yet to mandate such use, and it may be preferable to
>> leave this decision to the relevant application WGs.
>
>I am happy with this delegation of authority to other WGs,
>and private IP-application makers, by normal extension. I would
>ask that PKIX, in the  next 2459 revision, if any, remove any
>prohibition or advice against use of of the NR bit in application
>WGs, including those leveraging IKE or SSL/TLS. Should IPSEC+APP WG define a
>VPN network application relying upon the IKE handshake in the course
>of a layer-7 (ACSE-like) connection procedure, and define
>use of the NR bit, the PKIX standards should not stand in
>the way, or assert an authoritative position.

We'll see.

>>
>> In the specific case of the Authenticode example, I agree that it might be
>> reasonable to amend 2459 to allow the NR bit to be set as well as the DS
>> bit.
>
>This was discussed before, and the list agreed with
>my assertion then, as you evidently do now. Unaccountable
>offline msgs got the bit removed, presumably.

I don't recall that "the list agreed" on this topic, but then the length of
many of your messages precludes reading them to the end :-).  If the 2459
authors agree, then we're OK.

Steve


Received: from prv-mail20.provo.novell.com (prv-mail20.provo.novell.com [137.65.82.195]) by mail.proper.com (8.9.3/8.9.3) with SMTP id NAA05571 for <[e-mail]>; Fri, 20 Aug 1999 13:53:50 -0700 (PDT)
From: [e-mail]
Message-Id: <[e-mail]>
Received: from INET-PRV-Message_Server by prv-mail20.provo.novell.com with Novell_GroupWise; Fri, 20 Aug 1999 14:54:34 -0600
Mime-version: 1.0
Date: Fri, 20 Aug 1999 14:54:00 -0600
X-Mailer: Groupwise 5.5.2.1 (Beta)
Subject: Re: NR and Private Key Usage Period
To: "[e-mail]", [e-mail]
Content-type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="____ABOZVOANFSIBPQEMFNXT____"

--____ABOZVOANFSIBPQEMFNXT____
Content-type: multipart/mixed; boundary="____YRAVWPHZSVVDQNAOAEBW____"


--____YRAVWPHZSVVDQNAOAEBW____
Content-type: text/plain; charset=iso-8859-1
Content-disposition: inline

Tom,

Unless I read your message too quickly, to my way of thinking 
you have this exactly backwards.  The Private Key Usage
period was supposed to be shorter than, not longer than the
certificate validity.

If the current definition of NR means anything at all (which
isn't clear), then I would submit that it PROBABLY means that
that the signature is intended to endure and still be considered
valid long AFTER the certificate has been expired, or even 
been revoked, so long as it can be established that it was valid
at the time of signing, e.g., with OCSP, CRLs plus notarized timestamps,
Papal archives, or whatever.

There is virtually no reason I can think of why the Private Key Usage
should extend beyond the expiration date of the certificate -- 
that just increases the risk of compromise with no concomitant
benefit.

What the Private Key Validity period should do, and the reason why 
I am still opposed to deprecating it, is to set a time after which a signature
which was apparently created using a key that was supposedly zeroized
should be looked at with considerable scepticism, to say the least.

(For those who may have tuned in late -- the fact that a certificate has 
expired or even been revoked does NOT ipso facto mean that the 
signature is not legally binding -- it just means that it may be
more difficult to prove.)

Assuming that keys and certificates are relatively inexpensive, but that
validation of a signature once the certificate has expired is considerably 
more expensive than during the validity period (because of the 
additional archiving, etc., required), then from the user's perspective
what he would like to do is use short-lived keys and long-lived certificates.

Ignoring cryptanalytic attacks, zeroizing a key is the surest possible 
way of protecting against a key compromise. So if a key management 
system provides a way to automatically schedule a key for destruction
(or at least to remind the user to destroy it), that would be a Good Thing.

Once the key has been zeroized, from the user's perspective, and especially
from the Relying Party's perspective, the longer the certificate lifetime, the 
better, since during the validity period it isn't necessary to have all of the 
time stamped archives -- you can just query the CA to see whether 
the key is still valid..  But from the CA's perspective, of course, this 
isn't too good, because it increases the size of the CRL's.


Regards,

Bob

(P.S. -- this is a beta version of GroupWise 5.5 with S/MIME support.  
If anyone notices anything wrong with the format, etc., please let 
me know so we can fix it.)


Robert R. Jueneman
Security Architect
Network Security Development
Novell, Inc.
122 East 1700 South
Provo, UT 84606
[e-mail]
1-801-861-7387

>>> <[e-mail]> 08/20/99 10:12AM >>>
     Today, Private Key Usage Period is recommended against by RFC 2459 (section
4.2.1.4).  Given that most of the scenarios for NR require that certificates be
valid at the time when a signature is to be checked by a third party, which may
be long after the object is signed, shouldn't Private Key Usage Period be used
with NR certificates?

     A possible new wording would be:
     The Private Key Usage Period extension should only be present in
certificates which possess a keyUsage extension with the nonRepudiation bit of
that extension set.

     Similar, but weaker, arguments would apply to permitting this extension
when the keyCertSign bit is set as well, since certificates may also be valid
for a long time.

          Tom Gindin



--____YRAVWPHZSVVDQNAOAEBW____
Content-type: text/x-vcard; charset=iso-8859-1; name="Bob Jueneman.vcf"
Content-transfer-encoding: quoted-printable
Content-id: <RAFXRPTHZUVAJIVULZFZ>
Content-disposition: attachment; filename="Bob Jueneman.vcf";
	modification-date="Fri, 20 Aug 1999 14:54:15 -0600"

BEGIN:VCARD
VERSION:2.1
X-GWTYPE:USER
FN:Bob Jueneman
TEL;WORK:1-801-861-7387, 1-800-453-1267
ORG:Novell, Inc.;Network Security Development
TEL;PREF;FAX:[phone]
EMAIL;WORK;PREF;NGW:[e-mail]
N:Jueneman;Robert
TITLE:Security Architect
ADR;INTL;WORK;PARCEL;POSTAL:;PRV-F331;122 E. 1700 South;Provo;Utah;84606;US=
A
LABEL;INTL;WORK;PARCEL;POSTAL;ENCODING=3DQUOTED-PRINTABLE:Bob 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:Bob 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-80-1-361-1410
TEL;PREF:1-801-861-7387, 1-800-453-1267
X-GWUSERID:BJUENEMAN
END:VCARD


--____YRAVWPHZSVVDQNAOAEBW____--

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

MIIJaQYJKoZIhvcNAQcCoIIJWjCCCVYCAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCCB6kw
ggMuMIICl6ADAgECAhEA0nYujRQMPX2yqCVdr+4NdTANBgkqhkiG9w0BAQIFADBfMQswCQYDVQQG
EwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xNzA1BgNVBAsTLkNsYXNzIDEgUHVibGljIFBy
aW1hcnkgQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkwHhcNOTgwNTEyMDAwMDAwWhcNMDgwNTEyMjM1
OTU5WjCBzDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0
IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEgSW5jb3Jw
LiBCeSBSZWYuLExJQUIuTFREKGMpOTgxSDBGBgNVBAMTP1ZlcmlTaWduIENsYXNzIDEgQ0EgSW5k
aXZpZHVhbCBTdWJzY3JpYmVyLVBlcnNvbmEgTm90IFZhbGlkYXRlZDCBnzANBgkqhkiG9w0BAQEF
AAOBjQAwgYkCgYEAu1pEigQWu1X9A3qKLZRPFXg2uA1Ksm+cVL+86HcqnbnwaLuV2TFBcHqBS7lI
E1YtxwjhhEKrwKKSq0RcqkLwgg4C6S/7wju7vsknCl22sDZCM7VuVIhPh0q/Gdr5FegPh7Yc48zG
mo5/aiSS4/zgZbqnsX7vyds3ashKyAkG5JkCAwEAAaN8MHowEQYJYIZIAYb4QgEBBAQDAgEGMEcG
A1UdIARAMD4wPAYLYIZIAYb4RQEHAQEwLTArBggrBgEFBQcCARYfd3d3LnZlcmlzaWduLmNvbS9y
ZXBvc2l0b3J5L1JQQTAPBgNVHRMECDAGAQH/AgEAMAsGA1UdDwQEAwIBBjANBgkqhkiG9w0BAQIF
AAOBgQCIuDc73dqUNwCtqp/hgQFxHpJqbS/28Z3TymQ43BuYDAeGW4UVag+5SYWklfEXfWe0fy0s
3ZpCnsM+tI6q5QsG3vJWKvozx74Z11NMw73I4xe1pElCY+zCphcPXVgaSTyQXFWjZSAA/Rgg5V+C
prGoksVYasGNAzzrw80FopCubjCCBHMwggPcoAMCAQICEF6mQzFngv6Wl+eGgC1QPt4wDQYJKoZI
hvcNAQEEBQAwgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBU
cnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIElu
Y29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENB
IEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQwHhcNOTkwNTExMDAw
MDAwWhcNMDAwNTEwMjM1OTU5WjCCARcxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQL
ExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9z
aXRvcnkvUlBBIEluY29ycC4gYnkgUmVmLixMSUFCLkxURChjKTk4MR4wHAYDVQQLExVQZXJzb25h
IE5vdCBWYWxpZGF0ZWQxNDAyBgNVBAsTK0RpZ2l0YWwgSUQgQ2xhc3MgMSAtIE1pY3Jvc29mdCBG
dWxsIFNlcnZpY2UxGDAWBgNVBAMUD1JvYmVydCBKdWVuZW1hbjEjMCEGCSqGSIb3DQEJARYUYmp1
ZW5lbWFuQG5vdmVsbC5jb20wgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBANW8HQNToKMy+VNz
L0IEq3SoWmSY2Qlsut0sMwe3fwzJR9DglDQApUf13tJZdU48ZNzRC16QkZs8nFM2gCyFAAv4QhfA
kYymhVqjrBiuNTs7K3O30W0ok6Nv6v/aokHIU6tAzLLuBMuayuN7sS58FDfcXwBvabN/ePIamR40
aQN5AgMBAAGjggEGMIIBAjAJBgNVHRMEAjAAMIGsBgNVHSAEgaQwgaEwgZ4GC2CGSAGG+EUBBwEB
MIGOMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vQ1BTMGIGCCsGAQUFBwIC
MFYwFRYOVmVyaVNpZ24sIEluYy4wAwIBARo9VmVyaVNpZ24ncyBDUFMgaW5jb3JwLiBieSByZWZl
cmVuY2UgbGlhYi4gbHRkLiAoYyk5NyBWZXJpU2lnbjARBglghkgBhvhCAQEEBAMCB4AwMwYDVR0f
BCwwKjAooCagJIYiaHR0cDovL2NybC52ZXJpc2lnbi5jb20vY2xhc3MxLmNybDANBgkqhkiG9w0B
AQQFAAOBgQBhbRmCI9CSHD2vYJOyQ9JsQ8NKDmTAKUY4qNwGXfsQcE+Wtr/vvhllfHscQ/JY4GM0
dvR2rYEq/I6nMk5Unlju527qbQYsVoA4FqRdcl1tGQRwBSsSPMS7qTmbnyujc1PA5dEjQRu9VVNj
pDiDc3nAcWFeb7SpjVmqzav5opJvizGCAYgwggGEAgEBMIHhMIHMMRcwFQYDVQQKEw5WZXJpU2ln
biwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZl
cmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFI
MEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29u
YSBOb3QgVmFsaWRhdGVkAhBepkMxZ4L+lpfnhoAtUD7eMAkGBSsOAwIaBQAwDQYJKoZIhvcNAQEB
BQAEgYAGRnr1NzX+dpjYJ0oLRF2dvaGJZPH4AwOldeiN89NqkM0CjSzJShoiEDRnuV0yyc8FwJ4m
AlUp3/LwyuRYSnGiGb/T90bFxVXOcWE4jXQZ7gin0i+VRg5zUgoMOCUCmedAFy1EzXwxc9bqak8l
MOGCqzmUBNzM+r7O/hDXRRqV8w==

--____ABOZVOANFSIBPQEMFNXT____--


Received: from meridianus.com (209.249.223.26.has.no.reverse [209.249.223.26] (may be forged)) by mail.proper.com (8.9.3/8.9.3) with ESMTP id NAA05250 for <[e-mail]>; Fri, 20 Aug 1999 13:40:43 -0700 (PDT)
Received: from PC1 by meridianus.com (8.8.8+Sun/SMI-SVR4) id OAA00629; Fri, 20 Aug 1999 14:35:32 -0700 (PDT)
Message-ID: <036901beeb4e$9455cce0$[e-mail]>
From: "tog" <[e-mail]>
To: "Tony Bartoletti" <[e-mail]>, "Stephen Kent" <[e-mail]>
Cc: <[e-mail]>
References: <v04020a16b3df92b9f0bd@[128.89.0.110]><[e-mail]><v04020a0db3df6342c8eb@[128.89.0.110]><[e-mail]> <v04020a00b3e0715c457c@[128.89.0.110]>
Subject: Re: To Be, or NR To Be ...
Date: Fri, 20 Aug 1999 13:57:09 -0700
Organization: Meridianus
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.2918.2701
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2918.2701

----- Original Message -----
From: Stephen Kent <[e-mail]>
To: Tony Bartoletti <[e-mail]>
Cc: <[e-mail]>
Sent: Wednesday, August 18, 1999 7:25 AM
Subject: Re: To Be, or NR To Be ...


> Tony,
>
> >I don't claim to be expert on all the existing protocols.  But certainly
> >there could arise protocols that provide for crypto-strength throughout.
> >In such a case, it would seem that an "NR-authentication" might be
required
> >at the outset of the session, else the chain has no anchors.
>
> Usually, we provide NR only in the context of a specific application,
> because the semantics of the application are an important part of NR.
> Since one does all sorts of things during a "login session" it may be less
> appropriate to suppoort NR at the Telnet level.  However, I don't dispute
> your suggestion that it might be possible to fashion NR at this
granularity.
>
> >But the entire discussion is still confused, I believe, by the often
> >unspoken distinction between "repudiating that you took some action"
> >versus "repudiating that you did so intentionally, understood your
> >exposure to liability, etc."
>
> Agreed.

Actually the agrument seems to be based in whether the NR bit is a protocol
flag to the application or for use within the protocol itself as part of the
protocol process.

>

Todd




Received: from poptop.llnl.gov (poptop.llnl.gov [128.115.18.65]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id NAA05042 for <[e-mail]>; Fri, 20 Aug 1999 13:32:06 -0700 (PDT)
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 NAA10477; Fri, 20 Aug 1999 13:33:18 -0700 (PDT)
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.3 (32)
Date: Fri, 20 Aug 1999 13:33:10 -0700
To: Paul Koning <[e-mail]>
From: Tony Bartoletti <[e-mail]>
Subject: Re: FW: Is this non-repudiation or NR, and why?
Cc: [e-mail]
In-Reply-To: <[e-mail]>
References: <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"

At 03:33 PM 8/20/99 -0400, Paul Koning wrote:
>>>>>> "Tony" == Tony Bartoletti <[e-mail]> writes:
>
> Tony> All, There is a central point to this debate.  There appears to
> Tony> be two distinct positions held, in particular to the meaning
> Tony> "NR-bit NOT SET".
>
> Tony> Strength 0f Intent: Some say this means "I signed it, I
> Tony> intended to sign it, but I do not intend its use beyond pure
> Tony> authentication of data and sender, and that specifically *I* am
> Tony> not signalling assent to be legally/contractually bound by any
> Tony> terms contained in the data."
>
> Tony> Strength Of Key-Binding: Others say it means "I may not have
> Tony> signed it.  The key protections for this key do not warrant any
> Tony> presumption that its use is restricted to the individual given
> Tony> as the certified owner."  Its not a "strong-enough" key for the
> Tony> purposes of NR.
>
> Tony> Clearly, these two meanings are WORLDS apart, and cannot both
> Tony> be called "the meaning of NR-bit NOT SET".
>
>Agreed.
>
>In addition, the second interpretation seems to have no value at all.
>It says, in effect "don't assume you're talking to the supposed owner
>of this key".  In other words, "don't use this message for
>authentication purposes either".
>
>If it doesn't do NR and it doesn't do authentication, what does it do?
>
>	paul

Paul,

In general, I agree.  But some have posited having a key identify a
"group" or "role", rather than an individual.  Perhaps they envision
"NR=0" to mean, loosely, "not resolvable to an individual."

___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 po1.bbn.com (PO1.BBN.COM [192.1.50.38]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id NAA04729 for <[e-mail]>; Fri, 20 Aug 1999 13:11:12 -0700 (PDT)
Received: from [128.89.0.110] (COSMEC.BBN.COM [128.89.0.110]) by po1.bbn.com (8.9.1/8.9.1) with ESMTP id QAA02620; Fri, 20 Aug 1999 16:12:21 -0400 (EDT)
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
X-Sender: [e-mail]
Message-Id: <v04020a0cb3e363e29bff@[128.89.0.110]>
In-Reply-To: <[e-mail]>
References: <v04020a01b3e318d1f67a@[128.89.0.110]>
Date: Fri, 20 Aug 1999 16:12:21 -0400
To: "Peter Williams" <[e-mail]>
From: Stephen Kent <[e-mail]>
Subject: RE: To Be, or NR To Be ...
Cc: <[e-mail]>

Peter,

Your long discussion of other asepcts of NR evidence for user sessions is
consistent with my observation, and my rationale for NOT wanting to assert
NR for such applications.

If law enforcement is willing to rely on logs created by ISPs, system
operators, etc. as evidence of someone's activity, then they will continue
to do so irrespective of our technical recommendations re use of the NR
bit.  We know that the evidentiary mechanisms described in your message are
very much tamperable; they rely extensively, if not exclusively, on
physical, procedural, and personnel security of many individuals.  The
legal system can easily make use of the signed data from an SSL or IKE
exchange as part of this evidence, irrespective of whether the NR bit is
set.

I think it would be a mistake to grant the imprimatur of crypto-based NR to
this larger process by endorsing the use of the NR bit in these application
contexts.  We know better, in a technical context, and I think we ought to
take a stand here, distinguishing crypto-based NR in its most secure forms,
from other forms of NR evidence that can, by fiat, be used.

As an analogy, I cite the long held position of some in the banking
community that the service provided by a DES-MAC is NR. We all know that
either party to a transaction can create a MAC value that will pass as
genuine for traffic purportedly transmitted by the other party. Yes, the
use of two-party key control and audit logs at each end lend increased
credence to the claim that a logged MAC was really created by the other
party, but we have seen evidence of bank fraud on a larbe scale (remember
BCCI) and we know that multi-party authorization is not foolproof,
especially when tamperable computers are involved.

I beleive it is appropriate for this WG to stake a claim for the technical
high ground in dealing with these issues, which translates into not
endorsing use of the NR bit in these circumstances, and not modifying our
technical, crypto-based definitions for NR.

Steve


Received: from po1.bbn.com (PO1.BBN.COM [192.1.50.38]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id NAA04495 for <[e-mail]>; Fri, 20 Aug 1999 13:01:11 -0700 (PDT)
Received: from [128.89.0.110] (COSMEC.BBN.COM [128.89.0.110]) by po1.bbn.com (8.9.1/8.9.1) with ESMTP id QAA01251; Fri, 20 Aug 1999 16:02:18 -0400 (EDT)
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
X-Sender: [e-mail]
Message-Id: <v04020a0bb3e3639c8b5f@[128.89.0.110]>
In-Reply-To: <[e-mail]>
Date: Fri, 20 Aug 1999 15:58:17 -0400
To: Tony Bartoletti <[e-mail]>
From: Stephen Kent <[e-mail]>
Subject: Re: FW: Is this non-repudiation or NR, and why?
Cc: [e-mail]

Tony,

The second issue you raise is not just an NR issue, as it calls into
question other security aspects of the use of the private key.  I don't
consider the NR bit (not being asserted) to be a good way to address this
concern.

Steve


Received: from chi6-1.relay.mail.uu.net (chi6-1.relay.mail.uu.net [199.171.54.98]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id MAA04134 for <[e-mail]>; Fri, 20 Aug 1999 12:34:30 -0700 (PDT)
Received: from xedia.com by chi6sosrv11.alter.net with SMTP  (peer crosschecked as: madway.xedia.com [198.202.232.199]) id QQhdcw03149; Fri, 20 Aug 1999 19:35:34 GMT
Received: from tonga.xedia.com by xedia.com (4.1/SMI-4.1) id AA08622; Fri, 20 Aug 99 15:34:02 EDT
Received: by tonga.xedia.com (SMI-8.6/SMI-SVR4) id PAA20909; Fri, 20 Aug 1999 15:33:52 -0400
Date: Fri, 20 Aug 1999 15:33:52 -0400
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: FW: Is this non-repudiation or NR, and why?
References: <[e-mail]>
X-Mailer: VM 6.34 under 20.3 "Vatican City" XEmacs  Lucid

>>>>> "Tony" == Tony Bartoletti <[e-mail]> writes:

 Tony> All, There is a central point to this debate.  There appears to
 Tony> be two distinct positions held, in particular to the meaning
 Tony> "NR-bit NOT SET".

 Tony> Strength 0f Intent: Some say this means "I signed it, I
 Tony> intended to sign it, but I do not intend its use beyond pure
 Tony> authentication of data and sender, and that specifically *I* am
 Tony> not signalling assent to be legally/contractually bound by any
 Tony> terms contained in the data."

 Tony> Strength Of Key-Binding: Others say it means "I may not have
 Tony> signed it.  The key protections for this key do not warrant any
 Tony> presumption that its use is restricted to the individual given
 Tony> as the certified owner."  Its not a "strong-enough" key for the
 Tony> purposes of NR.

 Tony> Clearly, these two meanings are WORLDS apart, and cannot both
 Tony> be called "the meaning of NR-bit NOT SET".

Agreed.

In addition, the second interpretation seems to have no value at all.
It says, in effect "don't assume you're talking to the supposed owner
of this key".  In other words, "don't use this message for
authentication purposes either".

If it doesn't do NR and it doesn't do authentication, what does it do?

	paul


Received: from poptop.llnl.gov (poptop.llnl.gov [128.115.18.65]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id MAA03852 for <[e-mail]>; Fri, 20 Aug 1999 12:20:10 -0700 (PDT)
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 MAA08289 for <[e-mail]>; Fri, 20 Aug 1999 12:21:24 -0700 (PDT)
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.3 (32)
Date: Fri, 20 Aug 1999 12:21:15 -0700
To: [e-mail]
From: Tony Bartoletti <[e-mail]>
Subject: Re: FW: Is this non-repudiation or NR, and why?
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"

All,

There is a central point to this debate.  There appears to be two
distinct positions held, in particular to the meaning "NR-bit NOT SET".

Strength 0f Intent:
Some say this means "I signed it, I intended to sign it, but I do not
intend its use beyond pure authentication of data and sender, and that
specifically *I* am not signalling assent to be legally/contractually
bound by any terms contained in the data."

Strength Of Key-Binding:
Others say it means "I may not have signed it.  The key protections for
this key do not warrant any presumption that its use is restricted to
the individual given as the certified owner."  Its not a "strong-enough"
key for the purposes of NR.

Clearly, these two meanings are WORLDS apart, and cannot both be called
"the meaning of NR-bit NOT SET".

Part of the confusion is that these two meanings are not entirely
unrelated.  It would make no sense to assert "assent to legal binding"
with a key that is weakly-held.  In a sense,

  weakly-held-key < strongly-held-key < strongly-intended-signature

and some want "NR-bit 0" to disavow only "strongly-intended-signature"
while others argue it disavows "strongly-held-key", which then takes
"strongly-intended-signature" down with it.

There are probably good arguments for both positions.  But it is
clear to me that there cannot be ambiguity as to which of these
two positions is being asserted.

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 ext-mail.valicert.com (ns1.valicert.com [63.65.221.10]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id LAA03387 for <[e-mail]>; Fri, 20 Aug 1999 11:35:41 -0700 (PDT)
Received: from int-mail.valicert.com (corporate-gw.valicert.com [63.65.221.2]) by ext-mail.valicert.com (8.9.3/8.9.3) with ESMTP id LAA04492; Fri, 20 Aug 1999 11:36:47 -0700 (PDT)
Received: from rsalaptop (1Cust96.tnt10.sfo3.da.uu.net [153.37.28.96]) by int-mail.valicert.com (8.9.3/8.9.3) with SMTP id LAA19299; Fri, 20 Aug 1999 11:36:08 -0700 (PDT)
From: "Peter Williams" <[e-mail]>
To: "Stephen Kent" <[e-mail]>
Cc: <[e-mail]>
Subject: RE: To Be, or NR To Be ...
Date: Fri, 20 Aug 1999 11:37:20 -0700
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 8bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
In-Reply-To: <v04020a01b3e318d1f67a@[128.89.0.110]>
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300

> -----Original Message-----
> From: Stephen Kent [mailto:[e-mail]]
> Sent: Friday, August 20, 1999 8:35 AM
> To: Peter Williams
> Cc: [e-mail]
> Subject: RE: To Be, or NR To Be ...
>
>
> Peter,
>
> I am leary of your suggestion wrt NR for logins. Which specific values in
> IKE and SSL protocol exchanges provide evidence of the time at which the
> exchange took place, i.e., distinguishing in a user verifiable fashion,
> which login instance the evidence pertains to?


We learned, from the differences in older and more modern ISO
definitions of (technical) NR, that there are communication-oriented
and event-oriented modes of NR. We are concerned here with the case of mere
login, or SSL or IKE connection-establishment more correctly.
We note that like of these are subject to pen-trap surveillance
laws in the  US, allowing for warrantless-surveillance of
traffic patterns and storage of the data.

The crypto handshake elements, and definition of connection, and the
point at which an SSL-connection is established in SSL/TLS
is clear; I assume IKE is as competent.

Absent an ability to
> establish which login session the evidence pertains to, the evidence
> merely supports the contention that the user in question executed a login
> at some point prior to the time at which the evidence was timestamped,
> right?

As we know, effective NR services requires that there be
timestamped records; the records collect together all the technical
data that would be used to (re-)validate the underlying
proof-grade security service.

We know from US law, that CALEA-enforced ISP collection
of packets represents effective timestamped records; and these
include the cleartext initial handshake messages of the
SSL connection establishment procedure. Nothing in ISO
NR definitions requires timestamping be a cryptographic
process; only that the binding of records/packets to time is
assured. Pen-trap evidence has long relied upon the assurances
of telephone company records, and (now) ISP records of packet
flow/content, to bind time to peoples location and intent
to communicate with another. Warrants may be required
for the session content, but the cleartext connection data
records are available without so much as a hassle.

On this basis, the initial packet of the SSL handshake
procedure is effectively timestamped, TODAY; the 180 day records
backup-capability obligation faced by American ISPs also provides
infrastructure for effective data archival, for long-term NR
records. The cryptographic security of the SSL handshake ensures
that all SSL messages in the handshake protocol are
irrefutably bound to a unique instance of the procedure, and
the first record in that sequence is timestamped by
the ISP, to all intents and purposes. The crypto process built
into the handshake’s challenge-response of course provides assurance
that the resulting agreement to SSL-conect is proof of a
SSL-connection event. The potential NR services and
required assurances derive from the trustworthy
records environment, as described, as one would expect
of any NR service option.

 For both IPsec and SSL (with client certs), a user who is
> successfully authenticated and granted access to a system must
> have been an
> authorized user at some time.

This is a systems/communication usage of security, possibly
requiring NR benefits. But this is not our concern, in this
bind/login thread.  We are concerned merely with the undeniable
“event” of binding ; the “I was undeniably here”, doctrine.
This event is the foundation of trespass on networks, information
or other property. By definition, if you trespass, you
are not authorized; you may still be identified, however. And it is
this implied lack of authorization, WITH strong
identification, that one  seeks in the form of irrefutable
evidence, to pursue a network property trespass case.


So, what good is evidence that the user did
> log in at some time, if we can't establish what time the login took place?

As we know, effective NR requires records, binding time
to the messages. We know the means by which this
is performed is outside the definition of
proof-grade security services, and is not limited to
PKI techniques. We know this time assurance is available
to day for US Internet packets from ISP records. Other
comemrcial techniques may also come along, from TTP ISPs - wherein
user IP data flows pass within virtual IP tunnels
whose own IPSEC AH headers convey authoriative current time
asserted by the tunnel-provider’s TTP routers. The outer
tunnel, and its stored packets, constitue the electronic
records for the tunneled data.

> I worry about the transition from crypto-strong evidence that a login took
> place, to evidence (based on procedural security and minimal technical
> safeguards) that the login in question is tied to a session during which
> something unlawful happened.  I don't like to give technical
> credibility to
> the overall process when we know that there is a big disconnect
> between the
> potentially non-repudiable login vs. the audit trail that follows. This
> sort of analysis underlies my contention that security protocols designed
> for login do not necessarily contain the features we would want for NR.

We must disgaree on this fun topic, and its at the model
level. You evidently continue to concentrate on the resulting
session, not the connection event. Trespass is concerned with
the initial connection “event” (which is apparently not subject
to 4th Amendment protections in the US.) This initial event
may be the illegal or tortuous act, and accountability thereto
requires no system-oriented audit trail or other
session-data handling. What damage was done
in the session is irrelevant, nor is the evidence (or lack
thereof) relevant to a application layer-entity strong
binding procedure (otherwise known as
user/network login). You were there, and you
were not supposed to be! What you did there,
with or without authorization, is irrelevant
for trespass.

>
> I agree with the notion that use of extended key usage bits can provide
> better specification of the context in which a cert is intended
> to be used.
> That's precisely the reason for having this extension. I'm not
> sure that we
> have enough evidence yet to mandate such use, and it may be preferable to
> leave this decision to the relevant application WGs.

I am happy with this delegation of authority to other WGs,
and private IP-application makers, by normal extension. I would
ask that PKIX, in the  next 2459 revision, if any, remove any
prohibition or advice against use of of the NR bit in application
WGs, including those leveraging IKE or SSL/TLS. Should IPSEC+APP WG define a
VPN network application relying upon the IKE handshake in the course
of a layer-7 (ACSE-like) connection procedure, and define
use of the NR bit, the PKIX standards should not stand in
the way, or assert an authoritative position.

>
> In the specific case of the Authenticode example, I agree that it might be
> reasonable to amend 2459 to allow the NR bit to be set as well as the DS
> bit.

This was discussed before, and the list agreed with
my assertion then, as you evidently do now. Unaccountable
offline msgs got the bit removed, presumably.


>
> Steve



Received: from poptop.llnl.gov (poptop.llnl.gov [128.115.18.65]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id KAA02715 for <[e-mail]>; Fri, 20 Aug 1999 10:48:54 -0700 (PDT)
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 KAA21491; Fri, 20 Aug 1999 10:50:04 -0700 (PDT)
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.3 (32)
Date: Fri, 20 Aug 1999 10:49:56 -0700
To: Elliot Ginsburg <[e-mail]>, [e-mail]
From: Tony Bartoletti <[e-mail]>
Subject: Re: FW: Is this non-repudiation or NR, and why?
In-Reply-To: <F19999D192F6D211AA1700207810B43403A583@SOLO>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"

At 09:50 AM 8/20/99 -0400, Elliot Ginsburg wrote:
>Lets look at the physical model we're trying to emulate.
>
>When I physically sign a piece of paper, my possible rebuttals are:
>	1) I didn't sign it (someone else did)	
>	2) I didn't know what I was signing
>	3) I was forced to sign
>Note that one the possibilities IS NOT that I don't consider my
>signature to mean anything. It always means, subject to rebuttal, that I
>physically created it; I was there, I knew what I was going, etc.
>Very often the thing signed defines the meaning of the signature, as in
>"I attest to...", "Approved by...", etc., and that is what my signature
>is an agreement to.

I agree.  There seems to be a use-focus to most of the discussion that
one is signing a "promise", hence NR attests to the validity of the
promise.

In contrast, if I were to send an email to someone containing a threat
to their life, and part of the evidence that points to me was my
digital signature on that email, I don't think the court will be
impressed when I demonstrate that the cert's NR-bit was not set,
so "I didn't intend to be held liable for the content."  That would
be ridiculous, because the "act-in-question" is the signed object
itself, not whether the promise/threat contained therein would,
in the future, be faithfully "executed" (sorry about that!)

___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 puma.baltimore.ie ([e-mail] [194.125.215.9]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id KAA02551; Fri, 20 Aug 1999 10:47:31 -0700 (PDT)
Received: by puma.baltimore.ie; id MAA28263; Tue, 17 Aug 1999 12:03:06 +0100 (GMT/IST)
Received: from bobcat.baltimore.ie(192.168.20.10) by puma.baltimore.ie via smap (4.1) id xma028182; Tue, 17 Aug 99 12:00:26 +0100
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 LAA31421; Tue, 17 Aug 1999 11:03:15 +0100
Received: from ocelot.baltimore.ie (afarrell@localhost [127.0.0.1]) by ocelot.baltimore.ie (8.8.7/8.8.7) with ESMTP id LAA27047; Tue, 17 Aug 1999 11:00:19 +0100
Message-Id: <[e-mail]>
To: Peter Siklosi <[e-mail]>
Cc: "John Hughes" <[e-mail]>, [e-mail], [e-mail], Darren Harter <[e-mail]>, [e-mail], [e-mail]
Date: Tue, 17 Aug 1999 11:00:19 +0100
From: Andrew Farrell <[e-mail]>

Fcc: +sent
Subject: Re: X9.42 and RFC2459 inconsistency? 
In-Reply-To: Your message of "Tue, 17 Aug 1999 11:26:55 +0200."
             <[e-mail]> 
--------
In message <[e-mail]>you write:
>Andrew,

>In the RFC2459, section 7.3.2, it says:

>   "The Diffie-Hellman OID supported by this profile is defined by ANSI X9.42"

>I am not sure what you mean by the "X9.42 oid with the pfc 2459 semantics".

What I said. The OID in RFC 2459 is taken from X9.42, but the semantics
specifed below are different to the ones specified in X9.42. In RFC
2459, the subjectPublicKey is a bitstring wrapping an encoded integer
which has the value of the public key. This is consistent with the
treatment of DSA and RSA, but contradicts X9.42, which specifies that
the subjectPublicKey is a bitstring which has the value of the public
key.

This is something that PKIX may have to push back on X9.42 on, so it's
not clear which will be the winning semantics.

Andrew.


Received: from letterbox.cs.auckland.ac.nz (letterbox.cs.auckland.ac.nz [130.216.35.1]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id KAA02137 for <[e-mail]>; Fri, 20 Aug 1999 10:20:48 -0700 (PDT)
Received: from kakapo.cs.auckland.ac.nz (kakapo.cs.auckland.ac.nz [130.216.34.10]) by letterbox.cs.auckland.ac.nz (8.8.6/8.8.6/cs-master) with ESMTP id FAA06398 for <[e-mail]>; Sat, 21 Aug 1999 05:21:53 +1200 (sender [e-mail])
Received: (from pgut001@localhost) by kakapo.cs.auckland.ac.nz (8.8.6/8.8.6/cs-slave) id FAA10712 for [e-mail]; Sat, 21 Aug 1999 05:21:47 +1200 (NZST) (sender [e-mail])
Date: Sat, 21 Aug 1999 05:21:47 +1200 (NZST)
Message-ID: <[e-mail]>
From: [e-mail] (Peter Gutmann)
To: [e-mail]
Subject: Re: NR and Private Key Usage Period

[e-mail] writes:

>Today, Private Key Usage Period is recommended against by RFC 2459 (section
>4.2.1.4).  Given that most of the scenarios for NR require that certificates 
>be valid at the time when a signature is to be checked by a third party, 
>which may be long after the object is signed, shouldn't Private Key Usage 
>Period be used with NR certificates?

It's needed not just with NR certs but with any certs (although it's 
especially necessary with NR certs) - typically you want to be able to sign 
now, but have the signature valid for a much longer time than the lifetime of
the private key.  What was the rationale behind deprecating PKUP?  I seem to
remember grumbling about this some time ago, I don't recall anyone being able
to provide any convincing argument for deprecating PKUP in RFC 2459.

Peter.


Received: from neodymium.btinternet.com (neodymium.btinternet.com [194.73.73.83]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id JAA01339 for <[e-mail]>; Fri, 20 Aug 1999 09:16:03 -0700 (PDT)
Received: from [195.99.55.30] (helo=dwc-acer) by neodymium.btinternet.com with smtp (Exim 2.05 #1) id 11HrLS-0006xE-00; Fri, 20 Aug 1999 17:16:47 +0100
From: "David Chadwick" <[e-mail]>
Organization: University of Salford
To: Stefan Santesson <[e-mail]>, Magnus =?iso-8859-1?Q?Nystr=F6m?= <[e-mail]>, [e-mail]
Date: Fri, 20 Aug 1999 17:15:27 +0100
MIME-Version: 1.0
Content-type: text/plain; charset=US-ASCII
Content-transfer-encoding: 7BIT
Subject: Re: Pseudonym in Subject DN (in QC certificates)
Reply-to: [e-mail]
Priority: normal
In-reply-to: <[e-mail]>
References: <048801bee9c7$30307b80$[e-mail]>
X-mailer: Pegasus Mail for Win32 (v3.01d)
Message-Id: <[e-mail]>

Stefan, Magnus

I quite like the idea of a pseudonym attribute type, since we then 
have proper semantics attached to the attribute value. Otherwise we 
leave it to the certificate user to infer that one value of common 
name is a pseudonym and another value is a real name. This is 
easy for values like "batman" but not for values like " John Smith". 
So if CAs are to issue certs for pseudonyms, let this be publicly 
stated by the pseudonym attribute type in the subject field.

David

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

David Chadwick
IS Institute, University of Salford, Salford M5 4WT
Tel [phone]  Fax [phone]
Mobile [phone]
*NEW* Email [e-mail] *NEW*
Home Page  http://www.salford.ac.uk/its024/chadwick.htm
Understanding X.500  http://www.salford.ac.uk/its024/X500.htm
X.500/LDAP Seminars http://www.salford.ac.uk/its024/seminars.htm
Entrust key validation string MLJ9-DU5T-HV8J

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


Received: from e1.ny.us.ibm.com (e1.ny.us.ibm.com [32.97.182.101]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id JAA01151 for <[e-mail]>; Fri, 20 Aug 1999 09:12:26 -0700 (PDT)
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 MAA123046 for <[e-mail]>; Fri, 20 Aug 1999 12:13:14 -0400
Received: from D51MTA05.pok.ibm.com (d51mta05.pok.ibm.com [9.117.200.33]) by northrelay02.pok.ibm.com (8.8.8m2/NCO v2.04) with SMTP id MAA148988 for <[e-mail]>; Fri, 20 Aug 1999 12:13:35 -0400
Received: by D51MTA05.pok.ibm.com(Lotus SMTP MTA v4.6.4  (830.2 3-23-1999))  id 852567D3.005921AB ; Fri, 20 Aug 1999 12:13:33 -0400
X-Lotus-FromDomain: IBMUS
To: [e-mail]
Message-ID: <[e-mail]>
Date: Fri, 20 Aug 1999 12:12:21 -0400
Subject: NR and Private Key Usage Period
Mime-Version: 1.0
Content-type: text/plain; charset=us-ascii
Content-Disposition: inline

     Today, Private Key Usage Period is recommended against by RFC 2459 (section
4.2.1.4).  Given that most of the scenarios for NR require that certificates be
valid at the time when a signature is to be checked by a third party, which may
be long after the object is signed, shouldn't Private Key Usage Period be used
with NR certificates?

     A possible new wording would be:
     The Private Key Usage Period extension should only be present in
certificates which possess a keyUsage extension with the nonRepudiation bit of
that extension set.

     Similar, but weaker, arguments would apply to permitting this extension
when the keyCertSign bit is set as well, since certificates may also be valid
for a long time.

          Tom Gindin




Received: from po1.bbn.com (PO1.BBN.COM [192.1.50.38]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id IAA00747 for <[e-mail]>; Fri, 20 Aug 1999 08:42:03 -0700 (PDT)
Received: from [128.89.0.110] (COSMEC.BBN.COM [128.89.0.110]) by po1.bbn.com (8.9.1/8.9.1) with ESMTP id LAA01172; Fri, 20 Aug 1999 11:43:03 -0400 (EDT)
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
X-Sender: [e-mail]
Message-Id: <v04020a01b3e318d1f67a@[128.89.0.110]>
In-Reply-To: <000001bee9b3$fd4b4960$[e-mail]>
References: <v04020a00b3e0715c457c@[128.89.0.110]>
Date: Fri, 20 Aug 1999 11:35:29 -0400
To: "Peter Williams" <[e-mail]>
From: Stephen Kent <[e-mail]>
Subject: RE: To Be, or NR To Be ...
Cc: <[e-mail]>

Peter,

I am leary of your suggestion wrt NR for logins. Which specific values in
IKE and SSL protocol exchanges provide evidence of the time at which the
exchange took place, i.e., distinguishing in a user verifiable fashion,
which login instance the evidence pertains to?  Absent an ability to
establish which login session the evidence pertains to, the evidence
merely supports the contention that the user in question executed a login
at some point prior to the time at which the evidence was timestamped,
right?  For both IPsec and SSL (with client certs), a user who is
successfully authenticated and granted access to a system must have been an
authorized user at some time. So, what good is evidence that the user did
log in at some time, if we can't establish what time the login took place?
I worry about the transition from crypto-strong evidence that a login took
place, to evidence (based on procedural security and minimal technical
safeguards) that the login in question is tied to a session during which
something unlawful happened.  I don't like to give technical credibility to
the overall process when we know that there is a big disconnect between the
potentially non-repudiable login vs. the audit trail that follows. This
sort of analysis underlies my contention that security protocols designed
for login do not necessarily contain the features we would want for NR.

I agree with the notion that use of extended key usage bits can provide
better specification of the context in which a cert is intended to be used.
That's precisely the reason for having this extension. I'm not sure that we
have enough evidence yet to mandate such use, and it may be preferable to
leave this decision to the relevant application WGs.

In the specific case of the Authenticode example, I agree that it might be
reasonable to amend 2459 to allow the NR bit to be set as well as the DS
bit.

Steve


Received: from solo.cygnacom.com (endor.cygnacom.com [205.177.169.102]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id GAA26528 for <[e-mail]>; Fri, 20 Aug 1999 06:44:05 -0700 (PDT)
Received: by SOLO with Internet Mail Service (5.0.1458.49) id <Q24NZ07Y>; Fri, 20 Aug 1999 09:50:56 -0400
Message-ID: <F19999D192F6D211AA1700207810B43403A583@SOLO>
From: Elliot Ginsburg <[e-mail]>
To: [e-mail]
Subject: FW: Is this non-repudiation or NR, and why?
Date: Fri, 20 Aug 1999 09:50:54 -0400
X-Priority: 3
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.0.1458.49)
Content-Type: text/plain

Lets look at the physical model we're trying to emulate.

When I physically sign a piece of paper, my possible rebuttals are:
	1) I didn't sign it (someone else did)	
	2) I didn't know what I was signing
	3) I was forced to sign
Note that one the possibilities IS NOT that I don't consider my
signature to mean anything. It always means, subject to rebuttal, that I
physically created it; I was there, I knew what I was going, etc.
Very often the thing signed defines the meaning of the signature, as in
"I attest to...", "Approved by...", etc., and that is what my signature
is an agreement to.

Whether or not this signed thing is sufficiently trustworthy is a
different question. We have rules for applying signatures which affect
its "strength": doesn't require a witness, required to be signed in
presence of other parties to agreement, requires notarization, etc.
These are determined by the participants in the transaction. For
example, my mutual fund company requires written requests witnessed by a
bank officer; they will not honor any other form of the request, even
though they will have a signed piece of paper. 

In other words, NR is authentication: my signature means, subject to
rebuttal, that I (and not someone else) agreed to whatever is implied in
that transaction, and the paper with my signature is evidence of that
(whether or not the evidence is sufficient or is accepted, it is
evidence). It is up to the participants in the transaction to make sure
that it will be sufficient evidence if contested.

The DS and NR bits are assertions of policy BY THE CA, of how, within
the scope of its use and according to policy, this cert can be used. A
CA might NOT set NR because the key is escrowed, or shared, or some
other reason, but it still offers data integrity within its scope of use
and according to the policies within that scope. For example, if the key
was escrowed, then it won't assert authentication (NR), but it will
assert data integrity because the handling of the key is trusted enough
for that. Another exampel, we're not careful enough with verifying WHO
in this organization really was registered, but we're sure they were
part of this organization. 

Another possibility for not asserting NR could be that this CA does not
sufficiently back-up/archive certs and CRLs so that it wouldn't be
possible to use it later for NR. 

We really should have a data integrity usage, and a NR/authentication
usage. And it seems to me that, by default, NR implies also data
integrity.

Elliott N Ginsburg
CygnaCom Solutions
[e-mail]
703-848-0883
703-848-0960(FAX)

> -----Original Message-----
> From:	Flanigan, Bill [SMTP:[e-mail]]
> Sent:	Friday, August 20, 1999 8:45 AM
> To:	'David P. Kemp'
> Cc:	[e-mail]
> Subject:	RE: Is this non-repudiation or NR, and why?
> 
> Dave,
> 
> 	Again, how do you define "technical non-repudiation"?  Thanks.
> 
> Bill
> 
> > ----------
> > From: 	David P. Kemp[SMTP:[e-mail]]
> > Reply To: 	David P. Kemp
> > Sent: 	Thursday, August 19, 1999 6:13 PM
> > To: 	[e-mail]
> > Subject: 	Re: Is this non-repudiation or NR, and why?
> > 
> [snip]
> 
> > I would like to see a request from the ABA that we cease and desist
> > using the term "technical non-repudiation" 
> > 
> [snip]


Received: from rbhub101.chamb.disa.mil (rbhub101.chamb.disa.mil [209.22.120.24]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id FAA22235 for <[e-mail]>; Fri, 20 Aug 1999 05:41:14 -0700 (PDT)
Received: by rbhub101.chamb.disa.mil with Internet Mail Service (5.5.2650.10) id <Q09DKRMG>; Fri, 20 Aug 1999 08:43:05 -0400
Message-ID: <[e-mail]>
From: "Flanigan, Bill" <[e-mail]>
To: "'David P. Kemp'" <[e-mail]>
Cc: [e-mail]
Subject: RE: Is this non-repudiation or NR, and why?
Date: Fri, 20 Aug 1999 08:45:23 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.10)
Content-Type: text/plain

Dave,

	Again, how do you define "technical non-repudiation"?  Thanks.

Bill

> ----------
> From: 	David P. Kemp[SMTP:[e-mail]]
> Reply To: 	David P. Kemp
> Sent: 	Thursday, August 19, 1999 6:13 PM
> To: 	[e-mail]
> Subject: 	Re: Is this non-repudiation or NR, and why?
> 
[snip]

> I would like to see a request from the ABA that we cease and desist
> using the term "technical non-repudiation" 
> 
[snip]


Received: from tomcat.sac.verio.net ([e-mail] [209.162.64.15]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id QAA17164 for <[e-mail]>; Thu, 19 Aug 1999 16:51:37 -0700 (PDT)
Received: from nma.com (pm06-32.sac.verio.net [209.162.64.239]) by tomcat.sac.verio.net (8.9.1a/8.9.1) with ESMTP id QAA18807; Thu, 19 Aug 1999 16:52:39 -0700 (PDT)
Message-ID: <[e-mail]>
Date: Thu, 19 Aug 1999 16:52:42 -0700
From: Ed Gerck <[e-mail]>
X-Mailer: Mozilla 4.61 [en]C-CCK-MCD {Sony}  (Win98; I)
X-Accept-Language: en
MIME-Version: 1.0
To: "Robert W. Shirey" <[e-mail]>
CC: PKIX <[e-mail]>, Nicholas Bohm <[e-mail]>
Subject: Re: Is this non-repudiation or NR, and why?
References: <[e-mail]> <v03110705b3e21ec90198@[192.233.50.129]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

"Robert W. Shirey" wrote:

> Ed,
>
> In your terms, what is this? And why is that?
>
> non-repudiation service
> -----------------------
> (I) A security service that provide protection against false denial of
> involvement in a communication. (Also see: repudiation.)

There is no mention of previous acceptance of non-repudiation liability by signer.
The word false in "false denial" either means intent or logic negation:

i. If it is logic negation than the service produces no information because the
denial was already known to be false.

ii. iIf it is intent then the service does not apply to a protocol that only deals
with applications, not users.

Further, the service does not say it provides what its name denotes --
non-repudiation -- rather, it provides "protection".

In conclusion, the above definition cannot be used to denote non-repudiation, because
of the above mentioned impeditive legal and technical reasons and also because
the service does not say it provides non-repudiation -- even though the service
bears the name of non-repudiation.

To contrast, compare with Menezes et al., in HAC, page 3:

"non-repudiation: preventing the denial of previous commitments or actions"

which is both legally and technically possible (as a function of how it is done)
and is in accord with the name -- non-repudiation. Note that there is no mention
of intent.

For your interest I set out below two clauses from a set of banking terms
recently published by a UK banking organisation for its online banking
business (thanks to Nicholas Bohm, CC'd).  It is typical of the
non-repudiation approach, although more lucid than many.   Note
that any expression of intent or cause are carefully avoided in the text
-- the form used is "until you tell us", where "why you are telling us" or
"what for you are telling us" is avoided.  Also, note the text "even if it
was not given by you" which is a characteristic of non-repudiation --
it is not subject to the proof finding method that you quoted; with
non-repudiation, a truthful denial can be thwarted by a legal
affirmation.

///////////////////////////////////////////////////////////////////////
3.1 We may establish security procedures with you either by post, telephone
or internet (when available).  You must keep your security details and
password secret.  If you make written records of any security details or
password, you must disguise them so that they cannot easily be understood
by anyone else.

3.2 You must tell us as soon as possible if:

you think that someone else knows your security details or password;

you have forgotten your security details or password;

you think that someone else (other than a joint account holder or
authorised person) is trying to use your account.

Until you tell us, you will be responsible for any instruction in writing
or by telephone or internet which we receive and act on, even if it was not
given by you.  Normally we will pay back into your account the amount of
any payments we make after you have told us.  But, if we can show that you
have acted fraudulently or have been grossly negligent or have not kept
your security details and password secret you will be responsible for all
payments we make and all losses on your account.  We will have no other
liability to you.
///////////////////////////////////////////////////////////////////////

Other banks are equally clear that the account holder is only liable
for non-repudiation when in fact they did give or authorize the
instruction to be held under non-repudiation liability (with no
presumption, rebuttable or otherwise). The point is that if I
don't have the power to deny a given capability in advance, it
really isn't non-repudiation -- it's just an option that I can't
control and hence can't be binding, since it isn't voluntary.

> (C) Non-repudiation service does not and cannot prevent an entity from
> repudiating a communication.  Instead, the service provides evidence that
> can be stored and later presented to a third party to resolve disputes that
> arise if and when a communication is repudiated by one of the entities
> involved.

The description itself says that this is not a non-repudiation service -- so,
there is hardly a doubt that the name is misplaced.

On the other hand, this is a service that collects  evidence of authentication
acts -- the system collects authentication proofs that will operate as evidence
to a resolver. The end result of the system are either evidences (if the
third-party is not included) or a decision based on what is essentially a
rebuttable presumption model.

Again, this is not a non-rebuttable presumption model that would be able to
provide for non-repudiation.

> There are two basic kinds of non-repudiation service:
>
>  - "Non-repudiation with proof of origin" provides the recipient of data
> with evidence that proves the origin of the data, and thus protects the
> recipient against an attempt by the originator to falsely deny sending the
> data. This service can be viewed as as a stronger version of an data origin
> authentication service, in that it proves authenticity to a third party.

Again, no claim is made to non-repudiation but its name.  The service
provides proof of origin authentication

>  - "Non-repudiation with proof of receipt" provides the originator of data
> with evidence that proves the data was received as addressed, and thus
> protects the originator against an attempt by the recipient to falsely deny
> receiving the data.

Ditto.  The service provides proof of receipt authentication.

> (C) Phases of a Non-Repudiation Service: [For94]'s discussion uses the term
> "critical action" to refer to the act of communication that is the subject
> of the service, which has five phases:
>
> --------   --------   --------  --------                 --------
> Phase 1:   Phase 2:   Phase 3:  Phase 4:                 Phase 5:
> Request    Generate   Store     Verify                   Resolve
> Service    Evidence   Evidence  Evidence                 Dispute
> --------   --------   --------  --------                 --------
>
> Service    Critical   Evidence  Evidence    Critical     Evidence
> Request => Action  => Is     => Is       => Action Is => Is
> Is Made    Occurs     Stored    Tested      Repudiated   Verified
>            and           |         ^                         ^
>            Evidence      v         |                         |
>            Is         +-------------------+                  |
>            Generated  |Verifiable Evidence|------------------+
>                       +-------------------+
>
> [For94] W. Ford, *Computer Communications Security: Principles, Standard
> Protocols and Techniques", ISBN 0-13-799453-2, 1994.

These phases apply for a rebuttable presumption model of validity. Not
for a non-rebuttable presumption model (ie, non-repudiation).

Just to highlight the basic difference, in "non-rebuttable presumption of validity"
or "irrebuttable presumption of validity" or "non-repudiation of validity",
the apparent signer is bound irrespective of the facts (including
proof of non-signing) that it may truthfully prove a posteriori.

But, how does non-repudiation work?

The relying-party has the (legal, technical, etc.) means to deny
the signer's affirmation that the signer did not produce the signature,
irrespective of whether the signer actually produced the signature or not,
or even had the intent to produce it or not, and based *solely* on the fact
that the relying-party could not distinguish the signature from a signature
that the signer did make when the non-repudiation liability was accepted
by the signer.

The relying-party's trust in what was apparently (but not in fact) that
signer's signature will therefore be held by law to be well-founded.
The signer's trust in the reliability of the systems concerned (i.e.,
the signer's trust that only a signature the signer produced will be
treated as binding on the signer) will be held by law to be ill-founded.

Why is non-repudiation useful?

For example, to afford a high-reliance open-loop authorization chain
-- where the signer considers useful to allow a trusted relying-party
to perform its orders with high-reliance and without calling back on
the signer for verification.

As another example, to afford a closed-loop authorization chain
that uses implicit non-repudiation -- as I commented in regard to
SET in a reply to Bob B.

Cheers,

Ed Gerck



Received: from mail-out2.apple.com (mail-out2.apple.com [17.254.0.51]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id QAA16970 for <[e-mail]>; Thu, 19 Aug 1999 16:45:09 -0700 (PDT)
Received: from mailgate2.apple.com ([17.129.100.225]) by mail-out2.apple.com (8.8.5/8.8.5) with ESMTP id QAA23160 for <[e-mail]>; Thu, 19 Aug 1999 16:46:20 -0700
Received: from scv4.apple.com (scv4.apple.com) by mailgate2.apple.com (Content Technologies SMTPRS 2.0.15) with ESMTP id <[e-mail]> for <[e-mail]>; Thu, 19 Aug 1999 16:45:55 -0700
Received: from [17.205.41.166] (aram1.apple.com [17.205.41.166]) by scv4.apple.com (8.9.3/8.9.3) with ESMTP id QAA25246 for <[e-mail]>; Thu, 19 Aug 1999 16:45:54 -0700
Message-Id: <[e-mail]>
X-Mailer: Microsoft Outlook Express Macintosh Edition - 4.5 (0410)
Date: Thu, 19 Aug 1999 16:45:46 -0700
Subject: Re: NR -- what the real issues are, and  a proposal
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

Bob J.,

Since I already repudiated my previous statement about not giving any more
comments on the NR issue, I'll give you my comments on your proposal ;-)

[snip]
> However, since many may want to skip the justification and cut t
> o the bottom line, I'll put the proposal up front, and then justify it:
>
> My proposal is that the text of the nonrepudiation key usage bit I
> n the PKIX RFC (and hopefully in X.509) be revised to unambiguously
> state that the defined semantics of this bit is to indicate the willingness
> of the subscriber to be legally bound by a digital signature which can be
> verified by a certificate that can be established to have been valid at the
> time of signature, where "valid" has the normal meaning of not expired, not
> revoked, etc., etc.

I would vote against this proposal because I think the NR bit should be
deprecated. Why? Because this bit has caused so many problems and
misunderstandings for at least "the last five years or so". Why is it that
no one argues about the other KeyUsage bits? I'll give my answer a bit
later. [I personally believe that there should only be three key usage bits:
digitalSignature, keyEncipherment (with the addition of keyAgreement) and
dataEncipherment. With the exception of NR, the rest are just "refinements"
of the three. But I can live with the current definition (except for NR).]

>
> In addition, I propose that we create an additional indicator of a
> human being's conscious and willful intent to be legally bound by
> a digital signature that would be applied on a message by message
> basis. This additional indicator would require, as an integral part of
> its semantic definition, that an explicit computer-to-human interaction
> be required to provide some reasonable level of ceremonial and due
> caution warning be provided to the user.

I partially agree up to here. My disagreement is in "an additional
indicator". I think there should be more than one indicator depending on
different circumstances and applications.  And to me, having a "ceremony"
implies application level code, not cryptographic engine code and certainly
not a bit in a certificate.

>  In addition, the semantics
> of this indicator should specify that its use must be ENABLED by the
> NR bit ( as redefined) in the certificate which includes the corresponding
> public key.  If the certificate does not have the bit turned on, the
> application is not obligated to request the ceremonial, due caution
> approval; and relying party software should ignore a per-message
> indicator even if present in that case.

I do not agree with "must be ENABLED by the NR bit (as redefined)" or any
indicator in a certificate. Since its the application assisting the user
with the ceremony, I don't think having an additional bit in a certificate
helps if the indicators are present.

>
> The obvious, but not necessarily the only, place to put such a message
> by message indicator would be in the Cryptographic Message Syntax
> used by S/MIME V3, in particular as a new signedAttribute.  Since
> signedAttributes is a SET of self-describing attributes, adding
> an additional one would be very simple.

I have no problem with this suggestion as long as we don't limit it to just
S/MIME. Some other non-X.509 group might want the same or similar indicators
in another PKI such as PGP.

Now for my belief as to why the NR bit is the only bit to cause so much
discussion/confusion/misunderstandings/etc (and hence should be deprecated).
If you look at the other KeyUsage bits, they all refer either to a
cryptographic object (a key, a certificate or a CRL) or to a cryptographic
operation (a digital signature, key agreement or data encipherment). These
tend to be used in "real-time"; the results are generally immediate (e.g. I
encrypt the data I get the ciphertext right away; I verify a certificate
chain and make sure the appropriate certificates have the keyCertSign bit
set). In addition, these bits can be easily enforced at the cryptographic
engine level: the SignData function only works with a signature key and the
EncryptData only works with a data encipherment key.

The NR bit is different. The 2459 definition states that it "protects
against the signing entity falsely denying some action". Below are what I
believe to be some of the issues and misunderstandings:

1) There's a problem with the term "signing entity". This begs the question
that Tony B. raised: What's the difference between a digital signature that
has the NR bit set and a digital signature that doesn't have NR set? (And
unless I missed the correct answer, I don't think anyone really answered it
in a purely technical way.) And if it is a "signing entity", does the DS bit
have to be set also? Is the protection less if the DS bit is set? Is there
no protection if the NR bit is not set?

2) To me, "falsely denying" implies a time lag. I performed my services for
a client after he/she digitally signed a contract. Now I want to collect my
fee and he/she denys signing the contract.

3) To me, "falsely denying" also implies something more that just a
reference to a cryptographic object or performing a cryptographic operation.
This implies "semantics" of what is being signed. Which means that it is
very hard to enforce at the cryptographic engine level. How does the
SignData function know that the data is a contract vs. an SSL block
(corollary to Tony's question)?

4) To me, "falsely denying" also implies that for me to rebut the denial, I
have to have evidence and an impartial third party to evaluate the evidence.
Is the signed contract with the NR bit set sufficient evidence?

5) How is the protection provided? How strong is the protection? Is there
any protection without the NR bit?

6) The NR bit is in the public key certificate. How does that relate to the
how the private key was used and/or mis-used? Does the private key also need
a NR bit?

[snip]

The opinions expressed are strictly my own but I reserve the right to
repudiate any of them ;-)

Regards,
Aram Perez


BTW, did anyone successfully define "technical non-repudiation" in a purely
technical way or did I miss that also?


Received: from poptop.llnl.gov (poptop.llnl.gov [128.115.18.65]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id QAA16647 for <[e-mail]>; Thu, 19 Aug 1999 16:23:29 -0700 (PDT)
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 QAA22961; Thu, 19 Aug 1999 16:24:33 -0700 (PDT)
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.3 (32)
Date: Thu, 19 Aug 1999 16:24:25 -0700
To: "David P. Kemp" <[e-mail]>, [e-mail]
From: Tony Bartoletti <[e-mail]>
Subject: Re: Is this non-repudiation or NR, and why?
In-Reply-To: <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"

At 06:13 PM 8/19/99 -0400, David P. Kemp wrote:
[snip]
>>  [snip]
>> >
>> >--------   --------   --------  --------                 --------
>> >Phase 1:   Phase 2:   Phase 3:  Phase 4:                 Phase 5:
>> >Request    Generate   Store     Verify                   Resolve
>> >Service    Evidence   Evidence  Evidence                 Dispute
>> >--------   --------   --------  --------                 --------
>> >
>> >Service    Critical   Evidence  Evidence    Critical     Evidence
>> >Request => Action  => Is     => Is       => Action Is => Is
>> >Is Made    Occurs     Stored    Tested      Repudiated   Verified
>> >           and           |         ^                         ^
>> >           Evidence      v         |                         |
>> >           Is         +-------------------+                  |
>> >           Generated  |Verifiable Evidence|------------------+
>> >                      +-------------------+
>> >

[snip]
>
>I would like to see a request from the ABA that we cease and desist
>using the term "technical non-repudiation" or "non-repudiation
>[security] service" to refer to this mathematical process, before we
>feel obliged to abandon a term that is well established in the
>literature.  To date, we have not seen evidence of concern within
>the legal community that the term is either confusing or inaccurate.

Agreed.  This is an "evidence preservation" system/process, and the
unlabeled phase "Critical Action Is Repudiated" should be described
by "Authenticity of Evidence is Questioned".

Unfortunately, the sense that this process itself represents "NR"
is not uncommon.  We need a term, such as Ed's "POA" to refer to
the mechanism above, so when someone claims to be talking about
"NR", one can ask "in what sense, beyond POA?"

___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 tomcat.sac.verio.net ([e-mail] [209.162.64.15]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id PAA16049 for <[e-mail]>; Thu, 19 Aug 1999 15:38:15 -0700 (PDT)
Received: from nma.com (pm06-03.sac.verio.net [209.162.64.210]) by tomcat.sac.verio.net (8.9.1a/8.9.1) with ESMTP id PAA00676; Thu, 19 Aug 1999 15:39:22 -0700 (PDT)
Message-ID: <[e-mail]>
Date: Thu, 19 Aug 1999 15:39:25 -0700
From: Ed Gerck <[e-mail]>
X-Mailer: Mozilla 4.61 [en]C-CCK-MCD {Sony}  (Win98; I)
X-Accept-Language: en
MIME-Version: 1.0
To: Aram Perez <[e-mail]>
CC: pkix <[e-mail]>, Tony Bartoletti <[e-mail]>
Subject: Re: SET and NR
References: <[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Aram Perez wrote:

> I guess I missed the implied point of "by the card owner".

> > Aram,
> >
> > I believe Ed really meant "ordered, received and used" by the card owner.
> > ___tony___

Yes, I did -- but note that I did not mention it even when I commented on Aram's
"sly try" because it is really irrelevant if it was by the card owner or not.  The logic
may be useful here, so let me comment some cases (CO = card owner; O = other):

1. CO repudiates order but goods were delivered to CO's house and there is
no proof of return to the supplier.  So, even though CO's old girl-friend actually
ordered the goods and received the goods, and CO can prove it, CO pays in
full.

2. CO repudiates order but goods were ordered from a public phone,
received in a PO Box now closed and used over a public phone. CO pays
the NR fee of $ 50.00, even though CO can prove that CO was never in
Moldavia (where the phone calls were made, the goods sent to and used
over the phone).

3. CO's wife uses CO's credit card and buys heart out. CO pays in full
(also because of quasi-contract obligation in marriage).

4. CO repudiates charge, fraudster is located and agrees to pay. CO
pays nothing.  If fraudster is located but does not pay, CO may have to
pay NR fee of $ 50.00.

5. CO buys gimmick, that is never delivered. CO repudiates charge based
on non-delivery and CO credit card service promotes a dispute resolution
with merchant's bank. If merchant cannot prove delivery, merchant's bank
does a charge-back and credits CO bank, meanwhile *full* amount goes
to CO's "in dispute" balance and reduces the CO's card limit in full (ie, not
just for the NR fee of $ 50.00) until the dispute resolution is cleared.

Cheers,

Ed Gerck



Received: from stingray.missi.ncsc.mil (stingray.missi.ncsc.mil [144.51.50.20]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id PAA15644 for <[e-mail]>; Thu, 19 Aug 1999 15:14:01 -0700 (PDT)
Received: from stingray.missi.ncsc.mil (root@localhost) by stingray.missi.ncsc.mil with ESMTP id SAA20755 for <[e-mail]>; Thu, 19 Aug 1999 18:15:15 -0400 (EDT)
Received: from missi.ncsc.mil (depot.missi.ncsc.mil [144.51.60.1]) by stingray.missi.ncsc.mil with ESMTP id SAA20751 for <[e-mail]>; Thu, 19 Aug 1999 18:15:14 -0400 (EDT)
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 SAA00214 for <[e-mail]>; Thu, 19 Aug 1999 18:15:04 -0400 (EDT)
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 SAA25783 for <[e-mail]>; Thu, 19 Aug 1999 18:13:47 -0400 (EDT)
Message-Id: <[e-mail]>
Date: Thu, 19 Aug 1999 18:13:47 -0400 (EDT)
From: "David P. Kemp" <[e-mail]>
Reply-To: "David P. Kemp" <[e-mail]>
Subject: Re: Is this non-repudiation or NR, and why?
To: [e-mail]
MIME-Version: 1.0
Content-Type: TEXT/plain; charset=us-ascii
Content-MD5: sJXOu0yjLr/maVIpPMY9Rg==
X-Mailer: dtmail 1.3.0 CDE Version 1.3 SunOS 5.7 sun4u sparc

From: Tony Bartoletti <[e-mail]>
>
> At 04:54 PM 8/19/99 -0400, Robert W. Shirey wrote:
> >
> > non-repudiation service
> > -----------------------
> > (I) A security service that provide protection against false denial of
> > involvement in a communication. (Also see: repudiation.)
> > 
>  [snip]
> >
> >--------   --------   --------  --------                 --------
> >Phase 1:   Phase 2:   Phase 3:  Phase 4:                 Phase 5:
> >Request    Generate   Store     Verify                   Resolve
> >Service    Evidence   Evidence  Evidence                 Dispute
> >--------   --------   --------  --------                 --------
> >
> >Service    Critical   Evidence  Evidence    Critical     Evidence
> >Request => Action  => Is     => Is       => Action Is => Is
> >Is Made    Occurs     Stored    Tested      Repudiated   Verified
> >           and           |         ^                         ^
> >           Evidence      v         |                         |
> >           Is         +-------------------+                  |
> >           Generated  |Verifiable Evidence|------------------+
> >                      +-------------------+
> >
> >[For94] W. Ford, *Computer Communications Security: Principles, Standard
> >Protocols and Techniques", ISBN 0-13-799453-2, 1994.
> 
> Nice Graph!
> 
> Classically referred to as NR, I believe predict Ed will describe it
> as a mechanical "Proof of Authentication" scheme.  The contents so
> authenticated may or may not be NR, except in the earlier sense of
> "mathematically non-repudiable".


I would like to see a request from the ABA that we cease and desist
using the term "technical non-repudiation" or "non-repudiation
[security] service" to refer to this mathematical process, before we
feel obliged to abandon a term that is well established in the
literature.  To date, we have not seen evidence of concern within
the legal community that the term is either confusing or inaccurate.



Received: from tomcat.sac.verio.net ([e-mail] [209.162.64.15]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id PAA15466 for <[e-mail]>; Thu, 19 Aug 1999 15:11:43 -0700 (PDT)
Received: from nma.com (pm06-03.sac.verio.net [209.162.64.210]) by tomcat.sac.verio.net (8.9.1a/8.9.1) with ESMTP id PAA23914; Thu, 19 Aug 1999 15:12:51 -0700 (PDT)
Message-ID: <[e-mail]>
Date: Thu, 19 Aug 1999 15:12:53 -0700
From: Ed Gerck <[e-mail]>
X-Mailer: Mozilla 4.61 [en]C-CCK-MCD {Sony}  (Win98; I)
X-Accept-Language: en
MIME-Version: 1.0
To: Aram Perez <[e-mail]>
CC: PKIX <[e-mail]>
Subject: Re: SET and NR
References: <[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Aram Perez wrote:

> Hi Ed,
>
> I was only referring to your point 1. In my case, there was "legal proof
> that the goods were ordered, received and used" using my credit card number.

;-) nice sly try -- but phone calls are not "goods", and that is why I especifically
mentioned goods since goods are moveable and they leave a trace which can
supply legal proof that they were ordered (phone call ID), received (postal
delivery with return ticket) and used (a debit card which is used in
card-present mode).

I agree that the wording would have to be more precise for "services" but that
is why I left them out ;-)

Thus, it is harder to repudiate services in credit-card charges,  while
it is easier to repudiate goods that are wrongly charged.  That is why most
card frauds from inescrupulous merchants are based on supplying inexisting
services.  There is one website case that offered ridiculously low hosting prices
($15.00/month) for 300 Mb and then simply never replied after the payment was
made -- how to prove that the website was not active in that month ... after
the month is passed and the bill arrives?

> But in my case, the proof proved that I did not make the phone calls.

Yes, which saved you $ 50.00.  But, if the miscreant does not pay the full
bill you may be called to pay the NR fee.

Cheers,

Ed Gerck



Received: from poptop.llnl.gov (poptop.llnl.gov [128.115.18.65]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id OAA14970 for <[e-mail]>; Thu, 19 Aug 1999 14:37:25 -0700 (PDT)
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 OAA25663; Thu, 19 Aug 1999 14:38:31 -0700 (PDT)
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.3 (32)
Date: Thu, 19 Aug 1999 14:38:23 -0700
To: "Robert W. Shirey" <[e-mail]>, Ed Gerck <[e-mail]>
From: Tony Bartoletti <[e-mail]>
Subject: Re: Is this non-repudiation or NR, and why?
Cc: PKIX <[e-mail]>
In-Reply-To: <v03110705b3e21ec90198@[192.233.50.129]>
References: <[e-mail]> <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"

At 04:54 PM 8/19/99 -0400, Robert W. Shirey wrote:
>Ed,
>
[snip]
>
>--------   --------   --------  --------                 --------
>Phase 1:   Phase 2:   Phase 3:  Phase 4:                 Phase 5:
>Request    Generate   Store     Verify                   Resolve
>Service    Evidence   Evidence  Evidence                 Dispute
>--------   --------   --------  --------                 --------
>
>Service    Critical   Evidence  Evidence    Critical     Evidence
>Request => Action  => Is     => Is       => Action Is => Is
>Is Made    Occurs     Stored    Tested      Repudiated   Verified
>           and           |         ^                         ^
>           Evidence      v         |                         |
>           Is         +-------------------+                  |
>           Generated  |Verifiable Evidence|------------------+
>                      +-------------------+
>
>[For94] W. Ford, *Computer Communications Security: Principles, Standard
>Protocols and Techniques", ISBN 0-13-799453-2, 1994.

Nice Graph!

Classically referred to as NR, I believe predict Ed will describe it
as a mechanical "Proof of Authentication" scheme.  The contents so
authenticated may or may not be NR, except in the earlier sense of
"mathematically non-repudiable".

The issue, as I still see it, is that any connection to the supposed
"denying entity" is either formal (The Key has your name on it, so
we will take it as being You) or just hoped for, and whether or not
the distinction between these bindings can really rest on the force
of an "I meant to do this" bit.

If the Key with my name in involved in some action, and you collect
and archive the critical evidence, then you can surely prove to a
third party (up to mathematic strength) that it was indeed the Key
with my name that was involved.  So you have (what I have called)
NR in this sense.

But if it can also be proven that I was in a hospital, comatose
during the time the transaction occurred, it seems awkward to me
to claim "Tony's agreement to the action is non-repudiable."

If, for some reason, I can still (formally) be held liable,
then this is the "Non-Rebuttable Presumption" system at work.

But even in this case, NRP rests on top of the mechanical
"Proof-of-Authentication" machine described by the graph,
which could serve to post-verify all manner of activities.

___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 mail.proper.com (8.9.3/8.9.3) with ESMTP id OAA14597 for <[e-mail]>; Thu, 19 Aug 1999 14:07:47 -0700 (PDT)
Received: from mailgate2.apple.com ([17.129.100.225]) by mail-out2.apple.com (8.8.5/8.8.5) with ESMTP id OAA18602 for <[e-mail]>; Thu, 19 Aug 1999 14:08:57 -0700
Received: from scv4.apple.com (scv4.apple.com) by mailgate2.apple.com (Content Technologies SMTPRS 2.0.15) with ESMTP id <[e-mail]> for <[e-mail]>; Thu, 19 Aug 1999 14:08:37 -0700
Received: from [17.205.41.166] (aram1.apple.com [17.205.41.166]) by scv4.apple.com (8.9.3/8.9.3) with ESMTP id OAA12682 for <[e-mail]>; Thu, 19 Aug 1999 14:08:37 -0700
Message-Id: <[e-mail]>
X-Mailer: Microsoft Outlook Express Macintosh Edition - 4.5 (0410)
Date: Thu, 19 Aug 1999 14:08:34 -0700
Subject: Re: SET and NR
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

I guess I missed the implied point of "by the card owner".

:-(
Aram Perez

> Aram,
>
> I believe Ed really meant "ordered, received and used" by the card owner.
>
> (correct me if wrong, Ed.)
>
> At 12:53 PM 8/19/99 -0700, Aram Perez wrote:
>>Hi Ed,
>>
>>I was only referring to your point 1. In my case, there was "legal proof
>>that the goods were ordered, received and used" using my credit card number.
>>But in my case, the proof proved that I did not make the phone calls.
>>
>>Regards,
>>Aram Perez
>>
>>> Aram Perez wrote:
>>>
>>>> And contrary to what Ed Gerck said, I have personally repudiated phone
>>>> calls made with my credit card. A while back someone stole
>>>> my credit card numbers and made around $250 worth of phone-sex calls (they
>>>> were dumb enough to call 800 numbers which traced back to their home
phone).
>>>> I did not have to pay any of the calls.
>>>
>>> :-) thanks for the bait. Let me repeat what I said, before I comment:
>>>
>>> 1. Credit-card purchases are not repudiable for example if there is legal
>>> proof that
>>> the goods were ordered, received and used -- for example, a phone debit
card.
>
> [snip]
>
> ___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 rosslyn.BBN.COM (rosslyn.bbn.com [192.233.49.140]) by mail.proper.com (8.9.3/8.9.3) with SMTP id NAA14322 for <[e-mail]>; Thu, 19 Aug 1999 13:59:44 -0700 (PDT)
Received: from ros-dhcp050-129.bbn.com by rosslyn.BBN.COM id aa27917; 19 Aug 99 17:05 EDT
X-Sender: [e-mail]
Message-Id: <v03110705b3e21ec90198@[192.233.50.129]>
In-Reply-To: <[e-mail]>
References: <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Thu, 19 Aug 1999 16:54:06 -0400
To: Ed Gerck <[e-mail]>
From: "Robert W. Shirey" <[e-mail]>
Subject: Is this non-repudiation or NR, and why?
Cc: PKIX <[e-mail]>

Ed,

In your terms, what is this? And why is that?

non-repudiation service
-----------------------
(I) A security service that provide protection against false denial of
involvement in a communication. (Also see: repudiation.)

(C) Non-repudiation service does not and cannot prevent an entity from
repudiating a communication.  Instead, the service provides evidence that
can be stored and later presented to a third party to resolve disputes that
arise if and when a communication is repudiated by one of the entities
involved. There are two basic kinds of non-repudiation service:

 - "Non-repudiation with proof of origin" provides the recipient of data
with evidence that proves the origin of the data, and thus protects the
recipient against an attempt by the originator to falsely deny sending the
data. This service can be viewed as as a stronger version of an data origin
authentication service, in that it proves authenticity to a third party.

 - "Non-repudiation with proof of receipt" provides the originator of data
with evidence that proves the data was received as addressed, and thus
protects the originator against an attempt by the recipient to falsely deny
receiving the data.

(C) Phases of a Non-Repudiation Service: [For94]'s discussion uses the term
"critical action" to refer to the act of communication that is the subject
of the service, which has five phases:

--------   --------   --------  --------                 --------
Phase 1:   Phase 2:   Phase 3:  Phase 4:                 Phase 5:
Request    Generate   Store     Verify                   Resolve
Service    Evidence   Evidence  Evidence                 Dispute
--------   --------   --------  --------                 --------

Service    Critical   Evidence  Evidence    Critical     Evidence
Request => Action  => Is     => Is       => Action Is => Is
Is Made    Occurs     Stored    Tested      Repudiated   Verified
           and           |         ^                         ^
           Evidence      v         |                         |
           Is         +-------------------+                  |
           Generated  |Verifiable Evidence|------------------+
                      +-------------------+

[For94] W. Ford, *Computer Communications Security: Principles, Standard
Protocols and Techniques", ISBN 0-13-799453-2, 1994.




Received: from poptop.llnl.gov (poptop.llnl.gov [128.115.18.65]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id NAA14099 for <[e-mail]>; Thu, 19 Aug 1999 13:55:56 -0700 (PDT)
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 NAA02557; Thu, 19 Aug 1999 13:57:04 -0700 (PDT)
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.3 (32)
Date: Thu, 19 Aug 1999 13:56:57 -0700
To: "Aram Perez" <[e-mail]>, PKIX <[e-mail]>
From: Tony Bartoletti <[e-mail]>
Subject: Re: SET and NR
In-Reply-To: <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"

Aram,

I believe Ed really meant "ordered, received and used" by the card owner.

(correct me if wrong, Ed.)

At 12:53 PM 8/19/99 -0700, Aram Perez wrote:
>Hi Ed,
>
>I was only referring to your point 1. In my case, there was "legal proof
>that the goods were ordered, received and used" using my credit card number.
>But in my case, the proof proved that I did not make the phone calls.
>
>Regards,
>Aram Perez
>
>> Aram Perez wrote:
>>
>>> And contrary to what Ed Gerck said, I have personally repudiated phone
>>> calls made with my credit card. A while back someone stole
>>> my credit card numbers and made around $250 worth of phone-sex calls (they
>>> were dumb enough to call 800 numbers which traced back to their home phone).
>>> I did not have to pay any of the calls.
>>
>> :-) thanks for the bait. Let me repeat what I said, before I comment:
>>
>> 1. Credit-card purchases are not repudiable for example if there is legal
>> proof that
>> the goods were ordered, received and used -- for example, a phone debit card.

[snip]

___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 mail.proper.com (8.9.3/8.9.3) with ESMTP id MAA13354 for <[e-mail]>; Thu, 19 Aug 1999 12:52:05 -0700 (PDT)
Received: from mailgate2.apple.com ([17.129.100.225]) by mail-out2.apple.com (8.8.5/8.8.5) with ESMTP id MAA18894 for <[e-mail]>; Thu, 19 Aug 1999 12:53:15 -0700
Received: from scv4.apple.com (scv4.apple.com) by mailgate2.apple.com (Content Technologies SMTPRS 2.0.15) with ESMTP id <[e-mail]> for <[e-mail]>; Thu, 19 Aug 1999 12:53:08 -0700
Received: from [17.205.41.166] (aram1.apple.com [17.205.41.166]) by scv4.apple.com (8.9.3/8.9.3) with ESMTP id MAA13778 for <[e-mail]>; Thu, 19 Aug 1999 12:53:07 -0700
Message-Id: <[e-mail]>
X-Mailer: Microsoft Outlook Express Macintosh Edition - 4.5 (0410)
Date: Thu, 19 Aug 1999 12:53:04 -0700
Subject: Re: SET and NR
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 Ed,

I was only referring to your point 1. In my case, there was "legal proof
that the goods were ordered, received and used" using my credit card number.
But in my case, the proof proved that I did not make the phone calls.

Regards,
Aram Perez

> Aram Perez wrote:
>
>> And contrary to what Ed Gerck said, I have personally repudiated phone
>> calls made with my credit card. A while back someone stole
>> my credit card numbers and made around $250 worth of phone-sex calls (they
>> were dumb enough to call 800 numbers which traced back to their home phone).
>> I did not have to pay any of the calls.
>
> :-) thanks for the bait. Let me repeat what I said, before I comment:
>
> 1. Credit-card purchases are not repudiable for example if there is legal
> proof that
> the goods were ordered, received and used -- for example, a phone debit card.
>
> 2. Credit-card purchases are not repudiable in the case of fraud
> by the cardholder, as another example.
>
> 3. There are many more case where credit cards are not repudiable.
>
> 4. Credit-card purchases are repudiable in the case of fraud NOT
> by the cardholder but credit card holders agree to non-repudiation
> of a US$ 50.00  charge in the event of card fraud.
>
> The card debt you say is repudiable -- there was fraud and it could be
> easily seen that it was not yours.  If the miscreant could not be traced
> (for example, used public phones) then you would have to pay the
> $ 50.00 fee, but in your case I doubt you paid even that.  However,
> if the miscreant never pays the bill I imagine that the credit card will
> eventually ask you to pay that $ 50.00 fee.
>
> Cheers,
>
> Ed Gerck
>



Received: from tomcat.sac.verio.net ([e-mail] [209.162.64.15]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id MAA13060 for <[e-mail]>; Thu, 19 Aug 1999 12:38:55 -0700 (PDT)
Received: from nma.com (pm06-27.sac.verio.net [209.162.64.234]) by tomcat.sac.verio.net (8.9.1a/8.9.1) with ESMTP id MAA14798; Thu, 19 Aug 1999 12:40:02 -0700 (PDT)
Message-ID: <[e-mail]>
Date: Thu, 19 Aug 1999 12:40:04 -0700
From: Ed Gerck <[e-mail]>
X-Mailer: Mozilla 4.61 [en]C-CCK-MCD {Sony}  (Win98; I)
X-Accept-Language: en
MIME-Version: 1.0
To: Aram Perez <[e-mail]>
CC: PKIX <[e-mail]>
Subject: Re: SET and NR
References: <[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Aram Perez wrote:

> And contrary to what Ed Gerck said, I have personally repudiated phone
> calls made with my credit card. A while back someone stole
> my credit card numbers and made around $250 worth of phone-sex calls (they
> were dumb enough to call 800 numbers which traced back to their home phone).
> I did not have to pay any of the calls.

:-) thanks for the bait. Let me repeat what I said, before I comment:

1. Credit-card purchases are not repudiable for example if there is legal proof that
the goods were ordered, received and used -- for example, a phone debit card.

2. Credit-card purchases are not repudiable in the case of fraud
by the cardholder, as another example.

3. There are many more case where credit cards are not repudiable.

4. Credit-card purchases are repudiable in the case of fraud NOT
by the cardholder but credit card holders agree to non-repudiation
of a US$ 50.00  charge in the event of card fraud.

The card debt you say is repudiable -- there was fraud and it could be
easily seen that it was not yours.  If the miscreant could not be traced
(for example, used public phones) then you would have to pay the
$ 50.00 fee, but in your case I doubt you paid even that.  However,
if the miscreant never pays the bill I imagine that the credit card will
eventually ask you to pay that $ 50.00 fee.

Cheers,

Ed Gerck



Received: from tomcat.sac.verio.net ([e-mail] [209.162.64.15]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id MAA12835 for <[e-mail]>; Thu, 19 Aug 1999 12:29:15 -0700 (PDT)
Received: from nma.com (pm06-27.sac.verio.net [209.162.64.234]) by tomcat.sac.verio.net (8.9.1a/8.9.1) with ESMTP id MAA12449; Thu, 19 Aug 1999 12:30:20 -0700 (PDT)
Message-ID: <[e-mail]>
Date: Thu, 19 Aug 1999 12:30:22 -0700
From: Ed Gerck <[e-mail]>
X-Mailer: Mozilla 4.61 [en]C-CCK-MCD {Sony}  (Win98; I)
X-Accept-Language: en
MIME-Version: 1.0
To: [e-mail], "[e-mail]" <[e-mail]>
Subject: Re: NR -- what the real issues are, and  a proposal
References: <[e-mail]>
Content-Type: text/html; charset=us-ascii
Content-Transfer-Encoding: 7bit

<!doctype html public "-//w3c//dtd html 4.0 transitional//en">
<html>
<body bgcolor="#FFFFFF" style="FONT: 10pt Arial; MARGIN-LEFT: 2px; MARGIN-TOP: 2px">
Bob:
<p>I hope we both won't be blamed for the World Wide Wait ;-)
<br>BTW, the lifetime of a cerficate tends to be inversely proportional
<br>to the number of its attributes (old thread) but, fortunately, an
<br>email can escape this rule by being also valid by parts -- not
<br>just invalid as a whole when one part is wrong.&nbsp; I especially
<br>liked some parts of your email even though others invite
<br>some counter-examples.
<p>[e-mail] wrote:
<blockquote TYPE=CITE>&nbsp;<font face="MS Sans Serif"><font size=-2>I
agree with you regarding the case when the NR bit is&nbsp;<br>
off -- you can't use the certificate for any nonrepudiation&nbsp;<br>
purpose in that case.</font></font></blockquote>
<tt><font color="#FF0000">The NR bit off case has three logic levels as
I commented. So,</font></tt>
<br><tt><font color="#FF0000">which one is meant? This question cannot
be answered by a</font></tt>
<br><tt><font color="#FF0000">boolean bit.&nbsp; Appart from this, what
is it that each level means,</font></tt>
<br><tt><font color="#FF0000">exactly? This questions seems to have 4 meanings
(three of</font></tt>
<br><tt><font color="#FF0000">which were recently summarized by Tony).</font></tt>
<blockquote TYPE=CITE><font face="MS Sans Serif"><font size=-2>Perhaps
I wasn't sufficiently clear in the proposal summary,although I think I
was in the more detailed text, where I said that the NRbit has to be used
to ENABLE the NR bit in the message itself.</font></font></blockquote>
<font color="#FF0000">I agree with this</font>
<blockquote TYPE=CITE><font face="MS Sans Serif"><font size=-2>Why should
you try to deny in advance something that might belegally binding (to answer
someone else's question)?</font></font></blockquote>
<font color="#FF0000">The problem here is that you may deny as much as
you wish and yet it</font>
<br><font color="#FF0000">may be used in court and so accepted -- and not
only in the case of</font>
<br><font color="#FF0000">a tort (when it is trivially accepted and even
rated as a further evidence</font>
<br><font color="#FF0000">of intent to deceive).</font>
<blockquote TYPE=CITE><font face="MS Sans Serif"><font size=-2>(I think
this is Ed's point -- that if I don't have the power to denya given capability
in advance, it really isn't nonrepudiation -- it'sjust an option that I
can't control and hence can't be binding, sinceit isn't voluntary.)</font></font></blockquote>
<font color="#FF0000">This is correctly as I said.</font>
<blockquote TYPE=CITE><font face="MS Sans Serif"><font size=-2>However,
Steve, Tony, and even Ed then go down a path that I think ishighly questionable,
and that is the CA-centric view of enablingor disabling nonrepudiation
within the CPS.</font></font></blockquote>
<font color="#FF0000">Thanks for the "even Ed" ;-) -- but I guess we may
be talking across each other.</font>
<br><font color="#FF0000">I see two different points here:</font><font color="#FF0000"></font>
<p><font color="#FF0000">1. I posit that CA-centric and verifier-centric
are both valid PKI modes,</font>
<br><font color="#FF0000">and I also include other two modes (different
thread).&nbsp; Thus, it is IMO</font>
<br><font color="#FF0000">valid to use a CA-centric mode when that mode
is justified.</font><font color="#FF0000"></font>
<p><font color="#FF0000">2. We do have a distinct view on the r-p/ca/subscriber
legal</font>
<br><font color="#FF0000">relationships due to extra-contractual issues.
I will address them</font>
<br><font color="#FF0000">inline after your comments below.</font>
<blockquote TYPE=CITE><font face="MS Sans Serif"><font size=-2>There are
three reasons why something like a NR bit should be in thecertificate,
and not just rely on a certificate policy OID (or worse yet,just a statement
in the CPS itself.)</font></font> <font face="MS Sans Serif"><font size=-2>The
first is a practical one -- very little RP software to date (none that
I know of)implements the policy OID constraint, and without that constraint
there is noenforcement.</font></font></blockquote>
<font color="#FF0000">Enforcement can never exist -- the r-p is free to
use any software and is free</font>
<br><font color="#FF0000">to set any of its features.&nbsp; The only thing
a CA can control is its own actions</font>
<br><font color="#FF0000">-- a truism which crypto cannot change.</font>
<blockquote TYPE=CITE><font face="MS Sans Serif"><font size=-2>In fact,
I would bet that a lot of software would ignore theconstraint even if it
were marked critical -- they certainly ignore a lot of other critical attributes.</font></font></blockquote>
<font color="#FF0000">I agree, and this first reason is thus IMO not relevant
because not enforceable in principle.</font>
<blockquote TYPE=CITE><font face="MS Sans Serif"><font size=-2>The second
reason is more important.&nbsp; Although I can, if I am the relyingparty,
choose a superior CA whose certificate specifies a policy OID constraint,I
am not required to do so. In fact, I can import and "trust" (accept as
valid)a user's certificate directly, without relying on any intervening
CA's certificateat all.&nbsp; I'm not quite certain whether a policyOID
constraint can be placed onthe end-user's certificate -- can it? -- but
even if it is it is far from obvious thatsuch a constraint is binding upon
the application. What mechanisms arepostulated to tell the RP what particular
policy OID the user feels like acceptingtoday?</font></font> <font face="MS Sans Serif"><font size=-2>So
the relying party, or the relying party's IS department, may specify such
a policyconstraint, BUT THEY ARE NOT REQUIRED TO DO SO.</font></font></blockquote>
<font color="#FF0000">This is the same case as the first, but in regard
to the subscriber. The subscriber is</font>
<br><font color="#FF0000">free to do as it pleases -- and this is good
for security and free market reasons.</font>
<br><font color="#FF0000">Thus, this second reason is also IMO not relevant
because not enforceable in principle.</font>
<blockquote TYPE=CITE><font face="MS Sans Serif"><font size=-2>Finally,
as I believe I explained in a previous message, to the best of myknowledge
there is no legal way that I know of whereby the relying partycan be required
to even read the CA's CPS prior to accepting a digital signature,or more
importantly why a CPS that reflects an agreement between the CAand the
subscriber would be binding upon the RP.</font></font> <font face="MS Sans Serif"><font size=-2>This
is a contractual privity issue, and there simply isn't any way around it
thatI know of -- a contract between A and B is not binding on C, even if
there werealso a contract between B and C.</font></font></blockquote>
<font color="#FF0000">This is IMO the real issue.&nbsp; The r-p is not
even required to read the PKIX, spec,</font>
<br><font color="#FF0000">or not even read what his browser says. Again,
the r-p is free to do what it pleases.</font><font color="#FF0000"></font>
<p><font color="#FF0000">But, there are some very strong and well-know
points that allow a CA to</font>
<br><font color="#FF0000">impose conditions upon a r-p and, even, allow
a subscriber to impose</font>
<br><font color="#FF0000">conditions upon a r-p, as well as allowing either
the CA or the subscriber</font>
<br><font color="#FF0000">to grant legal rights to a r-p -- and all, without
contract privity with the r-p.</font>
<br><font color="#FF0000">In fact, this is what makes a CPS dearly vital
to CAs -- as I am sure you</font>
<br><font color="#FF0000">don't ignore because you must have faced this
issue with Novell's CPS.</font>
<br><font color="#FF0000">To give some examples:</font><font color="#FF0000"></font>
<p><font color="#FF0000">i. if the subscriber or the CA issue a blank warranty
such as was done by</font>
<br><font color="#FF0000">the classical case of the Carbolic Ball Co. (I
cited this before and you may</font>
<br><font color="#FF0000">recall it), then any r-p can claim rights to
that warranty even if there is no</font>
<br><font color="#FF0000">contract privity between the r-p and either of
them (CA or subscriber).</font><font color="#FF0000"></font>
<p><font color="#FF0000">ii. If the CA makes it publicly known (website,
legal register, ISBN-numbered</font>
<br><font color="#FF0000">publications such as books, etc.) that any use
of a certificate issued by that CA</font>
<br><font color="#FF0000">must be governed by the CA's CPS before any entity
may rely on the certificate,</font>
<br><font color="#FF0000">then this is binding&nbsp; upon any r-p as a
condition to use that certificate, even if</font>
<br><font color="#FF0000">there is no specific contract between them.</font><font color="#FF0000"></font>
<p><font color="#FF0000">iii. ditto for the subscriber -- for example,
in a form which the user must "accept"</font>
<br><font color="#FF0000">in his browser before actually relying on that
subscriber's certificate for anything</font><font color="#FF0000"></font>
<p><font color="#FF0000">iv. If the law of a specific jurisdiction consider
that a certificate is mostly</font>
<br><font color="#FF0000">a "good" and not so much a "service" (for example,
because a cert is surely</font>
<br><font color="#FF0000">something that is moveable at the time of identification
to the contract for sale</font>
<br><font color="#FF0000">and in the sense that certs need to be moved
from the CA to the subscriber</font>
<br><font color="#FF0000">or r-p), then the r-p can make the CA and the
subscriber liable much in the</font>
<br><font color="#FF0000">same way that a consumer that buys a car from
a dealer (akin to subscriber)</font>
<br><font color="#FF0000">can make the car manufacturer (akin to CA) directly
responsible for defects.</font>
<br><font color="#FF0000">The legal doctrine of "caveat emptor"&nbsp; (buyer,
beware) no longer applies to</font>
<br><font color="#FF0000">such&nbsp; relationships and this was overturned
in the US already in the 50's.</font><font color="#FF0000"></font>
<p><font color="#FF0000">v. UCC Section 2-302 specifies that an agreement
will not be enforced when it is deemed unconscionable.&nbsp; Thus, a too-strong
worded CPS that would deny all liability from</font>
<br><font color="#FF0000">CAs to r-ps may be nullified. Unconscionability
can be found where the agreement is excessively one-sided, such as where
the terms are unreasonably favorable to one party and the other party had
little bargaining power and therefore an absence of meaningful choice.
A CA's disclaiming of implied warranties, exclusion of consequential damages,
exclusion of suitability of purpose and</font>
<br><font color="#FF0000">a zero limit on its monetary liability, often
hiddent&nbsp; in long, technical, complicated, legalese-intensive documents,
may thus backfire and open the CA to a consumer-law based claim from</font>
<br><font color="#FF0000">the r-p -- where the burden of proof is reversed
to the CA.&nbsp;&nbsp; Please see <A HREF="http://www.ilpf.org/work/ca/app3.htm">http://www.ilpf.org/work/ca/app3.htm</A>
for a reference on this and related issues.</font><font color="#FF0000"></font>
<p><font color="#FF0000">vi. The traditional rule in service relationships
has been that one party is not liable to any party not in contractual "privity"
(i.e., has entered into a contract with the party causing harm). However,
this general rule has been relaxed by several jurisdictions. In the case
of merchants, this means that in some</font>
<br><font color="#FF0000">situations merchants may be able to benefit from
the warranties (if any) granted by the CA to the consumer.&nbsp; There
is a continuum across jurisdictions in their adherence to the privity rule.
Among the theories deployed by jurisdictions: * Liability extends only
to those in privity. * Liability extends where the third party was known.
* Liability extends where the third party was known but only if there was
actual communication between the information provider and the third party.
* Liability extends to all foreseeable third parties. * Liability extends
based upon a balancing of various factors.&nbsp; * Liability extends only
when the parties not in privity are physically injured.&nbsp; Please see
<A HREF="http://www.ilpf.org/work/ca/app3.htm">http://www.ilpf.org/work/ca/app3.htm</A> for a reference on this and in other
ways that even in the absence of a contract in place between a merchant
and a CA, there exist alternative arguments under common law for a merchant
to have recourse against a CA for losses suffered.</font><font color="#FF0000"></font>
<p><font color="#FF0000">vii. The certificate is a copyrighted work, by
definition of copyright, even if it</font>
<br><font color="#FF0000">does not mention it.&nbsp; Thus, its use can
be controlled by a copyright declaration</font>
<br><font color="#FF0000">and the r-p cannot claim ignorance of its terms.
Thus, the CPS can be viewed</font>
<br><font color="#FF0000">as a copyright declaration that controls the
right to use that protected work -- the</font>
<br><font color="#FF0000">certificate -- and thus deny or grant rights
to the user of that work.&nbsp; The right</font>
<br><font color="#FF0000">to make a copy being just one of them.</font>
<blockquote TYPE=CITE><font face="MS Sans Serif"><font size=-2>So the only
way that I know of to specify something of this type is in the defined
semantics of the attribute itself.</font></font></blockquote>
<font color="#FF0000">As above, no.&nbsp; And note that even if your argument
would be correct it would</font>
<br><font color="#FF0000">say too much -- in fact, even the"<font face="MS Sans Serif"><font size=-2>defined
semantics of the attribute itself</font></font>" would also</font>
<br><font color="#FF0000">not be in contractual privity and thus would
also be unenforceable under the</font>
<br><font color="#FF0000">"caveat emptor" doctrine.&nbsp; In other words,
not only the CPS is NOT in</font>
<br><font color="#FF0000">contractual privity but also&nbsp; the PKIX spec
itself is NOT in contractual</font>
<br><font color="#FF0000">privity.</font>
<blockquote TYPE=CITE><font face="MS Sans Serif"><font size=-2>&nbsp;If
the NR bit is now so hopeless confused thatsomeone could wriggle out of
this definition, then we ought to define a new one,perhaps intentToBeLegallyBound,
and deprecate the old one.</font></font></blockquote>
<font color="#FF0000">ToBeLegallyBound is a name like any other but IMO
it still says too much -- its</font>
<br><font color="#FF0000">denotational value is still confusing.&nbsp;
Here, I have suggested "proofOfAuthentication"</font>
<br><font color="#FF0000">-- which essentially IMO says the same that you
want to express but does not mandate</font>
<br><font color="#FF0000">a legal context (which may not exist, as in a
company).</font><font color="#FF0000"></font>
<p><font color="#FF0000">However, I must say I am today more inclined to
use a term that you have explained here</font>
<br><font color="#FF0000">and this may make it more acceptable in general
because your comment was IMO</font>
<br><font color="#FF0000">very clear --- I would be more inclined to use
the name rebuttablePresumption for</font>
<br><font color="#FF0000">that bit, because IMO this is what is meant by
the NR bit service.</font><font color="#FF0000"></font>
<p><font color="#FF0000">In this case, the subscriber would be legally
bound unless he could prove otherwise.</font>
<br><font color="#FF0000">This seems fair and this seems what has been
expressed here. Of course, this</font>
<br><font color="#FF0000">implies a first step (often neglected), which
falls squarely on the shoulders</font>
<br><font color="#FF0000">of the r-p -- to collect enough evidences in
order to convince the court that</font>
<br><font color="#FF0000">the signer has to be called upon to present a
convinving denial (or, must</font>
<br><font color="#FF0000">accept the deal).</font><font color="#FF0000"></font>
<p><font color="#FF0000">BTW,&nbsp; I first intended calling this bit "proofOfAuthentication"
exactly because</font>
<br><font color="#FF0000">it enables the first step that the r-p must undertake:</font><font color="#FF0000"></font>
<p><font color="#FF0000">&nbsp;The proofOfAuthentication bit is asserted
in a certificate as an authorization</font>
<br><font color="#FF0000">&nbsp;to the effect that any message signed with
the certificate can be used as</font>
<br><font color="#FF0000">&nbsp;evidence operating to determine the finding
of an authentication proof, but not</font>
<br><font color="#FF0000">&nbsp;otherwise.</font><font color="#FF0000"></font>
<p><font color="#FF0000">and because I try to avoid specific legal terms
--&nbsp; however, "rebuttable</font>
<br><font color="#FF0000">presumption" was also described and used in these
discussions by Bob</font>
<br><font color="#FF0000">Blakley and others, so I guess it is OK. And,
more meaningful in order</font>
<br><font color="#FF0000">to span that gulf between lawyers and non-lawyers.&nbsp;
I will comment in</font>
<br><font color="#FF0000">a separate posting that the difference between
a "rebuttable presumption"</font>
<br><font color="#FF0000">(ie, the old NR bit cert) and a "non-rebuttable
presumption" certificate</font>
<br><font color="#FF0000">(ie, a possibly new non-repudiation bit cert)
may be made slight in practice,</font>
<br><font color="#FF0000">though they are different in theory.</font><font color="#FF0000"></font>
<p><font color="#FF0000">Cheers,</font><font color="#FF0000"></font>
<p><font color="#FF0000">Ed Gerck</font><font color="#FF0000"></font>
<p><font color="#FF0000">PS: I also agree to avoid HTML mail ;-)</font>
</body>
</html>



Received: from www.meridianus.com (209.249.223.9.has.no.reverse [209.249.223.9] (may be forged)) by mail.proper.com (8.9.3/8.9.3) with ESMTP id MAA12631 for <[e-mail]>; Thu, 19 Aug 1999 12:24:47 -0700 (PDT)
Received: from PC1 by www.meridianus.com (8.8.8+Sun/SMI-SVR4) id NAA10666; Thu, 19 Aug 1999 13:19:32 -0700 (PDT)
Message-ID: <003301beea7a$c3bcc2b0$[e-mail]>
From: "tog" <[e-mail]>
To: "Aram Perez" <[e-mail]>, "PKIX" <[e-mail]>
References: <[e-mail]>
Subject: Re: SET and NR
Date: Thu, 19 Aug 1999 12:40:55 -0700
Organization: Meridianus
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.2918.2701
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2918.2701

Aram, all,
SET was maybe a bad or side-track choice for this conversation since it is
really dead as of this time, even SET II is non-sequitor to some extent.

The real and only issue in the basic thread was and still is "does the
intended use model's for timestamping as per the TS Draft  require a single
NR bit as currently defined for these services, or would an oid or other
structure be mo' bettah'"

That's it.

Todd

----- Original Message -----
From: Aram Perez <[e-mail]>
To: PKIX <[e-mail]>
Sent: Thursday, August 19, 1999 10:33 AM
Subject: SET and NR


> Having worked on SET a couple of years, I like to put in a few comments on
> Bob Blakley's example:
>

SNIP - Flush - SNIP



Received: from mail-out2.apple.com (mail-out2.apple.com [17.254.0.51]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id KAA11272 for <[e-mail]>; Thu, 19 Aug 1999 10:34:02 -0700 (PDT)
Received: from mailgate2.apple.com ([17.129.100.225]) by mail-out2.apple.com (8.8.5/8.8.5) with ESMTP id KAA66706 for <[e-mail]>; Thu, 19 Aug 1999 10:35:11 -0700
Received: from scv4.apple.com (scv4.apple.com) by mailgate2.apple.com (Content Technologies SMTPRS 2.0.15) with ESMTP id <[e-mail]> for <[e-mail]>; Thu, 19 Aug 1999 10:33:42 -0700
Received: from [17.205.41.166] (aram1.apple.com [17.205.41.166]) by scv4.apple.com (8.9.3/8.9.3) with ESMTP id KAA39018 for <[e-mail]>; Thu, 19 Aug 1999 10:33:41 -0700
Message-Id: <[e-mail]>
X-Mailer: Microsoft Outlook Express Macintosh Edition - 4.5 (0410)
Date: Thu, 19 Aug 1999 10:33:38 -0700
Subject: SET and NR
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

Having worked on SET a couple of years, I like to put in a few comments on
Bob Blakley's example:

* SET was designed to be a new "input" mechanism to today's existing payment
card infrastructure. Existing mechanisms are "card present" (i.e., when you
hand your card to a waiter) and "card not present" (i.e. when you order from
a catalog over the phone or you pay over the Internet using SSL).

* A typical payment card transaction is as follows: cardholder provides card
number to merchant. Merchant sends the cost and card number to the acquirer
(the merchant's bank). The acquirer sends the cost and card number to the
issuer (the bank that issued the card to the cardholder). The issuer checks
the card number and payment limit. If there is sufficient credit/payment,
the issuer returns an authorization token (and not a "NR token" as Bob
stated) to the acquirer. The acquirer then sends its own authorization token
to the merchant. The merchant now delivers the goods to the cardholder.

* SET deliberately chose not to use the NR bit or digital signatures for any
type of non-repudiation. Why? Because the existing infrastructure already
provides it. And contrary to what Ed Gerck said, I have personally
repudiated phone calls made with my credit card. A while back someone stole
my credit card numbers and made around $250 worth of phone-sex calls (they
were dumb enough to call 800 numbers which traced back to their home phone).
I did not have to pay any of the calls.

* Although there is a mode of SET where the merchant does not get the card
number, the reality is that today most merchants do track transactions by
card numbers. When SET provides the card number to the merchant, it is after
the transaction is approved, not before the transaction (like when you give
your card to a waiter).

* I disagree with Bob's statement that there is "no *proof* of
authentication". The issuer does check that the card number is "authentic"
before sending the authorization token to the acquirer.

* Bob is correct that "there IS non-repudiation evidence" but it exists with
or without digital signatures (or the NR bit).

Regards,
Aram Perez

P.S. Is this message a repudiation of my previous statement that I would not
comment on the NR issue anymore? ;-)


Received: from prv-mail20.provo.novell.com (prv-mail20.provo.novell.com [137.65.82.195]) by mail.proper.com (8.9.3/8.9.3) with SMTP id JAA10653; Thu, 19 Aug 1999 09:57:54 -0700 (PDT)
From: [e-mail]
Message-Id: <[e-mail]>
Received: from INET-PRV-Message_Server by prv-mail20.provo.novell.com with Novell_GroupWise; Thu, 19 Aug 1999 10:58:32 -0600
Mime-version: 1.0
Date: Thu, 19 Aug 1999 10:58:00 -0600
X-Mailer: Groupwise 5.5.2.1 (Beta)
Cc: [e-mail], [e-mail]
Subject: Re: NR -- what the real issues are, and  a proposal
To: "[e-mail]"
Content-type: multipart/alternative; boundary="____JVKELTVPWVZXCRLXUMYG____"

--____JVKELTVPWVZXCRLXUMYG____
Content-type: text/plain; charset=iso-8859-1

>>> "Rich Ankney" <[e-mail]> 08/17/99 05:07PM >>>
Bob,

Thanks for finally posting all of the relevant stuff in one
message.  My first thought would be to minimize reliance
on the NR bit, i.e. follow Steve's suggestion that if it's
FALSE, you can't use the cert for NR, else you might
be able to.

Of course, ANSI X9.45 defines a useful (CMS signed) attribute
to indicate the purpose of a signature.  Could we overload this (or
define something new but similar) to indicate intent?  The
syntax was an OID, so doing this is pretty simple.  I'd be
glad to force this thru X9 if the IETF crowd is not interested.

Best regards,
Rich

PS: I sent this to you personally rather than to the list in case
you'd like to discuss the details.  If not, of course, feel free
to post your response to the list.


 
Hi, Rich,

I'll take you upon your offer to post your note to the list, and
I'll also comment in passing on some other contributions from
Ed, Tony, and Steve, recognizing that some other suggestions have 
partially overtaken some of these ideas while I was preparing
this note and attending meetings. :-)

I agree with you regarding the case when the NR bit is off -- you
can't use the certificate for any nonrepudiation purpose in that case.
Perhaps I wasn't sufficiently clear in the proposal summary, 
although I think I was in the more detailed text, where I said that the NR
bit has to be used to ENABLE the NR bit in the message itself.

If NR bit is off, any message signed with the key in that certificate 
CANNOT intentionally or unintentionally be used for any legally 
binding purpose -- you are denying, in advance, that that was 
your intent, and signaling a prospective relying party that relying 
on your signature and certificate would be repudiated in court, if 
necessary, and hence such reliance would be quite unwise,
to say the least.
 
Why should you try to deny in advance something that might be 
legally binding (to answer someone else's question)?  Because 
you might be concerned about the possibility that your key might 
be stolen, and that it might not be YOU that is signing in that fashion!

Obviously you know (or at least ought to know) the strengths and 
weakness of your own key management system, and you might
very well decide that a given key/certificate was not sufficiently 
well protected to be used for any legally binding purposes -- it would 
just be too risky. Maybe your ordinary digital-signature-key-used-for-
network-logon-authentication-via-SSL is kept on your hard 
drive with relatively weak password encryption, and your 
nonrepudiation key/certificate is kept on a removable smart card.  
(I think this is Ed's point -- that if I don't have the power to deny 
a given capability in advance, it really isn't nonrepudiation -- it's 
just an option that I can't control and hence can't be binding, since 
it isn't voluntary.)

As I read Steve's note, I think he is in agreement with at least this point.

However, Steve, Tony, and even Ed then go down a path that I think is 
highly questionable, and that is the CA-centric view of enabling 
or disabling nonrepudiation within the CPS. Granted, if there is even 
the faintest suggestion that the CA might be liable for the user's 
actions with respect to his key and how they are used, then the 
CA ought to be able to deny the user the ability to set the NR bit. 
But it should do, obviously, by simply refusing to issue a certificate 
containing that bit.  But whether the CA can impose other conditions 
on the subscriber, or on the RP, in this particular area seems highly 
doubtful, as I will explain. (And as I expect that you, Rich, 
already know because of your banking involvement.)

There are three reasons why something like a NR bit should be in the 
certificate, and not just rely on a certificate policy OID (or worse yet, 
just a statement in the CPS itself.)

The first is a practical one -- very little RP software to date (none that I know of) 
implements the policy OID constraint, and without that constraint there is no 
enforcement.  In fact, I would bet that a lot of software would ignore the
constraint even if it were marked critical -- they certainly ignore a lot of other
critical attributes.

The second reason is more important.  Although I can, if I am the relying
party, choose a superior CA whose certificate specifies a policy OID constraint,
I am not required to do so. In fact, I can import and "trust" (accept as valid) 
a user's certificate directly, without relying on any intervening CA's certificate 
at all.  I'm not quite certain whether a policyOID constraint can be placed on 
the end-user's certificate -- can it? -- but even if it is it is far from obvious that
such a constraint is binding upon the application. What mechanisms are 
postulated to tell the RP what particular policy OID the user feels like accepting 
today?

So the relying party, or the relying party's IS department, may specify such a policy
constraint, BUT THEY ARE NOT REQUIRED TO DO SO.  

Finally, as I believe I explained in a previous message, to the best of my
knowledge there is no legal way that I know of whereby the relying party
can be required to even read the CA's CPS prior to accepting a digital signature,
or more importantly why a CPS that reflects an agreement between the CA 
and the subscriber would be binding upon the RP.  

This is a contractual privity issue, and there simply isn't any way around it that 
I know of -- a contract between A and B is not binding on C, even if there were 
also a contract between B and C.

So the only way that I know of to specify something of this type is in the defined 
semantics of the attribute itself.  If the NR bit is now so hopeless confused that
someone could wriggle out of this definition, then we ought to define a new one,
perhaps intentToBeLegallyBound, and deprecate the old one. But I don't think we 
are there yet -- I think we can use the existing bit for this purpose, so long as we 
recognize that it is the turning off of the bit that is really the most important thing.

With respect to the suggestion to define a new signedAttribute to be applied 
to the message, Russ Housely indicates that would be outside of the current
SMIME WG's charter, but that the charter could be amended if there was 
sufficient interest.

If we can get some reasonable consensus on the overall approach, I would 
be happy to work with you, Rich, to perhaps define a joint IETF-SMIME and
 X9 contribution in this area.

Bob



-----Original Message-----
From: Bob Jueneman <[e-mail]>
To: [e-mail] <[e-mail]>
Date: Tuesday, August 17, 1999 5:39 PM
Subject: NR -- what the real issues are, and a proposal


>The message which follows is a rather lengthy attempt to recap of
>the last five years or so of technical/legal discussion regarding
>digital signatures, followed by a proposal for what to do to fix these
>problems.
>
>However, since many may want to skip the justification and cut t
>o the bottom line, I'll put the proposal up front, and then justify it:
>
>My proposal is that the text of the nonrepudiation key usage bit I
>n the PKIX RFC (and hopefully in X.509) be revised to unambiguously
>state that the defined semantics of this bit is to indicate the willingness
>of the subscriber to be legally bound by a digital signature which can be
>verified by a certificate that can be established to have been valid at the
>time of signature, where "valid" has the normal meaning of not expired, not
>revoked, etc., etc.
>
>In addition, I propose that we create an additional indicator of a
>human being's conscious and willful intent to be legally bound by
>a digital signature that would be applied on a message by message
>basis. This additional indicator would require, as an integral part of
>its semantic definition, that an explicit computer-to-human interaction
>be required to provide some reasonable level of ceremonial and due
>caution warning be provided to the user.  In addition, the semantics
>of this indicator should specify that its use must be ENABLED by the
>NR bit ( as redefined) in the certificate which includes the corresponding
>public key.  If the certificate does not have the bit turned on, the
>application is not obligated to request the ceremonial, due caution
>approval; and relying party software should ignore a per-message
>indicator even if present in that case.
>
>The obvious, but not necessarily the only, place to put such a message
>by message indicator would be in the Cryptographic Message Syntax
>used by S/MIME V3, in particular as a new signedAttribute.  Since
>signedAttributes is a SET of self-describing attributes, adding
>an additional one would be very simple.
>
>Now for the history lesson.
[snip]
--____JVKELTVPWVZXCRLXUMYG____
Content-type: multipart/related; boundary="____AHXCDJKVBWFYUXNLTMAP____"


--____AHXCDJKVBWFYUXNLTMAP____
Content-type: text/html; charset=iso-8859-1

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META content="text/html; charset=unicode" http-equiv=Content-Type>
<META content="MSHTML 5.00.2314.1000" name=GENERATOR></HEAD>
<BODY bgColor=#ffffff 
style="FONT: 10pt Arial; MARGIN-LEFT: 2px; MARGIN-TOP: 2px">
<DIV><FONT face="MS Sans Serif" size=1><FONT face="MS Sans Serif" 
size=1>&gt;&gt;&gt; "Rich Ankney" &lt;[e-mail]&gt; 08/17/99 05:07PM 
&gt;&gt;&gt;<BR>Bob,<BR><BR>Thanks for finally posting all of the relevant stuff 
in one<BR>message.&nbsp; My first thought would be to minimize reliance<BR>on 
the NR bit, i.e. follow Steve's suggestion that if it's<BR>FALSE, you can't use 
the cert for NR, else you might<BR>be able to.<BR><BR>Of course, ANSI X9.45 
defines a useful (CMS signed) attribute<BR>to indicate the purpose of a 
signature.&nbsp; Could we overload this (or<BR>define something new but similar) 
to indicate intent?&nbsp; The<BR>syntax was an OID, so doing this is pretty 
simple.&nbsp; I'd be<BR>glad to force this thru X9 if the IETF crowd is not 
interested.<BR><BR>Best regards,<BR>Rich<BR><BR>PS: I sent this to you 
personally rather than to the list in case<BR>you'd like to discuss the 
details.&nbsp; If not, of course, feel free<BR>to post your response to the 
list.<BR><BR></FONT></FONT></DIV>
<DIV><FONT face="MS Sans Serif" size=1></FONT>&nbsp;</DIV>
<DIV><FONT face="MS Sans Serif" size=1>Hi, Rich,</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face="MS Sans Serif" size=1>I'll take you upon your offer to post 
your note to the list, and</FONT></DIV>
<DIV><FONT face="MS Sans Serif" size=1>I'll also comment in passing on some 
other contributions from</FONT></DIV>
<DIV><FONT face="MS Sans Serif" size=1>Ed, Tony, and Steve, recognizing that 
some other suggestions have </FONT></DIV>
<DIV><FONT face="MS Sans Serif" size=1>partially overtaken some of these ideas 
while I was preparing</FONT></DIV>
<DIV><FONT face="MS Sans Serif" size=1>this note and attending meetings. 
:-)</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face="MS Sans Serif" size=1>I agree with you regarding the case when 
the NR bit is off -- you</FONT></DIV>
<DIV><FONT face="MS Sans Serif" size=1>can't use the certificate for any 
nonrepudiation purpose in that case.</FONT></DIV>
<DIV><FONT face="MS Sans Serif" size=1>Perhaps I wasn't suffici</FONT><FONT 
face="MS Sans Serif" size=1>ently clear in </FONT><FONT face="MS Sans Serif" 
size=1>the proposal summary, </FONT></DIV>
<DIV><FONT face="MS Sans Serif" size=1>although I think I was in the more 
</FONT><FONT face="MS Sans Serif" size=1>detailed text, where I said that the 
NR</FONT></DIV>
<DIV><FONT face="MS Sans Serif" size=1>bit has to be used to ENABLE the NR bit 
in the message itself.</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face="MS Sans Serif" size=1>If </FONT><FONT face="MS Sans Serif" 
size=1>NR bit is off, any message signed </FONT><FONT face="MS Sans Serif" 
size=1>with the key in that certificate </FONT></DIV>
<DIV><FONT face="MS Sans Serif" size=1>CANNOT intentionally or 
unintentionally&nbsp;be used for</FONT><FONT face="MS Sans Serif" size=1> any 
</FONT><FONT face="MS Sans Serif" size=1>legally </FONT></DIV>
<DIV><FONT face="MS Sans Serif" size=1>binding purpose -- you are denying, 
</FONT><FONT face="MS Sans Serif" size=1>in advance, </FONT><FONT 
face="MS Sans Serif" size=1>that that&nbsp;was </FONT></DIV>
<DIV><FONT face="MS Sans Serif" size=1>your intent, and signaling a prospective 
</FONT><FONT face="MS Sans Serif" size=1>relying party that relying 
</FONT></DIV>
<DIV><FONT face="MS Sans Serif" size=1>on your signature and certificate would 
</FONT><FONT face="MS Sans Serif" size=1>be repudiated in court, if 
</FONT></DIV>
<DIV><FONT face="MS Sans Serif" size=1>necessary, and hence such reliance 
</FONT><FONT face="MS Sans Serif" size=1>would be quite unwise,</FONT></DIV>
<DIV><FONT face="MS Sans Serif" size=1>to say the least.</FONT></DIV>
<DIV><FONT face="MS Sans Serif" size=1></FONT>&nbsp;</DIV>
<DIV><FONT face="MS Sans Serif" size=1>Why should you try to deny in advance 
</FONT><FONT face="MS Sans Serif" size=1>something that might be </FONT></DIV>
<DIV><FONT face="MS Sans Serif" size=1>legally binding (to answer someone else's 
</FONT><FONT face="MS Sans Serif" size=1>question)?&nbsp; Because </FONT></DIV>
<DIV><FONT face="MS Sans Serif" size=1>you might be concerned about the 
possibility </FONT><FONT face="MS Sans Serif" size=1>that your key might 
</FONT></DIV>
<DIV><FONT face="MS Sans Serif" size=1>be stolen, and that it might not be YOU 
</FONT><FONT face="MS Sans Serif" size=1>that is signing in that 
fashion!</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face="MS Sans Serif" size=1>Obviously you know (or at least ought to 
know) the strengths and </FONT></DIV>
<DIV><FONT face="MS Sans Serif" size=1>weakness of your own key management 
system, and you might</FONT></DIV>
<DIV><FONT face="MS Sans Serif" size=1>very well decide that a given 
key/certificate was not sufficiently </FONT></DIV>
<DIV><FONT face="MS Sans Serif" size=1>well protected to be used for any legally 
binding purposes -- it would </FONT></DIV>
<DIV><FONT face="MS Sans Serif" size=1>just be too risky. Maybe your ordinary 
</FONT><FONT face="MS Sans Serif" 
size=1>digital-signature-key-used-for-</FONT></DIV>
<DIV><FONT face="MS Sans Serif" size=1>network-logon-authentication-via-SSL is 
kept on your hard </FONT></DIV>
<DIV><FONT face="MS Sans Serif" size=1>drive with relatively weak password 
encryption, and your </FONT></DIV>
<DIV><FONT face="MS Sans Serif" size=1>nonrepudiation </FONT><FONT 
face="MS Sans Serif" size=1>key/certificate is kept on a removable smart 
card.&nbsp; </FONT></DIV>
<DIV><FONT face="MS Sans Serif" size=1>(I think this is Ed's point -- 
</FONT><FONT face="MS Sans Serif" size=1>that if I don't have the power to deny 
</FONT></DIV>
<DIV><FONT face="MS Sans Serif" size=1>a given&nbsp;capability in advance, it 
really </FONT><FONT face="MS Sans Serif" size=1>isn't nonrepudiation -- it's 
</FONT></DIV>
<DIV><FONT face="MS Sans Serif" size=1>just an option that I can't control and 
hence can't be binding, since </FONT></DIV>
<DIV><FONT face="MS Sans Serif" size=1>it isn't voluntary.)</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face="MS Sans Serif" size=1>As I read Steve's note, I think he is in 
agreement with at least this point.</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face="MS Sans Serif" size=1>However, Steve, Tony, and even Ed then go 
down a path that I think is </FONT></DIV>
<DIV><FONT face="MS Sans Serif" size=1>highly questionable, and that is the 
CA-centric view of enabling </FONT></DIV>
<DIV><FONT face="MS Sans Serif" size=1>or disabling nonrepudiation within the 
CPS. Granted, if there is even </FONT></DIV>
<DIV><FONT face="MS Sans Serif" size=1>the faintest suggestion </FONT><FONT 
face="MS Sans Serif" size=1>that the CA might be liable for the user's 
</FONT></DIV>
<DIV><FONT face="MS Sans Serif" size=1>actions with respect to his key 
</FONT><FONT face="MS Sans Serif" size=1>and how they are used, then the 
</FONT></DIV>
<DIV><FONT face="MS Sans Serif" size=1>CA ought to be able to deny the user 
</FONT><FONT face="MS Sans Serif" size=1>the ability to set the NR bit. 
</FONT></DIV>
<DIV><FONT face="MS Sans Serif" size=1>But it should do, obviously, by simply 
refusing to </FONT><FONT face="MS Sans Serif" size=1>issue a certificate 
</FONT></DIV>
<DIV><FONT face="MS Sans Serif" size=1>containing that bit.&nbsp; But whether 
the CA can impose </FONT><FONT face="MS Sans Serif" size=1>other conditions 
</FONT></DIV>
<DIV><FONT face="MS Sans Serif" size=1>on the subscriber, or on the RP, in this 
particular area </FONT><FONT face="MS Sans Serif" size=1>seems highly 
</FONT></DIV>
<DIV><FONT face="MS Sans Serif" size=1>doubtful, as I will explain. (And as I 
expect that you, Rich, </FONT></DIV>
<DIV><FONT face="MS Sans Serif" size=1>already know because of your banking 
involvement.)</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face="MS Sans Serif" size=1>There are three reasons why something 
like a NR bit should be in the </FONT></DIV>
<DIV><FONT face="MS Sans Serif" size=1>certificate, and not </FONT><FONT 
face="MS Sans Serif" size=1>just rely on a certificate policy OID (or worse yet, 
</FONT></DIV>
<DIV><FONT face="MS Sans Serif" size=1>just a statement in the CPS </FONT><FONT 
face="MS Sans Serif" size=1>itself.)</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face="MS Sans Serif" size=1>The first is a practical one -- very 
little RP software to date (none that I know of) </FONT></DIV>
<DIV><FONT face="MS Sans Serif" size=1>implements the policy OID constraint, and 
without that constraint there is no </FONT></DIV>
<DIV><FONT face="MS Sans Serif" size=1>enforcement.&nbsp; In fact, I would bet 
that a lot of software would ignore the</FONT></DIV>
<DIV><FONT face="MS Sans Serif" size=1>constraint even if it were marked 
critical -- they certainly ignore a lot of other</FONT></DIV>
<DIV><FONT face="MS Sans Serif" size=1>critical attributes.</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face="MS Sans Serif" size=1>The second reason is more 
important.&nbsp; Although I can, if I am the relying</FONT></DIV>
<DIV><FONT face="MS Sans Serif" size=1>party, choose a superior CA whose 
certificate specifies a policy OID constraint,</FONT></DIV>
<DIV><FONT face="MS Sans Serif" size=1>I am not required to do so. In fact, I 
can import and "trust" (accept as valid) </FONT></DIV>
<DIV><FONT face="MS Sans Serif" size=1>a user's certificate directly, 
</FONT><FONT face="MS Sans Serif" size=1>without relying on any intervening CA's 
certificate </FONT></DIV>
<DIV><FONT face="MS Sans Serif" size=1>at all.&nbsp; I'm not quite certain 
whether a policyOID constraint can be placed on </FONT></DIV>
<DIV><FONT face="MS Sans Serif" size=1>the end-user's certificate -- can it? -- 
but even if it is it is far from obvious that</FONT></DIV>
<DIV><FONT face="MS Sans Serif" size=1>such a constraint is binding upon the 
application. What mechanisms are </FONT></DIV>
<DIV><FONT face="MS Sans Serif" size=1>postulated to tell the RP what particular 
policy OID the user feels like accepting </FONT></DIV>
<DIV><FONT face="MS Sans Serif" size=1>today?</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face="MS Sans Serif" size=1>So the relying party, or the relying 
party's IS department, may specify such a policy</FONT></DIV>
<DIV><FONT face="MS Sans Serif" size=1>constraint, BUT THEY ARE NOT REQUIRED TO 
DO SO.&nbsp; </FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face="MS Sans Serif" size=1>Finally, as I believe I explained in a 
previous message, to the best of my</FONT></DIV>
<DIV><FONT face="MS Sans Serif" size=1>knowledge there is no legal way that I 
know of whereby the relying party</FONT></DIV>
<DIV><FONT face="MS Sans Serif" size=1>can be required to even read the CA's CPS 
prior to accepting a digital signature,</FONT></DIV>
<DIV><FONT face="MS Sans Serif" size=1>or more importantly why a CPS that 
reflects </FONT><FONT face="MS Sans Serif" size=1>an agreement between the CA 
</FONT></DIV>
<DIV><FONT face="MS Sans Serif" size=1>and the subscriber would be binding upon 
the </FONT><FONT face="MS Sans Serif" size=1>RP.&nbsp; </FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face="MS Sans Serif" size=1>This is a contractual privity issue, and 
there simply isn't any way around it that </FONT></DIV>
<DIV><FONT face="MS Sans Serif" size=1>I know of -- a contract between A and B 
is not binding on C, even if there were </FONT></DIV>
<DIV><FONT face="MS Sans Serif" size=1>also </FONT><FONT face="MS Sans Serif" 
size=1>a contract between B and C.</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face="MS Sans Serif" size=1>So the only way that I know of to specify 
something of this type is in the defined </FONT></DIV>
<DIV><FONT face="MS Sans Serif" size=1>semantics of the attribute itself.&nbsp; 
If the NR bit is now so hopeless confused that</FONT></DIV>
<DIV><FONT face="MS Sans Serif" size=1>someone could wriggle out of this 
definition, then we ought to define a new one,</FONT></DIV>
<DIV><FONT face="MS Sans Serif" size=1>perhaps intentToBeLegallyBound, and 
deprecate the old one. But I don't think we </FONT></DIV>
<DIV><FONT face="MS Sans Serif" size=1>are there yet -- I think we can use the 
existing bit for&nbsp;this purpose, so long as we </FONT></DIV>
<DIV><FONT face="MS Sans Serif" size=1>recognize that it is the turning off of 
the bit that is really the most important thing.</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face="MS Sans Serif" size=1>With respect to the suggestion to define 
a new signedAttribute to be applied </FONT></DIV>
<DIV><FONT face="MS Sans Serif" size=1>to the message, Russ Housely indicates 
that would be outside of the current</FONT></DIV>
<DIV><FONT face="MS Sans Serif" size=1>SMIME WG's charter, but that the charter 
could be amended if there was </FONT></DIV>
<DIV><FONT face="MS Sans Serif" size=1>sufficient </FONT><FONT 
face="MS Sans Serif" size=1>interest.</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face="MS Sans Serif" size=1>If we can get some reasonable consensus 
on the overall approach, I would </FONT></DIV>
<DIV><FONT face="MS Sans Serif" size=1>be happy to work with you, Rich, to 
perhaps define a joint IETF-SMIME and</FONT></DIV>
<DIV><FONT face="MS Sans Serif" size=1>&nbsp;X9 contribution in this 
area.</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face="MS Sans Serif" size=1>Bob</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV>&nbsp;</DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face="MS Sans Serif" size=1>-----Original Message-----<BR>From: Bob 
Jueneman &lt;[e-mail]&gt;<BR>To: [e-mail] 
&lt;[e-mail]&gt;<BR>Date: Tuesday, August 17, 1999 5:39 PM<BR>Subject: 
NR -- what the real issues are, and a proposal<BR><BR><BR>&gt;The message which 
follows is a rather lengthy attempt to recap of<BR>&gt;the last five years or so 
of technical/legal discussion regarding<BR>&gt;digital signatures, followed by a 
proposal for what to do to fix these<BR>&gt;problems.<BR>&gt;<BR>&gt;However, 
since many may want to skip the justification and cut t<BR>&gt;o the bottom 
line, I'll put the proposal up front, and then justify it:<BR>&gt;<BR>&gt;My 
proposal is that the text of the nonrepudiation key usage bit I<BR>&gt;n the 
PKIX RFC (and hopefully in X.509) be revised to unambiguously<BR>&gt;state that 
the defined semantics of this bit is to indicate the willingness<BR>&gt;of the 
subscriber to be legally bound by a digital signature which can 
be<BR>&gt;verified by a certificate that can be established to have been valid 
at the<BR>&gt;time of signature, where "valid" has the normal meaning of not 
expired, not<BR>&gt;revoked, etc., etc.<BR>&gt;<BR>&gt;In addition, I propose 
that we create an additional indicator of a<BR>&gt;human being's conscious and 
willful intent to be legally bound by<BR>&gt;a digital signature that would be 
applied on a message by message<BR>&gt;basis. This additional indicator would 
require, as an integral part of<BR>&gt;its semantic definition, that an explicit 
computer-to-human interaction<BR>&gt;be required to provide some reasonable 
level of ceremonial and due<BR>&gt;caution warning be provided to the 
user.&nbsp; In addition, the semantics<BR>&gt;of this indicator should specify 
that its use must be ENABLED by the<BR>&gt;NR bit ( as redefined) in the 
certificate which includes the corresponding<BR>&gt;public key.&nbsp; If the 
certificate does not have the bit turned on, the<BR>&gt;application is not 
obligated to request the ceremonial, due caution<BR>&gt;approval; and relying 
party software should ignore a per-message<BR>&gt;indicator even if present in 
that case.<BR>&gt;<BR>&gt;The obvious, but not necessarily the only, place to 
put such a message<BR>&gt;by message indicator would be in the Cryptographic 
Message Syntax<BR>&gt;used by S/MIME V3, in particular as a new 
signedAttribute.&nbsp; Since<BR>&gt;signedAttributes is a SET of self-describing 
attributes, adding<BR>&gt;an additional one would be very 
simple.<BR>&gt;<BR>&gt;Now for the history lesson.</FONT></DIV>
<DIV><FONT face="MS Sans Serif" size=1>[snip]</DIV></FONT></BODY></HTML>

--____AHXCDJKVBWFYUXNLTMAP____--

--____JVKELTVPWVZXCRLXUMYG____--


Received: from tomcat.sac.verio.net ([e-mail] [209.162.64.15]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id JAA10239 for <[e-mail]>; Thu, 19 Aug 1999 09:28:53 -0700 (PDT)
Received: from nma.com (pm02-23.sac.verio.net [209.162.64.42]) by tomcat.sac.verio.net (8.9.1a/8.9.1) with ESMTP id JAA23598; Thu, 19 Aug 1999 09:29:55 -0700 (PDT)
Message-ID: <[e-mail]>
Date: Thu, 19 Aug 1999 09:29:57 -0700
From: Ed Gerck <[e-mail]>
X-Mailer: Mozilla 4.61 [en]C-CCK-MCD {Sony}  (Win98; I)
X-Accept-Language: en
MIME-Version: 1.0
To: tog <[e-mail]>
CC: Bob Blakley <[e-mail]>, [e-mail], Tony Bartoletti <[e-mail]>, Stephen Kent <[e-mail]>, Nicholas Bohm <[e-mail]>, "David P. Kemp" <[e-mail]>
Subject: Time, was Re: What non-repudiation is not and the PA bit, was Re: To  Be,or NR To Be ...
References: <033f01bee9bd$47814ee0$[e-mail]>  <[e-mail]> <007101beea51$ed5b5970$[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

tog wrote:

> Bob Ed, pardon me for doing this in the middle of this thread... but this
> has gone on much too long...
>
> >> Imagine that I'm using SET to initiate a transaction with a
> > > merchant.
>
> Yech - but OK - do it.

;-) I would second that. But reading through your thoughtful message,
I saw no relation either to SET (thanks!), or to the NR bit semantics or
to non-repudiation semantics (both, this thread's subject).  The use of
time as evidence in a transaction is fine and useful for NR, whatever
NR is, but this is the question we need to treat from 500,000 feet:
what do we mean when that bit is set? Is this meaning clear to all
and doable? Is one bit enough?  Are the useful validity modes
represented? Or, are we involuntarily misrepresenting what can be
done and confusing the public?

Thus, I welcome the increasing perception that your comments may bring
to this thread but IMO we simply can't talk about how to do it before we
know what we are doing and whether this is doable at all within the scope of
PKIX -- this would not be pragmatism or "hands on approach" but loss of
time.  As someone said, akin to building a Maginot Line fortification and
doing so on quicksand.

> That being said, what are we really talking about here in this conversation?
> Whether the protocol for this particular NR bit use model has enough
> utility, and I say not as a single bit.

I would dare to say we are past this point. In fact, we found several utilities
for it -- and this is what is confusing.  Which utilities are doable within PKIX,
what part we need to refer to the CPS and what part is simply a question
we will never solve? Further, which utility is *the* one we pick, based on all
these considerations? And, can we or should we pick more than one, if
possible?  Finally, what do we mean when we say NR? Is this also what
businesses understand by non-repudiation, across the world?  Or, should
we change that NR name since we all agree the NR bit is neither necessary
nor sufficient for non-repudiation?

> Personally - I think that a whole bunch of the current TS draft needs to get
> flushed and replaced by a section more elevated from component features into
> usable services at the app layer. Otherwise, timestamping is like I said
> before, better left as an application level process with a distributed
> proofing access model so that it can be accessed remotely for TTP models or
> as an embedded feature.

You make IMO some valid points.

Much needs to be said about timestamping as I see it, and I have just
been holding myself in some comments on this -- not only because,
of course (IMO) we need sub-second resolution but because the whole
subject of trust pervades reliance on time.  Time is a relative measurement,
any way you see it., and thus ... where is the reference?  We are thus back
to the same question regarding certificates ... if a certificate is validated by
another and then another... where is the reference?  In either case, there is
no absolute reference -- just relative references.

True, time only moves forward and GPS can be very precise worldwide but
indeterminacy between two independent time measurements always exists
whether in the sub-day level or in the sub-microsecond level -- so, two
independent systems that use time in order to create a reference common
to both will have that indeterminacy to cope with.  Which will be,
paradoxically, equally significant in a system that has a resolution of one
day versus one that has a resolution of one microsecond.  Security
protocols will not be able to work bellow that system's indeterminacy
(whether day or microsecond) and this is where they will be attacked,
no doubt. Using systems in series, an attacker could also create race
conditions that would very much magnify the relevance of that
indeterminacy. Super-attackers could use their superior connectivity
or computing power to create imbalance. Denial of service could create
isalnds of time. MITM attacks could create arbitrary time.

> Otherwise, my feeling is that this conversation is akin to arguing whether
> 'the pair of pliers should have rounded or squared jaws',  and makes about
> as much sense.

As an electronic engineer, I tell you it makes much sense. Square-jaw pliers
may not produce the needed curvature when used as a handtool to bend a
component's leads. Also, round-jaw pliers may create too much pressure
when crimpring a wire in a connector.  But, the discussion on this thread
was not even at this level of tool detail (which you seem to bring in with time,
though). Rather, some are calling those tools "screwdivers", others are calling
them "hammers", others still are calling them "wrenches" and we are having
a great time because no one really knows what those tools are to each other
-- and this is what we are trying to find out in an intersubjective agreement.
Though it may look like an objective disagreement ;-)

Indeed, it may become clear to any observer that there are serious
terminology problems here, in the sense that people are using words in a
variety of senses without realizing when they do not mean the same thing
as others they are communicating with.

But, just give us some time ;-)

Cheers,

Ed Gerck




Received: from www.meridianus.com (209.249.223.25.has.no.reverse [209.249.223.25] (may be forged)) by mail.proper.com (8.9.3/8.9.3) with ESMTP id HAA09054 for <[e-mail]>; Thu, 19 Aug 1999 07:49:39 -0700 (PDT)
Received: from PC1 by www.meridianus.com (8.8.8+Sun/SMI-SVR4) id IAA10379; Thu, 19 Aug 1999 08:26:52 -0700 (PDT)
Message-ID: <007101beea51$ed5b5970$[e-mail]>
From: "tog" <[e-mail]>
To: "Ed Gerck" <[e-mail]>, "Bob Blakley" <[e-mail]>, <[e-mail]>
Cc: "Tony Bartoletti" <[e-mail]>, "Stephen Kent" <[e-mail]>, "Nicholas Bohm" <[e-mail]>, "David P. Kemp" <[e-mail]>
References: <033f01bee9bd$47814ee0$[e-mail]> <[e-mail]>
Subject: Re: What non-repudiation is not and the PA bit, was Re: To Be,or NR To Be ...
Date: Thu, 19 Aug 1999 07:48:15 -0700
Organization: Meridianus
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.2918.2701
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2918.2701

Bob Ed, pardon me for doing this in the middle of this thread... but this
has gone on much too long...

>> Imagine that I'm using SET to initiate a transaction with a
> > merchant.

Yech - but OK - do it.

> > SET has a mode in which my name & credit card number
> > are not divulged to the merchant -- all the merchant gets is a NR token
> > demonstrating to the cardholder's bank (the issuer) that it should pay
> > the merchant's bank (the acquirer) the sum listed in the token from the
> > account (which the issuer is able to extract from the token).

And don't forget the boatload of process overhead, so that SET costs the
operators more in "impatience" and "frustration" than it provides for in
indemnity - These are key issues in any solutions that we produce. If we are
not here for our own ego's and we are really involved in this to better the
world and make commercial use of the Internet and open Networking a reality,
then I propose that some other conceptual ideas need to get mixed into this
conversation. Most especially what it is we are trying to accomplish and
what use it has.

>
> There are two authentication acts going on, in the above -- not just one.
> And, it works because these two acts form a closed circuit; you
> will recognize a flavor of SPKI in it.

I like this model but lets take it a couple of steps farther and jump up to
50,000 feet where we can  get a look at what the timestamping process is
used for anyway.

In using Timestamping, we through a complex mathematical process, create
some evidentiary element to prove some assertion of an event having occured.
It may be the validity of a particular digital signature, it may also be a
digitally signed blob of data that state's why I intended to buy the house I
just did.

As an operating requirement, we claim that these event-process evidentiary
models need to be reconcilable between themselves and other systems issuing
like event-stamps. To support this requirement, we use the one thing we all
can agree on, time. And it essentially forms the cornerstone of the
interoperability in the trust model - Viola' the Timestamp!

Now lets take the next step, the need for security in the proof process..
Lets just leave it at that our justifiable paranoia makes us create security
envelopes for the component data, so we feel better about believing them and
the events they offer proof for. That given, up here at 50,000 ft, the next
query  is what do I do with them, these timestamps? and the answer is
something like "as part of the bigger-picture,  you can either use the
protocol itself to control various types of local events by issuing signals
to an interacting process, or we can use the token that is produced as the
evidentiary proof itself."

With the first model, we see perhaps an Application waiting for the signal
from the Protocol Interface as defined in the current TS Draft, or perhaps
the receipt of the token itself triggers some event or event chain. BTW,
These capabilities  will be important for building Agent's and other
technological systems that require an authorized signal model (i..e. the
receipt of a verifiable token) to trigger some pre-programmed function,
feature, or other event or event chain.

In the second case, the token is actually the proof of the event in
question, and it is likely that the token is archived, so this is really an
audit certification process model... You just grab a token and validate it
when you need to.

Now that we understand what we are going to use the timestamping for - at
50,000 feet. That it provides a mechanism that can inter-relate provable
events to each other , we can really figure out what we need here.

In my book, the token is what's important unless you want to hand policy
flags to a control process, in which case what you want to do is issue
signals based on whether the event "verifies" or not - nothing more. So in
no uncertain terms - Timestamping is an evidentiary process wherein policy
and crontrol infrastructure all add together to create the totality of the
trust and proof models. So in this case not knowing about evidentiary
process would actually be a problem? eh?

That being said, what are we really talking about here in this conversation?
Whether the protocol for this particular NR bit use model has enough
utility, and I say not as a single bit.

The issue of the basic model of services is that the TS technology currently
lets you verify a signature was valid at some point in time, and while that
is valid as a policy control model it is only a small component of proofing
for a transaction model that will stand any audit scrutiny. Remember the
word timestamping is based in creating a stamp as the outcome, not how the
printing of the stamp was done. No one cares what the press was except the
printer, we care about the validity of the stamp.

I am sorry to bring the "morning lights" to this conversation, but the
entire TS protocol is way to complex to use, and provides the users and
developers with way to much overhead in the form of granularity. What the
protocol really needs is simple and easily called services model to create
stamps and verify them, not their discrete components alone. This will
require the creation and promulgation of standard stamps too, or has
everyone realized that already...

]The current model is rooted upon the control of policy and other services
based in signals in the protocol model regarding the validity of the
signatures, but since there is no formal stamp spec, the routines fall way
short of being something like:
o-    verifyStamp(stampID),
o-    createStamp(stampComponentList),
o-    extractStampComponent(stampID,stampComponent) ,
o-    listStampComponents(stampID), etc etc

or the distributed host version:
o-    verifyStamp(stampArchiveHost, stampType, stampID).

Personally - I think that a whole bunch of the current TS draft needs to get
flushed and replaced by a section more elevated from component features into
usable services at the app layer. Otherwise, timestamping is like I said
before, better left as an application level process with a distributed
proofing access model so that it can be accessed remotely for TTP models or
as an embedded feature.

Otherwise, my feeling is that this conversation is akin to arguing whether
'the pair of pliers should have rounded or squared jaws',  and makes about
as much sense.

Todd



Received: from honcho.austin.dascom.com (email.austin.dascom.com [206.196.73.5]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id HAA08836 for <[e-mail]>; Thu, 19 Aug 1999 07:43:59 -0700 (PDT)
Received: from austin.dascom.com by honcho.austin.dascom.com (8.8.8/SMI-SVR4) id JAA14538; Thu, 19 Aug 1999 09:41:49 -0500 (CDT)
Received: from shaggy by austin.dascom.com (8.8.8/SMI-SVR4) id JAA14080; Thu, 19 Aug 1999 09:41:47 -0500 (CDT)
Message-ID: <054e01beea51$a8d2f240$[e-mail]>
Reply-To: "Bob Blakley" <[e-mail]>
From: "Bob Blakley" <[e-mail]>
To: "Ivan Milman" <[e-mail]>, <[e-mail]>
Subject: Re: NR -- what the real issues are, and  a proposal
Date: Thu, 19 Aug 1999 09:46:45 -0500
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="----=_NextPart_000_054B_01BEEA27.BFD3B760"
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

This is a multi-part message in MIME format.

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

Ivan

>Bob J - >>
>Bob B - >
>
>>....  Perhaps we'd have to look at a two-stage process, whereby
>>a non-binding cert would be generated and distributed, and then a request
>>for a binding cert would be generated and signed using the non-binding
cert...
>
>Presumably the user/RA/CA could archive the CRMF message where the NR bit was
>set.

A good idea!

--bob

Bob Blakley ([e-mail])
Chief Scientist, Dascom





------=_NextPart_000_054B_01BEEA27.BFD3B760
Content-Type: text/x-vcard;
	name="Bob Blakley.vcf"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment;
	filename="Bob Blakley.vcf"

BEGIN:VCARD
VERSION:2.1
N:Blakley;Bob
FN:Bob Blakley
ORG:Dascom
TITLE:Chief Scientist
TEL;WORK;VOICE:[phone] x 5012
TEL;WORK;FAX:[phone]
ADR;WORK;ENCODING=3DQUOTED-PRINTABLE:;;Plaza Balcones=3D0D=3D0A5515 =
Balcones Drive;Austin;TX;78731;USA
LABEL;WORK;ENCODING=3DQUOTED-PRINTABLE:Plaza Balcones=3D0D=3D0A5515 =
Balcones Drive=3D0D=3D0AAustin, TX 78731=3D0D=3D0AUSA
URL:
URL:http://www.dascom.com
EMAIL;PREF;INTERNET:[e-mail]
REV:19990819T144645Z
END:VCARD

------=_NextPart_000_054B_01BEEA27.BFD3B760--



Received: from ietf.org (odin.ietf.org [132.151.1.176]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id EAA06699 for <[e-mail]>; Thu, 19 Aug 1999 04:06:20 -0700 (PDT)
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA21474; Thu, 19 Aug 1999 07:06:56 -0400 (EDT)
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-dhpop-01.txt
Date: Thu, 19 Aug 1999 07:06:56 -0400
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		: Diffie-Hellman Proof-of-Possession Algorithms
	Author(s)	: H. Prafullchandra, J. Schaad
	Filename	: draft-ietf-pkix-dhpop-01.txt
	Pages		: 23
	Date		: 18-Aug-99
	
This document describes two methods for producing a signature from a
Diffie-Hellman key pair.  This behavior is needed for such
operations as creating a signature of a PKCS #10 certification
request.  These algorithms are designed to provide a proof-of-
possession rather than general purpose signing.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-pkix-dhpop-01.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-dhpop-01.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-dhpop-01.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-dhpop-01.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-pkix-dhpop-01.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 mail.proper.com (8.9.3/8.9.3) with ESMTP id DAA05440 for <[e-mail]>; Thu, 19 Aug 1999 03:22:20 -0700 (PDT)
Received: from stefan2 (accurata.inbox.se [193.12.72.24]) by popmail.inbox.se (8.9.3/8.9.3) with SMTP id MAA13672; Thu, 19 Aug 1999 12:23:26 +0200
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 
Date: Thu, 19 Aug 1999 12:23:45 +0200
To: <[e-mail]>
From: Stefan Santesson <[e-mail]>
Subject: Pseudonym in Subject DN (in QC certificates)
Cc: Magnus =?iso-8859-1?Q?Nystr=F6m?= <[e-mail]>
In-Reply-To: <048801bee9c7$30307b80$[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 mail.proper.com id DAA05441

All,

I have just received a mail from Magnus Nyström, RSA who writes:

Magnus> "I would suggest that you include 'pseudonym' as a possible
attribute (in the subject field). The text now talks about using 
pseudonyms inside commonNames although you (almost) have defined 
a pseudonym ATTRIBUTE in 3.2.1, which is confusing and 
inconsistent."

Magnus> "Several of the personal data attributes, in particular perhaps the
'pseudonym' one, appears to be useful constructs, but would be so even
more if they were defined as true attributes and not as
'almost-attributes' as they currently are (no matching rules, for
example). That would make it possible to include them in distinguished
names, for example. In order to give them broader visibility and
useability I suggest that you define them as ordinary attributes. As an
alternative (which also perhaps would be beneficial from a visibility
standpoint) we could define them in the upcoming PKCS #9 v2.0, "Selected
Attribute Types". I do not think this would slow down your progress, as
that version of PKCS #9 is scheduled for release in Q4 this year. You
could get an OID in the RSA tree from me and use a simplified attribute
definition for the time being which then could be expanded in PKCS #9 v2.0
if you think that is a better solution."


My comment>
The reason why we didn't include any of the new attributes in the subject
field was that we didn't want to cause problems for the installed base of
products (including directory systems), which understands the attributes in
RFC 2459, but would get into trouble if new attribute were introduced in
the subject field.

I must say that I'm not 100% sure if this fear is justified, or if we
actually should go along with Magnus proposal and introduce the pseudonym
as an optional attribute in the subject field.

If this attribute were defined in PKCS #9 we may face another situation
where this attribute is more widely accepted and maybe this could be a good
reason to include it. If this is the case, we would have to expand the
supported attributes list of RFC 2459. This could be done in the QC spec
but it could also be an issue to consider in RFC 2459 (if that is formally
possible).

I would like the lists comments on this.

/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 tomcat.sac.verio.net ([e-mail] [209.162.64.15]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id VAA19799 for <[e-mail]>; Wed, 18 Aug 1999 21:00:29 -0700 (PDT)
Received: from nma.com (pm05-07.sac.verio.net [209.162.64.167]) by tomcat.sac.verio.net (8.9.1a/8.9.1) with ESMTP id VAA14233; Wed, 18 Aug 1999 21:01:27 -0700 (PDT)
Message-ID: <[e-mail]>
Date: Wed, 18 Aug 1999 21:01:26 -0700
From: Ed Gerck <[e-mail]>
X-Mailer: Mozilla 4.61 [en]C-CCK-MCD {Sony}  (Win98; I)
X-Accept-Language: en
MIME-Version: 1.0
To: Bob Jueneman <[e-mail]>
CC: [e-mail], Bob Blakley <[e-mail]>, Tony Bartoletti <[e-mail]>
Subject: Re: NR -- what the real issues are, and  a proposal
References: <[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Bob Jueneman wrote:

> My proposal is that the text of the nonrepudiation key usage bit I
> n the PKIX RFC (and hopefully in X.509) be revised to unambiguously
> state that the defined semantics of this bit is to indicate the willingness
> of the subscriber to be legally bound by a digital signature which can be
> verified by a certificate that can be established to have been valid at the
> time of signature, where "valid" has the normal meaning of not expired, not
> revoked, etc., etc.

Bob:

1. What you describe does not provide for non-repudiation, so a name change
is needed unless the issue continues confused -- what you describe is to use
authentication data as evidence operating to determine the finding of an
authentication proof (which proof is, of course, the result of that evaluation
or finding).

2. Also, no one can say what the subscriber was willing to do --  so, it is also
confusing to talk about  "the willingness of the subscriber", even as "indicating"
(i.e., ambiguously).  IMO, it is actually an authorization.

3. Further, the words "to be legally bound" are far too strong -- but "to supply
evidence" seems desirable, where I also prefer to delete the word "legal" since
it is useless and just adds noise.  Furthermore, there are cases which will be
settled within an organization itself, so the word "legal" is also wrong in those
cases (i.e., a company does not have to follow public legal procedures in its
own private findings -- for example, the right to have a lawyer).

In all, I would rephrase to what seems to be more aligned also with other
suggestions I read here, and also linting all lawyerly fat, as:

- PA bit:
 The proofOfAuthentication bit is asserted in a certificate as an authorization
 to the effect that any message signed with the certificate can be used as
 evidence operating to determine the finding of an authentication proof, but not
 otherwise.

I would also add: "The CPS may impose other conditions in addition to this
definition."

One of the items the CPS may define is "who authorizes" -- which question is
intentionally left implict in the text since simple use of the certificate already
shows that the subscriber agrees with the authorization.

 Perhaps, the PA bit could be called POA bit, following other examples
such as the "source of authority"  SOA record in DNS. Further, a
search-and-replace should be performed to replace all occurrences
of "non-repudiation" with "proof-of-authentication" and NR with PA (or,
POA).

> In addition, I propose that we create an additional indicator of a
> human being's conscious and willful intent to be legally bound by
> a digital signature that would be applied on a message by message
> basis.

I would not favor this item at all.  If  "user intent" and "user willingness" are
already outside of the scope of PKIX, then "human being's conscious and
willful intent" is not even in sight, I would say.

A separate issue is the definition of non-repudiation, as understood in business
and which use may need to asserted in a certificate in order to enable it in
an application.

I entirely agree that using "non-rebuttable presumption" is better than using
"non-repudiation"  -- in order to make a clean break.  Since Bob Blakley also
suggested this and Tony Bartoletti agreed, I guess at least three are in
agreement at least in that name ;-)

My suggestion is, understanding "Non-Rebuttable Presumption" as that
which allows a truthful denial to be thwarted by a legal affirmation, to have
the following additional text:

- NRP bit:

 Non-Rebuttable Presumption is defined in the CPS and its usage is asserted by
 setting the nonRebuttablePresumption bit.

Here, if  the bit simply enables or disables, then I believe that a single bit is
enough. What the bit is enabling/disabling can then have any number of
states and transitions. Essentially, also in terms of future software uses, the
spec text:

- X is defined in the CPS and its usage is asserted by setting the x bit

can be understood as turning on/off a specific state machine associated with
X in the CPS.  The same applies when a human reads the CPS and employes
the logical/legal rules present in that case.

The use of the PA bit, the NR bit, plus the open-ended bits R, G, B
(for want of a better name) suggested by Tony will IMO allow situations
involving multiple parties/contracts/obligations to be represented, which
is a concern also commented by Bob Blakley.

Cheers,

Ed Gerck



Received: from mail.rdc1.az.home.com ([e-mail] [24.1.240.66]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id TAA10564 for <[e-mail]>; Wed, 18 Aug 1999 19:36:56 -0700 (PDT)
Received: from earthlink.net ([24.1.214.107]) by mail.rdc1.az.home.com (InterMail v4.01.01.00 201-229-111) with ESMTP id <[e-mail]>; Wed, 18 Aug 1999 19:37:43 -0700
Message-ID: <[e-mail]>
Date: Wed, 18 Aug 1999 19:38:52 -0700
From: Timothy Fisher <[e-mail]>
X-Mailer: Mozilla 4.61 [en] (WinNT; I)
X-Accept-Language: en
MIME-Version: 1.0
To: [e-mail]
CC: [e-mail], [e-mail]
Subject: Cast5-MAC Algorithm
References: <[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Can anyone point me to a reference where I might be able to find implementation
details for implementing the CAST5-MAC algorithm?
I have looked at RFC2144 which is the RFC for CAST, but it does not contain details
for implementing the MAC version of CAST.   That is what I am interested in.

If you can be of help, or point me to an appropriate reference/specification I would
be greatful.

Sincerely,
Timothy Fisher
[e-mail]





Received: from poptop.llnl.gov (poptop.llnl.gov [128.115.18.65]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id QAA25206 for <[e-mail]>; Wed, 18 Aug 1999 16:57:42 -0700 (PDT)
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 QAA09384; Wed, 18 Aug 1999 16:58:38 -0700 (PDT)
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.3 (32)
Date: Wed, 18 Aug 1999 16:58:31 -0700
To: "Bob Blakley" <[e-mail]>
From: Tony Bartoletti <[e-mail]>
Subject: Re: What non-repudiation is not and the PA bit, was Re: To Be,or NR To Be ...
Cc: [e-mail]
In-Reply-To: <048801bee9c7$30307b80$[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"

Bob,

Thanks for the explanation regarding SET.

By my understanding, The merchant constructs a token, containing
info that identifies the merchant and a transaction, and that token
is signed by the buyer with a key (certified by the bank?) that
contains nothing more than "belongs to cardholder 92874892983749",
a number that has meaning only to that bank.

So the merchant has no interest in the identity of the keyholder.
Indeed, the merchant has no interest in whether the key used by
the supposed buyer is authentic or not.

Rather, the merchant IS interested in whether the bank will find
the token to be authentic, as the completion of the transaction
is dependent upon it.  I would also suppose that this merchant
would be unhappy to submit such a token, and have a fraudulent
reply (appearing as if from the bank in question) stating that
the token was honored, when in fact it was not.

I assume the merchant has some means to protect themselves from
such an occurance.  Perhaps the bank's reply is signed by the
bank's key, and verified by the merchant.  If so, then this is
the case where the merchant would desire NR, and indeed would
want to be able to prove it in court if the bank were to deny
having issued that response.

If anyone here wanted NR with respect to the buyer, it would be
the bank itself, which I assume would not hand out account
signature keys without some such agreement.  But as Ed has
pointed out, things get a bit simpler when the issuer is
also the verifier.

Am I on the right track?

___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 honcho.austin.dascom.com (email.austin.dascom.com [206.196.73.5]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id QAA24729 for <[e-mail]>; Wed, 18 Aug 1999 16:30:41 -0700 (PDT)
Received: from austin.dascom.com by honcho.austin.dascom.com (8.8.8/SMI-SVR4) id SAA12457; Wed, 18 Aug 1999 18:28:28 -0500 (CDT)
Received: from dascom.com by austin.dascom.com (8.8.8/SMI-SVR4) id SAA11183; Wed, 18 Aug 1999 18:28:26 -0500 (CDT)
Message-ID: <[e-mail]>
Date: Wed, 18 Aug 1999 18:31:47 -0500
From: Ivan Milman <[e-mail]>
X-Mailer: Mozilla 4.61 [en] (WinNT; U)
X-Accept-Language: en
MIME-Version: 1.0
To: [e-mail]
Subject: Re: NR -- what the real issues are, and  a proposal
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Bob J - >>
Bob B - >

>>My proposal is that the text of the nonrepudiation key usage bit I
>>n the PKIX RFC (and hopefully in X.509) be revised to unambiguously
>>state that the defined semantics of this bit is to indicate the willingness
>>of the subscriber to be legally bound by a digital signature which can be
>>verified by a certificate that can be established to have been valid at the
>>time of signature, where "valid" has the normal meaning of not expired, not
>>revoked, etc., etc.

>I think this is a good choice of semantics for the key usage bit, but I have
>some questions about how it's implemented.  Specifically, I want to know
>by whom the bit is going to be set, and on the basis of what assurances.
>You clearly don't want a CA to be creating certs. with this bit set and handing
>them out to people without prior authorization, because if such a cert and
>its corresponding private key got sent to the wrong person for any reason,
>it would be an instrument which could legally bind someone else.  I think people
>are going to want to have a record that they authorized the creation of such
>a liability-bearing instrument -- they might even want to set the bit themselves,
>in some sense.  Perhaps we'd have to look at a two-stage process, whereby
>a non-binding cert would be generated and distributed, and then a request
>for a binding cert would be generated and signed using the non-binding cert...

Presumably the user/RA/CA could archive the CRMF message where the NR bit was
set.

Ivan M. Milman	Technical Director	DASCOM Austin
email:  [e-mail]		Phone:  [phone], ext. 5014


Received: from tomcat.sac.verio.net ([e-mail] [209.162.64.15]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id PAA24121 for <[e-mail]>; Wed, 18 Aug 1999 15:36:36 -0700 (PDT)
Received: from nma.com (pm09-30.sac.verio.net [209.162.65.143]) by tomcat.sac.verio.net (8.9.1a/8.9.1) with ESMTP id PAA08975; Wed, 18 Aug 1999 15:37:29 -0700 (PDT)
Message-ID: <[e-mail]>
Date: Wed, 18 Aug 1999 15:37:28 -0700
From: Ed Gerck <[e-mail]>
X-Mailer: Mozilla 4.61 [en]C-CCK-MCD {Sony}  (Win98; I)
X-Accept-Language: en
MIME-Version: 1.0
To: Bob Blakley <[e-mail]>
CC: Tony Bartoletti <[e-mail]>, Stephen Kent <[e-mail]>, [e-mail], Nicholas Bohm <[e-mail]>, "David P. Kemp" <[e-mail]>, Tod Glassey <[e-mail]>
Subject: Re: What non-repudiation is not and the PA bit, was Re: To Be,or NR To  Be ...
References: <033f01bee9bd$47814ee0$[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Bob Blakley wrote:

> But I disagree that what it is is proof of authentication.  Let me give an
> example.  Imagine that I'm using SET to initiate a transaction with a
> merchant.  SET has a mode in which my name & credit card number
> are not divulged to the merchant -- all the merchant gets is a NR token
> demonstrating to the cardholder's bank (the issuer) that it should pay
> the merchant's bank (the acquirer) the sum listed in the token from the
> account (which the issuer is able to extract from the token).

There are two authentication acts going on, in the above -- not just one.
And, it works because these these two acts form a closed circuit; you
will recognize a flavor of SPKI in it.

What is called the "NR token" above is an "authentication token" that the
merchant can use to demonstrate to the cardholder's bank that it should
perform an act.  This "demonstration" is thus an authentication that
the relying-party (the cardholder's bank) must perform when the token is
received.

In this scenario, when the merchant receives the token, that token has
value exactly because it can be authenticated by the cardholder's
bank -- i.e., it can be corroborated by the cardholder's bank.

But all this would be moot if that value would be repudiated.  Here,
repudiation is avoided by an authorization chain which begins and
ends with the *same* entity -- the token is authorized and issued
by the cardholder's bank and then authenticated by the same.

Since the cardholder's bank is at the same time both the issuer and
the last relying-party, the system works based on the cardholder's
trust that no attacker can produce a token that the cardholder's
bank will mistakenly accept and the trust that no token produced
by the cardholder's bank will be rejected.  This is simplified by the
fact that since that bank is at the same the issuer and the verifier,
there is no limit on the type andd number of authentication proofs
it may require from itself -- it is, basically, a question of risk and
cost, not of denied rights or legal battles.

[paraphrazing]:
Thus, there is *proof* of authentication, there's authentication, and in
fact there's even identification -- since the issuer knows that the token
is identified as of its own making.  Yes, there IS non-repudiation
but not based on any evidence besides that authentication proof --
since here non-repudiation is based on the fact that the bank warrants
its own services to itself, believes its own files and is its own tribunal,
being also its own laws, jury and executioner ;-)

> Finally, I think restricting the definition of non-repudiation to strongly
> non-rebuttable presumptions will tend to discredit the technology, since
> many kinds of transactions require much weaker presumptions.

No, for one it will credit the technology for not making easily rebuttable
declarations about a "non-repudiation service" that is not at all provided
by that technology.

Second, by using the name "proof of authentication", it will allow legal
proof of authentication to be collected and supported by the technology.
How that "proof" is evaluated is a question to be decided by the arbiter
-- a court of law, a supervisor, a comittee, etc.  The "proof" may be
deemed sufficient, insufficient, denied, or illegal. The last three cases,
all possible, do not justify the use of the name non-repudiation -- but
justify the use of the name proof of authentication, because a "proof"
is simply an evidence presented for evaluation (Webster):

proof - evidence operating to determine the finding or judgment of a tribunal.

> Credit-card purchases, for example, are explicitly repudiable after the
> fact and liability of the cardholder (who performs the signature act
> which creates the presumption) is limited to a very small sum - $50
> in the USA.

This is not correct, though a common misconception. Credit-card
purchases are not repudiable for example if there is legal proof that
the goods were ordered, received and used -- for example, a
phone debit card.  They are not repudiable in the case of fraud
by the cardholder, as another example. There are many more.

> This doesn't fall under your definition of non-repudiation,

Yes, it does, for the case that does -- as I cited before: "For
example, when credit card holders agree to non-repudiation
of a US$ 50.00 charge in the event of card fraud. "

> ... in lots of countries that it's not legal under the
> prevailing commercial codes and consumer protection statutes
> to put consumers into positions in which their acts create
> non-rebuttable presumptions with associated liability -- this
> would exclude the use of what you're defining as
> non-repudiation protection in many commercially interesting
> applications in many jurisdictions.

And, in good measure if it does!  But, there are cases where it
is in the interest of the consumer to agree with a non-repudiation
clause -- but, such clause must be very clear: Non-repudiation
is that which allows a truthful denial to be thwarted by a legal
affirmation.  Possibly useful, if properly constrained.

Cheers,

Ed Gerck




Received: from honcho.austin.dascom.com (email.austin.dascom.com [206.196.73.5]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id PAA23707 for <[e-mail]>; Wed, 18 Aug 1999 15:12:51 -0700 (PDT)
Received: from austin.dascom.com by honcho.austin.dascom.com (8.8.8/SMI-SVR4) id RAA12369; Wed, 18 Aug 1999 17:10:38 -0500 (CDT)
Received: from shaggy by austin.dascom.com (8.8.8/SMI-SVR4) id RAA11078; Wed, 18 Aug 1999 17:10:38 -0500 (CDT)
Message-ID: <048801bee9c7$30307b80$[e-mail]>
Reply-To: "Bob Blakley" <[e-mail]>
From: "Bob Blakley" <[e-mail]>
To: "Tony Bartoletti" <[e-mail]>
Cc: <[e-mail]>
Subject: Re: What non-repudiation is not and the PA bit, was Re: To Be,or NR To Be ...
Date: Wed, 18 Aug 1999 17:15:32 -0500
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="----=_NextPart_000_0485_01BEE99D.472077C0"
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

This is a multi-part message in MIME format.

------=_NextPart_000_0485_01BEE99D.472077C0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit

Tony,

>>But I disagree that what it is is proof of authentication.  Let me give an
>>example.  Imagine that I'm using SET to initiate a transaction with a
>>merchant.  SET has a mode in which my name & credit card number
>>are not divulged to the merchant -- all the merchant gets is a NR token
>>demonstrating to the cardholder's bank (the issuer) that it should pay
>>the merchant's bank (the acquirer) the sum listed in the token from the
>>account (which the issuer is able to extract from the token).
>>
>>In this scenario, when the merchant receives the token, not only is
>>there no *proof* of authentication, there's no authentication, and in
>>fact there's not even any identification.  Yet there IS non-repudiation
>>evidence, and the merchant *can* use this evidence.
>
>(I am expert in a different SET theory;)
>
>When you say there is no authentication/(or even identification), I believe
>you must be using these terms in the limited sense "this was demonstrably
>signed by Tony."  I tend to apply the terms authentication and identity
>a bit more broadly, even in the PKI context.
>
>To stick with your example:
>
>1.  Your part in the transaction helps produce the "NR-token".  Ostensibly,
>    I could not produce such a token and present it to the merchant so that
>    your account would be charged.  Thus, your uniqueness must come to bear.

This is correct.  But the merchant doesn't get my identity, or have it proven
to him.
So no authentication has taken place, and nothing is proven (neither
authentication
nor anything else) to the merchant.  Similarly, since authentication didn't
take place,
it isn't proven to the acquirer or the issuer either.

>2.  The merchant receives and can forward this token to (your issuing) bank.
>    The token, or some associated instrument, must convey the identity of
>    the merchant's bank to your bank, so that it will authorize the funds
>    transfer.  Again, ostensibly, this must be a tamperproof process so
>    that the funds cannot be misdirected.
>
>Suppose, in one case, the merchant forwards the SET token, but the bank
>decides (somehow) that this token is forged, and refuses to make payment.
>(How would it ever know, if authentication were not involved?)

In fact it does nothing to authenticate the user.  It simply validates the
token,
checks to see if a credit hold has been put on the account number in the
token, and (if no hold has been placed and the charge is under that account's
remaining credit limit) transfers the funds to the acquirer for credit to the
merchant's account.

>OK, here the transaction would break, the merchant would not deliver the
>goods to you in the first place, so no loss.  Clearly this protocol must
>enforce (merchant/merchant's bank) is satisfied in order for the transaction
>to complete.

The protocol checks the validity of the cert. whose corresponding private key
was used to sign the request.

>Suppose it does, but you never receive the ordered merchandise.  You take
>issue with the merchant, who declares they have never had any dealings
>with you at all.  Where is the evidence that YOU were a party to the
>transaction?

That's a different matter; what you want in that case is a different piece of
NR
evidence, specifically non-repduiation of receipt of the order.

>Alternately, if I were to claim to be the "you" in the transaction, and
>complain that I have not received the promised goods, how might the
>merchant demonstrate that it could not have been me?

Again, that's a different matter.  If the goods were electronic, this dispute
either couldn't arise, or the merchant would simply tell the customer to
cancel his (stolen) credit card number.  If the goods were physical, the
merchant keeps a record of the ship-to address.  If it's correct, then (as
today)
some presumption (if traceable shipping was not requested) governs whether
you were assumed to have received the goods or not.  If it isn't correct, then
again the merchant will probably tell you to take the matter up with your
credit-card issuer, under the assumption that your card has been stolen.

--bob

Bob Blakley ([e-mail])
Chief Scientist, Dascom

------=_NextPart_000_0485_01BEE99D.472077C0
Content-Type: text/x-vcard;
	name="Bob Blakley.vcf"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment;
	filename="Bob Blakley.vcf"

BEGIN:VCARD
VERSION:2.1
N:Blakley;Bob
FN:Bob Blakley
ORG:Dascom
TITLE:Chief Scientist
TEL;WORK;VOICE:[phone] x 5012
TEL;WORK;FAX:[phone]
ADR;WORK;ENCODING=3DQUOTED-PRINTABLE:;;Plaza Balcones=3D0D=3D0A5515 =
Balcones Drive;Austin;TX;78731;USA
LABEL;WORK;ENCODING=3DQUOTED-PRINTABLE:Plaza Balcones=3D0D=3D0A5515 =
Balcones Drive=3D0D=3D0AAustin, TX 78731=3D0D=3D0AUSA
URL:
URL:http://www.dascom.com
EMAIL;PREF;INTERNET:[e-mail]
REV:19990818T221532Z
END:VCARD

------=_NextPart_000_0485_01BEE99D.472077C0--



Received: from poptop.llnl.gov (poptop.llnl.gov [128.115.18.65]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id PAA23395 for <[e-mail]>; Wed, 18 Aug 1999 15:02:48 -0700 (PDT)
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 PAA09946; Wed, 18 Aug 1999 15:03:51 -0700 (PDT)
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.3 (32)
Date: Wed, 18 Aug 1999 15:03:44 -0700
To: "Bob Blakley" <[e-mail]>
From: Tony Bartoletti <[e-mail]>
Subject: Re: What non-repudiation is not and the PA bit, was Re: To Be,or NR To Be ...
Cc: [e-mail]
In-Reply-To: <033f01bee9bd$47814ee0$[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"

At 04:04 PM 8/18/99 -0500, Bob Blakley wrote:

>But I disagree that what it is is proof of authentication.  Let me give an
>example.  Imagine that I'm using SET to initiate a transaction with a
>merchant.  SET has a mode in which my name & credit card number
>are not divulged to the merchant -- all the merchant gets is a NR token
>demonstrating to the cardholder's bank (the issuer) that it should pay
>the merchant's bank (the acquirer) the sum listed in the token from the
>account (which the issuer is able to extract from the token).
>
>In this scenario, when the merchant receives the token, not only is
>there no *proof* of authentication, there's no authentication, and in
>fact there's not even any identification.  Yet there IS non-repudiation
>evidence, and the merchant *can* use this evidence.

(I am expert in a different SET theory;)

When you say there is no authentication/(or even identification), I believe
you must be using these terms in the limited sense "this was demonstrably
signed by Tony."  I tend to apply the terms authentication and identity
a bit more broadly, even in the PKI context.

To stick with your example:

1.  Your part in the transaction helps produce the "NR-token".  Ostensibly,
    I could not produce such a token and present it to the merchant so that
    your account would be charged.  Thus, your uniqueness must come to bear.

2.  The merchant receives and can forward this token to (your issuing) bank.
    The token, or some associated instrument, must convey the identity of
    the merchant's bank to your bank, so that it will authorize the funds
    transfer.  Again, ostensibly, this must be a tamperproof process so
    that the funds cannot be misdirected.

Suppose, in one case, the merchant forwards the SET token, but the bank
decides (somehow) that this token is forged, and refuses to make payment.
(How would it ever know, if authentication were not involved?)

OK, here the transaction would break, the merchant would not deliver the
goods to you in the first place, so no loss.  Clearly this protocol must
enforce (merchant/merchant's bank) is satisfied in order for the transaction
to complete.

Suppose it does, but you never receive the ordered merchandise.  You take
issue with the merchant, who declares they have never had any dealings
with you at all.  Where is the evidence that YOU were a party to the
transaction?

Alternately, if I were to claim to be the "you" in the transaction, and
complain that I have not received the promised goods, how might the
merchant demonstrate that it could not have been me?

Curious.

___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 honcho.austin.dascom.com (email.austin.dascom.com [206.196.73.5]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id OAA22960 for <[e-mail]>; Wed, 18 Aug 1999 14:36:02 -0700 (PDT)
Received: from austin.dascom.com by honcho.austin.dascom.com (8.8.8/SMI-SVR4) id QAA12192; Wed, 18 Aug 1999 16:33:49 -0500 (CDT)
Received: from shaggy by austin.dascom.com (8.8.8/SMI-SVR4) id QAA10908; Wed, 18 Aug 1999 16:33:48 -0500 (CDT)
Message-ID: <03fd01bee9c2$0b08b5c0$[e-mail]>
Reply-To: "Bob Blakley" <[e-mail]>
From: "Bob Blakley" <[e-mail]>
To: "Daniel Finkelstein" <[e-mail]>, <[e-mail]>
Subject: Re: NR -- what the real issues are, and  a proposal
Date: Wed, 18 Aug 1999 16:38:42 -0500
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="----=_NextPart_000_03F9_01BEE998.22005320"
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

This is a multi-part message in MIME format.

------=_NextPart_000_03F9_01BEE998.22005320
Content-Type: multipart/alternative;
	boundary="----=_NextPart_001_03FA_01BEE998.22005320"


------=_NextPart_001_03FA_01BEE998.22005320
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Bob Blakley wrote:=20
    >In addition, I propose that we create an additional indicator of a=20
    >human being's conscious and willful intent to be legally bound by=20
    >a digital signature that would be applied on a message by message=20
    >basis. This additional indicator would require, as an integral part =
of=20
    >its semantic definition, that an explicit computer-to-human =
interaction=20
    >be required to provide some reasonable level of ceremonial and due=20
    >caution warning be provided to the user.  In addition, the =
semantics=20
    >of this indicator should specify that its use must be ENABLED by =
the=20
    >NR bit ( as redefined) in the certificate which includes the =
corresponding=20
    >public key.  If the certificate does not have the bit turned on, =
the=20
    >application is not obligated to request the ceremonial, due caution =

    >approval; and relying party software should ignore a per-message=20
    >indicator even if present in that case.=20
    This is the real crux of the matter and is another good suggestion, =
in my=20
    view.=20
    How we assure that the CHI has taken place is of course a =
theological=20
    discussion...

>Let the lawyers worry about the law. I think we're spinning our wheels =
here. Frankly, we could argue "proof" and "truth" until we're blue in =
the >face, but with each argument we step further away from =
technical/business requirements and closer to legalspeak.=20

I think that was my point (unless I was encouraging theological =
discussions; I can't remember... :-)

--bob

Bob Blakley ([e-mail])
Chief Scientist, Dascom




------=_NextPart_001_03FA_01BEE998.22005320
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD W3 HTML//EN">
<HTML>
<HEAD>

<META content=3Dtext/html;charset=3Diso-8859-1 =
http-equiv=3DContent-Type><!doctype html public "-//w3c//dtd html 4.0 =
transitional//en">
<META content=3D'"MSHTML 4.72.3110.7"' name=3DGENERATOR>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV>Bob Blakley wrote:=20
<BLOCKQUOTE TYPE =3D CITE>&gt;In addition, I propose that we create an=20
    additional indicator of a <BR>&gt;human being's conscious and =
willful intent=20
    to be legally bound by <BR>&gt;a digital signature that would be =
applied on=20
    a message by message <BR>&gt;basis. This additional indicator would =
require,=20
    as an integral part of <BR>&gt;its semantic definition, that an =
explicit=20
    computer-to-human interaction <BR>&gt;be required to provide some =
reasonable=20
    level of ceremonial and due <BR>&gt;caution warning be provided to =
the=20
    user.&nbsp; In addition, the semantics <BR>&gt;of this indicator =
should=20
    specify that its use must be ENABLED by the <BR>&gt;NR bit ( as =
redefined)=20
    in the certificate which includes the corresponding <BR>&gt;public=20
    key.&nbsp; If the certificate does not have the bit turned on, the=20
    <BR>&gt;application is not obligated to request the ceremonial, due =
caution=20
    <BR>&gt;approval; and relying party software should ignore a =
per-message=20
    <BR>&gt;indicator even if present in that case.=20
    <P>This is the real crux of the matter and is another good =
suggestion, in my=20
    <BR>view. <BR>How we assure that the CHI has taken place is of =
course a=20
    theological <BR>discussion...</P></BLOCKQUOTE>&gt;Let the lawyers =
worry about=20
the law. I think we're spinning our wheels here. Frankly, we could argue =

&quot;proof&quot; and &quot;truth&quot; until we're blue in the =
&gt;face, but=20
with each argument we step further away from technical/business =
requirements and=20
closer to legalspeak. </DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face=3D"Goudy Old Style" size=3D2>I think that was my point =
(unless I was=20
encouraging theological discussions; I can't remember... =
:-)</FONT></DIV>
<DIV><FONT color=3D#000000 face=3D"Goudy Old Style" =
size=3D2><BR>--bob</FONT></DIV>
<DIV><FONT color=3D#000000 face=3D"Goudy Old Style" =
size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT color=3D#000000 face=3D"Goudy Old Style" size=3D2>Bob Blakley =
(<A=20
href=3D"mailto:[e-mail]">[e-mail]</A>)<BR>Chief =
Scientist,=20
Dascom</FONT><FONT face=3DArial size=3D2><BR></FONT></DIV>
<BLOCKQUOTE=20
style=3D"BORDER-LEFT: #000000 solid 2px; MARGIN-LEFT: 5px; PADDING-LEFT: =
5px">
    <P>&nbsp;</P></BLOCKQUOTE></BODY></HTML>

------=_NextPart_001_03FA_01BEE998.22005320--

------=_NextPart_000_03F9_01BEE998.22005320
Content-Type: text/x-vcard;
	name="Bob Blakley.vcf"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment;
	filename="Bob Blakley.vcf"

BEGIN:VCARD
VERSION:2.1
N:Blakley;Bob
FN:Bob Blakley
ORG:Dascom
TITLE:Chief Scientist
TEL;WORK;VOICE:[phone] x 5012
TEL;WORK;FAX:[phone]
ADR;WORK;ENCODING=3DQUOTED-PRINTABLE:;;Plaza Balcones=3D0D=3D0A5515 =
Balcones Drive;Austin;TX;78731;USA
LABEL;WORK;ENCODING=3DQUOTED-PRINTABLE:Plaza Balcones=3D0D=3D0A5515 =
Balcones Drive=3D0D=3D0AAustin, TX 78731=3D0D=3D0AUSA
URL:
URL:http://www.dascom.com
EMAIL;PREF;INTERNET:[e-mail]
REV:19990818T213842Z
END:VCARD

------=_NextPart_000_03F9_01BEE998.22005320--



Received: from pub.siac.com (pub.siac.com [162.69.5.194]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id OAA22724 for <[e-mail]>; Wed, 18 Aug 1999 14:31:04 -0700 (PDT)
Received: from bigmouth.siac.com(162.69.5.8) by pub.siac.com via smap (4.1) id xma012952; Wed, 18 Aug 99 17:31:49 -0400
Received: from siac.com (localhost [127.0.0.1]) by charley.wisdom.siac.com (980427.SGI.8.8.8/980728.SGI.AUTOCF) via ESMTP id RAA50281 for <[e-mail]>; Wed, 18 Aug 1999 17:31:42 -0400 (EDT)
Sender: [e-mail]
Message-ID: <[e-mail]>
Date: Wed, 18 Aug 1999 17:31:42 -0400
From: Daniel Finkelstein <[e-mail]>
Organization: Securities Industry Automation Corporation
X-Mailer: Mozilla 4.61C-SGI [en] (X11; U; IRIX 6.5 IP32)
X-Accept-Language: en
MIME-Version: 1.0
To: [e-mail]
Subject: Re: NR -- what the real issues are, and  a proposal
References: <037701bee9be$b751c500$[e-mail]>
Content-Type: multipart/alternative; boundary="------------417A290EF4F85B60A36DFCFE"

--------------417A290EF4F85B60A36DFCFE
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Bob Blakley wrote:

> >In addition, I propose that we create an additional indicator of a
> >human being's conscious and willful intent to be legally bound by
> >a digital signature that would be applied on a message by message
> >basis. This additional indicator would require, as an integral part of
> >its semantic definition, that an explicit computer-to-human interaction
> >be required to provide some reasonable level of ceremonial and due
> >caution warning be provided to the user.  In addition, the semantics
> >of this indicator should specify that its use must be ENABLED by the
> >NR bit ( as redefined) in the certificate which includes the corresponding
> >public key.  If the certificate does not have the bit turned on, the
> >application is not obligated to request the ceremonial, due caution
> >approval; and relying party software should ignore a per-message
> >indicator even if present in that case.
>
> This is the real crux of the matter and is another good suggestion, in my
> view.
> How we assure that the CHI has taken place is of course a theological
> discussion...

Let the lawyers worry about the law. I think we're spinning our wheels here.
Frankly, we could argue "proof" and "truth" until we're blue in the face, but
with each argument we step further away from technical/business requirements and
closer to legalspeak.

We must settle on something that is sufficient for our use (and if lucky,
extensible enough to outgrow it). While the search for perfection is noble, it is
also futile. We'll let perfection be the realm of PhD theses, and functionality
be driven by our businesses.

--
Daniel Alex Finkelstein
New Technologies
phone   [phone]
pager   917-427-1630
fax     [phone]
Securities Industry Automation Corporation



--------------417A290EF4F85B60A36DFCFE
Content-Type: text/html; charset=us-ascii
Content-Transfer-Encoding: 7bit

<!doctype html public "-//w3c//dtd html 4.0 transitional//en">
<html>
Bob Blakley wrote:
<blockquote TYPE=CITE>>In addition, I propose that we create an additional
indicator of a
<br>>human being's conscious and willful intent to be legally bound by
<br>>a digital signature that would be applied on a message by message
<br>>basis. This additional indicator would require, as an integral part
of
<br>>its semantic definition, that an explicit computer-to-human interaction
<br>>be required to provide some reasonable level of ceremonial and due
<br>>caution warning be provided to the user.&nbsp; In addition, the semantics
<br>>of this indicator should specify that its use must be ENABLED by the
<br>>NR bit ( as redefined) in the certificate which includes the corresponding
<br>>public key.&nbsp; If the certificate does not have the bit turned
on, the
<br>>application is not obligated to request the ceremonial, due caution
<br>>approval; and relying party software should ignore a per-message
<br>>indicator even if present in that case.
<p>This is the real crux of the matter and is another good suggestion,
in my
<br>view.
<br>How we assure that the CHI has taken place is of course a theological
<br>discussion...</blockquote>
Let the lawyers worry about the law. I think we're spinning our wheels
here. Frankly, we could argue "proof" and "truth" until we're blue in the
face, but with each argument we step further away from technical/business
requirements and closer to legalspeak.
<p>We must settle on something that is sufficient for our use (and if lucky,
extensible enough to outgrow it). While the search for perfection is noble,
it is also futile. We'll let perfection be the realm of PhD theses, and
functionality be driven by our businesses.
<pre>--&nbsp;
Daniel Alex Finkelstein
New Technologies
phone&nbsp;&nbsp; 212-383-2951
pager&nbsp;&nbsp; 917-427-1630
fax&nbsp;&nbsp;&nbsp;&nbsp; 212-383-3289
Securities Industry Automation Corporation</pre>
&nbsp;</html>

--------------417A290EF4F85B60A36DFCFE--



Received: from honcho.austin.dascom.com (email.austin.dascom.com [206.196.73.5]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id OAA22383 for <[e-mail]>; Wed, 18 Aug 1999 14:12:24 -0700 (PDT)
Received: from austin.dascom.com by honcho.austin.dascom.com (8.8.8/SMI-SVR4) id QAA12052; Wed, 18 Aug 1999 16:10:00 -0500 (CDT)
Received: from shaggy by austin.dascom.com (8.8.8/SMI-SVR4) id QAA10783; Wed, 18 Aug 1999 16:09:59 -0500 (CDT)
Message-ID: <037701bee9be$b751c500$[e-mail]>
Reply-To: "Bob Blakley" <[e-mail]>
From: "Bob Blakley" <[e-mail]>
To: "Bob Jueneman" <[e-mail]>, <[e-mail]>
Subject: Re: NR -- what the real issues are, and  a proposal
Date: Wed, 18 Aug 1999 16:14:53 -0500
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="----=_NextPart_000_0374_01BEE994.CE41C140"
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

This is a multi-part message in MIME format.

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

Bob

>My proposal is that the text of the nonrepudiation key usage bit I
>n the PKIX RFC (and hopefully in X.509) be revised to unambiguously
>state that the defined semantics of this bit is to indicate the willingness
>of the subscriber to be legally bound by a digital signature which can be
>verified by a certificate that can be established to have been valid at the
>time of signature, where "valid" has the normal meaning of not expired, not
>revoked, etc., etc.

I think this is a good choice of semantics for the key usage bit, but I have
some questions about how it's implemented.  Specifically, I want to know
by whom the bit is going to be set, and on the basis of what assurances.
You clearly don't want a CA to be creating certs. with this bit set and
handing
them out to people without prior authorization, because if such a cert and
its corresponding private key got sent to the wrong person for any reason,
it would be an instrument which could legally bind someone else.  I think
people
are going to want to have a record that they authorized the creation of such
a liability-bearing instrument -- they might even want to set the bit
themselves,
in some sense.  Perhaps we'd have to look at a two-stage process, whereby
a non-binding cert would be generated and distributed, and then a request
for a binding cert would be generated and signed using the non-binding cert...

>In addition, I propose that we create an additional indicator of a
>human being's conscious and willful intent to be legally bound by
>a digital signature that would be applied on a message by message
>basis. This additional indicator would require, as an integral part of
>its semantic definition, that an explicit computer-to-human interaction
>be required to provide some reasonable level of ceremonial and due
>caution warning be provided to the user.  In addition, the semantics
>of this indicator should specify that its use must be ENABLED by the
>NR bit ( as redefined) in the certificate which includes the corresponding
>public key.  If the certificate does not have the bit turned on, the
>application is not obligated to request the ceremonial, due caution
>approval; and relying party software should ignore a per-message
>indicator even if present in that case.

This is the real crux of the matter and is another good suggestion, in my
view.
How we assure that the CHI has taken place is of course a theological
discussion...

--bob

Bob Blakley ([e-mail])
Chief Scientist, Dascom

------=_NextPart_000_0374_01BEE994.CE41C140
Content-Type: text/x-vcard;
	name="Bob Blakley.vcf"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment;
	filename="Bob Blakley.vcf"

BEGIN:VCARD
VERSION:2.1
N:Blakley;Bob
FN:Bob Blakley
ORG:Dascom
TITLE:Chief Scientist
TEL;WORK;VOICE:[phone] x 5012
TEL;WORK;FAX:[phone]
ADR;WORK;ENCODING=3DQUOTED-PRINTABLE:;;Plaza Balcones=3D0D=3D0A5515 =
Balcones Drive;Austin;TX;78731;USA
LABEL;WORK;ENCODING=3DQUOTED-PRINTABLE:Plaza Balcones=3D0D=3D0A5515 =
Balcones Drive=3D0D=3D0AAustin, TX 78731=3D0D=3D0AUSA
URL:
URL:http://www.dascom.com
EMAIL;PREF;INTERNET:[e-mail]
REV:19990818T211453Z
END:VCARD

------=_NextPart_000_0374_01BEE994.CE41C140--



Received: from honcho.austin.dascom.com (email.austin.dascom.com [206.196.73.5]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id OAA22149 for <[e-mail]>; Wed, 18 Aug 1999 14:02:15 -0700 (PDT)
Received: from austin.dascom.com by honcho.austin.dascom.com (8.8.8/SMI-SVR4) id PAA11980; Wed, 18 Aug 1999 15:59:43 -0500 (CDT)
Received: from shaggy by austin.dascom.com (8.8.8/SMI-SVR4) id PAA10723; Wed, 18 Aug 1999 15:59:42 -0500 (CDT)
Message-ID: <033f01bee9bd$47814ee0$[e-mail]>
Reply-To: "Bob Blakley" <[e-mail]>
From: "Bob Blakley" <[e-mail]>
To: "Ed Gerck" <[e-mail]>
Cc: "Tony Bartoletti" <[e-mail]>, "Stephen Kent" <[e-mail]>, <[e-mail]>, "Nicholas Bohm" <[e-mail]>, "David P. Kemp" <[e-mail]>, "Tod Glassey" <[e-mail]>
Subject: Re: What non-repudiation is not and the PA bit, was Re: To Be,or NR To Be ...
Date: Wed, 18 Aug 1999 16:04:36 -0500
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="----=_NextPart_000_033C_01BEE993.5E714B20"
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

This is a multi-part message in MIME format.

------=_NextPart_000_033C_01BEE993.5E714B20
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit

Ed,

>In fact, the use of NR may not allow you to prove something to a judge even
>though you present "proof", so I agree with what you say above -- and I
>already did agree with this when I wrote my summary point (1),  that is also
>why I wrote WILL  and not MUST in my sentence: "Only the use of NR
>will allow you to prove  something to a judge".  Please note also that I
wrote
>"the use of NR" because NR is not used alone in your model and I recognize
>that -- there is something that uses NR.

The most important word I was objecting to in your statement
was neither "evidence" nor "proof" -- it's "only".  Lots of things other than
NR evidence allow you to prove things to a judge.

>Your claim, however, is that one needs to use NR (and that is why you defend
its
>need) in order to have the ability to produce legal evidence of user actions.
I can
>read this in one of your other emails:

Again, this isn't quite right.  One *may* use NR to produce legally admissible
evidence, but one does not *need* to use NR -- there are other ways to
produce admissible evidence.

>In fact, I believe your definition of NR is germane for a defintion of "proof
>of authnetication".  And you and others, as well as myself, have several
times
>agreed here that one must not always grant "proof of authentication" rights
to
>the verifier -- or, sometimes, that is simply not possible.  Thus, it is
useful to
>have this feature ON/OFF in a certificate:
>
>But, this NR discussion is far simpler and can be cleared IMO by
>using a denotationally improved name for it: proof of authentication
>-- the PA bit. This is what you  describe and this is what PKIX can
>handle "out of the box" and this is also what ISO tries to describe
>(but irrefutably fails by calling for "irrefutable evidences").  However,
>since IMO the PA bit is useful then it is also useful to make it clear
>-- what you mean by "NR" is actually proof of authentication,
>so ... name it so.

But I disagree that what it is is proof of authentication.  Let me give an
example.  Imagine that I'm using SET to initiate a transaction with a
merchant.  SET has a mode in which my name & credit card number
are not divulged to the merchant -- all the merchant gets is a NR token
demonstrating to the cardholder's bank (the issuer) that it should pay
the merchant's bank (the acquirer) the sum listed in the token from the
account (which the issuer is able to extract from the token).

In this scenario, when the merchant receives the token, not only is
there no *proof* of authentication, there's no authentication, and in
fact there's not even any identification.  Yet there IS non-repudiation
evidence, and the merchant *can* use this evidence.

=========

Finally, I think restricting the definition of non-repudiation to strongly
non-rebuttable presumptions will tend to discredit the technology, since
many kinds of transactions require much weaker presumptions.  Credit-card
purchases, for example, are explicitly repudiable after the fact and liability
of the cardholder (who performs the signature act which creates the
presumption) is limited to a very small sum - $50 in the USA.  This
doesn't fall under your definition of non-repudiation, but is a purpose to
which businesses clearly want to put signature technologies coupled with
what they have come to think of as non-repudiation protection.

It's also the case in lots of countries that it's not legal under the
prevailing
commercial codes and consumer protection statutes to put consumers
into positions in which their acts create non-rebuttable presumptions
with associated liability -- this would exclude the use of what you're
defining
as non-repudiation protection in many commercially interesting applications
in many jurisdictions.

--bob

Bob Blakley ([e-mail])
Chief Scientist, Dascom

------=_NextPart_000_033C_01BEE993.5E714B20
Content-Type: text/x-vcard;
	name="Bob Blakley.vcf"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment;
	filename="Bob Blakley.vcf"

BEGIN:VCARD
VERSION:2.1
N:Blakley;Bob
FN:Bob Blakley
ORG:Dascom
TITLE:Chief Scientist
TEL;WORK;VOICE:[phone] x 5012
TEL;WORK;FAX:[phone]
ADR;WORK;ENCODING=3DQUOTED-PRINTABLE:;;Plaza Balcones=3D0D=3D0A5515 =
Balcones Drive;Austin;TX;78731;USA
LABEL;WORK;ENCODING=3DQUOTED-PRINTABLE:Plaza Balcones=3D0D=3D0A5515 =
Balcones Drive=3D0D=3D0AAustin, TX 78731=3D0D=3D0AUSA
URL:
URL:http://www.dascom.com
EMAIL;PREF;INTERNET:[e-mail]
REV:19990818T210436Z
END:VCARD

------=_NextPart_000_033C_01BEE993.5E714B20--



Received: from tomcat.sac.verio.net ([e-mail] [209.162.64.15]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id NAA21428 for <[e-mail]>; Wed, 18 Aug 1999 13:10:24 -0700 (PDT)
Received: from nma.com (pm09-30.sac.verio.net [209.162.65.143]) by tomcat.sac.verio.net (8.9.1a/8.9.1) with ESMTP id NAA01706; Wed, 18 Aug 1999 13:11:18 -0700 (PDT)
Message-ID: <[e-mail]>
Date: Wed, 18 Aug 1999 13:11:17 -0700
From: Ed Gerck <[e-mail]>
X-Mailer: Mozilla 4.61 [en]C-CCK-MCD {Sony}  (Win98; I)
X-Accept-Language: en
MIME-Version: 1.0
To: Bob Blakley <[e-mail]>
CC: Tony Bartoletti <[e-mail]>, Stephen Kent <[e-mail]>, [e-mail], Nicholas Bohm <[e-mail]>, "David P. Kemp" <[e-mail]>, Tod Glassey <[e-mail]>
Subject: Re: What non-repudiation is not and the PA bit, was Re: To Be,or NR To  Be ...
References: <002c01bee98d$c8eba6e0$[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Bob Blakley wrote:

> Ed Gerck wrote:
> >Reading your paragraph above -- when you talk about NR -- it is clear that
> >you think:
> >
> >1. Only the use of NR will allow you to prove something to a judge
>
> No; I absolutely do NOT think this.  In fact, just the opposite.  NR may NOT
> allow you to prove something to a judge.  It's just evidence, and like all
> evidence has some probative value relative to the charge, the rules of
> evidence, the mood of the judge, etc...

This is a simple confusion. I did not write that the judge will *accept* your
proof.  I wrote that I believe you think that "Only the use of NR will allow
you to prove something to a judge" and this is what you say when you use
the word "evidence" -- above and in your texts. All evidence is presented
with the intent to prove something--  and you present it so that it allows (in
the sense of enablement) you to prove somenthing to the court, the judge,
etc.  In law, no proof is ipso facto and a proof can always be repudiated
(and this is another confusion in terminology of "repudiating proofs" vs.
"non-repudiation of a proof" -- see footnote [1]).

In fact, the use of NR may not allow you to prove something to a judge even
though you present "proof", so I agree with what you say above -- and I
already did agree with this when I wrote my summary point (1),  that is also
why I wrote WILL  and not MUST in my sentence: "Only the use of NR
will allow you to prove  something to a judge".  Please note also that I wrote
"the use of NR" because NR is not used alone in your model and I recognize
that -- there is something that uses NR.

Thus, I believe my sentence captured the essence of what you have been saying
here in regard to "proofs" and the use of NR, as I can also read in your other
emails, for example, as you wrote:

} In a model in which login is subject to NR evidence generation ... you could
} get into lots of situations in which the user's login implies consent or assumes
} liability.

where you employ "NR evidence generation" as a conditional to derive an user's
implied consent or liability -- thus, using NR to derive proofs with potential legal
consequences (if accepted by a court). Or, in the other text you wrote:

} The reason NR is necessary is precisely because the signer
} might deny.  If the signer denies, a dispute exists.  If a dispute exists, it
} is arbitrated by some authority.  The authority has rules of evidence.  Using
} these rules of evidence, the authority examines the NR evidence, which IN NO
} CASE is proof ipso facto, and determines its probative value.  Then, based
} not only on the NR evidence, but ALSO on other evidence and on law and
} perhaps other bases, the arbitrator makes a judgement.

Now, please do note that I do NOT disagree with anything that you wrote in the above
quotes -- I am just showing that they are included in my summary point (1) of
"your" definition of NR and this is fair because this is what you declared NR to be.


> >2.  Only the use of NR will be able to make the user accountable
>
> Again, absolutely not.  Accountability is embedded in some kind of regime.
> In what I call authoritarian regimes, where a single source of authority is
> judge and jury and that source trusts the sysop, an audit log is just fine.
> In other regimes, NR is fine.  In many regimes, NEITHER of these is yet
> considered worthwhile evidence.

You yourself admit above that accountability varies according to the regime
but this does not invalidade my summary of your argument line -- in fact,
strengthens it because I can subsumm all your NR arguments for NR enabling
user accountability under my item (2) above; where "accountable" will be modal
according to each regime.

Thus, when I say that you believe that "Only the use of NR will be able to
make the user accountable", I am saying that in whatever regime the user is
held accountable ("authoritarian", legal, etc.)  you state that NR is needed
in order to provide evidences deemed adequate for each case.

Again, please do note that I do NOT disagree with anything that you wrote in
your quote -- I am just showing that they are included in my summary point (2) of
"your" definition of NR.


> >3. Only the use of NR will provide legal evidence of user actions
>
> Again, I don't think this at all.  Only legal evidence is legal evidence.
>  NR -- or other kinds of technical artifacts -- may or may not be legal
> evidence, depending on the legal system and rules of evidence in use.

This is a simple confusion. The term "legal evidence" is a technical term in
law -- not absolute, but relative to many things. For example, X may be
legal evidence to the defense but the judge may have it removed because it
was submitted after the deadline, or X may be legal evidence to the prosecutor
but the judge may not accept it because the defense successfully claims
conflict of interest, or a witness may provide legal evidence but be descredited
in court, or by a truthful denial that the court accepts, etc.

Your claim, however, is that one needs to use NR (and that is why you defend its
need) in order to have the ability to produce legal evidence of user actions. I can
read this in one of your other emails:

} Nevertheless, none of these things has fundamentally to do with the technical
} aspects of a non-repudation service.  Such a service ought simply to produce
} evidence of a transaction, and ought to have the property that it's easy to
} explain to an adjudicator what must be done in order to successfully forge
} such evidence.  The adjudicator can then decide for himself the probative value
} of the evidence, and whether it's germane to the accusations being made.

And, in your other phrase when you *deny* ("unlikely to be able") the capability to
"prove to a judge" when normal (i.e., not non-repudiable login) is used:

} Why would you want "nonrepudiable login"?  Normally no liability is associated
} with logging in -- it's what you do afterward that creates the liability.  The
} system owner has no interest in holding you accountable for logging  in, and is
} unlikely to be able to prove to a judge that you didn't walk away in the middle of a
} session.

Again, please do note that I do NOT disagree with anything that you wrote in the above
quotes -- I am just showing that they are included in my summary point (3) of
"your" definition of NR.

> >So, these topics can be seen as "definition" of NR -- and you are not alone
> >because this is essentially what the DMS and ISO concepts of NR are all
> >about.  Well, these topics are all false in regard to non-repudiation, so
> that NR <> non-repudiation.
>
> This *isn't* what the ISO definition of "NR" is!  The ISO definition is a
> technical definition of a service which produces evidence tokens associated with
> certain kinds of requests.  Whether what this service provides is admissible
> in any court whatsoever, or what its probative value is, is not addressed AT
> ALL in the ISO specs.

And, yet the ISO specs do (though you don't, and I granted you that
improvement)-- when they mention "irrefutable evidence" (a well-intentioned
fiction of an absolute probative value).  You clearly stayed away from that slippery
slope of evaluating a proof -- which PKIX and X.509 have however followed
when they mention "falsely denying" and thus included intent and proof
evaluation in a protocol over the wire.

Note also that I agree 100% with all your explanations on NR -- I see nothing that
I would change in them either!

So, what are discussing about?

Because IMO your definition of NR (as well as ISO's) is NOT what one
considers to be non-repudiation (and this is the point around which we spin
here) [2].  So, I disagree not with your definition of NR but when you (following
ISO precedent, however) equate this technical concept of NR with the legal and
business concept of non-repudiation.

In fact, I believe your definition of NR is germane for a defintion of "proof
of authnetication".  And you and others, as well as myself, have several times
agreed here that one must not always grant "proof of authentication" rights to
the verifier -- or, sometimes, that is simply not possible.  Thus, it is useful to
have this feature ON/OFF in a certificate:

- do you want a certificate that will be used in all transactions for which you agree
beforehand that proof of authentication can be collected and eventually used to
provide evidences of such authentication?

And, exactly because this authorization is granted *beforehand* and such is
strongly (crypto sense) affirmed in the certificate itsefl by setting a PA
(proofOfAuthentication) bit -- that it is legally admissable as evidence.

Otherwise, one might even argue (and, declare with full legal support
worldwide by  Intellectual Property law) that anything signed with a
private-key and the signature itself are documents (a string of bytes) that are
copyrighted at the moment they are made tangible (just like this email is)
and thus cannot be used by a third-party unless the copyright owner so
authorizes, and for the authorized purposes.  And, if the authentication
spec or the CPS says that nothing signed with that PA bit OFF can be
used as evidence in any way -- so it is effectively denied.

Now, non-repudiation is a different subject altogether [1].
Non-repudiation is that which allows a truthful denial to be
thwarted by a legal affirmation [2], hence the extreme care
this matter must be handled.

But, this NR discussion is far simpler and can be cleared IMO by
using a denotationally improved name for it: proof of authentication
-- the PA bit. This is what you  describe and this is what PKIX can
handle "out of the box" and this is also what ISO tries to describe
(but irrefutably fails by calling for "irrefutable evidences").  However,
since IMO the PA bit is useful then it is also useful to make it clear
-- what you mean by "NR" is actually proof of authentication,
so ... name it so.

BTW, that is why I said I was sorry to use your text as an example of
what non-repudiation is not -- because I think that your text is useful
and clear on what PA is.

Cheers,

Ed Gerck

[1] Non-repudiation provides for means (e.g., a contract) which
preempts repudiation claims if certain criteria are met.  However,
non-repudiation can be repudiated either by disproving assumptions
supposed to exist (e.g., that the contract is legal) or by proving acts
supposed to be absent (e.g., a tort).  Aside from these two possibilities,
non-repudiation can be enforced according to the criteria agreed
to in the contract and cannot be repudiated, hence its name.

[2] The evaluation whether an act can be truthfully denied is
irrelevant if that act falls under non-repudiation [1] -- the only
thing that matters is that the act *reached* the relying-party, not
who did it or how it was done.  For example, when credit card
holders agree to non-repudiation of a US$ 50.00 charge in the
event of card fraud.  And this is oftentimes acceptable even
under the legal doctrine of "mens rea" and the excuses the
law admit, which reflect the fundamental moral principle that a
person is not to be blamed for what he has done if he could not
help doing it, because the law concentrates on cognitive elements
in responsibility, rather than on the defects of volition or will -- it
is presumed that if a man knows what he is doing then he has the
capacity to adjust his behaviour to the contractual requirements.



Received: from ext-mail.valicert.com (ns1.valicert.com [63.65.221.10]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id MAA21149 for <[e-mail]>; Wed, 18 Aug 1999 12:56:36 -0700 (PDT)
Received: from int-mail.valicert.com (corporate-gw.valicert.com [63.65.221.2]) by ext-mail.valicert.com (8.9.3/8.9.3) with ESMTP id MAA24331; Wed, 18 Aug 1999 12:57:30 -0700 (PDT)
Received: from rsalaptop ([192.168.3.230]) by int-mail.valicert.com (8.9.3/8.9.3) with SMTP id MAA16710; Wed, 18 Aug 1999 12:56:59 -0700 (PDT)
From: "Peter Williams" <[e-mail]>
To: "Stephen Kent" <[e-mail]>, "Tony Bartoletti" <[e-mail]>
Cc: <[e-mail]>
Subject: RE: To Be, or NR To Be ...
Date: Wed, 18 Aug 1999 12:58:06 -0700
Message-ID: <000001bee9b3$fd4b4960$[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
Importance: Normal
In-Reply-To: <v04020a00b3e0715c457c@[128.89.0.110]>
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300

A number of conclusions are emerging. I present
some facts to substantiate them. I suggest
a change to PKIX-QC.

(a) strong authentication during entity authentication (login)
is very useful. It may prove that one trespasses on an information
resource, regardless of what one damages during
the act of trespass. The availability
of NR on that security service is as useful to
information owners as proof of origin of interpersonal
messages is to msg recipients.  IPSEC Client, and SSL
client Auth, when applied to network applications such
as VPNs and https, both support login. Should the packets be
stored (as all American ISPs are now required to
do for 180 days by the US authorities to allow for
surveillance and prosecution of Americans), non-repudiation
services in these contexts should be recognized by PKIX to
potentially prevent denial of the act of network/resource
login/trespass.

Therefore, the NR bit should be allowed
in IPSEC client, and SSL Client auth certs, where the
extended keyusage extension is suitably set
for those application contexts. 2459 does not support this
legitimate NR application, and it clearly should. When PKIX-QC
name-constrained certs are used, furthermore in this
context, such signature devices may meet CEC
directive requirements, additionally.

(b) Today, a Korean name was affixed to a pkix mailing
list memo.  My browser popped up a dialogue, enabling
me to download software to display that name in the
character set of native speaker. Removal of enforced
US-English cultural imperialism is a nice internet-centric
direction, IMO! The software was  protected via the
Authenticode application, featuring
a PKCS7 digital signature msg & 2459-conforming certificates.
The signature has been timestamped, records kept, and the CA
highly audited to rigorous standards following PKIX-IV.  PKIX
2459 does not allow that signature maker (software publisher)
to enable users to use a NR service for that act. Why
not? Clearly PKIX is insufficient, and not consistent
with its technical NR model, and application focus now
admitted.

My conclusion is, that to embrace the technical NR
model being advanced in Steve's mail, we could
should mandate in PKIX-QC a model in which two existing
extensions must be used in collaboration when dealing
with NR: the keyusage NR bit can signal what Steve
asserts, and the extended key usage  bit can label
the necessary application context. (IPSEC
Client, for example). Authenticode can fit into this
scheme, simply by defining itself an extended key
usage OID. (One notes that other Publisher security
services have already adopted this scheme, and the
Internet's PKIX-like public CA PKIs works just fine;
working code (deployed worldwide) can be shown, if
needed.)

To cut through to the changes necessary to address this
discussion thread, PKIX-QC might incorporate the
rule discussed above; it is limited to technical
matters, and does not address policy matters, or
regulatory environments. It does link NR to applications.

As most US state laws specifically do not provide recognition
for the highest grade of personal signature (those on wills for
example) where NR value is most recognized by consumers,
bringing PKIX into line with a world in which NR bit is made
inherently  application sensitive would move use forward both
architecturally, and to properly address such as the
Authenticode PKI security  services actually used by tens
of thousands of people  each and every day. For free, the FBI
can also use those same Internet packets to prosecute people for spreading
viruses, or trespassing - with less chance they can repudiate the technical
evidence.

Peter.


> -----Original Message-----
> From: Stephen Kent [mailto:[e-mail]]
> Sent: Wednesday, August 18, 1999 7:25 AM
> To: Tony Bartoletti
> Cc: [e-mail]
> Subject: Re: To Be, or NR To Be ...
>
>
> Tony,
>
> >I don't claim to be expert on all the existing protocols.  But certainly
> >there could arise protocols that provide for crypto-strength throughout.
> >In such a case, it would seem that an "NR-authentication" might
> be required
> >at the outset of the session, else the chain has no anchors.
>
> Usually, we provide NR only in the context of a specific application,
> because the semantics of the application are an important part of NR.
> Since one does all sorts of things during a "login session" it may be less
> appropriate to suppoort NR at the Telnet level.  However, I don't dispute
> your suggestion that it might be possible to fashion NR at this
> granularity.
>
> >But the entire discussion is still confused, I believe, by the often
> >unspoken distinction between "repudiating that you took some action"
> >versus "repudiating that you did so intentionally, understood your
> >exposure to liability, etc."
>
> Agreed.
>
> >If I can be assured, by whatever means, that you are the sole-wielder
> >of a private key, then the existence of its signature on any object
> >(login-token or mortgage contract) assures me that it was you that
> >interacted with said object so to affix signature.  And no NR-bit
> >is required to make "the fact" of this signature "non-repudiable"
> >(modulo current mathematical strengths).
>
> No, the NR bit is not intrinsically required for this from a purely
> crypto-technical perspective.
>
> >It is only when NR hopes to manage "intent" or "knowing liability"
> >that it has any additional force.  But here, I have yet to understand
> >how its setting, protocol-wise, helps to effect this end.  It may
> >help in precluding key use in "lightweight or automatic" operations,
> >authentications, it is true.  But of what value?  If these lightweight
> >operations are less interested in NR, why employ keys that are
> >"identity-certified" at all?
>
> I do think that precluding key use in these non-NR contexts is valuable,
> for the reasons I cited earflier, e.g., such apps might permit acquisition
> of signatures on hashes for data the user has never had access to.
>
> >If I want to be sure that its "really really" you, then why should I
> >not want the ability to establish later, in court if necessary, that
> >it was "really really" you, (independent of your intent or actions)?
>
> It's a two-way street.  If all communicationm we engage in was
> non-repudiable, some of that communication would never take place; the
> political characterization is "plausible deniability."  So, sometimes I
> NEED to authenticate myself to gain access to a resourec, but
> that does not
> mean that I want to make use of NR-capable protocols for the interaction.
>
> Steve
>



Received: from poptop.llnl.gov (poptop.llnl.gov [128.115.18.65]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id LAA20252 for <[e-mail]>; Wed, 18 Aug 1999 11:44:23 -0700 (PDT)
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 LAA27836; Wed, 18 Aug 1999 11:45:24 -0700 (PDT)
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.3 (32)
Date: Wed, 18 Aug 1999 11:45:17 -0700
To: [e-mail] (Tom Gindin)
From: Tony Bartoletti <[e-mail]>
Subject: Re: What non-repudiation is not and the PA bit, was Re: To Be, or NR To Be ...
Cc: [e-mail]
In-Reply-To: <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"

At 02:00 PM 8/18/99 -0400, [e-mail] wrote:
>     Does most of the group agree that it is true of the nonRepudiation service
>that:
>
>     It is required by the NR service that a digital signature be associated
>with the object signed (or an unambiguous reference to it) and with the signer's
>certificate (or an unambiguous reference to it) in such a way that an
>independent verifier can later verify whether the signature is a valid one for
>the indicated object using the certified key.

That really depends upon what one means by "can later verify" and by
"valid for the indicated object".

I think "independent verification" is a theme common to most of the
discussion (some may have other views;)

Most folks take "can later verify" to mean that the relevant objects (certs,
CRLs, etc) have been sufficiently archived/timestamped/notarized/whatever
so that later (mechanical) digital signature verifications have meaning.
I assume this would be a component of most NR-thingies.

But "valid for the indicated object" conjures up a zoo of possibilities.
How many "types" of object might require their own unique "valid-for"
conditions?  And is it reasonable to work from the assumption that a
one-shot (cert-bit + CP/CPS) combo will be sufficient to identify that
particular object's "valid-for" conditions, and whether they have indeed
been met?

Might I need a key that says "indicates user awareness of liability",
another that says "may be used as evidence", and another that says
"establishes a non-rebuttable presumption"?  Might I be required to
sign some "legal" objects with multiple keys?  And is the simple
identification of "proper-key-type" sufficient, or must some kind
of "witness signatures" be required, to afford certain transactions?

>     If so, then the debate we have been having is about whether that condition
>is sufficient to characterize the NR service as well as necessary to do so.
>Furthermore, the set of data formats which facilitate meeting this requirement
>includes some well-known formats such as CMS SignerInfo and (in the future) XML
>Digital Signatures.
>
>          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 poptop.llnl.gov (poptop.llnl.gov [128.115.18.65]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id LAA19854 for <[e-mail]>; Wed, 18 Aug 1999 11:20:09 -0700 (PDT)
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 LAA07473; Wed, 18 Aug 1999 11:11:14 -0700 (PDT)
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.3 (32)
Date: Wed, 18 Aug 1999 11:11:07 -0700
To: "Bob Blakley" <[e-mail]>, "Ed Gerck" <[e-mail]>
From: Tony Bartoletti <[e-mail]>
Subject: Re: What non-repudiation is not and the PA bit, was Re: To Be, or NR To Be ...
Cc: <[e-mail]>
In-Reply-To: <002c01bee98d$c8eba6e0$[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"

Bob and Ed,

Well,  For all of the apparent disagreement, it does seem that a kind of
common ground has been reached.  Namely, a distinction between several
kinds of so-called "non-repudiation" assertion:

1.  NR = declaration of non-rebuttable presumption

2.  "NR" (PA) = proof of authenticity

3.  NR = assent to legal context

Unfortunately, the terms may vary in meaning according to context and
perhaps political system.  So it might be best to try and characterize,
for each of these three assertions (at least) according to several
salient features.  For instance, does the signer control "x" on a
per-key or per-signature basis? (I'm certain Ed can list others:)

It is somewhat a waste of time to try and define exactly "what is proof",
since as Bob points out, it is essentially determined by trial outcome.

More to the point, it needs to be determined for which, if any, of these
meanings/usages a single cert-bit is a sufficient indicator (cert CPS
notwithstanding.)  In other words, when are we trying to accomplish
with a cert-bit, that which really requires a constellation of lesser
transactions to establish?  In the same way that traditional "contract
signature" involves the ceremony of multi-party presence/witness,
perhaps an "I meant to do this" protocol, involving multiple parties,
needs to be invoked as a component of digital contract signature.

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 e4.ny.us.ibm.com (e4.ny.us.ibm.com [32.97.182.104]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id LAA19479 for <[e-mail]>; Wed, 18 Aug 1999 11:02:07 -0700 (PDT)
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 OAA84538; Wed, 18 Aug 1999 14:02:10 -0400
Received: from D51MTA05.pok.ibm.com (d51mta05.pok.ibm.com [9.117.200.33]) by northrelay02.pok.ibm.com (8.8.8m2/NCO v2.04) with SMTP id OAA275550; Wed, 18 Aug 1999 14:02:09 -0400
Received: by D51MTA05.pok.ibm.com(Lotus SMTP MTA v4.6.4  (830.2 3-23-1999))  id 852567D1.0063085E ; Wed, 18 Aug 1999 14:01:42 -0400
X-Lotus-FromDomain: IBMUS
To: "Bob Blakley" <[e-mail]>
cc: "Ed Gerck" <[e-mail]>, "Tony Bartoletti" <[e-mail]>, "Stephen Kent" <[e-mail]>, [e-mail], "Nicholas Bohm" <[e-mail]>, "David P. Kemp" <[e-mail]>, "Tod Glassey" <[e-mail]>
Message-ID: <[e-mail]>
Date: Wed, 18 Aug 1999 14:00:38 -0400
Subject: Re: What non-repudiation is not and the PA bit, was Re: To Be, or NR To Be ...
Mime-Version: 1.0
Content-type: text/plain; charset=us-ascii
Content-Disposition: inline

     Does most of the group agree that it is true of the nonRepudiation service
that:

     It is required by the NR service that a digital signature be associated
with the object signed (or an unambiguous reference to it) and with the signer's
certificate (or an unambiguous reference to it) in such a way that an
independent verifier can later verify whether the signature is a valid one for
the indicated object using the certified key.

     If so, then the debate we have been having is about whether that condition
is sufficient to characterize the NR service as well as necessary to do so.
Furthermore, the set of data formats which facilitate meeting this requirement
includes some well-known formats such as CMS SignerInfo and (in the future) XML
Digital Signatures.

          Tom Gindin




Received: from honcho.austin.dascom.com (email.austin.dascom.com [206.196.73.5]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id IAA17128 for <[e-mail]>; Wed, 18 Aug 1999 08:22:06 -0700 (PDT)
Received: from austin.dascom.com by honcho.austin.dascom.com (8.8.8/SMI-SVR4) id KAA10881; Wed, 18 Aug 1999 10:19:46 -0500 (CDT)
Received: from shaggy by austin.dascom.com (8.8.8/SMI-SVR4) id KAA09747; Wed, 18 Aug 1999 10:19:43 -0500 (CDT)
Message-ID: <002c01bee98d$c8eba6e0$[e-mail]>
Reply-To: "Bob Blakley" <[e-mail]>
From: "Bob Blakley" <[e-mail]>
To: "Ed Gerck" <[e-mail]>
Cc: "Tony Bartoletti" <[e-mail]>, "Stephen Kent" <[e-mail]>, <[e-mail]>, "Nicholas Bohm" <[e-mail]>, "David P. Kemp" <[e-mail]>, "Tod Glassey" <[e-mail]>
Subject: Re: What non-repudiation is not and the PA bit, was Re: To Be, or NR To Be ...
Date: Wed, 18 Aug 1999 10:24:37 -0500
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="----=_NextPart_000_0029_01BEE963.DFDBA320"
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

This is a multi-part message in MIME format.

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

Ed,

--bob

Bob Blakley ([e-mail])
Chief Scientist, Dascom

>Reading your paragraph above -- when you talk about NR -- it is clear that
>you think:
>
>1. Only the use of NR will allow you to prove something to a judge


No; I absolutely do NOT think this.  In fact, just the opposite.  NR may NOT
allow you to prove something to a judge.  It's just evidence, and like all
evidence has some probative value relative to the charge, the rules of
evidence, the mood of the judge, etc...

>2.  Only the use of NR will be able to make the user accountable


Again, absolutely not.  Accountability is embedded in some kind of regime.
In what I call authoritarian regimes, where a single source of authority is
judge and jury and that source trusts the sysop, an audit log is just fine.
In other regimes, NR is fine.  In many regimes, NEITHER of these is yet
considered worthwhile evidence.

>3. Only the use of NR will provide legal evidence of user actions


Again, I don't think this at all.  Only legal evidence is legal evidence.
 NR -- or
other kinds of technical artifacts -- may or may not be legal evidence,
depending
on the legal system and rules of evidence in use.

>So, these topics can be seen as "definition" of NR -- and you are not alone
>because this is essentially what the DMS and ISO concepts of NR are all
>about.  Well, these topics are all false in regard to non-repudiation, so
that
>NR <> non-repudiation.


This *isn't* what the ISO definition of "NR" is!  The ISO definition is a
technical
definition of a service which produces evidence tokens associated with
certain kinds of requests.  Whether what this service provides is admissible
in any court whatsoever, or what its probative value is, is not addressed AT
ALL
in the ISO specs.

>But, this is not the main problem. The main problem is that you did not even
>talk about non-repudiation!  In your entire text, the notion of
non-repudiation
>did not appear even once.
>
>Contrary to what Steve Kent believes, there is a very clear idea in business
>and banking about what non-repudiation is.  What those sectors do not know
>is how to represent that in a reasonable fashion in security protocols --
and,
>thank God they don't ;-)  So, how about we trying to find out how to do it
>before they do it?
>
>Oftentimes, a word is used just to satisfy a market need -- and, surely, we
can
>read press-releases of security companies that currently deliver products
with
>"non-repudiation" and at least one company even went as far as declaring that
>it delivered products that offered "true non-repudiation".  Isn't this the
same as
>those "FREE" offers we read all the time? We all know it ain't FREE, so it
>simply does not work after a while.  But, is this what we want?
>
>To be fair, the motivation for the NR definition is a laudable one (contrary
>to many of those FREE offers).  Indeed, this definition of NR reflects a
concern
>to improve security and it also recognizes that an element of proof is needed
.
>
>Where it fails is that it follows a common non-lawyer approach to solve a
>legal issue -- non-lawyers believe that if they explain something "really
well"
>and provide "strong proof" then they will have a fat chance to win in court.
>It is all a drive forward, a positive assertion -- more files, more logs,
more
>crypto keys, more digital signatures.  So, NR as you use it (and you are not
>alone) is simply proof of authentication.  But, never non-repudiation.


No, no, no and no.  None of this has anything whatsoever to do with what I
think of as NR, and I'm not laboring under even a single one of the
misapprehensions
you describe.  I understand rules of evidence and admissibility quite well, in
fact,
and I know a lot about the circumstances under which logs, files, keys, and
signatures are admissible, relevant, and probative.

Furthermore, what I describe has nothing whatsoever to do with authentication.

>Why? Because non-repudiation needs to be deniable a priori in order to be
>legally valid -- yes, and please do not change my word "deny" to "refuse" ;-)
>Because non-repudiation is a "two-prong test" [*] that allows a relying-party
to
>thwart a truthful denial (made a posteriori) with a legal affirmation (made a
>priori).  Because if it does not allow all this, then it is not
non-repudiation.


What you describe is called (in the US anyway) presumption, not
non-repudiation.
Actions can create a presumption, and the presumption may or may not be
rebuttable by certain arguments or evidences.  To translate into terms I've
heard
used, what you're saying is that

    business non-repudiation is the creation of a non-rebuttable presumption,
binding upon
    an initiating party, which a relying party can use to hold the intitiating
party to some
    stated liability even if the intiating party truthfully denies having been
the actual
    initiator of the action in question.

Such a thing is useful in some contexts but is certainly not the only, or even
perhaps the
preferred, definition of non-repudiation.  It's quite important to note that
the legal system
isn't going to allow automated processes to create these sorts of
presumptions - actions
of humans are going to be what creates presumptions like these, and a
non-repudiation
service's function in a situation like this is probably going to be (exactly
as I've stated
several times already) to record evidence of the action which created the
presumption
in a way which makes it difficult to forge or alter the evidence.

>And please note what I say above. That even the strongest of proofs
>(more files, more logs, more keys, more signatures, better timestamps,
>better whatever you want) made afterwards to a judge is powerless
>against a legal affirmation made a priori -- when non-repudiation is
>either correctly applied or denied.   Thus, the non-lawyer approach
>must fail in either case.


This is the case only if the presumption created is non-rebuttable.  Most
aren't.
In the US legal system, which allows trial by jury even in civil cases in many
instances, it's NEVER the case that proofs are powerless, because of
jury nullification (the ability of the jury to render any verdict it chooses
even if
the evidence and the law indicate that a different verdict should be reached).

Where we agree is that the non-lawyer approach must fail.

>That is why a change of heart is needed.  What DMC, PKIX and ISO
>have been calling "non-repudiation" simply is not non-repudiation -- is
>proof of authentication.


Wrong on both counts, in my opinion.

>And, maybe this is one way out of this corner were are all painted in.   We
>may change the current NR bit name to "PA bit" -- proofOfAuthentication
>bit. In a rather humorous rendering:
>
>- We hereby declare that when the proofOfAuthentication bit is asserted in a
>  certificate, any  message signed with the certificate can be used as legal
>  proof against us, but not otherwise.


Except that the name is completely wrong, this is essentially what's being
advocated on the list, I believe.

>But, I suggest to indeed add a non-repudiation bit -- exactly because
>non-repudiation is NOT the same as authentication, or strong authentication,
>or proof of authentication.  Non-repudiation and authentication are
>complement operations (technically speaking, reference upon request). As
>I wrote earlier, my suggestion to define non-repudiation in PKIX is that
>the text would negate any semantics to the non-repudiation bit beyond its own
>syntactic expression as a boolean bit, while defining non-repudiation as
>a qualified pointer (i.e., avoiding the dangling clause problem):
>
>1'. Non-repudiation is defined in the CPS and its usage is asserted by
setting the
>nonRepudiation bit.
>
>I also suggest to follow Tony's comment and define all other usage bits that
are
>not taken, calling them by generic names (say, in a humorous tone, Green,
Red,
>Blue):
>
>- The Green service is defined in the CPS and its usage is asserted by
setting the
>  green bit.
>
>etc.
>
>Thus, what some sectors of the security community have felt a need to express
>(and, with which need I agree), will be well represented by the PA bit. This
>includes some needs previously expressed by Dave Kemp as the "XYZ" bit.
>Thus,  marketing materials can say that a product offers "true proof of
>authentication" without a  second thought (if, indeed, it does, of course).
>
>Likewise, what some sectors of the business community have felt a need to use
>and apply as non-repudiation will be well represented by the non-repudiation
bit
>in support of such (future?) uses.
>
>And, other special services will be available as flagged by the R,G,B bits.
>
>Comments?
>
>Cheers,
>
>Ed Gerck
>
>[*] defined here in some of my messages.
>
>

------=_NextPart_000_0029_01BEE963.DFDBA320
Content-Type: text/x-vcard;
	name="Bob Blakley.vcf"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment;
	filename="Bob Blakley.vcf"

BEGIN:VCARD
VERSION:2.1
N:Blakley;Bob
FN:Bob Blakley
ORG:Dascom
TITLE:Chief Scientist
TEL;WORK;VOICE:[phone] x 5012
TEL;WORK;FAX:[phone]
ADR;WORK;ENCODING=3DQUOTED-PRINTABLE:;;Plaza Balcones=3D0D=3D0A5515 =
Balcones Drive;Austin;TX;78731;USA
LABEL;WORK;ENCODING=3DQUOTED-PRINTABLE:Plaza Balcones=3D0D=3D0A5515 =
Balcones Drive=3D0D=3D0AAustin, TX 78731=3D0D=3D0AUSA
URL:
URL:http://www.dascom.com
EMAIL;PREF;INTERNET:[e-mail]
REV:19990818T152437Z
END:VCARD

------=_NextPart_000_0029_01BEE963.DFDBA320--



Received: from po1.bbn.com (PO1.bbn.com [192.1.50.38]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id HAA15909 for <[e-mail]>; Wed, 18 Aug 1999 07:25:46 -0700 (PDT)
Received: from [128.89.0.110] (COSMEC.BBN.COM [128.89.0.110]) by po1.bbn.com (8.9.1/8.9.1) with ESMTP id KAA07758; Wed, 18 Aug 1999 10:26:29 -0400 (EDT)
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
X-Sender: [e-mail]
Message-Id: <v04020a00b3e0715c457c@[128.89.0.110]>
In-Reply-To: <[e-mail]>
References: <v04020a16b3df92b9f0bd@[128.89.0.110]> <[e-mail]> <v04020a0db3df6342c8eb@[128.89.0.110]> <[e-mail]>
Date: Wed, 18 Aug 1999 10:25:19 -0400
To: Tony Bartoletti <[e-mail]>
From: Stephen Kent <[e-mail]>
Subject: Re: To Be, or NR To Be ...
Cc: [e-mail]

Tony,

>I don't claim to be expert on all the existing protocols.  But certainly
>there could arise protocols that provide for crypto-strength throughout.
>In such a case, it would seem that an "NR-authentication" might be required
>at the outset of the session, else the chain has no anchors.

Usually, we provide NR only in the context of a specific application,
because the semantics of the application are an important part of NR.
Since one does all sorts of things during a "login session" it may be less
appropriate to suppoort NR at the Telnet level.  However, I don't dispute
your suggestion that it might be possible to fashion NR at this granularity.

>But the entire discussion is still confused, I believe, by the often
>unspoken distinction between "repudiating that you took some action"
>versus "repudiating that you did so intentionally, understood your
>exposure to liability, etc."

Agreed.

>If I can be assured, by whatever means, that you are the sole-wielder
>of a private key, then the existence of its signature on any object
>(login-token or mortgage contract) assures me that it was you that
>interacted with said object so to affix signature.  And no NR-bit
>is required to make "the fact" of this signature "non-repudiable"
>(modulo current mathematical strengths).

No, the NR bit is not intrinsically required for this from a purely
crypto-technical perspective.

>It is only when NR hopes to manage "intent" or "knowing liability"
>that it has any additional force.  But here, I have yet to understand
>how its setting, protocol-wise, helps to effect this end.  It may
>help in precluding key use in "lightweight or automatic" operations,
>authentications, it is true.  But of what value?  If these lightweight
>operations are less interested in NR, why employ keys that are
>"identity-certified" at all?

I do think that precluding key use in these non-NR contexts is valuable,
for the reasons I cited earflier, e.g., such apps might permit acquisition
of signatures on hashes for data the user has never had access to.

>If I want to be sure that its "really really" you, then why should I
>not want the ability to establish later, in court if necessary, that
>it was "really really" you, (independent of your intent or actions)?

It's a two-way street.  If all communicationm we engage in was
non-repudiable, some of that communication would never take place; the
political characterization is "plausible deniability."  So, sometimes I
NEED to authenticate myself to gain access to a resourec, but that does not
mean that I want to make use of NR-capable protocols for the interaction.

Steve


Received: from netwk.hannam.ac.kr (netwk.hannam.ac.kr [203.247.39.32]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id AAA05901 for <[e-mail]>; Wed, 18 Aug 1999 00:35:42 -0700 (PDT)
Received: from hanjin (hanjin.hannam.ac.kr [203.247.39.68]) by netwk.hannam.ac.kr (8.9.3/8.9.3) with SMTP id QAA00369 for <[e-mail]>; Wed, 18 Aug 1999 16:34:25 +0900 (KST)
Message-ID: <01e901bee94c$4acd56f0$[e-mail]>
From: =?ks_c_5601-1987?B?wbbH0cH4?= <[e-mail]>
To: <[e-mail]>
Subject: 
Date: Wed, 18 Aug 1999 16:34:02 +0900
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_01E6_01BEE997.7ABCA730"
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_01E6_01BEE997.7ABCA730
Content-Type: text/plain;
	charset="ks_c_5601-1987"
Content-Transfer-Encoding: base64

dW5zdWJzY3JpYmUgaGpjaG9AbmV0d2suaGFubmFtLmFjLmtyDQo=

------=_NextPart_000_01E6_01BEE997.7ABCA730
Content-Type: text/html;
	charset="ks_c_5601-1987"
Content-Transfer-Encoding: base64

PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDQuMCBUcmFuc2l0aW9uYWwv
L0VOIj4NCjxIVE1MPjxIRUFEPg0KPE1FVEEgY29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PWtz
X2NfNTYwMS0xOTg3IiBodHRwLWVxdWl2PUNvbnRlbnQtVHlwZT4NCjxNRVRBIGNvbnRlbnQ9Ik1T
SFRNTCA1LjAwLjIzMTQuMTAwMCIgbmFtZT1HRU5FUkFUT1I+DQo8U1RZTEU+PC9TVFlMRT4NCjwv
SEVBRD4NCjxCT0RZIGJnQ29sb3I9I2ZmZmZmZj4NCjxESVY+PEZPTlQgc2l6ZT0yPnVuc3Vic2Ny
aWJlIA0KaGpjaG9AbmV0d2suaGFubmFtLmFjLmtyPC9GT05UPjwvRElWPjwvQk9EWT48L0hUTUw+
DQo=

------=_NextPart_000_01E6_01BEE997.7ABCA730--



Received: from www.meridianus.com (209.249.223.38.has.no.reverse [209.249.223.38] (may be forged)) by mail.proper.com (8.9.3/8.9.3) with ESMTP id WAA00289 for <[e-mail]>; Tue, 17 Aug 1999 22:20:40 -0700 (PDT)
Received: from PC1 by www.meridianus.com (8.8.8+Sun/SMI-SVR4) id XAA09226; Tue, 17 Aug 1999 23:15:17 -0700 (PDT)
Message-ID: <009101bee93b$9b3bea90$[e-mail]>
From: "tog" <[e-mail]>
To: "Paul Koning" <[e-mail]>, "Stephen Kent" <[e-mail]>
Cc: <[e-mail]>
References: <[e-mail]><v04020a13b3da4a3d754d@[128.89.0.110]> <v04020a0bb3df5cbc4079@[128.89.0.110]>
Subject: Re: Non-Repudiation
Date: Tue, 17 Aug 1999 22:36:22 -0700
Organization: Meridianus
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.2918.2701
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2918.2701

Stephen -

----- Original Message -----
From: Stephen Kent <[e-mail]>

SNIP -

> The NR bit is provided to allow a CA to assert whether a
> certificate is suitable for use in an NR context.

This is exactly the reason for this argument. We all say that there should
be a way of signifying a "different mode" of processing or looking at the
cert operations, but this is a single bit. That makes a total of two
possible modes. NR and Not NR.

The issue is that becuase we acknowledge that PKI needs multiple modes of
processing and a mechanism from the trust component to signal this to the
app that is using it, so all we have to ask is the simple question: IS TWO
MODES ENOUGH?

I personally think not, and that the NR bit could easily be upgraded to be
either a bit or an OID in the TS process. This would allow for much more
control on policy sensitive models that use the timestamp for more than an
evidentiary token so I think its a very good thing.

> Not setting the bit is,
> by itself, valuable, to prevent certs from being considered suitable as
> part of NR evidence when there is clear intent that this not be done.
> However, even when the NR bit is set, one must be cognizant of the policy
> of the CA in question, which can be specified by a policy OID.

Maybe someone will do an ID on standard policy models, and we can get some
template policy OIDS. Actually, it sort of sounds like something that NIST
should supply.

> One might
> ask if, given the availability of a policy OID, do we need to use the NR
> bit?  Perhaps not.

No, I think that you are right that the NR feature is conceptually a good
thing, but I want to have it at least optionally  based on an OID at the
very minimum. As a single bit it is pretty of limited in the scope of its
effectivity.

> But various combinations of uses of these fields are
> possible.  For example, a CA may have on policy that covers all certs it
> issues, and it may the rely on the NR bit to state which part of the
policy
> applies to a given cert.  Or, a CA may not put policy info into a cert and
> rely on a posted CPS, and again rely on inclusion of the NR bit to trigger
> which part of the CPS is applicable to the cert in question.
>
> In each of these cases, there is a valid, reasonable use of the NR bit in
> conjunction with other aspects of conveying NR policy info.  No one can
> point to a uniform, international, legal approach to the technical details
> of NR evidence, so it is not valid to argue that the examples I have cited
> here are inconsistent with such (non-existant) rules.  Under these
> circumstances is appropriate for the WG to continue to develop technical
> mechanisms for expressing intent re the use of certs, so long as we have a
> solid technical basis for doing so.




Received: from tomcat.sac.verio.net ([e-mail] [209.162.64.15]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id VAA24509 for <[e-mail]>; Tue, 17 Aug 1999 21:07:21 -0700 (PDT)
Received: from nma.com (pm06-36.sac.verio.net [209.162.64.243]) by tomcat.sac.verio.net (8.9.1a/8.9.1) with ESMTP id VAA24982; Tue, 17 Aug 1999 21:04:53 -0700 (PDT)
Message-ID: <[e-mail]>
Date: Tue, 17 Aug 1999 21:05:01 -0700
From: Ed Gerck <[e-mail]>
X-Mailer: Mozilla 4.61 [en]C-CCK-MCD {Sony}  (Win98; I)
X-Accept-Language: en
MIME-Version: 1.0
To: Bob Blakley <[e-mail]>
CC: Tony Bartoletti <[e-mail]>, Stephen Kent <[e-mail]>, [e-mail], Nicholas Bohm <[e-mail]>, "David P. Kemp" <[e-mail]>, Tod Glassey <[e-mail]>
Subject: What non-repudiation is not and the PA bit, was Re: To Be, or NR To Be  ...
References: <047b01bee903$123e5080$[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Bob Blakley wrote:

> >Tony,
> >
> >>>>If I employed a PK solution to authenticate "remote logins",
> >>>>why should I settle for a mere "repudiable" login?
>
> Why would you want "nonrepudiable login"?  Normally no liability is associated
> with logging in -- it's what you do afterward that creates the liability.  The
> system owner has no interest in holding you accountable for logging  in, and is
> unlikely to be able to prove to a judge that you didn't walk away in the middle of a
> session.
> Hence it's much more interesting to have evidence of your having originated
> requests for specific transactions, than to have evidence of your having
> initiated the session within which those transactions were originated.

Bob and all:

Sorry to pick your text as an example for what non-repudiation is not, but
it exemplifies the paradigm shift, change of heart or whatever other metaphor
I can use to denote that need to stop, ponder and change.   To make this
posting clearer I will use "non-repudiation"  to denote what I call
non-repudiation and NR to denote what you mean by non-repudiation.

Reading your paragraph above -- when you talk about NR -- it is clear that
you think:

1. Only the use of NR will allow you to prove something to a judge

2.  Only the use of NR will be able to make the user accountable

3. Only the use of NR will provide legal evidence of user actions

So, these topics can be seen as "definition" of NR -- and you are not alone
because this is essentially what the DMS and ISO concepts of NR are all
about.  Well, these topics are all false in regard to non-repudiation, so that
NR <> non-repudiation.

But, this is not the main problem. The main problem is that you did not even
talk about non-repudiation!  In your entire text, the notion of non-repudiation
did not appear even once.

Contrary to what Steve Kent believes, there is a very clear idea in business
and banking about what non-repudiation is.  What those sectors do not know
is how to represent that in a reasonable fashion in security protocols -- and,
thank God they don't ;-)  So, how about we trying to find out how to do it
before they do it?

Oftentimes, a word is used just to satisfy a market need -- and, surely, we can
read press-releases of security companies that currently deliver products with
"non-repudiation" and at least one company even went as far as declaring that
it delivered products that offered "true non-repudiation".  Isn't this the same as
those "FREE" offers we read all the time? We all know it ain't FREE, so it
simply does not work after a while.  But, is this what we want?

To be fair, the motivation for the NR definition is a laudable one (contrary
to many of those FREE offers).  Indeed, this definition of NR reflects a concern
to improve security and it also recognizes that an element of proof is needed .

Where it fails is that it follows a common non-lawyer approach to solve a
legal issue -- non-lawyers believe that if they explain something "really well"
and provide "strong proof" then they will have a fat chance to win in court.
It is all a drive forward, a positive assertion -- more files, more logs, more
crypto keys, more digital signatures.  So, NR as you use it (and you are not
alone) is simply proof of authentication.  But, never non-repudiation.

Why? Because non-repudiation needs to be deniable a priori in order to be
legally valid -- yes, and please do not change my word "deny" to "refuse" ;-)
Because non-repudiation is a "two-prong test" [*] that allows a relying-party to
thwart a truthful denial (made a posteriori) with a legal affirmation (made a
priori).  Because if it does not allow all this, then it is not non-repudiation.

And please note what I say above. That even the strongest of proofs
(more files, more logs, more keys, more signatures, better timestamps,
better whatever you want) made afterwards to a judge is powerless
against a legal affirmation made a priori -- when non-repudiation is
either correctly applied or denied.   Thus, the non-lawyer approach
must fail in either case.

That is why a change of heart is needed.  What DMC, PKIX and ISO
have been calling "non-repudiation" simply is not non-repudiation -- is
proof of authentication.

And, maybe this is one way out of this corner were are all painted in.   We
may change the current NR bit name to "PA bit" -- proofOfAuthentication
bit. In a rather humorous rendering:

- We hereby declare that when the proofOfAuthentication bit is asserted in a
  certificate, any  message signed with the certificate can be used as legal
  proof against us, but not otherwise.

But, I suggest to indeed add a non-repudiation bit -- exactly because
non-repudiation is NOT the same as authentication, or strong authentication,
or proof of authentication.  Non-repudiation and authentication are
complement operations (technically speaking, reference upon request). As
I wrote earlier, my suggestion to define non-repudiation in PKIX is that
the text would negate any semantics to the non-repudiation bit beyond its own
syntactic expression as a boolean bit, while defining non-repudiation as
a qualified pointer (i.e., avoiding the dangling clause problem):

1'. Non-repudiation is defined in the CPS and its usage is asserted by setting the
nonRepudiation bit.

I also suggest to follow Tony's comment and define all other usage bits that are
not taken, calling them by generic names (say, in a humorous tone, Green, Red,
Blue):

- The Green service is defined in the CPS and its usage is asserted by setting the
  green bit.

etc.

Thus, what some sectors of the security community have felt a need to express
(and, with which need I agree), will be well represented by the PA bit. This
includes some needs previously expressed by Dave Kemp as the "XYZ" bit.
Thus,  marketing materials can say that a product offers "true proof of
authentication" without a  second thought (if, indeed, it does, of course).

Likewise, what some sectors of the business community have felt a need to use
and apply as non-repudiation will be well represented by the non-repudiation bit
in support of such (future?) uses.

And, other special services will be available as flagged by the R,G,B bits.

Comments?

Cheers,

Ed Gerck

[*] defined here in some of my messages.



Received: from netwk.hannam.ac.kr (netwk.hannam.ac.kr [203.247.39.32]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id SAA07204 for <[e-mail]>; Tue, 17 Aug 1999 18:29:56 -0700 (PDT)
Received: from hanjin (hanjin.hannam.ac.kr [203.247.39.68]) by netwk.hannam.ac.kr (8.9.3/8.9.3) with SMTP id KAA01423 for <[e-mail]>; Wed, 18 Aug 1999 10:28:43 +0900 (KST)
Message-ID: <02c201bee919$34358710$[e-mail]>
From: =?ks_c_5601-1987?B?wbbH0cH4?= <[e-mail]>
To: <[e-mail]>
Subject: 
Date: Wed, 18 Aug 1999 10:30:06 +0900
MIME-Version: 1.0
Content-Type: text/plain; charset="ks_c_5601-1987"
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: 8bit
X-MIME-Autoconverted: from base64 to 8bit by mail.proper.com id SAA07208

unsubscribe


Received: from poptop.llnl.gov (poptop.llnl.gov [128.115.18.65]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id RAA01728 for <[e-mail]>; Tue, 17 Aug 1999 17:56:11 -0700 (PDT)
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 RAA19348; Tue, 17 Aug 1999 17:57:05 -0700 (PDT)
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.3 (32)
Date: Tue, 17 Aug 1999 17:57:00 -0700
To: Stephen Kent <[e-mail]>
From: Tony Bartoletti <[e-mail]>
Subject: Re: To Be, or NR To Be ...
Cc: [e-mail]
In-Reply-To: <v04020a16b3df92b9f0bd@[128.89.0.110]>
References: <[e-mail]> <v04020a0db3df6342c8eb@[128.89.0.110]> <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"

At 06:32 PM 8/17/99 -0400, Stephen Kent wrote:
[I wrote]
>>Should it not be up to the relying party to consider whether their system
>>can maintain the NR-trail for actions that occur during after login?
>
>Now you are moving into an area where we no longer have crypto support for
>NR.  The protocols I cited permit either end to generate an audit trail for
>data that was not sent by the other party, and thus they do not provide a
>strong basis for NR (using "strong" in the technical sense, e.g., "strong
>authentication.")

I don't claim to be expert on all the existing protocols.  But certainly
there could arise protocols that provide for crypto-strength throughout.
In such a case, it would seem that an "NR-authentication" might be required
at the outset of the session, else the chain has no anchors.

But the entire discussion is still confused, I believe, by the often
unspoken distinction between "repudiating that you took some action"
versus "repudiating that you did so intentionally, understood your
exposure to liability, etc."

If I can be assured, by whatever means, that you are the sole-wielder
of a private key, then the existence of its signature on any object
(login-token or mortgage contract) assures me that it was you that
interacted with said object so to affix signature.  And no NR-bit
is required to make "the fact" of this signature "non-repudiable"
(modulo current mathematical strengths).

It is only when NR hopes to manage "intent" or "knowing liability"
that it has any additional force.  But here, I have yet to understand
how its setting, protocol-wise, helps to effect this end.  It may
help in precluding key use in "lightweight or automatic" operations,
authentications, it is true.  But of what value?  If these lightweight
operations are less interested in NR, why employ keys that are
"identity-certified" at all?

If I want to be sure that its "really really" you, then why should I
not want the ability to establish later, in court if necessary, that
it was "really really" you, (independent of your intent or actions)? 

___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 mail.proper.com (8.9.3/8.9.3) with ESMTP id RAA01133 for <[e-mail]>; Tue, 17 Aug 1999 17:16:35 -0700 (PDT)
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 RAA07773; Tue, 17 Aug 1999 17:17:33 -0700 (PDT)
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.3 (32)
Date: Tue, 17 Aug 1999 17:17:27 -0700
To: "Bob Blakley" <[e-mail]>, "Stephen Kent" <[e-mail]>
From: Tony Bartoletti <[e-mail]>
Subject: Re: To Be, or NR To Be ...
Cc: <[e-mail]>
In-Reply-To: <047b01bee903$123e5080$[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"

At 05:51 PM 8/17/99 -0500, Bob Blakley wrote:
>>Tony,
>>
>>>>>If I employed a PK solution to authenticate "remote logins",
>>>>>why should I settle for a mere "repudiable" login?
>
>
>Why would you want "nonrepudiable login"?  Normally no liability is associated
>with logging in -- it's what you do afterward that creates the liability.  The
>system owner has no interest in holding you accountable for logging  in, and is
>unlikely to be able to prove to a judge that you didn't walk away in the middle
>of a session.
>Hence it's much more interesting to have evidence of your having originated
>requests for specific transactions, than to have evidence of your having
>initiated the session within which those transactions were originated.

I simply consider a login to be one particular transaction.  Why assume
that no system owner would want to hold me accountable thereby?  Seems just
a bit like saying that banks don't care if I can sneak into their vaults
undetected/unidentified, just so long as I don't take any money.

With regard to "walking away in the middle of a session", suppose I enter
a transaction where I am presented with an electronic contract, and after
I unlock my NR-key (but before following through with signature) I were to
be suddenly called away, and a co-worker enters my office and completes the
operation in my absence.

Convincing a judge that you did/didn't walk away seems comparably problematic
in both the login and digsig cases. 

I see only shades-of-gray here, as much as we want to see black and white.
And shades-of-gray are the domain of policies and lawyers, not protocols.

Really, I agree with the goals, I just don't have alot of faith in the
given mechanism not providing a certain false-sense of something that's
really not there.

___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 mail.proper.com (8.9.3/8.9.3) with ESMTP id QAA00706 for <[e-mail]>; Tue, 17 Aug 1999 16:57:42 -0700 (PDT)
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 QAA29388; Tue, 17 Aug 1999 16:58:41 -0700 (PDT)
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.3 (32)
Date: Tue, 17 Aug 1999 16:58:35 -0700
To: Stephen Kent <[e-mail]>
From: Tony Bartoletti <[e-mail]>
Subject: Re: To Be, or NR To Be ...
Cc: [e-mail]
In-Reply-To: <v04020a15b3df90a573aa@[128.89.0.110]>
References: <[e-mail]> <v04020a0db3df6342c8eb@[128.89.0.110]> <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"

At 06:28 PM 8/17/99 -0400, Stephen Kent wrote:
[I wrote]
>>Hence my suggestion to add another few key-usage bits, say Red, Blue,
>>and Green, indicating a joint agreement that key use will be consistent
>>with evidences for R,G, or B, (see CPS or CA Policy for details.)
>
>Why do this vs. using a policy OID?

Prescience!  I REALLY WAS going to ask that same question.

Why is NR being treated differently?  Its just another key usage bit.

My feeling is, it is because the "market" is clamoring for NR, whatever
they may intend by that, and that we humor them by providing an NR bit,
reserved exclusively for that mysterious "NR" thingy.

However, by doing so, we take the first step down that slippery slope,
and invite the protocol-vs-policy debate we see today.

___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 honcho.austin.dascom.com (email.austin.dascom.com [206.196.73.5]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id PAA29686 for <[e-mail]>; Tue, 17 Aug 1999 15:48:37 -0700 (PDT)
Received: from austin.dascom.com by honcho.austin.dascom.com (8.8.8/SMI-SVR4) id RAA09066; Tue, 17 Aug 1999 17:46:47 -0500 (CDT)
Received: from shaggy by austin.dascom.com (8.8.8/SMI-SVR4) id RAA07854; Tue, 17 Aug 1999 17:46:47 -0500 (CDT)
Message-ID: <047b01bee903$123e5080$[e-mail]>
Reply-To: "Bob Blakley" <[e-mail]>
From: "Bob Blakley" <[e-mail]>
To: "Tony Bartoletti" <[e-mail]>, "Stephen Kent" <[e-mail]>
Cc: <[e-mail]>
Subject: Re: To Be, or NR To Be ...
Date: Tue, 17 Aug 1999 17:51:41 -0500
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="----=_NextPart_000_0478_01BEE8D9.29377480"
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

This is a multi-part message in MIME format.

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

>Tony,
>
>>>>If I employed a PK solution to authenticate "remote logins",
>>>>why should I settle for a mere "repudiable" login?


Why would you want "nonrepudiable login"?  Normally no liability is associated
with logging in -- it's what you do afterward that creates the liability.  The
system
owner has no interest in holding you accountable for logging  in, and is
unlikely
to be able to prove to a judge that you didn't walk away in the middle of a
session.
Hence it's much more interesting to have evidence of your having originated
requests for specific transactions, than to have evidence of your having
initiated
the session within which those transactions were originated.


>>>You mioght have to settle for a repudiable login to the extent that none of
>>>the current schemes for protected sessions (e.g., IPsec, SSL, Telnet
>>>authentication, ...) provide NR for the session.  Yes, one could engineer
>>>and exchange that provided evidence that a user logged in, but current
>>>protocols do not provide good technical evidence of what the user did after
>>>login.
>>
>>Should it not be up to the relying party to consider whether their system
>>can maintain the NR-trail for actions that occur during after login?

In some sense it's up to the arbitrator; he's the one who evaluates the
evidence.
He's only going to care about evidence of login if the evidence of the
transaction
about which a dispute has arisen, depends on evidence of the login.  (This is
similar to legal arguments about "chain of custody" of evidence, but not
identical).
But given that making this kind of argument is going to be harder than making
an argument without this kind of dependency built in, I don't see why you'd go
to
the trouble of generating evidence of logins.

>Now you are moving into an area where we no longer have crypto support for
>NR.  The protocols I cited permit either end to generate an audit trail for
>data that was not sent by the other party, and thus they do not provide a
>strong basis for NR (using "strong" in the technical sense, e.g., "strong
>authentication.")

There's also a problem of presumption here.  In a model in which login is
subject to NR evidence generation, and evidence of other transactions is
contingent upon login evidence, you could get into lots of situations in which
the user's login implies consent or assumes liability.  There's lots of
consumer
law limiting the counterparty's ability to impose implied consent or liability
on the user, so there might be lots of applications which could not legally
be deployed on such a system.

--bob

Bob Blakley ([e-mail])
Chief Scientist, Dascom



------=_NextPart_000_0478_01BEE8D9.29377480
Content-Type: text/x-vcard;
	name="Bob Blakley.vcf"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment;
	filename="Bob Blakley.vcf"

BEGIN:VCARD
VERSION:2.1
N:Blakley;Bob
FN:Bob Blakley
ORG:Dascom
TITLE:Chief Scientist
TEL;WORK;VOICE:[phone] x 5012
TEL;WORK;FAX:[phone]
ADR;WORK;ENCODING=3DQUOTED-PRINTABLE:;;Plaza Balcones=3D0D=3D0A5515 =
Balcones Drive;Austin;TX;78731;USA
LABEL;WORK;ENCODING=3DQUOTED-PRINTABLE:Plaza Balcones=3D0D=3D0A5515 =
Balcones Drive=3D0D=3D0AAustin, TX 78731=3D0D=3D0AUSA
URL:
URL:http://www.dascom.com
EMAIL;PREF;INTERNET:[e-mail]
REV:19990817T225140Z
END:VCARD

------=_NextPart_000_0478_01BEE8D9.29377480--



Received: from po1.bbn.com (PO1.BBN.COM [192.1.50.38]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id PAA29435 for <[e-mail]>; Tue, 17 Aug 1999 15:39:33 -0700 (PDT)
Received: from [128.89.0.110] (COSMEC.BBN.COM [128.89.0.110]) by po1.bbn.com (8.9.1/8.9.1) with ESMTP id SAA04256; Tue, 17 Aug 1999 18:40:27 -0400 (EDT)
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
X-Sender: [e-mail]
Message-Id: <v04020a16b3df92b9f0bd@[128.89.0.110]>
In-Reply-To: <[e-mail]>
References: <v04020a0db3df6342c8eb@[128.89.0.110]> <[e-mail]>
Date: Tue, 17 Aug 1999 18:32:30 -0400
To: Tony Bartoletti <[e-mail]>
From: Stephen Kent <[e-mail]>
Subject: Re: To Be, or NR To Be ...
Cc: [e-mail]

Tony,

>>>If I employed a PK solution to authenticate "remote logins",
>>>why should I settle for a mere "repudiable" login?
>>
>>You mioght have to settle for a repudiable login to the extent that none of
>>the current schemes for protected sessions (e.g., IPsec, SSL, Telnet
>>authentication, ...) provide NR for the session.  Yes, one could engineer
>>and exchange that provided evidence that a user logged in, but current
>>protocols do not provide good technical evidence of what the user did after
>>login.
>
>Should it not be up to the relying party to consider whether their system
>can maintain the NR-trail for actions that occur during after login?

Now you are moving into an area where we no longer have crypto support for
NR.  The protocols I cited permit either end to generate an audit trail for
data that was not sent by the other party, and thus they do not provide a
strong basis for NR (using "strong" in the technical sense, e.g., "strong
authentication.")

<snip>

Steve

P.S.  I forgot to respond to teh first paragraph in my previous message.


Received: from po1.bbn.com (PO1.BBN.COM [192.1.50.38]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id PAA29114 for <[e-mail]>; Tue, 17 Aug 1999 15:29:43 -0700 (PDT)
Received: from [128.89.0.110] (COSMEC.BBN.COM [128.89.0.110]) by po1.bbn.com (8.9.1/8.9.1) with ESMTP id SAA03610; Tue, 17 Aug 1999 18:30:36 -0400 (EDT)
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
X-Sender: [e-mail]
Message-Id: <v04020a15b3df90a573aa@[128.89.0.110]>
In-Reply-To: <[e-mail]>
References: <v04020a0db3df6342c8eb@[128.89.0.110]> <[e-mail]>
Date: Tue, 17 Aug 1999 18:28:57 -0400
To: Tony Bartoletti <[e-mail]>
From: Stephen Kent <[e-mail]>
Subject: Re: To Be, or NR To Be ...
Cc: [e-mail]

Tony,

>>No.  The NR bit is an assertion that the private key is being used in a
>>fashion that the key holder and CA acknowledge is consistent with
>>generation of evidence in support of the NR service.  In many respects, it
>>is the absence of the NR bit that is especially helpful, i.e., to prevent
>>the use of signed data from authentication or key exchanges from later
>>being submitted as NR evidence, contrary to the declaration provided in the
>>cert.
>>
>
>But this begs the question "Why is this helpful?"  That is, why should
>signed data from authentication or key-exchanges NOT be submittable as
>NR-evidence?  Why allow repudiation of the authenticity of the data or
>its origin?  Indeed, the mathematics supports its own role in the NR
>(via key-pair uniqueness) and so the issue still falls to assumptions
>about the identity of the "key-wielder" (be it the legal owner or not).

Two things:
	- One wants the provide the user with the ability to make a choice
bnetweenuse of a key which is declared explicity as being supportive of NR
vs. not.  I think this is an important feature to retain.

	- Many authentication protocols do not provide NR; only some that
make use of signature are suitable as a start.  if one wants to explicitly
design protocols that provide NR and are used for bind-time user
authentication. then it seems OK to do so and to then use an NR-labelled
cert as part of them.  Again, making this explicit is appropriate.  But,
because some auth protocols that involve signatures could be used to create
sigs for hashs of things that a user never saw, it would be a mistake to
talk in terms of auth protocols being used for NRTT in general.  One has to
be quite careful here.

>On the other hand, if NR is expected to be a reliable announcement
>of INTENT to conform-to-the-terms of the data so-signed, then that
>is a different matter.  But the description of the NR-bit as simply
>a joint (CA/Subscriber) agreement that "use will be consistent with
>providing evidences for NR, modulo CPS" is rather wide open.

It's not as concrete as some might like, but I think it is at a suitable
level of abstraction for 2459, gievn our desire to relegate NR policy
details to CA policies.

>Hence my suggestion to add another few key-usage bits, say Red, Blue,
>and Green, indicating a joint agreement that key use will be consistent
>with evidences for R,G, or B, (see CPS or CA Policy for details.)

Why do this vs. using a policy OID?

<snip>

Steve


Received: from honcho.austin.dascom.com (email.austin.dascom.com [206.196.73.5]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id PAA28818 for <[e-mail]>; Tue, 17 Aug 1999 15:22:37 -0700 (PDT)
Received: from austin.dascom.com by honcho.austin.dascom.com (8.8.8/SMI-SVR4) id RAA08913; Tue, 17 Aug 1999 17:20:19 -0500 (CDT)
Received: from shaggy by austin.dascom.com (8.8.8/SMI-SVR4) id RAA07718; Tue, 17 Aug 1999 17:20:18 -0500 (CDT)
Message-ID: <03a601bee8ff$5f4ae180$[e-mail]>
Reply-To: "Bob Blakley" <[e-mail]>
From: "Bob Blakley" <[e-mail]>
To: "Ed Gerck" <[e-mail]>
Cc: "Zmudzinski, Tom" <[e-mail]>, "tog" <[e-mail]>, "Alfred Arsenault" <[e-mail]>, <[e-mail]>, "Nicholas Bohm" <[e-mail]>
Subject: Re: And the definition of non-repudiation is....?
Date: Tue, 17 Aug 1999 17:25:12 -0500
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="----=_NextPart_000_03A3_01BEE8D5.764BA6A0"
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

This is a multi-part message in MIME format.

------=_NextPart_000_03A3_01BEE8D5.764BA6A0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit

Ed,

>> >This is not what non-repudiation is in business -- what DMS-NR describes
is
>> >simply the assertion of a truth, which is authentication.
>>
>> Sorry, but your definitions are all non-standard from the security
viewpoint,
>> Ed.
>
>I disagree.  See, for example, Menezes et. al., "Handbook of Cryptography",
>page 3:
>
>- entity authentication: *corroboration* of the identity of an entity
>- message authentication: *corroborating* the source of information
>
>Now, see Webster:
>
>- corroboration: to support with evidence or authority, to make more certain

When confronted by multiple layers of definition, I usually try substitution.
Here goes:

    entity authentication: to support the identity of an entity with evidence
or authority

(according to your citations).

I have failed to find substitutions which make this equivalent to

    the assertion of a truth [about an entity?]

Identity is not truth, nor vice versa -- not even to a logician!

>Thus, authentication involves two steps:
>
>(i) cognition, in which a trusted value X is acquired (e.g., the identity,
>the public-key, etc.) -- cognition defines a "fact", X;

Cognition does not define a fact!! "Cogito ergo sum" -- not "Cogito ergo est"!

>(ii) recognition, in which that trusted value X is used to support with its
>evidenciary or authoritative value whether a variable x presented for
>recognition is accepted or rejected -- recognition defines whether x
>is in accord with fact X.

??!!

This doesn't appear even well-formed.  Variables aren't "accepted or
rejected";
predicates or propositions involving variables are either true or false in a
model,
or, more generally, valid or invalid, based on the *values* of the variables
(or their
range of admissible values).  Are you simply defining recognition as truth in
a model?
In other words

REC = f(x) with X substituted for x?
or are you defining a function REC (X, x)?  If so, what's the function?  (I
think this
is the point....)

In a real example, I might imagine an authentication procedure which takes as
inputs a claimed "identity" (say "bob"), a password (say "friend") and then
runs a procedure which uses a table lookup to see if the password is the one
which the verifier associates with the identity, i.e.

        REC = (pw("bob") = "friend")

Is this what's intended?

But in this case, neither "bob" nor "friend" is in any sense "trusted".... or
even "a fact".
They're just data coming in on some channel.

>Thus, authentication asserts a truth -- Webster:

I think you left a few steps out, at least from the viewpoint of the slower
among us,
myself included in this group.

>truth: the property (as of a statement) of being in accord with fact or
reality.

We're fixin' to get into deep water here.  Steve will have tender parts of my
anatomy in a vise
if I follow you down this path....

Suffice it to say that you've not explicitly given either the fact or the
statement
which would support the argument here.

>So, in terms of logic, to authenticate x is to assert the truth of x in the
system of
>X.

Now you've got things hopelessly confused; you've earlier defined x to be a
variable,
but now you seem to be using it to denote an expression which has a truth
value.
If you're going to use logic as the basis of your argument here, I'm going to
insist
on at least well-formed formulae!

But on the point, this isn't how the security community has defined *either*
entity
authentication or origin authentication.  Again I'll refer you to the paper I
cited earlier,
and to others in the related literature,
none of which agree.

>I know that it may sound confusing to say that a "truth" is not an absolute
truism
>but such is the world of mathematics -- truths can be denied, even if I
affirm
>them ;-)

I think much of this audience is perfectly familiar with formal logic, but
this line
of argument doesn't use it properly and doesn't in any event address the issue
of departures from the security community's established definitions.

>So, there is no tautology.  Just a little "getting used to" -- but in math,
not in
>security definitions.
>
>I suggest you re-read my msg with this explanation in mind.


--bob

Bob Blakley ([e-mail])
Chief Scientist, Dascom


------=_NextPart_000_03A3_01BEE8D5.764BA6A0
Content-Type: text/x-vcard;
	name="Bob Blakley.vcf"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment;
	filename="Bob Blakley.vcf"

BEGIN:VCARD
VERSION:2.1
N:Blakley;Bob
FN:Bob Blakley
ORG:Dascom
TITLE:Chief Scientist
TEL;WORK;VOICE:[phone] x 5012
TEL;WORK;FAX:[phone]
ADR;WORK;ENCODING=3DQUOTED-PRINTABLE:;;Plaza Balcones=3D0D=3D0A5515 =
Balcones Drive;Austin;TX;78731;USA
LABEL;WORK;ENCODING=3DQUOTED-PRINTABLE:Plaza Balcones=3D0D=3D0A5515 =
Balcones Drive=3D0D=3D0AAustin, TX 78731=3D0D=3D0AUSA
URL:
URL:http://www.dascom.com
EMAIL;PREF;INTERNET:[e-mail]
REV:19990817T222512Z
END:VCARD

------=_NextPart_000_03A3_01BEE8D5.764BA6A0--



Received: from poptop.llnl.gov (poptop.llnl.gov [128.115.18.65]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id OAA28174 for <[e-mail]>; Tue, 17 Aug 1999 14:53:33 -0700 (PDT)
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 OAA22678; Tue, 17 Aug 1999 14:54:24 -0700 (PDT)
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.3 (32)
Date: Tue, 17 Aug 1999 14:54:18 -0700
To: Ed Gerck <[e-mail]>, Peter Williams <[e-mail]>, "[e-mail]" <[e-mail]>
From: Tony Bartoletti <[e-mail]>
Subject: Re: And the definition of non-repudiation is....?
In-Reply-To: <[e-mail]>
References: <001301bee8ea$44676290$[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"

At 02:15 PM 8/17/99 -0700, Ed Gerck wrote:
[paraphrasing]

> Non-repudiation is that which allows a truthful denial to be thwarted
> by a legal affirmation.

Now, THERE'S a functional definition! :)

___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 tomcat.sac.verio.net ([e-mail] [209.162.64.15]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id OAA27956 for <[e-mail]>; Tue, 17 Aug 1999 14:45:17 -0700 (PDT)
Received: from nma.com (pm03-04.sac.verio.net [209.162.64.70]) by tomcat.sac.verio.net (8.9.1a/8.9.1) with ESMTP id OAA02049; Tue, 17 Aug 1999 14:46:00 -0700 (PDT)
Message-ID: <[e-mail]>
Date: Tue, 17 Aug 1999 14:46:06 -0700
From: Ed Gerck <[e-mail]>
X-Mailer: Mozilla 4.61 [en]C-CCK-MCD {Sony}  (Win98; I)
X-Accept-Language: en
MIME-Version: 1.0
To: Bob Blakley <[e-mail]>
CC: "Zmudzinski, Tom" <[e-mail]>, tog <[e-mail]>, Alfred Arsenault <[e-mail]>, [e-mail], Nicholas Bohm <[e-mail]>
Subject: Re: And the definition of non-repudiation is....?
References: <029f01bee8ed$4c79daa0$[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Bob Blakley wrote:

> Ed Geerck wrote:
> >This is not what non-repudiation is in business -- what DMS-NR describes is
> >simply the assertion of a truth, which is authentication.
>
> Sorry, but your definitions are all non-standard from the security viewpoint,
> Ed.

I disagree.  See, for example, Menezes et. al., "Handbook of Cryptography",
page 3:

- entity authentication: *corroboration* of the identity of an entity
- message authentication: *corroborating* the source of information

Now, see Webster:

- corroboration: to support with evidence or authority, to make more certain

Thus, authentication involves two steps:

(i) cognition, in which a trusted value X is acquired (e.g., the identity,
the public-key, etc.) -- cognition defines a "fact", X;

(ii) recognition, in which that trusted value X is used to support with its
evidenciary or authoritative value whether a variable x presented for
recognition is accepted or rejected -- recognition defines whether x
is in accord with fact X.

Thus, authentication asserts a truth -- Webster:

truth: the property (as of a statement) of being in accord with fact or reality.

So, in terms of logic, to authenticate x is to assert the truth of x in the system of
X.

I know that it may sound confusing to say that a "truth" is not an absolute truism
but such is the world of mathematics -- truths can be denied, even if I affirm
them ;-)

So, there is no tautology.  Just a little "getting used to" -- but in math, not in
security definitions.

I suggest you re-read my msg with this explanation in mind.

Cheers,

Ed Gerck



Received: from poptop.llnl.gov (poptop.llnl.gov [128.115.18.65]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id OAA27790 for <[e-mail]>; Tue, 17 Aug 1999 14:43:36 -0700 (PDT)
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 OAA17334; Tue, 17 Aug 1999 14:44:33 -0700 (PDT)
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.3 (32)
Date: Tue, 17 Aug 1999 14:44:28 -0700
To: Stephen Kent <[e-mail]>
From: Tony Bartoletti <[e-mail]>
Subject: Re: To Be, or NR To Be ...
Cc: [e-mail]
In-Reply-To: <v04020a0db3df6342c8eb@[128.89.0.110]>
References: <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"

At 03:12 PM 8/17/99 -0400, Stephen Kent wrote:
>Tony,
>
>>If I employed a PK solution to authenticate "remote logins",
>>why should I settle for a mere "repudiable" login?
>
>You mioght have to settle for a repudiable login to the extent that none of
>the current schemes for protected sessions (e.g., IPsec, SSL, Telnet
>authentication, ...) provide NR for the session.  Yes, one could engineer
>and exchange that provided evidence that a user logged in, but current
>protocols do not provide good technical evidence of what the user did after
>login.

Should it not be up to the relying party to consider whether their system
can maintain the NR-trail for actions that occur during after login?


>>In PK, most all bets hinge upon "who holds the private key".
>>The only value a certificate NR-bit can hold is one that conveys
>>some reliable assurance about uniquely identifying the keyholder.
>
>No.  The NR bit is an assertion that the private key is being used in a
>fashion that the key holder and CA acknowledge is consistent with
>generation of evidence in support of the NR service.  In many respects, it
>is the absence of the NR bit that is especially helpful, i.e., to prevent
>the use of signed data from authentication or key exchanges from later
>being submitted as NR evidence, contrary to the declaration provided in the
>cert.
>

But this begs the question "Why is this helpful?"  That is, why should
signed data from authentication or key-exchanges NOT be submittable as
NR-evidence?  Why allow repudiation of the authenticity of the data or
its origin?  Indeed, the mathematics supports its own role in the NR
(via key-pair uniqueness) and so the issue still falls to assumptions
about the identity of the "key-wielder" (be it the legal owner or not).

On the other hand, if NR is expected to be a reliable announcement
of INTENT to conform-to-the-terms of the data so-signed, then that
is a different matter.  But the description of the NR-bit as simply
a joint (CA/Subscriber) agreement that "use will be consistent with
providing evidences for NR, modulo CPS" is rather wide open.

Hence my suggestion to add another few key-usage bits, say Red, Blue,
and Green, indicating a joint agreement that key use will be consistent
with evidences for R,G, or B, (see CPS or CA Policy for details.)
 
Really, I am not trying to be difficult here.  Perhaps a clarification
can be afforded by example:

Suppose I have two documents, each says "Will pay Tony $X on day Y".
Document "A" closes with "Signer agrees to the above terms", while
the other (document "B") does not.

I send either document to my debtor, who (I assume) signs and returns
the document (electronically), using a key certified either with or
without the NR-bit set.

This leads to 4 possible pairs (docA or docB)x(NR or not-NR)

Day Y passes with no payment.  I approach my debtor, who says (perhaps)
"I don't know what you are referring to.  I made no such agreement.)

In court, would the pair (docB,NR) be any stronger than (docA,not-NR)
given equal assurances that the signing key was uniquely in the hands
of the debtor?

How can the CA's certification of the key, in one state or another,
serve to better sway the court regarding an activity between the
subscriber and the relying party?  I cannot help but feel that by
precluding an NR-key from use in "mindless authentication", one
either expects that it will thus not be as loosely held, or that
the given CPS can somehow lend force to the idea that the subscriber
knew what they were getting into by requesting an NR key.

It just seems to me that many other bits could be added that would
be just as useful (meaning defined according to CPS and CA Policy).

Regards,

___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.meridianus.com (209.249.223.33.has.no.reverse [209.249.223.33] (may be forged)) by mail.proper.com (8.9.3/8.9.3) with ESMTP id OAA27610 for <[e-mail]>; Tue, 17 Aug 1999 14:39:40 -0700 (PDT)
Received: from PC1 by www.meridianus.com (8.8.8+Sun/SMI-SVR4) id PAA08883; Tue, 17 Aug 1999 15:34:12 -0700 (PDT)
Message-ID: <003f01bee8fb$2f9d5cf0$[e-mail]>
From: "tog" <[e-mail]>
To: "Ed Gerck" <[e-mail]>, "Stephen Kent" <[e-mail]>
Cc: <[e-mail]>, "Nicholas Bohm" <[e-mail]>
References: <[e-mail]> <v04020a10b3df70ccf76b@[128.89.0.110]>
Subject: Re: And the definition of non-repudiation is....?
Date: Tue, 17 Aug 1999 14:55:13 -0700
Organization: Meridianus
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.2918.2701
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2918.2701

Stephen, Ed
the simple issue is that we are talking about NR as a number of different
things... At different altitudes so to speak. In the context of these
discussions, no real resolution will be possible until the specific use and
constraint of the NR concept is hammered down.

Is this like David K says, a bit to inform the process of the Keying
Information used, or is it something more that says something to the using
applications?

Once this is answered formally and finally, these conversations will likely
turn to whether the answer we come to is enough to support the anticipated
use models or needs to be augmented.

Either way, lets get on with it.

Oh, and Bob, congrats on the book!.

Todd

----- Original Message -----
From: Stephen Kent <[e-mail]>
To: Ed Gerck <[e-mail]>
Cc: <[e-mail]>; Nicholas Bohm <[e-mail]>
Sent: Tuesday, August 17, 1999 1:11 PM
Subject: Re: And the definition of non-repudiation is....?


> Ed,
>
> >This is not what non-repudiation is in business -- what DMS-NR describes
is
> >simply the assertion of a truth, which is authentication.
>
> We again seem to have a terminology problem.  Authentication, in our
> technical context, is either entity (e.g., user) authehntication or data
> authentication (e.g., data origin authentication).  There is a very
> significant difference between the sort of user or data origin
> authentication, and the mechanisms that we often employ to implement these
> services, and the NR technology we are discussing.  Specifically,
> authentication mechanaims usually do not provide a good technical basis
for
> NR, since either party to the authentication process could, in most cases,
> generate the same sets of bits that are the product of the auth process.
>
> [snip]
>
> Steve
>



Received: from prv-mail20.provo.novell.com (prv-mail20.provo.novell.com [137.65.82.195]) by mail.proper.com (8.9.3/8.9.3) with SMTP id OAA27375 for <[e-mail]>; Tue, 17 Aug 1999 14:37:11 -0700 (PDT)
Received: from INET-PRV-Message_Server by prv-mail20.provo.novell.com with Novell_GroupWise; Tue, 17 Aug 1999 15:21:25 -0600
Message-Id: <[e-mail]>
X-Mailer: Novell GroupWise 5.5.2
Date: Tue, 17 Aug 1999 15:02:23 -0600
From: "Bob Jueneman" <[e-mail]>
To: <[e-mail]>
Subject: NR -- what the real issues are, and  a proposal
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 mail.proper.com id OAA27376

The message which follows is a rather lengthy attempt to recap of 
the last five years or so of technical/legal discussion regarding 
digital signatures, followed by a proposal for what to do to fix these 
problems.

However, since many may want to skip the justification and cut t
o the bottom line, I'll put the proposal up front, and then justify it:

My proposal is that the text of the nonrepudiation key usage bit I
n the PKIX RFC (and hopefully in X.509) be revised to unambiguously 
state that the defined semantics of this bit is to indicate the willingness 
of the subscriber to be legally bound by a digital signature which can be 
verified by a certificate that can be established to have been valid at the 
time of signature, where "valid" has the normal meaning of not expired, not 
revoked, etc., etc.

In addition, I propose that we create an additional indicator of a 
human being's conscious and willful intent to be legally bound by 
a digital signature that would be applied on a message by message 
basis. This additional indicator would require, as an integral part of 
its semantic definition, that an explicit computer-to-human interaction 
be required to provide some reasonable level of ceremonial and due 
caution warning be provided to the user.  In addition, the semantics 
of this indicator should specify that its use must be ENABLED by the 
NR bit ( as redefined) in the certificate which includes the corresponding 
public key.  If the certificate does not have the bit turned on, the 
application is not obligated to request the ceremonial, due caution 
approval; and relying party software should ignore a per-message 
indicator even if present in that case.

The obvious, but not necessarily the only, place to put such a message 
by message indicator would be in the Cryptographic Message Syntax 
used by S/MIME V3, in particular as a new signedAttribute.  Since 
signedAttributes is a SET of self-describing attributes, adding 
an additional one would be very simple.

Now for the history lesson.

When the ABA Digital Signature Guidelines were being formulated within the 
Information Security Committee, with lots of very bright, well-informed 
attorneys and technologists contributing, there was a fundamental, underlying 
assumption that PKI technology could be used to reduce some of the uncertainty that 
was perceived to be a barrier to the efficient use of electronic commerce.

Instead of having to use proprietary, value added networks and negotiate 
N*(N-1) contracts between all of the trading partners, it was expected that 
the use of a common PKI technology and appropriate legal frameworks 
would eliminate most of that overhead.

It was recognized that a accretion of case law had resulted in a situation 
where printed forms, letterhead, FAXs, telegrams and later Telexes, 
ordinary e-mail, and who knows what else forms of communications could, 
under the proper circumstances, be interpreted as being a legally binding 
signature.  The trouble was that the technology had moved much faster t
han the case law, and the uncertainty was increasing at a compounded rate.

For example, back when printed forms were created on letterhead presses, 
and were filled in using either handwriting or a typewriter, it was pretty obvious 
what the difference was. And because going to a printer and having a lot of 
standard forms printed involved some expense, time and effort, the 
conventional use of such a form for purposes of trade might reasonably 
be considered tantamount to a signature of the company. Unfortunately, 
a technological decision that was rational at the time is no longer rational 
in the age of laser printers, when preprinted forms have almost disappeared.  
But the case law hasn't changed, so the question of what constitutes 
signature becomes more of a risk, both for the relying party who thought 
it was valid, and for the originator, who really didn't intend for it to be anything 
more than a draft proposal.

In addition to these technical/legal issues, there was also the issue of 
liability in the event of something going wrong, such as a key being compromised.

One approach would be the very loose standard of care embodied in 
the US credit card law (Regulation E), where even the most egregious 
carelessness on the part of the subscriber could only result in a $50 loss.  
The problem with that approach is that it effectively required the 
establishment of a mechanism that would be very similar to the 
credit card industry to centralize the reporting of every time 
a certificate was used to verify a transaction, so that loss 
limits could be enforced.

At the other end of the spectrum was "strict liability,' which is 
the standard used between major financial institutions.  Because 
of the volume of the business, and the difficulty of backing out 
transactions in error that might otherwise leave an innocent third 
party holding the bag for a transaction gone wrong, inter-bank 
transactions are generally governed by strict liability -- no matter 
what the extenuating circumstances might be the bank was 
still liable for a transaction that went out in its name.

In between these two poles were standards of simple negligence 
or gross negligence as a possible defense.

The final decision that was incorporated in the Guidelines, 
Section 5.6 Presumption in dispute resolution, was to create 
a "rebuttable presumption" that a digital signature verified by 
reference to the public key listed in a valid certificate is the 
digital signature of the subscriber listed in that certificate.

The effect of this presumption was to allocate the burden of 
proof to the person who is challenge the validity of the 
signature.  In the case of a claimed forgery, for example, 
the burden of proof (independent of the risk of loss) falls on 
the subscriber, who would generally be in a much better 
position to know how the keys were protected, etc., than 
the relying party.

The State of Utah, in their pioneering Digital Signature Act, 
didn't go quite so far as that. Instead, they applied the rebuttable 
presumption argument only to a special class of certificates created 
by so-called "Licensed Certification Authorities" that were subject 
to a higher level of assurance, involving inspection and audit and 
financial viability controls that were intended to make the imposition 
of a rebuttable presumption a more reasonable proposition.  And 
these Licensed CA certificates were strictly a voluntary opt-in provision.  
No one had to use them, and if they didn't, the traditional common-law 
provisions regarding signatures was explicitly stated to be unaffected.  
Some other states, including Washington and Minnesota, and a large 
number of foreign countries, also adopted this model.

Nonetheless, some elements of the legal profession were strongly opposed.  
A law student by the name of Bradford Biddle published a law review article 
or polemic bitterly attacking the Utah statute as an unholy interference in the 
market by creating financial subsidies for a particular class of technology 
while disadvantaging others (which others were being disadvantaged was 
never explained.) A noted lobbyist for a company who was marketing a 
biometric-based, digitized signature device managed to get the Secretary of 
State of California to effectively gut their digital signature law by completely 
redefining a "digital signature" to be something else entirely.  (At the same
time he has made a rather convincing case for a certain element of 
"ceremonial" and "due caution" protection in any device or 
program that applies a legally binding signature to a document, whether a 
digital signature or not. In particular, he has effectively raised the issue of 
an automaton or daemon applying a digital signature automatically, without 
any human input at all. And of course that is precisely what S/MIME v3 "
Enhanced" Security Services with automatically signed receipts is intended to do!)

Meanwhile, a young but influential attorney in the Massachusetts state 
government, responding the electoral "mandate" of their Libertarian governor, 
Gov. Weld, strongly opposed the "regulatory burden" that might be imposed by 
State licensing of CAs, leading to the rather ironic situation of arch-conservative 
Utah sponsoring a regulatory regime, while ultra-liberal Massachusetts was trying 
to privatize CAs  and let the lawyers fight it out in court. In addition, some of the 
computer industry was also opposed to any kind of regulatory regime -- they didn't 
want the government, any government, telling them what they could do, ever. 
So the establishment of some kind of a rebuttable presumption faced serious 
political difficulties. 

And then another segment of the academic legal community raised a consumer 
protection issue that quickly became even more of an political hot potato.  If a 
digital signature was presumed to be valid, then, since "everybody knows" that 
operating systems are not secure and that the Internet is a cesspool of viruses, 
etc., poor Grandma is going to lose her house someday because her keys were 
compromised.  (This is q variation on the "death-penalty" certificate theme.)

>From this perspective, what was desired was not more nonrepudiation, but 
LESS!  Or to be more precise, a better way to control exactly when and 
how a signature might reasonably be viewed as being intended to be legally 
binding, and when it might be restricted to being used for more benign applications.

Restricting such usages to a certificate issued by a Licensed CA might have 
been a reasonable option * Grandma should never apply for or accept such a 
certificate if she never wanted to be legally bound, especially for a high-value 
transaction such as selling her house, and the CA would presumably be 
obligated to make sure that she understood the possible risks and need to 
adequately protect her keys before accepting such a certificate.  Unfortunately, 
since statutes enabling the use of a Licensed CA are not yet common and are 
being opposed by some, this may not be a viable approach.

Another approach MIGHT be to very carefully spell out the terms and 
conditions of use for a certificate in the CAs Certification Practice Statement.  
But despite the general belief in the PKIX community of the efficacy of a CPS 
to cure all ills, there are very grave doubts about whether a CPS is really all t
hat helpful in this case.

First of all, there is not necessarily any requirement for a relying party to even 
read the CPS.  Granted, if the relying party does not conform to the terms of 
the CPS, it may have a more difficult time suing the CA for damages, but even 
this is arguable.

Second, no matter what the CPS states with respect to what the subscriber 
is obligated to do with respect to the CA, and no matter what the CPS might 
imply with regard to the relying party, (assuming it can be demonstrated that 
an enforceable contract even exists between the CA and the RP), there is 
absolutely no privity of contract between the subscriber and the relying party 
that is caused by the CA and the CPS.  The RP can't sue the CA because of 
something the subscriber did or didn't do, and likewise the subscriber can't sue 
the CA for something the RP did or didn't do. The RP can sue the CA if it 
misrepresented the subscriber to the RP, and the subscriber can likewise 
sue the CA if it misrepresented the subscriber to the RP, but that is about it.

So relying on the CPS to protect the subscriber against a claim that she 
signed a legally binding document when she never intended to do so is a 
rather shaky legal premise.  Of course, like the fabled chicken soup remedy 
for a cold, it probably won't hurt, either, and so CPS's tend to include all sorts
of things just in case they might help.

What is really needed, given the lack of legal consensus as to how to 
approach these issues, is an unambiguous, standards-based way of indicating 
whether even a relatively naive consumer did or did not intend to be legally 
bound, ever, by a particular public key and certificate, and in particular by 
any kind of a high-value transaction that might allegedly be signed by t
hat person.  (In a certain ironic sense, we really need a positive, 
"repudiation" bit in a certificate, rather than the absence of a nonrepudiation 
bit.)  Insofar as possible, this indication must not depend on the existence or
nonexistence of digital signature laws, especially laws providing a rebuttable 
presumption to certain classes of certificates, because of the uncertainty of 
passage of such laws and the possibility that they might be preempted by 
federal legislation.. The desired effect therefore must be clearly stated in 
the semantics of the indicator itself, and interpreted as such by application 
programs, so that there can be very little doubt.

Secondly, in the case where a knowledgeable subscriber is in fact willing to 
be legally bound by a digital signature, it seems highly advisable to define a 
means of explicitly indicating, on a case by case, document by document 
basis, the subscriber's human consent and intent to be so bound, and to 
ensure that such an indication could not reasonably be interpreted as 
applying to any kind of an automatic or programmed generation of a 
digital signature by a human user.  (A server or automated process may 
automatically generate a digital signature on behalf a subscriber such as 
an organization, but it must NOT be applied in such as way as to indicate 
human consent on a case by case basis.)

My proposal, therefore, is that the text of the nonrepudiation key usage bit in 
the PKIX RFC (and hopefully in X.509) be revised to unambiguously state that 
the defined semantics of this bit is to indicate the willingness of the subscriber 
to be legally bound by a digital signature which can be verified by a certificate 
that can be established to have been valid at the time of signature.

In addition, I propose that we create an additional indicator of a human 
being's conscious and willful intent to be legally bound by a digital signature 
that would be applied on a message by message basis. This additional 
indicator would require, as an integral part of its semantic definition, that 
an explicit computer-to-human interaction be required to provide some 
reasonable level of ceremonial and due caution warning be provided to 
the user.  In addition, the semantics of this indicator should specify that 
its use must be ENABLED by the NR bit ( as redefined) in the certificate 
which includes the corresponding public key.  If the certificate does not 
have the bit turned on, the application is not obligated to request the 
ceremonial, due caution approval; and relying party software should 
ignore a per-message indicator even if present in that case.

The obvious, but not necessarily the only, place to put such a message 
by message indicator would be in the Cryptographic Message Syntax 
used by S/MIME V3, in particular as a new .  Since signedAttributes 
is a SET of self-describing attributes, adding an additional one would 
be very simple.

Comments?

Bob







Robert R. Jueneman
Security Architect
Network Security Development
Novell, Inc.
122 East 1700 South
Provo, UT 84606
[e-mail]
1-801-861-7387


Received: from honcho.austin.dascom.com (email.austin.dascom.com [206.196.73.5]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id OAA27177 for <[e-mail]>; Tue, 17 Aug 1999 14:30:39 -0700 (PDT)
Received: from austin.dascom.com by honcho.austin.dascom.com (8.8.8/SMI-SVR4) id QAA08607; Tue, 17 Aug 1999 16:28:22 -0500 (CDT)
Received: from shaggy by austin.dascom.com (8.8.8/SMI-SVR4) id QAA07453; Tue, 17 Aug 1999 16:28:23 -0500 (CDT)
Message-ID: <034301bee8f8$1e200160$[e-mail]>
Reply-To: "Bob Blakley" <[e-mail]>
From: "Bob Blakley" <[e-mail]>
To: "Ed Gerck" <[e-mail]>, "Peter Williams" <[e-mail]>, <[e-mail]>
Subject: Re: And the definition of non-repudiation is....?
Date: Tue, 17 Aug 1999 16:33:16 -0500
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="----=_NextPart_000_0340_01BEE8CE.3520C680"
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

This is a multi-part message in MIME format.

------=_NextPart_000_0340_01BEE8CE.3520C680
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit

All

>I see that non-repudiation is being mistaken for proof of authentication --
>so that there is  a paradigm shift involved here.  The ISO definitions and
>also at least two definitions of non-repudiation presented today are IMO
>not non-repudiation at  all; they just deal with proof of authentication.

I disagree; ISO definitions have explicitly to do with proof of action, but
that
action need not be authentication.

>It will take time for us all to sort the different nuances and the
discussions
>can be very helpful  to bring out the differences between authentication,
>proof of authentication and non-repudiation.
>
>But, non-repudiation is that which allows a truthful denial to be thwarted
>by a legal affirmation.

Another definition I don't agree with.  I think NR is *most effective* if
transactions
which use it are defined to have the following properties:

* Each party has evidence to cast doubt on all false accusations which
    might be made against it
* Each party has evidence to support all true accusations it might want to
make
* No party has evidence to support any false accusation it might want to make

It certainly isn't a desirable property to thwart truthful denials, any more
than it
is a desirable property to support false accusations.

Nevertheless, none of these things has fundamentally to do with the technical
aspects of a non-repudation service.  Such a service ought simply to produce
evidence of a transaction, and ought to have the property that it's easy to
explain to an adjudicator what must be done in order to successfully forge
such
evidence.  The adjudicator can then decide for himself the probative value
of the evidence, and whether it's germane to the accusations being made.

>This will however just punish the cert user, not the
>miscreant -- so that the NR "death penalty effect" will be not be a deterrent
>to crime in this case, even for those that believe in the effect.   IMO,
using
>non-repudiation certificates can actually decrease the security level of a
>system -- and I hope to make this point technically clear in a next text.

I'm fully prepared to believe this!

>So, using non-repudiation in a PKIX-QC implementation may not
>necessarily mean that a better assurance level will be reached in
>business transactions.

Using NR does not inherently have anything whatsoever to do with
the assurance level in business transactions.  It's possible to use NR to
increase the risk of engaging in fraudulent transactions, which may lower
the incidence of fraud and provide lower risk for the transactors.
But it's possible to use NR in lots of situations where it doesn't accomplish
this
goal.


--bob

Bob Blakley ([e-mail])
Chief Scientist, Dascom

------=_NextPart_000_0340_01BEE8CE.3520C680
Content-Type: text/x-vcard;
	name="Bob Blakley.vcf"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment;
	filename="Bob Blakley.vcf"

BEGIN:VCARD
VERSION:2.1
N:Blakley;Bob
FN:Bob Blakley
ORG:Dascom
TITLE:Chief Scientist
TEL;WORK;VOICE:[phone] x 5012
TEL;WORK;FAX:[phone]
ADR;WORK;ENCODING=3DQUOTED-PRINTABLE:;;Plaza Balcones=3D0D=3D0A5515 =
Balcones Drive;Austin;TX;78731;USA
LABEL;WORK;ENCODING=3DQUOTED-PRINTABLE:Plaza Balcones=3D0D=3D0A5515 =
Balcones Drive=3D0D=3D0AAustin, TX 78731=3D0D=3D0AUSA
URL:
URL:http://www.dascom.com
EMAIL;PREF;INTERNET:[e-mail]
REV:19990817T213316Z
END:VCARD

------=_NextPart_000_0340_01BEE8CE.3520C680--



Received: from tomcat.sac.verio.net ([e-mail] [209.162.64.15]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id OAA26889 for <[e-mail]>; Tue, 17 Aug 1999 14:14:53 -0700 (PDT)
Received: from nma.com (pm03-04.sac.verio.net [209.162.64.70]) by tomcat.sac.verio.net (8.9.1a/8.9.1) with ESMTP id OAA23921; Tue, 17 Aug 1999 14:15:45 -0700 (PDT)
Message-ID: <[e-mail]>
Date: Tue, 17 Aug 1999 14:15:14 -0700
From: Ed Gerck <[e-mail]>
X-Mailer: Mozilla 4.61 [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: And the definition of non-repudiation is....?
References: <001301bee8ea$44676290$[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Peter:

Thank you.  I agree with you that 2459 is already implictly changed
-- but the change noted by (1') in my msg was made known and
explict in order to be concrete as a suggestion, also for PKIX-QC.

I see that non-repudiation is being mistaken for proof of authentication --
so that there is  a paradigm shift involved here.  The ISO definitions and
also at least two definitions of non-repudiation presented today are IMO
not non-repudiation at  all; they just deal with proof of authentication. It
will take time for us all to sort the different nuances and the discussions
can be very helpful  to bring out the differences between authentication,
proof of authentication and non-repudiation.

But, non-repudiation is that which allows a truthful denial to be thwarted
by a legal affirmation.  This will however just punish the cert user, not the
miscreant -- so that the NR "death penalty effect" will be not be a deterrent
to crime in this case, even for those that believe in the effect.   IMO, using
non-repudiation certificates can actually decrease the security level of a
system -- and I hope to make this point technically clear in a next text.

So, using non-repudiation in a PKIX-QC implementation may not
necessarily mean that a better assurance level will be reached in
business transactions.

Cheers,

Ed Gerck

Peter Williams wrote:

> I support your efforts here, Ed. You are making PKIX
> work, with the NR bit issue. As PKIX-QC is pushing
> the envelope on NR beyond its current vague state,
> and given we are in the final call review
> of PKIX QC, it is appropriate to comment, and suggest
> refinement.



Received: from po1.bbn.com (PO1.bbn.com [192.1.50.38]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id NAA26287 for <[e-mail]>; Tue, 17 Aug 1999 13:30:02 -0700 (PDT)
Received: from [128.89.0.110] (COSMEC.BBN.COM [128.89.0.110]) by po1.bbn.com (8.9.1/8.9.1) with ESMTP id QAA21670; Tue, 17 Aug 1999 16:30:49 -0400 (EDT)
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
X-Sender: [e-mail]
Message-Id: <v04020a11b3df73308755@[128.89.0.110]>
In-Reply-To: <[e-mail]>
References: <[e-mail]> 	    <v04020a13b3da4a3d754d@[128.89.0.110]> <v04020a0bb3df5cbc4079@[128.89.0.110]>
Date: Tue, 17 Aug 1999 16:28:47 -0400
To: Ed Gerck <[e-mail]>
From: Stephen Kent <[e-mail]>
Subject: Re: Non-Repudiation
Cc: [e-mail]

Ed,

>>  No one can point to a uniform, international, legal approach to the
>>technical
>> details of NR evidence, so it is not valid to argue that the examples I
>>have cited
>> here are inconsistent with such (non-existant) rules.
>
>Steve:  But, there is. Pls read my reply to Tom Zmudzinski.
>
>Cheers -- Ed Gerck
>
>PS.: this is a short message ;-)

Yes, it's short, but not true.  ;-)

Note my insistence on uniform rules, on a worldwide basis.  The examples
you provide are the opinions of a few people, based on digital signature
laws and regulations that vary from state to state and from country to
country. I have been involved with some of the ABA committee early
deliberations, I subscribe to the list, I have professional interations
with some of the international regs (as my company sells into these
markets).  It's a mess, it's unstable, and there are widely varying
opinions among legal professionals about these matters.

I believe in the ability of well-grouned technical standards to pave the
way for appropriate legal regulations, although they are not a guarantee of
such.

Steve


Received: from honcho.austin.dascom.com (email.austin.dascom.com [206.196.73.5]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id NAA26195 for <[e-mail]>; Tue, 17 Aug 1999 13:29:36 -0700 (PDT)
Received: from austin.dascom.com by honcho.austin.dascom.com (8.8.8/SMI-SVR4) id PAA08242; Tue, 17 Aug 1999 15:27:18 -0500 (CDT)
Received: from shaggy by austin.dascom.com (8.8.8/SMI-SVR4) id PAA07146; Tue, 17 Aug 1999 15:27:18 -0500 (CDT)
Message-ID: <02b901bee8ef$95b44640$[e-mail]>
Reply-To: "Bob Blakley" <[e-mail]>
From: "Bob Blakley" <[e-mail]>
To: "Ed Gerck" <[e-mail]>, <[e-mail]>
Subject: Re: And the definition of non-repudiation is....? 
Date: Tue, 17 Aug 1999 15:32:11 -0500
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="----=_NextPart_000_02B6_01BEE8C5.AC9B1AC0"
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

This is a multi-part message in MIME format.

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



--bob

Bob Blakley ([e-mail])
Chief Scientist, Dascom
>Bob Blakley wrote:
>>I hate this definition.  In a book on the CORBAsecurity service (to appear
>>this fall), which includes a non-repudiation function, I used the following
>>*informal* definition, which is very different from the one above.
>>
>>"Non-repudiation services work by generating evidence of subjects' actions.
>>When a dispute arises, non-repudiation evidence can be used to help settle
the
>>issue."
>
>Bob:
>
>Maybe there is time to edit the galley proofs ;-)
>
>I note that the "informal" definition of NR that you present is nothing
>more than the definition of authentication.

Sorry, but this is obviously, absolutely wrong.  Authentication clearly does
NOT provide
evidence of a subject's actions.  In fact you explain this yourself below, in
your discussion
of weak authentication.  Authentication asserts the identity of one party to
another party
in an individual transaction, but NOT to third parties, and NOT outside the
scope (temporal
or spatial) of the transaction.  This is one of the reasons people want to
separate authentication
keys from NR keys -- because you're under a legal obligation, at the risk of
liability, for
*evidence* generated by executing a signature using a NR key, but you are NOT
at this
risk by virtue of executing a signature using an authentication key.

The whole notion of non-repudiation was invented because it was observed that
in
secret-key systems, and in poorly administered public-key systems,
authentication keys
could be stolen or maliciously disclosed in ways that created doubt about
whether the
subject using the key was the one whom it ostensibly authenticated.

>Indeed, authentication works
>by generating evidences of subject's actions (eg, a password being entered,
>a certificate being verified, etc.).  When a dispute arises, such
authentication
>evidence can be recalled and used to help settle the issue.

Absolutely not.

>In all this, note further
>that the signer had *no* participation -- i.e., the signer could NOT deny to
>provide what you call "NR".  Which is a sure sign that this is not NR.


I think what you mean here is "refuse", not "deny".  Subjects can ALWAYS deny
that evidence is genuine, germane, accurate, etc....

However I don't understand what you're getting at here; the subject certainly
enters
the password, and hence does participate in authentication.  He doesn't
participate
in the later recovery of the evidence, but this is the case in most NR
scenarios too.

>> Ed's larger point, that the only context in which NR makes sense is the
legal
>> context, is exactly right.
>
>I am afraid I must then be exactly wrong ;-)  because this is the opposite of
>what I said.  Yes, I did say that the legal context cannot be ignored in
business,
>but I have also said a couple of times that NR can be based on a legal test,
a
>technical test, a policy test, etc.

NR could be based on a technical test, if one expected that the evidence would
never be challenged before an impartial third party.  However this isn't an NR
case - it's an authoritarian regime.  In such a regime, a simple audit log
will
serve to convict both the innocent and the guilty of their real or imagined
offenses, and we need not resort to difficult technologies like digital
signature.
In regimes in which the arbitrator is to some degree impartial, NR will be
based
on rules of evidence and rules of procedure adhered to by the arbitrator.
In this case the test will always be in some sense "legal", in the context of
policy
and procedure.

>Since I have received some pvt emails
>asking for the NR model that I presented here in summary form
>before (and which I cited yesterday but is IMO too complex for PKIX
>usage but may be useful for CPS usage), I copy it below -- defining any
>number of contexts in which NR makes sense, of which the legal context is
>but one example.
>
>--------------------copy/begin-----------------------------------------
>{Fri, 23 Jul 1999 20:36:23 -0700}
>
> In order to preclude further interpretation problems, let me present a
>NR model that classifies what I consider to be the major aspects that
>any system wishing to provide non-repudiation at any given level should
>include, also naming each of a series of levels and providing for a division
>between Variables (which I can't control) and Modifiers (which I can
>control to some extent):
>
>A. Variables -- involves only "you", where "you" is the one that
authenticates
>
>A1. syntatic form (Is the authentication yours?),
>
>A2. semantic form (Did you understand what you were authenticating?),


In principle not determinate

>A3. trust form (Did you yourself willfully authenticate it?),


In principle cannot be captured in evidence

>A4. identification form (Are you the authenticator you claim to be?),


About 2000 years of philosophy have not yet converged on a view of what this
means

>A5. temporal form (When did you authenticate it?),
>
>A6. local form (Where did you authenticate it?),
>
>A7. etc.
>
>
>B. Modifiers -- involves also "me" (ie, "I", the verifier)
>
>B1. legal form (Can I legally prove it?)


In most systems this can only be known after the fact (i.e. after the judge or
jury
renders a decision)

>B2. liability form (Can you back and idemnify it to me?)


Relevant, but more interesting if "can and will"

>B3. extent form (What is the temporal and legal extent of the authentication,
for you
>                         towards me and me towards you?


I know something about how to define temporal extents - legal extents are very
tricky
and the syntax is going to be a bitch -- even in ASN.1 :-)

>B4. policy form (Is that allowed by the applicable policies, for you towards
me
>                         and me towards you?)
>
>B5. etc.
>
>Where I prefer to divide the issues of non-repudiation according to a
>state-space where one has a FIRST set of clear variables which I do not
>control, but measure:
>
> Variables: syntatic, semantic, trust, identification, temporal, local, etc.
>
>and a SECOND set of clear modifiers which I can control at least to
>some extent:
>
> Modifiers:  legal, liability, extent, policy, etc.
>
>As needed, one combines the components for a specific
>"law/policy non-repudiation system" as a logical function that uses
>A1, A2,... and B1, B2, ...  above as functional inputs, but in
>each respective classification.
>
>So,  weak authentication (as provided by passwords) fails to
>provide values for *ALL* variables when viewed under B.1
>since any such value could be replayed at will by the verifier
>(for example, or by an attacker) and there is nothing that the
>password holder could do to avoid it. Thus, as a legal principle
>valid in law theory in general (between power and liability),  since
>the password holder has no power to deny weak authentication it
>also has no derived liability from it, including non-repudiation.


I certainly agree that "weak authentication" does not create a presumption
of intent or contract.

>However, it is possible that some A variables could provide
>non-repudiation for passwords when viewed under the B4 modifier,
>for example --  such as when an ISP uses A.1 and B.4 in order to
>put an user's account on hold when two succesfull logins occur at a
>given time (indicating either two persons using the same account or
>a password compromise).  But, this is not legal NR -- which is what
>we are focusing here.
>
>So, to avoid further confusions whenever I mention NR, I mean legal
>NR unless otherwise noted.
>---------------------------------------copy/end------------------------
>
>Cheers,
>
>Ed Gerck
>
>

------=_NextPart_000_02B6_01BEE8C5.AC9B1AC0
Content-Type: text/x-vcard;
	name="Bob Blakley.vcf"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment;
	filename="Bob Blakley.vcf"

BEGIN:VCARD
VERSION:2.1
N:Blakley;Bob
FN:Bob Blakley
ORG:Dascom
TITLE:Chief Scientist
TEL;WORK;VOICE:[phone] x 5012
TEL;WORK;FAX:[phone]
ADR;WORK;ENCODING=3DQUOTED-PRINTABLE:;;Plaza Balcones=3D0D=3D0A5515 =
Balcones Drive;Austin;TX;78731;USA
LABEL;WORK;ENCODING=3DQUOTED-PRINTABLE:Plaza Balcones=3D0D=3D0A5515 =
Balcones Drive=3D0D=3D0AAustin, TX 78731=3D0D=3D0AUSA
URL:
URL:http://www.dascom.com
EMAIL;PREF;INTERNET:[e-mail]
REV:19990817T203211Z
END:VCARD

------=_NextPart_000_02B6_01BEE8C5.AC9B1AC0--



Received: from po1.bbn.com (PO1.bbn.com [192.1.50.38]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id NAA25932 for <[e-mail]>; Tue, 17 Aug 1999 13:19:58 -0700 (PDT)
Received: from [128.89.0.110] (COSMEC.BBN.COM [128.89.0.110]) by po1.bbn.com (8.9.1/8.9.1) with ESMTP id QAA20359; Tue, 17 Aug 1999 16:20:48 -0400 (EDT)
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
X-Sender: [e-mail]
Message-Id: <v04020a10b3df70ccf76b@[128.89.0.110]>
In-Reply-To: <[e-mail]>
References: <[e-mail]>
Date: Tue, 17 Aug 1999 16:11:23 -0400
To: Ed Gerck <[e-mail]>
From: Stephen Kent <[e-mail]>
Subject: Re: And the definition of non-repudiation is....?
Cc: [e-mail], Nicholas Bohm <[e-mail]>

Ed,

>This is not what non-repudiation is in business -- what DMS-NR describes is
>simply the assertion of a truth, which is authentication.

We again seem to have a terminology problem.  Authentication, in our
technical context, is either entity (e.g., user) authehntication or data
authentication (e.g., data origin authentication).  There is a very
significant difference between the sort of user or data origin
authentication, and the mechanisms that we often employ to implement these
services, and the NR technology we are discussing.  Specifically,
authentication mechanaims usually do not provide a good technical basis for
NR, since either party to the authentication process could, in most cases,
generate the same sets of bits that are the product of the auth process.

[snip]

Steve


Received: from honcho.austin.dascom.com (email.austin.dascom.com [206.196.73.5]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id NAA25721 for <[e-mail]>; Tue, 17 Aug 1999 13:14:40 -0700 (PDT)
Received: from austin.dascom.com by honcho.austin.dascom.com (8.8.8/SMI-SVR4) id PAA08114; Tue, 17 Aug 1999 15:10:57 -0500 (CDT)
Received: from shaggy by austin.dascom.com (8.8.8/SMI-SVR4) id PAA07043; Tue, 17 Aug 1999 15:10:56 -0500 (CDT)
Message-ID: <029f01bee8ed$4c79daa0$[e-mail]>
Reply-To: "Bob Blakley" <[e-mail]>
From: "Bob Blakley" <[e-mail]>
To: "Ed Gerck" <[e-mail]>, "Zmudzinski, Tom" <[e-mail]>
Cc: "tog" <[e-mail]>, "Alfred Arsenault" <[e-mail]>, <[e-mail]>, "Nicholas Bohm" <[e-mail]>
Subject: Re: And the definition of non-repudiation is....?
Date: Tue, 17 Aug 1999 15:15:48 -0500
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="----=_NextPart_000_029C_01BEE8C3.62E38FE0"
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

This is a multi-part message in MIME format.

------=_NextPart_000_029C_01BEE8C3.62E38FE0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit



--bob

Bob Blakley ([e-mail])
Chief Scientist, Dascom

>This is not what non-repudiation is in business -- what DMS-NR describes is
>simply the assertion of a truth, which is authentication.

Sorry, but your definitions are all non-standard from the security viewpoint,
Ed.
Authentication is *nowehere* defined as "the assertion of a truth".  There's
a wealth of definition, including from ISO, from various national bodies,
and from academic literature.  For a start you might look at :

"Authentication in Distributed Systems: Theory and Practice"
        (Butler Lampson, Martin Abadi, Michael Burrows, Edward Wobber, 1991)

The tautology "1=1" asserts a truth, but authenticates nothing.

>BTW, the sure sign
>that the DMS-NR definition does not define a non-repudiation process is
>the fact  that the signer can NOT deny providing DMS-NR.

It's probably not worthwhile to go much further down the path of this
argument,
but I'll repeat one more time that this definition cannot possibly be right.
The only way one can ensure that the signer can't deny providing DMS-NR is
to kill the signer the instant after signature, and I'm not sure that's
effective
in all cases.  The reason NR is necessary is precisely because the signer
might deny.  If the signer denies, a dispute exists.  If a dispute exists, it
is
arbitrated by some authority.  The authority has rules of evidence.  Using
these rules of evidence, the authority examines the NR evidence, which IN NO
CASE is proof ipso facto, and determines its probative value.  Then, based
not only on the NR evidence, but ALSO on other evidence and on law and
perhaps other bases, the arbitrator makes a judgement.

It would be very nice to imagine that we could produce a technical artifact
that would make the arbitration process unecessary, or just a rubber stamp.
But it isn't going to happen.

>To a bank or in business [cf. Nicholas Bohm, CC'd] , non-repudiation
>means that I can be held liable for a signature I did not make if the
>recipient could not distinguish it from a signature I did make. The
>recipient's trust in what was apparently (but not in fact) my signature
>is therefore held by law to be well-founded.  My trust in the reliability
>of the systems concerned (i.e. my trust that only a signature made or
>authorised by me will be treated as binding on me) is held by law
>to be ill-founded.


The real situation is much more complicated than this.  In some cases
the recipient is out of luck.  In other cases the bank is out of luck.
In yet other cases you're out of luck.  And *all* this is on the basis of
*exactly* the same evidence (your signature) which should demonstrate
why NR evidence is not proof of anything.

>In fact, non-repudiation occurs and is logically granted even if, indeed,
>the signer *proves* (legal, technical, etc.) beyond doubt that it did
>NOT make the signature -- the basic tenet here is that the
>relying-party had (past) to make a decision to accept the signature
>and based (past) such decision on its means to deny signature
>repudiation, which power was granted by the signer.

I don't agree with the terminology yet again.  Non-repudiation *does not*
occur - what occurs is liability for a transaction in the presence of
evidence.

>That is
>why *absence* of the signer's expression of power to grant
>non-repudiation to the relying-party is a sure sign that
>non-repudiation does not exist (since the signer cannot be coerced
>into granting a liability).
>
>I take that non-repudiation in this sense is a desirable feature:  I should
>not be free to deny that I signed what in fact I did sign.  But we need
>to be aware of the other use of this expression (or misuse of it) in
>the sense that a truthful denial is thwarted by a legal affirmation.
>
>The NR "definition" presented by Todd captured IMO the fine points
>of this business scenario and that is why I believe Todd's definition is
>closer to non-repudiation as used in business than the one adopted
>by DMS -- which is simply proof of authentication.
>
>Cheers,
>
>Ed Gerck
>
>

------=_NextPart_000_029C_01BEE8C3.62E38FE0
Content-Type: text/x-vcard;
	name="Bob Blakley.vcf"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment;
	filename="Bob Blakley.vcf"

BEGIN:VCARD
VERSION:2.1
N:Blakley;Bob
FN:Bob Blakley
ORG:Dascom
TITLE:Chief Scientist
TEL;WORK;VOICE:[phone] x 5012
TEL;WORK;FAX:[phone]
ADR;WORK;ENCODING=3DQUOTED-PRINTABLE:;;Plaza Balcones=3D0D=3D0A5515 =
Balcones Drive;Austin;TX;78731;USA
LABEL;WORK;ENCODING=3DQUOTED-PRINTABLE:Plaza Balcones=3D0D=3D0A5515 =
Balcones Drive=3D0D=3D0AAustin, TX 78731=3D0D=3D0AUSA
URL:
URL:http://www.dascom.com
EMAIL;PREF;INTERNET:[e-mail]
REV:19990817T201548Z
END:VCARD

------=_NextPart_000_029C_01BEE8C3.62E38FE0--



Received: from ext-mail.valicert.com (ext-mail.valicert.com [63.65.221.10]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id MAA25388 for <[e-mail]>; Tue, 17 Aug 1999 12:52:40 -0700 (PDT)
Received: from int-mail.valicert.com (corporate-gw.valicert.com [63.65.221.2]) by ext-mail.valicert.com (8.9.3/8.9.3) with ESMTP id MAA18374; Tue, 17 Aug 1999 12:53:35 -0700 (PDT)
Received: from rsalaptop ([192.168.3.230]) by int-mail.valicert.com (8.9.3/8.9.3) with SMTP id MAA27880; Tue, 17 Aug 1999 12:53:04 -0700 (PDT)
From: "Peter Williams" <[e-mail]>
To: "Ed Gerck" <[e-mail]>
Cc: <[e-mail]>
Subject: RE: And the definition of non-repudiation is....?
Date: Tue, 17 Aug 1999 12:54:08 -0700
Message-ID: <001301bee8ea$44676290$[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
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300
In-Reply-To: <[e-mail]>

I support your efforts here, Ed. You are making PKIX
work, with the NR bit issue. As PKIX-QC is pushing
the envelope on NR beyond its current vague state,
and given we are in the final call review
of PKIX QC, it is appropriate to comment, and suggest
refinement.

I would encourage that the amendments be
made in the context of PKIX-QC, however, not
2459.  Though 2459 profile is clearly broken (linking
NR to a digital signature mechanism, and denying such
as the audited/signed/timestamped Authenticode
application the legitimacy of NR status) its
not really worthy fixing at this state of minimal
market acceptance of the specification.

Getting PKIX-QC right is worthwhile; it
and can "amend" 2459 for all practical
purposes, and state the general
case it assumes when mandating
use of the NR bit as the means
to show that a signature device
meets the CEC  directive's technical
assurance requirements for electronic
signatures.


> -----Original Message-----
> From: Ed Gerck [mailto:[e-mail]]
> Sent: Monday, August 16, 1999 11:04 PM
> To: Alfred Arsenault
> Cc: [e-mail]; Tony Bartoletti; Tod Glassey
> Subject: Re: And the definition of non-repudiation is....?
>
>
>
>
> Alfred Arsenault wrote:
>
> > Ed,
> >
> >         Since you so outspokenly oppose the definition of
> "non-repudiation"
> > from ISO 7498-2 which (most of) the group has been working under for
> > these last few years, perhaps you'd like to enlighten us as to the one
> > true, correct definition of non-repudiation?
>
> Yes, and what should we do about the expected polemic around such NR
> definition, specially since good definitions are usually abstract
> -- "is this
> definition of NR the right one?".  Since this question is
> inevitable, let me
> address it first.
>
> Clearly, this will be a right question.  And I hope that nothing
> that I have
> written or will write here will be interpreted as a claim that my
> definition of
> NR will be the "right" or the only possible one. But, answer we must --
> what is "the right one"?
>
> Here, perhaps the only metric we may accept is [Leshniewski]:  "A theory,
> ultimately, must be judged for its accord with reality". This is
> the reason why I
> have extensively looked into the question of what nonrepudiation
> is and what it
> is not,  and have so much enjoyed the discussion here with so
> many different
> takes at it from many different participants and perspectives,
> when comparing
> the different legal, technical and linguistic usages of the word
> "nonrepudiation"
> in our reality -- for several stances and observer relationships.
>
> Thus, I think we would need to verify any proposed definition of
> NR in terms
> of its derived results based on different stances and observer
> relationships,
> including other areas besides technical communication processes,
> such as to
> test its usage also when modeling nonrepudiation for legal and social
> communication processes -- e.g., power relationships, managerial
> activities,
> contracts, auditing, interpersonal relationships,  etc.  --
> because they will all
> play a role "before" and "after" PKIX certificates are used and (somehow)
> PKIX certs must "glue" to these interfaces.
>
> All this, seems to me, is beyond the PKIX charter, however.  So, we may be
> left with a chicken and egg problem unless we try to simplify the
> question and
> simply stay for the moment with a NR definition that says the
> least we need
> to say -- thus, avoiding conflicts with interfaces "before" and
> "after" PKIX.
> For example, no more statements on "falsely denying",
> "providing", "irrefutable
> evidence", etc.
>
> In this sense, I suggest that this WG's definition of NR should
> be operational,
> minimalistic, and cast in terms PKIX variables -- rather than a
> formal logic
> definition valid in general (as I have discussed in the MCG
> list), or a NR model
> (such as I presented here and elsewhere) that is too broad for
> the cases dealt
> with by PKIX in a protocol.
>
> I very much liked Todd Glassey's operational definition of NR
> sent today to this
> list: 'Non-repudiation is a process that puts in place a trust
> model such that any
> event that is "deemed nonrepudiable" is beyond question.'
>
> As I see it, this definition needs some fine tunning but it
> sucessfully operationalizes
> NR in terms of trust -- however, trust is outside the scope of
> PKIX.  Also, we
> need to connect NR to that pesky bit.  So, taking into account
> that we have more
> nonrepudiation states than simply on-off (see my previous msg --
> at least three
> on states and three off states), we could have something like
> this in the PKIX spec:
>
> 1. Non-repudiation is a process based on a trust model defined in the CPS
> and its usage is asserted by setting the non-repudiation bit.
>
> Following this text, a particular usage of NR could have many
> logical states while a
> boolean bit could still be used to define whether a NR service is
> available or not
> in services associated with that cert.
>
> An alternative definition of NR (my preferred choice and one
> which I have stated
> already, before) would be to negate any semantics to the NR bit
> beyond its own
> syntatic expression in PKIX itself as a boolean bit, while
> defining NR as a
> qualified pointer (i.e., not as a dangling clause):
> "Non-repudiation is defined in
> the CPS.".  The resulting text in the spec would be:
>
> 1'. Non-repudiation is defined in the CPS and its usage is
> asserted by setting the
> non-repudiation bit.
>
> Definition (1') includes definition (1) as subcase.  Either of
> these two NR
> definitions would allow for logically consistent CPSs because
> anyone writing
> a CPS could use this list's archives and adequate legal counsel
> in order to verify
> what a "non-repudiation service" could or could not provide in
> each particular
> case -- for example, for a company acting as a CA in its own
> interest or as a
> commercial CA acting on behalf of the subscriber.  Also, the CPS
> could define
> the validation services required for that NR service during the
> lifetime of the
> cert, in accord to risk/cost, and any other issues that may be relevant to
> nonrepudiation for each case -- such as insurance, jurisdiction,
> legal capacity,
> maximum cumulative coverage, delay time to maturation, etc.
>
> In terms of text changes, either of these two NR definitions
> could directly
> substitute the following legacy paragraph in 2459, in its entirety:
>
>     "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."
>
> (ie, deleting the above paragraph).
>
> NOTE: Since nonrepudiation is not used in PKIX itself, the
> situation that results
> from (1) or (1') is much better than X.509/PKIX usage of the
> concept of trust
> itself -- which is defined a posteriori in the CPS but used a
> priori in the specs.
> This is one more reason to prefer (1') over (1), IMO -- because,
> since (1) < (1'),
> nothing is lost in either in expressive capacity or in coherence
> when (1') is used.
>
> > Or is it your assertion that there is no such thing as
> non-repudiation, and we
> > should just drop it from PKIX altogether?
>
> No, and never was. In fact, I have been stressing that this
> discussion is important
> also because the concept of  nonrepudiation is IMO logically
> needed and cannot
> be subsummed under authentication.
>
> As Tony Bartoletti wrote today: ".. it seems that in a contract
> or transaction of
> such value that NR becomes a goal, its benefits could be applied
> to any and all
> of these usages [data authentication, endpoint authentication,
> digital signature]."
>
> So, if NR can be applied to any and all of such services then
> this also indicates
> that NR cannot be of the same type of any of them. Thus, in a geometric
> model, non-repudiation is in an orthogonal axis to authentication -- not a
> "better" or "stronger" authentication act or, even, an improvement over
> authentication.  NR is, simply, different than authentication -- apples
> and speedboats.
>
> That is why I commented elsewhere that NR is not a "stronger" type
> of authentication and that usage of such concept would lead to
> contradictions -- e.g., since nonrepudiation evidence (even if
> cryptographic)
> can always be repudiated by authentication evidence (even if
> non-cryptographic).
>
> Cheers,
>
> Ed Gerck
>



Received: from honcho.austin.dascom.com (email.austin.dascom.com [206.196.73.5]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id MAA25098 for <[e-mail]>; Tue, 17 Aug 1999 12:36:17 -0700 (PDT)
Received: from austin.dascom.com by honcho.austin.dascom.com (8.8.8/SMI-SVR4) id OAA07875; Tue, 17 Aug 1999 14:33:52 -0500 (CDT)
Received: from shaggy by austin.dascom.com (8.8.8/SMI-SVR4) id OAA06877; Tue, 17 Aug 1999 14:33:51 -0500 (CDT)
Message-ID: <025501bee8e8$1e845bc0$[e-mail]>
Reply-To: "Bob Blakley" <[e-mail]>
From: "Bob Blakley" <[e-mail]>
To: "Zmudzinski, Tom" <[e-mail]>, "tog" <[e-mail]>
Cc: "Alfred Arsenault" <[e-mail]>, <[e-mail]>, <[e-mail]>
Subject: Re: Re[2]: And the definition of non-repudiation is....?
Date: Tue, 17 Aug 1999 14:38:45 -0500
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="----=_NextPart_000_0252_01BEE8BE.35745800"
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

This is a multi-part message in MIME format.

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

All

>>> Since you so outspokenly oppose the definition of "non-repudiation"
>>> from ISO 7498-2 which (most of) the group has been working under for
>>> these last few years, perhaps you'd like to enlighten us as to the one
>>> true, correct definition of non-repudiation?
>>
>> Actually, I will...
>>
>> Non-repudiation is a process that puts in place a trust model such that
>any
>> event that is "deemed nonrepudiable" is beyond question. It's about the
>> totality of the trust model that surrounds the envelope of the transaction
>> and the facilities for evaluating it. Such events are deemed
>non-repudiated.
>
>Now can we try it without the tautology?

Not even a tautology, but an absurdity, unless it's intended to describe a set
(of events) with no members.  The whole point here is that if an event is
beyond question, there's no need for non-repudiation protection.  If there is
a need to protect against repudiation, then by definition a question might
arise.

>The Defense Message System
>defines non-repudiation as a security service that "protects against the
>denial by one of the entities involved in a message exchange of having
>participated in all or part of the exchange.  It supports the
>proof-of-origin
>and the proof-of-receipt services that provide proof of message origin to
>the recipient and proof of message receipt to the sender.

I like this definition, except for the word "proof", which of course isn't
defined
here.  What's actually provided in DMS implementations is evidence, which
may be judged sufficient in some cases, depending upon who is eventually
called on to arbitrate disputes.  It seems clear that the JCS is more likely
to think that DMS NR evidence is "proof" than, say, the Supreme Court.

>Non-repudiation
>combines the use of modification detection with digital signatures.  These
>security services are vital in a military message system to verify that the
>proper authority issued an order and that the correct recipient received
>the order." -- DMS System Security Authorization Agreement Version 2.1
>
>In the early days of DMS, we used to say simply [sorry about the message-
>centric verbiage] that non-repudiation was that property which would
>demonstrate to an impartial third party that a given message had been
>sent by a specific individual or received by a specific individual.

I like this verbiage too!

--bob

Bob Blakley ([e-mail])
Chief Scientist, Dascom

------=_NextPart_000_0252_01BEE8BE.35745800
Content-Type: text/x-vcard;
	name="Bob Blakley.vcf"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment;
	filename="Bob Blakley.vcf"

BEGIN:VCARD
VERSION:2.1
N:Blakley;Bob
FN:Bob Blakley
ORG:Dascom
TITLE:Chief Scientist
TEL;WORK;VOICE:[phone] x 5012
TEL;WORK;FAX:[phone]
ADR;WORK;ENCODING=3DQUOTED-PRINTABLE:;;Plaza Balcones=3D0D=3D0A5515 =
Balcones Drive;Austin;TX;78731;USA
LABEL;WORK;ENCODING=3DQUOTED-PRINTABLE:Plaza Balcones=3D0D=3D0A5515 =
Balcones Drive=3D0D=3D0AAustin, TX 78731=3D0D=3D0AUSA
URL:
URL:http://www.dascom.com
EMAIL;PREF;INTERNET:[e-mail]
REV:19990817T193845Z
END:VCARD

------=_NextPart_000_0252_01BEE8BE.35745800--



Received: from tomcat.sac.verio.net ([e-mail] [209.162.64.15]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id MAA24927 for <[e-mail]>; Tue, 17 Aug 1999 12:33:17 -0700 (PDT)
Received: from nma.com (pm04-04.sac.verio.net [209.162.64.117]) by tomcat.sac.verio.net (8.9.1a/8.9.1) with ESMTP id MAA29185; Tue, 17 Aug 1999 12:34:12 -0700 (PDT)
Message-ID: <[e-mail]>
Date: Tue, 17 Aug 1999 12:34:19 -0700
From: Ed Gerck <[e-mail]>
X-Mailer: Mozilla 4.61 [en]C-CCK-MCD {Sony}  (Win98; I)
X-Accept-Language: en
MIME-Version: 1.0
To: Stephen Kent <[e-mail]>
CC: Paul Koning <[e-mail]>, [e-mail]
Subject: Re: Non-Repudiation
References: <[e-mail]>  <v04020a13b3da4a3d754d@[128.89.0.110]> <v04020a0bb3df5cbc4079@[128.89.0.110]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Stephen Kent wrote:

>  No one can point to a uniform, international, legal approach to the technical
> details of NR evidence, so it is not valid to argue that the examples I have cited
> here are inconsistent with such (non-existant) rules.

Steve:  But, there is. Pls read my reply to Tom Zmudzinski.

Cheers -- Ed Gerck

PS.: this is a short message ;-)



Received: from tomcat.sac.verio.net ([e-mail] [209.162.64.15]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id MAA24704 for <[e-mail]>; Tue, 17 Aug 1999 12:26:18 -0700 (PDT)
Received: from nma.com (pm04-04.sac.verio.net [209.162.64.117]) by tomcat.sac.verio.net (8.9.1a/8.9.1) with ESMTP id MAA27462; Tue, 17 Aug 1999 12:27:04 -0700 (PDT)
Message-ID: <[e-mail]>
Date: Tue, 17 Aug 1999 12:27:10 -0700
From: Ed Gerck <[e-mail]>
X-Mailer: Mozilla 4.61 [en]C-CCK-MCD {Sony}  (Win98; I)
X-Accept-Language: en
MIME-Version: 1.0
To: "Zmudzinski, Tom" <[e-mail]>
CC: tog <[e-mail]>, Alfred Arsenault <[e-mail]>, [e-mail], Nicholas Bohm <[e-mail]>
Subject: Re: And the definition of non-repudiation is....?
References: <[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

"Zmudzinski, Tom" wrote:

> ...The Defense Message System defines non-repudiation as a security
> service that "protects against the denial by one of the entities involved
> in a message exchange of having participated in all or part of the
> exchange.  It supports the proof-of-origin  and the proof-of-receipt
> services that provide proof of  message origin to the recipient and proof
> of message receipt to the sender. Non-repudiation combines the use of
> modification detection with digital signatures.  These security services
> are vital in a military message system to verify that the proper authority
> issued an order and that the correct recipient received the order." --
> DMS System Security Authorization  Agreement Version 2.1
>
> In the early days of DMS, we used to say simply [sorry about the message-
> centric verbiage] that non-repudiation was that property which would
> demonstrate to an impartial third party that a given message had been
> sent by a specific individual or received by a specific individual.

This is not what non-repudiation is in business -- what DMS-NR describes is
simply the assertion of a truth, which is authentication.  BTW, the sure sign
that the DMS-NR definition does not define a non-repudiation process is
the fact  that the signer can NOT deny providing DMS-NR.

To a bank or in business [cf. Nicholas Bohm, CC'd] , non-repudiation
means that I can be held liable for a signature I did not make if the
recipient could not distinguish it from a signature I did make. The
recipient's trust in what was apparently (but not in fact) my signature
is therefore held by law to be well-founded.  My trust in the reliability
of the systems concerned (i.e. my trust that only a signature made or
authorised by me will be treated as binding on me) is held by law
to be ill-founded.

In fact, non-repudiation occurs and is logically granted even if, indeed,
the signer *proves* (legal, technical, etc.) beyond doubt that it did
NOT make the signature -- the basic tenet here is that the
relying-party had (past) to make a decision to accept the signature
and based (past) such decision on its means to deny signature
repudiation, which power was granted by the signer.  That is
why *absence* of the signer's expression of power to grant
non-repudiation to the relying-party is a sure sign that
non-repudiation does not exist (since the signer cannot be coerced
into granting a liability).

I take that non-repudiation in this sense is a desirable feature:  I should
not be free to deny that I signed what in fact I did sign.  But we need
to be aware of the other use of this expression (or misuse of it) in
the sense that a truthful denial is thwarted by a legal affirmation.

The NR "definition" presented by Todd captured IMO the fine points
of this business scenario and that is why I believe Todd's definition is
closer to non-repudiation as used in business than the one adopted
by DMS -- which is simply proof of authentication.

Cheers,

Ed Gerck



Received: from po1.bbn.com (PO1.bbn.com [192.1.50.38]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id MAA24502 for <[e-mail]>; Tue, 17 Aug 1999 12:20:34 -0700 (PDT)
Received: from [128.89.0.110] (COSMEC.BBN.COM [128.89.0.110]) by po1.bbn.com (8.9.1/8.9.1) with ESMTP id PAA11225; Tue, 17 Aug 1999 15:21:08 -0400 (EDT)
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
X-Sender: [e-mail]
Message-Id: <v04020a0db3df6342c8eb@[128.89.0.110]>
In-Reply-To: <[e-mail]>
Date: Tue, 17 Aug 1999 15:12:15 -0400
To: Tony Bartoletti <[e-mail]>
From: Stephen Kent <[e-mail]>
Subject: Re: To Be, or NR To Be ...
Cc: [e-mail]

Tony,

>If I employed a PK solution to authenticate "remote logins",
>why should I settle for a mere "repudiable" login?

You mioght have to settle for a repudiable login to the extent that none of
the current schemes for protected sessions (e.g., IPsec, SSL, Telnet
authentication, ...) provide NR for the session.  Yes, one could engineer
and exchange that provided evidence that a user logged in, but current
protocols do not provide good technical evidence of what the user did after
login.

>And to loosely paraphrase Ed Gerck:  If you think you are talking
>with the US President, but in reality it is Saddam Hussein, then
>what does having a "tamperproof, data-protected" channel buy you?

If I have good NR mechanisms, then it may help in my defense that I had
valid reason to believe that I was talking to the president, and thus my
actions were justified.

>These use-cases have overlapping effects and implications, in
>particular due to the characteristics of the PK mechanism.
>
>In PK, most all bets hinge upon "who holds the private key".
>The only value a certificate NR-bit can hold is one that conveys
>some reliable assurance about uniquely identifying the keyholder.

No.  The NR bit is an assertion that the private key is being used in a
fashion that the key holder and CA acknowledge is consistent with
generation of evidence in support of the NR service.  In many respects, it
is the absence of the NR bit that is especially helpful, i.e., to prevent
the use of signed data from authentication or key exchanges from later
being submitted as NR evidence, contrary to the declaration provided in the
cert.

>It must have some value beyond "I better be REAL careful with
>THIS key, since its (cert's) NR-bit is set." (death penalty cert.)
>
>As Ed has asked, Who is authoritative regarding the NR-bit setting?
>And I ask, what are the "lower and upper bounds" to what it being
>attested to in each case?

The question of bounds is outside the scope of that single bit, e.g., it is
represented in the CPS or CA policy.

Steve


Received: from tomcat.sac.verio.net ([e-mail] [209.162.64.15]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id MAA24100 for <[e-mail]>; Tue, 17 Aug 1999 12:01:29 -0700 (PDT)
Received: from nma.com (pm04-04.sac.verio.net [209.162.64.117]) by tomcat.sac.verio.net (8.9.1a/8.9.1) with ESMTP id MAA21150 for <[e-mail]>; Tue, 17 Aug 1999 12:02:26 -0700 (PDT)
Message-ID: <[e-mail]>
Date: Tue, 17 Aug 1999 12:02:33 -0700
From: Ed Gerck <[e-mail]>
X-Mailer: Mozilla 4.61 [en]C-CCK-MCD {Sony}  (Win98; I)
X-Accept-Language: en
MIME-Version: 1.0
To: "[e-mail]" <[e-mail]>
Subject: Re: And the definition of non-repudiation is....? 
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

>Ed Gerck wrote:
>> I very much liked Todd Glassey's operational definition of NR sent today to
>> this list: 'Non-repudiation is a process that puts in place a trust model such
>> that any event that is "deemed nonrepudiable" is beyond question.'

Bob Blakley wrote:
>I hate this definition.  In a book on the CORBAsecurity service (to appear
>this fall), which includes a non-repudiation function, I used the following
>*informal* definition, which is very different from the one above.
>
>"Non-repudiation services work by generating evidence of subjects' actions.
>When a dispute arises, non-repudiation evidence can be used to help settle the
>issue."

Bob:

Maybe there is time to edit the galley proofs ;-)

I note that the "informal" definition of NR that you present is nothing
more than the definition of authentication.  Indeed, authentication works
by generating evidences of subject's actions (eg, a password being entered,
a certificate being verified, etc.).  When a dispute arises, such authentication
evidence can be recalled and used to help settle the issue.  In all this, note further
that the signer had *no* participation -- i.e., the signer could NOT deny to
provide what you call "NR".  Which is a sure sign that this is not NR.

> Ed's larger point, that the only context in which NR makes sense is the legal
> context, is exactly right.

I am afraid I must then be exactly wrong ;-)  because this is the opposite of
what I said.  Yes, I did say that the legal context cannot be ignored in business,
but I have also said a couple of times that NR can be based on a legal test, a
technical test, a policy test, etc.  Since I have received some pvt emails
asking for the NR model that I presented here in summary form
before (and which I cited yesterday but is IMO too complex for PKIX
usage but may be useful for CPS usage), I copy it below -- defining any
number of contexts in which NR makes sense, of which the legal context is
but one example.

--------------------copy/begin-----------------------------------------
{Fri, 23 Jul 1999 20:36:23 -0700}

 In order to preclude further interpretation problems, let me present a
NR model that classifies what I consider to be the major aspects that
any system wishing to provide non-repudiation at any given level should
include, also naming each of a series of levels and providing for a division
between Variables (which I can't control) and Modifiers (which I can
control to some extent):

A. Variables -- involves only "you", where "you" is the one that authenticates

A1. syntatic form (Is the authentication yours?),

A2. semantic form (Did you understand what you were authenticating?),

A3. trust form (Did you yourself willfully authenticate it?),

A4. identification form (Are you the authenticator you claim to be?),

A5. temporal form (When did you authenticate it?),

A6. local form (Where did you authenticate it?),

A7. etc.


B. Modifiers -- involves also "me" (ie, "I", the verifier)

B1. legal form (Can I legally prove it?)

B2. liability form (Can you back and idemnify it to me?)

B3. extent form (What is the temporal and legal extent of the authentication, for you
                         towards me and me towards you?

B4. policy form (Is that allowed by the applicable policies, for you towards me
                         and me towards you?)

B5. etc.

Where I prefer to divide the issues of non-repudiation according to a
state-space where one has a FIRST set of clear variables which I do not
control, but measure:

 Variables: syntatic, semantic, trust, identification, temporal, local, etc.

and a SECOND set of clear modifiers which I can control at least to
some extent:

 Modifiers:  legal, liability, extent, policy, etc.

As needed, one combines the components for a specific
"law/policy non-repudiation system" as a logical function that uses
A1, A2,... and B1, B2, ...  above as functional inputs, but in
each respective classification.

So,  weak authentication (as provided by passwords) fails to
provide values for *ALL* variables when viewed under B.1
since any such value could be replayed at will by the verifier
(for example, or by an attacker) and there is nothing that the
password holder could do to avoid it. Thus, as a legal principle
valid in law theory in general (between power and liability),  since
the password holder has no power to deny weak authentication it
also has no derived liability from it, including non-repudiation.

However, it is possible that some A variables could provide
non-repudiation for passwords when viewed under the B4 modifier,
for example --  such as when an ISP uses A.1 and B.4 in order to
put an user's account on hold when two succesfull logins occur at a
given time (indicating either two persons using the same account or
a password compromise).  But, this is not legal NR -- which is what
we are focusing here.

So, to avoid further confusions whenever I mention NR, I mean legal
NR unless otherwise noted.
---------------------------------------copy/end------------------------

Cheers,

Ed Gerck



Received: from po1.bbn.com (PO1.bbn.com [192.1.50.38]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id LAA23838 for <[e-mail]>; Tue, 17 Aug 1999 11:50:10 -0700 (PDT)
Received: from [128.89.0.110] (COSMEC.BBN.COM [128.89.0.110]) by po1.bbn.com (8.9.1/8.9.1) with ESMTP id OAA07075; Tue, 17 Aug 1999 14:51:03 -0400 (EDT)
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
X-Sender: [e-mail]
Message-Id: <v04020a0bb3df5cbc4079@[128.89.0.110]>
In-Reply-To: <[e-mail]>
References: <[e-mail]> <v04020a13b3da4a3d754d@[128.89.0.110]>
Date: Tue, 17 Aug 1999 14:48:13 -0400
To: Paul Koning <[e-mail]>
From: Stephen Kent <[e-mail]>
Subject: Re: Non-Repudiation
Cc: [e-mail]

Oaul,

>Agreed.  But, unless I'm missing something, those don't involve the
>semantics, if any, of the NR bit.  It's the NR bit that's been the
>subject of this long drawn-out discussion.  My understanding of the NR
>concept has always been that it is tied to legal issues.  Viewed in
>purely technical isolation in such applications as IPSec endpoint
>authentication, it doesn't seem to do anything useful.

You are correct that NR is not a bit I would expect to set in certs used
for IPsec or SSL, for example.

>So I think the issues Bob raises are relevant.  If the only meaningful
>applications of the NR bit are tied to legal notions, but those legal
>notions aren't in agreement with what the NR bit does, or the
>mechanisms don't work to support them, then the NR bit doesn't
>actually do anything useful.  It doesn't seem like a good idea to have
>a bit whose name suggests a specific application, but it doesn't
>actually support those applications, and if it supports other things,
>those things aren't what the name implies.  Finding out whether that's
>indeed the case seems to be what the debate is all about.  I don't
>think it's appropriate to try to stop it while that issue clearly
>remains unsettled.

The issues Bob and Ed raise are relevant, but we do not agree that they are
correct.  The NR bit is provided to allow a CA to assert whether a
certificate is suitable for use in an NR context.  Not setting the bit is,
by itself, valuable, to prevent certs from being considered suitable as
part of NR evidence when there is clear intent that this not be done.
However, even when the NR bit is set, one must be cognizant of the policy
of the CA in question, which can be specified by a policy OID.  One might
ask if, given the availability of a policy OID, do we need to use the NR
bit?  Perhaps not.  But various combinations of uses of these fields are
possible.  For example, a CA may have on policy that covers all certs it
issues, and it may the rely on the NR bit to state which part of the policy
applies to a given cert.  Or, a CA may not put policy info into a cert and
rely on a posted CPS, and again rely on inclusion of the NR bit to trigger
which part of the CPS is applicable to the cert in question.

In each of these cases, there is a valid, reasonable use of the NR bit in
conjunction with other aspects of conveying NR policy info.  No one can
point to a uniform, international, legal approach to the technical details
of NR evidence, so it is not valid to argue that the examples I have cited
here are inconsistent with such (non-existant) rules.  Under these
circumstances is appropriate for the WG to continue to develop technical
mechanisms for expressing intent re the use of certs, so long as we have a
solid technical basis for doing so.

Steve


Received: from po1.bbn.com (PO1.bbn.com [192.1.50.38]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id LAA23606 for <[e-mail]>; Tue, 17 Aug 1999 11:40:44 -0700 (PDT)
Received: from [128.89.0.110] (COSMEC.BBN.COM [128.89.0.110]) by po1.bbn.com (8.9.1/8.9.1) with ESMTP id OAA05595; Tue, 17 Aug 1999 14:41:36 -0400 (EDT)
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
X-Sender: [e-mail]
Message-Id: <v04020a0ab3df5a6cb572@[128.89.0.110]>
In-Reply-To: <[e-mail]>
Date: Tue, 17 Aug 1999 14:35:17 -0400
To: "Bob Jueneman" <[e-mail]>
From: Stephen Kent <[e-mail]>
Subject: Re: Non-Repudiation
Cc: <[e-mail]>, <[e-mail]>

Bob,

>[snip]
>>Most of "we" are not trying to do what you suggest.  We are defining a bit
>>and explaining what we mean when the bit is turn on or off.  Others will
>>decide, over time, how that fits into any specific legal context.  We have
>>an obligation to make good technical decisions regarding the syntax and
>>processing for our protocols, and I believe that we are doing just that.
>
>The issue is not the syntax, but the semantics, and semantics necessarily
>involve more than just "good technical decisions".  Such decisions have
>to fit into a broader context of how the specifications and products
>embodying them are to be used.

I agree that the semantics are at issue here, but good technical judgement
IS still cntral to the operation of this and other IETF WGs.  Legislators
in different states and different parts of the world are tackling these
issues with  varying results.  The IETF is interneationla in scope and
generates standards that try not to bend to "local" laws/regulations
whenever the results may be skewed.  Note, for example, IESG/IAB/IETF
crypto policy.  In the absence of consistent, sound, legal bases for
discussing NR, I reject the notion that the PKIX standards should be
strongly influenced by the current, haphazard set of regulations.

>[snip]
>
>>Deliberation on a topic is valuable up to a point.  I think we passed that
>>point on this topic a while ago.
>
>Pardon me, Steve, but the fact that this issue has droned on for a number
>of years without any satisfactory resolution is an obvious indication that
>there is a lack of consensus on this.
>
>On the contrary, there seems to be a fair amount of consensus that the
>current definition and explanation of "what we mean when the bit is
>turned on or off"  is NOT adequate, and NOT a good technical decision,
>and various people are trying to decide how to fix it.

I read the traffic differently.  Some of the participants in the discussion
who are agruing that we got it wrong in 2459 are new to the list, at least
as contributors, and some others have had their say and failed to persuade
the WG to adopt a different approach.  We operate on concensus, not
unanimity.

Steve


Received: from rbhub100.chamb.disa.mil (rbhub100.chamb.disa.mil [209.22.120.23]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id LAA23079 for <[e-mail]>; Tue, 17 Aug 1999 11:08:11 -0700 (PDT)
Message-Id: <[e-mail]>
Received: by rbhub100.chamb.disa.mil with Internet Mail Service (5.5.2650.10) id <RCPZ163D>; Tue, 17 Aug 1999 14:08:52 -0400
From: "Zmudzinski, Tom" <[e-mail]>
To: tog <[e-mail]>
Cc: Alfred Arsenault <[e-mail]>, [e-mail], [e-mail]
Subject: Re[2]: And the definition of non-repudiation is....?
Date: Tue, 17 Aug 1999 14:08:31 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.10)
Content-Type: text/plain

>>> truncated message with additional comments <<<
> From:	tog <[e-mail]> on 08/16/99 10:46 PM
> To:	Alfred Arsenault <[e-mail]>, [e-mail], [e-mail]
> Subject:	Re: And the definition of non-repudiation is....?
>
> Comments Inline below
> 
> Todd
> ----- Original Message -----
> From: Alfred Arsenault <[e-mail]>
> To: <[e-mail]>; <[e-mail]>
> Sent: Monday, August 16, 1999 6:41 PM
> Subject: And the definition of non-repudiation is....?
> 
>> Ed,
>>
>> Since you so outspokenly oppose the definition of "non-repudiation"
>> from ISO 7498-2 which (most of) the group has been working under for
>> these last few years, perhaps you'd like to enlighten us as to the one
>> true, correct definition of non-repudiation?
>
> Actually, I will...
>
> Non-repudiation is a process that puts in place a trust model such that
any
> event that is "deemed nonrepudiable" is beyond question. It's about the
> totality of the trust model that surrounds the envelope of the transaction
> and the facilities for evaluating it. Such events are deemed
non-repudiated.

Now can we try it without the tautology?  The Defense Message System
defines non-repudiation as a security service that "protects against the 
denial by one of the entities involved in a message exchange of having 
participated in all or part of the exchange.  It supports the
proof-of-origin 
and the proof-of-receipt services that provide proof of message origin to 
the recipient and proof of message receipt to the sender.  Non-repudiation 
combines the use of modification detection with digital signatures.  These 
security services are vital in a military message system to verify that the 
proper authority issued an order and that the correct recipient received 
the order." -- DMS System Security Authorization Agreement Version 2.1

In the early days of DMS, we used to say simply [sorry about the message-
centric verbiage] that non-repudiation was that property which would 
demonstrate to an impartial third party that a given message had been 
sent by a specific individual or received by a specific individual.

v/r
Thomas E. Zmudzinski, CISSP                            [e-mail]
IPMO matrixed support for DMS PMO               703.681.9089 [DSN 761.9089]



Received: from honcho.austin.dascom.com (email.austin.dascom.com [206.196.73.5]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id IAA21059 for <[e-mail]>; Tue, 17 Aug 1999 08:21:24 -0700 (PDT)
Received: from austin.dascom.com by honcho.austin.dascom.com (8.8.8/SMI-SVR4) id KAA06891; Tue, 17 Aug 1999 10:17:58 -0500 (CDT)
Received: from shaggy by austin.dascom.com (8.8.8/SMI-SVR4) id KAA05929; Tue, 17 Aug 1999 10:17:57 -0500 (CDT)
Message-ID: <00bc01bee8c4$5e91cc80$[e-mail]>
Reply-To: "Bob Blakley" <[e-mail]>
From: "Bob Blakley" <[e-mail]>
To: "Ed Gerck" <[e-mail]>, "Alfred Arsenault" <[e-mail]>
Cc: <[e-mail]>, "Tony Bartoletti" <[e-mail]>, "Tod Glassey" <[e-mail]>
Subject: Re: And the definition of non-repudiation is....?
Date: Tue, 17 Aug 1999 10:22:50 -0500
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="----=_NextPart_000_00B9_01BEE89A.759291A0"
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

This is a multi-part message in MIME format.

------=_NextPart_000_00B9_01BEE89A.759291A0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit

All

>I very much liked Todd Glassey's operational definition of NR sent today to
this
>list: 'Non-repudiation is a process that puts in place a trust model such
that any
>event that is "deemed nonrepudiable" is beyond question.'

I hate this definition.  In a book on the CORBAsecurity service (to appear
this fall), which
includes a non-repudiation function, I used the following *informal*
definition, which is very
different from the one above.

"Non-repudiation services work by generating evidence of subjects' actions.
When a
dispute arises, non-repudiation evidence can be used to help settle the
issue."

The point I'm trying to make here is that the only service we can really
provide is
generation of evidence.  We can use various mechanisms to make the evidence
plausible or compelling - including using strong cryptography, good trust
models,
good physical security, etc.....  But NONE of this puts an event "beyond
question",
because in the contexts in which protection against repudiation (=
non-repudiation
protection) is an issue, disputes always arise (hence there is by definition a
question),
and they are always settled according to procedures which include rules of
evidence
etc....

Ed's larger point, that the only context in which NR makes sense is the legal
context, is exactly right.  But so is Steve's - all we can do is to provide
technical
mechanisms of evidence generation which have well-understood properties,
and work with the lawyers to make sure that we've chosen the right properties
and are able to explain them to lawyers, judges, and juries so that they
understand the evidence they're evaluating.

--bob

Bob Blakley ([e-mail])
Chief Scientist, Dascom



------=_NextPart_000_00B9_01BEE89A.759291A0
Content-Type: text/x-vcard;
	name="Bob Blakley.vcf"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment;
	filename="Bob Blakley.vcf"

BEGIN:VCARD
VERSION:2.1
N:Blakley;Bob
FN:Bob Blakley
ORG:Dascom
TITLE:Chief Scientist
TEL;WORK;VOICE:[phone] x 5012
TEL;WORK;FAX:[phone]
ADR;WORK;ENCODING=3DQUOTED-PRINTABLE:;;Plaza Balcones=3D0D=3D0A5515 =
Balcones Drive;Austin;TX;78731;USA
LABEL;WORK;ENCODING=3DQUOTED-PRINTABLE:Plaza Balcones=3D0D=3D0A5515 =
Balcones Drive=3D0D=3D0AAustin, TX 78731=3D0D=3D0AUSA
URL:
URL:http://www.dascom.com
EMAIL;PREF;INTERNET:[e-mail]
REV:19990817T152250Z
END:VCARD

------=_NextPart_000_00B9_01BEE89A.759291A0--



Received: from marcellus.cost.se (marcellus.cost.se [195.100.88.66]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id CAA14886; Tue, 17 Aug 1999 02:36:14 -0700 (PDT)
Received: from wallace ([10.0.0.13]) by marcellus.cost.se (8.9.3/8.9.3) with SMTP id LAA25843; Tue, 17 Aug 1999 11:28:04 +0200 (MET DST)
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32)
Date: Tue, 17 Aug 1999 11:26:55 +0200
To: "Andrew Farrell" <[e-mail]>
From: Peter Siklosi <[e-mail]>
Subject: RE: X9.42 and RFC2459 inconsistency? 
Cc: "John Hughes" <[e-mail]>, [e-mail], [e-mail], Darren Harter <[e-mail]>, <[e-mail]>, <[e-mail]>
In-Reply-To: <000a01bedb94$0e50ed60$0138d90a@joh-laptop>
References: <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"

Andrew,

In the RFC2459, section 7.3.2, it says:

   "The Diffie-Hellman OID supported by this profile is defined by ANSI X9.42"

I am not sure what you mean by the "X9.42 oid with the pfc 2459 semantics".

Regards,
Peter


John Hughes wrote:
>We can generate D-H certificates - and we use the rfc 2459 dhpublicnumber
>OID.

Andrew Farrel wrote:
> You mean the X9.42 oid with the pfc 2459 semantics? Do you have serious
> "Permanent root for paying customer" certs using this out there? And if
> so, why? :)




Received: from tomcat.sac.verio.net ([e-mail] [209.162.64.15]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id XAA06419 for <[e-mail]>; Mon, 16 Aug 1999 23:03:05 -0700 (PDT)
Received: from nma.com (pm02-12.sac.verio.net [209.162.64.31]) by tomcat.sac.verio.net (8.9.1a/8.9.1) with ESMTP id XAA23916; Mon, 16 Aug 1999 23:03:50 -0700 (PDT)
Message-ID: <[e-mail]>
Date: Mon, 16 Aug 1999 23:03:56 -0700
From: Ed Gerck <[e-mail]>
X-Mailer: Mozilla 4.61 [en]C-CCK-MCD {Sony}  (Win98; I)
X-Accept-Language: en
MIME-Version: 1.0
To: Alfred Arsenault <[e-mail]>
CC: [e-mail], Tony Bartoletti <[e-mail]>, Tod Glassey <[e-mail]>
Subject: Re: And the definition of non-repudiation is....?
References: <[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Alfred Arsenault wrote:

> Ed,
>
>         Since you so outspokenly oppose the definition of "non-repudiation"
> from ISO 7498-2 which (most of) the group has been working under for
> these last few years, perhaps you'd like to enlighten us as to the one
> true, correct definition of non-repudiation?

Yes, and what should we do about the expected polemic around such NR
definition, specially since good definitions are usually abstract -- "is this
definition of NR the right one?".  Since this question is inevitable, let me
address it first.

Clearly, this will be a right question.  And I hope that nothing that I have
written or will write here will be interpreted as a claim that my definition of
NR will be the "right" or the only possible one. But, answer we must --
what is "the right one"?

Here, perhaps the only metric we may accept is [Leshniewski]:  "A theory,
ultimately, must be judged for its accord with reality". This is the reason why I
have extensively looked into the question of what nonrepudiation is and what it
is not,  and have so much enjoyed the discussion here with so many different
takes at it from many different participants and perspectives, when comparing
the different legal, technical and linguistic usages of the word "nonrepudiation"
in our reality -- for several stances and observer relationships.

Thus, I think we would need to verify any proposed definition of NR in terms
of its derived results based on different stances and observer relationships,
including other areas besides technical communication processes, such as to
test its usage also when modeling nonrepudiation for legal and social
communication processes -- e.g., power relationships, managerial activities,
contracts, auditing, interpersonal relationships,  etc.  -- because they will all
play a role "before" and "after" PKIX certificates are used and (somehow)
PKIX certs must "glue" to these interfaces.

All this, seems to me, is beyond the PKIX charter, however.  So, we may be
left with a chicken and egg problem unless we try to simplify the question and
simply stay for the moment with a NR definition that says the least we need
to say -- thus, avoiding conflicts with interfaces "before" and "after" PKIX.
For example, no more statements on "falsely denying", "providing", "irrefutable
evidence", etc.

In this sense, I suggest that this WG's definition of NR should be operational,
minimalistic, and cast in terms PKIX variables -- rather than a formal logic
definition valid in general (as I have discussed in the MCG list), or a NR model
(such as I presented here and elsewhere) that is too broad for the cases dealt
with by PKIX in a protocol.

I very much liked Todd Glassey's operational definition of NR sent today to this
list: 'Non-repudiation is a process that puts in place a trust model such that any
event that is "deemed nonrepudiable" is beyond question.'

As I see it, this definition needs some fine tunning but it sucessfully operationalizes
NR in terms of trust -- however, trust is outside the scope of PKIX.  Also, we
need to connect NR to that pesky bit.  So, taking into account that we have more
nonrepudiation states than simply on-off (see my previous msg -- at least three
on states and three off states), we could have something like this in the PKIX spec:

1. Non-repudiation is a process based on a trust model defined in the CPS
and its usage is asserted by setting the non-repudiation bit.

Following this text, a particular usage of NR could have many logical states while a
boolean bit could still be used to define whether a NR service is available or not
in services associated with that cert.

An alternative definition of NR (my preferred choice and one which I have stated
already, before) would be to negate any semantics to the NR bit beyond its own
syntatic expression in PKIX itself as a boolean bit, while defining NR as a
qualified pointer (i.e., not as a dangling clause): "Non-repudiation is defined in
the CPS.".  The resulting text in the spec would be:

1'. Non-repudiation is defined in the CPS and its usage is asserted by setting the
non-repudiation bit.

Definition (1') includes definition (1) as subcase.  Either of these two NR
definitions would allow for logically consistent CPSs because anyone writing
a CPS could use this list's archives and adequate legal counsel in order to verify
what a "non-repudiation service" could or could not provide in each particular
case -- for example, for a company acting as a CA in its own interest or as a
commercial CA acting on behalf of the subscriber.  Also, the CPS could define
the validation services required for that NR service during the lifetime of the
cert, in accord to risk/cost, and any other issues that may be relevant to
nonrepudiation for each case -- such as insurance, jurisdiction, legal capacity,
maximum cumulative coverage, delay time to maturation, etc.

In terms of text changes, either of these two NR definitions could directly
substitute the following legacy paragraph in 2459, in its entirety:

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

(ie, deleting the above paragraph).

NOTE: Since nonrepudiation is not used in PKIX itself, the situation that results
from (1) or (1') is much better than X.509/PKIX usage of the concept of trust
itself -- which is defined a posteriori in the CPS but used a priori in the specs.
This is one more reason to prefer (1') over (1), IMO -- because, since (1) < (1'),
nothing is lost in either in expressive capacity or in coherence when (1') is used.

> Or is it your assertion that there is no such thing as non-repudiation, and we
> should just drop it from PKIX altogether?

No, and never was. In fact, I have been stressing that this discussion is important
also because the concept of  nonrepudiation is IMO logically needed and cannot
be subsummed under authentication.

As Tony Bartoletti wrote today: ".. it seems that in a contract or transaction of
such value that NR becomes a goal, its benefits could be applied to any and all
of these usages [data authentication, endpoint authentication, digital signature]."

So, if NR can be applied to any and all of such services then this also indicates
that NR cannot be of the same type of any of them. Thus, in a geometric
model, non-repudiation is in an orthogonal axis to authentication -- not a
"better" or "stronger" authentication act or, even, an improvement over
authentication.  NR is, simply, different than authentication -- apples
and speedboats.

That is why I commented elsewhere that NR is not a "stronger" type
of authentication and that usage of such concept would lead to
contradictions -- e.g., since nonrepudiation evidence (even if cryptographic)
can always be repudiated by authentication evidence (even if
non-cryptographic).

Cheers,

Ed Gerck



Received: from www.meridianus.com (209.249.223.11.has.no.reverse [209.249.223.11] (may be forged)) by mail.proper.com (8.9.3/8.9.3) with ESMTP id TAA20763 for <[e-mail]>; Mon, 16 Aug 1999 19:31:16 -0700 (PDT)
Received: from PC1 by www.meridianus.com (8.8.8+Sun/SMI-SVR4) id UAA08128; Mon, 16 Aug 1999 20:25:19 -0700 (PDT)
Message-ID: <004801bee85a$c105dc40$[e-mail]>
From: "tog" <[e-mail]>
To: "Alfred Arsenault" <[e-mail]>, <[e-mail]>, <[e-mail]>
References: <[e-mail]>
Subject: Re: And the definition of non-repudiation is....?
Date: Mon, 16 Aug 1999 19:46:10 -0700
Organization: Meridianus
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.2918.2701
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2918.2701

Comments Inline below

Todd
----- Original Message -----
From: Alfred Arsenault <[e-mail]>
To: <[e-mail]>; <[e-mail]>
Sent: Monday, August 16, 1999 6:41 PM
Subject: And the definition of non-repudiation is....?


> Ed,
>
> Since you so outspokenly oppose the definition of "non-repudiation"
> from ISO 7498-2 which (most of) the group has been working under for
> these last few years, perhaps you'd like to enlighten us as to the one
> true, correct definition of non-repudiation?

Actually, I will...

Non-repudiation is a process that puts in place a trust model such that any
event that is "deemed nonrepudiable" is beyond question. It's about the
totality of the trust model that surrounds the envelope of the transaction
and the facilities for evaluating it. Such events are deemed non-repudiated.

> Or is it your assertion
> that there is no such thing as non-repudiation, and we should just drop
> it from PKIX altogether?

No it's very necessary - However, the reality is that the NR bit, as it sits
today is nearly useless IMHO, because what its intended use is is to signal
that there is something different or "more better" about this instance of a
cert process. What it actually should be is an OID or a blob of data that
can be used to describe why or how this non-repudiated status was awarded to
this entity, since this NR BIT's use is clearly an evidentiary process or
enablement for complex decision processing.

>
> Always looking to improve my understanding

me to!

>
> Al Arsenault
>
> -- these comments represent the opinions of the author.  Nobody else.
>

Ditto



Received: from mail.rdc1.md.home.com ([e-mail] [24.2.2.66]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id SAA14342 for <[e-mail]>; Mon, 16 Aug 1999 18:42:21 -0700 (PDT)
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]>; Mon, 16 Aug 1999 18:43:16 -0700
Message-ID: <[e-mail]>
Date: Mon, 16 Aug 1999 21:41:28 -0400
From: Alfred Arsenault <[e-mail]>
Organization: @Home Network
X-Mailer: Mozilla 4.5 [en]C-AtHome0405  (Win95; U)
X-Accept-Language: en
MIME-Version: 1.0
To: [e-mail], [e-mail]
Subject: And the definition of non-repudiation is....?
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Ed,

	Since you so outspokenly oppose the definition of "non-repudiation"
from ISO 7498-2 which (most of) the group has been working under for
these last few years, perhaps you'd like to enlighten us as to the one
true, correct definition of non-repudiation?  Or is it your assertion
that there is no such thing as non-repudiation, and we should just drop
it from PKIX altogether?

	Always looking to improve my understanding,

				Al Arsenault

-- these comments represent the opinions of the author.  Nobody else.


Received: from poptop.llnl.gov (poptop.llnl.gov [128.115.18.65]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id SAA14079 for <[e-mail]>; Mon, 16 Aug 1999 18:40:43 -0700 (PDT)
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 SAA05736 for <[e-mail]>; Mon, 16 Aug 1999 18:41:30 -0700 (PDT)
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.3 (32)
Date: Mon, 16 Aug 1999 18:41:25 -0700
To: [e-mail]
From: Tony Bartoletti <[e-mail]>
Subject: To Be, or NR To Be ...
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"

The more I think about this NR-bit discussion, the more I begin
to question some of the founding motivations.

Often, there is posited a supposedly sharp distinction between 
these three key usages (leaving aside crypto for confidentiality):

1.  Data Authentication (or Integrity).
    The purpose, to tamperproof data during transport.  The data
    as received is the data as sent.

2.  Endpoint Authentication.
    The purpose, to thwart "origin spoofing".  That data really
    did come from X, and was really received by Y.

3.  "Digital Signature".
    The purpose, to enforce "I meant to do that."  I intend to
    be bound by terms contained in the data.

 (Unfortunately, the root mechanism expected to enable these
 assurances is often the same in each case, a digital signature.
 And all hinge on some assumption about who/what wields the key.)

On the surface, it seems reasonable to make these distinctions.
In particular, to (hope to) apply NR only to usage (3).  And yet
it seems that in a contract or transaction of such value that
NR becomes a goal, its benefits could be applied to any and all
of these usages.

If I employed a PK solution to authenticate "remote logins",
why should I settle for a mere "repudiable" login?

And to loosely paraphrase Ed Gerck:  If you think you are talking
with the US President, but in reality it is Saddam Hussein, then
what does having a "tamperproof, data-protected" channel buy you?

These use-cases have overlapping effects and implications, in
particular due to the characteristics of the PK mechanism.

In PK, most all bets hinge upon "who holds the private key".
The only value a certificate NR-bit can hold is one that conveys
some reliable assurance about uniquely identifying the keyholder.

It must have some value beyond "I better be REAL careful with
THIS key, since its (cert's) NR-bit is set." (death penalty cert.)

As Ed has asked, Who is authoritative regarding the NR-bit setting?
And I ask, what are the "lower and upper bounds" to what it being
attested to in each case?

___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 tomcat.sac.verio.net ([e-mail] [209.162.64.15]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id PAA05920 for <[e-mail]>; Mon, 16 Aug 1999 15:51:47 -0700 (PDT)
Received: from nma.com (pm09-02.sac.verio.net [209.162.65.115]) by tomcat.sac.verio.net (8.9.1a/8.9.1) with ESMTP id PAA25244; Mon, 16 Aug 1999 15:52:39 -0700 (PDT)
Message-ID: <[e-mail]>
Date: Mon, 16 Aug 1999 15:52:42 -0700
From: Ed Gerck <[e-mail]>
X-Mailer: Mozilla 4.61 [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
References: <[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

"David P. Kemp" wrote:

> > From: Ed Gerck <[e-mail]>
> >
> > A secondary but overshadowing mistake is, as I have also commented, that
> > this IETF WG may be connected with an extension of IETF protocols over
> > the domain of applications and, even, what "user intent" is. Language in the
> > current text says :
> >
> >  " ...to provide a non-repudiation service which protects against the signing
> >   entity falsely denying some action"
> >
> > and now we have user intent ("falsely denying") as a parameter in an IETF
> > spec, besides the empty word "protects".
>
> Ed,
>

[snip, already commented]

> "User intent" has no connection with "denying" - I can deny driving
> above the speed limit, or I can deny intending to drive above the
> speed limit while admitting that in fact I did.

But the language used is "falsely denying", not denying.  And, in both
versions (Dave: I am bundling here my reply to your other msg on X509
vs. 2459 NR text):

1. X.509, "12.2.2.3 Key Usage field":

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

2. RFC 2459:

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

So, either section goes into the mistakes of stating intention (viz, "falsely
denying some action")  and providing a blank service ("protects against")
and IMO this adds nothing that will be missed elsewhere in the specs.

But, will the solution be a simple deletion of the word "falsely"?  No, because
such "protection" is not possible at all *within* PKIX.  This is not like an
umbrella that "protects" against rain or cryptography that "protects" against
eavesdropping. This is a nonrepudiation service which is NOT provided in
PKIX by that pesky bit and hence setting it neither "protects" nor fails to
"protect" anything that PKIX can reach, provide, enforce or even negate.
In particular, as said here several times, the "nonrepudiation bit" is neither
necessary nor sufficient for nonrepudiation --so, not seting it can also allow
NR to be applied.

As Paul Koning commented today:

"It doesn't seem like a good idea to have  a bit [NR] whose name suggests
a specific application, but it doesn't actually support those applications, and
if it supports other things, those things aren't what the name implies."

Further, the nonrepudiation bit is NOT "used in providing" any
nonrepudiation service described elsewhere in the spec or even elsewhere
else (pls, no pointers to the abstract, wrong and useless ISO definition of
NR).

This is also what is called, in technical writing terms, a "dangling clause":

dangling clause:  to occur in a sentence without having a normally expected
syntactic relation to the rest of the sentence <the word climbing in
"Climbing the mountain the cabin came into view" is dangling>.

Good for poetry, when ambiguity and obscurity are useful and allows each
reader to use their own imagination, but it is a capital sin in technical and
legal writing.

> RFC 2459 does not have "user intent" as a parameter.

As above, "falsely denying" is an user intention -- Webster:

false:  intentionally untrue <false testimony> b : adjusted or made so
as to deceive <false scales> <a trunk with a false bottom>
c : intended or tending to mislead <a false promise>

>  The X.509 certificate format contains nothing with respect to user
> intent.

Ditto, the same mistake as above in "12.2.2.3.b" -- and, it is not the
only place where X.509 makes this mistake but this is not relevant to
NR so I will skip it here.

> A CA claims nothing about user intent WRT a specific transaction when
> signing a cert with the NR bit (or any other bit) asserted; the CA
> claims only that the key may be used for a particular purpose.

Perhaps, not even this.  As we all know, this is where PKIX sends the
reader to the each CA's CPS -- so what a CA 'claims' is off-topic to
the PKIX NR discussion, IMO.

> If you have a piece of data covered by a digital signature, you have a
> piece of evidence that a particular private key was used to generate
> the signature.  The type of data is relevant to PKIX: it could be a random
> number used in a challenge-response entity authentication protocol, or
> it could be something with intrinsic meaning (a message).
>
> The NR bit is set if the *purpose* of the signature is to create an object
> that can later be shown to have been signed by the private key.

This is not what the spec says, as above. But, even if it did, one would
have some other questions and three cases for bit-on and three cases
for bit-off which would need to be well-defined in the specs:

1. Who is authoritative for the nonRepudiation bit state, the
CA or the subscriber?

2. Can a CA use PKIX in order to permit or prohibit a
particular subscriber certificate from being used in a
transaction?

3. Take a certificate with the nonRepudiation bit on
-- what can the relying-party depend upon: (i) in regard
to the certificate;  (ii) in regard to a transaction signed
with the certificate; (iii) in regard to the transaction being
repudiated?

4   Take a certificate with the nonRepudiation bit off --
is this a negation, or a declaration of non-existence, or a
declaration of an ignored feature?  To clarify, if the NR
bit is off, does it mean that the NR is denied, or that
NR does not exist, or that NR can still be provided if so
declared elsewhere?

5. Are questions (1-4) beyond the scope of PKIX?

These are the main technical  questions that need to be and can
be addressed here, IMO. Dangling clauses will not help -- this
is not pkix-poetry ;-)

Cheers,

Ed Gerck



Received: from tomcat.sac.verio.net ([e-mail] [209.162.64.15]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id OAA04975 for <[e-mail]>; Mon, 16 Aug 1999 14:44:05 -0700 (PDT)
Received: from nma.com (pm09-02.sac.verio.net [209.162.65.115]) by tomcat.sac.verio.net (8.9.1a/8.9.1) with ESMTP id OAA06719; Mon, 16 Aug 1999 14:44:30 -0700 (PDT)
Message-ID: <[e-mail]>
Date: Mon, 16 Aug 1999 14:44:33 -0700
From: Ed Gerck <[e-mail]>
X-Mailer: Mozilla 4.61 [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: rat hole, was  Re: Non-Repudiation
References: <[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

"David P. Kemp" wrote:

> > From: Ed Gerck <[e-mail]>
> >
> > A secondary but overshadowing mistake is, as I have also commented, that
> > this IETF WG may be connected with an extension of IETF protocols over
> > the domain of applications and, even, what "user intent" is. Language in the
> > current text says :
> >
> >  " ...to provide a non-repudiation service which protects against the signing
> >   entity falsely denying some action"
> >
> > and now we have user intent ("falsely denying") as a parameter in an IETF
> > spec, besides the empty word "protects".
>
> Ed,
>
> If this discussion is a rat hole,

Unfortunately, you misread and I did not say or imply that this
discussion is a rat hole, neither did I coin the term.  Pls read
my original text, after I commented that the present NR bit
setting and definition could "create lateral damage, besides
their own technical and legal damage":

} Already in another thread here, we can read [Russ Housley]:
}
} "The setting of the nonrepudiation bit is a rat hole, as you can see on
} other threads on ietf-pkix.  It does not impact cert path validation, so I
} would like to avoid that rat hole...."

Thus, clearly, the term 'rat hole' in regard to NR was coined by Russ
and it is clear that he did not mean the NR discussions either, but the
current definitions used in setting the NR bit in the PKIX spec.

> you must take some partial responsibility for injecting irrelevancies into it.

Also, I fail to see any irrelevancies in any of my emails posted in this
context here -- including this one. The first relevant purpose of this
email is simply to show again that Steve Kent has brought it upon
himself to have the setting of the NR bit described by other persons
as a "rat hole" -- for example, by using Tina Turner to exemplify
what he believes is the NR trust model or by his other misleading
comments referred to in the 'rat hole' message.  So, no, Steve did
not have my help in order to inject irrelevancies into his debate.

Indeed, I have waited to see if the situtation would improve and
then, when it did  not,  decided to answer to the point (not bullying)
when I saw that the obvious was being negated once again.

In regard to legal issues, yes, they must not be involved in IETF protocols
but they must not be ignored either. Otherwise, those protocols will be
either "illegal" or useless.  Since I have no interest whatsoever in IETF
politics, I guess I am also rather free and unbiased when saying it.

And, IMO, the lawyers will get their "revenge" and field day when they realize
how insecure, misrepresented and misleading those products are out there
and then go after the companies that produced them or that were involved
in their production, and that effected misprision by setting 'standards' that they
said were 'true', 'fine' and 'safe' but they themselves knew they were not as
proved by list archives, emails, etc -- if the tobacco lawsuits can teach
us anything.

I tried to show otherwise by stressing the positive qualities -- not by
being uncorteous, irrelevant, bullying in debate, or less than deliberative,
which could be taken as an excuse by a person to cut off debate, but that
was BTW already cut off IMO.

Thoughtful, group-aware and courteous messages are IMO the only way
to try to put things in a useful track.  If you read anything else in my
messages, pls read again.  Sometimes we must share differences, which
are sometimes (unfortunately) distorted by email flatness that then they
get reconstructed with too much emotion.

Again, I am not questioning anyone's authority or the Chair's authority or
using my email as a personal argument vector (not even this one) but I
am pointing out that the Chair of this WG has overstepped that limit
defined when bullying a debate -- that  limit over which people may just
politely bow and let the way clear to the cliff.

I indeed believe this limit has been reached in this WG in regard to Steve's
comments and I have shown it by quoting several instances where I have
rather let the mistake pass uncommented than going for a dog fight with
Tina Turner.  Further, recognizing that this limit was overstepped is the
first action needed in order to solve it -- which must be done by those
that brought it upon themselves, of course.  And, that is how I ended
my message:

} So, in all fairness,  I think this WG has reached a reasonable intersubjective
} understanding of the NR issue and it is now up to the spec scribes to make
} the next move and correct the old spec version. That is what this WG is for,
} no?

Cheers,

Ed Gerck



Received: from stingray.missi.ncsc.mil (stingray.missi.ncsc.mil [144.51.50.20]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id NAA03929 for <[e-mail]>; Mon, 16 Aug 1999 13:38:53 -0700 (PDT)
Received: from stingray.missi.ncsc.mil (root@localhost) by stingray.missi.ncsc.mil with ESMTP id QAA29382 for <[e-mail]>; Mon, 16 Aug 1999 16:39:46 -0400 (EDT)
Received: from missi.ncsc.mil (depot.missi.ncsc.mil [144.51.60.1]) by stingray.missi.ncsc.mil with ESMTP id QAA29378 for <[e-mail]>; Mon, 16 Aug 1999 16:39:45 -0400 (EDT)
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 QAA22527 for <[e-mail]>; Mon, 16 Aug 1999 16:39:38 -0400 (EDT)
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 QAA24075 for <[e-mail]>; Mon, 16 Aug 1999 16:38:29 -0400 (EDT)
Message-Id: <[e-mail]>
Date: Mon, 16 Aug 1999 16:38:29 -0400 (EDT)
From: "David P. Kemp" <[e-mail]>
Reply-To: "David P. Kemp" <[e-mail]>
Subject: Re: rat hole, was  Re: Non-Repudiation
To: [e-mail]
MIME-Version: 1.0
Content-Type: TEXT/plain; charset=us-ascii
Content-MD5: c6IM6ID4kLpB7sxxLmRe5Q==
X-Mailer: dtmail 1.3.0 CDE Version 1.3 SunOS 5.7 sun4u sparc

> From: Ed Gerck <[e-mail]>
> 
> A secondary but overshadowing mistake is, as I have also commented, that
> this IETF WG may be connected with an extension of IETF protocols over
> the domain of applications and, even, what "user intent" is. Language in the
> current text says :
> 
>  " ...to provide a non-repudiation service which protects against the signing
>   entity falsely denying some action"
> 
> and now we have user intent ("falsely denying") as a parameter in an IETF
> spec, besides the empty word "protects".


Ed,

If this discussion is a rat hole, you must take some partial
responsibility for injecting irrelevancies into it.  "User intent" has
no connection with "denying" - I can deny driving above the speed
limit, or I can deny intending to drive above the speed limit while
admitting that in fact I did.  Radar evidence says absolutely nothing
about my intent, yet provides generally-accepted protection against the
first denial.  The word "protects" itself is no more empty than any
other word in a dictionary.  A signature obviously does not protect
data -- software and people and procedures and mathematical algorithms
protect data -- yet in common parlance it is always said that keys
protect data and no one is confused about what is meant.

RFC 2459 does not have "user intent" as a parameter.  The X.509
certificate format contains nothing with respect to user intent.  A CA
claims nothing about user intent WRT a specific transaction when
signing a cert with the NR bit (or any other bit) asserted; the CA
claims only that the key may be used for a particular purpose.

If you have a piece of data covered by a digital signature, you have a
piece of evidence that a particular private key was used to generate
the signature.  The type of data is relevant to PKIX: it could be a random
number used in a challenge-response entity authentication protocol, or
it could be something with intrinsic meaning (a message).

The NR bit is set if the *purpose* of the signature is to create an object
that can later be shown to have been signed by the private key.

The DS bit is set (and NR unset) if the *purpose* of the signature is
something else (such as an authenticated session), notwithstanding the
fact that protocol byproducts might be used later in forensic analysis.

User intent and many many other factors are critically important when
using PKIs and digital signatures to support business processes.  But
it is not the purpose of the Internet X.509 PKI Certificate and CRL
Profile to describe business processes.  Perhaps we need a "pki-talk"
mail list.



Received: from dkeynt1.DATAKEY.COM (dkeynt1.datakey.com [205.218.59.2]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id MAA02899 for <[e-mail]>; Mon, 16 Aug 1999 12:18:16 -0700 (PDT)
Received: from datakey.com ([205.218.59.75]) by dkeynt1.DATAKEY.COM (Netscape Messaging Server 3.5)  with ESMTP id 330; Mon, 16 Aug 1999 14:21:36 -0500
Message-ID: <[e-mail]>
Date: Mon, 16 Aug 1999 14:25:12 -0500
From: "Dale Gustafson" <[e-mail]>
X-Mailer: Mozilla 4.61 [en] (WinNT; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Anders Rundgren <[e-mail]>, [e-mail]
CC: [e-mail], Bob Jueneman <[e-mail]>
Subject: Re: Smart Card sign key and PIN-code Was: Non-Repudiation
References: <001401bee62b$0188fe50$[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Anders, Peter,

When I first became aware of the requirements for the German Digital Signature laws
I thought the desire to control the mechanics of all signing key operations at the
crypto library level (essentially from the time the key pair was created) seemed
more than a little awkward.  Having listened to the ongoing PKIX debates on NR, I
can better understand the need to define such restrictions for a signing only key
pair.  These concepts may be useful irrespective of whether the key pair is created
and stored in a smart card or in a software lib.

Additional comments inline.

Best Regards,

Dale Gustafson


Anders Rundgren wrote:

> Just a little comment on the side of this great(?) NR-debate.
> I think that this requirement to force a different PIN for signings and
> always require it is a bit rigid.  It should depend on what you are signing.
>
> For example: Assume that all credit-card transactions should be signed.  If
> you require low value-payments (that you tend to do frequently) also to
> go through a lengthy sequence of keying, such a system may become rather
> impopular.  In the CyberPhone/Thin PKI specification there is a limit like
> $1000/24 hours before the system will enforce a PIN-code.  To always have
> to use the PIN-code lowers security as it will be exposed in public.

Good point -- we need to ensure that such distinctions can be accomodated.


> For authentication purposes, a high-value resource should probably have
> its own "PIN-code" and the PIN-code in the user-end becomes less needed
> (redundant I would say).
>
> Anders
>
> -----Original Message-----
> From: Peter Gutmann <[e-mail]>
> To: [e-mail] <[e-mail]>
> Date: Saturday, August 14, 1999 01:45
> Subject: Re: Non-Repudiation
>
> >"Dale Gustafson" <[e-mail]> writes:
> >
> >>Smart card vendors will provide software libraries and card operating systems
> >>that include support for a "signing only" key pair.  The distinguishing
> >>characteristic of this special type of public/private key pair is that access
> >>to the private key component is protected by a special "Signing Key PIN"
> >>(distinct from the User PIN that controls general user access to the card).
> >>The Signing Key PIN must be entered each and every time that private key is
> >>used to create a digital signature (preferably through a protected
> >>authentication path reader device -- the PIN characters go directly from the
> >>keyboard or PINpad to the card and do not traverse the user's desktop or
> >>laptop machine.)
> >
> >Is there any rigorous definition of exactly what's required for this, or just a
> >general requirement that a user explicitly take some action to enable the key
> >for each use?  The way I've implemented this is to allow an extra key attribute
> >which acts as a usage counter for the object (eg a signature key), after every
> >use the counter is decremented and once it reaches zero the object destroys
> >itself.  For the "signing only" use described above, you'd just set the counter
> >to 1.  This sort of thing would be fairly easy to add onto existing
> >implementations, for example it could be a new PKCS #11 attribute which can be
> >set when a key object is created (but not changed afterwards), once you've
> >implemented it in the PKCS #11 driver you'd automatically have support for it
> >in any apps which use the driver.

I think the intent is that making a digital signature should be a "willful act" on
the part of the signer.  Entering a signing PIN for each digital signature operation
has been given as but one example of how a system could be implemented.  Clicking a
single button on a computer screen was given as a counter example of a user
operation that perhaps did not require sufficient user attention to be deemed a
"willful act".  For source material, I've been using the ESSSI Final Report, 7/20/99
provided earlier by Nick Pope or Denis Pinkas.

At the crypto library level, these high level requirements have been translated to a
specific capability:

 - a signing-only key pair can be created such that the user must be authenticated
(via a unique PIN) prior to using the private key as part of a digital signature
operation
 - the user is logged in to the signing key for the duration of a single digital
signature operation only.

The following is (at best) a very rough approximation of one of the new capabilities
being defined for PKCS#11, version 2.1.  The secure application will be able to
create a signing-only key pair that has a special, write-only (can never be read by
any application / can only be updated by a user or application who knows the current
value) attribute that contains the "signing PIN" for this key pair.  This PIN must
be entered each and every time the private key component is used to create a digital
signature.  Programatically, the signing PIN is provided by the calling application
once for each digital signature operation (a multiple command sequence in PKCS#11).
If a protected authentication path (secure PIN) reader is used, the crypto library
is directed by the secure application to initiate secure PIN entry via the
computer's keyboard or a PINpad device that's part of the reader, etc.

Similar signing key access control logic could be provided in software
implementations (sans secure keyboard/PINpad reader and smart card, of course).

> >
> >Peter.
> >
> >



Received: from stingray.missi.ncsc.mil (stingray.missi.ncsc.mil [144.51.50.20]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id KAA01936 for <[e-mail]>; Mon, 16 Aug 1999 10:58:29 -0700 (PDT)
Received: from stingray.missi.ncsc.mil (root@localhost) by stingray.missi.ncsc.mil with ESMTP id NAA10863 for <[e-mail]>; Mon, 16 Aug 1999 13:59:16 -0400 (EDT)
Received: from missi.ncsc.mil (depot.missi.ncsc.mil [144.51.60.1]) by stingray.missi.ncsc.mil with ESMTP id NAA10857 for <[e-mail]>; Mon, 16 Aug 1999 13:59:16 -0400 (EDT)
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 NAA20571 for <[e-mail]>; Mon, 16 Aug 1999 13:59:09 -0400 (EDT)
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 NAA24044 for <[e-mail]>; Mon, 16 Aug 1999 13:58:00 -0400 (EDT)
Message-Id: <[e-mail]>
Date: Mon, 16 Aug 1999 13:58:00 -0400 (EDT)
From: "David P. Kemp" <[e-mail]>
Reply-To: "David P. Kemp" <[e-mail]>
Subject: Re: Non-Repudiation
To: [e-mail]
MIME-Version: 1.0
Content-Type: TEXT/plain; charset=us-ascii
Content-MD5: t+wb4Nea77QN9619fBg/lg==
X-Mailer: dtmail 1.3.0 CDE Version 1.3 SunOS 5.7 sun4u sparc

> From: Ed Gerck <[e-mail]>
> 
>
> So, if commerce thrives and actually favors wide reaching return policies
> (i.e., favors not harassing the consumer with a non-repudiation bit of prose),
> why should this WG favor the opposite and introduce PKIX as a tribunal
> over its users, with language such as (2459):
> 
>  " ...to provide a non-repudiation service which protects against the signing
>   entity falsely denying some action"
> 
> I think it is time to stop beating around the bush and calling examples that do
> not fit at all in the case at hand or speak in lawyerly terms, and just make the
> changes needed to make precise the semantics of the nonRepudiation bit.  This
> responsibility falls IMO on the spec authors, but I believe this list has provided
> ample examples and counterexamples.


The relevant text from X.509 is:

    12.2.2.3 Key Usage field

    This field, which indicates the purpose for which the certified public key
    is used, is defined as follows:
    
    ...
    
    b) 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);


This text makes no claims that a NR bit provides a NR service, or that the
private key or certified public key provide a NR service.  What it says is
that the key is to be *USED IN* providing a NR service, i.e.:

  IF there is a system (of legal, procedural and technical elements)
   that does provide protection (including after-the-fact sanctions
   with the purpose of deterrence) against an entity falsely denying
   some action,

  THEN the NR bit indicates that the purpose of the keypair is to support
   such a system.

Is there any disagreement that this is a legitimate, entirely correct,
reading of the X.509 words?

(I do believe that the X.509 text "used in providing a NR service" is
more precise than 2459's "used to provide a NR service", and that the
replacement for 2459 should use the X.509 language.)


> Thus, where IMO the present PKIX spec fails is that by saying too much
> the baby is going with the baby water. The NR text in 2549 (which I
> quoted before) should be simply deleted IMO, as a first correcting action.

If the text were incorrect, then deleting it would be a step towards
clarity.  But the text is correct.  Perhaps, at 129 pages, RFC 2459
does not contain enough descriptive and tutorial information, and the
Security Considerations section should be expanded to explain the
technical and legal requirements for a system to effectively support
non-repudiation.

Or perhaps not :-).

There is, of course, a lot of bath water that goes along with the baby.
The statement "this key is used in providing a confidentiality service"
leaves a tremendous amount unsaid, but is nonetheless a useful statement.



Received: from prv-mail20.provo.novell.com (prv-mail20.provo.novell.com [137.65.82.195]) by mail.proper.com (8.9.3/8.9.3) with SMTP id JAA00499 for <[e-mail]>; Mon, 16 Aug 1999 09:13:25 -0700 (PDT)
Received: from INET-PRV-Message_Server by prv-mail20.provo.novell.com with Novell_GroupWise; Mon, 16 Aug 1999 10:04:52 -0600
Message-Id: <[e-mail]>
X-Mailer: Novell GroupWise 5.5.2
Date: Mon, 16 Aug 1999 10:04:45 -0600
From: "Bob Jueneman" <[e-mail]>
To: <[e-mail]>, <[e-mail]>
Cc: <[e-mail]>
Subject: Controls over signing keys (Was: Re; Non-repudiation)
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 mail.proper.com id JAA00500

Dale, in addition to supporting smart cards, we are also very interested in supporting
high-integrity software-only solutions that supporting signing and even nonrepudiation.
Understanding a set of requirements that would pertain to both hardware and software
via a PKCS #11 interface would be extremely useful.

So I encourage you (and Peter) to continue to post whatever comments you might 
have in this area to the entire group.  

Bob


> "Dale Gustafson" <[e-mail]> writes:
>
> >Smart card vendors will provide software libraries and card operating systems
> >that include support for a "signing only" key pair.  The distinguishing
> >characteristic of this special type of public/private key pair is that access
> >to the private key component is protected by a special "Signing Key PIN"
> >(distinct from the User PIN that controls general user access to the card).
> >The Signing Key PIN must be entered each and every time that private key is
> >used to create a digital signature (preferably through a protected
> >authentication path reader device -- the PIN characters go directly from the
> >keyboard or PINpad to the card and do not traverse the user's desktop or
> >laptop machine.)
>
> Is there any rigorous definition of exactly what's required for this, or just a
> general requirement that a user explicitly take some action to enable the key
> for each use?  The way I've implemented this is to allow an extra key attribute
> which acts as a usage counter for the object (eg a signature key), after every
> use the counter is decremented and once it reaches zero the object destroys
> itself.  For the "signing only" use described above, you'd just set the counter
> to 1.  This sort of thing would be fairly easy to add onto existing
> implementations, for example it could be a new PKCS #11 attribute which can be
> set when a key object is created (but not changed afterwards), once you've
> implemented it in the PKCS #11 driver you'd automatically have support for it
> in any apps which use the driver.

Will provide more info. off-list (e.g., to save bandpass).

>
> Peter.



Received: from dkeynt1.DATAKEY.COM (dkeynt1.datakey.com [205.218.59.2]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id HAA29324 for <[e-mail]>; Mon, 16 Aug 1999 07:59:26 -0700 (PDT)
Received: from datakey.com ([205.218.59.75]) by dkeynt1.DATAKEY.COM (Netscape Messaging Server 3.5)  with ESMTP id 383; Mon, 16 Aug 1999 10:02:43 -0500
Message-ID: <[e-mail]>
Date: Mon, 16 Aug 1999 10:06:18 -0500
From: "Dale Gustafson" <[e-mail]>
X-Mailer: Mozilla 4.61 [en] (WinNT; U)
X-Accept-Language: en
MIME-Version: 1.0
To: [e-mail]
CC: [e-mail]
Subject: Re: Non-Repudiation
References: <[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Peter,

My comments below were intended primarily as an FYI to the list. :-)

It's interesting to note that multiple groups appear to be defining and creating
architectures that require the end user to take some overt action (presumably at a
decision point) during the process of creating a digital signature in support of an
NR service.

Best Regards,

Dale Gustafson


Peter Gutmann wrote:

> "Dale Gustafson" <[e-mail]> writes:
>
> >Smart card vendors will provide software libraries and card operating systems
> >that include support for a "signing only" key pair.  The distinguishing
> >characteristic of this special type of public/private key pair is that access
> >to the private key component is protected by a special "Signing Key PIN"
> >(distinct from the User PIN that controls general user access to the card).
> >The Signing Key PIN must be entered each and every time that private key is
> >used to create a digital signature (preferably through a protected
> >authentication path reader device -- the PIN characters go directly from the
> >keyboard or PINpad to the card and do not traverse the user's desktop or
> >laptop machine.)
>
> Is there any rigorous definition of exactly what's required for this, or just a
> general requirement that a user explicitly take some action to enable the key
> for each use?  The way I've implemented this is to allow an extra key attribute
> which acts as a usage counter for the object (eg a signature key), after every
> use the counter is decremented and once it reaches zero the object destroys
> itself.  For the "signing only" use described above, you'd just set the counter
> to 1.  This sort of thing would be fairly easy to add onto existing
> implementations, for example it could be a new PKCS #11 attribute which can be
> set when a key object is created (but not changed afterwards), once you've
> implemented it in the PKCS #11 driver you'd automatically have support for it
> in any apps which use the driver.

Will provide more info. off-list (e.g., to save bandpass).

>
> Peter.



Received: from sjc3-1.relay.mail.uu.net (sjc3-1.relay.mail.uu.net [199.171.54.122]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id HAA28714 for <[e-mail]>; Mon, 16 Aug 1999 07:02:22 -0700 (PDT)
Received: from xedia.com by sjc3sosrv11.alter.net with SMTP  (peer crosschecked as: madway.xedia.com [198.202.232.199]) id QQhcng29714; Mon, 16 Aug 1999 14:04:20 GMT
Received: from tonga.xedia.com by xedia.com (4.1/SMI-4.1) id AA04912; Mon, 16 Aug 99 10:01:30 EDT
Received: by tonga.xedia.com (SMI-8.6/SMI-SVR4) id KAA03195; Mon, 16 Aug 1999 10:02:57 -0400
Date: Mon, 16 Aug 1999 10:02:57 -0400
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]
Subject: Re: Non-Repudiation
References: <[e-mail]> <v04020a13b3da4a3d754d@[128.89.0.110]>
X-Mailer: VM 6.34 under 20.3 "Vatican City" XEmacs  Lucid

>>>>> "Stephen" == Stephen Kent <[e-mail]> writes:

 Stephen> Bob,
 >> The reason why I have been so interested in the legal issues of
 >> PKI is that the four companies I have worked for in the 15 or so
 >> years I've been involved in this space have all had a reasonable
 >> expectation that eventually a product (or service) would emerge
 >> from this that they could make some money on.  If we were only
 >> interested in protecting casual e-mail, certainly PGP would have
 >> been a lot easier to develop and use.  But for business uses, it
 >> is simply not possible to ignore the potential legal issues, and I
 >> have been working to try to draw the technologists and the legal
 >> community toward a common understanding of these issues.

 Stephen> There are many examples of PKI use where the thorny legal
 Stephen> issues you cite do NOT arise, as I have noted in the past.
 Stephen> For example, using certs for authentication for SSL and
 Stephen> IPsec, in lieu of using passwords, SecurID cards etc. 

Agreed.  But, unless I'm missing something, those don't involve the
semantics, if any, of the NR bit.  It's the NR bit that's been the
subject of this long drawn-out discussion.  My understanding of the NR 
concept has always been that it is tied to legal issues.  Viewed in
purely technical isolation in such applications as IPSec endpoint
authentication, it doesn't seem to do anything useful.

So I think the issues Bob raises are relevant.  If the only meaningful 
applications of the NR bit are tied to legal notions, but those legal
notions aren't in agreement with what the NR bit does, or the
mechanisms don't work to support them, then the NR bit doesn't
actually do anything useful.  It doesn't seem like a good idea to have 
a bit whose name suggests a specific application, but it doesn't
actually support those applications, and if it supports other things,
those things aren't what the name implies.  Finding out whether that's 
indeed the case seems to be what the debate is all about.  I don't
think it's appropriate to try to stop it while that issue clearly
remains unsettled.

	paul


Received: from stargate.zergo.com.au (IDENT:[e-mail] [203.2.208.130]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id UAA20127 for <[e-mail]>; Sun, 15 Aug 1999 20:44:21 -0700 (PDT)
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 NAA14317; Mon, 16 Aug 1999 13:46:32 +1000
Received: by sydneymail1.jp.zergo.com.au with Internet Mail Service (5.5.2448.0) id <Q5K5BKZA>; Mon, 16 Aug 1999 13:45:25 +1000
Message-ID: <[e-mail]>
From: Michael Zolotarev <[e-mail]>
To: Peter Sylvester <[e-mail]>, [e-mail]
Cc: Denis.Pinkas[[e-mail]]
Subject: RE: Lets Standardize Time Representation Formats!!!: WAS Re: New  TSTTimedefinition
Date: Mon, 16 Aug 1999 13:45:14 +1000
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2448.0)
Content-Type: text/plain; charset="iso-8859-1"

Peter wrote:
>Using the same format for a secure document and a time stamp, namely CMS is
>a good thing IMHO. In other words, a time stamp itself is simply a signed
>document, and as such similar or identical procedures to validate and
verify
>the content can be use.
>Another element is that the result can become an signed attribute of
another
>signed document thus binding together data and additional information.

TimeStamp is currently defined as a CMS's signedData, isn't it?

>As it is indicated in the DCS text, a time stamping authority becomes just
>one example of a more general model. An entity communicates with other
>entities in order to distribute or collect information in order to
>enhance the value of a document. 

Even with DCS, time stamping may still maintain its value as a separate
service. DCS would reach out to a TSA in order to get a TS token, and
encapsulate it. Right?

>'Time stamping' is not 'everything'. If one tries to solve 'everything'
>by using just time stamping, indeed things become overcomplicate as you
>say. Replace the word 'time stamping' by 'data certification' (where
>data can be time) for example. higher level data may have a different
value,
>thus they may justify additional effort.

But I was talking about time stamping, so it was "everything" in the context
of the mail :). Maintaining "chain of trust" in time stamping makes "it"
overcomplicated.
Chain of trust may be perfectly legitimate for other data certification
services, of course.

>> 
>> *** Precision and Accuracy ***
>> I guess this is where most of people have finally come to common grounds:
We
>> need sub-second resolution, and we need the accuracy. Where the accuracy
is
>> defined as a diapason, deviation from the 'absolute time'. The guaranteed
>> minimum accuracy should be defined in the TSA policy statement, allowing
a
>> customer to chose a provider. The actual accuracy can be placed in the
>> token, reflecting the current conditions. The accuracy can NOT be greater
>> then a precision (i.e.. 12.30'17'' +- .1 is fine, but 12.30'17''001 +- .1
is
>> wrong).

>In your model the accuracy is not needed. 12.30'17'' is always different
>from 12.30'18'' if the accuracy is less a second += .5 What does an
accuracy
>of .1 second buy you if your precision if one second.  

12.30'17'' is always different from 12.30'18'' only if your clock is
accurate within a second. What if it not, and the clock's deviation from
"real" time is +- 2 seconds? In other words, "the time is 12.30'17'' +-
2sec". 
But you are right - I've made a mistake. Should the definition rather be:
"The units of accuracy MUST be the same as the precision's factor: i.e.
12.30'17'' +- 1 sec. 12.30'17''.5 +- .1, 12.30'17''.15 +- .03"

>2 different needs:
>
>- A format that is not almost printable calender based like
generalizedtime,
>  as initial proposal think about a REAL representing international
>  atomic time. but: how many implementations can convert correctly an NTP
>  time into a correctly encoded DER REAL :-)
>
>- An format where the TSTInfo is just another Token from another provider
>  (just using a SignedDocument). (cf DCSTime)

I agree in principle that we need more then one time presentation format
here, and probably more then just 2. 
However, the International Atomic Time format can be only an optional
feature, unless we mandate that all TSA read time from the IAT source.

As a common denominator, I believe ASN1 GeneralizedTime + accuracy is a good
choice. Any other time presentation formats and provider's tokens can be
included as optional fields into the TSTTime. The problem is 1) how are we
going to identify the optional elements - using OIDs or tags, and 2) do we
define the set now or leave the list open?

Should we introduce a TSTTime::Version element? This would allow us to move
on, assuming that any enhancements can be implemented later, under different
version numbers?

TSTTime ::= Sequence
{
	version	INTEGER [0]
	tstTime	GeneralizedTime  // MAY include sub-second precision
	accuracy	INTEGER OPTIONAL // interpreted as units of the
tstTime's precision
	// serialNumber ??? Sorry, I am not quite sure what was the
conclusion about having it here
}


Regards
MichaelZ


Received: from popmail.inbox.se (popmail.inbox.se [193.12.72.101]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id EAA25650 for <[e-mail]>; Sun, 15 Aug 1999 04:48:29 -0700 (PDT)
Received: from foo.telia.se (t4o68p101.telia.com [62.20.139.221]) by popmail.inbox.se (8.9.3/8.9.3) with SMTP id NAA27336; Sun, 15 Aug 1999 13:48:58 +0200
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 
Date: Sun, 15 Aug 1999 13:50:10 +0200
To: "Bill Brice (listserv)" <[e-mail]>, [e-mail]
From: Stefan Santesson <[e-mail]>
Subject: Re: Qualified Certificates and NR
In-Reply-To: <9E60D6A452AAD211904E00105A1973FD02CEDB@ATDEV1>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"

Bill,

Comments in line.

At 12:47 1999-08-11 -0500, Bill Brice (listserv) wrote:
>All,
>
>The recently published Qualified Certificates draft states
>regarding key usage and NR:
>
>---
>3.2.3 Key Usage
>
>The key usage extension SHALL be present. If the key usage nonRepudi-
>ation (1) is asserted then it SHALL NOT be combined with any other
>key usage, i.e. if set, the key usage non-repudiation SHALL be set
>exclusively.
>---
>
>The above requirement would mandate that a QC cert be only used 
>for signing based on policy defined NR requirements. 
>

No. This is only true if the NR bit is set.

>My query is a practical one. I see two issues. First,
>this requirement precludes QC certs from being dual use, as
>is common now (RSA signing + encryption), which is typically done
>by combining the digital signature bit with the key encipherment bit
>(if used as all). 

No. This works just fine. But these bits can't be combined with the NR bit.

>This list knows the security value of single use certs,
>but most software in use today can't handle them. Certain versions of
>Netscape and Microsoft email software would see a QC cert in a signed
>message, save it in the address book, and later use it for sending
>an encrypted message back to the signer.
>
>What is the value of precluding other, complementary, bits when the
>NR bit is asserted in a QC cert? Is this really what is desired?
>

The NR bit covers digital signatures used for NR. No other bits have to be
set to meet this purpose.
If this bit is set, these types of certificates should not be combined with
other usages.

The reason for this is to avoid repudiation of signatures due to the fact
that the private key was used to sign an important agreement under another
key-usage policy than the NR-bit.

>The second issue: Does anyone know what today's popular software would do
>with a cert that had only the NR bit set? Would it recognize it as
>valid for signing without the digital signature bit being set?
>

Yes absolutely. I know of several and they use the right interpretation of
the bits. The digital signature bit is only defined for purposes OTHER than
non-repudiation. See RFC 2459 and X.509.

>-Bill Brice, CEO
>alphatrust.com

/Stefan


Received: from popmail.inbox.se (popmail.inbox.se [193.12.72.101]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id EAA25468 for <[e-mail]>; Sun, 15 Aug 1999 04:39:15 -0700 (PDT)
Received: from foo.telia.se (t3o68p29.telia.com [62.20.139.29]) by popmail.inbox.se (8.9.3/8.9.3) with SMTP id NAA27287; Sun, 15 Aug 1999 13:39:46 +0200
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 
Date: Sun, 15 Aug 1999 13:40:59 +0200
To: "Anders Rundgren" <[e-mail]>, "'SEIS-List'" <[e-mail]>, "PKIX-List" <[e-mail]>
From: Stefan Santesson <[e-mail]>
Subject: Re: QC - Unmistakable Identity Attributes
In-Reply-To: <000301bee438$b1dc9f40$[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"

Anders,

I have problem understanding your question. Do you mean the subject field
or the PersonalData field (in subjectAltName extension)?

In the subject field the attributes SHALL form a distinguished name
(X.500). If this is sufficient in order to establish an unmistakable
identity (that by unmistakable means relates to a person), the Personal
Data field may be omitted.

In the PersonalData field, the attributes must form an unmistakable identity.

So the answer to your question is that the attributes in the subject field
does NOT have to form an unmistakable identity if the PersonalData field is
used to serve that purpose.

/Stefan


At 21:32 1999-08-11 +0100, Anders Rundgren wrote:
>Pardon me, I have probably just read the QC draft badly (but repeatedly), 
>but I just 
>can't figure out if an attribute that according to the QC-draft CAN be used 
>to uniquely
>identify a subject, always MUST be used to create the unique identity. I 
>hope not.
>Or is this a part of the CPS to define which of the specified attributes 
>that should
>be used to uniquely identify a subject?
>
>Section 4 security 
><snip> 
>     Finally, matching rules are not specified for the new attributes 
>     defined in the PersonalData field. It is not expected that two quali- 
>     fied certificates would be compared to determine if they represent 
>     the same physical entity. Such a comparison may provide misleading 
>     and should not be performed. 
><snip>
>
>1. Skip "new" in the first paragraph, as it is only "new" at this 
>pre-standard stage. 
>
>2. I don't understand the rest. If applied to let's say a typical ID-card 
>program 
>I would say the statement is wrong. I think that a major point with 
>unmistakable 
>identity is to be able to have a long-lasting certificate-based relationship 
>without 
>any hassles for RPs and subjects.  If identity is allowed to change for a 
>subject
>it is a part of the CPS and if a comparision is possible or not is then 
>outside the
>scope of the draft (which BTW should be mentioned).
>
>Anders
>



Received: from tomcat.sac.verio.net ([e-mail] [209.162.64.15]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id BAA15736 for <[e-mail]>; Sat, 14 Aug 1999 01:18:35 -0700 (PDT)
Received: from nma.com (pm03-15.sac.verio.net [209.162.64.81]) by tomcat.sac.verio.net (8.9.1a/8.9.1) with ESMTP id BAA01231; Sat, 14 Aug 1999 01:19:12 -0700 (PDT)
Message-ID: <[e-mail]>
Date: Sat, 14 Aug 1999 01:19:03 -0700
From: Ed Gerck <[e-mail]>
X-Mailer: Mozilla 4.51 [en]C-CCK-MCD {Sony}  (Win98; I)
X-Accept-Language: en
MIME-Version: 1.0
To: Stephen Kent <[e-mail]>
CC: Bob Jueneman <[e-mail]>, "[e-mail]" <[e-mail]>
Subject: rat hole, was  Re: Non-Repudiation
References: <v04020a13b3da4a3d754d@[128.89.0.110]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Stephen Kent wrote:

> Bob Jueneman wrote:
> >The reason why I have been so interested in the legal issues of PKI is
> >that the four companies I have worked for in the 15 or so years I've been
> >involved in this space have all had a reasonable expectation that eventually a
> >product (or service) would emerge from this that they could make some money
> >on.
> >If we were only interested in protecting casual e-mail, certainly PGP
> >would have been a lot easier to develop and use.  But for business uses,
> >it is simply not possible to ignore the potential legal issues, and I
> >have been working to try to draw the technologists and the legal community
> >toward a common understanding of these issues.
>
> There are many examples of PKI use where the thorny legal issues you cite
> do NOT arise, as I have noted in the past.  For example, using certs for
> authentication for SSL and IPsec, in lieu of using passwords, SecurID cards
> etc.  So, irrespective of the casual e-mail example, we have lots of
> situations that are of value to businesses but which do not involve NR and
> do not require "help" from attorneys.

Steve:

The US has 50% of the world's lawyers. This is also the only country
I know of where amateur lawyers are accepted. And yet, based on
my direct professional experience in Germany, Belgium, US, Argentina and
Brazil and also with companies based in Sweden, Switzerland, Japan, Italy
and France, I have not yet seen a country where the gulf between lawyers
and non-lawyers is so large.  No one needs "help" from attorneys, since they
usually charge for it ;-),  but anyone that uses the word "business" and then
denies any value of "legal issues" in regard to it either does not know business,
does not know law or thinks that the reader does not know them.

So, I must agree 100% with Bob Jueneman when he affirms: "for business uses,
it is simply not possible to ignore the potential legal issues".  As a bit of advice,
I suggest you do too.

BTW, using client certs for authentication in SSL does introduce a series of
new legal questions over using passwords -- but I am not going to explain
this again since I already did it in the list. I am just noting that lack of
opposition oftentimes does not denote accord but simply a courteous attitude
in face of lack of understanding.  This is also why I chose not to reply when, for
example, you denied the need to consult a CRL before relying on an S/MIME
message.  Or, when you denied the need for fresh data in NR. Or, when you
insisted that the lifetime of a certificate is inversely proportional to the square
of the number of attributes.  I believe however these actions are an overstepping
of your function as WG Chair since this WG is not supposed to be an one-man
show, and I do not say this in order to question your authority or as a personal
argument but to point out that bullying the debate has a limit -- over which
people may just politely bow and let the way clear to the cliff.

Again, I don't care what  ISO says about NR because ISO is wrong and
several voices here have said this besides myself, and ISO is a private
company -- not an international treaty organization that must be followed.
Surely, ISO is entitled to their  opinions or 'standards' -- so, I have
nothing against ISO per se.  But the argument  that IETF matters are
defined by ISO would mean that IETF must also abandon TCP/IP and
SMTP (just to cite a few cases).  So, I do not buy it.

If my private mailbox could be proof, or if one would do an unbiased survey
of the PKIX list messages over the past weeks I believe it would become
clear that the WG consensus is that the present definition of NR *and* the
present text on the nonRepudiation bit are both misleading and need to be
changed ASAP before they create lateral damage, besides their own technical
and legal damage.

Already in another thread here, we can read [Russ Housley]:

"The setting of the nonrepudiation bit is a rat hole, as you can see on
other threads on ietf-pkix.  It does not impact cert path validation, so I
would like to avoid that rat hole...."

I note also that, of recent, you have been insisting that "I think we passed that
point on this topic a while ago" in regard to revisiting the NR bit .  Thus, I infer
that this is the last strawman argument on the NR debate.  But, I do not buy it.

Since I have no interest whatsoever in IETF politics or long rethorics over
the "broad base of WG members",  and my motivation is essentially
technical as an Engineer and a Ph.D., you may take my opinion as a sincere
vision of what list consensus indicates is a largely uncontrolled liability and a
rat hole, regardless how old the mistake is or how "small" that bit may seem.

A secondary but overshadowing mistake is, as I have also commented, that
this IETF WG may be connected with an extension of IETF protocols over
the domain of applications and, even, what "user intent" is. Language in the
current text says :

 " ...to provide a non-repudiation service which protects against the signing
  entity falsely denying some action"

and now we have user intent ("falsely denying") as a parameter in an IETF
spec, besides the empty word "protects".  Perhaps, following this slippery
slope further down, a new WG should be formed to discuss an RFC on
"falsely denying" and define how it  can be established in a protocol over the
wire. Clearly, I am exaggerating -- but, how else, pray tell, could you define
"falsely denying" in an IETF protocol?  The exaggeration is thus not in my
words but in what is affirmed in that spec.

So, in all fairness,  I think this WG has reached a reasonable intersubjective
understanding of the NR issue and it is now up to the spec scribes to make
the next move and correct the old spec version. That is what this WG is for,
no?

Cheers,

Ed Gerck






Received: from caesar.udac.se (caesar.udac.se [193.44.79.10]) by mail.proper.com (8.9.3/8.9.3) with SMTP id AAA15035 for <[e-mail]>; Sat, 14 Aug 1999 00:02:02 -0700 (PDT)
Received: from mega (t3o69p109.telia.com [62.20.145.109]) by caesar.udac.se (8.7.3/NetworkC-1) with SMTP id JAA69903; Sat, 14 Aug 1999 09:02:30 +0200
Message-ID: <001401bee62b$0188fe50$[e-mail]>
From: "Anders Rundgren" <[e-mail]>
To: <[e-mail]>, <[e-mail]>
Cc: <[e-mail]>
Subject: Smart Card sign key and PIN-code Was: Non-Repudiation
Date: Sat, 14 Aug 1999 08:59:58 +0100
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 mail.proper.com id AAA15036

Just a little comment on the side of this great(?) NR-debate.
I think that this requirement to force a different PIN for signings and
always require it is a bit rigid.  It should depend on what you are signing.

For example: Assume that all credit-card transactions should be signed.  If
you require low value-payments (that you tend to do frequently) also to
go through a lengthy sequence of keying, such a system may become rather
impopular.  In the CyberPhone/Thin PKI specification there is a limit like
$1000/24hours before the system will enforce a PIN-code.  To always have
to use the PIN-code lowers security as it will be exposed in public.

For authentication purposes, a high-value resource should probably have
its own "PIN-code" and the PIN-code in the user-end becomes less needed 
(redundant I would say).  

Anders

-----Original Message-----
From: Peter Gutmann <[e-mail]>
To: [e-mail] <[e-mail]>
Date: Saturday, August 14, 1999 01:45
Subject: Re: Non-Repudiation


>"Dale Gustafson" <[e-mail]> writes:
>
>>Smart card vendors will provide software libraries and card operating systems
>>that include support for a "signing only" key pair.  The distinguishing
>>characteristic of this special type of public/private key pair is that access
>>to the private key component is protected by a special "Signing Key PIN"
>>(distinct from the User PIN that controls general user access to the card).
>>The Signing Key PIN must be entered each and every time that private key is
>>used to create a digital signature (preferably through a protected
>>authentication path reader device -- the PIN characters go directly from the
>>keyboard or PINpad to the card and do not traverse the user's desktop or
>>laptop machine.)
>
>Is there any rigorous definition of exactly what's required for this, or just a
>general requirement that a user explicitly take some action to enable the key
>for each use?  The way I've implemented this is to allow an extra key attribute
>which acts as a usage counter for the object (eg a signature key), after every
>use the counter is decremented and once it reaches zero the object destroys
>itself.  For the "signing only" use described above, you'd just set the counter
>to 1.  This sort of thing would be fairly easy to add onto existing
>implementations, for example it could be a new PKCS #11 attribute which can be
>set when a key object is created (but not changed afterwards), once you've
>implemented it in the PKCS #11 driver you'd automatically have support for it
>in any apps which use the driver.
>
>Peter.
>
>



Received: from mail.student.auckland.ac.nz (mail.student.auckland.ac.nz [130.216.35.101]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id RAA02986 for <[e-mail]>; Fri, 13 Aug 1999 17:43:38 -0700 (PDT)
Received: from kahu.cs.auckland.ac.nz ([e-mail] [130.216.36.13]) by mail.student.auckland.ac.nz (8.8.6/8.8.6/cs-master) with SMTP id MAA08371 for <[e-mail]>; Sat, 14 Aug 1999 12:44:15 +1200 (NZST) (sender [e-mail])
Received: by kahu.cs.auckland.ac.nz (relaymail v0.9) id <93459103804479>; Sat, 14 Aug 1999 12:37:18 (NZST)
From: [e-mail] (Peter Gutmann)
To: [e-mail]
Subject: Re: Non-Repudiation
Sender: [e-mail]
Reply-To: [e-mail]
X-Charge-To: pgut001
X-Authenticated: relaymail v0.9 on kahu.cs.auckland.ac.nz
Date: Sat, 14 Aug 1999 12:37:18 (NZST)
Message-ID: <[e-mail]>

"Dale Gustafson" <[e-mail]> writes:

>Smart card vendors will provide software libraries and card operating systems
>that include support for a "signing only" key pair.  The distinguishing
>characteristic of this special type of public/private key pair is that access
>to the private key component is protected by a special "Signing Key PIN"
>(distinct from the User PIN that controls general user access to the card).
>The Signing Key PIN must be entered each and every time that private key is
>used to create a digital signature (preferably through a protected
>authentication path reader device -- the PIN characters go directly from the
>keyboard or PINpad to the card and do not traverse the user's desktop or
>laptop machine.)

Is there any rigorous definition of exactly what's required for this, or just a
general requirement that a user explicitly take some action to enable the key
for each use?  The way I've implemented this is to allow an extra key attribute
which acts as a usage counter for the object (eg a signature key), after every
use the counter is decremented and once it reaches zero the object destroys
itself.  For the "signing only" use described above, you'd just set the counter
to 1.  This sort of thing would be fairly easy to add onto existing
implementations, for example it could be a new PKCS #11 attribute which can be
set when a key object is created (but not changed afterwards), once you've
implemented it in the PKCS #11 driver you'd automatically have support for it
in any apps which use the driver.

Peter.



Received: from poptop.llnl.gov (poptop.llnl.gov [128.115.18.65]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id RAA02732 for <[e-mail]>; Fri, 13 Aug 1999 17:34:42 -0700 (PDT)
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 RAA07263; Fri, 13 Aug 1999 17:34:53 -0700 (PDT)
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.3 (32)
Date: Fri, 13 Aug 1999 17:34:51 -0700
To: "Bob Jueneman" <[e-mail]>, <[e-mail]>
From: Tony Bartoletti <[e-mail]>
Subject: Re: Non-Repudiation
Cc: <[e-mail]>
In-Reply-To: <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"

Bob and Stephen,

You both make valid points, and I don't know where best to draw a line
between syntax and semantics.  One certainly cannot imbue a bit with
any meaning besides "on/off", and yet its utility must be made clear.

Otherwise, I suggest adding an "Alpha-bit" to the profile with the
following utility:

  1.  PKIX-compliant products must recognize the Alpha-bit.
  2.  Each CA is free to accept or reject certificate requests
      according to the Alpha-bit setting. 
  3.  Refer to each CA's CP/CPS regarding the intention of that
      CA with respect to the Alpha-bit setting.

Of course, Relying-Parties should be aware of both the CA's intent
regarding the Alpha-bit, as well as their own vendor's certificate
software (browser) processing behaviors regarding the Alpha-bit,
lest they incur unexpected liabilities.

OK, The profile says more about the NR-bit than the Alpha-bit.
But not sufficient to preclude these debates, it seems.

___tony___

At 05:17 PM 8/13/99 -0600, Bob Jueneman wrote:
>
>
>>>> Stephen Kent <[e-mail]> 08/13/99 04:32PM >>>
>[snip]
>>Most of "we" are not trying to do what you suggest.  We are defining a bit
>>and explaining what we mean when the bit is turn on or off.  Others will
>>decide, over time, how that fits into any specific legal context.  We have
>>an obligation to make good technical decisions regarding the syntax and
>>processing for our protocols, and I believe that we are doing just that.
>
>The issue is not the syntax, but the semantics, and semantics necessarily
>involve more than just "good technical decisions".  Such decisions have
>to fit into a broader context of how the specifications and products 
>embodying them are to be used.
>
>[snip]
>
>>Deliberation on a topic is valuable up to a point.  I think we passed that
>>point on this topic a while ago.
>
>Pardon me, Steve, but the fact that this issue has droned on for a number
>of years without any satisfactory resolution is an obvious indication that 
>there is a lack of consensus on this.  
>
>On the contrary, there seems to be a fair amount of consensus that the
>current definition and explanation of "what we mean when the bit is 
>turned on or off"  is NOT adequate, and NOT a good technical decision,
>and various people are trying to decide how to fix it.
>
>Bob
>
>
>


Received: from tomcat.sac.verio.net ([e-mail] [209.162.64.15]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id RAA02362 for <[e-mail]>; Fri, 13 Aug 1999 17:09:06 -0700 (PDT)
Received: from nma.com (pm04-03.sac.verio.net [209.162.64.116]) by tomcat.sac.verio.net (8.9.1a/8.9.1) with ESMTP id RAA01175; Fri, 13 Aug 1999 17:09:43 -0700 (PDT)
Message-ID: <[e-mail]>
Date: Fri, 13 Aug 1999 17:09:40 -0700
From: Ed Gerck <[e-mail]>
X-Mailer: Mozilla 4.51 [en]C-CCK-MCD {Sony}  (Win98; I)
X-Accept-Language: en
MIME-Version: 1.0
To: Bob Jueneman <[e-mail]>
CC: [e-mail], [e-mail]
Subject: Re: Non-Repudiation
References: <[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Bob Jueneman wrote:

> However, I tend to disagree with your characterization of all of this
> as a CA issue, for other than perhaps counter-signing or witnessing
> the subscriber's desire to enable a particular key/certificate for a higher
> level of presumptive validity, I don't think the CA plays a role at all
> with respect to nonrepudiation.

Bob:

We are in agreement. I don't know what you tend to disagree with
but I believe it is not in the above.  BTW, just to make it clearer, this
is what I wrote before on the role the CA can/cannot play, as the
topic you mention seems also to fall under my question (2) of
two days ago:

 2. Can a CA use PKIX in order to permit or prohibit a
 particular subscriber certificate from being used in a
 transaction?

And the answer IMO is no, only the CPS can handle it in a consistent
way by policy or legal restrictions since all the CA can do is take good
care of what the CA signs, not what the subscriber signs.  The certificate
itself can be seen as a tamperproof communication channel from CA to
r-p but no assurance can be provided on how the corresponding
subscriber's private-key  is used in a transaction at the subscriber's
platform.

Thus, PKIX should allow such matters to be handled in the CPS.
Otherwise, if this would be pre-empted in the specs (as the *current*
specs do) then IMO this will very probably be either too vague or
too restrictive in a general case.

> And in particular, although this is just my personal opinion, I don't think
> that the CPS is going to be particularly relevant in this area, since contracts
> are not transitive.

Here we do seem to disagree in basics, but not by the reason you provide.
My reasons to say the above were provided earlier in this thread, but
I comment some below.

> Even if the subscriber agrees to a contract with the CA, and even if
> the RP also contracts with the CA

I posit that a relationship CA-RP  always exists and that is why the
relying-party is called a "relying-party" in a CPS. That is also why a
CPS exists in first place -- to save the CA from the relying-party
obligations it would otherwise have.  I note, however, that this has
nothing to do with the fact that the relying-party is not privy to the
contract between CA and subscriber -- which is another
problem for non-repudiation.

> I have said repeatedly that "technical nonrepudiation" is NOT required
> in order for a signature to be legally binding.

Not even "legal nonrepudiation" is required. However, yesterday you may
have slipped a few words too much when you distinguished between "digital
signatures" and "legally binding, nonrepudiation type fo signatures":

> 2.  Authentication, using what is conventionally called a digital signature, and in
> ....
>
> 3.  Legally binding, "nonrepudiation" type of signatures reflecting the user's intent to be
> legally bound, ....

and I simply noted that a digital signature can be legally binding even though repudiable.
And, I also noted that this is very useful nowadays and even preferred by commerce
in general, so it is not a bad idea to let PKIX also reflect it.  Further, I disagreed in
basics with the notion of  "reflecting the user's intent to be legally bound" and
commented that such may be possible in smart-cards but not all in PKIX. Contrary
to a smart-card, the objects in PKIX are exchanged exclusively among applications
(not between an application and a user).

The distinction you seem to have meant in items #2 and #3 above could be better
expressed in the following way, IMO:

2. Authentication, or digital signature without attribution to a persona (ie, a
legal entity with adequate capacity for the act).

3. Legally binding signature, or digital signature with attribution to a persona.

and, I would add:

4. Legally binding nonrepudiation signature, or  digital signature with attribution
both to a persona and to nonrepudiation.

But, again, I think this WG has reached a resonable intersubjective understanding of
the NR issue and it is now up to the spec scribes to make the next move.

Cheers,

Ed Gerck



Received: from prv-mail20.provo.novell.com (prv-mail20.provo.novell.com [137.65.82.195]) by mail.proper.com (8.9.3/8.9.3) with SMTP id QAA01813 for <[e-mail]>; Fri, 13 Aug 1999 16:21:12 -0700 (PDT)
Received: from INET-PRV-Message_Server by prv-mail20.provo.novell.com with Novell_GroupWise; Fri, 13 Aug 1999 17:21:21 -0600
Message-Id: <[e-mail]>
X-Mailer: Novell GroupWise 5.5.2
Date: Fri, 13 Aug 1999 17:17:43 -0600
From: "Bob Jueneman" <[e-mail]>
To: <[e-mail]>
Cc: <[e-mail]>, <[e-mail]>
Subject: Re: Non-Repudiation
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 mail.proper.com id QAA01814

>>> Stephen Kent <[e-mail]> 08/13/99 04:32PM >>>
[snip]
>Most of "we" are not trying to do what you suggest.  We are defining a bit
>and explaining what we mean when the bit is turn on or off.  Others will
>decide, over time, how that fits into any specific legal context.  We have
>an obligation to make good technical decisions regarding the syntax and
>processing for our protocols, and I believe that we are doing just that.

The issue is not the syntax, but the semantics, and semantics necessarily
involve more than just "good technical decisions".  Such decisions have
to fit into a broader context of how the specifications and products 
embodying them are to be used.

[snip]

>Deliberation on a topic is valuable up to a point.  I think we passed that
>point on this topic a while ago.

Pardon me, Steve, but the fact that this issue has droned on for a number
of years without any satisfactory resolution is an obvious indication that 
there is a lack of consensus on this.  

On the contrary, there seems to be a fair amount of consensus that the
current definition and explanation of "what we mean when the bit is 
turned on or off"  is NOT adequate, and NOT a good technical decision,
and various people are trying to decide how to fix it.

Bob



Received: from prv-mail20.provo.novell.com (prv-mail20.provo.novell.com [137.65.82.195]) by mail.proper.com (8.9.3/8.9.3) with SMTP id QAA01541 for <[e-mail]>; Fri, 13 Aug 1999 16:02:06 -0700 (PDT)
Received: from INET-PRV-Message_Server by prv-mail20.provo.novell.com with Novell_GroupWise; Fri, 13 Aug 1999 17:02:17 -0600
Message-Id: <[e-mail]>
X-Mailer: Novell GroupWise 5.5.2
Date: Fri, 13 Aug 1999 17:00:45 -0600
From: "Bob Jueneman" <[e-mail]>
To: <[e-mail]>
Cc: <[e-mail]>, <[e-mail]>
Subject: Re: Non-Repudiation
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 mail.proper.com id QAA01542

Ed,

I doubt it, too.  I just didn't beat up on Dale, the author of that paragraph, too much.

As to whether this is true of PKIX, PKIX is a specification of a protocol, not of
an application, and so you are right.

However, I tend to disagree with your characterization of all of this as a CA issue,
for other than perhaps counter-signing or witnessing the subscriber's desire to 
enable a particular key/certificate for a higher level of presumptive validity, 
I don't think the CA plays a role at all with respect to nonrepudiation.  And 
in particular, although this is just my personal opinion, I don't think that the CPS
is going to be particularly relevant in this area, since contracts are not transitive.

Even if the subscriber agrees to a contract with the CA, and even if the RP also 
contracts with the CA, that does not mean that can rely on the CAs contract with 
the subscriber. At best, the RP can hope that the CA will take on some liability
for the subscriber's actions, but fat chance.  (Insurance, however, is a different 
issue.)

I'm not sure what your returning underwear has to do with nonrepudiation, but
I have said repeatedly that "technical nonrepudiation" is NOT required in order for
a signature to be legally binding.  It may, however, make it easier to prove,
it may help to decide who has the burden of proof, and it may also shed a significant 
amount of light on whether the RP's reliance on a signature could be considered 
commercially reasonable, which has a very great deal to do with who should 
bear the risk of loss.

The question of whether or not an application actually enforces some user action,
e.g., asking a due-caution, ceremonial intent question prior to using a NR certificate
and/or setting a bit appropriately in CMS is not something that "PKIX tribunal" should 
decide, obviously.  It can be decided very quickly by expert witness testimony.

If users request such functionality, the vendors (at least this vendor) would be happy to 
oblige them, and we wouldn't dare NOT enforce such  criteria for fear of the lawsuits 
that might follow, not withstanding shrink wrapped contracts.

I'll grant that this issue (application behavior) is somewhat outside of the scope of this
WG, but we don't hesitate to say what "PKIX-compliant" products must do in other areas, 
such as the enforcement of the Critical bit, or various constraints.

I'm not trying to eliminate the concept of nonrepudiation, I'm merely trying to clarify
what it means.  And obviously, I'm not trying to make it mandatory somehow --
if someone doesn't want to use it, don't turn it on.  And if a relying party wants to be 
more consumer friendly by not requiring the amount of detail you would find in a 
mortgage contract in order to buy underwear over the Internet, then that's fine 
with me.

Just don't eliminate the ability to sell goods of vastly higher value by eliminating or failing to 
clarify an important concept.

Bob

>>> Ed Gerck <[e-mail]> 08/13/99 03:48PM >>>


Bob Jueneman wrote:

> I believe card vendor initial requirements were defined and driven by the new German Digital
> Signature laws.  Perhaps their concept of requiring the user to enter this signing key PIN (or
> perform some other concious action) for each and every digital signature, which appears to be
> motivated by a very similar set of issues, may be useful to this discussion as well.

Bob:

Sorry to harp on your text again in less than a day (since I do agree with some
of the things you put forth in this discussion), but I doubt it. A smart-card is
physically made by a company that uses a series of physical and logical
tamperproof techniques in order to precisely control *usage* of the smart-card
-- for example, by enforcing the need to enter a PIN every time before
authentication, by internally fusing a relay that makes the card dead if more
than 10 successive attempts are made with a wrong PIN, by limiting the number of
authentications possible with the card, etc.  Further, a smart-card needs to be
physically handled by a user -- you can't just pipe commands into it.

None of this is true for PKIX. So, the analogy is not illuminating and requiring
the user to do anything in PKIX is an empty promise.  All the CA can do is take
good care of what the CA signs, not what the subscriber signs.   The only place
where user actions, rights, duties, powers and liabilities can be handled is in the
CPS but the CPS is outside the scope of this WG -- in fact, outside the scope
of PKIX.

Further, contrary to a smart-card, the objects in PKIX are exchanged exclusively
among applications (not between an application and a user) -- so, how can one
even consider "user intent" or "requiring users" if:  (i) the user is not necessarily
engaged, (ii) there is no way to know if the user is engaged.

I also find that one should seriously consider the large value of repudiable
transactions in commerce, which are nonetheless legally binding.  The myth
that a contract must be non-repudiable in order to be "useful", "strong",
"valuable"  or "legally binding" is simply wrong.  Just walk into a store,
buy a product and return it back within 30 days -- "no questions asked".
AFAIK, this procedure seems to fail only for the sales of underwear -- but,
then, only if the package is open and the buying act was physically done at
the store.

So, if commerce thrives and actually favors wide reaching return policies
(i.e., favors not harassing the consumer with a non-repudiation bit of prose),
why should this WG favor the opposite and introduce PKIX as a tribunal
over its users, with language such as (2459):

 " ...to provide a non-repudiation service which protects against the signing
  entity falsely denying some action"

I think it is time to stop beating around the bush and calling examples that do
not fit at all in the case at hand or speak in lawyerly terms, and just make the
changes needed to make precise the semantics of the nonRepudiation bit.  This
responsibility falls IMO on the spec authors, but I believe this list has provided
ample examples and counterexamples.

Thus, where IMO the present PKIX spec fails is that by saying too much
the baby is going with the baby water. The NR text in 2549 (which I
quoted before) should be simply deleted IMO, as a first correcting action.

Cheers,

Ed Gerck



Received: from po1.bbn.com (PO1.BBN.COM [192.1.50.38]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id PAA01202 for <[e-mail]>; Fri, 13 Aug 1999 15:33:44 -0700 (PDT)
Received: from [128.89.0.110] (COSMEC.BBN.COM [128.89.0.110]) by po1.bbn.com (8.9.1/8.9.1) with ESMTP id SAA10606; Fri, 13 Aug 1999 18:34:17 -0400 (EDT)
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
X-Sender: [e-mail]
Message-Id: <v04020a13b3da4a3d754d@[128.89.0.110]>
In-Reply-To: <[e-mail]>
Date: Fri, 13 Aug 1999 18:32:02 -0400
To: "Bob Jueneman" <[e-mail]>
From: Stephen Kent <[e-mail]>
Subject: Re: Non-Repudiation
Cc: <[e-mail]>, <[e-mail]>

Bob,

>The reason why I have been so interested in the legal issues of PKI is
>that the
>four companies I have worked for in the 15 or so years I've been
>involved in
>this space have all had a reasonable expectation that eventually a
>product
>(or service) would emerge from this that they could make some money
>on.
>If we were only interested in protecting casual e-mail, certainly PGP
>would
>have been a lot easier to develop and use.  But for business uses,
>it is simply not possible to ignore the potential legal issues, and I
>have
>been working to try to draw the technologists and the legal community
>toward a common understanding of these issues.

There are many examples of PKI use where the thorny legal issues you cite
do NOT arise, as I have noted in the past.  For example, using certs for
authentication for SSL and IPsec, in lieu of using passwords, SecurID cards
etc.  So, irrespective of the casual e-mail example, we have lots of
situations that are of value to businesses but which do not involve NR and
do not require "help" from attorneys.

>>This is an IETF (technica)l WG, not the ABA Technical Committee on
>Digital
>Signatures. The technical definition of NR that we use comes from ISO
>7498-2.
>
>Definitions are of course neither right nor wrong in and of themselves,
>
>since they are definitions.
>
>Instead, they are either helpful, because they are consistent with the
>
>general  and accepted usage of a particular term, or they are not
>helpful.
>Just because one person or group puts together a set of definitions,
>that
>does not automatically ensure that they will be particularly helpful,
>or
>well accepted. (The oxymoronic X.521 "useful attributes" with their
>specificity of syntax and paucity of semantics, would be a good case
>in point.)
>
>The technical definition of NR in ISO 7498-2 may or may not have been
>helpful in the context of an X.400 message delivery service, but the
>lack of
>consensus or even understanding of that definition, as has been
>repeatedly demonstrated in this WG for at least the last half-dozen
>years, is
>convincing evidence that the definition is distinctly NOT helpful,
>useful, or
>in agreement with the common usage, and it therefore deserves to be
>deprecated, and either fixed or ignored, regardless of the position
>taken by
>ISO or one of the cochairs. (That does NOT mean, however, that
>the bit itself should be removed from the spec, or necessarily even
>renamed.
>We just need to clarify the semantics.)

Given the broad base of WG members, including new members, I do not
evaluate the utility of a definition by whether it is well understood by
everyone who happens to contribute to discussions.  In a less contentious
example, we have had numerous examples of confusion in the IPsec WG over
completely factual issues, due to less than careful reading of specs, etc.
So, I don't agree with your criteria for deciding whether the NR definition
I cited is appropriate or not.

>Attorneys, especially attorneys who are relatively new to the field of
>PKI and
>therefore haven't absorbed all of the technical jargon, would tell you
>that in
>the law, there is no such thing as nonrepudiation. A given statement
>can be
>repudiated for any of a whole host of reasons, ranging from denial of
>the facts of
>the case, to duress or compulsion, to lack of knowing intent, to legal
>or
>mental incapacity or lack of agency * the infamous "infants, idiots,
>and married
>women" clause.

Yes, and if this were the ABA committee, I'm sure that would be a
beneficial debate.  But this is NOT that committee.

>On the other hand, as Tony Bartoletti pointed out, neither the presence
>nor
>the absence of the NR bit is necessarily definitive as to whether a
>court of law
>determines that you signed (or didn't sign) something.
>
>There are so many different digital signature laws and regulations in
>various
>jurisdictions, and no case law as yet, that it is very difficult to say
>anything
>with absolute certainty, but it is pretty clear that even if your
>certificate
>was expired or even explicitly revoked at the time a document was
>signed,
>that does NOT automatically mean that a given digital signature was
>invalid, if a preponderance of the evidence to the contrary can be
>presented.

Yes, so?

>Strange as it may seem, a digital signature may be valid, and the
>contract binding,
>even though it can be absolutely established that the subscriber was
>not and
>could not possibly be the person who caused the digital signature to be
>associated
>with a document. In that case, it is quite possible that the forger of
>a digital
>signature (perhaps someone who stole someone else's private key) ends
>up being
>contractually bound by the terms of the contract he signed, even though
>
>he used a key and certificate issued to another person. Caveat hacker!
>
>Obviously, however, it is more difficult to convince a jury that the
>subscriber
>did in fact sign a document if the certificate had been revoked. And
>even
>more importantly, it is much more difficult for the relying party to
>prove
>that his reliance on such a digital signature was "commercially
>reasonable,"
>and that he should not bear the loss in that case.
>
>In this regard I agree with Peter, when he said "An electronic
>signature
>created using a digital signature security procedure satisfies writing
>and
>signature requirements, with or without non-repudiation properties,
>whether
>it is created by, or on behalf of, a user." That is generally true with
>respect to
>the statute of frauds requirements that contracts be in writing.  But
>this may
>not go as far as a higher level of presumptive validity that may attach
>to a
>"secure electronic signature", AKA "digital signature" (to refer to the
>Illinois act)
>
>There are two fundamental issues in contract law -- who has the burden
>of proof,
>and who bears the risk of loss.  These two issues are NOT automatically
>linked --
>it is perfectly possible that the subscriber (the putative signer) has
>the burden of
>(dis)proof, yet the relying party bears the risk of loss.  In fact,
>that is precisely
>the case under the rebuttable presumption, burden-shifting statutes
>such as the
>Utah, Washington, etc. acts pertaining to the voluntary use of a
>certificate issued by
>a Licensed CA.
>
>So all that even the best PKI can do is to provide the technical basis
>for such a
>rebuttable presumption, and to make it substantially easier to prove
>one thing, and
>substantially more difficult to disprove it. But God-like infallibility
>isn't going to happen,
>and fortunately isn't required..

Yes, so?

>This WG cannot DEFINE what the legal consequences of some
>"nonrepudiation"
>bit is or should be.  That is completely beyond our power (and
>expertise), and
>can only be done by contract, or by statutes such as the Uniform
>Electronic
>Transactions Act being considered by the state commissioners
>responsible
>for drafting the Uniform Commercial Code in the U.S.

Most of "we" are not trying to do what you suggest.  We are defining a bit
and explaining what we mean when the bit is turn on or off.  Others will
decide, over time, how that fits into any specific legal context.  We have
an obligation to make good technical decisions regarding the syntax and
processing for our protocols, and I believe that we are doing just that.

>However, this WG can and does have enormous influence in this area,
>because in
>the absence of either an explicit contract or a statutory requirement
>or permission,
>the common trade practices within an industry, e.g. as may be
>established by
>technical standards; or by the course of trade between two parties, are
>typically
>given great weight by the court in determining whether a given mark or
>
>signature should be considered legally binding.  Chinese chops may be
>binding in
>San Francisco's Chinatown, but not in the New York diamond district,
>where a
>handshake is traditionally considered binding.  In addition, as
>lawmakers rush
>to pass feel-good legislation in favor of electronic commerce,
>motherhood,
>and apple pie, their staffs tend to point to the quote the technical
>definitions
>(whether they understand either the law or the technology).  So it is
>very important
>that we be as deliberative as possible in this issue.

Deliberation on a topic is valuable up to a point.  I think we passed that
point on this topic a while ago.

>The real problem in all of this is that PKIX is quite CA-centric, and
>fixated on
>the issue of certificates and protocols, with the tendency to believe
>that if we can
>just solve those problems, everything else is trivial. The other parts
>of the
>problem (unfortunately) tend to lie outside of our charter, yet
>nonetheless
>the other groups listen.

I'd rather not devote much time on the list to speculating on those out of
scope topics, providing less than expert fodder for those other discussions.

<snip>

Steve


Received: from tomcat.sac.verio.net ([e-mail] [209.162.64.15]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id OAA00673 for <[e-mail]>; Fri, 13 Aug 1999 14:48:07 -0700 (PDT)
Received: from nma.com (pm03-29.sac.verio.net [209.162.64.95]) by tomcat.sac.verio.net (8.9.1a/8.9.1) with ESMTP id OAA01196; Fri, 13 Aug 1999 14:48:32 -0700 (PDT)
Message-ID: <[e-mail]>
Date: Fri, 13 Aug 1999 14:48:30 -0700
From: Ed Gerck <[e-mail]>
X-Mailer: Mozilla 4.51 [en]C-CCK-MCD {Sony}  (Win98; I)
X-Accept-Language: en
MIME-Version: 1.0
To: Bob Jueneman <[e-mail]>
CC: [e-mail], [e-mail]
Subject: Re: Non-Repudiation
References: <[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Bob Jueneman wrote:

> I believe card vendor initial requirements were defined and driven by the new German Digital
> Signature laws.  Perhaps their concept of requiring the user to enter this signing key PIN (or
> perform some other concious action) for each and every digital signature, which appears to be
> motivated by a very similar set of issues, may be useful to this discussion as well.

Bob:

Sorry to harp on your text again in less than a day (since I do agree with some
of the things you put forth in this discussion), but I doubt it. A smart-card is
physically made by a company that uses a series of physical and logical
tamperproof techniques in order to precisely control *usage* of the smart-card
-- for example, by enforcing the need to enter a PIN every time before
authentication, by internally fusing a relay that makes the card dead if more
than 10 successive attempts are made with a wrong PIN, by limiting the number of
authentications possible with the card, etc.  Further, a smart-card needs to be
physically handled by a user -- you can't just pipe commands into it.

None of this is true for PKIX. So, the analogy is not illuminating and requiring
the user to do anything in PKIX is an empty promise.  All the CA can do is take
good care of what the CA signs, not what the subscriber signs.   The only place
where user actions, rights, duties, powers and liabilities can be handled is in the
CPS but the CPS is outside the scope of this WG -- in fact, outside the scope
of PKIX.

Further, contrary to a smart-card, the objects in PKIX are exchanged exclusively
among applications (not between an application and a user) -- so, how can one
even consider "user intent" or "requiring users" if:  (i) the user is not necessarily
engaged, (ii) there is no way to know if the user is engaged.

I also find that one should seriously consider the large value of repudiable
transactions in commerce, which are nonetheless legally binding.  The myth
that a contract must be non-repudiable in order to be "useful", "strong",
"valuable"  or "legally binding" is simply wrong.  Just walk into a store,
buy a product and return it back within 30 days -- "no questions asked".
AFAIK, this procedure seems to fail only for the sales of underwear -- but,
then, only if the package is open and the buying act was physically done at
the store.

So, if commerce thrives and actually favors wide reaching return policies
(i.e., favors not harassing the consumer with a non-repudiation bit of prose),
why should this WG favor the opposite and introduce PKIX as a tribunal
over its users, with language such as (2459):

 " ...to provide a non-repudiation service which protects against the signing
  entity falsely denying some action"

I think it is time to stop beating around the bush and calling examples that do
not fit at all in the case at hand or speak in lawyerly terms, and just make the
changes needed to make precise the semantics of the nonRepudiation bit.  This
responsibility falls IMO on the spec authors, but I believe this list has provided
ample examples and counterexamples.

Thus, where IMO the present PKIX spec fails is that by saying too much
the baby is going with the baby water. The NR text in 2549 (which I
quoted before) should be simply deleted IMO, as a first correcting action.

Cheers,

Ed Gerck



Received: from mail.spyrus.com (mail.spyrus.com [207.212.34.20]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id OAA00295 for <[e-mail]>; Fri, 13 Aug 1999 14:09:05 -0700 (PDT)
Received: from rhousley_laptop.spyrus.com ([209.172.119.101]) by mail.spyrus.com (8.9.3/8.9.3) with ESMTP id OAA06484; Fri, 13 Aug 1999 14:04:07 -0700 (PDT)
Message-Id: <[e-mail]>
X-Sender: [e-mail] (Unverified)
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58 
Date: Fri, 13 Aug 1999 13:58:15 -0400
To: Robert Moskowitz <[e-mail]>
From: Russ Housley <[e-mail]>
Subject: Re: 2459 question
Cc: [e-mail]
In-Reply-To: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed

Bob:

Within the key usage extension, both keyCertSign and crlSign should be 
TRUE. (unless separate private keys are used for signing these two objects).

The setting of the nonrepudiation bit is a rat hole, as you can see on 
other threads on ietf-pkix.  It does not impact cert path validation, so I 
would like to avoid that rat hole....

Russ

At 11:32 AM 8/13/99 -0400, Robert Moskowitz wrote:
>At 08:53 AM 8/13/1999 -0400, Russ Housley wrote:
> >You have the correct idea.  But, can't we keep it simple?  A
> >CA  certificate has a subject that can issue other
> >certificates.  Obviously, the CA  certificate must contain a digital
> >signature public key (not a key management public key).
>
>This makes sense, then raises another question.
>
>Is KeyUsage Non-Repudiation bit set, since it is signing tbsCertificate?
>(along with cRLsign bit).
>
> >At 02:22 PM 8/12/99 -0400, Robert Moskowitz wrote:
> >>At 01:12 PM 8/12/1999 -0400, Russ Housley wrote:
> >> >
> >> >If the certificate belongs to an entity that will issue certificate to
> >> >other entities, then the identified extensions should be included.
> >>
> >>ERGO  'CA Certificates' Includes:
> >>
> >>Root Certs (self-signed and hierarchically signed)
> >>Signing Certs (though not all signing certs, a VA can have a signing cert)
> >>Cross Certs
> >>
>
>Robert Moskowitz
>ICSA
>Security Interest EMail: [e-mail]



Received: from crack.x509.com (crack.x509.com [199.175.150.1]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id MAA29385 for <[e-mail]>; Fri, 13 Aug 1999 12:40:31 -0700 (PDT)
Received: from xcert.com (saxifrage.x509.com [199.175.148.75]) by crack.x509.com (8.9.3/XCERT) with ESMTP id MAA21697 for <[e-mail]>; Fri, 13 Aug 1999 12:40:46 -0700 (PDT)
Sender: [e-mail]
Message-ID: <[e-mail]>
Date: Fri, 13 Aug 1999 12:43:16 -0700
From: Marc Branchaud <[e-mail]>
Organization: Xcert International Inc.
X-Mailer: Mozilla 4.61 [en] (X11; U; Linux 2.2.10 i686)
X-Accept-Language: en, fr
MIME-Version: 1.0
To: [e-mail]
Subject: Re: Cross-certificate path processing
References: <[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Bob,

I agree with your analysis, though I think the confusion you saw in my
message is due more to its vagueness than my misreading of the
situation.

I feel we're all sortof reading from the same page here, so I don't want
to extend this any further.  Just to clarify my previous message,
though, I was thinking of a more general hierarchy, in which each CA
certifies its parent as well as its children.  In that case, 1 may very
well not be in a trust domain defined by A (in building the chain, 1 can
go from B to C instead of to A).

I admit that I was really unclear about this in my message.

The desirability and practicality of such an arrangement is pretty
debatable though.  Is such a general hierarchy truly a hierarchy
anyway?  How many certificates can dance on the head of a pin?

		Marc

+------------------------------------------------------------------------+
 Marc Branchaud                                  \/
 Chief PKI Architect                             /\CERT INTERNATIONAL
INC.
 [e-mail]        PKI References page:             
www.xcert.com
 604-640-6227          www.xcert.com/~marcnarc/PKI/
+------------------------------------------------------------------------+
  PGP key fingerprint:  60 11 4B 9D 4E E5 2F 47  BD C5 C2 BF 26 DF 5A E1


Bob Jueneman wrote:
> 
> Marc,
> 
> I think you have confused locality of trust with the path construction.
> 
> True, I may trust CA C, in your example, more than the more remote CAs,
> but B signed C's certificate, not the other way around.  So C can't impose
> constraints on B, B has to impose them on C.
> 
> In the paradigm I have described several times, user 1 is operating in
> a domain of trust established by A, and A gets to specify whatever constraints
> it wishes to.
> 
> Likewise B can specify constraints on E, and E on F, and F on 2.
> 
> The path processing has to be bottom up, in order to establish what
> CAs are involved, and then top down to establish the constraints.
> 
> So bottom up, the relying party (1) looks at 2's certificate and asks if
> he recognizes that key.  If not, he proceeds up the chain.
> 
> When he comes to E's public key and he asks if he has seen it
> before, the answer is Ah ha!  I have seen it, because I processed
> the cross-certificate. So now the RP completely abandons the
> D hierarchy as being of no consequence, and tracks back to A.
> 
> Then in order to properly validate the various extensions, he starts at A
> and works his way back down the chain.
> 
> This is particularly important, because there may in effect be multiple
> "A's", with different policies that apply to different kinds of transactions,
> in other words a choice of Platinum, Gold, and Silver certificate.
> 
> If A-Platinum is selected, then assuming B and C conform, E and F will be
> tested to make sure that they conform to the A-Platinum requirements.
> 
> What constraints might have been imposed by D don't matter to the
> relying party, who doesn't necessarily trust D in any case.
> 
> However, observe that this makes it almost impossible for D to enforce
> a negative policy that would restrict usage of lower level certificates.
> 
> A unidirectional cross-certificate can be issued that includes the public
> key of some intermediate CA, without that CA necessarily even being
> aware of that fact, and without that CA's concurrence. Of course
> D would deny any liability in that case, but it can't prevent the
> certificate chain from being used.
> 
> Bob
> 
> >>> Marc Branchaud <[e-mail]> 08/13/99 12:18PM >>>
> Robert Moskowitz wrote:
> >
> > OK.  The path construction starts with the EE's trusted cert, typically a
> > root cert.  But any other CA in the path root cert is not needed if the
> > linkcage is cross-cert.
> >
> 
> I think I was slightly confusing the CA at the top of a hierarchy with
> the root ca that is the trust source in a path (using the definitions
> from the Roadmap now).
> 
> I still feel the need to niggle with your statement, though.  Consider
> this:
> 
>    A    D
>    |    |
>    B----E
>    |    |
>    C    F
>    |    |
>    1    2
> 
> where A-F are CAs and 1 & 2 are users.  A is at the top of the A-B-C
> hierarchy and D is at the top of the D-E-F hierarchy.  Also, B and E
> have cross-certified.
> 
> The path that 1 uses to verify a cert for 2 is sourced either at A or
> C.  That is, 1 either implictly trusts A or C.  If 1 trusts C, then I
> agree with your statement that other CAs in the path to A (say, if there
> were CAs between B and A) would not be considered in the path that is
> validated.  That path would be C-B-E-F-2.
> 
> But if A is the trusted CA (as is common is hierarchical PKIs), then the
> path that is validated is A-B-E-F-2, and so extensions in A's cert (and
> any certs between A and B) are included in the validation.
> 
>                 Marc
>


Received: from prv-mail20.provo.novell.com (prv-mail20.provo.novell.com [137.65.82.195]) by mail.proper.com (8.9.3/8.9.3) with SMTP id MAA29029 for <[e-mail]>; Fri, 13 Aug 1999 12:06:21 -0700 (PDT)
Received: from INET-PRV-Message_Server by prv-mail20.provo.novell.com with Novell_GroupWise; Fri, 13 Aug 1999 13:06:30 -0600
Message-Id: <[e-mail]>
X-Mailer: Novell GroupWise 5.5.2
Date: Fri, 13 Aug 1999 13:06:20 -0600
From: "Bob Jueneman" <[e-mail]>
To: <[e-mail]>, <[e-mail]>
Subject: Cross-certificate path processing
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 mail.proper.com id MAA29030

Marc,

I think you have confused locality of trust with the path construction.

True, I may trust CA C, in your example, more than the more remote CAs,
but B signed C's certificate, not the other way around.  So C can't impose
constraints on B, B has to impose them on C.

In the paradigm I have described several times, user 1 is operating in 
a domain of trust established by A, and A gets to specify whatever constraints
it wishes to.  

Likewise B can specify constraints on E, and E on F, and F on 2.

The path processing has to be bottom up, in order to establish what 
CAs are involved, and then top down to establish the constraints.

So bottom up, the relying party (1) looks at 2's certificate and asks if
he recognizes that key.  If not, he proceeds up the chain.

When he comes to E's public key and he asks if he has seen it 
before, the answer is Ah ha!  I have seen it, because I processed 
the cross-certificate. So now the RP completely abandons the
D hierarchy as being of no consequence, and tracks back to A.

Then in order to properly validate the various extensions, he starts at A
and works his way back down the chain.

This is particularly important, because there may in effect be multiple
"A's", with different policies that apply to different kinds of transactions,
in other words a choice of Platinum, Gold, and Silver certificate.

If A-Platinum is selected, then assuming B and C conform, E and F will be
tested to make sure that they conform to the A-Platinum requirements.

What constraints might have been imposed by D don't matter to the
relying party, who doesn't necessarily trust D in any case.

However, observe that this makes it almost impossible for D to enforce 
a negative policy that would restrict usage of lower level certificates.

A unidirectional cross-certificate can be issued that includes the public
key of some intermediate CA, without that CA necessarily even being
aware of that fact, and without that CA's concurrence. Of course
D would deny any liability in that case, but it can't prevent the
certificate chain from being used.

Bob


>>> Marc Branchaud <[e-mail]> 08/13/99 12:18PM >>>
Robert Moskowitz wrote:
> 
> OK.  The path construction starts with the EE's trusted cert, typically a
> root cert.  But any other CA in the path root cert is not needed if the
> linkcage is cross-cert.
> 

I think I was slightly confusing the CA at the top of a hierarchy with
the root ca that is the trust source in a path (using the definitions
from the Roadmap now).

I still feel the need to niggle with your statement, though.  Consider
this:

   A    D
   |    |
   B----E
   |    |
   C    F
   |    |
   1    2

where A-F are CAs and 1 & 2 are users.  A is at the top of the A-B-C
hierarchy and D is at the top of the D-E-F hierarchy.  Also, B and E
have cross-certified.

The path that 1 uses to verify a cert for 2 is sourced either at A or
C.  That is, 1 either implictly trusts A or C.  If 1 trusts C, then I
agree with your statement that other CAs in the path to A (say, if there
were CAs between B and A) would not be considered in the path that is
validated.  That path would be C-B-E-F-2.

But if A is the trusted CA (as is common is hierarchical PKIs), then the
path that is validated is A-B-E-F-2, and so extensions in A's cert (and
any certs between A and B) are included in the validation.

		Marc

+------------------------------------------------------------------------+
 Marc Branchaud                                  \/
 Chief PKI Architect                             /\CERT INTERNATIONAL
INC.
 [e-mail]        PKI References page:             
www.xcert.com 
 604-640-6227          www.xcert.com/~marcnarc/PKI/ 
+------------------------------------------------------------------------+
  PGP key fingerprint:  60 11 4B 9D 4E E5 2F 47  BD C5 C2 BF 26 DF 5A E1



Received: from prv-mail20.provo.novell.com (prv-mail20.provo.novell.com [137.65.82.195]) by mail.proper.com (8.9.3/8.9.3) with SMTP id LAA28696 for <[e-mail]>; Fri, 13 Aug 1999 11:44:43 -0700 (PDT)
Received: from INET-PRV-Message_Server by prv-mail20.provo.novell.com with Novell_GroupWise; Fri, 13 Aug 1999 12:44:52 -0600
Message-Id: <[e-mail]>
X-Mailer: Novell GroupWise 5.5.2
Date: Fri, 13 Aug 1999 12:42:17 -0600
From: "Bob Jueneman" <[e-mail]>
To: <[e-mail]>
Subject: Application processing of NR indictators
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 mail.proper.com id LAA28698

Larry Leyton referred to some discussion of what an application should do 
when it encountered a NR certificate.  However, as I recall that discussion
took place on the cert-talk list, so it might be worth summarising
here.

Since I responded to Hans Neilson on the same subject, I hope he won't mind my
posting his observation and my response to the list:

>>> Hans Nilsson <[e-mail]> 08/13/99 02:27AM >>>
Bob,

A short response to your long posting:

In the EESSI project we discussed, and Denis Pinkas convinced us, that "type
of commitment" indicated by the signature is something that should be
encoded into the "electronic signature token", i.e. in the CMS (or whatever
encoding that is used) structure of the signed message, together with a
reference to a Signing Policy. Today, I may use my NR key to sign an
electronic contract, tomorrow I may use it to send you something "FYI",
without feeling bound to it.

Hans

Hans,

Thanks for your note. I agree with you, but only partially.

I agree that some "type of commitment" indication is needed in CMS.
I think that X9 was going down the same path with some kind of a "purpose"
indicator, but I'm not sure that ever went anywhere.

The concern I have about using only one indicator is that it isn't as fail 
safe as my friends in the legal community seem to feel is required.
At least, when I have proposed using a single indicator, that didn't seem
to satisfy them that sufficient consumer protection had been provided.

>From my perspective, certificates are cheap (and if they aren't, once the
basic due diligence has been done, you ought to find another CA).  I therefore
don't see any particular need to use the same certificate for both casual, FYI
correspondence as for a contract, and in fact think that would be quite
undesirable.

If I can show that I invariably use one NR certificate (corresponding to my 
fancy fountain pen) for contracts, and consistently use another, lighter-weight
DS only certificate (my "Bic" ball-point pen) for casual purposes, including 
authenticated FYI correspondence, then I believe that is a lot safer.

So I might use a software-based encryption private key, encrypted in my not
terribly secure password, for my casual messages, and then pull out my 
"Danger! Danger!" red-flag, binding legal commitment smart card for the 
serious stuff.

In other words, the NR bit in the certificate should be required to ENABLE the 
NR bit in the message. If the two don't match, the signature might very well still 
be binding, but it would presumably be harder to prove intent, and from 
the standpoint of protecting the user against misattribution, that is exactly what I
want to ensure.

The two bits might serve some other purposes as well.  The NR bit in the 
certificate could be used as a signal to the relying party software that the certificate 
chain should be appropriately timestamped and archived along with the CRL or 
OCSP response, for example.

And turning on the NR bit in the CMS header would require invoking a more 
ceremonial, "Are you really, really sure that you want to be legally bound by this?" 
type of message within the application.

Although traditionally the IETF doesn't get into the API business, much less the 
look and feel of an application, this particular issue is so important for business 
uses of PKI that I don't think we have a choice.  Describing what we want to 
have happen in the semantics of these bits is the only way we can achieve the 
desired result.

BTW, allow me to once again express my considerable scepticism regarding the 
efficacy of Signing Policies, policy OIDs, and policy constraints in general.  I don't 
believe they are workable, except perhaps in a small, closed community.

To date, I haven't seen any application software implement any of these constraints, 
and with the expected proliferation of CA policies, I can't imagine how a vendor
could possibly keep up with all of the different flavors that might be defined.

The CA may be able to define some of these policies in their contract, although 
in the case of "click-wrapped" subscriber agreements I have considerable doubts 
as to whether such an agreement is enforceable even against the subscriber, much 
less the relying party.

But I really, really doubt that the CAs are going to be able to convince the various 
vendors that they should code their application packages in such a was as to 
enforce a particular policy.  To put it more personally, as the security architect 
responsible for defining the technical requirements for Novell software in this area, 
I certainly haven't been convinced that there is a sufficient business case to 
justify doing this, even if I could decide what should be done.

That's why I think we need a standard, instead of relying on CA's CSPs in 
this area.  Otherwise, it won't go anywhere.

Bob




Received: from crack.x509.com (crack.x509.com [199.175.150.1]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id LAA28455 for <[e-mail]>; Fri, 13 Aug 1999 11:34:43 -0700 (PDT)
Received: from xcert.com (saxifrage.x509.com [199.175.148.75]) by crack.x509.com (8.9.3/XCERT) with ESMTP id LAA16489 for <[e-mail]>; Fri, 13 Aug 1999 11:34:58 -0700 (PDT)
Sender: [e-mail]
Message-ID: <[e-mail]>
Date: Fri, 13 Aug 1999 11:37:28 -0700
From: Marc Branchaud <[e-mail]>
Organization: Xcert International Inc.
X-Mailer: Mozilla 4.61 [en] (X11; U; Linux 2.2.10 i686)
X-Accept-Language: en, fr
MIME-Version: 1.0
To: [e-mail]
Subject: Re: Non-Repudiation
References: <[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

WRT the issues that Bob raises below (the need for intent and such), I
have been inclined to consider current practices with "wet" signatures.

Wet signature mechanisms -- applying ink to paper and hand to pen --
have nothing to do with the intent of the signatory.  Instead, the
document being signed usually states that the intent of the signature
is.  There's usually a line somewhere like "I represent that the above
information is true." or "I hereby agree to the above conditions."

So I think that adding an extra bit here and there inside certificates
or CMS is completely inadequate.  To capture current practice it is
necessary to extend the way documents are signed.  Instead of adding a
bit to CMS, an authenticated attribute should be defined that is
basically a statement of intent for the signature.  Statements such as
"I am Party A as identified in this contract" or "I am witnessing the
following 3 signatures on this will." would go a long way towards
clarifying intent.

Bitwise NR is still important, if only to add a layer assurance that a
person will use the certified key pair for NR.  But bitwise NR can never
capture intent, so we shouldn't even try to make it do so.

IANAL, but I think that some technical & legal types could get together
to define a few intent-statement authenticated attributes along with the
cryptographic semantics that machines can enforce to make the intentions
sensible.  (For example, two parties signing a contract would probably
be implemented as parallel signatures, whereas a witness signature would
include existing signatures on the document).

		Marc

+------------------------------------------------------------------------+
 Marc Branchaud                                  \/
 Chief PKI Architect                             /\CERT INTERNATIONAL
INC.
 [e-mail]        PKI References page:             
www.xcert.com
 604-640-6227          www.xcert.com/~marcnarc/PKI/
+------------------------------------------------------------------------+
  PGP key fingerprint:  60 11 4B 9D 4E E5 2F 47  BD C5 C2 BF 26 DF 5A E1


Bob Jueneman wrote:
> 

[ snip ]

> 
> So Peter was correct when he went on to say "On the NR issue, nothing in
> the NR definition requires there to be evidence of user intent. USER INTENT
> IS REQUIRED IN THE UNDERLYING ELECTRONIC SIGNATURE
> AGREEMENT, however." (My emphasis.)
> 
> The question, then is whether it is legitimate to INFER user intent from a
> particular key usage type, and to what extent, if any, the subscriber can be
> bound to such a an alleged "death penalty" type of certificate on the basis
> of some shrink-wrapped or "click-wrapped" contract of adhesion, based on the
> user's cursory acceptance of a CA's CPS or subscriber agreement.
> 
> We could argue that the user should be so bound, and in fact I have so
> argued with some of my attorney friends. But invariably, I lost. Emotional
> consumer protection issues generally ended up triumphing over logic.
> 
> I am therefore inclined to take a more moderate position.  The NR bit
> in the certificate should be interpreted as ENABLING the use of digital
> signatures that are intended to be legally binding, but I now believe that it
> would be prudent to provide an additional indicator to serve as a more
> explicit indication that the user did in fact consciously intend to be
> legally bound by her signature.
> 
> The ideal place to provide this indication would be in the CMS used by S/MIME.
> However, although I am not as certain as I'd like to be, I don't believe that
> the existing "digital signature" signedData bit in CMS provides this
> indication.
> That bit, as I understand it, says what the purpose of the particular CMS
> wrapper is, i.e., encryption vs. signature, but that DOESN'T even address
> the issue of intent.  It might be, for example, that a message was
> digitally signed to prevent its undetected corruption in transit or storage,
> but that the intent of the message was approximately "look at what these
> idiots have done now."
>


Received: from crack.x509.com (crack.x509.com [199.175.150.1]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id LAA28133 for <[e-mail]>; Fri, 13 Aug 1999 11:15:30 -0700 (PDT)
Received: from xcert.com (saxifrage.x509.com [199.175.148.75]) by crack.x509.com (8.9.3/XCERT) with ESMTP id LAA15580 for <[e-mail]>; Fri, 13 Aug 1999 11:15:35 -0700 (PDT)
Sender: [e-mail]
Message-ID: <[e-mail]>
Date: Fri, 13 Aug 1999 11:18:05 -0700
From: Marc Branchaud <[e-mail]>
Organization: Xcert International Inc.
X-Mailer: Mozilla 4.61 [en] (X11; U; Linux 2.2.10 i686)
X-Accept-Language: en, fr
MIME-Version: 1.0
To: [e-mail]
Subject: Re: 2459 question
References: <[e-mail]> <[e-mail]> <[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Robert Moskowitz wrote:
> 
> OK.  The path construction starts with the EE's trusted cert, typically a
> root cert.  But any other CA in the path root cert is not needed if the
> linkcage is cross-cert.
> 

I think I was slightly confusing the CA at the top of a hierarchy with
the root ca that is the trust source in a path (using the definitions
from the Roadmap now).

I still feel the need to niggle with your statement, though.  Consider
this:

   A    D
   |    |
   B----E
   |    |
   C    F
   |    |
   1    2

where A-F are CAs and 1 & 2 are users.  A is at the top of the A-B-C
hierarchy and D is at the top of the D-E-F hierarchy.  Also, B and E
have cross-certified.

The path that 1 uses to verify a cert for 2 is sourced either at A or
C.  That is, 1 either implictly trusts A or C.  If 1 trusts C, then I
agree with your statement that other CAs in the path to A (say, if there
were CAs between B and A) would not be considered in the path that is
validated.  That path would be C-B-E-F-2.

But if A is the trusted CA (as is common is hierarchical PKIs), then the
path that is validated is A-B-E-F-2, and so extensions in A's cert (and
any certs between A and B) are included in the validation.

		Marc

+------------------------------------------------------------------------+
 Marc Branchaud                                  \/
 Chief PKI Architect                             /\CERT INTERNATIONAL
INC.
 [e-mail]        PKI References page:             
www.xcert.com
 604-640-6227          www.xcert.com/~marcnarc/PKI/
+------------------------------------------------------------------------+
  PGP key fingerprint:  60 11 4B 9D 4E E5 2F 47  BD C5 C2 BF 26 DF 5A E1


Received: from prv-mail20.provo.novell.com (prv-mail20.provo.novell.com [137.65.82.195]) by mail.proper.com (8.9.3/8.9.3) with SMTP id LAA27850 for <[e-mail]>; Fri, 13 Aug 1999 11:02:44 -0700 (PDT)
Received: from INET-PRV-Message_Server by prv-mail20.provo.novell.com with Novell_GroupWise; Fri, 13 Aug 1999 12:02:44 -0600
Message-Id: <[e-mail]>
X-Mailer: Novell GroupWise 5.5.2
Date: Fri, 13 Aug 1999 12:01:10 -0600
From: "Bob Jueneman" <[e-mail]>
To: <[e-mail]>
Cc: <[e-mail]>, <[e-mail]>
Subject: Re: Non-Repudiation
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 mail.proper.com id LAA27851

Dale,

I hope that the smart card manufacturers will in fact provide some kind of
additional protection for special purpose keys, in particular NR keys.
And since some people seem to equate a NR certificate to a "death
penalty" certificate (greatly exaggerated for effect), it might be appropriate
to paint those smart cards bright red as well.

My concern, however, is that even the German law is not adequately
distinguishing between a legitimate application of a digital signature for
authentication, either for SSL or for a casual, attribution-only, non-binding intent,
FYI type of message, vs. a contract that is intended to be legally binding.

Some of the more vocal detractors of PKI initiatives, notably Ben Wright of 
PenOp, have made a big deal about the ceremonial, due-caution issues 
that ought to be involved in a legally binding signature. Of course he is pushing 
PenOp's signature dynamics product, but what he says make some sense.

As another example of the differences that have to be made clear,
S/MIME version 3 supports the generation and transmission of 
a digitally signed message receipt, and s far as I know the intent is that 
this receipt be generated automatically.

This is an excellent example of a case where two certificates and 
two separate keys should really be provided, to differentiate between 
the case where something was generated automatically, although
on the user's behalf, vs. a willful, conscious intent type of signature.

Of course, as Ed and others have pointed out, both cases may have legal 
consequences, and may be binding in some circumstances and to some 
degree -- that's true even of an automatic, unsigned, "out of the office" reply.

Bob

>>> "Dale Gustafson" <[e-mail]> 08/13/99 10:57AM >>>
Hi Bob,

A comment or two, inline.

Best Regards,

Dale Gustafson
Datakey, Inc.
407 West Travelers Trail
Burnsville, MN 55337 USA
612.808.2360 voice
612.890.2726 fax


Bob Jueneman wrote:

> (Warning -- longer than even Ed Gerck's missives, but worth every megabyte.)
>
> Robert R. Jueneman
> Security Architect
> Network Security Development
> Novell, Inc.
> 122 East 1700 South
> Provo, UT 84606
> [e-mail] 
> 1-801-861-7387

[snip]

> The question, then is whether it is legitimate to INFER user intent from a particular
> key usage type, and to what extent, if any, the subscriber can be bound to such a
> an alleged "death penalty" type of certificate on the basis of some shrink-wrapped or
> "click-wrapped" contract of adhesion, based on the user's cursory acceptance of
> a CA's CPS or subscriber agreement.

[snip]

> But I disagree that CMS signedData provides nonrepudiation, except in the sense that
> Tony Bartoletti argued, i.e., authentication, UNLESS signedData REQUIRES AN
> EXPLICIT CONFIRMATION OF USER INTENT TO BE BOUND.  signedData therefore
> should NOT require a certificate with the NR bit set, since there are lots of times when
> it may be useful to provide authentication (integrity with origin) when there is absolutely
> no intent to be legally bound.  Instead, I would like to see an additional bit defined
> in CMS, perhaps called "bindingIntent."
>
> To be crystal clear, and to bring this diatribe to a close, I divide the end-user uses of
> public key cryptography into three relatively disjoint sets:
>
> 1.  Encryption.  Encryption (key agreement or key exchange, really) keys are generally
> subject to key recovery, either on behalf of the user, so he can recover stored
> encrypted data some number of years later, or on behalf of his organization, for
> reasons ranging from business continuity to investigating fraud.
>
> 2.  Authentication, using what is conventionally called a digital signature, and in
> particular using the DS key usage.  Since authentication is typically (but not always)
> used to access organizational resources and is not legally binding, authentication keys
> are typically not very sensitive to whether key recovery is permitted or not. But
> authentication may apply to a logon for a stream type of session, such as TLS, or it
> may apply to a signed message that is not intended to be legally binding. (The fact t
> hat it wasn't so intended doesn't necessarily mean that it couldn't be construed to be
> binding, however, just as an unsigned e-mail message might also be legally binding
> under the rather relaxed rules for what constitutes a signature.)
>
> 3.  Legally binding, "nonrepudiation" type of signatures reflecting the user's intent to be
> legally bound, whether or not someone (such as the RP) bothers to go to the trouble of
> actually collecting all of the timestamps, CRLs, etc., that might make proving the validity
> of the signature considerably easier.  Since in this case it is vitally important to both the
> user and the RP that only the bona fide subscriber be able to sign such a document, business
> key recovery (and/or centralized key generation) is absolutely unacceptable, and even the
> ability to do personal key recovery may be unwise, because of the presumably greater risk
> of compromise.
>
> The reason why a mixed or unspecified use of encryption plus digital signature (much less NR)
> is such a bad idea is due to the business key recovery requirements, and in addition to the (US)
> export laws that tend to constrain the key length for encryption, but do not constrain digital
> signature key lengths, for those system that enforce such distinctions.

Smart card vendors will provide software libraries and card operating systems that include support
for a "signing only" key pair.  The distinguishing characteristic of this special type of
public/private key pair is that access to the private key component is protected by a special
"Signing Key PIN" (distinct from the User PIN that controls general user access to the card).  The
Signing Key PIN must be entered each and every time that private key is used to create a digital
signature (preferably through a protected authentication path reader device -- the PIN characters go
directly from the keyboard or PINpad to the card and do not traverse the user's desktop or laptop
machine.)

I believe card vendor initial requirements were defined and driven by the new German Digital
Signature laws.  Perhaps their concept of requiring the user to enter this signing key PIN (or
perform some other concious action) for each and every digital signature, which appears to be
motivated by a very similar set of issues, may be useful to this discussion as well.


> Hope this helps to clarify some of these issues.
>
> Regards,
>
> Bob


Received: from ext-mail.valicert.com (ext-mail.valicert.com [63.65.221.10]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id KAA27548 for <[e-mail]>; Fri, 13 Aug 1999 10:44:29 -0700 (PDT)
Received: from int-mail.valicert.com (corporate-gw.valicert.com [63.65.221.2]) by ext-mail.valicert.com (8.9.3/8.9.3) with ESMTP id KAA02653; Fri, 13 Aug 1999 10:44:49 -0700 (PDT)
Received: from rsalaptop ([192.168.3.230]) by int-mail.valicert.com (8.9.3/8.9.3) with SMTP id KAA04601; Fri, 13 Aug 1999 10:44:25 -0700 (PDT)
From: "Peter Williams" <[e-mail]>
To: "Ed Gerck" <[e-mail]>
Cc: <[e-mail]>
Subject: RE: Non-Repudiation
Date: Fri, 13 Aug 1999 10:45:13 -0700
Message-ID: <001101bee5b3$9869f4a0$[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 8.5, Build 4.71.2173.0
Importance: Normal
In-Reply-To: <[e-mail]>
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.0810.800

The NR diatribe, and comments on diatribe, show
that PKIX-QC must first address these issues, before it
can proceed. It cannot proceed 
until, in its definitions and other implied
semantic assumptions, it clears up this NR 
issue set to the satisfaction of the consensus.
(The chairs may bully this process a little.)

So, in summary, for PKIX-QC to proceed,
it should surely define the IETF semantics of the NR
bit it mandates.  The authors should make
a best attempt to represent what the community
has stated the various technical issue set to 
be, here; and not merely quote some evidently 
quite useless, abstract ISO definition(s). Once 
the dust settles, the issues will be settled for 
the moment, and the first generation CEC qualified
certificate will at least have a firm, if
disputable, semantic basis.

To proceed as is will be like deploying the Maginot
Line on quicksand.


> -----Original Message-----
> From: Ed Gerck [mailto:[e-mail]]
> Sent: Thursday, August 12, 1999 6:58 PM
> To: Bob Jueneman
> Cc: [e-mail]; [e-mail]
> Subject: Re: Non-Repudiation
> 
> 
> 
> 
> Bob Jueneman wrote:
> 
> > [snip]
> > To be crystal clear, and to bring this diatribe to a close, I 
> divide the end-user uses of
> > public key cryptography into three relatively disjoint sets:
> >
> > 1.  Encryption.  Encryption (key agreement or key exchange, 
> really) keys are generally
> > ....
> >
> > 2.  Authentication, using what is conventionally called a 
> digital signature, and in
> > ....
> >
> > 3.  Legally binding, "nonrepudiation" type of signatures 
> reflecting the user's intent to be
> > legally bound, ....
> 
> Note that a digital signature can be legally binding even though 
> repudiable.  In other
> words, one must be carefull not to equate "legally binding" with 
> "nonrepudiation" --
> the difference is that rights equate to duties while power 
> equates to liability  So that
> absence of nonrepudiation liability does not mean absence of 
> contract duties -- for
> example, the duty to return the merchandise.
> 
> In fact, if the nonRepudiation bit would be fully erased from the 
> PKIX specs then
> there would IMO be no significant decrease in the value of the 
> specs in order to
> support legally binding contracts.  The value of keeping that 
> pesky bit IMO can
> thus only be justified if its meaning is clear -- it has no 
> meaning but that which
> is defined in a particular CPS.  Otherwise, it will muddy the 
> waters and backfire,
> since the UCC does make CAs liable for using incorrect methods.
> 
> Cheers,
> 
> Ed Gerck
> 


Received: from prv-mail20.provo.novell.com (prv-mail20.provo.novell.com [137.65.82.195]) by mail.proper.com (8.9.3/8.9.3) with SMTP id KAA27355 for <[e-mail]>; Fri, 13 Aug 1999 10:36:57 -0700 (PDT)
Received: from INET-PRV-Message_Server by prv-mail20.provo.novell.com with Novell_GroupWise; Fri, 13 Aug 1999 11:36:55 -0600
Message-Id: <[e-mail]>
X-Mailer: Novell GroupWise 5.5.2
Date: Fri, 13 Aug 1999 11:36:35 -0600
From: "Bob Jueneman" <[e-mail]>
To: <[e-mail]>, <[e-mail]>
Cc: <[e-mail]>
Subject: RE: Possible solution?, was Re: Non-Repudiation, was Re: Common  misconceptions, was Re: KISSfor   PKIX.   (Was: RE:ASN.1vs   XML    (usedto be RE: I-D 	ACTION 	 :draft-ietf-pkix-scvp-00.txt))
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 mail.proper.com id KAA27356

Steve, 

There was a fairly extensive discussion which I think I initiated, but
it may have taken place on the cert-talk list -- I just don't recall.

Bob

>>> Stephen Kent <[e-mail]> 08/12/99 03:55PM >>>
Larry,

I do not recall agreement on this list consistent with your suggestion that
the NR flag would tigger an application to invoke  some form of user alert
re signing.

Steve



Received: from po1.bbn.com (PO1.BBN.COM [192.1.50.38]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id KAA27143 for <[e-mail]>; Fri, 13 Aug 1999 10:28:57 -0700 (PDT)
Received: from [192.233.50.119] ([192.233.50.119]) by po1.bbn.com (8.9.1/8.9.1) with ESMTP id NAA06747; Fri, 13 Aug 1999 13:29:23 -0400 (EDT)
X-Sender: [e-mail]
Message-Id: <v0311070db3da0565ca5b@[192.233.50.119]>
In-Reply-To: <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Fri, 13 Aug 1999 13:30:16 -0400
To: [e-mail]
From: "Robert W. Shirey" <[e-mail]>
Subject: Re: 2459 question - types of issuer certificate
Cc: Sharon Boeyen <[e-mail]>, [e-mail]

At 11:46 AM -0400 8/13/99, [e-mail] wrote:
>     I think we need a more comprehensive and unambiguous set of terms for the
>subclasses of CA certificates (or issuer certificates).  The three main types
>are: self-signed issuer certificates, inter-domain certificates (including
>most
>of those which were previously known as cross-certificates), and intra-domain
>issuer certificates (including most hierarchical certificates).   Two of the
>combinations of these three probably also need special names: all issuer
>certificates which are not self-signed are "Delegated issuer" certificates or
>"PKIX cross certificates", and all issuer certificates other than inter-domain
>ones are "Local-domain issuer" certificates.
>
>     The objects managed through the CCR/CCP messages, and the objects
>stored in
>the crossCertificatePair directory attribute, are "Delegated issuer"
>certificates (or "PKIX cross certificates").  The objects stored in the
>caCertificate attribute are "Local-domain issuer" certificates.

Tom,

I strongly support the establishment of unambiguous terminology. But two notes:

1. An effort is underway to correct and improve terminology in the X.509
FPDAM. We need to stay in synch with X.509, or at least not conflict with
it. I assume that the editor, Sharon Boeyen, is monitoring the pkix list
and will help keep us straight.

2. Some of us are trying codify and improve the security terminology in use
in RFCs and Internet-Drafts. If you have not already looked at
<draft-shirey-security-glossary-00.txt>, you might want to check whether
your choices of words are already used for something else, or whether there
is already a suitable term for the concept.

For example, unless I misunderstand your intent, what you call "delegated
issuer" has long been called "subordinate CA", a CA whose public-key
certificate is issued by another CA.

Regards, -Rob-

Robert W. Shirey     GTE Internetworking     Security Practice Center
Suite 1200, 1300 Seventeenth St. North, Arlington, VA  22209-3801 USA
[e-mail], Phone [phone], Reception 284-4600, Fax [phone]




Received: from dkeynt1.DATAKEY.COM (dkeynt1.datakey.com [205.218.59.2]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id JAA26685 for <[e-mail]>; Fri, 13 Aug 1999 09:51:29 -0700 (PDT)
Received: from datakey.com ([205.218.59.75]) by dkeynt1.DATAKEY.COM (Netscape Messaging Server 3.5)  with ESMTP id 376; Fri, 13 Aug 1999 11:54:26 -0500
Message-ID: <[e-mail]>
Date: Fri, 13 Aug 1999 11:57:56 -0500
From: "Dale Gustafson" <[e-mail]>
X-Mailer: Mozilla 4.61 [en] (WinNT; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Bob Jueneman <[e-mail]>
CC: [e-mail], [e-mail]
Subject: Re: Non-Repudiation
References: <[e-mail]>
Content-Type: multipart/alternative; boundary="------------18FB945AE11B041F4E925B58"

--------------18FB945AE11B041F4E925B58
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Hi Bob,

A comment or two, inline.

Best Regards,

Dale Gustafson
Datakey, Inc.
407 West Travelers Trail
Burnsville, MN 55337 USA
612.808.2360 voice
612.890.2726 fax


Bob Jueneman wrote:

> (Warning -- longer than even Ed Gerck's missives, but worth every megabyte.)
>
> Robert R. Jueneman
> Security Architect
> Network Security Development
> Novell, Inc.
> 122 East 1700 South
> Provo, UT 84606
> [e-mail]
> 1-801-861-7387

[snip]

> The question, then is whether it is legitimate to INFER user intent from a particular
> key usage type, and to what extent, if any, the subscriber can be bound to such a
> an alleged "death penalty" type of certificate on the basis of some shrink-wrapped or
> "click-wrapped" contract of adhesion, based on the user's cursory acceptance of
> a CA's CPS or subscriber agreement.

[snip]

> But I disagree that CMS signedData provides nonrepudiation, except in the sense that
> Tony Bartoletti argued, i.e., authentication, UNLESS signedData REQUIRES AN
> EXPLICIT CONFIRMATION OF USER INTENT TO BE BOUND.  signedData therefore
> should NOT require a certificate with the NR bit set, since there are lots of times when
> it may be useful to provide authentication (integrity with origin) when there is absolutely
> no intent to be legally bound.  Instead, I would like to see an additional bit defined
> in CMS, perhaps called "bindingIntent."
>
> To be crystal clear, and to bring this diatribe to a close, I divide the end-user uses of
> public key cryptography into three relatively disjoint sets:
>
> 1.  Encryption.  Encryption (key agreement or key exchange, really) keys are generally
> subject to key recovery, either on behalf of the user, so he can recover stored
> encrypted data some number of years later, or on behalf of his organization, for
> reasons ranging from business continuity to investigating fraud.
>
> 2.  Authentication, using what is conventionally called a digital signature, and in
> particular using the DS key usage.  Since authentication is typically (but not always)
> used to access organizational resources and is not legally binding, authentication keys
> are typically not very sensitive to whether key recovery is permitted or not. But
> authentication may apply to a logon for a stream type of session, such as TLS, or it
> may apply to a signed message that is not intended to be legally binding. (The fact t
> hat it wasn't so intended doesn't necessarily mean that it couldn't be construed to be
> binding, however, just as an unsigned e-mail message might also be legally binding
> under the rather relaxed rules for what constitutes a signature.)
>
> 3.  Legally binding, "nonrepudiation" type of signatures reflecting the user's intent to be
> legally bound, whether or not someone (such as the RP) bothers to go to the trouble of
> actually collecting all of the timestamps, CRLs, etc., that might make proving the validity
> of the signature considerably easier.  Since in this case it is vitally important to both the
> user and the RP that only the bona fide subscriber be able to sign such a document, business
> key recovery (and/or centralized key generation) is absolutely unacceptable, and even the
> ability to do personal key recovery may be unwise, because of the presumably greater risk
> of compromise.
>
> The reason why a mixed or unspecified use of encryption plus digital signature (much less NR)
> is such a bad idea is due to the business key recovery requirements, and in addition to the (US)
> export laws that tend to constrain the key length for encryption, but do not constrain digital
> signature key lengths, for those system that enforce such distinctions.

Smart card vendors will provide software libraries and card operating systems that include support
for a "signing only" key pair.  The distinguishing characteristic of this special type of
public/private key pair is that access to the private key component is protected by a special
"Signing Key PIN" (distinct from the User PIN that controls general user access to the card).  The
Signing Key PIN must be entered each and every time that private key is used to create a digital
signature (preferably through a protected authentication path reader device -- the PIN characters go
directly from the keyboard or PINpad to the card and do not traverse the user's desktop or laptop
machine.)

I believe card vendor initial requirements were defined and driven by the new German Digital
Signature laws.  Perhaps their concept of requiring the user to enter this signing key PIN (or
perform some other concious action) for each and every digital signature, which appears to be
motivated by a very similar set of issues, may be useful to this discussion as well.


> Hope this helps to clarify some of these issues.
>
> Regards,
>
> Bob

--------------18FB945AE11B041F4E925B58
Content-Type: text/html; charset=us-ascii
Content-Transfer-Encoding: 7bit

<!doctype html public "-//w3c//dtd html 4.0 transitional//en">
<html>
Hi Bob,
<p>A comment or two, inline.
<p>Best Regards,
<p>Dale Gustafson
<br>Datakey, Inc.
<br>407 West Travelers Trail
<br>Burnsville, MN 55337 USA
<br>612.808.2360 voice
<br>612.890.2726 fax
<br>&nbsp;
<p>Bob Jueneman wrote:
<blockquote TYPE=CITE>(Warning -- longer than even Ed Gerck's missives,
but worth every megabyte.)
<p>Robert R. Jueneman
<br>Security Architect
<br>Network Security Development
<br>Novell, Inc.
<br>122 East 1700 South
<br>Provo, UT 84606
<br>[e-mail]
<br>1-801-861-7387</blockquote>
[snip]
<blockquote TYPE=CITE>The question, then is whether it is legitimate to
<font color="#FF0000">INFER user intent</font> <font color="#FF0000">from
a particular</font>
<br><u><font color="#FF0000">key usage type</font></u>, and to what extent,
if any, the subscriber can be bound to such a
<br>an alleged "death penalty" type of certificate on the basis of some
shrink-wrapped or
<br>"click-wrapped" contract of adhesion, based on the user's cursory acceptance
of
<br>a CA's CPS or subscriber agreement.</blockquote>
[snip]
<blockquote TYPE=CITE>But I disagree that CMS signedData provides nonrepudiation,
except in the sense that
<br>Tony Bartoletti argued, i.e., authentication, UNLESS signedData REQUIRES
AN
<br>EXPLICIT CONFIRMATION OF USER INTENT TO BE BOUND.&nbsp; signedData
therefore
<br>should NOT require a certificate with the NR bit set, since there are
lots of times when
<br>it may be useful to provide authentication (integrity with origin)
when there is absolutely
<br>no intent to be legally bound.&nbsp; Instead, I would like to see an
additional bit defined
<br>in CMS, perhaps called "bindingIntent."
<p>To be crystal clear, and to bring this diatribe to a close, I divide
the end-user uses of
<br>public key cryptography into three relatively disjoint sets:
<p>1.&nbsp; Encryption.&nbsp; Encryption (key agreement or key exchange,
really) keys are generally
<br>subject to key recovery, either on behalf of the user, so he can recover
stored
<br>encrypted data some number of years later, or on behalf of his organization,
for
<br>reasons ranging from business continuity to investigating fraud.
<p>2.&nbsp; Authentication, using what is conventionally called a digital
signature, and in
<br>particular using the DS key usage.&nbsp; Since authentication is typically
(but not always)
<br>used to access organizational resources and is not legally binding,
authentication keys
<br>are typically not very sensitive to whether key recovery is permitted
or not. But
<br>authentication may apply to a logon for a stream type of session, such
as TLS, or it
<br>may apply to a signed message that is not intended to be legally binding.
(The fact t
<br>hat it wasn't so intended doesn't necessarily mean that it couldn't
be construed to be
<br>binding, however, just as an unsigned e-mail message might also be
legally binding
<br>under the rather relaxed rules for what constitutes a signature.)
<p>3.&nbsp; Legally binding, "nonrepudiation" type of signatures reflecting
the user's intent to be
<br>legally bound, whether or not someone (such as the RP) bothers to go
to the trouble of
<br>actually collecting all of the timestamps, CRLs, etc., that might make
proving the validity
<br>of the signature considerably easier.&nbsp; Since in this case it is
vitally important to both the
<br>user and the RP that only the bona fide subscriber be able to sign
such a document, business
<br>key recovery (and/or centralized key generation) is absolutely unacceptable,
and even the
<br>ability to do personal key recovery may be unwise, because of the presumably
greater risk
<br>of compromise.
<p>The reason why a mixed or unspecified use of encryption plus digital
signature (much less NR)
<br>is such a bad idea is due to the business key recovery requirements,
and in addition to the (US)
<br>export laws that tend to constrain the key length for encryption, but
do not constrain digital
<br>signature key lengths, for those system that enforce such distinctions.</blockquote>
Smart card vendors will provide software libraries and card operating systems
that include support for a "signing only" key pair.&nbsp; The distinguishing
characteristic of this special type of public/private key pair is that
access to the private key component is protected by a special "Signing
Key PIN" (distinct from the User PIN that controls general user access
to the card).&nbsp; The Signing Key PIN must be entered each and every
time that private key is used to create a digital signature (preferably
through a protected authentication path reader device -- the PIN characters
go directly from the keyboard or PINpad to the card and do not traverse
the user's desktop or laptop machine.)
<p>I believe card vendor initial requirements were defined and driven by
the new German Digital Signature laws.&nbsp; Perhaps their concept of requiring
the user to enter this signing key PIN (or perform some other concious
action) for each and every digital signature, which appears to be motivated
by a very similar set of issues, may be useful to this discussion as well.
<br>&nbsp;
<blockquote TYPE=CITE>Hope this helps to clarify some of these issues.
<p>Regards,
<p>Bob</blockquote>
</html>

--------------18FB945AE11B041F4E925B58--



Received: from e4.ny.us.ibm.com (e4.ny.us.ibm.com [32.97.182.104]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id IAA25880 for <[e-mail]>; Fri, 13 Aug 1999 08:47:33 -0700 (PDT)
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 LAA37460; Fri, 13 Aug 1999 11:47:46 -0400
Received: from D51MTA05.pok.ibm.com (d51mta05.pok.ibm.com [9.117.200.33]) by northrelay02.pok.ibm.com (8.8.8m2/NCO v2.04) with SMTP id LAA113704; Fri, 13 Aug 1999 11:48:06 -0400
Received: by D51MTA05.pok.ibm.com(Lotus SMTP MTA v4.6.4  (830.2 3-23-1999))  id 852567CC.0056C967 ; Fri, 13 Aug 1999 11:47:56 -0400
X-Lotus-FromDomain: IBMUS
To: Russ Housley <[e-mail]>
cc: Robert Moskowitz <[e-mail]>, [e-mail]
Message-ID: <[e-mail]>
Date: Fri, 13 Aug 1999 11:46:43 -0400
Subject: Re: 2459 question - types of issuer certificate
Mime-Version: 1.0
Content-type: text/plain; charset=us-ascii
Content-Disposition: inline

     I think we need a more comprehensive and unambiguous set of terms for the
subclasses of CA certificates (or issuer certificates).  The three main types
are: self-signed issuer certificates, inter-domain certificates (including most
of those which were previously known as cross-certificates), and intra-domain
issuer certificates (including most hierarchical certificates).   Two of the
combinations of these three probably also need special names: all issuer
certificates which are not self-signed are "Delegated issuer" certificates or
"PKIX cross certificates", and all issuer certificates other than inter-domain
ones are "Local-domain issuer" certificates.

     The objects managed through the CCR/CCP messages, and the objects stored in
the crossCertificatePair directory attribute, are "Delegated issuer"
certificates (or "PKIX cross certificates").  The objects stored in the
caCertificate attribute are "Local-domain issuer" certificates.

     Is this a reasonable interpretation of the current specifications?  I'm
trying to avoid terms which have had inconsistent meanings over time.

          Tom Gindin


Russ Housley <[e-mail]> on 08/13/99 08:53:29 AM

To:   Robert Moskowitz <[e-mail]>
cc:   [e-mail]
Subject:  Re: 2459 question





You have the correct idea.  But, can't we keep it simple?  A
CA  certificate has a subject that can issue other
certificates.  Obviously, the CA  certificate must contain a digital
signature public key (not a key management public key).

Russ

At 02:22 PM 8/12/99 -0400, Robert Moskowitz wrote:
>At 01:12 PM 8/12/1999 -0400, Russ Housley wrote:
> >
> >If the certificate belongs to an entity that will issue certificate to
> >other entities, then the identified extensions should be included.
>
>ERGO  'CA Certificates' Includes:
>
>Root Certs (self-signed and hierarchically signed)
>Signing Certs (though not all signing certs, a VA can have a signing cert)
>Cross Certs
>
>Any others?
>
>
>Robert Moskowitz
>ICSA
>Security Interest EMail: [e-mail]






Received: from homebase.htt-consult.com (homebase.htt-consult.com [208.235.169.130]) by mail.proper.com (8.9.3/8.9.3) with SMTP id IAA25526 for <[e-mail]>; Fri, 13 Aug 1999 08:31:35 -0700 (PDT)
Received: from rgm ([208.235.169.131]) by homebase.htt-consult.com ; Fri, 13 Aug 1999 11:33:10 -0500
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 
Date: Fri, 13 Aug 1999 11:32:03 -0400
To: Russ Housley <[e-mail]>
From: Robert Moskowitz <[e-mail]>
Subject: Re: 2459 question
Cc: [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"

At 08:53 AM 8/13/1999 -0400, Russ Housley wrote:
>You have the correct idea.  But, can't we keep it simple?  A 
>CA  certificate has a subject that can issue other 
>certificates.  Obviously, the CA  certificate must contain a digital 
>signature public key (not a key management public key).

This makes sense, then raises another question.

Is KeyUsage Non-Repudiation bit set, since it is signing tbsCertificate?
(along with cRLsign bit).

>At 02:22 PM 8/12/99 -0400, Robert Moskowitz wrote:
>>At 01:12 PM 8/12/1999 -0400, Russ Housley wrote:
>> >
>> >If the certificate belongs to an entity that will issue certificate to
>> >other entities, then the identified extensions should be included.
>>
>>ERGO  'CA Certificates' Includes:
>>
>>Root Certs (self-signed and hierarchically signed)
>>Signing Certs (though not all signing certs, a VA can have a signing cert)
>>Cross Certs
>>

Robert Moskowitz
ICSA
Security Interest EMail: [e-mail]


Received: from po1.bbn.com (PO1.bbn.com [192.1.50.38]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id IAA25287 for <[e-mail]>; Fri, 13 Aug 1999 08:18:59 -0700 (PDT)
Received: from [128.89.0.110] (COSMEC.BBN.COM [128.89.0.110]) by po1.bbn.com (8.9.1/8.9.1) with ESMTP id LAA20289; Fri, 13 Aug 1999 11:19:23 -0400 (EDT)
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
X-Sender: [e-mail]
Message-Id: <v04020a03b3d9e57d976b@[128.89.0.110]>
In-Reply-To: <010101bee59b$dc750260$[e-mail]>
References: <v04020a01b3d8f2ec6746@[128.33.238.15]>
Date: Fri, 13 Aug 1999 11:09:52 -0400
To: "tog" <[e-mail]>
From: Stephen Kent <[e-mail]>
Subject: Re: Possible solution?, was Re: Non-Repudiation
Cc: <[e-mail]>

Todd,

>Then what exactly is the scope of the use-model for the NR bit?
>
>Todd
>
>> Larry,
>>
>> I do not recall agreement on this list consistent with your suggestion
>that
>> the NR flag would tigger an application to invoke  some form of user alert
>> re signing.
>>
>> Steve

We've discussed the utility of the NR bit, both when asserted and when not
asserted.  I'm not going to spend more time on this thread.

Steve


Received: from www.meridianus.com (209.249.223.28.has.no.reverse [209.249.223.28] (may be forged)) by mail.proper.com (8.9.3/8.9.3) with ESMTP id HAA24910 for <[e-mail]>; Fri, 13 Aug 1999 07:43:22 -0700 (PDT)
Received: from PC1 by www.meridianus.com (8.8.8+Sun/SMI-SVR4) id IAA05206; Fri, 13 Aug 1999 08:35:09 -0700 (PDT)
Message-ID: <010101bee59b$dc750260$[e-mail]>
From: "tog" <[e-mail]>
To: "Larry Layten" <[e-mail]>, "Stephen Kent" <[e-mail]>
Cc: <[e-mail]>
References: <v04020a01b3d8f2ec6746@[128.33.238.15]>
Subject: Re: Possible solution?, was Re: Non-Repudiation
Date: Fri, 13 Aug 1999 07:55:18 -0700
Organization: Meridianus
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.2918.2701
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2918.2701

Then what exactly is the scope of the use-model for the NR bit?

Todd

> Larry,
>
> I do not recall agreement on this list consistent with your suggestion
that
> the NR flag would tigger an application to invoke  some form of user alert
> re signing.
>
> Steve
>



Received: from po1.bbn.com (PO1.bbn.com [192.1.50.38]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id GAA23925 for <[e-mail]>; Fri, 13 Aug 1999 06:21:22 -0700 (PDT)
Received: from [128.33.238.15] (YAKOV.BBN.COM [128.89.0.111]) by po1.bbn.com (8.9.1/8.9.1) with ESMTP id JAA03284; Fri, 13 Aug 1999 09:21:52 -0400 (EDT)
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Message-Id: <v04020a01b3d8f2ec6746@[128.33.238.15]>
In-Reply-To: <[e-mail]>
Date: Thu, 12 Aug 1999 17:55:30 -0400
To: Larry Layten <[e-mail]>
From: Stephen Kent <[e-mail]>
Subject: RE: Possible solution?, was Re: Non-Repudiation, was Re: Common   misconceptions, was Re: KISSfor   PKIX.   (Was: RE:ASN.1vs   XML     (usedto be RE: I-D 	ACTION 	 :draft-ietf-pkix-scvp-00.txt))
Cc: "'[e-mail]'" <[e-mail]>

Larry,

I do not recall agreement on this list consistent with your suggestion that
the NR flag would tigger an application to invoke  some form of user alert
re signing.

Steve


Received: from mail.spyrus.com (mail.spyrus.com [207.212.34.20]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id GAA23847 for <[e-mail]>; Fri, 13 Aug 1999 06:17:39 -0700 (PDT)
Received: from rhousley_laptop.spyrus.com ([209.172.119.101]) by mail.spyrus.com (8.9.3/8.9.3) with ESMTP id GAA24723; Fri, 13 Aug 1999 06:12:41 -0700 (PDT)
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58 
Date: Fri, 13 Aug 1999 08:53:29 -0400
To: Robert Moskowitz <[e-mail]>
From: Russ Housley <[e-mail]>
Subject: Re: 2459 question
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

You have the correct idea.  But, can't we keep it simple?  A 
CA  certificate has a subject that can issue other 
certificates.  Obviously, the CA  certificate must contain a digital 
signature public key (not a key management public key).

Russ

At 02:22 PM 8/12/99 -0400, Robert Moskowitz wrote:
>At 01:12 PM 8/12/1999 -0400, Russ Housley wrote:
> >
> >If the certificate belongs to an entity that will issue certificate to
> >other entities, then the identified extensions should be included.
>
>ERGO  'CA Certificates' Includes:
>
>Root Certs (self-signed and hierarchically signed)
>Signing Certs (though not all signing certs, a VA can have a signing cert)
>Cross Certs
>
>Any others?
>
>
>Robert Moskowitz
>ICSA
>Security Interest EMail: [e-mail]



Received: from tomcat.sac.verio.net ([e-mail] [209.162.64.15]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id TAA21604 for <[e-mail]>; Thu, 12 Aug 1999 19:00:30 -0700 (PDT)
Received: from nma.com (pm03-38.sac.verio.net [209.162.64.104]) by tomcat.sac.verio.net (8.9.1a/8.9.1) with ESMTP id SAA20861; Thu, 12 Aug 1999 18:57:36 -0700 (PDT)
Message-ID: <[e-mail]>
Date: Thu, 12 Aug 1999 18:57:36 -0700
From: Ed Gerck <[e-mail]>
X-Mailer: Mozilla 4.51 [en]C-CCK-MCD {Sony}  (Win98; I)
X-Accept-Language: en
MIME-Version: 1.0
To: Bob Jueneman <[e-mail]>
CC: [e-mail], [e-mail]
Subject: Re: Non-Repudiation
References: <[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Bob Jueneman wrote:

> [snip]
> To be crystal clear, and to bring this diatribe to a close, I divide the end-user uses of
> public key cryptography into three relatively disjoint sets:
>
> 1.  Encryption.  Encryption (key agreement or key exchange, really) keys are generally
> ....
>
> 2.  Authentication, using what is conventionally called a digital signature, and in
> ....
>
> 3.  Legally binding, "nonrepudiation" type of signatures reflecting the user's intent to be
> legally bound, ....

Note that a digital signature can be legally binding even though repudiable.  In other
words, one must be carefull not to equate "legally binding" with "nonrepudiation" --
the difference is that rights equate to duties while power equates to liability  So that
absence of nonrepudiation liability does not mean absence of contract duties -- for
example, the duty to return the merchandise.

In fact, if the nonRepudiation bit would be fully erased from the PKIX specs then
there would IMO be no significant decrease in the value of the specs in order to
support legally binding contracts.  The value of keeping that pesky bit IMO can
thus only be justified if its meaning is clear -- it has no meaning but that which
is defined in a particular CPS.  Otherwise, it will muddy the waters and backfire,
since the UCC does make CAs liable for using incorrect methods.

Cheers,

Ed Gerck



Received: from prv-mail20.provo.novell.com (prv-mail20.provo.novell.com [137.65.82.195]) by mail.proper.com (8.9.3/8.9.3) with SMTP id RAA11211 for <[e-mail]>; Thu, 12 Aug 1999 17:01:41 -0700 (PDT)
Received: from INET-PRV-Message_Server by prv-mail20.provo.novell.com with Novell_GroupWise; Thu, 12 Aug 1999 18:01:44 -0600
Message-Id: <[e-mail]>
X-Mailer: Novell GroupWise 5.5.2
Date: Thu, 12 Aug 1999 18:01:41 -0600
From: "Bob Jueneman" <[e-mail]>
To: <[e-mail]>
Cc: <[e-mail]>
Subject: Re: Non-Repudiation
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 mail.proper.com id RAA11212

(Warning -- longer than even Ed Gerck's missives, but worth every megabyte.)

Robert R. Jueneman
Security Architect
Network Security Development
Novell, Inc.
122 East 1700 South
Provo, UT 84606
[e-mail]
1-801-861-7387

>>> Stephen Kent <[e-mail]> 08/03/99 03:01PM >>>

>Aside: Could you be related to Bob Jueneman?  In the anals of IETF WG
mailing lists, only he has tended to send such long, detailed messages, as
well as being so involved in the legal aspects of PKI :-}.

In the annals of the IETF WG, I've never seen anyone form a plural
of the word 'anal'.  The mind boggles at the thought, but perhaps it's 
appropriate for this thread. :-)

The reason why I have been so interested in the legal issues of PKI is that the 
four companies I have worked for in the 15 or so years I've been involved in 
this space have all had a reasonable expectation that eventually a product 
(or service) would emerge from this that they could make some money on.
If we were only interested in protecting casual e-mail, certainly PGP would 
have been a lot easier to develop and use.  But for business uses, 
it is simply not possible to ignore the potential legal issues, and I have 
been working to try to draw the technologists and the legal community
toward a common understanding of these issues.

>This is an IETF (technica)l WG, not the ABA Technical Committee on Digital
Signatures. The technical definition of NR that we use comes from ISO
7498-2.  

Definitions are of course neither right nor wrong in and of themselves, 
since they are definitions.

Instead, they are either helpful, because they are consistent with the 
general  and accepted usage of a particular term, or they are not helpful.  
Just because one person or group puts together a set of definitions, that 
does not automatically ensure that they will be particularly helpful, or 
well accepted. (The oxymoronic X.521 "useful attributes" with their 
specificity of syntax and paucity of semantics, would be a good case 
in point.)

The technical definition of NR in ISO 7498-2 may or may not have been
helpful in the context of an X.400 message delivery service, but the lack of 
consensus or even understanding of that definition, as has been 
repeatedly demonstrated in this WG for at least the last half-dozen years, is
convincing evidence that the definition is distinctly NOT helpful, useful, or
in agreement with the common usage, and it therefore deserves to be 
deprecated, and either fixed or ignored, regardless of the position taken by
ISO or one of the cochairs. (That does NOT mean, however, that
the bit itself should be removed from the spec, or necessarily even renamed.
We just need to clarify the semantics.)

Attorneys, especially attorneys who are relatively new to the field of PKI and
therefore haven't absorbed all of the technical jargon, would tell you that in 
the law, there is no such thing as nonrepudiation. A given statement can be 
repudiated for any of a whole host of reasons, ranging from denial of the facts of 
the case, to duress or compulsion, to lack of knowing intent, to legal or 
mental incapacity or lack of agency * the infamous "infants, idiots, and married 
women" clause.

On the other hand, as Tony Bartoletti pointed out, neither the presence nor 
the absence of the NR bit is necessarily definitive as to whether a court of law 
determines that you signed (or didn't sign) something.

There are so many different digital signature laws and regulations in various
jurisdictions, and no case law as yet, that it is very difficult to say anything 
with absolute certainty, but it is pretty clear that even if your certificate 
was expired or even explicitly revoked at the time a document was signed, 
that does NOT automatically mean that a given digital signature was 
invalid, if a preponderance of the evidence to the contrary can be presented.

Strange as it may seem, a digital signature may be valid, and the contract binding,
even though it can be absolutely established that the subscriber was not and 
could not possibly be the person who caused the digital signature to be associated 
with a document. In that case, it is quite possible that the forger of a digital 
signature (perhaps someone who stole someone else's private key) ends up being
contractually bound by the terms of the contract he signed, even though 
he used a key and certificate issued to another person. Caveat hacker!

Obviously, however, it is more difficult to convince a jury that the subscriber 
did in fact sign a document if the certificate had been revoked. And even 
more importantly, it is much more difficult for the relying party to prove 
that his reliance on such a digital signature was "commercially reasonable," 
and that he should not bear the loss in that case.

In this regard I agree with Peter, when he said "An electronic signature 
created using a digital signature security procedure satisfies writing and 
signature requirements, with or without non-repudiation properties, whether 
it is created by, or on behalf of, a user." That is generally true with respect to
the statute of frauds requirements that contracts be in writing.  But this may 
not go as far as a higher level of presumptive validity that may attach to a
"secure electronic signature", AKA "digital signature" (to refer to the Illinois act)

There are two fundamental issues in contract law -- who has the burden of proof,
and who bears the risk of loss.  These two issues are NOT automatically linked --
it is perfectly possible that the subscriber (the putative signer) has the burden of 
(dis)proof, yet the relying party bears the risk of loss.  In fact, that is precisely
the case under the rebuttable presumption, burden-shifting statutes such as the
Utah, Washington, etc. acts pertaining to the voluntary use of a certificate issued by
a Licensed CA.

So all that even the best PKI can do is to provide the technical basis for such a 
rebuttable presumption, and to make it substantially easier to prove one thing, and 
substantially more difficult to disprove it. But God-like infallibility isn't going to happen,
and fortunately isn't required..

This WG cannot DEFINE what the legal consequences of some "nonrepudiation" 
bit is or should be.  That is completely beyond our power (and expertise), and 
can only be done by contract, or by statutes such as the Uniform Electronic
Transactions Act being considered by the state commissioners responsible 
for drafting the Uniform Commercial Code in the U.S.

However, this WG can and does have enormous influence in this area, because in 
the absence of either an explicit contract or a statutory requirement or permission, 
the common trade practices within an industry, e.g. as may be established by 
technical standards; or by the course of trade between two parties, are typically 
given great weight by the court in determining whether a given mark or 
signature should be considered legally binding.  Chinese chops may be binding in 
San Francisco's Chinatown, but not in the New York diamond district, where a 
handshake is traditionally considered binding.  In addition, as lawmakers rush 
to pass feel-good legislation in favor of electronic commerce, motherhood, 
and apple pie, their staffs tend to point to the quote the technical definitions 
(whether they understand either the law or the technology).  So it is very important
that we be as deliberative as possible in this issue.

The real problem in all of this is that PKIX is quite CA-centric, and fixated on 
the issue of certificates and protocols, with the tendency to believe that if we can
just solve those problems, everything else is trivial. The other parts of the 
problem (unfortunately) tend to lie outside of our charter, yet nonetheless 
the other groups listen. 

So Peter was correct when he went on to say "On the NR issue, nothing in 
the NR definition requires there to be evidence of user intent. USER INTENT 
IS REQUIRED IN THE UNDERLYING ELECTRONIC SIGNATURE 
AGREEMENT, however." (My emphasis.)  

The question, then is whether it is legitimate to INFER user intent from a particular 
key usage type, and to what extent, if any, the subscriber can be bound to such a 
an alleged "death penalty" type of certificate on the basis of some shrink-wrapped or 
"click-wrapped" contract of adhesion, based on the user's cursory acceptance of
a CA's CPS or subscriber agreement.

We could argue that the user should be so bound, and in fact I have so 
argued with some of my attorney friends. But invariably, I lost. Emotional 
consumer protection issues generally ended up triumphing over logic.

I am therefore inclined to take a more moderate position.  The NR bit 
in the certificate should be interpreted as ENABLING the use of digital 
signatures that are intended to be legally binding, but I now believe that it would 
be prudent to provide an additional indicator to serve as a more explicit 
indication that the user did in fact consciously intend to be legally bound
by her signature.

The ideal place to provide this indication would be in the CMS used by S/MIME.
However, although I am not as certain as I'd like to be, I don't believe that the 
existing "digital signature" signedData bit in CMS provides this indication.  
That bit, as I understand it, says what the purpose of the particular CMS
 wrapper is, i.e., encryption vs. signature, but that DOESN'T even address
the issue of intent.  It might be, for example, that a message was
digitally signed to prevent its undetected corruption in transit or storage, 
but that the intent of the message was approximately "look at what these 
idiots have done now."

Granted, in a traditional mail message that intent can and should be indicated 
by the text of the message itself, but in a transaction processing system we 
want the "message" to be completely machine process able and unambiguous.

I am therefore in complete agreement with Larry Layton (who may have been 
repeating an earlier argument of mine): "If the certificate indicated non-repudiation, 
then an [standards-compliant -- RRJ] application would have to specifically ask for a user's 
authorization to use the certificate to create a [NR type of legally binding] signature." 
[And it probably ought to provide an additional explicit indicator of that fact 
in the message itself, and not rely solely on the certificate - RRJ]"

"I realize that this gets into the policy area rather than the
technical area, but in my mind, the NR indicator provides
a technical means to support a policy whereby specific user
action is required (versus a digital signature used for authentication)."  

Exactly right.

In other words, I disagree with David Kemp when he says: 

> "CMS signedData provides technical nonrepudiation and requires certs
  with the NR bit set", and

> "TLS does not provide technical nonrepudiation of user-level data,
   and when it uses digital signature certs those certs must have the
   DS bit set"

I agree with respect to SSL/TLS -- it does not provide "technical nonrepudiation"
or any kind of nonrepudiation, except arguably nonrepudiation of origin of 
the entire message stream.

But I disagree that CMS signedData provides nonrepudiation, except in the sense that 
Tony Bartoletti argued, i.e., authentication, UNLESS signedData REQUIRES AN 
EXPLICIT CONFIRMATION OF USER INTENT TO BE BOUND.  signedData therefore
should NOT require a certificate with the NR bit set, since there are lots of times when
it may be useful to provide authentication (integrity with origin) when there is absolutely 
no intent to be legally bound.  Instead, I would like to see an additional bit defined
in CMS, perhaps called "bindingIntent."

To be crystal clear, and to bring this diatribe to a close, I divide the end-user uses of 
public key cryptography into three relatively disjoint sets:

1.  Encryption.  Encryption (key agreement or key exchange, really) keys are generally 
subject to key recovery, either on behalf of the user, so he can recover stored 
encrypted data some number of years later, or on behalf of his organization, for 
reasons ranging from business continuity to investigating fraud.

2.  Authentication, using what is conventionally called a digital signature, and in 
particular using the DS key usage.  Since authentication is typically (but not always) 
used to access organizational resources and is not legally binding, authentication keys 
are typically not very sensitive to whether key recovery is permitted or not. But
authentication may apply to a logon for a stream type of session, such as TLS, or it 
may apply to a signed message that is not intended to be legally binding. (The fact t
hat it wasn't so intended doesn't necessarily mean that it couldn't be construed to be 
binding, however, just as an unsigned e-mail message might also be legally binding 
under the rather relaxed rules for what constitutes a signature.)

3.  Legally binding, "nonrepudiation" type of signatures reflecting the user's intent to be 
legally bound, whether or not someone (such as the RP) bothers to go to the trouble of 
actually collecting all of the timestamps, CRLs, etc., that might making proving the validity
of the signature considerably easier.  Since in this case it is vitally important to both the 
user and the RP that only the bona fide subscriber be able to sign such a document, business
key recovery (and/or centralized key generation) is absolutely unacceptable, and even the 
ability to do personal key recovery may be unwise, because of the presumably greater risk 
of compromise.

The reason why a mixed or unspecified use of encryption plus digital signature (much less NR) 
is such a bad idea is due to the business key recovery requirements, and in addition to the (US) 
export laws that tend to constrain the key length for encryption, but do not constrain digital 
signature key lengths, for those system that enforce such distinctions.

Hope this helps to clarify some of these issues.

Regards,

Bob


Received: from netwk.hannam.ac.kr (netwk.hannam.ac.kr [203.247.39.32]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id RAA11172 for <[e-mail]>; Thu, 12 Aug 1999 17:00:30 -0700 (PDT)
Received: from hanjin (hanjin.hannam.ac.kr [203.247.39.68]) by netwk.hannam.ac.kr (8.9.3/8.9.3) with SMTP id SAA02128 for <[e-mail]>; Sun, 13 Aug 2000 18:36:35 +0900 (KST)
From: =?ks_c_5601-1987?B?wbbH0cH4?= <[e-mail]>
To: <[e-mail]>
Subject: 
Date: Fri, 13 Aug 1999 09:00:20 +0900
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="ks_c_5601-1987"
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300
Importance: Normal
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from base64 to 8bit by mail.proper.com id RAA11173

unsubscribe


Received: from mail-out2.apple.com (mail-out2.apple.com [17.254.0.51]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id QAA10797 for <[e-mail]>; Thu, 12 Aug 1999 16:29:30 -0700 (PDT)
Received: from mailgate2.apple.com ([17.129.100.225]) by mail-out2.apple.com (8.8.5/8.8.5) with ESMTP id QAA34220 for <[e-mail]>; Thu, 12 Aug 1999 16:30:07 -0700
Received: from scv4.apple.com (scv4.apple.com) by mailgate2.apple.com (Content Technologies SMTPRS 2.0.15) with ESMTP id <[e-mail]> for <[e-mail]>; Thu, 12 Aug 1999 16:30:00 -0700
Received: from [17.205.41.166] (aram1.apple.com [17.205.41.166]) by scv4.apple.com (8.9.3/8.9.3) with ESMTP id QAA47000 for <[e-mail]>; Thu, 12 Aug 1999 16:29:59 -0700
Message-Id: <[e-mail]>
X-Mailer: Microsoft Outlook Express Macintosh Edition - 4.5 (0410)
Date: Thu, 12 Aug 1999 16:29:56 -0700
Subject: Re: Non-Repudiation
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

Steve:

[snip]
>>I don't care whether MAC "fits the definition". I was arguing David Kemp's
>>point that "Symmetric cryptography involves shared secrets, and so cannot be
>>used to distinguish between parties in a communication." All I was stating
>>was that you can build a system that uses MAC (and hence symmetric
>>cryptography) to replace handwritten signatures and the system can provide
>>the ability to "distinguish between parties".
>
> I do care whether terms used in our discussions fit standard technical
> defintions apropos to the discussion.  Inaccurate use of words in these
> discussions wastes the time of everyone on the list.
>

You are right about the inaccurate use of words and I apologize for typing
too fast (and wasting anybody's time and/or confusing anyone). What I was
trying to state is that for the argument I was making, the definition does
not matter.

Regards,
Aram Perez


Received: from po1.bbn.com (PO1.BBN.COM [192.1.50.38]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id OAA09620 for <[e-mail]>; Thu, 12 Aug 1999 14:42:50 -0700 (PDT)
Received: from [128.33.238.15] (TC015.BBN.COM [128.33.238.15]) by po1.bbn.com (8.9.1/8.9.1) with ESMTP id RAA01972; Thu, 12 Aug 1999 17:43:15 -0400 (EDT)
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
X-Sender: [e-mail] (Unverified)
Message-Id: <v04020a04b3d8a95165a2@[128.33.238.155]>
In-Reply-To: <[e-mail]>
Date: Thu, 12 Aug 1999 12:42:31 -0400
To: "Aram Perez" <[e-mail]>
From: Stephen Kent <[e-mail]>
Subject: Re: Non-Repudiation
Cc: [e-mail]

Aram,

>Steve Kent wrote:
>
>> Aram,
>>
>> The term "digital signature" has a well defined meaning in the technical
>> literature, and was specifically coined in the context of public key
>> cryptography, although one can achieve analogous features via symmetric
>> crypto.
>>
>> [Also note that your characterization of signing a hash by "encrypting" it
>> is not correct, in general, e.g., DSA does not encrypt a hash to sign it.]
>>
>> The term "signature" is more generally applied, and is more broadly defined
>> outside of the technical area in which we are working. Hence a definitoion
>> from a dictionary for the term signature does not address our debate.
>>
>> The X9.9 standard was written at a time when the distinction was clear and
>> that's why that standard does not confuse matters by refering to a MAC as a
>> signature, much less a digital signature.  A critical aspect of a digital
>> signature is that the ability to verify it is cryptogra[hically distinct
>> from the ability to generate it.  That asymmetry is essential if signatures
>> are to be used to support NR.
>>
>> I would argue that your example of a MAC does not fit this definition, as
>> the controls used to effect asymmetry are procedural, not cryptographic.
>> We have about 20 years of technical literature on this topic, most of which
>> is quite consistent in the use of this terminology.
>
>I don't care whether MAC "fits the definition". I was arguing David Kemp's
>point that "Symmetric cryptography involves shared secrets, and so cannot be
>used to distinguish between parties in a communication." All I was stating
>was that you can build a system that uses MAC (and hence symmetric
>cryptography) to replace handwritten signatures and the system can provide
>the ability to "distinguish between parties".

I do care whether terms used in our discussions fit standard technical
defintions apropos to the discussion.  Inaccurate use of words in these
discussions wastes the time of everyone on the list.

Steve


Received: from tomcat.sac.verio.net ([e-mail] [209.162.64.15]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id OAA09029 for <[e-mail]>; Thu, 12 Aug 1999 14:02:16 -0700 (PDT)
Received: from nma.com (pm09-34.sac.verio.net [209.162.65.147]) by tomcat.sac.verio.net (8.9.1a/8.9.1) with ESMTP id NAA15895; Thu, 12 Aug 1999 13:58:54 -0700 (PDT)
Message-ID: <[e-mail]>
Date: Thu, 12 Aug 1999 13:58:54 -0700
From: Ed Gerck <[e-mail]>
X-Mailer: Mozilla 4.51 [en]C-CCK-MCD {Sony}  (Win98; I)
X-Accept-Language: en
MIME-Version: 1.0
To: Larry Layten <[e-mail]>
CC: Alfred Arsenault <[e-mail]>, Stephen Kent <[e-mail]>, "'[e-mail]'" <[e-mail]>
Subject: Re: Possible solution?, was Re: Non-Repudiation, was Re: Common    misconceptions, was Re: KISSfor   PKIX.   (Was: RE:ASN.1vs   XML      (usedto be RE: I-D 	ACTION 	 :draft-ietf-pkix-scvp-00.txt))
References: <[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Larry Layten wrote:

> Please excuse me for jumping into the fray here, but from
> an applilcation developer's point of view, this thread seems
> to have ignored a point that was discussed in this mail list
> several months ago -- and my understanding of this was:
>
> If the certificate indicated non-repudiation, then an application
> would have to specifically ask for a user's authorization to
> use the certificate to create a signature.

This is IMO both too vague and too restricitve. The user may
need also the supervisor's authorization for example, or the user's
authorization may be supplied over a time period.   This also goes
not only into the policy area but also into the application area,
where PKIX should be neutral.

I also agree with Peter Williams, that nothing in the present NR
definition requires there to be evidence of user intent -- and I doubt
that an infrastructure protocol such as PKIX which deals with
objects being exchanged between applications could provide it.

The topic you mention seems also to fall under my question (2)
of yesterday:

 2. Can a CA use PKIX in order to permit or prohibit a
 particular subscriber certificate from being used in a
 transaction?

And the answer IMO is no, only the CPS can handle it in a consistent
way by policy or legal restrictions since all the CA can do is take good
care of what the CA signs, not what the subscriber signs.  The certificate
itself can be seen as a tamperproof communication channel from CA to
r-p but no assurance can be provided on how the corresponding
subscriber's private-key  is used in a transaction at the subscriber's
platform.

Thus, ignoring in PKIX what the application may do in regard to the
user will allow such matters to be handled in the CPS. Otherwise, this
would be pre-empted in the specs and would very probably be either
too vague or too restrictive in a general case.

Cheers,

Ed Gerck



Received: from homebase.htt-consult.com (homebase.htt-consult.com [208.235.169.130]) by mail.proper.com (8.9.3/8.9.3) with SMTP id LAA07334 for <[e-mail]>; Thu, 12 Aug 1999 11:22:15 -0700 (PDT)
Received: from rgm ([208.235.169.131]) by homebase.htt-consult.com ; Thu, 12 Aug 1999 14:23:40 -0500
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 
Date: Thu, 12 Aug 1999 14:22:34 -0400
To: Russ Housley <[e-mail]>
From: Robert Moskowitz <[e-mail]>
Subject: Re: 2459 question
Cc: [e-mail]
In-Reply-To: <[e-mail]>
References: <[e-mail]> <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"

At 01:12 PM 8/12/1999 -0400, Russ Housley wrote:
>
>If the certificate belongs to an entity that will issue certificate to 
>other entities, then the identified extensions should be included.  

ERGO  'CA Certificates' Includes:

Root Certs (self-signed and hierarchically signed)
Signing Certs (though not all signing certs, a VA can have a signing cert)
Cross Certs

Any others?


Robert Moskowitz
ICSA
Security Interest EMail: [e-mail]


Received: from homebase.htt-consult.com (homebase.htt-consult.com [208.235.169.130]) by mail.proper.com (8.9.3/8.9.3) with SMTP id LAA07070 for <[e-mail]>; Thu, 12 Aug 1999 11:11:59 -0700 (PDT)
Received: from rgm ([208.235.169.131]) by homebase.htt-consult.com ; Thu, 12 Aug 1999 14:13:24 -0500
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 
Date: Thu, 12 Aug 1999 14:12:15 -0400
To: Marc Branchaud <[e-mail]>, [e-mail]
From: Robert Moskowitz <[e-mail]>
Subject: Re: 2459 question
In-Reply-To: <[e-mail]>
References: <[e-mail]> <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"

At 10:40 AM 8/12/1999 -0700, Marc Branchaud wrote:
>
>Bob did mention something that has me puzzled:
>
>> Also in a cross-certified PKI, [root] certs are never examined in path
>> construction or validation.
>
>I don't think that's true.  Aren't root/trusted certs used to initialize
>the path processing algorithm?

OK.  The path construction starts with the EE's trusted cert, typically a
root cert.  But any other CA in the path root cert is not needed if the
linkcage is cross-cert.


Robert Moskowitz
ICSA
Security Interest EMail: [e-mail]


Received: from stingray.missi.ncsc.mil (stingray.missi.ncsc.mil [144.51.50.20]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id KAA06652 for <[e-mail]>; Thu, 12 Aug 1999 10:41:21 -0700 (PDT)
Received: from stingray.missi.ncsc.mil (root@localhost) by stingray.missi.ncsc.mil with ESMTP id NAA15701 for <[e-mail]>; Thu, 12 Aug 1999 13:41:50 -0400 (EDT)
Received: from missi.ncsc.mil (depot.missi.ncsc.mil [144.51.60.1]) by stingray.missi.ncsc.mil with ESMTP id NAA15697 for <[e-mail]>; Thu, 12 Aug 1999 13:41:50 -0400 (EDT)
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 NAA21254 for <[e-mail]>; Thu, 12 Aug 1999 13:41:45 -0400 (EDT)
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 NAA23068 for <[e-mail]>; Thu, 12 Aug 1999 13:40:41 -0400 (EDT)
Message-Id: <[e-mail]>
Date: Thu, 12 Aug 1999 13:40:41 -0400 (EDT)
From: "David P. Kemp" <[e-mail]>
Reply-To: "David P. Kemp" <[e-mail]>
Subject: RE: Possible solution?
To: [e-mail]
MIME-Version: 1.0
Content-Type: TEXT/plain; charset=us-ascii
Content-MD5: KHqlHcTYcFW1OXagCnNGpg==
X-Mailer: dtmail 1.3.0 CDE Version 1.3 SunOS 5.7 sun4u sparc

> From: "Peter Williams" <[e-mail]>
> 
> (Note an "electronic signature" is not restricted to
> a digital signature security procedure; an S/MIME envelopedData
> message protected by persistent KEA certificates and the
> KEA key agreement security procedure does just as well,
> as does a MAC exchanged using a notarized symmetric key
> issued according to X9.17. Both of these latter procedures
> may also satisfy NR requirements, additionally.)


As Tony said,

> I agree that this is "technical NR".  The point is, it would seem to
> be uninvolved with issues of private key ownership and protection.

By design, KEA private keys are not held exclusively by the owner.
Because envelopedData may need to be unenveloped at sometime in
the future, and unenveloping requires private keys, the private
keys will be backed up.  This is in contrast to signedData where
no private keys are required to verify the signature.

So if the term "electronic signature"* applies to applications which
require disclosure of the private key in order to verify the signature,
I would say that keypairs for "electronic signature" mechanisms which
are not digital signatures should not have the NR bit asserted.

Symmetric-key-based "arbitrated digital signature schemes" (H.A.C.
11.107), which require an unconditionally trusted third party to
participate in signature generation and verification, are not within
the scope of PKIX or any other PKI.


---
* Since I am not familiar with a rigorous definition of electronic
signature, I can't say if KEA is, in fact, one.  I'll take your word
that it is.



Received: from crack.x509.com (crack.x509.com [199.175.150.1]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id KAA06476 for <[e-mail]>; Thu, 12 Aug 1999 10:38:11 -0700 (PDT)
Received: from xcert.com (saxifrage.x509.com [199.175.148.75]) by crack.x509.com (8.9.3/8.9.3) with ESMTP id KAA07597 for <[e-mail]>; Thu, 12 Aug 1999 10:38:18 -0700 (PDT)
Sender: [e-mail]
Message-ID: <[e-mail]>
Date: Thu, 12 Aug 1999 10:40:46 -0700
From: Marc Branchaud <[e-mail]>
Organization: Xcert International Inc.
X-Mailer: Mozilla 4.61 [en] (X11; U; Linux 2.2.10 i686)
X-Accept-Language: en, fr
MIME-Version: 1.0
To: [e-mail]
Subject: Re: 2459 question
References: <[e-mail]> <[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Of the three extensions Bob mentioned (BasicConstraints, PolicyMapping,
and PolicyConstraints), the only one that I'd leave out of "root" CAs is
PolicyMapping.  I can easily envision creating a root CA that is
constrained as to levels of sub-CAs (BasicConstraints' path length) or
to specific policies.

Only PolicyMapping seems to make sense exclusively in cross-certs.

So I'm agreeing with Russ here, but I gotta say that the bit that Russ
quoted ...

> RFC 2459 says:
> 
>     Conforming CAs MUST support key identifiers (see sec. 4.2.1.1 and
>     4.2.1.2), basic constraints (see sec. 4.2.1.10), key usage (see sec.
>     4.2.1.3), and certificate policies (see sec. 4.2.1.5) extensions. If
>     the CA issues certificates with an empty sequence for the subject
>     field, the CA MUST support the subject alternative name extension
>     (see sec. 4.2.1.7).  Support for the remaining extensions is
>     OPTIONAL. Conforming CAs may support extensions that are not
>     identified within this specification; certificate issuers are
>     cautioned that marking such extensions as critical may inhibit
>     interoperability.
> 

... has nothing to do with the contents of a CA's certificate.  Rather,
the above specifies what extensions CAs have to support (i.e., be able
to include in issued certificates) to be PKIX-compliant.

Bob did mention something that has me puzzled:

> Also in a cross-certified PKI, [root] certs are never examined in path
> construction or validation.

I don't think that's true.  Aren't root/trusted certs used to initialize
the path processing algorithm?

		Marc

+------------------------------------------------------------------------+
 Marc Branchaud                                  \/
 Chief PKI Architect                             /\CERT INTERNATIONAL
INC.
 [e-mail]        PKI References page:             
www.xcert.com
 604-640-6227          www.xcert.com/~marcnarc/PKI/
+------------------------------------------------------------------------+
  PGP key fingerprint:  60 11 4B 9D 4E E5 2F 47  BD C5 C2 BF 26 DF 5A E1


Russ Housley wrote:
> 
> Bob:
> 
> If the certificate belongs to an entity that will issue certificate to
> other entities, then the identified extensions should be included.  This is
> not just the "root" CA, but any CA.  These extensions should be included in
> the CA signature certificate that contains the public key that corresponds
> to the private key used to sign subordinate certificates.
> 
> RFC 2459 says:
> 
>     Conforming CAs MUST support key identifiers (see sec. 4.2.1.1 and
>     4.2.1.2), basic constraints (see sec. 4.2.1.10), key usage (see sec.
>     4.2.1.3), and certificate policies (see sec. 4.2.1.5) extensions. If
>     the CA issues certificates with an empty sequence for the subject
>     field, the CA MUST support the subject alternative name extension
>     (see sec. 4.2.1.7).  Support for the remaining extensions is
>     OPTIONAL. Conforming CAs may support extensions that are not
>     identified within this specification; certificate issuers are
>     cautioned that marking such extensions as critical may inhibit
>     interoperability.
> 
> So, if you do not wish to include PolicyMapping and PolicyConstraints, you
> are not required to do so.
> 
> When two CAs cross-certify, the point is to allow the subordinates to
> validate each other's cetriciates.  As you point out, these cross
> certificates are the most likely to contain PolicyMapping and
> PolicyConstraints extensions.  However, is a complex hierarchy, there may
> be CAs superior to the point of cross certification.  These parent
> certificates may also contain PolicyMapping and PolicyConstraints
> extensions to constrain the privileges of the CAs involved in the cross
> certification.  In such an environment, the trusted point may be superior
> to the point where cross certification is performed.
> 
> Russ
> 
> At 09:43 AM 8/12/99 -0400, Robert Moskowitz wrote:
> >Certain extensions are defined in 2459 as being for 'CA' certs.
> >Particularly BasicConstraints, PolicyMapping, and PolicyConstraints.
> >
> >What is meant by 'CA' certs?  Is this restricted to 'root' or signing
> >certs?  Does it include croos-certs?  Is it defined anywhere?
> >
> >I would think that PolicyMapping and PolicyConstraints are a **Bad** thing
> >to put in root or signing certs, as they are subject to change.  Also in a
> >cross-certified PKI, these certs are never examined in path construction or
> >validation.
> >
> >It makes BIG sense to put them into cross-certs, thus a CA could define its
> >relation with another CA by the constraints IN cert it signs.  Also the
> >constraints could be unilateral.
> >
> >It is OK to respond privately to me on this if the answer is commonly known
> >and I just can't find the reference.
> >
> >
> >Robert Moskowitz
> >ICSA
> >Security Interest EMail: [e-mail]


Received: from mail.spyrus.com (mail.spyrus.com [207.212.34.20]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id KAA06113 for <[e-mail]>; Thu, 12 Aug 1999 10:17:49 -0700 (PDT)
Received: from rhousley_laptop.spyrus.com ([209.172.119.101]) by mail.spyrus.com (8.9.3/8.9.3) with ESMTP id KAA06141; Thu, 12 Aug 1999 10:12:45 -0700 (PDT)
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58 
Date: Thu, 12 Aug 1999 13:12:54 -0400
To: Robert Moskowitz <[e-mail]>
From: Russ Housley <[e-mail]>
Subject: Re: 2459 question
Cc: [e-mail]
In-Reply-To: <[e-mail]>
References: <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed

Bob:

If the certificate belongs to an entity that will issue certificate to 
other entities, then the identified extensions should be included.  This is 
not just the "root" CA, but any CA.  These extensions should be included in 
the CA signature certificate that contains the public key that corresponds 
to the private key used to sign subordinate certificates.

RFC 2459 says:

    Conforming CAs MUST support key identifiers (see sec. 4.2.1.1 and
    4.2.1.2), basic constraints (see sec. 4.2.1.10), key usage (see sec.
    4.2.1.3), and certificate policies (see sec. 4.2.1.5) extensions. If
    the CA issues certificates with an empty sequence for the subject
    field, the CA MUST support the subject alternative name extension
    (see sec. 4.2.1.7).  Support for the remaining extensions is
    OPTIONAL. Conforming CAs may support extensions that are not
    identified within this specification; certificate issuers are
    cautioned that marking such extensions as critical may inhibit
    interoperability.

So, if you do not wish to include PolicyMapping and PolicyConstraints, you 
are not required to do so.

When two CAs cross-certify, the point is to allow the subordinates to 
validate each other's cetriciates.  As you point out, these cross 
certificates are the most likely to contain PolicyMapping and 
PolicyConstraints extensions.  However, is a complex hierarchy, there may 
be CAs superior to the point of cross certification.  These parent 
certificates may also contain PolicyMapping and PolicyConstraints 
extensions to constrain the privileges of the CAs involved in the cross 
certification.  In such an environment, the trusted point may be superior 
to the point where cross certification is performed.

Russ

At 09:43 AM 8/12/99 -0400, Robert Moskowitz wrote:
>Certain extensions are defined in 2459 as being for 'CA' certs.
>Particularly BasicConstraints, PolicyMapping, and PolicyConstraints.
>
>What is meant by 'CA' certs?  Is this restricted to 'root' or signing
>certs?  Does it include croos-certs?  Is it defined anywhere?
>
>I would think that PolicyMapping and PolicyConstraints are a **Bad** thing
>to put in root or signing certs, as they are subject to change.  Also in a
>cross-certified PKI, these certs are never examined in path construction or
>validation.
>
>It makes BIG sense to put them into cross-certs, thus a CA could define its
>relation with another CA by the constraints IN cert it signs.  Also the
>constraints could be unilateral.
>
>It is OK to respond privately to me on this if the answer is commonly known
>and I just can't find the reference.
>
>
>Robert Moskowitz
>ICSA
>Security Interest EMail: [e-mail]



Received: from ext-mail.valicert.com ([63.65.221.10]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id JAA05487 for <[e-mail]>; Thu, 12 Aug 1999 09:40:20 -0700 (PDT)
Received: from int-mail.valicert.com (corporate-gw.valicert.com [63.65.221.2]) by ext-mail.valicert.com (8.9.3/8.9.3) with ESMTP id JAA23725; Thu, 12 Aug 1999 09:40:41 -0700 (PDT)
Received: from rsalaptop ([192.168.3.230]) by int-mail.valicert.com (8.9.3/8.9.3) with SMTP id JAA10155; Thu, 12 Aug 1999 09:40:18 -0700 (PDT)
From: "Peter Williams" <[e-mail]>
To: "Larry Layten" <[e-mail]>
Cc: <[e-mail]>
Subject: RE: Possible solution?, was Re: Non-Repudiation, was Re: Common   misconceptions, was Re: KISSfor   PKIX.   (Was: RE:ASN.1vs   XML     (usedto be RE: I-D 	ACTION 	 :draft-ietf-pkix-scvp-00.txt))
Date: Thu, 12 Aug 1999 09:41:14 -0700
Message-ID: <000401bee4e1$7dfa1af0$[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 8.5, Build 4.71.2173.0
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.0810.800
Importance: Normal
In-Reply-To: <[e-mail]>

> If the certificate indicated non-repudiation, then an application
> would have to specifically ask for a user's authorization to
> use the certificate to create a signature.


No. An electronic signature created using a digital signature
security procedure satisfies writing and signature requirements,
with or without non-repudiation properties, whether it is created
by, or on behalf of, a user. The "on behalf of" clause enables
such as server-agents to perform cryptography on one's behalf
during, for example, its performance of
the automated proof of receipt (with NR) service during
an EDI functional acknowledgement procedure.

On the NR issue, nothing in the NR definition requires there
to be evidence of user intent. User intent is required
in the underlying electronic signature requirement, however.

(Note an "electronic signature" is not restricted to
a digital signature security procedure; an S/MIME envelopedData
message protected by persistent KEA certificates and the
KEA key agreement security procedure does just as well,
as does a MAC exchanged using a notarized symmetric key
issued according to X9.17. Both of these latter procedures
may also satisfy NR requirements, additionally.)


Received: from homebase.htt-consult.com (homebase.htt-consult.com [208.235.169.130]) by mail.proper.com (8.9.3/8.9.3) with SMTP id HAA04354 for <[e-mail]>; Thu, 12 Aug 1999 07:54:40 -0700 (PDT)
Received: from rgm ([208.235.169.131]) by homebase.htt-consult.com ; Thu, 12 Aug 1999 10:56:06 -0500
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 
Date: Thu, 12 Aug 1999 10:55:00 -0400
To: [e-mail]
From: Robert Moskowitz <[e-mail]>
Subject: Re: Another 2459 question <blush>
In-Reply-To: <[e-mail]>
References: <[e-mail]> <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"

At 10:31 AM 8/12/1999 -0400, Robert Moskowitz wrote:

too much reading.  Not reading staight.  this is a straight forward
mis-reading of the quoted text.

<blush>

>5.3.3  Invalidity Date
>
>   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.
>   This date may be earlier than the revocation date in the CRL entry,
>   which is the date at which the CA processed the revocation. When a
>   revocation is first posted by a CA in a CRL, the invalidity date may
>   precede the date of issue of earlier CRLs, but the revocation date
>   SHOULD NOT precede the date of issue of earlier CRLs.  
>

"invalidity date may precede the date of issue of earlier CRLs"

<blush off>


Robert Moskowitz
ICSA
Security Interest EMail: [e-mail]


Received: from homebase.htt-consult.com (homebase.htt-consult.com [208.235.169.130]) by mail.proper.com (8.9.3/8.9.3) with SMTP id HAA03929 for <[e-mail]>; Thu, 12 Aug 1999 07:31:31 -0700 (PDT)
Received: from rgm ([208.235.169.131]) by homebase.htt-consult.com ; Thu, 12 Aug 1999 10:32:56 -0500
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 
Date: Thu, 12 Aug 1999 10:31:49 -0400
To: [e-mail]
From: Robert Moskowitz <[e-mail]>
Subject: Another 2459 question
In-Reply-To: <[e-mail]>
References: <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"

5.3.3  Invalidity Date

   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.
   This date may be earlier than the revocation date in the CRL entry,
   which is the date at which the CA processed the revocation. When a
   revocation is first posted by a CA in a CRL, the invalidity date may
   precede the date of issue of earlier CRLs, but the revocation date
   SHOULD NOT precede the date of issue of earlier CRLs.  

I can see many cases where the Invalidity date WOULD precede the date of
issue of the earlier CRLs.

-	Come back from a vacation, find your system broken into.
-	Short CRL cycle times (eg 4 hours) and find it was comprimised 'yesterday'.
-	Cert is for a system, and HAC attack dated footprints found.

and so forth.  It would be NICE if this date is before previous CRLs, but
SHOULD NOT is too strong.

Of course, what does it mean?  Will anything look at it?  Probably only for
archival, CYA, purposes for the CA.


Robert Moskowitz
ICSA
Security Interest EMail: [e-mail]


Received: from hq.ljl.COM (hq.ljl.com [206.151.234.1]) by mail.proper.com (8.9.3/8.9.3) with SMTP id GAA03389 for <[e-mail]>; Thu, 12 Aug 1999 06:50:43 -0700 (PDT)
Received: from larry.ljl.com by hq.ljl.COM. with smtp id aa20330; Thu, 12 Aug 1999 08:51:25 -0500
Received: by localhost with Microsoft MAPI; Thu, 12 Aug 1999 08:51:19 -0500
Message-ID: <[e-mail]>
From: Larry Layten <[e-mail]>
To: "'Ed Gerck'" <[e-mail]>, Alfred Arsenault <[e-mail]>
Cc: Stephen Kent <[e-mail]>, "'[e-mail]'" <[e-mail]>
Subject: RE: Possible solution?, was Re: Non-Repudiation, was Re: Common   misconceptions, was Re: KISSfor   PKIX.   (Was: RE:ASN.1vs   XML     (usedto be RE: I-D 	ACTION 	 :draft-ietf-pkix-scvp-00.txt))
Date: Thu, 12 Aug 1999 08:51:18 -0500
Organization: LJL Enterprises, Inc.
X-Mailer: Microsoft Internet E-mail/MAPI - 8.0.0.4211
Encoding: 26 TEXT

Please excuse me for jumping into the fray here, but from
an applilcation developer's point of view, this thread seems
to have ignored a point that was discussed in this mail list
several months ago -- and my understanding of this was:

If the certificate indicated non-repudiation, then an application
would have to specifically ask for a user's authorization to
use the certificate to create a signature.

I realize that this gets into the policy area rather than the
technical area, but in my mind, the the NR indicator provides
a technical means to support a policy whereby specific user
action is required (versus a digital signature used for authentication).

Larry

-----Original Message-----
From:	Ed Gerck [SMTP:[e-mail]]
Sent:	Wednesday, August 11, 1999 6:43 PM
To:	Alfred Arsenault
Cc:	Stephen Kent; Stephen Kent; '[e-mail]'
Subject:	Re: Possible solution?, was Re: Non-Repudiation, was Re: Common 
  misconceptions, was Re: KISSfor   PKIX.   (Was: RE:ASN.1vs   XML     (  
usedto be RE: I-D 	ACTION 	 :draft-ietf-pkix-scvp-00.txt))

[snip]



Received: from homebase.htt-consult.com (homebase.htt-consult.com [208.235.169.130]) by mail.proper.com (8.9.3/8.9.3) with SMTP id GAA03168 for <[e-mail]>; Thu, 12 Aug 1999 06:43:08 -0700 (PDT)
Received: from rgm ([208.235.169.131]) by homebase.htt-consult.com ; Thu, 12 Aug 1999 09:44:34 -0500
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 
Date: Thu, 12 Aug 1999 09:43:27 -0400
To: [e-mail]
From: Robert Moskowitz <[e-mail]>
Subject: 2459 question
In-Reply-To: <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"

Certain extensions are defined in 2459 as being for 'CA' certs.
Particularly BasicConstraints, PolicyMapping, and PolicyConstraints.

What is meant by 'CA' certs?  Is this restricted to 'root' or signing
certs?  Does it include croos-certs?  Is it defined anywhere?

I would think that PolicyMapping and PolicyConstraints are a **Bad** thing
to put in root or signing certs, as they are subject to change.  Also in a
cross-certified PKI, these certs are never examined in path construction or
validation.

It makes BIG sense to put them into cross-certs, thus a CA could define its
relation with another CA by the constraints IN cert it signs.  Also the
constraints could be unilateral.

It is OK to respond privately to me on this if the answer is commonly known
and I just can't find the reference.


Robert Moskowitz
ICSA
Security Interest EMail: [e-mail]


Received: from edelweb.fr (edelweb.fr [193.51.12.16]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id EAA01792 for <[e-mail]>; Thu, 12 Aug 1999 04:57:22 -0700 (PDT)
Received: from champagne.edelweb.fr (localhost.edelweb.fr [127.0.0.1]) by edelweb.fr with ESMTP id NAA14887; Thu, 12 Aug 1999 13:57:54 +0200 (MET DST)
Received: from champagne.edelweb.fr (champagne.edelweb.fr [193.51.14.161]) by edelweb.fr (nospam/1.1); Thu, 12 Aug 1999 13:57:53 +0200 (MET DST)
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 NAA04937; Thu, 12 Aug 1999 13:57:53 +0200 (MET DST)
From: Peter Sylvester <[e-mail]>
Received: (sylvest@localhost) by emeriau.edelweb.fr (8.7.6/8.6.6) id NAA29029; Thu, 12 Aug 1999 13:57:52 +0200 (MET DST)
Date: Thu, 12 Aug 1999 13:57:52 +0200 (MET DST)
Message-Id: <[e-mail]>
To: [e-mail], [e-mail]
Subject: RE: Lets Standardize Time Representation Formats!!!: WAS Re: New  TSTTimedefinition
Cc: Denis.Pinkas[[e-mail]]

> 
> *** Model ***
> The originally proposed model ( TSA as a TTP, maintaining a source of timing
> information and issuing time stamps on requests by external clients) is
> being somewhat dissolved and obscured. Even up to a point when people new to
> the subject found themselves completely lost. Stephen has already raised his
> voice, asking to stick to the original model. I can not agree more. I
> suggest we do not question the model with regards to that draft. The other
> use models are valuable and should not be discarded, but should we discuss
> them outside the context of the current TSS draft?.

A TSA as a third party service is only one of the possible services
that may be necessary in order to provide legally acceptable
dematerialized documents. 

Using the same format for a secure document and a time stamp, namely CMS is
a good thing IMHO. In other words, a time stamp itself is simply a signed
document, and as such similar or identical procedures to validate and verify
the content can be use.

Another element is that the result can become an signed attribute of another
signed document thus binding together data and additional information.

As it is indicated in the DCS text, a time stamping authority becomes just
one example of a more general model. An entity communicates with other
entities in order to distribute or collect information in order to
enhance the value of a document. 

It seems that what has been asked for was to open up the TSTInfo field
for two different purposes (see later under presentation); 

> 
> *** Trust ***
> The main questions to be answered with regards to the trustworthiness of
> time the TSA puts into a token - 
> 1) do we trust the time in the token simply because we trust the TSA, its
> policy and diligence. 
> 2) do we need an extra prove/trust_chain present in each token, as the
> evidence that the time is 'right'.
> 3) do we need anything extra in a token to preserve its value of an
> undeniable evidence 10 years after its creation.
> 
> To me, (3) is simple - if you trust a token today, you should legitimately
> trust it later. It should not matter if the TSA is still around, the time
> was changed because the earth slowed down, or anything else. Similar to "if
> a transaction that used a certificate was authenticated and validated today,
> its validity should be acknowledged in the future, even if the CA who issued
> the certificate no longer exists".

"Simple"? Depending on the final usage and value  (a concept that in itself is
a moving target) you may need to use a network of data to provide evidence that
something exists, had happened, etc. In other words, you get statements like. 
I claim or believe that something is good because this and that other entity told
me that they have verified some other data, and I know that they probaly don't
lie or that they assume a risk because they have shown the an assurance policy
signed by xyz and the government, etc. 
But in the basic argument I agree: At some point, you just have to believe. 



> As a proponent of (1), I've been trying to see the avail of having extra
> time-source-trace data in the token. So far, I am failing to see how it can
> be done unless:
> a) TSA takes ALL time values, for EACH token, directly or indirectly, from a
> 'trusted' source (NIST). Thus effectively precluding using local (even
> closely synchronised with NIST) time sources.
> AND
> b) Each time source (or "time base", using the BERT dictionary), keeps a log
> of all requests
> AND
> c) Each request is signed by the client, so the record in the time base's
> log is rightly associated with the client.
> 
> Unless I'm wrong in my understanding, the a)b)c) above make everything too
> overcomplicated.
'Time stamping' is not 'everything'. If one tries to solve 'everything'
by using just time stamping, indeed things become overcomplicate as you
say. Replace the word 'time stamping' by 'data certification' (where
data can be time) for example. higher level data may have a different value,
thus they may justify additional effort.

> 
> *** Precision and Accuracy ***
> I guess this is where most of people have finally come to common grounds: We
> need sub-second resolution, and we need the accuracy. Where the accuracy is
> defined as a diapason, deviation from the 'absolute time'. The guaranteed
> minimum accuracy should be defined in the TSA policy statement, allowing a
> customer to chose a provider. The actual accuracy can be placed in the
> token, reflecting the current conditions. The accuracy can NOT be greater
> then a precision (i.e.. 12.30'17'' +- .1 is fine, but 12.30'17''001 +- .1 is
> wrong).
In your model the accuracy is not needed. 12.30'17'' is always different
from 12.30'18'' if the accuracy is less a second += .5 What does an accuracy
of .1 second buy you if your precision if one second.  

> 
> *** Presentation ***
> Believe or not, this is were the discussion started. There are dozens of
> comments on the subject, and I will spare myself from reiterating through
> various proposals. It is just technical, and hopefully we will get it right
> there. However, I liked a suggestion (I think it was Todd) of loosing the
> TSTnfo format a bit, by allowing inclusion extra data in case we need it.
> This may be a wise alternative, to pacify the various parties.

2 different needs:

- A format that is not almost printable calender based like generalizedtime,
  as initial proposal think about a REAL representing international
  atomic time. but: how many implementations can convert correctly an NTP
  time into a correctly encoded DER REAL :-)

- An format where the TSTInfo is just another Token from another provider
  (just using a SignedDocument). (cf DCSTime)


Some so called complex things may have much nicer and simple features
than their subdimensional real or imaginary projections. 

> 
> Hoping it will help the discussion to straighten up :)

/P

 


Received: from stargate.zergo.com.au (IDENT:[e-mail] [203.2.208.130]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id VAA12621 for <[e-mail]>; Wed, 11 Aug 1999 21:14:41 -0700 (PDT)
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 OAA06589; Thu, 12 Aug 1999 14:17:38 +1000
Received: by sydneymail1.jp.zergo.com.au with Internet Mail Service (5.5.2448.0) id <QFS34MN6>; Thu, 12 Aug 1999 14:16:21 +1000
Message-ID: <[e-mail]>
From: Michael Zolotarev <[e-mail]>
To: [e-mail]
Cc: Denis Pinkas <Denis.Pinkas[[e-mail]]>
Subject: RE: Lets Standardize Time Representation Formats!!!: WAS Re: New  TSTTimedefinition
Date: Thu, 12 Aug 1999 14:16:21 +1000
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2448.0)
Content-Type: text/plain; charset="iso-8859-1"

Dear All,

I've been away for a week, thus putting myself into a surprisingly favorable
position of not been dragged into the 'discussion rampage'. Instead, after
coming back and run-surfing through 200+ messages (oh dear), a kind of a
'general' picture has emerged.

Unfortunately, as it appears to be, we are loosing track of what we have
started from and what we are trying to resolve/achieve. The things are as
messy and merry-go-roundish as they have never been, and it does not seem
that the end is near.

Hoping to help the discussion out of the loop, I separate all various
problems into 4 groups: Model, Trust, Precision and Accuracy, Presentation.

*** Model ***
The originally proposed model ( TSA as a TTP, maintaining a source of timing
information and issuing time stamps on requests by external clients) is
being somewhat dissolved and obscured. Even up to a point when people new to
the subject found themselves completely lost. Stephen has already raised his
voice, asking to stick to the original model. I can not agree more. I
suggest we do not question the model with regards to that draft. The other
use models are valuable and should not be discarded, but should we discuss
them outside the context of the current TSS draft?.

*** Trust ***
The main questions to be answered with regards to the trustworthiness of
time the TSA puts into a token - 
1) do we trust the time in the token simply because we trust the TSA, its
policy and diligence. 
2) do we need an extra prove/trust_chain present in each token, as the
evidence that the time is 'right'.
3) do we need anything extra in a token to preserve its value of an
undeniable evidence 10 years after its creation.

To me, (3) is simple - if you trust a token today, you should legitimately
trust it later. It should not matter if the TSA is still around, the time
was changed because the earth slowed down, or anything else. Similar to "if
a transaction that used a certificate was authenticated and validated today,
its validity should be acknowledged in the future, even if the CA who issued
the certificate no longer exists".
As a proponent of (1), I've been trying to see the avail of having extra
time-source-trace data in the token. So far, I am failing to see how it can
be done unless:
a) TSA takes ALL time values, for EACH token, directly or indirectly, from a
'trusted' source (NIST). Thus effectively precluding using local (even
closely synchronised with NIST) time sources.
AND
b) Each time source (or "time base", using the BERT dictionary), keeps a log
of all requests
AND
c) Each request is signed by the client, so the record in the time base's
log is rightly associated with the client.

Unless I'm wrong in my understanding, the a)b)c) above make everything too
overcomplicated.

*** Precision and Accuracy ***
I guess this is where most of people have finally come to common grounds: We
need sub-second resolution, and we need the accuracy. Where the accuracy is
defined as a diapason, deviation from the 'absolute time'. The guaranteed
minimum accuracy should be defined in the TSA policy statement, allowing a
customer to chose a provider. The actual accuracy can be placed in the
token, reflecting the current conditions. The accuracy can NOT be greater
then a precision (i.e.. 12.30'17'' +- .1 is fine, but 12.30'17''001 +- .1 is
wrong).

*** Presentation ***
Believe or not, this is were the discussion started. There are dozens of
comments on the subject, and I will spare myself from reiterating through
various proposals. It is just technical, and hopefully we will get it right
there. However, I liked a suggestion (I think it was Todd) of loosing the
TSTnfo format a bit, by allowing inclusion extra data in case we need it.
This may be a wise alternative, to pacify the various parties.


Regards
MichaelZ

Hoping it will help the discussion to straighten up :)


Received: from e1.ny.us.ibm.com (e2.ny.us.ibm.com [32.97.182.102]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id TAA29888 for <[e-mail]>; Wed, 11 Aug 1999 19:05:37 -0700 (PDT)
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 WAA302130; Wed, 11 Aug 1999 22:05:30 -0400
Received: from D51MTA05.pok.ibm.com (d51mta05.pok.ibm.com [9.117.200.33]) by northrelay02.pok.ibm.com (8.8.8m2/NCO v2.04) with SMTP id WAA177794; Wed, 11 Aug 1999 22:05:48 -0400
Received: by D51MTA05.pok.ibm.com(Lotus SMTP MTA v4.6.4  (830.2 3-23-1999))  id 852567CB.000B826A ; Wed, 11 Aug 1999 22:05:42 -0400
X-Lotus-FromDomain: IBMUS
To: Tony Bartoletti <[e-mail]>
cc: Ed Gerck <[e-mail]>, Alfred Arsenault <[e-mail]>, Stephen Kent <[e-mail]>, "'[e-mail]'" <[e-mail]>
Message-ID: <[e-mail]>
Date: Wed, 11 Aug 1999 22:04:31 -0400
Subject: Re: Possible solution?, was Re: Non-Repudiation
Mime-Version: 1.0
Content-type: text/plain; charset=us-ascii
Content-Disposition: inline

(snip)
Tony Bartoletti wrote:

>4   Take a certificate with the nonRepudiation bit off --
>is this a negation, or a declaration of non-existence, or a
>declaration of an ignored feature?  To clarify, if the NR
>bit is off, does it mean that the NR is denied, or that
>NR does not exist, or that NR can still be provided if so
>declared elsewhere?
>
>[Tom Gindin]   It might mean "proceed at your own risk", as well.  That would
>deny NR, but not necessarily the transaction.

Once again (now in reverse) if you intentionally sign a contract,
in the presence of suitable witnesses (for example), using a
key whose cert has the NR bit OFF, with the hope of being able
to later repudiate the signature, I may still be able to take you
to court and "prove" non-repudiability, if I have collected some
other suitable evidences that you were in sole possession of the
key, and expressed intent, etc., regarding the act.

So NR is NOT denied.  At most, the cert says "the CA denies".

[Tom Gindin]   In the case of a remote automated access, the absence of an NR
bit would make a difference.  Of course, an individual can always make a
contract, and with enough witnesses an "X" is sufficient.  The NR bit might
enable denial of an agent relationship all by itself, however.  Personally, I
would imagine that for the next generation or so formal contract signings with
witnesses will involve the signing of a written summary of the contract with a
reference to a digital object signed by each party.  Such a procedure would
certainly have greater assurance than the conventional one, because of the
non-severability of digital signatures, and repudiating the digital signature
will not overturn the contract signature anyway.

As a general rule, assuming we trust a CA to any degree, it would be
well to remember that a certificate can never say anything more than
"the CA says X", since it is nothing more than a document signed
with their issuing key.

Regards,

___tony___




Received: from tomcat.sac.verio.net ([e-mail] [209.162.64.15]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id TAA29854 for <[e-mail]>; Wed, 11 Aug 1999 19:05:20 -0700 (PDT)
Received: from nma.com (pm02-26.sac.verio.net [209.162.64.45]) by tomcat.sac.verio.net (8.9.1a/8.9.1) with ESMTP id TAA08840; Wed, 11 Aug 1999 19:05:37 -0700 (PDT)
Message-ID: <[e-mail]>
Date: Wed, 11 Aug 1999 19:05:39 -0700
From: Ed Gerck <[e-mail]>
X-Mailer: Mozilla 4.51 [en]C-CCK-MCD {Sony}  (Win98; I)
X-Accept-Language: en
MIME-Version: 1.0
To: "<" <@e4.ny.us.ibm.com:[e-mail]>
CC: Alfred Arsenault <[e-mail]>, "'[e-mail]'" <[e-mail]>
Subject: Re: Possible solution?, was Re: Non-Repudiation
References: <[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Tom Gindin a.k.a. "<" wrote:

[snip]

> From Ed Gerck <[e-mail]> on 08/11/99 07:42:36 PM
> ....
>
> Alfred:
>
> I will reply with some questions ;-)
>
> Alfred Arsenault wrote:
>
> > Now, I think that most people agree that the purpose of the
> > non-repudiation bit in the key usage bits field was to signal to relying
> > parties that the CA intended to permit or prohibit a particular
> > certificate from being used in a transaction for which the service of
> > non-repudiation was provided.
>
> 1. Who is authoritative for the nonRepudiation bit state, the
> CA or the subscriber?  What you say above ("the CA
> intended to permit or prohibit") would still be valid if
> the CA would not be authoritative for the NR bit?
>
> 2. Can a CA use PKIX in order to permit or prohibit a
> particular subscriber certificate from being used in a
> transaction?
>
> [Tom Gindin]   A CA can set, and an EE can request, fields in a subscriber
> certificate which restrict which transactions that certificate may be used in.
> The simplest examples are values of a critical extendedKeyUsage extension.  For
> that matter, a critical keyUsage containing neither digitalSignature nor
> nonRepudiation cannot be used as authentication for most transactions.

Tom:

Regarding question (1), that is why I motivated it -- in order to defer this matter
to be handled in the CPS, since either way (CA can set or EE can request) is
allowed in principle.

Regarding question  (2), IMO only the CPS can handle it in a consistent
way by policy or legal restrictions since all the CA can do is take good
care of what the CA signs, not what the subscriber signs.  The certificate
itself can be seen as a tamperproof communication channel from CA to
r-p but no assurance can be provided on how the corresponding
subscriber's private-key  is used in a transaction at the subscriber's platform.

> 3. Take a certificate with the nonRepudiation bit on
> -- what can the relying-party depend upon: (i) in regard
> to the certificate;  (ii) in regard to a transaction signed
> with the certificate; (iii) in regard to the transaction being
> repudiated?
>
> [Tom Gindin]   (i) The relying party can assume that the certificate was
> intended by the issuer to be used in some nonRepudiation transactions.

;-) or, intended by the subscriber? Or, by both? Or, by none of them (say,
by an intervening insurance agent)? Or, simply, the nonRepudiation bit on
means that the subscriber could not change it during Certificate Request
(as no subscriber can, BTW) -- so that the subscriber is not liable (perhaps,
just mildly negligent).

> (ii) and (iii) are the harder ones.
>
> 4   Take a certificate with the nonRepudiation bit off --
> is this a negation, or a declaration of non-existence, or a
> declaration of an ignored feature?  To clarify, if the NR
> bit is off, does it mean that the NR is denied, or that
> NR does not exist, or that NR can still be provided if so
> declared elsewhere?
>
> [Tom Gindin]   It might mean "proceed at your own risk", as well.  That would
> deny NR, but not necessarily the transaction.

"proceed at your own risk" is the second option I offered, denying
NR.  In all *three* options for "bit off" (negation, non-existence,
ignore) I did not include any qualifier for the transaction itself -- which
remains authenticated (after all, it *was* signed).  So, denying NR has
nothing to with denying the transaction -- and, in fact, may be much safer
to the signer even if the signer intends to never repudiate the transaction.


> > How exactly the CA makes that decision is beyond the scope
> > of PKIX; it's presumed that there's a CPS or some
> > similar document that describes it for any given CA.
>
> Yes, and the three questions above can also be declared beyond
> the scope of PKIX -- which is my fourth question:
>
> 4. Are questions (1-3) beyond the scope of PKIX?

Please correct my message to:

5. Are questions (1-4) beyond the scope of PKIX?

> If you answer "Yes", please just delete this email and the following section
> from 2459:
>
>      "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."
>
> and I have no further comments on this matter.

Cheers,

Ed Gerck




Received: from poptop.llnl.gov (poptop.llnl.gov [128.115.18.65]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id SAA25633 for <[e-mail]>; Wed, 11 Aug 1999 18:35:02 -0700 (PDT)
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 SAA22512; Wed, 11 Aug 1999 18:35:23 -0700 (PDT)
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.3 (32)
Date: Wed, 11 Aug 1999 18:35:23 -0700
To: [e-mail], Ed Gerck <[e-mail]>
From: Tony Bartoletti <[e-mail]>
Subject: Re: Possible solution?, was Re: Non-Repudiation
Cc: Alfred Arsenault <[e-mail]>, Stephen Kent <[e-mail]>, "'[e-mail]'" <[e-mail]>
In-Reply-To: <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"

At 08:55 PM 8/11/99 -0400, [e-mail] wrote:

Apologies for the need to qualify every statement, but...

[Ed Gerck asked]
>2. Can a CA use PKIX in order to permit or prohibit a
>particular subscriber certificate from being used in a
>transaction?
>
>[Tom Gindin]   A CA can set, and an EE can request, fields in a subscriber
>certificate which restrict which transactions that certificate may be used in.
>The simplest examples are values of a critical extendedKeyUsage extension.  For
>that matter, a critical keyUsage containing neither digitalSignature nor
>nonRepudiation cannot be used as authentication for most transactions.

This assumes, implicitly, that the subsequent transaction was processed
through "PKIX-compliant" software.

I can certainly write non-compliant processes that would allow the
given transaction to proceed, regardless of what the CA intends.  This
may make it a bit harder for me to argue my case in court, but I doubt
by very much, given all other variables.

>3. Take a certificate with the nonRepudiation bit on
>-- what can the relying-party depend upon: (i) in regard
>to the certificate;  (ii) in regard to a transaction signed
>with the certificate; (iii) in regard to the transaction being
>repudiated?
>
>[Tom Gindin]   (i) The relying party can assume that the certificate was
>intended by the issuer to be used in some nonRepudiation transactions.  (ii) and
>(iii) are the harder ones.

I agree.  "Intended by the issuer" is all one can get, given that the
issuer has control over whether to sign a certificate or not.

>4   Take a certificate with the nonRepudiation bit off --
>is this a negation, or a declaration of non-existence, or a
>declaration of an ignored feature?  To clarify, if the NR
>bit is off, does it mean that the NR is denied, or that
>NR does not exist, or that NR can still be provided if so
>declared elsewhere?
>
>[Tom Gindin]   It might mean "proceed at your own risk", as well.  That would
>deny NR, but not necessarily the transaction.

Once again (now in reverse) if you intentionally sign a contract,
in the presence of suitable witnesses (for example), using a
key whose cert has the NR bit OFF, with the hope of being able
to later repudiate the signature, I may still be able to take you
to court and "prove" non-repudiability, if I have collected some
other suitable evidences that you were in sole possession of the
key, and expressed intent, etc., regarding the act.

So NR is NOT denied.  At most, the cert says "the CA denies".

As a general rule, assuming we trust a CA to any degree, it would be
well to remember that a certificate can never say anything more than
"the CA says X", since it is nothing more than a document signed
with their issuing key.

Regards,

___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 mail.proper.com (8.9.3/8.9.3) with ESMTP id RAA19692 for <[e-mail]>; Wed, 11 Aug 1999 17:56:47 -0700 (PDT)
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 UAA215542; Wed, 11 Aug 1999 20:56:56 -0400
Received: from D51MTA05.pok.ibm.com (d51mta05.pok.ibm.com [9.117.200.33]) by northrelay02.pok.ibm.com (8.8.8m2/NCO v2.04) with SMTP id UAA143296; Wed, 11 Aug 1999 20:57:15 -0400
Received: by D51MTA05.pok.ibm.com(Lotus SMTP MTA v4.6.4  (830.2 3-23-1999))  id 852567CB.00053C77 ; Wed, 11 Aug 1999 20:57:11 -0400
X-Lotus-FromDomain: IBMUS
To: Ed Gerck <[e-mail]>
cc: Alfred Arsenault <[e-mail]>, Stephen Kent <[e-mail]>, "'[e-mail]'" <[e-mail]>
Message-ID: <[e-mail]>
Date: Wed, 11 Aug 1999 20:55:58 -0400
Subject: Re: Possible solution?, was Re: Non-Repudiation
Mime-Version: 1.0
Content-type: text/plain; charset=us-ascii
Content-Disposition: inline

     I hope it's not too presumptuous if I answer some of them myself :-)  I
have one question of my own.  Is David Kemp's suggestion that nonRepudiation
refers to a distinct class of object formats that might be signed consistent
with the recollection of members of this list, or is this quasi-legal discussion
the way to clarify the original intent?  If David's suggestion is the right one,
the set of formats for nonRepudiation would begin with PKCS-7 and CMS
SignedData, but might later grow to include XML signatures, for example.

          Tom Gindin


Ed Gerck <[e-mail]> on 08/11/99 07:42:36 PM

To:   Alfred Arsenault <[e-mail]>
cc:   Stephen Kent <[e-mail]>, Stephen Kent <[e-mail]>,
      "'[e-mail]'" <[e-mail]>
Subject:  Re: Possible solution?, was Re: Non-Repudiation, was Re: Common
      misconceptions, was Re: KISSfor   PKIX.   (Was: RE:ASN.1vs   XML
      (usedto be RE: I-D      ACTION      :draft-ietf-pkix-scvp-00.txt))





Alfred:

I will reply with some questions ;-)

Alfred Arsenault wrote:

> Now, I think that most people agree that the purpose of the
> non-repudiation bit in the key usage bits field was to signal to relying
> parties that the CA intended to permit or prohibit a particular
> certificate from being used in a transaction for which the service of
> non-repudiation was provided.

1. Who is authoritative for the nonRepudiation bit state, the
CA or the subscriber?  What you say above ("the CA
intended to permit or prohibit") would still be valid if
the CA would not be authoritative for the NR bit?

2. Can a CA use PKIX in order to permit or prohibit a
particular subscriber certificate from being used in a
transaction?

[Tom Gindin]   A CA can set, and an EE can request, fields in a subscriber
certificate which restrict which transactions that certificate may be used in.
The simplest examples are values of a critical extendedKeyUsage extension.  For
that matter, a critical keyUsage containing neither digitalSignature nor
nonRepudiation cannot be used as authentication for most transactions.

3. Take a certificate with the nonRepudiation bit on
-- what can the relying-party depend upon: (i) in regard
to the certificate;  (ii) in regard to a transaction signed
with the certificate; (iii) in regard to the transaction being
repudiated?

[Tom Gindin]   (i) The relying party can assume that the certificate was
intended by the issuer to be used in some nonRepudiation transactions.  (ii) and
(iii) are the harder ones.

4   Take a certificate with the nonRepudiation bit off --
is this a negation, or a declaration of non-existence, or a
declaration of an ignored feature?  To clarify, if the NR
bit is off, does it mean that the NR is denied, or that
NR does not exist, or that NR can still be provided if so
declared elsewhere?

[Tom Gindin]   It might mean "proceed at your own risk", as well.  That would
deny NR, but not necessarily the transaction.

> How exactly the CA makes that decision is beyond the scope
> of PKIX; it's presumed that there's a CPS or some
> similar document that describes it for any given CA.

Yes, and the three questions above can also be declared beyond
the scope of PKIX -- which is my fourth question:

4. Are questions (1-3) beyond the scope of PKIX?

[Tom Gindin]   What happened to the other question 4? :-)

If you answer "Yes", please just delete this email and the following section
from 2459:

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

and I have no further comments on this matter.

Cheers,

Ed Gerck




Received: from tomcat.sac.verio.net ([e-mail] [209.162.64.15]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id QAA18750 for <[e-mail]>; Wed, 11 Aug 1999 16:45:35 -0700 (PDT)
Received: from nma.com (pm06-42.sac.verio.net [209.162.64.249]) by tomcat.sac.verio.net (8.9.1a/8.9.1) with ESMTP id QAA08293; Wed, 11 Aug 1999 16:42:34 -0700 (PDT)
Message-ID: <[e-mail]>
Date: Wed, 11 Aug 1999 16:42:36 -0700
From: Ed Gerck <[e-mail]>
X-Mailer: Mozilla 4.51 [en]C-CCK-MCD {Sony}  (Win98; I)
X-Accept-Language: en
MIME-Version: 1.0
To: Alfred Arsenault <[e-mail]>
CC: Stephen Kent <[e-mail]>, Stephen Kent <[e-mail]>, "'[e-mail]'" <[e-mail]>
Subject: Re: Possible solution?, was Re: Non-Repudiation, was Re: Common   misconceptions, was Re: KISSfor   PKIX.   (Was: RE:ASN.1vs   XML     (usedto be RE: I-D 	ACTION 	 :draft-ietf-pkix-scvp-00.txt))
References: <v04020a07b3cf66fa3d68@[128.33.238.163]>			 <[e-mail]> <v04020a03b3d0a62117c1@[128.89.0.110]>	 <v04020a04b3d0c4b7d037@[128.89.0.110]> <v04020a08b3d1044e4f27@[128.89.0.110]> <v04020a01b3d4b44253ec@[128.33.238.250]> <[e-mail]> <[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Alfred:

I will reply with some questions ;-)

Alfred Arsenault wrote:

> Now, I think that most people agree that the purpose of the
> non-repudiation bit in the key usage bits field was to signal to relying
> parties that the CA intended to permit or prohibit a particular
> certificate from being used in a transaction for which the service of
> non-repudiation was provided.

1. Who is authoritative for the nonRepudiation bit state, the
CA or the subscriber?  What you say above ("the CA
intended to permit or prohibit") would still be valid if
the CA would not be authoritative for the NR bit?

2. Can a CA use PKIX in order to permit or prohibit a
particular subscriber certificate from being used in a
transaction?

3. Take a certificate with the nonRepudiation bit on
-- what can the relying-party depend upon: (i) in regard
to the certificate;  (ii) in regard to a transaction signed
with the certificate; (iii) in regard to the transaction being
repudiated?

4   Take a certificate with the nonRepudiation bit off --
is this a negation, or a declaration of non-existence, or a
declaration of an ignored feature?  To clarify, if the NR
bit is off, does it mean that the NR is denied, or that
NR does not exist, or that NR can still be provided if so
declared elsewhere?

> How exactly the CA makes that decision is beyond the scope
> of PKIX; it's presumed that there's a CPS or some
> similar document that describes it for any given CA.

Yes, and the three questions above can also be declared beyond
the scope of PKIX -- which is my fourth question:

4. Are questions (1-3) beyond the scope of PKIX?

If you answer "Yes", please just delete this email and the following section
from 2459:

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

and I have no further comments on this matter.

Cheers,

Ed Gerck



Received: from poptop.llnl.gov (poptop.llnl.gov [128.115.18.65]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id OAA17403 for <[e-mail]>; Wed, 11 Aug 1999 14:49:37 -0700 (PDT)
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 OAA18933; Wed, 11 Aug 1999 14:50:06 -0700 (PDT)
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.3 (32)
Date: Wed, 11 Aug 1999 14:50:06 -0700
To: "David P. Kemp" <[e-mail]>, [e-mail]
From: Tony Bartoletti <[e-mail]>
Subject: RE: Possible solution?
In-Reply-To: <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"

At 04:51 PM 8/11/99 -0400, David P. Kemp wrote:
>
>> From: Tony Bartoletti <[e-mail]>
>> 
>> But of course, this is nothing more than what is meant by "authentication"
>> in digital signatures.  So, unless someone can explain how "technical
>> non-repudiation" is more than this, it is a misleading redundancy (IMHO).
>> 
>> Someone distinguish "technical NR" from "technical authentication" for me,
>> and I'll will stand corrected.
>
>There is a distinction to be made between entity authentication
>(H.A.C. Definition 1.45) and data origin authentication (Definition
>1.48).  There is also a distinction between two-party authentication
>and digital signatures (Definition 1.41, involving a set of messages
>M, a set of signature values S, a signing transformation M->S, and
>a verification transformation MxS -> {True, False}).
>
>I would agree that "technical NR" is a synonym for the combination of
>data authentication and digital signature.  If you leave out either
>the data (persistence) or the signature (proof to a third party), you
>don't have technical NR.

OK.  I stand corrected (or at least clarified;)  

I take "data authentication" to mean, "cryptographically tamperproofed",
and "digital signature" to be the verifiable output of the "signature-
algorithm-collision" of (private) signature key with the data in question.

If this is what is meant (I must read the H.A.C. definitions) then
I agree that this is "technical NR".  The point is, it would seem
to be uninvolved with issues of private key ownership and protection.

That is, a private key could be "made public", anyone could use it
to sign anything, and the assumed cryptographic strength of the
algorithms assures us that, given the triple (data,publicKey,digSig)
we cannot "repudiate" that "data met the private Key" somewhere,
and this is "technical NR".

Anyway, thanks to the pointers to those definitions.

Regards,

___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 mail.proper.com (8.9.3/8.9.3) with ESMTP id OAA17363 for <[e-mail]>; Wed, 11 Aug 1999 14:48:17 -0700 (PDT)
Received: from mailgate1.apple.com (A17-128-100-225.apple.com [17.128.100.225]) by mail-out2.apple.com (8.8.5/8.8.5) with ESMTP id OAA51188 for <[e-mail]>; Wed, 11 Aug 1999 14:48:48 -0700
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, 11 Aug 1999 14:48:38 -0700
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 OAA30396 for <[e-mail]>; Wed, 11 Aug 1999 14:48:36 -0700
Message-Id: <[e-mail]>
X-Mailer: Microsoft Outlook Express Macintosh Edition - 4.5 (0410)
Date: Wed, 11 Aug 1999 14:48:35 -0700
Subject: Re: Possible solution?, was Re: Non-Repudiation, was Re: Common misconceptions, was Re: KISSfor   PKIX.   (Was: RE:ASN.1vs XML (usedto be RE: I-D 	ACTION 	 :draft-ietf-pkix-scvp-00.txt))
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

Alfred Arsenault wrote:

> Holy criminoley!  I'm now officially dazed and confused - not to mention
> hopelessly lost.  I'm trying to figure out how Sean and I are gonna
> write this one up in the PKIX Roadmap, and folks, I ain't got a clue.
> What the heck is this argument about, and what is it we want to
> accomplish, anyway?

Having "work" to do, and not wanting to contribute anymore to your confusion
(or anybody's else), these will be my last comments on the issue (but I
retain the right to repudiate this statement ;):

[snip]
>
> So, the question that seems to have arisen is:
>
>  Does the presence of the non-repudiation bit in the key usage
>  bits field do more harm than good?  That is, given that a
>  certificate with the non-repudiation bit turned on can be easily
>  used in a transaction for which the service of non-repudiation
>  is clearly not provided, is the bit so misleading as to be
>  harmful in a well-designed, well run system based on a PKI using
>  these certificates?
>
> If that's the question under discussion, then I've got at least a
> tenuous grasp on it.

This is the question/issue in my opinion (besides using the term
'non-repudiation'). And in my opinion, the bit does more harm than good. No
matter whether the bit is set or not set, no matter if the bit exists or
not, I can always repudiate a transaction/communication/etc that is signed
with a digital signatures (with the definition pointed out by Steve Kent).
What the digital signature provides is strong evidence for the rebuttal of a
repudiation.

>  If there's more, than somebody needs to enlighten me.

If and when you are enlighten, send some of that enlighten my way ;-)

>
> Now, we have to bear in mind that this question needs to apply across
> all models of PKI that might be put onto the Internet (for which we're
> supposed to be developing "standards").

But this is the PKIX WG which only concerns itself with the model of PKI
based X.509 and not with "all models of PKI" which would include the PGP
model.

>  That is, it should apply in the
> model where we're using a trusted third party such as Verisign,
> GTE-Cybertrust, or Thawte to provide services.  It should also apply in
> situations where a PKI is being run entirely internal to an
> organization, using software and/or hardware from folks like Entrust or
> Microsoft.  It should also apply in situations that combine elements of
> these two.  What is appropriate in one situation may not be appropriate
> in others.
>
> IF it's the case (and I emphasize the IF, there) that we're still trying
> to answer the question above for all of the situations above, and write
> a PKIX profile/successor to RFC 2459 that best supports those
> situations, then I'll stick with my previous position:  the NR bit is
> useful, and should be left in the PKIX profile. It's usefulness includes
> at a minimum the ability for a CA to signal to a relying party that a
> given certificate should NOT be used in a transaction requiring the
> service of non-repudiation.

I disagree because your statement seems to imply that the service of
non-repudiation can only be provided if the NR bit is set. I (or whoever)
should be able to use a "complete system" where I contractually agree that I
would not repudiate any transaction/communication/etc signed with my digital
signature (independent of whether certificate has the NR bit set or reset).

[snip]
>
> AWA:  I'm darned if I understand why having an NR bit turned on allows
> an issuer to "impose NR to all messages purportedly from a subscriber --
> in bulk and for all risks."  Yes, I guess that you could design a system
> such that, if the NR bit was turned on in the subject's certificate, the
> RP would automatically assume that the service of non-repudiation was
> being provided.  Such a system would be horribly wrong, IMNSHO (and to
> use Steve's "technical term").  There are far too many other
> considerations, which are far beyond the scope of PKIX.  You have to do
> the system engineering, or you ain't secure.

I'm confused. If the NR bit is set, how do you distinguish between the
"service of non-repudiation" is being provided and when it's not?

>
>> > >In other words, the NR bit should be used to denote a service, never to
>> > >provide it in any form (however weak).
>> >
>> > We agree that a bit cannot provide the service, just denote the suitability
>> > of the certificate as a component of the service.
>>
>> If we really agree, then we must agree that the NR bit cannot stand for
>> any semantics in regard to NR -- it must be merely a pointer to indicate
>> that a suitable NR service can be queried, which service can be denied
>> or granted prior to the reliance act. Not always granted as nowadays.
>>
>
> AWA:  I wish someone would point out the words in the PKIX documents
> that say, "if the NR bit is on, then NR is automatically provided."  I
> haven't found 'em, and I'd support their being changed.

See my confusion just above. You seem to be saying "If the NR bit is no,
then NR is *NOT* automatically provided". How does the relying party know
when NR is being provided?

[snip]
>
> AWA:  Again, if there are words in the PKIX documents that say or
> strongly imply that any transaction signed by a cert with the NR bit on
> automatically comes with the service of NR, then those words should be
> changed.  But I haven't found them.  Hey, I've been wrong before, I'm
> willing to be shown what I've overlooked.  But, honestly, I can't see
> this.

Ditto my previous comment.

[snip]
>
>  A certificate subject and a relying party (who relied on that
> certificate in carrying out some transaction) go to court over that
> transaction.  The relying party asserts that, based on the certificate
> in question, other evidence it possesses, and the basic qualities of the
> technology, the subject is the one who did something, and thus is
> liable.  The certificate subject asserts that, due to some circumstance
> and based on its own evidence (possibly even including its private key,
> posted on a web site as the solution to an RSA-1024 factoring
> challenge), it is not liable - perhaps this is all fraudulent activity
> on the part of the relying party itself.  The question is:  whom does
> the court believe, and how does it arrive at that belief?
> That's going to be a hard question to resolve, especially the first
> couple of times.  If the RP's evidence consists solely of the subject's
> cert with the NR bit set, the RP is most likely going to lose.

I agree 100% with you here.

>  If, on
> the other hand, the subject shows that its cert had the NR bit off, and
> the subject's CA asserts that that meant that this cert was never to
> have been used in transactions that require the service of
> non-repudiation, then I suspect that that's a strong point for the
> subject.  It may be overcome by other evidence, but it's a starting
> point.

I mostly disagree. The issue will not be decided on solely whether the NR
bit is set or reset. It will be decided on the body of evidence (and who has
the best lawyers).

>
> -- my own opinions.  As if anybody - especially my employer - would
> agree with them!!!

I agreed at least with one point!

Regards,
Aram Perez



Received: from tomcat.sac.verio.net ([e-mail] [209.162.64.15]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id OAA16888 for <[e-mail]>; Wed, 11 Aug 1999 14:09:48 -0700 (PDT)
Received: from nma.com (pm05-13.sac.verio.net [209.162.64.173]) by tomcat.sac.verio.net (8.9.1a/8.9.1) with ESMTP id OAA29516; Wed, 11 Aug 1999 14:10:04 -0700 (PDT)
Message-ID: <[e-mail]>
Date: Wed, 11 Aug 1999 14:10:06 -0700
From: Ed Gerck <[e-mail]>
X-Mailer: Mozilla 4.51 [en]C-CCK-MCD {Sony}  (Win98; I)
X-Accept-Language: en
MIME-Version: 1.0
To: Phillip M Hallam-Baker <[e-mail]>
CC: [e-mail]
Subject: Re: Non-Repudiation
References: <002601bee42a$854c92e0$[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Phill:

Your comments are IMO  fascinatingly irrelevant to PKIX ;-)
And that is why I believe they are timely, since they address
that twilight zone between a PKI and its users -- the transition
from subjective to objective that is not in the objective specs
but which eventually separates what is to be included in the
objective specs.

BTW, if NR would be 100% objective or 100% subjective
then I believe there would be no need to discuss it here --
and we do so exactly because it has several intersubjective
aspects.  Users will have the same problem.

Phillip M Hallam-Baker wrote:

> The only objective definition of Non-Repudiation in my view
> is that a signature has the property of Non-Repudiation if
> the signatories belief in the strength of NR is such that
> she does not repudiate or if a court judgement rules the
> signature to be valid.

I agree that the second statement "if a court judgement rules the
signature to be valid" is an objective definition of NR -- but
one which cannot ascertain NR before the reliance act since it
cannot be applied a priori in most law systems.  Thus, we can't
use it here.

[COMMENT:  in regard to court rules being objective, of course
they are but if there would be a court above the Supreme Court then
it is probable that many Supreme Court decisions would be overturned
-- including those that are unanimous.  OTOH,  technical decisions
such as the value of pi cannot be overtuned. This means that technical
rules can be less dependent on the observer -- ie, can be more
objective.]

The first statement "if the signatories belief  in the strength of NR is such
that she [it] does not repudiate" is  IMO always intersubjectively true
but the usefulness of NR is when one the signatories does NOT believe
in the strength of NR but the other does.  Or, when neither signer
believes but the law "believes" (ie, mandates). Or, any such combination
in tension.  Thus, IMO the first statement is neither objective (eg, in regard
to law) nor useful here, though true (intersubjectively).

> Any other definition of NR will inevitably involve an
> element of subjectivity. This is not surprising since
> the idea that logic provides a route to objective truths
> on any topic other than logic is pretty much discredited
> these days (Alan Sokal's tantrums aside).

Yes, agree on both counts.

> The PKIX group has clearly arrived at an intersubjective
> understanding of Non Repudiation based on the use of Public
> Key cryptography.

Yes, I think so.

> It may be possible to achieve the same quality in other ways
> but these are outside the scope of the working group.

I tend to agree, also. Automating such intersubjective understanding
is not a PKIX matter. BTW, I agree with Bill Brice that if adequate
cert policy OIDs are introduced then adequate software could do it
at least to a certain extent -- but this is also outside the scope of the
WG as far as I understand it.  And, I  agree with David Kemp that
if we want to make distinctions about what a company wishes to
provide, we should use the CP or other extensions to communicate
it, not the keyUsage extension.

Cheers,

Ed Gerck



Received: from stingray.missi.ncsc.mil (stingray.missi.ncsc.mil [144.51.50.20]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id NAA16551 for <[e-mail]>; Wed, 11 Aug 1999 13:52:17 -0700 (PDT)
Received: from stingray.missi.ncsc.mil (root@localhost) by stingray.missi.ncsc.mil with ESMTP id QAA17443 for <[e-mail]>; Wed, 11 Aug 1999 16:52:46 -0400 (EDT)
Received: from missi.ncsc.mil (depot.missi.ncsc.mil [144.51.60.1]) by stingray.missi.ncsc.mil with ESMTP id QAA17439 for <[e-mail]>; Wed, 11 Aug 1999 16:52:46 -0400 (EDT)
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 QAA14125 for <[e-mail]>; Wed, 11 Aug 1999 16:52:41 -0400 (EDT)
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 QAA22693 for <[e-mail]>; Wed, 11 Aug 1999 16:51:40 -0400 (EDT)
Message-Id: <[e-mail]>
Date: Wed, 11 Aug 1999 16:51:40 -0400 (EDT)
From: "David P. Kemp" <[e-mail]>
Reply-To: "David P. Kemp" <[e-mail]>
Subject: RE: Possible solution?
To: [e-mail]
MIME-Version: 1.0
Content-Type: TEXT/plain; charset=us-ascii
Content-MD5: kt92aC0z/L5irlQo20dV3w==
X-Mailer: dtmail 1.3.0 CDE Version 1.3 SunOS 5.7 sun4u sparc

> From: Tony Bartoletti <[e-mail]>
> 
> But of course, this is nothing more than what is meant by "authentication"
> in digital signatures.  So, unless someone can explain how "technical
> non-repudiation" is more than this, it is a misleading redundancy (IMHO).
> 
> Someone distinguish "technical NR" from "technical authentication" for me,
> and I'll will stand corrected.

There is a distinction to be made between entity authentication
(H.A.C. Definition 1.45) and data origin authentication (Definition
1.48).  There is also a distinction between two-party authentication
and digital signatures (Definition 1.41, involving a set of messages
M, a set of signature values S, a signing transformation M->S, and
a verification transformation MxS -> {True, False}).

I would agree that "technical NR" is a synonym for the combination of
data authentication and digital signature.  If you leave out either
the data (persistence) or the signature (proof to a third party), you
don't have technical NR.




Received: from caesar.udac.se (caesar.udac.se [193.44.79.10]) by mail.proper.com (8.9.3/8.9.3) with SMTP id MAA15581 for <[e-mail]>; Wed, 11 Aug 1999 12:35:17 -0700 (PDT)
Received: from mega (t3o69p31.telia.com [62.20.145.31]) by caesar.udac.se (8.7.3/NetworkC-1) with SMTP id VAA55066; Wed, 11 Aug 1999 21:35:26 +0200
Message-ID: <000301bee438$b1dc9f40$[e-mail]>
From: "Anders Rundgren" <[e-mail]>
To: "Stefan Santesson" <[e-mail]>, "'SEIS-List'" <[e-mail]>, "PKIX-List" <[e-mail]>
Subject: QC - Unmistakable Identity Attributes
Date: Wed, 11 Aug 1999 21:32:55 +0100
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 mail.proper.com id MAA15584

Pardon me, I have probably just read the QC draft badly (but repeatedly), but I just 
can't figure out if an attribute that according to the QC-draft CAN be used to uniquely
identify a subject, always MUST be used to create the unique identity. I hope not.
Or is this a part of the CPS to define which of the specified attributes that should
be used to uniquely identify a subject?

Section 4 security 
<snip> 
     Finally, matching rules are not specified for the new attributes 
     defined in the PersonalData field. It is not expected that two quali- 
     fied certificates would be compared to determine if they represent 
     the same physical entity. Such a comparison may provide misleading 
     and should not be performed. 
<snip>

1. Skip "new" in the first paragraph, as it is only "new" at this pre-standard stage. 

2. I don't understand the rest. If applied to let's say a typical ID-card program 
I would say the statement is wrong. I think that a major point with unmistakable 
identity is to be able to have a long-lasting certificate-based relationship without 
any hassles for RPs and subjects.  If identity is allowed to change for a subject
it is a part of the CPS and if a comparision is possible or not is then outside the
scope of the draft (which BTW should be mentioned).

Anders





Received: from poptop.llnl.gov (poptop.llnl.gov [128.115.18.65]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id MAA15070 for <[e-mail]>; Wed, 11 Aug 1999 12:07:30 -0700 (PDT)
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 MAA22316; Wed, 11 Aug 1999 12:07:54 -0700 (PDT)
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.3 (32)
Date: Wed, 11 Aug 1999 12:07:54 -0700
To: "Flanigan, Bill" <[e-mail]>, "'David P. Kemp'" <[e-mail]>
From: Tony Bartoletti <[e-mail]>
Subject: RE: Possible solution?
Cc: [e-mail]
In-Reply-To: <[e-mail].d isa.mil>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"

At 02:26 PM 8/11/99 -0400, Flanigan, Bill wrote:
 
>BF:  What is "technical nonrepudiation"?

Someone correct me if I'm wrong :)

"Technical Nonrepudiation" means that, modulo the current strength and
state of mathematics and (say) factoring:

   Data "D", public key "Y" and (mathematically) verified DigSig "S"
   constitute "proof positive" that the corresponding private key "X"
   collided with data D somewhere.

"Repudiation" of this conclusion would constitute repudiation of the
algorithm's quality of mathematical strength.

"Intent-to-sign" and "ownership-of-key" are not considerations.

But of course, this is nothing more than what is meant by "authentication"
in digital signatures.  So, unless someone can explain how "technical
non-repudiation" is more than this, it is a misleading redundancy (IMHO).

Someone distinguish "technical NR" from "technical authentication" for me,
and I'll will stand corrected.

___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 atdev1.alphatrust.com (www.alphatrust.com [209.39.43.33]) by mail.proper.com (8.9.3/8.9.3) with SMTP id MAA14948 for <[e-mail]>; Wed, 11 Aug 1999 12:04:58 -0700 (PDT)
Received: from 172.16.32.5 by atdmzfrw01.alphatrust.com  Wed, 11 Aug 1999 14:06:53 -0800
Received: from 10.10.1.2 by atdmzfrw02.alphatrust.com  Wed, 11 Aug 1999 14:07:14 -0800
Received: by ATDEV1 with Internet Mail Service (5.5.2448.0) id <QBGV00VH>; Wed, 11 Aug 1999 14:08:33 -0500
Message-ID: <9E60D6A452AAD211904E00105A1973FD02CEDD@ATDEV1>
From: "Bill Brice (listserv)" <[e-mail]>
To: "'Flanigan, Bill'" <[e-mail]>, "'David P. Kemp'" <[e-mail]>
Cc: [e-mail]
Subject: RE: Possible solution?
Date: Wed, 11 Aug 1999 14:08:32 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2448.0)
Content-Type: text/plain; charset="windows-1252"

If one wishes to programmatically determine the meaning
of an NR bit in a cert, it should consult both the 
key usage extension (for presence of NR), and the
certificate policies extension for the presence of a
cert policy OID that is understands. 

This requires, of course, that the software process
understand the implementation of NR under that CP
referenced by the OID.

-Bill Brice, CEO
alphatrust.com

> -----Original Message-----
> From: Flanigan, Bill [mailto:[e-mail]]
> Sent: Wednesday, August 11, 1999 1:27 PM
> To: 'David P. Kemp'
> Cc: [e-mail]
> Subject: RE: Possible solution?
> 
> 
> Dave,
> 
> > ----------
> > From: 	David P. Kemp[SMTP:[e-mail]]
> > Reply To: 	David P. Kemp
> > Sent: 	Wednesday, August 11, 1999 10:22 AM
> > To: 	[e-mail]
> > Subject: 	Re: Possible solution?
> > 
> [snip]
> 
> > IMO, Key Usage bits should be *EXCLUSIVELY* for meanings that
> > can be interpreted by machines without making any reference to the
> > intent of users, CAs, CPSs or CPs.  If we want to make distinctions
> > about what the company wishes to provide, we should use the 
> CP or other
> > extensions to communicate it, not the keyUsage extension.
> > 
> BF:  If machine interpretations should be *exclusively* devoid of
> user/CA/CPS/CP intent, then should we not eliminate the 
> keyUsage extension
> from PKIX as a pre-emptive strike?  What other extensions do 
> you feel should
> have meanings solely interpreted by machines?  On the other hand, what
> current extensions do you feel should be used to communicate 
> user/CA/CPS/CP
> intent?  What new extensions do you feel may be required to 
> communicate
> user/CA/CPS/CP intent? 
> 
> [snip]
> 
> > If we in the IETF can get our act together enough to say that:
> > 
> > * "CMS signedData provides technical nonrepudiation and 
> requires certs
> >   with the NR bit set", and
> > 
> > * "TLS does not provide technical nonrepudiation of user-level data,
> >    and when it uses digital signature certs those certs 
> must have the
> >    DS bit set"
> > 
> > then we will have done the lawyers and legislators a 
> profound service
> > by keeping our noses out of their business.
> > 
> BF:  What is "technical nonrepudiation"?
> 
> Thanks,
> 
> Bill
> 


Received: from caladan.verisign.com (caladan.verisign.com [205.180.232.21]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id LAA14646 for <[e-mail]>; Wed, 11 Aug 1999 11:50:33 -0700 (PDT)
Received: from mentat.verisign.com by caladan.verisign.com (8.8.5/BCH1.5) id LAA20307; Wed, 11 Aug 1999 11:49:09 -0700 (PDT)
Received: from newman.verisign.com by mentat.verisign.com (8.8.5/BCH1.0) id LAA29887; Wed, 11 Aug 1999 11:50:31 -0700 (PDT)
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 PQHGB7BN; Wed, 11 Aug 1999 11:50:32 -0700
From: "Phillip M Hallam-Baker" <[e-mail]>
To: "Aram Perez" <[e-mail]>, <[e-mail]>
Subject: RE: Non-Repudiation
Date: Wed, 11 Aug 1999 14:51:28 -0400
Message-ID: <002601bee42a$854c92e0$[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

I find this thread facinatingly irrelevant to PKIX. For good
or ill PKIX is for PUBLIC KEY Infrastructure.

The only objective definition of Non-Repudiation in my view
is that a signature has the property of Non-Repudiation if
the signatories belief in the strength of NR is such that
she does not repudiate or if a court judgement rules the
signature to be valid.

Any other definition of NR will inevitably involve an
element of subjectivity. This is not surprising since
the idea that logic provides a route to objective truths
on any topic other than logic is pretty much discredited
these days (Alan Sokal's tantrums aside).

The PKIX group has clearly arrived at an intersubjective 
understanding of Non Repudiation based on the use of Public
Key cryptography. It may be possible to achieve the same 
quality in other ways but these are outside the scope of
the working group.

		Phill



Received: from rbhub100.chamb.disa.mil (rbhub100.chamb.disa.mil [209.22.120.23]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id LAA14171 for <[e-mail]>; Wed, 11 Aug 1999 11:23:01 -0700 (PDT)
Received: by rbhub100.chamb.disa.mil with Internet Mail Service (5.5.2448.0) id <QWY3YA2J>; Wed, 11 Aug 1999 14:23:05 -0400
Message-ID: <[e-mail]>
From: "Flanigan, Bill" <[e-mail]>
To: "'David P. Kemp'" <[e-mail]>
Cc: [e-mail]
Subject: RE: Possible solution?
Date: Wed, 11 Aug 1999 14:26:37 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2448.0)
Content-Type: text/plain

Dave,

> ----------
> From: 	David P. Kemp[SMTP:[e-mail]]
> Reply To: 	David P. Kemp
> Sent: 	Wednesday, August 11, 1999 10:22 AM
> To: 	[e-mail]
> Subject: 	Re: Possible solution?
> 
[snip]

> IMO, Key Usage bits should be *EXCLUSIVELY* for meanings that
> can be interpreted by machines without making any reference to the
> intent of users, CAs, CPSs or CPs.  If we want to make distinctions
> about what the company wishes to provide, we should use the CP or other
> extensions to communicate it, not the keyUsage extension.
> 
BF:  If machine interpretations should be *exclusively* devoid of
user/CA/CPS/CP intent, then should we not eliminate the keyUsage extension
from PKIX as a pre-emptive strike?  What other extensions do you feel should
have meanings solely interpreted by machines?  On the other hand, what
current extensions do you feel should be used to communicate user/CA/CPS/CP
intent?  What new extensions do you feel may be required to communicate
user/CA/CPS/CP intent? 

[snip]

> If we in the IETF can get our act together enough to say that:
> 
> * "CMS signedData provides technical nonrepudiation and requires certs
>   with the NR bit set", and
> 
> * "TLS does not provide technical nonrepudiation of user-level data,
>    and when it uses digital signature certs those certs must have the
>    DS bit set"
> 
> then we will have done the lawyers and legislators a profound service
> by keeping our noses out of their business.
> 
BF:  What is "technical nonrepudiation"?

Thanks,

Bill


Received: from atdev1.alphatrust.com (www.alphatrust.com [209.39.43.33]) by mail.proper.com (8.9.3/8.9.3) with SMTP id KAA13237 for <[e-mail]>; Wed, 11 Aug 1999 10:43:43 -0700 (PDT)
Received: from 172.16.32.5 by atdmzfrw01.alphatrust.com  Wed, 11 Aug 1999 12:45:38 -0800
Received: from 10.10.1.2 by atdmzfrw02.alphatrust.com  Wed, 11 Aug 1999 12:45:59 -0800
Received: by ATDEV1 with Internet Mail Service (5.5.2448.0) id <QBGV0049>; Wed, 11 Aug 1999 12:47:16 -0500
Message-ID: <9E60D6A452AAD211904E00105A1973FD02CEDB@ATDEV1>
From: "Bill Brice (listserv)" <[e-mail]>
To: [e-mail]
Subject: Qualified Certificates and NR
Date: Wed, 11 Aug 1999 12:47:15 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2448.0)
Content-Type: text/plain; charset="iso-8859-1"

All,

The recently published Qualified Certificates draft states
regarding key usage and NR:

---
3.2.3 Key Usage

The key usage extension SHALL be present. If the key usage nonRepudi-
ation (1) is asserted then it SHALL NOT be combined with any other
key usage, i.e. if set, the key usage non-repudiation SHALL be set
exclusively.
---

The above requirement would mandate that a QC cert be only used 
for signing based on policy defined NR requirements. 

My query is a practical one. I see two issues. First,
this requirement precludes QC certs from being dual use, as
is common now (RSA signing + encryption), which is typically done
by combining the digital signature bit with the key encipherment bit
(if used as all). This list knows the security value of single use certs,
but most software in use today can't handle them. Certain versions of
Netscape and Microsoft email software would see a QC cert in a signed
message, save it in the address book, and later use it for sending
an encrypted message back to the signer.

What is the value of precluding other, complementary, bits when the
NR bit is asserted in a QC cert? Is this really what is desired?

The second issue: Does anyone know what today's popular software would do
with a cert that had only the NR bit set? Would it recognize it as
valid for signing without the digital signature bit being set?

-Bill Brice, CEO
alphatrust.com


Received: from mail-out2.apple.com (mail-out2.apple.com [17.254.0.51]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id KAA12672 for <[e-mail]>; Wed, 11 Aug 1999 10:24:27 -0700 (PDT)
Received: from mailgate1.apple.com (A17-128-100-225.apple.com [17.128.100.225]) by mail-out2.apple.com (8.8.5/8.8.5) with ESMTP id KAA52826 for <[e-mail]>; Wed, 11 Aug 1999 10:24:53 -0700
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, 11 Aug 1999 10:24:41 -0700
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 KAA27158 for <[e-mail]>; Wed, 11 Aug 1999 10:24:40 -0700
Message-Id: <[e-mail]>
X-Mailer: Microsoft Outlook Express Macintosh Edition - 4.5 (0410)
Date: Wed, 11 Aug 1999 10:24:39 -0700
Subject: Re: Non-Repudiation
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

Steve Kent wrote:

> Aram,
> 
> The term "digital signature" has a well defined meaning in the technical
> literature, and was specifically coined in the context of public key
> cryptography, although one can achieve analogous features via symmetric
> crypto.
>
> [Also note that your characterization of signing a hash by "encrypting" it
> is not correct, in general, e.g., DSA does not encrypt a hash to sign it.]
>
> The term "signature" is more generally applied, and is more broadly defined
> outside of the technical area in which we are working. Hence a definitoion
> from a dictionary for the term signature does not address our debate.
>
> The X9.9 standard was written at a time when the distinction was clear and
> that's why that standard does not confuse matters by refering to a MAC as a
> signature, much less a digital signature.  A critical aspect of a digital
> signature is that the ability to verify it is cryptogra[hically distinct
> from the ability to generate it.  That asymmetry is essential if signatures
> are to be used to support NR.
>
> I would argue that your example of a MAC does not fit this definition, as
> the controls used to effect asymmetry are procedural, not cryptographic.
> We have about 20 years of technical literature on this topic, most of which
> is quite consistent in the use of this terminology.

I don't care whether MAC "fits the definition". I was arguing David Kemp's
point that "Symmetric cryptography involves shared secrets, and so cannot be
used to distinguish between parties in a communication." All I was stating
was that you can build a system that uses MAC (and hence symmetric
cryptography) to replace handwritten signatures and the system can provide
the ability to "distinguish between parties".

Regards,
Aram Perez


Received: from www.meridianus.com (209.249.223.37.has.no.reverse [209.249.223.37] (may be forged)) by mail.proper.com (8.9.3/8.9.3) with ESMTP id HAA07816 for <[e-mail]>; Wed, 11 Aug 1999 07:51:44 -0700 (PDT)
Received: from PC1 by www.meridianus.com (8.8.8+Sun/SMI-SVR4) id IAA03536; Wed, 11 Aug 1999 08:46:06 -0700 (PDT)
Message-ID: <001f01bee40b$07a99500$[e-mail]>
From: "tog" <[e-mail]>
To: "Paul Koning" <[e-mail]>
Cc: <[e-mail]>
References: <[e-mail]><[e-mail]> <[e-mail]>
Subject: Re: language tags in PKIFreeText
Date: Wed, 11 Aug 1999 08:06:03 -0700
Organization: Meridianus
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 8bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.00.2918.2701
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2918.2701

This is somewhat of a complex issue. Depending on what the PKIFreeText is
used for, it may or may not need a language statement embedded with it  and
this is specific to what and how you intend to use this construct.

For instance if PKIFreeText is used to convey any "transaction specific"
data, there may be a need to specify the language type for any objects
encoded into the Digital Structure, but my feeling is that there should be a
generic applicable language definition tag for the processing of encased or
encapsulated objects inside a larger PKI process.

The reason is that in commercial processing it may be necessary to prove
that the program that used the PKI enablement did a specific set of XY&Z and
this language tag would be useful in establishing a context for the enclosed
objects. This exact same facility can be used in timestamping as well for
setting a an evaluatory context for complex stamping or other efforts where
totally online interpretation is necessary.

The concept to me seems like a perfect use of an OID tree. There are a
limited number of languages on this planet, and it would be pretty easy to
setup a parallel tree to the ISO character encoding tree to represent these
since for commercial purposes there are less than 20 or thirty instances of
different language tags. This in and of itself may be one of the things that
pushes us as a planetary race to come to grips with uniform methods of
representing the context of our interpretation models.

My feeling is that only a small subset of languages will really be necessary
and since this is really for commerce based  or 'legally binding'
applications, that this effort should not be too complex and that the system
described in RFC2482 is likely to work here just
fine.(http://www.ietf.org/rfc/rfc2482.txt )

Todd

----- Original Message -----
From: Paul Koning <[e-mail]>
To: "Ronald Tschal <[e-mail]>"
Cc: <[e-mail]>
Sent: Monday, August 09, 1999 6:52 AM
Subject: Re: language tags in PKIFreeText


>
>  > Paul Hoffman wrote:
>  >>  At 02:18 PM 8/7/1999 -0700, Ronald Tschalär wrote:
>  >>
>  >> >The definition of PKIFreeText in RFC-2510 says: > > PKIFreeText
>  >> ::= SEQUENCE SIZE (1..MAX) OF UTF8String > -- text encoded as
>  >> UTF-8 String (note: each UTF8String SHOULD > -- include an RFC
>  >> 1766 language tag to indicate the language > -- of the contained
>  >> text) > >Unfortunately, I could find no hint as to *how* the
>  >> language tag should >be included (RFC-1766 only defines the tags
>  >> themselves and a Content-Language >header for MIME-like
>  >> structures). I presume the idea is that the string >start off with
>  >> "<lang-tag>:" followed by the actual text?
>  >>
>  >> I don't think so. Embedding language tags in Unicode (of which
>  >> UTF-8 is a transformation) is described in RFC 2482. This is the
>  >> method that is expected to be used in all Unicode text that will
>  >> contain language tags.
>
>  > Ah, wasn't aware of that spec. Maybe a refernce to it should
>  > be included in the above text.
>
>  > Looking 2482, it allows any number of tags anywhere in the
>  > text. For PKIFreeText it seems to me that one tag per string,
>  > located at the beginning, should suffice.
>
> Maybe so, but maybe not.  Does it make matters significantly easier to
> deviate from the existing RFC and define a data type that is almost
> the same as something already defined but not quite, because it is
> subject to new limitations?
>
> "Free text" suggests that its use is pretty much open; that being the
> case it doesn't seem terribly useful to throw in new restrictions.
>
> paul
>
>



Received: from stingray.missi.ncsc.mil (stingray.missi.ncsc.mil [144.51.50.20]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id HAA07118 for <[e-mail]>; Wed, 11 Aug 1999 07:23:13 -0700 (PDT)
Received: from stingray.missi.ncsc.mil (root@localhost) by stingray.missi.ncsc.mil with ESMTP id KAA09798 for <[e-mail]>; Wed, 11 Aug 1999 10:23:40 -0400 (EDT)
Received: from missi.ncsc.mil (depot.missi.ncsc.mil [144.51.60.1]) by stingray.missi.ncsc.mil with ESMTP id KAA09793 for <[e-mail]>; Wed, 11 Aug 1999 10:23:40 -0400 (EDT)
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 KAA08836 for <[e-mail]>; Wed, 11 Aug 1999 10:23:35 -0400 (EDT)
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 KAA22615 for <[e-mail]>; Wed, 11 Aug 1999 10:22:35 -0400 (EDT)
Message-Id: <[e-mail]>
Date: Wed, 11 Aug 1999 10:22:35 -0400 (EDT)
From: "David P. Kemp" <[e-mail]>
Reply-To: "David P. Kemp" <[e-mail]>
Subject: Re: Possible solution?
To: [e-mail]
MIME-Version: 1.0
Content-Type: TEXT/plain; charset=us-ascii
Content-MD5: 1l2QQzpLy3dWH2fep0Fz3w==
X-Mailer: dtmail 1.3.0 CDE Version 1.3 SunOS 5.7 sun4u sparc

> From: Alfred Arsenault <[e-mail]>
> 
> AWA:  Here's the situation:  a company builds an extranet for
> communication with its subscribers/customers/contractors, using the
> Internet as the transport mechanism and thus fulling under the PKIX
> purview, if there is such a thing.  The company decides as a matter of
> policy that all certs issued for the extranet will have the NR bit set,
> because the company wishes to provide the service of non-repudiation in
> its dealings.  On the paper forms, which users fill out to request
> initialization into the system, users are told all about this.  Thus,
> when the user later sends in the CMP or CMC request message for a
> certificate, there is no indication about the setting of the NR bit. 
> Such an indication is not needed.  I think that this is the case to
> which Steve Kent was referring, and I think that the company's position
> would have a chance of passing a court case.  Yes, in the case of public
> TTP, the CA should not arbitrarily set bits without the user's being
> aware of that, but remember that the public TTP is only one of the
> situations we need to support.


Al,

  My personal opinion is that saying "the company sets the NR bit
because it wishes to provide the service of non-repudiation in its
dealings" is something that PKIX should not touch with a ten foot
pole.  IMO, Key Usage bits should be *EXCLUSIVELY* for meanings that
can be interpreted by machines without making any reference to the
intent of users, CAs, CPSs or CPs.  If we want to make distinctions
about what the company wishes to provide, we should use the CP or other
extensions to communicate it, not the keyUsage extension.

In other words, the X.509 definition: "for verifying digital signatures
used in providing a nonrepudiation service" should be interpreted to
mean "providing a nonrepudiation *security service*", where the universe
of possible security services is the usual list: confidentiality, integrity,
authentication, nonrepudiation, ...

Because CMS signedData provides "the security service of nonrepudiation" or
"technical nonrepudiation", CMS applications which support the keyUsage
extension should require the NR bit to be set in order to create or
verify signedData.  CAs which set the NR bit are saying only that the
certs are usable for CMS signedData and other applications which use
digital signatures persistently applied to user data.  Users who
request certs with the NR bit set are simply requesting a cert which
can be used with S/MIME and the like.  They are *NOT* requesting a cert
which would enable "company non-repudiation" for some S/MIME messages,
as opposed to a different cert which would disclaim "company
non-repudiation" for other S/MIME messages.

If we in the IETF can get our act together enough to say that:

* "CMS signedData provides technical nonrepudiation and requires certs
  with the NR bit set", and

* "TLS does not provide technical nonrepudiation of user-level data,
   and when it uses digital signature certs those certs must have the
   DS bit set"

then we will have done the lawyers and legislators a profound service
by keeping our noses out of their business.

As my grandmother used to say of me in the kitchen, "you're a precious
little help".  She meant it purely in the complimentary sense, but I
can't escape the feeling that this discussion is of precious little help
to anyone in a policymaking position.



Received: from ietf.org (odin.ietf.org [132.151.1.176]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id EAA01022 for <[e-mail]>; Wed, 11 Aug 1999 04:10:33 -0700 (PDT)
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA17809; Wed, 11 Aug 1999 07:10:28 -0400 (EDT)
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-cmp-http-00.txt
Date: Wed, 11 Aug 1999 07:10:28 -0400
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		: Using HTTP as a Transport Protocol for CMP
	Author(s)	: R. Tschalar,  A. Kapoor, C. Adams
	Filename	: draft-ietf-pkix-cmp-http-00.txt
	Pages		: 
	Date		: 10-Aug-99
	
This document describes how to layer [CMP] over [HTTP]. A simple method
for doing so is described in section 5.4 of [CMP], but that method does 
not accommodate a polling mechanism, which may be required in some 
environments. This document specifies an alternative method which uses 
the polling protocol defined in section 5.2 of [CMP]. A new Content-Type 
for messages is also defined.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-pkix-cmp-http-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-cmp-http-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-cmp-http-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-cmp-http-00.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-pkix-cmp-http-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 ietf.org (odin.ietf.org [132.151.1.176]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id EAA01016 for <[e-mail]>; Wed, 11 Aug 1999 04:10:32 -0700 (PDT)
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA17795; Wed, 11 Aug 1999 07:10:24 -0400 (EDT)
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-scvp-01.txt
Date: Wed, 11 Aug 1999 07:10:24 -0400
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		: Simple Certificate Validation Protocol (SCVP)
	Author(s)	: A. Malpani, P. Hoffman	
        Filename	: draft-ietf-pkix-scvp-01.txt
	Pages		: 
	Date		: 10-Aug-99
	
The SCVP protocol allows a client to offload certificate handling to a
server. The server can give a variety of valuable information about the
certificate, such as whether or not the certificate is valid, a chain
to a trusted root, and so on.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-pkix-scvp-01.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-scvp-01.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-scvp-01.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-scvp-01.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-pkix-scvp-01.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

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

--OtherAccess--

--NextPart--




Received: from add3.add.es (add3.add.es [195.76.43.3]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id XAA17583 for <[e-mail]>; Tue, 10 Aug 1999 23:31:07 -0700 (PDT)
From: [e-mail]
Received: from firewall.add.es ([192.168.1.1]) by add3.add.es (Netscape Messaging Server 3.01)  with SMTP id 358 for <[e-mail]>; Wed, 11 Aug 1999 08:15:56 +0200
Message-ID: <[e-mail]>
Date: Wed, 11 Aug 1999 08:22:10 +0200
X-Mailer: Mozilla 4.6 [en] (Win95; I)
X-Accept-Language: en
MIME-Version: 1.0
To: [e-mail]
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

auth 5b019952 subscribe ietf-pkix \
[e-mail]





Received: from po1.bbn.com (PO1.BBN.COM [192.1.50.38]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id UAA07395 for <[e-mail]>; Tue, 10 Aug 1999 20:38:13 -0700 (PDT)
Received: from [128.33.238.45] (TC045.BBN.COM [128.33.238.45]) by po1.bbn.com (8.9.1/8.9.1) with ESMTP id XAA28723; Tue, 10 Aug 1999 23:35:56 -0400 (EDT)
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
X-Sender: [e-mail] (Unverified)
Message-Id: <v04020a02b3d5ecbae80b@[128.33.238.74]>
In-Reply-To: <[e-mail]>
References: <v04020a07b3cf66fa3d68@[128.33.238.163]>				 <[e-mail]> <v04020a03b3d0a62117c1@[128.89.0.110]>		 <v04020a04b3d0c4b7d037@[128.89.0.110]>	 <v04020a08b3d1044e4f27@[128.89.0.110]> <v04020a01b3d4b44253ec@[128.33.238.250]>
Date: Tue, 10 Aug 1999 13:10:11 -0400
To: Ed Gerck <[e-mail]>
From: Stephen Kent <[e-mail]>
Subject: Re: continued, confused, NR discussion
Cc: "'[e-mail]'" <[e-mail]>

Ed,

<snip>


>> >The main difference point may be summarized by saying that a NR
>>certificate:
>> >
>> >- should merely define that a NR service is available in a suitable query,
>>
>> NR is a service that requires certain actions on the part of an RP, perhaps
>> requiring one or more queries to various servers, but not always.
>
>I posit that challenge-response (again, not necessarily cryptographic) is
>a sine qua non condition for any form of NR.  This statement can be reviewed
>in my previous postings and is based on a quite general formal modeling.

There has been no substanbtitive support for that assertion by others on
this list, so ...

>> >- should not attempt to provide NR, neither by declaring that the message
>> >signed with that NR cert is non-repudiable by itself nor by declaring
>>that the
>> >messagewas signed with an intent of NR.
>>
>> The second piint is precisley why the bit is included, so I doubt that we
>> would reverse the semantics based on your suggestion.
>
>Not reverse, but correct the present reversion of cause and effect. The cause
>must be the subscriber right to choose to offer or deny NR in a message by
>message analysis conducted by the subscriber himself as a function of risk
>and cost, not the issuer's power to impose NR to all messages purportedly
>from a subscriber -- in bulk and for all risks.

Subscriber's are not, generally, required to sign up for service with a
given CA, so implicit agreement to enabling the NR bit, as part of a
subscriber agreeemnt, might well be considered equivalent to explicit
request for the bit to be turned on in  a request.  This is especially true
in the current environment, where many cert request implementations do not
permit a user to explicitly request specific cert features in this detail.

>> >In other words, the NR bit should be used to denote a service, never to
>> >provide it in any form (however weak).
>>
>> We agree that a bit cannot provide the service, just denote the suitability
>> of the certificate as a component of the service.
>
>If we really agree, then we must agree that the NR bit cannot stand for
>any semantics in regard to NR -- it must be merely a pointer to indicate
>that a suitable NR service can be queried, which service can be denied
>or granted prior to the reliance act. Not always granted as nowadays.

No. NR is not a service provided by a single bit, a single cert, a single
CRL or OCSP response, or a singloe time stamp from a TSA.  NR reuqires a
collection of subsidiary mechanisms to support it.  Just because the NR bit
is neither sufficient nor necessary for NR in all cases, that does not mean
that it is not of value, that it does not have a role to play.

>> >This could be expressed for example as:
>> >
>> > 1. A certificate that sets the nonRepudiation bit also implictly defines
>> >where  the non-repudiation service is provided, which MUST be:
>> >    1.a. by the issuer if the certificate is self-signed, or otherwise,
>> >    1.b. as regulated in the CPS.
>>
>> Becuase multiple servers may be required to provide NR (e.g., a TSA, a
>> directory, etc.) I don't think "1.a" is quite right.
>
>If the certificate is self-signed, the logic is that the issuer can define
>by itself if and where such multiple servers may be required -- since
>the issuer is identical to the subject and there is no division of powers
>or liability between issuer and subject.  This may also preclude the need
>for an extensive CPS.  In this case, the NR argument goes inductively
>from the issuer to the subject because it was the subject that initially
>caused
>the certificate to be authoritatively self-signed at one past point in time.

Self-signed certs are generally just a syntactic convenience with minimal
security properties, as 2459 points out.   They should not be construed as
anything more.  A cert used in an NR context ought to be issued by a CA
with a published CPS.  If I were an RP, I would not accept a cert in
support of NR from a CA unless I could access and evaluate the
corresponding CPS.

>> >Which would solve IMO the power/liability problem because the subscriber
>> >would always have the power to deny NR upon query (even if done indirectly
>> >through a CA) -- and  the r-p would also know where to query, who is
>> >responsible for what NR aspect (there may be many, with one entity
>>answering
>> >for each aspect, for example in time NR, policy NR, etc.) and in what
>>terms,
>> >*before* deciding to rely on the liability implied by the NR service.
>>
>> You seem to be fixated on this notion of a query involving the subscriber
>> or CA, neither of which is intrinsic to NR.
>
>What you tend to call NR is IMO actually an act of information control
>from the
>CA over the subscriber -- and that is why IMO you see no need for a query
>over a matter already decided.  But, if you really agree that "a [NR] bit
>cannot
>provide the service, just denote the suitability of the certificate as a
>component
>of the service" as you wrote above then you must also agree that the NR
>service
>must be provided elsewhere -- ie, when a client queries a server or a list of
>servers (TSAs, etc.).

The specific requirements for NR are context specific.  Cert revocatioin
info might be acquired by a query to a directory or an OSCP server, or it
might be multicast to a subscriber set.  A transaction and supporting NR
data might be sent to a TSA to be time stamped, or a TTP might act as a
intermediary in the transaction and thus provide the necessary archival
protection w/o recourse to a query. This is how the e-mail equivalent of
registered mail could work, e.g., sending the message via a suitable relay
could provide the necessary NR data.

>The tension between these two visions is perhaps the disconnect here.
>Indeed, I am
>fixated (ie, focused) on the notion that NR is a liability to the
>subscriber and one
>which the subscriber must not be powerless to deny in a message by message
>case.
>And, more, I posit that if the subscriber is put in such a situation (ie,
>being powerless
>to deny for each case) then it will backfire and be nullified.

We don't disagree that NR is ultimately a subscriber and RP issue; the role
of a CA in NR is to provide accurate certs and to act as the source of cert
revocation status info (perhaps distributed via others).  Others may have a
role as well, e.g., TSAs.

>> >Note that the text above says that the subscriber could deny NR upon query
>> >but this only applies *before* the reliance act, not afterwards (ie, if
>>NR is
>> >granted by thesubscriber for that act). Also note that the above mechanism
>> >eliminates the bulk NR aspect  of the present text (which binds NR to
>>the cert,
>> >hence to all messages signed by that cert at all times) and allows NR to be
>> >managed per user and per message.
>> >
>> >> In general, PKIX tries to be policy neutral.
>> >
>> >And that is what it is not, by setting a policy for *key usage*. Which,
>>BTW,
>> >allows an issuer to unilaterally impose a liability upon a subscriber in
>> >regard to all relying-parties at all times -- even if the subscriber
>>does not
>> >request  or know about it.
>>
>> There is a difference between the spec being policy neutral and between the
>> spec providing a means for a cert issuer to express policy.  I think you
>> are confusing the two here.
>
>I am saying that the present text is not policy neutral because it imposes a
>NR policy.  Further, I am saying that this NR policy is not neutral because it
>imposes a liability which the subscriber is powerless to control.  For
>example,
>it is irrelevant whether the NR cert is used to sign a $50.00 or a $500.00
>contract, or whether the contract includes cascading risks -- the subscriber
>cannot vary its NR liability according to risk or even total its NR
>liability under
>a certain cap warranted by insurance. Thus, the PKIX spec became the NR
>policy and an unfair one. However, the "other side" can define the NR policy
>it wants for the transaction -- so that the seller may end up not liable
>at all
>for NR on the seller's obligations but the buyer may have to carry the
>burden of PKIX NR. At least, until the buyer consults a lawyer ;-)

As noted above, a subscriber chooses a CA and associated CPS which
constitutes a critical part of the context for NR.  It is unlikely that a
public, commercial CA would unilaterally impose an NR policy on
subscribers, since that would likely cause subscrubers to look elsewhere.
If an employer acts as a CA and mandates issuance of certs in support of NR
for its employees, for use in their jobs, that is not radically different
from the various other constraints imposed by emoployers (e.g.,
intellectual property agreeements) as conditions of employment. For
example, to travel on business for my employer, I MUST use a Corporate Amex
card issued in my name, and for which I am personally liable for charges.
I didn't get to choose the credit card, and the associated agreement terms,
because my employer has a database link to Amex to collect data om air
carrier, hotel, and car rental use as a means of negotiating better rates
in the future. This is analogous (though not perfectly so) to imposition of
NR policy on users of a CA, in a non-cooperative fashion, and it is a very
real example.

>> >> >> So, I don't envision any change to the text.
>> >> >
>> >> >Is this a matter of consensus? Or, sensus?
>> >>
>> >> My dictionary does not contain an entry for "sensus," so I'll have to
>>pass
>> >> on that one.
>> >
>> >Maybe the lawyers in this list can answer that to you for a change ;-) but
>> >"sensus" is Latin for feeling or perception -- ie, "personal sense" in
>> >English.
>> >Not to be confused with census, neither as voting nor as censorship.
>> >
>> >My phrase simply asked whether your position is a matter of consensus
>> >(collective agreement) or  sensus (personal feeling).
>> >
>> >In regard to NR you may however note that even if PKIX does not change
>> >its text, the beans are already out.   The archived exchanges in this
>>list and
>> >your own bit by bit agreement that setting the nonRepudiation bit is
>>neither
>> >necessary nor sufficient for NR already provides IMO enough grounds for
>> >legal and technical repudiation of the whole concept as currently stated in
>> >the PKIX text.
>>
>> Thanks for sharing your opinion on this topic.
>
>I suggest that a study of Verisign's NetSure plan (for example) will
>reveal further weight to the notion that a party must not offer bulk NR
>or be forced into it as predicated in the PKIX spec for the nonRepudiation
>bit.  There are specific needs (including virus, cascading risks, etc.)
>that need
>to be taken into account by anyone offering to cover a risk. Which is what
>NR is all about -- eg, the risk that the cert subscriber may need to repudiate
>a transaction (for example, because the terms were not well understood at
>03:00 AM or because a virus precluded him to read the full contract).  And,
>pushing for unfair NR in the PKIX spec itself will perhaps only serve to
>make CAs liable for it -- since adoption of PKIX is, after all, voluntary by
>each CA.

Now that IS an example of a specific NR policy.

Steve


Received: from mail.rdc1.md.home.com ([e-mail] [24.2.2.66]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id TAA00782 for <[e-mail]>; Tue, 10 Aug 1999 19:30:02 -0700 (PDT)
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]>; Tue, 10 Aug 1999 19:30:22 -0700
Message-ID: <[e-mail]>
Date: Tue, 10 Aug 1999 22:28:37 -0400
From: Alfred Arsenault <[e-mail]>
Organization: @Home Network
X-Mailer: Mozilla 4.5 [en]C-AtHome0405  (Win95; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Ed Gerck <[e-mail]>
CC: Stephen Kent <[e-mail]>, Stephen Kent <[e-mail]>, "'[e-mail]'" <[e-mail]>
Subject: Re: Possible solution?, was Re: Non-Repudiation, was Re: Common   misconceptions, was Re: KISSfor   PKIX.   (Was: RE:ASN.1vs   XML     (usedto be RE: I-D 	ACTION 	 :draft-ietf-pkix-scvp-00.txt))
References: <v04020a07b3cf66fa3d68@[128.33.238.163]>			 <[e-mail]> <v04020a03b3d0a62117c1@[128.89.0.110]>	 <v04020a04b3d0c4b7d037@[128.89.0.110]> <v04020a08b3d1044e4f27@[128.89.0.110]> <v04020a01b3d4b44253ec@[128.33.238.250]> <[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Holy criminoley!  I'm now officially dazed and confused - not to mention
hopelessly lost.  I'm trying to figure out how Sean and I are gonna
write this one up in the PKIX Roadmap, and folks, I ain't got a clue. 
What the heck is this argument about, and what is it we want to
accomplish, anyway?  

As I understand it, the situation is this:

	- some organizations wish to provide a certificate-based system that
provides the service of non-repudiation for some or all transactions.

	- other organizations wish to provide a certificate-based system  that
provides the authentication and/or confidentiality services, but does
not provide the service of non-repudiation.

These are the things that are within the scope of PKIX.  There are
obviously others who want to provide authentication, confidentiality,
and/or non-repudiation WITHOUT the use of certificates, but they're by
definition outside the scope of PKIX.

Now, I think that most people agree that the purpose of the
non-repudiation bit in the key usage bits field was to signal to relying
parties that the CA intended to permit or prohibit a particular
certificate from being used in a transaction for which the service of
non-repudiation was provided.  How exactly the CA makes that decision is
beyond the scope of PKIX; it's presumed that there's a CPS or some
similar document that describes it for any given CA.

I think that everybody is in violent agreement that actually providing
the service of non-repudiation for any given transaction involves a lot
more than a bit in a certificate being turned on.  It requires an entire
system being well-defined and working properly, including the human
beings who have to interact with it.  However, much of this is beyond
the scope of PKIX, once again.  There's also general agreement that,
since there's little to no case law, nobody's sure what it takes to
really provide the service of non-repudiation in a certificate-based
system.  But, it's beyond the charter of this group to describe how you
do the whole thing, and to levy requirements upon anybody to actually do
it.

So, the question that seems to have arisen is:

	Does the presence of the non-repudiation bit in the key usage
	bits field do more harm than good?  That is, given that a 
	certificate with the non-repudiation bit turned on can be easily
	used in a transaction for which the service of non-repudiation
	is clearly not provided, is the bit so misleading as to be 
	harmful in a well-designed, well run system based on a PKI using
	these certificates?

If that's the question under discussion, then I've got at least a
tenuous grasp on it.  If there's more, than somebody needs to enlighten
me.

Now, we have to bear in mind that this question needs to apply across
all models of PKI that might be put onto the Internet (for which we're
supposed to be developing "standards").  That is, it should apply in the
model where we're using a trusted third party such as Verisign,
GTE-Cybertrust, or Thawte to provide services.  It should also apply in
situations where a PKI is being run entirely internal to an
organization, using software and/or hardware from folks like Entrust or
Microsoft.  It should also apply in situations that combine elements of
these two.  What is appropriate in one situation may not be appropriate
in others.

IF it's the case (and I emphasize the IF, there) that we're still trying
to answer the question above for all of the situations above, and write
a PKIX profile/successor to RFC 2459 that best supports those
situations, then I'll stick with my previous position:  the NR bit is
useful, and should be left in the PKIX profile. It's usefulness includes
at a minimum the ability for a CA to signal to a relying party that a
given certificate should NOT be used in a transaction requiring the
service of non-repudiation. 

If, however, there's something more under discussion, then I'm at a
loss, and I wish that somebody would explain it to me.

Lemme address a couple of the specific things that are causing me
confusion (large snips present below; my comments are prefaced by my
initials):


On the setting of the NR-bit without the explicit requesting of such by
a subscriber in an enrollment message:

> 
> So, if the subscriber did not explictly request that NR be turned on then
> I believe that consumer law will protect consumers from this about face
> overreaching by a business sector in a standard form contract that would
> have no alternative and no clear voluntary adhesion, all in detriment to the
> subscriber that was not physically present to even discuss the contract.
>

AWA:  Here's the situation:  a company builds an extranet for
communication with its subscribers/customers/contractors, using the
Internet as the transport mechanism and thus fulling under the PKIX
purview, if there is such a thing.  The company decides as a matter of
policy that all certs issued for the extranet will have the NR bit set,
because the company wishes to provide the service of non-repudiation in
its dealings.  On the paper forms, which users fill out to request
initialization into the system, users are told all about this.  Thus,
when the user later sends in the CMP or CMC request message for a
certificate, there is no indication about the setting of the NR bit. 
Such an indication is not needed.  I think that this is the case to
which Steve Kent was referring, and I think that the company's position
would have a chance of passing a court case.  Yes, in the case of public
TTP, the CA should not arbitrarily set bits without the user's being
aware of that, but remember that the public TTP is only one of the
situations we need to support.


 

> Not reverse, but correct the present reversion of cause and effect. The cause
> must be the subscriber right to choose to offer or deny NR in a message by
> message analysis conducted by the subscriber himself as a function of risk
> and cost, not the issuer's power to impose NR to all messages purportedly
> from a subscriber -- in bulk and for all risks.
> 

AWA:  I'm darned if I understand why having an NR bit turned on allows
an issuer to "impose NR to all messages purportedly from a subscriber --
in bulk and for all risks."  Yes, I guess that you could design a system
such that, if the NR bit was turned on in the subject's certificate, the
RP would automatically assume that the service of non-repudiation was
being provided.  Such a system would be horribly wrong, IMNSHO (and to
use Steve's "technical term").  There are far too many other
considerations, which are far beyond the scope of PKIX.  You have to do
the system engineering, or you ain't secure.

> > >In other words, the NR bit should be used to denote a service, never to
> > >provide it in any form (however weak).
> >
> > We agree that a bit cannot provide the service, just denote the suitability
> > of the certificate as a component of the service.
> 
> If we really agree, then we must agree that the NR bit cannot stand for
> any semantics in regard to NR -- it must be merely a pointer to indicate
> that a suitable NR service can be queried, which service can be denied
> or granted prior to the reliance act. Not always granted as nowadays.
> 

AWA:  I wish someone would point out the words in the PKIX documents
that say, "if the NR bit is on, then NR is automatically provided."  I
haven't found 'em, and I'd support their being changed.


> The tension between these two visions is perhaps the disconnect here.  Indeed, I am
> fixated (ie, focused) on the notion that NR is a liability to the subscriber and one
> which the subscriber must not be powerless to deny in a message by message case.
> And, more, I posit that if the subscriber is put in such a situation (ie, being powerless
> to deny for each case) then it will backfire and be nullified.
> 
> > >Note that the text above says that the subscriber could deny NR upon query
> > >but this only applies *before* the reliance act, not afterwards (ie, if NR is
> > >granted by thesubscriber for that act). Also note that the above mechanism
> > >eliminates the bulk NR aspect  of the present text (which binds NR to the cert,
> > >hence to all messages signed by that cert at all times) and allows NR to be
> > >managed per user and per message.
> > >

AWA:  Again, if there are words in the PKIX documents that say or
strongly imply that any transaction signed by a cert with the NR bit on
automatically comes with the service of NR, then those words should be
changed.  But I haven't found them.  Hey, I've been wrong before, I'm
willing to be shown what I've overlooked.  But, honestly, I can't see
this.



> 
> I am saying that the present text is not policy neutral because it imposes a
> NR policy.  Further, I am saying that this NR policy is not neutral because it
> imposes a liability which the subscriber is powerless to control.  For example,
> it is irrelevant whether the NR cert is used to sign a $50.00 or a $500.00
> contract, or whether the contract includes cascading risks -- the subscriber
> cannot vary its NR liability according to risk or even total its NR liability under
> a certain cap warranted by insurance. Thus, the PKIX spec became the NR
> policy and an unfair one. However, the "other side" can define the NR policy
> it wants for the transaction -- so that the seller may end up not liable at all
> for NR on the seller's obligations but the buyer may have to carry the
> burden of PKIX NR. At least, until the buyer consults a lawyer ;-)
>

AWA:  I'm dazed, confused, lost, and beating my head against the wall. 
I can't find any of this in the PKIX specs. All I can find is stuff
about asserting policies (which, btw, would cover the 50 vs. 500 above,
if you wanted it to), etc., which would seem to me to imply more control
over liability, not less. 
 

> I suggest that a study of Verisign's NetSure plan (for example) will
> reveal further weight to the notion that a party must not offer bulk NR
> or be forced into it as predicated in the PKIX spec for the nonRepudiation
> bit.  There are specific needs (including virus, cascading risks, etc.) that need
> to be taken into account by anyone offering to cover a risk. Which is what
> NR is all about -- eg, the risk that the cert subscriber may need to repudiate
> a transaction (for example, because the terms were not well understood at
> 03:00 AM or because a virus precluded him to read the full contract).  And,
> pushing for unfair NR in the PKIX spec itself will perhaps only serve to
> make CAs liable for it -- since adoption of PKIX is, after all, voluntary by
> each CA.
> 

AWA:  Okay, this doesn't help.  I've read everything on Verisign's web
site I could find about NetSure(sm).  (It's really cool.  I especially
like section 2.4, which says that if anybody comes up with a factoring
attack, and can thus deduce your private key given your public one in a
feasible amount of time, it means that you didn't adequately protect
your private key from compromise and they don't have to pay.  Neat - no
matter what happens, it's your fault.)  However, I didn't see anything
in those documents that relates to this discussion.  Verisign is simply
limiting its risk by stating the obvious: IF the subject hasn't cheated,
and IF the subject doesn't cheat in the future, and IF nobody figures
out a fast way to factor large numbers, and IF a bunch of other stuff
happens, then the system should work, and if they screw up, they'll pay
(maybe).  Of course they're not accepting liability as a CA for
everything that happens in the Internet - they'd be out of business by
next month if they did.

As I understand it from talking to lawyers (and I've done far too much
of that in the last 18 months, again IMNSHO), the situation that will
someday come up will be something like this: (I'm not a lawyer; if I get
this wrong, mea culpa, mea culpa, mea maxima culpa.)

	A certificate subject and a relying party (who relied on that
certificate in carrying out some transaction) go to court over that
transaction.  The relying party asserts that, based on the certificate
in question, other evidence it possesses, and the basic qualities of the
technology, the subject is the one who did something, and thus is
liable.  The certificate subject asserts that, due to some circumstance
and based on its own evidence (possibly even including its private key,
posted on a web site as the solution to an RSA-1024 factoring
challenge), it is not liable - perhaps this is all fraudulent activity
on the part of the relying party itself.  The question is:  whom does
the court believe, and how does it arrive at that belief?
That's going to be a hard question to resolve, especially the first
couple of times.  If the RP's evidence consists solely of the subject's
cert with the NR bit set, the RP is most likely going to lose.  If, on
the other hand, the subject shows that its cert had the NR bit off, and
the subject's CA asserts that that meant that this cert was never to
have been used in transactions that require the service of
non-repudiation, then I suspect that that's a strong point for the
subject.  It may be overcome by other evidence, but it's a starting
point.  
	

	That's my thoughts.  Any help here would be appreciated.

			Al Arsenault

-- my own opinions.  As if anybody - especially my employer - would
agree with them!!!


Received: from www.meridianus.com (209.249.223.20.has.no.reverse [209.249.223.20] (may be forged)) by mail.proper.com (8.9.3/8.9.3) with ESMTP id PAA14714 for <[e-mail]>; Tue, 10 Aug 1999 15:11:58 -0700 (PDT)
Received: from PC1 by www.meridianus.com (8.8.8+Sun/SMI-SVR4) id QAA02944; Tue, 10 Aug 1999 16:06:18 -0700 (PDT)
Message-ID: <001501bee37f$57660c90$[e-mail]>
From: "tog" <[e-mail]>
To: "Paul Koning" <[e-mail]>, <[e-mail]>
Cc: <[e-mail]>
References: <[e-mail]><[e-mail]> <[e-mail]>
Subject: Re: Lets Standardize Time Representation Formats!!!: WAS Re: New TSTTimedefinition
Date: Tue, 10 Aug 1999 15:26:07 -0700
Organization: Meridianus
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.2918.2701
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2918.2701

Paul,

SNIP

>
>  Daniel> Trust is the problem I envision.

Exactly!

>  Daniel> Who decides what your error
>  Daniel> factor is? If you trust me, you assume that my clock is set
>  Daniel> correctly and I'm not lying about the error factor with
>  Daniel> respect to some standard clock. Error factors depend on
>  Daniel> network speed, routes, and availability, the accuracy of the
>  Daniel> hardware clock, and so on. We could argue about the accuracy
>  Daniel> of every system out there, every network, and combination of
>  Daniel> such. Rather messy.

I think that the issue of the accuracy and services are specific to the
transaction types and the indemnity model that they support.

>
>  Daniel> The only surefire way to timestamp something is to have
>  Daniel> someone else do it, a trusted third party,

I disagree. The issue with timestamping is whether a system can be put in
place that the two parties that are doing a transaction agree upon. I think
that a certifieable timebase is really necessary for fully enabling digital
commerce, but if your doing simple one-sided transactions so to speak, that
is you at your browser doing some POS transaction, then a simple
timestamping system where the transaction happens and then there is a
secondary approval of the event stamping process seems to me like it would
eliminate the timebase credibility issues.

So if a simple acknowkledgement process, that the transaction was accepted
as it was logged, would eliminate the issues of the timebase for a number of
transaction models.

As a political statement regarding timestamping and those of us trying to
scratch out a living doing it, it seems to me that the real key to making
timestamping work is to bury it into other processes models, and not in
making it a stand alone system. The TTP model can more readily be
implemented as an application layered on an embedded system than as a core
'distributed' protocol, I think!.

>  Daniel> whom we assign the
>  Daniel> task of being the master timestamper. But that's rather
>  Daniel> impractical.
>
> I don't understand the issue.  The subject is trusted timestamping.

Paul, let me say that I believe that the real issue is the credibility of
the time data represented in the timestamp or other PKI services model. As a
second concern, there is how the timestamping process proves this
credibility some number of years later across stamps issued by different
servers..

> If you ask a server to put a signed timestamp on something, presumably
> you trust it to do that correctly.  "Correctly" includes putting on a
> proper value for accuracy

The idea is really simple. If the source of time is not credible and
referencable then why should anyone believe anything that is stamped with
timedata in it?.

The reality is that the timedata itself represents nothing more than a
monotonic incrementing serialization process, that is globally referencable.
What this provides theoretically is that multiple marks or events can be
accurately comparable to each other, but this is totally based in that the
timesense on System A is identical to that on System B and it just aint so.
The problem is that the current draft doesn't address this issue too well.

This is now, and has always been my primary objection to the current TS
Drafts. They assume that the TOD clocks and the services that make them up
are reliable and they may be.

Todd



Received: from mail.spyrus.com (mail.spyrus.com [207.212.34.20]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id OAA14202; Tue, 10 Aug 1999 14:36:43 -0700 (PDT)
Received: from rhousley_laptop.spyrus.com ([209.172.119.101]) by mail.spyrus.com (8.9.3/8.9.3) with ESMTP id OAA23933; Tue, 10 Aug 1999 14:31:34 -0700 (PDT)
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58 
Date: Tue, 10 Aug 1999 16:41:22 -0400
To: [e-mail], [e-mail]
From: Russ Housley <[e-mail]>
Subject: Five AES Candidates
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed

For those of you who have not heard, on Monday NIST announced the five
finalists for the Advanced Encryption Standard:

	MARS
	RC6
	Rijndael
	Serpent
	Twofish

More information is available at http://www.nist.gov/aes.



Received: from pub.siac.com (pub.siac.com [162.69.5.194]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id OAA13789 for <[e-mail]>; Tue, 10 Aug 1999 14:11:13 -0700 (PDT)
Received: from bigmouth.siac.com(162.69.5.8) by pub.siac.com via smap (4.1) id xma027579; Tue, 10 Aug 99 17:11:16 -0400
Received: from siac.com (localhost [127.0.0.1]) by charley.wisdom.siac.com (980427.SGI.8.8.8/980728.SGI.AUTOCF) via ESMTP id RAA56066; Tue, 10 Aug 1999 17:12:23 -0400 (EDT)
Sender: [e-mail]
Message-ID: <[e-mail]>
Date: Tue, 10 Aug 1999 17:12:23 -0400
From: Daniel Finkelstein <[e-mail]>
Organization: Securities Industry Automation Corporation
X-Mailer: Mozilla 4.61C-SGI [en] (X11; U; IRIX 6.5 IP32)
X-Accept-Language: en
MIME-Version: 1.0
To: Paul Koning <[e-mail]>
CC: [e-mail]
Subject: Re: Lets Standardize Time Representation Formats!!!: WAS Re: New  TSTTimedefinition
References: <[e-mail]> <[e-mail]> <[e-mail]>
Content-Type: multipart/alternative; boundary="------------C52556E2001D8891EB83A0B9"

--------------C52556E2001D8891EB83A0B9
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Paul Koning wrote:

> I don't understand the issue.  The subject is trusted timestamping.
> If you ask a server to put a signed timestamp on something, presumably
> you trust it to do that correctly.  "Correctly" includes putting on a
> proper value for accuracy.
>

I apologize if I was unclear; I agree with what you've said thus far.

>
> Network delays etc. are not an issue.  The timestamp reflects when the
> server acted on the request, i.e., after it got it and before it
> replied.   How long it took for the request to get there doesn't
> affect the accuracy of the timestamp.

> (If you care about establishing priority, you may need a server that
> you can reach with low latency.  For that matter, you'd want it to
> have good accuracy, and low processing delay also.)

That's what I was thinking about. Say two messages are sent from separate
systems at exactly the same time to a timestamp service; one may get a
timestamp that differs from the other. In the case of patent applications
and so on, this is of material consequence.

--
Daniel Alex Finkelstein
New Technologies
phone   [phone]
pager   917-427-1630
fax     [phone]
Securities Industry Automation Corporation



--------------C52556E2001D8891EB83A0B9
Content-Type: text/html; charset=us-ascii
Content-Transfer-Encoding: 7bit

<!doctype html public "-//w3c//dtd html 4.0 transitional//en">
<html>
Paul Koning wrote:
<blockquote TYPE=CITE>I don't understand the issue.&nbsp; The subject is
trusted timestamping.
<br>If you ask a server to put a signed timestamp on something, presumably
<br>you trust it to do that correctly.&nbsp; "Correctly" includes putting
on a
<br>proper value for accuracy.
<br>&nbsp;</blockquote>
I apologize if I&nbsp;was unclear; I agree with what you've said thus far.
<blockquote TYPE=CITE>&nbsp;
<br>Network delays etc. are not an issue.&nbsp; The timestamp reflects
when the
<br>server acted on the request, i.e., after it got it and before it
<br>replied.&nbsp;&nbsp; How long it took for the request to get there
doesn't
<br>affect the accuracy of the timestamp.</blockquote>

<blockquote TYPE=CITE>(If you care about establishing priority, you may
need a server that
<br>you can reach with low latency.&nbsp; For that matter, you'd want it
to
<br>have good accuracy, and low processing delay also.)</blockquote>
That's what I&nbsp;was thinking about. Say two messages are sent from separate
systems at exactly the same time to a timestamp service; one may get a
timestamp that differs from the other. In the case of patent applications
and so on, this is of material consequence.
<pre>--&nbsp;
Daniel Alex Finkelstein
New Technologies
phone&nbsp;&nbsp; 212-383-2951
pager&nbsp;&nbsp; 917-427-1630
fax&nbsp;&nbsp;&nbsp;&nbsp; 212-383-3289
Securities Industry Automation Corporation</pre>
&nbsp;</html>

--------------C52556E2001D8891EB83A0B9--



Received: from e1.ny.us.ibm.com (e2.ny.us.ibm.com [32.97.182.102]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id OAA13538 for <[e-mail]>; Tue, 10 Aug 1999 14:04:27 -0700 (PDT)
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 RAA156156; Tue, 10 Aug 1999 17:04:09 -0400
Received: from D51MTA05.pok.ibm.com (d51mta05.pok.ibm.com [9.117.200.33]) by northrelay02.pok.ibm.com (8.8.8m2/NCO v2.04) with SMTP id RAA156954; Tue, 10 Aug 1999 17:04:25 -0400
Received: by D51MTA05.pok.ibm.com(Lotus SMTP MTA v4.6.4  (830.2 3-23-1999))  id 852567C9.0073BD35 ; Tue, 10 Aug 1999 17:04:10 -0400
X-Lotus-FromDomain: IBMUS
To: "William Whyte" <[e-mail]>
cc: [e-mail], [e-mail]
Message-ID: <[e-mail]>
Date: Tue, 10 Aug 1999 17:02:57 -0400
Subject: RE: Lets Standardize Time Representation Formats!!!: WAS Re: New TSTTimedefinition
Mime-Version: 1.0
Content-type: text/plain; charset=us-ascii
Content-Disposition: inline

> The only thing missing from this is an indication of the accuracy
> of the time value.  This is easily accomplished by adding a field
> that indicates the accuracy.  So the resulting ASN.1 would look
> something like:
>
> TSTTime ::= SEQUENCE { genTime GeneralizedTime, errorFactor
> INTEGER DEFAULT 0 -- genTime is correct to within (2**errorFactor)
> of the actual time.  }

But surely, since GeneralizedTime contains a subsecond facility, we
can simply assume that the GeneralizedTime is accurate to the precision
given?

In other words: If errorFactor implies a greater precision than
is provided in genTime (for example, genTime provides time to 1/10th
of a second and and errorFactor implies precision to a microsecond)
then errorFactor cannot be trusted; If errorFactor implies a smaller
prcision than is provided in genTime, why not simply leave off the
trailing digits of genTime?; and if errorFactor implies an error of
more than a second, why would anyone use that TST?

[Tom Gindin]   This is where we started on this topic.  The DER standard (X.690
section 11.7.2) requires that trailing 0's be truncated from the fractional part
of a GeneralizedTime, and that the entire fractional part be omitted if it
consists of all 0's.  Therefore, inferring the precision from the value given
for GeneralizedTime will often (10% of the time for any precision closer than a
second) result in understating it by at least a factor of 10.

What actual purpose does errorFactor serve?

Cheers,

William





Received: from puma.baltimore.ie ([e-mail] [194.125.215.8]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id NAA13042 for <[e-mail]>; Tue, 10 Aug 1999 13:28:03 -0700 (PDT)
Received: by puma.baltimore.ie; id WAA12843; Tue, 10 Aug 1999 22:25:29 +0100 (GMT/IST)
Received: from bobcat.baltimore.ie(192.168.20.10) by puma.baltimore.ie via smap (4.1) id xma012810; Tue, 10 Aug 99 22:24:37 +0100
Received: from knuckle (knuckle.baltimore.ie [192.168.21.91]) by bobcat.baltimore.ie (8.9.3/8.9.3) with SMTP id VAA31227; Tue, 10 Aug 1999 21:28:41 +0100
From: "William Whyte" <[e-mail]>
To: <[e-mail]>
Cc: <[e-mail]>
Subject: RE: Lets Standardize Time Representation Formats!!!: WAS Re: New TSTTimedefinition
Date: Tue, 10 Aug 1999 21:27:22 +0100
Message-ID: <000601bee36e$c04be6a0$[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.2377.0
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3155.0
In-Reply-To: <[e-mail]>

> The only thing missing from this is an indication of the accuracy
> of the time value.  This is easily accomplished by adding a field
> that indicates the accuracy.  So the resulting ASN.1 would look
> something like:
> 
> TSTTime ::= SEQUENCE { genTime GeneralizedTime, errorFactor
> INTEGER DEFAULT 0 -- genTime is correct to within (2**errorFactor)
> of the actual time.  }
 
But surely, since GeneralizedTime contains a subsecond facility, we
can simply assume that the GeneralizedTime is accurate to the precision
given?

In other words: If errorFactor implies a greater precision than
is provided in genTime (for example, genTime provides time to 1/10th
of a second and and errorFactor implies precision to a microsecond)
then errorFactor cannot be trusted; If errorFactor implies a smaller
prcision than is provided in genTime, why not simply leave off the
trailing digits of genTime?; and if errorFactor implies an error of
more than a second, why would anyone use that TST?

What actual purpose does errorFactor serve?

Cheers,

William


Received: from wodc7-1.relay.mail.uu.net (wodc7-1.relay.mail.uu.net [199.171.54.114]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id MAA12616 for <[e-mail]>; Tue, 10 Aug 1999 12:57:51 -0700 (PDT)
Received: from xedia.com by wodc7mr0.ffx.ops.us.uu.net with SMTP  (peer crosschecked as: madway.xedia.com [198.202.232.199]) id QQhbrz26051; Tue, 10 Aug 1999 19:58:13 GMT
Received: from tonga.xedia.com by xedia.com (4.1/SMI-4.1) id AA05662; Tue, 10 Aug 99 15:56:47 EDT
Received: by tonga.xedia.com (SMI-8.6/SMI-SVR4) id PAA29448; Tue, 10 Aug 1999 15:58:12 -0400
Date: Tue, 10 Aug 1999 15:58:12 -0400
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: Lets Standardize Time Representation Formats!!!: WAS Re: New  TSTTimedefinition
References: <[e-mail]> <[e-mail]>
X-Mailer: VM 6.34 under 20.3 "Vatican City" XEmacs  Lucid

>>>>> "Daniel" == Daniel Finkelstein <[e-mail]> writes:

 Daniel> [e-mail] wrote:
 >> The only thing missing from this is an indication of the accuracy
 >> of the time value.  This is easily accomplished by adding a field
 >> that indicates the accuracy.  So the resulting ASN.1 would look
 >> something like:
 >> 
 >> TSTTime ::= SEQUENCE { genTime GeneralizedTime, errorFactor
 >> INTEGER DEFAULT 0 -- genTime is correct to within (2**errorFactor)
 >> of the actual time.  }
 >> 
 >> Thus the default accuracy would be 1 second.  More accurate time
 >> values would be indicated by a negative errorFactor, less accurate
 >> by a positive value.
 >> 
 >> Or since generalizedTime is a decimal representation, perhaps
 >> 10**errorFactor would be a better way of expressing the
 >> inaccuracy.

 Daniel> Trust is the problem I envision. Who decides what your error
 Daniel> factor is? If you trust me, you assume that my clock is set
 Daniel> correctly and I'm not lying about the error factor with
 Daniel> respect to some standard clock. Error factors depend on
 Daniel> network speed, routes, and availability, the accuracy of the
 Daniel> hardware clock, and so on. We could argue about the accuracy
 Daniel> of every system out there, every network, and combination of
 Daniel> such. Rather messy.

 Daniel> The only surefire way to timestamp something is to have
 Daniel> someone else do it, a trusted third party, whom we assign the
 Daniel> task of being the master timestamper. But that's rather
 Daniel> impractical.

I don't understand the issue.  The subject is trusted timestamping.
If you ask a server to put a signed timestamp on something, presumably 
you trust it to do that correctly.  "Correctly" includes putting on a
proper value for accuracy.

Network delays etc. are not an issue.  The timestamp reflects when the 
server acted on the request, i.e., after it got it and before it
replied.   How long it took for the request to get there doesn't
affect the accuracy of the timestamp.

(If you care about establishing priority, you may need a server that
you can reach with low latency.  For that matter, you'd want it to
have good accuracy, and low processing delay also.)

	paul


Received: from pub.siac.com (pub.siac.com [162.69.5.194]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id MAA12141 for <[e-mail]>; Tue, 10 Aug 1999 12:42:53 -0700 (PDT)
Received: from bigmouth.siac.com(162.69.5.8) by pub.siac.com via smap (4.1) id xma019475; Tue, 10 Aug 99 15:42:36 -0400
Received: from siac.com (localhost [127.0.0.1]) by charley.wisdom.siac.com (980427.SGI.8.8.8/980728.SGI.AUTOCF) via ESMTP id PAA55953 for <[e-mail]>; Tue, 10 Aug 1999 15:43:38 -0400 (EDT)
Sender: [e-mail]
Message-ID: <[e-mail]>
Date: Tue, 10 Aug 1999 15:43:38 -0400
From: Daniel Finkelstein <[e-mail]>
Organization: Securities Industry Automation Corporation
X-Mailer: Mozilla 4.61C-SGI [en] (X11; U; IRIX 6.5 IP32)
X-Accept-Language: en
MIME-Version: 1.0
To: [e-mail]
Subject: Re: language tags in PKIFreeText
References: <[e-mail]> <[e-mail]> <[e-mail]>
Content-Type: multipart/alternative; boundary="------------73405D5991468898E5D4AA69"

--------------73405D5991468898E5D4AA69
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Paul Koning wrote:

>  Maybe so, but maybe not.  Does it make matters significantly easier to
>
> deviate from the existing RFC and define a data type that is almost
> the same as something already defined but not quite, because it is
> subject to new limitations?
>
> "Free text" suggests that its use is pretty much open; that being the
> case it doesn't seem terribly useful to throw in new restrictions.

If I may offer an analogy, albeit an unusual one: when swimming freestyle
one traditionally chooses the crawl, but every so often you see a breast
stroke or something the athlete prefers. But it is assumed the crawl will
be done.

Free isn't necessarily free if traditional steps in, or peer pressure.

--
Daniel Alex Finkelstein
New Technologies
phone   [phone]
pager   917-427-1630
fax     [phone]
Securities Industry Automation Corporation



--------------73405D5991468898E5D4AA69
Content-Type: text/html; charset=us-ascii
Content-Transfer-Encoding: 7bit

<!doctype html public "-//w3c//dtd html 4.0 transitional//en">
<html>
Paul Koning wrote:
<blockquote TYPE=CITE>&nbsp;Maybe so, but maybe not.&nbsp; Does it make
matters significantly easier to
<br>deviate from the existing RFC and define a data type that is almost
<br>the same as something already defined but not quite, because it is
<br>subject to new limitations?
<p>"Free text" suggests that its use is pretty much open; that being the
<br>case it doesn't seem terribly useful to throw in new restrictions.</blockquote>
If I&nbsp;may offer an analogy, albeit an unusual one: when swimming freestyle
one traditionally chooses the crawl, but every so often you see a breast
stroke or something the athlete prefers. But it is assumed the crawl will
be done.
<p>Free isn't necessarily free if traditional steps in, or peer pressure.
<pre>--&nbsp;
Daniel Alex Finkelstein
New Technologies
phone&nbsp;&nbsp; 212-383-2951
pager&nbsp;&nbsp; 917-427-1630
fax&nbsp;&nbsp;&nbsp;&nbsp; 212-383-3289
Securities Industry Automation Corporation</pre>
&nbsp;</html>

--------------73405D5991468898E5D4AA69--



Received: from pub.siac.com (pub.siac.com [162.69.5.194]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id MAA11108 for <[e-mail]>; Tue, 10 Aug 1999 12:13:44 -0700 (PDT)
Received: from bigmouth.siac.com(162.69.5.8) by pub.siac.com via smap (4.1) id xma017286; Tue, 10 Aug 99 15:13:39 -0400
Received: from siac.com (localhost [127.0.0.1]) by charley.wisdom.siac.com (980427.SGI.8.8.8/980728.SGI.AUTOCF) via ESMTP id PAA55848 for <[e-mail]>; Tue, 10 Aug 1999 15:14:37 -0400 (EDT)
Sender: [e-mail]
Message-ID: <[e-mail]>
Date: Tue, 10 Aug 1999 15:14:37 -0400
From: Daniel Finkelstein <[e-mail]>
Organization: Securities Industry Automation Corporation
X-Mailer: Mozilla 4.61C-SGI [en] (X11; U; IRIX 6.5 IP32)
X-Accept-Language: en
MIME-Version: 1.0
To: [e-mail]
Subject: Re: Lets Standardize Time Representation Formats!!!: WAS Re: New  TSTTimedefinition
References: <[e-mail]>
Content-Type: multipart/alternative; boundary="------------69B7C59DF4BC97F2C8D43C3D"

--------------69B7C59DF4BC97F2C8D43C3D
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

[e-mail] wrote:

> The only thing missing from this is an indication of the accuracy of the
> time value.  This is easily accomplished by adding a field that indicates
> the accuracy.  So the resulting ASN.1 would look something like:
>
> TSTTime ::= SEQUENCE  {
>   genTime  GeneralizedTime,
>   errorFactor INTEGER DEFAULT 0
>   -- genTime is correct to within (2**errorFactor) of the actual time.
> }
>
> Thus the default accuracy would be 1 second.  More accurate time values
> would be indicated by a negative errorFactor, less accurate by a positive
> value.
>
> Or since generalizedTime is a decimal representation, perhaps
> 10**errorFactor would be a better way of expressing the inaccuracy.

This brings back memories of significant digits and the red grade marks next
to my pathetic attempts. I don't want to dwell too long on this topic:
10^errorFactor could be a large number, but it correlates with TCP timeouts
that are also geometric so I don't disagree with the equation in theory.

Trust is the problem I envision. Who decides what your error factor is? If
you trust me, you assume that my clock is set correctly and I'm not lying
about the error factor with respect to some standard clock. Error factors
depend on network speed, routes, and availability, the accuracy of the
hardware clock, and so on. We could argue about the accuracy of every system
out there, every network, and combination of such. Rather messy.

The only surefire way to timestamp something is to have someone else do it,
a trusted third party, whom we assign the task of being the master
timestamper. But that's rather impractical.

--
Daniel Alex Finkelstein
New Technologies
phone   [phone]
pager   917-427-1630
fax     [phone]
Securities Industry Automation Corporation



--------------69B7C59DF4BC97F2C8D43C3D
Content-Type: text/html; charset=us-ascii
Content-Transfer-Encoding: 7bit

<!doctype html public "-//w3c//dtd html 4.0 transitional//en">
<html>
[e-mail] wrote:
<blockquote TYPE=CITE>The only thing missing from this is an indication
of the accuracy of the
<br>time value.&nbsp; This is easily accomplished by adding a field that
indicates
<br>the accuracy.&nbsp; So the resulting ASN.1 would look something like:
<p>TSTTime ::= SEQUENCE&nbsp; {
<br>&nbsp; genTime&nbsp; GeneralizedTime,
<br>&nbsp; errorFactor INTEGER DEFAULT 0
<br>&nbsp; -- genTime is correct to within (2**errorFactor) of the actual
time.
<br>}
<p>Thus the default accuracy would be 1 second.&nbsp; More accurate time
values
<br>would be indicated by a negative errorFactor, less accurate by a positive
<br>value.
<p>Or since generalizedTime is a decimal representation, perhaps
<br>10**errorFactor would be a better way of expressing the inaccuracy.</blockquote>
This brings back memories of significant digits and the red grade marks
next to my pathetic attempts. I don't want to dwell too long on this topic:
10^errorFactor could be a large number, but it correlates with TCP timeouts
that are also geometric so I&nbsp;don't disagree with the equation in theory.
<p>Trust is the problem I envision. Who decides what your error factor
is? If you trust me, you assume that my clock is set correctly and I'm
not lying about the error factor with respect to some standard clock. Error
factors depend on network speed, routes, and availability, the accuracy
of the hardware clock, and so on. We could argue about the accuracy of
every system out there, every network, and combination of such. Rather
messy.
<p>The only surefire way to timestamp something is to have someone else
do it, a trusted third party, whom we assign the task of being the master
timestamper. But that's rather impractical.
<pre>--&nbsp;
Daniel Alex Finkelstein
New Technologies
phone&nbsp;&nbsp; 212-383-2951
pager&nbsp;&nbsp; 917-427-1630
fax&nbsp;&nbsp;&nbsp;&nbsp; 212-383-3289
Securities Industry Automation Corporation</pre>
&nbsp;</html>

--------------69B7C59DF4BC97F2C8D43C3D--



Received: from caladan.verisign.com (caladan.verisign.com [205.180.232.21]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id JAA09432 for <[e-mail]>; Tue, 10 Aug 1999 09:58:13 -0700 (PDT)
Received: from mentat.verisign.com by caladan.verisign.com (8.8.5/BCH1.5) id JAA09277; Tue, 10 Aug 1999 09:56:44 -0700 (PDT)
Received: from newman.verisign.com by mentat.verisign.com (8.8.5/BCH1.0) id JAA08984; Tue, 10 Aug 1999 09:58:03 -0700 (PDT)
Received: by newman.verisign.com with Internet Mail Service (5.5.2448.0) id <PQHGBTMD>; Tue, 10 Aug 1999 09:58:05 -0700
Message-ID: <[e-mail]>
From: Warwick Ford <[e-mail]>
To: "'[e-mail]'" <[e-mail]>
Subject: Progression of CMC
Date: Tue, 10 Aug 1999 09:57:55 -0700
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2448.0)
Content-Type: text/plain; charset="iso-8859-1"

It is now over 21 days since the 14-day WG Last Call on CMC was issued.

The only comments received were related to a thread initiated by Paul
Hoffman who suggested that we wait until there are 2 interoperable
conforming implementations before progressing CMC to Proposed Standard.
Paul's comment was motivated by concerns regarding the stability of the CMP
spec, in light of recent CMP interoperability trials.  While there was
general agreement that demonstrated interoperability is important, Paul's
concerns with CMP were largely refuted by CMP implementors.  

Since no-one contributing to that thread identified any problems with CMC
per se, since Paul's suggestion would imply us introducing a new procedural
requirement that goes beyond both usual IESG requirements and past PKIX WG
practice, and since the discussion on the thread did not represent any sort
of concensus that CMC should not progress, Steve and I believe that the WG
has finished its work on this specification.  Accordingly we shall now be
forwarding CMC to the IESG for standards track processing and IETF Last
Call.

Thanks to the editors for their extensive efforts in getting this
specification to this stage.

Warwick

---------------------------------------------------------------------
Warwick Ford, VeriSign, Inc., Tel [phone] x225; Fax [phone]
[e-mail];  301 Edgewater Pl, Suite 210, Wakefield, MA 01880
---------------------------------------------------------------------



Received: from arista.iris.com (arista.iris.com [198.112.211.22]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id GAA05832 for <[e-mail]>; Tue, 10 Aug 1999 06:57:06 -0700 (PDT)
From: [e-mail]
Subject: Re: Lets Standardize Time Representation Formats!!!: WAS Re: New TSTTime definition
To: [e-mail]
Cc: 
Date: Tue, 10 Aug 1999 09:56:52 -0400
Message-ID: <[e-mail]>
X-Priority: 3 (Normal)
X-MIMETrack: Serialize by Router on Arista/Iris(Build V5010621|June 21, 1999) at 08/10/99 09:57:31 AM
MIME-Version: 1.0
Content-type: text/plain; charset=us-ascii

Tom Gindin has already said this, but as it seems to have got lost, I'll
repeat it...

There is a desire to be able to express timestamp times to sub-second
precision, coupled with an indication of the accuracy of the time value.

GeneralizedTime already allows for arbitrary precision; why not use this
rather than trying to invent a new format?  It's trivial for
implementations to simply ignore trailing decimal digits if they only
require one-second precision.

The only thing missing from this is an indication of the accuracy of the
time value.  This is easily accomplished by adding a field that indicates
the accuracy.  So the resulting ASN.1 would look something like:


TSTTime ::= SEQUENCE  {
  genTime  GeneralizedTime,
  errorFactor INTEGER DEFAULT 0
  -- genTime is correct to within (2**errorFactor) of the actual time.
}

Thus the default accuracy would be 1 second.  More accurate time values
would be indicated by a negative errorFactor, less accurate by a positive
value.

Or since generalizedTime is a decimal representation, perhaps
10**errorFactor would be a better way of expressing the inaccuracy.

John



Received: from tomcat.sac.verio.net ([e-mail] [209.162.64.15]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id WAA16094 for <[e-mail]>; Mon, 9 Aug 1999 22:09:59 -0700 (PDT)
Received: from nma.com (pm02-16.sac.verio.net [209.162.64.35]) by tomcat.sac.verio.net (8.9.1a/8.9.1) with ESMTP id WAA24213; Mon, 9 Aug 1999 22:06:49 -0700 (PDT)
Message-ID: <[e-mail]>
Date: Mon, 09 Aug 1999 22:06:51 -0700
From: Ed Gerck <[e-mail]>
X-Mailer: Mozilla 4.51 [en]C-CCK-MCD {Sony}  (Win98; I)
X-Accept-Language: en
MIME-Version: 1.0
To: Stephen Kent <[e-mail]>
CC: Stephen Kent <[e-mail]>, "'[e-mail]'" <[e-mail]>
Subject: Re: Possible solution?, was Re: Non-Repudiation, was Re: Common   misconceptions, was Re: KISSfor   PKIX.   (Was: RE:ASN.1vs   XML     (usedto be RE: I-D 	ACTION 	 :draft-ietf-pkix-scvp-00.txt))
References: <v04020a07b3cf66fa3d68@[128.33.238.163]>			 <[e-mail]> <v04020a03b3d0a62117c1@[128.89.0.110]>	 <v04020a04b3d0c4b7d037@[128.89.0.110]> <v04020a08b3d1044e4f27@[128.89.0.110]> <v04020a01b3d4b44253ec@[128.33.238.250]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Stephen Kent wrote:

> Ed,
>
> > Stephen Kent wrote:
> >> A CA might offer a policy under which all users were issued signature certs
> >> with the NR bit on, but the users don't explicitly request it in such
> >> cases.
>
> Ed Gerck wrote:
> >You may recognize that such act has null validity in general -- since the
> >subscribers (ie, "users" as you call) would become liable for what they
> >did not explictly request.
>
> Note that I said the users did not "explicitly" request that NR be turned
> on.  That does not mean that the user is unaware that the bit has been
> turned on, e.g., it may be described in the CPS and thus considred an
> intrinsic part of having subscribed to the CA's service.

I noted that.  But, legislatures often disfavor provisions imposed on
consumers in standard form contracts if they believe that they will
result in unfairness. In California, for example, an agreement to conduct
a transaction electronically may not be contained in a standard form
contract that is not an electronic record, and an agreement in such a
standard form contract may not be conditioned upon an agreement
to conduct transactions electronically.  In most countries, consumer
laws also allow a period of at least seven days for a consumer to
repudiate any transaction for which the consumer was not physically
present (eg, phone orders, Internet orders).

So, if the subscriber did not explictly request that NR be turned on then
I believe that consumer law will protect consumers from this about face
overreaching by a business sector in a standard form contract that would
have no alternative and no clear voluntary adhesion, all in detriment to the
subscriber that was not physically present to even discuss the contract.

> >The main difference point may be summarized by saying that a NR certificate:
> >
> >- should merely define that a NR service is available in a suitable query,
>
> NR is a service that requires certain actions on the part of an RP, perhaps
> requiring one or more queries to various servers, but not always.

I posit that challenge-response (again, not necessarily cryptographic) is
a sine qua non condition for any form of NR.  This statement can be reviewed
in my previous postings and is based on a quite general formal modeling.

> >- should not attempt to provide NR, neither by declaring that the message
> >signed with that NR cert is non-repudiable by itself nor by declaring that the
> >messagewas signed with an intent of NR.
>
> The second piint is precisley why the bit is included, so I doubt that we
> would reverse the semantics based on your suggestion.

Not reverse, but correct the present reversion of cause and effect. The cause
must be the subscriber right to choose to offer or deny NR in a message by
message analysis conducted by the subscriber himself as a function of risk
and cost, not the issuer's power to impose NR to all messages purportedly
from a subscriber -- in bulk and for all risks.

> >In other words, the NR bit should be used to denote a service, never to
> >provide it in any form (however weak).
>
> We agree that a bit cannot provide the service, just denote the suitability
> of the certificate as a component of the service.

If we really agree, then we must agree that the NR bit cannot stand for
any semantics in regard to NR -- it must be merely a pointer to indicate
that a suitable NR service can be queried, which service can be denied
or granted prior to the reliance act. Not always granted as nowadays.

> >This could be expressed for example as:
> >
> > 1. A certificate that sets the nonRepudiation bit also implictly defines
> >where  the non-repudiation service is provided, which MUST be:
> >    1.a. by the issuer if the certificate is self-signed, or otherwise,
> >    1.b. as regulated in the CPS.
>
> Becuase multiple servers may be required to provide NR (e.g., a TSA, a
> directory, etc.) I don't think "1.a" is quite right.

If the certificate is self-signed, the logic is that the issuer can define
by itself if and where such multiple servers may be required -- since
the issuer is identical to the subject and there is no division of powers
or liability between issuer and subject.  This may also preclude the need
for an extensive CPS.  In this case, the NR argument goes inductively
from the issuer to the subject because it was the subject that initially caused
the certificate to be authoritatively self-signed at one past point in time.

> >Which would solve IMO the power/liability problem because the subscriber
> >would always have the power to deny NR upon query (even if done indirectly
> >through a CA) -- and  the r-p would also know where to query, who is
> >responsible for what NR aspect (there may be many, with one entity answering
> >for each aspect, for example in time NR, policy NR, etc.) and in what terms,
> >*before* deciding to rely on the liability implied by the NR service.
>
> You seem to be fixated on this notion of a query involving the subscriber
> or CA, neither of which is intrinsic to NR.

What you tend to call NR is IMO actually an act of information control from the
CA over the subscriber -- and that is why IMO you see no need for a query
over a matter already decided.  But, if you really agree that "a [NR] bit cannot
provide the service, just denote the suitability of the certificate as a component
of the service" as you wrote above then you must also agree that the NR service
must be provided elsewhere -- ie, when a client queries a server or a list of
servers (TSAs, etc.).

The tension between these two visions is perhaps the disconnect here.  Indeed, I am
fixated (ie, focused) on the notion that NR is a liability to the subscriber and one
which the subscriber must not be powerless to deny in a message by message case.
And, more, I posit that if the subscriber is put in such a situation (ie, being powerless
to deny for each case) then it will backfire and be nullified.

> >Note that the text above says that the subscriber could deny NR upon query
> >but this only applies *before* the reliance act, not afterwards (ie, if NR is
> >granted by thesubscriber for that act). Also note that the above mechanism
> >eliminates the bulk NR aspect  of the present text (which binds NR to the cert,
> >hence to all messages signed by that cert at all times) and allows NR to be
> >managed per user and per message.
> >
> >> In general, PKIX tries to be policy neutral.
> >
> >And that is what it is not, by setting a policy for *key usage*. Which, BTW,
> >allows an issuer to unilaterally impose a liability upon a subscriber in
> >regard to all relying-parties at all times -- even if the subscriber does not
> >request  or know about it.
>
> There is a difference between the spec being policy neutral and between the
> spec providing a means for a cert issuer to express policy.  I think you
> are confusing the two here.

I am saying that the present text is not policy neutral because it imposes a
NR policy.  Further, I am saying that this NR policy is not neutral because it
imposes a liability which the subscriber is powerless to control.  For example,
it is irrelevant whether the NR cert is used to sign a $50.00 or a $500.00
contract, or whether the contract includes cascading risks -- the subscriber
cannot vary its NR liability according to risk or even total its NR liability under
a certain cap warranted by insurance. Thus, the PKIX spec became the NR
policy and an unfair one. However, the "other side" can define the NR policy
it wants for the transaction -- so that the seller may end up not liable at all
for NR on the seller's obligations but the buyer may have to carry the
burden of PKIX NR. At least, until the buyer consults a lawyer ;-)

> >> >> So, I don't envision any change to the text.
> >> >
> >> >Is this a matter of consensus? Or, sensus?
> >>
> >> My dictionary does not contain an entry for "sensus," so I'll have to pass
> >> on that one.
> >
> >Maybe the lawyers in this list can answer that to you for a change ;-) but
> >"sensus" is Latin for feeling or perception -- ie, "personal sense" in
> >English.
> >Not to be confused with census, neither as voting nor as censorship.
> >
> >My phrase simply asked whether your position is a matter of consensus
> >(collective agreement) or  sensus (personal feeling).
> >
> >In regard to NR you may however note that even if PKIX does not change
> >its text, the beans are already out.   The archived exchanges in this list and
> >your own bit by bit agreement that setting the nonRepudiation bit is neither
> >necessary nor sufficient for NR already provides IMO enough grounds for
> >legal and technical repudiation of the whole concept as currently stated in
> >the PKIX text.
>
> Thanks for sharing your opinion on this topic.

I suggest that a study of Verisign's NetSure plan (for example) will
reveal further weight to the notion that a party must not offer bulk NR
or be forced into it as predicated in the PKIX spec for the nonRepudiation
bit.  There are specific needs (including virus, cascading risks, etc.) that need
to be taken into account by anyone offering to cover a risk. Which is what
NR is all about -- eg, the risk that the cert subscriber may need to repudiate
a transaction (for example, because the terms were not well understood at
03:00 AM or because a virus precluded him to read the full contract).  And,
pushing for unfair NR in the PKIX spec itself will perhaps only serve to
make CAs liable for it -- since adoption of PKIX is, after all, voluntary by
each CA.

Cheers,

Ed Gerck



Received: from po1.bbn.com (PO1.BBN.COM [192.1.50.38]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id TAA03302 for <[e-mail]>; Mon, 9 Aug 1999 19:39:43 -0700 (PDT)
Received: from [128.33.238.19] (TC019.BBN.COM [128.33.238.19]) by po1.bbn.com (8.9.1/8.9.1) with ESMTP id WAA19395; Mon, 9 Aug 1999 22:39:55 -0400 (EDT)
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
X-Sender: [e-mail] (Unverified)
Message-Id: <v04020a01b3d4b44253ec@[128.33.238.250]>
In-Reply-To: <[e-mail]>
References: <v04020a07b3cf66fa3d68@[128.33.238.163]>			 <[e-mail]> <v04020a03b3d0a62117c1@[128.89.0.110]>	 <v04020a04b3d0c4b7d037@[128.89.0.110]> <v04020a08b3d1044e4f27@[128.89.0.110]>
Date: Mon, 9 Aug 1999 13:20:32 -0400
To: Ed Gerck <[e-mail]>
From: Stephen Kent <[e-mail]>
Subject: Re: Possible solution?, was Re: Non-Repudiation, was Re: Common   misconceptions, was Re: KISSfor   PKIX.   (Was: RE:ASN.1vs   XML     (usedto be RE: I-D 	ACTION 	 :draft-ietf-pkix-scvp-00.txt))
Cc: Stephen Kent <[e-mail]>, "'[e-mail]'" <[e-mail]>

Ed,

>> A CA might offer a policy under which all users were issued signature certs
>> with the NR bit on, but the users don't explicitly request it in such
>> cases.
>
>You may recognize that such act has null validity in general -- since the
>subscribers
>(ie, "users" as you call) would become liable for what they did not
>explictly request.

Note that I said the users did not "explicitly" request that NR be turned
on.  That does not mean that the user is unaware that the bit has been
turned on, e.g., it may be described in the CPS and thus considred an
intrinsic part of having subscribed to the CA's service.

>The main difference point may be summarized by saying that a NR certificate:
>
>- should merely define that a NR service is available in a suitable query,

NR is a service that requires certain actions on the part of an RP, perhaps
requiring one or more queries to various servers, but not always.

>- should not attempt to provide NR, neither by declaring that the message
>signed
>with that NR cert is non-repudiable by itself nor by declaring that the
>message
>was signed with an intent of NR.

The second piint is precisley why the bit is included, so I doubt that we
would reverse the semantics based on your suggestion.

>In other words, the NR bit should be used to denote a service, never to
>provide it in any form (however weak).

We agree that a bit cannot provide the service, just denote the suitability
of the certificate as a component of the service.

>This could be expressed for example as:
>
> 1. A certificate that sets the nonRepudiation bit also implictly defines
>where
>     the non-repudiation service is provided, which MUST be:
>    1.a. by the issuer if the certificate is self-signed, or otherwise,
>    1.b. as regulated in the CPS.

Becuase multiple servers may be required to provide NR (e.g., a TSA, a
directory, etc.) I don't think "1.a" is quite right.

>Which would solve IMO the power/liability problem because the subscriber
>would always have the power to deny NR upon query (even if done indirectly
>through
>a CA) -- and  the r-p would also know where to query, who is responsible
>for what
>NR aspect (there may be many, with one entity answering for each aspect,
>for example
>in time NR, policy NR, etc.) and in what terms, *before* deciding to rely
>on the liability
>implied by the NR service.

You seem to be fixated on this notion of a query involving the subscriber
or CA, neither of which is intrinsic to NR.

>Note that the text above says that the subscriber could deny NR upon query
>but this
>only applies *before* the reliance act, not afterwards (ie, if NR is
>granted by the
>subscriber for that act). Also note that the above mechanism eliminates
>the bulk NR
>aspect  of the present text (which binds NR to the cert, hence to all
>messages signed
>by that cert at all times) and allows NR to be managed per user and per
>message.
>
>> In general, PKIX tries to be policy neutral.
>
>And that is what it is not, by setting a policy for *key usage*. Which, BTW,
>allows an issuer to unilaterally impose a liability upon a subscriber in
>regard to
>all relying-parties at all times -- even if the subscriber does not
>request  or
>know about it.

There is a difference between the spec being policy neutral and between the
spec providing a means for a cert issuer to express policy.  I think you
are confusing the two here.

>> >> So, I don't envision any change to the text.
>> >
>> >Is this a matter of consensus? Or, sensus?
>>
>> My dictionary does not contain an entry for "sensus," so I'll have to pass
>> on that one.
>
>Maybe the lawyers in this list can answer that to you for a change ;-) but
>"sensus" is Latin for feeling or perception -- ie, "personal sense" in
>English.
>Not to be confused with census, neither as voting nor as censorship.
>
>My phrase simply asked whether your position is a matter of consensus
>(collective agreement) or  sensus (personal feeling).
>
>In regard to NR you may however note that even if PKIX does not change
>its text, the beans are already out.   The archived exchanges in this list and
>your own bit by bit agreement that setting the nonRepudiation bit is neither
>necessary nor sufficient for NR already provides IMO enough grounds for
>legal and technical repudiation of the whole concept as currently stated in
>the PKIX text.

Thanks for sharing your opinion on this topic.

Steve


Received: from caladan.verisign.com (caladan.verisign.com [205.180.232.21]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id OAA15096 for <[e-mail]>; Mon, 9 Aug 1999 14:20:52 -0700 (PDT)
Received: from mentat.verisign.com by caladan.verisign.com (8.8.5/BCH1.5) id OAA17061; Mon, 9 Aug 1999 14:19:19 -0700 (PDT)
Received: from newman.verisign.com by mentat.verisign.com (8.8.5/BCH1.0) id OAA10844; Mon, 9 Aug 1999 14:20:39 -0700 (PDT)
Received: by newman.verisign.com with Internet Mail Service (5.5.2448.0) id <PQHGB3V2>; Mon, 9 Aug 1999 14:20:41 -0700
Message-ID: <[e-mail]>
From: Warwick Ford <[e-mail]>
To: "'[e-mail]'" <[e-mail]>
Subject: LAST CALL:draft-ietf-pkix-qc-01.txt
Date: Mon, 9 Aug 1999 14:20:32 -0700 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2448.0)
Content-Type: text/plain; charset="iso-8859-1"

The Qualified Certificates draft is issued for 14-day WG Last Call.

-----Original Message-----
From: [e-mail] [mailto:[e-mail]] 
Sent: Monday, August 09, 1999 4:24 AM
To: IETF-Announce; @imc.org
Cc: [e-mail]
Subject: I-D ACTION:draft-ietf-pkix-qc-01.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		: Internet X.509 Public Key Infrastructure Qualified

                          Certificates Profile
	Author(s)	: S. Santesson, W. Polk,  P. Gloeckner
	Filename	: draft-ietf-pkix-qc-01.txt
	Pages		: 33
	Date		: 06-Aug-99
	
This Internet-Draft forms a certificate profile for Qualified
Certificates, based on RFC 2459, for use in the Internet. The term
Qualified Certificate is used to describe a certificate with a
certain qualified status within applicable governing law. Further
Qualified Certificates are issued exclusively to physical persons
represented by a registered unmistakable identity.
The goal of this document is to define a general syntax independent
of local legal requirements. The profile is however designed to allow
further profiling in order to meet specific local needs.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-pkix-qc-01.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-qc-01.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-qc-01.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 gandalf.trustpoint.com (IDENT:[e-mail] [216.100.231.61]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id MAA13509 for <[e-mail]>; Mon, 9 Aug 1999 12:03:48 -0700 (PDT)
Received: from ronald.trustpoint.com (ronald@ronald [192.168.42.4]) by gandalf.trustpoint.com (8.8.7/8.8.7) with ESMTP id MAA02638; Mon, 9 Aug 1999 12:04:06 -0700
From: Ronald Tschalär <[e-mail]>
Received: (from ronald@localhost) by ronald.trustpoint.com (8.8.7/8.8.7) id MAA01597; Mon, 9 Aug 1999 12:04:05 -0700
Message-Id: <[e-mail]>
Subject: Re: language tags in PKIFreeText
To: [e-mail] (Paul Koning)
Date: Mon, 9 Aug 1999 12:04:05 -0700 (PDT)
Cc: [e-mail]
In-Reply-To: <[e-mail]> from "Paul Koning" at Aug 9, 99 09:52:07 am
Content-Type: text

>  > Looking 2482, it allows any number of tags anywhere in the
>  > text. For PKIFreeText it seems to me that one tag per string,
>  > located at the beginning, should suffice. 
> 
> Maybe so, but maybe not.  Does it make matters significantly easier to 
> deviate from the existing RFC and define a data type that is almost
> the same as something already defined but not quite, because it is
> subject to new limitations?

First, given that PKIFreeText is defined as a *sequence of* UTF8String,
and given the texts

         -- text encoded as UTF-8 String (note:  each UTF8String SHOULD
         -- include an RFC 1766 language tag to indicate the language
         -- of the contained text)

and 

   The freeText field may be used to send a human-readable message to
   the recipient (in any number of languages).  The first language used
   in this sequence indicates the desired language for replies.

this seemed to imply that the intent was one language per string. However,
that is not specified anywhere. So, if the spec allows any number of tags
anywhere in the strings then the following questions arise:

  - What if the first string contains a language tag in the middle of
    the string - is the "first language used" the default language assigned
    to the text before the language tag (which is presumably whatever
    language the client happens to choose as default), or is it that of
    the first language tag? I presume the former?

  - Is there any reason to ever include more than one string? After all,
    you can just create one string with all the languages separated by
    the language tags.
    
And yes, the handling becomes easier if it's one language tag per string
at the beginning, but it's not like a full free-format is impossible to
implement.

> "Free text" suggests that its use is prety much open; that being the
> case it doesn't seem terribly useful to throw in new restrictions.

I was just trying to nail down what I thought was the intent. Maybe I
just read too much into those sentences.


  Cheers,

  Ronald



Received: from wodc7-1.relay.mail.uu.net (wodc7-1.relay.mail.uu.net [199.171.54.114]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id GAA10549 for <[e-mail]>; Mon, 9 Aug 1999 06:51:50 -0700 (PDT)
Received: from xedia.com by wodc7mr0.ffx.ops.us.uu.net with SMTP  (peer crosschecked as: madway.xedia.com [198.202.232.199]) id QQhbnj00089 for <[e-mail]>; Mon, 9 Aug 1999 13:52:08 GMT
Received: from tonga.xedia.com by xedia.com (4.1/SMI-4.1) id AA13697; Mon, 9 Aug 99 09:50:42 EDT
Received: by tonga.xedia.com (SMI-8.6/SMI-SVR4) id JAA21958; Mon, 9 Aug 1999 09:52:07 -0400
Date: Mon, 9 Aug 1999 09:52:07 -0400
Message-Id: <[e-mail]>
From: Paul Koning <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
To: (Unparsable address -- Strange character or missing comma: "Ronald Tschal_^_\\dr <\\@[e-mail]>") madway!@[e-mail]
Cc: [e-mail]
Subject: Re: language tags in PKIFreeText
References: <[e-mail]> <[e-mail]>
X-Mailer: VM 6.34 under 20.3 "Vatican City" XEmacs  Lucid
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by mail.proper.com id GAA10550

 > Paul Hoffman wrote:
 >>  At 02:18 PM 8/7/1999 -0700, Ronald Tschalär wrote:
 >> 
 >> >The definition of PKIFreeText in RFC-2510 says: > > PKIFreeText
 >> ::= SEQUENCE SIZE (1..MAX) OF UTF8String > -- text encoded as
 >> UTF-8 String (note: each UTF8String SHOULD > -- include an RFC
 >> 1766 language tag to indicate the language > -- of the contained
 >> text) > >Unfortunately, I could find no hint as to *how* the
 >> language tag should >be included (RFC-1766 only defines the tags
 >> themselves and a Content-Language >header for MIME-like
 >> structures). I presume the idea is that the string >start off with
 >> "<lang-tag>:" followed by the actual text?
 >> 
 >> I don't think so. Embedding language tags in Unicode (of which
 >> UTF-8 is a transformation) is described in RFC 2482. This is the
 >> method that is expected to be used in all Unicode text that will
 >> contain language tags.

 > Ah, wasn't aware of that spec. Maybe a refernce to it should
 > be included in the above text.

 > Looking 2482, it allows any number of tags anywhere in the
 > text. For PKIFreeText it seems to me that one tag per string,
 > located at the beginning, should suffice. 

Maybe so, but maybe not.  Does it make matters significantly easier to 
deviate from the existing RFC and define a data type that is almost
the same as something already defined but not quite, because it is
subject to new limitations?

"Free text" suggests that its use is pretty much open; that being the
case it doesn't seem terribly useful to throw in new restrictions.

	paul



Received: from ietf.org (odin.ietf.org [132.151.1.176]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id EAA08816 for <[e-mail]>; Mon, 9 Aug 1999 04:24:13 -0700 (PDT)
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA00867; Mon, 9 Aug 1999 07:23:57 -0400 (EDT)
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-qc-01.txt
Date: Mon, 09 Aug 1999 07:23:57 -0400
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		: Internet X.509 Public Key Infrastructure Qualified 
                          Certificates Profile
	Author(s)	: S. Santesson, W. Polk,  P. Gloeckner
	Filename	: draft-ietf-pkix-qc-01.txt
	Pages		: 33
	Date		: 06-Aug-99
	
This Internet-Draft forms a certificate profile for Qualified
Certificates, based on RFC 2459, for use in the Internet. The term
Qualified Certificate is used to describe a certificate with a
certain qualified status within applicable governing law. Further
Qualified Certificates are issued exclusively to physical persons
represented by a registered unmistakable identity.
The goal of this document is to define a general syntax independent
of local legal requirements. The profile is however designed to allow
further profiling in order to meet specific local needs.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-pkix-qc-01.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-qc-01.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-qc-01.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-qc-01.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-pkix-qc-01.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

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

--OtherAccess--

--NextPart--




Received: from gandalf.trustpoint.com (IDENT:[e-mail] [216.100.231.61]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id VAA19199; Sat, 7 Aug 1999 21:24:43 -0700 (PDT)
Received: from ronald.trustpoint.com (ronald@ronald [192.168.42.4]) by gandalf.trustpoint.com (8.8.7/8.8.7) with ESMTP id VAA31683; Sat, 7 Aug 1999 21:24:54 -0700
From: Ronald Tschalär <[e-mail]>
Received: (from ronald@localhost) by ronald.trustpoint.com (8.8.7/8.8.7) id VAA00926; Sat, 7 Aug 1999 21:24:52 -0700
Message-Id: <[e-mail]>
Subject: Re: language tags in PKIFreeText
To: [e-mail] (Paul Hoffman / IMC)
Date: Sat, 7 Aug 1999 21:24:52 -0700 (PDT)
Cc: [e-mail]
In-Reply-To: <[e-mail]> from "Paul Hoffman / IMC" at Aug 7, 99 06:32:26 pm
Content-Type: text

> At 05:07 PM 8/7/1999 -0700, Ronald Tschalär wrote:
> >      PKIFreeText ::= SEQUENCE SIZE (1..MAX) OF UTF8String
> >          -- text encoded as UTF-8 String (note:  each UTF8String SHOULD
> >          -- include a single RFC 1766 language tag, as specified in RFC
> >         -- 2482, located at the beginning of the string, to indicate
> >         -- the language of the contained text)
> 
> I see three problems with this:
[snip]
> - There are a fair number of people in the Unicode community who do not 
> think much of language tagging; they consider it unneeded overhead that is 
> rarely of value. Language tags are really only of value on text that will 
> be machine-processed. Unfortunately, it is impossible to determine this 
> ahead of time in most cases. For instance, PKIFreeText is meant to be read 
> *by* a human, so the language tag is superfluous (either the human 
> understands the language, or they don't). However, if that text is read 
> *to* a human, such as by a text speaking program, then the language tag can 
> be very valuable.

I disagree with this. The spec says further down that:

   The freeText field may be used to send a human-readable message to
   the recipient (in any number of languages).  The first language used
   in this sequence indicates the desired language for replies.

In other words you get a list of languages, and the client can then
choose most suitable for display according to the clients preferences
or environment. I.e. PKIFreeText is much like multipart/alternative.
So labeling the individual variants is useful and neccessary.

> I apologize for not having seen this in the CMP drafts; otherwise, I would 
> have suggested that it be changed to a MAY or dropped altogether. Any UTF-8 
> reader should be able to handle language tags just fine if they are in the 
> text; nothing special is needed.

Ok, so I'm confused. Are you refering to some other way of embeding
language tags in the text?


  Cheers,

  Ronald



Received: from tomcat.sac.verio.net ([e-mail] [209.162.64.15]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id UAA12176 for <[e-mail]>; Sat, 7 Aug 1999 20:13:34 -0700 (PDT)
Received: from nma.com (pm09-23.sac.verio.net [209.162.65.136]) by tomcat.sac.verio.net (8.9.1a/8.9.1) with ESMTP id UAA28348; Sat, 7 Aug 1999 20:13:42 -0700 (PDT)
Message-ID: <[e-mail]>
Date: Sat, 07 Aug 1999 20:13:43 -0700
From: Ed Gerck <[e-mail]>
X-Mailer: Mozilla 4.51 [en]C-CCK-MCD {Sony}  (Win98; I)
X-Accept-Language: en
MIME-Version: 1.0
To: Stephen Kent <[e-mail]>
CC: "'[e-mail]'" <[e-mail]>
Subject: Re: Possible solution?, was Re: Non-Repudiation, was Re: Common   misconceptions, was Re: KISSfor   PKIX.   (Was: RE:ASN.1vs   XML    (usedto be RE: I-D 	ACTION 	 :draft-ietf-pkix-scvp-00.txt))
References: <v04020a07b3cf66fa3d68@[128.33.238.163]>		 <[e-mail]> <v04020a03b3d0a62117c1@[128.89.0.110]> <v04020a04b3d0c4b7d037@[128.89.0.110]> <v04020a08b3d1044e4f27@[128.89.0.110]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Stephen Kent wrote:

> Ed,
>
> >Can you pls exemplify what CA policies would be both precluded and yet useful
> >for NR, by following either usage above: (i) MUST; and (ii) SHOULD NOT?
>
> A CA might offer a policy under which all users were issued signature certs
> with the NR bit on, but the users don't explicitly request it in such
> cases.

You may recognize that such act has null validity in general -- since the subscribers
(ie, "users" as you call) would become liable for what they did not explictly request.

The main difference point may be summarized by saying that a NR certificate:

- should merely define that a NR service is available in a suitable query,

- should not attempt to provide NR, neither by declaring that the message signed
with that NR cert is non-repudiable by itself nor by declaring that the message
was signed with an intent of NR.

In other words, the NR bit should be used to denote a service, never to
provide it in any form (however weak).

This could be expressed for example as:

 1. A certificate that sets the nonRepudiation bit also implictly defines where
     the non-repudiation service is provided, which MUST be:
    1.a. by the issuer if the certificate is self-signed, or otherwise,
    1.b. as regulated in the CPS.

Which would solve IMO the power/liability problem because the subscriber
would always have the power to deny NR upon query (even if done indirectly through
a CA) -- and  the r-p would also know where to query, who is responsible for what
NR aspect (there may be many, with one entity answering for each aspect, for example
in time NR, policy NR, etc.) and in what terms, *before* deciding to rely on the liability
implied by the NR service.

Note that the text above says that the subscriber could deny NR upon query but this
only applies *before* the reliance act, not afterwards (ie, if NR is granted by the
subscriber for that act). Also note that the above mechanism eliminates the bulk NR
aspect  of the present text (which binds NR to the cert, hence to all messages signed
by that cert at all times) and allows NR to be managed per user and per message.

> In general, PKIX tries to be policy neutral.

And that is what it is not, by setting a policy for *key usage*. Which, BTW,
allows an issuer to unilaterally impose a liability upon a subscriber in regard to
all relying-parties at all times -- even if the subscriber does not request  or
know about it.

> >> So, I don't envision any change to the text.
> >
> >Is this a matter of consensus? Or, sensus?
>
> My dictionary does not contain an entry for "sensus," so I'll have to pass
> on that one.

Maybe the lawyers in this list can answer that to you for a change ;-) but
"sensus" is Latin for feeling or perception -- ie, "personal sense" in English.
Not to be confused with census, neither as voting nor as censorship.

My phrase simply asked whether your position is a matter of consensus
(collective agreement) or  sensus (personal feeling).

In regard to NR you may however note that even if PKIX does not change
its text, the beans are already out.   The archived exchanges in this list and
your own bit by bit agreement that setting the nonRepudiation bit is neither
necessary nor sufficient for NR already provides IMO enough grounds for
legal and technical repudiation of the whole concept as currently stated in
the PKIX text.

Cheers,

Ed Gerck



Received: from aum (ip11.proper.com [165.227.249.11]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id SAA29298; Sat, 7 Aug 1999 18:33:14 -0700 (PDT)
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58 
Date: Sat, 07 Aug 1999 18:32:26 -0700
To: Ronald =?iso-8859-1?Q?Tschal=E4r?= <[e-mail]>, [e-mail]
From: Paul Hoffman / IMC <[e-mail]>
Subject: Re: language tags in PKIFreeText
In-Reply-To: <[e-mail]>
References: <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"; format=flowed
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by mail.proper.com id SAA29303

At 05:07 PM 8/7/1999 -0700, Ronald Tschalär wrote:
>      PKIFreeText ::= SEQUENCE SIZE (1..MAX) OF UTF8String
>          -- text encoded as UTF-8 String (note:  each UTF8String SHOULD
>          -- include a single RFC 1766 language tag, as specified in RFC
>         -- 2482, located at the beginning of the string, to indicate
>         -- the language of the contained text)

I see three problems with this:

- RFC 2482 is an Informational RFC, and therefore there cannot have a 
normative reference to it in a standards-track RFC

- There are a fair number of people in the Unicode community who do not 
think much of language tagging; they consider it unneeded overhead that is 
rarely of value. Language tags are really only of value on text that will 
be machine-processed. Unfortunately, it is impossible to determine this 
ahead of time in most cases. For instance, PKIFreeText is meant to be read 
*by* a human, so the language tag is superfluous (either the human 
understands the language, or they don't). However, if that text is read 
*to* a human, such as by a text speaking program, then the language tag can 
be very valuable.

- Language tags in UTF-8 come out really long, like about 28 octets on 
average, due to their position in the character set (way out in plane 14).

I apologize for not having seen this in the CMP drafts; otherwise, I would 
have suggested that it be changed to a MAY or dropped altogether. Any UTF-8 
reader should be able to handle language tags just fine if they are in the 
text; nothing special is needed. This SHOULD may get dropped when going 
from Proposed to Draft Standard unless two implementations both use them in 
a noticeable way, which seems unlikely.

(Folks interested in IETF and internationalization, at least as it affects 
Internet mail, can find lots of information and pointers to RFCs at 
<http://www.imc.org/imc-intl/>.)

--Paul Hoffman, Director
--Internet Mail Consortium


Received: from gandalf.trustpoint.com (IDENT:[e-mail] [216.100.231.61]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id RAA22394 for <[e-mail]>; Sat, 7 Aug 1999 17:07:46 -0700 (PDT)
Received: from ronald.trustpoint.com (ronald@ronald [192.168.42.4]) by gandalf.trustpoint.com (8.8.7/8.8.7) with ESMTP id RAA31419 for <[e-mail]>; Sat, 7 Aug 1999 17:07:55 -0700
From: Ronald Tschalär <[e-mail]>
Received: (from ronald@localhost) by ronald.trustpoint.com (8.8.7/8.8.7) id RAA00814 for [e-mail]; Sat, 7 Aug 1999 17:07:54 -0700
Message-Id: <[e-mail]>
Subject: Re: language tags in PKIFreeText
To: [e-mail]
Date: Sat, 7 Aug 1999 17:07:54 -0700 (PDT)
In-Reply-To: <[e-mail]> from "Paul Hoffman / IMC" at Aug 7, 99 02:45:20 pm
Content-Type: text

Paul Hoffman wrote:
> 
> At 02:18 PM 8/7/1999 -0700, Ronald Tschalär wrote:
> 
> >The definition of PKIFreeText in RFC-2510 says:
> >
> >      PKIFreeText ::= SEQUENCE SIZE (1..MAX) OF UTF8String
> >          -- text encoded as UTF-8 String (note:  each UTF8String SHOULD
> >          -- include an RFC 1766 language tag to indicate the language
> >          -- of the contained text)
> >
> >Unfortunately, I could find no hint as to *how* the language tag should
> >be included (RFC-1766 only defines the tags themselves and a Content-Language
> >header for MIME-like structures). I presume the idea is that the string
> >start off with "<lang-tag>:" followed by the actual text?
> 
> I don't think so. Embedding language tags in Unicode (of which UTF-8 is a 
> transformation) is described in RFC 2482. This is the method that is 
> expected to be used in all Unicode text that will contain language tags. 

Ah, wasn't aware of that spec. Maybe a refernce to it should be included
in the above text.

Looking 2482, it allows any number of tags anywhere in the text. For
PKIFreeText it seems to me that one tag per string, located at the
beginning, should suffice. So how about:

     PKIFreeText ::= SEQUENCE SIZE (1..MAX) OF UTF8String
         -- text encoded as UTF-8 String (note:  each UTF8String SHOULD
         -- include a single RFC 1766 language tag, as specified in RFC
	 -- 2482, located at the beginning of the string, to indicate
	 -- the language of the contained text)

> FWIW, UTF-8 is described in RFC 2279 (this wasn't referenced in the CMP 
> spec). Also note that RFC 1766 is being updated; the Internet Draft for the 
> update is draft-alvestrand-lang-tags-v2-00.txt.

Thanks for the pointer - good to see language ranges included.


  Cheers,

  Ronald



Received: from tomcat.sac.verio.net ([e-mail] [209.162.64.15]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id PAA21458 for <[e-mail]>; Sat, 7 Aug 1999 15:55:26 -0700 (PDT)
Received: from nma.com (pm05-22.sac.verio.net [209.162.64.182]) by tomcat.sac.verio.net (8.9.1a/8.9.1) with ESMTP id PAA00628; Sat, 7 Aug 1999 15:55:30 -0700 (PDT)
Message-ID: <[e-mail]>
Date: Sat, 07 Aug 1999 15:55:32 -0700
From: Ed Gerck <[e-mail]>
X-Mailer: Mozilla 4.51 [en]C-CCK-MCD {Sony}  (Win98; I)
X-Accept-Language: en
MIME-Version: 1.0
To: Peter Gutmann <[e-mail]>
CC: [e-mail]
Subject: Alternative, was Re: [Junk] Re: Possible solution?, was Re:  Non-Repudiation
References: <[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Peter Gutmann wrote:

> Paul Hoffman / IMC <[e-mail]> writes:
>
> >At 08:57 AM 8/6/1999 -0700, Ed Gerck wrote:
> >>"Certificates that ascertain the non-repudiation bit MUST be issued by
> >>the subject."
> >
> >A certificate is an inanimate object. It cannot "ascertain" anything. It
> >can't "know" anything.
>
> Given the amount of cruft which various standards groups are busy stuffing into
> certificates, it wouldn't surprise me if some of the components eventually
> reached sentience.

Me neither -- but thanks for the subject warning ;-)

However, I point out that the word "ascertain" was used in order to try to
reflect exactly what Paul mentioned -- so, I welcome his comment.

That is, the word "ascertain" was used to convey (some would say overload)
the notion that non-repudiation is not infused and transported in the
certificate itself (as PKIX currently defines) but must be queried from
elsewhere when the certificate ascertains the NR bit -- ie, for which NR
service a challenge-response mechanism is needed (not necessarily
cryptographic).  Here, the NR certificate is merely defining that a NR
service is available in a suitable query -- but, does not provide it.

A look in the URL [http://www.m-w.com/cgi-bin/thesaurus] will show that
"ascertain" has the synonym "find out" and the related words "ask", "inquire",
"interrogate" and "query"; any of which will provide the context.

Based on a private comment (for other possible and valid NR uses based on
a CA contract) and the possible confusion with overloading too much meaning
into a word (other msgs and, essentially, what I read from Paul's comment), I
would suggest the following alternatives:

1. A certificate that sets the nonRepudiation bit also implictly defines where
the non-repudiation service is provided, which MUST be:
  1.a. by the issuer if the certificate is self-signed, or otherwise,
  1.b. as regulated in the CPS.

Cheers,

Ed Gerck



Received: from aum (ip11.proper.com [165.227.249.11]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id OAA20569; Sat, 7 Aug 1999 14:45:34 -0700 (PDT)
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58 
Date: Sat, 07 Aug 1999 14:45:20 -0700
To: Ronald =?iso-8859-1?Q?Tschal=E4r?= <[e-mail]>, [e-mail]
From: Paul Hoffman / IMC <[e-mail]>
Subject: Re: language tags in PKIFreeText
In-Reply-To: <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"; format=flowed
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by mail.proper.com id OAA20570

At 02:18 PM 8/7/1999 -0700, Ronald Tschalär wrote:

>The definition of PKIFreeText in RFC-2510 says:
>
>      PKIFreeText ::= SEQUENCE SIZE (1..MAX) OF UTF8String
>          -- text encoded as UTF-8 String (note:  each UTF8String SHOULD
>          -- include an RFC 1766 language tag to indicate the language
>          -- of the contained text)
>
>Unfortunately, I could find no hint as to *how* the language tag should
>be included (RFC-1766 only defines the tags themselves and a Content-Language
>header for MIME-like structures). I presume the idea is that the string
>start off with "<lang-tag>:" followed by the actual text?

I don't think so. Embedding language tags in Unicode (of which UTF-8 is a 
transformation) is described in RFC 2482. This is the method that is 
expected to be used in all Unicode text that will contain language tags. 
However, there are not many applications that use language tagging, so I 
can't say for certain if that's what is supposed to be done in CMP.

FWIW, UTF-8 is described in RFC 2279 (this wasn't referenced in the CMP 
spec). Also note that RFC 1766 is being updated; the Internet Draft for the 
update is draft-alvestrand-lang-tags-v2-00.txt.

--Paul Hoffman, Director
--Internet Mail Consortium


Received: from gandalf.trustpoint.com (IDENT:[e-mail] [216.100.231.61]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id OAA20211 for <[e-mail]>; Sat, 7 Aug 1999 14:18:05 -0700 (PDT)
Received: from ronald.trustpoint.com (ronald@ronald [192.168.42.4]) by gandalf.trustpoint.com (8.8.7/8.8.7) with ESMTP id OAA31043 for <[e-mail]>; Sat, 7 Aug 1999 14:18:14 -0700
From: Ronald Tschalär <[e-mail]>
Received: (from ronald@localhost) by ronald.trustpoint.com (8.8.7/8.8.7) id OAA00708 for [e-mail]; Sat, 7 Aug 1999 14:18:13 -0700
Message-Id: <[e-mail]>
Subject: language tags in PKIFreeText
To: [e-mail]
Date: Sat, 7 Aug 1999 14:18:12 -0700 (PDT)
Content-Type: text

The definition of PKIFreeText in RFC-2510 says:

     PKIFreeText ::= SEQUENCE SIZE (1..MAX) OF UTF8String
         -- text encoded as UTF-8 String (note:  each UTF8String SHOULD
         -- include an RFC 1766 language tag to indicate the language
         -- of the contained text)

Unfortunately, I could find no hint as to *how* the language tag should
be included (RFC-1766 only defines the tags themselves and a Content-Language
header for MIME-like structures). I presume the idea is that the string
start off with "<lang-tag>:" followed by the actual text?


  Cheers,

  Ronald



Received: from tomcat.sac.verio.net ([e-mail] [209.162.64.15]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id MAA19351; Sat, 7 Aug 1999 12:45:02 -0700 (PDT)
Received: from nma.com (pm04-19.sac.verio.net [209.162.64.132]) by tomcat.sac.verio.net (8.9.1a/8.9.1) with ESMTP id MAA08538; Sat, 7 Aug 1999 12:45:10 -0700 (PDT)
Message-ID: <[e-mail]>
Date: Sat, 07 Aug 1999 12:45:11 -0700
From: Ed Gerck <[e-mail]>
X-Mailer: Mozilla 4.51 [en]C-CCK-MCD {Sony}  (Win98; I)
X-Accept-Language: en
MIME-Version: 1.0
To: Paul Hoffman / IMC <[e-mail]>
CC: tog <[e-mail]>, "[e-mail]" <[e-mail]>
Subject: avoid but not ignore, was Re: Non-Repudiation
References: <v04020a00b3d09bccaa3d@[128.89.0.110]> <[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Paul Hoffman / IMC wrote:

> BTW, I'm not at all against announcing interesting legal stuff that is
> related to the WG's work; that's fine. It's the trying to make our work
> align with the ever-changing legal stuff that is distracting and not
> helpful for us finishing our work.

I agree with your msg. ICANN is perhaps a living proof how distracting
it can be to try to cope with all laws within one rule -- in fact, this is not
doable at all IMO.

And, I also strongly agree not to drag the WG towards "legal" solutions,
since they are always local to some extent.  However, the WG must not
either be dragged into "illegal" solutions -- which are dead on arrival. The
tension area between avoiding but not ignoring the legal issues is what
IMO needs to distinguish the results of this WG.

Also, one must be aware of over-legislative efforts that are just proposed
by "special interest groups" (an euphemism) and then mostly abandoned,
to which one must not swerve unless one wishes to go nowhere.

Cheers,

Ed Gerck



Received: from imo28.mx.aol.com (imo28.mx.aol.com [198.81.17.72]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id MAA19048 for <[e-mail]>; Sat, 7 Aug 1999 12:19:24 -0700 (PDT)
From: [e-mail]
Received: from [e-mail] by imo28.mx.aol.com (mail_out_v22.4.) id 3LLIa22755 (4542); Sat, 7 Aug 1999 15:18:55 -0400 (EDT)
Message-ID: <[e-mail]>
Date: Sat, 7 Aug 1999 15:18:55 EDT
Subject: Re: Non-Repudiation (Definitions)
To: [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 21

Dear Aram,

Steve is dead on when describing the state of definitions/terms of art within 
the technical community folks that have been engaged in PKI work for some 
time.

Unfortunately even within (ANSI X9F5- Financial 
Institutions/Security/Certificate Policies and Practices) which I cochair, 
other definitions leaking in occasionally create problems for us.  If it is 
confusing for us it is deadly when our documents or discussions leave the 
committees or forums and reach the eyes of others.

Even worse than accidental misunderstandings are the intentional blurrings...
Many promulgators of lighterweight authentication technology have been 
intentionally free riding on the presumptive goodness of "digital signatures" 
by using "electronic signatures" or "electronic authentication" as a direct 
substitute or worse yet applying the term "digital signature" to cover  
"digitized signatures."

It is very important for us to clearly define terms and stick to them or we 
end up with laws like the recent California authentication horror that was 
just passed.

I myself have created some extremely fast and scalable authentication 
technology, but at least have the honesty to put the term "lightweight" in 
front of the descriptions.

I hope my former colleagues at ABAecom were able to get the keys from the 
root to you and your people.

I hope to be able to demo some of our new stuff for you very soon.

Good luck...kawika...

PS.  Call if you need anything...301 332 5224
PPS.  I would encourage you to look at the work that x9f5 is doing.


Received: from letterbox.cs.auckland.ac.nz (letterbox.cs.auckland.ac.nz [130.216.35.1]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id MAA18846 for <[e-mail]>; Sat, 7 Aug 1999 12:11:48 -0700 (PDT)
Received: from kakapo.cs.auckland.ac.nz (kakapo.cs.auckland.ac.nz [130.216.34.10]) by letterbox.cs.auckland.ac.nz (8.8.6/8.8.6/cs-master) with ESMTP id HAA00958 for <[e-mail]>; Sun, 8 Aug 1999 07:11:42 +1200 (sender [e-mail])
Received: (from pgut001@localhost) by kakapo.cs.auckland.ac.nz (8.8.6/8.8.6/cs-slave) id HAA27201 for [e-mail]; Sun, 8 Aug 1999 07:11:37 +1200 (NZST) (sender [e-mail])
Date: Sun, 8 Aug 1999 07:11:37 +1200 (NZST)
Message-ID: <[e-mail]>
From: [e-mail] (Peter Gutmann)
To: [e-mail]
Subject: [Junk] Re: Possible solution?, was Re: Non-Repudiation

Paul Hoffman / IMC <[e-mail]> writes:

>At 08:57 AM 8/6/1999 -0700, Ed Gerck wrote:
>>"Certificates that ascertain the non-repudiation bit MUST be issued by
>>the subject."
>
>A certificate is an inanimate object. It cannot "ascertain" anything. It
>can't "know" anything.

Given the amount of cruft which various standards groups are busy stuffing into
certificates, it wouldn't surprise me if some of the components eventually
reached sentience.

Peter.


Received: from aum (ip11.proper.com [165.227.249.11]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id LAA18442; Sat, 7 Aug 1999 11:29:06 -0700 (PDT)
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58 
Date: Sat, 07 Aug 1999 11:29:12 -0700
To: Stefan Santesson <[e-mail]>, <[e-mail]>
From: Paul Hoffman / IMC <[e-mail]>
Subject: Re: New draft for the Qualified Certificate profile
In-Reply-To: <[e-mail]>
References: <000801bee0d6$49ea7d40$[e-mail]> <v04020a00b3d09bccaa3d@[128.89.0.110]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed

At 08:04 PM 8/7/1999 +0200, Stefan Santesson wrote:
>For those who don't want to wait untlil the draft hit the official pages,

They're faster than you think. It made it into the official directory 
Friday night. The new version is thus available at 
<http://www.ietf.org/internet-drafts/draft-ietf-pkix-qc-01.txt> 
and  <http://www.imc.org/draft-ietf-pkix-qc>.

--Paul Hoffman, Director
--Internet Mail Consortium


Received: from popmail.inbox.se (popmail.inbox.se [193.12.72.101]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id LAA17937 for <[e-mail]>; Sat, 7 Aug 1999 11:03:27 -0700 (PDT)
Received: from stefan2 (accurata.inbox.se [193.12.72.24]) by popmail.inbox.se (8.9.3/8.9.3) with SMTP id UAA22364 for <[e-mail]>; Sat, 7 Aug 1999 20:04:05 +0200
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 
Date: Sat, 07 Aug 1999 20:04:22 +0200
To: <[e-mail]>
From: Stefan Santesson <[e-mail]>
Subject: New draft for the Qualified Certificate profile
In-Reply-To: <000801bee0d6$49ea7d40$[e-mail]>
References: <v04020a00b3d09bccaa3d@[128.89.0.110]>
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 mail.proper.com id LAA17938

On August 6, we submitted the new draft for the Qualified Certificate profile 

We think this is ready now for WG last call and that all outstanding issues
has been resolved.
I will request WG last call as soon as the draft is officially published.

For those who don't want to wait untlil the draft hit the official pages,
the new draft can be obtained from: 

http://www.accurata.se/QC/documents/draft-ietf-pkix-qc-01.txt

In this draft we have also included an example cert. I would encourage
testing and evaluation of the example cert as well as all ASN.1 modules.

/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 aum (ip11.proper.com [165.227.249.11]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id LAA17905 for <[e-mail]>; Sat, 7 Aug 1999 11:03:15 -0700 (PDT)
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58 
Date: Sat, 07 Aug 1999 11:01:10 -0700
To: <[e-mail]>
From: Paul Hoffman / IMC <[e-mail]>
Subject: Re: Non-Repudiation
In-Reply-To: <000801bee0d6$49ea7d40$[e-mail]>
References: <v04020a00b3d09bccaa3d@[128.89.0.110]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed

At 06:10 AM 8/7/1999 -0700, tog wrote:
>Why I bring this up is that it seems to me is that we as technologies as we
>progress farther and farther upwards in the food chain (the bottom being
>Core Enablement, and the top being a Turnkey System) that the legislative
>process and standards become some of the critical gating issues to deploying
>our collective vision.

Todd, I don't believe you understand the role that the IETF has actively 
chosen for itself. We stay out of local legislative issues wherever we can 
(and the US is local, as we have seen in this WG with the Europeans going 
many places the US has not). We're not lawyers here, and we strive mightily 
to not become them.

If you think you understand the law, great. (I do too, in some areas, but 
not this one.) I suggest you take that legal understanding to groups that 
are concerned with the law and help them understand what you understand of 
the technology. (I do that too.) They do law with only a bit of care for 
the technology; we do technology with only a bit (or zero) care for the 
law. But please stop trying to drag the WG towards "legal" solutions. I 
assure you, we'll do a bad job of it, given how little the vast majority of 
us understand about legal issues, and given how little coordination there 
is for the law in this area (or any technical area, for that matter).

BTW, I'm not at all against announcing interesting legal stuff that is 
related to the WG's work; that's fine. It's the trying to make our work 
align with the ever-changing legal stuff that is distracting and not 
helpful for us finishing our work.

--Paul Hoffman, Director
--Internet Mail Consortium


Received: from www.meridianus.com (209.249.223.31.has.no.reverse [209.249.223.31] (may be forged)) by mail.proper.com (8.9.3/8.9.3) with ESMTP id HAA16566 for <[e-mail]>; Sat, 7 Aug 1999 07:45:47 -0700 (PDT)
Received: from PC1 by www.meridianus.com (8.8.8+Sun/SMI-SVR4) id IAA29967; Sat, 7 Aug 1999 08:40:30 -0700 (PDT)
Message-ID: <002e01bee0e5$cf5d6690$[e-mail]>
From: "tog" <[e-mail]>
To: <[e-mail]>
Subject: The BERT token and the our API services for it
Date: Sat, 7 Aug 1999 08:01:59 -0700
Organization: Meridianus
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.2918.2701
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2918.2701

All,
to clarify a point in Michael McNeal's mailing yesterday where he
essentially announced that we (Glassey-McNeil Technologies) intend to
release a complete API and protocol use model for our BERT token
structure...

It is pivotal to our thinking that the centerpiece of the timestamping
system be the Token Structure and not the routines or API that uses or
manages it. Our vision is that this token (aka 'the BERT')  is the only
really necessary point of interoperability in timestamping systems and that
the rest of it, that is the services and the tools that support the token
structure use models, are essentially an Application Level Technology API.

In addressing this vision, our intent was to create a simple lightweight
token structure that could easily be used for timestamping network events as
well as whole-cloth document services, and that could sit in PKIX as a
datastructure for representing time data and its validity (source,
resolution, indemnity statement, etc). Additionally we realized that
Jurisdictional Indication would be an important factor in sighting and
fixing events in time and space.

As to the issues facing timestamping on a global basis, there were
international ramifications as well, we figured that it might be a nightmare
to get systems standardized whole-cloth across International boundaries, and
that the token itself was a much simpler proposition.

We also looked at commercial proofing requirements and what they actually
provided vs. what they cost to operate, and we found that in distilling the
envelope of trust in question, that the perimeter OS in most instances was
exactly this envelope. This has many serious implications regarding the what
and the how of timestamping.

Another cornerstone of our vision is that it is irrelevant  whether the TS
service is operated externally, as a trusted third party, or internally as
underlayment for existing processes. That there is also a dramatic need for
this service model to be as fast as possible, as Bill Lattin noted so well,
technology is evolving and that is an important factor in any standard we
propose here.

With all of these issues in mind, we looked at BERT's use models and thought
it through pretty carefully. The BERT can be made smaller by replacing
literal content with OIDS and this can be done in a number of places.
Realize however, that this means that the token structure itself will not be
able to represent an event without other TRUST DATA external to the token
structure, in this case the OID Definitions. This externalizing the trust
components changes to totality and value of the trust processes being
supported. In these models the timestamp token leverages more reliance on
the routines that made and manage the tokens so they are similar in this to
the current TS Drafts.

Likewise for document or larger operations, the BERT can balloon up to 65K
now and can be chained together to support timestamping individual objects,
pages or whole documents.  There is also an optional token structure coming
in the BERT 2.0 draft that provides for adding a descriptive statement as to
the intent of the timestamp itself in the form of  an ESP. We feel this is
absolutely critical in building stamps that stand on their own two feet.
Likewise this "indicated intent statement" will support an external OID
representation of a statement of intent as well.

Back on the metal - the original BERT was designed to represent events in
time and space and to be essentially a  'totality of the event'
representation method. It is light enough to be used inside of both DB and
Warehousing Operations and strong enough to withstand any reasonable attack
of its' event.   In comparing BERT to other systems that use external
representation systems, that is to say systems that are not part of the core
application to represent their respective proofs,  BERT is based in a use
model for commercial trust processes, not absolute trust.

BERT systems are subject to attack in the OS just as all other systems are,
but TTP models or other BCP techniques limit these in day to day operations.
So the BERT is built for commercial grade proofing models and by leveraging
these against one another it eliminates the need for complex and expensive
to operate, external systems. The BERT based timestamping process can easily
run inside or as a local service to the application that needs it.

As to operating BERT systems themselves as TTP's, this works fine and
provides all the protection that an external site or TTP provides by its
relation to its customers. The idea is that the BERT work is all done
locally and then submitted to the auditor station for restamping and
logging, whether this is local or remote. This model, running an external
logger, actually can provide two (or more) separate timestamps for the same
physical event, and since the BERT API's timebase, resolution/reliability
data is included with the BERT Token, they - the events referenced and
proven by the tokens - are directly comparable to each other, even when they
are created thousands of miles or years apart.

Regarding the current TS and DCS services. The BERT API is another competing
system for timestamping, the BERT token is not. There is no reason why the
BERT Token could not easily be a TST.

In closing I want to mention personally that I believe that the BERT is a
much simpler solution for the standards process than a fully blown system
and pretty much, any API that implements the BERT to be commercially valid
will just need a simple audit, not the blessing of this committee. I also
want to say that either of the other two systems currently proposed for
issuing secure timestamps could easily interoperate with the BERT token
structure and that this would create a uniformity that would provide
reasonably any service model to be supported.

BERT is also not cast in concrete, if you have any additions or suggestions
lets run them up the flagpole so to speak!

Todd Glassey





Received: from www.meridianus.com (209.249.223.39.has.no.reverse [209.249.223.39] (may be forged)) by mail.proper.com (8.9.3/8.9.3) with ESMTP id FAA15727 for <[e-mail]>; Sat, 7 Aug 1999 05:54:44 -0700 (PDT)
Received: from PC1 by www.meridianus.com (8.8.8+Sun/SMI-SVR4) id GAA29874; Sat, 7 Aug 1999 06:49:28 -0700 (PDT)
Message-ID: <000801bee0d6$49ea7d40$[e-mail]>
From: "tog" <[e-mail]>
To: "Aram Perez" <[e-mail]>, "Stephen Kent" <[e-mail]>
Cc: <[e-mail]>
References: <v04020a00b3d09bccaa3d@[128.89.0.110]>
Subject: Re: Non-Repudiation
Date: Sat, 7 Aug 1999 06:10:57 -0700
Organization: Meridianus
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.2918.2701
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2918.2701

Stephen, Aram,

----- Original Message -----
From: Stephen Kent <[e-mail]>
To: Aram Perez <[e-mail]>
Cc: <[e-mail]>
Sent: Friday, August 06, 1999 7:11 AM
Subject: Re: Non-Repudiation


> Aram,
>
> The term "digital signature" has a well defined meaning in the technical
> literature, and was specifically coined in the context of public key
> cryptography, although one can achieve analogous features via symmetric
> crypto.

It also has a pretty clear definition under US Law, I suggest if your
interested in looking at the state of the various legeislative processes at
MBC.COM, one of the premeir law firms that tracks US EC Legislation. The URL
is http://www.mbc.com/ds_sum.html, those of us that are aslo ISC members
(http://www.abanet.org/scitech/ec/isc) are familiar with this site, it and
several others including Perkins-Coie in Seattle have excellent "tracking EC
Legislation" websites.

Why I bring this up is that it seems to me is that we as technologies as we
progress farther and farther upwards in the food chain (the bottom being
Core Enablement, and the top being a Turnkey System) that the legislative
process and standards become some of the critical gating issues to deploying
our collective vision.

So I suggest that you might (or might not) enjoy looking at these sites.

Todd




Received: from prv-mail20.provo.novell.com (prv-mail20.provo.novell.com [137.65.82.195]) by mail.proper.com (8.9.3/8.9.3) with SMTP id PAA02508; Fri, 6 Aug 1999 15:41:08 -0700 (PDT)
Received: from INET-PRV-Message_Server by prv-mail20.provo.novell.com with Novell_GroupWise; Fri, 06 Aug 1999 16:41:18 -0600
Message-Id: <[e-mail]>
X-Mailer: Novell GroupWise 5.5.2
Date: Fri, 06 Aug 1999 16:41:09 -0600
From: "Bob Jueneman" <[e-mail]>
To: <[e-mail]>, <[e-mail]>, <[e-mail]>, <[e-mail]>
Subject: RE: X9.42 and RFC2459 inconsistency?
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 mail.proper.com id PAB02509

We aren't shipping it yet, but have planned to use the RFC 2459 OID,
as we haven't been following X9 that closely.  We could potentially 
support both uses, but rather not, especially for VPN.

Of course, I'm not all that hot on the use of DH to begin with,
since the primary rational seems to be intellectual property-related 
rather than technical.

Bob

>>> "Jim Schaad (Exchange)" <[e-mail]> 08/06/99 02:34PM >>>
I would object to changing this.  I have code which has shipped and uses
these OIDs.

jim


-----Original Message-----
From: Andrew Farrell [mailto:[e-mail]] 
Sent: Friday, July 30, 1999 6:22 AM
To: [e-mail]; [e-mail] 
Subject: Re: X9.42 and RFC2459 inconsistency? 


I wrote:

>Cool (and a welcome gesture towards fixing broken stuff). So why do we
>use their OID?

Sine there's been a deafing silence on this topic, I have two further
questions:

(1) Are there any deployed codebases which would object to changing the
Diffie-Hellman OID in rfc2459 to reflect the fact that it has different
semantics than in X9.42? 

I know that John Pawling has stated that Van Dyke's S/MIME Freeware
Library has no issues, and as far as I know Microsoft haven't shipped
anything with Diffie-Hellman, so that S/MIME would appear to be in the
clear on this.

(2) Are there any other groups that profile 2459 that we should ask
about this?.

Andrew



Received: from po1.bbn.com (PO1.BBN.COM [192.1.50.38]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id OAA01267 for <[e-mail]>; Fri, 6 Aug 1999 14:47:52 -0700 (PDT)
Received: from [128.89.0.110] (COSMEC.BBN.COM [128.89.0.110]) by po1.bbn.com (8.9.1/8.9.1) with ESMTP id RAA06247; Fri, 6 Aug 1999 17:48:21 -0400 (EDT)
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
X-Sender: [e-mail]
Message-Id: <v04020a08b3d1044e4f27@[128.89.0.110]>
In-Reply-To: <[e-mail]>
References: <v04020a07b3cf66fa3d68@[128.33.238.163]>		 <[e-mail]> <v04020a03b3d0a62117c1@[128.89.0.110]> <v04020a04b3d0c4b7d037@[128.89.0.110]>
Date: Fri, 6 Aug 1999 17:38:22 -0400
To: Ed Gerck <[e-mail]>
From: Stephen Kent <[e-mail]>
Subject: Re: Possible solution?, was Re: Non-Repudiation, was Re: Common   misconceptions, was Re: KISSfor   PKIX.   (Was: RE:ASN.1vs   XML   (used to be RE: I-D 	ACTION 	 :draft-ietf-pkix-scvp-00.txt))
Cc: "'[e-mail]'" <[e-mail]>

Ed,

>Can you pls exemplify what CA policies would be both precluded and yet useful
>for NR, by following either usage above: (i) MUST; and (ii) SHOULD NOT?

A CA might offer a policy under which all users were issued signature certs
with the NR bit on, but the users don't explicitly request it in such
cases.  In general, PKIX tries to be policy neutral.

>> So, I don't envision any change to the text.
>
>Is this a matter of consensus? Or, sensus?

My dictionary does not contain an entry for "sensus," so I'll have to pass
on that one.

>> I've generally assumed this bit would appear only in certs issued to EEs,
>> not to CAs.  It might be applicable for some forms of CA certs,  but I
>> think the semantics for certs and CRLs and OCSP messages, plus a CA's CSP,
>> already provide the necessary (and more definitive) info about the NR
>> aspects of data signed with the corresponding private keys.
>
>In a world where anyone can be an issuer (ie, a CA), it makes sense to
>make some CAs just informative, not only affirmative.  Even in CA-centric
>PKIs it may also be useful for CAs to use the NR bit but on the other way
>around (since in PKIX all CAs are just as affirmative as their CPS) --
>where the certSign bit could then carry more weight than today's no-warranty
>and no-suitability-of-purpose disclaimers, but when combined with the
>nonRepudiation bit.  In fact, one could have four combinations of reliance
>modes.

Yes, a CA can specify, in its policies, what legal assurances it associates
with use of these bits, beyond the straightforward, technical definitions
contained in 2459.

Steve


Received: from doggate.exchange.microsoft.com (doggate.exchange.microsoft.com [131.107.88.55]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id NAA00248; Fri, 6 Aug 1999 13:36:14 -0700 (PDT)
Received: by doggate.exchange.microsoft.com with Internet Mail Service (5.5.2232.9) id <QGYGKSHB>; Fri, 6 Aug 1999 13:34:26 -0700
Message-ID: <2FBF98FC7852CF11912A0000000000010ECB60D4@DINO>
From: "Jim Schaad (Exchange)" <[e-mail]>
To: "'Andrew Farrell'" <[e-mail]>, [e-mail], [e-mail]
Subject: RE: X9.42 and RFC2459 inconsistency? 
Date: Fri, 6 Aug 1999 13:34:24 -0700 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2232.9)
Content-Type: text/plain; charset="iso-8859-1"

I would object to changing this.  I have code which has shipped and uses
these OIDs.

jim


-----Original Message-----
From: Andrew Farrell [mailto:[e-mail]]
Sent: Friday, July 30, 1999 6:22 AM
To: [e-mail]; [e-mail]
Subject: Re: X9.42 and RFC2459 inconsistency? 


I wrote:

>Cool (and a welcome gesture towards fixing broken stuff). So why do we
>use their OID?

Sine there's been a deafing silence on this topic, I have two further
questions:

(1) Are there any deployed codebases which would object to changing the
Diffie-Hellman OID in rfc2459 to reflect the fact that it has different
semantics than in X9.42? 

I know that John Pawling has stated that Van Dyke's S/MIME Freeware
Library has no issues, and as far as I know Microsoft haven't shipped
anything with Diffie-Hellman, so that S/MIME would appear to be in the
clear on this.

(2) Are there any other groups that profile 2459 that we should ask
about this?.

Andrew


Received: from po1.bbn.com (PO1.BBN.COM [192.1.50.38]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id MAA29466 for <[e-mail]>; Fri, 6 Aug 1999 12:44:39 -0700 (PDT)
Received: from [128.89.0.110] (COSMEC.BBN.COM [128.89.0.110]) by po1.bbn.com (8.9.1/8.9.1) with ESMTP id PAA23815; Fri, 6 Aug 1999 15:45:13 -0400 (EDT)
Mime-Version: 1.0
Content-Type: multipart/alternative; boundary="============_-1278153790==_ma============"
X-Sender: [e-mail]
Message-Id: <v04020a03b3d0ea92428b@[128.89.0.110]>
Date: Fri, 6 Aug 1999 15:41:38 -0400
To: [e-mail]
From: Stephen Kent <[e-mail]>
Subject: PKIX Final minutes (45th IETF)
Cc: [e-mail]

--============_-1278153790==_ma============
Content-Type: text/plain; charset="us-ascii"

PKIX WG Meeting 7/14/99
Edited by Steve Kent (WG co-chair)

The PKIX WG met only once during the 45th IETF and a approximately 180
individuals participated in these meetings.

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

PKIX WORK IN PROGRESS

ECDSA Algorithms for Profile (draft-ietf-pkix-ipki-ecdsa-01.txt)
		New draft to be issued for WG last call shortly
CMC (draft-ietf-pkix-cmc-02.txt)

Diffie-Hellman POP (draft-ietf-pkix-dhpop-00.txt)
		Ready for WG last call
Qualified Certificates (draft-ietf-pkix-qc-01.txt)
		Version ready for WG last call
CMMF (draft-ietf-pkix-cmmf-02.txt)
		This item to be dropped from the program
Time Stamp (draft-ietf-pkix-time-stamp-00.txt)
		Near to WG last call
DCS (draft-ietf-pkix-dcs-00.txt)
		Under WG review
PKIX Rodamap (draftietf-pkix-roadmap-??.txt)
		Under WG review.
Others??


Reports on Established Projects:


Progressing RFC 2459 to Draft Status (R. Housley-Spyrus)
Russ described the requirements for progression to draft standard status
and solicited inputs from the PKIX community in support of this
progression. He also solicited edits to 2459 and noted that a defect report
on policy mapping in certificate validation processing has been filed. This
defect is expected to be resolved in a meeting in September, and the
results will be reflected in the revisions to 2459. Depending on the
resolution of this defect, it may be necessary for 2459 to "cycle in
grade," or it may be possible to progress to draft standard status. A straw
poll on a technical detail of delta CRL management was conducted, and the
consensus was to allow delta CRLs to be based on any specified base (vs.
only the most recently issued base).

Revision of RFC 2527 Certificate Policy Practice Guidelines (J. Rodriguez-IBM)
An activity on revising this informational RFC, based on operational
experience in the CA realm, and inputs from the legal community (ABA) has
been initiated. A small group has been created, with a corresponding
mailing list ([e-mail]), to pursue this revision.

CMC and Diffie-Hellman POP (J. Schaad-Microsoft)
Final draft for CMC will be published in about one week, and then go to WG
last call.  The D-H POP draft will follow shortly.


PKIX Roadmap (S. Turner-IECSA)
Updated QC discussion, and added a number of items (not all of which are
accepted as work items for the WG). A comparison of PKIX vs. other
certificate profiles will be the subject of a separate document, as per the
recommendation of the WG chairs.

Time Stamping Protocol (D. Pinkas-Bull)
Denis has taken over as editor for this work, from R. Zuccherato.  A new
draft (version 2) was posted just prior to the IETF. Major revisions
include the scope of the protocol, removal of TDA support, moving status
outside of the signed token per se, removal of support for sequence of
hashes, format of TST time, etc.  Choice of TST format uses GeneralisedTime
plus sub-second granularity as a separate component, taken directly from
NTP. But this second component is primarily used as a means to serialize
time stamps within a one-second interval, not specifically to offer highly
precise time stamps. The question was raised whether it is appropriate to
make dual use of this field, i.e., for sub-second accuracy and for
serialization. Alternative is to use GeneralizedTime to millisecond
accuracy, and then use serial number for further serialization. This needs
to be resolved on the list.

Denis observed that time stamping is an area rife with intellectual
property claims.  A list of patents in this area, provided by Denis,
illustrates the recent history in this area (back to 1989).  It is noted
that a submission to ISO in April 1989, in part of work on a
non-repudiation framework, constitutes early published work in this area,
perhaps calling into question some of the most general patents on time
stamping.  Work will continue to resolve the cloud that hangs over this
work item. (See slides for additional details.)

Data Certification Server Protocol (C. Adams-Entrust)
Peter Sylvester is the new lead editor and a new I-D has been published as
of this week. Scope has been pretty broad, encompassing features of
notarization OCSP, SCVP, TSP, etc. So, this is an example of the question
raised on the list with regard to different protocols for different
services, or a grand unified protocol approach. Possible options include
freezing this spec now as an experimental protocol, reduce scope to avoid
conflicts with other work items and continue as a standard track protocol,
or keep broad scope and kill other protocols. Denis notes that, from a
conformance standpoint, bundling would create the need to allow subset
compliance, since not all clients or servers will need all of the features
offered by a unified protocol. Discussion explored the dimensions in which
one may choose to partition protocols, e.g., mandatory use of a server for
non-repudiation vs. optional use of a server for operations that could be
performed by a client.

Simple Certificate Validation Protocol (P. Hoffman-VPNC & A. Malpani-ValiCert)
Questions arise about many different parts of this proposal, including use
of the "tiny" syntax, choice of higher level encapsulation formats, support
for non-X.509 (OPGP) certificates, etc.  The authors agreed to delete the
tiny syntax for now, due its controversy. (One WG chair pointed out that
support for other than X.509 certificates is not within scope for PKIX.
Members of the OPGP WG question this position, asserting that the IESG
precluded OPGP from pursuing its own PKI work. This needs to be addressed
via discussion with the security ADs.) Denis and others provided more
detailed criticism. A straw poll of attendees shows did not show clear
consensus for or against the general notion of offloading certificate
processing from a client. Discussion of this topic will continue on the
list, and a new draft (minus the tiny syntax) will be published.

Qualified Certificates (S. Santesson)
A new draft will be posted shortly, reflecting the latest set of changes
based on mailing list discussions.  Highlights of this new draft include:
"de-legalization" of scope of the document, an extension for inclusion of a
hash of biometric data (for human verification), and a new extension for
marking a certificate as qualified (via reference to an OID) and for
expressing reliance limits, separate from the use of the policy extension.
(This extension is general in order to fit any legal system, and thus is
not restricted to marking a certificate as a qualified certificate.)  The
author requested that a WG last call be issued, after the list has had a
chance to review this latest version.


Other Topics:

LDAPv3 Profile (D. Chadwick- University of Salford)
Description of what features of LDAP v3 are relevant to PKIX and thus why a
profile is needed. This is especially important because LDAP v2 is being
phased out as an IETF standard and PKIX must migrate to v3.  The author is
soliciting comments from the list, and will co-ordinate with the LDAP WG as
well.

Attribute Certificates	(S. Farrell-SSE)
Stephen briefly reviewed the document, which profiles the X.509 AC.
Several WG members discussed appropriate forms of linkage between the AC
and the PKC, i.e., name vs. certificate or key hash, vs. issuer and serial
#, revisiting a debate on the list. This discussion did not resolve the
debate. General agreement to include a standard attribute set, but still
need to resolve details of these attributes, and must require support for
creation of new AC extensions. Questions were raised whether a new,
lightweight protocol is needed pull ACs, vs. use of LDAP, as an adjunct to
the push model that now underlies the AC use model.  Straw poll showed
overwhelming support for moving the retrieval protocol to another document.
This document defines the base profile, plus extensions that are optional.
The WG needs to work out details of what is base vs. extension. Do we need
an extension in the AC authority's public key certificate to characterize
what the authority is authorized to issue what ACs, or should this be done
via an attribute certificate itself?

Basic Event Representation Token (M. McNeil-GMT)
The author notes that this proposal relates to the TSP work, but uses what
is believed a more compact format so that it may be used in environments
where the size of the response from a TSA is too big. The primary use model
provided here is rather implementation-specific, i.e., tamper-evident
hardware in a local context, vs. a TSA accessible via a network.  A
Security AD raised questions about any intellectual property claims
associated with this model, as this may affect whether the proposal is
appropriate for an IETF WG. The speaker stated that he is aware of no IP
with regard to the proposed formats, etc. A PKIX WG chair expressed concern
over the apparent product-specific nature of the proposed model.  The
author acknowledges that only one vendor (Datum) offers the sort of
hardware cited as the primary use example. The WG chairs and the Security
ADs will discuss whether this work is appropriate for PKIX, given the
issues cited above.

CMP Interoperability Testing	(R. Moskowitz-ISSA)
Bob reported results of four classes of testing for 5 CMP implementations,
conducted by ICSA and NIST. The next workshop will continue and expand
testing.  One lesson from this work is that the CMP RFC fails to mandate
defaults in many instances, which reduces interoperability.  Bob's analysis
of this testing is that we need more MUSTs in this standard!  One security
concern arose, with regard to the size of the salt used in registration.

Temporal Data Token (M. Duren-WetStone)
Presentation focused on format for TDT (in the TSA) that helps attest to
the integrity of the time source, i.e., providing a link to a trusted time
source. This approach pushes evidence of time source into a token, vs.
other, external measures that a TSA takes to ensure the accuracy and
integrity of its time source. A claimed feature of this approach is that it
allows a client to be able to verify the utility (for non-repudiation) of
the returned token immediately, vs. the deferred verification more typical
of TSA operation. As with the BERT presentation, the speaker was asked
about possible intellectual property claims and about the breadth of vendor
support for the propose TDT format.  The speaker asserted that he was aware
of no IP claims, and that he was aware of at least two vendors who had
expressed interest in this format, although no more than one was building
products to this spec at this time.  The WG Chairs and the Security ADs
also will need to discuss whether this is within the scope of PKIX, before
this item progresses.
--============_-1278153790==_ma============
Content-Type: text/enriched; charset="us-ascii"

<fontfamily><param>Courier_New</param><bigger>PKIX WG Meeting 7/14/99 

Edited by Steve Kent (WG co-chair)


The PKIX WG met only once during the 45th IETF and a approximately 180
individuals participated in these meetings. 


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


PKIX WORK IN PROGRESS


ECDSA Algorithms for Profile (draft-ietf-pkix-ipki-ecdsa-01.txt)

		New draft to be issued for WG last call shortly

CMC (draft-ietf-pkix-cmc-02.txt)

		

Diffie-Hellman POP (draft-ietf-pkix-dhpop-00.txt)

		Ready for WG last call 

Qualified Certificates (draft-ietf-pkix-qc-01.txt)

		Version ready for WG last call

CMMF (draft-ietf-pkix-cmmf-02.txt)

		This item to be dropped from the program 

Time Stamp (draft-ietf-pkix-time-stamp-00.txt) 

		Near to WG last call

DCS (draft-ietf-pkix-dcs-00.txt)

		Under WG review

PKIX Rodamap (draftietf-pkix-roadmap-??.txt)

		Under WG review.

Others??



Reports on Established Projects:



Progressing RFC 2459 to Draft Status (R. Housley-Spyrus)

Russ described the requirements for progression to draft standard
status and solicited inputs from the PKIX community in support of this
progression. He also solicited edits to 2459 and noted that a defect
report on policy mapping in certificate validation processing has been
filed. This defect is expected to be resolved in a meeting in
September, and the results will be reflected in the revisions to 2459.
Depending on the resolution of this defect, it may be necessary for
2459 to "cycle in grade," or it may be possible to progress to draft
standard status. A straw poll on a technical detail of delta CRL
management was conducted, and the consensus was to allow delta CRLs to
be based on any specified base (vs. only the most recently issued
base).


Revision of RFC 2527 Certificate Policy Practice Guidelines (J.
Rodriguez-IBM)

An activity on revising this informational RFC, based on operational
experience in the CA realm, and inputs from the legal community (ABA)
has been initiated. A small group has been created, with a
corresponding mailing list ([e-mail]), to pursue this
revision.


CMC and Diffie-Hellman POP (J. Schaad-Microsoft)

Final draft for CMC will be published in about one week, and then go to
WG last call.  The D-H POP draft will follow shortly.



PKIX Roadmap (S. Turner-IECSA)

Updated QC discussion, and added a number of items (not all of which
are accepted as work items for the WG). A comparison of PKIX vs. other
certificate profiles will be the subject of a separate document, as per
the recommendation of the WG chairs.


Time Stamping Protocol (D. Pinkas-Bull)

Denis has taken over as editor for this work, from R. Zuccherato.  A
new draft (version 2) was posted just prior to the IETF. Major
revisions include the scope of the protocol, removal of TDA support,
moving status outside of the signed token per se, removal of support
for sequence of hashes, format of TST time, etc.  Choice of TST format
uses GeneralisedTime plus sub-second granularity as a separate
component, taken directly from NTP. But this second component is
primarily used as a means to serialize time stamps within a one-second
interval, not specifically to offer highly precise time stamps. The
question was raised whether it is appropriate to make dual use of this
field, i.e., for sub-second accuracy and for serialization. Alternative
is to use GeneralizedTime to millisecond accuracy, and then use serial
number for further serialization. This needs to be resolved on the
list.


Denis observed that time stamping is an area rife with intellectual
property claims.  A list of patents in this area, provided by Denis,
illustrates the recent history in this area (back to 1989).  It is
noted that a submission to ISO in April 1989, in part of work on a
non-repudiation framework, constitutes early published work in this
area, perhaps calling into question some of the most general patents on
time stamping.  Work will continue to resolve the cloud that hangs over
this work item. (See slides for additional details.)


Data Certification Server Protocol (C. Adams-Entrust)

Peter Sylvester is the new lead editor and a new I-D has been published
as of this week. Scope has been pretty broad, encompassing features of
notarization OCSP, SCVP, TSP, etc. So, this is an example of the
question raised on the list with regard to different protocols for
different services, or a grand unified protocol approach. Possible
options include freezing this spec now as an experimental protocol,
reduce scope to avoid conflicts with other work items and continue as a
standard track protocol, or keep broad scope and kill other protocols.
Denis notes that, from a conformance standpoint, bundling would create
the need to allow subset compliance, since not all clients or servers
will need all of the features offered by a unified protocol. Discussion
explored the dimensions in which one may choose to partition protocols,
e.g., mandatory use of a server for non-repudiation vs. optional use of
a server for operations that could be performed by a client.


Simple Certificate Validation Protocol (P. Hoffman-VPNC & A.
Malpani-ValiCert)

Questions arise about many different parts of this proposal, including
use of the "tiny" syntax, choice of higher level encapsulation formats,
support for non-X.509 (OPGP) certificates, etc.  The authors agreed to
delete the tiny syntax for now, due its controversy. (One WG chair
pointed out that support for other than X.509 certificates is not
within scope for PKIX.  Members of the OPGP WG question this position,
asserting that the IESG precluded OPGP from pursuing its own PKI work.
This needs to be addressed via discussion with the security ADs.) Denis
and others provided more detailed criticism. A straw poll of attendees
shows did not show clear consensus for or against the general notion of
offloading certificate processing from a client. Discussion of this
topic will continue on the list, and a new draft (minus the tiny
syntax) will be published.


Qualified Certificates (S. Santesson)

A new draft will be posted shortly, reflecting the latest set of
changes based on mailing list discussions.  Highlights of this new
draft include: "de-legalization" of scope of the document, an extension
for inclusion of a hash of biometric data (for human verification), and
a new extension for marking a certificate as qualified (via reference
to an OID) and for expressing reliance limits, separate from the use of
the policy extension. (This extension is general in order to fit any
legal system, and thus is not restricted to marking a certificate as a
qualified certificate.)  The author requested that a WG last call be
issued, after the list has had a chance to review this latest version.



Other Topics:


LDAPv3 Profile (D. Chadwick- University of Salford)

Description of what features of LDAP v3 are relevant to PKIX and thus
why a profile is needed. This is especially important because LDAP v2
is being phased out as an IETF standard and PKIX must migrate to v3. 
The author is soliciting comments from the list, and will co-ordinate
with the LDAP WG as well.


Attribute Certificates	(S. Farrell-SSE)

Stephen briefly reviewed the document, which profiles the X.509 AC. 
Several WG members discussed appropriate forms of linkage between the
AC and the PKC, i.e., name vs. certificate or key hash, vs. issuer and
serial #, revisiting a debate on the list. This discussion did not
resolve the debate. General agreement to include a standard attribute
set, but still need to resolve details of these attributes, and must
require support for creation of new AC extensions. Questions were
raised whether a new, lightweight protocol is needed pull ACs, vs. use
of LDAP, as an adjunct to the push model that now underlies the AC use
model.  Straw poll showed overwhelming support for moving the retrieval
protocol to another document.  This document defines the base profile,
plus extensions that are optional.  The WG needs to work out details of
what is base vs. extension. Do we need an extension in the AC
authority's public key certificate to characterize what the authority
is authorized to issue what ACs, or should this be done via an
attribute certificate itself? 


Basic Event Representation Token (M. McNeil-GMT)

The author notes that this proposal relates to the TSP work, but uses
what is believed a more compact format so that it may be used in
environments where the size of the response from a TSA is too big. The
primary use model provided here is rather implementation-specific,
i.e., tamper-evident hardware in a local context, vs. a TSA accessible
via a network.  A Security AD raised questions about any intellectual
property claims associated with this model, as this may affect whether
the proposal is appropriate for an IETF WG. The speaker stated that he
is aware of no IP with regard to the proposed formats, etc. A PKIX WG
chair expressed concern over the apparent product-specific nature of
the proposed model.  The author acknowledges that only one vendor
(Datum) offers the sort of hardware cited as the primary use example.
The WG chairs and the Security ADs will discuss whether this work is
appropriate for PKIX, given the issues cited above. 


CMP Interoperability Testing	(R. Moskowitz-ISSA)

Bob reported results of four classes of testing for 5 CMP
implementations, conducted by ICSA and NIST. The next workshop will
continue and expand testing.  One lesson from this work is that the CMP
RFC fails to mandate defaults in many instances, which reduces
interoperability.  Bob's analysis of this testing is that we need more
MUSTs in this standard!  One security concern arose, with regard to the
size of the salt used in registration.


Temporal Data Token (M. Duren-WetStone)

Presentation focused on format for TDT (in the TSA) that helps attest
to the integrity of the time source, i.e., providing a link to a
trusted time source. This approach pushes evidence of time source into
a token, vs. other, external measures that a TSA takes to ensure the
accuracy and integrity of its time source. A claimed feature of this
approach is that it allows a client to be able to verify the utility
(for non-repudiation) of the returned token immediately, vs. the
deferred verification more typical of TSA operation. As with the BERT
presentation, the speaker was asked about possible intellectual
property claims and about the breadth of vendor support for the propose
TDT format.  The speaker asserted that he was aware of no IP claims,
and that he was aware of at least two vendors who had expressed
interest in this format, although no more than one was building
products to this spec at this time.  The WG Chairs and the Security ADs
also will need to discuss whether this is within the scope of PKIX,
before this item progresses. </bigger></fontfamily>

--============_-1278153790==_ma============--


Received: from tomcat.sac.verio.net ([e-mail] [209.162.64.15]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id MAA29212 for <[e-mail]>; Fri, 6 Aug 1999 12:36:05 -0700 (PDT)
Received: from nma.com (pm02-46.sac.verio.net [209.162.64.65]) by tomcat.sac.verio.net (8.9.1a/8.9.1) with ESMTP id MAA00730 for <[e-mail]>; Fri, 6 Aug 1999 12:36:43 -0700 (PDT)
Message-ID: <[e-mail]>
Date: Fri, 06 Aug 1999 12:36:41 -0700
From: Ed Gerck <[e-mail]>
X-Mailer: Mozilla 4.51 [en]C-CCK-MCD {Sony}  (Win98; I)
X-Accept-Language: en
MIME-Version: 1.0
CC: "'[e-mail]'" <[e-mail]>
Subject: Re: Possible solution?, was Re: Non-Repudiation, was Re: Common   misconceptions, was Re: KISSfor   PKIX.   (Was: RE:ASN.1vs   XML   (used  to be RE: I-D 	ACTION 	 :draft-ietf-pkix-scvp-00.txt))
References: <v04020a07b3cf66fa3d68@[128.33.238.163]>	 <[e-mail]> <v04020a03b3d0a62117c1@[128.89.0.110]> <v04020a04b3d0c4b7d037@[128.89.0.110]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Stephen Kent wrote:

> Ed,
>
> >Compare with this:
> >
> > "Certificates that ascertain the non-repudiation bit MUST be issued by
> > the subject."
>
> PKIX does not encourage issuance of certs by end-entities, so this is a
> non-starter (to use a buzzword).  One might imagine text such as "A CA
> SHOULD NOT issue a certificates asserting the NR key usgae bit unless it
> was requested by the Subject."  However, this would preclude certain CA
> policies and we don't want to do that.

Can you pls exemplify what CA policies would be both precluded and yet useful
for NR, by following either usage above: (i) MUST; and (ii) SHOULD NOT?

> So, I don't envision any change to the text.

Is this a matter of consensus? Or, sensus?

> I've generally assumed this bit would appear only in certs issued to EEs,
> not to CAs.  It might be applicable for some forms of CA certs,  but I
> think the semantics for certs and CRLs and OCSP messages, plus a CA's CSP,
> already provide the necessary (and more definitive) info about the NR
> aspects of data signed with the corresponding private keys.

In a world where anyone can be an issuer (ie, a CA), it makes sense to
make some CAs just informative, not only affirmative.  Even in CA-centric
PKIs it may also be useful for CAs to use the NR bit but on the other way
around (since in PKIX all CAs are just as affirmative as their CPS) --
where the certSign bit could then carry more weight than today's no-warranty
and no-suitability-of-purpose disclaimers, but when combined with the
nonRepudiation bit.  In fact, one could have four combinations of reliance
modes.

Cheers,

Ed Gerck



Received: from po1.bbn.com (PO1.BBN.COM [192.1.50.38]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id KAA27741 for <[e-mail]>; Fri, 6 Aug 1999 10:26:35 -0700 (PDT)
Received: from [128.89.0.110] (COSMEC.BBN.COM [128.89.0.110]) by po1.bbn.com (8.9.1/8.9.1) with ESMTP id NAA07781; Fri, 6 Aug 1999 13:27:01 -0400 (EDT)
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
X-Sender: [e-mail]
Message-Id: <v04020a04b3d0c4b7d037@[128.89.0.110]>
In-Reply-To: <[e-mail]>
References: <v04020a07b3cf66fa3d68@[128.33.238.163]>	 <[e-mail]> <v04020a03b3d0a62117c1@[128.89.0.110]>
Date: Fri, 6 Aug 1999 13:22:37 -0400
To: Ed Gerck <[e-mail]>
From: Stephen Kent <[e-mail]>
Subject: Re: Possible solution?, was Re: Non-Repudiation, was Re: Common   misconceptions, was Re: KISSfor   PKIX.   (Was: RE:ASN.1vs   XML   (used  to be RE: I-D 	ACTION 	 :draft-ietf-pkix-scvp-00.txt))
Cc: "'[e-mail]'" <[e-mail]>

Ed,

>Compare with this:
>
> "Certificates that ascertain the non-repudiation bit MUST be issued by
> the subject."

PKIX does not encourage issuance of certs by end-entities, so this is a
non-starter (to use a buzzword).  One might imagine text such as "A CA
SHOULD NOT issue a certificates asserting the NR key usgae bit unless it
was requested by the Subject."  However, this would preclude certain CA
policies and we don't want to do that.  So, I don't envision any change to
the text.

>This is what I suggested. It also implictly deprecates use of the NR bit
>in those cases where it can be abused -- ie, when subject just passively
>receives a NR cert from an issuer (eg, a commercial CA, a company-wide
>CA, etc.), when the subject has a NR cert signed by a CA but the CA
>neither backs nor indemnifies the ensuing liability; etc.
>
>I believe this solution is a minimum change that would both improve the
>protocol (by being VERY clear) and reduce confusion/fraud.
>
>>   Competent CAs can figure out how they wish to
>> use the bit as part of their policy.
>
>This is useful and is also captured by my suggestion -- CAs can
>self-sign their NR CA certs and can use them as they seem fit. Also,
>any issuer could do the same.

I've generally assumed this bit would appear only in certs issued to EEs,
not to CAs.  It might be applicable for some forms of CA certs,  but I
think the semantics for certs and CRLs and OCSP messages, plus a CA's CSP,
already provide the necessary (and more definitive) info about the NR
aspects of data signed with the corresponding private keys.

Steve


Received: from aum (ip11.proper.com [165.227.249.11]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id JAA26736 for <[e-mail]>; Fri, 6 Aug 1999 09:15:02 -0700 (PDT)
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58 
Date: Fri, 06 Aug 1999 09:15:10 -0700
To: "'[e-mail]'" <[e-mail]>
From: Paul Hoffman / IMC <[e-mail]>
Subject: Re: Possible solution?, was Re: Non-Repudiation
In-Reply-To: <[e-mail]>
References: <v04020a07b3cf66fa3d68@[128.33.238.163]> <[e-mail]> <v04020a03b3d0a62117c1@[128.89.0.110]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed

At 08:57 AM 8/6/1999 -0700, Ed Gerck wrote:
>  "Certificates that ascertain the non-repudiation bit MUST be issued by
>  the subject."

A certificate is an inanimate object. It cannot "ascertain" anything. It 
can't "know" anything. (Yes, I've been guilty of writing about software 
that ascertains and knows, but that's a process, not a format for bits.)

--Paul Hoffman, Director
--Internet Mail Consortium


Received: from edelweb.fr (edelweb.fr [193.51.12.16]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id JAA26553 for <[e-mail]>; Fri, 6 Aug 1999 09:13:44 -0700 (PDT)
Received: from champagne.edelweb.fr (localhost.edelweb.fr [127.0.0.1]) by edelweb.fr with ESMTP id SAA05189; Fri, 6 Aug 1999 18:14:18 +0200 (MET DST)
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 RAA27622; Fri, 6 Aug 1999 17:34:48 +0200 (MET DST)
From: Peter Sylvester <[e-mail]>
Received: (sylvest@localhost) by emeriau.edelweb.fr (8.7.6/8.6.6) id RAA26893; Fri, 6 Aug 1999 17:34:47 +0200 (MET DST)
Date: Fri, 6 Aug 1999 17:34:47 +0200 (MET DST)
Message-Id: <[e-mail]>
To: [e-mail], [e-mail]
Subject: Re: Lets Standardize Time Representation Formats!!!: WAS Re: New TSTTime definition
Cc: [e-mail]

You might look at the DCS draft: it actually says:

DCSTime ::= CHOICE  {
     genTime                      GeneralizedTime,			
     timeStampToken               [1] SignedData  
}

A timeStampToken is either a DCSToken or a TimeStampToken
defined in [TSA]. If a timeStampToken is present, this indicates
the time provided by another DCS or TSA. 





Received: from tomcat.sac.verio.net ([e-mail] [209.162.64.15]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id IAA26190 for <[e-mail]>; Fri, 6 Aug 1999 08:55:00 -0700 (PDT)
Received: from nma.com (pm04-10.sac.verio.net [209.162.64.123]) by tomcat.sac.verio.net (8.9.1a/8.9.1) with ESMTP id IAA07720 for <[e-mail]>; Fri, 6 Aug 1999 08:55:37 -0700 (PDT)
Message-ID: <[e-mail]>
Date: Fri, 06 Aug 1999 08:57:30 -0700
From: Ed Gerck <[e-mail]>
X-Mailer: Mozilla 4.51 [en]C-CCK-MCD {Sony}  (Win98; I)
X-Accept-Language: en
MIME-Version: 1.0
CC: "'[e-mail]'" <[e-mail]>
Subject: Possible solution?, was Re: Non-Repudiation, was Re: Common  misconceptions, was Re: KISSfor   PKIX.   (Was: RE:ASN.1vs   XML   (used  to be RE: I-D 	ACTION 	 :draft-ietf-pkix-scvp-00.txt))
References: <v04020a07b3cf66fa3d68@[128.33.238.163]> <[e-mail]> <v04020a03b3d0a62117c1@[128.89.0.110]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Stephen Kent wrote:

> ...  it is neither necessary nor suff icient, but it is useful in that NOT turining
> on the bit is an explciit declaration that the cert in question ought not
> be used in an NR context.

Compare with this:

 "Certificates that ascertain the non-repudiation bit MUST be issued by
 the subject."

This is what I suggested. It also implictly deprecates use of the NR bit
in those cases where it can be abused -- ie, when subject just passively
receives a NR cert from an issuer (eg, a commercial CA, a company-wide
CA, etc.), when the subject has a NR cert signed by a CA but the CA
neither backs nor indemnifies the ensuing liability; etc.

I believe this solution is a minimum change that would both improve the
protocol (by being VERY clear) and reduce confusion/fraud.

>   Competent CAs can figure out how they wish to
> use the bit as part of their policy.

This is useful and is also captured by my suggestion -- CAs can
self-sign their NR CA certs and can use them as they seem fit. Also,
any issuer could do the same.

Comments?

Cheers,

Ed Gerck



Received: from po1.bbn.com (PO1.BBN.COM [192.1.50.38]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id IAA25813 for <[e-mail]>; Fri, 6 Aug 1999 08:37:27 -0700 (PDT)
Received: from [128.89.0.110] (COSMEC.BBN.COM [128.89.0.110]) by po1.bbn.com (8.9.1/8.9.1) with ESMTP id LAA24607; Fri, 6 Aug 1999 11:37:23 -0400 (EDT)
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
X-Sender: [e-mail]
Message-Id: <v04020a02b3d0af9cdab7@[128.89.0.110]>
In-Reply-To: <029901bee021$180bc640$[e-mail]>
References: <[e-mail]> <v04020a05b3cf5f62a30b@[128.33.238.163]>
Date: Fri, 6 Aug 1999 11:33:27 -0400
To: "tog" <[e-mail]>
From: Stephen Kent <[e-mail]>
Subject: Re: Lets Standardize Time Representation Formats!!!: WAS Re: NewTSTTime definition
Cc: <[e-mail]>

Todd,

This aspect of the time stamp discussion has taken on a rather repititous
tone.  I see a persistant push to accommodate a specific model for TSAs
that is advocated by about 3 people on the list.  Unless I see substantial
additional support for this model, preferably not by people from the same
(very small) set of companies already represented, I will continue to
believe that the WG concensus is NOT to change the model from the one we
adopted long ago.

Steve


Received: from www.meridianus.com (209.249.223.22.has.no.reverse [209.249.223.22] (may be forged)) by mail.proper.com (8.9.3/8.9.3) with ESMTP id IAA25593 for <[e-mail]>; Fri, 6 Aug 1999 08:33:57 -0700 (PDT)
Received: from got.net by www.meridianus.com (8.8.8+Sun/SMI-SVR4) id JAA29014; Fri, 6 Aug 1999 09:28:41 -0700 (PDT)
Message-ID: <[e-mail]>
Date: Fri, 06 Aug 1999 08:34:03 -0700
From: Michael McNeil <[e-mail]>
X-Mailer: Mozilla 4.51 [en] (WinNT; U)
X-Accept-Language: en
MIME-Version: 1.0
To: IETF-PXIX <[e-mail]>
Subject: Basic Event Representation Token (BERT)
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

It's become apparent from comments made at the BERT presentation
in Oslo, others on this list and some received via e-mail that
the purpose and design of Bert aren't well understood within pkix.
I'll briefly try to clear up at least some of the misunderstanding.

One source of confusion, admittedly, was due to my use of slides
in Oslo which, as an example usage of Bert, illustrated a hardware
implementation.  To repeat what was said at that session, those
slides show an example of an application using the Bert Token --
one illustrating a physical situation where fine granularity timing
(much below the second level) might serve a purpose -- and thus a
timestamp format supporting finely grained timing is desirable.

What Bert is is a whole-cloth alternative to the proposed Time Stamp
Protocol (TSP), which can as readily be operated by a trusted third
party down a network remove as by a trusted piece of hardware within
one's own computer.  (Bert is _not_ a TST, the discussion of which
continues on the list, though Bert incorporates a variety of TST
within it -- which, I suggest, for compactness relative to the data,
ought to be the UTC96 representation described in the Bert draft.)

A key difference in the design of the Bert Token versus the Time
Stamp Protocol, as we see it, is that the TSP was clearly designed
with electronic versions of old-style paper documents in mind --
a model which inherently assumes a rather measured pace of
timestamping transactions (contracts to be notarized passing before
a notary public, for example).  The very existence of the discussion
on the list regarding whether granularity of time smaller than that
of a second ought to be supported is proof of that, in my view.

Bert, on the other hand, was designed with _computer_speeds_ in
mind.  Its intent is to enable "events" to be timestamped -- which
might involve, e.g., timestamping cascading crashes of multiple
computer systems being attacked by a worm, say, over a network.
"Events", in other words, which may require timestamps with small
fractions of a second resolution in order for those performing a
post mortem on the involved systems to put the recorded events
into proper chronological sequence, and make sense of them.

Another requirement for Bert is to allow individual transactions to
databases to be timestamped -- with a view of making such databases
inherently non-repudiated.  Since typical transactions to databases
involve a few hundred to a few thousand bytes of data, it's very
important that the timestamp (Bert) be as compact as possible --
no more than a few hundred bytes in length itself, so the addition
of non-repudiation timestamps to the data doesn't vastly bloat the
sizes of legacy databases.  Bert is very compact, in other words.

And yes, _some_ of the applications of Bert might involve hardware
running within a given computer host, rather than an at-network-
remove third-party-run Time Stamping Authority.  In no way, though,
does this mean Bert has particular ties to any vendor's hardware.
 
Regards,
Michael McNeil


Received: from tomcat.sac.verio.net ([e-mail] [209.162.64.15]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id IAA25385 for <[e-mail]>; Fri, 6 Aug 1999 08:31:33 -0700 (PDT)
Received: from nma.com (pm04-10.sac.verio.net [209.162.64.123]) by tomcat.sac.verio.net (8.9.1a/8.9.1) with ESMTP id IAA02231; Fri, 6 Aug 1999 08:31:42 -0700 (PDT)
Message-ID: <[e-mail]>
Date: Fri, 06 Aug 1999 08:33:35 -0700
From: Ed Gerck <[e-mail]>
X-Mailer: Mozilla 4.51 [en]C-CCK-MCD {Sony}  (Win98; I)
X-Accept-Language: en
MIME-Version: 1.0
To: "Robert W. Shirey" <[e-mail]>
CC: [e-mail]
Subject: Re: Correction regarding composition of ISO
References: <v03110717b3d0a5155f06@[192.233.50.115]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

"Robert W. Shirey" wrote:

> Regarding your comment about ISO being a private organization: the
> following is from <draft-shirey-security-glossary-00.txt>, to be announced
> today:

>  ISO
>       (I) International Organization for Standardization, a voluntary,
>       non-treaty organization with voting members that are designated
>       standards bodies of participating nations and non-voting observer
>       organizations. (Also see: ANSI, ITU-T.)

The draft could add that ISO is a Swiss non-profit private corporation,
with website at http://www.iso.ch

Cheers,

Ed Gerck



Received: from www.meridianus.com (209.249.223.38.has.no.reverse [209.249.223.38] (may be forged)) by mail.proper.com (8.9.3/8.9.3) with ESMTP id IAA25144 for <[e-mail]>; Fri, 6 Aug 1999 08:23:08 -0700 (PDT)
Received: from PC1 by www.meridianus.com (8.8.8+Sun/SMI-SVR4) id JAA28983; Fri, 6 Aug 1999 09:12:38 -0700 (PDT)
Message-ID: <029901bee021$180bc640$[e-mail]>
From: "tog" <[e-mail]>
To: "Stephen Kent" <[e-mail]>
Cc: "Manger, James" <[e-mail]>, <[e-mail]>
References: <[e-mail]> <v04020a05b3cf5f62a30b@[128.33.238.163]>
Subject: Re: Lets Standardize Time Representation Formats!!!: WAS Re: NewTSTTime definition
Date: Fri, 6 Aug 1999 08:33:55 -0700
Organization: Meridianus
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.2918.2701
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2918.2701

----- Original Message -----
From: Stephen Kent <[e-mail]>
To: tog <[e-mail]>
Cc: Manger, James <[e-mail]>; <[e-mail]>
Sent: Thursday, August 05, 1999 8:39 AM
Subject: Re: Lets Standardize Time Representation Formats!!!: WAS Re:
NewTSTTime definition


> Todd,
>
> <snip>
>
> >The proofing models for timestamping either need the trust anchors for
the
> >timestamp inside the token structure or as part of the token processing
> >infrastructure itself. It really doesn't work any other way.
>
> <snip>
>
> CAs publish policies stating what they do to ensure accuracy in binding of
> attributes into certificates.  The model PKIX has been following for TSAs
> is the same, i.e., a clientr decides to rely on a TSA or not, based on a
> disclosed policy.

Another oversight in the proofing process model IMHO

> This approach does not require embedding data in support
> of verification of TSA operations.

No then there needs to be someway to online verify that the cert polices and
practices fit in with what I as the relying party will accept. If you do not
put thise trust anchor points in the policy control models, then we will
need yet another flaming protocol to evaluate RPA (Relying Party Agreements)
online to see if the CPS and RPA's are compatible with our instance of PKI
requirements.

Thats part of the jumble that in my opinion and makes interoperating with
PKI a nightmare. I have to verify each CA services models becuase we wont
allow for this type of trust information then the open networking overhead
will kill many types of Point-Of-Sale PKI Transactions.

> The only extent to which your state
> above applies in this model is that the signature applied by the TSA can
be
> used to verify the source of the time stamp, and that can be used to make
a
> decision as to whether the time stamp is acceptable (based on the TSA's
> policy).

Except this adds an extra step that is easily eliminated by adding a simple
and optional amount of info to the TST itself.

>
> Steve
>

Todd



Received: from po1.bbn.com (PO1.BBN.COM [192.1.50.38]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id IAA24813 for <[e-mail]>; Fri, 6 Aug 1999 08:11:06 -0700 (PDT)
Received: from [128.89.0.110] (COSMEC.BBN.COM [128.89.0.110]) by po1.bbn.com (8.9.1/8.9.1) with ESMTP id LAA21110; Fri, 6 Aug 1999 11:10:49 -0400 (EDT)
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
X-Sender: [e-mail]
Message-Id: <v04020a03b3d0a62117c1@[128.89.0.110]>
In-Reply-To: <[e-mail]>
References: <v04020a07b3cf66fa3d68@[128.33.238.163]> <[e-mail]>
Date: Fri, 6 Aug 1999 11:06:12 -0400
To: Ed Gerck <[e-mail]>
From: Stephen Kent <[e-mail]>
Subject: Re: Non-Repudiation, was Re: Common misconceptions, was Re:  KISSfor   PKIX.   (Was: RE:ASN.1vs   XML   (used to be RE: I-D 	ACTION 	  :draft-ietf-pkix-scvp-00.txt))
Cc: "'[e-mail]'" <[e-mail]>

Ed,
>
>I believe you are correct and that is why the approach is wrong -- because
>this WG has been implictly using a concept which cannot stand even outside
>a court of law.  I also believe that, eventually, the ISO authors will come
>to realize that there is no such a thing as "irrefutable evidence" and
>thus such a thing cannot be 'made available' or 'validated' either.  But,
>again,
>since ISO is a private company, they may never do so.  However, I see
>no need for this WG to be bound by anything that ISO declares, or even try
>to change what ISO declares -- since ISO is simply a private company that
>is free to follow its own way.
>
>The reported ISO NR framework is IMO amiss also in a most fundamental
>aspect: that NR is *neither* a stronger authentication *nor* added data in
>support of an authentication act -- but a different act altogether.

I appreciate Denis pointing out the more recent ISO definition for NR, but
I don't think it substantially detracts from my point about the differences
between technical definitions of the sort we will use in this WG vs. ones
developed by the legal community as it attempts to understand the technical
capabilities being developed.

I do agree with your observation that NR not only embodies authentication
(and integrity) but also exhibits properties that distinguish it from these
other base security services.  Still, this WG needs to discuss these
services in a technical context, not a legal one.

>And that is why NR can exist (as I can show if needed) even in pure protocol
>terms in systems that rely only on symmetrically shared secrets (contrary to
>Dave's expectation that NR would not exist in such systems).  And, as Aram
>exemplified and as I agree, NR can also be provided by non-protocol means.

One can, by fiat, declare any mechanism/procedure to offer NR.  In a sense,
that is what the banking community did for many years with the use of X9.9.
However, we are a technical WG and our goal, in this case, is to device
infrastructure in suppport of NR in a technical sense.

>There were also some questions raised by Steve, which I will reply in
>separate but there is one which links to this msg and which I will deal
>with here:
>
> "Setting the NR bit does not ensure anything, and I don';t think anyone said
> it did. It is a declaration of intent with respect to key usage, by a CA.
> It is a component of the overall set of evidence that a RP would collect to
> help counter an attempt at repudiation by the subject of the certificate.
> That's all."
>
>This text says that Alice (the r-p) will trust to a certain extent a NR
>declaration
>by a CA in regard to *all* messages to be signed by a key purportedly
>held by Bob.  But, who is solely responsible for the private-key's security?
>Who signs each message? Who verifies each message before being sent
>to Alice? Who backs and indemnifies such trust? The CA? No, it is Bob in
>all counts.  So, NR is not a "bulk" property that can follow a "push" model
>but one that depends on *each* message and must (as I previously
>exemplified in several metrics) involve some mechanism of challenge-response.
>Which again shows what is wrong with ISO's "irrefutable evidence"  NR
>model -- NR cannot be produced by an "irrefutable oracle" approach.

The NR bit may not be a declaration by a CA, but a passthrough of a
declaration by the subject on the intended use of the private key
corresponding to the public key in the certificate.  In some cases, CA
policy may simply says that it passes on whatever KU bits the subject
selects, or it may refuse to set some bits requested by the subject.

>In fact, examples have been produced here showing that the "NR bit"
>in PKIX:
>
>- is neither necessary nor sufficient for NR;
>
>- can be very confusing to users (since it declares what it does not provide),
>even to sophisticated users such as a US State government contractor;
>
>- mislead CAs with a "standards-compliant" procedure to issue ineffectual
>certificates (since NR depends on actions by the subscriber, not by the CA);
>
>- wrongly shift the user's focus from the subscriber to the CA so that the
>liability is fully reflected to the user itself (even if the CA is a company
>issuing NR certs to employees as Steve asked for);
>
>- presents a serious security risk for "death penalty certificates" as if
>higher
>security could be achieved by increasing the value at stake (ie, with NR
>certs that carry a higher risk burden if stolen by a hacker -- and, so
>the notion goes, would thus be "better guarded by the subscriber");
>
>- should be restricted to self-signed certs in PKIX;
>
>- should be deprecated for any other use.

At least the latter 4 of the above statements are not true, or merely
represent your view, vs. an objective statement.  The list extensively
discussed the question of whether this bit might be confusing, and although
there was some sentiment that it might be, the concensus was to keep it. it
is neither necessary nor suff icient, but it is useful in that NOT turining
on the bit is an explciit declaration that the cert in question ought not
be used in an NR context.   Competent CAs can figure out how they wish to
use the bit as part of their policy.

Steve


Received: from www.meridianus.com (209.249.223.12.has.no.reverse [209.249.223.12] (may be forged)) by mail.proper.com (8.9.3/8.9.3) with ESMTP id HAA24501 for <[e-mail]>; Fri, 6 Aug 1999 07:55:53 -0700 (PDT)
Received: from PC1 by www.meridianus.com (8.8.8+Sun/SMI-SVR4) id IAA28936; Fri, 6 Aug 1999 08:50:32 -0700 (PDT)
Message-ID: <028b01bee01e$02123160$[e-mail]>
From: "tog" <[e-mail]>
To: "Peter Sylvester" <[e-mail]>
Cc: <[e-mail]>
References: <[e-mail]>
Subject: Re: Lets Standardize Time Representation Formats!!!: WAS Re: New TSTTime definition
Date: Fri, 6 Aug 1999 08:11:49 -0700
Organization: Meridianus
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.2918.2701
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2918.2701

That works fine for me, but lets add one then -
>
> IMHO one should keep these formats separated and not mixed.
>
>    CHOICE {
> genTime Generalizedtime
> bintime SEQUENCE  { whatever encodeing of seconds, leqpseconds, fractions
>          precision ... }
> }
>    }
>
> Peter
>

Pardon my sloppy ASN.1 - but you get the point -

CHOICE {
genTime Generalizedtime
bintime SEQUENCE  { whatever encodeing of seconds, leqpseconds, fractions
                                    precision ... }
SecureTime     SignedGeneralizedtime
}

and

SignedGeneralizedTime {
AuthSig            SEQUENCE { SigBlockLen, signature type, alg, and the
accompanying signature for bintime, resource} OPTIONAL
bintime SEQUENCE  { whatever encodeing of seconds, leqpseconds, fractions
                                    precision ... }
}

Then its just a matter of defining the resource types that are accepted and
maybe building OIDs to support those.

Todd




Received: from www.meridianus.com (209.249.223.11.has.no.reverse [209.249.223.11] (may be forged)) by mail.proper.com (8.9.3/8.9.3) with ESMTP id HAA24251 for <[e-mail]>; Fri, 6 Aug 1999 07:48:01 -0700 (PDT)
Received: from PC1 by www.meridianus.com (8.8.8+Sun/SMI-SVR4) id IAA28904; Fri, 6 Aug 1999 08:39:37 -0700 (PDT)
Message-ID: <028001bee01c$7c1a7f50$[e-mail]>
From: "tog" <[e-mail]>
To: "Denis Pinkas" <[e-mail]>, "Stephen Kent" <[e-mail]>
Cc: "Manger, James" <[e-mail]>, <[e-mail]>
References: <[e-mail]> <v04020a05b3cf5f62a30b@[128.33.238.163]> <[e-mail]>
Subject: Re: Lets Standardize Time Representation Formats!!!: WAS Re: New TSTTime definition
Date: Fri, 6 Aug 1999 08:00:54 -0700
Organization: Meridianus
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.2918.2701
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2918.2701

Denis,
----- Original Message -----
From: Denis Pinkas <[e-mail]>
To: Stephen Kent <[e-mail]>
Cc: tog <[e-mail]>; Manger, James
<[e-mail]>; <[e-mail]>
Sent: Thursday, August 05, 1999 11:58 PM
Subject: Re: Lets Standardize Time Representation Formats!!!: WAS Re: New
TSTTime definition


> > Todd,
> >
> >         <snip>
> >
> > >The proofing models for timestamping either need the trust anchors for
the
> > >timestamp inside the token structure or as part of the token processing
> > >infrastructure itself. It really doesn't work any other way.
> >
> >         <snip>
> >
> > CAs publish policies stating what they do to ensure accuracy in binding
of
> > attributes into certificates.  The model PKIX has been following for
TSAs
> > is the same, i.e., a clientr decides to rely on a TSA or not, based on a
> > disclosed policy. This approach does not require embedding data in
support
> > of verification of TSA operations.
>
> I fully support this position and your statement, Steve.
>
> Denis

This is true and seems totally based in that no one driving these standards
in PKIX  have talked to the physicists to see how they have been dealing
with highly accurate timebases in their data collection models for the last
30 years. The fact of the matter is that we as a collective group choked on
this one. Highly accurate and provable timeservices have been around for
years.

As to it's not being spec'd into X.509 - we think that this is an oversight
as well, and a growing number of us are forming to propose a certified
timebase and other trust anchors be defined as a recommended service
interface to support better trust than plain generic X.509 does by itsself.
Especially in AC's.

For timestamping to be what we all know it can be, it desparately needs to
be able to fulfill the emerging audit requirements and secure timesources
and their logging are part of that, in no uncertain terms.

Todd






Received: from po1.bbn.com (PO1.BBN.COM [192.1.50.38]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id HAA24076 for <[e-mail]>; Fri, 6 Aug 1999 07:45:29 -0700 (PDT)
Received: from [192.233.50.115] ([192.233.50.115]) by po1.bbn.com (8.9.1/8.9.1) with ESMTP id KAA17899; Fri, 6 Aug 1999 10:45:39 -0400 (EDT)
X-Sender: [e-mail]
Message-Id: <v03110717b3d0a5155f06@[192.233.50.115]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Fri, 6 Aug 1999 10:46:47 -0400
To: Ed Gerck <[e-mail]>
From: "Robert W. Shirey" <[e-mail]>
Subject: Correction regarding composition of ISO
Cc: [e-mail]

Regarding your comment about ISO being a private organization: the
following is from <draft-shirey-security-glossary-00.txt>, to be announced
today:

 ISO
      (I) International Organization for Standardization, a voluntary,
      non-treaty organization with voting members that are designated
      standards bodies of participating nations and non-voting observer
      organizations. (Also see: ANSI, ITU-T.)

      (C) ISO and the IEC (the International Electrotechnical
      Commission) form the specialized system for worldwide
      standardization. (ISO is a class D member of ITU-T.) National
      bodies that are members of ISO or IEC participate in developing
      international standards through ISO and IEC technical committees
      that deal with particular fields of activity. (ANSI is the U.S.
      voting member of ISO.) Other international organizations,
      governmental and non-governmental, in liaison with ISO and IEC,
      also take part. In information technology, ISO and IEC have a
      joint technical committee, ISO/IEC JTC 1.




Received: from tomcat.sac.verio.net ([e-mail] [209.162.64.15]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id HAA23887 for <[e-mail]>; Fri, 6 Aug 1999 07:43:32 -0700 (PDT)
Received: from nma.com (pm04-26.sac.verio.net [209.162.64.139]) by tomcat.sac.verio.net (8.9.1a/8.9.1) with ESMTP id HAA22688; Fri, 6 Aug 1999 07:43:59 -0700 (PDT)
Message-ID: <[e-mail]>
Date: Fri, 06 Aug 1999 07:45:51 -0700
From: Ed Gerck <[e-mail]>
X-Mailer: Mozilla 4.51 [en]C-CCK-MCD {Sony}  (Win98; I)
X-Accept-Language: en
MIME-Version: 1.0
To: Denis Pinkas <[e-mail]>
CC: "'[e-mail]'" <[e-mail]>
Subject: Re: Non-Repudiation, was Re: Common misconceptions, was Re: 	KISSfor  PKIX.   (Was: RE:ASN.1vs   XML   (used to be RE: I-D 	ACTION 	 :draft-ietf-pkix-scvp-00.txt))
References: <v04020a07b3cf66fa3d68@[128.33.238.163]> <[e-mail]> <[e-mail]> <[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Denis Pinkas wrote:

> Ed,
>
> (text deleted)
>
> > Dennis and WG friends:
> >
> > I believe you are correct and that is why the approach is wrong -- because
> > this WG has been implictly using a concept which cannot stand even outside
> > a court of law.  I also believe that, eventually, the ISO authors will come
> > to realize that there is no such a thing as "irrefutable evidence" and
> > thus such a thing cannot be 'made available' or 'validated' either.  But, again,
> > since ISO is a private company, they may never do so.  However, I see
> > no need for this WG to be bound by anything that ISO declares, or even try
> > to change what ISO declares -- since ISO is simply a private company that
> > is free to follow its own way.
>
> A small detail:
>
> ISO is not a private company, but an international organization.
> ANSI is a member of ISO.

This is a common misconception, and I say this with no argumentative
intent -- ISO is neither "international" (status reserved for bodies such
as WIPO) nor "public".  As a matter of law, ISO has no special stature
whatsoever, nor do their standards.

Let me quote a comment by Tony Rutkowski, elsewhere:

------------begin quote---------
Sorry to disagree - but the International Organization for Standardization
(which is its correct name) is a PRIVATE organization.  I don't mean to
be argumentative, but this is one of my specialities, and as an official
was responsible for ISO relations.  PUBLIC organizations are those established
by treaty instruments among governmental members.  PRIVATE organizations
are those created by incorporation in some jurisdiction.  The ISO is
such a creature.  I have a copy of its "constitution" on my bookshelf
and it exists as a Swiss non-profit corporation.  The fact that national
standards bodies are its members does not make it a public corporation.
In a number of cases, those national bodies are just non-profit organizations
themselves.  The US member is ANSI - a private, non-profit corporation.

The term "international agreement" has no significance whatsoever.
It simply infers that two or more parties from different places in
the works effected some agreement.  Similarly, the "used by government"
criteria is not particularly significant, as governments use all kinds
of standards - even tcp/ip. :-)

Again, I'm not denigrating ISO.  It's just that as a matter of law,
they have no special stature whatsoever, nor do their standards.
------------end quote-----------

Further info in [http://www.iso.ch/infoe/intro.htm#What is ISO]
(note: this is one of those pesky URLs that include spaces).


Cheers,

Ed Gerck




Received: from po1.bbn.com (PO1.BBN.COM [192.1.50.38]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id HAA23451 for <[e-mail]>; Fri, 6 Aug 1999 07:22:00 -0700 (PDT)
Received: from [128.89.0.110] (COSMEC.BBN.COM [128.89.0.110]) by po1.bbn.com (8.9.1/8.9.1) with ESMTP id KAA14569; Fri, 6 Aug 1999 10:20:56 -0400 (EDT)
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
X-Sender: [e-mail]
Message-Id: <v04020a00b3d09bccaa3d@[128.89.0.110]>
In-Reply-To: <[e-mail]>
Date: Fri, 6 Aug 1999 10:11:27 -0400
To: "Aram Perez" <[e-mail]>
From: Stephen Kent <[e-mail]>
Subject: Re: Non-Repudiation
Cc: [e-mail]

Aram,

The term "digital signature" has a well defined meaning in the technical
literature, and was specifically coined in the context of public key
cryptography, although one can achieve analogous features via symmetric
crypto.

[Also note that your characterization of signing a hash by "encrypting" it
is not correct, in general, e.g., DSA does not encrypt a hash to sign it.]

The term "signature" is more generally applied, and is more broadly defined
outside of the technical area in which we are working. Hence a definitoion
from a dictionary for the term signature does not address our debate.

The X9.9 standard was written at a time when the distinction was clear and
that's why that standard does not confuse matters by refering to a MAC as a
signature, much less a digital signature.  A critical aspect of a digital
signature is that the ability to verify it is cryptogra[hically distinct
from the ability to generate it.  That asymmetry is essential if signatures
are to be used to support NR.

I would argue that your example of a MAC does not fit this definition, as
the controls used to effect asymmetry are procedural, not cryptographic.
We have about 20 years of technical literature on this topic, most of which
is quite consistent in the use of this terminology.

Steve


Received: from clbull.frcl.bull.fr (clbull.frcl.bull.fr [129.182.8.31]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id GAA22972 for <[e-mail]>; Fri, 6 Aug 1999 06:55:29 -0700 (PDT)
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 PAA16626; Fri, 6 Aug 1999 15:56:05 +0200
Message-ID: <[e-mail]>
Date: Fri, 06 Aug 1999 15:55:56 +0200
From: Denis Pinkas <[e-mail]>
Organization: Bull
X-Mailer: Mozilla 4.06 [fr] (Win95; I)
MIME-Version: 1.0
To: Ed Gerck <[e-mail]>
CC: "'[e-mail]'" <[e-mail]>
Subject: Re: Non-Repudiation, was Re: Common misconceptions, was Re: 	KISSfor  PKIX.   (Was: RE:ASN.1vs   XML   (used to be RE: I-D 	ACTION 	 :draft-ietf-pkix-scvp-00.txt))
References: <v04020a07b3cf66fa3d68@[128.33.238.163]> <[e-mail]> <[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Ed,

(text deleted)

> Dennis and WG friends:
> 
> I believe you are correct and that is why the approach is wrong -- because
> this WG has been implictly using a concept which cannot stand even outside
> a court of law.  I also believe that, eventually, the ISO authors will come
> to realize that there is no such a thing as "irrefutable evidence" and
> thus such a thing cannot be 'made available' or 'validated' either.  But, again,
> since ISO is a private company, they may never do so.  However, I see
> no need for this WG to be bound by anything that ISO declares, or even try
> to change what ISO declares -- since ISO is simply a private company that
> is free to follow its own way.

A small detail:

ISO is not a private company, but an international organization.
ANSI is a member of ISO.

Regards,

Denis


Received: from tomcat.sac.verio.net ([e-mail] [209.162.64.15]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id GAA22364 for <[e-mail]>; Fri, 6 Aug 1999 06:19:34 -0700 (PDT)
Received: from nma.com (pm02-21.sac.verio.net [209.162.64.40]) by tomcat.sac.verio.net (8.9.1a/8.9.1) with ESMTP id GAA10251 for <[e-mail]>; Fri, 6 Aug 1999 06:20:09 -0700 (PDT)
Message-ID: <[e-mail]>
Date: Fri, 06 Aug 1999 06:21:57 -0700
From: Ed Gerck <[e-mail]>
X-Mailer: Mozilla 4.51 [en]C-CCK-MCD {Sony}  (Win98; I)
X-Accept-Language: en
MIME-Version: 1.0
CC: "'[e-mail]'" <[e-mail]>
Subject: Re: Non-Repudiation, was Re: Common misconceptions, was Re: 	KISSfor  PKIX.   (Was: RE:ASN.1vs   XML   (used to be RE: I-D 	ACTION 	 :draft-ietf-pkix-scvp-00.txt))
References: <v04020a07b3cf66fa3d68@[128.33.238.163]> <[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Denis Pinkas wrote:

> Steve,
>
> I would like to point out that the definition you are refering to is
> only applicable to the OSI model (it is in part 2 of the OSI model).
> Since then ISO has been considering NR on a broader scale and has
> produced the NR framework (ISO 10181-4) where the scope of NR has
> been enlarged.
>
> In the introduction the text says:
>
> "The goal of the NR service is to collect, maintain, make available
> and validate irrefutable evidence concerning a claimed event or
> action in order to resolve disputes about the occurence of the event
> or action".
>
> The event or action can be a communication, but does not need to be.
>
> I believe that we are implicitely using that concept in the WG.

Dennis and WG friends:

I believe you are correct and that is why the approach is wrong -- because
this WG has been implictly using a concept which cannot stand even outside
a court of law.  I also believe that, eventually, the ISO authors will come
to realize that there is no such a thing as "irrefutable evidence" and
thus such a thing cannot be 'made available' or 'validated' either.  But, again,
since ISO is a private company, they may never do so.  However, I see
no need for this WG to be bound by anything that ISO declares, or even try
to change what ISO declares -- since ISO is simply a private company that
is free to follow its own way.

The reported ISO NR framework is IMO amiss also in a most fundamental
aspect: that NR is *neither* a stronger authentication *nor* added data in
support of an authentication act -- but a different act altogether.

And that is why NR can exist (as I can show if needed) even in pure protocol
terms in systems that rely only on symmetrically shared secrets (contrary to
Dave's expectation that NR would not exist in such systems).  And, as Aram
exemplified and as I agree, NR can also be provided by non-protocol means.

There were also some questions raised by Steve, which I will reply in
separate but there is one which links to this msg and which I will deal with here:

 "Setting the NR bit does not ensure anything, and I don';t think anyone said
 it did. It is a declaration of intent with respect to key usage, by a CA.
 It is a component of the overall set of evidence that a RP would collect to
 help counter an attempt at repudiation by the subject of the certificate.
 That's all."

This text says that Alice (the r-p) will trust to a certain extent a NR declaration
by a CA in regard to *all* messages to be signed by a key purportedly
held by Bob.  But, who is solely responsible for the private-key's security?
Who signs each message? Who verifies each message before being sent
to Alice? Who backs and indemnifies such trust? The CA? No, it is Bob in
all counts.  So, NR is not a "bulk" property that can follow a "push" model
but one that depends on *each* message and must (as I previously
exemplified in several metrics) involve some mechanism of challenge-response.
Which again shows what is wrong with ISO's "irrefutable evidence"  NR
model -- NR cannot be produced by an "irrefutable oracle" approach.

In fact, examples have been produced here showing that the "NR bit"
in PKIX:

- is neither necessary nor sufficient for NR;

- can be very confusing to users (since it declares what it does not provide),
even to sophisticated users such as a US State government contractor;

- mislead CAs with a "standards-compliant" procedure to issue ineffectual
certificates (since NR depends on actions by the subscriber, not by the CA);

- wrongly shift the user's focus from the subscriber to the CA so that the
liability is fully reflected to the user itself (even if the CA is a company
issuing NR certs to employees as Steve asked for);

- presents a serious security risk for "death penalty certificates" as if higher
security could be achieved by increasing the value at stake (ie, with NR
certs that carry a higher risk burden if stolen by a hacker -- and, so
the notion goes, would thus be "better guarded by the subscriber");

- should be restricted to self-signed certs in PKIX;

- should be deprecated for any other use.

Cheers,

Ed Gerck



Received: from staffmail.digex.net (staffmail.digex.net [204.91.98.210]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id FAA21651 for <[e-mail]>; Fri, 6 Aug 1999 05:17:47 -0700 (PDT)
Received: from ntb-300553 (pix000104.staff.digex.net [206.205.168.116]) by staffmail.digex.net (8.9.1/8.9.1) with SMTP id IAA11926 for <[e-mail]>; Fri, 6 Aug 1999 08:18:24 -0400 (EDT)
From: "Jason Lamar" <[e-mail]>
To: <[e-mail]>
Subject: 
Date: Fri, 6 Aug 1999 08:20:56 -0400
Message-ID: <000001bee006$22c739e0$[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
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3

auth dbe46d1d unsubscribe ietf-pkix \


Received: from edelweb.fr (edelweb.fr [193.51.12.16]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id CAA17041 for <[e-mail]>; Fri, 6 Aug 1999 02:41:17 -0700 (PDT)
Received: from champagne.edelweb.fr (localhost.edelweb.fr [127.0.0.1]) by edelweb.fr with ESMTP id LAA25381; Fri, 6 Aug 1999 11:41:50 +0200 (MET DST)
Received: from champagne.edelweb.fr (champagne.edelweb.fr [193.51.14.161]) by edelweb.fr (nospam/1.1); Fri, 6 Aug 1999 11:41:50 +0200 (MET DST)
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 LAA25073; Fri, 6 Aug 1999 11:41:49 +0200 (MET DST)
From: Peter Sylvester <[e-mail]>
Received: (sylvest@localhost) by emeriau.edelweb.fr (8.7.6/8.6.6) id LAA26803; Fri, 6 Aug 1999 11:41:49 +0200 (MET DST)
Date: Fri, 6 Aug 1999 11:41:49 +0200 (MET DST)
Message-Id: <[e-mail]>
To: [e-mail]
Subject: Re: Lets Standardize Time Representation Formats!!!: WAS Re: New TSTTime definition
Cc: [e-mail]

> >
> > The issue is: why does the TSTTime consist of GeneralizedTime plus
> > more stuff, when that additional stuff merely duplicates in a
> > confusing way what you can already represent with GeneralizedTime?
> 
> Quite simply becuase I have no reason to believe that the timedata in the
> TST is any good.

This seems the wrong answer to a good question, or a answer to 
a question that has not been asked: 

- It seems to me that the model behind GeneralizedTime is to
  have something that corresponds to what human being experience
  all days; calendars and clocks. Furthermore leap seconds don't
  seem to exist in that world. 
  Humans are used to life with that, so be it. 

- Counting model for clocks with arbitrary precision like the NTP
  format or else don't seem to be for end user consumption. 
  Nevertheless I don't see why one should not be able to produce
  time stamps in that format. 

IMHO one should keep these formats separated and not mixed. 

   CHOICE {
	genTime Generalizedtime 
	bintime SEQUENCE  { whatever encodeing of seconds, leqpseconds, fractions
         precision ... }
	}
   }

Peter


Received: from clbull.frcl.bull.fr (clbull.frcl.bull.fr [129.182.8.31]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id AAA11872 for <[e-mail]>; Fri, 6 Aug 1999 00:08:44 -0700 (PDT)
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 JAA12078; Fri, 6 Aug 1999 09:08:04 +0200
Message-ID: <[e-mail]>
Date: Fri, 06 Aug 1999 09:07:56 +0200
From: Denis Pinkas <[e-mail]>
Organization: Bull
X-Mailer: Mozilla 4.06 [fr] (Win95; I)
MIME-Version: 1.0
To: Stephen Kent <[e-mail]>
CC: Aram Perez <[e-mail]>, "'[e-mail]'" <[e-mail]>
Subject: Re: Non-Repudiation, was Re: Common misconceptions, was Re: 	 KISSfor PKIX.   (Was: RE:ASN.1vs   XML   (used to be RE: I-D 	ACTION 	 :draft-ietf-pkix-scvp-00.txt))
References: <v04020a07b3cf66fa3d68@[128.33.238.163]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Steve,

I would like to point out that the definition you are refering to is
only applicable to the OSI model (it is in part 2 of the OSI model).
Since then ISO has been considering NR on a broader scale and has
produced the NR framework (ISO 10181-4) where the scope of NR has
been enlarged.

In the introduction the text says:

"The goal of the NR service is to collect, maintain, make available
and validate irrefutable evidence concerning a claimed event or
action in order to resolve disputes about the occurence of the event
or action".

The event or action can be a communication, but does not need to be.

I believe that we are implicitely using that concept in the WG.

Denis 

 
> Ed & Aram,
> 
> >>> This is an IETF (technica)l WG, not the ABA Technical Committee on Digital
> >>> Signatures. The technical definition of NR that we use comes from ISO
> >>> 7498-2.  Paraphrasing (since I don't have the spec in front of me on this
> >>> plane flight), NR is defined as a security service employed to prevent a
> >>> party in a communication from later denying having participated in the
> >>> communication.   Time is not mentioned explicitly, but because the
> >>> communication took place at some time, it is an implied component of NR.
> >>
> >> Steve, so many things are "implied" -- that one needs to be careful not
> >> to have "implied security" as well.  What I mean is that we need clear
> >> and well-defined concepts, if we want clear results. If NR is "to prevent
> >> a party in a communication from later denying having participated in the
> >> communication" as you say above then we must immediatley agree that NR
> >> does not exist and never will.
> >
> >I totally agree with Ed. I can always deny (a.k.a. repudiate) participating
> >in a communication. And, at least in the US where I am presumed innocent
> >until proven guilty, it would be up to the other party to prove that I did
> >participate. However, this does not preclude me from agreeing to a
> >non-repudiation clause in a contract where I agree that my digital signature
> >signifies my participation in a communication.
> 
> Sorry that you both disagree with the standard (technical) definition of
> NR, but that's what were sticking with in this WG.
> 
> >[snip]
> >>
> >> Thus, all I am saying is that the definition of NR being used in this WG
> >> is wrong and I don't care who defined it and where you based it -- while
> >> I also point out that ISO is a private organization, which definitions can
> >> be used or not and that none of them is some sort of "international treaty"
> >> or even "standard" or "fact".
> >
> >Again Ed is correct, the definition of NR is wrong. Quoting for the PKIX
> >Roadmap:
> >
> >     "Security depends
> >      on all parts of the  certificate-using SYSTEM, including but not
> >      limited to: physical security of the place the computer resides;
> >      personnel security (i.e., the trustworthiness of the people who
> >      actually develop, install, run, and maintain the system); the
> >      security provided by the operating system on which the private key
> >      is used; and the security provided the CA.  A failure in any one
> >      of these areas can cause the entire system security to fail."
> >
> >How can setting the NR bit ensure that there isn't a "failure in any one of
> >those areas"?
> 
> Setting the NR bit does not ensure anything, and I don';t think anyone said
> it did. It is a declaration of intent with respect to key usage, by a CA.
> It is a component of the overall set of evidence that a RP would collect to
> help counter an attempt at repudiation by the subject of the certificate.
> That's all.
> 
> steve


Received: from clbull.frcl.bull.fr (clbull.frcl.bull.fr [129.182.8.31]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id XAA10874 for <[e-mail]>; Thu, 5 Aug 1999 23:59:17 -0700 (PDT)
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 IAA18388; Fri, 6 Aug 1999 08:58:28 +0200
Message-ID: <[e-mail]>
Date: Fri, 06 Aug 1999 08:58:20 +0200
From: Denis Pinkas <[e-mail]>
Organization: Bull
X-Mailer: Mozilla 4.06 [fr] (Win95; I)
MIME-Version: 1.0
To: Stephen Kent <[e-mail]>
CC: tog <[e-mail]>, "Manger, James" <[e-mail]>, [e-mail]
Subject: Re: Lets Standardize Time Representation Formats!!!: WAS Re: New TSTTime definition
References: <[e-mail]> <v04020a05b3cf5f62a30b@[128.33.238.163]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

> Todd,
> 
>         <snip>
> 
> >The proofing models for timestamping either need the trust anchors for the
> >timestamp inside the token structure or as part of the token processing
> >infrastructure itself. It really doesn't work any other way.
> 
>         <snip>
> 
> CAs publish policies stating what they do to ensure accuracy in binding of
> attributes into certificates.  The model PKIX has been following for TSAs
> is the same, i.e., a clientr decides to rely on a TSA or not, based on a
> disclosed policy. This approach does not require embedding data in support
> of verification of TSA operations.  

I fully support this position and your statement, Steve.

Denis


> The only extent to which your state
> above applies in this model is that the signature applied by the TSA can be
> used to verify the source of the time stamp, and that can be used to make a
> decision as to whether the time stamp is acceptable (based on the TSA's
> policy).
> 
> Steve


Received: from www.meridianus.com (209.249.223.26.has.no.reverse [209.249.223.26] (may be forged)) by mail.proper.com (8.9.3/8.9.3) with ESMTP id WAA07551 for <[e-mail]>; Thu, 5 Aug 1999 22:40:03 -0700 (PDT)
Received: from PC1 by www.meridianus.com (8.8.8+Sun/SMI-SVR4) id XAA28486; Thu, 5 Aug 1999 23:34:37 -0700 (PDT)
Message-ID: <022e01bedfd0$55f67780$[e-mail]>
From: "tog" <[e-mail]>
To: "Paul Koning" <[e-mail]>
Cc: <[e-mail]>, <[e-mail]>
References: <[e-mail]><013d01bedf54$04c467e0$[e-mail]> <[e-mail]>
Subject: Re: Lets Standardize Time Representation Formats!!!: WAS Re: New TSTTime definition
Date: Thu, 5 Aug 1999 22:55:49 -0700
Organization: Meridianus
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.2918.2701
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2918.2701

----- Original Message -----
From: Paul Koning <[e-mail]>
To: <[e-mail]>
Cc: <[e-mail]>; <[e-mail]>
Sent: Thursday, August 05, 1999 7:55 AM
Subject: Re: Lets Standardize Time Representation Formats!!!: WAS Re: New
TSTTime definition


> >>>>> "tog" == tog  <[e-mail]> writes:
>
>  >> good[0] one already exists?" rant).  There's already a standard,
>  >> well-defined way to
>  >> represent time values, why invent another one?
>
>  tog> becuase there is nothing here except the time data. If we want
>  tog> an accompanying sense of credibility for the timedata then ASN.1
>  tog> would needs a signedTime format. The actual representation of
>  tog> the timedata is simple, its what is mandated with it to prove
>  tog> its credibility that's the question here.
>
> Exactly.  You do need to take an unsigned time format and apply a
> signature to it.  That isn't the issue.
>
> The issue is: why does the TSTTime consist of GeneralizedTime plus
> more stuff, when that additional stuff merely duplicates in a
> confusing way what you can already represent with GeneralizedTime?

Quite simply becuase I have no reason to believe that the timedata in the
TST is any good.

>
> paul
>



Received: from mail-out2.apple.com (mail-out2.apple.com [17.254.0.51]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id RAA08027 for <[e-mail]>; Thu, 5 Aug 1999 17:44:29 -0700 (PDT)
Received: from mailgate1.apple.com (A17-128-100-225.apple.com [17.128.100.225]) by mail-out2.apple.com (8.8.5/8.8.5) with ESMTP id RAA29270 for <[e-mail]>; Thu, 5 Aug 1999 17:45:05 -0700
Received: from scv1.apple.com (scv1.apple.com) by mailgate1.apple.com (mailgate1.apple.com- SMTPRS 2.0.15) with ESMTP id <[e-mail]> for <[e-mail]>; Thu, 05 Aug 1999 17:45:00 -0700
Received: from [17.205.41.166] (aram1.apple.com [17.205.41.166]) by scv1.apple.com (8.9.3/8.9.3) with ESMTP id RAA40662 for <[e-mail]>; Thu, 5 Aug 1999 17:45:00 -0700
Message-Id: <[e-mail]>
X-Mailer: Microsoft Outlook Express Macintosh Edition - 4.5 (0410)
Date: Thu, 05 Aug 1999 17:44:58 -0700
Subject: Re: Some thoughts on TST time precision
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

And to second what Bill Lattin wrote, not too long ago, many programmers and
technical folks thought that two digits was all you would ever need to
represent the year ;-)

Aram Perez

> We continue to debate the required amount of time precision required with
> some arguing that only resolution to the level of a second is required.
>
> Here is an anecdote - a long time ago, about 15 years, the telecommunication
> industry could think of no useful reason to provide telephone call
> 'timestamps' to a precision of less than 6 seconds (1/10th minute).  Hence
> bills were computed on the basis of call lengths with a granualrity of
> 1/10th a minute.
>
> Then along came Asynchronous Transfer Mode, ATM.  All of a sudden you had
> companies offering long distance service where they would initiate and
> disconnect a 'call' in less than 6 seconds, yet send 5 seconds worth of
> packets.  These companies managed to get free telephone service, because of
> an outdated time stamp precision.
>
> Now telcos plan to have a Call Time Stamp Precision of 1 millisecond.
>
> To give an idea of the rapid advance of timing precision requirements. In
> 1980, datum timing was mostly 1 second resolution.  After the advent of
> microprocessor based timing, 1 millisecond became the standard.  In the
> 1990's with GPS, 1 microsecond became the standard and 10s of a nanosecond
> became the holy grail.
>
> The standard should support at least 1 microsecond for applications 10 years
> from now
> that we don't conceive of now.
>
> Let's not be guilty of a short event horizon.
>
> Cheers,
>
> Bill Lattin
>



Received: from mail-out2.apple.com (mail-out2.apple.com [17.254.0.51]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id RAA07774 for <[e-mail]>; Thu, 5 Aug 1999 17:40:10 -0700 (PDT)
Received: from mailgate1.apple.com (A17-128-100-225.apple.com [17.128.100.225]) by mail-out2.apple.com (8.8.5/8.8.5) with ESMTP id RAA65908 for <[e-mail]>; Thu, 5 Aug 1999 17:40:47 -0700
Received: from scv1.apple.com (scv1.apple.com) by mailgate1.apple.com (mailgate1.apple.com- SMTPRS 2.0.15) with ESMTP id <[e-mail]> for <[e-mail]>; Thu, 05 Aug 1999 17:40:38 -0700
Received: from [17.205.41.166] (aram1.apple.com [17.205.41.166]) by scv1.apple.com (8.9.3/8.9.3) with ESMTP id RAA44396 for <[e-mail]>; Thu, 5 Aug 1999 17:40:37 -0700
Message-Id: <[e-mail]>
X-Mailer: Microsoft Outlook Express Macintosh Edition - 4.5 (0410)
Date: Thu, 05 Aug 1999 17:40:35 -0700
Subject: Re: Non-Repudiation
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

Steve Kent wrote:

> Aram,
> 
>>This is not correct. In a previous job, we built a system using DES where
>>party A could only sign (using ANSI X9.9) and party B could only verify.
>>With party A, all the keys were kept on hardware tokens and required dual
>>control: a Security Administrator (SA) to start the system and the Signing
>>Offer (SO) to enable the signature process. The signing key was the
>>combination of the SA and SO keys. A similar setup existed at party B. With
>>this system, I could prove (in a court of law) that the signature was
>>generated by party A and not by party B.
>
> This is a misuse of the term "sign" and it not consistent with the language
> of X9.9.

Though you may consider it may be a misuse of the term "sign", the system
was designed to replace handwritten signatures. Instead of the SO signing a
paper document with his/her handwritten signature, he/she would "sign" (or
append a MAC) an electronic version of the document (on a system that could
only be started up by the SA).

>  X9.9 specifies a MAC, and a MAC is not a signature, period!

I'm don't understand why you state that "a MAC is not a signature, period!"
The following is not a legal definition or the most accurate, but according
to "http://www.dictionary.com/cgi-bin/dict.pl?term=signature" the definition
is: "signature \Sig"na*ture\, n. [F. (cf. It. signatura,
    segnatura, Sp. & LL. signatura), from L. signare, signatum, v. t.]
   1. A sign, stamp, or mark impressed, as by a seal.
   2. Especially, the name of any person, written with his own
      hand, employed to signify that the writing which precedes
      accords with his wishes or intentions; a sign manual; an
      autograph."

So why is an encrypted hash anymore a signature than a MAC?

> While
> the banking community has long treated MACs as though they provide
> technical support for NR, we all understand that a MAC is a poor technical
> basis for such a service.

I'm not sure if you are including me in the "we all understand ...", but the
"owners" of the system believed it was good enough. For non-disclosure
reasons I can't provide more more detail, but the system handled millions of
dollars.

>  In your example, collaboration by the SA and SO
> at the receiver could generate a MAC indistinguishable from that produced
> by the sender.

In that system, the SO was the sender. Given the that receiver/relying party
could not generate a MAC but only verify it.

Regards,
Aram Perez


Received: from scaup.prod.itd.earthlink.net (scaup.prod.itd.earthlink.net [207.217.121.49]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id RAA07040 for <[e-mail]>; Thu, 5 Aug 1999 17:07:56 -0700 (PDT)
Received: from lattin (1Cust114.tnt22.sfo3.da.uu.net [208.254.230.114]) by scaup.prod.itd.earthlink.net (8.9.3/8.9.3) with SMTP id RAA03966 for <[e-mail]>; Thu, 5 Aug 1999 17:08:26 -0700 (PDT)
From: "Bill Lattin" <[e-mail]>
To: <[e-mail]>
Subject: Some thoughts on TST time precision
Date: Thu, 5 Aug 1999 17:07:48 -0700
Message-ID: <000001bedf9f$b793bf60$72e6fed0@lattin>
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.2106.4

We continue to debate the required amount of time precision required with
some arguing that only resolution to the level of a second is required.

Here is an anecdote - a long time ago, about 15 years, the telecommunication
industry could think of no useful reason to provide telephone call
'timestamps' to a precision of less than 6 seconds (1/10th minute).  Hence
bills were computed on the basis of call lengths with a granualrity of
1/10th a minute.

Then along came Asynchronous Transfer Mode, ATM.  All of a sudden you had
companies offering long distance service where they would initiate and
disconnect a 'call' in less than 6 seconds, yet send 5 seconds worth of
packets.  These companies managed to get free telephone service, because of
an outdated time stamp precision.

Now telcos plan to have a Call Time Stamp Precision of 1 millisecond.

To give an idea of the rapid advance of timing precision requirements. In
1980, datum timing was mostly 1 second resolution.  After the advent of
microprocessor based timing, 1 millisecond became the standard.  In the
1990's with GPS, 1 microsecond became the standard and 10s of a nanosecond
became the holy grail.

The standard should support at least 1 microsecond for applications 10 years
from now
that we don't conceive of now.

Let's not be guilty of a short event horizon.

Cheers,

Bill Lattin



Received: from po1.bbn.com (PO1.BBN.COM [192.1.50.38]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id QAA06272 for <[e-mail]>; Thu, 5 Aug 1999 16:43:27 -0700 (PDT)
Received: from [128.33.238.250] (tc238-250.bbn.com [128.33.238.250]) by po1.bbn.com (8.9.1/8.9.1) with ESMTP id TAA18155; Thu, 5 Aug 1999 19:43:54 -0400 (EDT)
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
X-Sender: [e-mail] (Unverified)
Message-Id: <v04020a0bb3cf6c928deb@[128.33.238.163]>
In-Reply-To: <[e-mail]>
References: <v04020a02b3b3e54bc992@[128.33.238.108]>		 <v04020a00b3b56b6383a7@[128.33.238.45]>	 <v04020a03b3be21dccc3c@[128.33.238.37]> <v04020a06b3ccc179271f@[128.33.238.37]>
Date: Thu, 5 Aug 1999 12:37:31 -0400
To: Ed Gerck <[e-mail]>
From: Stephen Kent <[e-mail]>
Subject: Re: Non-Repudiation, was Re: Common misconceptions, was Re: KISSfor   PKIX.   (Was: RE:ASN.1vs   XML   (used to be RE: I-D 	ACTION    :draft-ietf-pkix-scvp-00.txt))
Cc: "'[e-mail]'" <[e-mail]>

Ed,


>>
>> Aside: Could you be related to Bob Jueneman?  In the anals of IETF WG
>> mailing lists, only he has tended to send such long, detailed messages, as
>> well as being so involved in the legal aspects of PKI :-}.
>
>I have noticed another similarity between myself and Bob Jueneman. We both
>tend
>to reply to all relevant items in an email, even if it tends to disprove a
>former msg or
>shed a different light upon it.

An admirable trait!

>> This is an IETF (technica)l WG, not the ABA Technical Committee on Digital
>> Signatures. The technical definition of NR that we use comes from ISO
>> 7498-2.  Paraphrasing (since I don't have the spec in front of me on this
>> plane flight), NR is defined as a security service employed to prevent a
>> party in a communication from later denying having participated in the
>> communication.   Time is not mentioned explicitly, but because the
>> communication took place at some time, it is an implied component of NR.
>
>Steve, so many things are "implied" -- that one needs to be careful not to
>have
>"implied security" as well.  What I mean is that we need clear and
>well-defined
>concepts, if we want clear results. If NR is "to prevent a party in a
>communication
>from later denying having participated in the communication" as you say above
>then we must immediatley agree that NR does not exist and never will.

We do not agree.  Admittedly, the phrasing above is incorrect in that
anyone can deny anything.  A more accurate statement would be that an
attempt by a party to deny participation in a communication should be
rejected based on evidence provided by NR mechanism.

>Further, if I also mention that NR depends on trust and all I hear from
>you is that
>Tina Turner would have said it differently then I must assume that trust
>is also "implied"
>in that definition you use.

Trust is not implied in the definition of the service.  The service
definition does not specify a mechanism by which the service is provided
and thus what trust might be required, based on the mechanism, is not a
part of the definition.

>Thus, all I am saying is that the definition of NR being used in this WG
>is wrong
>and I don't care who defined it and where you based it -- while I also
>point out
>that ISO is a private organization, which definitions can be used or not
>and that
>none of them is some sort of "international treaty" or even "standard" or
>"fact".

Sorry that you disagree, but we will continue to use this technical
defintion of NR in this WG.

<snip>

Steve


Received: from po1.bbn.com (PO1.BBN.COM [192.1.50.38]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id QAA06205 for <[e-mail]>; Thu, 5 Aug 1999 16:43:22 -0700 (PDT)
Received: from [128.33.238.250] (tc238-250.bbn.com [128.33.238.250]) by po1.bbn.com (8.9.1/8.9.1) with ESMTP id TAA18138; Thu, 5 Aug 1999 19:43:39 -0400 (EDT)
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
X-Sender: [e-mail] (Unverified)
Message-Id: <v04020a09b3cf698dd82a@[128.33.238.163]>
In-Reply-To: <[e-mail]>
References: <[e-mail]>
Date: Thu, 5 Aug 1999 12:19:48 -0400
To: Ed Gerck <[e-mail]>
From: Stephen Kent <[e-mail]>
Subject: Re: Non-Repudiation, was Re: Common misconceptions, was Re:KISSfor   PKIX.   (Was: RE:ASN.1vs   XML   (used to be RE: I-D   ACTION:draft-ietf-pkix-scvp-00.txt))
Cc: "'[e-mail]'" <[e-mail]>

Ed,

<snip>

>It is not "assent" because if the CA would assume this role or even
>merely imply it, then that power to assent or co-assent to a key
>usage by the subscriber would make the CA liable or co-liable for
>that key's usage.
>
>
>> How far does that get anyone?  Not far. It is a bit like you want to
>> climb Mt. Everest, and to "support you" in this endeavor, I announce
>> that I will not stand in your way.
>
>But... "I will charge for not standing in your way".  What this means is that
>CAs now have two  "products": one with NR and another without NR--
>and both are "standards-compliant".  The product without NR costs X and
>warrants Z. The product with NR costs Y but also warrants Z, where
>Y > X.  In other words, a "value-add" without the value ;-)
>
>The subscriber not only pays more (ie, needs at least two certs) but has
>now a larger liability.  Mere usage of that private-key NR cert (say, by a
>hacker that snatched the private-key NR cert and broke the password)
>at any time will imply NR.  Which is a good thing since such liability
>argument can easily be defeated in law -- since the subscriber had no
>power to deny it and was at the mercy of uncontrollable events (hackers
>are, knowingly, uncontrollable and can penetrate even high-security
>government networks).


Your analysis seems to assume that all CAs are TTPs, selling a service.
Another model is that organizations act as their own CAs, issuing certs to
employees, customers, etc., in which case the preceeding analysis is
inapplicable.

<snip>

steve


Received: from po1.bbn.com (PO1.BBN.COM [192.1.50.38]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id QAA06185 for <[e-mail]>; Thu, 5 Aug 1999 16:43:20 -0700 (PDT)
Received: from [128.33.238.250] (tc238-250.bbn.com [128.33.238.250]) by po1.bbn.com (8.9.1/8.9.1) with ESMTP id TAA18143; Thu, 5 Aug 1999 19:43:49 -0400 (EDT)
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
X-Sender: [e-mail] (Unverified)
Message-Id: <v04020a0ab3cf6ad324c5@[128.33.238.163]>
In-Reply-To: <[e-mail]>
Date: Thu, 5 Aug 1999 12:26:17 -0400
To: "Aram Perez" <[e-mail]>
From: Stephen Kent <[e-mail]>
Subject: Re: Non-Repudiation
Cc: [e-mail]

Aram,

>This is not correct. In a previous job, we built a system using DES where
>party A could only sign (using ANSI X9.9) and party B could only verify.
>With party A, all the keys were kept on hardware tokens and required dual
>control: a Security Administrator (SA) to start the system and the Signing
>Offer (SO) to enable the signature process. The signing key was the
>combination of the SA and SO keys. A similar setup existed at party B. With
>this system, I could prove (in a court of law) that the signature was
>generated by party A and not by party B.

This is a misuse of the term "sign" and it not consistent with the language
of X9.9.  X9.9 specifies a MAC, and a MAC is not a signature, period! While
the banking community has long treated MACs as though they provide
technical support for NR, we all understand that a MAC is a poor technical
basis for such a service.  In your example, collaboration by the SA and SO
at the receiver could generate a MAC indistinguishable from that produced
by the sender.

Steve


Received: from po1.bbn.com (PO1.BBN.COM [192.1.50.38]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id QAA06128 for <[e-mail]>; Thu, 5 Aug 1999 16:43:03 -0700 (PDT)
Received: from [128.33.238.250] (tc238-250.bbn.com [128.33.238.250]) by po1.bbn.com (8.9.1/8.9.1) with ESMTP id TAA18076; Thu, 5 Aug 1999 19:42:42 -0400 (EDT)
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
X-Sender: [e-mail] (Unverified)
Message-Id: <v04020a07b3cf66fa3d68@[128.33.238.163]>
In-Reply-To: <[e-mail]>
Date: Thu, 5 Aug 1999 12:13:32 -0400
To: "Aram Perez" <[e-mail]>
From: Stephen Kent <[e-mail]>
Subject: Re: Non-Repudiation, was Re: Common misconceptions, was Re: 	 KISSfor PKIX.   (Was: RE:ASN.1vs   XML   (used to be RE: I-D 	ACTION 	 :draft-ietf-pkix-scvp-00.txt))
Cc: "'[e-mail]'" <[e-mail]>

Ed & Aram,

>>> This is an IETF (technica)l WG, not the ABA Technical Committee on Digital
>>> Signatures. The technical definition of NR that we use comes from ISO
>>> 7498-2.  Paraphrasing (since I don't have the spec in front of me on this
>>> plane flight), NR is defined as a security service employed to prevent a
>>> party in a communication from later denying having participated in the
>>> communication.   Time is not mentioned explicitly, but because the
>>> communication took place at some time, it is an implied component of NR.
>>
>> Steve, so many things are "implied" -- that one needs to be careful not
>> to have "implied security" as well.  What I mean is that we need clear
>> and well-defined concepts, if we want clear results. If NR is "to prevent
>> a party in a communication from later denying having participated in the
>> communication" as you say above then we must immediatley agree that NR
>> does not exist and never will.
>
>I totally agree with Ed. I can always deny (a.k.a. repudiate) participating
>in a communication. And, at least in the US where I am presumed innocent
>until proven guilty, it would be up to the other party to prove that I did
>participate. However, this does not preclude me from agreeing to a
>non-repudiation clause in a contract where I agree that my digital signature
>signifies my participation in a communication.

Sorry that you both disagree with the standard (technical) definition of
NR, but that's what were sticking with in this WG.

>[snip]
>>
>> Thus, all I am saying is that the definition of NR being used in this WG
>> is wrong and I don't care who defined it and where you based it -- while
>> I also point out that ISO is a private organization, which definitions can
>> be used or not and that none of them is some sort of "international treaty"
>> or even "standard" or "fact".
>
>Again Ed is correct, the definition of NR is wrong. Quoting for the PKIX
>Roadmap:
>
>     "Security depends
>      on all parts of the  certificate-using SYSTEM, including but not
>      limited to: physical security of the place the computer resides;
>      personnel security (i.e., the trustworthiness of the people who
>      actually develop, install, run, and maintain the system); the
>      security provided by the operating system on which the private key
>      is used; and the security provided the CA.  A failure in any one
>      of these areas can cause the entire system security to fail."
>
>How can setting the NR bit ensure that there isn't a "failure in any one of
>those areas"?

Setting the NR bit does not ensure anything, and I don';t think anyone said
it did. It is a declaration of intent with respect to key usage, by a CA.
It is a component of the overall set of evidence that a RP would collect to
help counter an attempt at repudiation by the subject of the certificate.
That's all.

steve


Received: from po1.bbn.com (PO1.BBN.COM [192.1.50.38]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id QAA06055 for <[e-mail]>; Thu, 5 Aug 1999 16:41:46 -0700 (PDT)
Received: from [128.33.238.250] (tc238-250.bbn.com [128.33.238.250]) by po1.bbn.com (8.9.1/8.9.1) with ESMTP id TAA17987; Thu, 5 Aug 1999 19:40:37 -0400 (EDT)
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
X-Sender: [e-mail] (Unverified)
Message-Id: <v04020a05b3cf5f62a30b@[128.33.238.163]>
In-Reply-To: <03c701bede87$dfb588c0$[e-mail]>
References: <[e-mail]>
Date: Thu, 5 Aug 1999 11:39:45 -0400
To: "tog" <[e-mail]>
From: Stephen Kent <[e-mail]>
Subject: Re: Lets Standardize Time Representation Formats!!!: WAS Re: New TSTTime definition
Cc: "Manger, James" <[e-mail]>, <[e-mail]>

Todd,

	<snip>

>The proofing models for timestamping either need the trust anchors for the
>timestamp inside the token structure or as part of the token processing
>infrastructure itself. It really doesn't work any other way.

	<snip>

CAs publish policies stating what they do to ensure accuracy in binding of
attributes into certificates.  The model PKIX has been following for TSAs
is the same, i.e., a clientr decides to rely on a TSA or not, based on a
disclosed policy. This approach does not require embedding data in support
of verification of TSA operations.  The only extent to which your state
above applies in this model is that the signature applied by the TSA can be
used to verify the source of the time stamp, and that can be used to make a
decision as to whether the time stamp is acceptable (based on the TSA's
policy).

Steve


Received: from www.meridianus.com (209.249.223.29.has.no.reverse [209.249.223.29] (may be forged)) by mail.proper.com (8.9.3/8.9.3) with ESMTP id NAA03661 for <[e-mail]>; Thu, 5 Aug 1999 13:39:05 -0700 (PDT)
Received: from got.net by www.meridianus.com (8.8.8+Sun/SMI-SVR4) id OAA28073; Thu, 5 Aug 1999 14:33:39 -0700 (PDT)
Message-ID: <[e-mail]>
Date: Thu, 05 Aug 1999 13:38:45 -0700
From: Michael McNeil <[e-mail]>
X-Mailer: Mozilla 4.51 [en] (WinNT; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Peter Sylvester <[e-mail]>
CC: [e-mail]
Subject: Re: Lets Standardize Time Representation Formats!!!: WAS Re: New TSTTime  definition
References: <[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Peter Sylvester wrote:
>This message is not a flame, there is no intention for any personal
>attack, although it might sound like so in some comments,

I didn't notice any such!

>>Denis to using your words - Creating yet another representation of
>>time in a PKIX tool also 'seems pointless'.

I agree with that.

>BERT provides yet another representation of
>'time' <--> GeneralizedTime in PKI, or date in rfc822

BERT's representation of time is a slight modification to one
which has long existed, enshrined in various RFCs -- that of NTP.
The modification is one which I've proposed (and presented at the
Stime meeting at Oslo) to defeat NTP's upcoming millennium problem.

>'identifiers' <--> generalname in pki
>'policyidentifier' <--> object id
>'signature'     <--> existing structures in pki+object ids for
>algorithms

BERT is still incomplete in these definitions; you might also have
criticized that some of these elements aren't (yet) defined in the
draft.  The intention (soon) is to reconcile these with other usage.

>it seems that some people have forgotten why we have leap seconds
>inserted sometimes (and not additional leap minutes). The intension
>is to make them invisible in real life applications. Or better,
>don't fix all real life applications by adding code to support
>leap seconds because you just need them once per 5 years.

Leap seconds actually occur about one every eighteen months these
days.  (The rate increases as time goes on and the Earth slows;
the current rate has been accumulated over the last century.)

Leap _years_, however -- a single day -- only occur every four
years; every eight years in the vicinity of the average century.
How many people should buy a calendar program that ignored them?

>The earth is the center of the universe (as Bert seems to tell us.)

Not at all.  Bert simply utilizes a coordinate system which, at the
moment, is relevant for nearly all of human affairs -- but which
is fully convertible into any other coordinate system that is
convenient.  If other coordinate systems become important, new
Bert "types" can be created which incorporate these systems.

However, except for planetary coordinate systems for those standing
on those planets, just about any other coordinate system is going to
have things moving about rather than remaining at fixed coordinates.

>>My point is that we don't know all the uses yet - and if we limit
>>ourselves to representing time at the same level of granularity
>>that the OS designers thought was relevant - Ahahahahahahah -
>>Well it just seemed a bit funny since we already know that it is
>>not clean enough. If you don't believe me call the stock exchanges
>>and find out what and how they use timedata/timesources for.

>Event arrive in ORDER, and the only relevant thing is the order,
>and not the absolute time value.

You're absolutely right, but it's also true that the absolute time
value (within limitations imposed by the space-time continuum --
relativity rules!) is the best tool we have (the best ruler against
which we can peg events) to help us put events into their proper
chronological order, and thus assist in making sense of them.

>Put a broker into a shuttle and look at the consequences. The only
>requirement is the order of two events, and sorry, you can give any
>resolution you want, something can arrive at 'the same moment' using
>whatever clock you use as external source, and you just decide who
>came first. A high resolution real time counter counts faster that
>you an make personal decisions, thus it is usable as a pure counter
>(and just gives an addtional convenient information).

That's why having a high resolution real time clock is a good idea,
and why the time in the timestamp should have a resolution much
finer than any practical usage -- to provide a smooth continuum
for expressing any possible time to any possible resolution.

>None of these 'facts' should be used. They are not necessary:
>
>- one second resultion is proposed only because
>  - we first overlooked that there was a subdivision (remember that
>    the initial draft just had an integer indicating milliseconds.
>  - existing certificats use seconds. I don't see a problem, a
>    CORRECT comparison of GeneralizedTime isn't rocket science
>    (leaving apart Challenger and Ariane 5).

There's even a saying I've heard of late that "rocket science isn't
rocket science."  Of course quite a few space rockets have blown up
recently, so maybe that's not such a good motto to take to heart.

>>What this entire thread seems to overlook or negate is that:
>>    o-    even in SW only systems,  that sub-millisecond precision
>>time is easily distributed in networking models. IRIG-B timecode
>>and NTP have been doing this *for decades* already.

>No it doesn't in principle. waht it negates is that real
>applications and HUMAN decisions need a higher precision. Tell
>me a real application with non-repudiation where you really need
>more than counting within the smallest observable time period for
>a human being (a second, or may be a little bit less than that).
>(if not, see my last comment).

Reminds me of an apocryphal story of a British commission early
in this century which decided that the automobile had no future
across the Atlantic in the United States -- because in all the
U.S.A. there was at the time no more than a few hundred miles of
_road_.  Sometimes these things change, the needed infrastructure
gets built.  Who would have predicted more than a handful of years
ago that every computer in every home in America (in the world...)
would need to be connected to the Internet, just to shop, to do
research, to read world newspapers -- as early as 1999?

I predict that these applications will be built, they will
appear -- and much faster than many people expect.  They will
initially be designed to operate in close proximity -- within
as close a fraction of a second as they can -- of temporal
boundary points with clear financial consequences, stock
closing times and the like.  Time will tell the tale.

Meanwhile, setting up a timestamp time format so that fine
subsecond precision is _impossible_, because we the designers
of the format decided no one would ever need it, is simply
silly.  It's like doing a repetition of the Y2K problem -- just
as that problem is about to climax.  One would think that we as
people would learn; but just as folks over the ages returned
after Pompeii to the slopes of Vesuvius (or, here in California,
live in the shadow of volcanic Mount Shasta), we make the same
mistakes, slightly differently each time, over and over again.
(What's the saying?  "History doesn't repeat itself, but
sometimes it rhymes.")

>The scenarios is a little bit more complex. A time stamp service
>and any form of notarisation service can be operated in a chain.
>Somewhere a clients asks some local service, the local service
>either provides it directly, or has to be backed up by another
>external service or more of them.

>BTW: Where is the external reference for spatial coordinates?
>I am here, and I can see the top of the Eiffel tower, do you
>trust me?

GPS is a possible source for location information.  Some future
secure-GPS system would be even better.  A fixed mounting, such
as within a building, might have the location wired in.  The
source and quality of the spatial information, as with the
temporal, should be identified, but needn't be the same.

>It seems that you misunderstood time and time stamp. I can make a
>time stamp 'number 9986557555787687', it comes before  'number
>9986557556787686', I record somewhere that I have issued time
>stamp X just at some time, in order to establish a convenient way
>of using it. The time stamp is the stamp of MY TIME, and nothing
>more.

Kind of like each community before the coming of the railroads;
each had its own time.  Then the railroads came, and they for
all practical purposes forced each community (at least within
a time zone, and convertible between) to keep the _same_ time.

What I'm saying is that the existence of Internet commerce will
basically force each TSA to keep the same (good) time, with which
they will calibrate their internal counters, and as a result of
which the counters from different TSAs will be fully comparable.

>>My point is that there needs to both be interoperability
>>in timestamping, as in all PKI, and in particular in the
>>representation of the other cornerstone trust element, like
>>the "Time" that an event is supposed to happened...and that
>>the granularity is really needed in the submillisecond range.

>No, a time stamp has nothing to do with when an event has
>happened, it is my time that I tell after perception of the
>event.

Since the former follows the latter by a (presumably small)
interval, it clearly does have something to do with it.

>Why do you stop at a granularity of 32 bits? I want 20 decimal
>digit time stamps in the next millenium.

As mentioned elsewhere, a 32-bit fractional second resolution
pins time down to a granularity wherein light travels a mere
3 inches (7 cm).  I do have some qualms about this, however, as
3 inches is certainly a macroscopic distance, and scientists
will definitely want to pin things down more accurately.  So,
reasoned arguments that a 2^(-64) second resolution is needed
might find me receptive.  However, for nearly every practical
(versus laboratory) purpose, 2^(-32) second is satisfactory.

>I want them human readable without a conversion of a binary digits.

Do you also want the Moon, as a bauble you can close your hand on?
Can you read computer media, without conversion and presentation?

>Someone told me once: Whenever you can remove one additional
>parameter, you divide you problems by 2 (I told that to myself
>BTW).

Actually, it's for a similar reason that I favor the NTP time
format over calendric.  The time server must keep count of the
current leap second count, and as a result TAI (atomic time)
is available.  TAI is simply a seconds count which marches one
standard second at a time towards infinity -- none of this
years-months-weeks-days-hours-minutes-seconds-microseconds-leap
seconds-leap years-AD-BC -- GAH!  Just a simple seconds count,
then call well-established software when desired to convert
into the calendar of your choice (and there are many calendars
in use today around the world, not just the conventional).

A pure standard seconds count, to my mind, is much less
"geocentric" (since we're talking geocentric) than our complex
calendric system, so closely tied to the cycles of the Earth.

>Peter Sylvester
>Not signed but simply written at PARIS (5th floor Montparnasse
>tour if you need more precision)

_Is_ the Eiffel Tower visible?  (I trust you!)

>PS: let's avoid reinventing the wheel. take the single element
>which is supposed to generalize a time event, if this is not
>sufficient, one can always propose a correction, for example
>addition a precision in readable form after the zone.

Regards,
Michael McNeil


Received: from mail-out2.apple.com (mail-out2.apple.com [17.254.0.51]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id LAA29654 for <[e-mail]>; Thu, 5 Aug 1999 11:05:21 -0700 (PDT)
Received: from mailgate1.apple.com (A17-128-100-225.apple.com [17.128.100.225]) by mail-out2.apple.com (8.8.5/8.8.5) with ESMTP id LAA05632 for <[e-mail]>; Thu, 5 Aug 1999 11:05:56 -0700
Received: from scv1.apple.com (scv1.apple.com) by mailgate1.apple.com (mailgate1.apple.com- SMTPRS 2.0.15) with ESMTP id <[e-mail]> for <[e-mail]>; Thu, 05 Aug 1999 11:05:45 -0700
Received: from [17.205.41.166] (aram1.apple.com [17.205.41.166]) by scv1.apple.com (8.9.3/8.9.3) with ESMTP id LAA45698 for <[e-mail]>; Thu, 5 Aug 1999 11:05:45 -0700
Message-Id: <[e-mail]>
X-Mailer: Microsoft Outlook Express Macintosh Edition - 4.5 (0410)
Date: Thu, 05 Aug 1999 11:05:44 -0700
Subject: Committee on Commerce News Release:
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

For the US folks, stay tuned, E-SIGN bill approved by the House Commerce 
Committee, see
http://com-notes.house.gov/cchear/hearings106.nsf/eeae8466ba03a2158525677f00
4b4d11/c40d48774b04bb02852567c400601e67?OpenDocument

Maybe if it becomes law, it will solve the NR issue ;-)

Still having fun,
Aram Perez


Received: from mail-out1.apple.com (mail-out1.apple.com [17.254.0.52]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id KAA29175 for <[e-mail]>; Thu, 5 Aug 1999 10:53:35 -0700 (PDT)
Received: from mailgate1.apple.com (A17-128-100-225.apple.com [17.128.100.225]) by mail-out1.apple.com (8.8.5/8.8.5) with ESMTP id KAA38934 for <[e-mail]>; Thu, 5 Aug 1999 10:54:09 -0700
Received: from scv1.apple.com (scv1.apple.com) by mailgate1.apple.com (mailgate1.apple.com- SMTPRS 2.0.15) with ESMTP id <[e-mail]> for <[e-mail]>; Thu, 05 Aug 1999 10:53:59 -0700
Received: from [17.205.41.166] (aram1.apple.com [17.205.41.166]) by scv1.apple.com (8.9.3/8.9.3) with ESMTP id KAA45636 for <[e-mail]>; Thu, 5 Aug 1999 10:53:58 -0700
Message-Id: <[e-mail]>
X-Mailer: Microsoft Outlook Express Macintosh Edition - 4.5 (0410)
Date: Thu, 05 Aug 1999 10:53:57 -0700
Subject: Re: Non-Repudiation
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

David Kemp wrote:
> 
>> From: Tony Bartoletti <[e-mail]>
>>
>> The NR-bit was intended (I believe) so that (for instance) the dutiful
>> vendor of contract-signing software would code "Sorry, I can't sign this
>> contract with this key, its (cert's) NR-bit is 0."  And likewise,
>> vendors of (say) routine data-packet authentication software would code
>> "Sorry, I can't sign these packets with this key, its NR-bit is 1."
>
> Close.  My interpretation is that each application checks only the bit
> corresponding to the function being performed.
>
> If the app is verifying the signature on a cert, it ensures that
> keyCertSign is set and ignores all others.
>
> If it is a contract signing application, it checks that nonRepudiation
> is set and ignores the others.
>
> If it is doing data authentication with signatures (CMS signedData), it
> checks that digitalSignature is set and ignores the others.
>
> If it is doing symmetric key data authentication and/or encryption
> (SSL/TLS), it should check that keyAgreement or keyEncipherment is
> set, and ignore the others.  I don't believe it should make any
> difference to SSL/TLS whether the NR bit is set or not - TLS
> applications should look only at the KA or KE bits.
>
> The TLS Security Considerations might point out the implication of
> using a single key (with both KA/KE and NR set) in both a web browser
> and the contract-signing application, but that is something for the CA
> and the user to consider; the TLS app shouldn't care.
>
>
> (As an aside, the dataEncipherment bit "is asserted when the subject
> public key is used for enciphering user data, other than cryptographic
> keys".  No general-purpose protocols use public key encryption of
> arbitrary-length user data, so the dataEncipherment bit should almost
> never be used.)

Your statements are correct if you assume that your applications are using a
general purpose, but very low level crypto API such as RSA's BSAFE or MS
CAPI. The trouble is that I can write an application that bypasses all the
checks you've just stated. If you use what a call a "good" crypto API, then
you can enforce the three basic key usages: data encipherment, key
agreement/exchange and authentication/signatures. Then I can't write
applications that violate the basic key usages. If you try to limit/control
anything beyond the basic key usages, then you have to start interpreting
the data stream which means you can't have a general purpose crypto API.

Regards,
Aram Perez


Received: from wodc7-1.relay.mail.uu.net (wodc7-1.relay.mail.uu.net [199.171.54.114]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id KAA27509 for <[e-mail]>; Thu, 5 Aug 1999 10:03:33 -0700 (PDT)
Received: from xedia.com by wodc7mr0.ffx.ops.us.uu.net with SMTP  (peer crosschecked as: madway.xedia.com [198.202.232.199]) id QQhazc12008; Thu, 5 Aug 1999 17:04:04 GMT
Received: from tonga.xedia.com by xedia.com (4.1/SMI-4.1) id AA04746; Thu, 5 Aug 99 13:02:38 EDT
Received: by tonga.xedia.com (SMI-8.6/SMI-SVR4) id NAA00815; Thu, 5 Aug 1999 13:04:01 -0400
Date: Thu, 5 Aug 1999 13:04:01 -0400
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: Lets Standardize Time Representation Formats!!!: WAS Re: New TSTTime definition
References: <[e-mail]>
X-Mailer: VM 6.34 under 20.3 "Vatican City" XEmacs  Lucid

>>>>> "tgindin" == tgindin  <[e-mail]> writes:
> The issue is: why does the TSTTime consist of
> GeneralizedTime plus more stuff, when that additional stuff
> merely duplicates in a confusing way what you can already
> represent with GeneralizedTime?

 tgindin> [Tom Gindin] I think that the main reason for having any
 tgindin> other field in TSTTime is that DER encoding of
 tgindin> GeneralizedTime removes trailing zeroes, and thus precision
 tgindin> cannot be inferred from it.  The only field other than
 tgindin> GeneralizedTime which is really needed is precision, because
 tgindin> DER eliminates the possibility of correctly inferring the
 tgindin> precision from the value presented.

That's true. 

The field under discussion, I think, is "subsecond".

	paul


Received: from mail-out1.apple.com (mail-out1.apple.com [17.254.0.52]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id JAA26326 for <[e-mail]>; Thu, 5 Aug 1999 09:34:00 -0700 (PDT)
Received: from mailgate1.apple.com (A17-128-100-225.apple.com [17.128.100.225]) by mail-out1.apple.com (8.8.5/8.8.5) with ESMTP id JAA48158 for <[e-mail]>; Thu, 5 Aug 1999 09:34:27 -0700
Received: from scv1.apple.com (scv1.apple.com) by mailgate1.apple.com (mailgate1.apple.com- SMTPRS 2.0.15) with ESMTP id <[e-mail]> for <[e-mail]>; Thu, 05 Aug 1999 09:32:16 -0700
Received: from [17.205.41.166] (aram1.apple.com [17.205.41.166]) by scv1.apple.com (8.9.3/8.9.3) with ESMTP id JAA46190 for <[e-mail]>; Thu, 5 Aug 1999 09:32:16 -0700
Message-Id: <[e-mail]>
X-Mailer: Microsoft Outlook Express Macintosh Edition - 4.5 (0410)
Date: Thu, 05 Aug 1999 09:32:16 -0700
Subject: Re: Non-Repudiation
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

Alfred Arsenault wrote:

> "Flanigan, Bill" wrote:
>> 
>> Dave,
>> 
>>         This one-bit failure thing gets scary when you, say, escrow a
>> dataEnciperment key pair without the nonRepudiation bit set, but with the
>> digitalSignature bit set.
>
> AWA:  First of all, don't do that.  Yes, I know, some people will
> because the architecture of their systems is such that they don't
> support separate keys for digitalSignature and dataEncipherment, and
> they want to be able to recover their encrypted mail after losing their
> keys, but don't even get me started on the lack of wisdom in such a
> system design!

If it is such a bad idea (and I totally agree with you), why does the PKIX
allow it? Why can't PKIX state you can have one or the other but not both?

[snip]
>
>  - The intent of the NonRepudiation bit was, as Dave Kemp has pointed
> out, to show that the CA is willing to say that this certificate is
> intended/permitted to be used in signing things for which their is hope
> of providing the service of nonrepudiation, as defined in 7498-2 and
> paraphrased by Steve Kent.  The intent of this bit is to explicitly
> distinguish such certs/keys from those only intended/permitted to be
> used in providing the service of authentication via the signing of
> short-term entities.

I personally would not trust a CA that certifies a public key based on some
"*hope* of providing the service of nonrepudiation". And if it is a
"service" of non-repudiation, then this information should be placed a
service extension not in a key usage bit.

>   - what the CA does before signing a certificate with the
> NonRepudiation bit set is a matter left to the CA's CP and/or CPS.  So
> is the division of liability between any given CA and user.  If you as
> the user don't like the CA's rejection of liability, don't do business
> with that CA.  (I try not to.)

I'd like to pose a question to any CA on this list: how many of you have set
the NR bit? Do you accept any liability for the NR bit?

>   - to have a true non-repudiation system, even with the NR bit turned
> on, requires a whole variety of things, and there's little to no legal
> precedent, so we don't really know what all is required.  Setting this
> one bit is clearly not sufficient, but it may be necessary.

I disagree that it may be necessary. What will be necessary is a legal
framework between the signer and relying party.

>
>  My bottom line is that I think that the NR bit should be left in,
> because at a minimum it serves the purpose of explicitly stating by
> being turned off that the CA provides NO WARRANTY whatsoever that the
> relying party can expect the service of non-repudiation to be provided.

I think dropping the NR bit would provide the same NO WARRANTY.

Regards,
Aram Perez


Received: from stingray.missi.ncsc.mil (stingray.missi.ncsc.mil [144.51.50.20]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id JAA25661 for <[e-mail]>; Thu, 5 Aug 1999 09:19:12 -0700 (PDT)
Received: from stingray.missi.ncsc.mil (root@localhost) by stingray.missi.ncsc.mil with ESMTP id MAA24625 for <[e-mail]>; Thu, 5 Aug 1999 12:19:45 -0400 (EDT)
Received: from missi.ncsc.mil (depot.missi.ncsc.mil [144.51.60.1]) by stingray.missi.ncsc.mil with ESMTP id MAA24619 for <[e-mail]>; Thu, 5 Aug 1999 12:19:44 -0400 (EDT)
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 MAA21076 for <[e-mail]>; Thu, 5 Aug 1999 12:19:40 -0400 (EDT)
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 MAA20579 for <[e-mail]>; Thu, 5 Aug 1999 12:18:51 -0400 (EDT)
Message-Id: <[e-mail]>
Date: Thu, 5 Aug 1999 12:18:51 -0400 (EDT)
From: "David P. Kemp" <[e-mail]>
Reply-To: "David P. Kemp" <[e-mail]>
Subject: Re: Non-Repudiation
To: [e-mail]
MIME-Version: 1.0
Content-Type: TEXT/plain; charset=us-ascii
Content-MD5: W2eURakyVrfgxZPJer9e+w==
X-Mailer: dtmail 1.3.0 CDE Version 1.3 SunOS 5.7 sun4u sparc

> From: Tony Bartoletti <[e-mail]>
>
> The NR-bit was intended (I believe) so that (for instance) the dutiful
> vendor of contract-signing software would code "Sorry, I can't sign this
> contract with this key, its (cert's) NR-bit is 0."  And likewise,
> vendors of (say) routine data-packet authentication software would code
> "Sorry, I can't sign these packets with this key, its NR-bit is 1."

Close.  My interpretation is that each application checks only the bit
corresponding to the function being performed.

If the app is verifying the signature on a cert, it ensures that
keyCertSign is set and ignores all others.

If it is a contract signing application, it checks that nonRepudiation
is set and ignores the others.

If it is doing data authentication with signatures (CMS signedData), it
checks that digitalSignature is set and ignores the others.

If it is doing symmetric key data authentication and/or encryption
(SSL/TLS), it should check that keyAgreement or keyEncipherment is
set, and ignore the others.  I don't believe it should make any
difference to SSL/TLS whether the NR bit is set or not - TLS
applications should look only at the KA or KE bits.

The TLS Security Considerations might point out the implication of
using a single key (with both KA/KE and NR set) in both a web browser
and the contract-signing application, but that is something for the CA
and the user to consider; the TLS app shouldn't care.


(As an aside, the dataEncipherment bit "is asserted when the subject
public key is used for enciphering user data, other than cryptographic
keys".  No general-purpose protocols use public key encryption of
arbitrary-length user data, so the dataEncipherment bit should almost
never be used.)



Received: from e1.ny.us.ibm.com (e1.ny.us.ibm.com [32.97.182.101]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id IAA25008 for <[e-mail]>; Thu, 5 Aug 1999 08:47:11 -0700 (PDT)
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 LAA30312; Thu, 5 Aug 1999 11:48:50 -0400
Received: from D51MTA05.pok.ibm.com (d51mta05.pok.ibm.com [9.117.200.33]) by northrelay02.pok.ibm.com (8.8.8m2/NCO v2.04) with SMTP id LAA162060; Thu, 5 Aug 1999 11:48:59 -0400
Received: by D51MTA05.pok.ibm.com(Lotus SMTP MTA v4.6.4  (830.2 3-23-1999))  id 852567C4.0056E037 ; Thu, 5 Aug 1999 11:48:54 -0400
X-Lotus-FromDomain: IBMUS
To: Paul Koning <[e-mail]>
cc: [e-mail], [e-mail], [e-mail]
Message-ID: <[e-mail]>
Date: Thu, 5 Aug 1999 11:47:28 -0400
Subject: Re: Lets Standardize Time Representation Formats!!!: WAS Re: New TSTTime definition
Mime-Version: 1.0
Content-type: text/plain; charset=us-ascii
Content-Disposition: inline

Paul Koning <[e-mail]> on 08/05/99 10:55:40 AM

To:   [e-mail]
cc:   [e-mail], [e-mail]
Subject:  Re: Lets Standardize Time Representation Formats!!!: WAS Re: New
      TSTTime definition





>>>>> "tog" == tog  <[e-mail]> writes:

 >> good[0] one already exists?" rant).  There's already a standard,
 >> well-defined way to
 >> represent time values, why invent another one?

 tog> becuase there is nothing here except the time data. If we want
 tog> an accompanying sense of credibility for the timedata then ASN.1
 tog> would needs a signedTime format. The actual representation of
 tog> the timedata is simple, its what is mandated with it to prove
 tog> its credibility that's the question here.

Exactly.  You do need to take an unsigned time format and apply a
signature to it.  That isn't the issue.

The issue is: why does the TSTTime consist of GeneralizedTime plus
more stuff, when that additional stuff merely duplicates in a
confusing way what you can already represent with GeneralizedTime?


[Tom Gindin]   I think that the main reason for having any other field in
TSTTime is that DER encoding of GeneralizedTime removes trailing zeroes, and
thus precision cannot be inferred from it.  The only field other than
GeneralizedTime which is really needed is precision, because DER eliminates the
possibility of correctly inferring the precision from the value presented.

     paul





Received: from chi6-1.relay.mail.uu.net (chi6-1.relay.mail.uu.net [199.171.54.98]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id HAA24127 for <[e-mail]>; Thu, 5 Aug 1999 07:52:43 -0700 (PDT)
Received: from xedia.com by chi6sosrv11.alter.net with SMTP  (peer crosschecked as: madway.xedia.com [198.202.232.199]) id QQhayt29133; Thu, 5 Aug 1999 14:55:42 GMT
Received: from tonga.xedia.com by xedia.com (4.1/SMI-4.1) id AA02692; Thu, 5 Aug 99 10:54:17 EDT
Received: by tonga.xedia.com (SMI-8.6/SMI-SVR4) id KAA00693; Thu, 5 Aug 1999 10:55:40 -0400
Date: Thu, 5 Aug 1999 10:55:40 -0400
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: Lets Standardize Time Representation Formats!!!: WAS Re: New TSTTime definition
References: <[e-mail]> <013d01bedf54$04c467e0$[e-mail]>
X-Mailer: VM 6.34 under 20.3 "Vatican City" XEmacs  Lucid

>>>>> "tog" == tog  <[e-mail]> writes:

 >> good[0] one already exists?" rant).  There's already a standard,
 >> well-defined way to
 >> represent time values, why invent another one?

 tog> becuase there is nothing here except the time data. If we want
 tog> an accompanying sense of credibility for the timedata then ASN.1
 tog> would needs a signedTime format. The actual representation of
 tog> the timedata is simple, its what is mandated with it to prove
 tog> its credibility that's the question here.

Exactly.  You do need to take an unsigned time format and apply a
signature to it.  That isn't the issue.

The issue is: why does the TSTTime consist of GeneralizedTime plus
more stuff, when that additional stuff merely duplicates in a
confusing way what you can already represent with GeneralizedTime?

	paul


Received: from www.meridianus.com (209.249.223.17.has.no.reverse [209.249.223.17] (may be forged)) by mail.proper.com (8.9.3/8.9.3) with ESMTP id HAA23952 for <[e-mail]>; Thu, 5 Aug 1999 07:51:18 -0700 (PDT)
Received: from PC1 by www.meridianus.com (8.8.8+Sun/SMI-SVR4) id IAA27658; Thu, 5 Aug 1999 08:48:17 -0700 (PDT)
Message-ID: <014801bedf54$801ec660$[e-mail]>
From: "tog" <[e-mail]>
To: "Peter Sylvester" <[e-mail]>, <[e-mail]>
Cc: <[e-mail]>, <[e-mail]>
References: <[e-mail]>
Subject: Re: Lets Standardize Time Representation Formats!!!: WAS Re: NewTSTTime definition
Date: Thu, 5 Aug 1999 08:09:22 -0700
Organization: Meridianus
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.2918.2701
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2918.2701

----- Original Message -----
From: Peter Sylvester <[e-mail]>
To: <[e-mail]>; <[e-mail]>
Cc: <[e-mail]>; <[e-mail]>
Sent: Thursday, August 05, 1999 2:09 AM
Subject: Re: Lets Standardize Time Representation Formats!!!: WAS Re:
NewTSTTime definition


> >
> > As long as each TSA gets to define "time" (what the counter means)
> > then this works.  However...
> Each TSA defines its OWN counter, even if the call it 'time'.

EXACTLY!!! and if there is no process to bind them, the TSA's together,
their output is "apples to oranges", and so of almost no evidentiary value.

What I mean is that if there is no process to coordinate the timesense on
the various TSA's  or to prove this in the marques the issue, how can you
compare their operations to one anopther? - the answer is you really cant.

> It seems that one of the questions is whether this 'time' is
> close to what everybody else thinks it is, and whether there
> is a need for the TSA either to prove this permanently, or from
> time to time, or to get a 'time stamp provider with good time'
> label, or... ?
>
>
>

SNIP



Received: from www.meridianus.com (209.249.223.34.has.no.reverse [209.249.223.34] (may be forged)) by mail.proper.com (8.9.3/8.9.3) with ESMTP id HAA23768 for <[e-mail]>; Thu, 5 Aug 1999 07:47:45 -0700 (PDT)
Received: from PC1 by www.meridianus.com (8.8.8+Sun/SMI-SVR4) id IAA27647; Thu, 5 Aug 1999 08:44:51 -0700 (PDT)
Message-ID: <013d01bedf54$04c467e0$[e-mail]>
From: "tog" <[e-mail]>
To: <[e-mail]>, <[e-mail]>
References: <[e-mail]>
Subject: Re: Lets Standardize Time Representation Formats!!!: WAS Re: New TSTTime definition
Date: Thu, 5 Aug 1999 08:05:56 -0700
Organization: Meridianus
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.2918.2701
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2918.2701

----- Original Message -----
From: Peter Gutmann <[e-mail]>
To: <[e-mail]>
Sent: Thursday, August 05, 1999 1:34 AM
Subject: RE: Lets Standardize Time Representation Formats!!!: WAS Re: New
TSTTime definition


> "Manger, James" <[e-mail]> writes:
>
> >GeneralizedTime is a basic ASN.1 type for representing time and already
> >supports fractions of seconds.  For example "19851106210627.3Z" is a
valid
> >value.  SO WHY NOT USE IT!
>
> Precisely (I've been trying to refrain from posting a "Why are people
trying
> to invent a gratuitously incompatible time format when a perfectly good[0]
> one already exists?" rant).  There's already a standard, well-defined way
to
> represent time values, why invent another one?

becuase there is nothing here except the time data. If we want an
accompanying sense of credibility for the timedata then ASN.1 would needs a
signedTime format. The actual representation of the timedata is simple, its
what is mandated with it to prove its credibility that's the question here.

>
> Peter.
>
> [0] Well, slightly clunky but adequate.  OTOH the "kludge a REAL using a
bunch
>     of INTEGER's" approach is even uglier.
>
>



Received: from edelweb.fr (edelweb.fr [193.51.12.16]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id HAA23468 for <[e-mail]>; Thu, 5 Aug 1999 07:38:48 -0700 (PDT)
Received: from champagne.edelweb.fr (localhost.edelweb.fr [127.0.0.1]) by edelweb.fr with ESMTP id QAA14667; Thu, 5 Aug 1999 16:41:43 +0200 (MET DST)
Received: from champagne.edelweb.fr (champagne.edelweb.fr [193.51.14.161]) by edelweb.fr (nospam/1.1); Thu, 5 Aug 1999 16:41:43 +0200 (MET DST)
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 QAA18821; Thu, 5 Aug 1999 16:41:42 +0200 (MET DST)
From: Peter Sylvester <[e-mail]>
Received: (sylvest@localhost) by emeriau.edelweb.fr (8.7.6/8.6.6) id QAA26478; Thu, 5 Aug 1999 16:41:42 +0200 (MET DST)
Date: Thu, 5 Aug 1999 16:41:42 +0200 (MET DST)
Message-Id: <[e-mail]>
To: [e-mail], [e-mail]
Subject: Re: TSTTime definition

Good morning. Here it is still yesterday :-)

I fully agree with you. I do not see any benefit to code
anything else than just GeneralizedTime with all its
features. Anyway, I believe if something is missing in
that format the right way is to get that changed.  

Furthermore: Copying just the subseconds of the NTP stuff
and leaving GeneralizedTime may create problems with
leap seconds when you actually want to compare two dates.
(Not that I believe that this is going to happen).

If someone needs such kind of authenticated time, then
one should choose the complete format, and not mixture
of two pieces of different worlds.  

/P

> 
> Peter Sylvester <[e-mail]> writes:
> 
> >TSTTime ::= SEQUENCE {
> >  genTime GeneralizedTime ,
> >  subsecond NumericString OPTIONAL
> >}
> >
> >GeneralizedTime is used with seconds or milliseconds.  Subsecond is a 
> >chain of decimal digits, the leftmost digit expresses 1/10th of a second, 
> >the second 1/100th.
> 
> OK, this time I will jump in first... given that GeneralizedTime *already
> includes* the subsecond facility in exactly the format described above, why
> is it necessary to add a second way to specify it?  Is there some secret
> annex to X.680 which says that you're not allowed to use GeneralizedTime to
> encode a generalised time which I'm missing?
> 
> Peter.
> 
> 


Received: from dis_exchange1.dis.wa.gov (mail.dis.wa.gov [147.55.136.51]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id HAA22865 for <[e-mail]>; Thu, 5 Aug 1999 07:06:28 -0700 (PDT)
Received: by mail.dis.wa.gov with Internet Mail Service (5.5.2448.0) id <PF434C8M>; Thu, 5 Aug 1999 07:09:03 -0700
Message-ID: <09F006027BBBD011BB290001C81A4366E71E68@dis_exchange3.dis.wa.gov>
From: "Covey, Carlene" <[e-mail]>
To: "'[e-mail]'" <[e-mail]>
Subject: 
Date: Thu, 5 Aug 1999 07:09:02 -0700 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2448.0)
Content-Type: text/plain; charset="iso-8859-1"

auth dbe46d1d subscribe ietf-pkix \



Received: from sjc3-2.relay.mail.uu.net (sjc3-2.relay.mail.uu.net [199.171.54.123]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id GAA22447 for <[e-mail]>; Thu, 5 Aug 1999 06:49:04 -0700 (PDT)
Received: from xedia.com by sjc3sosrv11.alter.net with SMTP  (peer crosschecked as: madway.xedia.com [198.202.232.199]) id QQhayp09458; Thu, 5 Aug 1999 13:52:39 GMT
Received: from tonga.xedia.com by xedia.com (4.1/SMI-4.1) id AA01511; Thu, 5 Aug 99 09:50:16 EDT
Received: by tonga.xedia.com (SMI-8.6/SMI-SVR4) id JAA00603; Thu, 5 Aug 1999 09:51:39 -0400
Date: Thu, 5 Aug 1999 09:51:39 -0400
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: TSTTime definition
References: <[e-mail]>
X-Mailer: VM 6.34 under 20.3 "Vatican City" XEmacs  Lucid

>>>>> "Denis" == Denis Pinkas <[e-mail]> writes:

 Denis> Since many applications will only use a time with a precision
 Denis> of a second , it makes sense to use GeneralizedTime only up to
 Denis> a precision of a second.

 Denis> Another argument is that using GeneralizedTime up to the
 Denis> millisecond, would not satisfy some people wishing to go
 Denis> beyond the millisecond.

 Denis> So we need an *additional* information to go under the
 Denis> millisecond, associated with a precision factor.

Why?  As I understand it, GeneralizedTime allows more than 3 digits
after the decimal point.  If you don't need them, don't look at them.
But I see no benefit in an arbitrary restriction that you must not go
beyond milliseconds.  Such a restriction modifies the standard
semantics of the datatype; it doesn't make any difference to an
application that only cares about seconds; and it introduces a problem 
for cases where you want better than milliseconds.  As Peter Gutmann
pointed out, why invent a new flat tire when an acceptable wheel
already exists?

	paul


Received: from mail.student.auckland.ac.nz (mail.student.auckland.ac.nz [130.216.35.101]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id GAA22182 for <[e-mail]>; Thu, 5 Aug 1999 06:43:29 -0700 (PDT)
Received: from kahu.cs.auckland.ac.nz ([e-mail] [130.216.36.13]) by mail.student.auckland.ac.nz (8.8.6/8.8.6/cs-master) with SMTP id BAA28495 for <[e-mail]>; Fri, 6 Aug 1999 01:46:31 +1200 (NZST) (sender [e-mail])
Received: by kahu.cs.auckland.ac.nz (relaymail v0.9) id <93386038321719>; Fri, 6 Aug 1999 01:39:43 (NZST)
From: [e-mail] (Peter Gutmann)
To: [e-mail]
Subject: Re: TSTTime definition
Sender: [e-mail]
Reply-To: [e-mail]
X-Charge-To: pgut001
X-Authenticated: relaymail v0.9 on kahu.cs.auckland.ac.nz
Date: Fri, 6 Aug 1999 01:39:43 (NZST)
Message-ID: <[e-mail]>

Peter Sylvester <[e-mail]> writes:

>TSTTime ::= SEQUENCE {
>  genTime GeneralizedTime ,
>  subsecond NumericString OPTIONAL
>}
>
>GeneralizedTime is used with seconds or milliseconds.  Subsecond is a 
>chain of decimal digits, the leftmost digit expresses 1/10th of a second, 
>the second 1/100th.

OK, this time I will jump in first... given that GeneralizedTime *already
includes* the subsecond facility in exactly the format described above, why
is it necessary to add a second way to specify it?  Is there some secret
annex to X.680 which says that you're not allowed to use GeneralizedTime to
encode a generalised time which I'm missing?

Peter.



Received: from edelweb.fr (edelweb.fr [193.51.12.16]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id FAA20734 for <[e-mail]>; Thu, 5 Aug 1999 05:29:28 -0700 (PDT)
Received: from champagne.edelweb.fr (localhost.edelweb.fr [127.0.0.1]) by edelweb.fr with ESMTP id OAA12299; Thu, 5 Aug 1999 14:32:32 +0200 (MET DST)
Received: from champagne.edelweb.fr (champagne.edelweb.fr [193.51.14.161]) by edelweb.fr (nospam/1.1); Thu, 5 Aug 1999 14:32:31 +0200 (MET DST)
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 OAA17958; Thu, 5 Aug 1999 14:32:31 +0200 (MET DST)
From: Peter Sylvester <[e-mail]>
Received: (sylvest@localhost) by emeriau.edelweb.fr (8.7.6/8.6.6) id OAA26428; Thu, 5 Aug 1999 14:32:30 +0200 (MET DST)
Date: Thu, 5 Aug 1999 14:32:30 +0200 (MET DST)
Message-Id: <[e-mail]>
To: [e-mail], [e-mail]
Subject: Re: TSTTime definition

> The current proposal is directly inspired from NTP. This should be
> satisfactory. If not, I would like to see an agreement on an
> alternative proposal written in ASN1 to specify only the time below
> the second.

For example:

TSTTime ::= SEQUENCE {
  genTime GeneralizedTime ,
  subsecond NumericString OPTIONAL
}

GeneralizedTime is used with seconds or milliseconds.
Subsecond is a chain of decimal digits, the leftmost
digit expresses 1/10th of a second, the second 1/100th.
Spaces MUST NOT be inserted.
The number of digits used corresponds to the precision.

I would like to have something like:
If subsecond is not present genTime MAY contain a fractional
part. Applications MUST be prepared to support fractional
parts after 31dec1999. 



  




 


Received: from genie.litronic.com (genie.litronic.com [198.17.235.220]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id FAA20666 for <[e-mail]>; Thu, 5 Aug 1999 05:28:00 -0700 (PDT)
Received: from litronic.com ([209.48.38.103]) by genie.litronic.com (Netscape Messaging Server 3.6)  with ESMTP id AAA43DA for <[e-mail]>; Thu, 5 Aug 1999 05:26:21 -0700
Message-ID: <[e-mail]>
Date: Thu, 05 Aug 1999 08:30:46 -0400
From: "Charlie Scruggs" <[e-mail]>
X-Mailer: Mozilla 4.6 [en] (Win98; U)
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



Received: from clbull.frcl.bull.fr (clbull.frcl.bull.fr [129.182.8.31]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id EAA19707 for <[e-mail]>; Thu, 5 Aug 1999 04:31:15 -0700 (PDT)
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 NAA24916 for <[e-mail]>; Thu, 5 Aug 1999 13:34:21 +0200
Message-ID: <[e-mail]>
Date: Thu, 05 Aug 1999 13:34:16 +0200
From: Denis Pinkas <[e-mail]>
Organization: Bull
X-Mailer: Mozilla 4.06 [fr] (Win95; I)
MIME-Version: 1.0
To: IETF-PXIX <[e-mail]>
Subject: TSTTime definition
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

After looking at the thread here is the position, as I see it.

I got a nice proposal from Stefan Santesson saying the serialNumber
in TSTInfo could be made mandatory without any problem in case of a
crash to remember the last one sent. The solution is fairly simple:
derive the serialNumber from the time through a proprietary
algorithm making sure that the integer obtained is always bigger if
the time is superior. The only drawback (that I am willing to
accept) is to use 64 bits integers. 

So let us assume that the serialNumber in TSTInfo is now mandatory.

We can then suppress the serialNumber in TSTTime.

Since many applications will only use a time with a precision of a
second , it makes sense to use GeneralizedTime only up to a
precision of a second.

Another argument is that using GeneralizedTime up to the
millisecond, would not satisfy some people wishing to go beyond the
millisecond.

So we need an *additional* information to go under the millisecond,
associated with a precision factor.

The current proposal is directly inspired from NTP. This should be
satisfactory. If not, I would like to see an agreement on an
alternative proposal written in ASN1 to specify only the time below
the second.

Of course, these additional fields will all be optional.

Denis


Received: from edelweb.fr (edelweb.fr [193.51.12.16]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id CAA15786 for <[e-mail]>; Thu, 5 Aug 1999 02:26:39 -0700 (PDT)
Received: from champagne.edelweb.fr (localhost.edelweb.fr [127.0.0.1]) by edelweb.fr with ESMTP id LAA10107; Thu, 5 Aug 1999 11:29:40 +0200 (MET DST)
Received: from champagne.edelweb.fr (champagne.edelweb.fr [193.51.14.161]) by edelweb.fr (nospam/1.1); Thu, 5 Aug 1999 11:29:39 +0200 (MET DST)
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 LAA17105; Thu, 5 Aug 1999 11:29:39 +0200 (MET DST)
From: Peter Sylvester <[e-mail]>
Received: (sylvest@localhost) by emeriau.edelweb.fr (8.7.6/8.6.6) id LAA26384; Thu, 5 Aug 1999 11:29:38 +0200 (MET DST)
Date: Thu, 5 Aug 1999 11:29:38 +0200 (MET DST)
Message-Id: <[e-mail]>
To: [e-mail], [e-mail]
Subject: Re: New TSTTime definition

> 
> Decimal conversion is very easily accomplished.  Slightly more
> difficult (but still easy) is conversion to calendric form if a
> pure seconds count is utilized.  However, one of the things that
> one might wish to do with timestamps is compare times -- either
> two timestamps, or a timestamp's time with a fixed calendric date.
Decimal conversion is not that easy. If one uses a certain
precision of the binary, and if you only have a certain amount
of decimal digits in a display, you need rounding, how do you
tell a user that  X+n*2**Y < X+(n+1)2**Y   with Y let's say -25
on a display with 3 digits after the second? 

> 
> Comparisons other than simply seeing which occurs before another
> (i.e., finding the exact time difference in seconds, say, between
> two timestamps) is much more complicated when calendric dates are
> involved.  It's necessary to convert from format to format -
> seconds, minutes, hours, days, weeks, months, years -- involving
> different bases, with odd rules such as leap years and leap
> seconds.  The latter can't be computed in advance, so lookup in
> historic leap-second tables is needed to compute the difference.
I do not see that an important usage is to measure time differences.
As far as I remember, the most important applications are to associate
time in the sense of sequence to a datum, in order to be able to
decide whether the datum (its hash) existed before some date. 

If I have an expiriation date of let's say today, then I am
very rarely concerned whether this is 150 or 160 days before
the end of the millenium. (The fact that everybody just begin
counting these days is a kind of prove.) 

In fact there are cases where date differences may be important:
When you send an invoice and you attend a payment. But then
you can have rules that say that you want to be payed 30 days 
later or 15 days after the end of the month or else. There are
tons of different habits.   

> 
> A timestamp which shows the time simply as, say, an NTP timestamp
> doesn't have these problems.  Ignoring leap seconds, the exact
> time difference (down to 2^^-32 second) between two timestamps
> can be found by simply performing a single 32-bit binary subtract.
Imagine two implemenations, one is ignoring the leap seconds, 
another one is not. 

What is the percentage of applications that need to count time
differences? 

> 
> (Elsewhere I've proposed an extension to the NTP time format which
> takes the issue of comparisons across leap seconds into account.
> http://www.ietf.org/internet-drafts/draft-ietf-pkix-bert1-01.txt)
> 
> >  it is not clear how many digits a user agent
> >  should present to a user espcially in case of some precision.
> >  if one requires no loss of information during display then the
> >  tex string becomes horribly long and the complexity of the
> >  display is far away from what can be actually expressed.
> >
> >  "the time stamp is xxxx plus .39876874654854 (+= -2**15)"
> 
> Three digits of accuracy sounds quite good, configurable if
> other lengths are desired.  This is not a serious problem.
Three digits of accuracy is what you have with standard
GeneralizedTime. But how do you compare such time stamps
if you don't have a sequence number? Where do you decide about
the precision of the conversion? Do you want a deciding 
entity to compare the binary time stamp and then tell to
the two parties 12:00:00.123 is after 12:00:00.123? 
Smells like a 1/Y2K problem. 
Or does the TSA indicate: Even if I give you binary values, 
I ensure not to issue more than one per millisecond or per 10*-n ?

> >
> >- If a time stamp authority just want to sell stamps without
> >  indication any particular order if they happen to be in the
> >  same second, what should they code?
> 
> I think this should be forbidden.  It should always be possible to
> take a sequence of timestamps and put them in their issued order.

I actually disagree: When you need a time stamp to prove that you got
it before midnight, it is not necessary to know whether you got it
before or after someone else. In fact you should be able to only get a
yes/no response when asking for 'i need a time stamp before a
certain date', and the TSA just indicates the date you want and not
its current date and just indicating whether it is before or after
that date.  

> 
> >- Using the NTP logic to carry subseconds seems to be a left over
> >  from a misunderstanding of requirements for "secure time" and
> >  "time stamp". using the time stamp protocol to provide secure
> >  time doesn't seem the a good approach anyway (I would start
> >  using a kind of NTP over secured channel, IPSEC, TLS, etc.).
> 
> I agree with that, though the time format could be interchangeable.

The current spec is a mixture of binary and textual data. 
Maybe a CHOICE of either GeneralizedTime with fractionals or
a complete binary format would be a compromise. choices should
reuse as is existing well established formats and not create
new bastards in order to be able to reuse existing code of
displays converters etc. 
There shouldn't be two many elements in the choice in order to
avoid interoperability problems anyway. 

using an unmodified NTP like format as *the* binary choice
seems ok with me.

A TSA may implement whatever it wants (this is policy).

In the TSA request one should be able to indicate the time
format that is desired/acceptable by the client.  

Peter Sylvester




Received: from edelweb.fr (edelweb.fr [193.51.12.16]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id CAA15406 for <[e-mail]>; Thu, 5 Aug 1999 02:06:54 -0700 (PDT)
Received: from champagne.edelweb.fr (localhost.edelweb.fr [127.0.0.1]) by edelweb.fr with ESMTP id LAA09771; Thu, 5 Aug 1999 11:09:49 +0200 (MET DST)
Received: from champagne.edelweb.fr (champagne.edelweb.fr [193.51.14.161]) by edelweb.fr (nospam/1.1); Thu, 5 Aug 1999 11:09:49 +0200 (MET DST)
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 LAA17005; Thu, 5 Aug 1999 11:09:47 +0200 (MET DST)
From: Peter Sylvester <[e-mail]>
Received: (sylvest@localhost) by emeriau.edelweb.fr (8.7.6/8.6.6) id LAA26381; Thu, 5 Aug 1999 11:09:47 +0200 (MET DST)
Date: Thu, 5 Aug 1999 11:09:47 +0200 (MET DST)
Message-Id: <[e-mail]>
To: [e-mail], [e-mail]
Subject: Re: Lets Standardize Time Representation Formats!!!: WAS Re: NewTSTTime  definition
Cc: [e-mail], [e-mail]

> 
> As long as each TSA gets to define "time" (what the counter means)
> then this works.  However...
Each TSA defines its OWN counter, even if the call it 'time'.
It seems that one of the questions is whether this 'time' is
close to what everybody else thinks it is, and whether there
is a need for the TSA either to prove this permanently, or from
time to time, or to get a 'time stamp provider with good time'
label, or... ? 


> 
> >The indication of what time it is at a particular counter
> >simplifies the scenario, since everybody agrees that the time
> >provided by the TSA is part of the game.
> 
> Time not only "simplifies" the scenario, it makes it possible to
> function in the real world.  Imagine that one has a contract or
> document timestamped by a TSA.  Would it be of any utility in
> our world to say merely that the document was "time"stamped at
> counter location 25,058,964,923 of a counter meaningful only
> to the TSA?  I think not (but convince me otherwise...).

If the only service that is asked for is to make a decision who came
first (but not WHEN), then time is not necessary. 

I don't want to be misunderstood. Using a time value in
a stamp makes 'time stamps' more usable. 

But what are we discussing here? 

The subject of that thread is still Let's Standardise Time Representation formats,
I still wonder why because first there are tons of formats available,
GeneralizedTime, UTF96, Z39.50, RFC822, ..., and each format is more or
less useful for particular application contexts. I don't think that
one should invent a new format.








  


Received: from mail.rdc1.md.home.com ([e-mail] [24.2.2.66]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id RAA23875 for <[e-mail]>; Wed, 4 Aug 1999 17:23:42 -0700 (PDT)
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]>; Wed, 4 Aug 1999 17:26:43 -0700
Message-ID: <[e-mail]>
Date: Wed, 04 Aug 1999 20:25:06 -0400
From: Alfred Arsenault <[e-mail]>
Organization: @Home Network
X-Mailer: Mozilla 4.5 [en]C-AtHome0405  (Win95; U)
X-Accept-Language: en
MIME-Version: 1.0
To: "Flanigan, Bill" <[e-mail]>
CC: "'David P. Kemp'" <[e-mail]>, [e-mail]
Subject: Re: Non-Repudiation
References: <[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Bill,



"Flanigan, Bill" wrote:
> 
> Dave,
> 
>         This one-bit failure thing gets scary when you, say, escrow a
> dataEnciperment key pair without the nonRepudiation bit set, but with the
> digitalSignature bit set.  

AWA:  First of all, don't do that.  Yes, I know, some people will
because the architecture of their systems is such that they don't
support separate keys for digitalSignature and dataEncipherment, and
they want to be able to recover their encrypted mail after losing their
keys, but don't even get me started on the lack of wisdom in such a
system design!


>And someone signs something for you.  Talk about
> being hung by a bit (or hung by no bit)!  Can you think of any safe guards
> within the PKIX "environment" that might help (leaving such things as
> physical security, key-escrow policy, the ABA, and crossed fingers aside)?
> 
> Bill
> 

AWA:  In response to Bill's question above, I don't believe that there's
anything in what I consider to be the "PKIX environment" other than the
NR bit that provides this protection, other than compliance with the
rest of the PKIX (proposed) standards (like the stuff on cert path
validation, CRL checking, etc.).

My take on this whole matter is this:

	- I stand by the words I wrote in the Roadmap, which Tony quoted
earlier. Security of the system depends on the security of all the parts
of the system, to include the wetware which operates it.

	- The intent of the NonRepudiation bit was, as Dave Kemp has pointed
out, to show that the CA is willing to say that this certificate is
intended/permitted to be used in signing things for which their is hope
of providing the service of nonrepudiation, as defined in 7498-2 and
paraphrased by Steve Kent.  The intent of this bit is to explicitly
distinguish such certs/keys from those only intended/permitted to be
used in providing the service of authentication via the signing of
short-term entities.  

		- what the CA does before signing a certificate with the
NonRepudiation bit set is a matter left to the CA's CP and/or CPS.  So
is the division of liability between any given CA and user.  If you as
the user don't like the CA's rejection of liability, don't do business
with that CA.  (I try not to.)

		- to have a true non-repudiation system, even with the NR bit turned
on, requires a whole variety of things, and there's little to no legal
precedent, so we don't really know what all is required.  Setting this
one bit is clearly not sufficient, but it may be necessary.

	My bottom line is that I think that the NR bit should be left in,
because at a minimum it serves the purpose of explicitly stating by
being turned off that the CA provides NO WARRANTY whatsoever that the
relying party can expect the service of non-repudiation to be provided.  

			Al Arsenault

	-- the opinions expressed in this message are those of the author, and
do not necessarily represent those of my employer, or of any other
organization with which I have a relationship


Received: from poptop.llnl.gov (poptop.llnl.gov [128.115.18.65]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id RAA23563 for <[e-mail]>; Wed, 4 Aug 1999 17:08:47 -0700 (PDT)
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 RAA13901; Wed, 4 Aug 1999 17:11:47 -0700 (PDT)
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.3 (32)
Date: Wed, 04 Aug 1999 17:10:53 -0700
To: [e-mail], "Aram Perez" <[e-mail]>
From: Tony Bartoletti <[e-mail]>
Subject: Re: Non-Repudiation
Cc: [e-mail]
In-Reply-To: <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"

At 07:31 PM 8/4/99 -0400, [e-mail] wrote:
>     Isn't the basic distinction between an ordinary digitalSignature keyUsage
>and a keyUsage with nonRepudiation that the certificate without nonRepudiation
>is NOT expected to be used for any legal documents?  This does not imply that a
>given signature using a certificate with nonRepudiation is a legal document,
>merely that such a signature using a certificate without this bit is less likely
>to be one (perhaps even that such a signature must not be considered as one).
>Perhaps the nonRepudiation bit could be relabeled "permittedOnLegalDocuments" or
>something to that effect, or RFC 2459's replacement could state that that is its
>intended meaning.
>     A certificate subject might possibly wish to bind his or her self not to
>execute a contract using that certificate, and an organization might very well
>wish to state that the subject cannot execute a contract on behalf of the
>organization with which he or she is affiliated.  Leaving out the nonRepudiation
>bit (or whatever it winds up being called) would go some way toward establishing
>such a policy.  Admittedly, this boolean flag is pretty coarse for such a
>purpose, and the policies field is better.
>     Of course, nonRepudiation is not a very good name, since most of the
>defenses allowing a signature to be repudiated (prominently including the
>defense that someone else actually was using the key, which is very similar to
>claiming that a hand-written signature has been forged) cannot be evaluated when
>the certificate is issued, but that doesn't mean that the bit is worthless.  In
>any case, while very few of the participants in this group are lawyers, we
>probably include a large fraction of the potential expert witnesses in cases on
>digital signatures.
>
>          Tom Gindin
>

Preface (humor):  I am reminded somehow of the physicist who described the
attempts to produce fusion by magnetic confinement of hydrogen ions as
"trying to bind Jello with rubber bands".

The NR-bit was intended (I believe) so that (for instance) the dutiful
vendor of contract-signing software would code "Sorry, I can't sign this
contract with this key, its (cert's) NR-bit is 0."  And likewise,
vendors of (say) routine data-packet authentication software would code
"Sorry, I can't sign these packets with this key, its NR-bit is 1."

The precaution, especially in the latter case, was to preclude such
(unlikely?) scenarios as the following:  I prepare some electronic
documents as submission for a bank loan, leave them on a floppy disk,
and then call a coworker from home and say "Jee, I forgot to send a
document to my bank, its on a floppy on my desk. Could you please
send it to [e-mail] for me?"  Later, the coworker discovers
that they have "co-signed" my loan, by virtue of using "authenticated"
email.

(NR=Jello, NR-bit=RubberBand).

___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 e3.ny.us.ibm.com (e3.ny.us.ibm.com [32.97.182.103]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id QAA22924 for <[e-mail]>; Wed, 4 Aug 1999 16:29:33 -0700 (PDT)
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 TAA126770; Wed, 4 Aug 1999 19:32:16 -0400
Received: from D51MTA05.pok.ibm.com (d51mta05.pok.ibm.com [9.117.200.33]) by northrelay02.pok.ibm.com (8.8.8m2/NCO v2.04) with SMTP id TAA91838; Wed, 4 Aug 1999 19:32:32 -0400
Received: by D51MTA05.pok.ibm.com(Lotus SMTP MTA v4.6.4  (830.2 3-23-1999))  id 852567C3.00814F47 ; Wed, 4 Aug 1999 19:32:24 -0400
X-Lotus-FromDomain: IBMUS
To: "Aram Perez" <[e-mail]>
cc: [e-mail]
Message-ID: <[e-mail]>
Date: Wed, 4 Aug 1999 19:31:17 -0400
Subject: Re: Non-Repudiation
Mime-Version: 1.0
Content-type: text/plain; charset=us-ascii
Content-Disposition: inline

     Isn't the basic distinction between an ordinary digitalSignature keyUsage
and a keyUsage with nonRepudiation that the certificate without nonRepudiation
is NOT expected to be used for any legal documents?  This does not imply that a
given signature using a certificate with nonRepudiation is a legal document,
merely that such a signature using a certificate without this bit is less likely
to be one (perhaps even that such a signature must not be considered as one).
Perhaps the nonRepudiation bit could be relabeled "permittedOnLegalDocuments" or
something to that effect, or RFC 2459's replacement could state that that is its
intended meaning.
     A certificate subject might possibly wish to bind his or her self not to
execute a contract using that certificate, and an organization might very well
wish to state that the subject cannot execute a contract on behalf of the
organization with which he or she is affiliated.  Leaving out the nonRepudiation
bit (or whatever it winds up being called) would go some way toward establishing
such a policy.  Admittedly, this boolean flag is pretty coarse for such a
purpose, and the policies field is better.
     Of course, nonRepudiation is not a very good name, since most of the
defenses allowing a signature to be repudiated (prominently including the
defense that someone else actually was using the key, which is very similar to
claiming that a hand-written signature has been forged) cannot be evaluated when
the certificate is issued, but that doesn't mean that the bit is worthless.  In
any case, while very few of the participants in this group are lawyers, we
probably include a large fraction of the potential expert witnesses in cases on
digital signatures.

          Tom Gindin




Received: from mail.student.auckland.ac.nz (mail.student.auckland.ac.nz [130.216.35.101]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id PAA15064 for <[e-mail]>; Wed, 4 Aug 1999 15:15:28 -0700 (PDT)
Received: from kahu.cs.auckland.ac.nz ([e-mail] [130.216.36.13]) by mail.student.auckland.ac.nz (8.8.6/8.8.6/cs-master) with SMTP id BAA09239 for <[e-mail]>; Thu, 5 Aug 1999 01:41:11 +1200 (NZST) (sender [e-mail])
Received: by kahu.cs.auckland.ac.nz (relaymail v0.9) id <93377366408562>; Thu, 5 Aug 1999 01:34:24 (NZST)
From: [e-mail] (Peter Gutmann)
To: [e-mail]
Subject: RE: Lets Standardize Time Representation Formats!!!: WAS Re: New TSTTime definition
Sender: [e-mail]
Reply-To: [e-mail]
X-Charge-To: pgut001
X-Authenticated: relaymail v0.9 on kahu.cs.auckland.ac.nz
Date: Thu, 5 Aug 1999 01:34:24 (NZST)
Message-ID: <[e-mail]>

"Manger, James" <[e-mail]> writes:

>GeneralizedTime is a basic ASN.1 type for representing time and already 
>supports fractions of seconds.  For example "19851106210627.3Z" is a valid
>value.  SO WHY NOT USE IT!

Precisely (I've been trying to refrain from posting a "Why are people trying
to invent a gratuitously incompatible time format when a perfectly good[0]
one already exists?" rant).  There's already a standard, well-defined way to 
represent time values, why invent another one?

Peter.

[0] Well, slightly clunky but adequate.  OTOH the "kludge a REAL using a bunch
    of INTEGER's" approach is even uglier.



Received: from rbhub101.chamb.disa.mil (rbhub101.chamb.disa.mil [209.22.120.24]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id OAA10449 for <[e-mail]>; Wed, 4 Aug 1999 14:13:40 -0700 (PDT)
Received: by rbhub101.chamb.disa.mil with Internet Mail Service (5.5.2448.0) id <QDBRHBHP>; Wed, 4 Aug 1999 17:17:18 -0400
Message-ID: <[e-mail]>
From: "Flanigan, Bill" <[e-mail]>
To: "'David P. Kemp'" <[e-mail]>
Cc: [e-mail]
Subject: RE: Non-Repudiation
Date: Wed, 4 Aug 1999 17:20:04 -0400 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2448.0)
Content-Type: text/plain

Dave,

	This one-bit failure thing gets scary when you, say, escrow a
dataEnciperment key pair without the nonRepudiation bit set, but with the
digitalSignature bit set.  And someone signs something for you.  Talk about
being hung by a bit (or hung by no bit)!  Can you think of any safe guards
within the PKIX "environment" that might help (leaving such things as
physical security, key-escrow policy, the ABA, and crossed fingers aside)?

Bill

> ----------
> From: 	David P. Kemp[SMTP:[e-mail]]
> Reply To: 	David P. Kemp
> Sent: 	Wednesday, August 04, 1999 4:15 PM
> To: 	[e-mail]
> Subject: 	Re: Non-Repudiation
> 
> > From: "Aram Perez" <[e-mail]>
> > 
> > How can setting the NR bit ensure that there isn't a "failure in any one
> of
> > those areas"?
> 
> It can't, obviously.  The NR bit is a tiny amount (one binary digit's
> worth)
> of information imbedded in a technical protocol which can be used to
> signal a person's intent, no more, no less.
> 
> If there is NO failure in any of the listed areas, and NO failure in
> areas not listed (what the user saw is what he signed, cert is
> bound to signature, etc), then the fact that the user has chosen to use
> a keypair with the NR bit set instead of a keypair with the NR bit
> clear MAY provide some evidence of intent to the legal process.
> Or it may not, if so determined by the ABA, the courts, and the
> legislatures.
> 
[snip]



Received: from mail-out2.apple.com (mail-out2.apple.com [17.254.0.51]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id OAA10248 for <[e-mail]>; Wed, 4 Aug 1999 14:11:14 -0700 (PDT)
Received: from mailgate1.apple.com (A17-128-100-225.apple.com [17.128.100.225]) by mail-out2.apple.com (8.8.5/8.8.5) with ESMTP id OAA48812 for <[e-mail]>; Wed, 4 Aug 1999 14:14:16 -0700
Received: from scv2.apple.com (scv2.apple.com) by mailgate1.apple.com (mailgate1.apple.com- SMTPRS 2.0.15) with ESMTP id <[e-mail]>; Wed, 04 Aug 1999 14:14:05 -0700
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 OAA13644; Wed, 4 Aug 1999 14:14:03 -0700
Message-Id: <[e-mail]>
X-Mailer: Microsoft Outlook Express Macintosh Edition - 4.5 (0410)
Date: Wed, 04 Aug 1999 14:14:03 -0700
Subject: Re: Non-Repudiation
From: "Aram Perez" <[e-mail]>
To: "David P. Kemp" <[e-mail]>, [e-mail]
MIME-Version: 1.0
X-Priority: 3
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit

David Kemp wrote:

> Do you disagree that with a proper hardware token, the probability of
> private key compromise is decreased?

I agree that the probability is decreased for the compromise but not for me
un/intentionally giving my PIN to an attacker who stole my token.

Regards,
Aram Perez


Received: from mail-out1.apple.com (mail-out1.apple.com [17.254.0.52]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id OAA09914 for <[e-mail]>; Wed, 4 Aug 1999 14:05:55 -0700 (PDT)
Received: from mailgate1.apple.com (A17-128-100-225.apple.com [17.128.100.225]) by mail-out1.apple.com (8.8.5/8.8.5) with ESMTP id OAA25262 for <[e-mail]>; Wed, 4 Aug 1999 14:08:57 -0700
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, 04 Aug 1999 14:08:50 -0700
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 OAA36798 for <[e-mail]>; Wed, 4 Aug 1999 14:08:49 -0700
Message-Id: <[e-mail]>
X-Mailer: Microsoft Outlook Express Macintosh Edition - 4.5 (0410)
Date: Wed, 04 Aug 1999 14:08:48 -0700
Subject: Re: Non-Repudiation
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

David Kemp wrote:

>> From: "Aram Perez" <[e-mail]>
>> 
>> How can setting the NR bit ensure that there isn't a "failure in any one of
>> those areas"?
>
> It can't, obviously.  The NR bit is a tiny amount (one binary digit's worth)
> of information imbedded in a technical protocol which can be used to
> signal a person's intent, no more, no less.

That assumes the person was notified. How does the NR bit give that
assurance when no one knows what software/system the person is using.

>
> If there is NO failure in any of the listed areas, and NO failure in
> areas not listed (what the user saw is what he signed, cert is
> bound to signature, etc), then the fact that the user has chosen to use
> a keypair with the NR bit set instead of a keypair with the NR bit
> clear MAY provide some evidence of intent to the legal process.
> Or it may not, if so determined by the ABA, the courts, and the
> legislatures.

How do you provide that assurance of "NO failure"? I very much doubt that a
CA is going to give that assurance. And I doubt that my mom, as smart as she
is, is going to know when to pick the keypair with the NR bit set.

>
>
>> Steve, so many things are "implied" -- that one needs to be careful not
>> to have "implied security" as well.  What I mean is that we need clear
>> and well-defined concepts, if we want clear results.
>
> The technical concepts really aren't that controversial:
>
> 1) Symmetric cryptography involves shared secrets, and so cannot be
> used to distinguish between parties in a communication.

This is not correct. In a previous job, we built a system using DES where
party A could only sign (using ANSI X9.9) and party B could only verify.
With party A, all the keys were kept on hardware tokens and required dual
control: a Security Administrator (SA) to start the system and the Signing
Offer (SO) to enable the signature process. The signing key was the
combination of the SA and SO keys. A similar setup existed at party B. With
this system, I could prove (in a court of law) that the signature was
generated by party A and not by party B.

>
> 2) Asymmetric digital signature algorithms have applications (such as
> data integrity and entity authentication) other than providing the
> electronic analog of a handwritten signature.

But asymmetric digital signatures are not a one-to-one electronic analog of
a handwritten signature. And they certainly do not have the legal framework
that handwritten signature have.

>
> 3) Asymmetric private keys may be afforded differing levels of
> protection, and information in public certificates can communicate to a
> verifier the intended application of a specific private key.

But who controls the "intended application of a specific private key"? It is
easy to write a general purpose crypto library that enforces the
keyEncipherment bit, but how do you enforce "the user's intent"? How does
the crypto library enforce that the user only uses a keypair with the NR bit
set for signing a contract? The goal of the CA is to bind a user' identity
to a public key, not to quantify the "user's intent".

>
> What is the goal of this discussion: to argue that there is no such
> thing as "technical non-repudiation" as represented by the above three
> items, or that the name of the nonRepudiation keyUsage bit should be
> changed, or that the NR bit serves no purpose in any conceivable
> environment?

Personally I think that at minimum, the name should be changed but that
would require a change to X.509. I would prefer that IETF deprecate its use.

>
> The IETF obviously does not claim that a technical mechanism can
> "prevent a party in a communication from later denying having
> participated in the communication" - anyone can deny anything, and
> prisons are chock full of innocent bystanders.  The IETF does claim
> that the products under its control (protocol specifications) will not
> be the weak link in the chain of evidence used to refute such a
> denial.

It may "not claim" but it certainly give the impression (otherwise I don't
think there would be so much discussion on the issue). I don't see how the
NR bit makes the "link in the chain of evidence used to refute such a
denial" any weaker or stronger.

>
> There are plenty of links in a system designed to be secure - one that
> is designed exclusively to prevent an adversary from violating your
> self-defined policy, totally ignoring legal concepts such as intent and
> burden of proof.  If an IETF protocol specification is not the weak
> link in this constrained environment, then it will certainly not be the
> weak link when dozens of other legal grounds for successful
> repudiation (weaker links) are introduced.

Agreed.

Regards,
Aram Perez


Received: from poptop.llnl.gov (poptop.llnl.gov [128.115.18.65]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id OAA09490 for <[e-mail]>; Wed, 4 Aug 1999 14:00:02 -0700 (PDT)
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 OAA03714; Wed, 4 Aug 1999 14:03:01 -0700 (PDT)
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.3 (32)
Date: Wed, 04 Aug 1999 14:02:07 -0700
To: Michael McNeil <[e-mail]>, Aram Perez <[e-mail]>
From: Tony Bartoletti <[e-mail]>
Subject: Re: Lets Standardize Time Representation Formats!!!: WAS Re: NewTSTTime  definition
Cc: [e-mail]
In-Reply-To: <[e-mail]>
References: <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"

At 09:27 AM 8/4/99 -0700, Michael McNeil wrote:

>If we're specifying a denominator which is a power of 2, how about
>2^^32 (the natural denominator for fractional quantities within a
>32-bit binary cell), or 4,294,967,296.  This is the format used by
>the fractional portion of the time in NTP (Network Time Protocol).
>(In this quantity of time, light will travel about 3 inches.)
[snip]
>Why not just tack on enough bits to satisfy all future expectations?
>if 2^^(-32) isn't precise enough for future needs, then I'm prepared
>to hear arguments in favor of 2^^(-64).  It's only 64 bits, with a
>binary numeric format which is easily handled by today's processors.

Good point.  It will probably be awhile before teams of intercellular
nano-probes negotiate contracts amongst themselves ... I think :)

___tony___


 


Received: from popmail.inbox.se (popmail.inbox.se [193.12.72.101]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id NAA09184 for <[e-mail]>; Wed, 4 Aug 1999 13:56:52 -0700 (PDT)
Received: from stefan2 (accurata.inbox.se [193.12.72.24]) by popmail.inbox.se (8.9.3/8.9.3) with SMTP id WAA00099; Wed, 4 Aug 1999 22:59:51 +0200
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 
Date: Wed, 04 Aug 1999 23:00:07 +0200
To: "Anders Rundgren" <[e-mail]>, "PKIX-List" <[e-mail]>, "Petra Gloeckner" <[e-mail]>, <[e-mail]>
From: Stefan Santesson <[e-mail]>
Subject: Re: Use of localityName attribute
In-Reply-To: <001801beca71$68b1f1c0$[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 mail.proper.com id NAA09185

All,

I'm sorry that I totally missed this thread due to vacation. I have just
read through this thread and find nothing that changes the current assumptions.

What I see is a debate concerning how to form identities. From the QC
specification viewpoint I must disagree to any statement claiming that the
QC spec have any preferences concerning how an identity should be expressed
as long as it meets requirements stated in section 2.2. (section numbered
according to the new draft 01)

Note that the fact that an attribute is specified in the QC spec, does NOT
imply that this attribute must be used.

I can't find any issue raised that can't be solved with the updated draft
that will be submitted in a few days. This draft include support for
locality name.

/Stefan

At 02:13 AM 7/10/99 +0100, Anders Rundgren wrote:
>David
>
>>> The answers you got from the QC-editors signifiy what I consider the
>>> fundamentally flawed model that QC is based on:
>>> 
>>
>>Its a pity that you did not describe this model that you have in your 
>>head, since it is very difficult to pick it up from your comments 
>>below. It is also difficult to make sensible comments against some 
>>model that is not explicitly spelt out, but rather has been implicitly 
>>assumed.
>
>
>Well, some of it was in the points 1-3.
>
>>> #1:
>>> To begin with, miss Glöckner's answer was signed with a QC-like
>>> certificate which was issued by her employer (?) and was of course not
>>> trusted by my mail-program's root-certficates which it told me in many
>>> ways. This is where QCs will fail to meet the needs of the market and will
>>> make PKI a word associated with offensive amounts of tax-payers money
>>> spent in vain.  I.e. QCs of that kind have no use outside a very limited
>>> domain and definitely not in a public area.
>>
>>I must be missing something here, since I dont see how configuring 
>>trust in root CA certificates, which clearly needs to be initialised into 
>>each RP's client before you can trust the subject of a certificate, is 
>>tied into the debate about the name forms to be used in QCs. Once 
>>a root is trusted by some possibly out of band means, the QC 
>>actually makes it much easier to identify who the subject is beneath 
>>that root.
>
>
>My remark had as you say not so much to do with name-forms.
>I just expressed what I feel about a specification that I think will
>create more problems than it solves by beeing to imprecise
>and too flexible.
>
>But I don't expect you to agree on that as you obviously are up to your
>ears into QC-implemenrtations.
>
>This initializing of RPs is though not so easy to do if there are
>many roots.  And the QC-specification with its hairy variations
>will create many roots since every organsation or business sector
>will need different attributes.  Who are U going to trust?
>
><snip>
>
>>> As it is already a hard task to uniquely identify an organization, it
>>> deserves a certificate of its own.  
>>
>>Why? If I do not communicate with the organisation (as opposed to 
>>an organisations CA or manager or employee) what use is the 
>>certificate?
>
>
>This is a very interesting question that I have asked many times but
>the QC-camp has not responded to AT ALL:  When and how are QCs to
>be used and how many do U need on average? When you know that then it gets 
>much more interesting to discuss.
>
>>>And to build identity on local
>>> addresses is a bad idea as for instance my own company just moved a couple
>>> of blocks and we are still known as the Swedish company "Jaybis AB" with
>>> registration number 564567-1267.  If you need to know the address of an
>>> organization you should look in a public registry (assuming it is legally
>>> registered) and not in a certificate.
>>
>>I agree, thats what the directory is for. I did not suggest putting the 
>>complete address in the certificate (it is too big), just the locality. In 
>>the UK (at least) hospitals hardly ever move locations. We have 
>>many still standing from the last century. They are much more stable 
>>than the lifetime of a certificate. So they make a good unique name 
>>component for org units like hospitals that have the same common 
>>name (such as St Marys)
>
>
>Sure, but then you create a system that fits uniquelly well to your 
>perspective only.
>How about interoperability? 
>
>>
>>> 
>>> #3:
>>> A real problem with QCs is when they also provide information like
>>> profession and roles because then the need for diversion will make it
>>> virtually impossible to create interoperability and TTP support.
>>> 
>>
>>This is a completely separate topic, not directly related to QCs, but 
>>related to any type of certificate and how you determine privileges 
>>for people based on roles. A red herring QC wise in my opinion.
>
>I can't say I know the herring stuff.  Is it an english version of B***S***?
>It is a bit related to QCs as some published examples did indeed contain
>profession which I consider a bad idea as then you elimnate TTPs
>(in most cases) due to cost and inflexibility.
>
>>> Solutions?
>>> TTPs should certify organizations and individuals separately. 
>>> Organizations themselves should publish additional information about
>>> employees in formats and ways that are adapted and agreed upon by the
>>> business segment they operate within.
>>
>>And how do you get the trust that this person is an employee if his 
>>subject DN does not have the name of the organisation anywhere 
>>within it?
>
>There are several ways to do that.  Directory lookup.  Attribute certificates
>and my (in)famous "Thin PKI" approach (no URL here otherwise Steve
>will put me in the spam-filter :-(   )
>
>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 stingray.missi.ncsc.mil (stingray.missi.ncsc.mil [144.51.50.20]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id NAA08884 for <[e-mail]>; Wed, 4 Aug 1999 13:51:00 -0700 (PDT)
Received: from stingray.missi.ncsc.mil (root@localhost) by stingray.missi.ncsc.mil with ESMTP id QAA17406 for <[e-mail]>; Wed, 4 Aug 1999 16:54:02 -0400 (EDT)
Received: from missi.ncsc.mil (depot.missi.ncsc.mil [144.51.60.1]) by stingray.missi.ncsc.mil with ESMTP id QAA17402 for <[e-mail]>; Wed, 4 Aug 1999 16:54:01 -0400 (EDT)
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 QAA13222 for <[e-mail]>; Wed, 4 Aug 1999 16:53:57 -0400 (EDT)
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 QAA20111 for <[e-mail]>; Wed, 4 Aug 1999 16:53:10 -0400 (EDT)
Message-Id: <[e-mail]>
Date: Wed, 4 Aug 1999 16:53:10 -0400 (EDT)
From: "David P. Kemp" <[e-mail]>
Reply-To: "David P. Kemp" <[e-mail]>
Subject: Re: Non-Repudiation
To: [e-mail]
MIME-Version: 1.0
Content-Type: TEXT/plain; charset=us-ascii
Content-MD5: DhKJW7YeqKgYWvQHHHHBPQ==
X-Mailer: dtmail 1.3.0 CDE Version 1.3 SunOS 5.7 sun4u sparc

> From: Ed Gerck <[e-mail]>
> 
> It is not "assent" because if the CA would assume this role or even
> merely imply it, then that power to assent or co-assent to a key
> usage by the subscriber would make the CA liable or co-liable for
> that key's usage.
> 
>   [... and ...]
> 
> But... "I will charge for not standing in your way".  What this means is that
> CAs now have two  "products": one with NR and another without NR--
> and both are "standards-compliant".  The product without NR costs X and
> warrants Z. The product with NR costs Y but also warrants Z, where
> Y > X.  In other words, a "value-add" without the value ;-)

The CA's CPS says that it will sign whatever value of the NR bit is
requested by the subject.  Since the CA is powerless to do otherwise,
its liability is zero.  If Y != X, I agree with your conclusion :-).


> But, some believe that the "non-repudiation bit" feature can still be justified,
> even if not by reason nor by cost, by the "death penalty syndrome".  By
> raising the stakes (ie, "be extra careful with that NR cert now, because any
> misuse will haunt you")  the logic is that the "probability of occurrence" will
> decrease.

Now the CA's CPS is augmented to say that it will set the NR bit if
requested by the subscriber, but only if it can ensure that the private
key resides on a hardware token from which the key cannot be
extracted.  The CA's liability is still zero if the subscriber has a
token, because the subscriber completely controls whether the NR bit is
set.  The CA is liable only for failing to follow its CPS.

Do you disagree that with a proper hardware token, the probability of
private key compromise is decreased?



Received: from aum (ip11.proper.com [165.227.249.11]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id NAA08686 for <[e-mail]>; Wed, 4 Aug 1999 13:49:24 -0700 (PDT)
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58 
Date: Wed, 04 Aug 1999 13:52:20 -0700
To: [e-mail]
From: Paul Hoffman / IMC <[e-mail]>
Subject: PLEASE DON'T RESPOND Re: Confirmation for subscribe ietf-pkix
In-Reply-To: <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed

Someone managed to screw up their subscription requests in a very creative 
fashion. Please do *not* respond to those messages that got sent to the 
list. Thanks!

--Paul Hoffman, Director
--Internet Mail Consortium


Received: from libra.rapidstream.com (h207-21-186-99.ncal.verio.net [207.21.186.99]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id NAA08433 for <[e-mail]>; Wed, 4 Aug 1999 13:42:10 -0700 (PDT)
Received: from fuji (fuji.internal [10.10.0.21]) by libra.rapidstream.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.1960.3) id 3VD70CT1; Wed, 4 Aug 1999 13:29:00 -0700
Message-ID: <00d501bedebc$254db4a0$[e-mail]>
From: "James Lin" <[e-mail]>
To: <[e-mail]>
Subject: 
Date: Wed, 4 Aug 1999 13:58:47 -0700
MIME-Version: 1.0
Content-Type: text/plain; charset="big5"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 4.72.2110.0
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.2106.4

auth be8fb2c7 subscribe ietf-pkix 



Received: from mail-out2.apple.com (mail-out2.apple.com [17.254.0.51]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id NAA08183 for <[e-mail]>; Wed, 4 Aug 1999 13:39:39 -0700 (PDT)
Received: from mailgate1.apple.com (A17-128-100-225.apple.com [17.128.100.225]) by mail-out2.apple.com (8.8.5/8.8.5) with ESMTP id NAA35208 for <[e-mail]>; Wed, 4 Aug 1999 13:42:42 -0700
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, 04 Aug 1999 13:27:27 -0700
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 NAA37094 for <[e-mail]>; Wed, 4 Aug 1999 13:27:26 -0700
Message-Id: <[e-mail]>
X-Mailer: Microsoft Outlook Express Macintosh Edition - 4.5 (0410)
Date: Wed, 04 Aug 1999 13:27:25 -0700
Subject: Re: Non-Repudiation, was Re: Common misconceptions, was Re: KISSfor PKIX.   (Was: RE:ASN.1vs   XML   (used to be RE: I-D ACTION :draft-ietf-pkix-scvp-00.txt))
From: "Aram Perez" <[e-mail]>
To: "'[e-mail]'" <[e-mail]>
MIME-Version: 1.0
X-Priority: 3
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit

Tony Bartoletti wrote:

[snip]
> 
> Radically paraphrasing (I believe it was Steven Kent,) all that the
> "non-repudiation bit" signifies is that, as far as the CA is concerned,
> they assent to the use of a so-certified-key's signature in support of
> a potential non-repudiation claim.

First, you have the term "non-repudiation" which means, by definition, that
a party cannot repudiate. There are many places in the "literature" (whether
it is technical or marketing) that imply that digital signatures
provide/enforce non-repudiation. This is the perception of the "casual
observer". Second, how or why should the CA be concerned? The CA does not
have control over the whole security of the "certificate-using SYSTEM". And
if it is concerned, does it bear any liability? Can the relying party sue
the CA if the NR bit is set in a certificate issued by that CA?

>
> How far does that get anyone?  Not far. It is a bit like you want to
> climb Mt. Everest, and to "support you" in this endeavor, I announce
> that I will not stand in your way.

If it doesn't get anyone very far, why give a false sense of support?

Regards,
Aram Perez


Received: from stingray.missi.ncsc.mil (stingray.missi.ncsc.mil [144.51.50.20]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id NAA05253 for <[e-mail]>; Wed, 4 Aug 1999 13:13:24 -0700 (PDT)
Received: from stingray.missi.ncsc.mil (root@localhost) by stingray.missi.ncsc.mil with ESMTP id QAA14522 for <[e-mail]>; Wed, 4 Aug 1999 16:16:25 -0400 (EDT)
Received: from missi.ncsc.mil (depot.missi.ncsc.mil [144.51.60.1]) by stingray.missi.ncsc.mil with ESMTP id QAA14518 for <[e-mail]>; Wed, 4 Aug 1999 16:16:25 -0400 (EDT)
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 QAA12804 for <[e-mail]>; Wed, 4 Aug 1999 16:16:20 -0400 (EDT)
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 QAA20101 for <[e-mail]>; Wed, 4 Aug 1999 16:15:33 -0400 (EDT)
Message-Id: <[e-mail]>
Date: Wed, 4 Aug 1999 16:15:33 -0400 (EDT)
From: "David P. Kemp" <[e-mail]>
Reply-To: "David P. Kemp" <[e-mail]>
Subject: Re: Non-Repudiation
To: [e-mail]
MIME-Version: 1.0
Content-Type: TEXT/plain; charset=us-ascii
Content-MD5: mb6njQmvRVngEFdOT1rhDQ==
X-Mailer: dtmail 1.3.0 CDE Version 1.3 SunOS 5.7 sun4u sparc

> From: "Aram Perez" <[e-mail]>
> 
> How can setting the NR bit ensure that there isn't a "failure in any one of
> those areas"?

It can't, obviously.  The NR bit is a tiny amount (one binary digit's worth)
of information imbedded in a technical protocol which can be used to
signal a person's intent, no more, no less.

If there is NO failure in any of the listed areas, and NO failure in
areas not listed (what the user saw is what he signed, cert is
bound to signature, etc), then the fact that the user has chosen to use
a keypair with the NR bit set instead of a keypair with the NR bit
clear MAY provide some evidence of intent to the legal process.
Or it may not, if so determined by the ABA, the courts, and the
legislatures.


> Steve, so many things are "implied" -- that one needs to be careful not
> to have "implied security" as well.  What I mean is that we need clear
> and well-defined concepts, if we want clear results.

The technical concepts really aren't that controversial:

1) Symmetric cryptography involves shared secrets, and so cannot be
used to distinguish between parties in a communication.

2) Asymmetric digital signature algorithms have applications (such as
data integrity and entity authentication) other than providing the
electronic analog of a handwritten signature.

3) Asymmetric private keys may be afforded differing levels of
protection, and information in public certificates can communicate to a
verifier the intended application of a specific private key.


What is the goal of this discussion: to argue that there is no such
thing as "technical non-repudiation" as represented by the above three
items, or that the name of the nonRepudiation keyUsage bit should be
changed, or that the NR bit serves no purpose in any conceivable
environment?

The IETF obviously does not claim that a technical mechanism can
"prevent a party in a communication from later denying having
participated in the communication" - anyone can deny anything, and
prisons are chock full of innocent bystanders.  The IETF does claim
that the products under its control (protocol specifications) will not
be the weak link in the chain of evidence used to refute such a
denial.

There are plenty of links in a system designed to be secure - one that
is designed exclusively to prevent an adversary from violating your
self-defined policy, totally ignoring legal concepts such as intent and
burden of proof.  If an IETF protocol specification is not the weak
link in this constrained environment, then it will certainly not be the
weak link when dozens of other legal grounds for successful
repudiation (weaker links) are introduced.




Received: from tomcat.sac.verio.net ([e-mail] [209.162.64.15]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id MAA04417 for <[e-mail]>; Wed, 4 Aug 1999 12:49:18 -0700 (PDT)
Received: from nma.com (pm07-27.sac.verio.net [209.162.65.46]) by tomcat.sac.verio.net (8.9.1a/8.9.1) with ESMTP id MAA23956 for <[e-mail]>; Wed, 4 Aug 1999 12:52:18 -0700 (PDT)
Message-ID: <[e-mail]>
Date: Wed, 04 Aug 1999 12:52:15 -0700
From: Ed Gerck <[e-mail]>
X-Mailer: Mozilla 4.51 [en] (Win98; I)
X-Accept-Language: en
MIME-Version: 1.0
CC: "'[e-mail]'" <[e-mail]>
Subject: Re: Non-Repudiation, was Re: Common misconceptions, was Re:KISSfor  PKIX.   (Was: RE:ASN.1vs   XML   (used to be RE: I-D  ACTION:draft-ietf-pkix-scvp-00.txt))
References: <[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Tony Bartoletti wrote:

> ... all that the
> "non-repudiation bit" signifies is that, as far as the CA is concerned,
> they assent to the use of a so-certified-key's signature in support of
> a potential non-repudiation claim.

It is not "assent" because if the CA would assume this role or even
merely imply it, then that power to assent or co-assent to a key
usage by the subscriber would make the CA liable or co-liable for
that key's usage.


> How far does that get anyone?  Not far. It is a bit like you want to
> climb Mt. Everest, and to "support you" in this endeavor, I announce
> that I will not stand in your way.

But... "I will charge for not standing in your way".  What this means is that
CAs now have two  "products": one with NR and another without NR--
and both are "standards-compliant".  The product without NR costs X and
warrants Z. The product with NR costs Y but also warrants Z, where
Y > X.  In other words, a "value-add" without the value ;-)

The subscriber not only pays more (ie, needs at least two certs) but has
now a larger liability.  Mere usage of that private-key NR cert (say, by a
hacker that snatched the private-key NR cert and broke the password)
at any time will imply NR.  Which is a good thing since such liability
argument can easily be defeated in law -- since the subscriber had no
power to deny it and was at the mercy of uncontrollable events (hackers
are, knowingly, uncontrollable and can penetrate even high-security
government networks).

But, some believe that the "non-repudiation bit" feature can still be justified,
even if not by reason nor by cost, by the "death penalty syndrome".  By
raising the stakes (ie, "be extra careful with that NR cert now, because any
misuse will haunt you")  the logic is that the "probability of occurrence" will
decrease.  In other words, the notion that there is somewhere a "law of
equal risks" that  says that the product of "value at stake" times "probability
of occurence" is constant -- so that increasing the "value at stake" decreases
the occurrence.  The logical flaw behind this is that such "law" does not exist
-- especially here, because the "value at stake" is not borne by the hacker.

BTW, I recall one friend that described a patrolman's rendering of the
"death penaly syndrome" in a true story -- which may further illustrate
the point.  Bill got a speeding ticket, and had to attend one of those
"driving school" classes, put on by a former highway patrolman, who
bemoaned the fact that "everyone" seems to speed, 5 or 10 MPH
above the posted limit.  Indeed, the instructor thought that even the
posted limits are too high and asked, "what if the penalty for
speeding, even 1 MPH above the limit, were punishable by death?"

He expected the answer "No one would dare speed."

But Bill's answer was that within a month or so, the Highway Patrol would be
disbanded, or at least precluded from issuing any tickets for speeding.
The same will perhaps happen with those CAs that issue "death penalty
certs".

Cheers,

Ed Gerck



Received: by mail.proper.com (8.9.3/8.9.3) id MAA02531; Wed, 4 Aug 1999 12:20:59 -0700 (PDT)
Date: Wed, 4 Aug 1999 12:20:59 -0700 (PDT)
Message-Id: <[e-mail]>
To: mailto:[e-mail]
From: [e-mail]
Subject: Confirmation for subscribe ietf-pkix
Reply-To: [e-mail]

--

Someone (possibly you) has requested that your email address be added
to or deleted from the mailing list "[e-mail]".

If you really want this action to be taken, please send the following
commands (exactly as shown) back to "[e-mail]":

auth be8fb2c7 subscribe ietf-pkix \
<mailto:[e-mail] <mailto:[e-mail]>

(Yes, this is on two lines with a \ character at the end of the
first line. That's the best way to get majordomo to do the right
thing for authorization.)

If you do not want to this action taken, just ignore this message and
no action will be taken.

If you have any questions about the policy of the list owner, please
contact "[e-mail]".

Thanks!

[e-mail]


Received: by mail.proper.com (8.9.3/8.9.3) id MAA02273; Wed, 4 Aug 1999 12:18:07 -0700 (PDT)
Date: Wed, 4 Aug 1999 12:18:07 -0700 (PDT)
Message-Id: <[e-mail]>
To: mailto:[e-mail]
From: [e-mail]
Subject: Confirmation for subscribe ietf-pkix
Reply-To: [e-mail]

--

Someone (possibly you) has requested that your email address be added
to or deleted from the mailing list "[e-mail]".

If you really want this action to be taken, please send the following
commands (exactly as shown) back to "[e-mail]":

auth dbe46d1d subscribe ietf-pkix \
<mailto:[e-mail]>

(Yes, this is on two lines with a \ character at the end of the
first line. That's the best way to get majordomo to do the right
thing for authorization.)

If you do not want to this action taken, just ignore this message and
no action will be taken.

If you have any questions about the policy of the list owner, please
contact "[e-mail]".

Thanks!

[e-mail]


Received: from www.meridianus.com (209.249.223.14.has.no.reverse [209.249.223.14] (may be forged)) by mail.proper.com (8.9.3/8.9.3) with ESMTP id LAA00892 for <[e-mail]>; Wed, 4 Aug 1999 11:26:39 -0700 (PDT)
Received: from got.net by www.meridianus.com (8.8.8+Sun/SMI-SVR4) id MAA26680; Wed, 4 Aug 1999 12:21:44 -0700 (PDT)
Message-ID: <[e-mail]>
Date: Wed, 04 Aug 1999 11:27:25 -0700
From: Michael McNeil <[e-mail]>
X-Mailer: Mozilla 4.51 [en] (WinNT; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Peter Sylvester <[e-mail]>
CC: [e-mail], [e-mail]
Subject: Re: New TSTTime definition
References: <[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Peter Sylvester wrote:
>- A binary fraction of time always needs a calculation (conversion
>  to decimals.

Decimal conversion is very easily accomplished.  Slightly more
difficult (but still easy) is conversion to calendric form if a
pure seconds count is utilized.  However, one of the things that
one might wish to do with timestamps is compare times -- either
two timestamps, or a timestamp's time with a fixed calendric date.

Comparisons other than simply seeing which occurs before another
(i.e., finding the exact time difference in seconds, say, between
two timestamps) is much more complicated when calendric dates are
involved.  It's necessary to convert from format to format --
seconds, minutes, hours, days, weeks, months, years -- involving
different bases, with odd rules such as leap years and leap
seconds.  The latter can't be computed in advance, so lookup in
historic leap-second tables is needed to compute the difference.

A timestamp which shows the time simply as, say, an NTP timestamp
doesn't have these problems.  Ignoring leap seconds, the exact
time difference (down to 2^^-32 second) between two timestamps
can be found by simply performing a single 32-bit binary subtract.

(Elsewhere I've proposed an extension to the NTP time format which
takes the issue of comparisons across leap seconds into account.
http://www.ietf.org/internet-drafts/draft-ietf-pkix-bert1-01.txt)

>  it is not clear how many digits a user agent
>  should present to a user espcially in case of some precision.
>  if one requires no loss of information during display then the
>  tex string becomes horribly long and the complexity of the
>  display is far away from what can be actually expressed.
>
>  "the time stamp is xxxx plus .39876874654854 (+= -2**15)"

Three digits of accuracy sounds quite good, configurable if
other lengths are desired.  This is not a serious problem.

>- GeneralizedTime does not need much work to present it to a user.
>  It seems to me that fractions in GeneralizedTime are intended
>  to convey information about higher precision time values;
>  I propose to allow subseconds in the genTime at least when
>  the other precision stuff is not present.
>
>  BTW: If a certificate says "notafter 23:59:59" means not after
>  the end of the second that starts with 23:59:59 because during
>  the whole second a clock shows that value.
>
>  If time stamps with a precision below a second are necessary
>  then it might also be necessary to change certificates, i.e.
>  extend the precision.
>
>- Is the serialnumber in the TSTTime unique within the second
>  expressed by genTime, or globally? (I have the feeling that

>>>1) when associated with the name of the TSA and the genTime it may
>>>be used to unambiguously reference a Time Stamp token for auditing
>>>purposes. In order to allow anyone to easily reference any token
>>>from any TSA, this field is mandatory.

>  indicates uniqueness within a second, if so, ok.
>
>- If a time stamp authority just want to sell stamps without
>  indication any particular order if they happen to be in the
>  same second, what should they code?

I think this should be forbidden.  It should always be possible to
take a sequence of timestamps and put them in their issued order.

>- Using the NTP logic to carry subseconds seems to be a left over
>  from a misunderstanding of requirements for "secure time" and
>  "time stamp". using the time stamp protocol to provide secure
>  time doesn't seem the a good approach anyway (I would start
>  using a kind of NTP over secured channel, IPSEC, TLS, etc.).

I agree with that, though the time format could be interchangeable.

Regards,
Michael McNeil


Received: from poptop.llnl.gov (poptop.llnl.gov [128.115.18.65]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id LAA00531 for <[e-mail]>; Wed, 4 Aug 1999 11:15:29 -0700 (PDT)
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 LAA04374; Wed, 4 Aug 1999 11:18:29 -0700 (PDT)
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.3 (32)
Date: Wed, 04 Aug 1999 11:17:35 -0700
To: "Aram Perez" <[e-mail]>, "'[e-mail]'" <[e-mail]>
From: Tony Bartoletti <[e-mail]>
Subject: Re: Non-Repudiation, was Re: Common misconceptions, was Re: KISSfor PKIX.   (Was: RE:ASN.1vs   XML   (used to be RE: I-D ACTION :draft-ietf-pkix-scvp-00.txt))
In-Reply-To: <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"

At 10:12 AM 8/4/99 -0700, Aram Perez wrote:

>I totally agree with Ed. I can always deny (a.k.a. repudiate) participating
>in a communication. And, at least in the US where I am presumed innocent
>until proven guilty, it would be up to the other party to prove that I did
>participate. However, this does not preclude me from agreeing to a
>non-repudiation clause in a contract where I agree that my digital signature
>signifies my participation in a communication.

[tony-snip]

>     "Security depends
>      on all parts of the  certificate-using SYSTEM, including but not
>      limited to: physical security of the place the computer resides;
>      personnel security (i.e., the trustworthiness of the people who
>      actually develop, install, run, and maintain the system); the
>      security provided by the operating system on which the private key
>      is used; and the security provided the CA.  A failure in any one
>      of these areas can cause the entire system security to fail."
>
>How can setting the NR bit ensure that there isn't a "failure in any one of
>those areas"?


Radically paraphrasing (I believe it was Steven Kent,) all that the
"non-repudiation bit" signifies is that, as far as the CA is concerned,
they assent to the use of a so-certified-key's signature in support of
a potential non-repudiation claim.

How far does that get anyone?  Not far. It is a bit like you want to
climb Mt. Everest, and to "support you" in this endeavor, I announce
that I will not stand in your way.

___tony___

P.S.  Has this thread been re-subjected enough times?  Reading it,
I feel a bit like an archaeologist.



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.meridianus.com (209.249.223.38.has.no.reverse [209.249.223.38] (may be forged)) by mail.proper.com (8.9.3/8.9.3) with ESMTP id KAA29866 for <[e-mail]>; Wed, 4 Aug 1999 10:53:03 -0700 (PDT)
Received: from got.net by www.meridianus.com (8.8.8+Sun/SMI-SVR4) id LAA26644; Wed, 4 Aug 1999 11:46:50 -0700 (PDT)
Message-ID: <[e-mail]>
Date: Wed, 04 Aug 1999 10:52:32 -0700
From: Michael McNeil <[e-mail]>
X-Mailer: Mozilla 4.51 [en] (WinNT; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Denis Pinkas <[e-mail]>
CC: IETF-PXIX <[e-mail]>
Subject: Re: TSP: New TSTTime definition
References: <[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Denis, thanks for your work here.  My comments are below.

Denis Pinkas wrote:
>At the last WG meeting in Oslo, we discussed the format
>of the TSTTime.
> 
>In order to accommodate the need for PKIX applications to use
>a time resolution up to the second and other applications wishing
>to get a signed time below the second, here is a new proposal.
>
>There are many ways to address this issue. The format of
>GeneralizedTime below the second has not been the chosen
>solution in order to use the same time format as used in CRLs
>and certificates. Optional fields allow to go below the second
>when this is really needed.
>
>The proposal also attempts to prevent a competition between TSAs
>taking only argument of their better time accuracy. In others
>words, an accuracy around the second is fairly sufficient for
>PKIX applications
>
>Before incorporating the new text in the next version, I would
>like to get the WG opinion whether this proposal is acceptable.
>
>The current definition of TSTTime is as follows:
>
>TSTTime ::= SEQUENCE  {
>    genTime                       GeneralizedTime,
>    fractionOfSecond              BIT STRING,
>    precisionFactor               INTEGER
>}
>
>Here is a proposal for a new structure and the text that applies
>to it:
>
>TSTTime ::= SEQUENCE  {
>    genTime                       GeneralizedTime,
>    serialNumber                  INTEGER,
>    precisionFactor               INTEGER       OPTIONAL,
>    fractionOfSecond              BIT STRING    OPTIONAL
>}
>
>GeneralizedTime shall be used as described in [RFC2459] Section
>4.1.2.5.2.  GeneralizedTime only represents time with one second
>granularity.
>
>The integer used for the serial number shall be a strictly
>monotonically increasing integer that will guarantee that
>each token is unique. It carries to functions:
>
>1) when associated with the name of the TSA and the genTime it
>may be used to unambiguously reference a Time Stamp token for
>auditing purposes. In order to allow anyone to easily reference
>any token from any TSA, this field is mandatory.
>
>2) it allows to discriminate between the ordering of multiple
>time stamps issued within the same second. When comparing two
>time stamps issued by the same TSA within the same second, the
>one which contains the smaller integer shall be assumed to have
>been generated first.
>
>The precision of the time indicated in genTime may be obtained
>through the security policy. Alternatively, the precisionFactor
>may be used if:
>
>1) the precision of the time is variable with the time,
>2) a precision better than the second is desirable. In such a
>case, the precisionFactor shall be used in conjunction with the
>fractionOfSecond field.
>
>It should be noticed that in many cases the precision of
>the clock is lost by the time of transit inherent to the
>transport protocol.

Very true.  The time shown should be the time at the TSA.

>Conforming TSAs do not need to support the precisionFactor and
>the fractionOfSecond fields.
>
>When the service is offered locally on the same machine,
>a precision below the second can make sense. In that case,
>the fractionOfSecond field is used in conjunction with
>the precisionFactor field to indicate the sub-seconds.
>
>The precisionFactor field is an optional field. It is a signed
>integer giving an upper bound on the difference between the
>timestamp and UTC when the timestamp was issued. The actual
>precision of the clock is calculated as power (2, precisionFactor).
>
>Note that this method defines a precision of a clock as 'being
>around the value', not as an exact figure.  The actual method and
>frequency of synchronising the clock with UTC time, as well as the
>characteristics of the clock itself, define the deviation from UTC.

And this is then reflected in the precision shown....

>A negative precisionFactor value indicates a precision as a
>fraction of a second. This may be useful when the service is local
>on the same machine. In that case the fractionOfSecond field is
>used in conjunction with it to indicate the sub-seconds.

If one is going to do this, why limit resolution to milliseconds?
(I'm afraid the concept of "dumbing down" the time format so TSAs
can't advertise imaginary resolutions doesn't appeal to me.  In my
view, simply require that only realistic resolutions be claimed.)

>For instance, precisionFactor=-5 would yield 2^(-5) = 0.03125 sec
>(31 ms). This precisionFactor would account for the 50-Hz (20 ms)
>or 60-Hz (16.67 ms) power-frequency clock that is closely
>synchronized with UTC, for example.
>
>A positive precisionFactor value indicates a precision above the
>second.
>
>The fractionOfSecond field is an optional field which shall be
>used only when the precisionFactor field is present. It is an
>unsigned integer indicating the fraction of second; i.e. with
>the most significant bit indicating 500 ms, the second 250 ms,
>and so on.

Now this is peculiar.  You say elsewhere, Denis, that this was
copied from the way that NTP does things.  It's true that NTP's
fractional seconds are represented as each bit being one half
of the predecessor's value.  However, NTP accomplishes this using
a base [i.e., 2^^(-32)] which is a power of two; thus each digit
stands for a whole number.  In the system described above, the
"and so on" a few bits later encounters 62.5 ms, 31.25 ms, and
so on.  Do we really want to encode a system which allows (only)
milliseconds as the fractional-seconds representation -- but
whose representation takes on _fractional_ millisecond values?

Regards,
Michael McNeil


Received: from www.meridianus.com (209.249.223.21.has.no.reverse [209.249.223.21] (may be forged)) by mail.proper.com (8.9.3/8.9.3) with ESMTP id KAA29085 for <[e-mail]>; Wed, 4 Aug 1999 10:26:20 -0700 (PDT)
Received: from got.net by www.meridianus.com (8.8.8+Sun/SMI-SVR4) id LAA26625; Wed, 4 Aug 1999 11:21:21 -0700 (PDT)
Message-ID: <[e-mail]>
Date: Wed, 04 Aug 1999 10:27:03 -0700
From: Michael McNeil <[e-mail]>
X-Mailer: Mozilla 4.51 [en] (WinNT; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Stefan Santesson <[e-mail]>
CC: Denis Pinkas <[e-mail]>, IETF-PXIX <[e-mail]>
Subject: Re: TSP: New TSTTime definition
References: <[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Stefan Santesson wrote:
>I agree to the previous comments regarding serialNumber in TSTTime.
>This serialNumber is no time information and should not be present
>here.
>
>I believe it would be much more clean to use the serialNumber
>in the TSTInfo to determine sequences and provide uniqueness in
>timestamps.
>
>I also believe that serialNumber should be optional. Far from all
>applications are concerned with sequence determination or need
>serialNumber to resist replay attacks.

There should be some random client bits included in the signed
timestamp which identifies the timestamp as in response to a
particular client request.  This is much better than using
a serial number as a method of resisting replay attacks.

(I'm not saying don't have include serial number, mind you.)

Michael McNeil


Received: from mail-out2.apple.com (mail-out2.apple.com [17.254.0.51]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id KAA28474 for <[e-mail]>; Wed, 4 Aug 1999 10:09:21 -0700 (PDT)
Received: from mailgate1.apple.com (A17-128-100-225.apple.com [17.128.100.225]) by mail-out2.apple.com (8.8.5/8.8.5) with ESMTP id KAA64936 for <[e-mail]>; Wed, 4 Aug 1999 10:12:23 -0700
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, 04 Aug 1999 10:12:17 -0700
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 KAA25422 for <[e-mail]>; Wed, 4 Aug 1999 10:12:15 -0700
Message-Id: <[e-mail]>
X-Mailer: Microsoft Outlook Express Macintosh Edition - 4.5 (0410)
Date: Wed, 04 Aug 1999 10:12:14 -0700
Subject: Re: Non-Repudiation, was Re: Common misconceptions, was Re: KISSfor PKIX.   (Was: RE:ASN.1vs   XML   (used to be RE: I-D 	ACTION :draft-ietf-pkix-scvp-00.txt))
From: "Aram Perez" <[e-mail]>
To: "'[e-mail]'" <[e-mail]>
MIME-Version: 1.0
X-Priority: 3
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit

Ed Gerck wrote:

> Stephen Kent wrote:
[snip]
> 
>> This is an IETF (technica)l WG, not the ABA Technical Committee on Digital
>> Signatures. The technical definition of NR that we use comes from ISO
>> 7498-2.  Paraphrasing (since I don't have the spec in front of me on this
>> plane flight), NR is defined as a security service employed to prevent a
>> party in a communication from later denying having participated in the
>> communication.   Time is not mentioned explicitly, but because the
>> communication took place at some time, it is an implied component of NR.
>
> Steve, so many things are "implied" -- that one needs to be careful not
> to have "implied security" as well.  What I mean is that we need clear
> and well-defined concepts, if we want clear results. If NR is "to prevent
> a party in a communication from later denying having participated in the
> communication" as you say above then we must immediatley agree that NR
> does not exist and never will.

I totally agree with Ed. I can always deny (a.k.a. repudiate) participating
in a communication. And, at least in the US where I am presumed innocent
until proven guilty, it would be up to the other party to prove that I did
participate. However, this does not preclude me from agreeing to a
non-repudiation clause in a contract where I agree that my digital signature
signifies my participation in a communication.

[snip]
>
> Thus, all I am saying is that the definition of NR being used in this WG
> is wrong and I don't care who defined it and where you based it -- while
> I also point out that ISO is a private organization, which definitions can
> be used or not and that none of them is some sort of "international treaty"
> or even "standard" or "fact".

Again Ed is correct, the definition of NR is wrong. Quoting for the PKIX
Roadmap:

     "Security depends
      on all parts of the  certificate-using SYSTEM, including but not
      limited to: physical security of the place the computer resides;
      personnel security (i.e., the trustworthiness of the people who
      actually develop, install, run, and maintain the system); the
      security provided by the operating system on which the private key
      is used; and the security provided the CA.  A failure in any one
      of these areas can cause the entire system security to fail."

How can setting the NR bit ensure that there isn't a "failure in any one of
those areas"?

[snip]

Regards,
Aram Perez


Received: from www.meridianus.com (209.249.223.38.has.no.reverse [209.249.223.38] (may be forged)) by mail.proper.com (8.9.3/8.9.3) with ESMTP id JAA27162 for <[e-mail]>; Wed, 4 Aug 1999 09:24:44 -0700 (PDT)
Received: from got.net by www.meridianus.com (8.8.8+Sun/SMI-SVR4) id KAA26537; Wed, 4 Aug 1999 10:21:51 -0700 (PDT)
Message-ID: <[e-mail]>
Date: Wed, 04 Aug 1999 09:27:35 -0700
From: Michael McNeil <[e-mail]>
X-Mailer: Mozilla 4.51 [en] (WinNT; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Aram Perez <[e-mail]>
CC: [e-mail]
Subject: Re: Lets Standardize Time Representation Formats!!!: WAS Re: NewTSTTime  definition
References: <[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Aram Perez wrote:
>Tony Bartoletti wrote:
>
>>Aram Perez wrote:
>>>I personally prefer a
>>>numerator/denominator approach such as (please excuse my ASN.1):
>>>
>>>    Seconds ::= SEQUENCE {
>>>        numerator INTEGER,
>>>        denominator INTEGER OPTIONAL DEFAULT 100
>>>    }

>>For compactness, (idea courtesy of Denis Pinkas earlier post) why
>>not specify the denominator as a power of 2? (bit-shifts are fast.)
>
>Sure, just make the default 2.

If we're specifying a denominator which is a power of 2, how about
2^^32 (the natural denominator for fractional quantities within a
32-bit binary cell), or 4,294,967,296.  This is the format used by
the fractional portion of the time in NTP (Network Time Protocol).
(In this quantity of time, light will travel about 3 inches.)

>>I can believe Todd's argument that high precisions/resolutions may
>>be/become important, but I wonder the utility of, say, denom = 119.

>>I would wonder also if someone used a denominator of 119. What I
>see is a trade-off between compactness and arbitrary precision. I'm
>just proposing a scheme where you can be as precise (or unprecise)
>as you want to be. In the long run, I think different "industries"
>would adopt different "standard" denominators.

Why not just tack on enough bits to satisfy all future expectations?
if 2^^(-32) isn't precise enough for future needs, then I'm prepared
to hear arguments in favor of 2^^(-64).  It's only 64 bits, with a
binary numeric format which is easily handled by today's processors.

Regards,
Michael McNeil


Received: from www.meridianus.com (209.249.223.16.has.no.reverse [209.249.223.16] (may be forged)) by mail.proper.com (8.9.3/8.9.3) with ESMTP id JAA26777 for <[e-mail]>; Wed, 4 Aug 1999 09:14:29 -0700 (PDT)
Received: from got.net by www.meridianus.com (8.8.8+Sun/SMI-SVR4) id KAA26520; Wed, 4 Aug 1999 10:11:33 -0700 (PDT)
Message-ID: <[e-mail]>
Date: Wed, 04 Aug 1999 09:17:16 -0700
From: Michael McNeil <[e-mail]>
X-Mailer: Mozilla 4.51 [en] (WinNT; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Peter Sylvester <[e-mail]>
CC: [e-mail], [e-mail]
Subject: Re: Lets Standardize Time Representation Formats!!!: WAS Re: NewTSTTime  definition
References: <[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Peter Sylvester wrote:

>>In your own environment, you are correct. The problem arises when
>>the order has to be agreed upon by more than just one party.

>The order is defined as the order of integers. A smaller number
>comes before a larger one.
>
>Which problem? The problem of what the counter actually means?
>Imagine an environment where you need to meet a deadline. The
>deadline is defined as the time stamp that is obtained by some
>trustworthy entity. Everybody knows that this entity will try to
>obtain a timestamp just at the deadline. You miss the deadline if
>your sequencenumber is higher.
>
>In this scenario the TSA does not need to use time in the stamps.

As long as each TSA gets to define "time" (what the counter means)
then this works.  However...

>The indication of what time it is at a particular counter
>simplifies the scenario, since everybody agrees that the time
>provided by the TSA is part of the game.

Time not only "simplifies" the scenario, it makes it possible to
function in the real world.  Imagine that one has a contract or
document timestamped by a TSA.  Would it be of any utility in
our world to say merely that the document was "time"stamped at
counter location 25,058,964,923 of a counter meaningful only
to the TSA?  I think not (but convince me otherwise...).

[snips]

Regards,
Michael McNeil


Received: from www.meridianus.com (209.249.223.25.has.no.reverse [209.249.223.25] (may be forged)) by mail.proper.com (8.9.3/8.9.3) with ESMTP id IAA24805 for <[e-mail]>; Wed, 4 Aug 1999 08:10:32 -0700 (PDT)
Received: from PC1 by www.meridianus.com (8.8.8+Sun/SMI-SVR4) id JAA26429; Wed, 4 Aug 1999 09:07:37 -0700 (PDT)
Message-ID: <042301bede8e$021eae40$[e-mail]>
From: "tog" <[e-mail]>
To: "Peter Sylvester" <[e-mail]>, <[e-mail]>, <[e-mail]>
References: <[e-mail]>
Subject: Re: Lets Standardize Time Representation Formats!!!: WAS Re: New TSTTime definition
Date: Wed, 4 Aug 1999 08:28:29 -0700
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.2918.2701
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2918.2701

Peter -
----- Original Message -----
From: Peter Sylvester <[e-mail]>
To: <[e-mail]>; <[e-mail]>
Sent: Wednesday, August 04, 1999 3:42 AM
Subject: Re: Lets Standardize Time Representation Formats!!!: WAS Re: New
TSTTime definition


> >
> > [snip]
> > > I am the authority that defines the order, and not something else.
> > > I do NOT mean with respect to time. If at all it is MY time, my
counter
> > > is my time, it is just a matter of convenience to use something
> > > that most people will understand. (I have not said that
> > > I don't need an indication of time in a time stamp, I was just taking
> > > about order).
> >
> > In your own environment, you are correct. The problem arises when the
order
> > has to be agreed upon by more than just one party.
> The order is defined as the order of integers. A smaller number comes
> before a larger one.
>
> Which problem? The problem of what the counter actually means?

Yes and how its referable to other counters in other parts of the world.
What binds the trust models together here. Simple. Their conformance to the
one thing on this planet that is agreed on by virtually all the nations on
this earth. UTC.

> Imagine an
> environment where you need to meet a deadline. The deadline is defined as
> the time stamp that is obtained by some trustworthy entity. Everybody
> knows that this entity will try to obtain a timestamp just at
> the deadline. You miss the deadline if your sequencenumber is higher.

This assumes that you are going to use a TSA based system that is public in
nature. What there is here is no real method or comparing the outputs from
separate TSA's becuase there is nothing to reference that the timebase
running below them is synchronous to squat. The issue isn't that the TSA is
broken its that when there are a number of TSA up everywhere and we have to
start interoperating between the logging systems that they support the
proofing models need to be made portable or their reference value is moot.

>
> In this scenario the TSA does not need to use time in the stamps.
>

Only if it is part of a system that only shows the order of which events in
a single environment happened.

> The indication of what time it is at a particular counter simplifies
> the scenario, since everybody agrees that the time provided by the TSA
> is part of the game.

But they don't and that's just the point. Just becuase we say so doesn't
mean jack to a Court without supporting evidence.

>
> Or, are you taking about several independant TSA: 'In order to meet a
> deadline, you need to have a time stamp from one of n well known
entities".
> in this case you do not compare the order of time stamps issued by
> different tsas. You test whether your time stamp meets the deadline.
> Again, the deadline can be defined by an indication of time in the stamp
> or by using an independant entity that gets the deadline stamp from
> all TSAs.
>
> You can compare two time stamps of different TSAs; the game consists
> of trusting in the ability of the TSA to sync their clocks. Either
> you trust, or you don't.

So 10 years later, how do I trust. What is there that instills trust that
the TSA was operated correctly or that there is any real reason to believe
that the stamp is accurate.

> Whether or how the TSA do the sync is not
> important; it may be important in order to decide whether one can
> set up this game, or not.

I guess that we have different use models for timestamping systems. In my
world, the accuracy of the clock is the key evidentiary issue.

>
> >
> > [snip]
> > >
> > > I agree with you that a time structure that will not expire in the
near
> > > future is important,

Why? - if the accuracy of the timebase is irrelevent why is time needed at
all? If the timebase is not a referrable point in a transaction, this field
could just as eaisly be a nonce or other social-process keying component.
The point is that the time is very very important to the process. It is the
point of contact with the road so to speak.

>>> what's wrong with an arbitrary long decimal
> > > subdivision of a second?
> >
> > Good, then we're in violent agreement ;-). I personally prefer a
> > numerator/denominator approach such as (please excuse my ASN.1):
> >
> >     Seconds ::= SEQUENCE {
> >         numerator INTEGER,
> >         denominator INTEGER OPTIONAL DEFAULT 100
> >     }

The UTC96 selection from the BERT draft works just fine here.


SNIP

Todd



Received: from www.meridianus.com (209.249.223.21.has.no.reverse [209.249.223.21] (may be forged)) by mail.proper.com (8.9.3/8.9.3) with ESMTP id IAA24709 for <[e-mail]>; Wed, 4 Aug 1999 08:09:34 -0700 (PDT)
Received: from PC1 by www.meridianus.com (8.8.8+Sun/SMI-SVR4) id IAA26400; Wed, 4 Aug 1999 08:57:42 -0700 (PDT)
Message-ID: <042001bede8c$a842cb50$[e-mail]>
From: "tog" <[e-mail]>
To: "Linn, John" <[e-mail]>, "'Nick Pope'" <[e-mail]>, "Denis Pinkas" <[e-mail]>
Cc: <[e-mail]>
References: <[e-mail]>
Subject: Re: Comments on PKIX Time Stamp Protocol
Date: Wed, 4 Aug 1999 08:18:35 -0700
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.2918.2701
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2918.2701

----- Original Message -----
From: Linn, John <[e-mail]>
To: 'Nick Pope' <[e-mail]>; Denis Pinkas <[e-mail]>
Cc: <[e-mail]>
Sent: Wednesday, August 04, 1999 5:59 AM
Subject: RE: Comments on PKIX Time Stamp Protocol


> I'll agree with Nick here; I think the operation of matching a hash
> algorithm OID against the TSA's current list of

'supported' may be a better word than 'acceptable' here.

> acceptable algorithms as a
> prerequisite for timestamp generation should be a policy-configurable
option
> rather than an architectural requirement.  Application of timestamps and
> determinations of algorithmic strength and appropriateness are distinct
> operations, which may not always be coupled appropriately at the same
place.
>

True!

>
SNIP




Received: from mail1.gte.net (mail1.gte.net [207.115.153.32]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id IAA24315 for <[e-mail]>; Wed, 4 Aug 1999 08:01:02 -0700 (PDT)
Received: from mike (1Cust226.tnt4.clearwater.fl.da.uu.net [208.252.69.226]) by mail1.gte.net  with SMTP ; id KAA12720 Wed, 4 Aug 1999 10:01:33 -0500 (CDT)
Message-ID: <005101bede89$584d4f60$cb1cf0cc@mike>
Reply-To: "Michael Duren" <[e-mail]>
From: "Michael Duren" <[e-mail]>
To: "Nick Pope" <[e-mail]>, "Denis Pinkas" <[e-mail]>
Cc: <[e-mail]>
Subject: Re: Comments on PKIX Time Stamp Protocol
Date: Wed, 4 Aug 1999 10:52:48 -0400
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

Going back to your proposed, optional Digest AlgID, if there is not a
declaration of the hash algorithm in the SIGNED timestamp, then how do you
prove to a another party that you used a particular algorithm?  Should that
party just trust you when you say, "I used algorithm X"?

It seems to me that TSAs will be motivated to support the newest, and best
hash algorithms.  If there is a new strong hash algorithm and it gains a
reasonable amount of acceptance, TSAs will certainly support it for
competitive and security reasons.

Mike Duren

-----Original Message-----
From: Nick Pope <[e-mail]>
To: Denis Pinkas <[e-mail]>
Cc: [e-mail] <[e-mail]>
Date: Wednesday, August 04, 1999 8:39 AM
Subject: RE: Comments on PKIX Time Stamp Protocol


>Denis,
>
>What I am suggesting allows the TSA to set up a service which refuses to
>timestamp any algorithm which it doesn't recognise.  So if if this was a
>concern then this policy could be applied.  However, in an open environment
>I believe that it is unnecessarily restrictive to mandate that the TSA has
>to recognise the hashing algorithm.  It gives no flexibility for the use of
>new hashing algorithms.
>
>Nick
>
>> -----Original Message-----
>> From: Denis Pinkas [mailto:[e-mail]]
>> Sent: 04 August 1999 11:32
>> To: Nick Pope
>> Cc: [e-mail]
>> Subject: Re: Comments on PKIX Time Stamp Protocol
>>
>>
>> Nick,
>>
>> Since there has been many messages sent on the TSTTime format, I
>> missed that message. Sorry for the delay to respond.
>>
>> > Comments on PKIX Time Stamp Protocol
>> > draft-ietf-pkix-time-stamp-02.txt
>> >
>> > I have been working on an ETSI electronic signature standard
>> which makes use
>> > of time-stamping and as a result would like to offer the a few
>> comments on
>> > the document:
>> >
>> > 1) Section 2.4 mandates that the Hash Algorithm is provided by
>> the client
>> > and has to be approved by the server.
>> >
>> > This protocol can't be used if the client has its own, perfectly good,
>> > hashing algorithm which isn't known to the time-stamping server.
>>
>> This is a correct interpretation from the correct text.
>>
>>
>> > The current text already only states that the  hashedMessage
>> field "SHOULD
>> > contain the hash", but the length of this field "MUST match the
>> length of
>> > the hash value for that algorithm".
>>
>> Good catch. We should say "when present, the hashedMessage field
>> SHALL contain the hash".
>>
>>
>> > The current protocol encourages the client to lie about the
>> hash algorithm
>> > employed !
>>
>> With the modification above, I do not think so.
>>
>>
>> > I therefore suggest that the definition of MessageImprint is changed as
>> > follows:
>> >
>> > " MessageImprint ::= SEQUENCE  {
>> >      hashAlgorithm                AlgorithmIdentifier  OPTIONAL,
>> >      hashedMessage                OCTET STRING  }
>> >
>>
>> The basic question is whether the TSA will or will not accept to
>> sign if it does not recognize the hash algorithm. From the
>> discussion we had on the list the consensus seems to be that if the
>> TSA knowns a hash algorithm to be weak (which is an appreciation at
>> the discretion of each TSA), the TSA will refuse to sign.
>>
>> Unless we change that point, the ASN1 should not be changed.
>>
>> A further side advantage is that the TSA can verify that the length
>> of the hash value matches the expected length of the hash algorithm.
>>
>>
>> >   The hash algorithm employed to to create the hashedMessage
>> field SHOULD
>> >   be a strong hash algorithm.  That means that it SHOULD be one-way and
>> >   collision resistant.  If the hashAlgorithm is present then the Time
>> >   stamp Authority MUST check whether or not the given hash algorithm is
>> >   known to be "sufficient" (based on the current state of knowledge in
>> >   cryptanalysis and the current state of the art in computational
>> >   resources, for
>> >   example).  The TSA may refuse to time stamp hashedMessage without an
>> >   indication of the hashAlgorithm depending on the security policy.
>> >
>> >   The hashedMessage field SHOULD contain the hash of the datum to be
>> >   time stamped.  The hash is represented as an OCTET STRING.  If  the
>> >   hashAlgorithm field is present the length of the hashedMessage field
>> >   MUST match the length of the hash value for that algorithm (e.g.
>> >   20 bytes for SHA-1 or 16 bytes for MD-5). "
>> >
>> > -------------------------------
>> >
>> > 2) In Appendix A "Storage of Data and Token" it states "the
>> contentType is
>> > signedData and contentInfo is Data, which contains the datum
>> associated with
>> > the time stamp token."  It also goes on to describe a signed
>> attribute to
>> > carry the timestamptoken.
>> >
>> > Surely if the Content Type is signedData the the contentInfo
>> must contain
>> > the CMS SignedData structure.  Also, the SignedData structure
>> is needed to
>> > carry signed attributes.
>> >
>> > Thus, I presume that Appendix A should read:
>> >
>> >   "A time stamp token is meaningless without its associated data. The
>> >   following method can be used to store data and token together
securely
>> >   as a PKCS #7 SignedData object as described in [CMS].
>> >
>> >   The contentType is id-signedData and contentInfo is
>> signedData.  Within
>> >   the signedData eContentType is id-data and the eContent contains the
>> >   datum associated with the time stamp token.  The SignedData object is
>> >   signed by the person storing the data and token.
>> >
>> >  ... (unchanged) ...
>> >
>> >   id-aa-timeStampToken     OBJECT IDENTIFIER ::= { id-aa 13 }
>> >   id-aa   OBJECT IDENTIFIER ::= { id-smime 2 }
>> >
>> >   The hashMessage value in the MessageImprint is calculated over the
>> >   datum as held in value of eContent within the signedData."
>>
>> What you say seems reasonable. I would have to take a closer look
>> when I produce the next version.
>>
>>
>> >
>> > -------------------------------
>> >
>> > 3) Finally in 2.4, Page 6:
>> >
>> > id-ct    OBJECT IDENTIFIER ::= { id-smime 1 }
>> > id-smime OBJECT IDENTIFIER ::= { iso(1) member-body(2)
>> >             us(840) rsadsi(113549) pkcs(1) pkcs-9(9) 16 }
>>
>> I will take care of this when I produce the next version.
>>
>> Thanks,
>>
>> Denis
>>
>>
>> > is repeated.
>>
>




Received: from www.meridianus.com (209.249.223.32.has.no.reverse [209.249.223.32] (may be forged)) by mail.proper.com (8.9.3/8.9.3) with ESMTP id HAA23210 for <[e-mail]>; Wed, 4 Aug 1999 07:31:58 -0700 (PDT)
Received: from PC1 by www.meridianus.com (8.8.8+Sun/SMI-SVR4) id IAA26355; Wed, 4 Aug 1999 08:23:43 -0700 (PDT)
Message-ID: <03c701bede87$dfb588c0$[e-mail]>
From: "tog" <[e-mail]>
To: "Manger, James" <[e-mail]>, <[e-mail]>
References: <[e-mail]>
Subject: Re: Lets Standardize Time Representation Formats!!!: WAS Re: New TSTTime definition
Date: Wed, 4 Aug 1999 07:44:36 -0700
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.2918.2701
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2918.2701

Because there is nothing that tells me what the collective value, i.e the
empirical accuracy, or what the source of the time data is, and that is
critical the portability of the trust models, that's why.

I should trust your time just because you say so?

FOLKS - this is not about the accurate delivery of time or representing it,
there a bazillion ways to do that already. What there isn't is in a single
instance something that tells you:

   1)     what the timesource is
   2)     who say's its good-to-go
   3)     what time the timebase of the event says "time it is"
   4)    and the event itself

The proofing models for timestamping either need the trust anchors for the
timestamp inside the token structure or as part of the token processing
infrastructure itself. It really doesn't work any other way.

I deference to Stephen Kent's feelings about my coining new terms like
"Trust Anchor" - A trust anchor is a key component of any trust process or
operation that yields a fixed point of view for the transaction itself. I.E
something that anchors the transaction to another 'something' that makes it
"referable".

Todd



----- Original Message -----
From: Manger, James <[e-mail]>
To: <[e-mail]>
Sent: Tuesday, August 03, 1999 11:13 PM
Subject: RE: Lets Standardize Time Representation Formats!!!: WAS Re: New
TSTTime definition


> GeneralizedTime is a basic ASN.1 type for representing time and already
> supports fractions of seconds.  For example "19851106210627.3Z" is a valid
> value.  SO WHY NOT USE IT!
>
> How about the following syntax & text:
> -----
> TSTInfo ::= SEQUENCE {
> ...
> time GeneralizedTime,
> uncertainty REAL  OPTIONAL, -- in seconds
> ...
> }
>
> The 'time' & 'uncertainty' fields specify the Universal Coordinated Time
at
> which the timestamp was created.  The 'time' value SHALL NOT be earlier
than
> the 'time' value in any timestamps already created by the TSA.
> -----
> I don't think anyone could misinterpret the syntax or semantics.  If
> desired, a TSA can use the arbitrarily high time resolution to indicate an
> unambiguous order for all the timestamps it creates.  If desired, a TSA
can
> use second resolution if it only wants to support non-repudiation (or
> support legacy applications that only partially understand the
> GeneralizedTime syntax).
>
>



Received: from tholian.securitydynamics.com (tholian.securid.com [204.167.112.129]) by mail.proper.com (8.9.3/8.9.3) with SMTP id FAA21074 for <[e-mail]>; Wed, 4 Aug 1999 05:54:40 -0700 (PDT)
Received: from sdtihq24.securitydynamics.com by tholian.securitydynamics.com via smtpd (for imc.org [206.184.129.134]) with SMTP; 4 Aug 1999 12:56:55 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 IAA27025; Wed, 4 Aug 1999 08:50:30 -0400 (EDT)
Received: by exna00.securitydynamics.com with Internet Mail Service (5.5.2232.9) id <QGL9NVQS>; Wed, 4 Aug 1999 08:56:09 -0400
Message-ID: <[e-mail]>
From: "Linn, John" <[e-mail]>
To: "'Nick Pope'" <[e-mail]>, Denis Pinkas <[e-mail]>
Cc: [e-mail]
Subject: RE: Comments on PKIX Time Stamp Protocol
Date: Wed, 4 Aug 1999 08:59:58 -0400 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2232.9)
Content-Type: text/plain; charset="iso-8859-1"

I'll agree with Nick here; I think the operation of matching a hash
algorithm OID against the TSA's current list of acceptable algorithms as a
prerequisite for timestamp generation should be a policy-configurable option
rather than an architectural requirement.  Application of timestamps and
determinations of algorithmic strength and appropriateness are distinct
operations, which may not always be coupled appropriately at the same place.


--jl

> -----Original Message-----
> From: Nick Pope [mailto:[e-mail]]
> Sent: Wednesday, August 04, 1999 8:35 AM
> To: Denis Pinkas
> Cc: [e-mail]
> Subject: RE: Comments on PKIX Time Stamp Protocol
> 
> 
> Denis,
> 
> What I am suggesting allows the TSA to set up a service which 
> refuses to
> timestamp any algorithm which it doesn't recognise.  So if if 
> this was a
> concern then this policy could be applied.  However, in an 
> open environment
> I believe that it is unnecessarily restrictive to mandate 
> that the TSA has
> to recognise the hashing algorithm.  It gives no flexibility 
> for the use of
> new hashing algorithms.
> 
> Nick
> 
> > -----Original Message-----
> > From: Denis Pinkas [mailto:[e-mail]]
> > Sent: 04 August 1999 11:32
> > To: Nick Pope
> > Cc: [e-mail]
> > Subject: Re: Comments on PKIX Time Stamp Protocol
> >
> >
> > Nick,
> >
> > Since there has been many messages sent on the TSTTime format, I
> > missed that message. Sorry for the delay to respond.
> >
> > > Comments on PKIX Time Stamp Protocol
> > > draft-ietf-pkix-time-stamp-02.txt
> > >
> > > I have been working on an ETSI electronic signature standard
> > which makes use
> > > of time-stamping and as a result would like to offer the a few
> > comments on
> > > the document:
> > >
> > > 1) Section 2.4 mandates that the Hash Algorithm is provided by
> > the client
> > > and has to be approved by the server.
> > >
> > > This protocol can't be used if the client has its own, 
> perfectly good,
> > > hashing algorithm which isn't known to the time-stamping server.
> >
> > This is a correct interpretation from the correct text.
> >
> >
> > > The current text already only states that the  hashedMessage
> > field "SHOULD
> > > contain the hash", but the length of this field "MUST match the
> > length of
> > > the hash value for that algorithm".
> >
> > Good catch. We should say "when present, the hashedMessage field
> > SHALL contain the hash".
> >
> >
> > > The current protocol encourages the client to lie about the
> > hash algorithm
> > > employed !
> >
> > With the modification above, I do not think so.
> >
> >
> > > I therefore suggest that the definition of MessageImprint 
> is changed as
> > > follows:
> > >
> > > " MessageImprint ::= SEQUENCE  {
> > >      hashAlgorithm                AlgorithmIdentifier  OPTIONAL,
> > >      hashedMessage                OCTET STRING  }
> > >
> >
> > The basic question is whether the TSA will or will not accept to
> > sign if it does not recognize the hash algorithm. From the
> > discussion we had on the list the consensus seems to be that if the
> > TSA knowns a hash algorithm to be weak (which is an appreciation at
> > the discretion of each TSA), the TSA will refuse to sign.
> >
> > Unless we change that point, the ASN1 should not be changed.
> >
> > A further side advantage is that the TSA can verify that the length
> > of the hash value matches the expected length of the hash algorithm.
> >
> >
> > >   The hash algorithm employed to to create the hashedMessage
> > field SHOULD
> > >   be a strong hash algorithm.  That means that it SHOULD 
> be one-way and
> > >   collision resistant.  If the hashAlgorithm is present 
> then the Time
> > >   stamp Authority MUST check whether or not the given 
> hash algorithm is
> > >   known to be "sufficient" (based on the current state of 
> knowledge in
> > >   cryptanalysis and the current state of the art in computational
> > >   resources, for
> > >   example).  The TSA may refuse to time stamp 
> hashedMessage without an
> > >   indication of the hashAlgorithm depending on the 
> security policy.
> > >
> > >   The hashedMessage field SHOULD contain the hash of the 
> datum to be
> > >   time stamped.  The hash is represented as an OCTET 
> STRING.  If  the
> > >   hashAlgorithm field is present the length of the 
> hashedMessage field
> > >   MUST match the length of the hash value for that algorithm (e.g.
> > >   20 bytes for SHA-1 or 16 bytes for MD-5). "
> > >
> > > -------------------------------
> > >
> > > 2) In Appendix A "Storage of Data and Token" it states "the
> > contentType is
> > > signedData and contentInfo is Data, which contains the datum
> > associated with
> > > the time stamp token."  It also goes on to describe a signed
> > attribute to
> > > carry the timestamptoken.
> > >
> > > Surely if the Content Type is signedData the the contentInfo
> > must contain
> > > the CMS SignedData structure.  Also, the SignedData structure
> > is needed to
> > > carry signed attributes.
> > >
> > > Thus, I presume that Appendix A should read:
> > >
> > >   "A time stamp token is meaningless without its 
> associated data. The
> > >   following method can be used to store data and token 
> together securely
> > >   as a PKCS #7 SignedData object as described in [CMS].
> > >
> > >   The contentType is id-signedData and contentInfo is
> > signedData.  Within
> > >   the signedData eContentType is id-data and the eContent 
> contains the
> > >   datum associated with the time stamp token.  The 
> SignedData object is
> > >   signed by the person storing the data and token.
> > >
> > >  ... (unchanged) ...
> > >
> > >   id-aa-timeStampToken     OBJECT IDENTIFIER ::= { id-aa 13 }
> > >   id-aa   OBJECT IDENTIFIER ::= { id-smime 2 }
> > >
> > >   The hashMessage value in the MessageImprint is 
> calculated over the
> > >   datum as held in value of eContent within the signedData."
> >
> > What you say seems reasonable. I would have to take a closer look
> > when I produce the next version.
> >
> >
> > >
> > > -------------------------------
> > >
> > > 3) Finally in 2.4, Page 6:
> > >
> > > id-ct    OBJECT IDENTIFIER ::= { id-smime 1 }
> > > id-smime OBJECT IDENTIFIER ::= { iso(1) member-body(2)
> > >             us(840) rsadsi(113549) pkcs(1) pkcs-9(9) 16 }
> >
> > I will take care of this when I produce the next version.
> >
> > Thanks,
> >
> > Denis
> >
> >
> > > is repeated.
> >
> 


Received: from gnasher.sol.co.uk (gnasher.sol.co.uk [194.247.65.2]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id FAA20435 for <[e-mail]>; Wed, 4 Aug 1999 05:31:42 -0700 (PDT)
Received: from npwork2 (e2c9p28.scotland.net [148.176.238.28]) by gnasher.sol.co.uk (8.8.5/8.8.5) with SMTP id NAA02329; Wed, 4 Aug 1999 13:31:21 +0100 (BST)
From: "Nick Pope" <[e-mail]>
To: "Denis Pinkas" <[e-mail]>
Cc: <[e-mail]>
Subject: RE: Comments on PKIX Time Stamp Protocol
Date: Wed, 4 Aug 1999 13:34:46 +0100
Message-ID: <000401bede75$bc9fc600$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
In-Reply-To: <[e-mail]>
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3

Denis,

What I am suggesting allows the TSA to set up a service which refuses to
timestamp any algorithm which it doesn't recognise.  So if if this was a
concern then this policy could be applied.  However, in an open environment
I believe that it is unnecessarily restrictive to mandate that the TSA has
to recognise the hashing algorithm.  It gives no flexibility for the use of
new hashing algorithms.

Nick

> -----Original Message-----
> From: Denis Pinkas [mailto:[e-mail]]
> Sent: 04 August 1999 11:32
> To: Nick Pope
> Cc: [e-mail]
> Subject: Re: Comments on PKIX Time Stamp Protocol
>
>
> Nick,
>
> Since there has been many messages sent on the TSTTime format, I
> missed that message. Sorry for the delay to respond.
>
> > Comments on PKIX Time Stamp Protocol
> > draft-ietf-pkix-time-stamp-02.txt
> >
> > I have been working on an ETSI electronic signature standard
> which makes use
> > of time-stamping and as a result would like to offer the a few
> comments on
> > the document:
> >
> > 1) Section 2.4 mandates that the Hash Algorithm is provided by
> the client
> > and has to be approved by the server.
> >
> > This protocol can't be used if the client has its own, perfectly good,
> > hashing algorithm which isn't known to the time-stamping server.
>
> This is a correct interpretation from the correct text.
>
>
> > The current text already only states that the  hashedMessage
> field "SHOULD
> > contain the hash", but the length of this field "MUST match the
> length of
> > the hash value for that algorithm".
>
> Good catch. We should say "when present, the hashedMessage field
> SHALL contain the hash".
>
>
> > The current protocol encourages the client to lie about the
> hash algorithm
> > employed !
>
> With the modification above, I do not think so.
>
>
> > I therefore suggest that the definition of MessageImprint is changed as
> > follows:
> >
> > " MessageImprint ::= SEQUENCE  {
> >      hashAlgorithm                AlgorithmIdentifier  OPTIONAL,
> >      hashedMessage                OCTET STRING  }
> >
>
> The basic question is whether the TSA will or will not accept to
> sign if it does not recognize the hash algorithm. From the
> discussion we had on the list the consensus seems to be that if the
> TSA knowns a hash algorithm to be weak (which is an appreciation at
> the discretion of each TSA), the TSA will refuse to sign.
>
> Unless we change that point, the ASN1 should not be changed.
>
> A further side advantage is that the TSA can verify that the length
> of the hash value matches the expected length of the hash algorithm.
>
>
> >   The hash algorithm employed to to create the hashedMessage
> field SHOULD
> >   be a strong hash algorithm.  That means that it SHOULD be one-way and
> >   collision resistant.  If the hashAlgorithm is present then the Time
> >   stamp Authority MUST check whether or not the given hash algorithm is
> >   known to be "sufficient" (based on the current state of knowledge in
> >   cryptanalysis and the current state of the art in computational
> >   resources, for
> >   example).  The TSA may refuse to time stamp hashedMessage without an
> >   indication of the hashAlgorithm depending on the security policy.
> >
> >   The hashedMessage field SHOULD contain the hash of the datum to be
> >   time stamped.  The hash is represented as an OCTET STRING.  If  the
> >   hashAlgorithm field is present the length of the hashedMessage field
> >   MUST match the length of the hash value for that algorithm (e.g.
> >   20 bytes for SHA-1 or 16 bytes for MD-5). "
> >
> > -------------------------------
> >
> > 2) In Appendix A "Storage of Data and Token" it states "the
> contentType is
> > signedData and contentInfo is Data, which contains the datum
> associated with
> > the time stamp token."  It also goes on to describe a signed
> attribute to
> > carry the timestamptoken.
> >
> > Surely if the Content Type is signedData the the contentInfo
> must contain
> > the CMS SignedData structure.  Also, the SignedData structure
> is needed to
> > carry signed attributes.
> >
> > Thus, I presume that Appendix A should read:
> >
> >   "A time stamp token is meaningless without its associated data. The
> >   following method can be used to store data and token together securely
> >   as a PKCS #7 SignedData object as described in [CMS].
> >
> >   The contentType is id-signedData and contentInfo is
> signedData.  Within
> >   the signedData eContentType is id-data and the eContent contains the
> >   datum associated with the time stamp token.  The SignedData object is
> >   signed by the person storing the data and token.
> >
> >  ... (unchanged) ...
> >
> >   id-aa-timeStampToken     OBJECT IDENTIFIER ::= { id-aa 13 }
> >   id-aa   OBJECT IDENTIFIER ::= { id-smime 2 }
> >
> >   The hashMessage value in the MessageImprint is calculated over the
> >   datum as held in value of eContent within the signedData."
>
> What you say seems reasonable. I would have to take a closer look
> when I produce the next version.
>
>
> >
> > -------------------------------
> >
> > 3) Finally in 2.4, Page 6:
> >
> > id-ct    OBJECT IDENTIFIER ::= { id-smime 1 }
> > id-smime OBJECT IDENTIFIER ::= { iso(1) member-body(2)
> >             us(840) rsadsi(113549) pkcs(1) pkcs-9(9) 16 }
>
> I will take care of this when I produce the next version.
>
> Thanks,
>
> Denis
>
>
> > is repeated.
>



Received: from edelweb.fr (edelweb.fr [193.51.12.16]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id DAA14363 for <[e-mail]>; Wed, 4 Aug 1999 03:40:02 -0700 (PDT)
Received: from champagne.edelweb.fr (localhost.edelweb.fr [127.0.0.1]) by edelweb.fr with ESMTP id MAA25153; Wed, 4 Aug 1999 12:43:00 +0200 (MET DST)
Received: from champagne.edelweb.fr (champagne.edelweb.fr [193.51.14.161]) by edelweb.fr (nospam/1.1); Wed, 4 Aug 1999 12:42:59 +0200 (MET DST)
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 MAA09387; Wed, 4 Aug 1999 12:42:58 +0200 (MET DST)
From: Peter Sylvester <[e-mail]>
Received: (sylvest@localhost) by emeriau.edelweb.fr (8.7.6/8.6.6) id MAA25992; Wed, 4 Aug 1999 12:42:58 +0200 (MET DST)
Date: Wed, 4 Aug 1999 12:42:58 +0200 (MET DST)
Message-Id: <[e-mail]>
To: [e-mail], [e-mail]
Subject: Re: Lets Standardize Time Representation Formats!!!: WAS Re: New TSTTime definition

> 
> [snip]
> > I am the authority that defines the order, and not something else.
> > I do NOT mean with respect to time. If at all it is MY time, my counter
> > is my time, it is just a matter of convenience to use something
> > that most people will understand. (I have not said that
> > I don't need an indication of time in a time stamp, I was just taking
> > about order).
> 
> In your own environment, you are correct. The problem arises when the order
> has to be agreed upon by more than just one party.
The order is defined as the order of integers. A smaller number comes
before a larger one.  

Which problem? The problem of what the counter actually means? Imagine an
environment where you need to meet a deadline. The deadline is defined as
the time stamp that is obtained by some trustworthy entity. Everybody 
knows that this entity will try to obtain a timestamp just at 
the deadline. You miss the deadline if your sequencenumber is higher.

In this scenario the TSA does not need to use time in the stamps.

The indication of what time it is at a particular counter simplifies 
the scenario, since everybody agrees that the time provided by the TSA
is part of the game. 

Or, are you taking about several independant TSA: 'In order to meet a
deadline, you need to have a time stamp from one of n well known entities".
in this case you do not compare the order of time stamps issued by
different tsas. You test whether your time stamp meets the deadline.
Again, the deadline can be defined by an indication of time in the stamp
or by using an independant entity that gets the deadline stamp from
all TSAs.

You can compare two time stamps of different TSAs; the game consists
of trusting in the ability of the TSA to sync their clocks. Either
you trust, or you don't. Whether or how the TSA do the sync is not
important; it may be important in order to decide whether one can
set up this game, or not.

> 
> [snip]
> >
> > I agree with you that a time structure that will not expire in the near
> > future is important, what's wrong with an arbitrary long decimal
> > subdivision of a second?
> 
> Good, then we're in violent agreement ;-). I personally prefer a
> numerator/denominator approach such as (please excuse my ASN.1):
> 
>     Seconds ::= SEQUENCE {
>         numerator INTEGER,
>         denominator INTEGER OPTIONAL DEFAULT 100
>     }

Well, if you want only decimal fractions I'd prefer the log10 of the denominator. 

Bit shifts and binary to decimal conversion are NOT FAST for humans.
if the bank tells me that they refused my payment because 
if was 1.000.000.000+65875655*47**-7 seconds after 1jan1970 I'll
change the bank. 

But we are not counting seconds in this context, aren't the time stamps
a refinement of a second-based generalizedTime used in other areas like
certificates, signing date etc?
generalizedTime as it supports decimal fractions. 


Regards


Received: from clbull.frcl.bull.fr (clbull.frcl.bull.fr [129.182.8.31]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id DAA13566 for <[e-mail]>; Wed, 4 Aug 1999 03:28:53 -0700 (PDT)
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 MAA09382; Wed, 4 Aug 1999 12:31:49 +0200
Message-ID: <[e-mail]>
Date: Wed, 04 Aug 1999 12:31:48 +0200
From: Denis Pinkas <[e-mail]>
Organization: Bull
X-Mailer: Mozilla 4.06 [fr] (Win95; I)
MIME-Version: 1.0
To: Nick Pope <[e-mail]>
CC: [e-mail]
Subject: Re: Comments on PKIX Time Stamp Protocol
References: <001501bedcdb$2af91cb0$0500000a@npwork2>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Nick,

Since there has been many messages sent on the TSTTime format, I
missed that message. Sorry for the delay to respond.

> Comments on PKIX Time Stamp Protocol
> draft-ietf-pkix-time-stamp-02.txt
> 
> I have been working on an ETSI electronic signature standard which makes use
> of time-stamping and as a result would like to offer the a few comments on
> the document:
> 
> 1) Section 2.4 mandates that the Hash Algorithm is provided by the client
> and has to be approved by the server.
> 
> This protocol can't be used if the client has its own, perfectly good,
> hashing algorithm which isn't known to the time-stamping server.

This is a correct interpretation from the correct text.

 
> The current text already only states that the  hashedMessage field "SHOULD
> contain the hash", but the length of this field "MUST match the length of
> the hash value for that algorithm".

Good catch. We should say "when present, the hashedMessage field
SHALL contain the hash". 

 
> The current protocol encourages the client to lie about the hash algorithm
> employed !

With the modification above, I do not think so.

 
> I therefore suggest that the definition of MessageImprint is changed as
> follows:
> 
> " MessageImprint ::= SEQUENCE  {
>      hashAlgorithm                AlgorithmIdentifier  OPTIONAL,
>      hashedMessage                OCTET STRING  }
> 

The basic question is whether the TSA will or will not accept to
sign if it does not recognize the hash algorithm. From the
discussion we had on the list the consensus seems to be that if the
TSA knowns a hash algorithm to be weak (which is an appreciation at
the discretion of each TSA), the TSA will refuse to sign.

Unless we change that point, the ASN1 should not be changed.

A further side advantage is that the TSA can verify that the length
of the hash value matches the expected length of the hash algorithm. 


>   The hash algorithm employed to to create the hashedMessage field SHOULD
>   be a strong hash algorithm.  That means that it SHOULD be one-way and
>   collision resistant.  If the hashAlgorithm is present then the Time
>   stamp Authority MUST check whether or not the given hash algorithm is
>   known to be "sufficient" (based on the current state of knowledge in
>   cryptanalysis and the current state of the art in computational
>   resources, for
>   example).  The TSA may refuse to time stamp hashedMessage without an
>   indication of the hashAlgorithm depending on the security policy.
> 
>   The hashedMessage field SHOULD contain the hash of the datum to be
>   time stamped.  The hash is represented as an OCTET STRING.  If  the
>   hashAlgorithm field is present the length of the hashedMessage field
>   MUST match the length of the hash value for that algorithm (e.g.
>   20 bytes for SHA-1 or 16 bytes for MD-5). "
> 
> -------------------------------
> 
> 2) In Appendix A "Storage of Data and Token" it states "the contentType is
> signedData and contentInfo is Data, which contains the datum associated with
> the time stamp token."  It also goes on to describe a signed attribute to
> carry the timestamptoken.
> 
> Surely if the Content Type is signedData the the contentInfo must contain
> the CMS SignedData structure.  Also, the SignedData structure is needed to
> carry signed attributes.
> 
> Thus, I presume that Appendix A should read:
> 
>   "A time stamp token is meaningless without its associated data. The
>   following method can be used to store data and token together securely
>   as a PKCS #7 SignedData object as described in [CMS].
> 
>   The contentType is id-signedData and contentInfo is signedData.  Within
>   the signedData eContentType is id-data and the eContent contains the
>   datum associated with the time stamp token.  The SignedData object is
>   signed by the person storing the data and token.
> 
>  ... (unchanged) ...
> 
>   id-aa-timeStampToken     OBJECT IDENTIFIER ::= { id-aa 13 }
>   id-aa   OBJECT IDENTIFIER ::= { id-smime 2 }
> 
>   The hashMessage value in the MessageImprint is calculated over the
>   datum as held in value of eContent within the signedData."

What you say seems reasonable. I would have to take a closer look
when I produce the next version.


> 
> -------------------------------
> 
> 3) Finally in 2.4, Page 6:
> 
> id-ct    OBJECT IDENTIFIER ::= { id-smime 1 }
> id-smime OBJECT IDENTIFIER ::= { iso(1) member-body(2)
>             us(840) rsadsi(113549) pkcs(1) pkcs-9(9) 16 }

I will take care of this when I produce the next version.

Thanks,

Denis

 
> is repeated.


Received: from mailo.vtcif.telstra.com.au (mailo.vtcif.telstra.com.au [202.12.144.17]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id XAA27543 for <[e-mail]>; Tue, 3 Aug 1999 23:13:59 -0700 (PDT)
Received: (from uucp@localhost) by mailo.vtcif.telstra.com.au (8.8.2/8.6.9) id QAA14075 for <[e-mail]>; Wed, 4 Aug 1999 16:16:26 +1000 (EST)
Received: from maili.vtcif.telstra.com.au(202.12.142.17) via SMTP by mailo.vtcif.telstra.com.au, id smtpdlODWu_; Wed Aug  4 16:15:59 1999
Received: (from uucp@localhost) by maili.vtcif.telstra.com.au (8.8.2/8.6.9) id QAA23385 for <[e-mail]>; Wed, 4 Aug 1999 16:15:58 +1000 (EST)
Received: from mail.cdn.telstra.com.au(144.135.138.138) via SMTP by maili.vtcif.telstra.com.au, id smtpd0MdNxx; Wed Aug  4 16:15:23 1999
Received: from ntmsg0011.corpmail.telstra.com.au (ntmsg0011.corpmail.telstra.com.au [172.85.14.20]) by mail.cdn.telstra.com.au (8.8.2/8.6.9) with ESMTP id QAA13250 for <[e-mail]>; Wed, 4 Aug 1999 16:15:22 +1000 (EST)
Message-Id: <[e-mail]>
Received: by ntmsg0011.corpmail.telstra.com.au with Internet Mail Service (5.5.2448.0) id <QHM57QG7>; Wed, 4 Aug 1999 16:15:39 +1000
From: "Manger, James" <[e-mail]>
To: [e-mail]
Subject: RE: Lets Standardize Time Representation Formats!!!: WAS Re: New  TSTTime definition
Date: Wed, 4 Aug 1999 16:13:06 +1000 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2448.0)
Content-Type: multipart/mixed; boundary="----_=_NextPart_000_01BEDE40.C448C36E"

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_01BEDE40.C448C36E
Content-Type: text/plain

GeneralizedTime is a basic ASN.1 type for representing time and already
supports fractions of seconds.  For example "19851106210627.3Z" is a valid
value.  SO WHY NOT USE IT!

How about the following syntax & text:
-----
TSTInfo ::= SEQUENCE {
	...
	time		GeneralizedTime,
	uncertainty	REAL  OPTIONAL, -- in seconds
	...
}

The 'time' & 'uncertainty' fields specify the Universal Coordinated Time at
which the timestamp was created.  The 'time' value SHALL NOT be earlier than
the 'time' value in any timestamps already created by the TSA.
-----
I don't think anyone could misinterpret the syntax or semantics.  If
desired, a TSA can use the arbitrarily high time resolution to indicate an
unambiguous order for all the timestamps it creates.  If desired, a TSA can
use second resolution if it only wants to support non-repudiation (or
support legacy applications that only partially understand the
GeneralizedTime syntax).


------_=_NextPart_000_01BEDE40.C448C36E
Content-Type: application/ms-tnef
Content-Transfer-Encoding: base64

eJ8+IigGAQaQCAAEAAAAAAABAAEAAQeQBgAIAAAA5AQAAAAAAADoAAEIgAcAGAAAAElQTS5NaWNy
b3NvZnQgTWFpbC5Ob3RlADEIAQSAAQBUAAAAUkU6IExldHMgU3RhbmRhcmRpemUgVGltZSBSZXBy
ZXNlbnRhdGlvbiBGb3JtYXRzISEhOiBXQVMgUmU6IE5ldyBUU1RUaW1lIGRlZmluaXRpb24AthwB
CYABACEAAABENjM1Q0VENkY4NDlEMzExQkNGQzAwMTA0QjA4REJGMQBSBwEggAMADgAAAM8HCAAE
ABAADwAkAAMAKAEBBYADAA4AAADPBwgABAAQAA0ABgADAAgBAQ2ABAACAAAAAgACAAEDkAYAHAcA
AB4AAAADAC4AAAAAAEAAOQBgEZVqQN6+AR4AcAABAAAAUAAAAExldHMgU3RhbmRhcmRpemUgVGlt
ZSBSZXByZXNlbnRhdGlvbiBGb3JtYXRzISEhOiBXQVMgUmU6IE5ldyBUU1RUaW1lIGRlZmluaXRp
b24AAgFxAAEAAAAbAAAAAb7d4lWsI5hNaUnTEdOuRQAIxySt0gAVVPwBAAIBCRABAAAAUAMAAEwD
AAD3BAAATFpGdaXrmiIDAAoAcmNwZzEyNf4yAP8CBgKkA+QF6wKDAFATA1QCAGNoCsBzZXT+MgYA
BsMCgw5QA9UHEwKA/n0KgAjPCdkCgAqBDnELYKBuZzMwOABQaAWwUHpkb2MAACoSVSB7ApEYQGwY
dQr7E7IB0CDORwnwBJAHQGl6CYAHYoIgBAAgYSBiYQ3RARQwU04uMSB0ed5wG8ACEAXAFZBwFZAS
sLsCMAuAZxzgG6IAcGQcAAJsFZBhZHkgc3X8cHAVMQQgA1AA0B4AAiA5BCBvZh9QBZEesHMuCCAg
RgWxZXhhbQMLUBvAIjE5ODUxEDEwNjIigjcuM/RaIhvUdhsxHsAjsQpQgSExU08gV0hZB7AAT1Qg
VVNFIEnMVCEKhQqFSG8H4AGg0whgBUB0aB0ibBUgA/AJHiFzeQIwYXggJtMc4CGgdDoKhS0pYgqF
IFRTVEluAhAgOgQ6PQYARVFVRU4yQyVgXHsKhgGRIC6/LFArmh5SLAMsAxrtLCua+HVuYwSQAZAL
gBzwLAOQUkVBTCFAT1AqQPRPTjEALClRG9ADoCDFryufCqQWsiXpVCdBJx5SWicocScv6TWgZgiQ
bHchEB9QHRBjBpAfQCcyVdUDAHYEkHMHQCAIUAWwemQLgGEooB7AG5M5ACC0d2gN4GgnIx5ScwGQ
9yHQOcAcQCAFAB8QOREhMXc1GSQTBgBIMQAxECUCYvsbwB8QchtABJAnIQORJzL/PDsyEQBwN5E6
hhvxHvU7VTccIDeUKiBBLHYpakkg3RfwbjVQJyELgGs/0gIgyxvABaB1NvAgbQQAMFH/BJAdoScU
KBUFsRKwA4EeAPpjISJJIKAOcACQFZExwO8cEEJBO0ADkXUSsCcjCsDYYml0GyAFEGwfQDng/mc6
ERuiHbEG8CcAIEEc4P8qgAuAONBI8CigHpEv0SHA+UnQZ3UIYCBxCyA+IR1C/wdAAyA6OwQgSeA7
RUefSKv/IMRLCgaQTzICIEpBOxACMKcEIEvBH2UgbgIgLR2B7nU40DkAS4IoRuJUJSHw9mcA0B9A
YR+AG0BMMSBD/z5RUxUKsR4AThEfQC/gBIHfOrEesScyGu4oFCksdgqFBRSxAFxgAwD9P1IDAAAe
AEIQAQAAADMAAAA8My4wLjMuMzIuMTk5OTA4MDMxMTU3MTUuMDBjMTgxMDBAcG9wdG9wLmxsbmwu
Z292PgAAAwAmAAAAAAADADYAAAAAAB4AMUABAAAAEAAAAEpNQU5HRVIyOTI4OEVGMwADABpAAAAA
AB4AMEABAAAAEAAAAEpNQU5HRVIyOTI4OEVGMwADABlAAAAAAAIB+T8BAAAAZwAAAAAAAADcp0DI
wEIQGrS5CAArL+GCAQAAAAYAAAAvTz1URUxTVFJBL09VPVFMRCBLSU5HU0ZPUkQtU01JVEgvQ049
TVMgTUFJTCBSRUNJUElFTlRTL0NOPUpNQU5HRVIyOTI4OEVGMwAAHgD4PwEAAAAOAAAATWFuZ2Vy
LCBKYW1lcwAAAB4AOEABAAAAEAAAAEpNQU5HRVIyOTI4OEVGMwACAfs/AQAAAGcAAAAAAAAA3KdA
yMBCEBq0uQgAKy/hggEAAAAGAAAAL089VEVMU1RSQS9PVT1RTEQgS0lOR1NGT1JELVNNSVRIL0NO
PU1TIE1BSUwgUkVDSVBJRU5UUy9DTj1KTUFOR0VSMjkyODhFRjMAAB4A+j8BAAAADgAAAE1hbmdl
ciwgSmFtZXMAAAAeADlAAQAAABAAAABKTUFOR0VSMjkyODhFRjMAQAAHMCDvnak33r4BQAAIMG7D
SMRA3r4BHgA9AAEAAAAFAAAAUkU6IAAAAAAeAB0OAQAAAFAAAABMZXRzIFN0YW5kYXJkaXplIFRp
bWUgUmVwcmVzZW50YXRpb24gRm9ybWF0cyEhITogV0FTIFJlOiBOZXcgVFNUVGltZSBkZWZpbml0
aW9uAAsAKQAAAAAACwAjAAAAAAADAAYQJtVLcAMABxDjAgAAAwAQEAAAAAADABEQAQAAAB4ACBAB
AAAAZQAAAEdFTkVSQUxJWkVEVElNRUlTQUJBU0lDQVNOMVRZUEVGT1JSRVBSRVNFTlRJTkdUSU1F
QU5EQUxSRUFEWVNVUFBPUlRTRlJBQ1RJT05TT0ZTRUNPTkRTRk9SRVhBTVBMRSIxOTgAAAAAwuA=

------_=_NextPart_000_01BEDE40.C448C36E--


Received: from tomcat.sac.verio.net ([e-mail] [209.162.64.15]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id WAA25218 for <[e-mail]>; Tue, 3 Aug 1999 22:20:51 -0700 (PDT)
Received: from nma.com (pm03-45.sac.verio.net [209.162.64.111]) by tomcat.sac.verio.net (8.9.1a/8.9.1) with ESMTP id WAA01795; Tue, 3 Aug 1999 22:20:24 -0700 (PDT)
Message-ID: <[e-mail]>
Date: Tue, 03 Aug 1999 22:20:15 -0700
From: Ed Gerck <[e-mail]>
X-Mailer: Mozilla 4.51 [en] (Win98; I)
X-Accept-Language: en
MIME-Version: 1.0
To: Stephen Kent <[e-mail]>
CC: "'[e-mail]'" <[e-mail]>
Subject: Re: Non-Repudiation, was Re: Common misconceptions, was Re: KISSfor  PKIX.   (Was: RE:ASN.1vs   XML   (used to be RE: I-D 	ACTION   :draft-ietf-pkix-scvp-00.txt))
References: <v04020a02b3b3e54bc992@[128.33.238.108]>	 <v04020a00b3b56b6383a7@[128.33.238.45]> <v04020a03b3be21dccc3c@[128.33.238.37]> <v04020a06b3ccc179271f@[128.33.238.37]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Stephen Kent wrote:

> Ed,
>
> Aside: Could you be related to Bob Jueneman?  In the anals of IETF WG
> mailing lists, only he has tended to send such long, detailed messages, as
> well as being so involved in the legal aspects of PKI :-}.

I have noticed another similarity between myself and Bob Jueneman. We both tend
to reply to all relevant items in an email, even if it tends to disprove a former msg or
shed a different light upon it.

> This is an IETF (technica)l WG, not the ABA Technical Committee on Digital
> Signatures. The technical definition of NR that we use comes from ISO
> 7498-2.  Paraphrasing (since I don't have the spec in front of me on this
> plane flight), NR is defined as a security service employed to prevent a
> party in a communication from later denying having participated in the
> communication.   Time is not mentioned explicitly, but because the
> communication took place at some time, it is an implied component of NR.

Steve, so many things are "implied" -- that one needs to be careful not to have
"implied security" as well.  What I mean is that we need clear and well-defined
concepts, if we want clear results. If NR is "to prevent a party in a communication
from later denying having participated in the communication" as you say above
then we must immediatley agree that NR does not exist and never will.

Further, if I also mention that NR depends on trust and all I hear from you is that
Tina Turner would have said it differently then I must assume that trust is also "implied"
in that definition you use.

Thus, all I am saying is that the definition of NR being used in this WG is wrong
and I don't care who defined it and where you based it -- while I also point out
that ISO is a private organization, which definitions can be used or not and that
none of them is some sort of "international treaty" or even "standard" or "fact".

> finally, I appreciate the pointer to you web site, but I have way too much
> material to read already.  When it's refereed and published, then I'll look
> at your theory of certification.

I did not point to any web site.  Regarding being "refereed and published"
I guess that is for you to verify.

Cheers,

Ed Gerck



Received: from tomcat.sac.verio.net ([e-mail] [209.162.64.15]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id VAA23147 for <[e-mail]>; Tue, 3 Aug 1999 21:47:56 -0700 (PDT)
Received: from nma.com (pm03-45.sac.verio.net [209.162.64.111]) by tomcat.sac.verio.net (8.9.1a/8.9.1) with ESMTP id VAA26989; Tue, 3 Aug 1999 21:50:52 -0700 (PDT)
Message-ID: <[e-mail]>
Date: Tue, 03 Aug 1999 21:50:27 -0700
From: Ed Gerck <[e-mail]>
X-Mailer: Mozilla 4.51 [en] (Win98; I)
X-Accept-Language: en
MIME-Version: 1.0
To: Bob Blakley <[e-mail]>
CC: [e-mail]
Subject: Re: Common misconceptions
References: <012801beddba$018065c0$[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Bob Blakley wrote:

> A sample of DNA evidence has nothing whatsoever to do with non-repudiation.
> Non-repudiation evidence is evidence of intent; DNA evidence is emphatically
> **NOT** evidence of intent.  Both of Ed's examples get this wrong.

Yes, certainly, because this is not what I wrote or implied.  Moreover, I disagree
that "non-repudiation is evidence of intent".   For example, if a person is caught on
video footage and his fingerprints are found on a crime scene, his presence there
cannot be repudiated -- independently of his intent to allow such proof.

My point, however, was that non-repudiation could be illustrated by DNA evidence
in a subtle aspect -- that one DNA sample (blood) could more easily be repudiated
as involuntary than the other (sperm), because the suspect would have less power to
prevent the first sample to be obtained. Likewise, DNS sample from a strand of hair
could be more easily repudiated than from a blood sample, by the same principle --
that liability flows from power.

Now, what is non-repudiation of an authentication act? I have already provided
a model to answer this not-so-simple question, which deals not only with legally-based
non-repudiation but also with other forms of non-repudiation.  But, none of them
deals with "evidence of intent" -- because the intent of an authentication act can
always be legally or otherwise repudiated.  Here, we must deal with materially
defined variables, things which can be physically defined and measured -- the
rest is to be argued in court.

However, if you want to define that "non-repudiation is evidence of intent" in regard
to this WG's charter -- then I believe this is a notch better (if only a notch, however)
than the present usage which relies upon a bit being 0 or 1 in a certificate ;-)

Cheers,

Ed Gerck



Received: from tomcat.sac.verio.net ([e-mail] [209.162.64.15]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id VAA21936 for <[e-mail]>; Tue, 3 Aug 1999 21:04:17 -0700 (PDT)
Received: from nma.com (pm04-34.sac.verio.net [209.162.64.147]) by tomcat.sac.verio.net (8.9.1a/8.9.1) with ESMTP id VAA19493; Tue, 3 Aug 1999 21:07:04 -0700 (PDT)
Message-ID: <[e-mail]>
Date: Tue, 03 Aug 1999 21:06:56 -0700
From: Ed Gerck <[e-mail]>
X-Mailer: Mozilla 4.51 [en] (Win98; I)
X-Accept-Language: en
MIME-Version: 1.0
To: Graham Klyne <[e-mail]>
CC: [e-mail]
Subject: Re: Common misconceptions
References: <[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Graham Klyne wrote:

> To test my understanding, I would like to offer a hypothetical scenario
> that allows "verifier centric" reliance without a challenge-response in the
> struct sense that you seem to describe.
>
> Suppose a CA is broadcasting CRLs at regular intervals.  The receiver of a
> certificate will rely upon that certificate only if they are also in
> posession of a fresh CRL that does not revoke it.
>
> I think this satisfies reasonable requirements for verifier-centric
> reliance, without a struct challenge/response.  (But I suppose one might
> argue that the "challenge" in this scenario is implicit.)

Yes, in the sense that a fresh broadcast is expected at certain intervals. But, the
basic tenet of "verifier-centric" reliance must be that the verifier is able to verify
*at will* -- which would be negated by a CRL that is broadcast in the CA's
terms, not the verifier's terms.

So, your example is valid insofar as the broadcast frequency is adequate to
the verifier. Which may be hard to accomplish, since the verifier would need a
CRL more frequently for transactions with higher risk (ie, value at stake) and
less frequently otherwise -- but the broadcast rate would be constant.

> So what you are describing here is the principle that liability can arise
> only as the result of a *willing* action (e.g. _intent_ to commit a crime;
> _wilful_ neglect of safety procedures;  _willing_ and _informed_ execution
> of a contract; etc.)?

No, what I am describing is that liability is the counterpart of power. I did
not mention intent.

There are two basic symmetry axis in law theory, valid in general:

1. liability versus power
2. duty versus right

and these two axis are mostly orthogonal, so that it is possible to have
duties without liability and vice versa.  Here, non-repudiation implies a
liability, not a duty.  So, non-repudiation of an authentication act must be
derived from the subject's power to avoid that authentication act -- but,
if the act is automatic or automatically accepted even if the subject did
revoke the cert in a CRL, such power does not exist in regard to that act.

> Clearly, any purely technical system can only be _part_ of the evidence
> that may be used to establish liability in the affairs of men (as opposed
> to machines).

Yes, but when that technical system denies the basic requirements of providing
such evidence (for example, by denying power to the subject) then that technical
system denies evidence in regard to non-repudiation.

Cheers,

Ed Gerck



Received: from mail01-ewr.pilot.net (mail-ewr-1.pilot.net [206.98.230.18]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id RAA01951 for <[e-mail]>; Tue, 3 Aug 1999 17:07:23 -0700 (PDT)
From: [e-mail]
Received: from mailgw.firstdata.com ([204.48.27.166]) by mail01-ewr.pilot.net with ESMTP id UAA19255 for <[e-mail]>; Tue, 3 Aug 1999 20:10:20 -0400 (EDT)
Received: from lncora06.fl.fdms.firstdata.com (lnsunr02.firstdata.com [192.168.247.16]) by mailgw.firstdata.com with SMTP id UAA19348 for <[e-mail]>; Tue, 3 Aug 1999 20:10:19 -0400 (EDT)
Received: from 10.2.52.30 by lncora06.fl.fdms.firstdata.com with SMTP ( WorldSecure Server SMTP Relay(WSS) v3.6); Tue, 03 Aug 99 20:07:45 -0400
X-Server-Uuid: aadd1a76-264d-11d1-91c7-080009d97107
Received: by lnsunr02.firstdata.com(Lotus SMTP MTA v4.6.4 (830.2 3-23-1999)) id 852567C3.000095CF ; Tue, 3 Aug 1999 20:06:23 -0400
X-Lotus-FromDomain: FDC
To: [e-mail]
cc: "Russ Housley" <[e-mail]>, "Ed Gerck" <[e-mail]>, "'[e-mail]'" <[e-mail]>
Message-ID: <[e-mail]>
Date: Tue, 3 Aug 1999 16:54:47 -0700
Subject: Re: Common misconceptions, was Re: KISS for PKIX. (Was: RE: ASN .1vs XML (used to be RE: I-D ACTION
MIME-Version: 1.0
X-WSS-ID: 1BB95BC485813-05-01
Content-Type: text/plain;  charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: 7bit

basically what AADS has been looking at is an EC/DSS hardware token at the
highest currently available hardware assurance level ... as close in cost to
current magstripe debit cards as possible ... with the public key registered
associated with the account/userid in place of password ... and digital
signature authentication of messages ... in lieu of password compare.

we believe that we can deploy a common digital signature authentication
technology for all transactions (including login transactions) that supports
software public key as well as various hardware token public key ... where the
choice becomes one of the parameterized risk management issues.





Received: from mail01-ewr.pilot.net (mail-ewr-1.pilot.net [206.98.230.18]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id QAA01242 for <[e-mail]>; Tue, 3 Aug 1999 16:43:05 -0700 (PDT)
From: [e-mail]
Received: from mailgw.firstdata.com ([204.48.27.166]) by mail01-ewr.pilot.net with ESMTP id TAA16995 for <[e-mail]>; Tue, 3 Aug 1999 19:46:02 -0400 (EDT)
Received: from lncora06.fl.fdms.firstdata.com (lnsunr02.firstdata.com [192.168.247.16]) by mailgw.firstdata.com with SMTP id TAA18876 for <[e-mail]>; Tue, 3 Aug 1999 19:46:00 -0400 (EDT)
Received: from 10.2.52.30 by lncora06.fl.fdms.firstdata.com with SMTP ( WorldSecure Server SMTP Relay(WSS) v3.6); Tue, 03 Aug 99 19:43:37 -0400
X-Server-Uuid: aadd1a76-264d-11d1-91c7-080009d97107
Received: by lnsunr02.firstdata.com(Lotus SMTP MTA v4.6.4 (830.2 3-23-1999)) id 852567C2.00823A49 ; Tue, 3 Aug 1999 19:42:26 -0400
X-Lotus-FromDomain: FDC
To: [e-mail]
cc: "Russ Housley" <[e-mail]>, "Ed Gerck" <[e-mail]>, "'[e-mail]'" <[e-mail]>
Message-ID: <[e-mail]>
Date: Tue, 3 Aug 1999 16:44:44 -0700
Subject: Re: Common misconceptions, was Re: KISS for PKIX. (Was: RE: ASN .1vs XML (used to be RE: I-D ACTION
MIME-Version: 1.0
X-WSS-ID: 1BB9A12385332-01-01
Content-Type: text/plain;  charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: 7bit

basically what AADS has been looking at is an EC/DSS hardware token at the
highest currently available hardware assurance level ... as close in cost to
current magstripe debit cards as possible ... with the public key registered
associated with the account/userid in place of password ... and digital
signature authentication of messages ... in lieu of password compare.





Received: from po1.bbn.com (PO1.BBN.COM [192.1.50.38]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id QAA00410 for <[e-mail]>; Tue, 3 Aug 1999 16:15:16 -0700 (PDT)
Received: from [128.33.238.29] (TC029.BBN.COM [128.33.238.29]) by po1.bbn.com (8.9.1/8.9.1) with ESMTP id TAA04651; Tue, 3 Aug 1999 19:18:00 -0400 (EDT)
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
X-Sender: [e-mail] (Unverified)
Message-Id: <v04020a10b3ccedbf3afa@[128.33.238.37]>
In-Reply-To: <[e-mail]>
References: <v04020a02b3b3e54bc992@[128.33.238.108]>		 <v04020a00b3b56b6383a7@[128.33.238.45]>		 <[e-mail]>		 <[e-mail]>		 <[e-mail]>		 <[e-mail]> <[e-mail]> <[e-mail]>
Date: Tue, 3 Aug 1999 15:06:38 -0400
To: Ed Gerck <[e-mail]>
From: Stephen Kent <[e-mail]>
Subject: Re: Common misconceptions, was Re: KISS for PKIX. (Was: RE:ASN.1vs  XML   (used to be RE: I-D ACTION :draft-ietf-pkix-scvp- 00.txt))
Cc: "'[e-mail]'" <[e-mail]>

Ed,
	<snip>

>Yes, and following such notion that challenge-response protocols are not
>needed for
>"non-repudiation" in secure protocols/transmissions  in general you will
>arrive at the
>concusion that one would not need to do even a challenge-response query on
>the CRL
>before you rely on the authentication --  though such is demanded by S/MIME.

Wrong, to use a technical term.

	<snip>

Steve


Received: from po1.bbn.com (PO1.BBN.COM [192.1.50.38]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id QAA00372 for <[e-mail]>; Tue, 3 Aug 1999 16:14:57 -0700 (PDT)
Received: from [128.33.238.29] (TC029.BBN.COM [128.33.238.29]) by po1.bbn.com (8.9.1/8.9.1) with ESMTP id TAA04642; Tue, 3 Aug 1999 19:17:47 -0400 (EDT)
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
X-Sender: [e-mail] (Unverified)
Message-Id: <v04020a0db3cce5f566b5@[128.33.238.37]>
In-Reply-To: <852567BE.004E1239.00@LNOTES5>
Date: Tue, 3 Aug 1999 14:34:34 -0400
To: [e-mail]
From: Stephen Kent <[e-mail]>
Subject: Re: Common misconceptions, 	 was Re: KISS for PKIX. (Was: RE: ASN .1vs XML (used to be RE: 	 I-D ACTION :draft-ietf-pkix-scvp- 00.txt ))
Cc: "'[e-mail]'" <[e-mail]>

Eric,

>I believe a prompt (challenge) for a password to enable use of the private
>key for signing purposes is necessary in some instances. Automatic signing
>of a message by software always creates the potential for a repudiation
>claim by the sender, either because the software was accessed by an
>unauthorized party to effect an unauthorized transaction or because the
>authorized party is attempting to defraud by claiming the transaction was
>not authorized. In either case, the burden is on the recipient to prove
>otherwise.

A user has no direct evidence of what is being signed on his behalf,
because a lot of software and hardware is between the user and the
signature mechanism.  One may argue that some form of user prompt is
useful, but that is not a solution to the underlying problem.  Also, a user
prompt is not what we mean when we talk about "challenge-response" in this
technical environment.

Steve


Received: from po1.bbn.com (PO1.BBN.COM [192.1.50.38]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id QAA00349 for <[e-mail]>; Tue, 3 Aug 1999 16:14:19 -0700 (PDT)
Received: from [128.33.238.29] (TC029.BBN.COM [128.33.238.29]) by po1.bbn.com (8.9.1/8.9.1) with ESMTP id TAA04595; Tue, 3 Aug 1999 19:17:07 -0400 (EDT)
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
X-Sender: [e-mail] (Unverified)
Message-Id: <v04020a06b3ccc179271f@[128.33.238.37]>
In-Reply-To: <[e-mail]>
References: <v04020a02b3b3e54bc992@[128.33.238.108]>	 <v04020a00b3b56b6383a7@[128.33.238.45]> <v04020a03b3be21dccc3c@[128.33.238.37]>
Date: Tue, 3 Aug 1999 17:01:27 -0400
To: Ed Gerck <[e-mail]>
From: Stephen Kent <[e-mail]>
Subject: Re: Non-Repudiation, was Re: Common misconceptions, was Re: KISS for PKIX.   (Was: RE:ASN.1vs   XML   (used to be RE: I-D 	ACTION   :draft-ietf-pkix-scvp-00.txt))
Cc: "'[e-mail]'" <[e-mail]>

Ed,

Sorry to be so late in responding, but I've been on vacation for a week.

Aside: Could you be related to Bob Jueneman?  In the anals of IETF WG
mailing lists, only he has tended to send such long, detailed messages, as
well as being so involved in the legal aspects of PKI :-}.

This is an IETF (technica)l WG, not the ABA Technical Committee on Digital
Signatures. The technical definition of NR that we use comes from ISO
7498-2.  Paraphrasing (since I don't have the spec in front of me on this
plane flight), NR is defined as a security service employed to prevent a
party in a communication from later denying having participated in the
communication.   Time is not mentioned explicitly, but because the
communication took place at some time, it is an implied component of NR.
Semantic context also is not mentioned explicitly, but because NR is of
concern only when people interact, these issues arise as well.  However,
these latter issues are generally outside the scope of (technical) NR
security services, and thus outside the scope of this WG.  in contrast,
time is amenable to technical NR enforcement measures and is the subject of
this WG, e.g., the TSA document. Note that there is not mention of
liability in this service spec, and it is not a technical NR issue either.

Consider the case in which I receive a signed message, and I want to
prevent the sender of the e-mail fro later claiming that he did not send
the message. I validate the signature, collect the originator's
certificate, his CA's cert, etc. and the relevant CRLs, and go to a time
stamp authority to create a record that all of this data (message, certs,
and CRLs) existed at the time in question.  This NR evidence, in a
technical sense, enables me to prevent the originator from later
repudiating his communication.  There is no reqirement here for any form of
challange-response interaction with the message originator, and in fact a
requirement for such interaction would be antithetical to the way e-mail is
designed to work.

I agree that when push comes to shove, a court will have to decide whether
there is sufficient evidence that a user did, in fact, participate in a
specific communication, or whether there is reasonable doubt that the
communication took place unbeknownst to the user.  While the various state
laws regarding digital signatures will play a role here, they are not the
last word, and not all of them are well written.  (That's a technical
observation of mine, shared by a number of attorneys with whom I have
spoken.)

finally, I appreciate the pointer to you web site, but I have way too much
material to read already.  When it's refereed and published, then I'll look
at your theory of certification.

Steve


Received: from mail-out2.apple.com (mail-out2.apple.com [17.254.0.51]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id MAA13951 for <[e-mail]>; Tue, 3 Aug 1999 12:22:46 -0700 (PDT)
Received: from mailgate1.apple.com (A17-128-100-225.apple.com [17.128.100.225]) by mail-out2.apple.com (8.8.5/8.8.5) with ESMTP id MAA45204 for <[e-mail]>; Tue, 3 Aug 1999 12:25:41 -0700
Received: from scv1.apple.com (scv1.apple.com) by mailgate1.apple.com (mailgate1.apple.com- SMTPRS 2.0.15) with ESMTP id <[e-mail]> for <[e-mail]>; Tue, 03 Aug 1999 12:25:28 -0700
Received: from [17.205.41.166] (aram1.apple.com [17.205.41.166]) by scv1.apple.com (8.9.3/8.9.3) with ESMTP id MAA29226 for <[e-mail]>; Tue, 3 Aug 1999 12:25:26 -0700
Message-Id: <[e-mail]>
X-Mailer: Microsoft Outlook Express Macintosh Edition - 4.5 (0410)
Date: Tue, 03 Aug 1999 12:25:26 -0700
Subject: Re: Lets Standardize Time Representation Formats!!!: WAS Re: New TSTTime definition
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

Tony Bartoletti wrote:

> At 11:20 AM 8/3/99 -0700, Aram Perez wrote:
> 
>>I personally prefer a
>>numerator/denominator approach such as (please excuse my ASN.1):
>>
>>    Seconds ::= SEQUENCE {
>>        numerator INTEGER,
>>        denominator INTEGER OPTIONAL DEFAULT 100
>>    }
>>
>
> For compactness, (idea courtesy of Denis Pinkas earlier post) why not
> specify the denominator as a power of 2? (bit-shifts are fast.)

Sure, just make the default 2.

>
> I can believe Todd's argument that high precisions/resolutions may
> be/become important, but I wonder the utility of, say, denom = 119.

I would wonder also if someone used a denominator of 119. What I see is a
trade-off between compactness and arbitrary precision. I'm just proposing a
scheme where you can be as precise (or unprecise) as you want to be. In the
long run, I think different "industries" would adopt different "standard"
denominators.

>
> But I am a bit confused by the "numerator/denominator" notation.
>
> E.g.:  If the denominator were 1000 (I like milliseconds;) then
> would I need to represent 57.000 seconds as 57000/1000 ?

That is correct. Actually, a better representation would be:

    Seconds ::= SEQUENCE {
        whole-secs INTEGER,
        fraction-numerator INTEGER,
        fraction-denominator INTEGER DEFAULT 100 -- Correct ASN.1
                                        -- Thanks to Tom Gindin
    }

Still having fun,
Aram Perez


Received: from poptop.llnl.gov (poptop.llnl.gov [128.115.18.65]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id LAA13200 for <[e-mail]>; Tue, 3 Aug 1999 11:55:15 -0700 (PDT)
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 LAA08958; Tue, 3 Aug 1999 11:58:08 -0700 (PDT)
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.3 (32)
Date: Tue, 03 Aug 1999 11:57:15 -0700
To: "Aram Perez" <[e-mail]>, [e-mail]
From: Tony Bartoletti <[e-mail]>
Subject: Re: Lets Standardize Time Representation Formats!!!: WAS Re: New TSTTime definition
In-Reply-To: <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"

At 11:20 AM 8/3/99 -0700, Aram Perez wrote:

>I personally prefer a
>numerator/denominator approach such as (please excuse my ASN.1):
>
>    Seconds ::= SEQUENCE {
>        numerator INTEGER,
>        denominator INTEGER OPTIONAL DEFAULT 100
>    }
>

For compactness, (idea courtesy of Denis Pinkas earlier post) why not
specify the denominator as a power of 2? (bit-shifts are fast.)

I can believe Todd's argument that high precisions/resolutions may
be/become important, but I wonder the utility of, say, denom = 119.

But I am a bit confused by the "numerator/denominator" notation.

E.g.:  If the denominator were 1000 (I like milliseconds;) then
would I need to represent 57.000 seconds as 57000/1000 ?

Just curious.

___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 mailbox1.appliedtheory.com (mailbox1.appliedtheory.com [204.168.16.14]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id LAA12944 for <[e-mail]>; Tue, 3 Aug 1999 11:48:05 -0700 (PDT)
From: [e-mail]
Received: from eaglei-internet.ssg.bny.com (bk01.bankofny.com [160.254.115.80]) by mailbox1.appliedtheory.com (8.8.8/8.8.8) with SMTP id OAA00458; Tue, 3 Aug 1999 14:50:50 -0400 (EDT)
Received: from Hermes.bankofny.com by eaglei-internet.ssg.bny.com via smtpd (for mailbox1.appliedtheory.com [204.168.16.14]) with SMTP; 3 Aug 1999 18:50:50 UT
Received: from LNOTES5 by HERMES via SMTP with TCP; Tue, 3 Aug 99 11:17:44-EDT
Received: by LNOTES5(Lotus SMTP MTA v1.2  (600.1 3-26-1998))  id 852567C2.00540CD3 ; Tue, 3 Aug 1999 11:18:03 -0400
X-Lotus-FromDomain: BNY
To: [e-mail]
cc: "Russ Housley" <[e-mail]>, "Ed Gerck" <[e-mail]>, "'[e-mail]'" <[e-mail]>
Message-ID: <852567C2.0050E643.00@LNOTES5>
Date: Tue, 3 Aug 1999 11:17:37 -0400
Subject: Re: Common misconceptions, was Re: KISS for PKIX. (Was: RE: ASN .1vs XML (used to be RE: I-D ACTION
Mime-Version: 1.0
Content-type: text/plain; charset=us-ascii
Content-Disposition: inline

I was not implying that existing banking software provides for
non-repudiation. On the contrary, the fact that banks are using secret keys
for message authentication precludes this. And, as you noted, many banks
provide only one authentication key to be shared by all users at a customer
site. I created a PC-based cash management system in the early 80's, which
is still in use today but will soon be replaced by an internet-based
offering. The PC software requires one userid/password to authenticate to
the PC and a separate ID/password to authenticate a transmission session. A
DES-like algorithm is used to authenticate the messages utilizing a 56-bit
key that can not be scripted by the user (clipboard operations are not
supported for the field).

In moving the product to an internet-based client, one consideration was
use of client certificates versus user ID and dynamic passwords (hardware
tokens) for authentication. Our conclusion was client certificates required
too much administration and maintenance overhead, in the long-term, while
providing few incremental benefits The ability for certificates to support
nonrepudiation was examined in detail because it was the one major
potential benefit we could not support with alternatives, which are all
based on the secret key concept. Unfortunately, we concluded that current
software implementations of certificate technology did not provide a level
of security adequate to support nonrepudiation claims.

I agree password systems are inherently weak. In moving to an internet
client, the known weaknesses of password systems led us to the hardware
token decision. Each user is issued a separate token and the customer is
cautioned to discourage sharing (which would imply a sharing or IDs and
passwords as well which is a violation of our security policy).
Unfortunately, we admit even this does not provide assurance that is strong
enough to serve as a foundation for nonrepudiation, but it is significantly
easier to manage.

regards,
eric




Received: from mail-out1.apple.com (mail-out1.apple.com [17.254.0.52]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id LAA12391 for <[e-mail]>; Tue, 3 Aug 1999 11:20:09 -0700 (PDT)
Received: from mailgate1.apple.com (A17-128-100-225.apple.com [17.128.100.225]) by mail-out1.apple.com (8.8.5/8.8.5) with ESMTP id LAA09604 for <[e-mail]>; Tue, 3 Aug 1999 11:23:07 -0700
Received: from scv1.apple.com (scv1.apple.com) by mailgate1.apple.com (mailgate1.apple.com- SMTPRS 2.0.15) with ESMTP id <[e-mail]> for <[e-mail]>; Tue, 03 Aug 1999 11:20:58 -0700
Received: from [17.205.41.166] (aram1.apple.com [17.205.41.166]) by scv1.apple.com (8.9.3/8.9.3) with ESMTP id LAA47400 for <[e-mail]>; Tue, 3 Aug 1999 11:20:58 -0700
Message-Id: <[e-mail]>
X-Mailer: Microsoft Outlook Express Macintosh Edition - 4.5 (0410)
Date: Tue, 03 Aug 1999 11:20:57 -0700
Subject: Re: Lets Standardize Time Representation Formats!!!: WAS Re: New TSTTime definition
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

Peter Sylvester wrote:

[snip]
> I am the authority that defines the order, and not something else.
> I do NOT mean with respect to time. If at all it is MY time, my counter
> is my time, it is just a matter of convenience to use something
> that most people will understand. (I have not said that
> I don't need an indication of time in a time stamp, I was just taking
> about order).

In your own environment, you are correct. The problem arises when the order
has to be agreed upon by more than just one party.

[snip]
>
> I agree with you that a time structure that will not expire in the near
> future is important, what's wrong with an arbitrary long decimal
> subdivision of a second?

Good, then we're in violent agreement ;-). I personally prefer a
numerator/denominator approach such as (please excuse my ASN.1):

    Seconds ::= SEQUENCE {
        numerator INTEGER,
        denominator INTEGER OPTIONAL DEFAULT 100
    }

Having lots of fun,
Aram Perez


Received: from edelweb.fr (edelweb.fr [193.51.12.16]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id KAA11867 for <[e-mail]>; Tue, 3 Aug 1999 10:58:29 -0700 (PDT)
Received: from champagne.edelweb.fr (localhost.edelweb.fr [127.0.0.1]) by edelweb.fr with ESMTP id UAA15186 for <[e-mail]>; Tue, 3 Aug 1999 20:01:25 +0200 (MET DST)
Received: from champagne.edelweb.fr (champagne.edelweb.fr [193.51.14.161]) by edelweb.fr (nospam/1.1); Tue, 3 Aug 1999 20:01:25 +0200 (MET DST)
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 UAA04228 for <[e-mail]>; Tue, 3 Aug 1999 20:01:24 +0200 (MET DST)
From: Peter Sylvester <[e-mail]>
Received: (sylvest@localhost) by emeriau.edelweb.fr (8.7.6/8.6.6) id UAA25705 for [e-mail]; Tue, 3 Aug 1999 20:01:24 +0200 (MET DST)
Date: Tue, 3 Aug 1999 20:01:24 +0200 (MET DST)
Message-Id: <[e-mail]>
To: [e-mail]
Subject: Re: Lets Standardize Time Representation Formats!!!: WAS Re: New TSTTime definition

> 
> But how to you measure ORDER. You can have different types of order, e.g.
> alphabetical, numerical and yes even time. So when you state "Event arrive
> in ORDER", I'm assuming you mean with respect to time. So I agree with Todd
> that having a time structure that will not expire in the near future is
> important.

Events arrives in some order, this means that I observe them to arrive
one after another, or I voluntarily decide in what order I place them
which is in fact the real behaviour. 
 
I am the authority that defines the order, and not something else. 
I do NOT mean with respect to time. If at all it is MY time, my counter
is my time, it is just a matter of convenience to use something
that most people will understand. (I have not said that
I don't need an indication of time in a time stamp, I was just taking
about order).

If a CLOCK counts faster than I can count in another way, it is a
sufficient device to create unique stamps in some order.

I agree with you that a time structure that will not expire in the near
future is important, what's wrong with an arbitrary long decimal 
subdivision of a second?

Regards (ooups I forgot to say 'have fun' in my previous message)
Peter



Received: from mail-out2.apple.com (mail-out2.apple.com [17.254.0.51]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id KAA11478 for <[e-mail]>; Tue, 3 Aug 1999 10:42:41 -0700 (PDT)
Received: from mailgate1.apple.com (A17-128-100-225.apple.com [17.128.100.225]) by mail-out2.apple.com (8.8.5/8.8.5) with ESMTP id KAA35346 for <[e-mail]>; Tue, 3 Aug 1999 10:45:39 -0700
Received: from scv1.apple.com (scv1.apple.com) by mailgate1.apple.com (mailgate1.apple.com- SMTPRS 2.0.15) with ESMTP id <[e-mail]> for <[e-mail]>; Tue, 03 Aug 1999 10:45:30 -0700
Received: from [17.205.41.166] (aram1.apple.com [17.205.41.166]) by scv1.apple.com (8.9.3/8.9.3) with ESMTP id KAA48456 for <[e-mail]>; Tue, 3 Aug 1999 10:45:29 -0700
Message-Id: <[e-mail]>
X-Mailer: Microsoft Outlook Express Macintosh Edition - 4.5 (0410)
Date: Tue, 03 Aug 1999 10:45:29 -0700
Subject: Re: Lets Standardize Time Representation Formats!!!: WAS Re: New TSTTime definition
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

Peter Sylvester wrote:
[snip]
> 
>> My point is that we don't know all the uses yet - and if we limit ourselves
>> to representing time at the same level of granularity that the OS designers
>> thought was relevant - Ahahahahahahah - Well it just seemed a bit funny
>> since we already know that it is not clean enough. If you don't believe me
>> call the stock exchanges and find out what and how they use
>> timedata/timesources for.
> Event arrive in ORDER, and the only relevant thing is the order, and not the
> absolute time value.

But how to you measure ORDER. You can have different types of order, e.g.
alphabetical, numerical and yes even time. So when you state "Event arrive
in ORDER", I'm assuming you mean with respect to time. So I agree with Todd
that having a time structure that will not expire in the near future is
important.

[snip]

Regards,
Aram Perez


Received: from edelweb.fr (edelweb.fr [193.51.12.16]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id KAA10851 for <[e-mail]>; Tue, 3 Aug 1999 10:11:21 -0700 (PDT)
Received: from champagne.edelweb.fr (localhost.edelweb.fr [127.0.0.1]) by edelweb.fr with ESMTP id TAA14651 for <[e-mail]>; Tue, 3 Aug 1999 19:14:17 +0200 (MET DST)
Received: from champagne.edelweb.fr (champagne.edelweb.fr [193.51.14.161]) by edelweb.fr (nospam/1.1); Tue, 3 Aug 1999 19:14:17 +0200 (MET DST)
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 TAA03913 for <[e-mail]>; Tue, 3 Aug 1999 19:14:16 +0200 (MET DST)
From: Peter Sylvester <[e-mail]>
Received: (sylvest@localhost) by emeriau.edelweb.fr (8.7.6/8.6.6) id TAA25682 for [e-mail]; Tue, 3 Aug 1999 19:14:15 +0200 (MET DST)
Date: Tue, 3 Aug 1999 19:14:15 +0200 (MET DST)
Message-Id: <[e-mail]>
To: [e-mail]
Subject: Re: Lets Standardize Time Representation Formats!!!: WAS Re: New TSTTime definition

This message is not a flame, there is no intention for any personal
attack, although it might sound like so in some comments, 

> Denis to using your words - Creating yet another representation of time in a
> PKIX tool also 'seems pointless'.

BERT provides yet another representation of 
'time' <--> GeneralizedTime in PKI, or date in rfc822
'identifiers' <--> generalname in pki
'policyidentifier' <--> object id 
'signature'     <--> existing structures in pki+object ids for algorithms


> 
> Lets think of standardizing the representation of time to a format that will
> interoperate across the greatest number of PKIX applications. I suggest that
> the UTC 96 representation format from the BERT draft be adopted as the use
> standard. (McNeil - You want to jump in here?)
it seems that some people have forgotten why we have leap seconds inserted
sometimes (and not additional leap minutes). The intension is to make
them invisible in real life applications. Or better, don't fix all
real life applications by adding code to support leap seconds because 
you just need them once per 5 years. 

> 
> And Denis -  partner - as to what "you" personally think is the greatest
> resolution of time necessary, I look to that great Tommy Lee Jones line from
> MiB (Men In Black)  that went something like: "1500 years ago mankind
> thought that the Earth was the center of the Universe. 500 years ago mankind
> new the earth was flat. 15 minutes you knew you man was alone here on
> earth....think what you'll know tomorrow".
The earth is the center of the universe (as Bert seems to tell us.)
> 

> My point is that we don't know all the uses yet - and if we limit ourselves
> to representing time at the same level of granularity that the OS designers
> thought was relevant - Ahahahahahahah - Well it just seemed a bit funny
> since we already know that it is not clean enough. If you don't believe me
> call the stock exchanges and find out what and how they use
> timedata/timesources for.
Event arrive in ORDER, and the only relevant thing is the order, and not the
absolute time value. 

> 
> I have, and was surprised to find out that most of them have local Atomic
> Clocks that they reset daily or more often to NIST prime. These systems are
> good to 1*10e-12 Sec/Year which is clearly cleaner and finer that what we
> are proposing.  They have the most furious use of timestamping yet today and
> to them milliseconds are critically important. Especially in Digital Agent
> Models, where a number of agents are competing for common services in a
> control or market pool. The bottom line is that very fine granularity is
> absolutely necessary, if for no other reason than that the OS vendors
> choked.
Put a broker into a shuttle and look at the consequences. The only requirement
is the order of two events, and sorry, you can give any resolution you want,
something can arrive at 'the same moment' using whatever clock you use as
external source, and you just decide who came first. A high resolution 
real time counter counts faster that you an make personal decisions, thus
it is usable as a pure counter (and just gives an addtional convenient 
information). 


> 
> So what are the real issues here ? - It seems that we are going to choose a
> limiting criteria based on the fact that there is
>     o-    currently substantial propagation delay in a Open Networking
> Models (dependant on the topology of course) and this sets the baseline for
> the precision in remote-timestamping model's "credibility envelope".
>     o-    and that the OS is only capable of 1 Sec resolution in most cases
>     o-    and in almost all cases, the TOD services that create this
> granularity are based in some cheap Clock Chip that the BIOS or otherwise
> sub-OS services provide
>     o-    and most importantly, that there is really no real way to resynch
> the clocks properly in the field. [which simply isn't true BTW]
None of these 'facts' should be used. They are not necessary: 

- one second resultion is proposed only because 
  - we first overlooked that there was a subdivision (remember that the
    initial draft just had an integer indicating milliseconds.
  - existing certificats use seconds. I don't see a problem, a CORRECT
    comparison of GeneralizedTime isn't rocket science (leaving apart
    Challenger and Ariane 5).
   
> 
> What this entire thread seems to overlook or negate is that:
>     o-    even in SW only systems,  that sub-millisecond precision time is
> easily distributed in networking models. IRIG-B timecode and NTP have been
> doing this *for decades* already.
No it doesn't in principle. waht it negates is that real applications and 
HUMAN decisions need a higher precision. Tell me a real application with
non-repudiation where you really need more than counting within the smallest
observable time period for a human being (a second, or may be a little bit less
than that). (if not, see my last comment).

>     o-    Also that timestamping is often going to be done differently that
> the TS draft suggests, that is to say commercially I believe that the TS
> services will commercially live on the same platform that uses them, per
> say, rather than some Trusted-Third Party external third system. They may
> have a secondary proofing-stamp process happen at the "Archive Server" for
> the TST's, but that in reality that the system has to work not only embedded
> as we have proposed, but externally as you have proposed as well.
The scenarios is a little bit more complex. A time stamp service and any
form of notarisation service can be operated in a chain. Somewhere a clients
asks some local service, the local service either provides it directly, or
has to be backed up by another external service or more of them. 
BTW: Where is the external reference for spatial coordinates? I am here,
and I can see the top of the Eiffel tower, do you trust me?

> 
> To my mind, what this means is that the issue of network delay is not always
> applicable in the timestamping models, and this should be addressed by a
> uniform model that supports *all* use cases. Also that anyone can add a Time
> Board to a system if they need better grades of local time that can survive
> a reboot. Even the people that commercially depend on GPS for time (poor
> fools), get better time than the OS's can track in most all instances.

It seems that you misunderstood time and time stamp. I can make a time stamp
'number 9986557555787687', it comes before  'number 9986557556787686', I
record somewhere that I have issued time stamp X just at some time, in
order to establish a convenient way of using it. The time stamp is the stamp
of MY TIME, and nothing more.
 
> 
> My point is that there needs to both be interoperability in timestamping, as
> in all PKI, and in particular in the representation of the other cornerstone
> trust element, like the "Time" that an event is supposed to happened...and
> that the granularity is really needed in the submillisecond range.
No, a time stamp has nothing to do with when an event has happened, it is my
time that I tell after perception of the event. 

Why do you stop at a granularity of 32 bits? I want 20 decimal digit time stamps
in the next millenium. I want them human readable without a conversion of a 
binary digits.  

> 
> Also what is the real overhead for adding these features to the process?
> What is it really.?

Someone told me once: Whenever you can remove one additional parameter, you divide
you problems by 2 (I told that to myself BTW).

Peter Sylvester
Not signed but simply written at PARIS (5th floor Montparnasse tour if
you need more precision)

PS: let's avoid reinventing the wheel. take the single element which is
supposed to generalize a time event, if this is not sufficient, one
can always propose a correction, for example addition a precision in
readable form after the zone. 




Received: from mailbox1.appliedtheory.com (mailbox1.appliedtheory.com [204.168.16.14]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id IAA09082 for <[e-mail]>; Tue, 3 Aug 1999 08:35:40 -0700 (PDT)
From: [e-mail]
Received: from eaglei-internet.ssg.bny.com (bk01.bankofny.com [160.254.115.80]) by mailbox1.appliedtheory.com (8.8.8/8.8.8) with SMTP id LAA10474; Tue, 3 Aug 1999 11:38:15 -0400 (EDT)
Received: from Hermes.bankofny.com by eaglei-internet.ssg.bny.com via smtpd (for mailbox1.appliedtheory.com [204.168.16.14]) with SMTP; 3 Aug 1999 15:38:15 UT
Received: from LNOTES5 by HERMES via SMTP with TCP; Tue, 3 Aug 99 11:22:48-EDT
Received: from LNOTES5 by HERMES via SMTP with TCP; Tue, 3 Aug 99 11:22:52-EDT
Received: by LNOTES5(Lotus SMTP MTA v1.2  (600.1 3-26-1998))  id 852567C2.00547F93 ; Tue, 3 Aug 1999 11:22:56 -0400
X-Lotus-FromDomain: BNY
To: [e-mail]
cc: "Russ Housley" <[e-mail]>, "Ed Gerck" <[e-mail]>, "'[e-mail]'" <[e-mail]>
Message-ID: <852567C2.00541FAD.00@LNOTES5>
Date: Tue, 3 Aug 1999 11:22:28 -0400
Subject: Re: Common misconceptions, was Re: KISS for PKIX. (Was: RE: ASN .1vs XML (used to be RE: I-D ACTION
Mime-Version: 1.0
Content-type: text/plain; charset=us-ascii
Content-Disposition: inline

Yes. And banks face different liability requirements in different
jurisdictions and customer types (retail/consumer, wholesale/corporate0.
And, in most cases, banks can get the money back if they detect the fraud
quickly enough.
eric




[e-mail] on 08/03/99 10:43:27 AM

To:   Eric Guerrino
cc:   "Russ Housley" <[e-mail]>, "Ed Gerck" <[e-mail]>,
      "'[e-mail]'" <[e-mail]>
Subject:  Re: Common misconceptions,      was Re: KISS for PKIX. (Was: RE:
      ASN .1vs XML (used to be RE:  I-D ACTION





... oops and sorry for going on ... but question of whether bank is liable
tends
to be different than whether or not a specific person can be convicted in
case
of fraud. bank
can establish all the information assurance procedures that a corporation
has to
follow ...and try and get off the hook for liability in case of (online)
fraudalent transaction. that is somewhat seperate from whether a specific
(corporate insider or external) can be convicted of executing the
fraudulant
transaction.









Received: from www.meridianus.com (209.249.223.31.has.no.reverse [209.249.223.31] (may be forged)) by mail.proper.com (8.9.3/8.9.3) with ESMTP id IAA08665 for <[e-mail]>; Tue, 3 Aug 1999 08:23:56 -0700 (PDT)
Received: from PC1 by www.meridianus.com (8.8.8+Sun/SMI-SVR4) id JAA25336; Tue, 3 Aug 1999 09:20:35 -0700 (PDT)
Message-ID: <018f01beddc6$a00e56f0$[e-mail]>
From: "tog" <[e-mail]>
To: "Nick Pope" <[e-mail]>, "Denis Pinkas" <[e-mail]>, "IETF-PXIX" <[e-mail]>
References: <000401bedd95$280d52e0$0500000a@npwork2>
Subject: Lets Standardize Time Representation Formats!!!: WAS Re: New TSTTime definition 
Date: Tue, 3 Aug 1999 08:41:16 -0700
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.2918.2701
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2918.2701

Denis to using your words - Creating yet another representation of time in a
PKIX tool also 'seems pointless'.

Lets think of standardizing the representation of time to a format that will
interoperate across the greatest number of PKIX applications. I suggest that
the UTC 96 representation format from the BERT draft be adopted as the use
standard. (McNeil - You want to jump in here?)

And Denis -  partner - as to what "you" personally think is the greatest
resolution of time necessary, I look to that great Tommy Lee Jones line from
MiB (Men In Black)  that went something like: "1500 years ago mankind
thought that the Earth was the center of the Universe. 500 years ago mankind
new the earth was flat. 15 minutes you knew you man was alone here on
earth....think what you'll know tomorrow".

My point is that we don't know all the uses yet - and if we limit ourselves
to representing time at the same level of granularity that the OS designers
thought was relevant - Ahahahahahahah - Well it just seemed a bit funny
since we already know that it is not clean enough. If you don't believe me
call the stock exchanges and find out what and how they use
timedata/timesources for.

I have, and was surprised to find out that most of them have local Atomic
Clocks that they reset daily or more often to NIST prime. These systems are
good to 1*10e-12 Sec/Year which is clearly cleaner and finer that what we
are proposing.  They have the most furious use of timestamping yet today and
to them milliseconds are critically important. Especially in Digital Agent
Models, where a number of agents are competing for common services in a
control or market pool. The bottom line is that very fine granularity is
absolutely necessary, if for no other reason than that the OS vendors
choked.

So what are the real issues here ? - It seems that we are going to choose a
limiting criteria based on the fact that there is
    o-    currently substantial propagation delay in a Open Networking
Models (dependant on the topology of course) and this sets the baseline for
the precision in remote-timestamping model's "credibility envelope".
    o-    and that the OS is only capable of 1 Sec resolution in most cases
    o-    and in almost all cases, the TOD services that create this
granularity are based in some cheap Clock Chip that the BIOS or otherwise
sub-OS services provide
    o-    and most importantly, that there is really no real way to resynch
the clocks properly in the field. [which simply isn't true BTW]

What this entire thread seems to overlook or negate is that:
    o-    even in SW only systems,  that sub-millisecond precision time is
easily distributed in networking models. IRIG-B timecode and NTP have been
doing this *for decades* already.
    o-    Also that timestamping is often going to be done differently that
the TS draft suggests, that is to say commercially I believe that the TS
services will commercially live on the same platform that uses them, per
say, rather than some Trusted-Third Party external third system. They may
have a secondary proofing-stamp process happen at the "Archive Server" for
the TST's, but that in reality that the system has to work not only embedded
as we have proposed, but externally as you have proposed as well.

To my mind, what this means is that the issue of network delay is not always
applicable in the timestamping models, and this should be addressed by a
uniform model that supports *all* use cases. Also that anyone can add a Time
Board to a system if they need better grades of local time that can survive
a reboot. Even the people that commercially depend on GPS for time (poor
fools), get better time than the OS's can track in most all instances.

My point is that there needs to both be interoperability in timestamping, as
in all PKI, and in particular in the representation of the other cornerstone
trust element, like the "Time" that an event is supposed to happened...and
that the granularity is really needed in the submillisecond range.

Also what is the real overhead for adding these features to the process?
What is it really.?

Todd



Received: from mail01-ewr.pilot.net (mail-ewr-1.pilot.net [206.98.230.18]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id HAA07836 for <[e-mail]>; Tue, 3 Aug 1999 07:56:11 -0700 (PDT)
From: [e-mail]
Received: from mailgw.firstdata.com ([204.48.27.166]) by mail01-ewr.pilot.net with ESMTP id KAA17528 for <[e-mail]>; Tue, 3 Aug 1999 10:59:07 -0400 (EDT)
Received: from lncora06.fl.fdms.firstdata.com (lnsunr02.firstdata.com [192.168.247.16]) by mailgw.firstdata.com with SMTP id KAA06048 for <[e-mail]>; Tue, 3 Aug 1999 10:59:05 -0400 (EDT)
Received: from 10.2.52.30 by lncora06.fl.fdms.firstdata.com with SMTP ( WorldSecure Server SMTP Relay(WSS) v3.6); Tue, 03 Aug 99 10:56:36 -0400
X-Server-Uuid: aadd1a76-264d-11d1-91c7-080009d97107
Received: by lnsunr02.firstdata.com(Lotus SMTP MTA v4.6.4 (830.2 3-23-1999)) id 852567C2.0051F8AF ; Tue, 3 Aug 1999 10:55:20 -0400
X-Lotus-FromDomain: FDC
To: [e-mail]
cc: "Russ Housley" <[e-mail]>, "Ed Gerck" <[e-mail]>, "'[e-mail]'" <[e-mail]>
Message-ID: <[e-mail]>
Date: Tue, 3 Aug 1999 07:43:27 -0700
Subject: Re: Common misconceptions, was Re: KISS for PKIX. (Was: RE: ASN .1vs XML (used to be RE: I-D ACTION
MIME-Version: 1.0
X-WSS-ID: 1BB9DCAE26804-01-01
Content-Type: text/plain;  charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: 7bit

... oops and sorry for going on ... but question of whether bank is liable tends
to be different than whether or not a specific person can be convicted in case
of fraud. bank
can establish all the information assurance procedures that a corporation has to
follow ...and try and get off the hook for liability in case of (online)
fraudalent transaction. that is somewhat seperate from whether a specific
(corporate insider or external) can be convicted of executing the fraudulant
transaction.





Received: from mail01-ewr.pilot.net (mail-ewr-1.pilot.net [206.98.230.18]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id HAA06713 for <[e-mail]>; Tue, 3 Aug 1999 07:24:02 -0700 (PDT)
From: [e-mail]
Received: from mailgw.firstdata.com ([204.48.27.166]) by mail01-ewr.pilot.net with ESMTP id KAA06796 for <[e-mail]>; Tue, 3 Aug 1999 10:26:58 -0400 (EDT)
Received: from lncora06.fl.fdms.firstdata.com (lnsunr02.firstdata.com [192.168.247.16]) by mailgw.firstdata.com with SMTP id KAA02890 for <[e-mail]>; Tue, 3 Aug 1999 10:26:56 -0400 (EDT)
Received: from 10.2.52.30 by lncora06.fl.fdms.firstdata.com with SMTP ( WorldSecure Server SMTP Relay(WSS) v3.6); Tue, 03 Aug 99 10:24:33 -0400
X-Server-Uuid: aadd1a76-264d-11d1-91c7-080009d97107
Received: by lnsunr02.firstdata.com(Lotus SMTP MTA v4.6.4 (830.2 3-23-1999)) id 852567C2.004F0836 ; Tue, 3 Aug 1999 10:23:14 -0400
X-Lotus-FromDomain: FDC
To: [e-mail]
cc: "Russ Housley" <[e-mail]>, "Ed Gerck" <[e-mail]>, "'[e-mail]'" <[e-mail]>
Message-ID: <[e-mail]>
Date: Tue, 3 Aug 1999 07:24:15 -0700
Subject: Re: Common misconceptions, was Re: KISS for PKIX. (Was: RE: ASN .1vs XML (used to be RE: I-D ACTION
MIME-Version: 1.0
X-WSS-ID: 1BB8242B22372-01-01
Content-Type: text/plain;  charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: 7bit

oh yes ... i don't know about the availability to non-members ... but example of
some of the discussions on business banking:

http://www.global-concepts.com./forums/if_members/April_98.html

http://www.global-concepts.com./forums/if_members/if_presentations.html





Received: from mail01-ewr.pilot.net (mail-ewr-1.pilot.net [206.98.230.18]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id HAA06486 for <[e-mail]>; Tue, 3 Aug 1999 07:20:25 -0700 (PDT)
From: [e-mail]
Received: from mailgw.firstdata.com ([204.48.27.166]) by mail01-ewr.pilot.net with ESMTP id KAA05791 for <[e-mail]>; Tue, 3 Aug 1999 10:23:21 -0400 (EDT)
Received: from lncora06.fl.fdms.firstdata.com (lnsunr02.firstdata.com [192.168.247.16]) by mailgw.firstdata.com with SMTP id KAA02557 for <[e-mail]>; Tue, 3 Aug 1999 10:23:19 -0400 (EDT)
Received: from 10.2.52.30 by lncora06.fl.fdms.firstdata.com with SMTP ( WorldSecure Server SMTP Relay(WSS) v3.6); Tue, 03 Aug 99 10:20:55 -0400
X-Server-Uuid: aadd1a76-264d-11d1-91c7-080009d97107
Received: by lnsunr02.firstdata.com(Lotus SMTP MTA v4.6.4 (830.2 3-23-1999)) id 852567C2.004EB2D4 ; Tue, 3 Aug 1999 10:19:35 -0400
X-Lotus-FromDomain: FDC
To: [e-mail]
cc: "Russ Housley" <[e-mail]>, "Ed Gerck" <[e-mail]>, "'[e-mail]'" <[e-mail]>
Message-ID: <[e-mail]>
Date: Tue, 3 Aug 1999 07:20:35 -0700
Subject: Re: Common misconceptions, was Re: KISS for PKIX. (Was: RE: ASN .1vs XML (used to be RE: I-D ACTION
MIME-Version: 1.0
X-WSS-ID: 1BB8254D21897-02-01
Content-Type: text/plain;  charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: 7bit

with regard to banks dealing with online corporate transactions (typical is cash
management).... was difficult going from dumb terminals to online PCs ... even
with passwords ... a big concern was that corporate people would program
password into automatic scripting software as well as how lax they were in what
kind of software introduced onto the machine. basically there was very wide
variation across companies in how they observed information security policy with
regard to PCs used for doing online corporate banking transactions. the advent
of the internet is even more challenging .... as part of offering service and
reducing the cost of doing business ... corporate online banking software
package can have nearly 50 different versions to correspond to different kinds
of PCs, different kinds of PC operating system, different releases of PC
operating systems, as well as different modems. Going to internet SSL/VPN gets
the bank out of the sofware product business ... as well as all the software
product customer calls. The downsides is the level of information security is
typically even worse for PCs used for internet connections ... than what was
observed for previous generation of online-banking PCs. With broad range of
corporations using online banking software ... it was/is difficult mandating
appropriate level of information security for the machines involved. range of
companies from small operations with a dozen employees or less up thru very
large corporations with hundreds of thousands of employess ... required that
banks be somewhat flexable &/or look the other way.

trivial problem with (corporate) banking passwords/secret keys ... is that there
tends to be one per corporation ... with multiple corporate officers knowing the
value. in court cases ... one of legal non-repudiation issues is to show that
only a specific person could have executed a fradulant transaction.

the common exploit for passwords (& secret keys) is various kinds of social
engineering ... only the very largest corporations may have stringent training
with strong auditing procedures and unannounced penetrations/attacks ... that
they will be sure that their people are immune.  going to hardware token digital
signging (with or w/o certificates) cuts the possibly exploit to trojan horse
infections that display one thing on the screen ... but present the token
something else for signing.  for court cases ... would need hardware token per
person (non-shared) as well as demonstrable information security showing PC was
free of trojan horse software. observation is there is broad range of compliance
of information assurance among corporations using online banking for things like
cash management (including sweaping various amounts between different accounts
and/or even different banks). if lots of corporations were telling a bank that
that they were going to another bank to get "internet-based" online cash
management ... they would tend to try and provide the service ... regardless of
what their security people thot about the current state & vulnerbilities of
internet based services.

also there was recent note that (german) court held bank liable in fraud case
based (in part) that technology relied on DES and DES is not secure enuf
anymore.






[e-mail] on 08/02/99 01:24:23 PM

To:   Lynn Wheeler/CA/FDMS/FDC@FDC
cc:   Russ Housley <[e-mail]>, Ed Gerck <[e-mail]>,
      "'[e-mail]'" <[e-mail]>
Subject:  Re: Common misconceptions,      was Re: KISS for PKIX. (Was: RE: ASN
      .1vs XML (used to be RE:      I-D ACTION





Maybe for retail transactions and depending on the level of security
implemented.Unlikely for corporate banking transactions, since one of the
trivial details would be to know the secret key assigned to the customer that is
needed to authenticate the payment order

regards,
eric


To: [e-mail]
Subject: Re: Common misconceptions, was Re: KISS for PKIX. (Was: RE: ASN
.1vs XML (used to be RE: I-D ACTION
:draft-ietf-pkix-scvp- 00.txt ))
From: [e-mail]
Date: Mon, 2 Aug 1999 01:00:51 -0700
cc: Russ Housley <[e-mail]>, Ed Gerck <[e-mail]>,
"'[e-mail]'" <[e-mail]>



note that while software trojan horse can result in signing of incorrect data on
payment transactions .... that exploit is significantly smaller than current
situation where knowing the account number and a trivial number of other details
allows arbritrary generation of transactions from scratch. no trojans &
non-repudiation is better than trojans & repudiation ... but either one is a
great deal better than existing situation.










Received: from caladan.verisign.com (CALADAN.VERISIGN.COM [205.180.232.21]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id HAA06321 for <[e-mail]>; Tue, 3 Aug 1999 07:18:52 -0700 (PDT)
Received: from mentat.verisign.com by caladan.verisign.com (8.8.5/BCH1.5) id HAA24142; Tue, 3 Aug 1999 07:19:54 -0700 (PDT)
Received: from newman.verisign.com by mentat.verisign.com (8.8.5/BCH1.0) id HAA12061; Tue, 3 Aug 1999 07:21:13 -0700 (PDT)
Received: by newman.verisign.com with Internet Mail Service (5.5.2448.0) id <PQHGAJXK>; Tue, 3 Aug 1999 07:21:16 -0700
Message-ID: <[e-mail]>
From: Warwick Ford <[e-mail]>
To: [e-mail]
Cc: "'Tim Polk'" <[e-mail]>, [e-mail]
Subject: RE: Requesting WG Last Call for ECDSA Profile
Date: Tue, 3 Aug 1999 07:21:14 -0700 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2448.0)
Content-Type: text/plain; charset="iso-8859-1"

The PKIX ECDSA Profile <draft-ietf-pkix-ipki-ecdsa-01.txt> is hereby issued
for 14-day WG Last Call.

Warwick

> -----Original Message-----
> From: Tim Polk [mailto:[e-mail]]
> Sent: Monday, August 02, 1999 2:12 PM
> To: [e-mail]; [e-mail]
> Cc: [e-mail]
> Subject: Requesting WG Last Call for ECDSA Profile
> 
> 
> 
> Warwick & Steve,
> 
> I am requesting WG Last Call for the PKIX ECDSA profile.  I 
> am not aware of
> any outstanding issues, and the corresponding ANSI document 
> is complete and
> stable.
> 
> Thanks,
> 
> Tim Polk
> 


Received: from honcho.austin.dascom.com (email.austin.dascom.com [206.196.73.5]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id HAA05877 for <[e-mail]>; Tue, 3 Aug 1999 07:06:35 -0700 (PDT)
Received: from austin.dascom.com by honcho.austin.dascom.com (8.8.8/SMI-SVR4) id JAA21816; Tue, 3 Aug 1999 09:06:30 -0500 (CDT)
Received: from shaggy by austin.dascom.com (8.8.8/SMI-SVR4) id JAA04984; Tue, 3 Aug 1999 09:06:30 -0500 (CDT)
Message-ID: <012801beddba$018065c0$[e-mail]>
Reply-To: "Bob Blakley" <[e-mail]>
From: "Bob Blakley" <[e-mail]>
To: "Ed Gerck" <[e-mail]>, "David P. Kemp" <[e-mail]>
Cc: <[e-mail]>
Subject: Re: Common misconceptions
Date: Tue, 3 Aug 1999 09:10:56 -0500
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="----=_NextPart_000_0125_01BEDD90.18780320"
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

This is a multi-part message in MIME format.

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

Ed, David:

>> This statement is beyond my comprehension.  If a user is positively
>> identified (by eyewitnesses, DNA evidence, and his smartcard's
>> signature in a POS terminal) at a crime scene, he has little power to
>> repudiate his involvement.
>
>Thank you for the opportunity to clarify my statement -- which is a general
>statement valid in many legal systems (including common and civil law). If
>a person is positively identified  by DNA evidence of his sperm on a dress
>then the person has full liability to the extent of that identification (say,
>1:1000,000)  and to the extent that production of the sample was (most
>liked than not) voluntary and within his *power* to avoid.  Likewise, if a
>fresh sample of a person's blood is present at a crime scene then this
strongly
>implies that the person was present and has full liability for that presence
>to the extent of the time factor (fresh) and blood identification because
production
>of the sample at that time and place was (most likely than not) within his
>*power* to avoid.

Sorry, but you're both confused here.  This is something I know a lot about,
as
my wife is a forensic DNA analyst who's testified to DNA evidence on many
occasions.

A sample of DNA evidence has nothing whatsoever to do with non-repudiation.
Non-repudiation evidence is evidence of intent; DNA evidence is emphatically
**NOT** evidence of intent.  Both of Ed's examples get this wrong.

Sperm on a dress *may be* evidence of one party's sexual activity in the
presence of
a dress (not necessarily of the owner of the dress, or even the person who
most
recently wore it).  The most common defense against a charge of rape to which
DNA evidence is adduced as evidence, is consent.  In other words, the accused
party claims that the accuser consented to the act.  This defense is
successful
in strikingly many cases. The DNA evidence has no bearing on repudiation, as
there is no presumption or prior claim *by the accused* of intent or action.
In fact, in the USA, given the presumption of innocence in criminal
proceedings,
exactly the opposite is the case - the accused is presumed NOT to have
committed
the act, hence the evidence is a priori presumed not to indicate intent (hence
guilt)
unless it's so compelling that the jury finds it convincing all by itself.

The O.J. Simpson case should dispel any doubts that blood DNA evidence
creates a presumption of intent, at least in the USA.  Blood DNA indicates
that
a party's blood, with some probability, was present at the scene.  Again, in a
criminal proceeding, this evidence must overcome a presumption of innocence,
and is NOT indicative of intent, which MUST be established separately, at
least
in the USA.

Incidentally, no person is *ever* "positively identified" by DNA evidence.  If
you look
at the FBI's guidelines for presenting DNA evidence (even as they were before
the
FBI crime lab's run of bad publicity recently), this is very clear.  The FBI,
and all US
crime labs, have elaborate statistical rules for determining the probability
that

        a randomly chosen member of a population would match a given
        evidentiary sample

If this probability is low, and the suspect (or defendant) does match the
sample,
this can be taken as evidence that the suspect or defendant "contributed the
sample".
On this basis the suspect or defendant "cannot be excluded" by the sample.

I know of NO legal system whereby either

    1. A person incurs any liability as a result of contributing DNA to an
evidentiary sample.

        (persons incur liability through findings of fact, which may take DNA
as evidence)

    2. The extent of liability is contingent upon "the extent of
identification".

        (no legal system I know of judges strength of identity by inverse of
probability of
         DNA match, for example)

>Of course, the above comparison between sperm and blood samples already
>dicloses a basic difference between both in terms of degree of
non-repudiation
>which also links to power, in that the second depends on a much lesser degree
on
>that person's power to prevent it -- a simple needle will do, in  a casual
and even
>unperceived encounter (a  brief pain).  For example, a sperm stain on a dress
>can be much more devastating as evidence (as recent events showed) than a
>blood stain, which may even provide no evidence at all (seen the last episode
>of  "The Practice"? OJ?)

Sorry, but at least in the US legal system this simply isn't so.  DNA evidence
is
gathered from three kinds of samples: blood, sperm, and epithelial cells (e.g.
skin
cells).  Which type of sample generated a DNA match has as far as I'm aware
NEVER been raised as an issue either against strength of identification or
against
intent (to which DNA evidence isn't relevant anyway) in a US court case.

The only court I know of where "a sperm stain on a dress can be much more
devastating
evidence" is the court of public opinion, where the standard of evidence is so
low
that non-repudiation certainly isn't an issue.



--bob

Bob Blakley ([e-mail])
Chief Scientist, Dascom


------=_NextPart_000_0125_01BEDD90.18780320
Content-Type: text/x-vcard;
	name="Bob Blakley.vcf"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment;
	filename="Bob Blakley.vcf"

BEGIN:VCARD
VERSION:2.1
N:Blakley;Bob
FN:Bob Blakley
ORG:Dascom
TITLE:Chief Scientist
TEL;WORK;VOICE:[phone] x 5012
TEL;WORK;FAX:[phone]
ADR;WORK;ENCODING=3DQUOTED-PRINTABLE:;;Plaza Balcones=3D0D=3D0A5515 =
Balcones Drive;Austin;TX;78731;USA
LABEL;WORK;ENCODING=3DQUOTED-PRINTABLE:Plaza Balcones=3D0D=3D0A5515 =
Balcones Drive=3D0D=3D0AAustin, TX 78731=3D0D=3D0AUSA
URL:
URL:http://www.dascom.com
EMAIL;PREF;INTERNET:[e-mail]
REV:19990803T141056Z
END:VCARD

------=_NextPart_000_0125_01BEDD90.18780320--



Received: from edelweb.fr (edelweb.fr [193.51.12.16]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id HAA05576 for <[e-mail]>; Tue, 3 Aug 1999 07:00:31 -0700 (PDT)
Received: from champagne.edelweb.fr (localhost.edelweb.fr [127.0.0.1]) by edelweb.fr with ESMTP id QAA11239; Tue, 3 Aug 1999 16:03:15 +0200 (MET DST)
Received: from champagne.edelweb.fr (champagne.edelweb.fr [193.51.14.161]) by edelweb.fr (nospam/1.1); Tue, 3 Aug 1999 16:03:14 +0200 (MET DST)
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 QAA02128; Tue, 3 Aug 1999 16:03:06 +0200 (MET DST)
From: Peter Sylvester <[e-mail]>
Received: (sylvest@localhost) by emeriau.edelweb.fr (8.7.6/8.6.6) id QAA25608; Tue, 3 Aug 1999 16:03:05 +0200 (MET DST)
Date: Tue, 3 Aug 1999 16:03:05 +0200 (MET DST)
Message-Id: <[e-mail]>
To: [e-mail], [e-mail]
Subject: Re: TSP: New TSTTime definition
Cc: [e-mail]

> 
> The serial number in TSTInfo is not mandatory. It is an ABSOLUTE
> number (starting from the beginning of the life of the TSA and
> ending only when the TSA ceases activity or changes its name). There
> has been a thread on that topic. One of the reasons is that
> maintaining this number after a crash of the TSAn might be a
> problem. Another reason is the possibility to spy the number of Time
> Stamps being done by a given TSA and hence measuring its activity.
> 
The serialnumber does not need to be incremented by 1, you can for 
example choose something like 

(seconds since begin of existance)*x1000+number 


Received: from edelweb.fr (edelweb.fr [193.51.12.16]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id EAA02644 for <[e-mail]>; Tue, 3 Aug 1999 04:51:34 -0700 (PDT)
Received: from champagne.edelweb.fr (localhost.edelweb.fr [127.0.0.1]) by edelweb.fr with ESMTP id NAA09334; Tue, 3 Aug 1999 13:54:20 +0200 (MET DST)
Received: from champagne.edelweb.fr (champagne.edelweb.fr [193.51.14.161]) by edelweb.fr (nospam/1.1); Tue, 3 Aug 1999 13:54:19 +0200 (MET DST)
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 NAA01186; Tue, 3 Aug 1999 13:54:18 +0200 (MET DST)
From: Peter Sylvester <[e-mail]>
Received: (sylvest@localhost) by emeriau.edelweb.fr (8.7.6/8.6.6) id NAA25539; Tue, 3 Aug 1999 13:54:18 +0200 (MET DST)
Date: Tue, 3 Aug 1999 13:54:18 +0200 (MET DST)
Message-Id: <[e-mail]>
To: [e-mail]
Subject: Re: New TSTTime definition
Cc: [e-mail]

Hi,

- A binary fraction of time always needs a calculation (conversion
  to decimals. it is not clear how many digits a user agent
  should present to a user espcially in case of some precision. 
  if one requires no loss of information during display then the
  tex string becomes horribly long and the complexity of the
  display is far away from what can be actually expressed.

  "the time stamp is xxxx plus .39876874654854 (+= -2**15)"

- GeneralizedTime does not need much work to present it to a user.
  It seems to me that fractions in GeneralizedTime are intended
  to convey information about higher precision time values;
  I propose to allow subseconds in the genTime at least when 
  the other precision stuff is not present. 

  BTW: If a certificate says "notafter 23:59:59" means not after
  the end of the second that starts with 23:59:59 because during
  the whole second a clock shows that value.

  If time stamps with a precision below a second are necessary
  then it might also be necessary to change certificates, i.e.
  extend the precision.


- Is the serialnumber in the TSTTime unique within the second
  expressed by genTime, or globally? (I have the feeling that
  
> > 1) when associated with the name of the TSA and the genTime it may
> > be used to unambiguously reference a Time Stamp token for auditing
> > purposes. In order to allow anyone to easily reference any token
> > from any TSA, this field is mandatory.
  indicates uniqueness within a second, if so, ok.

- If a time stamp authority just want to sell stamps without
  indication any particular order if they happen to be in the
  same second, what should they code? 

- Using the NTP logic to carry subseconds seems to be a left over
  from a misunderstanding of requirements for "secure time" and
  "time stamp". using the time stamp protocol to provide secure
  time doesn't seem the a good approach anyway (I would start using
  a kind of NTP over secured channel, IPSEC, TLS, etc.).

Peter


Received: from firewall.andxor.it (firewall.andxor.it [195.223.2.2]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id EAA01671 for <[e-mail]>; Tue, 3 Aug 1999 04:11:03 -0700 (PDT)
Received: (from firewall@localhost) by firewall.andxor.it (8.8.7/8.8.7) id NAA16201; Tue, 3 Aug 1999 13:05:02 GMT
X-Authentication-Warning: firewall.andxor.it: firewall set sender to <[e-mail]> using -f
Received: from lello.andxor.it(195.223.2.223) by firewall.andxor.it via smap (V2.0) id xma016197; Tue, 3 Aug 99 13:04:57 GMT
Message-ID: <[e-mail]>
Date: Tue, 03 Aug 1999 13:10:51 +0200
From: Raffaello Galli <[e-mail]>
Organization: C&A
X-Mailer: Mozilla 4.5 [en] (WinNT; I)
X-Accept-Language: en
MIME-Version: 1.0
To: Denis Pinkas <[e-mail]>, [e-mail]
Subject: Re: TSP: New TSTTime definition
References: <[e-mail]> <[e-mail]> <[e-mail]>
Content-Type: multipart/mixed; boundary="------------0F0F9C106E1B6E5DA9721AEC"

This is a multi-part message in MIME format.
--------------0F0F9C106E1B6E5DA9721AEC
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Denis Pinkas wrote:

> The serialNumber is made mandatory so that TSAs are not required to
> support below of second information, in particular when that
> information is not meaningful because of a lack of accuracy.

I understand your point, but I still believe that the serialNumber field
can be OPTIONAL with the following constraint:
      --MUST be present if  fractionOfSecond  is not present
as indicated below.

TSTTime ::= SEQUENCE  {
  genTime                         GeneralizedTime,
  serialNumber                  INTEGER   OPTIONAL,
      --MUST be present if  fractionOfSecond  is not present
  precisionFactor               INTEGER   OPTIONAL,
  fractionOfSecond            BIT STRING    OPTIONAL
}

have a good lunch
Raffaello

--------------0F0F9C106E1B6E5DA9721AEC
Content-Type: text/x-vcard; charset=us-ascii;
 name="r.galli.vcf"
Content-Transfer-Encoding: 7bit
Content-Description: Card for Raffaello Galli
Content-Disposition: attachment;
 filename="r.galli.vcf"

begin:vcard 
n:Galli;Raffaello
tel;fax:++.39.2.24791826
tel;home:Please call me at work.
tel;work:++.39.2.24791823
x-mozilla-html:FALSE
url:www.com-and.com
org:C & A   Improve Your Security
adr:;;Viale Fulvio testi 126 ;Cinisello Balsamo   (MI);ITALY;20092;ITALY
version:2.1
email;internet:[e-mail]
title:Responsabile Tecnologie
note;quoted-printable:-------------------------  Improving Your Security  -------------------------=0D=0ACertification Authority -  X509 V3  -  RSA Strong  =0D=0AWeb Server SSL3 Strong  - Proxy SSL =0D=0ACrypto Smart Card - PKCS#11=0D=0AKey Manager -  Time Manager=0D=0ATime Stamping Authority  -  Corba (IIOP over SSL)=0D=0A-------------------------  Improving Your Security  -------------------------
x-mozilla-cpt:;-1
end:vcard

--------------0F0F9C106E1B6E5DA9721AEC--



Received: from clbull.frcl.bull.fr (clbull.frcl.bull.fr [129.182.8.31]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id DAA29117 for <[e-mail]>; Tue, 3 Aug 1999 03:11:25 -0700 (PDT)
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 MAA28490; Tue, 3 Aug 1999 12:14:18 +0200
Message-ID: <[e-mail]>
Date: Tue, 03 Aug 1999 12:13:55 +0200
From: Denis Pinkas <[e-mail]>
Organization: Bull
X-Mailer: Mozilla 4.06 [fr] (Win95; I)
MIME-Version: 1.0
To: Nick Pope <[e-mail]>
CC: IETF-PXIX <[e-mail]>
Subject: Re: New TSTTime definition
References: <000401bedd95$280d52e0$0500000a@npwork2>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Nick,

The format for fractionOfSecond is not "new" and was already present
in the current draft. The current definition is directly extracted
from NTP where the format of subseconds is defined this way (in 32
bits words instead of ASN1). I would like to hear about more people
carring about the sub-second information before making a decision.

I have personally no problem with your suggestion.

Regards,

Denis

 
> Denis,
> 
> I considered the BIT STRING encoding of fractionOfSecond to be difficult to
> process.  The precision will depend on the number of bits and it cannot be
> handled as a simple integer as the text suggests.  After a 3 bits the
> precision will be in fractions of milleseconds (62.5 ms, 31.25 ms etc).  I
> would suggest that a simple integer value giving 1/100 ths of second would
> be sufficient.  Any greater precision seems pointless.
> 
> Nick
> 
> > -----Original Message-----
> > From: Denis Pinkas [mailto:[e-mail]]
> > Sent: 03 August 1999 08:31
> > To: IETF-PXIX
> > Subject: TSP: New TSTTime definition
> >
> >
> > At the last WG meeting in Oslo, we discussed the format
> > of the TSTTime.
> >
> > In order to accommodate the need for PKIX applications to use
> > a time resolution up to the second and other applications wishing
> > to get a signed time below the second, here is a new proposal.
> >
> > There are many ways to address this issue. The format of
> > GeneralizedTime below the second has not been the chosen solution
> > in order to use the same time format as used in CRLs and certificates.
> > Optional fields allow to go below the second when this is really needed.
> >
> > The proposal also attempts to prevent a competition between TSAs
> > taking only argument of their better time accuracy. In others words,
> > an accuracy around the second is fairly sufficient for PKIX applications
> >
> > Before incorporating the new text in the next version, I would like
> > to get the WG opinion whether this proposal is acceptable.
> >
> > The current definition of TSTTime is as follows:
> >
> > TSTTime ::= SEQUENCE  {
> >     genTime                       GeneralizedTime,
> >     fractionOfSecond              BIT STRING,
> >     precisionFactor               INTEGER
> > }
> >
> > Here is a proposal for a new structure and the text that applies to it:
> >
> > TSTTime ::= SEQUENCE  {
> >     genTime                       GeneralizedTime,
> >     serialNumber                  INTEGER,
> >     precisionFactor               INTEGER       OPTIONAL,
> >     fractionOfSecond              BIT STRING    OPTIONAL
> > }
> >
> > GeneralizedTime shall be used as described in [RFC2459] Section
> > 4.1.2.5.2.  GeneralizedTime only represents time with one second
> > granularity.
> >
> > The integer used for the serial number shall be a strictly
> > monotonically increasing integer that will guarantee that each token
> > is unique. It carries to functions:
> >
> > 1) when associated with the name of the TSA and the genTime it may
> > be used to unambiguously reference a Time Stamp token for auditing
> > purposes. In order to allow anyone to easily reference any token
> > from any TSA, this field is mandatory.
> >
> > 2) it allows to discriminate between the ordering of multiple time
> > stamps issued within the same second. When comparing two time stamps
> > issued by the same TSA within the same second, the one which contains
> > the smaller integer shall be assumed to have been generated first.
> >
> > The precision of the time indicated in genTime may be obtained through
> > the security policy. Alternatively, the precisionFactor may be used if:
> >
> > 1) the precision of the time is variable with the time,
> > 2) a precision better than the second is desirable. In such a case,
> > the precisionFactor shall be used in conjunction with the
> > fractionOfSecond field.
> >
> > It should be noticed that in many cases the precision of
> > the clock is lost by the time of transit inherent to the transport
> > protocol.
> >
> > Conforming TSAs do not need to support the precisionFactor and the
> > fractionOfSecond fields.
> >
> > When the service is offered locally on the same machine,
> > a precision below the second can make sense. In that case,
> > the fractionOfSecond field is used in conjunction with
> > the precisionFactor field to indicate the sub-seconds.
> >
> > The precisionFactor field is an optional field. It is a signed
> > integer giving an upper bound on the difference between the timestamp
> > and UTC when the timestamp was issued. The actual precision of the
> > clock is calculated as power (2, precisionFactor).
> >
> > Note that this method defines a precision of a clock as 'being around
> > the value', not as an exact figure.  The actual method and frequency
> > of synchronising the clock with UTC time, as well as the
> > characteristics of the clock itself, define the deviation from UTC.
> >
> > A negative precisionFactor value indicates a precision as a fraction
> > of a second. This may be useful when the service is local on the same
> > machine. In that case the fractionOfSecond field is used in
> > conjunction with it to indicate the sub-seconds.
> >
> > For instance, precisionFactor=-5 would yield 2^(-5) = 0.03125 sec
> > (31 ms). This precisionFactor would account for the 50-Hz (20 ms) or
> > 60-Hz (16.67 ms) power-frequency clock that is closely synchronized
> > with UTC, for example.
> >
> > A positive precisionFactor value indicates a precision above the second.
> >
> > The fractionOfSecond field is an optional field which shall be used
> > only when the precisionFactor field is present. It is an unsigned
> > integer indicating the fraction of second; i.e. with the most
> > significant bit indicating 500 ms, the second 250 ms, and so on.
> >
> > -----
> >
> > Denis
> >
> >


Received: from clbull.frcl.bull.fr (clbull.frcl.bull.fr [129.182.8.31]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id DAA27556 for <[e-mail]>; Tue, 3 Aug 1999 03:04:42 -0700 (PDT)
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 MAA20496; Tue, 3 Aug 1999 12:07:42 +0200
Message-ID: <[e-mail]>
Date: Tue, 03 Aug 1999 12:07:20 +0200
From: Denis Pinkas <[e-mail]>
Organization: Bull
X-Mailer: Mozilla 4.06 [fr] (Win95; I)
MIME-Version: 1.0
To: Santoni Adriano <[e-mail]>
CC: IETF-PXIX <[e-mail]>
Subject: Re: R: New TSTTime definition
References: <[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Santoni,

The serial number in TSTInfo is an absolute optional number, whereas
the other one includes in TSTTIme is a relative mandatory one.

Take a look at the answer I just made on the same topic for other
arguments.

Regards,

Denis


> > Here is a proposal for a new structure and the text that
> > applies to it:
> >
> > TSTTime ::= SEQUENCE  {
> >     genTime                       GeneralizedTime,
> >     serialNumber                  INTEGER,
> >     precisionFactor               INTEGER       OPTIONAL,
> >     fractionOfSecond              BIT STRING    OPTIONAL
> > }
> >
> > [...]
> >
> > The integer used for the serial number shall be a strictly
> > monotonically increasing integer that will guarantee that each token
> > is unique. It carries to functions:
> 
> I take it that the serialNumber field of the outer TSTInfo structure (see
> below excerpt from draft-ietf-pkix-time-stamp-02.txt) is not sufficient to
> guarantee uniqueness of each token issued by a certain TSA. Then, what would
> be its purpose?
> 
> -----BEGIN EXCERPT-----
> 
> TSTInfo ::= SEQUENCE  {
>      version                      Integer  { v1(0) },
>      policy                       PolicyInformation,
>      tsa                          [0] GeneralName OPTIONAL,
>      tstTime                      TSTTime,
>      nonce                        [1] Integer OPTIONAL,
>       messageImprint               [2] MessageImprint OPTIONAL,
>      serialNumber                 [3] Integer OPTIONAL, --- <<< this one
>      tsaFreeData                  [4] OCTET STRING OPTIONAL,
>      tdaTokens                    [5] SEQUENCE OF TemporalDataToken OPTIONAL
> }
> 
> -----END EXCERPT-----
> 
> Adriano Santoni
> SIA S.p.A.


Received: from popmail.inbox.se (popmail.inbox.se [193.12.72.101]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id DAA27403 for <[e-mail]>; Tue, 3 Aug 1999 03:04:03 -0700 (PDT)
Received: from stefan2 (accurata.inbox.se [193.12.72.24]) by popmail.inbox.se (8.9.3/8.9.3) with SMTP id MAA19053; Tue, 3 Aug 1999 12:06:32 +0200
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 
Date: Tue, 03 Aug 1999 12:06:49 +0200
To: Denis Pinkas <[e-mail]>, IETF-PXIX <[e-mail]>
From: Stefan Santesson <[e-mail]>
Subject: Re: TSP: New TSTTime definition 
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 mail.proper.com id DAA27404

Denis,

I agree to the previous comments regarding serialNumber in TSTTime.
This serialNumber is no time information and should not be present here.

I believe it would be much more clean to use the serialNumber in the
TSTInfo to determine sequences and provide uniqueness in timestamps.

I also believe that serialNumber should be optional. Far from all
applications are concerned with sequence determination or need serialNumber
to resist replay attacks.

/Stefan 

At 09:30 AM 8/3/99 +0200, Denis Pinkas wrote:
>At the last WG meeting in Oslo, we discussed the format
>of the TSTTime.
>
>In order to accommodate the need for PKIX applications to use
>a time resolution up to the second and other applications wishing
>to get a signed time below the second, here is a new proposal.
>
>There are many ways to address this issue. The format of
>GeneralizedTime below the second has not been the chosen solution
>in order to use the same time format as used in CRLs and certificates.
>Optional fields allow to go below the second when this is really needed.
>
>The proposal also attempts to prevent a competition between TSAs
>taking only argument of their better time accuracy. In others words,
>an accuracy around the second is fairly sufficient for PKIX applications
>
>Before incorporating the new text in the next version, I would like
>to get the WG opinion whether this proposal is acceptable.
>
>The current definition of TSTTime is as follows:
>
>TSTTime ::= SEQUENCE  {
>    genTime                       GeneralizedTime,
>    fractionOfSecond              BIT STRING,
>    precisionFactor               INTEGER
>}
>
>Here is a proposal for a new structure and the text that applies to it:
>
>TSTTime ::= SEQUENCE  {
>    genTime                       GeneralizedTime,
>    serialNumber                  INTEGER,
>    precisionFactor               INTEGER       OPTIONAL,
>    fractionOfSecond              BIT STRING    OPTIONAL
>}
>
>GeneralizedTime shall be used as described in [RFC2459] Section
>4.1.2.5.2.  GeneralizedTime only represents time with one second
>granularity.
>
>The integer used for the serial number shall be a strictly
>monotonically increasing integer that will guarantee that each token
>is unique. It carries to functions:
>
>1) when associated with the name of the TSA and the genTime it may
>be used to unambiguously reference a Time Stamp token for auditing
>purposes. In order to allow anyone to easily reference any token
>from any TSA, this field is mandatory.
>
>2) it allows to discriminate between the ordering of multiple time
>stamps issued within the same second. When comparing two time stamps
>issued by the same TSA within the same second, the one which contains
>the smaller integer shall be assumed to have been generated first.
>
>The precision of the time indicated in genTime may be obtained through
>the security policy. Alternatively, the precisionFactor may be used if:
>
>1) the precision of the time is variable with the time,
>2) a precision better than the second is desirable. In such a case,
>the precisionFactor shall be used in conjunction with the
>fractionOfSecond field.
>
>It should be noticed that in many cases the precision of
>the clock is lost by the time of transit inherent to the transport
>protocol.
>
>Conforming TSAs do not need to support the precisionFactor and the
>fractionOfSecond fields.
>
>When the service is offered locally on the same machine,
>a precision below the second can make sense. In that case,
>the fractionOfSecond field is used in conjunction with
>the precisionFactor field to indicate the sub-seconds.
>
>The precisionFactor field is an optional field. It is a signed
>integer giving an upper bound on the difference between the timestamp
>and UTC when the timestamp was issued. The actual precision of the
>clock is calculated as power (2, precisionFactor).
>
>Note that this method defines a precision of a clock as 'being around
>the value', not as an exact figure.  The actual method and frequency
>of synchronising the clock with UTC time, as well as the
>characteristics of the clock itself, define the deviation from UTC.
>
>A negative precisionFactor value indicates a precision as a fraction
>of a second. This may be useful when the service is local on the same
>machine. In that case the fractionOfSecond field is used in
>conjunction with it to indicate the sub-seconds.
>
>For instance, precisionFactor=-5 would yield 2^(-5) = 0.03125 sec
>(31 ms). This precisionFactor would account for the 50-Hz (20 ms) or
>60-Hz (16.67 ms) power-frequency clock that is closely synchronized
>with UTC, for example.
>
>A positive precisionFactor value indicates a precision above the second.
>
>The fractionOfSecond field is an optional field which shall be used
>only when the precisionFactor field is present. It is an unsigned
>integer indicating the fraction of second; i.e. with the most
>significant bit indicating 500 ms, the second 250 ms, and so on.
>
>-----
>
>Denis

-------------------------------------------------------------------
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 mail.proper.com (8.9.3/8.9.3) with ESMTP id DAA27203 for <[e-mail]>; Tue, 3 Aug 1999 03:02:24 -0700 (PDT)
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 MAA17152; Tue, 3 Aug 1999 12:04:46 +0200
Message-ID: <[e-mail]>
Date: Tue, 03 Aug 1999 12:04:24 +0200
From: Denis Pinkas <[e-mail]>
Organization: Bull
X-Mailer: Mozilla 4.06 [fr] (Win95; I)
MIME-Version: 1.0
To: Raffaello Galli <[e-mail]>
CC: [e-mail]
Subject: Re: TSP: New TSTTime definition
References: <[e-mail]> <[e-mail]>
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit

Raffaello,

Thanks for your very fast answer.

The serialNumber is made mandatory so that TSAs are not required to
support below of second information, in particular when that
information is not meaningful because of a lack of accuracy.

It also serves, as indicated, as a pointer that can be used by any
one to retrieve or point to an old time stamp.

The serial number in TSTInfo is not mandatory. It is an ABSOLUTE
number (starting from the beginning of the life of the TSA and
ending only when the TSA ceases activity or changes its name). There
has been a thread on that topic. One of the reasons is that
maintaining this number after a crash of the TSAn might be a
problem. Another reason is the possibility to spy the number of Time
Stamps being done by a given TSA and hence measuring its activity.

Regards,
 
Denis


> 
> You wrote :
> >>> The integer used for the serial number shall be a strictly
> >>> monotonically increasing integer that will guarantee that each token
> >>> is unique. It carries to functions:
> >>>
> >>> 1) when associated with the name of the TSA and the genTime it may
> >>> be used to unambiguously reference a Time Stamp token for auditing
> >>> purposes. In order to allow anyone to easily reference any token
> >>> from any TSA, this field is mandatory.
> 
> >>> 2) it allows to discriminate between the ordering of multiple time
> >>> stamps issued within the same second. When comparing two time stamps
> >>> issued by the same TSA within the same second, the one which contains
> >>> the smaller integer shall be assumed to have been generated first.
> 
> Hi Denis,
> first I would like to answer to your second point.
> 2)
> According to me the proposal for the new structure of TSTTime is fine but
> I suggest to add an "OPTIONAL" flag to the "serialNumber" field as follow.
> 
> TSTTime ::= SEQUENCE  {
>     genTime                         GeneralizedTime,
>     serialNumber                  INTEGER   OPTIONAL,
>        --MUST be present if  fractionOfSecond  is not present
>     precisionFactor               INTEGER   OPTIONAL,
>     fractionOfSecond            BIT STRING    OPTIONAL
> }
> 
> A TSA filling in this new structure can decide to use the fractionOfSecond
> field
> and/or the serialNumber field if  doesn't  support the precisionFactor and
> the
> fractionOfSecond fields.
> 
> Now let's go back to the first.
> 1)
> I will remind you that the serilaNumber field is cointained into the TSTInfo
> structure anyway.
> So I think there are only two solutions:
>    A) the serialNumber field inside the TSTInfo structure should be changed
> from
>         OPTIONAL to MANDATORY without adding any serialNumber field inside
>         the TSTTime structure and using it for discriminating between the
> ordering of multiple
>         time stamps issued within the same second.
>     B) the serialNumber field inside the TSTInfo structure should be
> deleted.
> 
> So after all this word I think that the best solution is to change OPTIONAL
> to MANDATORY
> the serialNuber field in the TSTInfo structure and delete the serialNumber
> field from the
> TSTTime structure.
> In this way TSA that doesn't support the precisionFactor and the
> fractionOfSecond fields will
> use the serialNumber field in the TSTInfo structure to order  multiple time
> stamps issued within
> the same second, and the same field can be used  for auditing purposes.
> 
> Ciao
> Raffaello
> 
>   --------------------------------------------------------------------
> 
>   Responsabile Tecnologie
>   C & A Improve Your Security
> 
>   Responsabile Tecnologie                                                                                                                                     <[e-mail]>
>   C & A Improve Your Security
>   Viale Fulvio testi 126                                                                                                                                      Télécopie: ++.39.2.24791826
>   Cinisello Balsamo (MI)                                                                                                                                      Domicile: Please call me at work.
>   ITALY                                                                                                                                                       Bureau: ++.39.2.24791823
>   20092                                                                                                                                                       Adresse Netscape Conference
>   ITALY
>   ------------------------- Improving Your Security ------------------------- Certification Authority - X509 V3 - RSA Strong Web Server SSL3 Strong - Proxy SSL Crypto Smart Card - PKCS#11 Key Manager - Time Manager Time Stamping Authority - Corba (IIOP over SSL) ------------------------- Improving Your Security -------------------------
>   Informations supplémentaires:
>   le nom       Galli
>   Prénom       Raffaello
>   Version      2.1


Received: from pegasus.group5.co.uk (mailhost.group5.co.uk [193.128.238.226]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id CAA26845 for <[e-mail]>; Tue, 3 Aug 1999 02:51:34 -0700 (PDT)
Received: from GK-Portable (unverified [62.188.137.233]) by pegasus.group5.co.uk (Rockliffe SMTPRA 2.1.5) with SMTP id <[e-mail]>; Tue, 03 Aug 1999 10:43:29 +0100
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: Windows Eudora Pro Version 3.0 (32)
Date: Tue, 03 Aug 1999 10:52:56 +0100
To: Ed Gerck <[e-mail]>
From: Graham Klyne <[e-mail]>
Subject: Re: Common misconceptions
Cc: "David P. Kemp" <[e-mail]>, [e-mail]
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"

At 16:48 02/08/99 -0700, Ed Gerck wrote:
>This is exactly the point. In no way ought challenge-response  be used
>as a response that does not depend on the challenge or that is provided
untimely.
>Which is, however, what happens when a S/MIME user receives a signed
>message and "imagines" that the cert has not been revoked so that the msg is
>"certainly" valid -- ie, the user refuses to challenge that cert and obtain a
>response in the form of a CA's  CRL .  Every time we consult a CA in
>order to verify if a cert is included in a  CRL we are performing
>challenge-response on that cert's validity  -- in other words, we are
verifying it
>in a timely manner.
>
>If you accept that reliance must be verifier-centric then you must also
agree that
>the verifier must be able to verify ;-) and, at will.

I have had some difficulty understanding exactly what you were saying, but
I am now thinking that it is pretty much embodied in the first paragraph
above.

To test my understanding, I would like to offer a hypothetical scenario
that allows "verifier centric" reliance without a challenge-response in the
struct sense that you seem to describe.

Suppose a CA is broadcasting CRLs at regular intervals.  The receiver of a
certificate will rely upon that certificate only if they are also in
posession of a fresh CRL that does not revoke it.

I think this satisfies reasonable requirements for verifier-centric
reliance, without a struct challenge/response.  (But I suppose one might
argue that the "challenge" in this scenario is implicit.)

[...]
>Thank you for the opportunity to clarify my statement -- which is a general
>statement valid in many legal systems (including common and civil law). If
>a person is positively identified  by DNA evidence of his sperm on a dress
>then the person has full liability to the extent of that identification (say,
>1:1000,000)  and to the extent that production of the sample was (most
>liked than not) voluntary and within his *power* to avoid.  Likewise, if a
>fresh sample of a person's blood is present at a crime scene then this
strongly
>implies that the person was present and has full liability for that presence
>to the extent of the time factor (fresh) and blood identification because
production
>of the sample at that time and place was (most likely than not) within his
>*power* to avoid.

So what you are describing here is the principle that liability can arise
only as the result of a *willing* action (e.g. _intent_ to commit a crime;
_wilful_ neglect of safety procedures;  _willing_ and _informed_ execution
of a contract; etc.)?

Then, I think your use of the term "legal repudiation" means "repudiation
of liability"... ?

My _dictionary_ definition of repudiate also allows "deny", prevention of
which I thought was the primary intent of technical non-repudiation
mechanisms:

  repudiate :
  1 a disown; disavow; reject. b refuse dealings with. c deny.
  2 refuse to recognize or obey (authority or a treaty).
  3 refuse to discharge (an obligation or debt).
  4 (esp. of the ancients or non-Christians) divorce (one's wife).

Clearly, any purely technical system can only be _part_ of the evidence
that may be used to establish liability in the affairs of men (as opposed
to machines).

#g

------------
Graham Klyne
([e-mail])



Received: from gnasher.sol.co.uk (gnasher.sol.co.uk [194.247.64.2]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id CAA26508 for <[e-mail]>; Tue, 3 Aug 1999 02:41:07 -0700 (PDT)
Received: from npwork2 (e2c10p43.scotland.net [148.176.238.107]) by gnasher.sol.co.uk (8.8.5/8.8.5) with SMTP id KAA12755; Tue, 3 Aug 1999 10:43:46 +0100 (BST)
From: "Nick Pope" <[e-mail]>
To: "Denis Pinkas" <[e-mail]>, "IETF-PXIX" <[e-mail]>
Subject: RE: New TSTTime definition 
Date: Tue, 3 Aug 1999 10:47:10 +0100
Message-ID: <000401bedd95$280d52e0$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
In-Reply-To: <[e-mail]>
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3

Denis,

I considered the BIT STRING encoding of fractionOfSecond to be difficult to
process.  The precision will depend on the number of bits and it cannot be
handled as a simple integer as the text suggests.  After a 3 bits the
precision will be in fractions of milleseconds (62.5 ms, 31.25 ms etc).  I
would suggest that a simple integer value giving 1/100 ths of second would
be sufficient.  Any greater precision seems pointless.

Nick

> -----Original Message-----
> From: Denis Pinkas [mailto:[e-mail]]
> Sent: 03 August 1999 08:31
> To: IETF-PXIX
> Subject: TSP: New TSTTime definition
>
>
> At the last WG meeting in Oslo, we discussed the format
> of the TSTTime.
>
> In order to accommodate the need for PKIX applications to use
> a time resolution up to the second and other applications wishing
> to get a signed time below the second, here is a new proposal.
>
> There are many ways to address this issue. The format of
> GeneralizedTime below the second has not been the chosen solution
> in order to use the same time format as used in CRLs and certificates.
> Optional fields allow to go below the second when this is really needed.
>
> The proposal also attempts to prevent a competition between TSAs
> taking only argument of their better time accuracy. In others words,
> an accuracy around the second is fairly sufficient for PKIX applications
>
> Before incorporating the new text in the next version, I would like
> to get the WG opinion whether this proposal is acceptable.
>
> The current definition of TSTTime is as follows:
>
> TSTTime ::= SEQUENCE  {
>     genTime                       GeneralizedTime,
>     fractionOfSecond              BIT STRING,
>     precisionFactor               INTEGER
> }
>
> Here is a proposal for a new structure and the text that applies to it:
>
> TSTTime ::= SEQUENCE  {
>     genTime                       GeneralizedTime,
>     serialNumber                  INTEGER,
>     precisionFactor               INTEGER       OPTIONAL,
>     fractionOfSecond              BIT STRING    OPTIONAL
> }
>
> GeneralizedTime shall be used as described in [RFC2459] Section
> 4.1.2.5.2.  GeneralizedTime only represents time with one second
> granularity.
>
> The integer used for the serial number shall be a strictly
> monotonically increasing integer that will guarantee that each token
> is unique. It carries to functions:
>
> 1) when associated with the name of the TSA and the genTime it may
> be used to unambiguously reference a Time Stamp token for auditing
> purposes. In order to allow anyone to easily reference any token
> from any TSA, this field is mandatory.
>
> 2) it allows to discriminate between the ordering of multiple time
> stamps issued within the same second. When comparing two time stamps
> issued by the same TSA within the same second, the one which contains
> the smaller integer shall be assumed to have been generated first.
>
> The precision of the time indicated in genTime may be obtained through
> the security policy. Alternatively, the precisionFactor may be used if:
>
> 1) the precision of the time is variable with the time,
> 2) a precision better than the second is desirable. In such a case,
> the precisionFactor shall be used in conjunction with the
> fractionOfSecond field.
>
> It should be noticed that in many cases the precision of
> the clock is lost by the time of transit inherent to the transport
> protocol.
>
> Conforming TSAs do not need to support the precisionFactor and the
> fractionOfSecond fields.
>
> When the service is offered locally on the same machine,
> a precision below the second can make sense. In that case,
> the fractionOfSecond field is used in conjunction with
> the precisionFactor field to indicate the sub-seconds.
>
> The precisionFactor field is an optional field. It is a signed
> integer giving an upper bound on the difference between the timestamp
> and UTC when the timestamp was issued. The actual precision of the
> clock is calculated as power (2, precisionFactor).
>
> Note that this method defines a precision of a clock as 'being around
> the value', not as an exact figure.  The actual method and frequency
> of synchronising the clock with UTC time, as well as the
> characteristics of the clock itself, define the deviation from UTC.
>
> A negative precisionFactor value indicates a precision as a fraction
> of a second. This may be useful when the service is local on the same
> machine. In that case the fractionOfSecond field is used in
> conjunction with it to indicate the sub-seconds.
>
> For instance, precisionFactor=-5 would yield 2^(-5) = 0.03125 sec
> (31 ms). This precisionFactor would account for the 50-Hz (20 ms) or
> 60-Hz (16.67 ms) power-frequency clock that is closely synchronized
> with UTC, for example.
>
> A positive precisionFactor value indicates a precision above the second.
>
> The fractionOfSecond field is an optional field which shall be used
> only when the precisionFactor field is present. It is an unsigned
> integer indicating the fraction of second; i.e. with the most
> significant bit indicating 500 ms, the second 250 ms, and so on.
>
> -----
>
> Denis
>
>



Received: from ntsiaexch.office (exchange.sia.it [192.106.192.201]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id BAA24738 for <[e-mail]>; Tue, 3 Aug 1999 01:48:44 -0700 (PDT)
Received: by ntsiaexch.office with Internet Mail Service (5.5.2448.0) id <QFJWDWZS>; Tue, 3 Aug 1999 10:51:09 +0200
Message-ID: <[e-mail]>
From: Santoni Adriano <[e-mail]>
To: "'Denis Pinkas'" <[e-mail]>
Cc: IETF-PXIX <[e-mail]>
Subject: R: New TSTTime definition 
Date: Tue, 3 Aug 1999 10:51:08 +0200 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2448.0)
Content-Type: text/plain; charset="iso-8859-1"

> Here is a proposal for a new structure and the text that
> applies to it:
>
> TSTTime ::= SEQUENCE  {
>     genTime                       GeneralizedTime,
>     serialNumber                  INTEGER,
>     precisionFactor               INTEGER       OPTIONAL,
>     fractionOfSecond              BIT STRING    OPTIONAL
> }
>
> [...]
>
> The integer used for the serial number shall be a strictly
> monotonically increasing integer that will guarantee that each token
> is unique. It carries to functions:

I take it that the serialNumber field of the outer TSTInfo structure (see
below excerpt from draft-ietf-pkix-time-stamp-02.txt) is not sufficient to
guarantee uniqueness of each token issued by a certain TSA. Then, what would
be its purpose?

-----BEGIN EXCERPT-----

TSTInfo ::= SEQUENCE  {
     version                      Integer  { v1(0) },
     policy                       PolicyInformation,
     tsa                          [0] GeneralName OPTIONAL,
     tstTime                      TSTTime,
     nonce                        [1] Integer OPTIONAL,
      messageImprint               [2] MessageImprint OPTIONAL,
     serialNumber                 [3] Integer OPTIONAL, --- <<< this one
     tsaFreeData                  [4] OCTET STRING OPTIONAL,
     tdaTokens                    [5] SEQUENCE OF TemporalDataToken OPTIONAL
}

-----END EXCERPT-----

Adriano Santoni
SIA S.p.A.



Received: from firewall.andxor.it (firewall.andxor.it [195.223.2.2]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id BAA24444 for <[e-mail]>; Tue, 3 Aug 1999 01:46:02 -0700 (PDT)
Received: (from firewall@localhost) by firewall.andxor.it (8.8.7/8.8.7) id KAA15338; Tue, 3 Aug 1999 10:40:02 GMT
X-Authentication-Warning: firewall.andxor.it: firewall set sender to <[e-mail]> using -f
Received: from lello.andxor.it(195.223.2.223) by firewall.andxor.it via smap (V2.0) id xma015336; Tue, 3 Aug 99 10:39:32 GMT
Message-ID: <[e-mail]>
Date: Tue, 03 Aug 1999 10:45:27 +0200
From: Raffaello Galli <[e-mail]>
Organization: C&A
X-Mailer: Mozilla 4.5 [en] (WinNT; I)
X-Accept-Language: en
MIME-Version: 1.0
To: Denis Pinkas <[e-mail]>, [e-mail]
Subject: Re: TSP: New TSTTime definition
References: <[e-mail]>
Content-Type: multipart/mixed; boundary="------------8E9B06FF149B3D45FFBDF1DB"

This is a multi-part message in MIME format.
--------------8E9B06FF149B3D45FFBDF1DB
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

You wrote :
>>> The integer used for the serial number shall be a strictly
>>> monotonically increasing integer that will guarantee that each token
>>> is unique. It carries to functions:
>>>
>>> 1) when associated with the name of the TSA and the genTime it may
>>> be used to unambiguously reference a Time Stamp token for auditing
>>> purposes. In order to allow anyone to easily reference any token
>>> from any TSA, this field is mandatory.

>>> 2) it allows to discriminate between the ordering of multiple time
>>> stamps issued within the same second. When comparing two time stamps
>>> issued by the same TSA within the same second, the one which contains
>>> the smaller integer shall be assumed to have been generated first.

Hi Denis,
first I would like to answer to your second point.
2)
According to me the proposal for the new structure of TSTTime is fine but
I suggest to add an "OPTIONAL" flag to the "serialNumber" field as follow.

TSTTime ::= SEQUENCE  {
    genTime                         GeneralizedTime,
    serialNumber                  INTEGER   OPTIONAL,
       --MUST be present if  fractionOfSecond  is not present
    precisionFactor               INTEGER   OPTIONAL,
    fractionOfSecond            BIT STRING    OPTIONAL
}

A TSA filling in this new structure can decide to use the fractionOfSecond
field
and/or the serialNumber field if  doesn't  support the precisionFactor and
the
fractionOfSecond fields.

Now let's go back to the first.
1)
I will remind you that the serilaNumber field is cointained into the TSTInfo
structure anyway.
So I think there are only two solutions:
   A) the serialNumber field inside the TSTInfo structure should be changed
from
        OPTIONAL to MANDATORY without adding any serialNumber field inside
        the TSTTime structure and using it for discriminating between the
ordering of multiple
        time stamps issued within the same second.
    B) the serialNumber field inside the TSTInfo structure should be
deleted.


So after all this word I think that the best solution is to change OPTIONAL
to MANDATORY
the serialNuber field in the TSTInfo structure and delete the serialNumber
field from the
TSTTime structure.
In this way TSA that doesn't support the precisionFactor and the
fractionOfSecond fields will
use the serialNumber field in the TSTInfo structure to order  multiple time
stamps issued within
the same second, and the same field can be used  for auditing purposes.

Ciao
Raffaello






--------------8E9B06FF149B3D45FFBDF1DB
Content-Type: text/x-vcard; charset=us-ascii;
 name="r.galli.vcf"
Content-Transfer-Encoding: 7bit
Content-Description: Card for Raffaello Galli
Content-Disposition: attachment;
 filename="r.galli.vcf"

begin:vcard 
n:Galli;Raffaello
tel;fax:++.39.2.24791826
tel;home:Please call me at work.
tel;work:++.39.2.24791823
x-mozilla-html:FALSE
url:www.com-and.com
org:C & A   Improve Your Security
adr:;;Viale Fulvio testi 126 ;Cinisello Balsamo   (MI);ITALY;20092;ITALY
version:2.1
email;internet:[e-mail]
title:Responsabile Tecnologie
note;quoted-printable:-------------------------  Improving Your Security  -------------------------=0D=0ACertification Authority -  X509 V3  -  RSA Strong  =0D=0AWeb Server SSL3 Strong  - Proxy SSL =0D=0ACrypto Smart Card - PKCS#11=0D=0AKey Manager -  Time Manager=0D=0ATime Stamping Authority  -  Corba (IIOP over SSL)=0D=0A-------------------------  Improving Your Security  -------------------------
x-mozilla-cpt:;-1
end:vcard

--------------8E9B06FF149B3D45FFBDF1DB--



Received: from clbull.frcl.bull.fr (clbull.frcl.bull.fr [129.182.8.31]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id AAA20093 for <[e-mail]>; Tue, 3 Aug 1999 00:27:54 -0700 (PDT)
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 JAA20562; Tue, 3 Aug 1999 09:30:59 +0200
Message-ID: <[e-mail]>
Date: Tue, 03 Aug 1999 09:30:37 +0200
From: Denis Pinkas <[e-mail]>
Organization: Bull
X-Mailer: Mozilla 4.06 [fr] (Win95; I)
MIME-Version: 1.0
To: IETF-PXIX <[e-mail]>
Subject: TSP: New TSTTime definition 
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

At the last WG meeting in Oslo, we discussed the format
of the TSTTime.

In order to accommodate the need for PKIX applications to use
a time resolution up to the second and other applications wishing
to get a signed time below the second, here is a new proposal.

There are many ways to address this issue. The format of
GeneralizedTime below the second has not been the chosen solution
in order to use the same time format as used in CRLs and certificates.
Optional fields allow to go below the second when this is really needed.

The proposal also attempts to prevent a competition between TSAs
taking only argument of their better time accuracy. In others words,
an accuracy around the second is fairly sufficient for PKIX applications

Before incorporating the new text in the next version, I would like
to get the WG opinion whether this proposal is acceptable.

The current definition of TSTTime is as follows:

TSTTime ::= SEQUENCE  {
    genTime                       GeneralizedTime,
    fractionOfSecond              BIT STRING,
    precisionFactor               INTEGER
}

Here is a proposal for a new structure and the text that applies to it:

TSTTime ::= SEQUENCE  {
    genTime                       GeneralizedTime,
    serialNumber                  INTEGER,
    precisionFactor               INTEGER       OPTIONAL,
    fractionOfSecond              BIT STRING    OPTIONAL
}

GeneralizedTime shall be used as described in [RFC2459] Section
4.1.2.5.2.  GeneralizedTime only represents time with one second
granularity.

The integer used for the serial number shall be a strictly
monotonically increasing integer that will guarantee that each token
is unique. It carries to functions:

1) when associated with the name of the TSA and the genTime it may
be used to unambiguously reference a Time Stamp token for auditing
purposes. In order to allow anyone to easily reference any token
from any TSA, this field is mandatory.

2) it allows to discriminate between the ordering of multiple time
stamps issued within the same second. When comparing two time stamps
issued by the same TSA within the same second, the one which contains
the smaller integer shall be assumed to have been generated first.

The precision of the time indicated in genTime may be obtained through
the security policy. Alternatively, the precisionFactor may be used if:

1) the precision of the time is variable with the time,
2) a precision better than the second is desirable. In such a case,
the precisionFactor shall be used in conjunction with the
fractionOfSecond field.

It should be noticed that in many cases the precision of
the clock is lost by the time of transit inherent to the transport
protocol.

Conforming TSAs do not need to support the precisionFactor and the
fractionOfSecond fields.

When the service is offered locally on the same machine,
a precision below the second can make sense. In that case,
the fractionOfSecond field is used in conjunction with
the precisionFactor field to indicate the sub-seconds.

The precisionFactor field is an optional field. It is a signed
integer giving an upper bound on the difference between the timestamp
and UTC when the timestamp was issued. The actual precision of the
clock is calculated as power (2, precisionFactor).

Note that this method defines a precision of a clock as 'being around
the value', not as an exact figure.  The actual method and frequency
of synchronising the clock with UTC time, as well as the
characteristics of the clock itself, define the deviation from UTC.

A negative precisionFactor value indicates a precision as a fraction
of a second. This may be useful when the service is local on the same
machine. In that case the fractionOfSecond field is used in
conjunction with it to indicate the sub-seconds.

For instance, precisionFactor=-5 would yield 2^(-5) = 0.03125 sec
(31 ms). This precisionFactor would account for the 50-Hz (20 ms) or
60-Hz (16.67 ms) power-frequency clock that is closely synchronized
with UTC, for example.

A positive precisionFactor value indicates a precision above the second.

The fractionOfSecond field is an optional field which shall be used
only when the precisionFactor field is present. It is an unsigned
integer indicating the fraction of second; i.e. with the most
significant bit indicating 500 ms, the second 250 ms, and so on.

-----

Denis



Received: from mailbox1.appliedtheory.com (mailbox1.appliedtheory.com [204.168.16.14]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id SAA23035 for <[e-mail]>; Mon, 2 Aug 1999 18:44:56 -0700 (PDT)
From: [e-mail]
Received: from eaglei-internet.ssg.bny.com (bk01.bankofny.com [160.254.115.80]) by mailbox1.appliedtheory.com (8.8.8/8.8.8) with SMTP id VAA25066; Mon, 2 Aug 1999 21:47:41 -0400 (EDT)
Received: from Hermes.bankofny.com by eaglei-internet.ssg.bny.com via smtpd (for mailbox1.appliedtheory.com [204.168.16.14]) with SMTP; 3 Aug 1999 01:47:41 UT
Received: from LNOTES5 by HERMES via SMTP with TCP; Mon, 2 Aug 99 16:25:11-EDT
Received: from LNOTES5 by HERMES via SMTP with TCP; Mon, 2 Aug 99 16:26:53-EDT
Received: by LNOTES5(Lotus SMTP MTA v1.2  (600.1 3-26-1998))  id 852567C1.0070233E ; Mon, 2 Aug 1999 16:24:50 -0400
X-Lotus-FromDomain: BNY
To: [e-mail]
cc: Russ Housley <[e-mail]>, Ed Gerck <[e-mail]>, "'[e-mail]'" <[e-mail]>
Message-ID: <852567C1.006F4815.00@LNOTES5>
Date: Mon, 2 Aug 1999 16:24:23 -0400
Subject: Re: Common misconceptions, was Re: KISS for PKIX. (Was: RE: ASN .1vs XML (used to be RE: I-D ACTION
Mime-Version: 1.0
Content-type: text/plain; charset=us-ascii
Content-Disposition: inline

Maybe for retail transactions and depending on the level of security
implemented.
Unlikely for corporate banking transactions, since one of the trivial
details would be to know
the secret key assigned to the customer that is needed to authenticate the
payment order.
regards,
eric


To: [e-mail]
Subject: Re: Common misconceptions, was Re: KISS for PKIX. (Was: RE: ASN
.1vs XML (used to be RE: I-D ACTION
:draft-ietf-pkix-scvp- 00.txt ))
From: [e-mail]
Date: Mon, 2 Aug 1999 01:00:51 -0700
cc: Russ Housley <[e-mail]>, Ed Gerck <[e-mail]>,
"'[e-mail]'" <[e-mail]>



note that while software trojan horse can result in signing of incorrect
data on
payment transactions .... that exploit is significantly smaller than
current
situation where knowing the account number and a trivial number of other
details
allows arbritrary generation of transactions from scratch. no trojans &
non-repudiation is better than trojans & repudiation ... but either one is
a
great deal better than existing situation.





Received: from imo13.mx.aol.com (imo13.mx.aol.com [198.81.17.3]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id RAA15387 for <[e-mail]>; Mon, 2 Aug 1999 17:47:32 -0700 (PDT)
From: [e-mail]
Received: from [e-mail] by imo13.mx.aol.com (mail_out_v22.4.) id 7XHPa13743 (4186) for <[e-mail]>; Mon, 2 Aug 1999 20:49:42 -0400 (EDT)
Message-ID: <[e-mail]>
Date: Mon, 2 Aug 1999 20:49:41 EDT
Subject: Subscribe
To: [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 21

Subscribe


Received: from tomcat.sac.verio.net ([e-mail] [209.162.64.15]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id QAA14422 for <[e-mail]>; Mon, 2 Aug 1999 16:48:44 -0700 (PDT)
Received: from nma.com (pm06-22.sac.verio.net [209.162.64.229]) by tomcat.sac.verio.net (8.9.1a/8.9.1) with ESMTP id QAA16384; Mon, 2 Aug 1999 16:49:01 -0700 (PDT)
Message-ID: <[e-mail]>
Date: Mon, 02 Aug 1999 16:48:54 -0700
From: Ed Gerck <[e-mail]>
X-Mailer: Mozilla 4.51 [en] (Win98; I)
X-Accept-Language: en
MIME-Version: 1.0
To: "David P. Kemp" <[e-mail]>
CC: [e-mail]
Subject: Re: Common misconceptions
References: <[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

"David P. Kemp" wrote:

> > Yes, and following such notion that challenge-response protocols are
> > not needed for "non-repudiation" in secure protocols/transmissions
> > in general you will arrive at the concusion that one would not need
> > to do even a challenge-response query on the CRL before you rely on
> > the authentication --  though such is demanded by S/MIME.
>
> Ed,
>
> I'm not aware of any S/MIME requirements for protocol interactivity.

Me neither ;-) and that is why I said that S/MIME does not provide
adequate grounds for legal non-repudiation -- though it may provide
adequate grounds for policy non-repudiation.

> The information flow in a PKI is all designed to be one-way: certs are
> broadcast by the CA, CRLs are broadcast by the CA, and trusted time
> is broadcast (over GBS) by NIST :-).

Indeed, some CAs broadcast CRLs to some clients. But, CRLs are generally
obtained in a pull model, not provided by a push model as you say.  Information
flow in a PKI is both push and pull -- also when seen by any party. For example,
the subscriber provides information to the CA, that does an online challenge-response
on the subscriber's private-key and then the CA provides information to the subscriber.

In fact, if information flow in a PKI would be all one-way,  there would be no
basis for verification or assurance whatsoever.

> Using the term "challenge-response" to describe a policy- or legal-
> driven obligation of a certificate subject to report key compromises
> or other status changes to the CA (and I can't tell whether you've
> used it for that purpose) would not be accurate.

I used the term "challenge-response" to mean a challenge followed by a
response. Thus, correct.  What I called attention to (in linking to legal
terms) is that neither has to be cryptographic. I also noted that the time that
is allowed to elapse between challenge and response depends on operational
factors--  eg, as I am sure you aware but I just say it here in order to provide
an example, the definition of "real-time" can change from femtoseconds to
months or more, as a function of the system being considered.

> The information may
> flow from the subject to the CA, but it is not in response to any
> perceptible challenge.

Validation procedures for the subject's public-key are suggested ( though
not mandated) for example in Section 10 of X.509v3 -- which includes a
perceptible challenge.

> Using it to describe the interaction between a user and his
> private-key-wielding machine (view document, pop up dialog, click OK)
> is not completely inaccurate, but that has nothing to do with
> interactions between the subject and other parties in a PKI.

Perhaps my use of it was not clear to you. But I did use the term to mean
what the term means -- as I tried to explain above. I used the term
"challenge-response" to mean a challenge followed by a response in a timely
manner.  I did not mean "dead" data and I especifically excluded it.

> Even in
> the context of local operations, using the term "challenge-response" to
> describe an interaction with a dialog box is mostly inaccurate: in
> order to be effective, a response must depend on the challenge, not
> be a simple reflexive action.

This is exactly the point. In no way ought challenge-response  be used
as a response that does not depend on the challenge or that is provided untimely.
Which is, however, what happens when a S/MIME user receives a signed
message and "imagines" that the cert has not been revoked so that the msg is
"certainly" valid -- ie, the user refuses to challenge that cert and obtain a
response in the form of a CA's  CRL .  Every time we consult a CA in
order to verify if a cert is included in a  CRL we are performing
challenge-response on that cert's validity  -- in other words, we are verifying it
in a timely manner.

If you accept that reliance must be verifier-centric then you must also agree that
the verifier must be able to verify ;-) and, at will.

> > 2. the absence of a legal challenge-response mechanism will always
> > indicate absence of legal non-repudiation because power is the
> > counterpart of liability in law -- if the user has no power to deny
> > authentication then the user has no liability derived from it;
>
> This statement is beyond my comprehension.  If a user is positively
> identified (by eyewitnesses, DNA evidence, and his smartcard's
> signature in a POS terminal) at a crime scene, he has little power to
> repudiate his involvement.

Thank you for the opportunity to clarify my statement -- which is a general
statement valid in many legal systems (including common and civil law). If
a person is positively identified  by DNA evidence of his sperm on a dress
then the person has full liability to the extent of that identification (say,
1:1000,000)  and to the extent that production of the sample was (most
liked than not) voluntary and within his *power* to avoid.  Likewise, if a
fresh sample of a person's blood is present at a crime scene then this strongly
implies that the person was present and has full liability for that presence
to the extent of the time factor (fresh) and blood identification because production
of the sample at that time and place was (most likely than not) within his
*power* to avoid.

The issue is thus not on power to repudiate *a posteriori* (as you commented)
but power to avoid *a priori*.  Because, *a posteriori* all we have is a close and
shut case.  But, if the person has no power to avoid the act a priori, then there is
likewise no liability -- this is a general principle and one which may illuminate this
discussion accross the global Internet with so many jurisdictions and that is why
I venture to explain it.

Of course, the above comparison between sperm and blood samples already
dicloses a basic difference between both in terms of degree of non-repudiation
which also links to power, in that the second depends on a much lesser degree on
that person's power to prevent it -- a simple needle will do, in  a casual and even
unperceived encounter (a  brief pain).  For example, a sperm stain on a dress
can be much more devastating as evidence (as recent events showed) than a
blood stain, which may even provide no evidence at all (seen the last episode
of  "The Practice"? OJ?)

> Increasing strength of evidence does *not*
> lead to diminishing liability.

I counter-exemplify above; but not in regard to a generic "strength of evidence" but
"effectiveness of power to prevent" -- which however relates to strength of evidence
in regard to non-repudiation.  Again -- more power to prevent an act, more
liability towards non-repudiation of the act.  And, I cannot be liable for an act
which I was utterly powerless to avoid; for example, password authentication
in an open channel using my password (but which anyone could have sniffed
in a previous connection).

And, BTW, this is the reason why S/MIME signatures intuitively carry very
little (if any) weight for non-repudiation -- because the verifier cannot prove if
the message was understood before being signed, if it was the keyholder
that really did sign it, if the keyholder willfully wanted to sign it, etc. I.e., since
the S/MIME protocol denies power for the keyholder to effectively prevent
(ie, a priori) a S/MIME signed message to be sent using his key, then it cannot ask
for liability from the same.

>  There is no challenge-response in this
> scenario, yet the liability remains.  Certain company execs might wish
> to repudiate their email, but digital signatures on the messages would
> not make it easier for them to do so, nor absolve them of liability for
> the content of the messages.

A large danger exists, if the executives do not have the power to avoid
the act and if every 'whiff' is cast in stone in equal depth. In fact, what
you mention is one more reason not to use such  PKI protocols.

> If you are attempting to communicate an idea, your choice
> of terminology is an impediment to understanding, not an aid.

Maybe, but then just because I am using a terminology which is consistent
within a larger community -- not a tongue.  The present confusing use of
non-repudiation in our own circles, and even "true non-repudiation" as I
could read in a security company's press-release describing a PKI in a
US State contract, is what we should all avoid since such choice of terminology
is not only an impediment but also a false statement.  And, reading this list's
exchange, just aids confusion.

Cheers,

Ed Gerck



Received: from po1.bbn.com (PO1.BBN.COM [192.1.50.38]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id PAA13477 for <[e-mail]>; Mon, 2 Aug 1999 15:39:47 -0700 (PDT)
Received: from [128.89.0.110] (COSMEC.BBN.COM [128.89.0.110]) by po1.bbn.com (8.9.1/8.9.1) with ESMTP id SAA24311; Mon, 2 Aug 1999 18:42:35 -0400 (EDT)
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
X-Sender: [e-mail]
Message-Id: <v04020a08b3cbcd2d2924@[128.89.0.110]>
In-Reply-To: <000001bedd35$d45b21e0$[e-mail]>
References: <[e-mail]>
Date: Mon, 2 Aug 1999 18:36:00 -0400
To: "Peter Williams" <[e-mail]>
From: Stephen Kent <[e-mail]>
Subject: RE: Common misconceptions
Cc: <[e-mail]>

Peter,

I agree with David on this one.   VeriSign may choose to employ an approach
to CRL distribution, not mandated by standards, but that is not fundamental
to NR in general, nor for S/MIME in particular.  If anything, this is a
good example of why one should not confuse deployed products/services with
fundamental requirements nor with standards.

Steve


Received: from ns1.dmz.valicert.com (ns1.valicert.com [63.65.221.10]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id PAA12921 for <[e-mail]>; Mon, 2 Aug 1999 15:04:45 -0700 (PDT)
Received: from ns1.valicert.com (corporate-gw.valicert.com [63.65.221.2]) by ns1.dmz.valicert.com (8.9.2/8.9.2) with ESMTP id PAA20913; Mon, 2 Aug 1999 15:05:20 -0700 (PDT)
Received: from rsalaptop (dhcp-3-230.engineering.valicert.com [192.168.3.230]) by ns1.valicert.com (8.9.2/8.9.2) with SMTP id PAA08754; Mon, 2 Aug 1999 15:06:51 -0700 (PDT)
From: "Peter Williams" <[e-mail]>
To: "David P. Kemp" <[e-mail]>, <[e-mail]>
Subject: RE: Common misconceptions
Date: Mon, 2 Aug 1999 15:24:47 -0700
Message-ID: <000001bedd35$d45b21e0$[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 8.5, Build 4.71.2173.0
Importance: Normal
In-Reply-To: <[e-mail]>
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.0810.800

VeriSign claims to be the de-facto standard
for PKI with S/MIME. American ego aside, you 
obtain VeriSign's validity status on a certificate 
only following a user->CA challenge-response. 
Obtaining a  CRL also requires a handshake - in 
which one accepts the legal conditions of use.

These handshakes bind users/parties to
the governing policy (VeriSign's dispute
resolution rules) which control if
a proof of origin with non-repudiation
service has actually been provided to
nominated parties, or not.

Ed may not have been accurate in
terms of the standards statutes; he was
non-the-less right in today's common
commercial practice.

> -----Original Message-----
> From: David P. Kemp [mailto:[e-mail]]
> Sent: Monday, August 02, 1999 2:07 PM
> To: [e-mail]
> Subject: Re: Common misconceptions
> 
> 
> 
> > Yes, and following such notion that challenge-response protocols are
> > not needed for "non-repudiation" in secure protocols/transmissions
> > in general you will arrive at the concusion that one would not need
> > to do even a challenge-response query on the CRL before you rely on
> > the authentication --  though such is demanded by S/MIME.
> 
> 
> Ed,
> 
> I'm not aware of any S/MIME requirements for protocol interactivity.
> The information flow in a PKI is all designed to be one-way: certs are
> broadcast by the CA, CRLs are broadcast by the CA, and trusted time
> is broadcast (over GBS) by NIST :-).
> 
> Using the term "challenge-response" to describe a policy- or legal-
> driven obligation of a certificate subject to report key compromises
> or other status changes to the CA (and I can't tell whether you've
> used it for that purpose) would not be accurate.  The information may
> flow from the subject to the CA, but it is not in response to any
> perceptible challenge.
> 
> Using it to describe the interaction between a user and his
> private-key-wielding machine (view document, pop up dialog, click OK)
> is not completely inaccurate, but that has nothing to do with
> interactions between the subject and other parties in a PKI.  Even in
> the context of local operations, using the term "challenge-response" to
> describe an interaction with a dialog box is mostly inaccurate: in
> order to be effective, a response must depend on the challenge, not
> be a simple reflexive action.
> 
> 
> > 2. the absence of a legal challenge-response mechanism will always
> > indicate absence of legal non-repudiation because power is the
> > counterpart of liability in law -- if the user has no power to deny
> > authentication then the user has no liability derived from it;
> 
> This statement is beyond my comprehension.  If a user is positively
> identified (by eyewitnesses, DNA evidence, and his smartcard's
> signature in a POS terminal) at a crime scene, he has little power to
> repudiate his involvement.  Increasing strength of evidence does *not*
> lead to diminishing liability.  There is no challenge-response in this
> scenario, yet the liability remains.  Certain company execs might wish
> to repudiate their email, but digital signatures on the messages would
> not make it easier for them to do so, nor absolve them of liability for
> the content of the messages.
> 
> If you are attempting to communicate an idea, your choice
> of terminology is an impediment to understanding, not an aid.
> 
> 
> 


Received: from csmes.ncsl.nist.gov (csmes.ncsl.nist.gov [129.6.54.2]) by mail.proper.com (8.9.3/8.9.3) with SMTP id OAA12055 for <[e-mail]>; Mon, 2 Aug 1999 14:08:36 -0700 (PDT)
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 RAA11124; Mon, 2 Aug 1999 17:11:52 -0400
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32)
Date: Mon, 02 Aug 1999 17:11:52 -0400
To: [e-mail], [e-mail]
From: Tim Polk <[e-mail]>
Subject: Requesting WG Last Call for ECDSA Profile
Cc: [e-mail]
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"

Warwick & Steve,

I am requesting WG Last Call for the PKIX ECDSA profile.  I am not aware of
any outstanding issues, and the corresponding ANSI document is complete and
stable.

Thanks,

Tim Polk


Received: from stingray.missi.ncsc.mil (stingray.missi.ncsc.mil [144.51.50.20]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id OAA11888 for <[e-mail]>; Mon, 2 Aug 1999 14:06:03 -0700 (PDT)
Received: from stingray.missi.ncsc.mil (root@localhost) by stingray.missi.ncsc.mil with ESMTP id RAA04382 for <[e-mail]>; Mon, 2 Aug 1999 17:08:50 -0400 (EDT)
Received: from missi.ncsc.mil (depot.missi.ncsc.mil [144.51.60.1]) by stingray.missi.ncsc.mil with ESMTP id RAA04378 for <[e-mail]>; Mon, 2 Aug 1999 17:08:50 -0400 (EDT)
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 RAA29730 for <[e-mail]>; Mon, 2 Aug 1999 17:08:12 -0400 (EDT)
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 RAA19146 for <[e-mail]>; Mon, 2 Aug 1999 17:07:27 -0400 (EDT)
Message-Id: <[e-mail]>
Date: Mon, 2 Aug 1999 17:07:27 -0400 (EDT)
From: "David P. Kemp" <[e-mail]>
Reply-To: "David P. Kemp" <[e-mail]>
Subject: Re: Common misconceptions
To: [e-mail]
MIME-Version: 1.0
Content-Type: TEXT/plain; charset=us-ascii
Content-MD5: xSenRj1OHdihXNwvYX1AQA==
X-Mailer: dtmail 1.3.0 CDE Version 1.3 SunOS 5.7 sun4u sparc

> Yes, and following such notion that challenge-response protocols are
> not needed for "non-repudiation" in secure protocols/transmissions
> in general you will arrive at the concusion that one would not need
> to do even a challenge-response query on the CRL before you rely on
> the authentication --  though such is demanded by S/MIME.


Ed,

I'm not aware of any S/MIME requirements for protocol interactivity.
The information flow in a PKI is all designed to be one-way: certs are
broadcast by the CA, CRLs are broadcast by the CA, and trusted time
is broadcast (over GBS) by NIST :-).

Using the term "challenge-response" to describe a policy- or legal-
driven obligation of a certificate subject to report key compromises
or other status changes to the CA (and I can't tell whether you've
used it for that purpose) would not be accurate.  The information may
flow from the subject to the CA, but it is not in response to any
perceptible challenge.

Using it to describe the interaction between a user and his
private-key-wielding machine (view document, pop up dialog, click OK)
is not completely inaccurate, but that has nothing to do with
interactions between the subject and other parties in a PKI.  Even in
the context of local operations, using the term "challenge-response" to
describe an interaction with a dialog box is mostly inaccurate: in
order to be effective, a response must depend on the challenge, not
be a simple reflexive action.


> 2. the absence of a legal challenge-response mechanism will always
> indicate absence of legal non-repudiation because power is the
> counterpart of liability in law -- if the user has no power to deny
> authentication then the user has no liability derived from it;

This statement is beyond my comprehension.  If a user is positively
identified (by eyewitnesses, DNA evidence, and his smartcard's
signature in a POS terminal) at a crime scene, he has little power to
repudiate his involvement.  Increasing strength of evidence does *not*
lead to diminishing liability.  There is no challenge-response in this
scenario, yet the liability remains.  Certain company execs might wish
to repudiate their email, but digital signatures on the messages would
not make it easier for them to do so, nor absolve them of liability for
the content of the messages.

If you are attempting to communicate an idea, your choice
of terminology is an impediment to understanding, not an aid.



Received: from tomcat.sac.verio.net ([e-mail] [209.162.64.15]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id LAA10740 for <[e-mail]>; Mon, 2 Aug 1999 11:57:48 -0700 (PDT)
Received: from nma.com (pm09-07.sac.verio.net [209.162.65.120]) by tomcat.sac.verio.net (8.9.1a/8.9.1) with ESMTP id MAA01674; Mon, 2 Aug 1999 12:00:34 -0700 (PDT)
Message-ID: <[e-mail]>
Date: Mon, 02 Aug 1999 12:00:27 -0700
From: Ed Gerck <[e-mail]>
X-Mailer: Mozilla 4.51 [en] (Win98; I)
X-Accept-Language: en
MIME-Version: 1.0
To: Daniel Finkelstein <[e-mail]>
CC: "'[e-mail]'" <[e-mail]>
Subject: Re: Common misconceptions, was Re: KISS for PKIX. (Was: RE:ASN.1vs  XML  (used to be RE: I-D ACTION :draft-ietf-pkix-scvp- 00.txt))
References: <v04020a02b3b3e54bc992@[128.33.238.108]> <v04020a00b3b56b6383a7@[128.33.238.45]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Daniel Finkelstein wrote:

> Russ Housley wrote:
>
>> Challenge-response protocols are not needed for non-repudiation.  Such a
>> protocol might be used, but it is not required.  For example, a digitally
>> signed S/MIME message might provide non-repudiation and no
>> challenge-response protocol is involved.
>
> Yes, you're right. I had to think of a few scenarios and paths before I believed it, but after consideration I see that you could extend your idea further to include secure protocols/transmissions in general.
>
>
> Legally speaking (and I hate to do it) this reduces the computing
>  power required for non-repudiation actions significantly. Much of
>  the path can be clear, if not all.
>

Yes, and following such notion that challenge-response protocols are not needed for
"non-repudiation" in secure protocols/transmissions  in general you will arrive at the
concusion that one would not need to do even a challenge-response query on the CRL
before you rely on the authentication --  though such is demanded by S/MIME.

In fact, you seem happy to just  assume that  everything is correct, one-shot wise as given
by math.   However, math does not provide non-repudiation by itself and that is why I
call this a  common misconception, and an unfortunate one because it confuses not
only the public but protocol implementers as well.

As I mentioned before (now in summary form):

1. legal non-repudiation is a matter of evidences and respective trusted contexts
as defined by law (eg, cerimony, self-willingness to sign, understanding of what
was signed, etc.) -- not just a matter of one "fact" such as a cryptographic signature;

2. the absence of a legal challenge-response mechanism will always indicate absence
of legal non-repudiation because power is the counterpart of liability in law -- if the
user has no power to deny authentication then the user has no liability derived from
it;

3. such challenge-response mechanism does not have to be cryptographic in order
to attain legal non-repudiation properties  -- eg., can be provided by a witness, by a
log with a mutually contracted third-party (notary, time-stamping agent, etc.), etc.;

4. the freshness of such challenge-response may vary but there is a time limit beyond
which the probability of error becomes unaceptable as a function of other operational
parameters (eg, a signature muster in a bank can be "fresh" for one year or more as
a function of warranty policies and insurance coverage, a CRL can be "fresh" within
the hour, etc.);

5. other types of non-repudiation exist -- eg, policy non-repudiation.  This applies
well when non-repudiation is applied without any implied liability or deniable rights,
which (of course) carries not into legal non-repudiation. For example, an ISP that
asks a user to change the password because it has detected double use (which may
indicate a password compromise by a hacker) is applying its security policy and
is neither causing any harm to the user's rights nor implying user liability.  Thus, it is
legal to do so, even though the ISP considers the password collision non-repudiable
by the user ("I did not give out my password") -- since the ISP relies on its own logs,
which it uses in internal challenge-response.

6. even though non-legal non-repudiation does not need legal challenge-response you
will find that "X non-repudiation" in general depends on "X challenge-response": "legal
non-repudiation" depends on "legal challenge-response"; "policy non-repudiation
depends on "policy challenge-response"; etc.

BTW, list discussions also show that non-repudiation is a matter of challenge-response ;-)

Cheers,

Ed Gerck



Received: from pub.siac.com (pub.siac.com [162.69.5.194]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id KAA09573 for <[e-mail]>; Mon, 2 Aug 1999 10:15:53 -0700 (PDT)
Received: from bigmouth.siac.com(162.69.5.8) by pub.siac.com via smap (4.1) id xmatp4486; Mon, 2 Aug 99 13:22:51 -0400
Received: from siac.com (localhost [127.0.0.1]) by charley.wisdom.siac.com (980427.SGI.8.8.8/980728.SGI.AUTOCF) via ESMTP id IAA44087 for <[e-mail]>; Mon, 2 Aug 1999 08:57:23 -0400 (EDT)
Sender: [e-mail]
Message-ID: <[e-mail]>
Date: Mon, 02 Aug 1999 08:57:22 -0400
From: Daniel Finkelstein <[e-mail]>
Organization: Securities Industry Automation Corporation
X-Mailer: Mozilla 4.61C-SGI [en] (X11; U; IRIX 6.5 IP32)
X-Accept-Language: en
MIME-Version: 1.0
To: "'[e-mail]'" <[e-mail]>
Subject: Re: Common misconceptions, was Re: KISS for PKIX. (Was: RE:ASN.1vs  XML  (used to be RE: I-D ACTION :draft-ietf-pkix-scvp- 00.txt))
References: <v04020a02b3b3e54bc992@[128.33.238.108]> <v04020a00b3b56b6383a7@[128.33.238.45]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
Content-Type: multipart/alternative; boundary="------------61F841AD078E727786FE5002"

--------------61F841AD078E727786FE5002
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Russ Housley wrote:

> Challenge-response protocols are not needed for non-repudiation.  Such a
> protocol might be used, but it is not required.  For example, a digitally
> signed S/MIME message might provide non-repudiation and no
> challenge-response protocol is involved.

Yes, you're right. I had to think of a few scenarios and paths before I
believed it, but after consideration I see that you could extend your idea
further to include secure protocols/transmissions in general.

Legally speaking (and I hate to do it) this reduces the computing power
required for non-repudiation actions significantly. Much of the path can be
clear, if not all.

--
Daniel Alex Finkelstein
New Technologies
phone   [phone]
pager   917-427-1630
fax     [phone]
Securities Industry Automation Corporation



--------------61F841AD078E727786FE5002
Content-Type: text/html; charset=us-ascii
Content-Transfer-Encoding: 7bit

<!doctype html public "-//w3c//dtd html 4.0 transitional//en">
<html>
Russ Housley wrote:
<blockquote TYPE=CITE>Challenge-response protocols are not needed for non-repudiation.&nbsp;
Such a
<br>protocol might be used, but it is not required.&nbsp; For example,
a digitally
<br>signed S/MIME message might provide non-repudiation and no
<br>challenge-response protocol is involved.</blockquote>
Yes, you're right. I had to think of a few scenarios and paths before I
believed it, but after consideration I see that you could extend your idea
further to include secure protocols/transmissions in general.
<p>Legally speaking (and I hate to do it) this reduces the computing power
required for non-repudiation actions significantly. Much of the path can
be clear, if not all.
<pre>--&nbsp;
Daniel Alex Finkelstein
New Technologies
phone&nbsp;&nbsp; 212-383-2951
pager&nbsp;&nbsp; 917-427-1630
fax&nbsp;&nbsp;&nbsp;&nbsp; 212-383-3289
Securities Industry Automation Corporation</pre>
&nbsp;</html>

--------------61F841AD078E727786FE5002--



Received: from gnasher.sol.co.uk (gnasher.sol.co.uk [194.247.64.2]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id EAA05591 for <[e-mail]>; Mon, 2 Aug 1999 04:29:38 -0700 (PDT)
Received: from npwork2 (e2c9p10.scotland.net [148.176.238.10]) by gnasher.sol.co.uk (8.8.5/8.8.5) with SMTP id MAA04987; Mon, 2 Aug 1999 12:32:26 +0100 (BST)
From: "Nick Pope" <[e-mail]>
To: <[e-mail]>
Cc: "DENIS PINKAS" <[e-mail]>
Subject: Comments on PKIX Time Stamp Protocol
Date: Mon, 2 Aug 1999 12:35:48 +0100
Message-ID: <001501bedcdb$2af91cb0$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
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3
Importance: Normal

Comments on PKIX Time Stamp Protocol
draft-ietf-pkix-time-stamp-02.txt

I have been working on an ETSI electronic signature standard which makes use
of time-stamping and as a result would like to offer the a few comments on
the document:

1) Section 2.4 mandates that the Hash Algorithm is provided by the client
and has to be approved by the server.

This protocol can't be used if the client has its own, perfectly good,
hashing algorithm which isn't known to the time-stamping server.

The current text already only states that the  hashedMessage field "SHOULD
contain the hash", but the length of this field "MUST match the length of
the hash value for that algorithm".

The current protocol encourages the client to lie about the hash algorithm
employed !

I therefore suggest that the definition of MessageImprint is changed as
follows:

" MessageImprint ::= SEQUENCE  {
     hashAlgorithm                AlgorithmIdentifier  OPTIONAL,
     hashedMessage                OCTET STRING  }

  The hash algorithm employed to to create the hashedMessage field SHOULD
  be a strong hash algorithm.  That means that it SHOULD be one-way and
  collision resistant.  If the hashAlgorithm is present then the Time
  stamp Authority MUST check whether or not the given hash algorithm is
  known to be "sufficient" (based on the current state of knowledge in
  cryptanalysis and the current state of the art in computational
  resources, for
  example).  The TSA may refuse to time stamp hashedMessage without an
  indication of the hashAlgorithm depending on the security policy.

  The hashedMessage field SHOULD contain the hash of the datum to be
  time stamped.  The hash is represented as an OCTET STRING.  If  the
  hashAlgorithm field is present the length of the hashedMessage field
  MUST match the length of the hash value for that algorithm (e.g.
  20 bytes for SHA-1 or 16 bytes for MD-5). "

-------------------------------

2) In Appendix A "Storage of Data and Token" it states "the contentType is
signedData and contentInfo is Data, which contains the datum associated with
the time stamp token."  It also goes on to describe a signed attribute to
carry the timestamptoken.

Surely if the Content Type is signedData the the contentInfo must contain
the CMS SignedData structure.  Also, the SignedData structure is needed to
carry signed attributes.

Thus, I presume that Appendix A should read:

  "A time stamp token is meaningless without its associated data. The
  following method can be used to store data and token together securely
  as a PKCS #7 SignedData object as described in [CMS].

  The contentType is id-signedData and contentInfo is signedData.  Within
  the signedData eContentType is id-data and the eContent contains the
  datum associated with the time stamp token.  The SignedData object is
  signed by the person storing the data and token.

 ... (unchanged) ...

  id-aa-timeStampToken     OBJECT IDENTIFIER ::= { id-aa 13 }
  id-aa   OBJECT IDENTIFIER ::= { id-smime 2 }

  The hashMessage value in the MessageImprint is calculated over the
  datum as held in value of eContent within the signedData."

-------------------------------


3) Finally in 2.4, Page 6:

id-ct    OBJECT IDENTIFIER ::= { id-smime 1 }
id-smime OBJECT IDENTIFIER ::= { iso(1) member-body(2)
            us(840) rsadsi(113549) pkcs(1) pkcs-9(9) 16 }

is repeated.




Received: from mail-ewr-3.pilot.net (mail-ewr-3.pilot.net [206.98.230.17]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id AAA01347 for <[e-mail]>; Mon, 2 Aug 1999 00:59:50 -0700 (PDT)
From: [e-mail]
Received: from mailgw.firstdata.com ([204.48.27.166]) by mail-ewr-3.pilot.net (Pilot/8.8.8) with ESMTP id EAA13337; Mon, 2 Aug 1999 04:02:40 -0400 (EDT)
Received: from lnsunr02.firstdata.com (lnsunr02.firstdata.com [192.168.247.16]) by mailgw.firstdata.com with SMTP id EAA15424; Mon, 2 Aug 1999 04:02:35 -0400 (EDT)
Received: by lnsunr02.firstdata.com(Lotus SMTP MTA v4.6.4  (830.2 3-23-1999))  id 852567C1.002BD636 ; Mon, 2 Aug 1999 03:58:48 -0400
X-Lotus-FromDomain: FDC
To: [e-mail]
cc: Russ Housley <[e-mail]>, Ed Gerck <[e-mail]>, "'[e-mail]'" <[e-mail]>
Message-ID: <[e-mail]>
Date: Mon, 2 Aug 1999 01:00:51 -0700
Subject: Re: Common misconceptions,	 was Re: KISS for PKIX. (Was: RE: ASN  .1vs XML (used to be RE:	 I-D ACTION :draft-ietf-pkix-scvp- 00.txt ))
Mime-Version: 1.0
Content-type: text/plain; charset=us-ascii
Content-Disposition: inline

note that while software trojan horse can result in signing of incorrect data on
payment transactions .... that exploit is significantly smaller than current
situation where knowing the account number and a trivial number of other details
allows arbritrary generation of transactions from scratch. no trojans &
non-repudiation is better than trojans & repudiation ... but either one is a
great deal better than existing situation.




Received: from honcho.austin.dascom.com (email.austin.dascom.com [206.196.73.5]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id TAA15612 for <[e-mail]>; Sun, 1 Aug 1999 19:10:02 -0700 (PDT)
Received: from austin.dascom.com by honcho.austin.dascom.com (8.8.8/SMI-SVR4) id VAA09719; Sun, 1 Aug 1999 21:09:49 -0500 (CDT)
Received: from shaggy by austin.dascom.com (8.8.8/SMI-SVR4) id VAA01284; Sun, 1 Aug 1999 21:09:48 -0500 (CDT)
Message-ID: <009401bedc8c$d860b060$[e-mail]>
Reply-To: "Bob Blakley" <[e-mail]>
From: "Bob Blakley" <[e-mail]>
To: <[e-mail]>, "Bill Doster" <[e-mail]>
Subject: Re: Ptr to doc on "how end-entity authenticates cert_req to CA"
Date: Sun, 1 Aug 1999 21:15:08 -0500
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="----=_NextPart_000_0091_01BEDC62.EF25F320"
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

This is a multi-part message in MIME format.

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

Bill,

This isn't specified; it is left up to the CA service provider to determine
and state in his certification practice statement.
It's an operational trust parameter which might be handled differently by
different providers whose
clients use the certificates for tasks of varying degrees of sensitivity.

--bob

Bob Blakley ([e-mail])
Chief Scientist, Dascom
-----Original Message-----
From: Bill Doster <[e-mail]>
To: [e-mail] <[e-mail]>
Date: Thursday, July 22, 1999 4:54 PM
Subject: Ptr to doc on "how end-entity authenticates cert_req to CA"


>After looking through all the IETF PKIX drafts, I'm still in the dark as to
what information is provided by the end-entity to authenticate itself as the
entity named in the cert req
>(as opposed to demonstrating possession of the cert's associated private
key).
>
>Perhaps my question is malformed to begin with?
>
>Pointers anyone?
>
>

------=_NextPart_000_0091_01BEDC62.EF25F320
Content-Type: text/x-vcard;
	name="Bob Blakley.vcf"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment;
	filename="Bob Blakley.vcf"

BEGIN:VCARD
VERSION:2.1
N:Blakley;Bob
FN:Bob Blakley
ORG:Dascom
TITLE:Chief Scientist
TEL;WORK;VOICE:[phone] x 5012
TEL;WORK;FAX:[phone]
ADR;WORK;ENCODING=3DQUOTED-PRINTABLE:;;Plaza Balcones=3D0D=3D0A5515 =
Balcones Drive;Austin;TX;78731;USA
LABEL;WORK;ENCODING=3DQUOTED-PRINTABLE:Plaza Balcones=3D0D=3D0A5515 =
Balcones Drive=3D0D=3D0AAustin, TX 78731=3D0D=3D0AUSA
URL:
URL:http://www.dascom.com
EMAIL;PREF;INTERNET:[e-mail]
REV:19990802T021508Z
END:VCARD

------=_NextPart_000_0091_01BEDC62.EF25F320--