Request for IESG consideration: DPD/DPV Requirements

[Tim Polk <[e-mail]>]

Jeff & Steve,

The PKIX working group has achieved rough consensus and completed WG Last 
Call 
for 
http://www.ietf.org/internet-drafts/draft-ietf-pkix-dpv-dpd-req-05.txt, 
"Delegated Path Validation and Delegated Path Discovery Protocol 
Requirements".  Please consider this specification for submission to the 
IESG for advancement to RFC status.

We believe this specification would be most appropriate as an informational 
track RFC.

Thanks,

Tim Polk







Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g516BSR19643 for ietf-pkix-bks; Fri, 31 May 2002 23:11:28 -0700 (PDT)
Received: from mailhost2.auckland.ac.nz (mailhost2.auckland.ac.nz [130.216.191.4]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g516BMg19622 for <[e-mail]>; Fri, 31 May 2002 23:11:26 -0700 (PDT)
Received: from mailhost-mp.auckland.ac.nz (IDENT:[e-mail] [130.216.191.61]) by mailhost2.auckland.ac.nz (8.9.2/8.9.2/8.9.2-ua) with ESMTP id SAA17490; Sat, 1 Jun 2002 18:11:24 +1200 (NZST)
Received: from hermes.cs.auckland.ac.nz (hermes.cs.auckland.ac.nz [130.216.35.151]) by mailhost-mp.auckland.ac.nz (Mirapoint Messaging Server MOS 3.1.0.58-GA) with ESMTP id ADY05558; Sat, 1 Jun 2002 18:11:24 +1200 (NZST)
Received: from ruru.cs.auckland.ac.nz (ruru-nfs.cs.auckland.ac.nz [130.216.35.12]) by hermes.cs.auckland.ac.nz (8.12.3/8.12.3) with ESMTP id g516BOAC014045; Sat, 1 Jun 2002 18:11:24 +1200
Received: (from pgut001@localhost) by ruru.cs.auckland.ac.nz (8.9.3/8.8.6/cs-slave) id SAA394110; Sat, 1 Jun 2002 18:11:21 +1200 (NZST) (sender [e-mail])
Date: Sat, 1 Jun 2002 18:11:21 +1200 (NZST)
Message-ID: <[e-mail]>
From: [e-mail] (Peter Gutmann)
To: [e-mail], [e-mail]
Subject: Re: ASN.1 syntax for OCSP nonce value?
Cc: [e-mail]
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Geoff Elgey <[e-mail]> writes:

>This leads to the following: treating the V part of the nonce TLV as having
>some specific syntax is clearly implementation specific. Any OCSPRequest /
>OCSPResponse value inspected by third-party tools (such as Peter's "dumpasn1"
>tool) therefore MUST treat the nonce as an untyped blob.

The problem with this is that it's then in violation of all other definitions
of EXTENSION in any other standard (X.509, RFC 2459/3280, etc etc).  It's an
error in the OCSP spec which needs to be fixed.  Bride-of-2560 should include a
warning to implementors to say that older implementations may get it wrong (in
terms of what X.509/2459/3280 define) and that implementations should therefore
be able to handle either alternative, but what's actually used should be
consistent with the accepted definition.  Otherwise there's little point in
going through draft standards and whatnot if errors aren't corrected.

Peter.


Received: by above.proper.com (8.11.6/8.11.3) id g4VLofn10553 for ietf-pkix-bks; Fri, 31 May 2002 14:50:41 -0700 (PDT)
Received: from email.nist.gov (email.nist.gov [129.6.2.7]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g4VLodg10549 for <[e-mail]>; Fri, 31 May 2002 14:50:39 -0700 (PDT)
Received: from st25 (st25.ncsl.nist.gov [129.6.54.67]) by email.nist.gov (8.12.2/8.12.2) with ESMTP id g4VLodeh015374; Fri, 31 May 2002 17:50:39 -0400 (EDT)
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58 
Date: Fri, 31 May 2002 17:48:21 -0400
To: [e-mail]
From: Tim Polk <[e-mail]>
Subject: WG Last Call CLOSED: DPD/DPV Requirements
Cc: [e-mail]
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Folks,

As there has been no discussion on the list regarding the DPD/DPV 
requirements document I have forwarded it to Jeff and Steve.    We have 
obsessed long enough, and there will be lots of opportunities to grind your 
favorite axe on the protocol specs.

Tim Polk




Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g4VLl8610470 for ietf-pkix-bks; Fri, 31 May 2002 14:47:08 -0700 (PDT)
Received: from email.nist.gov (email.nist.gov [129.6.2.7]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g4VLl6g10466 for <[e-mail]>; Fri, 31 May 2002 14:47:06 -0700 (PDT)
Received: from st25 (st25.ncsl.nist.gov [129.6.54.67]) by email.nist.gov (8.12.2/8.12.2) with ESMTP id g4VLl5eh012050; Fri, 31 May 2002 17:47:06 -0400 (EDT)
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58 
Date: Fri, 31 May 2002 17:44:39 -0400
To: [e-mail], [e-mail]
From: Tim Polk <[e-mail]>
Subject: Request for IESG consideration: DPD/DPV Requirements
Cc: [e-mail], [e-mail]
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Jeff & Steve,

The PKIX working group has achieved rough consensus and completed WG Last 
Call 
for 
http://www.ietf.org/internet-drafts/draft-ietf-pkix-dpv-dpd-req-05.txt, 
"Delegated Path Validation and Delegated Path Discovery Protocol 
Requirements".  Please consider this specification for submission to the 
IESG for advancement to RFC status.

We believe this specification would be most appropriate as an informational 
track RFC.

Thanks,

Tim Polk






Received: by above.proper.com (8.11.6/8.11.3) id g4VLGsG09892 for ietf-pkix-bks; Fri, 31 May 2002 14:16:54 -0700 (PDT)
Received: from e1.ny.us.ibm.com (e1.ny.us.ibm.com [32.97.182.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g4VLGqg09888 for <[e-mail]>; Fri, 31 May 2002 14:16:52 -0700 (PDT)
Received: from northrelay02.pok.ibm.com (northrelay02.pok.ibm.com [9.56.224.150]) by e1.ny.us.ibm.com (8.12.2/8.12.2) with ESMTP id g4VLGmg5222822; Fri, 31 May 2002 17:16:48 -0400
Received: from d01ml062.pok.ibm.com (d01ml062.pok.ibm.com [9.117.250.163]) by northrelay02.pok.ibm.com (8.11.1m3/NCO/VER6.1) with ESMTP id g4VLGc9137746; Fri, 31 May 2002 17:16:38 -0400
Importance: Normal
Sensitivity: 
Subject: Re: draft-ietf-pkix-warranty-extn-01
To: Juergen Brauckmann <[e-mail]>
Cc: [e-mail], Pkix <[e-mail]>
X-Mailer: Lotus Notes Release 5.0.7  March 21, 2001
Message-ID: <[e-mail]>
From: "Tom Gindin" <[e-mail]>
Date: Fri, 31 May 2002 17:16:42 -0400
X-MIMETrack: Serialize by Router on D01ML062/01/M/IBM(Release 5.0.10 |March 28, 2002) at 05/31/2002 05:16:47 PM
MIME-Version: 1.0
Content-type: text/plain; charset=us-ascii
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

      Juergen:

      This depends on the interpretation of the text.  There are two ways
to resolve this.  Either the amtExp10 field should have a different range
(perhaps (-6..MAX)) or amtExp10 is to be interpreted as a resolution
exponent only, so the actual value is amount / 10**amtExp10.  The example
points towards the second option.
      If the second of these options is to be taken, the wording must
change.  I suggest adding after the sentence defining amtExp10 an extra
sentence as follows: "The actual monetary value in the named currency unit,
when amtExp10 is present, is amount divided by 10 to the (amtExp10) power".
Anyway, why is this value an exponent base 10?  Not that long ago, one of
the world's principal hard currencies had two minor units, 1/20 and 1/240,
and I'm not sure there aren't some similar cases still around.  It could be
called minorUnitDivisor and the value would just be amount /
minorUnitDivisor.

            Tom Gindin


Juergen Brauckmann <[e-mail]>@mail.imc.org on 05/31/2002
09:15:27 AM

Sent by:    [e-mail]


To:    [e-mail]
cc:    Pkix <[e-mail]>
Subject:    Re: draft-ietf-pkix-warranty-extn-01



Hi.

How should extendedWarranty be used? Perhaps you can give an example?

Format of the currency field in CurrencyAmount: There is at least one
standard ("ETSI qualified certificate profile") I know of which
recommends use of a PrintableString and the alphabetic code from ISO
4217.

The example in chapter 2.2 is wrong:
 "$48,525.50 (in US dollars) is represented as:
     currency =      840
     amount   =  4852550
     amtExp10 =        2"

That's wrong. 4852550 * (10 ** 2) is 485,255,000. I guess you wanted to
say that amtExp10 is -2, but you cannot do that because it has to be >=
0.

Regards,
   Juergen







Received: by above.proper.com (8.11.6/8.11.3) id g4VFDqP24006 for ietf-pkix-bks; Fri, 31 May 2002 08:13:52 -0700 (PDT)
Received: from edelweb.fr (edelweb.fr [212.234.46.16]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g4VFDng24001 for <[e-mail]>; Fri, 31 May 2002 08:13:49 -0700 (PDT)
Received: from champagne.edelweb.fr (localhost.edelweb.fr [127.0.0.1]) by edelweb.fr with ESMTP id RAA21903; Fri, 31 May 2002 17:13:34 +0200 (MET DST)
Received: from champagne.edelweb.fr (champagne.edelweb.fr [193.51.14.161]) by edelweb.fr (nospam/1.5); Fri, 31 May 2002 17:13:34 +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 RAA13547; Fri, 31 May 2002 17:13:32 +0200 (MET DST)
From: Peter Sylvester <[e-mail]>
Received: (sylvest@localhost) by emeriau.edelweb.fr (8.7.6/8.6.6) id RAA25171; Fri, 31 May 2002 17:13:31 +0200 (MET DST)
Date: Fri, 31 May 2002 17:13:31 +0200 (MET DST)
Message-Id: <[e-mail]>
To: [e-mail], [e-mail]
Subject: Re: ASN.1 syntax for OCSP nonce value?
Cc: [e-mail]
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

> G'day,
> 
> Peter Gutmann wrote:
> > (Some implementation guidance as to what's really supposed to be encapsulated
> >  in the OCTET STRING would be useful for bride-of-2560).
> 
> I think the rationale for the nonce value as defined in RFC 2560 is as 
> follows:

Geoff,

I rather believe that the omission is not voluntary, a pure error,
not detected during the fast review process like for example an OID 
that was initially defined in another PKIX draft....

CLIENTS that create a blob as the value can also be considered as simply 
wrong; or, there cannot be a conformant implementation because there is 
no complete definition (i.e., a missing piece ASN1 syntax). 

It was not possible to detect this automatically with some ASN1 tool as it 
would be possible in the new 2002 asn1 by specifying something like 

Extension         ::=   SEQUENCE {
    extnId            EXTENSION.&id ({ExtensionSet}),
    critical          BOOLEAN DEFAULT FALSE,
    extnValue         OCTET STRING (
         CONTAINING EXTENSION.&ExtnType({ExtensionSet}{@extnId})
    }

( One can also argue that the whole concept of have an encapsulated
  piece of syntax in an octet string is a horrible and useless non-sense 
  IF in all cases the content is supposed to be correctly encoded
  but this is really almost 'talking about cars' (to avoid usage
  of 'religious'). )

Now one can strt and discuss whether one want to find a ASN1 definition
that matches the current client implementations or whether it seems
more appropriate to make a syntax which is clean with 3280. 

> If the nonce extension was being introduced now, I'd recommend that it 
> be defined as having an INTEGER syntax.

I'd would support introducing this, and allowing client to generate
invalid encodings until some not so far time in the future, and or
indicate that servers may want not to decode all extensions, etc.

Technically, fixing a client doesn't seem a big issue to me, 
installing it in a real environment, ... hm ... 

Somehow this reminds me to to SMIME encapssulated content vs PKCS7 V1.

Peter






Received: by above.proper.com (8.11.6/8.11.3) id g4VDGS218033 for ietf-pkix-bks; Fri, 31 May 2002 06:16:28 -0700 (PDT)
Received: from mystic1.trustcenter.de (mystic1.trustcenter.de [193.194.157.34]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g4VDGRg18025 for <[e-mail]>; Fri, 31 May 2002 06:16:27 -0700 (PDT)
Received: (from root@localhost) by mystic1.trustcenter.de (8.10.2+Sun/8.10.2) id g4VDFBB06784; Fri, 31 May 2002 15:15:11 +0200 (MEST)
Received: from venus.trustcenter.de(192.168.200.233) by mystic1.trustcenter.de via csmap (V6.0) id srcAAAmTa4pn; Fri, 31 May 02 15:15:11 +0200
Received: from trustcenter.de (titan.trustcenter.de [192.168.200.244]) by venus.trustcenter.de (8.11.0/8.11.0) with ESMTP id g4VDFSQ06157; Fri, 31 May 2002 15:15:28 +0200 (MET DST)
Message-ID: <[e-mail]>
Date: Fri, 31 May 2002 15:15:27 +0200
From: Juergen Brauckmann <[e-mail]>
Organization: TC TrustCenter AG
X-Mailer: Mozilla 4.75 [en] (WinNT; U)
X-Accept-Language: en
MIME-Version: 1.0
To: [e-mail]
CC: Pkix <[e-mail]>
Subject: Re: draft-ietf-pkix-warranty-extn-01
References: <[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Hi.

How should extendedWarranty be used? Perhaps you can give an example? 

Format of the currency field in CurrencyAmount: There is at least one
standard ("ETSI qualified certificate profile") I know of which
recommends use of a PrintableString and the alphabetic code from ISO
4217. 

The example in chapter 2.2 is wrong:
 "$48,525.50 (in US dollars) is represented as:
     currency =      840
     amount   =  4852550
     amtExp10 =        2"

That's wrong. 4852550 * (10 ** 2) is 485,255,000. I guess you wanted to
say that amtExp10 is -2, but you cannot do that because it has to be >=
0.

Regards,
   Juergen


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g4VB7oW09949 for ietf-pkix-bks; Fri, 31 May 2002 04:07:50 -0700 (PDT)
Received: from e1.ny.us.ibm.com (e1.ny.us.ibm.com [32.97.182.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g4VB7mg09945 for <[e-mail]>; Fri, 31 May 2002 04:07:48 -0700 (PDT)
Received: from northrelay02.pok.ibm.com (northrelay02.pok.ibm.com [9.56.224.150]) by e1.ny.us.ibm.com (8.12.2/8.12.2) with ESMTP id g4VB7Zg5262460; Fri, 31 May 2002 07:07:35 -0400
Received: from d01ml062.pok.ibm.com (d01ml062.pok.ibm.com [9.117.250.163]) by northrelay02.pok.ibm.com (8.11.1m3/NCO/VER6.1) with ESMTP id g4VB7Xi117346; Fri, 31 May 2002 07:07:34 -0400
Importance: Normal
Sensitivity: 
Subject: Re: ASN.1 syntax for OCSP nonce value?
To: Geoff Elgey <[e-mail]>
Cc: Peter Gutmann <[e-mail]>, [e-mail]
X-Mailer: Lotus Notes Release 5.0.7  March 21, 2001
Message-ID: <[e-mail]>
From: "Tom Gindin" <[e-mail]>
Date: Thu, 30 May 2002 16:16:14 -0400
X-MIMETrack: Serialize by Router on D01ML062/01/M/IBM(Release 5.0.10 |March 28, 2002) at 05/31/2002 07:07:34 AM
MIME-Version: 1.0
Content-type: text/plain; charset=us-ascii
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

      Geoff:

      Even ANY requires that the length field of the embedded object be
consistent with its wrapping.  In particular, the following ugly check
could be performed: "If (considering octet values as unsigned integers in
the range 0-255) the value of the first octet of the embedded object is not
31 mod 32, either the next series of octets must be a definite-length
encoding matching the length of the OCTET STRING after deduction for the
DER/BER header or the value of the next octet must be 128 and the values of
the last two octets of the encoding must both be zero.".  There's a
corresponding check if the first byte's value is 31 mod 32.
      Even these relatively weak constraints are inconsistent with treating
the value as an untyped blob.  A large majority (over 95%) of untyped blobs
of random data will fail this check, and the proportion will go up (not
down) if one includes a check for multi-byte identifiers.

            Tom Gindin


Geoff Elgey <[e-mail]>@mail.imc.org on 05/30/2002 03:47:52 AM

Sent by:    [e-mail]


To:    Peter Gutmann <[e-mail]>
cc:    [e-mail]
Subject:    Re: ASN.1 syntax for OCSP nonce value?



G'day,

Peter Gutmann wrote:
> (Some implementation guidance as to what's really supposed to be
encapsulated
>  in the OCTET STRING would be useful for bride-of-2560).

I think the rationale for the nonce value as defined in RFC 2560 is as
follows:

"It does not matter what value is inside the OCTET STRING, so long as
this value can be recognized as unique by the requestor and responder.
The requestor MAY define additional semantics on the V part of the OCTET
STRING TLV (for example, treating the V part as having a DER encoded
INTEGER value). Such semantics are beyond the scope of the OCSP
specification. The responder however MUST treat the V part of the OCTET
STRING TLV as an untyped blob, and put it back unmodified into the
response. The requestor MUST check that the untyped blob received in the
response matches the V part of the OCTET STRING in the original request."

This leads to the following: treating the V part of the nonce TLV as
having some specific syntax is clearly implementation specific. Any
OCSPRequest / OCSPResponse value inspected by third-party tools (such as
Peter's "dumpasn1" tool) therefore MUST treat the nonce as an untyped
blob. While the original requestor may consider the nonce value of "02
01 01" as representing an INTEGER with the value 1, to the OCSP server
and any third-party tools, the nonce value is simply three bytes.

Of course, any implementation that treats the complete OCTET STRING TLV
as the nonce is asking for trouble (since DER encoding of the OCTET
STRING is only mandated for OCSP over HTTP).

The arguments above simply reflect the fact that the nonce extension in
RFC 2560 was not defined consistently with the definition of EXTENSION
in RFC 2459. The only way it can be made consistent with RFC 2459 and
remain consistent with existing implementations is to associate the
ASN.1 type ANY with the nonce object identifier. But this will only be
valid of pre-1997 ASN.1 compilers. Sigh.

If the nonce extension was being introduced now, I'd recommend that it
be defined as having an INTEGER syntax.

Cheers,
Geoff





Received: by above.proper.com (8.11.6/8.11.3) id g4UDODU01425 for ietf-pkix-bks; Thu, 30 May 2002 06:24:13 -0700 (PDT)
Received: from email.nist.gov (email.nist.gov [129.6.2.7]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g4UDOB101420 for <[e-mail]>; Thu, 30 May 2002 06:24:11 -0700 (PDT)
Received: from st25 (st25.ncsl.nist.gov [129.6.54.67]) by email.nist.gov (8.12.2/8.12.2) with ESMTP id g4UDO8dT023436; Thu, 30 May 2002 09:24:09 -0400 (EDT)
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58 
Date: Thu, 30 May 2002 09:21:50 -0400
To: "Jeffrey I. Schiller" <[e-mail]>
From: Tim Polk <[e-mail]>
Subject: Re: Request for IESG consideration: PKIX Roadmap
Cc: [e-mail], [e-mail], [e-mail]
In-Reply-To: <[e-mail]>
References: <[e-mail]> <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Jeff,

Thanks for the feedback.  I will ask the authors for proposed text for this 
section and get back to you ASAP.

Tim

At 02:40 PM 5/30/02 +0200, Jeffrey I. Schiller wrote:
>I have not completed my review of this document. However:
>
> > 7 Security Considerations
> >
> >    There are not requirements in this document.
>
>Will not cut it! Perhaps something a bit more descriptive could be
>provided. Something that states that Security Considerations are
>provided in the individual documents...etc.. etc.
>
>                         -Jeff



Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g4UCepO28931 for ietf-pkix-bks; Thu, 30 May 2002 05:40:51 -0700 (PDT)
Received: from jis.mit.edu (JIS.MIT.EDU [18.7.21.84]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g4UCen128924 for <[e-mail]>; Thu, 30 May 2002 05:40:50 -0700 (PDT)
Received: from jis.tzo.com (localhost [127.0.0.1]) by jis.mit.edu (8.9.2/8.9.3) with ESMTP id IAA26978; Thu, 30 May 2002 08:40:48 -0400 (EDT)
Received: (from jis@localhost) by jis.tzo.com (8.11.2/8.8.7) id g4UCejh00996; Thu, 30 May 2002 14:40:45 +0200
Date: Thu, 30 May 2002 14:40:45 +0200
From: "Jeffrey I. Schiller" <[e-mail]>
To: Tim Polk <[e-mail]>
Cc: [e-mail], [e-mail], [e-mail]
Subject: Re: Request for IESG consideration: PKIX Roadmap
Message-ID: <[e-mail]>
References: <[e-mail]>
Mime-Version: 1.0
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="vtzGhvizbBRQ85DL"
Content-Disposition: inline
User-Agent: Mutt/1.3.17i
In-Reply-To: <[e-mail]>; from [e-mail] on Thu, May 23, 2002 at 03:47:01PM -0400
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

--vtzGhvizbBRQ85DL
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

I have not completed my review of this document. However:

> 7 Security Considerations=20
>    =20
>    There are not requirements in this document.=20

Will not cut it! Perhaps something a bit more descriptive could be
provided. Something that states that Security Considerations are
provided in the individual documents...etc.. etc.

			-Jeff

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

MIIHggYJKoZIhvcNAQcCoIIHczCCB28CAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC
BX0wggLYMIICQaADAgECAgMSFgYwDQYJKoZIhvcNAQEEBQAwbDELMAkGA1UEBhMCVVMxFjAU
BgNVBAgTDU1hc3NhY2h1c2V0dHMxLjAsBgNVBAoTJU1hc3NhY2h1c2V0dHMgSW5zdGl0dXRl
IG9mIFRlY2hub2xvZ3kxFTATBgNVBAsTDENsaWVudCBDQSB2MTAeFw0wMTA3MzAyMDQyMDda
Fw0wMjA3MzAyMDQyMDdaMIGlMQswCQYDVQQGEwJVUzEWMBQGA1UECBMNTWFzc2FjaHVzZXR0
czEuMCwGA1UEChMlTWFzc2FjaHVzZXR0cyBJbnN0aXR1dGUgb2YgVGVjaG5vbG9neTEVMBMG
A1UECxMMQ2xpZW50IENBIHYxMRswGQYDVQQDExJKZWZmcmV5IEkgU2NoaWxsZXIxGjAYBgkq
hkiG9w0BCQETC2ppc0BNSVQuRURVMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDoCd+b
C/S0to8TMNKJPxWQT43onqWZUqSpZv7GIHEH3iqkV0Az6y87k/91+Ds9qGHJ+CXh+EilCl9Y
U6URQxOI0NBcbvl0bu0EGwUtN5CJctPXBmNRqEH2P3l9j7O9IhrVW7s7aGm5p21f5o8YKFc7
YTKJ+QOTjr1D9XOfkeH5zQIDAQABo04wTDALBgNVHQ8EBAMCAPAwPQYJKoZIhvcSAQMBBDAw
LgMVAHR77fxGtqt5ZqJ0K/xhsgbDjR08AxUAT6nWdfdyR30koKpq/U+s02ClpAYwDQYJKoZI
hvcNAQEEBQADgYEACK/+DTJFF5ej19X6ZoKci4RJRb//Aa8Sme63IikLWLzM1svAwOvwm/gR
BedFu8HN9qiPzR3GAW1ej5fvE6s+5FLAGG3QG4wfnupwPZlvPahghS5EJMAYhsCLd8qrRQQM
LDtaj+EWG0ql3oSsLv/wmkUKzjW+k2GqXFdDsSI3oLMwggKdMIICBqADAgECAgEAMA0GCSqG
SIb3DQEBBAUAMGwxCzAJBgNVBAYTAlVTMRYwFAYDVQQIEw1NYXNzYWNodXNldHRzMS4wLAYD
VQQKEyVNYXNzYWNodXNldHRzIEluc3RpdHV0ZSBvZiBUZWNobm9sb2d5MRUwEwYDVQQLEwxD
bGllbnQgQ0EgdjEwHhcNMDIwMjE5MTg1OTE1WhcNMDIwODE1MTg1OTE1WjBsMQswCQYDVQQG
EwJVUzEWMBQGA1UECBMNTWFzc2FjaHVzZXR0czEuMCwGA1UEChMlTWFzc2FjaHVzZXR0cyBJ
bnN0aXR1dGUgb2YgVGVjaG5vbG9neTEVMBMGA1UECxMMQ2xpZW50IENBIHYxMIGfMA0GCSqG
SIb3DQEBAQUAA4GNADCBiQKBgQDBXXUJrg7JZOeUXoUfzPwzAJRrcvknG4WysuzPtqsZ5MNL
f1aNbLAOAJkze84K86nOIYVjOJxLufglC7LThC5P7pd1zZsTHu4k6Gh5PP9XKkDgMjByy/bQ
jrcKCvXhow3PlSvgpZCPKfrNyBDbvp+cz9wkPfDMDNfZ9T2YX/UsUQIDAQABo08wTTAdBgNV
HQ4EFgQUARibj0xtym66P6slAv0eCMB6wo8wDAYDVR0TBAUwAwEB/zALBgNVHQ8EBAMCAQYw
EQYJYIZIAYb4QgEBBAQDAgEGMA0GCSqGSIb3DQEBBAUAA4GBAHaAud8SWOvQ+7KlEob/pqrX
NsQaKm/4dOMDVCQRfNhP24YbXrWvQt1x1zrwTdKAGaUbaoYNHoozTNqjxN2dE4ShnQ6/idgc
mNOg6VJNr+mxp79k2uib+mulzDA5cQ8kw2olXp0JiNbmgg/C6wxB12TXWd6QGWW6gMi5jqxQ
cpMAMYIBzTCCAckCAQEwczBsMQswCQYDVQQGEwJVUzEWMBQGA1UECBMNTWFzc2FjaHVzZXR0
czEuMCwGA1UEChMlTWFzc2FjaHVzZXR0cyBJbnN0aXR1dGUgb2YgVGVjaG5vbG9neTEVMBMG
A1UECxMMQ2xpZW50IENBIHYxAgMSFgYwCQYFKw4DAhoFAKCBsTAYBgkqhkiG9w0BCQMxCwYJ
KoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0wMjA1MzAxMjQwNDRaMCMGCSqGSIb3DQEJBDEW
BBSIk+iy0bsEJWaMCbK0qLNKBdTFyTBSBgkqhkiG9w0BCQ8xRTBDMAoGCCqGSIb3DQMHMA4G
CCqGSIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDAN
BgkqhkiG9w0BAQEFAASBgDS3uPN1Fqwe37XbgdNp5vV++dV2QV2EUmWx8iGFUkzVHatmewAK
oCP/gqSg2+fBOMdP4WkUxpgO73Q8FrDdbfjA64wnlC4s/yYW6rZxw27p3qOoeOOq4M41dbX4
PvuPa+ujloMhXCYAArEMxVmhregOSGWFRyK68BT6kkwxCbjw

--vtzGhvizbBRQ85DL--


Received: by above.proper.com (8.11.6/8.11.3) id g4U7mwZ00379 for ietf-pkix-bks; Thu, 30 May 2002 00:48:58 -0700 (PDT)
Received: from osprey.wedgetail.com (starling.wedgetail.com [202.83.95.124]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g4U7mu100369 for <[e-mail]>; Thu, 30 May 2002 00:48:57 -0700 (PDT)
Received: from wedgetail.com (eider.wedgetail.com [10.10.10.130]) by osprey.wedgetail.com (8.12.2/8.12.2) with ESMTP id g4U7lqn3027203; Thu, 30 May 2002 17:47:53 +1000 (EST)
Message-ID: <[e-mail]>
Date: Thu, 30 May 2002 17:47:52 +1000
From: Geoff Elgey <[e-mail]>
User-Agent: Mozilla/5.0 (X11; U; SunOS sun4u; en-US; rv:0.9.9) Gecko/20020311
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Peter Gutmann <[e-mail]>
CC: [e-mail]
Subject: Re: ASN.1 syntax for OCSP nonce value?
References: <[e-mail]>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
X-Scanned-By: MIMEDefang 2.6 (www dot roaringpenguin dot com slash mimedefang)
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

G'day,

Peter Gutmann wrote:
> (Some implementation guidance as to what's really supposed to be encapsulated
>  in the OCTET STRING would be useful for bride-of-2560).

I think the rationale for the nonce value as defined in RFC 2560 is as 
follows:

"It does not matter what value is inside the OCTET STRING, so long as 
this value can be recognized as unique by the requestor and responder. 
The requestor MAY define additional semantics on the V part of the OCTET 
STRING TLV (for example, treating the V part as having a DER encoded 
INTEGER value). Such semantics are beyond the scope of the OCSP 
specification. The responder however MUST treat the V part of the OCTET 
STRING TLV as an untyped blob, and put it back unmodified into the 
response. The requestor MUST check that the untyped blob received in the 
response matches the V part of the OCTET STRING in the original request."

This leads to the following: treating the V part of the nonce TLV as 
having some specific syntax is clearly implementation specific. Any 
OCSPRequest / OCSPResponse value inspected by third-party tools (such as 
Peter's "dumpasn1" tool) therefore MUST treat the nonce as an untyped 
blob. While the original requestor may consider the nonce value of "02 
01 01" as representing an INTEGER with the value 1, to the OCSP server 
and any third-party tools, the nonce value is simply three bytes.

Of course, any implementation that treats the complete OCTET STRING TLV 
as the nonce is asking for trouble (since DER encoding of the OCTET 
STRING is only mandated for OCSP over HTTP).

The arguments above simply reflect the fact that the nonce extension in 
RFC 2560 was not defined consistently with the definition of EXTENSION 
in RFC 2459. The only way it can be made consistent with RFC 2459 and 
remain consistent with existing implementations is to associate the 
ASN.1 type ANY with the nonce object identifier. But this will only be 
valid of pre-1997 ASN.1 compilers. Sigh.

If the nonce extension was being introduced now, I'd recommend that it 
be defined as having an INTEGER syntax.

Cheers,
Geoff




Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g4U5XMf13280 for ietf-pkix-bks; Wed, 29 May 2002 22:33:22 -0700 (PDT)
Received: from mailhost2.auckland.ac.nz ([130.216.191.4]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g4U5XK113275 for <[e-mail]>; Wed, 29 May 2002 22:33:20 -0700 (PDT)
Received: from mailhost-mp.auckland.ac.nz (IDENT:[e-mail] [130.216.191.61]) by mailhost2.auckland.ac.nz (8.9.2/8.9.2/8.9.2-ua) with ESMTP id RAA16079; Thu, 30 May 2002 17:33:23 +1200 (NZST)
Received: from hermes.cs.auckland.ac.nz (hermes.cs.auckland.ac.nz [130.216.35.151]) by mailhost-mp.auckland.ac.nz (Mirapoint Messaging Server MOS 3.1.0.58-GA) with ESMTP id ADX03937; Thu, 30 May 2002 17:33:22 +1200 (NZST)
Received: from ruru.cs.auckland.ac.nz (ruru-nfs.cs.auckland.ac.nz [130.216.35.12]) by hermes.cs.auckland.ac.nz (8.12.3/8.12.3) with ESMTP id g4U5XMAC011169; Thu, 30 May 2002 17:33:22 +1200
Received: (from pgut001@localhost) by ruru.cs.auckland.ac.nz (8.9.3/8.8.6/cs-slave) id RAA149943; Thu, 30 May 2002 17:33:21 +1200 (NZST) (sender [e-mail])
Date: Thu, 30 May 2002 17:33:21 +1200 (NZST)
Message-ID: <[e-mail]>
From: [e-mail] (Peter Gutmann)
To: [e-mail], [e-mail]
Subject: Re: ASN.1 syntax for OCSP nonce value?
Cc: [e-mail]
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Juergen Brauckmann <[e-mail]> writes:
>Peter Gutmann wrote:
>>Hmm, I wonder where I got the INTEGER from?  The fact that I complain about it
>>in the code indicates that something at some point specified it... does anyone
>>archive old drafts?
>
>Perhaps you mixed it with TSP?

That would explain it.  I'm guessing it was a cut-and-paste from one to the
other (I use customised ASN.1 definitions to handle implementation bugs and
ambiguities in specs, so the TSA customisation would have been copied across.
Luckily the code is already set up to handle the situation of finding non-DER
values where there should be DER, because a widely-used CA did this a few years
ago in its certificates :-).

(Some implementation guidance as to what's really supposed to be encapsulated
 in the OCTET STRING would be useful for bride-of-2560).

Peter.


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g4U3P3I02573 for ietf-pkix-bks; Wed, 29 May 2002 20:25:04 -0700 (PDT)
Received: from file.initech.com ([61.74.133.21]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g4U3P0J02518 for <[e-mail]>; Wed, 29 May 2002 20:25:00 -0700 (PDT)
content-class: urn:content-classes:message
Subject: Question on OCSP.
Date: Thu, 30 May 2002 11:55:46 +0900
MIME-Version: 1.0
Content-Type: text/plain; charset="euc-kr"
Message-ID: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
X-MimeOLE: Produced By Microsoft Exchange V6.0.4417.0
Thread-Topic: Question on OCSP.
Thread-Index: AcIHhRSaY/MbARbgQdu8RJqSlYT5Xw==
From: =?euc-kr?B?waQgsea3xA==?= <[e-mail]>
To: <[e-mail]>
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from base64 to 8bit by above.proper.com id g4U3P1J02534
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Hi,

  I was wondering if someone could clarify this paragraph, from
  'draft-ietf-pkix-rfc2560bis-01.txt'  section 4.4.4 Archive Cutoff.

  1. Waht is the mean of 'Archive Cutoff' ?
  1. What is the 'revocation information' ?
  1. How do the clients use 'Archive Cutoff date' in real ?
  1. Which information do you need for 'Archive Cutoff'  ?

 Thanks for you time.


Received: by above.proper.com (8.11.6/8.11.3) id g4TCZKN10631 for ietf-pkix-bks; Wed, 29 May 2002 05:35:20 -0700 (PDT)
Received: from mx1.magmacom.com (mx1.magmacom.com [206.191.0.217]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g4TCZJJ10625 for <[e-mail]>; Wed, 29 May 2002 05:35:19 -0700 (PDT)
Received: from mail6.magma.ca (mail6 [206.191.0.248]) by mx1.magmacom.com (Magma's Mail Server) with ESMTP id g4TCZ55L015939 for <[e-mail]>; Wed, 29 May 2002 08:35:05 -0400 (EDT)
Received: from asturgeonpc (ottawa-dial-64-26-139-108.d-ip.magma.ca [64.26.139.108]) by mail6.magma.ca (Magma's Mail Server) with SMTP id g4TCYmRZ003775 for <[e-mail]>; Wed, 29 May 2002 08:35:04 -0400 (EDT)
Reply-To: <[e-mail]>
From: "Alice Sturgeon" <[e-mail]>
To: "Pkix" <[e-mail]>
Subject: draft-ietf-pkix-warranty-extn-01
Date: Wed, 29 May 2002 08:44:25 -0400
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.2911.0)
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
Importance: Normal
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Hi folks,
The revised draft on certificate warranty extension was issued to the list
last week, addressing the first round of comments, and there have been no
comments back.  Is everyone satisfied with it now, with the revisions?  I
know some were not thrilled with the I-D but decided they could live with
it, given it is optional.  Some also thought it was more a legal matter -
The I-D was also posted to the ABA list, and received few comments; these
too have been taken into consideration.


Alice Sturgeon
Chair
Canadian Advisory Committee - Information Technology Security
ISO/IEC JTC1 SC 27
and
System Policy Architect
SPYRUS
Phone:     [phone]
Cell:         613-291-0331






Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g4TBeR905778 for ietf-pkix-bks; Wed, 29 May 2002 04:40:27 -0700 (PDT)
Received: from e1.ny.us.ibm.com (e1.ny.us.ibm.com [32.97.182.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g4TBeLJ05774 for <[e-mail]>; Wed, 29 May 2002 04:40:21 -0700 (PDT)
Received: from northrelay02.pok.ibm.com (northrelay02.pok.ibm.com [9.56.224.150]) by e1.ny.us.ibm.com (8.12.2/8.12.2) with ESMTP id g4TBeGg5198422; Wed, 29 May 2002 07:40:17 -0400
Received: from d01ml062.pok.ibm.com (d01ml062.pok.ibm.com [9.117.250.163]) by northrelay02.pok.ibm.com (8.11.1m3/NCO/VER6.1) with ESMTP id g4TBeFT82340; Wed, 29 May 2002 07:40:15 -0400
Importance: Normal
Sensitivity: 
Subject: Re: timeStamp vs electronic notary
To: "ChungKil Kim" <[e-mail]>
Cc: <[e-mail]>
X-Mailer: Lotus Notes Release 5.0.7  March 21, 2001
Message-ID: <[e-mail]>
From: "Tom Gindin" <[e-mail]>
Date: Wed, 29 May 2002 07:40:14 -0400
X-MIMETrack: Serialize by Router on D01ML062/01/M/IBM(Release 5.0.10 |March 28, 2002) at 05/29/2002 07:40:15 AM
MIME-Version: 1.0
Content-type: text/plain; charset=us-ascii
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

      Actually, time stamp has many uses outside the electronic notary
service, since there is no need for the time stamp service to see the
actual document at all.  You are correct that most electronic notary
services would be likely to use the time stamp service to prove that no
modifications have been made since the specified time.  IMHO, any designer
of an electronic notary service would want to use an external third-party
time stamp and would be likely to use RFC 3161 for that purpose.

            Tom Gindin

"ChungKil Kim" <[e-mail]>@mail.imc.org on 05/27/2002 03:51:04 AM

Sent by:    [e-mail]


To:    <[e-mail]>
cc:
Subject:    Re: timeStamp vs electronic notary



timeStamp would be used in electonic notray system.
timeStamp is software protocol subsystem of electonic notray.

----- Original Message -----
From: "Pere Fiol" <[e-mail]>
To: <[e-mail]>
Sent: Friday, May 24, 2002 8:24 PM
Subject: timeStamp vs electronic notary


>
> Hi,
>
> I would like to know the differences between the services: timeStamp &
> electronic notary. Moreover, I know that TimeStamp is described in
RFC3161,
> but is defined in some place the Electronic Notary service??
>
> Thanks in advance,
> Pere







Received: by above.proper.com (8.11.6/8.11.3) id g4T7Naw09786 for ietf-pkix-bks; Wed, 29 May 2002 00:23:36 -0700 (PDT)
Received: from mystic1.trustcenter.de (mystic1.trustcenter.de [193.194.157.34]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g4T7NZJ09777 for <[e-mail]>; Wed, 29 May 2002 00:23:35 -0700 (PDT)
Received: (from root@localhost) by mystic1.trustcenter.de (8.10.2+Sun/8.10.2) id g4T7N5b15277; Wed, 29 May 2002 09:23:05 +0200 (MEST)
Received: from venus.trustcenter.de(192.168.200.233) by mystic1.trustcenter.de via csmap (V6.0) id srcAAATyaG1D; Wed, 29 May 02 09:23:04 +0200
Received: from trustcenter.de (titan.trustcenter.de [192.168.200.244]) by venus.trustcenter.de (8.11.0/8.11.0) with ESMTP id g4T7NMQ20474; Wed, 29 May 2002 09:23:22 +0200 (MET DST)
Message-ID: <[e-mail]>
Date: Wed, 29 May 2002 09:23:21 +0200
From: Juergen Brauckmann <[e-mail]>
Organization: TC TrustCenter AG
X-Mailer: Mozilla 4.75 [en] (WinNT; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Peter Gutmann <[e-mail]>
CC: [e-mail]
Subject: Re: ASN.1 syntax for OCSP nonce value?
References: <[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Peter Gutmann wrote:
> Hmm, I wonder where I got the INTEGER from?  The fact that I complain about it
> in the code indicates that something at some point specified it... does anyone
> archive old drafts?  

In draft-ietf-ocsp-03.txt from March '98:
=======================================================
3.4.1 Nonce

The nonce cryptographically binds a request and a response to prevent
replay attacks. The nonce is included as one of the requestExtensions
in requests, while in responses it would be included as one of the
responseExtensions.  In both the request and the response, the nonce
will be identified by the object identifier id-pkix-ocsp-nonce, while
the extnValue is the value of the nonce.

id-pkix-ocsp-nonce     OBJECT IDENTIFIER ::= { id-pkix-ocsp 2 }
======================================================

Perhaps you mixed it with TSP?

Regards,
   Juergen


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g4T6nkr05043 for ietf-pkix-bks; Tue, 28 May 2002 23:49:46 -0700 (PDT)
Received: from mailhost2.auckland.ac.nz (mailhost2.auckland.ac.nz [130.216.191.4]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g4T6niJ05032 for <[e-mail]>; Tue, 28 May 2002 23:49:44 -0700 (PDT)
Received: from mailhost-mp.auckland.ac.nz (IDENT:[e-mail] [130.216.191.61]) by mailhost2.auckland.ac.nz (8.9.2/8.9.2/8.9.2-ua) with ESMTP id SAA00784 for <[e-mail]>; Wed, 29 May 2002 18:49:43 +1200 (NZST)
Received: from hermes.cs.auckland.ac.nz (hermes.cs.auckland.ac.nz [130.216.35.151]) by mailhost-mp.auckland.ac.nz (Mirapoint Messaging Server MOS 3.1.0.58-GA) with ESMTP id ADW43651; Wed, 29 May 2002 18:49:42 +1200 (NZST)
Received: from ruru.cs.auckland.ac.nz (ruru-nfs.cs.auckland.ac.nz [130.216.35.12]) by hermes.cs.auckland.ac.nz (8.12.3/8.12.3) with ESMTP id g4T6ngAC010657 for <[e-mail]>; Wed, 29 May 2002 18:49:42 +1200
Received: (from pgut001@localhost) by ruru.cs.auckland.ac.nz (8.9.3/8.8.6/cs-slave) id SAA100215 for [e-mail]; Wed, 29 May 2002 18:49:41 +1200 (NZST) (sender [e-mail])
Date: Wed, 29 May 2002 18:49:41 +1200 (NZST)
Message-ID: <[e-mail]>
From: [e-mail] (Peter Gutmann)
To: [e-mail]
Subject: Re: ASN.1 syntax for OCSP nonce value?
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

I wrote:

>Hmm, I wonder where I got the INTEGER from?  The fact that I complain about it
>in the code indicates that something at some point specified it... does anyone
>archive old drafts?  Could it be something which vanished during the editing
>process?

In case anyone cares the nonce appeared in -03 (I don't have -02, only -01
before that) and then remained constant until -08 and the final RFC.  No
mention of an INTEGER.  Hmm...

Peter.


Received: by above.proper.com (8.11.6/8.11.3) id g4T6JSW00537 for ietf-pkix-bks; Tue, 28 May 2002 23:19:28 -0700 (PDT)
Received: from mailhost2.auckland.ac.nz (mailhost2.auckland.ac.nz [130.216.1.4]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g4T6JQJ00528 for <[e-mail]>; Tue, 28 May 2002 23:19:26 -0700 (PDT)
Received: from mailhost-mp.auckland.ac.nz (IDENT:[e-mail] [130.216.191.61]) by mailhost2.auckland.ac.nz (8.9.2/8.9.2/8.9.2-ua) with ESMTP id SAA27109; Wed, 29 May 2002 18:18:58 +1200 (NZST)
Received: from hermes.cs.auckland.ac.nz (hermes.cs.auckland.ac.nz [130.216.35.151]) by mailhost-mp.auckland.ac.nz (Mirapoint Messaging Server MOS 3.1.0.58-GA) with ESMTP id ADW42651; Wed, 29 May 2002 18:18:55 +1200 (NZST)
Received: from ruru.cs.auckland.ac.nz (ruru-nfs.cs.auckland.ac.nz [130.216.35.12]) by hermes.cs.auckland.ac.nz (8.12.3/8.12.3) with ESMTP id g4T6IsAC010008; Wed, 29 May 2002 18:18:54 +1200
Received: (from pgut001@localhost) by ruru.cs.auckland.ac.nz (8.9.3/8.8.6/cs-slave) id SAA91380; Wed, 29 May 2002 18:18:51 +1200 (NZST) (sender [e-mail])
Date: Wed, 29 May 2002 18:18:51 +1200 (NZST)
Message-ID: <[e-mail]>
From: [e-mail] (Peter Gutmann)
To: [e-mail], [e-mail]
Subject: Re: ASN.1 syntax for OCSP nonce value?
Cc: [e-mail], [e-mail], [e-mail], [e-mail]
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Dr S N Henson <[e-mail]> writes:

>IIRC one client I tried placed an OCTET STRING inside the OCTET STRING whereas
>another just put the raw nonce value in there with no encoding. All the
>responders I tried would correctly handle the raw value.

Hmm, I wonder where I got the INTEGER from?  The fact that I complain about it
in the code indicates that something at some point specified it... does anyone
archive old drafts?  Could it be something which vanished during the editing
process?

Peter.


Received: by above.proper.com (8.11.6/8.11.3) id g4SMjAo15817 for ietf-pkix-bks; Tue, 28 May 2002 15:45:10 -0700 (PDT)
Received: from anchor-post-33.mail.demon.net (anchor-post-33.mail.demon.net [194.217.242.91]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g4SMj8J15813 for <[e-mail]>; Tue, 28 May 2002 15:45:08 -0700 (PDT)
Received: from drh-consultancy.demon.co.uk ([193.237.150.98] helo=gemplus.com) by anchor-post-33.mail.demon.net with esmtp (Exim 3.35 #1) id 17CpiF-000GkR-0X; Tue, 28 May 2002 23:45:07 +0100
Message-ID: <[e-mail]>
Date: Tue, 28 May 2002 23:50:11 +0100
From: Dr S N Henson <[e-mail]>
X-Mailer: Mozilla 4.79 [en] (Win98; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Peter Gutmann <[e-mail]>
CC: [e-mail], [e-mail], [e-mail], [e-mail]
Subject: Re: ASN.1 syntax for OCSP nonce value?
References: <[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Peter Gutmann wrote:
> 
> Geoff Elgey <[e-mail]> writes:
> 
> >This implies that a "nonce" must have some ASN.1 syntax, the complete DER-
> >encoding of which is encapsulated as the value part of an OCTET STRING
> >encoding.
> 
> I thought the nonce was an INTEGER?  My code has:
> 
>   /* Although the nonce should be an integer, it's really an integer equivalent
>      of an octet string hole so we call it an octet string to make sure it gets
>      handled appropriately */
> 
> (that is, I treat it as an INTEGER encoded as an OCTET STRING hole).  The
> result is:
> 
>   75 30   32:         SEQUENCE {
>   77 06    9:           OBJECT IDENTIFIER ocspNonce (1 3 6 1 5 5 7 48 1 2)
>   88 04   19:           OCTET STRING, encapsulates {
>   90 02   17:               INTEGER
>             :                 00 C0 4B 2A 18 F8 25 91 6C 49 1A 86 34 E7 45 D0
>             :                 67
>             :               }
>             :           }
> 

IIRC one client I tried placed an OCTET STRING inside the OCTET STRING
whereas another just put the raw nonce value in there with no encoding.
All the responders I tried would correctly handle the raw value. 

I had to treat ocspNonce as a special case in OpenSSL becasuse normally
it assumes some encoded structure is in there, it now treats it as a
'blob'.

Steve.
-- 
Dr Stephen N. Henson.   http://www.drh-consultancy.demon.co.uk/
Personal Email: [e-mail] 
Senior crypto engineer, Gemplus: http://www.gemplus.com/
Core developer of the   OpenSSL project: http://www.openssl.org/
Business Email: [e-mail] PGP key: via homepage.


Received: by above.proper.com (8.11.6/8.11.3) id g4SM8M915041 for ietf-pkix-bks; Tue, 28 May 2002 15:08:22 -0700 (PDT)
Received: from osprey.wedgetail.com (starling.wedgetail.com [202.83.95.124]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g4SM8KJ15037 for <[e-mail]>; Tue, 28 May 2002 15:08:20 -0700 (PDT)
Received: from wedgetail.com (eider.wedgetail.com [10.10.10.130]) by osprey.wedgetail.com (8.12.2/8.12.2) with ESMTP id g4SM8An3009223; Wed, 29 May 2002 08:08:11 +1000 (EST)
Message-ID: <[e-mail]>
Date: Wed, 29 May 2002 08:08:10 +1000
From: Geoff Elgey <[e-mail]>
User-Agent: Mozilla/5.0 (X11; U; SunOS sun4u; en-US; rv:0.9.9) Gecko/20020311
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Peter Gutmann <[e-mail]>
CC: [e-mail], [e-mail]
Subject: Re: ASN.1 syntax for OCSP nonce value?
References: <[e-mail]>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
X-Scanned-By: MIMEDefang 2.6 (www dot roaringpenguin dot com slash mimedefang)
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

G'day,

Peter Gutmann wrote:
> I thought the nonce was an INTEGER?  My code has:
> 
>   /* Although the nonce should be an integer, it's really an integer equivalent
>      of an octet string hole so we call it an octet string to make sure it gets
>      handled appropriately */
> 
> (that is, I treat it as an INTEGER encoded as an OCTET STRING hole).  

RFC 2560 does not specify what the nonce is.

I thought that the ambiguity of some applications treating a nonce as an 
encapsulated INTEGER, while others treat the nonce as the complete OCTET 
STRING transmitted, meant that replay attacks could be exploited.

However, since a DER encoding is required, unique INTEGER values will 
always give unique OCTET STRING values (although at least the first two 
bytes of the OCTET STRING will be discarded).

In fact, it does not matter what the syntax happens to be of the value 
part of the OCTET STRING. Whether it is INTEGER, GeneralizedTime, BIT 
STRING, or even a complete X509 Certificate, is irrelevent. The encoding 
will be canonical, and the only requirement is that the encoding is 
sufficient enough to detect replay attacks.

However, since RFC 2560 defines the nonce as an EXTENSION as defined in 
RFC 2459, then there *should* be a syntax associated with the object 
identifier (just as Peter defines above).  This is simply for conformity 
with the specification, which (hopefully) will not affect any extant 
implementations.

-- Geoff



Received: by above.proper.com (8.11.6/8.11.3) id g4SIpQb10744 for ietf-pkix-bks; Tue, 28 May 2002 11:51:26 -0700 (PDT)
Received: from ext-mail.valicert.com ([66.206.205.11]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g4SIpOJ10740 for <[e-mail]>; Tue, 28 May 2002 11:51:24 -0700 (PDT)
Received: from CONVERSION-DAEMON by ext-mail.valicert.com (PMDF V5.2-33 #46613) id <[e-mail]> for [e-mail]; Tue, 28 May 2002 11:46:16 -0700 (PDT)
Received: from polaris.valicert.com ([192.168.2.34]) by ext-mail.valicert.com (PMDF V5.2-33 #46613) with ESMTP id <[e-mail]>; Tue, 28 May 2002 11:46:15 -0700 (PDT)
Received: by polaris.valicert.com with Internet Mail Service (5.5.2653.19) id <K7HLM0ZP>; Tue, 28 May 2002 11:50:50 -0700
Content-return: allowed
Date: Tue, 28 May 2002 11:50:47 -0700
From: Ambarish Malpani <[e-mail]>
Subject: RE: ASN.1 syntax for OCSP nonce value?
To: "'[e-mail]'" <[e-mail]>, [e-mail], [e-mail]
Cc: [e-mail]
Message-id: <[e-mail]>
MIME-version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-type: text/plain
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Our server doesn't check to see the contents of the nonce value,
since all we do it put it back in the response.

I don't know how others encode it.

Regards,
Ambarish

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


> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]]
> Sent: Tuesday, May 28, 2002 7:50 AM
> To: [e-mail]; [e-mail]
> Cc: [e-mail]; [e-mail]
> Subject: Re: ASN.1 syntax for OCSP nonce value?
> 
> 
> Geoff Elgey <[e-mail]> writes:
> 
> >This implies that a "nonce" must have some ASN.1 syntax, the 
> complete DER-
> >encoding of which is encapsulated as the value part of an 
> OCTET STRING
> >encoding.
> 
> I thought the nonce was an INTEGER?  My code has:
> 
>   /* Although the nonce should be an integer, it's really an 
> integer equivalent
>      of an octet string hole so we call it an octet string to 
> make sure it gets
>      handled appropriately */
> 
> (that is, I treat it as an INTEGER encoded as an OCTET STRING 
> hole).  The
> result is:
> 
>   75 30   32:         SEQUENCE {
>   77 06    9:           OBJECT IDENTIFIER ocspNonce (1 3 6 1 
> 5 5 7 48 1 2)
>   88 04   19:           OCTET STRING, encapsulates {
>   90 02   17:               INTEGER
>             :                 00 C0 4B 2A 18 F8 25 91 6C 49 
> 1A 86 34 E7 45 D0
>             :                 67
>             :               }
>             :           }
> 
> Peter.
> 


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g4SEo9R27483 for ietf-pkix-bks; Tue, 28 May 2002 07:50:09 -0700 (PDT)
Received: from mailhost2.auckland.ac.nz (IDENT:mirapoint@[130.216.191.61]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g4SEo7J27475 for <[e-mail]>; Tue, 28 May 2002 07:50:07 -0700 (PDT)
Received: from hermes.cs.auckland.ac.nz (hermes.cs.auckland.ac.nz [130.216.35.151]) by mailhost2.auckland.ac.nz (Mirapoint Messaging Server MOS 2.9.3.2) with ESMTP id ADR31809; Wed, 29 May 2002 02:50:00 +1200 (NZST)
Received: from ruru.cs.auckland.ac.nz (ruru-nfs.cs.auckland.ac.nz [130.216.35.12]) by hermes.cs.auckland.ac.nz (8.12.3/8.12.3) with ESMTP id g4SEo0AC020397; Wed, 29 May 2002 02:50:00 +1200
Received: (from pgut001@localhost) by ruru.cs.auckland.ac.nz (8.9.3/8.8.6/cs-slave) id CAA44081; Wed, 29 May 2002 02:49:53 +1200 (NZST) (sender [e-mail])
Date: Wed, 29 May 2002 02:49:53 +1200 (NZST)
Message-ID: <[e-mail]>
From: [e-mail] (Peter Gutmann)
To: [e-mail], [e-mail]
Subject: Re: ASN.1 syntax for OCSP nonce value?
Cc: [e-mail], [e-mail]
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Geoff Elgey <[e-mail]> writes:

>This implies that a "nonce" must have some ASN.1 syntax, the complete DER-
>encoding of which is encapsulated as the value part of an OCTET STRING
>encoding.

I thought the nonce was an INTEGER?  My code has:

  /* Although the nonce should be an integer, it's really an integer equivalent
     of an octet string hole so we call it an octet string to make sure it gets
     handled appropriately */

(that is, I treat it as an INTEGER encoded as an OCTET STRING hole).  The
result is:

  75 30   32:         SEQUENCE {
  77 06    9:           OBJECT IDENTIFIER ocspNonce (1 3 6 1 5 5 7 48 1 2)
  88 04   19:           OCTET STRING, encapsulates {
  90 02   17:               INTEGER
            :                 00 C0 4B 2A 18 F8 25 91 6C 49 1A 86 34 E7 45 D0
            :                 67
            :               }
            :           }

Peter.


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g4SAnjA12109 for ietf-pkix-bks; Tue, 28 May 2002 03:49:45 -0700 (PDT)
Received: from popsmtp1.icenet.net (popsmtp.icenet.net [203.88.128.12]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g4SAncJ12104 for <[e-mail]>; Tue, 28 May 2002 03:49:39 -0700 (PDT)
Received: from numenindia.com (ice.130.client243.icenet.net [203.88.130.243] (may be forged)) by popsmtp1.icenet.net (8.9.3/8.9.3) with SMTP id QAA04873 for <[e-mail]>; Tue, 28 May 2002 16:17:03 +0530
X-Distribution-To: [e-mail]
From: "narendra" <[e-mail]>
To: "Ietf-Pkix" <[e-mail]>
Subject: about PKIX-CMP protocol
Date: Wed, 29 May 2002 04:24:18 +0530
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.2911.0)
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Dear Group Members,
      While studing rfc 2510  (the PKIX CMP protocol) ,i come   across the
word "out-of-band".What is this term specify? I tried but not able to
understand.

seeeking your co-operation,
narendra.
--------------------------------------------
Parmar Narendrasinh Abhesinh
Numen Technologies Pvt.Ltd,
505 "ADITYA"
Opp.Sardar Patel Seva Samaj,
Off.C.G.Road,Ahmedabad-380 006.India
Phone no:- [phone]/6466310 ex-46,47,48





Received: by above.proper.com (8.11.6/8.11.3) id g4S8AK725327 for ietf-pkix-bks; Tue, 28 May 2002 01:10:20 -0700 (PDT)
Received: from sonne.darmstadt.gmd.de (sonne.darmstadt.gmd.de [141.12.62.20]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g4S8ADJ25302 for <[e-mail]>; Tue, 28 May 2002 01:10:19 -0700 (PDT)
Received: from sit.fraunhofer.de (pc-rogerrabbit [141.12.35.140]) by sonne.darmstadt.gmd.de (8.8.8/8.8.5) with ESMTP id JAA06296; Tue, 28 May 2002 09:10:06 +0200 (MET DST)
Message-ID: <[e-mail]>
Date: Tue, 28 May 2002 09:10:20 +0200
From: Brian Hunter <[e-mail]>
X-Mailer: Mozilla 4.76 [en] (Windows NT 5.0; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Michael Myers <[e-mail]>
CC: [e-mail]
Subject: Re: DPD/DPV Requirements
References: <[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Mike,

Ok, then I will leave this topic for the protocol discussions.

Brian

Michael Myers wrote:
> 
> Brian,
> 
> This case is more a matter for the protocol design/selection
> stage of what we're up to here.  I'm certain there'll be ample
> opportunity for discussion and debate on this case and many
> others once we get to that stage.  But for now, it's sufficient
> that a high-level requirement exist for an "unknown" state as
> defined.
> 
> That said though, an inability to build a policy-compliant path
> is either an error or unknown but certainly not invalid. The
> latter assertion clearly implies the server has built a path.
> 
> At present, I would lean towards this being an unsigned error
> since the scenario you describe suggests the server at least
> recognizes the subject certificate.  It could be the case that
> the client specified a policy that requires the path to transit
> a bridging CA of which the server is completely ignorant.  In
> that particular sub-case, an unsigned error response of
> "unsupportedPolicy" seems most appropriate.
> 
> Mike
> 
> > -----Original Message-----
> > From: Brian Hunter [mailto:[e-mail]]
> > Sent: Monday, May 27, 2002 8:31 AM
> > To: Michael Myers
> > Cc: [e-mail]
> > Subject: Re: DPD/DPV Requirements
> >
> >
> > Mike,
> >
> > Thanks.  But I would still assume that that would
> > also mean a server would want to say unknown if
> > it could only partially build a path,
> > (reason "a" below), since "I cannot find the CA
> > certificate of the certificate in question
> > (ie I know absolutely nothing about the
> > certificate)" is a subset of "I cannot build a path".
> >
> > Brian
> >
> > Michael Myers wrote:
> > >
> > > Brian,
> > >
> > > The reason is, servers (responding parties) need a means to
> > > escape out of making a definitive assertion to
> > clients (relying
> > > parties) in the event the server (responding party) knows
> > > absolutely nothing about the certificate in question.
> > >
> > > Mike
> > >
> > > > "When the certificate is not valid according to the
> > > > validation policy,
> > > > then the reason MUST also be indicated. Invalidity
> > > > reasons include:
> > > >
> > > >    a) the DPV server cannot determine the validity of
> > > > the certificate
> > > >       because a certification path cannot be constructed.
> > > >
> >


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g4S4rdj06609 for ietf-pkix-bks; Mon, 27 May 2002 21:53:39 -0700 (PDT)
Received: from smtpzilla5.xs4all.nl (smtpzilla5.xs4all.nl [194.109.127.141]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g4S4raJ06604 for <[e-mail]>; Mon, 27 May 2002 21:53:37 -0700 (PDT)
Received: from pc1 (213-84-108-38.adsl.xs4all.nl [213.84.108.38]) by smtpzilla5.xs4all.nl (8.12.0/8.12.0) with ESMTP id g4S4reof032993 for <[e-mail]>; Tue, 28 May 2002 06:53:40 +0200 (CEST)
From: [e-mail]
To: [e-mail]
Date: Tue, 28 May 2002 06:54:18 +0200
MIME-Version: 1.0
Subject: Question on SCVP.
Message-ID: <3CF3299A.3419.386562@localhost>
X-mailer: Pegasus Mail for Windows (v4.01)
Content-type: text/plain; charset=US-ASCII
Content-transfer-encoding: 7BIT
Content-description: Mail message body
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Hi,

  I was wondering if someone could clarify this paragraph, from
  'draft-ietf-pkix-scvp-08.txt' section 6. Security Considerations,

    "If the client does not include a RequestNonce item, or if the client
     does not check that the RequestNonce in the reply matches that in the
     request, an attacker can replay previous responses from the server.
     [This is not true if the request hash is used as a nonce by the client.]"

  In particular, the square bracket text may be interpreted in two
  ways.

  1.  While generating a PSRequest, a hash of the PSRequest is
      included as the requestNonce.  Quite a feat, as this requires that
      the hash be known before generating the PSRequest, of which the hash
      is a part.
 
  2.  When decoding the PSResponse, the requestHash is compared with a
      previously calculated hash of PSRequest prior to transporting the
      ContentInfo to a SCVP compliant server.  This seems like a
      reasonable interpretation.  However, if this is the desired
      interpretation, then I do not believe the statement true in all
      cases.  

      Consider a minimal PSRequest, where none of the OPTIONAL fields
      are included, the typesOfCheck and wantBack items being constant
      (which I believe to be a valid assumption for any given usage
      of a scvp client, for pratical purposes).  Then for each
      single certificate (or single set of certificates), for which validity
      information is required, the hash of PSRequest will be the same.
      Therefore the requestHash cannot be used as a nonce. Or did I
      miss something?

      Another question that arises is, for security reasons, is it desirable
      to require a nonce extention, or is the whole nonce mechanism merely
      there to support clients that desire higher security than that which
      is provided if a minimum PSRequest is used?  Put another way, if a 
      client does not care to thwart replay attacks can they simply ignore
      checking the requestHash, if they are waiting on a single response?
      (Yes I know they MUST check it, but it is a trivial check if my point 
      2. above, is correct.)

      A last question would read, How can a server enforce the use of a
      nonce, or require a nonce before processing a PSRequest? And
      would it be desirable to do so, if not why not?


  BTW, I have a suggestion for normalizing the ASN.1 notation from

    "CertsQuery ::= SEQUENCE {
        queriedCerts          SEQUENCE SIZE (1..MAX) OF Cert,
        validityTime      [0] GeneralizedTime OPTIONAL,
        intermediateCerts [1] CertBundle OPTIONAL,
        trustedCerts      [2] CertBundle OPTIONAL,
        revocationInfos   [3] SEQUENCE SIZE (1..MAX) OF RevocationInfo OPTIONAL,
        policyID          [4] OBJECT IDENTIFIER OPTIONAL,
        configurationIdentifier [5] OBJECT IDENTIFIER OPTIONAL,
        queryExtensions        [6] Extensions OPTIONAL
    }"

  to

    CertsQuery ::= SEQUENCE {
        queriedCerts          CertBundle,
        validityTime      [0] GeneralizedTime OPTIONAL,
        intermediateCerts [1] CertBundle OPTIONAL,
        trustedCerts      [2] CertBundle OPTIONAL,
        revocationInfos   [3] SEQUENCE SIZE (1..MAX) OF RevocationInfo OPTIONAL,
        policyID          [4] OBJECT IDENTIFIER OPTIONAL,
        configurationIdentifier [5] OBJECT IDENTIFIER OPTIONAL,
        queryExtensions        [6] Extensions OPTIONAL
    }

  [change made to defintion of queriedCerts]


  Thanks for you time.

-rob paar
[e-mail]



Received: by above.proper.com (8.11.6/8.11.3) id g4RGArC18787 for ietf-pkix-bks; Mon, 27 May 2002 09:10:53 -0700 (PDT)
Received: from mail.coastside.net (mail.coastside.net [207.213.212.6]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g4RGApJ18781 for <[e-mail]>; Mon, 27 May 2002 09:10:51 -0700 (PDT)
Received: from laptop (dsl-63-194-153-52.coastside.net [63.194.153.52]) by poseidon.coastside.net  with SMTP id g4RGAqUg026923; Mon, 27 May 2002 09:10:52 -0700 (PDT)
From: "Michael Myers" <[e-mail]>
To: "Brian Hunter" <[e-mail]>
Cc: <[e-mail]>
Subject: RE: DPD/DPV Requirements
Date: Mon, 27 May 2002 09:07:48 -0700
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0)
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
Importance: Normal
In-Reply-To: <[e-mail]>
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Brian,

This case is more a matter for the protocol design/selection
stage of what we're up to here.  I'm certain there'll be ample
opportunity for discussion and debate on this case and many
others once we get to that stage.  But for now, it's sufficient
that a high-level requirement exist for an "unknown" state as
defined.

That said though, an inability to build a policy-compliant path
is either an error or unknown but certainly not invalid. The
latter assertion clearly implies the server has built a path.

At present, I would lean towards this being an unsigned error
since the scenario you describe suggests the server at least
recognizes the subject certificate.  It could be the case that
the client specified a policy that requires the path to transit
a bridging CA of which the server is completely ignorant.  In
that particular sub-case, an unsigned error response of
"unsupportedPolicy" seems most appropriate.

Mike


> -----Original Message-----
> From: Brian Hunter [mailto:[e-mail]]
> Sent: Monday, May 27, 2002 8:31 AM
> To: Michael Myers
> Cc: [e-mail]
> Subject: Re: DPD/DPV Requirements
>
>
> Mike,
>
> Thanks.  But I would still assume that that would
> also mean a server would want to say unknown if
> it could only partially build a path,
> (reason "a" below), since "I cannot find the CA
> certificate of the certificate in question
> (ie I know absolutely nothing about the
> certificate)" is a subset of "I cannot build a path".
>
> Brian
>
> Michael Myers wrote:
> >
> > Brian,
> >
> > The reason is, servers (responding parties) need a means to
> > escape out of making a definitive assertion to
> clients (relying
> > parties) in the event the server (responding party) knows
> > absolutely nothing about the certificate in question.
> >
> > Mike
> >
> > > "When the certificate is not valid according to the
> > > validation policy,
> > > then the reason MUST also be indicated. Invalidity
> > > reasons include:
> > >
> > >    a) the DPV server cannot determine the validity of
> > > the certificate
> > >       because a certification path cannot be constructed.
> > >
>



Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g4RFY4B14467 for ietf-pkix-bks; Mon, 27 May 2002 08:34:04 -0700 (PDT)
Received: from sonne.darmstadt.gmd.de (sonne.darmstadt.gmd.de [141.12.62.20]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g4RFY3J14462 for <[e-mail]>; Mon, 27 May 2002 08:34:03 -0700 (PDT)
Received: from sit.fraunhofer.de (pc-rogerrabbit [141.12.35.140]) by sonne.darmstadt.gmd.de (8.8.8/8.8.5) with ESMTP id RAA12633; Mon, 27 May 2002 17:30:44 +0200 (MET DST)
Message-ID: <[e-mail]>
Date: Mon, 27 May 2002 17:30:56 +0200
From: Brian Hunter <[e-mail]>
X-Mailer: Mozilla 4.76 [en] (Windows NT 5.0; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Michael Myers <[e-mail]>
CC: [e-mail]
Subject: Re: DPD/DPV Requirements
References: <[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Mike,

Thanks.  But I would still assume that that would also mean a server
would want to say unknown if it could only partially build a path,
(reason "a" below), since "I cannot find the CA certificate of the
certificate in question (ie I know absolutely nothing about the
certificate)" is a subset of "I cannot build a path".

Brian

Michael Myers wrote:
> 
> Brian,
> 
> The reason is, servers (responding parties) need a means to
> escape out of making a definitive assertion to clients (relying
> parties) in the event the server (responding party) knows
> absolutely nothing about the certificate in question.
> 
> Mike
> 
> > "When the certificate is not valid according to the
> > validation policy,
> > then the reason MUST also be indicated. Invalidity
> > reasons include:
> >
> >    a) the DPV server cannot determine the validity of
> > the certificate
> >       because a certification path cannot be constructed.
> >


Received: by above.proper.com (8.11.6/8.11.3) id g4RFGGl13989 for ietf-pkix-bks; Mon, 27 May 2002 08:16:16 -0700 (PDT)
Received: from mail.coastside.net (mail.coastside.net [207.213.212.6]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g4RFGEJ13983 for <[e-mail]>; Mon, 27 May 2002 08:16:15 -0700 (PDT)
Received: from laptop (dsl-63-194-153-52.coastside.net [63.194.153.52]) by poseidon.coastside.net  with SMTP id g4RFGCUg024659; Mon, 27 May 2002 08:16:13 -0700 (PDT)
From: "Michael Myers" <[e-mail]>
To: "Brian Hunter" <[e-mail]>, "Tim Polk" <[e-mail]>
Cc: <[e-mail]>
Subject: RE: DPD/DPV Requirements
Date: Mon, 27 May 2002 08:13:10 -0700
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0)
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
Importance: Normal
In-Reply-To: <[e-mail]>
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Brian,

The reason is, servers (responding parties) need a means to
escape out of making a definitive assertion to clients (relying
parties) in the event the server (responding party) knows
absolutely nothing about the certificate in question.

Mike


> -----Original Message-----
> From: [e-mail]
> [mailto:[e-mail]]On Behalf Of Brian Hunter
> Sent: Monday, May 27, 2002 5:33 AM
> To: Tim Polk
> Cc: [e-mail]
> Subject: Re: DPD/DPV Requirements
>
>
>
> I have a question regarding the valid/invalid/unknown
> status of a DPV
> request.
>
> In 4.1 it states that there are 4 possible status'
> that could be
> returned.  Then 3 possible reasons for invalid are given:
>
> "When the certificate is not valid according to the
> validation policy,
> then the reason MUST also be indicated. Invalidity
> reasons include:
>
>    a) the DPV server cannot determine the validity of
> the certificate
>       because a certification path cannot be constructed.
>
>    b) the DPV server successfully constructed a
> certification path, but
>       it was not valid according to the validation
> algorithm in
>       [PKIX-1].
>
>    c) ... "
>
> The three example reasons seem to be a remnant from
> -03 when there were
> only two states (valid/invalid).  Can someone tell me
> for what reason an
> unknown status would be returned?  I am confused
> because I thought that
> reason "a" would be for unknown and reason "b" would
> be for invalid.
>
> Thanks for the clarification.
> Brian
>
>
> Tim Polk wrote:
> >
> > Folks,
> >
> > I haven't seen any comments on the latest draft of
> the DPD/DPV
> > requirements.  I view this as a sign that consensus
> has been reached, or at
> > least very near.  If I don't see any comments to
> the contrary, I plan on
> > forwarding the document to the Area Directors
> Tuesday morning.
> >
> > Thanks,
> >
> > Tim Polk
>



Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g4RCWii05677 for ietf-pkix-bks; Mon, 27 May 2002 05:32:44 -0700 (PDT)
Received: from sonne.darmstadt.gmd.de (sonne.darmstadt.gmd.de [141.12.62.20]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g4RCWhJ05672 for <[e-mail]>; Mon, 27 May 2002 05:32:43 -0700 (PDT)
Received: from sit.fraunhofer.de (pc-rogerrabbit [141.12.35.140]) by sonne.darmstadt.gmd.de (8.8.8/8.8.5) with ESMTP id OAA20871; Mon, 27 May 2002 14:32:30 +0200 (MET DST)
Message-ID: <[e-mail]>
Date: Mon, 27 May 2002 14:32:42 +0200
From: Brian Hunter <[e-mail]>
X-Mailer: Mozilla 4.76 [en] (Windows NT 5.0; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Tim Polk <[e-mail]>
CC: [e-mail]
Subject: Re: DPD/DPV Requirements
References: <[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

I have a question regarding the valid/invalid/unknown status of a DPV
request.

In 4.1 it states that there are 4 possible status' that could be
returned.  Then 3 possible reasons for invalid are given:

"When the certificate is not valid according to the validation policy, 
then the reason MUST also be indicated. Invalidity reasons include:

   a) the DPV server cannot determine the validity of the certificate 
      because a certification path cannot be constructed.

   b) the DPV server successfully constructed a certification path, but
      it was not valid according to the validation algorithm in 
      [PKIX-1].

   c) ... "

The three example reasons seem to be a remnant from -03 when there were
only two states (valid/invalid).  Can someone tell me for what reason an
unknown status would be returned?  I am confused because I thought that
reason "a" would be for unknown and reason "b" would be for invalid.

Thanks for the clarification.
Brian


Tim Polk wrote:
> 
> Folks,
> 
> I haven't seen any comments on the latest draft of the DPD/DPV
> requirements.  I view this as a sign that consensus has been reached, or at
> least very near.  If I don't see any comments to the contrary, I plan on
> forwarding the document to the Area Directors Tuesday morning.
> 
> Thanks,
> 
> Tim Polk


Received: by above.proper.com (8.11.6/8.11.3) id g4R7oh110293 for ietf-pkix-bks; Mon, 27 May 2002 00:50:43 -0700 (PDT)
Received: from stdout ([61.74.133.2]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g4R7ocJ10288 for <[e-mail]>; Mon, 27 May 2002 00:50:42 -0700 (PDT)
Received: from nugen.initech.com ([61.74.133.14] helo=chkimw2k) by stdout with smtp (Exim 3.35 #1 (Debian)) id 17CF8w-0004zg-00 for <[e-mail]>; Mon, 27 May 2002 16:42:14 +0900
Message-ID: <003301c20553$41033970$0e854a3d@chkimw2k>
From: "ChungKil Kim" <[e-mail]>
To: <[e-mail]>
References: <[e-mail]>
Subject: Re: timeStamp vs electronic notary
Date: Mon, 27 May 2002 16:51:04 +0900
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.50.4807.1700
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from base64 to 8bit by above.proper.com id g4R7ohJ10290
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

timeStamp would be used in electonic notray system.
timeStamp is software protocol subsystem of electonic notray.

----- Original Message ----- 
From: "Pere Fiol" <[e-mail]>
To: <[e-mail]>
Sent: Friday, May 24, 2002 8:24 PM
Subject: timeStamp vs electronic notary


> 
> Hi,
> 
> I would like to know the differences between the services: timeStamp &
> electronic notary. Moreover, I know that TimeStamp is described in RFC3161,
> but is defined in some place the Electronic Notary service??
> 
> Thanks in advance,
> Pere


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g4OLVuQ27224 for ietf-pkix-bks; Fri, 24 May 2002 14:31:56 -0700 (PDT)
Received: from gonzo.aus.rsa.com (mail.rsasecurity.com.au [203.46.112.10]) by above.proper.com (8.11.6/8.11.3) with SMTP id g4OLVsL27219 for <[e-mail]>; Fri, 24 May 2002 14:31:54 -0700 (PDT)
Received: from grover by gonzo.aus.rsa.com via smtpd (for mail.imc.org [208.184.76.43]) with SMTP; 24 May 2002 21:32:23 UT
Received: from exaus01.local.aus.rsa.com (exaus01.local.aus.rsa.com [10.177.1.15]) by grover.local.aus.rsa.com (8.10.2/8.10.2) with ESMTP id g4OLatq05619 for <[e-mail]>; Sat, 25 May 2002 07:36:55 +1000 (EST)
Received: by exaus01.local.aus.rsa.com with Internet Mail Service (5.5.2653.19) id <K11DW073>; Sat, 25 May 2002 07:31:35 +1000
Received: from HOUSLEY-LAP.rsasecurity.com (HOUSLEY-LAP [10.3.9.8]) by exna00.securitydynamics.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id K2ZLGTCC; Fri, 24 May 2002 17:31:06 -0400
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Version 5.1
Date: Fri, 24 May 2002 17:31:03 -0400
To: [e-mail]
From: "Housley, Russ" <[e-mail]>
Subject: Re: WG Last Call: Permanent Identifier
In-Reply-To: <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

I have several comments on the Permanent Identifier Draft.  I have divided 
them between technical and editorial.

TECHNICAL

1.  The OID value { id-on 2 } has already been assigned for another 
purpose.  Please get fresh one.

2.  It is my understanding that international URIs can be encoded as 
IA5String.  This was one of the last issues raised in the development of 
RFC 3280.

3.  I do not understand how the identifierType can be optional.  The whole 
point of this draft is that distinguished names are not sufficiently 
unique.  (I am not trying to reopen this debate; it has been debated at too 
great a length already.)  If this is the case, then it would follow that 
two CAs could have the same distinguished name.  If two such CAs both 
include the proposed extension, then there will be undetectable 
collisions.  The resolution seem to be clear.  Make the identifierType 
mandatory.

4.  The Security Considerations section is pretty weak.  It mostly restated 
the purpose of the extension.  I think that it should contain advice for 
implementors that will make use of the identifier as well as advice for the 
Assigner Authority.  For example, the Social Security Administration would 
be such an authority in the US, and they assign nine digit 
indentifiers.  Are 123-45-6789 and 123456789 the same?

EDITORIAL

5.  Please move the reference to RFC 2119 out of the Abstract.  I think it 
belongs in the Introduction.

6.  Please reference RFC 3280 instead of RFC 2459.

7.  In the second paragraph of the Introduction, the word "it" is 
ambiguous.  I think that it is referring to the subject field.  Please reword.

8.  The document contains many non-ASCII characters.  Please replace the 
"smart" apostrophe and quote characters.

9.  Please change "non repudiation" to "non-repudiation"

10.  Please change "optional" to "OPTIONAL" in the second paragraph of 
section 2.

11.  Please divide the references into two groups: normative and informative.

Thanks,
   Russ



Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g4OL4sG26522 for ietf-pkix-bks; Fri, 24 May 2002 14:04:54 -0700 (PDT)
Received: from vulcan.rsasecurity.com (mail.rsasecurity.com [204.167.114.123]) by above.proper.com (8.11.6/8.11.3) with SMTP id g4OL4qL26518 for <[e-mail]>; Fri, 24 May 2002 14:04:52 -0700 (PDT)
Received: from no.name.available by vulcan.rsasecurity.com via smtpd (for mail.imc.org [208.184.76.43]) with SMTP; 24 May 2002 21:03:04 UT
Received: from ebola.securitydynamics.com (ebola.securid.com [192.80.211.4]) by sdtihq24.securid.com (Pro-8.9.3/Pro-8.9.3) with ESMTP id RAA29078 for <[e-mail]>; Fri, 24 May 2002 17:04:54 -0400 (EDT)
Received: from exeu00.securid.com (localhost [127.0.0.1]) by ebola.securitydynamics.com (8.10.2+Sun/8.10.2) with ESMTP id g4OL32C01559 for <[e-mail]>; Fri, 24 May 2002 17:03:02 -0400 (EDT)
Received: by exeu00.eu.rsa.net with Internet Mail Service (5.5.2653.19) id <LC0BB5DC>; Fri, 24 May 2002 22:05:14 +0100
Received: from HOUSLEY-LAP.rsasecurity.com (HOUSLEY-LAP [10.3.9.8]) by exna00.securitydynamics.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id K2ZLGS6Y; Fri, 24 May 2002 17:04:42 -0400
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Version 5.1
X-Priority: 1 (Highest)
Date: Fri, 24 May 2002 17:04:39 -0400
To: [e-mail]
From: "Housley, Russ" <[e-mail]>
Subject: Re: WG Last Call: Permanent Identifier
In-Reply-To: <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

All PKIX Members:

DO NOT USE THE OBJECT IDENTIFIER IN draft-ietf-pkix-pi-03.txt!  THE OBJECT 
IDENTIFER WAS ASSIGNED BY THE AUTHORS, NOT BY THE REGISTRAR.  THE VALUE IN 
QUESTION HAS ALREADY BEEN ASSIGNED FOR ANOTHER PURPOSE.

Please send mail to [e-mail] if you need to get an object 
identifier assigned by the PKIX Registrar.  I assume I will be hearing from 
the authors of draft-ietf-pkix-pi-03.txt soon ...

Thanks for your cooperation,
   Russ

At 03:55 PM 5/24/2002 -0400, Tim Polk wrote:


>Folks,
>
>The current version of the Permanent Identifier is ready for Working Group 
>Last Call; Last Call will close on or after June 7, 2001.
>
>The draft is named draft-ietf-pkix-pi-03.txt.  The text has been posted 
>and is available from the usual repositories, including: 
>http://www.ietf.org/internet-drafts/draft-ietf-pkix-pi-03.txt
>
>The current thinking is to progress the document as a standards track 
>document.
>
>Thanks,
>
>Tim Polk


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g4OJvph25360 for ietf-pkix-bks; Fri, 24 May 2002 12:57:51 -0700 (PDT)
Received: from email.nist.gov (email.nist.gov [129.6.2.7]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g4OJvoL25355 for <[e-mail]>; Fri, 24 May 2002 12:57:50 -0700 (PDT)
Received: from st25 (st25.ncsl.nist.gov [129.6.54.67]) by email.nist.gov (8.12.2/8.12.2) with ESMTP id g4OJvp87020711 for <[e-mail]>; Fri, 24 May 2002 15:57:52 -0400 (EDT)
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58 
Date: Fri, 24 May 2002 15:55:36 -0400
To: [e-mail]
From: Tim Polk <[e-mail]>
Subject: WG Last Call: Permanent Identifier
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Folks,

The current version of the Permanent Identifier is ready for Working Group 
Last Call; Last Call will close on or after June 7, 2001.

The draft is named draft-ietf-pkix-pi-03.txt.  The text has been posted and 
is available from the usual repositories, including: 
http://www.ietf.org/internet-drafts/draft-ietf-pkix-pi-03.txt

The current thinking is to progress the document as a standards track document.

Thanks,

Tim Polk 


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g4OFnrO17810 for ietf-pkix-bks; Fri, 24 May 2002 08:49:53 -0700 (PDT)
Received: from edelweb.fr (edelweb.fr [212.234.46.16]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g4OFnnL17806 for <[e-mail]>; Fri, 24 May 2002 08:49:49 -0700 (PDT)
Received: from champagne.edelweb.fr (localhost.edelweb.fr [127.0.0.1]) by edelweb.fr with ESMTP id RAA22605; Fri, 24 May 2002 17:49:38 +0200 (MET DST)
Received: from champagne.edelweb.fr (champagne.edelweb.fr [193.51.14.161]) by edelweb.fr (nospam/1.5); Fri, 24 May 2002 17:49: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 RAA15544; Fri, 24 May 2002 17:49:37 +0200 (MET DST)
From: Peter Sylvester <[e-mail]>
Received: (sylvest@localhost) by emeriau.edelweb.fr (8.7.6/8.6.6) id RAA22647; Fri, 24 May 2002 17:49:37 +0200 (MET DST)
Date: Fri, 24 May 2002 17:49:37 +0200 (MET DST)
Message-Id: <[e-mail]>
To: [e-mail], [e-mail]
Subject: Re: DPD/DPV Requirements
Cc: [e-mail], [e-mail]
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

> > 
> > - It is a matter of local configuration of a client to
> >   match a server identifier with a identifier associated
> >   to an authentication method, e.g., a signature.

If you mean that 'signature' should be replaced by 'signature
together with trustworthy public key certificate containing one
or more identifiers ...', note that this is an 'e.g.', so I 
leave it to you (Denis and Russ) whatever you want to use as 
unambiguous phrase.




Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g4OFMKV17246 for ietf-pkix-bks; Fri, 24 May 2002 08:22:20 -0700 (PDT)
Received: from odin2.bull.net (odin2.bull.net [192.90.70.84]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g4OFMJL17241 for <[e-mail]>; Fri, 24 May 2002 08:22:19 -0700 (PDT)
Received: from lvn-m002.frlv.bull.fr (lvn-m002.frlv.bull.fr [129.184.62.72]) by odin2.bull.net (8.9.3/8.9.3) with ESMTP id RAA17118; Fri, 24 May 2002 17:25:31 +0200
Received: from bull.net ([129.184.37.97]) by lvn-m002.frlv.bull.fr (Lotus Domino Release 5.0.8) with ESMTP id 2002052417220760:251 ; Fri, 24 May 2002 17:22:07 +0200 
Message-ID: <[e-mail]>
Date: Fri, 24 May 2002 17:22:02 +0200
From: Denis Pinkas <[e-mail]>
Organization: Bull SA.
X-Mailer: Mozilla 4.7 [fr] (Win98; I)
X-Accept-Language: fr
MIME-Version: 1.0
To: Peter Sylvester <[e-mail]>
CC: [e-mail], [e-mail]
Subject: Re: DPD/DPV Requirements
References: <[e-mail]>
X-MIMETrack: Itemize by SMTP Server on LVN-M002/FR/BULL(Release 5.0.8 |June 18, 2001) at 24/05/2002 17:22:07, Serialize by Router on LVN-M002/FR/BULL(Release 5.0.8 |June 18, 2001) at 24/05/2002 17:22:11, Serialize complete at 24/05/2002 17:22:11
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset=us-ascii
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Peter,

> > I would rather change the whole paragraph into:
> >
> >     For the client to be able prove to a third party that trusts the
> >     same DPV server that the certificate validation was handled correctly,
> >     the DPV response MUST be digitally signed and include a DPV certificate
> >     identifier, unless an error is reported.
> 
> IMO there are independant requirements:
> 
> - A method to enable response authentication by a third party
>   or by the client. An example is a digital signature.
>
> - Independantly of that the server can include an identity,
>   and it is a matter of policy or local client(s) configuration
>   about how this identification plays a role to authenticate
>   a response.

A digital signature by itself does not allow to authenticate a client,
unless you can reliably know the public key to be used to verify the digital
signature. Since we are writing this specification for an open environment,
including the identifier of a DPV certificate provides such a reliable link.
This is what meant the previous sentence: "The DPV server's certificate MUST
authenticate the DPV server".

Denis

> If one needs more text than what Russ has proposed, then I'd say:
> 
> - A client SHOULD be able to indicate to the server in its
>   request the identity or identities of server that it
>   believe SHOULD contribute to the service.
> 
> - A server MAY or may not honour these identifications.
> 
> - A server SHOULD be able to indicate in the response the
>   identities of the servers that participated in providing
>   the service.
> 
> - It is a matter of local configuration of a client to
>   match a server identifier with a identifier associated
>   to an authentication method, e.g., a signature.
> 
> Peter


Received: by above.proper.com (8.11.6/8.11.3) id g4OFDDe17066 for ietf-pkix-bks; Fri, 24 May 2002 08:13:13 -0700 (PDT)
Received: from edelweb.fr (edelweb.fr [212.234.46.16]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g4OFD9L17061 for <[e-mail]>; Fri, 24 May 2002 08:13:09 -0700 (PDT)
Received: from champagne.edelweb.fr (localhost.edelweb.fr [127.0.0.1]) by edelweb.fr with ESMTP id RAA22402; Fri, 24 May 2002 17:13:00 +0200 (MET DST)
Received: from champagne.edelweb.fr (champagne.edelweb.fr [193.51.14.161]) by edelweb.fr (nospam/1.5); Fri, 24 May 2002 17:13:00 +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 RAA15383; Fri, 24 May 2002 17:12:59 +0200 (MET DST)
From: Peter Sylvester <[e-mail]>
Received: (sylvest@localhost) by emeriau.edelweb.fr (8.7.6/8.6.6) id RAA22633; Fri, 24 May 2002 17:12:58 +0200 (MET DST)
Date: Fri, 24 May 2002 17:12:58 +0200 (MET DST)
Message-Id: <[e-mail]>
To: [e-mail], [e-mail], [e-mail]
Subject: Re: DPD/DPV Requirements
Cc: [e-mail]
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

> 
> I would rather change the whole paragraph into:
> 
>     For the client to be able prove to a third party that trusts the
>     same DPV server that the certificate validation was handled correctly,
>     the DPV response MUST be digitally signed and include a DPV certificate 
>     identifier, unless an error is reported.


IMO there are independant requirements: 

- A method to enable response authentication by a third party
  or by the client. An example is a digital signature.

- Independantly of that the server can include an identity,
  and it is a matter of policy or local client(s) configuration
  about how this identification plays a role to authenticate
  a response.

If one needs more text than what Russ has proposed, then I'd say:

- A client SHOULD be able to indicate to the server in its
  request the identity or identities of server that it
  believe SHOULD contribute to the service. 

- A server MAY or may not honour these identifications.

- A server SHOULD be able to indicate in the response the
  identities of the servers that participated in providing
  the service.

- It is a matter of local configuration of a client to
  match a server identifier with a identifier associated
  to an authentication method, e.g., a signature. 

Peter






Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g4OEpPs16258 for ietf-pkix-bks; Fri, 24 May 2002 07:51:25 -0700 (PDT)
Received: from odin2.bull.net (odin2.bull.net [192.90.70.84]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g4OEpNL16254 for <[e-mail]>; Fri, 24 May 2002 07:51:23 -0700 (PDT)
Received: from lvn-m002.frlv.bull.fr (lvn-m002.frlv.bull.fr [129.184.62.72]) by odin2.bull.net (8.9.3/8.9.3) with ESMTP id QAA26264; Fri, 24 May 2002 16:54:35 +0200
Received: from bull.net ([129.184.37.97]) by lvn-m002.frlv.bull.fr (Lotus Domino Release 5.0.8) with ESMTP id 2002052416505604:244 ; Fri, 24 May 2002 16:50:56 +0200 
Message-ID: <[e-mail]>
Date: Fri, 24 May 2002 16:50:52 +0200
From: Denis Pinkas <[e-mail]>
Organization: Bull SA.
X-Mailer: Mozilla 4.7 [fr] (Win98; I)
X-Accept-Language: fr
MIME-Version: 1.0
To: "Housley, Russ" <[e-mail]>, Peter Sylvester <[e-mail]>
CC: [e-mail]
Subject: Re: DPD/DPV Requirements
References: <[e-mail]>
X-MIMETrack: Itemize by SMTP Server on LVN-M002/FR/BULL(Release 5.0.8 |June 18, 2001) at 24/05/2002 16:50:56, Serialize by Router on LVN-M002/FR/BULL(Release 5.0.8 |June 18, 2001) at 24/05/2002 16:51:15, Serialize complete at 24/05/2002 16:51:15
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset=us-ascii
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Peter and Russ,
 
> Peter:
> 
> >- It would be nice if the 'smart' apostrophes could be avoided.
> 
> Thanks for point this out, it is easy to fix.
> 
> >  - The text does not include a requirement that a server should
> >   be able to indicate in the response its identity.
> >   This is symmetric to the requirement to allow an identity
> >   for the client (and the rationale is similar).
> >
> >   I thought this was clear in the example:
> >
> >"We, the President of Unites States, and the General Secretary of
> >  the United Nation", certify to you, President of France, President
> >  of the French General assembly, and president of the French Senate,
> >  the the certificate XXYZ can be used by you as a strong authentication
> >  method to demand deployment of a combined UN ad US forces on May 5
> >  according to plan LEF".
> 
> The paragraphs in question say:
> 
>    For the client to be confident that the certificate validation was
>    handled by the expected DPV server, the DPV response MUST be
>    authenticated, unless an error is reported (such as a badly formatted
>    request or unknown validation policy).
> 
>    For the client to be able prove to a third party that trusts the
>    same DPV server that the certificate validation was handled correctly,
>    the DPV response MUST be digitally signed, unless an error is reported.
>    The DPV server's certificate MUST authenticate the DPV server.
> 
>    The DPV server MAY require client authentication, therefore, the DPV
>    request MUST be able to be authenticated.
> 
>    When the DPV request is authenticated, the client SHOULD be able to
>    include a client identifier in the request for the DPV server to copy
>    into the response. Mechanisms for matching this identifier with the
>    authenticated identity depends on local DPV server conditions and/or
>    the validation policy. The DPV server MAY choose to blindly copy the
>    identifier, omit the identifier, or return an error response.
 
> I suggest that we add the following sentence to the end of the 2nd
> paragraph above:
> 
>    The DPV server SHOULD be able to include a server identifier in the
> response.

It is not clear to me in this additional sentence what a "server identifier"
would be. Given that the previous sentence says:
   
The DPV server's certificate MUST authenticate the DPV server.

I would rather change the whole paragraph into:

    For the client to be able prove to a third party that trusts the
    same DPV server that the certificate validation was handled correctly,
    the DPV response MUST be digitally signed and include a DPV certificate 
    identifier, unless an error is reported.

Denis
 
> Russ


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g4ODu6T14109 for ietf-pkix-bks; Fri, 24 May 2002 06:56:06 -0700 (PDT)
Received: from edelweb.fr (edelweb.fr [212.234.46.16]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g4ODu3L14098 for <[e-mail]>; Fri, 24 May 2002 06:56:04 -0700 (PDT)
Received: from champagne.edelweb.fr (localhost.edelweb.fr [127.0.0.1]) by edelweb.fr with ESMTP id PAA22049; Fri, 24 May 2002 15:55:53 +0200 (MET DST)
Received: from champagne.edelweb.fr (champagne.edelweb.fr [193.51.14.161]) by edelweb.fr (nospam/1.5); Fri, 24 May 2002 15:55: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 PAA14956; Fri, 24 May 2002 15:55:51 +0200 (MET DST)
From: Peter Sylvester <[e-mail]>
Received: (sylvest@localhost) by emeriau.edelweb.fr (8.7.6/8.6.6) id PAA22609; Fri, 24 May 2002 15:55:50 +0200 (MET DST)
Date: Fri, 24 May 2002 15:55:50 +0200 (MET DST)
Message-Id: <[e-mail]>
To: [e-mail], [e-mail]
Subject: Re: DPD/DPV Requirements
Cc: [e-mail]
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

> 
> I suggest that we add the following sentence to the end of the 2nd 
> paragraph above:
> 
>    The DPV server SHOULD be able to include a server identifier in the 
> response.

Ok. 


Received: by above.proper.com (8.11.6/8.11.3) id g4ODpvp13515 for ietf-pkix-bks; Fri, 24 May 2002 06:51:57 -0700 (PDT)
Received: from vulcan.rsasecurity.com (mail.rsasecurity.com [204.167.114.123]) by above.proper.com (8.11.6/8.11.3) with SMTP id g4ODptL13509 for <[e-mail]>; Fri, 24 May 2002 06:51:55 -0700 (PDT)
Received: from no.name.available by vulcan.rsasecurity.com via smtpd (for mail.imc.org [208.184.76.43]) with SMTP; 24 May 2002 13:50:05 UT
Received: from ebola.securitydynamics.com (ebola.securid.com [192.80.211.4]) by sdtihq24.securid.com (Pro-8.9.3/Pro-8.9.3) with ESMTP id JAA24233 for <[e-mail]>; Fri, 24 May 2002 09:51:55 -0400 (EDT)
Received: from exna00.securitydynamics.com (localhost [127.0.0.1]) by ebola.securitydynamics.com (8.10.2+Sun/8.10.2) with ESMTP id g4ODo3X18535 for <[e-mail]>; Fri, 24 May 2002 09:50:03 -0400 (EDT)
Received: by exna00.securitydynamics.com with Internet Mail Service (5.5.2653.19) id <K2ZLGMQB>; Fri, 24 May 2002 09:51:54 -0400
Received: from HOUSLEY-LAP.rsasecurity.com (HOUSLEY-LAP [10.3.9.8]) by exna00.securitydynamics.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id K2ZLGMP0; Fri, 24 May 2002 09:51:49 -0400
From: "Housley, Russ" <[e-mail]>
To: Peter Sylvester <[e-mail]>
Cc: [e-mail]
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Version 5.1
Date: Fri, 24 May 2002 09:51:38 -0400
Subject: Re: DPD/DPV Requirements
In-Reply-To: <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Peter:

>- It would be nice if the 'smart' apostrophes could be avoided.

Thanks for point this out, it is easy to fix.


>  - The text does not include a requirement that a server should
>   be able to indicate in the response its identity.
>   This is symmetric to the requirement to allow an identity
>   for the client (and the rationale is similar).
>
>   I thought this was clear in the example:
>
>"We, the President of Unites States, and the General Secretary of
>  the United Nation", certify to you, President of France, President
>  of the French General assembly, and president of the French Senate,
>  the the certificate XXYZ can be used by you as a strong authentication
>  method to demand deployment of a combined UN ad US forces on May 5
>  according to plan LEF".

The paragraphs in question say:

   For the client to be confident that the certificate validation was
   handled by the expected DPV server, the DPV response MUST be
   authenticated, unless an error is reported (such as a badly formatted
   request or unknown validation policy).

   For the client to be able prove to a third party that trusts the
   same DPV server that the certificate validation was handled correctly,
   the DPV response MUST be digitally signed, unless an error is reported.
   The DPV server's certificate MUST authenticate the DPV server.

   The DPV server MAY require client authentication, therefore, the DPV
   request MUST be able to be authenticated.

   When the DPV request is authenticated, the client SHOULD be able to
   include a client identifier in the request for the DPV server to copy
   into the response. Mechanisms for matching this identifier with the
   authenticated identity depends on local DPV server conditions and/or
   the validation policy. The DPV server MAY choose to blindly copy the
   identifier, omit the identifier, or return an error response.

I suggest that we add the following sentence to the end of the 2nd 
paragraph above:

   The DPV server SHOULD be able to include a server identifier in the 
response.

Russ


Received: by above.proper.com (8.11.6/8.11.3) id g4OBPkR05337 for ietf-pkix-bks; Fri, 24 May 2002 04:25:46 -0700 (PDT)
Received: from amatabogados.com ([213.229.156.26]) by above.proper.com (8.11.6/8.11.3) with SMTP id g4OBPiL05327 for <[e-mail]>; Fri, 24 May 2002 04:25:44 -0700 (PDT)
Received: from gandalf [213.96.78.77] by amatabogados.com (SMTPD32-4.07) id A2DE3FD025E; Fri, 24 May 2002 13:24:14 +0100
From: "Pere Fiol" <[e-mail]>
To: <[e-mail]>
Subject: timeStamp vs electronic notary
Date: Fri, 24 May 2002 13:24:18 +0200
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.2911.0)
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700
Importance: Normal
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Hi,

I would like to know the differences between the services: timeStamp &
electronic notary. Moreover, I know that TimeStamp is described in RFC3161,
but is defined in some place the Electronic Notary service??

Thanks in advance,
Pere



Received: by above.proper.com (8.11.6/8.11.3) id g4O9hHZ29321 for ietf-pkix-bks; Fri, 24 May 2002 02:43:17 -0700 (PDT)
Received: from web20004.mail.yahoo.com (web20004.mail.yahoo.com [216.136.225.49]) by above.proper.com (8.11.6/8.11.3) with SMTP id g4O9hGL29317 for <[e-mail]>; Fri, 24 May 2002 02:43:16 -0700 (PDT)
Message-ID: <[e-mail]>
Received: from [202.144.45.2] by web20004.mail.yahoo.com via HTTP; Fri, 24 May 2002 02:43:16 PDT
Date: Fri, 24 May 2002 02:43:16 -0700 (PDT)
From: vivek saraf <[e-mail]>
Subject: Re: About Certificate extention
To: narendra <[e-mail]>, Ietf-Pkix <[e-mail]>
In-Reply-To: <[e-mail]>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="0-478967902-1022233396=:98712"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

--0-478967902-1022233396=:98712
Content-Type: text/plain; charset=us-ascii


 You can directly start from rfc 3280.......
The certificate extensions are explanied in detail in rfc 3280 in section 4.2
  narendra <[e-mail]> wrote: 
Dear Group Member,
There are two questions.
Q:-1 I have got two rfcs 2459 and 3280 for publick key infrastructure.In
rfc 3280 there is written that it obsolutes 2459. So i am studing rfc 3280.
Question is
"Should i read 2459 first 2459 then move to 3280 or continue with 3280?

Q:- While studing rfc 3280 i do come across CERTIFICATE EXTENCTIONS, What
this terms specifies?


Seeking your co-opertaion,
narendra.



--------------------------------------------
Parmar Narendrasinh Abhesinh
Numen Technologies Pvt.Ltd,
505 "ADITYA"
Opp.Sardar Patel Seva Samaj,
Off.C.G.Road,Ahmedabd-380 006
Phone no:- [phone]/6466310 ex-46,47,48





---------------------------------
Do You Yahoo!?
LAUNCH - Your Yahoo! Music Experience
--0-478967902-1022233396=:98712
Content-Type: text/html; charset=us-ascii

<P>&nbsp;You can directly start from rfc 3280.......
<P>The certificate extensions are explanied in detail in rfc 3280 in section 4.2
<P>&nbsp; <B><I>narendra &lt;[e-mail]&gt;</I></B> wrote: 
<BLOCKQUOTE style="PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #1010ff 2px solid"><BR>Dear Group Member,<BR>There are two questions.<BR>Q:-1 I have got two rfcs 2459 and 3280 for publick key infrastructure.In<BR>rfc 3280 there is written that it obsolutes 2459. So i am studing rfc 3280.<BR>Question is<BR>"Should i read 2459 first 2459 then move to 3280 or continue with 3280?<BR><BR>Q:- While studing rfc 3280 i do come across CERTIFICATE EXTENCTIONS, What<BR>this terms specifies?<BR><BR><BR>Seeking your co-opertaion,<BR>narendra.<BR><BR><BR><BR>--------------------------------------------<BR>Parmar Narendrasinh Abhesinh<BR>Numen Technologies Pvt.Ltd,<BR>505 "ADITYA"<BR>Opp.Sardar Patel Seva Samaj,<BR>Off.C.G.Road,Ahmedabd-380 006<BR>Phone no:- [phone]/6466310 ex-46,47,48<BR><BR><BR></BLOCKQUOTE><p><br><hr size=1><b>Do You Yahoo!?</b><br>
<a href="http://rd.yahoo.com/welcome/*http://launch.yahoo.com">LAUNCH</a> - Your Yahoo! Music Experience
--0-478967902-1022233396=:98712--


Received: by above.proper.com (8.11.6/8.11.3) id g4O9O3C28939 for ietf-pkix-bks; Fri, 24 May 2002 02:24:03 -0700 (PDT)
Received: from edelweb.fr (edelweb.fr [212.234.46.16]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g4O9O1L28935 for <[e-mail]>; Fri, 24 May 2002 02:24:01 -0700 (PDT)
Received: from champagne.edelweb.fr (localhost.edelweb.fr [127.0.0.1]) by edelweb.fr with ESMTP id LAA21089; Fri, 24 May 2002 11:23:59 +0200 (MET DST)
Received: from champagne.edelweb.fr (champagne.edelweb.fr [193.51.14.161]) by edelweb.fr (nospam/1.5); Fri, 24 May 2002 11:23: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 LAA14416; Fri, 24 May 2002 11:23:58 +0200 (MET DST)
From: Peter Sylvester <[e-mail]>
Received: (sylvest@localhost) by emeriau.edelweb.fr (8.7.6/8.6.6) id LAA22550; Fri, 24 May 2002 11:23:58 +0200 (MET DST)
Date: Fri, 24 May 2002 11:23:58 +0200 (MET DST)
Message-Id: <[e-mail]>
To: [e-mail], [e-mail]
Subject: Re: DPD/DPV Requirements
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

- It would be nice if the 'smart' apostrophes could be avoided.
 
- The text does not include a requirement that a server should
  be able to indicate in the response its identity. 
  This is symmetric to the requirement to allow an identity
  for the client (and the rationale is similar).

  I thought this was clear in the example: 

"We, the President of Unites States, and the General Secretary of
 the United Nation", certify to you, President of France, President
 of the French General assembly, and president of the French Senate,
 the the certificate XXYZ can be used by you as a strong authentication 
 method to demand deployment of a combined UN ad US forces on May 5 
 according to plan LEF". 


> 
> 
> Folks,
> 
> I haven't seen any comments on the latest draft of the DPD/DPV 
> requirements.  I view this as a sign that consensus has been reached, or at 
> least very near.  If I don't see any comments to the contrary, I plan on 
> forwarding the document to the Area Directors Tuesday morning.
> 
> Thanks,
> 
> Tim Polk
> 


Received: by above.proper.com (8.11.6/8.11.3) id g4O9Cv728284 for ietf-pkix-bks; Fri, 24 May 2002 02:12:57 -0700 (PDT)
Received: from odin2.bull.net (odin2.bull.net [192.90.70.84]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g4O9CtL28275 for <[e-mail]>; Fri, 24 May 2002 02:12:55 -0700 (PDT)
Received: from lvn-m002.frlv.bull.fr (lvn-m002.frlv.bull.fr [129.184.62.72]) by odin2.bull.net (8.9.3/8.9.3) with ESMTP id LAA16368; Fri, 24 May 2002 11:16:10 +0200
Received: from bull.net ([129.184.37.97]) by lvn-m002.frlv.bull.fr (Lotus Domino Release 5.0.8) with ESMTP id 2002052411123853:169 ; Fri, 24 May 2002 11:12:38 +0200 
Message-ID: <[e-mail]>
Date: Fri, 24 May 2002 11:12:38 +0200
From: Denis Pinkas <[e-mail]>
Organization: Bull SA.
X-Mailer: Mozilla 4.7 [fr] (Win98; I)
X-Accept-Language: fr
MIME-Version: 1.0
To: narendra <[e-mail]>
CC: Ietf-Pkix <[e-mail]>
Subject: Re: About Time Stamp
References: <[e-mail]>
X-MIMETrack: Itemize by SMTP Server on LVN-M002/FR/BULL(Release 5.0.8 |June 18, 2001) at 24/05/2002 11:12:38, Serialize by Router on LVN-M002/FR/BULL(Release 5.0.8 |June 18, 2001) at 24/05/2002 11:12:51, Serialize complete at 24/05/2002 11:12:51
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset=us-ascii
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

> Dear Group Members,

>    What is time stamping in PKI? 

See RFC 3161 
http://www.imc.org/rfc3161

and also

Policy Requirements for Time-Stamping Authorities
http://www.imc.org/draft-ietf-pkix-pr-tsa

> where is it used and how ?

It can be used in various contexts. A typical use is to time-stamp a digital
signature, so that an upper limit of when the signature has been done can be
known. Then it can be known whether the signature has been applied while the
certificate was valid or not.

Denis

> seeking your co-operation,
> naredra.
> 
> --------------------------------------------
> Parmar Narendrasinh Abhesinh
> Numen Technologies Pvt.Ltd,
> 505 "ADITYA"
> Opp.Sardar Patel Seva Samaj,
> Off.C.G.Road,Ahmedabd-380 006
> Phone no:- [phone]/6466310 ex-46,47,48
> 
>


Received: by above.proper.com (8.11.6/8.11.3) id g4O3BUI21988 for ietf-pkix-bks; Thu, 23 May 2002 20:11:30 -0700 (PDT)
Received: from zetnet.co.uk ([e-mail] [194.247.47.48]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g4O3BQL21977 for <[e-mail]>; Thu, 23 May 2002 20:11:26 -0700 (PDT)
Received: from zetnet.co.uk (bts-0382.dialup.zetnet.co.uk [194.247.49.126]) by zetnet.co.uk (8.11.3/8.11.3/Debian 8.11.2-1) with ESMTP id g4O3BQc12354; Fri, 24 May 2002 04:11:26 +0100
Message-ID: <[e-mail]>
Date: Fri, 24 May 2002 03:31:19 +0000
From: David Hopwood <[e-mail]>
X-Mailer: Mozilla 4.7 [en] (WinNT; I)
X-Accept-Language: en-GB,en,fr-FR,fr,de-DE,de,ru
MIME-Version: 1.0
To: [e-mail]
CC: [e-mail], [e-mail]
Subject: Re: application/pkix-pkipath
References: <[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

-----BEGIN PGP SIGNED MESSAGE-----

Peter Williams wrote:
> All certs must comply with PKIX, it says. There are very real
> communities of TLS users who use a non-PKIX profile of certs.

- From RFC 2246, section 7.4.2:

# All certificate profiles, key and cryptographic formats are defined
# by the IETF PKIX working group [ref. to RFC 2459].

(In context, this applies only to X.509 formats. If other formats were
added they obviously wouldn't be defined by PKIX. This should be made
clearer in RFC2246-bis.)

Which communities of TLS users are (deliberately, rather than just as
a result of bugs) using non-PKIX-conformant X.509 certs, and why?

> They should not be excluded from the use of the TLS proposed extensions.
> There is nothing inherent in the nature of TLS or the extended handling
> that requires that PKIX-designated controls be enforced.

That's true, but specifying PKIX improves interoperability. It's not a
new requirement; it is just clarifying how a requirement that is already
in RFC 2246 applies for this type.

> TLS should continue to be able to maintain current
> interoperability AND exploit some of the newer extensions
> even when certificates are not the means of distributing
> public keys for the asymmetric cipher suites, as per
> traditional SSL design.

We (the extensions spec authors) were very careful not to do anything that
would preclude or create problems for other public key authentication
methods than X.509 certs. I don't see any good argument for using
non-PKIX X.509 certs, though.

- -- 
David Hopwood <[e-mail]>

Home page & PGP public key: http://www.users.zetnet.co.uk/hopwood/
RSA 2048-bit; fingerprint 71 8E A6 23 0E D3 4C E5  0F 69 8C D4 FA 66 15 01
Nothing in this message is intended to be legally binding. If I revoke a
public key but refuse to specify why, it is because the private key has been
seized under the Regulation of Investigatory Powers Act; see www.fipr.org/rip


-----BEGIN PGP SIGNATURE-----
Version: 2.6.3i
Charset: noconv

iQEVAwUBPO2zqjkCAxeYt5gVAQERdggAx5oxAZx9tm0NU1vjyfmjBbDShVAGyhkd
6Iw+sMVPIErBop61mE+8EC3vnM33yBD3fCQxWtE1L1a3LukxbKvlKzMZdl+GzIEk
HJ93K42IC9xdw4yu32tGLFZhr3zMtM4nPCsowctQ5EirwNWQ2qGGGPHosgV3eIPV
36W3ZQWozKsayJM4+HLQLLpGMpEW221jMgYlyAGcwbyeXLZq9IaVud7Rbx4tVL5k
lDnzQ1zSbwkvhCfTLehv2UHsvkLg8rhYCWsurU5lXxQR71wEBOBnNawy9mbltKCi
r8ih+FGAMS4VWRA3PxGdW42A5iurW/ugC5HGFaCgDS9Q+acaE+28FQ==
=aNbk
-----END PGP SIGNATURE-----


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g4O34Ra21781 for ietf-pkix-bks; Thu, 23 May 2002 20:04:27 -0700 (PDT)
Received: from zetnet.co.uk ([e-mail] [194.247.47.48]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g4O34PL21776 for <[e-mail]>; Thu, 23 May 2002 20:04:26 -0700 (PDT)
Received: from zetnet.co.uk (bts-0382.dialup.zetnet.co.uk [194.247.49.126]) by zetnet.co.uk (8.11.3/8.11.3/Debian 8.11.2-1) with ESMTP id g4O34Pc11209; Fri, 24 May 2002 04:04:25 +0100
Message-ID: <[e-mail]>
Date: Fri, 24 May 2002 03:24:17 +0000
From: David Hopwood <[e-mail]>
X-Mailer: Mozilla 4.7 [en] (WinNT; I)
X-Accept-Language: en-GB,en,fr-FR,fr,de-DE,de,ru
MIME-Version: 1.0
To: [e-mail]
CC: [e-mail], [e-mail]
Subject: Re: [ietf-tls] Re: application/pkix-pkipath
References: <LYRIS-3174254-5252-2002.05.23-13.52.29--hopwood#[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

-----BEGIN PGP SIGNED MESSAGE-----

"Housley, Russ" wrote:
> The registration says: "... an update to [PKIX] ..."
> 
> That update is (finally) finished.  See RFC 3280.
> Please reference RFC 3280 (not RFC 2459).

Thanks, this will be fixed as follows:

Change the [PKIX] reference to

   [PKIX] R. Housley, W. Polk, W. Ford, and D. Solo, "Internet Public
   Key Infrastructure - Certificate and Certificate Revocation List
   (CRL) Profile", IETF RFC 3280, April 2002.

and change the sentence in the registration to just
"All Certificates MUST conform to [PKIX]."

- -- 
David Hopwood <[e-mail]>

Home page & PGP public key: http://www.users.zetnet.co.uk/hopwood/
RSA 2048-bit; fingerprint 71 8E A6 23 0E D3 4C E5  0F 69 8C D4 FA 66 15 01
Nothing in this message is intended to be legally binding. If I revoke a
public key but refuse to specify why, it is because the private key has been
seized under the Regulation of Investigatory Powers Act; see www.fipr.org/rip


-----BEGIN PGP SIGNATURE-----
Version: 2.6.3i
Charset: noconv

iQEVAwUBPO2yNzkCAxeYt5gVAQEDmQf/Ug2IYX1t8P7N/o8pzKQwF+SbbjP/IMLY
96+llndPRHN3q1WPboAsCI+4zA+2LPEokN6PqivzXibKH9W+spSj1YZawu0kswoV
/mmWFR4bYk0el2bn8yrjxJsYd/zrNs4eu+4ctkUPI2sEWQGRPdtzGrrFtihQ0wEZ
AsuWNOrn/OIf+76J8kVOY6a4l8H3nkn3TWR4FiL9M9gDvXkdtmjvH3aO0M41fsXT
YLKFTC2HmxQRaCCBkyHKdwZz51GVk3KC/rSvxzWoYfJS30rLk9ft6Inilmnbpast
XcYW2EF1DLzFLtU8/MxKwTEdN5S0ZQwknAnRyRsTnBU8BrwDoiABRA==
=iPEL
-----END PGP SIGNATURE-----


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g4NLOTd15065 for ietf-pkix-bks; Thu, 23 May 2002 14:24:29 -0700 (PDT)
Received: from email.nist.gov (email.nist.gov [129.6.2.7]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g4NLOSL15061 for <[e-mail]>; Thu, 23 May 2002 14:24:28 -0700 (PDT)
Received: from st25 (st25.ncsl.nist.gov [129.6.54.67]) by email.nist.gov (8.12.2/8.12.2) with ESMTP id g4NLOO87018334 for <[e-mail]>; Thu, 23 May 2002 17:24:30 -0400 (EDT)
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58 
Date: Thu, 23 May 2002 17:22:11 -0400
To: [e-mail]
From: Tim Polk <[e-mail]>
Subject: DPD/DPV Requirements
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Folks,

I haven't seen any comments on the latest draft of the DPD/DPV 
requirements.  I view this as a sign that consensus has been reached, or at 
least very near.  If I don't see any comments to the contrary, I plan on 
forwarding the document to the Area Directors Tuesday morning.

Thanks,

Tim Polk


Received: by above.proper.com (8.11.6/8.11.3) id g4NJnSL12806 for ietf-pkix-bks; Thu, 23 May 2002 12:49:28 -0700 (PDT)
Received: from email.nist.gov (email.nist.gov [129.6.2.7]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g4NJnQL12802 for <[e-mail]>; Thu, 23 May 2002 12:49:26 -0700 (PDT)
Received: from st25 (st25.ncsl.nist.gov [129.6.54.67]) by email.nist.gov (8.12.2/8.12.2) with ESMTP id g4NJnQ87001432; Thu, 23 May 2002 15:49:26 -0400 (EDT)
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58 
Date: Thu, 23 May 2002 15:47:01 -0400
To: [e-mail], [e-mail]
From: Tim Polk <[e-mail]>
Subject: Request for IESG consideration: PKIX Roadmap
Cc: [e-mail], [e-mail]
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Jeff & Steve,

The PKIX working group has achieved rough consensus and completed WG Last 
Call 
for  http://www.ietf.org/internet-drafts/draft-ietf-pkix-roadmap-08.txt, 
"Internet X.509 Public Key Infrastructure: Roadmap".  Please consider this 
specification for submission to the IESG for advancement to RFC status.

We believe this specification would be most appropriate as an informational 
track RFC.

Thanks,

Tim Polk






Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g4NIbJ310757 for ietf-pkix-bks; Thu, 23 May 2002 11:37:19 -0700 (PDT)
Received: from ext-mail.valicert.com ([66.206.205.11]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g4NIbIL10753 for <[e-mail]>; Thu, 23 May 2002 11:37:18 -0700 (PDT)
Received: from CONVERSION-DAEMON by ext-mail.valicert.com (PMDF V5.2-33 #46613) id <[e-mail]> for [e-mail]; Thu, 23 May 2002 11:32:21 -0700 (PDT)
Received: from polaris.valicert.com ([192.168.2.34]) by ext-mail.valicert.com (PMDF V5.2-33 #46613) with ESMTP id <[e-mail]>; Thu, 23 May 2002 11:32:21 -0700 (PDT)
Received: by polaris.valicert.com with Internet Mail Service (5.5.2653.19) id <K7HLMPFY>; Thu, 23 May 2002 11:36:53 -0700
Content-return: allowed
Date: Thu, 23 May 2002 11:36:52 -0700
From: Peter Williams <[e-mail]>
Subject: RE: application/pkix-pkipath
To: "'Housley, Russ'" <[e-mail]>
Cc: [e-mail], [e-mail]
Message-id: <[e-mail]>
MIME-version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-type: text/plain
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

All certs must comply with PKIX, it says. There
are very real communities of TLS users who use a non-PKIX
profile of certs. They should not be excluded
from the use of the TLS proposed extensions. There
is nothing inherent in the nature of TLS or
the extended handling that requires that PKIX-designated 
controls be enforced. 

TLS should continue to be able to maintain current 
interoperability AND exploit some of the newer extensions
even when certificates are not the means of distributing
public keys for the asymmetric cipher suites, as per
traditional SSL design.

>>>>-----Original Message-----
>>>>From: Housley, Russ [mailto:[e-mail]]
>>>>Sent: Thursday, May 23, 2002 10:47 AM
>>>>To: [e-mail]
>>>>Cc: [e-mail]; [e-mail]
>>>>Subject: Re: application/pkix-pkipath
>>>>
>>>>
>>>>
>>>>David:
>>>>
>>>>The registration says: "... an update to [PKIX] ..."
>>>>
>>>>That update is (finally) finished.  See RFC 3280.
>>>>Please reference RFC 3280 (not RFC 2459).
>>>>
>>>>Russ
>>>>
>>>>
>>>>
>>>>At 04:08 PM 5/23/2002 +0000, David Hopwood wrote:
>>>>
>>>>>-----BEGIN PGP SIGNED MESSAGE-----
>>>>>
>>>>>The following template is from the Standards Track I-D
>>>>><draft-ietf-tls-extensions-04.txt>, which has just been submitted
>>>>>for Last Call in the TLS WG. It's intended to be 
>>>>consistent with the
>>>>>types application/pkix-{cert,crl} from RFC 2585.
>>>>>
>>>>>(Note: Reply-To is set to the ietf-types list only.)
>>>>>
>>>>>
>>>>>    To: [e-mail]
>>>>>    Subject: Registration of MIME media type 
>>>>application/pkix-pkipath
>>>>>
>>>>>    MIME media type name: application
>>>>>
>>>>>    MIME subtype name: pkix-pkipath
>>>>>
>>>>>    Required parameters: none
>>>>>
>>>>>    Optional parameters: version (default value is "1")
>>>>>
>>>>>    Encoding considerations:
>>>>>       This MIME type is a DER encoding of the ASN.1 type PkiPath,
>>>>>       defined as follows:
>>>>>
>>>>>          PkiPath ::= SEQUENCE OF Certificate
>>>>>
>>>>>          PkiPath is used to represent a certification 
>>>>path. Within the
>>>>>          sequence, the order of certificates is such that 
>>>>the subject of
>>>>>          the first certificate is the issuer of the 
>>>>second certificate,
>>>>>          etc.
>>>>>
>>>>>       This is identical to the definition that will be 
>>>>published in
>>>>>       [X509-4th-TC1]; note that it is different from that 
>>>>in [X509-4th].
>>>>>
>>>>>       All Certificates MUST conform to [PKIX] (an update 
>>>>to [PKIX] is
>>>>>       in preparation, and should be followed when it is 
>>>>published).
>>>>>       DER (as opposed to BER) encoding MUST be used. If 
>>>>this type is
>>>>>       sent over a 7-bit transport, base64 encoding SHOULD be used.
>>>>>
>>>>>    Security considerations:
>>>>>       The security considerations of [X509-4th] and [PKIX] (or any
>>>>>       updates to them) apply, as well as those of any 
>>>>protocol that uses
>>>>>       this type (e.g. TLS).
>>>>>
>>>>>       Note that this type only specifies a certificate chain that
>>>>>       can be assessed for validity according to the 
>>>>relying party's
>>>>>       existing configuration of trusted CAs; it is not 
>>>>intended to be
>>>>>       used to specify any change to that configuration.
>>>>>
>>>>>    Interoperability considerations:
>>>>>       No specific interoperability problems are known 
>>>>with this type,
>>>>>       but for recommendations relating to X.509 
>>>>certificates in general,
>>>>>       see [PKIX].
>>>>>
>>>>>    Published specification: <draft-ietf-tls-extensions-04.txt> and
>>>>>       [PKIX].
>>>>>
>>>>>    Applications which use this media type: TLS. It may 
>>>>also be used by
>>>>>       other protocols, or for general interchange of PKIX 
>>>>certificate
>>>>>       chains.
>>>>>
>>>>>    Additional information:
>>>>>       Magic number(s): DER-encoded ASN.1 can be easily recognised.
>>>>>          Further parsing is required to distinguish from 
>>>>other ASN.1
>>>>>          types.
>>>>>       File extension(s): .pkipath
>>>>>       Macintosh File Type Code(s): not specified
>>>>>
>>>>>    Person & email address to contact for further information:
>>>>>       Magnus Nystrom <[e-mail]>
>>>>>
>>>>>    Intended usage: COMMON
>>>>>
>>>>>    Author/Change controller:
>>>>>       Magnus Nystrom <[e-mail]>
>>>>>
>>>>>
>>>>>Normative References
>>>>>
>>>>>    [KEYWORDS] S. Bradner, "Key words for use in RFCs to Indicate
>>>>>    Requirement Levels," IETF RFC 2119, March 1997.
>>>>>
>>>>>    [PKIX] R. Housley, W. Ford, W. Polk, and D. Solo, 
>>>>"Internet Public
>>>>>    Key Infrastructure: Part I: X.509 Certificate and CRL 
>>>>Profile", IETF
>>>>>    RFC 2459, January 1999.
>>>>>
>>>>>    [X509-4th] ITU-T Recommendation X.509 (2000) | ISO/IEC 
>>>>9594-8:2001,
>>>>>    "Information Systems - Open Systems Interconnection - 
>>>>The Directory:
>>>>>    Public key and attribute certificate frameworks."
>>>>>
>>>>>    [X509-4th-TC1] ITU-T Recommendation X.509(2000) 
>>>>Corrigendum 1(2001) |
>>>>>    ISO/IEC 9594-8:2001/Cor.1:2002, Technical Corrigendum 
>>>>1 to ISO/IEC
>>>>>    9594:8:2001.
>>>>>
>>>>>- --
>>>>>David Hopwood <[e-mail]>
>>>>>
>>>>>Home page & PGP public key: http://www.users.zetnet.co.uk/hopwood/
>>>>>RSA 2048-bit; fingerprint 71 8E A6 23 0E D3 4C E5  0F 69 
>>>>8C D4 FA 66 15 01
>>>>>Nothing in this message is intended to be legally binding. 
>>>>If I revoke a
>>>>>public key but refuse to specify why, it is because the 
>>>>private key has been
>>>>>seized under the Regulation of Investigatory Powers Act; 
>>>>see www.fipr.org/rip
>>>>>
>>>>>
>>>>>-----BEGIN PGP SIGNATURE-----
>>>>>Version: 2.6.3i
>>>>>Charset: noconv
>>>>>
>>>>>iQEVAwUBPOrjTTkCAxeYt5gVAQHddQf5ATsJ4D4flPu6Y5JgtazAO/Fc0MxG9Iy6
>>>>>XJsov+JNMmEwP66eESuSkgk44RWlk+TkHadGnsybRth9aRUumhni8GjnIO4UAn4I
>>>>>QghOXua2BZ8QoePEcm2i1BqlcTg7jgOHIcVXiRk3l/N3IvZviDy1a/h9B4pmYafV
>>>>>ZUgKhzwr7qFg63LWQyuSkOzisWpNeC778A6u95G+P0HhGdL77IEqiVz0GfWPuq2A
>>>>>jTmGP7kOl+WhS1pbjliGqxUNjYyw4fX/rcd5ltzhijY5LRa3jsUq+ixK8uSx4kle
>>>>>XXI1Aig8NLaX5Vfu2AkojMrcH2/wMFQK/JHwZY2cfs2mhdi7JBPUng==
>>>>>=6X2a
>>>>>-----END PGP SIGNATURE-----
>>>>


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g4NI3ha09819 for ietf-pkix-bks; Thu, 23 May 2002 11:03:43 -0700 (PDT)
Received: from bulwinkle.sigaba.com (bulwinkle.sigaba.com [63.202.162.42]) by above.proper.com (8.11.6/8.11.3) with SMTP id g4NI3gL09815 for <[e-mail]>; Thu, 23 May 2002 11:03:42 -0700 (PDT)
Received:  from bsd.sigaba.com (63.202.162.50)  by bulwinkle.sigaba.com (Sigaba Gateway v3.0)  with SMTP; Thu, 23 May 2002 11:01:36 (PDT)
Received:  from exchange1.sigaba.com (exchange1.sigaba.com [10.10.10.10]) by bsd.sigaba.com (8.12.2/8.12.2) with ESMTP id g4NI3dre014605; Thu, 23 May 2002 11:03:39 -0700
Received:  by exchange.sigaba.com with Internet Mail Service (5.5.2653.19) id <LPQT2AMQ>; Thu, 23 May 2002 11:03:38 -0700
Message-id:  <[e-mail]>
From: Trevor Perrin <[e-mail]>
To: "'Stephen Kent'" <[e-mail]>, Trevor Perrin <[e-mail]>
Cc: [e-mail]
Subject:  RE: Proxy PKI.
Date:  Thu, 23 May 2002 11:03:37 -0700
MIME-Version:  1.0
X-mailer:  Internet Mail Service (5.5.2653.19)
Content-Type:  text/plain; charset="iso-8859-1"
Content-Transfer-Encoding:  7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Hi Stephen,

Thanks for tolerating me this far, I'll withdraw.  I enjoy these
discussions, I'd be happy to continue in a more appropriate forum or offline
if anyone's interested..

Trevor

-----Original Message-----
From: Stephen Kent [mailto:[e-mail]]
Sent: Wednesday, May 22, 2002 3:52 PM
To: Trevor Perrin
Cc: [e-mail]; [e-mail]
Subject: RE: Proxy PKI.



Trevor,

The model you propose may be appropriate for some set of 
circumstances, and for some forms of PKI-enabled applications. But, 
it is does not match the semantics usually associated with X.509 nor 
PKIX. This becomes increasingly apparent as you continue your 
explanations. There have been other PKI models proposed, e.g., SPKI, 
and you are free to develop a model based on the notions you espouse, 
but I do not envision PKIX making changes to our standards to 
accommodate what you propose.

Steve


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g4NHnOo09453 for ietf-pkix-bks; Thu, 23 May 2002 10:49:24 -0700 (PDT)
Received: from vulcan.rsasecurity.com (mail.rsasecurity.com [204.167.114.123]) by above.proper.com (8.11.6/8.11.3) with SMTP id g4NHnNL09448 for <[e-mail]>; Thu, 23 May 2002 10:49:23 -0700 (PDT)
Received: from no.name.available by vulcan.rsasecurity.com via smtpd (for mail.imc.org [208.184.76.43]) with SMTP; 23 May 2002 17:47:35 UT
Received: from ebola.securitydynamics.com (ebola.securid.com [192.80.211.4]) by sdtihq24.securid.com (Pro-8.9.3/Pro-8.9.3) with ESMTP id NAA01637; Thu, 23 May 2002 13:49:24 -0400 (EDT)
Received: from exna00.securitydynamics.com (localhost [127.0.0.1]) by ebola.securitydynamics.com (8.10.2+Sun/8.10.2) with ESMTP id g4NHlVX09184; Thu, 23 May 2002 13:47:31 -0400 (EDT)
Received: by exna00.securitydynamics.com with Internet Mail Service (5.5.2653.19) id <K2ZLFTXD>; Thu, 23 May 2002 13:49:22 -0400
Received: from HOUSLEY-LAP.rsasecurity.com (HOUSLEY-LAP [10.3.9.22]) by exna00.securitydynamics.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id K2ZLFTW0; Thu, 23 May 2002 13:49:16 -0400
From: "Housley, Russ" <[e-mail]>
To: [e-mail]
Cc: [e-mail], [e-mail]
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Version 5.1
Date: Thu, 23 May 2002 13:46:53 -0400
Subject: Re: application/pkix-pkipath
In-Reply-To: <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

David:

The registration says: "... an update to [PKIX] ..."

That update is (finally) finished.  See RFC 3280.
Please reference RFC 3280 (not RFC 2459).

Russ



At 04:08 PM 5/23/2002 +0000, David Hopwood wrote:

>-----BEGIN PGP SIGNED MESSAGE-----
>
>The following template is from the Standards Track I-D
><draft-ietf-tls-extensions-04.txt>, which has just been submitted
>for Last Call in the TLS WG. It's intended to be consistent with the
>types application/pkix-{cert,crl} from RFC 2585.
>
>(Note: Reply-To is set to the ietf-types list only.)
>
>
>    To: [e-mail]
>    Subject: Registration of MIME media type application/pkix-pkipath
>
>    MIME media type name: application
>
>    MIME subtype name: pkix-pkipath
>
>    Required parameters: none
>
>    Optional parameters: version (default value is "1")
>
>    Encoding considerations:
>       This MIME type is a DER encoding of the ASN.1 type PkiPath,
>       defined as follows:
>
>          PkiPath ::= SEQUENCE OF Certificate
>
>          PkiPath is used to represent a certification path. Within the
>          sequence, the order of certificates is such that the subject of
>          the first certificate is the issuer of the second certificate,
>          etc.
>
>       This is identical to the definition that will be published in
>       [X509-4th-TC1]; note that it is different from that in [X509-4th].
>
>       All Certificates MUST conform to [PKIX] (an update to [PKIX] is
>       in preparation, and should be followed when it is published).
>       DER (as opposed to BER) encoding MUST be used. If this type is
>       sent over a 7-bit transport, base64 encoding SHOULD be used.
>
>    Security considerations:
>       The security considerations of [X509-4th] and [PKIX] (or any
>       updates to them) apply, as well as those of any protocol that uses
>       this type (e.g. TLS).
>
>       Note that this type only specifies a certificate chain that
>       can be assessed for validity according to the relying party's
>       existing configuration of trusted CAs; it is not intended to be
>       used to specify any change to that configuration.
>
>    Interoperability considerations:
>       No specific interoperability problems are known with this type,
>       but for recommendations relating to X.509 certificates in general,
>       see [PKIX].
>
>    Published specification: <draft-ietf-tls-extensions-04.txt> and
>       [PKIX].
>
>    Applications which use this media type: TLS. It may also be used by
>       other protocols, or for general interchange of PKIX certificate
>       chains.
>
>    Additional information:
>       Magic number(s): DER-encoded ASN.1 can be easily recognised.
>          Further parsing is required to distinguish from other ASN.1
>          types.
>       File extension(s): .pkipath
>       Macintosh File Type Code(s): not specified
>
>    Person & email address to contact for further information:
>       Magnus Nystrom <[e-mail]>
>
>    Intended usage: COMMON
>
>    Author/Change controller:
>       Magnus Nystrom <[e-mail]>
>
>
>Normative References
>
>    [KEYWORDS] S. Bradner, "Key words for use in RFCs to Indicate
>    Requirement Levels," IETF RFC 2119, March 1997.
>
>    [PKIX] R. Housley, W. Ford, W. Polk, and D. Solo, "Internet Public
>    Key Infrastructure: Part I: X.509 Certificate and CRL Profile", IETF
>    RFC 2459, January 1999.
>
>    [X509-4th] ITU-T Recommendation X.509 (2000) | ISO/IEC 9594-8:2001,
>    "Information Systems - Open Systems Interconnection - The Directory:
>    Public key and attribute certificate frameworks."
>
>    [X509-4th-TC1] ITU-T Recommendation X.509(2000) Corrigendum 1(2001) |
>    ISO/IEC 9594-8:2001/Cor.1:2002, Technical Corrigendum 1 to ISO/IEC
>    9594:8:2001.
>
>- --
>David Hopwood <[e-mail]>
>
>Home page & PGP public key: http://www.users.zetnet.co.uk/hopwood/
>RSA 2048-bit; fingerprint 71 8E A6 23 0E D3 4C E5  0F 69 8C D4 FA 66 15 01
>Nothing in this message is intended to be legally binding. If I revoke a
>public key but refuse to specify why, it is because the private key has been
>seized under the Regulation of Investigatory Powers Act; see www.fipr.org/rip
>
>
>-----BEGIN PGP SIGNATURE-----
>Version: 2.6.3i
>Charset: noconv
>
>iQEVAwUBPOrjTTkCAxeYt5gVAQHddQf5ATsJ4D4flPu6Y5JgtazAO/Fc0MxG9Iy6
>XJsov+JNMmEwP66eESuSkgk44RWlk+TkHadGnsybRth9aRUumhni8GjnIO4UAn4I
>QghOXua2BZ8QoePEcm2i1BqlcTg7jgOHIcVXiRk3l/N3IvZviDy1a/h9B4pmYafV
>ZUgKhzwr7qFg63LWQyuSkOzisWpNeC778A6u95G+P0HhGdL77IEqiVz0GfWPuq2A
>jTmGP7kOl+WhS1pbjliGqxUNjYyw4fX/rcd5ltzhijY5LRa3jsUq+ixK8uSx4kle
>XXI1Aig8NLaX5Vfu2AkojMrcH2/wMFQK/JHwZY2cfs2mhdi7JBPUng==
>=6X2a
>-----END PGP SIGNATURE-----


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g4NFmWh06375 for ietf-pkix-bks; Thu, 23 May 2002 08:48:32 -0700 (PDT)
Received: from zetnet.co.uk ([e-mail] [194.247.47.48]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g4NFmVL06371 for <[e-mail]>; Thu, 23 May 2002 08:48:31 -0700 (PDT)
Received: from zetnet.co.uk (bts-0002.dialup.zetnet.co.uk [194.247.48.2]) by zetnet.co.uk (8.11.3/8.11.3/Debian 8.11.2-1) with ESMTP id g4NFmJR18320; Thu, 23 May 2002 16:48:20 +0100
Message-ID: <[e-mail]>
Date: Thu, 23 May 2002 16:08:14 +0000
From: David Hopwood <[e-mail]>
Reply-To: [e-mail]
X-Mailer: Mozilla 4.7 [en] (WinNT; I)
X-Accept-Language: en-GB,en,fr-FR,fr,de-DE,de,ru
MIME-Version: 1.0
To: [e-mail]
CC: [e-mail], [e-mail]
Subject: application/pkix-pkipath
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

-----BEGIN PGP SIGNED MESSAGE-----

The following template is from the Standards Track I-D
<draft-ietf-tls-extensions-04.txt>, which has just been submitted
for Last Call in the TLS WG. It's intended to be consistent with the
types application/pkix-{cert,crl} from RFC 2585.

(Note: Reply-To is set to the ietf-types list only.)


   To: [e-mail]
   Subject: Registration of MIME media type application/pkix-pkipath

   MIME media type name: application

   MIME subtype name: pkix-pkipath

   Required parameters: none

   Optional parameters: version (default value is "1")

   Encoding considerations:
      This MIME type is a DER encoding of the ASN.1 type PkiPath,
      defined as follows:

         PkiPath ::= SEQUENCE OF Certificate

         PkiPath is used to represent a certification path. Within the
         sequence, the order of certificates is such that the subject of
         the first certificate is the issuer of the second certificate,
         etc.

      This is identical to the definition that will be published in
      [X509-4th-TC1]; note that it is different from that in [X509-4th].

      All Certificates MUST conform to [PKIX] (an update to [PKIX] is
      in preparation, and should be followed when it is published).
      DER (as opposed to BER) encoding MUST be used. If this type is
      sent over a 7-bit transport, base64 encoding SHOULD be used.

   Security considerations:
      The security considerations of [X509-4th] and [PKIX] (or any
      updates to them) apply, as well as those of any protocol that uses
      this type (e.g. TLS).

      Note that this type only specifies a certificate chain that
      can be assessed for validity according to the relying party's
      existing configuration of trusted CAs; it is not intended to be
      used to specify any change to that configuration.

   Interoperability considerations:
      No specific interoperability problems are known with this type,
      but for recommendations relating to X.509 certificates in general,
      see [PKIX].

   Published specification: <draft-ietf-tls-extensions-04.txt> and
      [PKIX].

   Applications which use this media type: TLS. It may also be used by
      other protocols, or for general interchange of PKIX certificate
      chains.

   Additional information:
      Magic number(s): DER-encoded ASN.1 can be easily recognised.
         Further parsing is required to distinguish from other ASN.1
         types.
      File extension(s): .pkipath
      Macintosh File Type Code(s): not specified

   Person & email address to contact for further information:
      Magnus Nystrom <[e-mail]>

   Intended usage: COMMON

   Author/Change controller:
      Magnus Nystrom <[e-mail]>


Normative References

   [KEYWORDS] S. Bradner, "Key words for use in RFCs to Indicate
   Requirement Levels," IETF RFC 2119, March 1997.

   [PKIX] R. Housley, W. Ford, W. Polk, and D. Solo, "Internet Public
   Key Infrastructure: Part I: X.509 Certificate and CRL Profile", IETF
   RFC 2459, January 1999.

   [X509-4th] ITU-T Recommendation X.509 (2000) | ISO/IEC 9594-8:2001,
   "Information Systems - Open Systems Interconnection - The Directory:
   Public key and attribute certificate frameworks."

   [X509-4th-TC1] ITU-T Recommendation X.509(2000) Corrigendum 1(2001) |
   ISO/IEC 9594-8:2001/Cor.1:2002, Technical Corrigendum 1 to ISO/IEC
   9594:8:2001.

- -- 
David Hopwood <[e-mail]>

Home page & PGP public key: http://www.users.zetnet.co.uk/hopwood/
RSA 2048-bit; fingerprint 71 8E A6 23 0E D3 4C E5  0F 69 8C D4 FA 66 15 01
Nothing in this message is intended to be legally binding. If I revoke a
public key but refuse to specify why, it is because the private key has been
seized under the Regulation of Investigatory Powers Act; see www.fipr.org/rip


-----BEGIN PGP SIGNATURE-----
Version: 2.6.3i
Charset: noconv

iQEVAwUBPOrjTTkCAxeYt5gVAQHddQf5ATsJ4D4flPu6Y5JgtazAO/Fc0MxG9Iy6
XJsov+JNMmEwP66eESuSkgk44RWlk+TkHadGnsybRth9aRUumhni8GjnIO4UAn4I
QghOXua2BZ8QoePEcm2i1BqlcTg7jgOHIcVXiRk3l/N3IvZviDy1a/h9B4pmYafV
ZUgKhzwr7qFg63LWQyuSkOzisWpNeC778A6u95G+P0HhGdL77IEqiVz0GfWPuq2A
jTmGP7kOl+WhS1pbjliGqxUNjYyw4fX/rcd5ltzhijY5LRa3jsUq+ixK8uSx4kle
XXI1Aig8NLaX5Vfu2AkojMrcH2/wMFQK/JHwZY2cfs2mhdi7JBPUng==
=6X2a
-----END PGP SIGNATURE-----


Received: by above.proper.com (8.11.6/8.11.3) id g4NDWoa00771 for ietf-pkix-bks; Thu, 23 May 2002 06:32:50 -0700 (PDT)
Received: from eamail1-out.unisys.com (eamail1-out.unisys.com [192.61.61.99]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g4NDWmL00767 for <[e-mail]>; Thu, 23 May 2002 06:32:48 -0700 (PDT)
Received: from us-ea-gtwy-7.ea.unisys.com (us-ea-gtwy-7.ea.unisys.com [192.61.145.102]) by eamail1-out.unisys.com (8.9.3/8.9.3) with ESMTP id NAA19406; Thu, 23 May 2002 13:30:56 GMT
Received: by us-ea-gtwy-7.ea.unisys.com with Internet Mail Service (5.5.2655.55) id <K8WFMPWX>; Thu, 23 May 2002 08:32:28 -0500
Message-ID: <A1EFE1A8B989D211BF3500105A239AA904625807@AT-VIE-EXCH-1>
From: "Strizik, Christoph" <[e-mail]>
To: narendra <[e-mail]>, Ietf-Pkix <[e-mail]>
Subject: RE: About Certificate extention
Date: Thu, 23 May 2002 08:31:24 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2655.55)
Content-Type: text/plain
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Hi Narendra

I don't think that you will get responses to your questions. This forum is
mainly meant for experts working
on the future of PKI - Questions like yours are definitely outside the scope
of this forum.
If you are interested in PKI I would highly recommend you to read a few
papers about PKI.

Web sources:
1) http://www.nwfusion.com/research/2001/1210feat.html
2) http://csrc.nist.gov/pki/
3) http://www.pkiforum.org/
4) http://www.pkilaw.com/
5) http://www.counterpane.com/pki-risks.html
6) http://www.nss.co.uk/ Assesses the PKI offerings of various companies.
Registration required.

There is also a good book available which covers PKI from a very high level:
Understanding Public Key Infrastructure ISBN:157870166X

Kind regards,
Christoph

-----Original Message-----
From: narendra [mailto:[e-mail]] 
Sent: Freitag, 24. Mai 2002 01:32
To: Ietf-Pkix
Subject: About Certificate extention



Dear Group Member,
	There are two questions.
Q:-1 	I have got two rfcs 2459 and 3280 for publick key infrastructure.In
rfc 3280 there is written that it obsolutes 2459. So i am studing rfc 3280.
Question is  "Should i read 2459 first 2459 then move to 3280 or continue
with 3280?

Q:- While studing rfc 3280 i do come across CERTIFICATE EXTENCTIONS, What
this terms specifies?


Seeking your co-opertaion,
narendra.



--------------------------------------------
Parmar Narendrasinh Abhesinh
Numen Technologies Pvt.Ltd,
505 "ADITYA"
Opp.Sardar Patel Seva Samaj,
Off.C.G.Road,Ahmedabd-380 006
Phone no:- [phone]/6466310 ex-46,47,48




Received: by above.proper.com (8.11.6/8.11.3) id g4ND0F828967 for ietf-pkix-bks; Thu, 23 May 2002 06:00:15 -0700 (PDT)
Received: from raven.ecs.soton.ac.uk (raven.ecs.soton.ac.uk [152.78.70.1]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g4ND0EL28959 for <[e-mail]>; Thu, 23 May 2002 06:00:14 -0700 (PDT)
Received: from hawk.ecs.soton.ac.uk (hawk.ecs.soton.ac.uk [152.78.68.142]) by raven.ecs.soton.ac.uk (8.9.3/8.9.3) with ESMTP id OAA20395 for <[e-mail]>; Thu, 23 May 2002 14:00:14 +0100 (BST)
Received: from jap.ecs.soton.ac.uk (jap.ecs.soton.ac.uk [152.78.69.201]) by hawk.ecs.soton.ac.uk (8.9.3/8.9.3) with ESMTP id OAA17539 for <[e-mail]>; Thu, 23 May 2002 14:00:14 +0100 (BST)
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Version 4.3.2
Date: Thu, 23 May 2002 14:01:18 +0100
To: "'[e-mail]'" <[e-mail]>
From: J Adrian Pickering <[e-mail]>
Subject: Re: association between the time-stamp and the original document
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

At 12:04 23/05/2002 +0200, you wrote:

>Massimiliano,
>
> > Dear Denis,
>
> > thanks for your patience.  You got my point.
>
> > I am using time stamps in a service of certified
> > mail, where we time stamp e-mail messages, which
> > might not be signed.  At the moment we are sending
> > the original message and the time stamp as two
> > MIME attachments.  We do not like this and would
> > prefer to "attach the data (even not signed)
> > to the timestamp". To do this we would like to
> > insert the whole document in the time stamp,
> > in order to make time stamp verification more
> > robust.
>
>I would not like to place the whole document within the time-stamp.

I support that.


>I would rather prefer to indicate the link with a document that may
>be stored elsewhere in one or several places.

I support that too. Massimiliano has a point with which I have a great deal 
of sympathy. However, I have always accepted that a TSA's job was to stamp 
something it fundamentally could know anything about. This made the 
operation legally simple - no one could ever later suggest that the TSA was 
stamping anything with any (implied) meaning to it. TSP does that.

The duty of keeping the links is therefore the data owners'. No one elses'. 
The hash is actually a very good key to a document depository - it should 
be unique!

Adrian Pickering/
ECS, Southampton, UK



Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g4NCjEq26280 for ietf-pkix-bks; Thu, 23 May 2002 05:45:14 -0700 (PDT)
Received: from popsmtp1.icenet.net (popsmtp.icenet.net [203.88.128.12]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g4NCj8L26251 for <[e-mail]>; Thu, 23 May 2002 05:45:10 -0700 (PDT)
Received: from numenindia.com (ice.155.client177.icenet.net [203.88.155.177] (may be forged)) by popsmtp1.icenet.net (8.9.3/8.9.3) with SMTP id QAA14423 for <[e-mail]>; Thu, 23 May 2002 16:58:14 +0530
X-Distribution-To: [e-mail]
From: "narendra" <[e-mail]>
To: "Ietf-Pkix" <[e-mail]>
Subject: About Certificate extention
Date: Fri, 24 May 2002 05:01:41 +0530
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.2911.0)
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700
Importance: Normal
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Dear Group Member,
	There are two questions.
Q:-1 	I have got two rfcs 2459 and 3280 for publick key infrastructure.In
rfc 3280 there is written that it obsolutes 2459. So i am studing rfc 3280.
Question is
 "Should i read 2459 first 2459 then move to 3280 or continue with 3280?

Q:- While studing rfc 3280 i do come across CERTIFICATE EXTENCTIONS, What
this terms specifies?


Seeking your co-opertaion,
narendra.



--------------------------------------------
Parmar Narendrasinh Abhesinh
Numen Technologies Pvt.Ltd,
505 "ADITYA"
Opp.Sardar Patel Seva Samaj,
Off.C.G.Road,Ahmedabd-380 006
Phone no:- [phone]/6466310 ex-46,47,48





Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g4NBiet23253 for ietf-pkix-bks; Thu, 23 May 2002 04:44:40 -0700 (PDT)
Received: from popsmtp1.icenet.net (popsmtp.icenet.net [203.88.128.12]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g4NBiZL23249 for <[e-mail]>; Thu, 23 May 2002 04:44:35 -0700 (PDT)
Received: from numenindia.com (ice.155.client177.icenet.net [203.88.155.177] (may be forged)) by popsmtp1.icenet.net (8.9.3/8.9.3) with SMTP id RAA22571 for <[e-mail]>; Thu, 23 May 2002 17:11:58 +0530
X-Distribution-To: [e-mail]
From: "narendra" <[e-mail]>
To: "Ietf-Pkix" <[e-mail]>
Subject: About Time Stamp
Date: Fri, 24 May 2002 05:14:58 +0530
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.2911.0)
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700
Importance: Normal
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Dear Group Members,
   What is time stamping in PKI? where is it used and how ?
seeking your co-operation,
naredra.

--------------------------------------------
Parmar Narendrasinh Abhesinh
Numen Technologies Pvt.Ltd,
505 "ADITYA"
Opp.Sardar Patel Seva Samaj,
Off.C.G.Road,Ahmedabd-380 006
Phone no:- [phone]/6466310 ex-46,47,48

 


Received: by above.proper.com (8.11.6/8.11.3) id g4NAghY20623 for ietf-pkix-bks; Thu, 23 May 2002 03:42:43 -0700 (PDT)
Received: from web20001.mail.yahoo.com (web20001.mail.yahoo.com [216.136.225.46]) by above.proper.com (8.11.6/8.11.3) with SMTP id g4NAgfL20616 for <[e-mail]>; Thu, 23 May 2002 03:42:41 -0700 (PDT)
Message-ID: <[e-mail]>
Received: from [202.144.45.2] by web20001.mail.yahoo.com via HTTP; Thu, 23 May 2002 03:42:41 PDT
Date: Thu, 23 May 2002 03:42:41 -0700 (PDT)
From: vivek saraf <[e-mail]>
Subject: Re: Obtaining CA Certificate
To: narendra <[e-mail]>, Ietf-Pkix <[e-mail]>
In-Reply-To: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

hello narendra,

The CA certificate will be made available to the user
in the CA's site ( http/https), or the user can
download the CA certificate from the LDAP server.

The user MUST check the fingerprint of the CA
certificate before he installs in to the system

The CA's fingerprint ( HASH) will be published and 
will be made public when the CA certificate was 
generated.


vivek

--- narendra <[e-mail]> wrote:
> 
> Dear Group Member,
>        When we request for certificate from the
> CA,CA signes it with it's
> private key and it's authenticity is cheacked by
> CA's public key at the
> client side. When i request for the first time the
> certificate ( Here the
> certificate request is the first time to CA so user
> will not be having the
> CA digital certificate, isn't !),CA sends me a
> digital certificate signed by
> it's private key.But here when certificate comes to
> user , how it's
> autheticity being checked as user doesn't have CA
> certificate.
> 
> Does CA send a digital certificate to user first and
> then sends user's
> requested certificate?
> 
> seeking your co-operation,
> narendra.
> 
> --------------------------------------------
> Parmar Narendrasinh Abhesinh
> Numen Technologies Pvt.Ltd,
> 505 "ADITYA"
> Opp.Sardar Patel Seva Samaj,
> Off.C.G.Road,Ahmedabd-380 006
> Phone no:- [phone]/6466310 ex-46,47,48
> 
> 
> 


__________________________________________________
Do You Yahoo!?
LAUNCH - Your Yahoo! Music Experience
http://launch.yahoo.com


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g4NA4uG16790 for ietf-pkix-bks; Thu, 23 May 2002 03:04:56 -0700 (PDT)
Received: from odin2.bull.net (odin2.bull.net [192.90.70.84]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g4NA4sL16786 for <[e-mail]>; Thu, 23 May 2002 03:04:54 -0700 (PDT)
Received: from lvn-m002.frlv.bull.fr (lvn-m002.frlv.bull.fr [129.184.62.72]) by odin2.bull.net (8.9.3/8.9.3) with ESMTP id MAA18274; Thu, 23 May 2002 12:08:08 +0200
Received: from bull.net ([129.184.37.97]) by lvn-m002.frlv.bull.fr (Lotus Domino Release 5.0.8) with ESMTP id 2002052312041625:61 ; Thu, 23 May 2002 12:04:16 +0200 
Message-ID: <[e-mail]>
Date: Thu, 23 May 2002 12:04:13 +0200
From: Denis Pinkas <[e-mail]>
Organization: Bull SA.
X-Mailer: Mozilla 4.7 [fr] (Win98; I)
X-Accept-Language: fr
MIME-Version: 1.0
To: Massimiliano Farris <[e-mail]>
CC: "'[e-mail]'" <[e-mail]>
Subject: Re: association between the time-stamp and the original document
References: <[e-mail]>
X-MIMETrack: Itemize by SMTP Server on LVN-M002/FR/BULL(Release 5.0.8 |June 18, 2001) at 23/05/2002 12:04:16, Serialize by Router on LVN-M002/FR/BULL(Release 5.0.8 |June 18, 2001) at 23/05/2002 12:04:48, Serialize complete at 23/05/2002 12:04:48
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset=us-ascii
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Massimiliano,
 
> Dear Denis,
 
> thanks for your patience.  You got my point.

> I am using time stamps in a service of certified
> mail, where we time stamp e-mail messages, which
> might not be signed.  At the moment we are sending
> the original message and the time stamp as two
> MIME attachments.  We do not like this and would
> prefer to "attach the data (even not signed)
> to the timestamp". To do this we would like to
> insert the whole document in the time stamp,
> in order to make time stamp verification more
> robust.

I would not like to place the whole document within the time-stamp. 

I would rather prefer to indicate the link with a document that may 
be stored elsewhere in one or several places.

> Another desideratum is to let the user store
> messages (which are not SignedData) and associated
> time stamp.  At the moment I am using file extensions
> to do this.

> But what if the user wants to request some new time
> stamp on the message?  We do not like to solve
> this at the application level (for example with a
> private store of time stamps indexed by document hashes)
> or worse with some funny file extension syntax.
> 
> A sequence of URIs inserted in the time stamp is
> much more attractive to us,  but is there
> a CMS attribute that would suggest our intent in some
> generally understandable way?

Not at this time.

> For example, could ContentHints from ESS be a
> valid choice, or is there any better alternative?

ContentHints provides the document type, but not its location.

A new CMS attribute would be needed.

Denis
 
> > -----Original Message-----
> > From: Denis Pinkas [mailto:[e-mail]]
> > Sent: mercoledi 22 maggio 2002 11.30
> > To: Massimiliano Farris
> > Cc: '[e-mail]'
> > Subject: Re: association between the time-stamp and the original
> > document
> >
> >
> > Massimiliano,
> >
> > > > In the context of the use of CMS, RFC 3126 has defined
> > two time-stamp
> > > > related attributes:
> > > >
> > > > 1) A signed attribute, attached to the SignedData.
> > > >    It is the Content Time-Stamp attribute (p.34).
> > > >
> > > >    The content time-stamp attribute is an attribute which
> > is the time-
> > > >    stamp of the signed data content before it is signed.
> > > >
> > > >       id-aa-ets-contentTimestamp OBJECT IDENTIFIER ::= { iso(1)
> > > >       member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9)
> > > >       smime(16) id-aa(2) 20}
> > > >
> > > > 2) An unsigned attribute, attached to the digital signature.
> > > >    It is the Signature Time-Stamp Attribute (p.36):
> > > >
> > > >    The Signature Timestamp attribute is a timestamp of
> > the signature
> > > >    value.
> > > >
> > > >       id-aa-signatureTimeStampToken OBJECT IDENTIFIER ::= { iso(1)
> > > >       member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9)
> > > >       smime(16) id-aa(2) 14}
> > > >
> > > > As indicated, these attributes are only usable in the
> > context of a CMS
> > > > message.
> > > >
> > > > Denis
> >
> > >   I know it, I completely agree.
> >
> > >   However, my question is about something else.
> >
> > >   I talked of id-aa-signatureTimeStampToken only as an example.
> > >   I'm talking about the definition of an Unsigned Attribute
> > to be used
> > >   in the context of a time-stamp (which is a CMS).
> >
> > This does make sense.
> >
> > >   This lets a user to enrich the time-stamp received by a
> > TSA with the
> > >   'object' of the time-stamp itself.
> > >   In the first e-mail I said:
> > >
> > >   > However, the user may not like to be involved in a
> > >   > digital signature process everytime he wants to
> > >   > timestamp a document.
> > >
> > >   In this case, the user has the great problem to 'link',
> > to associate in
> > >   some manner the time-stamp with the document. Without
> > this association,
> > >   the time-stamp is useless.
> >
> > There are two ways to perform the link:
> >
> >   1) the time-stamp is attached to the data, this is what RFC
> > 3126 does.
> >   2) the data is attached to the time-stamp, this is what you suggest.
> >
> > >   Do you think this problem has to be solved by the client
> > responsible of
> > >   managing the interaction with the TSA, without any
> > standardized way ?
> > >   Do you think that only time-stamps of a signature have a sense ?
> >
> > The link could be done locally by adding an unsigned attribute to the
> > structure of the time-stamp token which is CMS based.
> >
> > I would guess that you would like a sequence of URIs to be
> > included in that
> > unsigned attribute. What else ?
> >
> > Denis
> >


Received: by above.proper.com (8.11.6/8.11.3) id g4N6n4422219 for ietf-pkix-bks; Wed, 22 May 2002 23:49:04 -0700 (PDT)
Received: from popsmtp1.icenet.net (popsmtp.icenet.net [203.88.128.12]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g4N6mwL22187 for <[e-mail]>; Wed, 22 May 2002 23:49:01 -0700 (PDT)
Received: from numenindia.com (ice.155.client175.icenet.net [203.88.155.175] (may be forged)) by popsmtp1.icenet.net (8.9.3/8.9.3) with SMTP id MAA04373 for <[e-mail]>; Thu, 23 May 2002 12:16:19 +0530
X-Distribution-To: [e-mail]
From: "narendra" <[e-mail]>
To: "Ietf-Pkix" <[e-mail]>
Subject: Obtaining CA Certificate
Date: Fri, 24 May 2002 00:09:13 +0530
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.2911.0)
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Dear Group Member,
       When we request for certificate from the CA,CA signes it with it's
private key and it's authenticity is cheacked by CA's public key at the
client side. When i request for the first time the certificate ( Here the
certificate request is the first time to CA so user will not be having the
CA digital certificate, isn't !),CA sends me a digital certificate signed by
it's private key.But here when certificate comes to user , how it's
autheticity being checked as user doesn't have CA certificate.

Does CA send a digital certificate to user first and then sends user's
requested certificate?

seeking your co-operation,
narendra.

--------------------------------------------
Parmar Narendrasinh Abhesinh
Numen Technologies Pvt.Ltd,
505 "ADITYA"
Opp.Sardar Patel Seva Samaj,
Off.C.G.Road,Ahmedabd-380 006
Phone no:- [phone]/6466310 ex-46,47,48





Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g4N2kBc07933 for ietf-pkix-bks; Wed, 22 May 2002 19:46:11 -0700 (PDT)
Received: from hermes.cs.auckland.ac.nz (hermes.cs.auckland.ac.nz [130.216.35.151]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g4N2k9L07929 for <[e-mail]>; Wed, 22 May 2002 19:46:09 -0700 (PDT)
Received: from ruru.cs.auckland.ac.nz (ruru-nfs.cs.auckland.ac.nz [130.216.35.12]) by hermes.cs.auckland.ac.nz (8.12.3/8.12.3) with ESMTP id g4N2k2aq006895; Thu, 23 May 2002 14:46:02 +1200
Received: (from pgut001@localhost) by ruru.cs.auckland.ac.nz (8.9.3/8.8.6/cs-slave) id OAA444232; Thu, 23 May 2002 14:46:01 +1200 (NZST) (sender [e-mail])
Date: Thu, 23 May 2002 14:46:01 +1200 (NZST)
Message-ID: <[e-mail]>
From: [e-mail] (Peter Gutmann)
To: [e-mail], [e-mail], [e-mail]
Subject: RE: Proxy PKI. Was: IBM alternative to PKI?
Cc: [e-mail]
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Trevor Perrin <[e-mail]> writes:

>I'm interested.  I hope you put up more information soon. 

I'm kinda hoping they publish some implementation-experience stuff at some
point.  At the moment they've covered some of their experiences in various
talks, but I don't know if there's anything online.  Their approach has been
"We'll do whatever COTS software supports", rather than the more traditional
"We'll design a grand infrastructure and then spend years trying to get vendors
to create the tools to support it".  The resulting system is quite some way
removed from any traditional PKI, but then they've also managed to get the
whole thing up and running with minimal cost and time expenditure.  From the
PKI-traditionalist POV what they're doing is heresy, from the get-something-
working-without-excessive-effort POV it's great.

(Cool quote from one of the talks: "It's nice to be in ~12 hours out of phase
with the rest of the world because you can submit bug reports in the afternoon,
have the vendors fix their products overnight, and have the patches by 8am the
next day".  Even with their minimalist, don't-push-the-envelope approach,
interoperability between products from different vendors has been a significant
problem).

Peter.


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g4N2P3607573 for ietf-pkix-bks; Wed, 22 May 2002 19:25:03 -0700 (PDT)
Received: from hermes.cs.auckland.ac.nz (hermes.cs.auckland.ac.nz [130.216.35.151]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g4N2P0L07568 for <[e-mail]>; Wed, 22 May 2002 19:25:01 -0700 (PDT)
Received: from ruru.cs.auckland.ac.nz (ruru-nfs.cs.auckland.ac.nz [130.216.35.12]) by hermes.cs.auckland.ac.nz (8.12.3/8.12.3) with ESMTP id g4N2Omaq006196; Thu, 23 May 2002 14:24:48 +1200
Received: (from pgut001@localhost) by ruru.cs.auckland.ac.nz (8.9.3/8.8.6/cs-slave) id OAA443919; Thu, 23 May 2002 14:24:48 +1200 (NZST) (sender [e-mail])
Date: Thu, 23 May 2002 14:24:48 +1200 (NZST)
Message-ID: <[e-mail]>
From: [e-mail] (Peter Gutmann)
To: [e-mail], [e-mail]
Subject: Re:  defining extension
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Peter Sylvester <[e-mail]> writes:

>can some tell me what in the 2002 versions of X.6XX the XXX {DER, CER, BER,
>XER, PER) encoding of an OCTET STRING defined with a constraint like
>
>     xxx         OCTET STRING ( CONTAINING abc )
>
>is? Does it mean that the value should/must be encoded using the same encoding
>rules as the data that contain an instance of xxx?

It's a nice way of formalising the old OCTET STRING hole practice.  Instead
of:

  foo OCTET STRING -- Contains a fooValue

which is impossible to process automatically by an ASN.1 compiler/processor
(unless you use a proprietary compiler hack like "--* compiler-directive" to
specify the semantics), you say:

  foo OCTET STRING ( CONTAINING fooValue )

Since OCTET STRINGs are (occasionally) used to hold blobs in other encoding
formats (and I'm not aware of any in PKI, but for other messaging types there'd
be legacy encodings present) you can also say:

  foo OCTET STRING ( CONTAINING fooValue ENCODED BY legacyEncodingFormat )

Peter.


Received: by above.proper.com (8.11.6/8.11.3) id g4N269h07161 for ietf-pkix-bks; Wed, 22 May 2002 19:06:09 -0700 (PDT)
Received: from hermes.cs.auckland.ac.nz (hermes.cs.auckland.ac.nz [130.216.35.151]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g4N267L07157 for <[e-mail]>; Wed, 22 May 2002 19:06:08 -0700 (PDT)
Received: from ruru.cs.auckland.ac.nz (ruru-nfs.cs.auckland.ac.nz [130.216.35.12]) by hermes.cs.auckland.ac.nz (8.12.3/8.12.3) with ESMTP id g4N25saq005696; Thu, 23 May 2002 14:05:54 +1200
Received: (from pgut001@localhost) by ruru.cs.auckland.ac.nz (8.9.3/8.8.6/cs-slave) id OAA443613; Thu, 23 May 2002 14:05:51 +1200 (NZST) (sender [e-mail])
Date: Thu, 23 May 2002 14:05:51 +1200 (NZST)
Message-ID: <[e-mail]>
From: [e-mail] (Peter Gutmann)
To: [e-mail], [e-mail]
Subject: Re: I-D ACTION:draft-ietf-pkix-acmc-01.txt
Cc: [e-mail]
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Denis Pinkas <[e-mail]> writes:

>It would be appropriate to write of the requirements first, so that we can all
>understand how a proposal would fit these requirements.

Isn't that a major departure from PKIX practice (see e.g. Steve Kent's message
of a few months ago on this topic)?  Or is this Todd forging mail from Denis
:-).

Peter.



Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g4MMtc401506 for ietf-pkix-bks; Wed, 22 May 2002 15:55:38 -0700 (PDT)
Received: from po1.bbn.com (PO1.BBN.com [192.1.50.38]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g4MMtNL01495; Wed, 22 May 2002 15:55:37 -0700 (PDT)
Received: from [128.89.88.34] (comsec.bbn.com [128.89.88.34]) by po1.bbn.com (8.9.1/8.9.1) with ESMTP id SAA25332; Wed, 22 May 2002 18:55:09 -0400 (EDT)
Mime-Version: 1.0
X-Sender: [e-mail]
Message-Id: <p05100307b911d0b946e3@[128.89.88.34]>
In-Reply-To: <[e-mail]>
References: <[e-mail]>
Date: Wed, 22 May 2002 18:52:11 -0400
To: Trevor Perrin <[e-mail]>
From: Stephen Kent <[e-mail]>
Subject: RE: Proxy PKI.
Cc: [e-mail], [e-mail]
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Trevor,

The model you propose may be appropriate for some set of 
circumstances, and for some forms of PKI-enabled applications. But, 
it is does not match the semantics usually associated with X.509 nor 
PKIX. This becomes increasingly apparent as you continue your 
explanations. There have been other PKI models proposed, e.g., SPKI, 
and you are free to develop a model based on the notions you espouse, 
but I do not envision PKIX making changes to our standards to 
accommodate what you propose.

Steve


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g4MJxPO26573 for ietf-pkix-bks; Wed, 22 May 2002 12:59:25 -0700 (PDT)
Received: from bulwinkle.sigaba.com (bulwinkle.sigaba.com [63.202.162.42]) by above.proper.com (8.11.6/8.11.3) with SMTP id g4MJxNL26567 for <[e-mail]>; Wed, 22 May 2002 12:59:23 -0700 (PDT)
Received:  from bsd.sigaba.com (63.202.162.50)  by bulwinkle.sigaba.com (Sigaba Gateway v3.0)  with SMTP; Wed, 22 May 2002 12:57:20 (PDT)
Received:  from exchange1.sigaba.com (exchange1.sigaba.com [10.10.10.10]) by bsd.sigaba.com (8.12.2/8.12.2) with ESMTP id g4MJxLre009590; Wed, 22 May 2002 12:59:21 -0700
Received:  by exchange.sigaba.com with Internet Mail Service (5.5.2653.19) id <LN3WCWLY>; Wed, 22 May 2002 12:59:20 -0700
Message-id:  <[e-mail]>
From: Trevor Perrin <[e-mail]>
To: "'Douglas E. Engert'" <[e-mail]>, Trevor Perrin <[e-mail]>
Cc: [e-mail]
Subject:  RE: Proxy PKI.
Date:  Wed, 22 May 2002 12:59:19 -0700
MIME-Version:  1.0
X-mailer:  Internet Mail Service (5.5.2653.19)
Content-Type:  text/plain; charset="iso-8859-1"
Content-Transfer-Encoding:  7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

I like the proxy certificates approach, but it doesn't address my chief
complaint about PKI: semantics can only be expressed in certificates.  

Consider three organizations, each with a TTP of some sort:
 - A has an offline TTP, ie CA
   - CA issues certs to users, who sign, decrypt
 - B has an online TTP
   - users authenticate to TTP who signs, decrypts
 - C has an inline TTP
   - communications pass through TTP who signs, decrypts

Currently, B and C have to simulate A: ie, create a key pair and certificate
for each user, publish the certificates, etc..  These superfluous
certificates are needed because PKI only allows delegation of privilege in
the context of certificates, not operations.  Ie, a TTP can says "I trust
this public key to sign for Bob", but it can't say "I'm signing for Bob".
Similarly, it can say "I trust this public key to be encrypted to for Bob",
but no-one can encrypt to it and say "give this to Bob".

If semantics could be attached to operations, then B and C could function
much more naturally by simply signing and decrypting with a single key pair,
and would not have to pretend to be A.


-----Original Message-----
From: Douglas E. Engert [mailto:[e-mail]]
Sent: Wednesday, May 22, 2002 7:14 AM
To: Trevor Perrin
Cc: [e-mail]
Subject: Re: Proxy PKI.





Trevor Perrin wrote:
> 
> Hello PKIX,
> 
> Here's one way of looking at "proxy PKI".  I won't keep spamming the list
> about this, but I just wanted to throw it out there once..  I'd love any
> feedback, or hearing about similar thoughts/projects.

You should look a the Globus Project at http://www.globus.org
The GSI is a GSSAPI built on top of SSL. It uses proxy certificates
to delegate. 

The proxies used with the GSI today are the inspiration for: 
http://www.ietf.org/internet-drafts/draft-ietf-pkix-proxy-02.txt

So although the proxy you are describing is not the same, some of the
concepts are similar, as the GSI proxies are delegated to others to act
on behalf of a user. 


> 
> With PKI, it's implicitly assumed that when something verifies with a
public
> key, this key is "speaking for" everyone in its certificate, and when
> something is encrypted to this key, it is "heard by" everyone in the
> certificate.  Thus, if a group certificate is used, it is left unspecified
> which member of the group is actually sending/should receive the data.
> 
> Ie, PKI allows the semantics
>  - K1 says K2 speaks and hears for x (certificate)
>  - K2 says y (signature)
>  - only K2 hears y (encryption)
> 
> But does not allow indirect statements, like
>  - K1 says "x says y"
>  - only K1 hears "only x should hear y"
> 
> (K1, K2 are public keys, x is some set of named principals, y is some
> document)
> 
> This indirection would allow PKI "gateways", which would represent
entities
> in security domains that are not otherwise part of the PKI.  In
particular,
> clients who don't want the burdens of managing their own key pair or
> interfacing with PKI could authenticate to such gateways using simple
> methods like passwords.  These gateways could be inline with the
> communication path, like S/MIME Domain Security, or perpendicular to it,
> where clients call out to the gateways to perform signatures and
> decryptions.
> 
> With this indirection, statements can be made two different ways: either
> directly or indirectly.  This suggests we separate *how* things are said
> from *what* is being said.  Ignoring encryption, what can be said is:
>  - "K speaks for x" (introduction)
>  - "x says y" (attribution)
>  - application data
> The first corresponds to the to-be-signed content of a certificate, where
x
> specifies the name(s) associated with public key K.  The second is
similar,
> but instead of associating x with a public key, x is associated with a
> particular statement y, represented by its hash value.
> 
> Statements can be made by:
>  - signing them directly with a private key
>  - attributing them (i.e. including their hash value as y above)
> 
> Introductions and attributions could be chained arbitrarily, but since
> they're both defined on the same names, they can be processed uniformly by
> certificate validation logic.  A chain would be like:
>  - K1 says K2 speaks for a* (signed introduction, ie certificate)
>  - K2 says K3 speaks for a* (signed introduction)
>  - K3 says a* says          (signed attribution)
>   - ab* says                (attributed attribution)
>    - abc* says              (attributed attribution)
>     - K4 speaks for abcd*   (attributed introduction)
>  - K4 says abcde* says      (signed attribution)
>   - K5 speaks for abcdef*   (attributed introduction)
>  - K5 says acdef* says      (signed attribution)
>   - abcdefg* says           (attributed attribution)
>    - acdefgh says           (attributed attribution)
>     - hi                    (attributed application data)
> 
> The attribution chains could be collapsed.  Intuitively, instead of saying
> "Alice says Bob says Charlie says hi", I could just say "Charlie says hi",
> assuming I trust Alice and Bob.  But if I explicitly mention them, then
> later on when I (or you) discover that Alice is untrustworthy, it becomes
> easier to recover.
> 
> This may not justify the complexity of nested attributions.  We could make
> things simpler by disallowing attributions except in the final signature
> over application data.  This would give a more conventional certificate
> chain, but where the end-entity can explicitly represent who he is signing
> on behalf of:
>  - K1 says K2 speaks for a*
>  - K2 says K3 speaks for a*
>  - K3 says K4 speaks for acbd*
>  - K4 says K5 speaks for acdef*
>  - K5 says abcdefgh says
>   - hi
> 
> This last attribution could be represented in a variety of ways, for
example
> embedding a SAML Assertion as a signed property of an XML Signature.  The
> inverse notion, an encryption instructing a particular public key whom to
> give the encrypted data to, could be represented by a similar idiom
> involving XML Encryption and XACML.  A request/response protocol could be
> defined allowing clients to delegate processing of these structures to
their
> "PKI gateways".
> 
> The paper I mentioned a couple mails ago discusses this and also trying to
> represent this in X.509.  If a standard way to bind names into these
signed
> hashes and encrypted symmetric keys could be decided on, then potentially,
> application protocols could be modified to use these and thus support PKI
> gateways, allowing people with only passwords to do S/MIME mail, TLS
client
> authentication, etc..
> 
> Trevor
> 
> -----Original Message-----
> From: Trevor Perrin [mailto:[e-mail]]
> Sent: Tuesday, May 21, 2002 10:45 AM
> To: '[e-mail]'; Trevor Perrin; [e-mail]
> Cc: [e-mail]
> Subject: RE: Proxy PKI. Was: IBM alternative to PKI?
> 
> Hi Peter,
> 
> I'm interested.  I hope you put up more information soon.  If you're
talking
> about the "Authentication Proxies" described in 6.9.2 of the
"Authentication
> Mechanisms" paper, then it's sort of a mirror-image to what I'm
advocating,
> ie
>  - converting PKI authentications -> legacy (password) authentications to
> make things easier on apps
> versus
>  - converting legacy authentications -> PKI operations to make things
easier
> on users/desktop software
> 
> Trevor
> 
> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]]
> Sent: Sunday, May 19, 2002 9:34 PM
> To: [e-mail]; [e-mail]
> Cc: [e-mail]
> Subject: RE: Proxy PKI. Was: IBM alternative to PKI?
> 
> Trevor Perrin <[e-mail]> writes:
> 
> >I'm suggesting this proxy could be used for anything a private key is
used
> >for: signing, authenticating, decrypting.  The idea is just to let people
> with
> >only authentication mechanisms do PKI "stuff" in a simple fashion, by
> having a
> >server do it for them.
> 
> Something similar is being done in the SEE PKI project
> (http://www.e-government.govt.nz/see/pki/index.asp, although some of the
> newer
> documents covering this haven't been posted yet) as a means of letting
> people
> use a PKI without having to go through the pain of actually having to use
a
> PKI.  This uses (among other approaches) proxies to front-end to a PKI to
> allow
> existing/alternative mechanisms to be used.
> 
> Peter.

-- 

 Douglas E. Engert  <[e-mail]>
 Argonne National Laboratory
 9700 South Cass Avenue
 Argonne, Illinois  60439 
 [phone]


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g4MJ7DW25192 for ietf-pkix-bks; Wed, 22 May 2002 12:07:13 -0700 (PDT)
Received: from vulcan.rsasecurity.com (mail.rsasecurity.com [204.167.114.123]) by above.proper.com (8.11.6/8.11.3) with SMTP id g4MJ7BL25184 for <[e-mail]>; Wed, 22 May 2002 12:07:11 -0700 (PDT)
Received: from no.name.available by vulcan.rsasecurity.com via smtpd (for mail.imc.org [208.184.76.43]) with SMTP; 22 May 2002 19:05:24 UT
Received: from ebola.securitydynamics.com (ebola.securid.com [192.80.211.4]) by sdtihq24.securid.com (Pro-8.9.3/Pro-8.9.3) with ESMTP id PAA00939 for <[e-mail]>; Wed, 22 May 2002 15:07:13 -0400 (EDT)
Received: from exna00.securitydynamics.com (localhost [127.0.0.1]) by ebola.securitydynamics.com (8.10.2+Sun/8.10.2) with ESMTP id g4MJ5Jq15333 for <[e-mail]>; Wed, 22 May 2002 15:05:19 -0400 (EDT)
Received: by exna00.securitydynamics.com with Internet Mail Service (5.5.2653.19) id <K2ZLFF2H>; Wed, 22 May 2002 15:07:10 -0400
Received: from HOUSLEY-LAP.rsasecurity.com (HOUSLEY-LAP [10.3.9.3]) by exna00.securitydynamics.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id K2ZLFF21; Wed, 22 May 2002 15:07:04 -0400
From: "Housley, Russ" <[e-mail]>
To: Denis Pinkas <[e-mail]>
Cc: [e-mail]
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Version 5.1
Date: Wed, 22 May 2002 15:05:30 -0400
Subject: Re: I-D ACTION:draft-ietf-pkix-acmc-01.txt
In-Reply-To: <[e-mail]>
References: <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Denis:

Steve Farrell posted a draft called "Limited AttributeCertificate 
Acquisition Protocol (LAAP)" in July 2000.  Several people thought that 
this approach was too light weight.  I believe the ACMC/ACRMF approach 
handles all of the cases that LAAP handled and many, many more.

As for complexity, the PKIX group split CRMF from the enrollment protocol. 
By extending the enrollment protocol and the request format are both being 
extended, no new complexity is being introduced.

I think that we should proceed with the ACMC/ACRMF approach, even if it 
does not meet every requirement.  In my opinion, Synergy with CMC is desirable.

If it turns out that an attribute-centric protocol (as you advocate) is 
needed for communications between the client and the ARA, then it still 
seem likely that ACMC/ACRMF is a good fit between the ARA and the AA.

Russ

At 03:17 PM 5/21/2002 +0200, Denis Pinkas wrote:

>Comments on drafts "Attribute Certificate Request Message Format" and
>"Attribute Certificate Management Messages over CMS" (March 2002)
>
>The two drafts are very technical, hard to read, inter-related and do
>not have sufficient explanations to allow a rapid and easy understanding for
>everyone. It can be observed that no comment has been sent up to now on
>acmc.
>
>It is assumed that managing ACs is as simple as managing PKCs and thus that
>protocols able to manage PKCs, with a few modifications, will be able to
>manage ACs. This assumption is incorrect.
>
>The way ACs are managed is very different from the way PKCs are managed and
>for that reason it is not believed that extending CRMF and CMC is the right
>way. Whether some extension to CMP would be able to do the job better will
>not be discussed either. The problem is that is that we have a solution
>without requirements, so it is hard to say whether or not the solution fits
>the requirements.
>
>It would be appropriate to write of the requirements first, so that we can
>all understand how a proposal would fit these requirements.
>
>Before looking into some of these requirements, it is important to
>understand the major differences with a PKC.
>
>When a PKC is requested, a template of the PKC is provided together with
>registration information. From that request, a *single *certificate will be
>created later on, and will be given back to the requester and/or placed in a
>repository.
>
>When an attribute (beware, *not* an AC) is registered, that attribute is
>provided together with registration information. No AC is created from that
>request. The registration information consists of two main components:
>
>    - the definition of the attribute itself, together with some
>      constraints that apply to it (see later) and the revocation
>      conditions for that attribute.
>
>    - the way to link the "to-be-created-ACs" with an entity, most of
>      the time by linking it to a PKC. In that case providing the PKC is
>      not always sufficient since the subject DN may not be explicit
>      enough and thus information (or some link) from the CA that has
>      created the PKC may be necessary.
>
>Attribute registration is usually not done by the end user that will
>become ultimately the AC holder. Various attributes can be registered. Some
>attributes may be registered with some constraints like, the validity period
>of ACs that may be issued later on; how revocation will be handled, if
>handled for that attribute; restrictions that will apply to that attribute
>like target controls. Note that this operation is not necessary done
>remotely using a protocol, so it is not mandatory to support a protocol for
>it.
>
>Most users will be unable to specify the details of an AC and this will
>either be done locally at the level of the AA or remotely by using protocols
>dedicated to managers only. The job of these managers is to make life easy
>for certificate holders. They will define AC templates so that ACs can later
>on be created upon request from the AC holders by using these templates.
>Some grouping of attributes will need to be done to fulfill a job or to
>perform a set of operations. The AC holder will thus only need to know the
>references of these various templates that will be tailored to match their
>jobs. In some cases, end-users will make the definition themselves and then
>will use the reference of these definitions to get an AC.
>
>This means that AC will be obtained by providing a reference whose details
>are already known to the AA.
>
>As a summary, the following three basic functions are identified:
>
>    1) Attribute registration (no AC is produced). This can be invoked
>       several times. This function is optional since it can be done
>       locally.
>
>    2) AC template definition (a reference for a template is produced,
>       but no AC is produced). This function can be done locally or
>       remotely.
>
>    3) AC acquisition (an AC is produced based on a template reference).
>
>Additional functions are needed since the second function may be performed
>by managers while the third one will be performed by AC holders:
>
>   - list the AC templates for a given entity (for an AC holder or
>     a manager),
>
>   - list the AC templates for a set of entities (for a manager only).
>
>Note: This assumes that the AA already "know" the attribute type.
>If not, a registration function to register new attributes would be needed.
>
>Once an AC has been obtained, it may be necessary to revoke it (if this is
>allowed). However, the revocation requests is not for an AC, but either for
>an attribute or an AC template. This means that all ACs containing this
>attribute or produced using that template have to be revoked. This may be
>for one entity or for all entities using that attribute or that AC template.
>Since the requester (which may not be the AC holder) does not necessarily
>know all the AC s that have been issued, it cannot indicated the serial
>numbers of these ACs and thus let the AA find out how many and which ACs
>need to be revoked. This is fairly different from the ways PKCs are
>requested to be revoked.
>
>This description provides an hint on how an attribute revocation request
>should be handled. This is fairly different from the current proposal which
>is only able to revoke an AC by providing an AA name and a serial number.
>While useful in some cases, this is certainly insufficient.
>
>Since an AC is created for an AC holder and upon request from an AC holder,
>it is given back to the requester. In most protocols ACs are "pushed"
>towards an application or are provided attached to some signed data.
>Otherwise, the reference of the certificate is "pushed" by the AC holder and
>the AA may then provide the AC upon request. When that function is useful,
>it would be interesting to use an LDAP schema so that LDAP can be used for
>ACs, rather than a new dedicated protocol.
>
>Hereafter are a few comments on the two proposals.
>
>ACRMF is an "Attribute Certificate Request Message Format". It combines two
>functions mentioned earlier: the AC template definition function and the AC
>acquisition function. However, as indicated above, these functions should be
>separated.
>
>"Attribute Certificate Management Messages over CMS" - ACMC - fails to
>clearly present the functions that are supported. It is necessary to
>maintain open at the same time three other documents to be able to
>understand that document: [CMCbis], [ACRMF] and [CRMF]. Before going into
>the details, it would be most useful to express the functions that are
>supported.
>
>In section 3.6, GetCert is mentioned to be sufficient for attribute
>certificates while it only supports AC retrieval based upon the issuer name
>and the AC serial number. This function is insufficient and should be
>supported using LDAP.
>
>In section 3.8. the revoke request control attribute allows to revoke an
>attribute certificate, while it has been mentioned that this is
>insufficient.
>
>In section 4.1. attributes can be added but this is again insufficient:
>attributes with restrictions may need to be added. As an example, extensions
>like target Controls may be appropriate.
>
>CONCLUSION
>
>We first need to agree on a set of requirements before discussing the
>details of any proposal. It might be appropriate to write an
>Informational RFC to specify these requirements.
>
>Denis
>
> > 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           : Attribute Certificate Management Messages 
> over CMS
> >         Author(s)       : P. Yee
> >         Filename        : draft-ietf-pkix-acmc-01.txt
> >         Pages           : 10
> >         Date            : 06-Mar-02
> >
> > This document specifies modifications to the Certificate Management
> > Messages over CMS specification ([CMCbis]) to permit the management
> > of attribute certificates.  This document does not stand alone, but
> > must be used in conjunction with [CMCbis].  It is expected that the
> > modifications proposed here will also be used in conjunction with the
> > Attribute Certificate Request Message Format specification ([ACRMF]).
> >
> > A URL for this Internet-Draft is:
> > http://www.ietf.org/internet-drafts/draft-ietf-pkix-acmc-01.txt
> >
> > To remove yourself from the IETF Announcement list, send a message to
> > ietf-announce-request with the word unsubscribe in the body of the message.
> >
> > 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-acmc-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
> >


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g4MIoP324821 for ietf-pkix-bks; Wed, 22 May 2002 11:50:25 -0700 (PDT)
Received: from bulwinkle.sigaba.com (bulwinkle.sigaba.com [63.202.162.42]) by above.proper.com (8.11.6/8.11.3) with SMTP id g4MIoNL24811 for <[e-mail]>; Wed, 22 May 2002 11:50:23 -0700 (PDT)
Received:  from bsd.sigaba.com (63.202.162.50)  by bulwinkle.sigaba.com (Sigaba Gateway v3.0)  with SMTP; Wed, 22 May 2002 11:48:20 (PDT)
Received:  from exchange1.sigaba.com (exchange1.sigaba.com [10.10.10.10]) by bsd.sigaba.com (8.12.2/8.12.2) with ESMTP id g4MIoKre007087; Wed, 22 May 2002 11:50:20 -0700
Received:  by exchange.sigaba.com with Internet Mail Service (5.5.2653.19) id <LN3WCWHB>; Wed, 22 May 2002 11:50:20 -0700
Message-id:  <[e-mail]>
From: Trevor Perrin <[e-mail]>
To: "'[e-mail]'" <[e-mail]>, Trevor Perrin <[e-mail]>
Cc: [e-mail], [e-mail]
Subject:  RE: Proxy PKI.
Date:  Wed, 22 May 2002 11:50:19 -0700
MIME-Version:  1.0
X-mailer:  Internet Mail Service (5.5.2653.19)
Content-Type:  text/plain; charset="iso-8859-1"
Content-Transfer-Encoding:  7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Or maybe a CA is just a proxy in disguise!:  A CA receives an "authenticated
message" from a client, which just happens to be a public key, and signs the
message, while specifying who he is signing on behalf of.

Now allow the client to send a hash of a document, instead of a public key.
Imagine that the CA signs and returns a "certificate" which has this
document hash instead of the public key.  This "certificate" would specify
the name of the client and the policy under which the certificate was
issued, it would have a serial number so it could be later revoked, and
could be processed by the relying party as part of the certificate path.

In other words, a certificate says "this public key is associated with this
person under this policy".  Maybe we could generalize this structure to make
statements about things besides public keys.

Also, whereas a certificate is a declarative statement about an operation
performed by a TTP in the past ("I authenticated the client with a password,
he said this"), maybe you could invert the notion of a certificate to get a
structure which is encrypted to a TTP instead of signed by one, and is an
imperative instead of declarative statement ("authenticate the client with a
password, tell him this").  Ie, instead of saying "this client WAS bound to
this hash", it would say "this client SHOULD BE given this symmetric key".
Which is a kookier notion, but I actually think it makes a little sense..

This is discussed, not that coherently, in 4.1/4.2:
http://www.sigaba.com/products/whitepapers/delegatedCrypto.pdf


-----Original Message-----
From: [e-mail] [mailto:[e-mail]]
Sent: Wednesday, May 22, 2002 11:03 AM
To: Trevor Perrin
Cc: [e-mail]; [e-mail]
Subject: RE: Proxy PKI.



aka from trust standpoint, the described proxy PKI is a certification
authority in disguise ... implying possibly it might be in need of things
like CPS.



Received: by above.proper.com (8.11.6/8.11.3) id g4MI6bd23772 for ietf-pkix-bks; Wed, 22 May 2002 11:06:37 -0700 (PDT)
Received: from nymelsmtp.internet.ny.fdms.firstdata.com ([204.124.248.17]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g4MI6aL23765 for <[e-mail]>; Wed, 22 May 2002 11:06:36 -0700 (PDT)
Subject: RE: Proxy PKI.
To: Trevor Perrin <[e-mail]>
Cc: [e-mail], [e-mail]
X-Mailer: Lotus Notes Release 5.0.5  September 22, 2000
Message-ID: <[e-mail]>
From: [e-mail]
Date: Wed, 22 May 2002 12:03:28 -0600
X-MIMETrack: Serialize by Router on NYMELSMTP/NY/FDMS/FDC(Release 5.0.8 |June 18, 2001) at 05/22/2002 02:03:25 PM
MIME-Version: 1.0
Content-type: text/plain; charset=us-ascii
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

aka from trust standpoint, the described proxy PKI is a certification
authority in disguise ... implying possibly it might be in need of things
like CPS.




Received: by above.proper.com (8.11.6/8.11.3) id g4MFi1N17753 for ietf-pkix-bks; Wed, 22 May 2002 08:44:01 -0700 (PDT)
Received: from nymelsmtp.internet.ny.fdms.firstdata.com ([204.124.248.17]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g4MFhxL17743 for <[e-mail]>; Wed, 22 May 2002 08:43:59 -0700 (PDT)
Subject: RE: Proxy PKI.
To: Trevor Perrin <[e-mail]>
Cc: [e-mail], [e-mail]
X-Mailer: Lotus Notes Release 5.0.5  September 22, 2000
Message-ID: <[e-mail]>
From: [e-mail]
Date: Wed, 22 May 2002 09:41:31 -0600
X-MIMETrack: Serialize by Router on NYMELSMTP/NY/FDMS/FDC(Release 5.0.8 |June 18, 2001) at 05/22/2002 11:40:47 AM
MIME-Version: 1.0
Content-type: text/plain; charset=us-ascii
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

and of course the other case for Proxy PKI is where there is a hierarchy of
trust .... like in B-to-B scenario and the proxy may implement some number
of business rules in addition to authentication on subordinate trust units
(like a corporate purchasing department approval iinfrastructure). From a
design standpoint the authentication paradigm (password or digital
signature) on inbound requests from subordinate trust units should be
transparent to the outbound digital signed requests. top-level trust units
(say in b-to-b corporate scenario) shouldn't care about the internal trust
mechanism and/or even that their are subordinate trust units. This is
sort-of like inverting the standard CA trust hierarchy ... rather than the
CA distributing static proxy trust certificates to each individual .... and
each individual distributing the static proxy trust certificates with each
of their signed messages .... the individuals send each authenticated
message directly to the CA-equivalent  ... and the CA does real-time rules
in addition to the authentication operation before replacing the
lower-level trust authentication with their own digital signature and
sending it on. In this sort-of inverted trust paradigm, each message
becomes a little like a real-time certificate (and the originating
subordinate trust unit information doesn't even have to be propogated). The
trust paradigm is still with the entity applying the (final) digital
signature ... regardless of whether it chooses to use a single key-pair or
a multitude of key-pairs creating the facade of multiple entities
(simulating each of its sub-ordinate trust units).








Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g4MEEVq13338 for ietf-pkix-bks; Wed, 22 May 2002 07:14:31 -0700 (PDT)
Received: from dns2.anl.gov (dns2.anl.gov [146.139.254.3]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g4MEEUL13334 for <[e-mail]>; Wed, 22 May 2002 07:14:30 -0700 (PDT)
Received: from anl.gov (atalanta.ctd.anl.gov [146.137.64.60]) by dns2.anl.gov (8.9.1a/8.9.1) with ESMTP id JAA10575; Wed, 22 May 2002 09:14:26 -0500 (CDT)
Message-ID: <[e-mail]>
Date: Wed, 22 May 2002 09:14:16 -0500
From: "Douglas E. Engert" <[e-mail]>
X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Trevor Perrin <[e-mail]>
CC: [e-mail]
Subject: Re: Proxy PKI.
References: <[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Trevor Perrin wrote:
> 
> Hello PKIX,
> 
> Here's one way of looking at "proxy PKI".  I won't keep spamming the list
> about this, but I just wanted to throw it out there once..  I'd love any
> feedback, or hearing about similar thoughts/projects.

You should look a the Globus Project at http://www.globus.org
The GSI is a GSSAPI built on top of SSL. It uses proxy certificates
to delegate. 

The proxies used with the GSI today are the inspiration for: 
http://www.ietf.org/internet-drafts/draft-ietf-pkix-proxy-02.txt

So although the proxy you are describing is not the same, some of the
concepts are similar, as the GSI proxies are delegated to others to act
on behalf of a user. 


> 
> With PKI, it's implicitly assumed that when something verifies with a public
> key, this key is "speaking for" everyone in its certificate, and when
> something is encrypted to this key, it is "heard by" everyone in the
> certificate.  Thus, if a group certificate is used, it is left unspecified
> which member of the group is actually sending/should receive the data.
> 
> Ie, PKI allows the semantics
>  - K1 says K2 speaks and hears for x (certificate)
>  - K2 says y (signature)
>  - only K2 hears y (encryption)
> 
> But does not allow indirect statements, like
>  - K1 says "x says y"
>  - only K1 hears "only x should hear y"
> 
> (K1, K2 are public keys, x is some set of named principals, y is some
> document)
> 
> This indirection would allow PKI "gateways", which would represent entities
> in security domains that are not otherwise part of the PKI.  In particular,
> clients who don't want the burdens of managing their own key pair or
> interfacing with PKI could authenticate to such gateways using simple
> methods like passwords.  These gateways could be inline with the
> communication path, like S/MIME Domain Security, or perpendicular to it,
> where clients call out to the gateways to perform signatures and
> decryptions.
> 
> With this indirection, statements can be made two different ways: either
> directly or indirectly.  This suggests we separate *how* things are said
> from *what* is being said.  Ignoring encryption, what can be said is:
>  - "K speaks for x" (introduction)
>  - "x says y" (attribution)
>  - application data
> The first corresponds to the to-be-signed content of a certificate, where x
> specifies the name(s) associated with public key K.  The second is similar,
> but instead of associating x with a public key, x is associated with a
> particular statement y, represented by its hash value.
> 
> Statements can be made by:
>  - signing them directly with a private key
>  - attributing them (i.e. including their hash value as y above)
> 
> Introductions and attributions could be chained arbitrarily, but since
> they're both defined on the same names, they can be processed uniformly by
> certificate validation logic.  A chain would be like:
>  - K1 says K2 speaks for a* (signed introduction, ie certificate)
>  - K2 says K3 speaks for a* (signed introduction)
>  - K3 says a* says          (signed attribution)
>   - ab* says                (attributed attribution)
>    - abc* says              (attributed attribution)
>     - K4 speaks for abcd*   (attributed introduction)
>  - K4 says abcde* says      (signed attribution)
>   - K5 speaks for abcdef*   (attributed introduction)
>  - K5 says acdef* says      (signed attribution)
>   - abcdefg* says           (attributed attribution)
>    - acdefgh says           (attributed attribution)
>     - hi                    (attributed application data)
> 
> The attribution chains could be collapsed.  Intuitively, instead of saying
> "Alice says Bob says Charlie says hi", I could just say "Charlie says hi",
> assuming I trust Alice and Bob.  But if I explicitly mention them, then
> later on when I (or you) discover that Alice is untrustworthy, it becomes
> easier to recover.
> 
> This may not justify the complexity of nested attributions.  We could make
> things simpler by disallowing attributions except in the final signature
> over application data.  This would give a more conventional certificate
> chain, but where the end-entity can explicitly represent who he is signing
> on behalf of:
>  - K1 says K2 speaks for a*
>  - K2 says K3 speaks for a*
>  - K3 says K4 speaks for acbd*
>  - K4 says K5 speaks for acdef*
>  - K5 says abcdefgh says
>   - hi
> 
> This last attribution could be represented in a variety of ways, for example
> embedding a SAML Assertion as a signed property of an XML Signature.  The
> inverse notion, an encryption instructing a particular public key whom to
> give the encrypted data to, could be represented by a similar idiom
> involving XML Encryption and XACML.  A request/response protocol could be
> defined allowing clients to delegate processing of these structures to their
> "PKI gateways".
> 
> The paper I mentioned a couple mails ago discusses this and also trying to
> represent this in X.509.  If a standard way to bind names into these signed
> hashes and encrypted symmetric keys could be decided on, then potentially,
> application protocols could be modified to use these and thus support PKI
> gateways, allowing people with only passwords to do S/MIME mail, TLS client
> authentication, etc..
> 
> Trevor
> 
> -----Original Message-----
> From: Trevor Perrin [mailto:[e-mail]]
> Sent: Tuesday, May 21, 2002 10:45 AM
> To: '[e-mail]'; Trevor Perrin; [e-mail]
> Cc: [e-mail]
> Subject: RE: Proxy PKI. Was: IBM alternative to PKI?
> 
> Hi Peter,
> 
> I'm interested.  I hope you put up more information soon.  If you're talking
> about the "Authentication Proxies" described in 6.9.2 of the "Authentication
> Mechanisms" paper, then it's sort of a mirror-image to what I'm advocating,
> ie
>  - converting PKI authentications -> legacy (password) authentications to
> make things easier on apps
> versus
>  - converting legacy authentications -> PKI operations to make things easier
> on users/desktop software
> 
> Trevor
> 
> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]]
> Sent: Sunday, May 19, 2002 9:34 PM
> To: [e-mail]; [e-mail]
> Cc: [e-mail]
> Subject: RE: Proxy PKI. Was: IBM alternative to PKI?
> 
> Trevor Perrin <[e-mail]> writes:
> 
> >I'm suggesting this proxy could be used for anything a private key is used
> >for: signing, authenticating, decrypting.  The idea is just to let people
> with
> >only authentication mechanisms do PKI "stuff" in a simple fashion, by
> having a
> >server do it for them.
> 
> Something similar is being done in the SEE PKI project
> (http://www.e-government.govt.nz/see/pki/index.asp, although some of the
> newer
> documents covering this haven't been posted yet) as a means of letting
> people
> use a PKI without having to go through the pain of actually having to use a
> PKI.  This uses (among other approaches) proxies to front-end to a PKI to
> allow
> existing/alternative mechanisms to be used.
> 
> Peter.

-- 

 Douglas E. Engert  <[e-mail]>
 Argonne National Laboratory
 9700 South Cass Avenue
 Argonne, Illinois  60439 
 [phone]


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g4MAqPo00202 for ietf-pkix-bks; Wed, 22 May 2002 03:52:25 -0700 (PDT)
Received: from srv-mail.fst.it (nhmp.fst.it [208.164.5.212]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g4MAqML00192 for <[e-mail]>; Wed, 22 May 2002 03:52:23 -0700 (PDT)
Received: by srv-mail.fst.it with Internet Mail Service (5.5.2653.19) id <H7WVNSAR>; Wed, 22 May 2002 12:51:09 +0200
Message-ID: <[e-mail]>
From: Massimiliano Farris <[e-mail]>
To: "'Denis Pinkas'" <[e-mail]>
Cc: "'[e-mail]'" <[e-mail]>
Subject: RE: association between the time-stamp and the original document
Date: Wed, 22 May 2002 12:51:09 +0200
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Dear Denis,

thanks for your patience.  You got my point.
I am using time stamps in a service of certified
mail, where we time stamp e-mail messages, which
might not be signed.  At the moment we are sending
the original message and the time stamp as two
MIME attachments.  We do not like this and would 
prefer to "attach the data (even not signed) 
to the timestamp". To do this we would like to 
insert the whole document in the time stamp, 
in order to make time stamp verification more 
robust.


Another desideratum is to let the user store
messages (which are not SignedData) and associated 
time stamp.  At the moment I am using file extensions 
to do this.
But what if the user wants to request some new time
stamp on the message?  We do not like to solve
this at the application level (for example with a 
private store of time stamps indexed by document hashes)
or worse with some funny file extension syntax.

A sequence of URIs inserted in the time stamp is
much more attractive to us,  but is there
a CMS attribute that would suggest our intent in some 
generally understandable way?
For example, could ContentHints from ESS be a
valid choice, or is there any better alternative?



> -----Original Message-----
> From: Denis Pinkas [mailto:[e-mail]]
> Sent: mercoledi 22 maggio 2002 11.30
> To: Massimiliano Farris
> Cc: '[e-mail]'
> Subject: Re: association between the time-stamp and the original
> document
> 
> 
> Massimiliano,
> 
> > > In the context of the use of CMS, RFC 3126 has defined 
> two time-stamp
> > > related attributes:
> > >
> > > 1) A signed attribute, attached to the SignedData.
> > >    It is the Content Time-Stamp attribute (p.34).
> > >
> > >    The content time-stamp attribute is an attribute which 
> is the time-
> > >    stamp of the signed data content before it is signed.
> > >
> > >       id-aa-ets-contentTimestamp OBJECT IDENTIFIER ::= { iso(1)
> > >       member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9)
> > >       smime(16) id-aa(2) 20}
> > >
> > > 2) An unsigned attribute, attached to the digital signature.
> > >    It is the Signature Time-Stamp Attribute (p.36):
> > >
> > >    The Signature Timestamp attribute is a timestamp of 
> the signature
> > >    value.
> > >
> > >       id-aa-signatureTimeStampToken OBJECT IDENTIFIER ::= { iso(1)
> > >       member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9)
> > >       smime(16) id-aa(2) 14}
> > >
> > > As indicated, these attributes are only usable in the 
> context of a CMS
> > > message.
> > >
> > > Denis
> 
> >   I know it, I completely agree.
> 
> >   However, my question is about something else.
> 
> >   I talked of id-aa-signatureTimeStampToken only as an example.
> >   I'm talking about the definition of an Unsigned Attribute 
> to be used
> >   in the context of a time-stamp (which is a CMS).
> 
> This does make sense.
> 
> >   This lets a user to enrich the time-stamp received by a 
> TSA with the
> >   'object' of the time-stamp itself.
> >   In the first e-mail I said:
> > 
> >   > However, the user may not like to be involved in a
> >   > digital signature process everytime he wants to
> >   > timestamp a document.
> > 
> >   In this case, the user has the great problem to 'link', 
> to associate in
> >   some manner the time-stamp with the document. Without 
> this association,
> >   the time-stamp is useless.
> 
> There are two ways to perform the link:
> 
>   1) the time-stamp is attached to the data, this is what RFC 
> 3126 does.
>   2) the data is attached to the time-stamp, this is what you suggest.
> 
> >   Do you think this problem has to be solved by the client 
> responsible of
> >   managing the interaction with the TSA, without any 
> standardized way ?
> >   Do you think that only time-stamps of a signature have a sense ?
> 
> The link could be done locally by adding an unsigned attribute to the
> structure of the time-stamp token which is CMS based.
> 
> I would guess that you would like a sequence of URIs to be 
> included in that
> unsigned attribute. What else ?
> 
> Denis
> 


Received: by above.proper.com (8.11.6/8.11.3) id g4MA9Zg25464 for ietf-pkix-bks; Wed, 22 May 2002 03:09:35 -0700 (PDT)
Received: from web20007.mail.yahoo.com (web20007.mail.yahoo.com [216.136.225.70]) by above.proper.com (8.11.6/8.11.3) with SMTP id g4MA9XL25455 for <[e-mail]>; Wed, 22 May 2002 03:09:33 -0700 (PDT)
Message-ID: <[e-mail]>
Received: from [202.144.45.2] by web20007.mail.yahoo.com via HTTP; Wed, 22 May 2002 03:09:34 PDT
Date: Wed, 22 May 2002 03:09:34 -0700 (PDT)
From: vivek saraf <[e-mail]>
Subject: Re: polling reference
To: af Lamei <[e-mail]>, [e-mail]
In-Reply-To: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

when the request is sent from the RA server to the 
CA server, the CA may not process the request
immidiatly, the CA may need a manual approval for 
the request. In this case the CA will send a
polling ref number along with time to check back.
So the RA server must come back to CA server at
specified time and should submit the polling ref
number, if the request for the polling ref number is 
processed the CA will send the PKI response or else
it will send one more polling ref number and time to
check back.

vivek


--- af Lamei <[e-mail]> wrote:
> 
> Hi!
> 
> what does pollig refrence means and how it works in
> the TCP based transport (RFC 2510)?
> 
> af
> 
> 
> 
> ---------------------------------
> Do You Yahoo!?
> LAUNCH - Your Yahoo! Music Experience


__________________________________________________
Do You Yahoo!?
LAUNCH - Your Yahoo! Music Experience
http://launch.yahoo.com


Received: by above.proper.com (8.11.6/8.11.3) id g4M9Udt23496 for ietf-pkix-bks; Wed, 22 May 2002 02:30:39 -0700 (PDT)
Received: from odin2.bull.net (odin2.bull.net [192.90.70.84]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g4M9UbL23491 for <[e-mail]>; Wed, 22 May 2002 02:30:38 -0700 (PDT)
Received: from lvn-m002.frlv.bull.fr (lvn-m002.frlv.bull.fr [129.184.62.72]) by odin2.bull.net (8.9.3/8.9.3) with ESMTP id LAA13440; Wed, 22 May 2002 11:33:54 +0200
Received: from bull.net ([129.184.37.97]) by lvn-m002.frlv.bull.fr (Lotus Domino Release 5.0.8) with ESMTP id 2002052211300510:401 ; Wed, 22 May 2002 11:30:05 +0200 
Message-ID: <[e-mail]>
Date: Wed, 22 May 2002 11:30:04 +0200
From: Denis Pinkas <[e-mail]>
Organization: Bull SA.
X-Mailer: Mozilla 4.7 [fr] (Win98; I)
X-Accept-Language: fr
MIME-Version: 1.0
To: Massimiliano Farris <[e-mail]>
CC: "'[e-mail]'" <[e-mail]>
Subject: Re: association between the time-stamp and the original document
References: <[e-mail]>
X-MIMETrack: Itemize by SMTP Server on LVN-M002/FR/BULL(Release 5.0.8 |June 18, 2001) at 22/05/2002 11:30:05, Serialize by Router on LVN-M002/FR/BULL(Release 5.0.8 |June 18, 2001) at 22/05/2002 11:30:36, Serialize complete at 22/05/2002 11:30:36
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset=us-ascii
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Massimiliano,

> > In the context of the use of CMS, RFC 3126 has defined two time-stamp
> > related attributes:
> >
> > 1) A signed attribute, attached to the SignedData.
> >    It is the Content Time-Stamp attribute (p.34).
> >
> >    The content time-stamp attribute is an attribute which is the time-
> >    stamp of the signed data content before it is signed.
> >
> >       id-aa-ets-contentTimestamp OBJECT IDENTIFIER ::= { iso(1)
> >       member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9)
> >       smime(16) id-aa(2) 20}
> >
> > 2) An unsigned attribute, attached to the digital signature.
> >    It is the Signature Time-Stamp Attribute (p.36):
> >
> >    The Signature Timestamp attribute is a timestamp of the signature
> >    value.
> >
> >       id-aa-signatureTimeStampToken OBJECT IDENTIFIER ::= { iso(1)
> >       member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9)
> >       smime(16) id-aa(2) 14}
> >
> > As indicated, these attributes are only usable in the context of a CMS
> > message.
> >
> > Denis

>   I know it, I completely agree.

>   However, my question is about something else.

>   I talked of id-aa-signatureTimeStampToken only as an example.
>   I'm talking about the definition of an Unsigned Attribute to be used
>   in the context of a time-stamp (which is a CMS).

This does make sense.

>   This lets a user to enrich the time-stamp received by a TSA with the
>   'object' of the time-stamp itself.
>   In the first e-mail I said:
> 
>   > However, the user may not like to be involved in a
>   > digital signature process everytime he wants to
>   > timestamp a document.
> 
>   In this case, the user has the great problem to 'link', to associate in
>   some manner the time-stamp with the document. Without this association,
>   the time-stamp is useless.

There are two ways to perform the link:

  1) the time-stamp is attached to the data, this is what RFC 3126 does.
  2) the data is attached to the time-stamp, this is what you suggest.

>   Do you think this problem has to be solved by the client responsible of
>   managing the interaction with the TSA, without any standardized way ?
>   Do you think that only time-stamps of a signature have a sense ?

The link could be done locally by adding an unsigned attribute to the
structure of the time-stamp token which is CMS based.

I would guess that you would like a sequence of URIs to be included in that
unsigned attribute. What else ?

Denis


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g4M8wp522593 for ietf-pkix-bks; Wed, 22 May 2002 01:58:51 -0700 (PDT)
Received: from srv-mail.fst.it (nhmp.fst.it [208.164.5.212]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g4M8woL22588 for <[e-mail]>; Wed, 22 May 2002 01:58:50 -0700 (PDT)
Received: by srv-mail.fst.it with Internet Mail Service (5.5.2653.19) id <H7WVNRYA>; Wed, 22 May 2002 10:57:36 +0200
Message-ID: <[e-mail]>
From: Massimiliano Farris <[e-mail]>
To: "'Denis Pinkas'" <[e-mail]>
Cc: "'J Adrian Pickering'" <[e-mail]>, "'[e-mail]'" <[e-mail]>
Subject: RE: association between the time-stamp and the original document
Date: Wed, 22 May 2002 10:57:35 +0200
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

> In the context of the use of CMS, RFC 3126 has defined two time-stamp
> related attributes:
> 
> 1) A signed attribute, attached to the SignedData. 
>    It is the Content Time-Stamp attribute (p.34).
> 
>    The content time-stamp attribute is an attribute which is the time-
>    stamp of the signed data content before it is signed.
> 
>       id-aa-ets-contentTimestamp OBJECT IDENTIFIER ::= { iso(1)
>       member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9)
>       smime(16) id-aa(2) 20}
> 
> 2) An unsigned attribute, attached to the digital signature. 
>    It is the Signature Time-Stamp Attribute (p.36):
> 
>    The Signature Timestamp attribute is a timestamp of the signature
>    value.
> 
>       id-aa-signatureTimeStampToken OBJECT IDENTIFIER ::= { iso(1)
>       member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) 
> smime(16)
>       id-aa(2) 14}
> 
> As indicated, these attributes are only usable in the context of a CMS
> message.
> 
> Denis
> 
  I know it, I completely agree.
  However, my question is about something else.
  I talked of id-aa-signatureTimeStampToken only as an example.
  I'm talking about the definition of an Unsigned Attribute to be used
  in the context of a time-stamp (which is a CMS).
  This lets a user to enrich the time-stamp received by a TSA with the
  'object' of the time-stamp itself.
  In the first e-mail I said:

  > However, the user may not like to be involved in a 
  > digital signature process everytime he wants to 
  > timestamp a document.

  In this case, the user has the great problem to 'link', to associate in
  some manner the time-stamp with the document. Without this association,
  the time-stamp is useless.
  Do you think this problem has to be solved by the client responsible of
  managing the interaction with the TSA, without any standardized way ?
  Do you think that only time-stamps of a signature have a sense ?


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g4M83O216386 for ietf-pkix-bks; Wed, 22 May 2002 01:03:24 -0700 (PDT)
Received: from odin2.bull.net (odin2.bull.net [192.90.70.84]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g4M83ML16379 for <[e-mail]>; Wed, 22 May 2002 01:03:22 -0700 (PDT)
Received: from lvn-m002.frlv.bull.fr (lvn-m002.frlv.bull.fr [129.184.62.72]) by odin2.bull.net (8.9.3/8.9.3) with ESMTP id KAA16132; Wed, 22 May 2002 10:06:37 +0200
Received: from bull.net ([129.184.37.97]) by lvn-m002.frlv.bull.fr (Lotus Domino Release 5.0.8) with ESMTP id 2002052210031002:380 ; Wed, 22 May 2002 10:03:10 +0200 
Message-ID: <[e-mail]>
Date: Wed, 22 May 2002 10:03:09 +0200
From: Denis Pinkas <[e-mail]>
Organization: Bull SA.
X-Mailer: Mozilla 4.7 [fr] (Win98; I)
X-Accept-Language: fr
MIME-Version: 1.0
To: Massimiliano Farris <[e-mail]>
CC: "'J Adrian Pickering'" <[e-mail]>, "'[e-mail]'" <[e-mail]>
Subject: Re: association between the time-stamp and the original document
References: <[e-mail]>
X-MIMETrack: Itemize by SMTP Server on LVN-M002/FR/BULL(Release 5.0.8 |June 18, 2001) at 22/05/2002 10:03:10, Serialize by Router on LVN-M002/FR/BULL(Release 5.0.8 |June 18, 2001) at 22/05/2002 10:03:19, Serialize complete at 22/05/2002 10:03:19
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset=us-ascii
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Massimiliano,

> > The TSA *must* be completely disinterested in what he/she/it is
> > timestamping. To allow the document or any version of it to
> > travel through
> > the ether would be a security risk and compromise the
> > impartiality of the TSA.
> >
> > So, the anwer is 'no', I think. Some other service might like
> > to offer such
> > a service, but not this one.
> >
> > Adrian Pickering/
> > Southampton UK
> >
>   I'm not talking about what the TSA can manage.
>   TSA never sees the original document, only its
>   digest.
>   I'm talking about the definition of an attribute,
>   such like the 'id-aa-timeStampToken' one, which
>   allows the user to easily store a SignedData with
>   its time-stamp(s).

In the context of the use of CMS, RFC 3126 has defined two time-stamp
related attributes:

1) A signed attribute, attached to the SignedData. 
   It is the Content Time-Stamp attribute (p.34).

   The content time-stamp attribute is an attribute which is the time-
   stamp of the signed data content before it is signed.

      id-aa-ets-contentTimestamp OBJECT IDENTIFIER ::= { iso(1)
      member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9)
      smime(16) id-aa(2) 20}

2) An unsigned attribute, attached to the digital signature. 
   It is the Signature Time-Stamp Attribute (p.36):

   The Signature Timestamp attribute is a timestamp of the signature
   value.

      id-aa-signatureTimeStampToken OBJECT IDENTIFIER ::= { iso(1)
      member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16)
      id-aa(2) 14}

As indicated, these attributes are only usable in the context of a CMS
message.

Denis

>   All I'm asking is to allow the user to store in a
>   sure and easy way both the time-stamp and the
>   original document.
>   Otherwise, many users will set up many different
>   non-standardized ways to do this work. It's a great
>   problem, because if the user loses the document, or change
>   even one byte of it, its time-stamp becomes useless.


Received: by above.proper.com (8.11.6/8.11.3) id g4M7a3L10204 for ietf-pkix-bks; Wed, 22 May 2002 00:36:03 -0700 (PDT)
Received: from srv-mail.fst.it (nhmp.fst.it [208.164.5.212]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g4M7a1L10199 for <[e-mail]>; Wed, 22 May 2002 00:36:02 -0700 (PDT)
Received: by srv-mail.fst.it with Internet Mail Service (5.5.2653.19) id <H7WVNRQY>; Wed, 22 May 2002 09:34:47 +0200
Message-ID: <[e-mail]>
From: Massimiliano Farris <[e-mail]>
To: "'J Adrian Pickering'" <[e-mail]>, "'[e-mail]'" <[e-mail]>
Subject: RE: association between the time-stamp and the original document
Date: Wed, 22 May 2002 09:34:47 +0200
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

> The TSA *must* be completely disinterested in what he/she/it is 
> timestamping. To allow the document or any version of it to 
> travel through 
> the ether would be a security risk and compromise the 
> impartiality of the TSA.
> 
> So, the anwer is 'no', I think. Some other service might like 
> to offer such 
> a service, but not this one.
> 
> Adrian Pickering/
> Southampton UK
> 
  I'm not talking about what the TSA can manage.
  TSA never sees the original document, only its
  digest.
  I'm talking about the definition of an attribute,
  such like the 'id-aa-timeStampToken' one, which 
  allows the user to easily store a SignedData with
  its time-stamp(s).
  All I'm asking is to allow the user to store in a
  sure and easy way both the time-stamp and the 
  original document.
  Otherwise, many users will set up many different
  non-standardized ways to do this work. It's a great
  problem, because if the user loses the document, or change
  even one byte of it, its time-stamp becomes useless. 



Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g4M6SOE26076 for ietf-pkix-bks; Tue, 21 May 2002 23:28:24 -0700 (PDT)
Received: from bulwinkle.sigaba.com (bulwinkle.sigaba.com [63.202.162.42]) by above.proper.com (8.11.6/8.11.3) with SMTP id g4M6SML26072 for <[e-mail]>; Tue, 21 May 2002 23:28:22 -0700 (PDT)
Received:  from bsd.sigaba.com (63.202.162.50)  by bulwinkle.sigaba.com (Sigaba Gateway v3.0)  with SMTP; Tue, 21 May 2002 23:26:18 (PDT)
Received:  from exchange1.sigaba.com (exchange1.sigaba.com [10.10.10.10]) by bsd.sigaba.com (8.12.2/8.12.2) with ESMTP id g4M6SHre019683 for <[e-mail]>; Tue, 21 May 2002 23:28:17 -0700
Received:  by exchange.sigaba.com with Internet Mail Service (5.5.2653.19) id <LLMYV0YF>; Tue, 21 May 2002 23:28:16 -0700
Message-id:  <[e-mail]>
From: Trevor Perrin <[e-mail]>
To: [e-mail]
Subject:  RE: Proxy PKI.
Date:  Tue, 21 May 2002 23:28:15 -0700
MIME-Version:  1.0
X-mailer:  Internet Mail Service (5.5.2653.19)
Content-Type:  text/plain; charset="iso-8859-1"
Content-Transfer-Encoding:  7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Hello PKIX,

Here's one way of looking at "proxy PKI".  I won't keep spamming the list
about this, but I just wanted to throw it out there once..  I'd love any
feedback, or hearing about similar thoughts/projects.

With PKI, it's implicitly assumed that when something verifies with a public
key, this key is "speaking for" everyone in its certificate, and when
something is encrypted to this key, it is "heard by" everyone in the
certificate.  Thus, if a group certificate is used, it is left unspecified
which member of the group is actually sending/should receive the data.

Ie, PKI allows the semantics
 - K1 says K2 speaks and hears for x (certificate)
 - K2 says y (signature)
 - only K2 hears y (encryption)

But does not allow indirect statements, like
 - K1 says "x says y"
 - only K1 hears "only x should hear y"

(K1, K2 are public keys, x is some set of named principals, y is some
document)

This indirection would allow PKI "gateways", which would represent entities
in security domains that are not otherwise part of the PKI.  In particular,
clients who don't want the burdens of managing their own key pair or
interfacing with PKI could authenticate to such gateways using simple
methods like passwords.  These gateways could be inline with the
communication path, like S/MIME Domain Security, or perpendicular to it,
where clients call out to the gateways to perform signatures and
decryptions.

With this indirection, statements can be made two different ways: either
directly or indirectly.  This suggests we separate *how* things are said
from *what* is being said.  Ignoring encryption, what can be said is:
 - "K speaks for x" (introduction)
 - "x says y" (attribution)
 - application data
The first corresponds to the to-be-signed content of a certificate, where x
specifies the name(s) associated with public key K.  The second is similar,
but instead of associating x with a public key, x is associated with a
particular statement y, represented by its hash value.

Statements can be made by:
 - signing them directly with a private key
 - attributing them (i.e. including their hash value as y above)

Introductions and attributions could be chained arbitrarily, but since
they're both defined on the same names, they can be processed uniformly by
certificate validation logic.  A chain would be like:
 - K1 says K2 speaks for a* (signed introduction, ie certificate)
 - K2 says K3 speaks for a* (signed introduction)
 - K3 says a* says          (signed attribution)
  - ab* says                (attributed attribution)
   - abc* says              (attributed attribution)
    - K4 speaks for abcd*   (attributed introduction)
 - K4 says abcde* says      (signed attribution)
  - K5 speaks for abcdef*   (attributed introduction)
 - K5 says acdef* says      (signed attribution)
  - abcdefg* says           (attributed attribution)
   - acdefgh says           (attributed attribution)
    - hi                    (attributed application data)

The attribution chains could be collapsed.  Intuitively, instead of saying
"Alice says Bob says Charlie says hi", I could just say "Charlie says hi",
assuming I trust Alice and Bob.  But if I explicitly mention them, then
later on when I (or you) discover that Alice is untrustworthy, it becomes
easier to recover.

This may not justify the complexity of nested attributions.  We could make
things simpler by disallowing attributions except in the final signature
over application data.  This would give a more conventional certificate
chain, but where the end-entity can explicitly represent who he is signing
on behalf of:
 - K1 says K2 speaks for a*
 - K2 says K3 speaks for a*
 - K3 says K4 speaks for acbd*
 - K4 says K5 speaks for acdef*
 - K5 says abcdefgh says
  - hi 

This last attribution could be represented in a variety of ways, for example
embedding a SAML Assertion as a signed property of an XML Signature.  The
inverse notion, an encryption instructing a particular public key whom to
give the encrypted data to, could be represented by a similar idiom
involving XML Encryption and XACML.  A request/response protocol could be
defined allowing clients to delegate processing of these structures to their
"PKI gateways".  

The paper I mentioned a couple mails ago discusses this and also trying to
represent this in X.509.  If a standard way to bind names into these signed
hashes and encrypted symmetric keys could be decided on, then potentially,
application protocols could be modified to use these and thus support PKI
gateways, allowing people with only passwords to do S/MIME mail, TLS client
authentication, etc..

Trevor



-----Original Message-----
From: Trevor Perrin [mailto:[e-mail]]
Sent: Tuesday, May 21, 2002 10:45 AM
To: '[e-mail]'; Trevor Perrin; [e-mail]
Cc: [e-mail]
Subject: RE: Proxy PKI. Was: IBM alternative to PKI?




Hi Peter,

I'm interested.  I hope you put up more information soon.  If you're talking
about the "Authentication Proxies" described in 6.9.2 of the "Authentication
Mechanisms" paper, then it's sort of a mirror-image to what I'm advocating,
ie
 - converting PKI authentications -> legacy (password) authentications to
make things easier on apps
versus
 - converting legacy authentications -> PKI operations to make things easier
on users/desktop software

Trevor

-----Original Message-----
From: [e-mail] [mailto:[e-mail]]
Sent: Sunday, May 19, 2002 9:34 PM
To: [e-mail]; [e-mail]
Cc: [e-mail]
Subject: RE: Proxy PKI. Was: IBM alternative to PKI?


Trevor Perrin <[e-mail]> writes:

>I'm suggesting this proxy could be used for anything a private key is used
>for: signing, authenticating, decrypting.  The idea is just to let people
with
>only authentication mechanisms do PKI "stuff" in a simple fashion, by
having a
>server do it for them.

Something similar is being done in the SEE PKI project 
(http://www.e-government.govt.nz/see/pki/index.asp, although some of the
newer
documents covering this haven't been posted yet) as a means of letting
people
use a PKI without having to go through the pain of actually having to use a
PKI.  This uses (among other approaches) proxies to front-end to a PKI to
allow
existing/alternative mechanisms to be used.

Peter.


Received: by above.proper.com (8.11.6/8.11.3) id g4M5vB219766 for ietf-pkix-bks; Tue, 21 May 2002 22:57:11 -0700 (PDT)
Received: from popsmtp1.icenet.net (popsmtp.icenet.net [203.88.128.12]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g4M5v7L19762 for <[e-mail]>; Tue, 21 May 2002 22:57:08 -0700 (PDT)
Received: from numenindia.com (ice.131.client73.icenet.net [203.88.131.73] (may be forged)) by popsmtp1.icenet.net (8.9.3/8.9.3) with SMTP id LAA01547 for <[e-mail]>; Wed, 22 May 2002 11:24:44 +0530
X-Distribution-To: [e-mail]
From: "narendra" <[e-mail]>
To: <[e-mail]>
Subject: suggestion needed
Date: Tue, 21 May 2002 23:27:07 +0530
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.2911.0)
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700
Importance: Normal
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Dear sir,
   I am working on public key infrastructure in my organization.Our
oraganization is mainly on IT.Our organization is consits of five department
each consists of average 50 employees and  also having braches all over the
contry in india.I want to set up public key infrastrucure for my
organization.What would be the idea solution?

I know the below options,
1.Programmitically
2.use others product
Programmitically:
        I am having X509 toolkit form algorithmic reaserach which has the
capabiltiy of setting public key infrastructure.It provides set of strucures
and fucntions for certificate generation,certificate request , certificate
process ,Reply,Certificate revocation.
Another option is windows CAPI-cryptography  Application programming
inerface.

Third party product:-
1.Windows 2000 Public key infrastructure.
2.vesisign or others.

What would be the ideal solution?

seeking your co-opertaion,
narendra.

--------------------------------------------
Parmar Narendrasinh Abhesinh
Numen Technologies Pvt.Ltd,
505 "ADITYA"
Opp.Sardar Patel Seva Samaj,
Off.C.G.Road,Ahmedabd-380 006
Phone no:- [phone]/6466310 ex-46,47,48





Received: by above.proper.com (8.11.6/8.11.3) id g4M5V5319307 for ietf-pkix-bks; Tue, 21 May 2002 22:31:05 -0700 (PDT)
Received: from web14806.mail.yahoo.com (web14806.mail.yahoo.com [216.136.224.222]) by above.proper.com (8.11.6/8.11.3) with SMTP id g4M5V3L19303 for <[e-mail]>; Tue, 21 May 2002 22:31:03 -0700 (PDT)
Message-ID: <[e-mail]>
Received: from [213.29.60.65] by web14806.mail.yahoo.com via HTTP; Tue, 21 May 2002 22:31:08 PDT
Date: Tue, 21 May 2002 22:31:08 -0700 (PDT)
From: af Lamei <[e-mail]>
Subject: polling reference
To: [e-mail]
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="0-28862636-1022045468=:52665"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

--0-28862636-1022045468=:52665
Content-Type: text/plain; charset=us-ascii


Hi!

what does pollig refrence means and how it works in the TCP based transport (RFC 2510)?

af



---------------------------------
Do You Yahoo!?
LAUNCH - Your Yahoo! Music Experience
--0-28862636-1022045468=:52665
Content-Type: text/html; charset=us-ascii

<P>Hi!</P>
<P>what does pollig refrence means and how it works in the TCP based transport (RFC 2510)?</P>
<P>af</P><p><br><hr size=1><b>Do You Yahoo!?</b><br>
<a href="http://rd.yahoo.com/welcome/*http://launch.yahoo.com">LAUNCH</a> - Your Yahoo! Music Experience
--0-28862636-1022045468=:52665--


Received: by above.proper.com (8.11.6/8.11.3) id g4LLdqR08979 for ietf-pkix-bks; Tue, 21 May 2002 14:39:52 -0700 (PDT)
Received: from osprey.wedgetail.com (starling.wedgetail.com [202.83.95.124]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g4LLdoL08974 for <[e-mail]>; Tue, 21 May 2002 14:39:50 -0700 (PDT)
Received: from wedgetail.com (eider.wedgetail.com [10.10.10.130]) by osprey.wedgetail.com (8.12.2/8.12.2) with ESMTP id g4LLdRn3016068; Wed, 22 May 2002 07:39:27 +1000 (EST)
Message-ID: <[e-mail]>
Date: Wed, 22 May 2002 07:39:27 +1000
From: Geoff Elgey <[e-mail]>
User-Agent: Mozilla/5.0 (X11; U; SunOS sun4u; en-US; rv:0.9.9) Gecko/20020311
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Peter Sylvester <[e-mail]>
CC: [e-mail]
Subject: Re: defining extension
References: <[e-mail]>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
X-Scanned-By: MIMEDefang 2.6 (www dot roaringpenguin dot com slash mimedefang)
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

G'day Peter,

Peter Sylvester wrote:
> can some tell me what in the 2002 versions of X.6XX 
> the XXX {DER, CER, BER, XER, PER) encoding of an
> OCTET STRING defined with a constraint like
> 
>      xxx         OCTET STRING ( CONTAINING abc )
> 
> is? Does it mean that the value should/must be encoded using the
> same encoding rules as the data that contain an instance of
> xxx?  

Yes, the value of the type 'abc' is encoded using the same encoding 
scheme, and that encoding becomes the payload of the outer OCTET STRING.

For example:

T1 ::= SEQUENCE {
   a INTEGER
}

T2 ::= OCTET STRING (CONTAINING T1)

v1 T2 ::= { a 0 }

If using a DER encoding, the value v1 would be encoded as 0x04, 0x05, 
0x30, 0x03, 0x02, 0x01, 0x00.

If using a BER encoding, the value v1 could be encoded as above, or by 
using indefinite length for the inner SEQUENCE: 0x04, 0x06, 0x30, 0x80, 
0x02, 0x01, 0x00, 0x00.

If you need to specify a difference encoding within the CONTAINING 
constraint, then you would use the ENCODED BY constraint:

T3 ::= OCTET STRING (
                 CONTAINING T1
                 ENCODED BY {joint-iso-itu-t asn1(1) ber-derived(2) 
distinguished-encoding(1)}) -- DER

v2 T3 ::= { a 0 }

If using a DER encoding, the value v2 would be encoded as 0x04, 0x05, 
0x30, 0x03, 0x02, 0x01, 0x00 (ie it is equivalent to encoding v1 under DER).

If using a BER encoding, then the inner SEQUENCE must be encoded as DER, 
so it cannot use indefinite length. This restricts the possible BER 
encodings of v2 to 0x04, 0x05, 0x30, 0x03, 0x02, 0x01, 0x00 (ie, the 
same as the DER encoding).

Hope this helps.

Cheers,
Geoff




Received: by above.proper.com (8.11.6/8.11.3) id g4LLFLl08009 for ietf-pkix-bks; Tue, 21 May 2002 14:15:21 -0700 (PDT)
Received: from vulcan.rsasecurity.com (mail.rsasecurity.com [204.167.114.123]) by above.proper.com (8.11.6/8.11.3) with SMTP id g4LLFJL08005 for <[e-mail]>; Tue, 21 May 2002 14:15:19 -0700 (PDT)
Received: from no.name.available by vulcan.rsasecurity.com via smtpd (for mail.imc.org [208.184.76.43]) with SMTP; 21 May 2002 21:13:33 UT
Received: from ebola.securitydynamics.com (ebola.securid.com [192.80.211.4]) by sdtihq24.securid.com (Pro-8.9.3/Pro-8.9.3) with ESMTP id RAA05620 for <[e-mail]>; Tue, 21 May 2002 17:15:21 -0400 (EDT)
Received: from exna00.securitydynamics.com (localhost [127.0.0.1]) by ebola.securitydynamics.com (8.10.2+Sun/8.10.2) with ESMTP id g4LLDUx28481 for <[e-mail]>; Tue, 21 May 2002 17:13:30 -0400 (EDT)
Received: by exna00.securitydynamics.com with Internet Mail Service (5.5.2653.19) id <K2ZL1XXJ>; Tue, 21 May 2002 17:15:20 -0400
Received: from HOUSLEY-LAP.rsasecurity.com (HOUSLEY-LAP [10.3.9.10]) by exna00.securitydynamics.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id K2ZL1XXD; Tue, 21 May 2002 17:15:07 -0400
From: "Housley, Russ" <[e-mail]>
To: kim hk <[e-mail]>
Cc: [e-mail]
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Version 5.1
Date: Tue, 21 May 2002 15:03:52 -0400
Subject: Re: Certification Path Validation Algorithm in RFC3280
In-Reply-To: <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"; format=flowed
X-MIME-Autoconverted: from 8bit to quoted-printable by sdtihq24.securid.com id RAA05620
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id g4LLFJL08006
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

 From RFC 3280 itself:

       * To promote interoperable implementations, a detailed algorithm
       for certification path validation is included in section 6.1 of
       this specification; RFC 2459 provided only a high-level
       description of path validation.

       * An algorithm for determining the status of a certificate using
       CRLs is provided in section 6.3 of this specification.  This
       material was not present in RFC 2459.

Russ

At 08:32 AM 5/21/2002 +0000, kim hk wrote:

>hi!
>I read RFC3280 document following by RFC2459.
>New certification path validation algorithm is present in this document.
>It is very much changed comparing to RFC2459 algorithm.
>
>We are still using path validation algorithm supplied in RFC2459.
>
>Is there any problem if we keep RFC2459 algorithm ?
>What advantage of using RFC3280 algorithm ?
>Thank you.
>Regards.
>
>_________________________________________________________________
>http://messenger.msn.co.kr¿¡¼­ MSN Messenger¸¦ ´Ù¿î·ÎµåÇÏ¿© ¿Â¶óÀÎ »ó¿¡ ÀÖ´Â
>Ä£±¸¿Í ´ëÈ­¸¦ ³ª´©¼¼¿ä.


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g4LK3OH05657 for ietf-pkix-bks; Tue, 21 May 2002 13:03:24 -0700 (PDT)
Received: from colossus.systems.pipex.net (colossus.systems.pipex.net [62.190.223.73]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g4LK3NL05652 for <[e-mail]>; Tue, 21 May 2002 13:03:23 -0700 (PDT)
Received: from home.ecs.soton.ac.uk (useria090.dsl.pipex.com [195.217.48.90]) by colossus.systems.pipex.net (Postfix) with ESMTP id 566E0160000C1; Tue, 21 May 2002 21:03:19 +0100 (BST)
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Version 4.3.1
Date: Tue, 21 May 2002 21:02:25 +0100
To: Massimiliano Farris <[e-mail]>, "'[e-mail]'" <[e-mail]>
From: J Adrian Pickering <[e-mail]>
Subject: Re: association between the time-stamp and the original document
In-Reply-To: <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

At 14:51 20/05/2002 +0200, Massimiliano Farris wrote:
>   I'm developing a client application that manages time-stamps.
>   The application is responsible for creating the TimeStampReq,
>   for sending it to the TSA, for receiving and processing TimeStampResp
>   and for browsing and verifying the TimeStampToken.
>
>   One of the concerns of people using the Client is:
>   << How can I link the time-stamp to the original document? >>.
>   The user must setup a mechanism based on some naming convention
>   and/or directory location.
>
>   The user can always sign his document, timestamp the signature and
>   add the token to the SignedData, as APPENDIX A specs in RFC 3161
>   says.
>   However, the user may not like to be involved in a digital signature
>process
>   everytime he wants to timestamp a document.
>
>   Don't you think it would be useful to define something like an Attribute
>   through which the user can store his document inside the token itself ?

The TSA *must* be completely disinterested in what he/she/it is 
timestamping. To allow the document or any version of it to travel through 
the ether would be a security risk and compromise the impartiality of the TSA.

So, the anwer is 'no', I think. Some other service might like to offer such 
a service, but not this one.

Adrian Pickering/
Southampton UK



Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g4LILLR01739 for ietf-pkix-bks; Tue, 21 May 2002 11:21:21 -0700 (PDT)
Received: from edelweb.fr (edelweb.fr [212.234.46.16]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g4LILIL01735 for <[e-mail]>; Tue, 21 May 2002 11:21:19 -0700 (PDT)
Received: from champagne.edelweb.fr (localhost.edelweb.fr [127.0.0.1]) by edelweb.fr with ESMTP id UAA07316 for <[e-mail]>; Tue, 21 May 2002 20:21:19 +0200 (MET DST)
Received: from champagne.edelweb.fr (champagne.edelweb.fr [193.51.14.161]) by edelweb.fr (nospam/1.5); Tue, 21 May 2002 20:21: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 UAA02813 for <[e-mail]>; Tue, 21 May 2002 20:21:18 +0200 (MET DST)
From: Peter Sylvester <[e-mail]>
Received: (sylvest@localhost) by emeriau.edelweb.fr (8.7.6/8.6.6) id UAA21532 for [e-mail]; Tue, 21 May 2002 20:21:18 +0200 (MET DST)
Date: Tue, 21 May 2002 20:21:18 +0200 (MET DST)
Message-Id: <[e-mail]>
To: [e-mail]
Subject: defining extension
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Althogh this is probably not the right list:

can some tell me what in the 2002 versions of X.6XX 
the XXX {DER, CER, BER, XER, PER) encoding of an
OCTET STRING defined with a constraint like

     xxx         OCTET STRING ( CONTAINING abc )

is? Does it mean that the value should/must be encoded using the
same encoding rules as the data that contain an instance of
xxx?  

Peter


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g4LHj1C00197 for ietf-pkix-bks; Tue, 21 May 2002 10:45:01 -0700 (PDT)
Received: from bulwinkle.sigaba.com (bulwinkle.sigaba.com [63.202.162.42]) by above.proper.com (8.11.6/8.11.3) with SMTP id g4LHj0L00186 for <[e-mail]>; Tue, 21 May 2002 10:45:00 -0700 (PDT)
Received:  from bsd.sigaba.com (63.202.162.50)  by bulwinkle.sigaba.com (Sigaba Gateway v3.0)  with SMTP; Tue, 21 May 2002 10:42:59 (PDT)
Received:  from exchange1.sigaba.com (exchange1.sigaba.com [10.10.10.10]) by bsd.sigaba.com (8.12.2/8.12.2) with ESMTP id g4LHiure030990; Tue, 21 May 2002 10:44:57 -0700
Received:  by exchange.sigaba.com with Internet Mail Service (5.5.2653.19) id <LLMYV0F5>; Tue, 21 May 2002 10:44:55 -0700
Message-id:  <[e-mail]>
From: Trevor Perrin <[e-mail]>
To: "'[e-mail]'" <[e-mail]>, Trevor Perrin <[e-mail]>, [e-mail]
Cc: [e-mail]
Subject:  RE: Proxy PKI. Was: IBM alternative to PKI?
Date:  Tue, 21 May 2002 10:44:54 -0700
MIME-Version:  1.0
X-mailer:  Internet Mail Service (5.5.2653.19)
Content-Type:  text/plain; charset="iso-8859-1"
Content-Transfer-Encoding:  7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Hi Peter,

I'm interested.  I hope you put up more information soon.  If you're talking
about the "Authentication Proxies" described in 6.9.2 of the "Authentication
Mechanisms" paper, then it's sort of a mirror-image to what I'm advocating,
ie
 - converting PKI authentications -> legacy (password) authentications to
make things easier on apps
versus
 - converting legacy authentications -> PKI operations to make things easier
on users/desktop software

Trevor

-----Original Message-----
From: [e-mail] [mailto:[e-mail]]
Sent: Sunday, May 19, 2002 9:34 PM
To: [e-mail]; [e-mail]
Cc: [e-mail]
Subject: RE: Proxy PKI. Was: IBM alternative to PKI?


Trevor Perrin <[e-mail]> writes:

>I'm suggesting this proxy could be used for anything a private key is used
>for: signing, authenticating, decrypting.  The idea is just to let people
with
>only authentication mechanisms do PKI "stuff" in a simple fashion, by
having a
>server do it for them.

Something similar is being done in the SEE PKI project 
(http://www.e-government.govt.nz/see/pki/index.asp, although some of the
newer
documents covering this haven't been posted yet) as a means of letting
people
use a PKI without having to go through the pain of actually having to use a
PKI.  This uses (among other approaches) proxies to front-end to a PKI to
allow
existing/alternative mechanisms to be used.

Peter.


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g4LDHqx16008 for ietf-pkix-bks; Tue, 21 May 2002 06:17:52 -0700 (PDT)
Received: from odin2.bull.net (odin2.bull.net [192.90.70.84]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g4LDHnL15997 for <[e-mail]>; Tue, 21 May 2002 06:17:50 -0700 (PDT)
Received: from lvn-m002.frlv.bull.fr (lvn-m002.frlv.bull.fr [129.184.62.72]) by odin2.bull.net (8.9.3/8.9.3) with ESMTP id PAA20224; Tue, 21 May 2002 15:20:54 +0200
Received: from bull.net ([129.184.37.97]) by lvn-m002.frlv.bull.fr (Lotus Domino Release 5.0.8) with ESMTP id 2002052115170535:298 ; Tue, 21 May 2002 15:17:05 +0200 
Message-ID: <[e-mail]>
Date: Tue, 21 May 2002 15:17:05 +0200
From: Denis Pinkas <[e-mail]>
Organization: Bull SA.
X-Mailer: Mozilla 4.7 [fr] (Win98; I)
X-Accept-Language: fr
MIME-Version: 1.0
To: [e-mail]
CC: [e-mail]
Subject: Re: I-D ACTION:draft-ietf-pkix-acmc-01.txt
References: <[e-mail]>
X-MIMETrack: Itemize by SMTP Server on LVN-M002/FR/BULL(Release 5.0.8 |June 18, 2001) at 21/05/2002 15:17:05, Serialize by Router on LVN-M002/FR/BULL(Release 5.0.8 |June 18, 2001) at 21/05/2002 15:17:40, Serialize complete at 21/05/2002 15:17:40
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset=us-ascii
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Comments on drafts "Attribute Certificate Request Message Format" and
"Attribute Certificate Management Messages over CMS" (March 2002)

The two drafts are very technical, hard to read, inter-related and do
not have sufficient explanations to allow a rapid and easy understanding for
everyone. It can be observed that no comment has been sent up to now on
acmc.

It is assumed that managing ACs is as simple as managing PKCs and thus that
protocols able to manage PKCs, with a few modifications, will be able to
manage ACs. This assumption is incorrect.

The way ACs are managed is very different from the way PKCs are managed and
for that reason it is not believed that extending CRMF and CMC is the right
way. Whether some extension to CMP would be able to do the job better will
not be discussed either. The problem is that is that we have a solution
without requirements, so it is hard to say whether or not the solution fits
the requirements. 

It would be appropriate to write of the requirements first, so that we can
all understand how a proposal would fit these requirements.

Before looking into some of these requirements, it is important to
understand the major differences with a PKC.

When a PKC is requested, a template of the PKC is provided together with
registration information. From that request, a *single *certificate will be
created later on, and will be given back to the requester and/or placed in a
repository.

When an attribute (beware, *not* an AC) is registered, that attribute is
provided together with registration information. No AC is created from that
request. The registration information consists of two main components:

   - the definition of the attribute itself, together with some 
     constraints that apply to it (see later) and the revocation 
     conditions for that attribute.

   - the way to link the "to-be-created-ACs" with an entity, most of 
     the time by linking it to a PKC. In that case providing the PKC is 
     not always sufficient since the subject DN may not be explicit 
     enough and thus information (or some link) from the CA that has 
     created the PKC may be necessary.

Attribute registration is usually not done by the end user that will
become ultimately the AC holder. Various attributes can be registered. Some
attributes may be registered with some constraints like, the validity period
of ACs that may be issued later on; how revocation will be handled, if
handled for that attribute; restrictions that will apply to that attribute
like target controls. Note that this operation is not necessary done
remotely using a protocol, so it is not mandatory to support a protocol for
it.

Most users will be unable to specify the details of an AC and this will
either be done locally at the level of the AA or remotely by using protocols
dedicated to managers only. The job of these managers is to make life easy
for certificate holders. They will define AC templates so that ACs can later
on be created upon request from the AC holders by using these templates.
Some grouping of attributes will need to be done to fulfill a job or to
perform a set of operations. The AC holder will thus only need to know the
references of these various templates that will be tailored to match their
jobs. In some cases, end-users will make the definition themselves and then
will use the reference of these definitions to get an AC.

This means that AC will be obtained by providing a reference whose details
are already known to the AA.

As a summary, the following three basic functions are identified:

   1) Attribute registration (no AC is produced). This can be invoked 
      several times. This function is optional since it can be done 
      locally.

   2) AC template definition (a reference for a template is produced, 
      but no AC is produced). This function can be done locally or 
      remotely.

   3) AC acquisition (an AC is produced based on a template reference).

Additional functions are needed since the second function may be performed
by managers while the third one will be performed by AC holders:

  - list the AC templates for a given entity (for an AC holder or 
    a manager),

  - list the AC templates for a set of entities (for a manager only).

Note: This assumes that the AA already "know" the attribute type. 
If not, a registration function to register new attributes would be needed. 

Once an AC has been obtained, it may be necessary to revoke it (if this is
allowed). However, the revocation requests is not for an AC, but either for
an attribute or an AC template. This means that all ACs containing this
attribute or produced using that template have to be revoked. This may be
for one entity or for all entities using that attribute or that AC template.
Since the requester (which may not be the AC holder) does not necessarily
know all the AC s that have been issued, it cannot indicated the serial
numbers of these ACs and thus let the AA find out how many and which ACs
need to be revoked. This is fairly different from the ways PKCs are
requested to be revoked.

This description provides an hint on how an attribute revocation request
should be handled. This is fairly different from the current proposal which
is only able to revoke an AC by providing an AA name and a serial number.
While useful in some cases, this is certainly insufficient.

Since an AC is created for an AC holder and upon request from an AC holder,
it is given back to the requester. In most protocols ACs are "pushed"
towards an application or are provided attached to some signed data.
Otherwise, the reference of the certificate is "pushed" by the AC holder and
the AA may then provide the AC upon request. When that function is useful,
it would be interesting to use an LDAP schema so that LDAP can be used for
ACs, rather than a new dedicated protocol.

Hereafter are a few comments on the two proposals.

ACRMF is an "Attribute Certificate Request Message Format". It combines two
functions mentioned earlier: the AC template definition function and the AC
acquisition function. However, as indicated above, these functions should be
separated. 

"Attribute Certificate Management Messages over CMS" - ACMC - fails to
clearly present the functions that are supported. It is necessary to
maintain open at the same time three other documents to be able to
understand that document: [CMCbis], [ACRMF] and [CRMF]. Before going into
the details, it would be most useful to express the functions that are
supported. 

In section 3.6, GetCert is mentioned to be sufficient for attribute
certificates while it only supports AC retrieval based upon the issuer name
and the AC serial number. This function is insufficient and should be
supported using LDAP.

In section 3.8. the revoke request control attribute allows to revoke an
attribute certificate, while it has been mentioned that this is
insufficient.

In section 4.1. attributes can be added but this is again insufficient:
attributes with restrictions may need to be added. As an example, extensions
like target Controls may be appropriate.

CONCLUSION

We first need to agree on a set of requirements before discussing the
details of any proposal. It might be appropriate to write an
Informational RFC to specify these requirements.

Denis

> 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           : Attribute Certificate Management Messages over CMS
>         Author(s)       : P. Yee
>         Filename        : draft-ietf-pkix-acmc-01.txt
>         Pages           : 10
>         Date            : 06-Mar-02
> 
> This document specifies modifications to the Certificate Management
> Messages over CMS specification ([CMCbis]) to permit the management
> of attribute certificates.  This document does not stand alone, but
> must be used in conjunction with [CMCbis].  It is expected that the
> modifications proposed here will also be used in conjunction with the
> Attribute Certificate Request Message Format specification ([ACRMF]).
> 
> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-ietf-pkix-acmc-01.txt
> 
> To remove yourself from the IETF Announcement list, send a message to
> ietf-announce-request with the word unsubscribe in the body of the message.
> 
> 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-acmc-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
>


Received: by above.proper.com (8.11.6/8.11.3) id g4L8Xvn25287 for ietf-pkix-bks; Tue, 21 May 2002 01:33:57 -0700 (PDT)
Received: from hotmail.com (f269.law12.hotmail.com [64.4.18.144]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g4L8XuL25283 for <[e-mail]>; Tue, 21 May 2002 01:33:56 -0700 (PDT)
Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Tue, 21 May 2002 01:32:52 -0700
Received: from 203.233.91.230 by lw12fd.law12.hotmail.msn.com with HTTP; Tue, 21 May 2002 08:32:51 GMT
X-Originating-IP: [203.233.91.230]
From: "kim hk" <[e-mail]>
To: [e-mail]
Subject: Certification Path Validation Algorithm in RFC3280
Date: Tue, 21 May 2002 08:32:51 +0000
Mime-Version: 1.0
Content-Type: text/plain; charset=ks_c_5601-1987; format=flowed
Message-ID: <[e-mail]>
X-OriginalArrivalTime: 21 May 2002 08:32:52.0044 (UTC) FILETIME=[18CAC8C0:01C200A2]
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

hi!
I read RFC3280 document following by RFC2459.
New certification path validation algorithm is present in this document.
It is very much changed comparing to RFC2459 algorithm.

We are still using path validation algorithm supplied in RFC2459.

Is there any problem if we keep RFC2459 algorithm ?
What advantage of using RFC3280 algorithm ? 

Thank you. 

Regards.

_________________________________________________________________
http://messenger.msn.co.kr¿¡¼­ MSN Messenger¸¦ ´Ù¿î·ÎµåÇÏ¿© ¿Â¶óÀÎ »ó¿¡ ÀÖ´Â
 Ä£±¸¿Í ´ëÈ­¸¦ ³ª´©¼¼¿ä.



Received: by above.proper.com (8.11.6/8.11.3) id g4L4iRJ24695 for ietf-pkix-bks; Mon, 20 May 2002 21:44:27 -0700 (PDT)
Received: from web20008.mail.yahoo.com (web20008.mail.yahoo.com [216.136.225.71]) by above.proper.com (8.11.6/8.11.3) with SMTP id g4L4iPL24691 for <[e-mail]>; Mon, 20 May 2002 21:44:25 -0700 (PDT)
Message-ID: <[e-mail]>
Received: from [202.144.45.2] by web20008.mail.yahoo.com via HTTP; Mon, 20 May 2002 21:44:30 PDT
Date: Mon, 20 May 2002 21:44:30 -0700 (PDT)
From: vivek saraf <[e-mail]>
Subject: SSL Session Management
To: [e-mail]
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Hello,

Can i use SSL session id for managing application
level
session.

I am writting a SSL enabled web server with both
server and client authentication.

I have used SSL session id for managing the session.
but the problem that i am facing is, the IE browser 
is not maintaining that session id. The IE browser
changes the session id if the browser is kept idle for
some time. So by using what method i will be able to
maintain the sessions.

regards,
vivek


__________________________________________________
Do You Yahoo!?
LAUNCH - Your Yahoo! Music Experience
http://launch.yahoo.com


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g4KN6Kp15615 for ietf-pkix-bks; Mon, 20 May 2002 16:06:20 -0700 (PDT)
Received: from osprey.wedgetail.com (starling.wedgetail.com [202.83.95.124]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g4KN6IL15607 for <[e-mail]>; Mon, 20 May 2002 16:06:18 -0700 (PDT)
Received: from wedgetail.com (eider.wedgetail.com [10.10.10.130]) by osprey.wedgetail.com (8.12.2/8.12.2) with ESMTP id g4KN5in3007247; Tue, 21 May 2002 09:05:45 +1000 (EST)
Message-ID: <[e-mail]>
Date: Tue, 21 May 2002 09:05:44 +1000
From: Geoff Elgey <[e-mail]>
User-Agent: Mozilla/5.0 (X11; U; SunOS sun4u; en-US; rv:0.9.9) Gecko/20020311
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Wendsomde Evariste Sosthene Yameogo <[e-mail]>
CC: AmbarishMalpani <[e-mail]>, [e-mail]
Subject: Re: ASN.1 syntax for OCSP nonce value?
References: <[e-mail]>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
X-Scanned-By: MIMEDefang 2.6 (www dot roaringpenguin dot com slash mimedefang)
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

G'day,

Wendsomde Evariste Sosthene Yameogo wrote:

<snip>
> because the extension value is defined as 
> 
> extnValue  OCTET STRING
> 
> extnValue is always encoded as an OCTET STRING. 
> But what about *THE CONTENT OF extnValue(The value of extnValue in the TLV encoding)* ? RFC2459(Section 4.2) states that
> "..the corresponding ASN.1 encoded value is the value of the OCTET STRING extnValue".
> 
> This means that whatever we put in extnValue, it MUST be an *ASN.1 encoded value*. So if we have an extension where the extension value is a Certificate, we will have the encoded Certificate as the value of the OCTET STRING extnValue. As value I mean what remains when you remove the Type and Length bytes from the encoding.

RFC2560 imports the Extensions type from PKIXExplicit88, defined in RC2459.

Section 4.1 of RFC 2459 states that an extension has the following format:

Extension  ::=  SEQUENCE  {
      extnID      OBJECT IDENTIFIER,
      critical    BOOLEAN DEFAULT FALSE,
      extnValue   OCTET STRING  }

However, as you point out, section 4.2 mentions that "When an extension 
appears in a certificate, the OID appears as the field extnID and the 
corresponding ASN.1 encoded structure is the value of the octet string 
extnValue."

This is confirmed by the ASN.1 definition for Extension in Appendix B, 
as follows:

Extension         ::=   SEQUENCE {
    extnId            EXTENSION.&id ({ExtensionSet}),
    critical          BOOLEAN DEFAULT FALSE,
    extnValue         OCTET STRING }
                 -- contains a DER encoding of a value of type
                 -- &ExtnType for the
                 -- extension object identified by extnId --

In ASN.1 2002 syntax, this should probably be defined as follows:

Extension         ::=   SEQUENCE {
    extnId            EXTENSION.&id ({ExtensionSet}),
    critical          BOOLEAN DEFAULT FALSE,
    extnValue         OCTET STRING (
         CONTAINING EXTENSION.&ExtnType({ExtensionSet}{@extnId})
         ENCODED BY {joint-iso-itu-t asn1(1) ber-derived(2) 
distinguished-encoding(1)})
    }

This implies that a "nonce" must have some ASN.1 syntax, the complete 
DER-encoding of which is encapsulated as the value part of an OCTET 
STRING encoding.

 > This implies that in the case of the nonce we must first *Encode the 
Nonce as
 > some ASN.1 structure*. We should NOT just take the nonce bytes and 
put them
 > into the Value field of the OCTET STRING extnValue, because the nonce 
bytes
 > don t represent any ASN.1 structure. So we have to encode the Nonce 
as an OCTET
 > STRING (or BIT STRING if nonces with arbitrary number of bits are 
allowed, not only
 > byte arrays) and then encode the result in extnValue. The OCSP 
specification should
 > actually specify HOW TO encode the nonce bytes(bits), which is NOT 
the case.
 >
 > I think there is something like
 >
 > Nonce ::= OCTET STRING or Nonce ::= BIT STRING or
 > Nonce ::= WHATEVER-WE-WANT-TO-PUT-IN-THERE
 >
 > missing in section 4.4.1 of rfc2560.

It would be nice if the supported extensions in RFC 2560 could be 
defined as object sets:

OCSPExtensionSet EXTENSIONS ::= {
   nonce |
   crlReference |
   acceptableResponseTypes |
   archiveCutoff |
   serviceLocator |
    ... -- for further extensions
}

nonce EXTENSION ::= {
   OCTET STRING IDENTIFIED BY id-pkix-ocsp-nonce
}

crlReference EXTENSION ::= {
   CrlID IDENTIFIED BY id-pkix-ocsp-crl
}

However, this would seem to break interoperability.

> While Testing my OCSP Implementation against others I noticed that all responders/clients I tested(excepted one) are using the wrong encoding(a simple OCTET STRING as extnValue, where the value of the TLV encoding represents the bytes of the nonce).
> So for the sake of interoperabibility I modified my implementation altough I m conscious that this is wrong.

Basically, what we have with existing OCSP extensions is the following 
ASN.1 type:

OCSPExtensions ::= SEQUENCE OF OCSPExtension

OCSPExtension ::= SEQUENCE {
   extnId EXTENSION.&id({OCSPExtensionSet}),
   critical BOOLEAN DEFAULT FALSE,
   extnValue OCTET STRING
     -- If extnId is id-pkix-ocsp-nonce, then nonce value is the
     -- given OCTET STRING.
     --
     -- Otherwise, the value octets of the OCTET STRING contain
     -- the DER-encoding of the ASN.1type associated with the
     -- value in extnId.
     --
     -- This can be formally defined in ASN.1 2002 syntax as:
     --
     -- OCTET STRING (
     --   CONTAINING EXTENSION.&ExtnType({OCSPExtensionSet}{@extnId})
     --  ENCODER BY {joint-iso-itu-t asn1(1) ber-derived(2) 
distinguished-encoding(1)})
     --
     -- See OCSPExtensionSet for the identification of ASN.1 syntaxes 
with OCSP
     -- object identifiers.
}

I would suggest that RFC2560 uses the above definition of an extension 
instead of the RFC2459 definition, or use the RFC 2459 definition and 
note that some implementations handle nonce differently.

Cheers,
Geoff



Received: by above.proper.com (8.11.6/8.11.3) id g4KCqXo23798 for ietf-pkix-bks; Mon, 20 May 2002 05:52:33 -0700 (PDT)
Received: from srv-mail.fst.it (nhmp.fst.it [208.164.5.212]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g4KCqVL23792 for <[e-mail]>; Mon, 20 May 2002 05:52:31 -0700 (PDT)
Received: by srv-mail.fst.it with Internet Mail Service (5.5.2653.19) id <H7WVNNWX>; Mon, 20 May 2002 14:51:16 +0200
Message-ID: <[e-mail]>
From: Massimiliano Farris <[e-mail]>
To: "'[e-mail]'" <[e-mail]>
Subject: association between the time-stamp and the original document
Date: Mon, 20 May 2002 14:51:10 +0200
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain; charset="iso-8859-1"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

  Hi all,
  I'm developing a client application that manages time-stamps.
  The application is responsible for creating the TimeStampReq,
  for sending it to the TSA, for receiving and processing TimeStampResp
  and for browsing and verifying the TimeStampToken.
  
  One of the concerns of people using the Client is:
  << How can I link the time-stamp to the original document? >>.
  The user must setup a mechanism based on some naming convention
  and/or directory location.

  The user can always sign his document, timestamp the signature and
  add the token to the SignedData, as APPENDIX A specs in RFC 3161
  says.
  However, the user may not like to be involved in a digital signature
process
  everytime he wants to timestamp a document.

  Don't you think it would be useful to define something like an Attribute
  through which the user can store his document inside the token itself ?

--
Massimiliano Farris
Fst s.r.l.
System Integration & Software Development
Tel:    [phone]
Fax:    [phone]
e-mail: [e-mail]


Received: by above.proper.com (8.11.6/8.11.3) id g4KBu8320685 for ietf-pkix-bks; Mon, 20 May 2002 04:56:08 -0700 (PDT)
Received: from ietf.org (odin.ietf.org [132.151.1.176]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g4KBu7L20680 for <[e-mail]>; Mon, 20 May 2002 04:56:08 -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 HAA08516; Mon, 20 May 2002 07:55:51 -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-warranty-extn-01.txt
Date: Mon, 20 May 2002 07:55:50 -0400
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

--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		: Warranty Certificate Extension
	Author(s)	: D. Linsenbardt, S. Pontius
	Filename	: draft-ietf-pkix-warranty-extn-01.txt
	Pages		: 7
	Date		: 17-May-02
	
This document describes a certificate extension to explicitly state
the warranty offered by a Certificate Authority (CA) for a the
certificate containing the extension.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-pkix-warranty-extn-01.txt

To remove yourself from the IETF Announcement list, send a message to 
ietf-announce-request with the word unsubscribe in the body of the message.

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-warranty-extn-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-warranty-extn-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-warranty-extn-01.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-pkix-warranty-extn-01.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

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

--OtherAccess--

--NextPart--




Received: by above.proper.com (8.11.6/8.11.3) id g4KBu6C20677 for ietf-pkix-bks; Mon, 20 May 2002 04:56:06 -0700 (PDT)
Received: from ietf.org (odin.ietf.org [132.151.1.176]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g4KBu3L20673 for <[e-mail]>; Mon, 20 May 2002 04:56:05 -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 HAA08495; Mon, 20 May 2002 07:55:46 -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-dnstrings-00.txt
Date: Mon, 20 May 2002 07:55:45 -0400
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

--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		: LDAPv3 DN strings for use with PKIs
	Author(s)	: D. Chadwick
	Filename	: draft-ietf-pkix-dnstrings-00.txt
	Pages		: 
	Date		: 17-May-02
	
RFC 2253 [2] standardises a set of strings that can be used to 
represent attribute types in LDAP distinguished names. This list is 
does not cover the full set of attribute types used in the 
distinguished names of issuers and subjects in public key 
certificates. This document standardises the strings needed for these 
additional attribute types.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-pkix-dnstrings-00.txt

To remove yourself from the IETF Announcement list, send a message to 
ietf-announce-request with the word unsubscribe in the body of the message.

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-dnstrings-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-dnstrings-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-dnstrings-00.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-pkix-dnstrings-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 localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g4KAjPB18514 for ietf-pkix-bks; Mon, 20 May 2002 03:45:25 -0700 (PDT)
Received: from mailgate5.cinetic.de (mailgate5.cinetic.de [217.72.192.165]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g4KAjNL18503 for <[e-mail]>; Mon, 20 May 2002 03:45:23 -0700 (PDT)
Received: from web.de (fmomail02.dlan.cinetic.de [172.20.1.46]) by mailgate5.cinetic.de (8.11.2/8.11.2/SuSE Linux 8.11.0-0.4) with SMTP id g4KAixX29602; Mon, 20 May 2002 12:44:59 +0200
Date: Mon, 20 May 2002 12:44:59 +0200
Message-Id: <[e-mail]>
MIME-Version: 1.0
Organization: http://freemail.web.de/
From: Wendsomde Evariste Sosthene Yameogo <[e-mail]>
To: "AmbarishMalpani" <[e-mail]>, "'Geoff Elgey'" <[e-mail]>, [e-mail]
Subject: Re: RE: ASN.1 syntax for OCSP nonce value?
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Hi Geoff, Hi Ambarish,

>Ambarish Malpani <[e-mail]> schrieb am 20.05.02:
> Hi Geoff,
>     Yes, the syntax for the value of a nonce is an OCTET STRING
> (because the nonce is specified as an extension and the value
> of an extension is always encoded in an OCTET STRING).

What do you exactly mean hier?
because the extension value is defined as 

extnValue  OCTET STRING

extnValue is always encoded as an OCTET STRING. 
But what about *THE CONTENT OF extnValue(The value of extnValue in the TLV encoding)* ? RFC2459(Section 4.2) states that
"..the corresponding ASN.1 encoded value is the value of the OCTET STRING extnValue".

This means that whatever we put in extnValue, it MUST be an *ASN.1 encoded value*. So if we have an extension where the extension value is a Certificate, we will have the encoded Certificate as the value of the OCTET STRING extnValue. As value I mean what remains when you remove the Type and Length bytes from the encoding.

This implies that in the case of the nonce we must first *Encode the Nonce as some ASN.1 structure*. We should NOT just take the nonce bytes and put them into the Value field of the OCTET STRING extnValue, because the nonce bytes don t represent any ASN.1 structure. So we have to encode the Nonce as an OCTET STRING (or BIT STRING if nonces with arbitrary number of bits are allowed, not only byte arrays) and then encode the result in extnValue. The OCSP specification should actually specify HOW TO encode the
nonce bytes(bits), which is NOT the case. I think there is something like

Nonce ::= OCTET STRING or Nonce ::= BIT STRING or 
Nonce ::= WHATEVER-WE-WANT-TO-PUT-IN-THERE

missing in section 4.4.1 of rfc2560.

While Testing my OCSP Implementation against others I noticed that all responders/clients I tested(excepted one) are using the wrong encoding(a simple OCTET STRING as extnValue, where the value of the TLV encoding represents the bytes of the nonce).
So for the sake of interoperabibility I modified my implementation altough I m conscious that this is wrong.


Regards,

Wendsomde

________________________________________________________________
Keine verlorenen Lotto-Quittungen, keine vergessenen Gewinne mehr! 
Beim WEB.DE Lottoservice: http://tippen2.web.de/?x=13




Received: by above.proper.com (8.11.6/8.11.3) id g4K6ejQ15059 for ietf-pkix-bks; Sun, 19 May 2002 23:40:45 -0700 (PDT)
Received: from ext-mail.valicert.com ([66.206.205.11]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g4K6eiL15055 for <[e-mail]>; Sun, 19 May 2002 23:40:44 -0700 (PDT)
Received: from CONVERSION-DAEMON by ext-mail.valicert.com (PMDF V5.2-33 #46613) id <[e-mail]> for [e-mail]; Sun, 19 May 2002 23:35:56 -0700 (PDT)
Received: from polaris.valicert.com ([192.168.2.34]) by ext-mail.valicert.com (PMDF V5.2-33 #46613) with ESMTP id <[e-mail]>; Sun, 19 May 2002 23:35:56 -0700 (PDT)
Received: by polaris.valicert.com with Internet Mail Service (5.5.2653.19) id <K7HLL5R5>; Sun, 19 May 2002 23:40:20 -0700
Content-return: allowed
Date: Sun, 19 May 2002 23:40:16 -0700
From: Ambarish Malpani <[e-mail]>
Subject: RE: ASN.1 syntax for OCSP nonce value?
To: "'Geoff Elgey'" <[e-mail]>, [e-mail]
Message-id: <[e-mail]>
MIME-version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-type: text/plain
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Hi Geoff,
    Yes, the syntax for the value of a nonce is an OCTET STRING
(because the nonce is specified as an extension and the value
of an extension is always encoded in an OCTET STRING).

Regards,
Ambarish

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


> -----Original Message-----
> From: Geoff Elgey [mailto:[e-mail]]
> Sent: Sunday, May 19, 2002 10:29 PM
> To: [e-mail]
> Subject: ASN.1 syntax for OCSP nonce value?
> 
> 
> 
> G'day,
> 
> Section 4.4.1 of RFC 2560 describes a "nonce" extension, but 
> only gives 
> the object identifier for that extension. It mentions that the 
> "extnValue" component of the extension contains the nonce value, but 
> does not describe the syntax of this value.
> 
> I'm assuming that the syntax for a nonce value is an OCTET 
> STRING, correct?
> 
> Cheers,
> Geoff
> 


Received: by above.proper.com (8.11.6/8.11.3) id g4K5U0f05668 for ietf-pkix-bks; Sun, 19 May 2002 22:30:00 -0700 (PDT)
Received: from osprey.wedgetail.com (starling.wedgetail.com [202.83.95.124]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g4K5TwL05662 for <[e-mail]>; Sun, 19 May 2002 22:29:58 -0700 (PDT)
Received: from wedgetail.com (eider.wedgetail.com [10.10.10.130]) by osprey.wedgetail.com (8.12.2/8.12.2) with ESMTP id g4K5T3n3001858 for <[e-mail]>; Mon, 20 May 2002 15:29:04 +1000 (EST)
Message-ID: <[e-mail]>
Date: Mon, 20 May 2002 15:29:03 +1000
From: Geoff Elgey <[e-mail]>
User-Agent: Mozilla/5.0 (X11; U; SunOS sun4u; en-US; rv:0.9.9) Gecko/20020311
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: [e-mail]
Subject: ASN.1 syntax for OCSP nonce value?
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
X-Scanned-By: MIMEDefang 2.6 (www dot roaringpenguin dot com slash mimedefang)
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

G'day,

Section 4.4.1 of RFC 2560 describes a "nonce" extension, but only gives 
the object identifier for that extension. It mentions that the 
"extnValue" component of the extension contains the nonce value, but 
does not describe the syntax of this value.

I'm assuming that the syntax for a nonce value is an OCTET STRING, correct?

Cheers,
Geoff



Received: by above.proper.com (8.11.6/8.11.3) id g4K4YMh03763 for ietf-pkix-bks; Sun, 19 May 2002 21:34:22 -0700 (PDT)
Received: from hermes.cs.auckland.ac.nz (hermes.cs.auckland.ac.nz [130.216.35.151]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g4K4YCL03756 for <[e-mail]>; Sun, 19 May 2002 21:34:20 -0700 (PDT)
Received: from ruru.cs.auckland.ac.nz (ruru-nfs.cs.auckland.ac.nz [130.216.35.12]) by hermes.cs.auckland.ac.nz (8.12.3/8.12.3) with ESMTP id g4K4Xcaq013961; Mon, 20 May 2002 16:33:38 +1200
Received: (from pgut001@localhost) by ruru.cs.auckland.ac.nz (8.9.3/8.8.6/cs-slave) id QAA08637; Mon, 20 May 2002 16:33:36 +1200 (NZST) (sender [e-mail])
Date: Mon, 20 May 2002 16:33:36 +1200 (NZST)
Message-ID: <[e-mail]>
From: [e-mail] (Peter Gutmann)
To: [e-mail], [e-mail]
Subject: RE: Proxy PKI. Was: IBM alternative to PKI?
Cc: [e-mail]
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Trevor Perrin <[e-mail]> writes:

>I'm suggesting this proxy could be used for anything a private key is used
>for: signing, authenticating, decrypting.  The idea is just to let people with
>only authentication mechanisms do PKI "stuff" in a simple fashion, by having a
>server do it for them.

Something similar is being done in the SEE PKI project 
(http://www.e-government.govt.nz/see/pki/index.asp, although some of the newer
documents covering this haven't been posted yet) as a means of letting people
use a PKI without having to go through the pain of actually having to use a
PKI.  This uses (among other approaches) proxies to front-end to a PKI to allow
existing/alternative mechanisms to be used.

Peter.


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g4JJV2a15619 for ietf-pkix-bks; Sun, 19 May 2002 12:31:02 -0700 (PDT)
Received: from bulwinkle.sigaba.com (bulwinkle.sigaba.com [63.202.162.42]) by above.proper.com (8.11.6/8.11.3) with SMTP id g4JJV0L15612 for <[e-mail]>; Sun, 19 May 2002 12:31:00 -0700 (PDT)
Received:   from bsd.sigaba.com (63.202.162.50)  by bulwinkle.sigaba.com (Sigaba Gateway v3.0)  with SMTP; Fri, 17 May 2002 12:45:18 (PDT)
Received:   from exchange1.sigaba.com (exchange1.sigaba.com [10.10.10.10]) by bsd.sigaba.com (8.12.2/8.12.2) with ESMTP id g4HJkwre011959; Fri, 17 May 2002 12:47:04 -0700
Received:   by exchange.sigaba.com with Internet Mail Service (5.5.2653.19) id <LDFD1L8W>; Fri, 17 May 2002 12:46:57 -0700
Message-id:   <[e-mail]>
From: Trevor Perrin <[e-mail]>
To: "'Stephen Kent'" <[e-mail]>, Trevor Perrin <[e-mail]>
Cc: [e-mail]
Subject:   RE: Proxy PKI. Was: IBM alternative to PKI?
Date:   Fri, 17 May 2002 12:46:57 -0700
MIME-Version:   1.0
X-mailer:   Internet Mail Service (5.5.2653.19)
Content-Type:  text/plain; charset="iso-8859-1"
Content-Transfer-Encoding:   7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

I'm suggesting this proxy could be used for anything a private key is used
for: signing, authenticating, decrypting.  The idea is just to let people
with only authentication mechanisms do PKI "stuff" in a simple fashion, by
having a server do it for them.  I agree this wouldn't satisfy current NR
requirements.  Nor would it be easy to add support for this into PKIX, so
this is more a concept I think is interesting, then an immediately practical
suggestion, and probably off-topic.  I discuss this in more detail here
though, if anyone's interested:
http://www.sigaba.com/products/whitepapers/delegatedCrypto.pdf

(Presented here, but they only have the preproceedings version online):
http://www.cs.dartmouth.edu/~pki02/

Trevor

-----Original Message-----
From: Stephen Kent [mailto:[e-mail]]
Sent: Friday, May 17, 2002 12:00 PM
To: Trevor Perrin
Cc: [e-mail]
Subject: RE: Proxy PKI. Was: IBM alternative to PKI?


At 11:45 AM -0700 5/17/02, Trevor Perrin wrote:
>Hi Stephen,
>
>To seek clarification: I was suggesting the use of an "online", but not
>necessarily "inline", intermediary.  Ie, the communication might not flow
>through the intermediary, the client would just perform a request/response
>protocol with him to produce a signed statement, say.  Is "link" or
>"hop-to-hop" the appropriate term for that? 
>
>Regardless, my use of "end-to-end" was confusing and I'll avoid it in
>future.  Thanks,
>
>Trevor

Trevor,

Given the clarification above, this sort of scheme sounds more like a 
proxy authentication service, analogous to the many single signon 
techniques that have been developed, but applied here to signatures 
for NR purposes. Given the requirements imposed on signatures for NR 
purposes in many contexts, e.g., in the EU directive, it's not clear 
that any form of proxy would meet those requirements.

Steve


Received: by above.proper.com (8.11.6/8.11.3) id g4I5U1j29628 for ietf-pkix-bks; Fri, 17 May 2002 22:30:01 -0700 (PDT)
Received: from hermes.cs.auckland.ac.nz (hermes.cs.auckland.ac.nz [130.216.35.151]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g4I5TbL29609 for <[e-mail]>; Fri, 17 May 2002 22:29:48 -0700 (PDT)
Received: from ruru.cs.auckland.ac.nz (ruru-nfs.cs.auckland.ac.nz [130.216.35.12]) by hermes.cs.auckland.ac.nz (8.12.3/8.12.3) with ESMTP id g4I5Taaq016455; Sat, 18 May 2002 17:29:36 +1200
Received: (from pgut001@localhost) by ruru.cs.auckland.ac.nz (8.9.3/8.8.6/cs-slave) id RAA164771; Sat, 18 May 2002 17:29:31 +1200 (NZST) (sender [e-mail])
Date: Sat, 18 May 2002 17:29:31 +1200 (NZST)
Message-ID: <[e-mail]>
From: [e-mail] (Peter Gutmann)
To: [e-mail]
Subject: Re: Certificate for an authorized OCSP responder
Cc: [e-mail]
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

[e-mail] writes:
>In Germany a third option to authorize an OCSP responder is deployed in the
>law-conformant PKI: a CA can authorize a key for an OCSP responder for another
>CA if it issues itself an certificate to that other CAs key.

Just to make sure I'm interpreting this right, what you're saying is:

  CA2 acts as a responder for CA1 ->
    CA1 certifies the responder key for CA2

Is that correct?

Peter.


Received: by above.proper.com (8.11.6/8.11.3) id g4HKSYK14456 for ietf-pkix-bks; Fri, 17 May 2002 13:28:34 -0700 (PDT)
Received: from smtp-1.llnl.gov (smtp-1.llnl.gov [128.115.250.81]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g4HKSXL14452 for <[e-mail]>; Fri, 17 May 2002 13:28:33 -0700 (PDT)
Received: from poptop.llnl.gov (localhost [127.0.0.1]) by smtp-1.llnl.gov (8.9.3/8.9.3/LLNL-gateway-1.0) with ESMTP id NAA27913; Fri, 17 May 2002 13:28:26 -0700 (PDT)
Received: from catalyst2b.llnl.gov (catalyst.llnl.gov [128.115.222.68]) by poptop.llnl.gov (8.8.8/LLNL-3.0.2/pop.llnl.gov-5.1) with ESMTP id NAA13538; Fri, 17 May 2002 13:28:25 -0700 (PDT)
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Version 5.0
Date: Fri, 17 May 2002 13:26:33 -0700
To: Trevor Perrin <[e-mail]>
From: Tony Bartoletti <[e-mail]>
Subject: RE: Proxy PKI. Was: IBM alternative to PKI?
Cc: [e-mail]
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

At 11:54 AM 5/17/2002 -0700, you wrote:

>Yeah,
>
>I shouldn't have used that term.  Still, a CA has power to produce forgery,
>at least by issuing a fake certificate and then signing with that.

Trevor,

You are right about that.  Two unrelated parties cannot establish "instant 
end-to-end" trust, and a CA serves in the role of a "trusted introducer" of 
sorts.

The term "end-to-end" is usually applied to the "ongoing" nature of 
subsequent transactions, where trust in the initial certification is assumed.

An "initial forgery" is a single and isolated point of "foul play".  In 
contrast, a "trusted intermediary" has the opportunity for foul-play in any 
future transaction.

Cheers!

____tony____





Received: by above.proper.com (8.11.6/8.11.3) id g4HJ8vA12418 for ietf-pkix-bks; Fri, 17 May 2002 12:08:57 -0700 (PDT)
Received: from nymelsmtp.internet.ny.fdms.firstdata.com ([204.124.248.17]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g4HJ8tL12413 for <[e-mail]>; Fri, 17 May 2002 12:08:56 -0700 (PDT)
Subject: RE: Proxy PKI. Was: IBM alternative to PKI?
To: Trevor Perrin <[e-mail]>
Cc: Anders Rundgren <[e-mail]>, Dean Adams <[e-mail]>, [e-mail], [e-mail]
X-Mailer: Lotus Notes Release 5.0.5  September 22, 2000
Message-ID: <[e-mail]>
From: [e-mail]
Date: Fri, 17 May 2002 13:06:30 -0600
X-MIMETrack: Serialize by Router on NYMELSMTP/NY/FDMS/FDC(Release 5.0.8 |June 18, 2001) at 05/17/2002 03:05:48 PM
MIME-Version: 1.0
Content-type: text/plain; charset=us-ascii
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

1) there isn't end-to-end integrity ... there is a chain of trust .... that
has to be stiched together to approx. some end-to-end operatio; then we are
back to the original point about the security being only as strong as the
weakest link.

2) you can either be using password/pki security bifurcation as

a) transition solution not a security solution (as in the original post) or

b) the approving agency signs something that the external agencies trust
... (aka as in VPN) and the external agencies need to have absolutely zero
awareness about the internal machinations and internal trust relationships,
and/or

c) creating a total fabrication that individuals are really signing stuff
when they aren't.

The difference between "b" and "c" ... is that the relying parties are
really relying on the signing agency ... in "b" there is a one-to-one
relationship between the signature and the trust relationship ... and in
"c" the trust relationship is significantly obfuscated with lots of
different key pairs that contribute nothing to the intrinsic trust
infrastructure.


[e-mail] on 5/17/2002 12:14 pm wrote:

Hi Lynn,

I agree that using a password<->PKI middleman doesn't provide end-to-end
PKI
trust.  But it could provide end-to-end trust, in the sense that, when the
middleman signs, he explicitly mentions the name being signed for, or when
something is encrypted to the middleman, it explicitly includes the name
the
encrypted data is intended for.

Such a middleman would be a replacement for an identity certificate/key
pair, but it would not "artifically fabricate" signatures by holding
multiple keys, one for each client, but would instead make honest
statements
such as "I authenticated Alice with a password, and am signing this on her
behalf".

The point, I guess, is that you can have end-to-end security (meaning
authenticated or confidential communications with end-users) without
end-to-end PKI, if you trust the PKI endpoints to make authentic statements
from, or deliver confidential statements to, end-users..






Received: by above.proper.com (8.11.6/8.11.3) id g4HJ3Wg12281 for ietf-pkix-bks; Fri, 17 May 2002 12:03:32 -0700 (PDT)
Received: from po1.bbn.com (PO1.BBN.com [192.1.50.38]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g4HJ3UL12277 for <[e-mail]>; Fri, 17 May 2002 12:03:31 -0700 (PDT)
Received: from [128.89.88.34] (comsec.bbn.com [128.89.88.34]) by po1.bbn.com (8.9.1/8.9.1) with ESMTP id PAA03875; Fri, 17 May 2002 15:03:26 -0400 (EDT)
Mime-Version: 1.0
X-Sender: [e-mail]
Message-Id: <p05100317b90b03083175@[128.89.88.34]>
In-Reply-To: <[e-mail]>
References: <[e-mail]>
Date: Fri, 17 May 2002 14:59:30 -0400
To: Trevor Perrin <[e-mail]>
From: Stephen Kent <[e-mail]>
Subject: RE: Proxy PKI. Was: IBM alternative to PKI?
Cc: [e-mail]
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

At 11:45 AM -0700 5/17/02, Trevor Perrin wrote:
>Hi Stephen,
>
>To seek clarification: I was suggesting the use of an "online", but not
>necessarily "inline", intermediary.  Ie, the communication might not flow
>through the intermediary, the client would just perform a request/response
>protocol with him to produce a signed statement, say.  Is "link" or
>"hop-to-hop" the appropriate term for that? 
>
>Regardless, my use of "end-to-end" was confusing and I'll avoid it in
>future.  Thanks,
>
>Trevor

Trevor,

Given the clarification above, this sort of scheme sounds more like a 
proxy authentication service, analogous to the many single signon 
techniques that have been developed, but applied here to signatures 
for NR purposes. Given the requirements imposed on signatures for NR 
purposes in many contexts, e.g., in the EU directive, it's not clear 
that any form of proxy would meet those requirements.

Steve


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g4HIjlR11698 for ietf-pkix-bks; Fri, 17 May 2002 11:45:47 -0700 (PDT)
Received: from bulwinkle.sigaba.com (bulwinkle.sigaba.com [63.202.162.42]) by above.proper.com (8.11.6/8.11.3) with SMTP id g4HIjjL11694 for <[e-mail]>; Fri, 17 May 2002 11:45:45 -0700 (PDT)
Received:  from bsd.sigaba.com (63.202.162.50)  by bulwinkle.sigaba.com (Sigaba Gateway v3.0)  with SMTP; Fri, 17 May 2002 11:43:57 (PDT)
Received:  from exchange1.sigaba.com (exchange1.sigaba.com [10.10.10.10]) by bsd.sigaba.com (8.12.2/8.12.2) with ESMTP id g4HIjhre010208; Fri, 17 May 2002 11:45:43 -0700
Received:  by exchange.sigaba.com with Internet Mail Service (5.5.2653.19) id <LDFD1L5K>; Fri, 17 May 2002 11:45:42 -0700
Message-id:  <[e-mail]>
From: Trevor Perrin <[e-mail]>
To: "'Stephen Kent'" <[e-mail]>, Trevor Perrin <[e-mail]>
Cc: [e-mail]
Subject:  RE: Proxy PKI. Was: IBM alternative to PKI?
Date:  Fri, 17 May 2002 11:45:42 -0700
MIME-Version:  1.0
X-mailer:  Internet Mail Service (5.5.2653.19)
Content-Type:  text/plain; charset="iso-8859-1"
Content-Transfer-Encoding:  7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Hi Stephen,

To seek clarification: I was suggesting the use of an "online", but not
necessarily "inline", intermediary.  Ie, the communication might not flow
through the intermediary, the client would just perform a request/response
protocol with him to produce a signed statement, say.  Is "link" or
"hop-to-hop" the appropriate term for that?  

Regardless, my use of "end-to-end" was confusing and I'll avoid it in
future.  Thanks,

Trevor


-----Original Message-----
From: Stephen Kent [mailto:[e-mail]]
Sent: Friday, May 17, 2002 11:32 AM
To: Trevor Perrin
Cc: [e-mail]
Subject: RE: Proxy PKI. Was: IBM alternative to PKI?


At 11:14 AM -0700 5/17/02, Trevor Perrin wrote:
>Hi Lynn,
>
>I agree that using a password<->PKI middleman doesn't provide end-to-end
PKI
>trust.  But it could provide end-to-end trust, in the sense that, when the
>middleman signs, he explicitly mentions the name being signed for, or when
>something is encrypted to the middleman, it explicitly includes the name
the
>encrypted data is intended for.
>
>Such a middleman would be a replacement for an identity certificate/key
>pair, but it would not "artifically fabricate" signatures by holding
>multiple keys, one for each client, but would instead make honest
statements
>such as "I authenticated Alice with a password, and am signing this on her
>behalf".
>
>The point, I guess, is that you can have end-to-end security (meaning
>authenticated or confidential communications with end-users) without
>end-to-end PKI, if you trust the PKI endpoints to make authentic statements
>from, or deliver confidential statements to, end-users..

Trevor,

This is not how the phrase "end-to-end security" is used in the 
literature, and thus I would suggest one not use the phrase to refer 
to any scheme in which an intermediary in the communication path must 
be trusted to preserve the security services being advertised. Terms 
such as "link security" and "hop-by-hop security" have been used in 
the past to describe analogous schemes.

Steve


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g4HIXNP11212 for ietf-pkix-bks; Fri, 17 May 2002 11:33:23 -0700 (PDT)
Received: from po1.bbn.com (PO1.BBN.com [192.1.50.38]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g4HIXIL11207 for <[e-mail]>; Fri, 17 May 2002 11:33:22 -0700 (PDT)
Received: from [128.89.88.34] (comsec.bbn.com [128.89.88.34]) by po1.bbn.com (8.9.1/8.9.1) with ESMTP id OAA29247; Fri, 17 May 2002 14:33:13 -0400 (EDT)
Mime-Version: 1.0
X-Sender: [e-mail]
Message-Id: <p05100312b90afc93ad0d@[128.89.88.34]>
In-Reply-To: <[e-mail]>
References: <[e-mail]>
Date: Fri, 17 May 2002 14:32:26 -0400
To: Trevor Perrin <[e-mail]>
From: Stephen Kent <[e-mail]>
Subject: RE: Proxy PKI. Was: IBM alternative to PKI?
Cc: [e-mail]
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

At 11:14 AM -0700 5/17/02, Trevor Perrin wrote:
>Hi Lynn,
>
>I agree that using a password<->PKI middleman doesn't provide end-to-end PKI
>trust.  But it could provide end-to-end trust, in the sense that, when the
>middleman signs, he explicitly mentions the name being signed for, or when
>something is encrypted to the middleman, it explicitly includes the name the
>encrypted data is intended for.
>
>Such a middleman would be a replacement for an identity certificate/key
>pair, but it would not "artifically fabricate" signatures by holding
>multiple keys, one for each client, but would instead make honest statements
>such as "I authenticated Alice with a password, and am signing this on her
>behalf".
>
>The point, I guess, is that you can have end-to-end security (meaning
>authenticated or confidential communications with end-users) without
>end-to-end PKI, if you trust the PKI endpoints to make authentic statements
>from, or deliver confidential statements to, end-users..

Trevor,

This is not how the phrase "end-to-end security" is used in the 
literature, and thus I would suggest one not use the phrase to refer 
to any scheme in which an intermediary in the communication path must 
be trusted to preserve the security services being advertised. Terms 
such as "link security" and "hop-by-hop security" have been used in 
the past to describe analogous schemes.

Steve


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g4HIEwG10718 for ietf-pkix-bks; Fri, 17 May 2002 11:14:58 -0700 (PDT)
Received: from bulwinkle.sigaba.com (bulwinkle.sigaba.com [63.202.162.42]) by above.proper.com (8.11.6/8.11.3) with SMTP id g4HIEuL10713 for <[e-mail]>; Fri, 17 May 2002 11:14:56 -0700 (PDT)
Received:  from bsd.sigaba.com (63.202.162.50)  by bulwinkle.sigaba.com (Sigaba Gateway v3.0)  with SMTP; Fri, 17 May 2002 11:13:03 (PDT)
Received:  from exchange1.sigaba.com (exchange1.sigaba.com [10.10.10.10]) by bsd.sigaba.com (8.12.2/8.12.2) with ESMTP id g4HIEnre009383; Fri, 17 May 2002 11:14:49 -0700
Received:  by exchange.sigaba.com with Internet Mail Service (5.5.2653.19) id <LDFD1LY0>; Fri, 17 May 2002 11:14:48 -0700
Message-id:  <[e-mail]>
From: Trevor Perrin <[e-mail]>
To: "'[e-mail]'" <[e-mail]>, Anders Rundgren <[e-mail]>
Cc: Dean Adams <[e-mail]>, [e-mail], [e-mail]
Subject:  RE: Proxy PKI. Was: IBM alternative to PKI?
Date:  Fri, 17 May 2002 11:14:47 -0700
MIME-Version:  1.0
X-mailer:  Internet Mail Service (5.5.2653.19)
Content-Type:  text/plain; charset="iso-8859-1"
Content-Transfer-Encoding:  7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Hi Lynn,

I agree that using a password<->PKI middleman doesn't provide end-to-end PKI
trust.  But it could provide end-to-end trust, in the sense that, when the
middleman signs, he explicitly mentions the name being signed for, or when
something is encrypted to the middleman, it explicitly includes the name the
encrypted data is intended for.

Such a middleman would be a replacement for an identity certificate/key
pair, but it would not "artifically fabricate" signatures by holding
multiple keys, one for each client, but would instead make honest statements
such as "I authenticated Alice with a password, and am signing this on her
behalf".

The point, I guess, is that you can have end-to-end security (meaning
authenticated or confidential communications with end-users) without
end-to-end PKI, if you trust the PKI endpoints to make authentic statements
from, or deliver confidential statements to, end-users..

-----Original Message-----
From: [e-mail] [mailto:[e-mail]]
Sent: Friday, May 17, 2002 4:03 AM
To: Anders Rundgren
Cc: Dean Adams; [e-mail];
[e-mail]
Subject: Re: Proxy PKI. Was: IBM alternative to PKI?




you can do server-based PKI in conjunction with multiple authorization
operations .... i.e. somebody uses a password to talk to a server-based PKI
... and the server turns a password operation into a PKI operation at the
same time doing other organizational functions. However, it would be a
mistake to assume that because two different operations are being performed
by the same server ... that one kind of operation (password to PKI
translation) also inherits the other kind of operation (say multiple
approval level operations).

The counter example is an end-to-end security implementation where the
original client signs the transactions ... and if there are multiple
approvals required because of business reasons ... that the other agents
(human or software) along the way also sign the same transaction ...
providing end-to-end security for both the original transaction as well as
any intermediate approval steps.

If a organization has both a requirement for multiple level approval and
can't deploy real PKI out to the end clients ... that they could implement
both business functions in a single data processing unit.

Various scenarios for end-to-end security and multiple levels of
approval/signing are

1) in the NR thread in this list, I made reference to the EU FINREAD
standard for token acceptor device having secure display and secure
pin-entry ... as part of trying to close some of the NR-service gap with
respect to human intention .... i.e. all operations requiring some
indication of human intention in support of any NR ... required that every
signed transaction need to have been done with a hardware token in
conjunction with a FINREAD terminal configured such that every transaction
signing first required a person to first enter a PIN. Provisions were made
in the x9.59 standard that not only would the originating client sign the
financial transaction ... but the "environment" that the signing took place
in would also sign the operation (i.e. not only could you claim that an EU
FINREAD certified device was used for the signing environment ... but you
could proove that an EU FINREAD certified device was used for the signing
environment .... because the certified device also signed the transaction).

2) various kinds of workflow systems ... may require two or more levels for
final approval for purchase orders. The purchase order business protocol
can have that external business entities don't have to actually
authenticate the lower-level or originating digital signatures .... but
just the final approval agent that is responsible for interfacing to
external organizations. However, it can be useful to carry the originating
and intermediate digital signatures along with the transaction as an
internal audit trail.

Now it would be possible to implement such a function where all the
internal corporate processes were password based and that only purchase
orders (or other types of transactions) that actually left the corporate
boundaries carried a digital signature .... in effect the digital signature
of the final approval agent. I would claim that any use of a unique
signature per originating employee ... rather than the digital signature of
the approval function (human or software) is an artificial fabrication. In
this particular scenario, the trust is between all the external business
processes and the unit performing the signing ... any use of unique
signatures per originating employee rather than a single signature of the
signing authority is an artificial fabrication. The only purpose of such an
artificial fabrication might be because we want to pretend that the trust
relationship is directly between the external units and the individual
employee (because there is a transition plan that employees will be able to
directly sign individual transactions and send them directly to external
agencies w/o any individual approval authority). Otherwise the artificial
fabrication is merely obfuscation ... internal audit procedures will be
able to tie individual password transactions to specific approval
transactions; each PO has unique identifier and audit trail of all steps
including relating to the originating employee and their password
transaction.

===============================================================

Bifurcating the end-to-end trust relationship with some passwords and some
PKI ... implies that there is different levels of trust between the
password-based trust relationship and the PKI-based trust relationship. The
bifurcation is either because 1) we are planning on transitioning to a real
end-to-end PKI relationship .... in which case we create the artificial
appearance of each originator signing with a unique key as an aid to that
transition or 2) there isn't any "real" end-to-end trust relationship ever
required, that the trust infrastructure really is partitioned ....  that
password is sufficient for "internal" operation and only the interface
agent is ever going to be signing, in which case only a single key is
needed by that interface agent. Since there is never going to be any real
end-to-end trust relationship ... the signing agent only needs a single
key. Having the server/signing agent sign with a different unique key per
originator is an artificial fabrication since there is actually no
end-to-end trust (or planned to be).

My original statement is that the server-based PKI is either an a) aid to
transition to individual key signing ... in which case there is a point of
creating the fabrication that there is some end-to-end trust or b) a
permanent solution ... if it is a permanent solution there is no real point
in creating the artificial fabrication of an end-to-end trust relationship
(with different key per originator) ... the trust relationship is between
the signing agent and the external agencies ... for the purposes of trust
... it is only sufficient that the signing agent sign the operation because
it would be a total fabrication that there is an end-to-end PKI trust
relationship between the external entities and the individual. A properly
designed business process designed PKI-trust operation would have the keys
belonging to the operational entities being trusted. Any implication that
the PKI-trust boundaries are different (i.e. server signing agent using
individual associated signing keys) is an artificial fabrication that would
need some valid business justification ... like the planned transition to
real end-to-end PKI-trust boundaries. If there is never going to be any
real end-to-end PKI trust relationship ... and the trust relationship is
only between the signing agent and the external entities then I would claim
that multiple different keys (one per originating employee) is superfluous.

There is also always the danger when creating artificial fabrications that
somebody might incorrectly believe there is a real end-to-end PKI trust
relationship that doesn't really exist. Business executives will typically
sign-off a risk acceptance when creating artificial fabrication when it is
shown that it is a temporary solution pending transition to real
implementation.




[e-mail] on 5/17/2002 3:31 am wrote:


Lynn,

That was a rather prejudiced description of  server-based PKI.

There must be a reason why 42M people use Internet-banks just in
Europe.  These banks serve as giant "proxies" and I don't see how
Internet-banks could ever be replaced by client-side PKI solutions!
Do you?

I.e. the use of a "middle-man" or "proxy" has other qualities than
just enabling PKI-transition/roll-out.

Another example are B2B-systems, where clients must perform
actions *through* the local business system which enforces the
authorization and policy rules.  In addition to storing in- and out-
going business-messages.  A structure that is in daily use since at
least 20 years back or more, so it is definitely time-proven.

And what's more, employees' privacy is protected by this arrangement.

By using server-PKI, companies and banks can abandon expensive
leased-lines and use the Internet.  Probably with an increase in security
compared to today.  Message integrity control is essentially for free
using PKI.

Server-PKI actually supports end-to-end security as well, although
there are two pair of end-points: client-to-proxy, proxy-to-rp.
When/If client-side PKI becomes ubiquitous, it just makes the link
between the proxy and client stronger.  Including NR support in case
the proxy want to sue the client for malpractice.  Or the reverse BTW.

I think the real discussion is really what constitutes an "end-point".
In B2B it does not have to be an individual as an individual is not
a company.   Few PKI-lawyers understand this as companies cannot
"sign" in the paper-world.  But in the "e-world" that's a piece of cake!

In case you want to try a B2B-system implementing server-based PKI,
using XML-Signatures for all B2B-communication, you are invited
to try out https://buyer.x-obi.com/BuyerASP/buyer
Properly written, and protected by firewalls, HW-crypto, and secured
physical facilities, such systems can work wonders.  As Internet-banks
already do, and that on a massive scale.

The only "business" that so far has not fully grasped the usefulness
of using server-PKI is the public sector, but I stay confident that
they soon will, as running a government authority should be rather
similar to running a company.  I.e. there are internal and external
communication, policies etc. that means that you must have a
"proxy" somewhere in your organization to maintain this in a
reasonable way.  The net effect is the external communication
will be performed by the proxy rather than by the employees.

Cheers,
Anders





Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g4HGNWU07083 for ietf-pkix-bks; Fri, 17 May 2002 09:23:32 -0700 (PDT)
Received: from mail0.sibs.pt (mail0.sibs.pt [195.138.0.101]) by above.proper.com (8.11.6/8.11.3) with SMTP id g4HGNTL07079 for <[e-mail]>; Fri, 17 May 2002 09:23:30 -0700 (PDT)
Received: (qmail 27274 invoked from network); 17 May 2002 16:22:00 -0000
Received: from unknown (HELO multicert.com) (195.138.0.90) by mail0.sibs.pt with SMTP; 17 May 2002 16:22:00 -0000
Message-ID: <[e-mail]>
Date: Fri, 17 May 2002 17:23:25 +0100
From: Ricardo Barroso <[e-mail]>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.0rc2) Gecko/20020510
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Trevor Perrin <[e-mail]>
CC: "'[e-mail]'" <[e-mail]>, Anders Rundgren <[e-mail]>, Dean Adams <[e-mail]>, [e-mail], [e-mail]
Subject: Re: IBM alternative to PKI?
References: <[e-mail]>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Trevor Perrin wrote:

 >Hi Lynn (and greetings to PKIX, 1st-time poster here),
 >
 >A counter-argument: while adding a middleman adds a vulnerability, it also
 >adds auditing: the middleman can monitor all password attempts, so as to:
 > - lockout guessers
 >

That's an advantage but that will also probably be a serious source of
DOS attacks!

 > - detect anomalous patterns of use which may indicate a compromised
 >password is being exploited
 > - allow users to review audit trails to detect compromises themselves
 > - allow users to review audit trails to determine the extent of a
 >compromise
 >
 >Without this auditing, it may be much more difficult to detect a 
compromise
 >of a private key, and to determine precisely what has been compromised.
 >
 >So there are security benefits as well as disadvantages to middlemen, I
 >suppose a comparison depends on the exact situation and how you weight the
 >factors..
 >
 >Trevor

Regards,
Ricardo Barroso





Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g4HFLdh03097 for ietf-pkix-bks; Fri, 17 May 2002 08:21:39 -0700 (PDT)
Received: from vulcan.rsasecurity.com (mail.rsasecurity.com [204.167.114.123]) by above.proper.com (8.11.6/8.11.3) with SMTP id g4HFLcL03090 for <[e-mail]>; Fri, 17 May 2002 08:21:38 -0700 (PDT)
Received: from no.name.available by vulcan.rsasecurity.com via smtpd (for mail.imc.org [208.184.76.43]) with SMTP; 17 May 2002 15:19:56 UT
Received: from ebola.securitydynamics.com (ebola.securid.com [192.80.211.4]) by sdtihq24.securid.com (Pro-8.9.3/Pro-8.9.3) with ESMTP id KAA06479 for <[e-mail]>; Fri, 17 May 2002 10:44:50 -0400 (EDT)
Received: from exna00.securitydynamics.com (localhost [127.0.0.1]) by ebola.securitydynamics.com (8.10.2+Sun/8.10.2) with ESMTP id g4HEYtq14511 for <[e-mail]>; Fri, 17 May 2002 10:34:55 -0400 (EDT)
Received: by exna00.securitydynamics.com with Internet Mail Service (5.5.2653.19) id <K2ZLDJN5>; Fri, 17 May 2002 10:36:44 -0400
Received: from HOUSLEY-LAP.rsasecurity.com (HOUSLEY-LAP [10.3.9.23]) by exna00.securitydynamics.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id K2ZLDJNW; Fri, 17 May 2002 10:36:38 -0400
From: "Housley, Russ" <[e-mail]>
To: "Manger, James H" <[e-mail]>
Cc: [e-mail]
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Version 5.1
Date: Fri, 17 May 2002 10:00:02 -0400
Subject: RE: I-D ACTION:draft-ietf-pkix-logotypes-02.txt
In-Reply-To: <[e-mail] l.telstra.com.au>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

James:

Thanks for the suggestion.

I recognize that file format is just one dimension for selecting the most 
appropriate image. The authors have been discussion this too.  I think you 
will see a suggestion in the next draft.

Russ

At 05:48 PM 5/17/2002 +1000, Manger, James H wrote:

>Russ
>
>How about a field that holds the MIME subtype of the "image" type, e.g. the
>"jpeg" part of "image/jpeg".  It is short; it limits types to images; it can
>be matched to the Content-type header when dereferencing the URL; it imposes
>no restrictions on a URL; it is a managed & extensible name space; it is
>independent of O/S.
>
>P.S. Neither MIME type nor file extension offer any help as selectors for
>the features you listed: environment, display resolution, colour
>resolution...  Perhaps a separate field is needed to indicate a few key
>features.
>
> > ----------
> > From: Housley, Russ [SMTP:[e-mail]]
> > Sent: Friday, 17 May 2002 1:17 am
> >
>         ..The logo might be displayed on a desktop machine, a laptop, a
>kiosk, a palm device, or a cell phone.  Each has a different environment,
>display resolution, color resolution, and so on.  Therefore, I think the
>application needs to know what image formats are available.
>
>         ..To me, the question is what provides the application with the best
>selector to pick the URL.
>
>         ..file extension or a longer MIME type ..I advocate the file
>extension.  I have only one reason -- it is shorter.


Received: by above.proper.com (8.11.6/8.11.3) id g4HEamt01481 for ietf-pkix-bks; Fri, 17 May 2002 07:36:48 -0700 (PDT)
Received: from gonzo.aus.rsa.com (mail.rsasecurity.com.au [203.46.112.10]) by above.proper.com (8.11.6/8.11.3) with SMTP id g4HEajL01476 for <[e-mail]>; Fri, 17 May 2002 07:36:45 -0700 (PDT)
Received: from grover by gonzo.aus.rsa.com via smtpd (for mail.imc.org [208.184.76.43]) with SMTP; 17 May 2002 14:37:10 UT
Received: from exaus01.local.aus.rsa.com (exaus01.local.aus.rsa.com [10.177.1.15]) by grover.local.aus.rsa.com (8.10.2/8.10.2) with ESMTP id g4HEfhq07519 for <[e-mail]>; Sat, 18 May 2002 00:41:43 +1000 (EST)
Received: by exaus01.local.aus.rsa.com with Internet Mail Service (5.5.2653.19) id <K11DWZCR>; Sat, 18 May 2002 00:36:20 +1000
Received: from HOUSLEY-LAP.rsasecurity.com (HOUSLEY-LAP [10.3.9.23]) by exna00.securitydynamics.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id K2ZLDJN4; Fri, 17 May 2002 10:36:36 -0400
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Version 5.1
Date: Fri, 17 May 2002 09:53:40 -0400
To: [e-mail]
From: "Housley, Russ" <[e-mail]>
Subject: Re: I-D ACTION:draft-chadwick-pkix-dnstrings-00.txt
In-Reply-To: <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

David:

Thanks for gathering all of this information into one place.

Please include emailAddress in the next version of this document.

Russ


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g4HCJ3t22103 for ietf-pkix-bks; Fri, 17 May 2002 05:19:03 -0700 (PDT)
Received: from nymelsmtp.internet.ny.fdms.firstdata.com ([204.124.248.17]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g4HCJ2L22099 for <[e-mail]>; Fri, 17 May 2002 05:19:02 -0700 (PDT)
Subject: Re: Proxy PKI. Was: IBM alternative to PKI?
To: "Anders Rundgren" <[e-mail]>
Cc: "Dean Adams" <[e-mail]>, [e-mail], [e-mail]
X-Mailer: Lotus Notes Release 5.0.5  September 22, 2000
Message-ID: <[e-mail]>
From: [e-mail]
Date: Fri, 17 May 2002 06:17:00 -0600
X-MIMETrack: Serialize by Router on NYMELSMTP/NY/FDMS/FDC(Release 5.0.8 |June 18, 2001) at 05/17/2002 08:15:53 AM
MIME-Version: 1.0
Content-type: text/plain; charset=us-ascii
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

note that i believe all the original ipsec stuff was end-to-end ....
lightweight ipsec i believe was introduced with VPN at a router working
group at the fall '94 IETF meeting in San Jose (by somebody who had
originally built one for thier personal use).

VPNs have some of the characteristics you claim for proxy PKI ... but they
don't claim to be signing stuff on behalf of other entities  ... they have
a specific trust model and the PKI mirrors the trust model of the units
involved in the trust operations. There is no artificial fabrication that
the VPN unit that does the signing as part of a PKI trust operation is some
totally other entity pretending to fabricate some totally different trust
operation.

VPNs also allow corporations to replace expensive leased lines with
internet connections.

bank-to-bank financial transfers don't happen under the pretend signatures
of the individual account holders. bank settlement has uthentication
between the two bank entities (either implicit, possibly because of leased
line, routing code, etc ... or explicit ... the banks actual authentication
process). As part of a bank-to-bank transfer ... banks will include adenda
records that break out the individual accounting detail.




Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g4HBQLc20882 for ietf-pkix-bks; Fri, 17 May 2002 04:26:21 -0700 (PDT)
Received: from ietf.org (odin.ietf.org [132.151.1.176]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g4HBQJL20878 for <[e-mail]>; Fri, 17 May 2002 04:26:19 -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 HAA08429; Fri, 17 May 2002 07:26:03 -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-roadmap-08.txt
Date: Fri, 17 May 2002 07:26:03 -0400
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

--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:Roadmap
	Author(s)	: A. Arsenault, S. Turner
	Filename	: draft-ietf-pkix-roadmap-08.txt
	Pages		: 55
	Date		: 16-May-02
	
This document provides an overview or 'roadmap' of the work done by
the IETF PKIX working group. It describes some of the terminology
used in the working group's documents, and the theory behind an
This document provides an overview or 'roadmap' of the work done by 
the IETF PKIX working group. It describes some of the terminology 
used in the working group's documents, and the theory behind an 
X.509-based Public Key Infrastructure, Privilege Management 
Infrastructure (PMI), and Time Stamping and Data Certification 
Infrastructures. It identifies each document developed by the PKIX 
working group, and describes the relationships among the various 
documents. It also provides advice to would-be PKIX implementors 
about some of the issues discussed at length during PKIX development, 
in hopes of making it easier to build implementations that will 
actually interoperate.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-pkix-roadmap-08.txt

To remove yourself from the IETF Announcement list, send a message to 
ietf-announce-request with the word unsubscribe in the body of the message.

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-roadmap-08.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-roadmap-08.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-roadmap-08.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-pkix-roadmap-08.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

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

--OtherAccess--

--NextPart--




Received: by above.proper.com (8.11.6/8.11.3) id g4HBPCc20847 for ietf-pkix-bks; Fri, 17 May 2002 04:25:12 -0700 (PDT)
Received: from ietf.org (odin.ietf.org [132.151.1.176]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g4HBPBL20843 for <[e-mail]>; Fri, 17 May 2002 04:25:11 -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 HAA08161; Fri, 17 May 2002 07:24:55 -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-chadwick-pkix-dnstrings-00.txt
Date: Fri, 17 May 2002 07:24:55 -0400
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.


	Title		: LDAPv3 DN strings for use with PKIs
	Author(s)	: D. Chadwick
	Filename	: draft-chadwick-pkix-dnstrings-00.txt
	Pages		: 
	Date		: 16-May-02
	
RFC 2253 [2] standardises a set of strings that can be used to 
represent attribute types in LDAP distinguished names. This list is 
does not cover the full set of attribute types used in the 
distinguished names of issuers and subjects in public key 
certificates. This document standardises the strings needed for these 
additional attribute types.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-chadwick-pkix-dnstrings-00.txt

To remove yourself from the IETF Announcement list, send a message to 
ietf-announce-request with the word unsubscribe in the body of the message.

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-chadwick-pkix-dnstrings-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-chadwick-pkix-dnstrings-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-chadwick-pkix-dnstrings-00.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-chadwick-pkix-dnstrings-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 localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g4HB4sA20356 for ietf-pkix-bks; Fri, 17 May 2002 04:04:54 -0700 (PDT)
Received: from nymelsmtp.internet.ny.fdms.firstdata.com ([204.124.248.17]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g4HB4qL20352 for <[e-mail]>; Fri, 17 May 2002 04:04:52 -0700 (PDT)
Subject: Re: Proxy PKI. Was: IBM alternative to PKI?
To: "Anders Rundgren" <[e-mail]>
Cc: "Dean Adams" <[e-mail]>, [e-mail], [e-mail]
X-Mailer: Lotus Notes Release 5.0.5  September 22, 2000
Message-ID: <[e-mail]>
From: [e-mail]
Date: Fri, 17 May 2002 05:02:53 -0600
X-MIMETrack: Serialize by Router on NYMELSMTP/NY/FDMS/FDC(Release 5.0.8 |June 18, 2001) at 05/17/2002 07:01:43 AM
MIME-Version: 1.0
Content-type: text/plain; charset=us-ascii
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

you can do server-based PKI in conjunction with multiple authorization
operations .... i.e. somebody uses a password to talk to a server-based PKI
... and the server turns a password operation into a PKI operation at the
same time doing other organizational functions. However, it would be a
mistake to assume that because two different operations are being performed
by the same server ... that one kind of operation (password to PKI
translation) also inherits the other kind of operation (say multiple
approval level operations).

The counter example is an end-to-end security implementation where the
original client signs the transactions ... and if there are multiple
approvals required because of business reasons ... that the other agents
(human or software) along the way also sign the same transaction ...
providing end-to-end security for both the original transaction as well as
any intermediate approval steps.

If a organization has both a requirement for multiple level approval and
can't deploy real PKI out to the end clients ... that they could implement
both business functions in a single data processing unit.

Various scenarios for end-to-end security and multiple levels of
approval/signing are

1) in the NR thread in this list, I made reference to the EU FINREAD
standard for token acceptor device having secure display and secure
pin-entry ... as part of trying to close some of the NR-service gap with
respect to human intention .... i.e. all operations requiring some
indication of human intention in support of any NR ... required that every
signed transaction need to have been done with a hardware token in
conjunction with a FINREAD terminal configured such that every transaction
signing first required a person to first enter a PIN. Provisions were made
in the x9.59 standard that not only would the originating client sign the
financial transaction ... but the "environment" that the signing took place
in would also sign the operation (i.e. not only could you claim that an EU
FINREAD certified device was used for the signing environment ... but you
could proove that an EU FINREAD certified device was used for the signing
environment .... because the certified device also signed the transaction).

2) various kinds of workflow systems ... may require two or more levels for
final approval for purchase orders. The purchase order business protocol
can have that external business entities don't have to actually
authenticate the lower-level or originating digital signatures .... but
just the final approval agent that is responsible for interfacing to
external organizations. However, it can be useful to carry the originating
and intermediate digital signatures along with the transaction as an
internal audit trail.

Now it would be possible to implement such a function where all the
internal corporate processes were password based and that only purchase
orders (or other types of transactions) that actually left the corporate
boundaries carried a digital signature .... in effect the digital signature
of the final approval agent. I would claim that any use of a unique
signature per originating employee ... rather than the digital signature of
the approval function (human or software) is an artificial fabrication. In
this particular scenario, the trust is between all the external business
processes and the unit performing the signing ... any use of unique
signatures per originating employee rather than a single signature of the
signing authority is an artificial fabrication. The only purpose of such an
artificial fabrication might be because we want to pretend that the trust
relationship is directly between the external units and the individual
employee (because there is a transition plan that employees will be able to
directly sign individual transactions and send them directly to external
agencies w/o any individual approval authority). Otherwise the artificial
fabrication is merely obfuscation ... internal audit procedures will be
able to tie individual password transactions to specific approval
transactions; each PO has unique identifier and audit trail of all steps
including relating to the originating employee and their password
transaction.

===============================================================

Bifurcating the end-to-end trust relationship with some passwords and some
PKI ... implies that there is different levels of trust between the
password-based trust relationship and the PKI-based trust relationship. The
bifurcation is either because 1) we are planning on transitioning to a real
end-to-end PKI relationship .... in which case we create the artificial
appearance of each originator signing with a unique key as an aid to that
transition or 2) there isn't any "real" end-to-end trust relationship ever
required, that the trust infrastructure really is partitioned ....  that
password is sufficient for "internal" operation and only the interface
agent is ever going to be signing, in which case only a single key is
needed by that interface agent. Since there is never going to be any real
end-to-end trust relationship ... the signing agent only needs a single
key. Having the server/signing agent sign with a different unique key per
originator is an artificial fabrication since there is actually no
end-to-end trust (or planned to be).

My original statement is that the server-based PKI is either an a) aid to
transition to individual key signing ... in which case there is a point of
creating the fabrication that there is some end-to-end trust or b) a
permanent solution ... if it is a permanent solution there is no real point
in creating the artificial fabrication of an end-to-end trust relationship
(with different key per originator) ... the trust relationship is between
the signing agent and the external agencies ... for the purposes of trust
... it is only sufficient that the signing agent sign the operation because
it would be a total fabrication that there is an end-to-end PKI trust
relationship between the external entities and the individual. A properly
designed business process designed PKI-trust operation would have the keys
belonging to the operational entities being trusted. Any implication that
the PKI-trust boundaries are different (i.e. server signing agent using
individual associated signing keys) is an artificial fabrication that would
need some valid business justification ... like the planned transition to
real end-to-end PKI-trust boundaries. If there is never going to be any
real end-to-end PKI trust relationship ... and the trust relationship is
only between the signing agent and the external entities then I would claim
that multiple different keys (one per originating employee) is superfluous.

There is also always the danger when creating artificial fabrications that
somebody might incorrectly believe there is a real end-to-end PKI trust
relationship that doesn't really exist. Business executives will typically
sign-off a risk acceptance when creating artificial fabrication when it is
shown that it is a temporary solution pending transition to real
implementation.




[e-mail] on 5/17/2002 3:31 am wrote:


Lynn,

That was a rather prejudiced description of  server-based PKI.

There must be a reason why 42M people use Internet-banks just in
Europe.  These banks serve as giant "proxies" and I don't see how
Internet-banks could ever be replaced by client-side PKI solutions!
Do you?

I.e. the use of a "middle-man" or "proxy" has other qualities than
just enabling PKI-transition/roll-out.

Another example are B2B-systems, where clients must perform
actions *through* the local business system which enforces the
authorization and policy rules.  In addition to storing in- and out-
going business-messages.  A structure that is in daily use since at
least 20 years back or more, so it is definitely time-proven.

And what's more, employees' privacy is protected by this arrangement.

By using server-PKI, companies and banks can abandon expensive
leased-lines and use the Internet.  Probably with an increase in security
compared to today.  Message integrity control is essentially for free
using PKI.

Server-PKI actually supports end-to-end security as well, although
there are two pair of end-points: client-to-proxy, proxy-to-rp.
When/If client-side PKI becomes ubiquitous, it just makes the link
between the proxy and client stronger.  Including NR support in case
the proxy want to sue the client for malpractice.  Or the reverse BTW.

I think the real discussion is really what constitutes an "end-point".
In B2B it does not have to be an individual as an individual is not
a company.   Few PKI-lawyers understand this as companies cannot
"sign" in the paper-world.  But in the "e-world" that's a piece of cake!

In case you want to try a B2B-system implementing server-based PKI,
using XML-Signatures for all B2B-communication, you are invited
to try out https://buyer.x-obi.com/BuyerASP/buyer
Properly written, and protected by firewalls, HW-crypto, and secured
physical facilities, such systems can work wonders.  As Internet-banks
already do, and that on a massive scale.

The only "business" that so far has not fully grasped the usefulness
of using server-PKI is the public sector, but I stay confident that
they soon will, as running a government authority should be rather
similar to running a company.  I.e. there are internal and external
communication, policies etc. that means that you must have a
"proxy" somewhere in your organization to maintain this in a
reasonable way.  The net effect is the external communication
will be performed by the proxy rather than by the employees.

Cheers,
Anders






Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g4H8Pga01479 for ietf-pkix-bks; Fri, 17 May 2002 01:25:42 -0700 (PDT)
Received: from blooper.utfors.se (mail.utfors.se [195.58.103.125]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g4H8PeL01466 for <[e-mail]>; Fri, 17 May 2002 01:25:41 -0700 (PDT)
Received: from arport ([62.119.75.13]) by blooper.utfors.se (Utfors AB) with SMTP id g4H8PNJJ028804; Fri, 17 May 2002 10:25:23 +0200 (MEST)
Message-ID: <006001c1fd84$5579a370$0500a8c0@arport>
From: "Anders Rundgren" <[e-mail]>
To: <[e-mail]>
Cc: "Dean Adams" <[e-mail]>, <[e-mail]>, <[e-mail]>
References: <[e-mail]>
Subject: Proxy PKI. Was: IBM alternative to PKI?
Date: Fri, 17 May 2002 11:21:34 +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 5.50.4133.2400
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Lynn,

That was a rather prejudiced description of  server-based PKI.

There must be a reason why 42M people use Internet-banks just in
Europe.  These banks serve as giant "proxies" and I don't see how
Internet-banks could ever be replaced by client-side PKI solutions!
Do you?

I.e. the use of a "middle-man" or "proxy" has other qualities than
just enabling PKI-transition/roll-out.

Another example are B2B-systems, where clients must perform
actions *through* the local business system which enforces the
authorization and policy rules.  In addition to storing in- and out-
going business-messages.  A structure that is in daily use since at
least 20 years back or more, so it is definitely time-proven. 

And what's more, employees' privacy is protected by this arrangement.

By using server-PKI, companies and banks can abandon expensive
leased-lines and use the Internet.  Probably with an increase in security
compared to today.  Message integrity control is essentially for free
using PKI.

Server-PKI actually supports end-to-end security as well, although
there are two pair of end-points: client-to-proxy, proxy-to-rp.
When/If client-side PKI becomes ubiquitous, it just makes the link
between the proxy and client stronger.  Including NR support in case
the proxy want to sue the client for malpractice.  Or the reverse BTW.

I think the real discussion is really what constitutes an "end-point".
In B2B it does not have to be an individual as an individual is not
a company.   Few PKI-lawyers understand this as companies cannot
"sign" in the paper-world.  But in the "e-world" that's a piece of cake!

In case you want to try a B2B-system implementing server-based PKI,
using XML-Signatures for all B2B-communication, you are invited
to try out https://buyer.x-obi.com/BuyerASP/buyer
Properly written, and protected by firewalls, HW-crypto, and secured
physical facilities, such systems can work wonders.  As Internet-banks
already do, and that on a massive scale.

The only "business" that so far has not fully grasped the usefulness
of using server-PKI is the public sector, but I stay confident that
they soon will, as running a government authority should be rather
similar to running a company.  I.e. there are internal and external
communication, policies etc. that means that you must have a
"proxy" somewhere in your organization to maintain this in a
reasonable way.  The net effect is the external communication
will be performed by the proxy rather than by the employees.

Cheers,
Anders

----- Original Message ----- 
From: <[e-mail]>
To: "Anders Rundgren" <[e-mail]>
Cc: "Dean Adams" <[e-mail]>; <[e-mail]>; <[e-mail]>
Sent: Thursday, May 16, 2002 18:59
Subject: Re: IBM alternative to PKI?


i.e. middle-man tends to represent transition/roll-out solutions .... not
security infrastructure solutions.

from traditional security

* end-to-end

middle-man approaches tend to always negate any end-to-end attribute

* additional steps represent additional vulnerabilities

middle-man approaches increase the number of steps/processes .... each of
which represent an additional vulnerability, each additional vulnerability
represents additional points of failure/fraud

* only as strong as the weakest link

shared-secret password paradigm in series with digital signature isn't
additive.

* 2-factor authentication

secret password (as opposed to shared-secret password) in conjunction with
hardware token (i.e. processing in parallel instead of in series)
represents a combination link (both hardware token and secret password has
to be compromised). a shared-secret password process in series with a
digital signature process can fail with just the shared-secret password.












Received: by above.proper.com (8.11.6/8.11.3) id g4H7mgl27086 for ietf-pkix-bks; Fri, 17 May 2002 00:48:42 -0700 (PDT)
Received: from mailo.vtcif.telstra.com.au (mailo.vtcif.telstra.com.au [202.12.144.17]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g4H7meL27082 for <[e-mail]>; Fri, 17 May 2002 00:48:41 -0700 (PDT)
Received: (from uucp@localhost) by mailo.vtcif.telstra.com.au (8.8.2/8.6.9) id RAA17416 for <[e-mail]>; Fri, 17 May 2002 17:48:34 +1000 (EST)
Received: from maili.vtcif.telstra.com.au(202.12.142.17) via SMTP by mailo.vtcif.telstra.com.au, id smtpd0xhO6p; Fri May 17 17:48:20 2002
Received: (from uucp@localhost) by maili.vtcif.telstra.com.au (8.8.2/8.6.9) id RAA19899 for <[e-mail]>; Fri, 17 May 2002 17:48:19 +1000 (EST)
Received: from localhost(127.0.0.1), claiming to be "mail.cdn.telstra.com.au" via SMTP by localhost, id smtpdDoKMO_; Fri May 17 17:48:03 2002
Received: from ntmsg0028.corpmail.telstra.com.au (ntmsg0028.corpmail.telstra.com.au [192.168.174.24]) by mail.cdn.telstra.com.au (8.8.2/8.6.9) with ESMTP id RAA13578 for <[e-mail]>; Fri, 17 May 2002 17:48:03 +1000 (EST)
Received: by ntmsg0028.corpmail.telstra.com.au with Internet Mail Service (5.5.2655.55) id <LC199LJS>; Fri, 17 May 2002 17:48:03 +1000
Message-ID: <[e-mail]>
From: "Manger, James H" <[e-mail]>
To: [e-mail]
Subject: RE: I-D ACTION:draft-ietf-pkix-logotypes-02.txt
Date: Fri, 17 May 2002 17:48:03 +1000
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2655.55)
Content-Type: text/plain
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Russ

How about a field that holds the MIME subtype of the "image" type, e.g. the
"jpeg" part of "image/jpeg".  It is short; it limits types to images; it can
be matched to the Content-type header when dereferencing the URL; it imposes
no restrictions on a URL; it is a managed & extensible name space; it is
independent of O/S.

P.S. Neither MIME type nor file extension offer any help as selectors for
the features you listed: environment, display resolution, colour
resolution...  Perhaps a separate field is needed to indicate a few key
features.

> ----------
> From:	Housley, Russ [SMTP:[e-mail]]
> Sent:	Friday, 17 May 2002 1:17 am
> 
	..The logo might be displayed on a desktop machine, a laptop, a
kiosk, a palm device, or a cell phone.  Each has a different environment,
display resolution, color resolution, and so on.  Therefore, I think the
application needs to know what image formats are available.

	..To me, the question is what provides the application with the best
selector to pick the URL.

	..file extension or a longer MIME type ..I advocate the file
extension.  I have only one reason -- it is shorter.



Received: by above.proper.com (8.11.6/8.11.3) id g4H74bj20984 for ietf-pkix-bks; Fri, 17 May 2002 00:04:37 -0700 (PDT)
Received: from fw1.gdm.de (fw1.gdm.de [193.108.184.254]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g4H74ZL20968; Fri, 17 May 2002 00:04:36 -0700 (PDT)
Received: by fw1.gdm.de (8.11.6/8.11.6) id g4H74Q913361; Fri, 17 May 2002 09:04:26 +0200 (CEST)
Received: (from localhost) by fw1.gdm.de (MSCAN) id 3/fw1.gdm.de/smtp-gw/mscan; Fri May 17 09:04:26 2002
To: [e-mail]
Cc: [e-mail], [e-mail]
Subject: Re: Certificate for an authorized OCSP responder
MIME-Version: 1.0
X-Mailer: Lotus Notes Release 5.07a  May 14, 2001
Message-ID: <[e-mail]>
From: [e-mail]
Date: Fri, 17 May 2002 09:05:06 +0200
X-MIMETrack: MIME-CD by tm_grab on NOTESGDM1/SRV/GuD(Release 5.0.8 |June 18, 2001) at 05/17/2002 09:05:18 AM, MIME-CD complete at 05/17/2002 09:05:18 AM, Serialize by Router on NOTESDMZ1/SRV/GuD(Release 5.0.8 |June 18, 2001) at 05/17/2002 09:07:21 AM
Content-type: text/plain; charset=us-ascii
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

In Germany a third option to authorize an OCSP responder is deployed in the
law-conformant PKI: a CA can authorize a key for an OCSP responder for
another CA if it issues itself an certificate to that other CAs key. This
option is used for all CAs except root which authorize its own responder
key. Thus an OCSP service of a law-compliant CA (except root) can continue
to issue reliable responses even after key compromise and revocation of its
associated CA.

This is not the same as the "local configuration", as the CA can name its
authorized OCSP responder in its own certificate.




Received: by above.proper.com (8.11.6/8.11.3) id g4H5Ahb08164 for ietf-pkix-bks; Thu, 16 May 2002 22:10:43 -0700 (PDT)
Received: from osprey.wedgetail.com (starling.wedgetail.com [202.83.95.124]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g4H5AeL08158 for <[e-mail]>; Thu, 16 May 2002 22:10:40 -0700 (PDT)
Received: from wedgetail.com (coot.wedgetail.com [10.10.10.4]) by osprey.wedgetail.com (8.12.2/8.12.2) with ESMTP id g4H5ANn3017331; Fri, 17 May 2002 15:10:24 +1000 (EST)
Message-Id: <[e-mail]>
X-Mailer: exmh exmh 2.5 (2001-07-13) with nmh-1.0.4
From: Dean Povey <[e-mail]>
To: "Housley, Russ" <[e-mail]>
Cc: [e-mail]
Subject: Re: I-D ACTION:draft-ietf-pkix-logotypes-02.txt 
In-reply-to: Your message of "Thu, 16 May 2002 11:17:03 -0400." <[e-mail]> 
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Fri, 17 May 2002 15:10:23 +1000
X-Scanned-By: MIMEDefang 2.6 (www dot roaringpenguin dot com slash mimedefang)
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

>Is a file extension or a longer MIME type a better convention?  I think 
>that they provide the same information as a selector.  I advocate the file 
>extension.  I have only one reason -- it is shorter.

Um, compared to putting embedded images in a cert this is irrelevant. The
MIME type is a (more or less) managed namespace without ambiguity.  I think
the benefits of choosing the MIME type rather than the file extension to
indicate the image format are clear.

-- 
Dean Povey,              |em: [e-mail] |  JCSI: Java security toolkit
Senior S/W Developer     |ph:  [phone]    | uPKI: Embedded/C PKI toolkit
Wedgetail Communications |fax: [phone]    | uSSL: Embedded/C SSL toolkit
Brisbane, Australia      |www: www.wedgetail.com  | XML Security: XML Signatures 




Received: by above.proper.com (8.11.6/8.11.3) id g4GLgF126848 for ietf-pkix-bks; Thu, 16 May 2002 14:42:15 -0700 (PDT)
Received: from bulwinkle.sigaba.com (bulwinkle.sigaba.com [63.202.162.42]) by above.proper.com (8.11.6/8.11.3) with SMTP id g4GLgDL26844 for <[e-mail]>; Thu, 16 May 2002 14:42:13 -0700 (PDT)
Received:  from bsd.sigaba.com (63.202.162.50)  by bulwinkle.sigaba.com (Sigaba Gateway v3.0)  with SMTP; Thu, 16 May 2002 14:40:27 (PDT)
Received:  from exchange1.sigaba.com (exchange1.sigaba.com [10.10.10.10]) by bsd.sigaba.com (8.12.2/8.12.2) with ESMTP id g4GLgBre009572; Thu, 16 May 2002 14:42:11 -0700
Received:  by exchange.sigaba.com with Internet Mail Service (5.5.2653.19) id <LBDF5YVR>; Thu, 16 May 2002 14:42:10 -0700
Message-id:  <[e-mail]>
From: Trevor Perrin <[e-mail]>
To: "'[e-mail]'" <[e-mail]>, Trevor Perrin <[e-mail]>
Cc: Anders Rundgren <[e-mail]>, Dean Adams <[e-mail]>, [e-mail], [e-mail]
Subject:  RE: IBM alternative to PKI?
Date:  Thu, 16 May 2002 14:42:09 -0700
MIME-Version:  1.0
X-mailer:  Internet Mail Service (5.5.2653.19)
Content-Type:  text/plain; charset="iso-8859-1"
Content-Transfer-Encoding:  7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Yeah, that wouldn't be good.  If a middleman is going to "speak for" you
then it is definitely inside your security perimeter, and shouldn't be in
the hands of an adversary.  I'm imagining middlemen that are owned by an
organization so that its members, who only have passwords or authentication
devices, can perform private-key functions like signing or decrypting, for a
sort of PKI-on-the-cheap solution.  In the case where users have their own
private keys, and the other PKI issues are dealt with, I agree that
end-to-end security is preferrable.

Trevor

-----Original Message-----
From: [e-mail] [mailto:[e-mail]]
Sent: Thursday, May 16, 2002 2:15 PM
To: Trevor Perrin
Cc: Anders Rundgren; Dean Adams; [e-mail];
[e-mail]
Subject: RE: IBM alternative to PKI?


so lets do the counter argument in the business process sense ... a
middle-man that is a different company than the end-points (as opposed to
possibly middle-man implementation which is actually a business entity's
compartmentalized operation ... which has various security/vulnerability
trade-offs).

so in the business middle-man scenario ... the middle-man is your strongest
competitor/advisary. they process incoming transactions and then generate
something from scratch that is forwarded to you. you have no way of
prooving that the incoming transactions are fraudulent or not. furthermore
the business middle-man has no financial penalty/liability with regard to
fraudulent transactions.



Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g4GLPvA26276 for ietf-pkix-bks; Thu, 16 May 2002 14:25:57 -0700 (PDT)
Received: from bulwinkle.sigaba.com (bulwinkle.sigaba.com [63.202.162.42]) by above.proper.com (8.11.6/8.11.3) with SMTP id g4GLPtL26271 for <[e-mail]>; Thu, 16 May 2002 14:25:55 -0700 (PDT)
Received:  from bsd.sigaba.com (63.202.162.50)  by bulwinkle.sigaba.com (Sigaba Gateway v3.0)  with SMTP; Thu, 16 May 2002 14:24:08 (PDT)
Received:  from exchange1.sigaba.com (exchange1.sigaba.com [10.10.10.10]) by bsd.sigaba.com (8.12.2/8.12.2) with ESMTP id g4GLPpre009042; Thu, 16 May 2002 14:25:51 -0700
Received:  by exchange.sigaba.com with Internet Mail Service (5.5.2653.19) id <LBDF5Y4Y>; Thu, 16 May 2002 14:25:50 -0700
Message-id:  <[e-mail]>
From: Trevor Perrin <[e-mail]>
To: "'[e-mail]'" <[e-mail]>, Trevor Perrin <[e-mail]>
Cc: Anders Rundgren <[e-mail]>, Dean Adams <[e-mail]>, [e-mail], [e-mail]
Subject:  RE: IBM alternative to PKI?
Date:  Thu, 16 May 2002 14:25:50 -0700
MIME-Version:  1.0
X-mailer:  Internet Mail Service (5.5.2653.19)
Content-Type:  text/plain; charset="iso-8859-1"
Content-Transfer-Encoding:  7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Good point: auditing can be provided without needing middlemen who rewrite
the client's transactions, and these should be avoided when possible for
end-to-end integrity.

When these middlemen can't be avoided, though, (i.e. the client only has a
password, so needs a middleman to speak for him), then these middlemen seem
a good point for auditing.  Particularly in cases where these middlemen are
the only online server involved in everything the client does.

For example, the clients might not only use middlemen to sign transactions
which their bank could audit, but sign documents, authenticate themselves to
different services, etc..  All of these could potentially be mediated
through a middleman who authenticates clients with a password and then signs
things on their behalf, and since this middleman is helping the client talk
to a variety of other people, no-one but the middleman appears able to audit
the full spectrum of the client's activity..

But that may be getting a little out of scope..  

Thanks,
Trevor

-----Original Message-----
From: [e-mail] [mailto:[e-mail]]
Sent: Thursday, May 16, 2002 1:17 PM
To: Trevor Perrin
Cc: Anders Rundgren; Dean Adams; [e-mail];
[e-mail]
Subject: RE: IBM alternative to PKI?



but purely monitor/audit isn't usually a transition scenario also.

if you are looking at the financial "middle-man" given in the example by
anders ... the financial end-point already contains extensive audit and
dynamic risk management (i think there was an article in NYTimes this week
or last week about the neural net stuff that looks for complex fraud
patterns). Given end-to-end integrity and no intermediate stand-in .... I
would contend that the end-point risk management can do a much better job
of deciding whether or not to approve a transaction ... based on more
comprehensive understanding of the situation ... that wouldn't be available
to middleman processing.

the issue is if you have a no-security infrastructure ... then adding a
monitor for auditing purposes can be a risk management benefit. we defined
a bunch of that stuff back in the '80s for something we were calling
"middle-layer" ... sort of the precursor to 3-layer architecture.

Note however, this doesn't have to be a middle-man in the transaction
processing sense ... in the current internet ... a packet can flow thru a
large number of nodes ... all of which can be doing monitoring and auditing
(do a traceroute sometime) ... but wouldn't be considered a transaction
processing middle-man ... in the sense that it takes in a transation ...
processes the semantics of that transaction and then generates a different
transaction.

The scenario example is that a client does a password transaction with a
middle-man ... the middle-man processes the password transaction and then
generates a totally different digitally signed transaction ... possibly
even emulating that the transaction originated directly from the client.

A purely intermediate monitor/audit environment with no "middle-man"
processing and end-to-end security would have the client directly
generating the digitally signed transaction and sending it all the way thru
to the processing end-point.  It isn't the monitoring/audit that descreases
security, it is any middle-man processing interferring with end-to-end
integrity.

Another scenario was "SET". SET had relying-party-only certificates with
digitally signed transaction. A "SET" gateway .... accepted incoming SET
financial transactions, verified the certificate, verified the signature,
stripped everything out ... and generated a standard ISO 8583 transactions
.... with an additional flag indicating whether or not the "SET" gateway
believe the certificate and signature to be correct. Then a consumer's
financial institution was dependent on the "flag" in deciding whether or
not it was a valid transaction (aka there wasn't any end-to-end integrity).
Furthmore, I don't know if any of the "SET" gateways that had any financial
liability associated with fraudulent transaction (i.e. what happens if they
were to lie). At one point one of the associations gave a talk at an ISO
meeting giving the number of 8583 transactions that had the "SET" valid
signature flag set .... and they could proove that there was no
cryptographic capability involved at all (i.e. it wasn't even a SET gateway
that might not be telling the truth ... but there were financial reasons
why others might want the flag set also).

now, I would claim that an end-point business operation might
compartmentilize some of its functions ... so that any compromize in any
single component doesn't compromise all components. i would contend that a
compartmentilzed end-point security solution is different than several
different business operations all implementing various kinds of
intermediate processing (middle-man) preventing any kind of end-to-end
integrity.

random old middleware/middle layer refs:
http://www.garlic.com/~lynn/96.html#16 middle layer
http://www.garlic.com/~lynn/96.html#17 middle layer
http://www.garlic.com/~lynn/98.html#50 Edsger Dijkstra: the blackest week
of his professional life
http://www.garlic.com/~lynn/99.html#123 Speaking of USB ( was Re: ASR 33
Typing Element)
http://www.garlic.com/~lynn/99.html#124 Speaking of USB ( was Re: ASR 33
Typing Element)
http://www.garlic.com/~lynn/99.html#201 Middleware - where did that come
from?
http://www.garlic.com/~lynn/99.html#202 Middleware - where did that come
from?
http://www.garlic.com/~lynn/2000b.html#59 7 layers to a program
http://www.garlic.com/~lynn/2000e.html#45 IBM's Workplace OS (Was: .. Pink)
http://www.garlic.com/~lynn/2001d.html#69 Block oriented I/O over IP
http://www.garlic.com/~lynn/2001j.html#4 I hate Compaq
http://www.garlic.com/~lynn/2001j.html#20 OT - Internet Explorer V6.0
http://www.garlic.com/~lynn/2001k.html#18 HP-UX will not be ported to Alpha
(no surprise)exit
http://www.garlic.com/~lynn/2001m.html#15 departmental servers
http://www.garlic.com/~lynn/2001n.html#23 Alpha vs. Itanic:  facts vs. FUD
http://www.garlic.com/~lynn/2001n.html#34 Hercules etc. IBM not just
missing a great opportunity...
http://www.garlic.com/~lynn/2001n.html#55 9-track tapes (by the armful)
http://www.garlic.com/~lynn/2002.html#2 The demise of compaq
http://www.garlic.com/~lynn/2002.html#7 The demise of compaq
http://www.garlic.com/~lynn/2002.html#11 The demise of compaq
http://www.garlic.com/~lynn/2002b.html#4 Microcode? (& index searching)
http://www.garlic.com/~lynn/2002b.html#37 Poor Man's clustering idea
http://www.garlic.com/~lynn/2002d.html#4 IBM Mainframe at home
http://www.garlic.com/~lynn/2002d.html#14 Mainframers: Take back the light
(spotlight, that is)
http://www.garlic.com/~lynn/2002e.html#2 IBM's "old" boss speaks (was
"new")



[e-mail] on 5/16/2002 1:33 pm wrote:


Hi Lynn (and greetings to PKIX, 1st-time poster here),

A counter-argument: while adding a middleman adds a vulnerability, it also
adds auditing: the middleman can monitor all password attempts, so as to:
 - lockout guessers
 - detect anomalous patterns of use which may indicate a compromised
password is being exploited
 - allow users to review audit trails to detect compromises themselves
 - allow users to review audit trails to determine the extent of a
compromise

Without this auditing, it may be much more difficult to detect a compromise
of a private key, and to determine precisely what has been compromised.

So there are security benefits as well as disadvantages to middlemen, I
suppose a comparison depends on the exact situation and how you weight the
factors..

Trevor


-----Original Message-----
From: [e-mail] [mailto:[e-mail]]
Sent: Thursday, May 16, 2002 10:00 AM
To: Anders Rundgren
Cc: Dean Adams; [e-mail];
[e-mail]
Subject: Re: IBM alternative to PKI?



i.e. middle-man tends to represent transition/roll-out solutions .... not
security infrastructure solutions.

from traditional security

* end-to-end

middle-man approaches tend to always negate any end-to-end attribute

* additional steps represent additional vulnerabilities

middle-man approaches increase the number of steps/processes .... each of
which represent an additional vulnerability, each additional vulnerability
represents additional points of failure/fraud

* only as strong as the weakest link

shared-secret password paradigm in series with digital signature isn't
additive.

* 2-factor authentication

secret password (as opposed to shared-secret password) in conjunction with
hardware token (i.e. processing in parallel instead of in series)
represents a combination link (both hardware token and secret password has
to be compromised). a shared-secret password process in series with a
digital signature process can fail with just the shared-secret password.








Received: by above.proper.com (8.11.6/8.11.3) id g4GLP5426252 for ietf-pkix-bks; Thu, 16 May 2002 14:25:05 -0700 (PDT)
Received: from nymelsmtp.internet.ny.fdms.firstdata.com ([204.124.248.17]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g4GLP3L26248 for <[e-mail]>; Thu, 16 May 2002 14:25:03 -0700 (PDT)
Subject: RE: IBM alternative to PKI?
To: Trevor Perrin <[e-mail]>
Cc: Anders Rundgren <[e-mail]>, Dean Adams <[e-mail]>, [e-mail], [e-mail]
X-Mailer: Lotus Notes Release 5.0.5  September 22, 2000
Message-ID: <[e-mail]>
From: [e-mail]
Date: Thu, 16 May 2002 15:15:21 -0600
X-MIMETrack: Serialize by Router on NYMELSMTP/NY/FDMS/FDC(Release 5.0.8 |June 18, 2001) at 05/16/2002 05:21:57 PM
MIME-Version: 1.0
Content-type: text/plain; charset=us-ascii
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

so lets do the counter argument in the business process sense ... a
middle-man that is a different company than the end-points (as opposed to
possibly middle-man implementation which is actually a business entity's
compartmentalized operation ... which has various security/vulnerability
trade-offs).

so in the business middle-man scenario ... the middle-man is your strongest
competitor/advisary. they process incoming transactions and then generate
something from scratch that is forwarded to you. you have no way of
prooving that the incoming transactions are fraudulent or not. furthermore
the business middle-man has no financial penalty/liability with regard to
fraudulent transactions.




Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g4GKJGw24262 for ietf-pkix-bks; Thu, 16 May 2002 13:19:16 -0700 (PDT)
Received: from nymelsmtp.internet.ny.fdms.firstdata.com ([204.124.248.17]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g4GKJEL24257 for <[e-mail]>; Thu, 16 May 2002 13:19:15 -0700 (PDT)
Subject: RE: IBM alternative to PKI?
To: Trevor Perrin <[e-mail]>
Cc: Anders Rundgren <[e-mail]>, Dean Adams <[e-mail]>, [e-mail], [e-mail]
X-Mailer: Lotus Notes Release 5.0.5  September 22, 2000
Message-ID: <[e-mail]>
From: [e-mail]
Date: Thu, 16 May 2002 14:17:09 -0600
X-MIMETrack: Serialize by Router on NYMELSMTP/NY/FDMS/FDC(Release 5.0.8 |June 18, 2001) at 05/16/2002 04:16:08 PM
MIME-Version: 1.0
Content-type: text/plain; charset=us-ascii
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

but purely monitor/audit isn't usually a transition scenario also.

if you are looking at the financial "middle-man" given in the example by
anders ... the financial end-point already contains extensive audit and
dynamic risk management (i think there was an article in NYTimes this week
or last week about the neural net stuff that looks for complex fraud
patterns). Given end-to-end integrity and no intermediate stand-in .... I
would contend that the end-point risk management can do a much better job
of deciding whether or not to approve a transaction ... based on more
comprehensive understanding of the situation ... that wouldn't be available
to middleman processing.

the issue is if you have a no-security infrastructure ... then adding a
monitor for auditing purposes can be a risk management benefit. we defined
a bunch of that stuff back in the '80s for something we were calling
"middle-layer" ... sort of the precursor to 3-layer architecture.

Note however, this doesn't have to be a middle-man in the transaction
processing sense ... in the current internet ... a packet can flow thru a
large number of nodes ... all of which can be doing monitoring and auditing
(do a traceroute sometime) ... but wouldn't be considered a transaction
processing middle-man ... in the sense that it takes in a transation ...
processes the semantics of that transaction and then generates a different
transaction.

The scenario example is that a client does a password transaction with a
middle-man ... the middle-man processes the password transaction and then
generates a totally different digitally signed transaction ... possibly
even emulating that the transaction originated directly from the client.

A purely intermediate monitor/audit environment with no "middle-man"
processing and end-to-end security would have the client directly
generating the digitally signed transaction and sending it all the way thru
to the processing end-point.  It isn't the monitoring/audit that descreases
security, it is any middle-man processing interferring with end-to-end
integrity.

Another scenario was "SET". SET had relying-party-only certificates with
digitally signed transaction. A "SET" gateway .... accepted incoming SET
financial transactions, verified the certificate, verified the signature,
stripped everything out ... and generated a standard ISO 8583 transactions
.... with an additional flag indicating whether or not the "SET" gateway
believe the certificate and signature to be correct. Then a consumer's
financial institution was dependent on the "flag" in deciding whether or
not it was a valid transaction (aka there wasn't any end-to-end integrity).
Furthmore, I don't know if any of the "SET" gateways that had any financial
liability associated with fraudulent transaction (i.e. what happens if they
were to lie). At one point one of the associations gave a talk at an ISO
meeting giving the number of 8583 transactions that had the "SET" valid
signature flag set .... and they could proove that there was no
cryptographic capability involved at all (i.e. it wasn't even a SET gateway
that might not be telling the truth ... but there were financial reasons
why others might want the flag set also).

now, I would claim that an end-point business operation might
compartmentilize some of its functions ... so that any compromize in any
single component doesn't compromise all components. i would contend that a
compartmentilzed end-point security solution is different than several
different business operations all implementing various kinds of
intermediate processing (middle-man) preventing any kind of end-to-end
integrity.

random old middleware/middle layer refs:
http://www.garlic.com/~lynn/96.html#16 middle layer
http://www.garlic.com/~lynn/96.html#17 middle layer
http://www.garlic.com/~lynn/98.html#50 Edsger Dijkstra: the blackest week
of his professional life
http://www.garlic.com/~lynn/99.html#123 Speaking of USB ( was Re: ASR 33
Typing Element)
http://www.garlic.com/~lynn/99.html#124 Speaking of USB ( was Re: ASR 33
Typing Element)
http://www.garlic.com/~lynn/99.html#201 Middleware - where did that come
from?
http://www.garlic.com/~lynn/99.html#202 Middleware - where did that come
from?
http://www.garlic.com/~lynn/2000b.html#59 7 layers to a program
http://www.garlic.com/~lynn/2000e.html#45 IBM's Workplace OS (Was: .. Pink)
http://www.garlic.com/~lynn/2001d.html#69 Block oriented I/O over IP
http://www.garlic.com/~lynn/2001j.html#4 I hate Compaq
http://www.garlic.com/~lynn/2001j.html#20 OT - Internet Explorer V6.0
http://www.garlic.com/~lynn/2001k.html#18 HP-UX will not be ported to Alpha
(no surprise)exit
http://www.garlic.com/~lynn/2001m.html#15 departmental servers
http://www.garlic.com/~lynn/2001n.html#23 Alpha vs. Itanic:  facts vs. FUD
http://www.garlic.com/~lynn/2001n.html#34 Hercules etc. IBM not just
missing a great opportunity...
http://www.garlic.com/~lynn/2001n.html#55 9-track tapes (by the armful)
http://www.garlic.com/~lynn/2002.html#2 The demise of compaq
http://www.garlic.com/~lynn/2002.html#7 The demise of compaq
http://www.garlic.com/~lynn/2002.html#11 The demise of compaq
http://www.garlic.com/~lynn/2002b.html#4 Microcode? (& index searching)
http://www.garlic.com/~lynn/2002b.html#37 Poor Man's clustering idea
http://www.garlic.com/~lynn/2002d.html#4 IBM Mainframe at home
http://www.garlic.com/~lynn/2002d.html#14 Mainframers: Take back the light
(spotlight, that is)
http://www.garlic.com/~lynn/2002e.html#2 IBM's "old" boss speaks (was
"new")



[e-mail] on 5/16/2002 1:33 pm wrote:


Hi Lynn (and greetings to PKIX, 1st-time poster here),

A counter-argument: while adding a middleman adds a vulnerability, it also
adds auditing: the middleman can monitor all password attempts, so as to:
 - lockout guessers
 - detect anomalous patterns of use which may indicate a compromised
password is being exploited
 - allow users to review audit trails to detect compromises themselves
 - allow users to review audit trails to determine the extent of a
compromise

Without this auditing, it may be much more difficult to detect a compromise
of a private key, and to determine precisely what has been compromised.

So there are security benefits as well as disadvantages to middlemen, I
suppose a comparison depends on the exact situation and how you weight the
factors..

Trevor


-----Original Message-----
From: [e-mail] [mailto:[e-mail]]
Sent: Thursday, May 16, 2002 10:00 AM
To: Anders Rundgren
Cc: Dean Adams; [e-mail];
[e-mail]
Subject: Re: IBM alternative to PKI?



i.e. middle-man tends to represent transition/roll-out solutions .... not
security infrastructure solutions.

from traditional security

* end-to-end

middle-man approaches tend to always negate any end-to-end attribute

* additional steps represent additional vulnerabilities

middle-man approaches increase the number of steps/processes .... each of
which represent an additional vulnerability, each additional vulnerability
represents additional points of failure/fraud

* only as strong as the weakest link

shared-secret password paradigm in series with digital signature isn't
additive.

* 2-factor authentication

secret password (as opposed to shared-secret password) in conjunction with
hardware token (i.e. processing in parallel instead of in series)
represents a combination link (both hardware token and secret password has
to be compromised). a shared-secret password process in series with a
digital signature process can fail with just the shared-secret password.









Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g4GJXog23209 for ietf-pkix-bks; Thu, 16 May 2002 12:33:50 -0700 (PDT)
Received: from bulwinkle.sigaba.com (bulwinkle.sigaba.com [63.202.162.42]) by above.proper.com (8.11.6/8.11.3) with SMTP id g4GJXmL23205 for <[e-mail]>; Thu, 16 May 2002 12:33:48 -0700 (PDT)
Received:  from bsd.sigaba.com (63.202.162.50)  by bulwinkle.sigaba.com (Sigaba Gateway v3.0)  with SMTP; Thu, 16 May 2002 12:32:01 (PDT)
Received:  from exchange1.sigaba.com (exchange1.sigaba.com [10.10.10.10]) by bsd.sigaba.com (8.12.2/8.12.2) with ESMTP id g4GJXire005748; Thu, 16 May 2002 12:33:44 -0700
Received:  by exchange.sigaba.com with Internet Mail Service (5.5.2653.19) id <LBDF5Y39>; Thu, 16 May 2002 12:33:43 -0700
Message-id:  <[e-mail]>
From: Trevor Perrin <[e-mail]>
To: "'[e-mail]'" <[e-mail]>, Anders Rundgren <[e-mail]>
Cc: Dean Adams <[e-mail]>, [e-mail], [e-mail]
Subject:  RE: IBM alternative to PKI?
Date:  Thu, 16 May 2002 12:33:42 -0700
MIME-Version:  1.0
X-mailer:  Internet Mail Service (5.5.2653.19)
Content-Type:  text/plain; charset="iso-8859-1"
Content-Transfer-Encoding:  7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Hi Lynn (and greetings to PKIX, 1st-time poster here),

A counter-argument: while adding a middleman adds a vulnerability, it also
adds auditing: the middleman can monitor all password attempts, so as to:
 - lockout guessers
 - detect anomalous patterns of use which may indicate a compromised
password is being exploited
 - allow users to review audit trails to detect compromises themselves
 - allow users to review audit trails to determine the extent of a
compromise

Without this auditing, it may be much more difficult to detect a compromise
of a private key, and to determine precisely what has been compromised.

So there are security benefits as well as disadvantages to middlemen, I
suppose a comparison depends on the exact situation and how you weight the
factors..

Trevor


-----Original Message-----
From: [e-mail] [mailto:[e-mail]]
Sent: Thursday, May 16, 2002 10:00 AM
To: Anders Rundgren
Cc: Dean Adams; [e-mail];
[e-mail]
Subject: Re: IBM alternative to PKI?



i.e. middle-man tends to represent transition/roll-out solutions .... not
security infrastructure solutions.

from traditional security

* end-to-end

middle-man approaches tend to always negate any end-to-end attribute

* additional steps represent additional vulnerabilities

middle-man approaches increase the number of steps/processes .... each of
which represent an additional vulnerability, each additional vulnerability
represents additional points of failure/fraud

* only as strong as the weakest link

shared-secret password paradigm in series with digital signature isn't
additive.

* 2-factor authentication

secret password (as opposed to shared-secret password) in conjunction with
hardware token (i.e. processing in parallel instead of in series)
represents a combination link (both hardware token and secret password has
to be compromised). a shared-secret password process in series with a
digital signature process can fail with just the shared-secret password.





Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g4GH46A17655 for ietf-pkix-bks; Thu, 16 May 2002 10:04:06 -0700 (PDT)
Received: from nymelsmtp.internet.ny.fdms.firstdata.com ([204.124.248.17]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g4GH45L17649 for <[e-mail]>; Thu, 16 May 2002 10:04:05 -0700 (PDT)
Subject: Re: IBM alternative to PKI?
To: "Anders Rundgren" <[e-mail]>
Cc: "Dean Adams" <[e-mail]>, [e-mail], [e-mail]
X-Mailer: Lotus Notes Release 5.0.5  September 22, 2000
Message-ID: <[e-mail]>
From: [e-mail]
Date: Thu, 16 May 2002 10:59:36 -0600
X-MIMETrack: Serialize by Router on NYMELSMTP/NY/FDMS/FDC(Release 5.0.8 |June 18, 2001) at 05/16/2002 01:00:57 PM
MIME-Version: 1.0
Content-type: text/plain; charset=us-ascii
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

i.e. middle-man tends to represent transition/roll-out solutions .... not
security infrastructure solutions.

from traditional security

* end-to-end

middle-man approaches tend to always negate any end-to-end attribute

* additional steps represent additional vulnerabilities

middle-man approaches increase the number of steps/processes .... each of
which represent an additional vulnerability, each additional vulnerability
represents additional points of failure/fraud

* only as strong as the weakest link

shared-secret password paradigm in series with digital signature isn't
additive.

* 2-factor authentication

secret password (as opposed to shared-secret password) in conjunction with
hardware token (i.e. processing in parallel instead of in series)
represents a combination link (both hardware token and secret password has
to be compromised). a shared-secret password process in series with a
digital signature process can fail with just the shared-secret password.






Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g4GG0Cj15033 for ietf-pkix-bks; Thu, 16 May 2002 09:00:12 -0700 (PDT)
Received: from vulcan.rsasecurity.com (mail.rsasecurity.com [204.167.114.123]) by above.proper.com (8.11.6/8.11.3) with SMTP id g4GG09L15017 for <[e-mail]>; Thu, 16 May 2002 09:00:09 -0700 (PDT)
Received: from no.name.available by vulcan.rsasecurity.com via smtpd (for mail.imc.org [208.184.76.43]) with SMTP; 16 May 2002 15:58:28 UT
Received: from ebola.securitydynamics.com (ebola.securid.com [192.80.211.4]) by sdtihq24.securid.com (Pro-8.9.3/Pro-8.9.3) with ESMTP id MAA08952 for <[e-mail]>; Thu, 16 May 2002 12:00:09 -0400 (EDT)
Received: from exna00.securitydynamics.com (localhost [127.0.0.1]) by ebola.securitydynamics.com (8.10.2+Sun/8.10.2) with ESMTP id g4GFwJr25415 for <[e-mail]>; Thu, 16 May 2002 11:58:19 -0400 (EDT)
Received: by exna00.securitydynamics.com with Internet Mail Service (5.5.2653.19) id <K2ZLC6DN>; Thu, 16 May 2002 12:00:07 -0400
Received: from HOUSLEY-LAP.rsasecurity.com (HOUSLEY-LAP [10.3.16.68]) by exna00.securitydynamics.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id K2ZLC6DD; Thu, 16 May 2002 11:59:56 -0400
From: "Housley, Russ" <[e-mail]>
To: "Manger, James H" <[e-mail]>
Cc: [e-mail]
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Version 5.1
Date: Thu, 16 May 2002 11:17:03 -0400
Subject: RE: I-D ACTION:draft-ietf-pkix-logotypes-02.txt
In-Reply-To: <[e-mail] l.telstra.com.au>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

James:

I have been giving this issue (raised almost a month ago) some 
thought.  Suppose that an community wants to make their logo available in 
many different formats to support the diverse set of platforms that may 
choose to display it.  A credit card brand logo is a straightforward 
example.  The logo might be displayed on a desktop machine, a laptop, a 
kiosk, a palm device, or a cell phone.  Each has a different environment, 
display resolution, color resolution, and so on.  Therefore, I think the 
application needs to know what image formats are available.

You make the point that the file extension does not really have to be 
honored.  It is followed by convention, but that the MIME type really 
governs way that the URL will be processed.

To me, the question is what provides the application with the best selector 
to pick the URL.  If the blob of bits that is returned is not in the 
expected format, then the application may not be able to display 
anything.  The result will be an empty box instead of a logo.  Since this 
is bad for the community, I expect them to follow any conventions that we 
establish.

Is a file extension or a longer MIME type a better convention?  I think 
that they provide the same information as a selector.  I advocate the file 
extension.  I have only one reason -- it is shorter.

Russ

At 11:52 AM 4/19/2002 +1000, Manger, James H wrote:

>A referenced logo WILL be identified by a MIME-type.  Dereferencing the URI
>will (presumably) result in something like the following (with various other
>header fields omitted):
>
>         HTTP/1.1 200 OK
>         Content-Length: 177
>         Last-Modified: Thu, 18 Sep 1997 04:22:02 GMT
>         Content-Type: image/gif
>
>         GIF89aJH&^%&^b6TB^(&...
>
>A ".gif" extension in the URL may suggest a "image/gif" MIME-type will be
>returned, but a web server is actually free to return any MIME-type it
>wants.  I think browsers will (and should) process the result based on the
>MIME-type instead of the URI extension.
>
>So perhaps it would be better for the 'imageFileExtn' field to be
>'imageContentType' and hold a MIME-type.  (might you ever what to include
>other MIME header fields? in which case a 'imageMIMEHeaders' field might be
>needed instead.)
>
>
>There is no description of the 'logotypeHash' field.  I suspect the authors
>intention is to hash the bytes of the *.gif (or *.jpeg) file, excluding any
>MIME or HTTP headers fields delivered with the image.  Presumably any
>transfer encoding (but not Content-Encoding?) is also removed before
>hashing?
>
>Such a hash does not bind the content to the MIME-type.  This maybe
>acceptable, though it might warrant a paragraph in the security
>considerations section.
>
>
>Change the 'highRes' and 'lowRes' field names to, say, 'reference' and
>'embedded' (or 'indirect' and 'direct').  Which resolutions are appropriate
>is a matter of judgement, policy, environment or best practise -- so it
>should be discussed in the document, but not hard-wired into the syntax.
>
>
>
> > ----------
> > From: Housley, Russ [SMTP:[e-mail]]
> > Sent: Friday, 19 April 2002 5:58 am
> >
> > >..Also, IMHO it would be better to identify GIF & JPEG pictures by their
> > >corresponding MIME types than to invent your own way of doing this..
> >
>         ..We do not want to point to a MIME encoded object.  Rather we want
>to point
> > to the GIF or JPEG binary object.  In this manner, one could use the same
> > file for many different purposes, including display on the organization's
> > web page.  This size seems appropriate for a logo in a header.
> >


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g4GFlOs14655 for ietf-pkix-bks; Thu, 16 May 2002 08:47:24 -0700 (PDT)
Received: from ext-mail.valicert.com ([66.206.205.11]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g4GFlOL14651 for <[e-mail]>; Thu, 16 May 2002 08:47:24 -0700 (PDT)
Received: from CONVERSION-DAEMON by ext-mail.valicert.com (PMDF V5.2-33 #46613) id <[e-mail]> for [e-mail]; Thu, 16 May 2002 08:43:04 -0700 (PDT)
Received: from polaris.valicert.com ([192.168.2.34]) by ext-mail.valicert.com (PMDF V5.2-33 #46613) with ESMTP id <[e-mail]>; Thu, 16 May 2002 08:43:04 -0700 (PDT)
Received: by polaris.valicert.com with Internet Mail Service (5.5.2653.19) id <K7HLL3RD>; Thu, 16 May 2002 08:47:17 -0700
Content-return: allowed
Date: Thu, 16 May 2002 08:47:17 -0700
From: Ambarish Malpani <[e-mail]>
Subject: RE: Certificate for an authorized OCSP responder
To: "'[e-mail]'" <[e-mail]>, [e-mail]
Message-id: <[e-mail]>
MIME-version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-type: text/plain;	charset="iso-8859-1"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Hi DM,
    If you are trying to use the CA delegated trust model of OCSP,
then you are absolutely right - the responder will need one cert
from each CA (even if they belong to the same hierarchy).

However, if you are using the
"Matches a local configuration of OCSP signing authority for..."
model of OCSP (which I call direct trust), then you can have just
a single certificate for multiple CAs.

Hope this helps,
Regards,
Ambarish

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


> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]]
> Sent: Thursday, May 16, 2002 5:08 AM
> To: [e-mail]
> Subject: Certificate for an authorized OCSP responder
> 
> 
> 
> From rfc 2560
> 
>  "The key that signs a certificate's status information need 
> not be the
>  same key that signed the certificate. It is necessary however to
>  ensure that the entity signing this information is authorized to do
>  so.  Therefore, a certificate's issuer MUST either sign the OCSP
>  responses itself or it MUST explicitly designate this authority to
>  another entity.  OCSP signing delegation SHALL be designated by the
>  inclusion of id-kp-OCSPSigning in an extendedKeyUsage certificate
>  extension included in the OCSP response signer's certificate.  This
>  certificate MUST be issued directly by the CA that issued the
>  certificate in question.
> 
> ....
>   They MUST reject the
>    response if the certificate required to validate the 
> signature on the
>    response fails to meet at least one of the following criteria:
> 
>    1. Matches a local configuration of OCSP signing authority for the
>    certificate in question; or
> 
>    2. Is the certificate of the CA that issued the certificate in
>    question; or
> 
>    3. Includes a value of id-ad-ocspSigning in an ExtendedKeyUsage
>    extension and is issued by the CA that issued the certificate in
>    question.
> 
> .....
> 
> 4.2.2.2.1  Revocation Checking of an Authorized Responder
> 
>    Since an Authorized OCSP responder provides status information for
> one or more CAs "
> 
> My understanding of the RFC is that an authorized responder 
> need more than
> one certificate if it provides status information for one or 
> more CAs otherwise
> is not possible to meet the requirement that specifies the 
> need for the
> OCSP responder certificate to be issued directly from the CA 
> that issued
> the EE certificate under examination. Is this correct?
> 
> If yes it is the same true even if these different CAs belong 
> to same PKI
> ?
> 
> Thanks in advance for any clarification.
> Regards,
> DM  
> 
> 
> 
> 
> 
> 
> 
> __________________________________________________________________
> Abbonati a Tiscali!
> Con Tiscali By Phone puoi anche ascoltare ed inviare email al 
> telefono.
> Chiama Tiscali By Phone all' 892 800        http://byphone.tiscali.it
> 
> 
> 
> 


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g4GEqss12699 for ietf-pkix-bks; Thu, 16 May 2002 07:52:54 -0700 (PDT)
Received: from nymelsmtp.internet.ny.fdms.firstdata.com ([204.124.248.17]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g4GEqrL12695 for <[e-mail]>; Thu, 16 May 2002 07:52:53 -0700 (PDT)
Subject: Re: IBM alternative to PKI?
To: "Anders Rundgren" <[e-mail]>
Cc: "Dean Adams" <[e-mail]>, [e-mail], [e-mail]
X-Mailer: Lotus Notes Release 5.0.5  September 22, 2000
Message-ID: <[e-mail]>
From: [e-mail]
Date: Thu, 16 May 2002 08:48:51 -0600
X-MIMETrack: Serialize by Router on NYMELSMTP/NY/FDMS/FDC(Release 5.0.8 |June 18, 2001) at 05/16/2002 10:49:45 AM
MIME-Version: 1.0
Content-type: text/plain; charset=us-ascii
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

my impression is that server-side signings are typically the desire for
putting in a "real" PKI infrastructure .... but single, large roll-out of
all the technology is an issue ... so the backends implement real PKI, and
there is a middle-man which interacts with the clients in a more
traditional (password) paradigm and the middle-man  acts as a proxy doing
the PKI stuff on behalf of the client. At any point, individual clients
might be able to deploy their own PKI operation and eliminate using the
proxy (theory is that it facilitates the transition from password-based
paradigm to PKI-based paradigm by not requiring all backends and all
clients to make the paradigm transition in a single, syncronous event).

Many of the EU and other relying-party-only PKI deployments were addressing
a different issue. They came to realize that the traditional PKI identity
certificates didn't address any of their business needs ... the client was
doing digital signature operations and appending things that bore a little
resemblence to identity certificates ... enuf so that traditional PKI
sottware might work. However, other than the facilitating of traditional
PKI software ... the certificates weren't not serving any actual business
function.

The first case of server-side PKI isn't so much a PKI alternative issue ...
it is a traditional PKI roll-out/transition facilitor.  I believe the
second case of experience from relying-party-only certificates ... could be
considered more of a PKI alternative issue (i.e. discovery that
certificates weren't serving any valid business  function).


[e-mail] on 5/16/2002 6:53 am wrote:


Liaquat

>This model came out of the work down by IBM and others as a part of the
TIE
>(Trust Infrastructure for Europe) project.  It is based on public key
>cryptography, but looking at things from a slight different angle, i.e.
from
>the viewpoint of the RP. I need to be careful on how much I can say.

You just triggered my curiosity!

Is it fundamentally different to 3D Secure and SAML?  I.e. schemes
where the client authenticates to a server-based PKI-thing that does
the actual work (signs resp. creates auth*).

Anders









Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g4GC8Gx03112 for ietf-pkix-bks; Thu, 16 May 2002 05:08:16 -0700 (PDT)
Received: from mail.tiscalinet.it (mail-6.tiscalinet.it [195.130.225.152]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g4GC8FL03108 for <[e-mail]>; Thu, 16 May 2002 05:08:15 -0700 (PDT)
Received: from [130.192.1.66] by mail.tiscalinet.it with HTTP; Thu, 16 May 2002 14:08:10 +0200
Message-ID: <[e-mail]>
Date: Thu, 16 May 2002 14:08:10 +0200
From: [e-mail]
Subject: =?iso-8859-1?Q?Certificate=20for=20an=20authorized=20OCSP=20responder?=
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 above.proper.com id g4GC8FL03109
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

>From rfc 2560

 "The key that signs a certificate's status information need not be the
 same key that signed the certificate. It is necessary however to
 ensure that the entity signing this information is authorized to do
 so.  Therefore, a certificate's issuer MUST either sign the OCSP
 responses itself or it MUST explicitly designate this authority to
 another entity.  OCSP signing delegation SHALL be designated by the
 inclusion of id-kp-OCSPSigning in an extendedKeyUsage certificate
 extension included in the OCSP response signer's certificate.  This
 certificate MUST be issued directly by the CA that issued the
 certificate in question.

....
  They MUST reject the
   response if the certificate required to validate the signature on the
   response fails to meet at least one of the following criteria:

   1. Matches a local configuration of OCSP signing authority for the
   certificate in question; or

   2. Is the certificate of the CA that issued the certificate in
   question; or

   3. Includes a value of id-ad-ocspSigning in an ExtendedKeyUsage
   extension and is issued by the CA that issued the certificate in
   question.

.....

4.2.2.2.1  Revocation Checking of an Authorized Responder

   Since an Authorized OCSP responder provides status information for
one or more CAs "

My understanding of the RFC is that an authorized responder need more than
one certificate if it provides status information for one or more CAs otherwise
is not possible to meet the requirement that specifies the need for the
OCSP responder certificate to be issued directly from the CA that issued
the EE certificate under examination. Is this correct?

If yes it is the same true even if these different CAs belong to same PKI
?

Thanks in advance for any clarification.
Regards,
DM  







__________________________________________________________________
Abbonati a Tiscali!
Con Tiscali By Phone puoi anche ascoltare ed inviare email al telefono.
Chiama Tiscali By Phone all' 892 800        http://byphone.tiscali.it






Received: by above.proper.com (8.11.6/8.11.3) id g4GBvSR02361 for ietf-pkix-bks; Thu, 16 May 2002 04:57:28 -0700 (PDT)
Received: from blooper.utfors.se (mail.utfors.se [195.58.103.125]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g4GBvML02354 for <[e-mail]>; Thu, 16 May 2002 04:57:22 -0700 (PDT)
Received: from arport ([62.119.75.13]) by blooper.utfors.se (Utfors AB) with SMTP id g4GBv3JJ009016; Thu, 16 May 2002 13:57:03 +0200 (MEST)
Message-ID: <023001c1fcd8$c0b4bb90$0500a8c0@arport>
From: "Anders Rundgren" <[e-mail]>
To: <[e-mail]>, "Dean Adams" <[e-mail]>, <[e-mail]>
References: <[e-mail]>
Subject: Re: IBM alternative to PKI?
Date: Thu, 16 May 2002 14:53:50 +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 5.50.4133.2400
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Liaquat

>This model came out of the work down by IBM and others as a part of the TIE
>(Trust Infrastructure for Europe) project.  It is based on public key
>cryptography, but looking at things from a slight different angle, i.e. from
>the viewpoint of the RP. I need to be careful on how much I can say.

You just triggered my curiosity!

Is it fundamentally different to 3D Secure and SAML?  I.e. schemes
where the client authenticates to a server-based PKI-thing that does
the actual work (signs resp. creates auth*).

Anders





Received: by above.proper.com (8.11.6/8.11.3) id g4GBLxX27865 for ietf-pkix-bks; Thu, 16 May 2002 04:21:59 -0700 (PDT)
Received: from ietf.org (odin.ietf.org [132.151.1.176]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g4GBLvL27860 for <[e-mail]>; Thu, 16 May 2002 04:21:58 -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 HAA20390; Thu, 16 May 2002 07:21:03 -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-dpv-dpd-req-05.txt
Date: Thu, 16 May 2002 07:21:03 -0400
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

--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		: Delegated Path Validation and Delegated Path Discovery
                          Protocol Requirements
	Author(s)	: D. Pinkas, R. Housley
	Filename	: draft-ietf-pkix-dpv-dpd-req-05.txt
	Pages		: 13
	Date		: 15-May-02
	
This document specifies the requirements for Delegated Path Validation 
(DPV) and Delegated Path Discovery (DPD) for Public Key Certificates. 
It also specifies the requirements for DPV and DPD policy management.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-pkix-dpv-dpd-req-05.txt

To remove yourself from the IETF Announcement list, send a message to 
ietf-announce-request with the word unsubscribe in the body of the message.

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-dpv-dpd-req-05.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-dpv-dpd-req-05.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-dpv-dpd-req-05.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-pkix-dpv-dpd-req-05.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

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

--OtherAccess--

--NextPart--




Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g4G8hEs13123 for ietf-pkix-bks; Thu, 16 May 2002 01:43:14 -0700 (PDT)
Received: from fw1.gdm.de (fw1.gdm.de [193.108.184.254]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g4G8hDL13109 for <[e-mail]>; Thu, 16 May 2002 01:43:13 -0700 (PDT)
Received: (from root@localhost) by fw1.gdm.de (8.11.6/8.11.6) id g4G8gQp05992; Thu, 16 May 2002 10:42:26 +0200 (CEST)
Received: (from localhost) by fw1.gdm.de (MSCAN) id 3/fw1.gdm.de/smtp-gw/mscan; Thu May 16 10:42:25 2002
To: Denis Pinkas <[e-mail]>
Cc: pkix <[e-mail]>
Subject: Re: Meaning of Non-repudiation
MIME-Version: 1.0
X-Mailer: Lotus Notes Release 5.07a  May 14, 2001
Message-ID: <[e-mail]>
From: [e-mail]
Date: Thu, 16 May 2002 10:43:07 +0200
X-MIMETrack: MIME-CD by tm_grab on NOTESGDM1/SRV/GuD(Release 5.0.8 |June 18, 2001) at 05/16/2002 10:43:11 AM, MIME-CD complete at 05/16/2002 10:43:11 AM, Serialize by Router on NOTESDMZ1/SRV/GuD(Release 5.0.8 |June 18, 2001) at 05/16/2002 10:45:14 AM
Content-type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id g4G8hEL13119
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Looking at existing PKI implementations in standard products like Lotus
Notes or Microsoft Outlook, unfortunately it appears that only
keyEncipherment and digitalSignature are used in an coherent way. Outlook
or Netscape Messenger for example reject and do not offer the use of a key
with a certificate containing a keyUsage = NR only for anything, Notes does
accept it for signing E-Mails (as it does with KeyUsage= DS). On the other
hand a key certified with NR = DS can be used both for authentication and
signing in all products I looked at.

This means that DS is currently interpreted by existing applications as
"private key capable of signing something (a hash or a challenge)", NR is
interpreted by some applications as either equivalent to DS or "private key
not capable of signing." (I did not test the applicability of the keyUsage
= NR for authentication beside checking wether Netscape offers this
certificate for preselection as an authenticaiton certificate, it does not)

Looking at the suggested semantics listed below, existing applications
obviously do not follow, but include the suggested meaning of NR into the
meaning of DS.

Note that a CA can not normally make statements on the environment a user
has when applying a key for any purpose. A CA only can make a statement
like "I informed the user about the conditions under which the key shall be
used, and the user is aware of consequences of not meeting those
conditions." An excemption of this is if the CA knows the the token holding
the private key protects it against misuse in a technologically way then
the CA can make this statement on the "environment". However, one can
always design and deploy an authentication protocol that utilizes a key
capable of signing hashes only. There are no technological means for a CA
to ensure that the user uses a key intended for non-repudiation really only
in this way.

I suggest to define the bits in keyUsage in terms of key capabilities. This
is already been done for the DS bit, and should be done for the NR bit as
well. The NR bit should be defined as "the private key is in some way
restricted in signing certain data formats only, and cannot be used to sign
arbitrary data pieces".
Applications should then not use a key with the NR bit set for
authentication protocols.
|------------------------+------------------------+------------------------|
|                        |   Denis Pinkas         |                        |
|                        |   <[e-mail]|           To:          |
|                        |   t>                   |   pkix                 |
|                        |   Sent by:             |   <[e-mail]>  |
|                        |   owner-ietf-pkix@mail.|           cc:          |
|                        |   imc.org              |           Subject:     |
|                        |                        |   Re: Meaning of       |
|                        |   15.05.2002 18:19     |   Non-repudiation      |
|                        |                        |                        |
|------------------------+------------------------+------------------------|








After taking a few days off, I have analyzed the storm of the e-mail
exchanges on that topic.

The core of the problem is that some people, by claiming requesting some
"clarifications" on these two bits, would like to change their semantics.

:-(

The roadmap provides a good summary of what happened in the past:

   (...) many discussions were needed to arrive at
  a common agreement on the meaning of the digitalSignature (DS bit)
  and nonRepudiation (NR bit) bits and when they should be set. The
  group quickly realized that key usage extension mixes services and
  mechanisms. The DS bit indicates a mechanism - a public key used to
  verify a digital signature. The NR bit indicates a service - a public
  key used to verify a digital signature and to provide a non-
  repudiation service. When trying to indicate when each bit should be
  indicated arguments were based on:

   The lifetime of the object being singed. Some felt that the DS bit
  should be set when the certificate is used to sign ephemeral objects
  (e.g., bind tokens) while the NR bit should be set for things that
  are survive longer (e.g., documents). Of course, the problem with
  this distinction to determine how long is the time period for
  ephemeral?

   A conscious act taken by the signer. Many felt that the NR bit should
  be set only when the subject has expressly acknowledged that they
  want to use the private key to sign an object. Signing a document say
  where there is a conscious decision by the subject would be
  appropriate for the key usage extension to contain NR, but when the
  key is used for authentication purposes, which can occur
  automatically and more frequently, the DS bit is more appropriate.

   The discussion also concluded that since some authentication schemes
  occur automatically, that the DS bit and NR bit should never be set
  together in the same certificate. Some agreed to the differentiation
  of the bits based on the time, but did not agree that the two could
  not be in the same key usage extension.

   The procedures followed by the CA. Some felt that NR bit was kind of
  'quality mark' indicating to the verifier that the verifier could be
  assured that the CA is implementing appropriate procedures for
  checking the subject's identity, performing certificate archival,
  etc. Other felt that it was not entirely the CAs job and that some
  other entity must be involved.

   In the end the WG agreed to a few things:

   - Provision of the service of non-repudiation requires more than a
    single bit set in a PKC. It requires an entire infrastructure of
    components to preserve for some period of time the keys, PKCs,
    revocation status, signed material, etc., as well as a trusted
    source of time. However, the nonRepudiation key usage bit is
    provided as an indicator that such keys could be used as a
    component of a system providing a non-repudiation service.

   - The certificate policy is the appropriate place to indicate the
    permitted combinations of key usages. That is, a policy may
    indicate that the DS and NR bits can not be set in the same
    certificate while another may say that the DS and NR bits can be
    set in the same certificate.

   [2459bis] includes new text indicating the above agreements.

In addition to these explanations I would like to quickly reply to Sharon
to
say her that I disagree (as others) when she says that the only meaning of
the NR bit is to say that the CA has no knowledge of the value of the
private key. This would rule out CAs generating key pairs and would not be
backward compatible with the current meaning.

Now let us attempt to CLARIFY the meaning.

David Kemp offered good explanations on these two bits:

DS bit: the key is used to sign data, nonces or challenges that can be
verified in real-time (entity authentication and data origin authentication
services).

NR bit: the key is used to sign data that can be verified at a later time
(non?repudiation service).

I would offer these additional explanations:

When the DS bit (bit 0) is set, this means that the private key MAY have
been used in an environment that is not fully controlled by the private key
holder. In practice, this means that private keys related to certificates
that have the DS bit set, will be used for entity authentication (e.g.
signing challenges or nonces) or for data origin authentication (signing
data that has not necessarily been reviewed).

Since the environment is not fully controlled by the private key holder,
the
private key holder COULD deny that his key was used to sign a transaction,
because he could claim that he was believing that his private key was used
in an authentication process.

Some authorities (like CRL Issuers) can sign by using a key related to a
certificate that only has the DS bit set because they always chose what
they
sign and will never use that same key in an authentication exchange.


When the NR bit (bit 1) is set, this means that the private key holder will
only use its private key in an environment that he can control and which
allows him to be confident of the data that is being effectively signed..

The signer cannot claim that he was believing that his private key was
simply used in an authentication process that he could not control.

Denis





Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g4FJuBe09139 for ietf-pkix-bks; Wed, 15 May 2002 12:56:11 -0700 (PDT)
Received: from nymelsmtp.internet.ny.fdms.firstdata.com ([204.124.248.17]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g4FJuAL09134 for <[e-mail]>; Wed, 15 May 2002 12:56:10 -0700 (PDT)
Subject: RE: IBM alternative to PKI?
To: <[e-mail]>
Cc: [e-mail]
X-Mailer: Lotus Notes Release 5.0.5  September 22, 2000
Message-ID: <[e-mail]>
From: [e-mail]
Date: Wed, 15 May 2002 13:50:14 -0600
X-MIMETrack: Serialize by Router on NYMELSMTP/NY/FDMS/FDC(Release 5.0.8 |June 18, 2001) at 05/15/2002 03:53:04 PM
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 above.proper.com id g4FJuAL09135
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

there have been a number of things done for relying party operations. for
various of the relying-party-only certification authority pilots done in
europe and other countries .... it was possible to show that the public key
could be registered ... and it wasn't even necessary to send the
certificate back to the key owner .... just put it in the relying partie's
account record (i.e. they were sending the certificate back to the key
owner ... because there was some COTS software that could be used ... but
other than that it served no useful business function).

is this in anyway related to the previous work on relying-party-only pilots
that have been done in europe?



                                                                                                   
                                      "Liaquat khan"                                               
                    <Liaquat.Khan@TheGlobalTrustAuth     To:      <[e-mail]>              
                                          ority.org>     cc:                                       
                                            Sent by:     Subject:      RE: IBM alternative to PKI? 
                        [e-mail]                                               
                                                                                                   
                                                                                                   
                                 05/15/2002 01:10 PM                                               
                      Please respond to Liaquat.Khan                                               
                                                                                                   
                                                                                                   






This model came out of the work down by IBM and others as a part of the TIE
(Trust Infrastructure for Europe) project.  It is based on public key
cryptography, but looking at things from a slight different angle, i.e.
from
the viewpoint of the RP. I need to be careful on how much I can say.
Although there maybe publicly available information out there somewhere.

Regards,
Liaquat Khan

-----Original Message-----
From: [e-mail]
[mailto:[e-mail]]On Behalf Of Dean Adams
Sent: Tuesday, May 14, 2002 8:32 AM
To: Peter Gutmann; [e-mail]; [e-mail]
Subject: RE: IBM alternative to PKI?



Thanks Peter,
           It was this sort of question that I really intended. Apologies
for being so
vague.

Your theories may be correct on how this has been invented and put forward
to the UK government.  My understanding is that a UK IBM'er (Peter Dare)
may
have proposed this new PKI alternative.
Any IBM'ers out there who can comment - provide further detail on this
model?


> -----Original Message-----
> From: Peter Gutmann [mailto:[e-mail]]
> Sent: 14 May 2002 08:41
> To: [e-mail]; [e-mail]; [e-mail]
> Subject: Re: IBM alternative to PKI?
>
>
> "Anders Rundgren" <[e-mail]> writes:
>
> >I do not know anything of e-Envoy but I do know a few things
> concerning PKI
> >and smart cards.  There are indeed commercial problems
> associated with smart
> >cards.  But does it get better by introducing yet another type
> of card and
> >credentials?
>
> Does anyone know exactly what this new solution is?  With the
> size of IBM, the
> news story could quite easily translate into "Some random corner
> of IBM, under
> the impression that another far-flung corner of said company had
> something cool
> to offer, have tried to sell said something to the UK government,
> and are now
> frantically trying to find out what it is they've sold them".
>
> (I've seen some research papers on an XML-based PKI-avoiding
> system which might
> fit the bill, but who knows what the story is really talking about).
>
> Peter.
>
>
____________________________________________________________
Dean Adams               mobile:         [phone]
Trustis Limited          Direct Tel/Fax: [phone]
49 Whitehall             Office Tel:     [phone]
London SW1A 2BX          Office Fax:     [phone]
email: [e-mail]    Web: http://www.trustis.com
____________________________________________________________
The information in this message is confidential.  It is intended solely for
the addressee.  Access to this message by anyone else is unauthorised.  If
you are not the intended recipient, any disclosure, copying, distribution
or
any action taken or omitted to be taken in reliance on it, is prohibited
and
may be unlawful.

Any attachments to this message have been checked for viruses, but please
rely on your own virus checker and procedures.

If you contact us by e-mail, we may store your name and address to
facilitate communications.








Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g4FInkI07097 for ietf-pkix-bks; Wed, 15 May 2002 11:49:46 -0700 (PDT)
Received: from mtiwmhc22.worldnet.att.net (mtiwmhc22.worldnet.att.net [204.127.131.47]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g4FIniL07091 for <[e-mail]>; Wed, 15 May 2002 11:49:44 -0700 (PDT)
Received: from tsg1 ([12.81.64.32]) by mtiwmhc22.worldnet.att.net (InterMail vM.4.01.03.27 201-229-121-127-20010626) with SMTP id <20020515184939.BBNU11146.mtiwmhc22.worldnet.att.net@tsg1>; Wed, 15 May 2002 18:49:39 +0000
Message-ID: <01fe01c1fc40$abbc37b0$[e-mail]>
From: "todd glassey" <[e-mail]>
To: "Michael Froomkin - U.Miami School of Law" <[e-mail]>
Cc: "PKIX-IETF" <[e-mail]>, "LISTS - IETF-IESG" <[e-mail]>, <[e-mail]>
References: <[e-mail]> <01a101bfc044$ebb9e180$[e-mail]>
Subject: Re: Open issue: requester identifier in DPV response
Date: Wed, 15 May 2002 11:45:15 -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.50.4522.1200
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

By the way Michael - why were you suggesting that the officers of the IETF
and its other management have immunity from the skulls of Antitrust

Was it that they are the State's "Actors" under the Noerr-Pennington
Immunity model?  OK - but  486 US 501 seems to dismiss this, and in any
event the members of the IETF's management are there for their own
commercial and professional enrichment. Not some altruistic endeavor. So
what was the specific reason that you claimed I was wrong?

My take is that perhaps the IAB might pull this off and certainly ICANN
members might as you so rightly noted in your excellent dissertation on
ICANN reform. I especially enjoyed the section on the ICANN IP issues under
UDRP scenarios but I think the IP issues facing the standards portions of
the ICANN (IETF/IESG)  are different than those facing the trademark/urdp
groups within the registrar management functions.

Again this is just my two cents.

Todd

SNIP -




Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g4FIHZa06075 for ietf-pkix-bks; Wed, 15 May 2002 11:17:35 -0700 (PDT)
Received: from spitfire.law.miami.edu ([e-mail] [129.171.187.10]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g4FIHYL06063 for <[e-mail]>; Wed, 15 May 2002 11:17:34 -0700 (PDT)
Received: from spitfire.law.miami.edu (localhost [127.0.0.1]) by spitfire.law.miami.edu (Postfix) with ESMTP id 424505C3B90; Wed, 15 May 2002 14:17:36 -0400 (EDT)
Received: by spitfire.law.miami.edu (Postfix, from userid 1113) id 931835C3AEE; Wed, 15 May 2002 14:17:30 -0400 (EDT)
Received: from localhost (localhost [127.0.0.1]) by spitfire.law.miami.edu (Postfix) with ESMTP id 8A1885D3A61; Wed, 15 May 2002 14:17:30 -0400 (EDT)
Date: Wed, 15 May 2002 14:17:30 -0400 (EDT)
From: "Michael Froomkin - U.Miami School of Law" <[e-mail]>
To: todd glassey <[e-mail]>
Cc: PKIX-IETF <[e-mail]>, LISTS - IETF-IESG <[e-mail]>, [e-mail]
Subject: Re: Open issue: requester identifier in DPV response
In-Reply-To: <01a101bfc044$ebb9e180$[e-mail]>
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

This is silly, and I suspect you know it.  Perhaps it is no accident you
posted this after I wrote to you privately and asked you to stop emailing
me off-list?

Of course what I write here is not an "official" statement since I'm not
an "official" of anything. And it's not a statement as "counsel" because I
don't have a client here (or, indeed, at present any clients anywhere) and
am not licensed to practice in most of the places members of this list are
likely to be found. It's my personal academic opinion as a law professor
on a purely hypothetical question.  You may take it with a grain of salt,
since anti-trust is not my specialty, although I've recently had a crash
course in it by co-authoring a paper with one of the leading specialists
on anti-trust issues raised by ICANN.  My views are set out there for all
to see.

If you think you have an actual monetizable injury, I urge you to go find
a good lawyer admitted to practice wherever it may be you live, pay her a
lot of money, tell her the detailed facts, and get the sort of opinion you
can rely on given your facts and circumstances.  In making important life
choices such as whether to file a lawsuit, it would be beyond foolhardy to
rely on generalized and hypothetical comments on a mailing list if you
believe you are in possession of facts that might make out such a claim.

None of which is inconsistent with me saying that I personally can't
imagine what such a claim would look like without there being certain
types of facts, notably those I mentioned earlier in this thread, a set of
facts rather different from the ones you opined would suffice. [Note also
that I expressed no opinion as to whether either set of facts exist.] But
go ahead, find a laywer, then surprise me by filing a meritorious claim.
I'll learn something from the judge's opinion. Or someone will.


On Wed, 17 May 2000, todd glassey wrote:

> Michael - Ahahahahah (in my best Steve Martin from that fateful bar scene in
> "Roxanne") - 'Ohhhhh, you got me there', I'm just some dumb hacker and you
> are, well, you are...
> 
> ----- Original Message -----
> From: "Michael Froomkin - U.Miami School of Law" <[e-mail]>
> 
> SNIP --
> 
> >
> > The statement in your last 3.5 lines of the post quoted below is false as
> > a matter of US law.
> 
> OK Professor Froomkin, just one simple question - is this  your official
> statement to us as Counsel, and does that mean that if any of us that rely
> on your advice are damaged or fined as part of any antitrust action herein,
> that you will bear the financial responsibility?
> 
> See thats the wonder of being a lawyer these days - you dont get to have
> mere mortal opinions anymore, not when you assert them as more than simple
> fact, but rather as the fact.
> 

Actually I gave you a URL to a paper. Why don't you read it?
http://personal.law.miami.edu/~froomkin/articles/icann-antitrust.pdf
-- 
		Please visit http://www.icannwatch.org
A. Michael Froomkin   |    Professor of Law    |   [e-mail]
U. Miami School of Law, P.O. Box 248087, Coral Gables, FL 33124 USA
[phone]  |  [phone] (fax)  |  http://www.law.tm
                        -->It's hot here.<--



Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g4FIAQP05911 for ietf-pkix-bks; Wed, 15 May 2002 11:10:26 -0700 (PDT)
Received: from host8.successfulhosting.com (host8.successfulhosting.com [209.239.36.32]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g4FIAPL05907 for <[e-mail]>; Wed, 15 May 2002 11:10:25 -0700 (PDT)
Received: from fujitsu (host213-122-175-25.in-addr.btopenworld.com [213.122.175.25]) by host8.successfulhosting.com (8.10.2/8.10.2) with SMTP id g4FIAKN16322 for <[e-mail]>; Wed, 15 May 2002 14:10:21 -0400
Reply-To: <[e-mail]>
From: "Liaquat khan" <[e-mail]>
To: <[e-mail]>
Subject: RE: IBM alternative to PKI?
Date: Wed, 15 May 2002 19:10:11 -0000
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)
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
In-Reply-To: <[e-mail]>
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

This model came out of the work down by IBM and others as a part of the TIE
(Trust Infrastructure for Europe) project.  It is based on public key
cryptography, but looking at things from a slight different angle, i.e. from
the viewpoint of the RP. I need to be careful on how much I can say.
Although there maybe publicly available information out there somewhere.

Regards,
Liaquat Khan

-----Original Message-----
From: [e-mail]
[mailto:[e-mail]]On Behalf Of Dean Adams
Sent: Tuesday, May 14, 2002 8:32 AM
To: Peter Gutmann; [e-mail]; [e-mail]
Subject: RE: IBM alternative to PKI?



Thanks Peter,
	It was this sort of question that I really intended. Apologies for being so
vague.

Your theories may be correct on how this has been invented and put forward
to the UK government.  My understanding is that a UK IBM'er (Peter Dare) may
have proposed this new PKI alternative.
Any IBM'ers out there who can comment - provide further detail on this
model?


> -----Original Message-----
> From: Peter Gutmann [mailto:[e-mail]]
> Sent: 14 May 2002 08:41
> To: [e-mail]; [e-mail]; [e-mail]
> Subject: Re: IBM alternative to PKI?
>
>
> "Anders Rundgren" <[e-mail]> writes:
>
> >I do not know anything of e-Envoy but I do know a few things
> concerning PKI
> >and smart cards.  There are indeed commercial problems
> associated with smart
> >cards.  But does it get better by introducing yet another type
> of card and
> >credentials?
>
> Does anyone know exactly what this new solution is?  With the
> size of IBM, the
> news story could quite easily translate into "Some random corner
> of IBM, under
> the impression that another far-flung corner of said company had
> something cool
> to offer, have tried to sell said something to the UK government,
> and are now
> frantically trying to find out what it is they've sold them".
>
> (I've seen some research papers on an XML-based PKI-avoiding
> system which might
> fit the bill, but who knows what the story is really talking about).
>
> Peter.
>
>
____________________________________________________________
Dean Adams               mobile:         [phone]
Trustis Limited          Direct Tel/Fax: [phone]
49 Whitehall             Office Tel:     [phone]
London SW1A 2BX          Office Fax:     [phone]
email: [e-mail]    Web: http://www.trustis.com
____________________________________________________________
The information in this message is confidential.  It is intended solely for
the addressee.  Access to this message by anyone else is unauthorised.  If
you are not the intended recipient, any disclosure, copying, distribution or
any action taken or omitted to be taken in reliance on it, is prohibited and
may be unlawful.

Any attachments to this message have been checked for viruses, but please
rely on your own virus checker and procedures.

If you contact us by e-mail, we may store your name and address to
facilitate communications.




Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g4FGopV02428 for ietf-pkix-bks; Wed, 15 May 2002 09:50:51 -0700 (PDT)
Received: from mtiwmhc24.worldnet.att.net (mtiwmhc24.worldnet.att.net [204.127.131.49]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g4FGooL02424 for <[e-mail]>; Wed, 15 May 2002 09:50:50 -0700 (PDT)
Received: from tsg1 ([12.81.71.196]) by mtiwmhc24.worldnet.att.net (InterMail vM.4.01.03.27 201-229-121-127-20010626) with SMTP id <20020515165045.UPEN18857.mtiwmhc24.worldnet.att.net@tsg1>; Wed, 15 May 2002 16:50:45 +0000
Message-ID: <01a101bfc044$ebb9e180$[e-mail]>
From: "todd glassey" <[e-mail]>
To: "Michael Froomkin - U.Miami School of Law" <[e-mail]>
Cc: "PKIX-IETF" <[e-mail]>, "LISTS - IETF-IESG" <[e-mail]>, <[e-mail]>
References: <[e-mail]>
Subject: Re: Open issue: requester identifier in DPV response
Date: Wed, 17 May 2000 14:14:37 -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.50.4522.1200
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Michael - Ahahahahah (in my best Steve Martin from that fateful bar scene in
"Roxanne") - 'Ohhhhh, you got me there', I'm just some dumb hacker and you
are, well, you are...

----- Original Message -----
From: "Michael Froomkin - U.Miami School of Law" <[e-mail]>

SNIP --

>
> The statement in your last 3.5 lines of the post quoted below is false as
> a matter of US law.

OK Professor Froomkin, just one simple question - is this  your official
statement to us as Counsel, and does that mean that if any of us that rely
on your advice are damaged or fined as part of any antitrust action herein,
that you will bear the financial responsibility?

See thats the wonder of being a lawyer these days - you dont get to have
mere mortal opinions anymore, not when you assert them as more than simple
fact, but rather as the fact.

So which is it big guy. Tell us all will ya?

> I'd be mildly curious to learn at what law school you
> acquired this view, or which non-US (or non-Earth?) legal system you are
> referring to with your assurance.

Mars' no doubt, eh?

> > > A. Michael Frocking   |    Professor of Law    |   [e-mail]
> > > U. Miami School of Law, P.O. Box 248087, Coral Gables, FL 33124 USA
> > > [phone]  |  [phone] (fax)  |  http://www.law.tm
> > >                         -->It's hot here.<--




Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g4FGKx700601 for ietf-pkix-bks; Wed, 15 May 2002 09:20:59 -0700 (PDT)
Received: from odin2.bull.net (odin2.bull.net [192.90.70.84]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g4FGKwL00597 for <[e-mail]>; Wed, 15 May 2002 09:20:58 -0700 (PDT)
Received: from lvn-m002.frlv.bull.fr (lvn-m002.frlv.bull.fr [129.184.62.72]) by odin2.bull.net (8.9.3/8.9.3) with ESMTP id SAA24746; Wed, 15 May 2002 18:24:07 +0200
Received: from bull.net ([129.184.37.97]) by lvn-m002.frlv.bull.fr (Lotus Domino Release 5.0.8) with ESMTP id 2002051518202420:360 ; Wed, 15 May 2002 18:20:24 +0200 
Message-ID: <[e-mail]>
Date: Wed, 15 May 2002 18:19:09 +0200
From: Denis Pinkas <[e-mail]>
Organization: Bull SA.
X-Mailer: Mozilla 4.7 [fr] (Win98; I)
X-Accept-Language: fr
MIME-Version: 1.0
To: pkix <[e-mail]>
Subject: Re: Meaning of Non-repudiation
References: <[e-mail]>
X-MIMETrack: Itemize by SMTP Server on LVN-M002/FR/BULL(Release 5.0.8 |June 18, 2001) at 15/05/2002 18:20:24, Serialize by Router on LVN-M002/FR/BULL(Release 5.0.8 |June 18, 2001) at 15/05/2002 18:20:56, Serialize complete at 15/05/2002 18:20:56
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id g4FGKxL00598
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

After taking a few days off, I have analyzed the storm of the e-mail
exchanges on that topic.

The core of the problem is that some people, by claiming requesting some
"clarifications" on these two bits, would like to change their semantics.  

:-(

The roadmap provides a good summary of what happened in the past:

   (...) many discussions were needed to arrive at
   a common agreement on the meaning of the digitalSignature (DS bit)
   and nonRepudiation (NR bit) bits and when they should be set. The
   group quickly realized that key usage extension mixes services and
   mechanisms. The DS bit indicates a mechanism - a public key used to
   verify a digital signature. The NR bit indicates a service - a public
   key used to verify a digital signature and to provide a non-
   repudiation service. When trying to indicate when each bit should be
   indicated arguments were based on:

   The lifetime of the object being singed. Some felt that the DS bit
   should be set when the certificate is used to sign ephemeral objects
   (e.g., bind tokens) while the NR bit should be set for things that
   are survive longer (e.g., documents). Of course, the problem with
   this distinction to determine how long is the time period for
   ephemeral?

   A conscious act taken by the signer. Many felt that the NR bit should
   be set only when the subject has expressly acknowledged that they
   want to use the private key to sign an object. Signing a document say
   where there is a conscious decision by the subject would be
   appropriate for the key usage extension to contain NR, but when the
   key is used for authentication purposes, which can occur
   automatically and more frequently, the DS bit is more appropriate.

   The discussion also concluded that since some authentication schemes
   occur automatically, that the DS bit and NR bit should never be set
   together in the same certificate. Some agreed to the differentiation
   of the bits based on the time, but did not agree that the two could
   not be in the same key usage extension.

   The procedures followed by the CA. Some felt that NR bit was kind of
   'quality mark' indicating to the verifier that the verifier could be
   assured that the CA is implementing appropriate procedures for
   checking the subject's identity, performing certificate archival,
   etc. Other felt that it was not entirely the CAs job and that some
   other entity must be involved.

   In the end the WG agreed to a few things:

   - Provision of the service of non-repudiation requires more than a
     single bit set in a PKC. It requires an entire infrastructure of
     components to preserve for some period of time the keys, PKCs,
     revocation status, signed material, etc., as well as a trusted
     source of time. However, the nonRepudiation key usage bit is
     provided as an indicator that such keys could be used as a
     component of a system providing a non-repudiation service.

   - The certificate policy is the appropriate place to indicate the
     permitted combinations of key usages. That is, a policy may
     indicate that the DS and NR bits can not be set in the same
     certificate while another may say that the DS and NR bits can be
     set in the same certificate.

   [2459bis] includes new text indicating the above agreements.

In addition to these explanations I would like to quickly reply to Sharon to
say her that I disagree (as others) when she says that the only meaning of
the NR bit is to say that the CA has no knowledge of the value of the
private key. This would rule out CAs generating key pairs and would not be
backward compatible with the current meaning.

Now let us attempt to CLARIFY the meaning.

David Kemp offered good explanations on these two bits:

DS bit: the key is used to sign data, nonces or challenges that can be
verified in real-time (entity authentication and data origin authentication
services).

NR bit: the key is used to sign data that can be verified at a later time 
(non–repudiation service).

I would offer these additional explanations:

When the DS bit (bit 0) is set, this means that the private key MAY have
been used in an environment that is not fully controlled by the private key
holder. In practice, this means that private keys related to certificates
that have the DS bit set, will be used for entity authentication (e.g.
signing challenges or nonces) or for data origin authentication (signing
data that has not necessarily been reviewed).

Since the environment is not fully controlled by the private key holder, the
private key holder COULD deny that his key was used to sign a transaction,
because he could claim that he was believing that his private key was used
in an authentication process. 

Some authorities (like CRL Issuers) can sign by using a key related to a
certificate that only has the DS bit set because they always chose what they
sign and will never use that same key in an authentication exchange. 


When the NR bit (bit 1) is set, this means that the private key holder will
only use its private key in an environment that he can control and which
allows him to be confident of the data that is being effectively signed.

The signer cannot claim that he was believing that his private key was
simply used in an authentication process that he could not control. 

Denis


Received: by above.proper.com (8.11.6/8.11.3) id g4F8KJK29370 for ietf-pkix-bks; Wed, 15 May 2002 01:20:19 -0700 (PDT)
Received: from kftc.or.kr ([210.103.193.1]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g4F8KIL29357 for <[e-mail]>; Wed, 15 May 2002 01:20:18 -0700 (PDT)
Received: from LocalHost ([203.233.91.243]) by kftc.or.kr (8.10.0/8.10.0) with SMTP id g4F8HaP27538 for <[e-mail]>; Wed, 15 May 2002 17:17:36 +0900 (KST)
Message-ID: <007401c1fbe9$b47bd290$f35be9cb@LocalHost>
From: "Joong Hyo Oh" <[e-mail]>
To: <[e-mail]>
Subject: sorry, test
Date: Wed, 15 May 2002 17:22:46 +0900
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_0071_01C1FC35.21412BF0"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.50.4522.1200
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

This is a multi-part message in MIME format.

------=_NextPart_000_0071_01C1FC35.21412BF0
Content-Type: text/plain;
	charset="ks_c_5601-1987"
Content-Transfer-Encoding: base64

c29ycnkNCg==

------=_NextPart_000_0071_01C1FC35.21412BF0
Content-Type: text/html;
	charset="ks_c_5601-1987"
Content-Transfer-Encoding: base64

PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDQuMCBUcmFuc2l0aW9uYWwv
L0VOIj4NCjxIVE1MPjxIRUFEPg0KPE1FVEEgY29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PWtz
X2NfNTYwMS0xOTg3IiBodHRwLWVxdWl2PUNvbnRlbnQtVHlwZT48QkFTRSANCmhyZWY9ImZpbGU6
Ly9DOlxQcm9ncmFtIEZpbGVzXENvbW1vbiBGaWxlc1xNaWNyb3NvZnQgU2hhcmVkXFN0YXRpb25l
cnlcIj4NCjxTVFlMRT48L1NUWUxFPg0KDQo8TUVUQSBjb250ZW50PSJNU0hUTUwgNS4wMC4zMzE1
LjI4NzAiIG5hbWU9R0VORVJBVE9SPjwvSEVBRD4NCjxCT0RZIGJhY2tncm91bmQ9IiI+DQo8RElW
PnNvcnJ5PC9ESVY+PC9CT0RZPjwvSFRNTD4NCg==

------=_NextPart_000_0071_01C1FC35.21412BF0--



Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g4F82wG25483 for ietf-pkix-bks; Wed, 15 May 2002 01:02:58 -0700 (PDT)
Received: from hotmail.com (f213.law15.hotmail.com [64.4.23.213]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g4F82vL25478 for <[e-mail]>; Wed, 15 May 2002 01:02:57 -0700 (PDT)
Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Wed, 15 May 2002 01:02:53 -0700
Received: from 203.233.91.243 by lw15fd.law15.hotmail.msn.com with HTTP; Wed, 15 May 2002 08:02:52 GMT
X-Originating-IP: [203.233.91.243]
From: "O JH" <[e-mail]>
To: [e-mail]
Subject: question about private key hash value
Date: Wed, 15 May 2002 08:02:52 +0000
Mime-Version: 1.0
Content-Type: text/plain; charset=ks_c_5601-1987; format=flowed
Message-ID: <[e-mail]>
X-OriginalArrivalTime: 15 May 2002 08:02:53.0277 (UTC) FILETIME=[EA2A38D0:01C1FBE6]
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Hello

With the hash value of a subject(or user)¡¯s private key, I am trying to 
identify the each user.

As the hash value of a user's private key is transferred to application 
server(e.g. shopping mall), it is possible for someone to get it.

In this case, I wonder if the security of private key would not be 
effected.

Could somebody give me some advice?

Thank you for your time.

Regards





_________________________________________________________________
MSN Explorer°¡ ÀÖÀ¸¸é Hotmail »ç¿ëÀÌ ÈξÀ Æí¸®ÇØ Áý´Ï´Ù. Áö±Ý 
http://explorer.msn.co.kr/ ¿¡¼­ ¹«·á·Î ´Ù¿î·ÎµåÇϼ¼¿ä.



Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g4F7iMp22849 for ietf-pkix-bks; Wed, 15 May 2002 00:44:22 -0700 (PDT)
Received: from hotmail.com (f108.law15.hotmail.com [64.4.23.108]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g4F7iLL22842 for <[e-mail]>; Wed, 15 May 2002 00:44:21 -0700 (PDT)
Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Wed, 15 May 2002 00:44:17 -0700
Received: from 203.233.91.243 by lw15fd.law15.hotmail.msn.com with HTTP; Wed, 15 May 2002 07:44:16 GMT
X-Originating-IP: [203.233.91.243]
From: "O JH" <[e-mail]>
To: [e-mail]
Subject: question about private key hash value
Date: Wed, 15 May 2002 07:44:16 +0000
Mime-Version: 1.0
Content-Type: text/plain; charset=ks_c_5601-1987; format=flowed
Message-ID: <[e-mail]>
X-OriginalArrivalTime: 15 May 2002 07:44:17.0051 (UTC) FILETIME=[50D7A6B0:01C1FBE4]
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Hello

With the hash value of a subject(or user)¡¯s private key, I am trying to 
identify the each user.

As the hash value of a user's private key is transferred to application 
server(e.g. shopping mall), it is possible for someone to get it.

In this case, I wonder if the security of private key would not be 
effected.

Could somebody give me some advice?

Thank you for your time.

Regards



_________________________________________________________________
MSN Explorer°¡ ÀÖÀ¸¸é Hotmail »ç¿ëÀÌ ÈξÀ Æí¸®ÇØ Áý´Ï´Ù. Áö±Ý 
http://explorer.msn.co.kr/ ¿¡¼­ ¹«·á·Î ´Ù¿î·ÎµåÇϼ¼¿ä.



Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g4F7cJ721425 for ietf-pkix-bks; Wed, 15 May 2002 00:38:19 -0700 (PDT)
Received: from hotmail.com (f211.law15.hotmail.com [64.4.23.211]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g4F7cIL21418 for <[e-mail]>; Wed, 15 May 2002 00:38:18 -0700 (PDT)
Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Wed, 15 May 2002 00:38:13 -0700
Received: from 203.233.91.243 by lw15fd.law15.hotmail.msn.com with HTTP; Wed, 15 May 2002 07:38:13 GMT
X-Originating-IP: [203.233.91.243]
From: "O JH" <[e-mail]>
To: [e-mail]
Subject: question about private key hash value
Date: Wed, 15 May 2002 07:38:13 +0000
Mime-Version: 1.0
Content-Type: text/plain; charset=ks_c_5601-1987; format=flowed
Message-ID: <[e-mail]>
X-OriginalArrivalTime: 15 May 2002 07:38:13.0660 (UTC) FILETIME=[783E95C0:01C1FBE3]
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Hello

With the hash value of a subject(or user)¡¯s private key, I am trying to 
identify the each user.

As the hash value of a user's private key is transferred to application 
server(e.g. shopping mall), it is possible for someone to get it.

In this case, I wonder if the security of private key would not be 
effected.

Could somebody give me some advice?

Thank you for your time.

Regards



_________________________________________________________________
http://messenger.msn.co.kr¿¡¼­ MSN Messenger¸¦ ´Ù¿î·ÎµåÇÏ¿© ¿Â¶óÀÎ »ó¿¡ ÀÖ´Â
 Ä£±¸¿Í ´ëÈ­¸¦ ³ª´©¼¼¿ä.



Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g4EEul407634 for ietf-pkix-bks; Tue, 14 May 2002 07:56:47 -0700 (PDT)
Received: from cmailg3.svr.pol.co.uk (cmailg3.svr.pol.co.uk [195.92.195.173]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g4EEukL07629 for <[e-mail]>; Tue, 14 May 2002 07:56:46 -0700 (PDT)
Received: from modem-2328.llama.dialup.pol.co.uk ([217.135.185.24] helo=badger) by cmailg3.svr.pol.co.uk with smtp (Exim 3.35 #1) id 177djF-0004rQ-00; Tue, 14 May 2002 15:56:41 +0100
From: "Dean Adams" <[e-mail]>
To: "Mike Rowan" <[e-mail]>, "'Richard Culshaw '" <[e-mail]>, "'Ietf-Pkix \(E-mail\) '" <[e-mail]>
Subject: RE: where should email address go?
Date: Tue, 14 May 2002 15:56:34 +0100
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.2911.0)
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200
Importance: Normal
In-Reply-To: <[e-mail]>
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Hi Mike
> If you read my comments more closely, this is exactly what I said.

OK - re-read more carefully this time. mea culpa

>
> -----Original Message-----
> From: Dean Adams [mailto:[e-mail]]
> Sent: Tuesday, May 14, 2002 4:06 AM
> To: Mike Rowan; 'Richard Culshaw '; 'Ietf-Pkix (E-mail) '
> Subject: RE: where should email address go?
>
>
> Hi,
> 	Er - it was my understanding that it was actually the other way
> around,
> i.e. legacy apps may continue to place email addresses in the Subject DN,
> but that new apps are encouraged to use subjectAltName.
>
> For instance RFC2632 (S/MIME v3 certificate handling) states:
> End-entity certificates MAY contain an Internet mail address as
> described in
> [RFC-822]. The address must be an "addr-spec" as defined in Section 6.1 of
> that specification.  The email address SHOULD be in the subjectAltName
> extension, and SHOULD NOT be in the subject distinguished name.
>
> I believe, (though cannot find the reference at the moment) that Microsoft
> email apps (surely these being reasonably prevalent leagacy apps) have
> documented their position as previously using Subject DN for email
> addresses, but that they now recommend subjectAltName, and have
> stated that
> support for email addresses Subject DN in some future version may be
> dropped.
>
> 	Dean
>
> ____________________________________________________________
> Dean Adams               mobile:         [phone]
> Trustis Limited          Direct Tel/Fax: [phone]
> 49 Whitehall             Office Tel:     [phone]
> London SW1A 2BX          Office Fax:     [phone]
> email: [e-mail]    Web: http://www.trustis.com
> ____________________________________________________________
> The information in this message is confidential.  It is intended
> solely for
> the addressee.  Access to this message by anyone else is unauthorised.  If
> you are not the intended recipient, any disclosure, copying,
> distribution or
> any action taken or omitted to be taken in reliance on it, is
> prohibited and
> may be unlawful.
>
> Any attachments to this message have been checked for viruses, but please
> rely on your own virus checker and procedures.
>
> If you contact us by e-mail, we may store your name and address to
> facilitate communications.
>
>
> > -----Original Message-----
> > From: [e-mail]
> > [mailto:[e-mail]]On Behalf Of Mike Rowan
> > Sent: 14 May 2002 06:13
> > To: 'Richard Culshaw '; 'Ietf-Pkix (E-mail) '
> > Subject: RE: where should email address go?
> >
> >
> >
> > Richard:
> >
> > You are correct in that only some legacy apps use the RFC822Name
> > in the SAN.
> > Your best bet is to place this in both Subject DN and the SAN, unless of
> > cource you can be sure of your application usage.  Still it would be
> > limiting, by placing this in both you are sure to meet most
> needs.  There
> > may be a possiblity of a partiular legacy app having issues with
> > SAN values,
> > although I have not seen this as of yet.
> >
> > - Michael Rowan
> >   GeoTrust, Inc.
> >
> > -----Original Message-----
> > From: Richard Culshaw
> > To: Ietf-Pkix (E-mail)
> > Sent: 5/13/02 10:56 PM
> > Subject: where should email address go?
> >
> >
> >
> > Hi all,
> >
> > a quick question for the group...
> >
> > what is the best place to put an email address value in an client
> > certificate
> > in the E field of the Subject DN eg:
> > E = [e-mail]
> >
> > or
> > in the Subject Alt Name Extenstion eg:
> > RFC822 Name=[e-mail]
> >
> > my understanding is that only some legacy applications use the Subject
> > Alt
> > Name extension and just about all the client software out there looks in
> > the
> > Subject DN for the email address?
> >
> >  what about placing it in both fields???
> >
> > thanks in advance....
> >
> >
> >
> >
> > Richard Culshaw
> >
>



Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g4EElhM07306 for ietf-pkix-bks; Tue, 14 May 2002 07:47:43 -0700 (PDT)
Received: from mail1.ma.certco.com (owa.certco.com [208.222.33.16]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g4EElfL07302 for <[e-mail]>; Tue, 14 May 2002 07:47:41 -0700 (PDT)
X-MIMEOLE: Produced By Microsoft Exchange V6.0.5762.3
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Subject: RE: where should email address go?
Date: Tue, 14 May 2002 09:41:57 -0400
Message-ID: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: where should email address go?
Thread-Index: AcH7JdEs/Sfx+Xq5R6WbpKAAkbX/fAAJlpW4
From: "Harrington, Chris" <[e-mail]>
To: "Dean Adams" <[e-mail]>, "Mike Rowan" <[e-mail]>, "Richard Culshaw " <[e-mail]>, "Ietf-Pkix (E-mail) " <[e-mail]>
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from base64 to 8bit by above.proper.com id g4EElgL07303
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

I also thought it was the other way around. SAN gives some consistency to where the e-mail address is placed. Having the e-mail the DN can cause interop issues. We ran into a problem where some CA's placed the e-mail at the beginning of the DN (email= [e-mail] <mailto:[e-mail]>  , CN= My cert) with most placing it at the end (CN=My cert, email= [e-mail] <mailto:[e-mail]> ). This can cause issues when you try to look up a certificate in a directory or enumerate them from a certificate store.

 

Cheers,

 

Chris

 

-----Original Message----- 
From: Dean Adams [mailto:[e-mail]] 
Sent: Tue 5/14/2002 4:06 AM 
To: Mike Rowan; 'Richard Culshaw '; 'Ietf-Pkix (E-mail) ' 
Cc: 
Subject: RE: where should email address go?




	Hi,
	        Er - it was my understanding that it was actually the other way around,
	i.e. legacy apps may continue to place email addresses in the Subject DN,
	but that new apps are encouraged to use subjectAltName.
	
	For instance RFC2632 (S/MIME v3 certificate handling) states:
	End-entity certificates MAY contain an Internet mail address as described in
	[RFC-822]. The address must be an "addr-spec" as defined in Section 6.1 of
	that specification.  The email address SHOULD be in the subjectAltName
	extension, and SHOULD NOT be in the subject distinguished name.
	
	I believe, (though cannot find the reference at the moment) that Microsoft
	email apps (surely these being reasonably prevalent leagacy apps) have
	documented their position as previously using Subject DN for email
	addresses, but that they now recommend subjectAltName, and have stated that
	support for email addresses Subject DN in some future version may be
	dropped.
	
	        Dean
	
	____________________________________________________________
	Dean Adams               mobile:         [phone]
	Trustis Limited          Direct Tel/Fax: [phone]
	49 Whitehall             Office Tel:     [phone]
	London SW1A 2BX          Office Fax:     [phone]
	email: [e-mail]    Web: http://www.trustis.com
	____________________________________________________________
	The information in this message is confidential.  It is intended solely for
	the addressee.  Access to this message by anyone else is unauthorised.  If
	you are not the intended recipient, any disclosure, copying, distribution or
	any action taken or omitted to be taken in reliance on it, is prohibited and
	may be unlawful.
	
	Any attachments to this message have been checked for viruses, but please
	rely on your own virus checker and procedures.
	
	If you contact us by e-mail, we may store your name and address to
	facilitate communications.
	
	
	> -----Original Message-----
	> From: [e-mail]
	> [mailto:[e-mail]]On Behalf Of Mike Rowan
	> Sent: 14 May 2002 06:13
	> To: 'Richard Culshaw '; 'Ietf-Pkix (E-mail) '
	> Subject: RE: where should email address go?
	>
	>
	>
	> Richard:
	>
	> You are correct in that only some legacy apps use the RFC822Name
	> in the SAN.
	> Your best bet is to place this in both Subject DN and the SAN, unless of
	> cource you can be sure of your application usage.  Still it would be
	> limiting, by placing this in both you are sure to meet most needs.  There
	> may be a possiblity of a partiular legacy app having issues with
	> SAN values,
	> although I have not seen this as of yet.
	>
	> - Michael Rowan
	>   GeoTrust, Inc.
	>
	> -----Original Message-----
	> From: Richard Culshaw
	> To: Ietf-Pkix (E-mail)
	> Sent: 5/13/02 10:56 PM
	> Subject: where should email address go?
	>
	>
	>
	> Hi all,
	>
	> a quick question for the group...
	>
	> what is the best place to put an email address value in an client
	> certificate
	> in the E field of the Subject DN eg:
	> E = [e-mail]
	>
	> or
	> in the Subject Alt Name Extenstion eg:
	> RFC822 Name=[e-mail]
	>
	> my understanding is that only some legacy applications use the Subject
	> Alt
	> Name extension and just about all the client software out there looks in
	> the
	> Subject DN for the email address?
	>
	>  what about placing it in both fields???
	>
	> thanks in advance....
	>
	>
	>
	>
	> Richard Culshaw
	>
	
	



Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g4EDZ0903879 for ietf-pkix-bks; Tue, 14 May 2002 06:35:00 -0700 (PDT)
Received: from bosgeo2.geotrust.com (bosgeo2.geotrust.com [208.59.15.50]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g4EDYxL03875 for <[e-mail]>; Tue, 14 May 2002 06:34:59 -0700 (PDT)
Received: by bosgeo2.boston.geotrust.com with Internet Mail Service (5.5.2650.21) id <JQBVZWF7>; Tue, 14 May 2002 09:34:49 -0400
Message-ID: <[e-mail]>
From: Mike Rowan <[e-mail]>
To: "'Dean Adams'" <[e-mail]>, Mike Rowan <[e-mail]>, "'Richard Culshaw '" <[e-mail]>, "'Ietf-Pkix (E-mail) '" <[e-mail]>
Subject: RE: where should email address go?
Date: Tue, 14 May 2002 09:34:48 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id g4EDYxL03876
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

If you read my comments more closely, this is exactly what I said.

-----Original Message-----
From: Dean Adams [mailto:[e-mail]]
Sent: Tuesday, May 14, 2002 4:06 AM
To: Mike Rowan; 'Richard Culshaw '; 'Ietf-Pkix (E-mail) '
Subject: RE: where should email address go?


Hi,
	Er - it was my understanding that it was actually the other way
around,
i.e. legacy apps may continue to place email addresses in the Subject DN,
but that new apps are encouraged to use subjectAltName.

For instance RFC2632 (S/MIME v3 certificate handling) states:
End-entity certificates MAY contain an Internet mail address as described in
[RFC-822]. The address must be an "addr-spec" as defined in Section 6.1 of
that specification.  The email address SHOULD be in the subjectAltName
extension, and SHOULD NOT be in the subject distinguished name.

I believe, (though cannot find the reference at the moment) that Microsoft
email apps (surely these being reasonably prevalent leagacy apps) have
documented their position as previously using Subject DN for email
addresses, but that they now recommend subjectAltName, and have stated that
support for email addresses Subject DN in some future version may be
dropped.

	Dean

____________________________________________________________
Dean Adams               mobile:         [phone]
Trustis Limited          Direct Tel/Fax: [phone]
49 Whitehall             Office Tel:     [phone]
London SW1A 2BX          Office Fax:     [phone]
email: [e-mail]    Web: http://www.trustis.com
____________________________________________________________
The information in this message is confidential.  It is intended solely for
the addressee.  Access to this message by anyone else is unauthorised.  If
you are not the intended recipient, any disclosure, copying, distribution or
any action taken or omitted to be taken in reliance on it, is prohibited and
may be unlawful.

Any attachments to this message have been checked for viruses, but please
rely on your own virus checker and procedures.

If you contact us by e-mail, we may store your name and address to
facilitate communications.


> -----Original Message-----
> From: [e-mail]
> [mailto:[e-mail]]On Behalf Of Mike Rowan
> Sent: 14 May 2002 06:13
> To: 'Richard Culshaw '; 'Ietf-Pkix (E-mail) '
> Subject: RE: where should email address go?
>
>
>
> Richard:
>
> You are correct in that only some legacy apps use the RFC822Name
> in the SAN.
> Your best bet is to place this in both Subject DN and the SAN, unless of
> cource you can be sure of your application usage.  Still it would be
> limiting, by placing this in both you are sure to meet most needs.  There
> may be a possiblity of a partiular legacy app having issues with
> SAN values,
> although I have not seen this as of yet.
>
> - Michael Rowan
>   GeoTrust, Inc.
>
> -----Original Message-----
> From: Richard Culshaw
> To: Ietf-Pkix (E-mail)
> Sent: 5/13/02 10:56 PM
> Subject: where should email address go?
>
>
>
> Hi all,
>
> a quick question for the group...
>
> what is the best place to put an email address value in an client
> certificate
> in the E field of the Subject DN eg:
> E = [e-mail]
>
> or
> in the Subject Alt Name Extenstion eg:
> RFC822 Name=[e-mail]
>
> my understanding is that only some legacy applications use the Subject
> Alt
> Name extension and just about all the client software out there looks in
> the
> Subject DN for the email address?
>
>  what about placing it in both fields???
>
> thanks in advance....
>
>
>
>
> Richard Culshaw
>


Received: by above.proper.com (8.11.6/8.11.3) id g4EDHKB03348 for ietf-pkix-bks; Tue, 14 May 2002 06:17:20 -0700 (PDT)
Received: from vulcan.rsasecurity.com (mail.rsasecurity.com [204.167.114.123]) by above.proper.com (8.11.6/8.11.3) with SMTP id g4EDHIL03340 for <[e-mail]>; Tue, 14 May 2002 06:17:18 -0700 (PDT)
Received: from no.name.available by vulcan.rsasecurity.com via smtpd (for mail.imc.org [208.184.76.43]) with SMTP; 14 May 2002 13:15:39 UT
Received: from ebola.securitydynamics.com (ebola.securid.com [192.80.211.4]) by sdtihq24.securid.com (Pro-8.9.3/Pro-8.9.3) with ESMTP id JAA04927 for <[e-mail]>; Tue, 14 May 2002 09:17:18 -0400 (EDT)
Received: from exna00.securitydynamics.com (localhost [127.0.0.1]) by ebola.securitydynamics.com (8.10.2+Sun/8.10.2) with ESMTP id g4EDFRO28053 for <[e-mail]>; Tue, 14 May 2002 09:15:27 -0400 (EDT)
Received: by exna00.securitydynamics.com with Internet Mail Service (5.5.2653.19) id <K2ZLBX2F>; Tue, 14 May 2002 09:17:16 -0400
Received: from HOUSLEY-LAP.rsasecurity.com (HOUSLEY-LAP [10.3.16.143]) by exna00.securitydynamics.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id K2ZLBX2D; Tue, 14 May 2002 09:17:11 -0400
From: "Housley, Russ" <[e-mail]>
To: Richard Culshaw <[e-mail]>
Cc: "Ietf-Pkix (E-mail)" <[e-mail]>
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Version 5.1
Date: Tue, 14 May 2002 09:17:06 -0400
Subject: Re: where should email address go?
In-Reply-To: <FA4D9B37FE63D611858C00C00D016FCD0E0389@esmcex01>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Richard:

Please take a look at the last few paragraphs of section 4.1.2.6 in RFC 3280.

Russ


At 12:56 PM 5/14/2002 +1000, Richard Culshaw wrote:


>Hi all,
>
>a quick question for the group...
>
>what is the best place to put an email address value in an client
>certificate
>in the E field of the Subject DN eg:
>E = [e-mail]
>
>or
>in the Subject Alt Name Extenstion eg:
>RFC822 Name=[e-mail]
>
>my understanding is that only some legacy applications use the Subject Alt
>Name extension and just about all the client software out there looks in the
>Subject DN for the email address?
>
>  what about placing it in both fields???
>
>thanks in advance....
>
>
>
>
>Richard Culshaw


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g4E9o2e16839 for ietf-pkix-bks; Tue, 14 May 2002 02:50:02 -0700 (PDT)
Received: from sentosa.post1.com (sentosa.post1.com [202.27.17.100]) by above.proper.com (8.11.6/8.11.3) with SMTP id g4E9o0L16832 for <[e-mail]>; Tue, 14 May 2002 02:50:00 -0700 (PDT)
Received: (qmail 32113 invoked from network); 14 May 2002 09:53:29 -0000
Received: from bb-203-125-7-219.singnet.com.sg (HELO JAMESSONYVAIO) (203.125.7.219) by sentosa.post1.com with SMTP; 14 May 2002 09:53:29 -0000
Message-ID: <005701c1fb2c$aee17af0$2500a8c0@JAMESSONYVAIO>
From: "James Seng" <[e-mail]>
To: "todd glassey" <[e-mail]>, "Michael Froomkin - U.Miami School of Law" <[e-mail]>
Cc: "PKIX-IETF" <[e-mail]>, "LISTS - IETF-IESG" <[e-mail]>, <[e-mail]>
References: <[e-mail]> <046b01c1faae$b20155d0$020aff0a@tsg1>
Subject: Re: Open issue: requester identifier in DPV response
Date: Tue, 14 May 2002 17:49:46 +0800
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2600.0000
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Yes, thank god.

-James Seng

> The bottom line is that these IP issues and the Antitrust issues are real,
> from my opinion and as such actionable. Thank god I don't have a license
to
> practice law or I would go bonkers filing against these folks...
>
> Todd
>
> ----- Original Message -----
> From: "Michael Froomkin - U.Miami School of Law" <[e-mail]>
> To: "todd glassey" <[e-mail]>
> Cc: "PKIX-IETF" <[e-mail]>; "LISTS - IETF-IESG" <[e-mail]>;
> <[e-mail]>
> Sent: Wednesday, May 08, 2002 6:37 PM
> Subject: Re: Open issue: requester identifier in DPV response
>
>
> >
> > Merely having a bias, even one that hurts someone, is not a violation of
> > US (or, insofar as I understand it, EU) anti-trust/competition law.
> >
> > Oversimplifying slightly, in order to find an offense, you would have to
> > show concerted action, by a person or persons with a financial interest,
> > against one or more competitors.
> >
> > Generally speaking, and again oversimplifying, valid technical grounds
is
> > a defense against many if not most otherwise valid claims of abuse of
> > standard making.
> >
> > You will find a less simplistic discussion of these issues, in the
context
> > of US law and ICANN-as-a=standards-body, in an article I am co-authoring
> > with Mark Lemely, a leading antitrust authority.  A copy of the working
> > draft is here:
> > http://personal.law.miami.edu/~froomkin/articles/icann-antitrust.pdf
> >
> > The statement in your last 3.5 lines of the post quoted below is false
as
> > a matter of US law.  I'd be mildly curious to learn at what law school
you
> > acquired this view, or which non-US (or non-Earth?) legal system you are
> > referring to with your assurance.
> >
> > On Wed, 8 May 2002, todd glassey wrote:
> >
> > > Michael restraint of trade is actionable. refusing to allow any effort
> to
> > > pass without a definition of the formal processes to be applied to all
> > > submissions, i.e. how the IETF  is setup today, leaves the entirety to
> the
> > > WG Chairs and their AD's and that it the problem and I assure you that
> if it
> > > can be demonstrated to any level that anyone in a standards
organization
> > > gave undue advantage to one protocol over an other and anyone suffered
a
> > > financial loss because of this act, that this is assuredly actionable.
> > >
> > > Todd
> > >
> > > ----- Original Message -----
> > > From: "Michael Froomkin - U.Miami School of Law"
> <[e-mail]>
> > > To: "todd glassey" <[e-mail]>
> > > Cc: "PKIX-IETF" <[e-mail]>; "LISTS - IETF-IESG"
> <[e-mail]>;
> > > <[e-mail]>
> > > Sent: Monday, April 29, 2002 8:10 PM
> > > Subject: Re: Open issue: requester identifier in DPV response
> > >
> > >
> > > > "Actionable"?  I rather doubt it.  At least not in the US, and not
> without
> > > > many aggravating circumstances.
> > > >
> > > > On Sat, 27 Apr 2002, todd glassey wrote:
> > > >
> > > > > Stephen - I think that it is very likely that ANY involvement by a
> WG
> > > Chair
> > > > > in ANY protocol at any level is a conflict of interest and
> actionable as
> > > > > such. It shows a predudicial predisposition towards that protocol
> and
> > > favors
> > > > > it over all others. This is why I am demanding the rewriting of
the
> WG's
> > > > > charter as well as the approriate sections of RFC2026 et al..
> > > > >
> > > > [....]
> > > > --
> > > > Please visit http://www.icannwatch.org
> > > >
> > > > A. Michael Froomkin   |    Professor of Law    |   [e-mail]
> > > > U. Miami School of Law, P.O. Box 248087, Coral Gables, FL 33124 USA
> > > > [phone]  |  [phone] (fax)  |  http://www.law.tm
> > > >                         -->It's hot here.<--
> > > >
> > >
> > >
> >
> > --
> > Please visit http://www.icannwatch.org
> > A. Michael Froomkin   |    Professor of Law    |   [e-mail]
> > U. Miami School of Law, P.O. Box 248087, Coral Gables, FL 33124 USA
> > [phone]  |  [phone] (fax)  |  http://www.law.tm
> >                         -->It's hot here.<--
> >
>
>
>
>



Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g4E8Vjj11992 for ietf-pkix-bks; Tue, 14 May 2002 01:31:45 -0700 (PDT)
Received: from imailg2.svr.pol.co.uk (imailg2.svr.pol.co.uk [195.92.195.180]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g4E8ViL11980 for <[e-mail]>; Tue, 14 May 2002 01:31:44 -0700 (PDT)
Received: from modem-1426.lion.dialup.pol.co.uk ([217.135.165.146] helo=badger) by imailg2.svr.pol.co.uk with smtp (Exim 3.35 #1) id 177Xie-0005wI-00; Tue, 14 May 2002 09:31:40 +0100
From: "Dean Adams" <[e-mail]>
To: "Peter Gutmann" <[e-mail]>, <[e-mail]>, <[e-mail]>
Subject: RE: IBM alternative to PKI?
Date: Tue, 14 May 2002 09:31:34 +0100
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.2911.0)
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200
Importance: Normal
In-Reply-To: <[e-mail]>
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Thanks Peter,
	It was this sort of question that I really intended. Apologies for being so
vague.

Your theories may be correct on how this has been invented and put forward
to the UK government.  My understanding is that a UK IBM'er (Peter Dare) may
have proposed this new PKI alternative.
Any IBM'ers out there who can comment - provide further detail on this
model?


> -----Original Message-----
> From: Peter Gutmann [mailto:[e-mail]]
> Sent: 14 May 2002 08:41
> To: [e-mail]; [e-mail]; [e-mail]
> Subject: Re: IBM alternative to PKI?
>
>
> "Anders Rundgren" <[e-mail]> writes:
>
> >I do not know anything of e-Envoy but I do know a few things
> concerning PKI
> >and smart cards.  There are indeed commercial problems
> associated with smart
> >cards.  But does it get better by introducing yet another type
> of card and
> >credentials?
>
> Does anyone know exactly what this new solution is?  With the
> size of IBM, the
> news story could quite easily translate into "Some random corner
> of IBM, under
> the impression that another far-flung corner of said company had
> something cool
> to offer, have tried to sell said something to the UK government,
> and are now
> frantically trying to find out what it is they've sold them".
>
> (I've seen some research papers on an XML-based PKI-avoiding
> system which might
> fit the bill, but who knows what the story is really talking about).
>
> Peter.
>
>
____________________________________________________________
Dean Adams               mobile:         [phone]
Trustis Limited          Direct Tel/Fax: [phone]
49 Whitehall             Office Tel:     [phone]
London SW1A 2BX          Office Fax:     [phone]
email: [e-mail]    Web: http://www.trustis.com
____________________________________________________________
The information in this message is confidential.  It is intended solely for
the addressee.  Access to this message by anyone else is unauthorised.  If
you are not the intended recipient, any disclosure, copying, distribution or
any action taken or omitted to be taken in reliance on it, is prohibited and
may be unlawful.

Any attachments to this message have been checked for viruses, but please
rely on your own virus checker and procedures.

If you contact us by e-mail, we may store your name and address to
facilitate communications.



Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g4E86E504629 for ietf-pkix-bks; Tue, 14 May 2002 01:06:14 -0700 (PDT)
Received: from imailg2.svr.pol.co.uk (imailg2.svr.pol.co.uk [195.92.195.180]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g4E86DL04618 for <[e-mail]>; Tue, 14 May 2002 01:06:13 -0700 (PDT)
Received: from modem-1426.lion.dialup.pol.co.uk ([217.135.165.146] helo=badger) by imailg2.svr.pol.co.uk with smtp (Exim 3.35 #1) id 177XJv-0003GD-00; Tue, 14 May 2002 09:06:08 +0100
From: "Dean Adams" <[e-mail]>
To: "Mike Rowan" <[e-mail]>, "'Richard Culshaw '" <[e-mail]>, "'Ietf-Pkix \(E-mail\) '" <[e-mail]>
Subject: RE: where should email address go?
Date: Tue, 14 May 2002 09:06:05 +0100
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.2911.0)
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200
Importance: Normal
In-Reply-To: <[e-mail]>
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Hi,
	Er - it was my understanding that it was actually the other way around,
i.e. legacy apps may continue to place email addresses in the Subject DN,
but that new apps are encouraged to use subjectAltName.

For instance RFC2632 (S/MIME v3 certificate handling) states:
End-entity certificates MAY contain an Internet mail address as described in
[RFC-822]. The address must be an "addr-spec" as defined in Section 6.1 of
that specification.  The email address SHOULD be in the subjectAltName
extension, and SHOULD NOT be in the subject distinguished name.

I believe, (though cannot find the reference at the moment) that Microsoft
email apps (surely these being reasonably prevalent leagacy apps) have
documented their position as previously using Subject DN for email
addresses, but that they now recommend subjectAltName, and have stated that
support for email addresses Subject DN in some future version may be
dropped.

	Dean

____________________________________________________________
Dean Adams               mobile:         [phone]
Trustis Limited          Direct Tel/Fax: [phone]
49 Whitehall             Office Tel:     [phone]
London SW1A 2BX          Office Fax:     [phone]
email: [e-mail]    Web: http://www.trustis.com
____________________________________________________________
The information in this message is confidential.  It is intended solely for
the addressee.  Access to this message by anyone else is unauthorised.  If
you are not the intended recipient, any disclosure, copying, distribution or
any action taken or omitted to be taken in reliance on it, is prohibited and
may be unlawful.

Any attachments to this message have been checked for viruses, but please
rely on your own virus checker and procedures.

If you contact us by e-mail, we may store your name and address to
facilitate communications.


> -----Original Message-----
> From: [e-mail]
> [mailto:[e-mail]]On Behalf Of Mike Rowan
> Sent: 14 May 2002 06:13
> To: 'Richard Culshaw '; 'Ietf-Pkix (E-mail) '
> Subject: RE: where should email address go?
>
>
>
> Richard:
>
> You are correct in that only some legacy apps use the RFC822Name
> in the SAN.
> Your best bet is to place this in both Subject DN and the SAN, unless of
> cource you can be sure of your application usage.  Still it would be
> limiting, by placing this in both you are sure to meet most needs.  There
> may be a possiblity of a partiular legacy app having issues with
> SAN values,
> although I have not seen this as of yet.
>
> - Michael Rowan
>   GeoTrust, Inc.
>
> -----Original Message-----
> From: Richard Culshaw
> To: Ietf-Pkix (E-mail)
> Sent: 5/13/02 10:56 PM
> Subject: where should email address go?
>
>
>
> Hi all,
>
> a quick question for the group...
>
> what is the best place to put an email address value in an client
> certificate
> in the E field of the Subject DN eg:
> E = [e-mail]
>
> or
> in the Subject Alt Name Extenstion eg:
> RFC822 Name=[e-mail]
>
> my understanding is that only some legacy applications use the Subject
> Alt
> Name extension and just about all the client software out there looks in
> the
> Subject DN for the email address?
>
>  what about placing it in both fields???
>
> thanks in advance....
>
>
>
>
> Richard Culshaw
>



Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g4E7fRg01357 for ietf-pkix-bks; Tue, 14 May 2002 00:41:27 -0700 (PDT)
Received: from hermes.cs.auckland.ac.nz (hermes.cs.auckland.ac.nz [130.216.35.151]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g4E7fPL01347 for <[e-mail]>; Tue, 14 May 2002 00:41:26 -0700 (PDT)
Received: from ruru.cs.auckland.ac.nz (ruru-nfs.cs.auckland.ac.nz [130.216.35.12]) by hermes.cs.auckland.ac.nz (8.12.3/8.12.3) with ESMTP id g4E7fKaq017748; Tue, 14 May 2002 19:41:20 +1200
Received: (from pgut001@localhost) by ruru.cs.auckland.ac.nz (8.9.3/8.8.6/cs-slave) id TAA269827; Tue, 14 May 2002 19:41:18 +1200 (NZST) (sender [e-mail])
Date: Tue, 14 May 2002 19:41:18 +1200 (NZST)
Message-ID: <[e-mail]>
From: [e-mail] (Peter Gutmann)
To: [e-mail], [e-mail], [e-mail]
Subject: Re: IBM alternative to PKI?
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

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

>I do not know anything of e-Envoy but I do know a few things concerning PKI
>and smart cards.  There are indeed commercial problems associated with smart
>cards.  But does it get better by introducing yet another type of card and
>credentials?

Does anyone know exactly what this new solution is?  With the size of IBM, the
news story could quite easily translate into "Some random corner of IBM, under
the impression that another far-flung corner of said company had something cool
to offer, have tried to sell said something to the UK government, and are now
frantically trying to find out what it is they've sold them".

(I've seen some research papers on an XML-based PKI-avoiding system which might
fit the bill, but who knows what the story is really talking about).

Peter.


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g4E73sp24932 for ietf-pkix-bks; Tue, 14 May 2002 00:03:54 -0700 (PDT)
Received: from mail.utfors.se (mail.utfors.se [195.58.103.125]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g4E73lL24924 for <[e-mail]>; Tue, 14 May 2002 00:03:48 -0700 (PDT)
Received: from arport ([62.119.75.13]) by mail.utfors.se (8.8.8/8.8.8) with SMTP id JAA22378; Tue, 14 May 2002 09:03:33 +0200 (MET DST)
Message-ID: <005d01c1fb1d$69948910$0500a8c0@arport>
From: "Anders Rundgren" <[e-mail]>
To: "Dean Adams" <[e-mail]>, <[e-mail]>
References: <[e-mail]>
Subject: Re: IBM alternative to PKI?
Date: Tue, 14 May 2002 10:00:23 +0200
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_0054_01C1FB2E.29CBBD10"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.50.4133.2400
X-MIMEOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

This is a multi-part message in MIME format.

------=_NextPart_000_0054_01C1FB2E.29CBBD10
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Dean,
I do not know anything of e-Envoy but I do know a few things concerning =
PKI and smart cards.  There are indeed commercial problems associated =
with smart cards.  But does it get better by introducing yet another =
type of card and credentials?
=20
A major problem is that the card vendors have pushed "branding" and =
other standards-defying things leading to high costs and low =
interoperability.  Due to this, Windows does AFAIK not support a single =
PKI-card without adding external proprietary SW.  The same goes for all =
other OSes (although the other OSes are usually lagging even the =
proprietary SW).=20
=20
The privacy (or rather "the wrong information to the wrong party") =
problem, nowadays have solutions like OASIS' SAML, and VISA's 3D Secure =
that extends client-PKI by delegation which indeed is "empowerment" in a =
completey distributed on-line fashion.   Such schemes also eliminate the =
need for complex multi-function cards, which is yet another thing that =
has hampered deployment.
=20
A blocker for potential card-buyers is that it is no longer a secret =
that mobile phones are likely to replace the card itself, the only real =
uncertainity is when and how.  When could be relatively soon if the =
phone-makers unite and make the PKI solution independent of the =
subscription solution (i.e. not mixing PKI with the SIM-card in the case =
of GSM).
=20
cheers,
Anders Rundgren
  ----- Original Message -----=20
  From: Dean Adams=20
  To: [e-mail]=20
  Sent: Monday, May 13, 2002 13:36
  Subject: IBM alternative to PKI?


  Hi,
      Does anynone know-of and have comment on this?

  UK plans smarter ID card=20

  The Office of the e-Envoy is looking at alternatives to PKI (public =
key infrastructure) technology for making secure electronic =
transactions. Officials have held talks with supplier IBM to devise a =
new form of electronic ID card intended to avoid the commercial and =
privacy problems associated with PKI technology.=20

  The technology, known as the "empowerment model", could be used both =
in the private and public sectors to authenticate users of electronic =
services, a top IBM executive told Government Computing News.=20


-------------------------------------------------------------------------=
-----
        Dean Adams Mobile: [phone]=20
        Trustis Limited Direct Tel/Fax: [phone]=20
        49 Whitehall Office Tel: [phone]=20
        London SW1A 2BX Office Fax: [phone]=20
        email: [e-mail] Web: http://www.trustis.com=20

  The information in this message is confidential. It is intended solely =
for the addressee. Access to this message by anyone else is =
unauthorised. If you are not the intended recipient, any disclosure, =
copying, distribution or any action taken or omitted to be taken in =
reliance on it, is prohibited and may be unlawful.

  Any attachments to this message have been checked for viruses, but =
please rely on your own virus checker and procedures.

  If you contact us by e-mail, we may store your name and address to =
facilitate communications.=20



------=_NextPart_000_0054_01C1FB2E.29CBBD10
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META content=3D"text/html; charset=3Diso-8859-1" =
http-equiv=3DContent-Type>
<META content=3D"MSHTML 5.00.3103.1000" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV><FONT face=3DArial size=3D2>Dean,</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>I do not know anything of e-Envoy but I =
do know a=20
few things concerning PKI and smart cards.&nbsp; There are indeed =
commercial=20
problems associated with smart cards.&nbsp; But does it get better by=20
introducing yet another type of card and credentials?</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>A major problem is that the card =
vendors have=20
pushed "branding" and other standards-defying things leading to high =
costs and=20
low interoperability.&nbsp; Due to this,&nbsp;Windows does AFAIK not =
support a=20
single PKI-card without&nbsp;adding external proprietary SW.&nbsp; The =
same goes=20
for all other OSes (although the other OSes are usually lagging even the =

proprietary SW).&nbsp;</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>The privacy (or rather "the wrong=20
information&nbsp;to the wrong party") problem, nowadays have solutions =
like=20
OASIS' SAML, and VISA's 3D&nbsp;Secure that extends client-PKI by =
delegation=20
which indeed is "empowerment" in a&nbsp;completey distributed on-line=20
fashion.&nbsp;&nbsp; Such schemes also eliminate the need for complex=20
multi-function cards, which is yet another thing that has hampered=20
deployment.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>A&nbsp;blocker for potential =
card-buyers is that it=20
is no longer a secret that mobile phones&nbsp;are likely to replace the =
card=20
itself, the only real uncertainity is when and how.&nbsp; When could be=20
relatively soon if the phone-makers unite and make the PKI solution =
independent=20
of the subscription solution (i.e. not mixing PKI with the =
SIM-card&nbsp;in the=20
case of GSM).</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>cheers,</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>Anders Rundgren</FONT></DIV>
<BLOCKQUOTE=20
style=3D"BORDER-LEFT: #000000 2px solid; MARGIN-LEFT: 5px; MARGIN-RIGHT: =
0px; PADDING-LEFT: 5px; PADDING-RIGHT: 0px">
  <DIV style=3D"FONT: 10pt arial">----- Original Message ----- </DIV>
  <DIV=20
  style=3D"BACKGROUND: #e4e4e4; FONT: 10pt arial; font-color: =
black"><B>From:</B>=20
  <A href=3D"mailto:[e-mail]" title=[e-mail]>Dean =
Adams</A> </DIV>
  <DIV style=3D"FONT: 10pt arial"><B>To:</B> <A =
href=3D"mailto:[e-mail]"=20
  title=[e-mail]>[e-mail]</A> </DIV>
  <DIV style=3D"FONT: 10pt arial"><B>Sent:</B> Monday, May 13, 2002 =
13:36</DIV>
  <DIV style=3D"FONT: 10pt arial"><B>Subject:</B> IBM alternative to =
PKI?</DIV>
  <DIV><BR></DIV>
  <DIV><FONT face=3DArial size=3D2><SPAN=20
  class=3D080502611-13052002>Hi,</SPAN></FONT></DIV>
  <DIV><FONT face=3DArial size=3D2><SPAN =
class=3D080502611-13052002>&nbsp;&nbsp;&nbsp;=20
  Does anynone know-of and have comment on this?</SPAN></FONT></DIV>
  <DIV><FONT face=3DArial size=3D2><SPAN =
class=3D080502611-13052002><BR><A=20
  =
href=3D"http://www.kablenet.com/kd.nsf/Frontpage/7B504C830890B08180256BB4=
00427B02?OpenDocument"=20
  target=3D"new window"><FONT color=3Dblue face=3DArial size=3D2><B>UK =
plans smarter ID=20
  card</B></FONT></A><FONT face=3D"Times New Roman" size=3D3> =
<BR><BR></FONT><FONT=20
  face=3DArial size=3D2>The Office of the e-Envoy is looking at =
alternatives to PKI=20
  (public key infrastructure) technology for making secure electronic=20
  transactions. Officials have held talks with supplier IBM to devise a =
new form=20
  of electronic ID card intended to avoid the commercial and privacy =
problems=20
  associated with PKI technology. </FONT><BR><BR><FONT face=3DArial =
size=3D2>The=20
  technology, known as the "empowerment model", could be used both in =
the=20
  private and public sectors to authenticate users of electronic =
services, a top=20
  IBM executive told Government Computing News. =
</FONT><BR></SPAN></FONT></DIV>
  <HR>

  <TABLE border=3D0 width=3D433>
    <TBODY>
    <TR>
      <TD colSpan=3D2 width=3D203><FONT face=3DArial size=3D2>Dean =
Adams</FONT></TD>
      <TD width=3D143><FONT face=3DArial size=3D2>Mobile:</FONT></TD>
      <TD width=3D135><FONT face=3DArial size=3D2>+44 (0) 7989 =
385914</FONT></TD></TR>
    <TR>
      <TD colSpan=3D2 width=3D203><FONT face=3DArial size=3D2>Trustis=20
Limited</FONT></TD>
      <TD width=3D143><FONT face=3DArial size=3D2>Direct =
Tel/Fax:</FONT></TD>
      <TD width=3D135><FONT face=3DArial size=3D2>+44 (0) 1252 =
734320</FONT></TD></TR>
    <TR>
      <TD colSpan=3D2 width=3D203><FONT face=3DArial size=3D2>49 =
Whitehall</FONT></TD>
      <TD width=3D143><FONT face=3DArial size=3D2>Office =
Tel:</FONT></TD>
      <TD width=3D135><FONT face=3DArial size=3D2>[phone] =
1490</FONT></TD></TR>
    <TR>
      <TD colSpan=3D2 width=3D203><FONT face=3DArial size=3D2>London =
SW1A=20
2BX</FONT></TD>
      <TD width=3D143><FONT face=3DArial size=3D2>Office =
Fax:</FONT></TD>
      <TD width=3D135><FONT face=3DArial size=3D2>[phone] =
7961</FONT></TD></TR>
    <TR>
      <TD width=3D61><FONT face=3DArial size=3D2>email:</FONT></TD>
      <TD width=3D142><FONT face=3DArial size=3D2><A=20
        href=3D"mailto:[e-mail]">[e-mail]</A></FONT></TD>
      <TD width=3D143><FONT face=3DArial size=3D2>Web:</FONT></TD>
      <TD width=3D135><FONT face=3DArial size=3D2><A =
href=3D"http://www.trustis.com/"=20
        =
target=3D_blank>http://www.trustis.com</A></FONT></TD></TR></TBODY></TABL=
E>
  <P><FONT face=3DArial size=3D2>The information in this message is =
confidential. It=20
  is intended solely for the addressee. Access to this message by anyone =
else is=20
  unauthorised. If you are not the intended recipient, any disclosure, =
copying,=20
  distribution or any action taken or omitted to be taken in reliance on =
it, is=20
  prohibited and may be unlawful.</FONT></P>
  <P><FONT face=3DArial size=3D2>Any attachments to this message have =
been checked=20
  for viruses, but please rely on your own virus checker and=20
  procedures.</FONT></P>
  <P><FONT face=3DArial size=3D2>If you contact us by e-mail, we may =
store your name=20
  and address to facilitate communications. </FONT></P>
  <DIV>&nbsp;</DIV></BLOCKQUOTE></BODY></HTML>

------=_NextPart_000_0054_01C1FB2E.29CBBD10--



Received: by above.proper.com (8.11.6/8.11.3) id g4E5DJY10878 for ietf-pkix-bks; Mon, 13 May 2002 22:13:19 -0700 (PDT)
Received: from bosgeo2.geotrust.com (bosgeo2.geotrust.com [208.59.15.50]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g4E5DGL10873 for <[e-mail]>; Mon, 13 May 2002 22:13:16 -0700 (PDT)
Received: by bosgeo2.boston.geotrust.com with Internet Mail Service (5.5.2650.21) id <JQBVZVXP>; Tue, 14 May 2002 01:13:10 -0400
Message-ID: <[e-mail]>
From: Mike Rowan <[e-mail]>
To: "'Richard Culshaw '" <[e-mail]>, "'Ietf-Pkix (E-mail) '" <[e-mail]>
Subject: RE: where should email address go?
Date: Tue, 14 May 2002 01:13:10 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
Content-Type: text/plain; charset="iso-8859-1"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Richard:

You are correct in that only some legacy apps use the RFC822Name in the SAN.
Your best bet is to place this in both Subject DN and the SAN, unless of
cource you can be sure of your application usage.  Still it would be
limiting, by placing this in both you are sure to meet most needs.  There
may be a possiblity of a partiular legacy app having issues with SAN values,
although I have not seen this as of yet.

- Michael Rowan
  GeoTrust, Inc.

-----Original Message-----
From: Richard Culshaw
To: Ietf-Pkix (E-mail)
Sent: 5/13/02 10:56 PM
Subject: where should email address go?



Hi all,

a quick question for the group...

what is the best place to put an email address value in an client
certificate
in the E field of the Subject DN eg:
E = [e-mail]

or 
in the Subject Alt Name Extenstion eg:
RFC822 Name=[e-mail]

my understanding is that only some legacy applications use the Subject
Alt
Name extension and just about all the client software out there looks in
the
Subject DN for the email address?

 what about placing it in both fields???

thanks in advance....




Richard Culshaw 


Received: by above.proper.com (8.11.6/8.11.3) id g4E2ufK05465 for ietf-pkix-bks; Mon, 13 May 2002 19:56:41 -0700 (PDT)
Received: from esmddns01.esign.com.au ([203.58.177.3]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g4E2ucL05461 for <[e-mail]>; Mon, 13 May 2002 19:56:39 -0700 (PDT)
Received: from esmcex01.esign.com.au (not verified[192.168.1.12]) by esmddns01.esign.com.au with MailMarshal (4,0,9,0)  id <B00005da39>; Tue, 14 May 2002 12:56:37 +1000
Received: by esmcex01 with Internet Mail Service (5.5.2650.21) id <K45XX2RQ>; Tue, 14 May 2002 12:56:37 +1000
Message-ID: <FA4D9B37FE63D611858C00C00D016FCD0E0389@esmcex01>
From: Richard Culshaw <[e-mail]>
To: "Ietf-Pkix (E-mail)" <[e-mail]>
Subject: where should email address go?
Date: Tue, 14 May 2002 12:56:32 +1000
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain; charset="iso-8859-1"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Hi all,

a quick question for the group...

what is the best place to put an email address value in an client
certificate
in the E field of the Subject DN eg:
E = [e-mail]

or 
in the Subject Alt Name Extenstion eg:
RFC822 Name=[e-mail]

my understanding is that only some legacy applications use the Subject Alt
Name extension and just about all the client software out there looks in the
Subject DN for the email address?

 what about placing it in both fields???

thanks in advance....




Richard Culshaw 



Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g4DIpHn22336 for ietf-pkix-bks; Mon, 13 May 2002 11:51:17 -0700 (PDT)
Received: from mtiwmhc21.worldnet.att.net (mtiwmhc21.worldnet.att.net [204.127.131.46]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g4DIpFL22332 for <[e-mail]>; Mon, 13 May 2002 11:51:16 -0700 (PDT)
Received: from tsg1 ([12.81.70.177]) by mtiwmhc21.worldnet.att.net (InterMail vM.4.01.03.27 201-229-121-127-20010626) with SMTP id <20020513185056.PUW5949.mtiwmhc21.worldnet.att.net@tsg1>; Mon, 13 May 2002 18:50:56 +0000
Message-ID: <046b01c1faae$b20155d0$020aff0a@tsg1>
From: "todd glassey" <[e-mail]>
To: "Michael Froomkin - U.Miami School of Law" <[e-mail]>
Cc: "PKIX-IETF" <[e-mail]>, "LISTS - IETF-IESG" <[e-mail]>, <[e-mail]>
References: <[e-mail]>
Subject: Re: Open issue: requester identifier in DPV response
Date: Mon, 13 May 2002 11:47:51 -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.50.4522.1200
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Michael - the issue here is that the IETF and IESG are essentially run under
their own internal control and this is what is unacceptable. The overall
process of any standards organization must be able to withstand any
reasonable prosecution for wrong doing. If not then the value of the
standards produced comes into question.

Oh and as to the bias, the bias is not a problem until it causes any
one effort to be elevated over others, and then it becomes a serious
problem. And we are long past that point herein.

What this management team have successfully done to date is to build a
monolithic approval model and used it to play the game their way and no
other. This is of course not true of everyone in the management makeup but
it certainly is true of some. Which is exactly why this organization needs
restructuring.

The problem with techies is that we have a tendency to only look at things
in front of our face, i.e. at ground level, or things that interest us and
that is an
issue. The view of the problem is not even visible at ground level for the
most
part, and so the ostriches amongst us are content to keep their heads in the
sand until some predator comes along and "harvests" them.

The bottom line is that these IP issues and the Antitrust issues are real,
from my opinion and as such actionable. Thank god I don't have a license to
practice law or I would go bonkers filing against these folks...

Todd

----- Original Message -----
From: "Michael Froomkin - U.Miami School of Law" <[e-mail]>
To: "todd glassey" <[e-mail]>
Cc: "PKIX-IETF" <[e-mail]>; "LISTS - IETF-IESG" <[e-mail]>;
<[e-mail]>
Sent: Wednesday, May 08, 2002 6:37 PM
Subject: Re: Open issue: requester identifier in DPV response


>
> Merely having a bias, even one that hurts someone, is not a violation of
> US (or, insofar as I understand it, EU) anti-trust/competition law.
>
> Oversimplifying slightly, in order to find an offense, you would have to
> show concerted action, by a person or persons with a financial interest,
> against one or more competitors.
>
> Generally speaking, and again oversimplifying, valid technical grounds is
> a defense against many if not most otherwise valid claims of abuse of
> standard making.
>
> You will find a less simplistic discussion of these issues, in the context
> of US law and ICANN-as-a=standards-body, in an article I am co-authoring
> with Mark Lemely, a leading antitrust authority.  A copy of the working
> draft is here:
> http://personal.law.miami.edu/~froomkin/articles/icann-antitrust.pdf
>
> The statement in your last 3.5 lines of the post quoted below is false as
> a matter of US law.  I'd be mildly curious to learn at what law school you
> acquired this view, or which non-US (or non-Earth?) legal system you are
> referring to with your assurance.
>
> On Wed, 8 May 2002, todd glassey wrote:
>
> > Michael restraint of trade is actionable. refusing to allow any effort
to
> > pass without a definition of the formal processes to be applied to all
> > submissions, i.e. how the IETF  is setup today, leaves the entirety to
the
> > WG Chairs and their AD's and that it the problem and I assure you that
if it
> > can be demonstrated to any level that anyone in a standards organization
> > gave undue advantage to one protocol over an other and anyone suffered a
> > financial loss because of this act, that this is assuredly actionable.
> >
> > Todd
> >
> > ----- Original Message -----
> > From: "Michael Froomkin - U.Miami School of Law"
<[e-mail]>
> > To: "todd glassey" <[e-mail]>
> > Cc: "PKIX-IETF" <[e-mail]>; "LISTS - IETF-IESG"
<[e-mail]>;
> > <[e-mail]>
> > Sent: Monday, April 29, 2002 8:10 PM
> > Subject: Re: Open issue: requester identifier in DPV response
> >
> >
> > > "Actionable"?  I rather doubt it.  At least not in the US, and not
without
> > > many aggravating circumstances.
> > >
> > > On Sat, 27 Apr 2002, todd glassey wrote:
> > >
> > > > Stephen - I think that it is very likely that ANY involvement by a
WG
> > Chair
> > > > in ANY protocol at any level is a conflict of interest and
actionable as
> > > > such. It shows a predudicial predisposition towards that protocol
and
> > favors
> > > > it over all others. This is why I am demanding the rewriting of the
WG's
> > > > charter as well as the approriate sections of RFC2026 et al..
> > > >
> > > [....]
> > > --
> > > Please visit http://www.icannwatch.org
> > >
> > > A. Michael Froomkin   |    Professor of Law    |   [e-mail]
> > > U. Miami School of Law, P.O. Box 248087, Coral Gables, FL 33124 USA
> > > [phone]  |  [phone] (fax)  |  http://www.law.tm
> > >                         -->It's hot here.<--
> > >
> >
> >
>
> --
> Please visit http://www.icannwatch.org
> A. Michael Froomkin   |    Professor of Law    |   [e-mail]
> U. Miami School of Law, P.O. Box 248087, Coral Gables, FL 33124 USA
> [phone]  |  [phone] (fax)  |  http://www.law.tm
>                         -->It's hot here.<--
>





Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g4DBado04757 for ietf-pkix-bks; Mon, 13 May 2002 04:36:39 -0700 (PDT)
Received: from mail7.svr.pol.co.uk (mail7.svr.pol.co.uk [195.92.193.21]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g4DBabL04753 for <[e-mail]>; Mon, 13 May 2002 04:36:37 -0700 (PDT)
Received: from modem-2903.lion.dialup.pol.co.uk ([217.135.171.87] helo=badger) by mail7.svr.pol.co.uk with smtp (Exim 3.35 #1) id 177E84-0002JG-00 for [e-mail]; Mon, 13 May 2002 12:36:36 +0100
From: "Dean Adams" <[e-mail]>
To: <[e-mail]>
Subject: IBM alternative to PKI?
Date: Mon, 13 May 2002 12:36:22 +0100
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_0006_01C1FA7A.C9DF6720"
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0)
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200
Importance: Normal
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

This is a multi-part message in MIME format.

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

Hi,
    Does anynone know-of and have comment on this?

UK plans smarter ID card

The Office of the e-Envoy is looking at alternatives to PKI (public key
infrastructure) technology for making secure electronic transactions.
Officials have held talks with supplier IBM to devise a new form of
electronic ID card intended to avoid the commercial and privacy problems
associated with PKI technology.

The technology, known as the "empowerment model", could be used both in the
private and public sectors to authenticate users of electronic services, a
top IBM executive told Government Computing News.


----------------------------------------------------------------------------
----
      Dean Adams Mobile: [phone]
      Trustis Limited Direct Tel/Fax: [phone]
      49 Whitehall Office Tel: [phone]
      London SW1A 2BX Office Fax: [phone]
      email: [e-mail] Web: http://www.trustis.com

The information in this message is confidential. It is intended solely for
the addressee. Access to this message by anyone else is unauthorised. If you
are not the intended recipient, any disclosure, copying, distribution or any
action taken or omitted to be taken in reliance on it, is prohibited and may
be unlawful.

Any attachments to this message have been checked for viruses, but please
rely on your own virus checker and procedures.

If you contact us by e-mail, we may store your name and address to
facilitate communications.



------=_NextPart_000_0006_01C1FA7A.C9DF6720
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=3DContent-Type content=3D"text/html; =
charset=3Diso-8859-1">
<META content=3D"MSHTML 5.50.4727.700" name=3DGENERATOR></HEAD>
<BODY>
<DIV><FONT face=3DArial size=3D2><SPAN=20
class=3D080502611-13052002>Hi,</SPAN></FONT></DIV>
<DIV><FONT face=3DArial size=3D2><SPAN =
class=3D080502611-13052002>&nbsp;&nbsp;&nbsp;=20
Does anynone know-of and have comment on this?</SPAN></FONT></DIV>
<DIV><FONT face=3DArial size=3D2><SPAN class=3D080502611-13052002><BR><A =

target=3D"new window"=20
href=3D"http://www.kablenet.com/kd.nsf/Frontpage/7B504C830890B08180256BB4=
00427B02?OpenDocument"><FONT=20
face=3DArial color=3Dblue size=3D2><B>UK plans smarter ID =
card</B></FONT></A><FONT=20
face=3D"Times New Roman" size=3D3> <BR><BR></FONT><FONT face=3DArial =
size=3D2>The Office=20
of the e-Envoy is looking at alternatives to PKI (public key =
infrastructure)=20
technology for making secure electronic transactions. Officials have =
held talks=20
with supplier IBM to devise a new form of electronic ID card intended to =
avoid=20
the commercial and privacy problems associated with PKI technology.=20
</FONT><BR><BR><FONT face=3DArial size=3D2>The technology, known as the =
"empowerment=20
model", could be used both in the private and public sectors to =
authenticate=20
users of electronic services, a top IBM executive told Government =
Computing=20
News. </FONT><BR></SPAN></FONT></DIV>
<HR>

<TABLE width=3D433 border=3D0>
  <TBODY>
  <TR>
    <TD width=3D203 colSpan=3D2><FONT face=3DArial size=3D2>Dean =
Adams</FONT></TD>
    <TD width=3D143><FONT face=3DArial size=3D2>Mobile:</FONT></TD>
    <TD width=3D135><FONT face=3DArial size=3D2>+44 (0) 7989 =
385914</FONT></TD></TR>
  <TR>
    <TD width=3D203 colSpan=3D2><FONT face=3DArial size=3D2>Trustis =
Limited</FONT></TD>
    <TD width=3D143><FONT face=3DArial size=3D2>Direct =
Tel/Fax:</FONT></TD>
    <TD width=3D135><FONT face=3DArial size=3D2>+44 (0) 1252 =
734320</FONT></TD></TR>
  <TR>
    <TD width=3D203 colSpan=3D2><FONT face=3DArial size=3D2>49 =
Whitehall</FONT></TD>
    <TD width=3D143><FONT face=3DArial size=3D2>Office Tel:</FONT></TD>
    <TD width=3D135><FONT face=3DArial size=3D2>[phone] =
1490</FONT></TD></TR>
  <TR>
    <TD width=3D203 colSpan=3D2><FONT face=3DArial size=3D2>London SW1A =
2BX</FONT></TD>
    <TD width=3D143><FONT face=3DArial size=3D2>Office Fax:</FONT></TD>
    <TD width=3D135><FONT face=3DArial size=3D2>[phone] =
7961</FONT></TD></TR>
  <TR>
    <TD width=3D61><FONT face=3DArial size=3D2>email:</FONT></TD>
    <TD width=3D142><FONT face=3DArial size=3D2><A=20
      href=3D"mailto:[e-mail]">[e-mail]</A></FONT></TD>
    <TD width=3D143><FONT face=3DArial size=3D2>Web:</FONT></TD>
    <TD width=3D135><FONT face=3DArial size=3D2><A target=3D_blank=20
      =
href=3D"http://www.trustis.com/">http://www.trustis.com</A></FONT></TD></=
TR></TBODY></TABLE>
<P><FONT face=3DArial size=3D2>The information in this message is =
confidential. It=20
is intended solely for the addressee. Access to this message by anyone =
else is=20
unauthorised. If you are not the intended recipient, any disclosure, =
copying,=20
distribution or any action taken or omitted to be taken in reliance on =
it, is=20
prohibited and may be unlawful.</FONT></P>
<P><FONT face=3DArial size=3D2>Any attachments to this message have been =
checked for=20
viruses, but please rely on your own virus checker and =
procedures.</FONT></P>
<P><FONT face=3DArial size=3D2>If you contact us by e-mail, we may store =
your name=20
and address to facilitate communications. </FONT></P>
<DIV>&nbsp;</DIV></BODY></HTML>

------=_NextPart_000_0006_01C1FA7A.C9DF6720--



Received: by above.proper.com (8.11.6/8.11.3) id g4CLdNd13784 for ietf-pkix-bks; Sun, 12 May 2002 14:39:23 -0700 (PDT)
Received: from nymelsmtp.internet.ny.fdms.firstdata.com ([204.124.248.17]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g4CLdLL13774 for <[e-mail]>; Sun, 12 May 2002 14:39:21 -0700 (PDT)
Subject: Re: Meaning of Non-repudiation
To: [e-mail], [e-mail], "500 list (E-mail)" <[e-mail]>, [e-mail], Sharon Boeyen <[e-mail]>, "Bill Burr (E-mail)" <[e-mail]>
X-Mailer: Lotus Notes Release 5.0.5  September 22, 2000
Message-ID: <[e-mail]>
From: [e-mail]
Date: Sun, 12 May 2002 15:24:07 -0600
X-MIMETrack: Serialize by Router on NYMELSMTP/NY/FDMS/FDC(Release 5.0.8 |June 18, 2001) at 05/12/2002 05:36:17 PM
MIME-Version: 1.0
Content-type: text/plain; charset=us-ascii
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

I've finished some more of the taxonomy .... SC27 is big on evidence,
proof, audit trails and time-stamping.

try clicking on "evidence" (new to the concept section at the start of the
glossary frame).



[e-mail] on 5/11/2002 11:44 pm wrote:

while i was at it, i thot i would go ahead and update the merged security
glossary with the latest from ISO SC27
http://www.garlic.com/~lynn/secure.htm

some of the new defintions (from merged security taxonomy/glossary; i'm
still working on taxonomy for many of the new terms in the latest sc27
glossary).






Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g4C5krF15256 for ietf-pkix-bks; Sat, 11 May 2002 22:46:53 -0700 (PDT)
Received: from nymelsmtp.internet.ny.fdms.firstdata.com ([204.124.248.17]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g4C5kpL15252 for <[e-mail]>; Sat, 11 May 2002 22:46:52 -0700 (PDT)
Subject: Re: Meaning of Non-repudiation
To: Sharon Boeyen <[e-mail]>
Cc: [e-mail], "500 list (E-mail)" <[e-mail]>, [e-mail], "Bill Burr (E-mail)" <[e-mail]>
X-Mailer: Lotus Notes Release 5.0.5  September 22, 2000
Message-ID: <[e-mail]>
From: [e-mail]
Date: Sat, 11 May 2002 23:44:49 -0600
X-MIMETrack: Serialize by Router on NYMELSMTP/NY/FDMS/FDC(Release 5.0.8 |June 18, 2001) at 05/12/2002 01:43:50 AM
MIME-Version: 1.0
Content-type: text/plain; charset=us-ascii
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

while i was at it, i thot i would go ahead and update the merged security
glossary with the latest from ISO SC27
http://www.garlic.com/~lynn/secure.htm

some of the new defintions (from merged security taxonomy/glossary; i'm
still working on taxonomy for many of the new terms in the latest sc27
glossary).

non-repudiation

A security service by which evidence is maintained so that the sender of
data and recipient of data cannot deny having participated in the
communication. [IATF] Method by which the sender of data is provided with
proof of delivery and the recipient is assured of the sender's identity, so
that neither can later deny having processed the data. [NSAINT] The ability
to prove an action or event has taken place, so that this event or action
cannot be repudiated later. [ISO/IEC PDTR 13335-1 (11/2001)] [sc27] The
reasonable assurance that a principal cannot deny being the originator of a
message after sending it. Non-repudiation is achieved by encrypting the
message digest using a principal's private key. The public key of the
principal must be certified by a trusted certification authority. [misc]
(see also Generic Security Services API, IT security, NRD token, NRO token,
NRS token, NRT token, assurance, defense-wide information assurance
program, digital signature, distinguishing identifier, information
assurance, invalidity date, non-repudiation exchange, non-repudiation
information, non-repudiation of creation, non-repudiation of delivery,
non-repudiation of knowledge, non- repudiation of origin, non-repudiation
of receipt, non-repudiation of sending, non-repudiation of submission,
non-repudiation of transport, non-repudiation policy, non-repudiation
token, notarization token, originator, proof, recipient, sandboxed
environment, secure single sign-on, certification authority, public-key
infrastructure, quality of protection) (includes non-repudiation service,
privacy, authentication, identification, integrity, non-repudiation,
privacy, authentication, identification, non-repudation)

non-repudiation exchange

A sequence of one or more transfers of non-repudiation information (NRI)
for the purpose of non-repudiation. [ISO/IEC WD 13888-1 (11/2001)] [sc27]
(see also non-repudiation)

non-repudiation information

A set of information that may consist of the information about an event or
action for which evidence is to be generated and validated, the evidence
itself, and the non-repudiation policy in effect. [ISO/IEC WD 13888-1
(11/2001)] [sc27] (see also non-repudiation)

non-repudiation of creation

This service is intended to protect against an entity's false denial of
having created the content of a message (i.e. being responsible for the
content of a message). [ISO/IEC WD 13888-1 (11/2001)] Protection against an
entity's false denial of having created the content of a message (i.e.,
being responsible for the content of a message). [ISO/IEC 15945: 2002]
[sc27] (see also non-repudiation)

non-repudiation of delivery

This service is intended to protect against a recipient's false denial of
having received the message and recognised the content of a message.
[ISO/IEC WD 13888-1 (11/2001)] [sc27] (see also non-repudiation)

non-repudiation of knowledge

This service is intended to protect against a recipient's false denial of
having taken notice of the content of a received message. [ISO/IEC WD
13888-1 (11/2001)] [sc27] (see also non- repudiation)

non-repudiation of origin

This service is intended to protect against the originator's false denial
of having approved the content of a message and of having sent a message.
[ISO/IEC WD 13888-1 (11/2001)] [sc27] (see also non-repudiation)

non-repudiation of receipt

This service is intended to protect against a recipient's false denial of
having received a message. [ISO/IEC WD 13888-1 (11/2001)] [sc27] (see also
non-repudiation)

non-repudiation of sending

This service is intended to protect against the sender's false denial of
having sent a message. [ISO/IEC WD 13888-1 (11/2001)] [sc27] (see also
non-repudiation)

non-repudiation of submission

This service is intended to provide evidence that a delivery authority has
accepted the message for transmission. [ISO/IEC WD 13888-1 (11/2001)]
[sc27] (see also non-repudiation)

non-repudiation of transport

This service is intended to provide evidence for the message originator
that a delivery authority has delivered the message to the intended
recipient. [ISO/IEC WD 13888-1 (11/2001)] [sc27] (see also non-repudiation)






Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g4BCrF924934 for ietf-pkix-bks; Sat, 11 May 2002 05:53:15 -0700 (PDT)
Received: from mtiwmhc21.worldnet.att.net (mtiwmhc21.worldnet.att.net [204.127.131.46]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g4BCrEL24929 for <[e-mail]>; Sat, 11 May 2002 05:53:14 -0700 (PDT)
Received: from Chokhani ([12.91.131.252]) by mtiwmhc21.worldnet.att.net (InterMail vM.4.01.03.27 201-229-121-127-20010626) with ESMTP id <20020511125307.XSGX24238.mtiwmhc21.worldnet.att.net@Chokhani>; Sat, 11 May 2002 12:53:07 +0000
From: "Santosh Chokhani" <[e-mail]>
To: "'Peter Williams'" <[e-mail]>
Cc: <[e-mail]>
Subject: RE: "Authentication" and "Signature" bits...
Date: Sat, 11 May 2002 08:54:25 -0400
Message-ID: <000601c1f8eb$031ade20$fc835b0c@Chokhani>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.2627
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4910.0300
In-Reply-To: <[e-mail]>
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id g4BCrEL24930
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Peter:

I agree with your examples in items 1, 2, 3, 4, 5, and 6 in terms of key
usage.

In terms of how to achieve NR, I have no proposal in mind.  Your EKU
proposal may work.  NR is one of those things where the actioner can
always claim temporary or permanent insanity and get away with it (just
kidding).

Also, I would like to think that the usage of the two bits is further
explanation as opposed to two new bits, as some one else (I think Dave
Kemp) has suggested.

I also want the list to know the following things:

1.  I have faith in collective intelligence of this group and any
solution they come up with is acceptable to me.

2.  What is not acceptable is this further explanation on the bits being
called a change in semantics.  It smacks of "Cry Wolf" mentality.

3.  It is ok for folks not to accept this if they can show why it breaks
backward compatibility, but this is as good (probably best) a technical
(vice legal) distinction between the two bits as any.  And, no I did not
come up with it.  Some one else on this list did.  I just find it more
acceptable than other distinctions and consistent with the definition of
the extension and how other bits are used in the extension.

-----Original Message-----
From: [e-mail] [mailto:[e-mail]]
On Behalf Of Peter Williams
Sent: Friday, May 10, 2002 4:44 PM
To: 'Santosh Chokhani'
Cc: [e-mail]
Subject: RE: "Authentication" and "Signature" bits...



Thanks for responding. Im working hard to really
understand the implications of your model, by
testing it out on protocol examples. I conclude by
suggesting we adopt the model, but work
still to find a home for the signals we
are formalising.

---------------

Correct my errors further, please, in the improved examples, if 
any: Ive seperated out the NR issues from KeyUsage, per your last
message, 
and assigned actual internet/intranet protocols a set of appropriate
KeyUsages (per Santosh model).

1. OCSP

Basic OCSP responses: Use "digitalSignature/dataSign" KeyUsage

An OCSP Provider's optional upgrade of an OCSP response to provide some
NR assertions requires the provider's cert to bear an OCSP-NR oid in 
ExtendedKeyUsage  OR protocol specific means are used to signal the
additional NR semantics.

2. DPV

DPV responses: use "digitalSignature/dataSign" KeyUsage

A DPV Provider's formation of NR assertions is implicit, and does not
require that the provider's cert bears a DPV-NR oid in ExtendedKeyUsage.

3. OSI ROS-Bind variants

DAP/DSP/CMIP/ACSE-bind : use "authenthentication/nonceSign" KeyUsage

4. DAP/Directory operations

DAP operation request/responses: use "digitalSignature/dataSign" 
KeyUsage. A Directory Provider's optional upgrade of a signed DAP
response to 
provide some NR assertions means that the provider's cert bears an
DAP-NR 
oid in ExtendedKeyUsage OR protocol specific means are used to signal 
NR grade of response.

5. https transport

if any of the X, above, are transferred over https: then
https responder entity has a distinct SSL cert from the X entity, 
where the SSL cert has "authenthentication/nonceSign"  and 
"keyAgreement or keyTransport" KeyUsages. 

The X entity using the https A-entity
has a seperate cert from the https entity. the X cert has
X keyUsages and extendedKeyUsages.

6. SSL+X protocol (e.g. dpv-s, cmp over SSL)

If any of the X application protocols, above, are bound in an
application 
context to an SSL entity, then the X-responder has 1 (combined)
X-protocol 
and SSL cert with  "authenthentication/nonceSign" and "keyAgreement or
keyTransport" 
KeyUsages (for the SSL requirements) unioned with "X" keyUsages and 
extendedKeyUsages (for the X requirements)

Conclusion:

I think the above realize the model and the intent of
your scheme, in practice. I improved my understanding
by (a) understanding that mere presence of replay nonces,
does not mandate "authentication" KeyUsage, and (b)
NR assertion signals are provided by means other than
KeyUsage bits.

I like your scheme. We now need to suggest
how it can be factored into X.509 without
upsetting legacy applications, whilst clearly
making a complete break with the confused past.

New bits in the KeyUsage bitfield or a new X.509 extension
seem appropriate, as Sharon suggests, rather than
simply redefining legacy bits. But your model for
clearing the confused notions about usages seems 
sound and workable, once we find a home for
the various signals.

>>>>-----Original Message-----
>>>>From: Santosh Chokhani [mailto:[e-mail]]
>>>>Sent: Friday, May 10, 2002 5:42 AM
>>>>To: 'Peter Williams'
>>>>Cc: [e-mail]
>>>>Subject: RE: "Authentication" and "Signature" bits...
>>>>
>>>>
>>>>Peter:
>>>>
>>>>There are several misunderstandings (in my mind) on your part of 
>>>>what I suggest.  First of all, I do not say that there is NR or
>>>>there is no NR.
>>>>That is why when people on this list talk about intent and 
>>>>software and
>>>>hardware between the human actions, I get lost.
>>>>
>>>>My proposal is very simple, just the way a key can be used for
>>>>encryption and signature verification or you can have two different 
>>>>keys for encryption and signature verification, I want to 
>>>>differential between signing challenges for entity authentication 
>>>>and signing data
>>>>that the user/application has formed/blessed.
>>>>
>>>>In these scenarios for OCSP and DPV, the digital signature (and not 
>>>>the
>>>>authentication) bit will be required to be set.  If both
>>>>are set, it is
>>>>ok.  I realize that the protocol, includes echoing the 
>>>>challenge, but
>>>>the responder is formulating a transaction as opposed to signing a
>>>>challenge in order to provide authentication.
>>>>
>>>>Those who want to solve NR problem, are welcome to.  My precise 
>>>>point is that NR is not a problem to be solved by PKC.  As it so
>>>>happens, a key
>>>>that is used for digital signature and not for signing 
>>>>challenges may
>>>>have a better luck on NR, just like a key that is not used for dual
>>>>purpose of signature and encryption (since encryption key 
>>>>may have key
>>>>escrow feature to it). 
>>>>
>>>>-----Original Message-----
>>>>From: Peter Williams [mailto:[e-mail]]
>>>>Sent: Thursday, May 09, 2002 5:43 PM
>>>>To: 'Santosh Chokhani'
>>>>Cc: [e-mail]
>>>>Subject: RE: "Authentication" and "Signature" bits...
>>>>
>>>>
>>>>Let me ask the dumb questions, and
>>>>then comment, publicly.
>>>>
>>>>
>>>>A1:
>>>>
>>>>An OCSP responder inevitably signs
>>>>an OCSP responses, which contains a
>>>>nonce and highly-legalistic reliance data. The
>>>>data is sent, sometimes by a TTP grade
>>>>operator, to influence reliance
>>>>on certificates. There is
>>>>no intention that the OCSP response
>>>>is necessarily a set of NR assertions,
>>>>however.
>>>>
>>>>I think in your scheme, we
>>>>use:
>>>>
>>>>"nonceSign", "digitalSignature|dataSign"
>>>>
>>>>Is this correct?
>>>>
>>>>A2:
>>>>
>>>>A DPV responder will act
>>>>similarly to an OCSP responder,
>>>>with the added twist that its operator
>>>>necessarily makes NR assertions
>>>>(by requirements of this WG), in
>>>>addition to signing a nonce,
>>>>and various pieces of reliance
>>>>data to be used by a relying
>>>>party application in deciding
>>>>how to use a certificate path.
>>>>
>>>>I think in your scheme, we
>>>>use:
>>>>
>>>>"nonceSign", "digitalSignature|dataSign"
>>>>
>>>>Is this correct?
>>>>
>>>>Conclusion 1: in the new scheme, there
>>>>is now no way - using certificates - for an OCSP
>>>>provider to signal that it intends to upgrade its
>>>>OCSP-based validation service to make NR-grade 
>>>>assertions. If an OCSP entity
>>>>is to upgrade its assurance level to
>>>>offer NR, then it would have to signal
>>>>this in an OCSP response extension. That is,
>>>>we tag the grade of OCSP signing assurance
>>>>via an attribute of the signature (essentially)
>>>>in the response, not the certificate.
>>>>
>>>>Conclusion 2: in the case of DPV, with
>>>>the new scheme, there is no need
>>>>to tag the DPV response with any
>>>>NR extension/field signal, as ALL DPV responses
>>>>are NR assertions, by protocol definition. That
>>>>is, one cannot run a DPV server
>>>>except as a NR service provider. Obviously
>>>>the precise meaning of a given signer's NR
>>>>semantics will be a function
>>>>of the posted "signing policy" of the 
>>>>subscriber.
>>>>
>>>>If this is all correct, I'm happy with all this. It
>>>>removes from the CA the technical perogative of controlling what 
>>>>subscribers can do with NR assertions - placing control in the hands

>>>>of the protocol designers (just like
>>>>X.400/EDIFACT did) and the  protocol 
>>>>operators who perform the act
>>>>of signing. This scheme aligns
>>>>with the model of PMI's
>>>>NR assertions.
>>>>
>>>>In terms of PKIX architecture, relying parties
>>>>determine when a security service is a subclass
>>>>of NR assertions - based on the protocol
>>>>definition, and by inspecting the subscribers
>>>>signing policy. This contrasts with
>>>>the current scheme - built into PKIX-1 and replacements,
>>>>in which one looks to the CA CP.
>>>>
>>>>Peter.
>>>>
>>>>
>>>>>>>>-----Original Message-----
>>>>>>>>From: Tom Gindin [mailto:[e-mail]]
>>>>>>>>Sent: Thursday, May 09, 2002 1:42 PM
>>>>>>>>To: Carlisle Adams
>>>>>>>>Cc: 'David P. Kemp'; 'Santosh Chokhani'; '500 list (E-mail)'; 
>>>>>>>>[e-mail]
>>>>>>>>Subject: RE: "Authentication" and "Signature" bits...
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>      Carlisle:
>>>>>>>>
>>>>>>>>      Actually, distinguishing nonces from documents is not a
>>>>>>>>very hard problem (the lengths are radically different).  The
>>>>>>>>difficulty would be in
>>>>>>>>distinguishing challenges which are inside larger objects 
>>>>>>>>from otherwise
>>>>>>>>similar objects.
>>>>>>>>
>>>>>>>>            Tom Gindin
>>>>>>>>
>>>>>>>>Carlisle Adams <[e-mail]>@mail.imc.org on
>>>>>>>>05/08/2002 02:15:28 PM
>>>>>>>>
>>>>>>>>Sent by:    [e-mail]
>>>>>>>>
>>>>>>>>
>>>>>>>>To:    Carlisle Adams <[e-mail]>, "'David 
>>>>>>>>P. Kemp'"
>>>>>>>>       <[e-mail]>, "'Santosh Chokhani'"
>>>>>>>>       <[e-mail]>
>>>>>>>>cc:    "'500 list (E-mail)'" <[e-mail]>,
>>>>>>>>       [e-mail]
>>>>>>>>Subject:    RE: "Authentication" and "Signature" bits...
>>>>>>>>
>>>>>>>>
>>>>>>>>Hi Santosh,
>>>>>>>>
>>>>>>>>
>>>>>>>>      ----------
>>>>>>>>      From:   Santosh Chokhani[SMTP:[e-mail]]
>>>>>>>>      Sent:   Wednesday, May 08, 2002 2:07 PM
>>>>>>>>      To:     'Carlisle Adams'; 'David P. Kemp'
>>>>>>>>      Cc:     '500 list (E-mail)'; [e-mail]
>>>>>>>>      Subject:        RE: "Authentication" and 
>>>>"Signature" bits...
>>>>>>>>
>>>>>>>>
>>>>>>>>      Carlisle:
>>>>>>>>
>>>>>>>>      You make persuasive arguments in favor of existing
>>>>>>>>implementation.
>>>>>>>>
>>>>>>>>      But, on technical grounds, there is a difference between
>>>>>>>>signing a
>>>>>>>>      challenge and signing to some contents that you want
>>>>>>>>to provide
>>>>>>>>      digital signatures for.  We have this distinction for 
>>>>>>>>certificate and
>>>>>>>>      CRL and what we have proposed is meaningful and 
>>>>useful without
>>>>>>>>      getting into all the legal mumbo-jumbo.
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>I'm not talking about legal mumbo-jumbo.  All I'm saying is that
>>>>>>>>a human may be able to readily see the difference between random
>>>>>>>>data that has been
>>>>>>>>signed and meaningful data that has been signed, but in 
>>>>many cases,
>>>>>>>>software can't.  Certificates and CRLs have a very specific, 
>>>>>>>>well-known syntax, so software *can* distinguish between these 
>>>>>>>>and other data.  But
>>>>>>>>deciding whether the thing that has been signed had the 
>>>>>>>>intent of being for
>>>>>>>>authentication purposes (e.g., a random challenge, or a 
>>>>data origin
>>>>>>>>authentication e-mail) is a very hard problem.
>>>>>>>>
>>>>>>>>
>>>>>>>>I disagree that the distinction that has been proposed is
>>>>>>>>meaningful and useful, completely independent of any legal 
>>>>>>>>interpretation.
>>>>>>>>
>>>>>>>>
>>>>>>>>Carlisle.
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>



Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g4B09ni01267 for ietf-pkix-bks; Fri, 10 May 2002 17:09:49 -0700 (PDT)
Received: from gamma.isi.edu (gamma.isi.edu [128.9.144.145]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g4B09lL01262 for <[e-mail]>; Fri, 10 May 2002 17:09:47 -0700 (PDT)
Received: from ISI.EDU (jet.isi.edu [128.9.160.87]) by gamma.isi.edu (8.11.6/8.11.2) with ESMTP id g4B09nm12156; Fri, 10 May 2002 17:09:49 -0700 (PDT)
Message-Id: <[e-mail]>
To: IETF-Announce: ;
Subject: RFC 3281 on An Internet Attribute Certificate
Cc: [e-mail], [e-mail]
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary=NextPart
Date: Fri, 10 May 2002 17:09:49 -0700
From: RFC Editor <[e-mail]>
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

--NextPart


A new Request for Comments is now available in online RFC libraries.


        RFC 3281

        Title:	    An Internet Attribute Certificate Profile for
                    Authorization 
        Author(s):  S. Farrell, R. Housley
        Status:	    Standards Track
	Date:       April 2002
        Mailbox:    [e-mail],
                    [e-mail] 
        Pages:      40
        Characters: 90580
        Updates/Obsoletes/SeeAlso:    None

        I-D Tag:    draft-ietf-pkix-ac509prof-09.txt

        URL:        ftp://ftp.rfc-editor.org/in-notes/rfc3281.txt


This specification defines a profile for the use of X.509 Attribute
Certificates in Internet Protocols.  Attribute certificates may be
used in a wide range of applications and environments covering a
broad spectrum of interoperability goals and a broader spectrum of
operational and assurance requirements.  The goal of this document is
to establish a common baseline for generic applications requiring
broad interoperability as well as limited special purpose
requirements.  The profile places emphasis on attribute certificate
support for Internet electronic mail, IPSec, and WWW security
applications.

This document is a product of the Public-Key Infrastructure (X.509)
Working Group of the IETF.

This is now a Proposed Standard Protocol.

This document specifies an Internet standards track protocol for
the Internet community, and requests discussion and suggestions
for improvements.  Please refer to the current edition of the
"Internet Official Protocol Standards" (STD 1) for the
standardization state and status of this protocol.  Distribution
of this memo is unlimited.

This announcement is sent to the IETF list and the RFC-DIST list.
Requests to be added to or deleted from the IETF distribution list
should be sent to [e-mail].  Requests to be
added to or deleted from the RFC-DIST distribution list should
be sent to [e-mail].

Details on obtaining RFCs via FTP or EMAIL may be obtained by sending
an EMAIL message to [e-mail] with the message body 
help: ways_to_get_rfcs.  For example:

        To: [e-mail]
        Subject: getting rfcs

        help: ways_to_get_rfcs

Requests for special distribution should be addressed to either the
author of the RFC in question, or to [e-mail].  Unless
specifically noted otherwise on the RFC itself, all RFCs are for
unlimited distribution.echo 
Submissions for Requests for Comments should be sent to
[e-mail].  Please consult RFC 2223, Instructions to RFC
Authors, for further information.


Joyce K. Reynolds and Sandy Ginoza
USC/Information Sciences Institute

...

Below is the data which will enable a MIME compliant Mail Reader 
implementation to automatically retrieve the ASCII version
of the RFCs.

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

RETRIEVE: rfc
DOC-ID: rfc3281

--OtherAccess
Content-Type:   Message/External-body;
        name="rfc3281.txt";
        site="ftp.isi.edu";
        access-type="anon-ftp";
        directory="in-notes"

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

--OtherAccess--
--NextPart--


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g4B04fU01147 for ietf-pkix-bks; Fri, 10 May 2002 17:04:41 -0700 (PDT)
Received: from gamma.isi.edu (gamma.isi.edu [128.9.144.145]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g4B04dL01141 for <[e-mail]>; Fri, 10 May 2002 17:04:39 -0700 (PDT)
Received: from ISI.EDU (jet.isi.edu [128.9.160.87]) by gamma.isi.edu (8.11.6/8.11.2) with ESMTP id g4B04fm10522; Fri, 10 May 2002 17:04:41 -0700 (PDT)
Message-Id: <[e-mail]>
To: IETF-Announce: ;
Subject: RFC 3280 on Internet X.509 Public Key Infrastructure
Cc: [e-mail], [e-mail]
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary=NextPart
Date: Fri, 10 May 2002 17:04:41 -0700
From: RFC Editor <[e-mail]>
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

--NextPart


A new Request for Comments is now available in online RFC libraries.


        RFC 3280

        Title:	    Internet X.509 Public Key Infrastructure
                    Certificate and Certificate Revocation List (CRL)
                    Profile 
        Author(s):  R. Housley, W. Polk, W. Ford, D. Solo
        Status:	    Standards Track
	Date:       April 2002
        Mailbox:    [e-mail], [e-mail],
                    [e-mail], [e-mail]
        Pages:      129
        Characters: 295556
        Updates/Obsoletes/SeeAlso:    None

        I-D Tag:    draft-ietf-pkix-new-part1-12.txt

        URL:        ftp://ftp.rfc-editor.org/in-notes/rfc3280.txt


This memo profiles the X.509 v3 certificate and X.509 v2 Certificate
Revocation List (CRL) for use in the Internet.  An overview of this
approach and model are provided as an introduction.  The X.509 v3
certificate format is described in detail, with additional information
regarding the format and semantics of Internet name forms.  Standard
certificate extensions are described and two Internet-specific
extensions are defined.  A set of required certificate extensions is
specified.  The X.509 v2 CRL format is described in detail, and
required extensions are defined.  An algorithm for X.509 certification
path validation is described.  An ASN.1 module and examples are
provided in the appendices.

This document is a product of the Internet X.509 Public Key
Infrastructure (PKIX) Working Group of the IETF.

This is now a Proposed Standard Protocol.

This document specifies an Internet standards track protocol for
the Internet community, and requests discussion and suggestions
for improvements.  Please refer to the current edition of the
"Internet Official Protocol Standards" (STD 1) for the
standardization state and status of this protocol.  Distribution
of this memo is unlimited.

This announcement is sent to the IETF list and the RFC-DIST list.
Requests to be added to or deleted from the IETF distribution list
should be sent to [e-mail].  Requests to be
added to or deleted from the RFC-DIST distribution list should
be sent to [e-mail].

Details on obtaining RFCs via FTP or EMAIL may be obtained by sending
an EMAIL message to [e-mail] with the message body 
help: ways_to_get_rfcs.  For example:

        To: [e-mail]
        Subject: getting rfcs

        help: ways_to_get_rfcs

Requests for special distribution should be addressed to either the
author of the RFC in question, or to [e-mail].  Unless
specifically noted otherwise on the RFC itself, all RFCs are for
unlimited distribution.echo 
Submissions for Requests for Comments should be sent to
[e-mail].  Please consult RFC 2223, Instructions to RFC
Authors, for further information.


Joyce K. Reynolds and Sandy Ginoza
USC/Information Sciences Institute

...

Below is the data which will enable a MIME compliant Mail Reader 
implementation to automatically retrieve the ASCII version
of the RFCs.

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

RETRIEVE: rfc
DOC-ID: rfc3280

--OtherAccess
Content-Type:   Message/External-body;
        name="rfc3280.txt";
        site="ftp.isi.edu";
        access-type="anon-ftp";
        directory="in-notes"

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

--OtherAccess--
--NextPart--


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g4ANB4W29603 for ietf-pkix-bks; Fri, 10 May 2002 16:11:04 -0700 (PDT)
Received: from mtiwmhc21.worldnet.att.net (mtiwmhc21.worldnet.att.net [204.127.131.46]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g4ANB0L29595 for <[e-mail]>; Fri, 10 May 2002 16:11:00 -0700 (PDT)
Received: from Chokhani ([12.91.132.160]) by mtiwmhc21.worldnet.att.net (InterMail vM.4.01.03.27 201-229-121-127-20010626) with ESMTP id <20020510231056.QIEZ24238.mtiwmhc21.worldnet.att.net@Chokhani>; Fri, 10 May 2002 23:10:56 +0000
From: "Santosh Chokhani" <[e-mail]>
To: "'Peter Williams'" <[e-mail]>
Cc: <[e-mail]>
Subject: RE: "Authentication" and "Signature" bits...
Date: Fri, 10 May 2002 19:12:25 -0400
Message-ID: <008d01c1f878$266a28e0$a300a8c0@Chokhani>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.2627
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4910.0300
In-Reply-To: <[e-mail]>
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id g4ANB1L29599
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Peter:

What I support is very simple.  We have two bits and have not found a
meaningful way to distinguish between the two.

One bit can be used to sign a challenge generated by some one who wants
to authenticate you and another bit is used to sign data generated by
you or on your behalf that you want to prove to be source of.

One is free to use a single key to sign both (by setting both bits).

That is all I am saying, nothing more, nothing less.

-----Original Message-----
From: Peter Williams [mailto:[e-mail]] 
Sent: Friday, May 10, 2002 4:44 PM
To: 'Santosh Chokhani'
Cc: [e-mail]
Subject: RE: "Authentication" and "Signature" bits...


Thanks for responding. Im working hard to really
understand the implications of your model, by
testing it out on protocol examples. I conclude by
suggesting we adopt the model, but work
still to find a home for the signals we
are formalising.

---------------

Correct my errors further, please, in the improved examples, if 
any: Ive seperated out the NR issues from KeyUsage, per your last
message, 
and assigned actual internet/intranet protocols a set of appropriate
KeyUsages (per Santosh model).

1. OCSP

Basic OCSP responses: Use "digitalSignature/dataSign" KeyUsage

An OCSP Provider's optional upgrade of an OCSP response to provide some
NR assertions requires the provider's cert to bear an OCSP-NR oid in 
ExtendedKeyUsage  OR protocol specific means are used to signal the
additional NR semantics.

2. DPV

DPV responses: use "digitalSignature/dataSign" KeyUsage

A DPV Provider's formation of NR assertions is implicit, and does not
require that the provider's cert bears a DPV-NR oid in ExtendedKeyUsage.

3. OSI ROS-Bind variants

DAP/DSP/CMIP/ACSE-bind : use "authenthentication/nonceSign" KeyUsage

4. DAP/Directory operations

DAP operation request/responses: use "digitalSignature/dataSign" 
KeyUsage. A Directory Provider's optional upgrade of a signed DAP
response to 
provide some NR assertions means that the provider's cert bears an
DAP-NR 
oid in ExtendedKeyUsage OR protocol specific means are used to signal 
NR grade of response.

5. https transport

if any of the X, above, are transferred over https: then
https responder entity has a distinct SSL cert from the X entity, 
where the SSL cert has "authenthentication/nonceSign"  and 
"keyAgreement or keyTransport" KeyUsages. 

The X entity using the https A-entity
has a seperate cert from the https entity. the X cert has
X keyUsages and extendedKeyUsages.

6. SSL+X protocol (e.g. dpv-s, cmp over SSL)

If any of the X application protocols, above, are bound in an
application 
context to an SSL entity, then the X-responder has 1 (combined)
X-protocol 
and SSL cert with  "authenthentication/nonceSign" and "keyAgreement or
keyTransport" 
KeyUsages (for the SSL requirements) unioned with "X" keyUsages and 
extendedKeyUsages (for the X requirements)

Conclusion:

I think the above realize the model and the intent of
your scheme, in practice. I improved my understanding
by (a) understanding that mere presence of replay nonces,
does not mandate "authentication" KeyUsage, and (b)
NR assertion signals are provided by means other than
KeyUsage bits.

I like your scheme. We now need to suggest
how it can be factored into X.509 without
upsetting legacy applications, whilst clearly
making a complete break with the confused past.

New bits in the KeyUsage bitfield or a new X.509 extension
seem appropriate, as Sharon suggests, rather than
simply redefining legacy bits. But your model for
clearing the confused notions about usages seems 
sound and workable, once we find a home for
the various signals.

>>>>-----Original Message-----
>>>>From: Santosh Chokhani [mailto:[e-mail]]
>>>>Sent: Friday, May 10, 2002 5:42 AM
>>>>To: 'Peter Williams'
>>>>Cc: [e-mail]
>>>>Subject: RE: "Authentication" and "Signature" bits...
>>>>
>>>>
>>>>Peter:
>>>>
>>>>There are several misunderstandings (in my mind) on your
>>>>part of what I
>>>>suggest.  First of all, I do not say that there is NR or 
>>>>there is no NR.
>>>>That is why when people on this list talk about intent and 
>>>>software and
>>>>hardware between the human actions, I get lost.
>>>>
>>>>My proposal is very simple, just the way a key can be used for 
>>>>encryption and signature verification or you can have two different 
>>>>keys for encryption and signature verification, I want to 
>>>>differential between signing challenges for entity authentication 
>>>>and signing data
>>>>that the user/application has formed/blessed.
>>>>
>>>>In these scenarios for OCSP and DPV, the digital signature
>>>>(and not the
>>>>authentication) bit will be required to be set.  If both 
>>>>are set, it is
>>>>ok.  I realize that the protocol, includes echoing the 
>>>>challenge, but
>>>>the responder is formulating a transaction as opposed to signing a
>>>>challenge in order to provide authentication.
>>>>
>>>>Those who want to solve NR problem, are welcome to.  My
>>>>precise point is
>>>>that NR is not a problem to be solved by PKC.  As it so 
>>>>happens, a key
>>>>that is used for digital signature and not for signing 
>>>>challenges may
>>>>have a better luck on NR, just like a key that is not used for dual
>>>>purpose of signature and encryption (since encryption key 
>>>>may have key
>>>>escrow feature to it). 
>>>>
>>>>-----Original Message-----
>>>>From: Peter Williams [mailto:[e-mail]]
>>>>Sent: Thursday, May 09, 2002 5:43 PM
>>>>To: 'Santosh Chokhani'
>>>>Cc: [e-mail]
>>>>Subject: RE: "Authentication" and "Signature" bits...
>>>>
>>>>
>>>>Let me ask the dumb questions, and
>>>>then comment, publicly.
>>>>
>>>>
>>>>A1:
>>>>
>>>>An OCSP responder inevitably signs
>>>>an OCSP responses, which contains a
>>>>nonce and highly-legalistic reliance data. The
>>>>data is sent, sometimes by a TTP grade
>>>>operator, to influence reliance
>>>>on certificates. There is
>>>>no intention that the OCSP response
>>>>is necessarily a set of NR assertions,
>>>>however.
>>>>
>>>>I think in your scheme, we
>>>>use:
>>>>
>>>>"nonceSign", "digitalSignature|dataSign"
>>>>
>>>>Is this correct?
>>>>
>>>>A2:
>>>>
>>>>A DPV responder will act
>>>>similarly to an OCSP responder,
>>>>with the added twist that its operator
>>>>necessarily makes NR assertions
>>>>(by requirements of this WG), in 
>>>>addition to signing a nonce,
>>>>and various pieces of reliance
>>>>data to be used by a relying
>>>>party application in deciding
>>>>how to use a certificate path.
>>>>
>>>>I think in your scheme, we
>>>>use:
>>>>
>>>>"nonceSign", "digitalSignature|dataSign"
>>>>
>>>>Is this correct?
>>>>
>>>>Conclusion 1: in the new scheme, there
>>>>is now no way - using certificates - for an OCSP
>>>>provider to signal that it intends to upgrade its 
>>>>OCSP-based validation service to make NR-grade 
>>>>assertions. If an OCSP entity
>>>>is to upgrade its assurance level to
>>>>offer NR, then it would have to signal
>>>>this in an OCSP response extension. That is,
>>>>we tag the grade of OCSP signing assurance
>>>>via an attribute of the signature (essentially)
>>>>in the response, not the certificate.
>>>>
>>>>Conclusion 2: in the case of DPV, with
>>>>the new scheme, there is no need
>>>>to tag the DPV response with any
>>>>NR extension/field signal, as ALL DPV responses
>>>>are NR assertions, by protocol definition. That
>>>>is, one cannot run a DPV server
>>>>except as a NR service provider. Obviously
>>>>the precise meaning of a given signer's NR
>>>>semantics will be a function 
>>>>of the posted "signing policy" of the 
>>>>subscriber.
>>>>
>>>>If this is all correct, I'm happy with all this. It
>>>>removes from the CA the technical perogative of controlling what
>>>>subscribers can do with NR assertions - placing control in 
>>>>the hands of
>>>>the protocol designers (just like 
>>>>X.400/EDIFACT did) and the  protocol 
>>>>operators who perform the act
>>>>of signing. This scheme aligns
>>>>with the model of PMI's
>>>>NR assertions.
>>>>
>>>>In terms of PKIX architecture, relying parties
>>>>determine when a security service is a subclass
>>>>of NR assertions - based on the protocol
>>>>definition, and by inspecting the subscribers
>>>>signing policy. This contrasts with
>>>>the current scheme - built into PKIX-1 and replacements,
>>>>in which one looks to the CA CP.
>>>>
>>>>Peter.
>>>>
>>>>
>>>>>>>>-----Original Message-----
>>>>>>>>From: Tom Gindin [mailto:[e-mail]]
>>>>>>>>Sent: Thursday, May 09, 2002 1:42 PM
>>>>>>>>To: Carlisle Adams
>>>>>>>>Cc: 'David P. Kemp'; 'Santosh Chokhani'; '500 list (E-mail)';
>>>>>>>>[e-mail]
>>>>>>>>Subject: RE: "Authentication" and "Signature" bits...
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>      Carlisle:
>>>>>>>>
>>>>>>>>      Actually, distinguishing nonces from documents is not a 
>>>>>>>>very hard problem (the lengths are radically different).  The
>>>>>>>>difficulty would be in
>>>>>>>>distinguishing challenges which are inside larger objects 
>>>>>>>>from otherwise
>>>>>>>>similar objects.
>>>>>>>>
>>>>>>>>            Tom Gindin
>>>>>>>>
>>>>>>>>Carlisle Adams <[e-mail]>@mail.imc.org on 
>>>>>>>>05/08/2002 02:15:28 PM
>>>>>>>>
>>>>>>>>Sent by:    [e-mail]
>>>>>>>>
>>>>>>>>
>>>>>>>>To:    Carlisle Adams <[e-mail]>, "'David 
>>>>>>>>P. Kemp'"
>>>>>>>>       <[e-mail]>, "'Santosh Chokhani'"
>>>>>>>>       <[e-mail]>
>>>>>>>>cc:    "'500 list (E-mail)'" <[e-mail]>,
>>>>>>>>       [e-mail]
>>>>>>>>Subject:    RE: "Authentication" and "Signature" bits...
>>>>>>>>
>>>>>>>>
>>>>>>>>Hi Santosh,
>>>>>>>>
>>>>>>>>
>>>>>>>>      ----------
>>>>>>>>      From:   Santosh Chokhani[SMTP:[e-mail]]
>>>>>>>>      Sent:   Wednesday, May 08, 2002 2:07 PM
>>>>>>>>      To:     'Carlisle Adams'; 'David P. Kemp'
>>>>>>>>      Cc:     '500 list (E-mail)'; [e-mail]
>>>>>>>>      Subject:        RE: "Authentication" and 
>>>>"Signature" bits...
>>>>>>>>
>>>>>>>>
>>>>>>>>      Carlisle:
>>>>>>>>
>>>>>>>>      You make persuasive arguments in favor of existing 
>>>>>>>>implementation.
>>>>>>>>
>>>>>>>>      But, on technical grounds, there is a difference between 
>>>>>>>>signing a
>>>>>>>>      challenge and signing to some contents that you want
>>>>>>>>to provide
>>>>>>>>      digital signatures for.  We have this distinction for 
>>>>>>>>certificate and
>>>>>>>>      CRL and what we have proposed is meaningful and 
>>>>useful without
>>>>>>>>      getting into all the legal mumbo-jumbo.
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>I'm not talking about legal mumbo-jumbo.  All I'm saying is that

>>>>>>>>a human may be able to readily see the difference between random
>>>>>>>>data that has been
>>>>>>>>signed and meaningful data that has been signed, but in 
>>>>many cases,
>>>>>>>>software can't.  Certificates and CRLs have a very
>>>>>>>>specific, well-known
>>>>>>>>syntax, so software *can* distinguish between these and 
>>>>>>>>other data.  But
>>>>>>>>deciding whether the thing that has been signed had the 
>>>>>>>>intent of being for
>>>>>>>>authentication purposes (e.g., a random challenge, or a 
>>>>data origin
>>>>>>>>authentication e-mail) is a very hard problem.
>>>>>>>>
>>>>>>>>
>>>>>>>>I disagree that the distinction that has been proposed is 
>>>>>>>>meaningful and useful, completely independent of any legal 
>>>>>>>>interpretation.
>>>>>>>>
>>>>>>>>
>>>>>>>>Carlisle.
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>



Received: by above.proper.com (8.11.6/8.11.3) id g4AMdsL28802 for ietf-pkix-bks; Fri, 10 May 2002 15:39:54 -0700 (PDT)
Received: from smtp-1.llnl.gov (smtp-1.llnl.gov [128.115.250.81]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g4AMdrL28798 for <[e-mail]>; Fri, 10 May 2002 15:39:53 -0700 (PDT)
Received: from poptop.llnl.gov (localhost [127.0.0.1]) by smtp-1.llnl.gov (8.9.3/8.9.3/LLNL-gateway-1.0) with ESMTP id PAA06014; Fri, 10 May 2002 15:39:14 -0700 (PDT)
Received: from catalyst.llnl.gov (catalyst.llnl.gov [128.115.222.68]) by poptop.llnl.gov (8.8.8/LLNL-3.0.2/pop.llnl.gov-5.1) with ESMTP id PAA12306; Fri, 10 May 2002 15:39:13 -0700 (PDT)
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Version 4.3.2
Date: Fri, 10 May 2002 15:52:05 -0700
To: Hal Lockhart <[e-mail]>, Hal Lockhart	 <[e-mail]>, "'[e-mail]'"	 <[e-mail]>, [e-mail], [e-mail]
From: Tony Bartoletti <[e-mail]>
Subject: RE: "Authentication" and "Signature" bits...
Cc: [e-mail], [e-mail]
In-Reply-To: <[e-mail]. com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

At 02:43 PM 5/10/02 -0400, Hal Lockhart wrote:
>
> > I was unaware that this applied to signature keys, but it may
> > well be as
> > you say.
>
>Well a S/MIME cert would have DS=1 and NR=0, which is the case you 
>specified in your last message.

In my mind, it is antithetical to escrow an authentication key (granted, 
the authentication/encryption distinction may be problematic.)  If a 
process involves a "mix" of crypto and authentication, that application of 
crypto should be one where "permanent loss of data" is tolerable (and thus 
key-escrow unmotivated), as opposed to "bulk storage crypto".

(Just goes to show, a "crypto-key-usage-bit," as in 
crypto-versus-signature, may "mechanically" mean apply/don't-apply a 
crypto-algorithm, and yet it makes more sense (and is harder to 
distinguish) crypto to protect data in transit versus crypto for safe storage.)

On the lighter side ...

>However, I don't believe there is any conspiracy involved, or any deep 
>thinking of any kind. I think the reasoning goes something like this.
>
>1. Key escrow is a feature that might be useful in some cases.

An automobile-mounted flamethrower may be useful in some cases.

>2. The more features a product has, the better product it is, all other 
>things being equal.

A car with a flamethrower is better than one without, all other things 
being equal.

>3. The RFP should ask for key escrow.

I want one for my car, too.  ;)


Cheers,

____tony____



Tony Bartoletti 925-422-3881 <[e-mail]>
Information Operations, Warfare and Assurance Center
Lawrence Livermore National Laboratory
Livermore, CA 94551-9900






Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g4AKj2K26039 for ietf-pkix-bks; Fri, 10 May 2002 13:45:02 -0700 (PDT)
Received: from ext-mail.valicert.com ([66.206.205.11]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g4AKj0L26025 for <[e-mail]>; Fri, 10 May 2002 13:45:00 -0700 (PDT)
Received: from CONVERSION-DAEMON by ext-mail.valicert.com (PMDF V5.2-33 #46613) id <[e-mail]> for [e-mail]; Fri, 10 May 2002 13:40:42 -0700 (PDT)
Received: from polaris.valicert.com ([192.168.2.34]) by ext-mail.valicert.com (PMDF V5.2-33 #46613) with ESMTP id <[e-mail]>; Fri, 10 May 2002 13:40:42 -0700 (PDT)
Received: by polaris.valicert.com with Internet Mail Service (5.5.2653.19) id <JQL5CVNK>; Fri, 10 May 2002 13:44:30 -0700
Content-return: allowed
Date: Fri, 10 May 2002 13:44:29 -0700
From: Peter Williams <[e-mail]>
Subject: RE: "Authentication" and "Signature" bits...
To: "'Santosh Chokhani'" <[e-mail]>
Cc: [e-mail]
Message-id: <[e-mail]>
MIME-version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-type: text/plain; charset=iso-8859-1
Content-transfer-encoding: 8BIT
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Thanks for responding. Im working hard to really
understand the implications of your model, by
testing it out on protocol examples. I conclude by
suggesting we adopt the model, but work
still to find a home for the signals we
are formalising.

---------------

Correct my errors further, please, in the improved examples, if 
any: Ive seperated out the NR issues from KeyUsage, per your last message, 
and assigned actual internet/intranet protocols a set of appropriate
KeyUsages (per Santosh model).

1. OCSP

Basic OCSP responses: Use "digitalSignature/dataSign" KeyUsage

An OCSP Provider's optional upgrade of an OCSP response to provide some
NR assertions requires the provider's cert to bear an OCSP-NR oid in 
ExtendedKeyUsage  OR protocol specific means are used to signal the
additional NR semantics.

2. DPV

DPV responses: use "digitalSignature/dataSign" KeyUsage

A DPV Provider's formation of NR assertions is implicit, and does not
require that the provider's cert bears a DPV-NR oid in ExtendedKeyUsage.

3. OSI ROS-Bind variants

DAP/DSP/CMIP/ACSE-bind : use "authenthentication/nonceSign" KeyUsage

4. DAP/Directory operations

DAP operation request/responses: use "digitalSignature/dataSign" 
KeyUsage. A Directory Provider's optional upgrade of a signed DAP response
to 
provide some NR assertions means that the provider's cert bears an DAP-NR 
oid in ExtendedKeyUsage OR protocol specific means are used to signal 
NR grade of response.

5. https transport

if any of the X, above, are transferred over https: then
https responder entity has a distinct SSL cert from the X entity, 
where the SSL cert has "authenthentication/nonceSign"  and 
"keyAgreement or keyTransport" KeyUsages. 

The X entity using the https A-entity
has a seperate cert from the https entity. the X cert has
X keyUsages and extendedKeyUsages.

6. SSL+X protocol (e.g. dpv-s, cmp over SSL)

If any of the X application protocols, above, are bound in an application 
context to an SSL entity, then the X-responder has 1 (combined) X-protocol 
and SSL cert with  "authenthentication/nonceSign" and "keyAgreement or
keyTransport" 
KeyUsages (for the SSL requirements) unioned with "X" keyUsages and 
extendedKeyUsages (for the X requirements)

Conclusion:

I think the above realize the model and the intent of
your scheme, in practice. I improved my understanding
by (a) understanding that mere presence of replay nonces,
does not mandate "authentication" KeyUsage, and (b)
NR assertion signals are provided by means other than
KeyUsage bits.

I like your scheme. We now need to suggest
how it can be factored into X.509 without
upsetting legacy applications, whilst clearly
making a complete break with the confused past.

New bits in the KeyUsage bitfield or a new X.509 extension
seem appropriate, as Sharon suggests, rather than
simply redefining legacy bits. But your model for
clearing the confused notions about usages seems 
sound and workable, once we find a home for
the various signals.

>>>>-----Original Message-----
>>>>From: Santosh Chokhani [mailto:[e-mail]]
>>>>Sent: Friday, May 10, 2002 5:42 AM
>>>>To: 'Peter Williams'
>>>>Cc: [e-mail]
>>>>Subject: RE: "Authentication" and "Signature" bits...
>>>>
>>>>
>>>>Peter:
>>>>
>>>>There are several misunderstandings (in my mind) on your 
>>>>part of what I
>>>>suggest.  First of all, I do not say that there is NR or 
>>>>there is no NR.
>>>>That is why when people on this list talk about intent and 
>>>>software and
>>>>hardware between the human actions, I get lost.
>>>>
>>>>My proposal is very simple, just the way a key can be used for
>>>>encryption and signature verification or you can have two 
>>>>different keys
>>>>for encryption and signature verification, I want to differential
>>>>between signing challenges for entity authentication and 
>>>>signing data
>>>>that the user/application has formed/blessed.
>>>>
>>>>In these scenarios for OCSP and DPV, the digital signature 
>>>>(and not the
>>>>authentication) bit will be required to be set.  If both 
>>>>are set, it is
>>>>ok.  I realize that the protocol, includes echoing the 
>>>>challenge, but
>>>>the responder is formulating a transaction as opposed to signing a
>>>>challenge in order to provide authentication.
>>>>
>>>>Those who want to solve NR problem, are welcome to.  My 
>>>>precise point is
>>>>that NR is not a problem to be solved by PKC.  As it so 
>>>>happens, a key
>>>>that is used for digital signature and not for signing 
>>>>challenges may
>>>>have a better luck on NR, just like a key that is not used for dual
>>>>purpose of signature and encryption (since encryption key 
>>>>may have key
>>>>escrow feature to it). 
>>>>
>>>>-----Original Message-----
>>>>From: Peter Williams [mailto:[e-mail]] 
>>>>Sent: Thursday, May 09, 2002 5:43 PM
>>>>To: 'Santosh Chokhani'
>>>>Cc: [e-mail]
>>>>Subject: RE: "Authentication" and "Signature" bits...
>>>>
>>>>
>>>>Let me ask the dumb questions, and
>>>>then comment, publicly.
>>>>
>>>>
>>>>A1: 
>>>>
>>>>An OCSP responder inevitably signs
>>>>an OCSP responses, which contains a
>>>>nonce and highly-legalistic reliance data. The
>>>>data is sent, sometimes by a TTP grade
>>>>operator, to influence reliance
>>>>on certificates. There is
>>>>no intention that the OCSP response
>>>>is necessarily a set of NR assertions,
>>>>however.
>>>>
>>>>I think in your scheme, we
>>>>use:
>>>>
>>>>"nonceSign", "digitalSignature|dataSign"
>>>>
>>>>Is this correct?
>>>>
>>>>A2:
>>>>
>>>>A DPV responder will act
>>>>similarly to an OCSP responder,
>>>>with the added twist that its operator
>>>>necessarily makes NR assertions 
>>>>(by requirements of this WG), in 
>>>>addition to signing a nonce,
>>>>and various pieces of reliance
>>>>data to be used by a relying
>>>>party application in deciding
>>>>how to use a certificate path.
>>>>
>>>>I think in your scheme, we
>>>>use:
>>>>
>>>>"nonceSign", "digitalSignature|dataSign"
>>>>
>>>>Is this correct?
>>>>
>>>>Conclusion 1: in the new scheme, there
>>>>is now no way - using certificates - for an OCSP 
>>>>provider to signal that it intends to upgrade its 
>>>>OCSP-based validation service to make NR-grade 
>>>>assertions. If an OCSP entity
>>>>is to upgrade its assurance level to
>>>>offer NR, then it would have to signal
>>>>this in an OCSP response extension. That is,
>>>>we tag the grade of OCSP signing assurance
>>>>via an attribute of the signature (essentially)
>>>>in the response, not the certificate.
>>>>
>>>>Conclusion 2: in the case of DPV, with
>>>>the new scheme, there is no need
>>>>to tag the DPV response with any
>>>>NR extension/field signal, as ALL DPV responses 
>>>>are NR assertions, by protocol definition. That
>>>>is, one cannot run a DPV server
>>>>except as a NR service provider. Obviously
>>>>the precise meaning of a given signer's NR
>>>>semantics will be a function 
>>>>of the posted "signing policy" of the 
>>>>subscriber.
>>>>
>>>>If this is all correct, I'm happy with all this. It 
>>>>removes from the CA the technical perogative of controlling what
>>>>subscribers can do with NR assertions - placing control in 
>>>>the hands of
>>>>the protocol designers (just like 
>>>>X.400/EDIFACT did) and the  protocol 
>>>>operators who perform the act
>>>>of signing. This scheme aligns
>>>>with the model of PMI's
>>>>NR assertions.
>>>>
>>>>In terms of PKIX architecture, relying parties
>>>>determine when a security service is a subclass
>>>>of NR assertions - based on the protocol
>>>>definition, and by inspecting the subscribers
>>>>signing policy. This contrasts with
>>>>the current scheme - built into PKIX-1 and replacements, 
>>>>in which one looks to the CA CP.
>>>>
>>>>Peter.
>>>>
>>>>
>>>>>>>>-----Original Message-----
>>>>>>>>From: Tom Gindin [mailto:[e-mail]]
>>>>>>>>Sent: Thursday, May 09, 2002 1:42 PM
>>>>>>>>To: Carlisle Adams
>>>>>>>>Cc: 'David P. Kemp'; 'Santosh Chokhani'; '500 list (E-mail)'; 
>>>>>>>>[e-mail]
>>>>>>>>Subject: RE: "Authentication" and "Signature" bits...
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>      Carlisle:
>>>>>>>>
>>>>>>>>      Actually, distinguishing nonces from documents is not
>>>>>>>>a very hard
>>>>>>>>problem (the lengths are radically different).  The 
>>>>>>>>difficulty would be in
>>>>>>>>distinguishing challenges which are inside larger objects 
>>>>>>>>from otherwise
>>>>>>>>similar objects.
>>>>>>>>
>>>>>>>>            Tom Gindin
>>>>>>>>
>>>>>>>>Carlisle Adams <[e-mail]>@mail.imc.org on
>>>>>>>>05/08/2002
>>>>>>>>02:15:28 PM
>>>>>>>>
>>>>>>>>Sent by:    [e-mail]
>>>>>>>>
>>>>>>>>
>>>>>>>>To:    Carlisle Adams <[e-mail]>, "'David 
>>>>>>>>P. Kemp'"
>>>>>>>>       <[e-mail]>, "'Santosh Chokhani'"
>>>>>>>>       <[e-mail]>
>>>>>>>>cc:    "'500 list (E-mail)'" <[e-mail]>,
>>>>>>>>       [e-mail]
>>>>>>>>Subject:    RE: "Authentication" and "Signature" bits...
>>>>>>>>
>>>>>>>>
>>>>>>>>Hi Santosh,
>>>>>>>>
>>>>>>>>
>>>>>>>>      ----------
>>>>>>>>      From:   Santosh Chokhani[SMTP:[e-mail]]
>>>>>>>>      Sent:   Wednesday, May 08, 2002 2:07 PM
>>>>>>>>      To:     'Carlisle Adams'; 'David P. Kemp'
>>>>>>>>      Cc:     '500 list (E-mail)'; [e-mail]
>>>>>>>>      Subject:        RE: "Authentication" and 
>>>>"Signature" bits...
>>>>>>>>
>>>>>>>>
>>>>>>>>      Carlisle:
>>>>>>>>
>>>>>>>>      You make persuasive arguments in favor of existing
>>>>>>>>implementation.
>>>>>>>>
>>>>>>>>      But, on technical grounds, there is a difference
>>>>>>>>between signing a
>>>>>>>>      challenge and signing to some contents that you want 
>>>>>>>>to provide
>>>>>>>>      digital signatures for.  We have this distinction for 
>>>>>>>>certificate and
>>>>>>>>      CRL and what we have proposed is meaningful and 
>>>>useful without
>>>>>>>>      getting into all the legal mumbo-jumbo.
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>I'm not talking about legal mumbo-jumbo.  All I'm saying is
>>>>>>>>that a human
>>>>>>>>may be able to readily see the difference between random 
>>>>>>>>data that has been
>>>>>>>>signed and meaningful data that has been signed, but in 
>>>>many cases,
>>>>>>>>software can't.  Certificates and CRLs have a very 
>>>>>>>>specific, well-known
>>>>>>>>syntax, so software *can* distinguish between these and 
>>>>>>>>other data.  But
>>>>>>>>deciding whether the thing that has been signed had the 
>>>>>>>>intent of being for
>>>>>>>>authentication purposes (e.g., a random challenge, or a 
>>>>data origin
>>>>>>>>authentication e-mail) is a very hard problem.
>>>>>>>>
>>>>>>>>
>>>>>>>>I disagree that the distinction that has been proposed is
>>>>>>>>meaningful and
>>>>>>>>useful, completely independent of any legal interpretation.
>>>>>>>>
>>>>>>>>
>>>>>>>>Carlisle.
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g4AIm8210031 for ietf-pkix-bks; Fri, 10 May 2002 11:48:08 -0700 (PDT)
Received: from dymwsm05.mailwatch.com (dymwsm05.mailwatch.com [204.253.83.41]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g4AIm7L10025 for <[e-mail]>; Fri, 10 May 2002 11:48:07 -0700 (PDT)
Received: from mwsc0206.mw4.mailwatch.com (mwsc0206.mw4.mailwatch.com [204.253.83.136]) by dymwsm05.mailwatch.com (8.11.0/8.11.0) with ESMTP id g4AIln729157 for <[e-mail]>; Fri, 10 May 2002 14:47:49 -0400
Received: from mail pickup service by mwsc0206.mw4.mailwatch.com with Microsoft SMTPSVC; Fri, 10 May 2002 14:47:49 -0400
Received: from 204.253.83.72 ([204.253.83.72]) by MWSC0206 with SMTP id 00020006e69be971-5927-43a7-a3a7-6f2f9cef00ff;	 Fri, 10 May 2002 14:47:48 -0500
Received: from bigbird.entegrity.com (bigbird.gradient.com [192.92.110.50])	by dymwsm10.mailwatch.com (8.11.0/8.11.0) with ESMTP id g4AIlmT27987;	Fri, 10 May 2002 14:47:48 -0400
Received: by bigbird.gradient.com with Internet Mail Service (5.5.2650.10)	id <KPCDABZZ>; Fri, 10 May 2002 14:43:57 -0400
Message-ID: <[e-mail]>
From: Hal Lockhart <[e-mail]>
To: "'Tony Bartoletti'" <[e-mail]>, Hal Lockhart	 <[e-mail]>, "'[e-mail]'"	 <[e-mail]>, [e-mail], [e-mail]
Cc: [e-mail], [e-mail]
Subject: RE: "Authentication" and "Signature" bits...
Date: Fri, 10 May 2002 14:43:56 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.10)
Content-Type: multipart/alternative;	boundary="----_=_NextPart_001_01C1F852.A43CAD72"
HOP-COUNT: 1
X-MAILWATCH-INSTANCEID: 01020006e69be971-5927-43a7-a3a7-6f2f9cef00ff
X-OriginalArrivalTime: 10 May 2002 18:47:49.0023 (UTC) FILETIME=[2E8FBAF0:01C1F853]
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

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_01C1F852.A43CAD72
Content-Type: text/plain;
	charset="ISO-8859-1"

 
> I was unaware that this applied to signature keys, but it may 
> well be as 
> you say.

Well a S/MIME cert would have DS=1 and NR=0, which is the case you specified
in your last message. 

However, I don't believe there is any conspiracy involved, or any deep
thinking of any kind. I think the reasoning goes something like this.

1. Key escrow is a feature that might be useful in some cases.
2. The more features a product has, the better product it is, all other
things being equal.
3. The RFP should ask for key escrow.

Hal

------_=_NextPart_001_01C1F852.A43CAD72
Content-Type: text/html;
	charset="ISO-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3DISO-8859-1">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2448.0">
<TITLE>RE: &quot;Authentication&quot; and &quot;Signature&quot; =
bits...</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=3D2>&nbsp;</FONT>
<BR><FONT SIZE=3D2>&gt; I was unaware that this applied to signature =
keys, but it may </FONT>
<BR><FONT SIZE=3D2>&gt; well be as </FONT>
<BR><FONT SIZE=3D2>&gt; you say.</FONT>
</P>

<P><FONT SIZE=3D2>Well a S/MIME cert would have DS=3D1 and NR=3D0, =
which is the case you specified in your last message. </FONT>
</P>

<P><FONT SIZE=3D2>However, I don't believe there is any conspiracy =
involved, or any deep thinking of any kind. I think the reasoning goes =
something like this.</FONT></P>

<P><FONT SIZE=3D2>1. Key escrow is a feature that might be useful in =
some cases.</FONT>
<BR><FONT SIZE=3D2>2. The more features a product has, the better =
product it is, all other things being equal.</FONT>
<BR><FONT SIZE=3D2>3. The RFP should ask for key escrow.</FONT>
</P>

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

</BODY>
</HTML>
------_=_NextPart_001_01C1F852.A43CAD72--


Received: by above.proper.com (8.11.6/8.11.3) id g4AIZu208371 for ietf-pkix-bks; Fri, 10 May 2002 11:35:56 -0700 (PDT)
Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g4AIZsL08366 for <[e-mail]>; Fri, 10 May 2002 11:35:55 -0700 (PDT)
Received: from sunlabs.East.Sun.COM ([129.148.75.250]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA18105; Fri, 10 May 2002 12:36:15 -0600 (MDT)
Received: from sun.com (dhcp75-167 [129.148.75.167]) by sunlabs.East.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.2) with ESMTP id OAA06251; Fri, 10 May 2002 14:35:53 -0400 (EDT)
Message-ID: <[e-mail]>
Date: Fri, 10 May 2002 14:32:40 -0400
From: Steve Hanna <[e-mail]>
X-Mailer: Mozilla 4.75 [en] (WinNT; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Markus Lorch <[e-mail]>
CC: [e-mail]
Subject: Re: EMAIL attribute in x500 name
References: <[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

While we are clarifying things, I will clarify that Sun's
Java implementation of an X.500 name (and any compliant
implementation of Java 2 Standard Edition 1.4) can handle
either of these attributes.

Note that there is no standard keyword for these OIDs.
Some people use "E=", some use "EMAIL=", etc. RFC 1779,
RFC 2253, and draft-ietf-ldapbis-dn-07.txt all say that
when representing an X.500 name as a string, you should
use the dotted decimal syntax for these OIDs, since there
is no standard keyword. That's what we do.

Thanks,

Steve Hanna

Tom Gindin wrote:
> 
>       Markus:
> 
>       There are two, not one, major attributes of this type.  You found
> EmailAddr { 1 2 840 113549 1 9 1} defined by PKCS#9, apparently.  There is
> also Mail or rfc822Mailbox, defined by RFC 1274 { 0 9 2342 19200300 100 1 3
> } .  They have essentially similar meanings, although different OID's.
> 
>             Tom Gindin
> 
> "Markus Lorch" <[e-mail]>@mail.imc.org on 05/10/2002 09:36:42 AM
> 
> Sent by:    [e-mail]
> 
> To:    <[e-mail]>
> cc:
> Subject:    EMAIL attribute in x500 name
> 
> I ran accross the question if the attribute /EMAIL= in an X.500
> name (issuer or subject in a X.509v3 cert) is standardized or at
> least what OID is assigned to it.
> 
> I can only find the attribute /EMAILADDR which apprears to have an
> RSA security OID. The /EMAIL attribute is often found in x.509
> certificates from "openCA" CA's. However, it is not supported by
> Sun's java implementation of an X.500 name.
> 
> I have been pointed to use the /EMAILADDR attribute - however
> from rfc2459 it appears that this attribute should no longer
> be used (it mentions it is deprecated).
> 
> It would be great if somebody has a pointer for me
> 
> Thanks
> 
> Markus
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> Markus Lorch
> Doctoral Student in Computer Science
> Virginia Tech
> http://csgrad.cs.vt.edu/~mlorch


Received: by above.proper.com (8.11.6/8.11.3) id g4AI1T806918 for ietf-pkix-bks; Fri, 10 May 2002 11:01:29 -0700 (PDT)
Received: from smtp-2.llnl.gov (smtp-2.llnl.gov [128.115.250.82]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g4AI1SL06914 for <[e-mail]>; Fri, 10 May 2002 11:01:28 -0700 (PDT)
Received: from poptop.llnl.gov (localhost [127.0.0.1]) by smtp-2.llnl.gov (8.9.3/8.9.3/LLNL-gateway-1.0) with ESMTP id KAA09166; Fri, 10 May 2002 10:50:58 -0700 (PDT)
Received: from catalyst.llnl.gov (catalyst.llnl.gov [128.115.222.68]) by poptop.llnl.gov (8.8.8/LLNL-3.0.2/pop.llnl.gov-5.1) with ESMTP id KAA15527; Fri, 10 May 2002 10:50:48 -0700 (PDT)
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Version 4.3.2
Date: Fri, 10 May 2002 11:03:41 -0700
To: Hal Lockhart <[e-mail]>, "'[e-mail]'" <[e-mail]>, [e-mail], [e-mail]
From: Tony Bartoletti <[e-mail]>
Subject: RE: "Authentication" and "Signature" bits...
Cc: [e-mail], [e-mail]
In-Reply-To: <[e-mail]. com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

At 11:03 AM 5/10/02 -0400, Hal Lockhart wrote:

>Also of particular interest to you Tony, all of the  US government RFPs I 
>have seen (including DOE) demand a key recovery capability. I don't know 
>if this is really being used, but it has become a product checkoff item.

Hal,

I was unaware that this applied to signature keys, but it may well be as 
you say.  In that case, it would make sense to have the ability for the CA 
to assert in the certificate that the private key was/was-never in their 
possession (rather than in a policy that may be variably interpreted.)

(I assume the rationale is that a very-strong signature key can be a 
very-strong crypto-key, and not that the government reserves the right to 
impersonate me, but that may be naive.  I suppose all governments reserve 
to themselves the right to make the false appear true, in the name of 
national security ... )

____tony____




Tony Bartoletti 925-422-3881 <[e-mail]>
Information Operations, Warfare and Assurance Center
Lawrence Livermore National Laboratory
Livermore, CA 94551-9900






Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g4AHexw05786 for ietf-pkix-bks; Fri, 10 May 2002 10:40:59 -0700 (PDT)
Received: from mtiwmhc21.worldnet.att.net (mtiwmhc21.worldnet.att.net [204.127.131.46]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g4AHewL05782 for <[e-mail]>; Fri, 10 May 2002 10:40:58 -0700 (PDT)
Received: from Chokhani ([12.91.131.176]) by mtiwmhc21.worldnet.att.net (InterMail vM.4.01.03.27 201-229-121-127-20010626) with ESMTP id <20020510174052.LWKU24238.mtiwmhc21.worldnet.att.net@Chokhani>; Fri, 10 May 2002 17:40:52 +0000
From: "Santosh Chokhani" <[e-mail]>
To: "'500 list \(E-mail\)'" <[e-mail]>, <[e-mail]>
Subject: RE: "Authentication" and "Signature" bits...
Date: Fri, 10 May 2002 13:42:23 -0400
Message-ID: <005601c1f84a$0b3537f0$a300a8c0@Chokhani>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_0057_01C1F828.842397F0"
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.2627
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4910.0300
In-Reply-To: <[e-mail]>
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

This is a multi-part message in MIME format.

------=_NextPart_000_0057_01C1F828.842397F0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit

Sharon:
 
I commend you for a good and succinct summary.
 
The two issues are intertwined in the sense that the only authentication
and digital signature are the only two meaningful distinctions between
the two bits.  NR is a slippery slope.  That has been the most common
comment on this thread.
 
I think saying that making what crypto operation is performed on the
data is changing the semantics, is calling the proposal exactly what it
is NOT.
 
Just the way there is a separate bit for certSign and cRLSign, we have
separate bits for signing data and challenges.
 
Granted this may break backward compatibility, but whether it does or
not and to what degree it does, the vendors have not provided any data
as to which of the four combinations breaks the backward compatibility.
 
FYI, Bill Burr's suggestion while a prudent one and probably backward
compatible with the implementations, is the one that changes the
semantics of the extension.  Please read the definition of the extension
and also note that all the other bits except NR are enforced by the
client and not the CA.
 
-----Original Message-----
From: [e-mail] [mailto:[e-mail]]
On Behalf Of Sharon Boeyen
Sent: Friday, May 10, 2002 9:52 AM
To: '500 list (E-mail)'; [e-mail]
Cc: Trevor Freeman (E-mail); Stefan Santeeson (E-mail)
Subject: RE: "Authentication" and "Signature" bits...



I'd like to try to bring the discussion back full circle and separate
what I believe are two distinct issues.
 
Issue 1: The current text that describes the digital signature and non
repudiation bits in X.509 have caused confusion and a request was made
to separate the description of digital signature from that for
non-repudiation and to clarify the meaning of the non-repudiation bit in
the keyUsage extension.
 
Issue 2: Some people would like a way to be able indicate that one key
should be used for authentication and another for signing docs (I know
I'm oversimplifying it).
 
I do not believe that we can or even should attempt to address issue 2
as part of the solution to issue 1. I agree with Trevor that making this
change to the semantics of the bits is not backward compatible and we
cannot do that with keeping the same OID for the keyUsage extension. 
 
The keyUsage extension is in wide use today and I firmly believe we
should not do anything that would cause most deployed environments to
break. I believe that replacing the current 2 bits with the proposed new
bits would do so. The digital signature bit is widely used today to sign
all sorts of objects including all of those mentioned in this whole
debate. In some cases it is used for challenge/response authentication,
in others it is used for data origin authentication and integrity. The
certificate that used to verify my digital signature on signed emails
AND the certificate that is used by me for online banking with my bank
both have the digital signature bit set. We should not do anything that
would render such implementations non-conformant. 
 
To address issue 1 I believe we should, as Stefan originally requested,
separate the description of digital signature from non repudiation for
the bits and try to clarify the role of the non-repudiation bit if that
is possible. However, fundamentally it is the non-repudiation bit and
the other is the digital signature bit. They are not authentication and
data signing bits, never were and never should be.
 
To address issue 2, I'm not yet convinced that X.509, or PKIX really
need this separation. However, if there is a requirement, I see this
more along the lines of the APPLICATION of keys that we currently define
through the extended key usage extension. I would not want to see the
current keyUsage extension replaced in favor of this new flavor. Rather,
leave the current extension with its original semantics (just clarify
them) and address this other aspect through some other mechanism, if
required at all. 
 
>From my own standpoint, I'd prefer to focus on issue 1 first, as that is
the one that raised to the X.509 group as a potential defect in that
standard.
 
>From a process standpoint re X.509 I wanted to let folks know that Hoyt
and I do plan to discuss the whole set of messages that have been
flowing on the X.500, PKIX and ABA lists on this topic and then decide
what, if anything, we should propose be done in X.509. However because
of our overlapping vacation schedule, you won't be hearing that from us
until the end of the month. 
 
Cheers,
Sharon
 
 


------=_NextPart_000_0057_01C1F828.842397F0
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Dus-ascii">
<TITLE>Message</TITLE>

<META content=3D"MSHTML 5.50.4915.500" name=3DGENERATOR></HEAD>
<BODY>
<DIV><FONT face=3DArial color=3D#0000ff size=3D2><SPAN=20
class=3D266573417-10052002>Sharon:</SPAN></FONT></DIV>
<DIV><FONT face=3DArial color=3D#0000ff size=3D2><SPAN=20
class=3D266573417-10052002></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial color=3D#0000ff size=3D2><SPAN =
class=3D266573417-10052002>I=20
commend you for a good and succinct summary.</SPAN></FONT></DIV>
<DIV><FONT face=3DArial color=3D#0000ff size=3D2><SPAN=20
class=3D266573417-10052002></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial color=3D#0000ff size=3D2><SPAN =
class=3D266573417-10052002>The=20
two&nbsp;issues are intertwined in the sense that the only =
authentication and=20
digital signature are the only two meaningful distinctions between the =
two=20
bits.&nbsp; NR is a slippery slope.&nbsp; That has been the most common =
comment=20
on this thread.</SPAN></FONT></DIV>
<DIV><FONT face=3DArial color=3D#0000ff size=3D2><SPAN=20
class=3D266573417-10052002></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial color=3D#0000ff size=3D2><SPAN =
class=3D266573417-10052002>I=20
think saying that making what crypto operation is performed on the data =
is=20
changing the semantics, is calling the proposal exactly what it is=20
NOT.</SPAN></FONT></DIV>
<DIV><FONT face=3DArial color=3D#0000ff size=3D2><SPAN=20
class=3D266573417-10052002></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial color=3D#0000ff size=3D2><SPAN =
class=3D266573417-10052002>Just=20
the way there is a separate bit for certSign and cRLSign, we have =
separate bits=20
for signing data and challenges.</SPAN></FONT></DIV>
<DIV><FONT face=3DArial color=3D#0000ff size=3D2><SPAN=20
class=3D266573417-10052002></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial color=3D#0000ff size=3D2><SPAN=20
class=3D266573417-10052002>Granted this may break backward =
compatibility, but=20
whether it does or not and to what degree it does,&nbsp;the vendors have =
not=20
provided any data as to which of the four combinations breaks the =
backward=20
compatibility.</SPAN></FONT></DIV>
<DIV><FONT face=3DArial color=3D#0000ff size=3D2><SPAN=20
class=3D266573417-10052002></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial color=3D#0000ff size=3D2><SPAN =
class=3D266573417-10052002>FYI,=20
Bill Burr's suggestion while a prudent one and probably backward =
compatible with=20
the implementations, is the one that changes the semantics of the=20
extension.&nbsp; Please read the definition of the extension and also =
note that=20
all the other bits except NR are enforced by the client and not the=20
CA.</SPAN></FONT></DIV>
<DIV><FONT face=3DArial color=3D#0000ff size=3D2><SPAN=20
class=3D266573417-10052002></SPAN></FONT>&nbsp;</DIV>
<DIV></DIV>
<DIV><FONT face=3DTahoma size=3D2>-----Original =
Message-----<BR><B>From:</B>=20
[e-mail] [mailto:[e-mail]] <B>On =
Behalf=20
Of </B>Sharon Boeyen<BR><B>Sent:</B> Friday, May 10, 2002 9:52 =
AM<BR><B>To:</B>=20
'500 list (E-mail)'; [e-mail]<BR><B>Cc:</B> Trevor Freeman =
(E-mail);=20
Stefan Santeeson (E-mail)<BR><B>Subject:</B> RE: "Authentication" and=20
"Signature" bits...<BR><BR></DIV></FONT>
<BLOCKQUOTE dir=3Dltr style=3D"MARGIN-RIGHT: 0px">
  <DIV><FONT face=3DArial color=3D#0000ff size=3D2><SPAN =
class=3D460502913-10052002>I'd=20
  like to try to bring the discussion back full circle and separate what =
I=20
  believe are two distinct issues.</SPAN></FONT></DIV>
  <DIV><FONT face=3DArial color=3D#0000ff size=3D2><SPAN=20
  class=3D460502913-10052002></SPAN></FONT>&nbsp;</DIV>
  <DIV><FONT face=3DArial color=3D#0000ff size=3D2><SPAN=20
  class=3D460502913-10052002>Issue 1: The current text that describes =
the digital=20
  signature and non repudiation bits in X.509 have caused confusion and =
a=20
  request was made to separate the description of digital signature from =
that=20
  for non-repudiation and to clarify the meaning of the non-repudiation =
bit in=20
  the keyUsage extension.</SPAN></FONT></DIV>
  <DIV><FONT face=3DArial color=3D#0000ff size=3D2><SPAN=20
  class=3D460502913-10052002></SPAN></FONT>&nbsp;</DIV>
  <DIV><FONT face=3DArial color=3D#0000ff size=3D2><SPAN=20
  class=3D460502913-10052002>Issue 2: Some people would like a way to be =
able=20
  indicate that one key should be used for authentication and another =
for=20
  signing docs (I know I'm oversimplifying it).</SPAN></FONT></DIV>
  <DIV><FONT face=3DArial color=3D#0000ff size=3D2><SPAN=20
  class=3D460502913-10052002></SPAN></FONT>&nbsp;</DIV>
  <DIV><FONT face=3DArial color=3D#0000ff size=3D2><SPAN =
class=3D460502913-10052002>I do=20
  not believe that we can or even should attempt to address issue 2 as =
part of=20
  the solution to issue 1. I agree with Trevor that making this change =
to the=20
  semantics of the bits is not backward compatible and we cannot do that =
with=20
  keeping the same OID for the keyUsage extension. </SPAN></FONT></DIV>
  <DIV><FONT face=3DArial color=3D#0000ff size=3D2><SPAN=20
  class=3D460502913-10052002></SPAN></FONT><FONT face=3DArial =
color=3D#0000ff=20
  size=3D2><SPAN class=3D460502913-10052002></SPAN></FONT>&nbsp;</DIV>
  <DIV><FONT face=3DArial color=3D#0000ff size=3D2><SPAN =
class=3D460502913-10052002>The=20
  keyUsage extension is in wide use today and I firmly believe we should =
not do=20
  anything that would cause most deployed environments to break. I =
believe that=20
  replacing the current 2 bits with the proposed new bits would do so. =
The=20
  digital signature bit is widely used today to sign all sorts of =
objects=20
  including all of those mentioned in this whole debate. In some cases =
it is=20
  used for challenge/response authentication, in others it is used for =
data=20
  origin authentication and integrity. The certificate that used to =
verify my=20
  digital signature on signed emails AND the certificate that is used by =
me for=20
  online banking with my bank both have the digital signature bit set. =
We should=20
  not do anything that would render such implementations non-conformant. =

  </SPAN></FONT></DIV>
  <DIV><FONT face=3DArial color=3D#0000ff size=3D2><SPAN=20
  class=3D460502913-10052002></SPAN></FONT>&nbsp;</DIV>
  <DIV><FONT face=3DArial color=3D#0000ff size=3D2><SPAN =
class=3D460502913-10052002>To=20
  address issue 1 I believe we should, as Stefan originally requested, =
separate=20
  the description of digital signature from non repudiation for the bits =
and try=20
  to clarify the role of the non-repudiation bit if that is possible. =
However,=20
  fundamentally it is the non-repudiation bit and the other is the =
digital=20
  signature bit. They are not authentication and data signing bits, =
never were=20
  and never should be.</SPAN></FONT></DIV>
  <DIV><FONT face=3DArial color=3D#0000ff size=3D2><SPAN=20
  class=3D460502913-10052002></SPAN></FONT>&nbsp;</DIV>
  <DIV><FONT face=3DArial color=3D#0000ff size=3D2><SPAN =
class=3D460502913-10052002>To=20
  address issue 2, I'm not yet convinced that X.509, or PKIX really need =
this=20
  separation. However, if there is a requirement, I see this more along =
the=20
  lines of the APPLICATION of keys that we currently define through the =
extended=20
  key usage extension. I would not want to see the current keyUsage =
extension=20
  replaced in favor of this new flavor. Rather, leave the current =
extension with=20
  its original semantics (just clarify them) and address this other =
aspect=20
  through some other mechanism, if required at all. </SPAN></FONT></DIV>
  <DIV><FONT face=3DArial color=3D#0000ff size=3D2><SPAN=20
  class=3D460502913-10052002></SPAN></FONT>&nbsp;</DIV>
  <DIV><FONT face=3DArial color=3D#0000ff size=3D2><SPAN =
class=3D460502913-10052002>From=20
  my own standpoint, I'd prefer to focus on issue 1 first, as that is =
the one=20
  that raised to the X.509 group as a potential defect in that=20
  standard.</SPAN></FONT></DIV>
  <DIV><FONT face=3DArial color=3D#0000ff size=3D2><SPAN=20
  class=3D460502913-10052002></SPAN></FONT>&nbsp;</DIV>
  <DIV><FONT face=3DArial color=3D#0000ff size=3D2><SPAN =
class=3D460502913-10052002>From=20
  a process standpoint re X.509 I wanted to let folks know that Hoyt and =
I do=20
  plan to discuss the whole set of messages that have been flowing on =
the X.500,=20
  PKIX and ABA lists on this topic and then decide what, if anything, we =
should=20
  propose be done in X.509. However because of our overlapping vacation=20
  schedule, you won't be hearing that from us until the end of the =
month.=20
  </SPAN></FONT></DIV>
  <DIV><FONT face=3DArial color=3D#0000ff size=3D2><SPAN=20
  class=3D460502913-10052002></SPAN></FONT>&nbsp;</DIV>
  <DIV><FONT face=3DArial color=3D#0000ff size=3D2><SPAN=20
  class=3D460502913-10052002>Cheers,</SPAN></FONT></DIV>
  <DIV><FONT face=3DArial color=3D#0000ff size=3D2><SPAN=20
  class=3D460502913-10052002>Sharon</SPAN></FONT></DIV>
  <DIV><FONT face=3DArial color=3D#0000ff size=3D2><SPAN=20
  class=3D460502913-10052002></SPAN></FONT>&nbsp;</DIV>
  <DIV><FONT face=3DArial color=3D#0000ff size=3D2><SPAN=20
  =
class=3D460502913-10052002></SPAN></FONT>&nbsp;</DIV></BLOCKQUOTE></BODY>=
</HTML>

------=_NextPart_000_0057_01C1F828.842397F0--



Received: by above.proper.com (8.11.6/8.11.3) id g4AHCYr05117 for ietf-pkix-bks; Fri, 10 May 2002 10:12:34 -0700 (PDT)
Received: from anchor-post-30.mail.demon.net (anchor-post-30.mail.demon.net [194.217.242.88]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g4AHCWL05113 for <[e-mail]>; Fri, 10 May 2002 10:12:32 -0700 (PDT)
Received: from drh-consultancy.demon.co.uk ([193.237.150.98] helo=gemplus.com) by anchor-post-30.mail.demon.net with esmtp (Exim 3.35 #1) id 176DwR-0001BP-0U for [e-mail]; Fri, 10 May 2002 18:12:27 +0100
Message-ID: <[e-mail]>
Date: Fri, 10 May 2002 18:12:35 +0100
From: Dr S N Henson <[e-mail]>
X-Mailer: Mozilla 4.79 [en] (Win98; U)
X-Accept-Language: en
MIME-Version: 1.0
To: [e-mail]
Subject: Re: "Authentication" and "Signature" bits...
References: <[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Peter Gutmann wrote:
> 
> Hal Lockhart <[e-mail]> writes:
> 
> >(You might think the random number issue would be moot by now, but I have yet
> >to see a commercial security product of any kind, not just PKI, that uses the
> >Pentium III hardware RNG.)
> 
> I use it in my code, but given that the user needs to go through a nontrivial
> install process to get a special driver set up for it, I think the number of
> users it gets is... small.  I've seen it somewhere else as well (OpenSSL?), 

Yes, newer versions of OpenSSL will use it on Windows builds if the
aforementioned driver is set up.

Steve.
-- 
Dr Stephen N. Henson.   http://www.drh-consultancy.demon.co.uk/
Personal Email: [e-mail] 
Senior crypto engineer, Gemplus: http://www.gemplus.com/
Core developer of the   OpenSSL project: http://www.openssl.org/
Business Email: [e-mail] PGP key: via homepage.



Received: by above.proper.com (8.11.6/8.11.3) id g4AFc3602399 for ietf-pkix-bks; Fri, 10 May 2002 08:38:03 -0700 (PDT)
Received: from hermes.cs.auckland.ac.nz (hermes.cs.auckland.ac.nz [130.216.35.151]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g4AFc1L02394 for <[e-mail]>; Fri, 10 May 2002 08:38:01 -0700 (PDT)
Received: from ruru.cs.auckland.ac.nz (ruru-nfs.cs.auckland.ac.nz [130.216.35.12]) by hermes.cs.auckland.ac.nz (8.12.3/8.12.3) with ESMTP id g4AFV5aq030341; Sat, 11 May 2002 03:31:05 +1200
Received: (from pgut001@localhost) by ruru.cs.auckland.ac.nz (8.9.3/8.8.6/cs-slave) id DAA365212; Sat, 11 May 2002 03:31:04 +1200 (NZST) (sender [e-mail])
Date: Sat, 11 May 2002 03:31:04 +1200 (NZST)
Message-ID: <[e-mail]>
From: [e-mail] (Peter Gutmann)
To: [e-mail], [e-mail], [e-mail], [e-mail], [e-mail]
Subject: RE: "Authentication" and "Signature" bits...
Cc: [e-mail], [e-mail]
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Hal Lockhart <[e-mail]> writes:

>Commonly cited reasons include ability to generate higher quality random
>numbers and performance issues around time to generate large keys.

I've heard this a couple of times, but each time it was being used as an excuse
for the fact that the CA wanted to do things its own proprietary way and this
was the best justification they could find for it.  In at least two cases the
CA had implemented its own software, incorrectly, and was desperately trying to
avoid having to fix it to interoperate with other vendors' products, leading to
one manager to comment that "It used to be said that patriotism was the last
refuge of the the scoundrel.  Now it's security" :-).

(I'm sure there are CAs who are genuinely concerned about security, but it also
 seems to be a very convenient excuse to ensure that things get done the CAs
 way and no other).

>(You might think the random number issue would be moot by now, but I have yet
>to see a commercial security product of any kind, not just PKI, that uses the
>Pentium III hardware RNG.)

I use it in my code, but given that the user needs to go through a nontrivial
install process to get a special driver set up for it, I think the number of
users it gets is... small.  I've seen it somewhere else as well (OpenSSL?), and
BSAFE uses it too, or at least RSADSI issued a press release saying it did.  In
any case it's not a silver bullet, I go into the requirements for secure random
number generation in some detail in
http://www.cryptoapps.com/~peter/06_random.pdf and I'd rate the PIII hardware
RNG at about the same level as /dev/random, ie one of a number of sources which
you can use as input to a full RNG.

Getting back to scoundrels running CAs, my standard reply to claims about "we
trust our RNG more" is to challenge them to demonstrate how their RNG is more
secure than the one I describe in the paper mentioned above.  I've never had
anyone take me up on that, which only reinforces the feeling that security
isn't the real reason they're doing it.

Peter.



Received: by above.proper.com (8.11.6/8.11.3) id g4AFSxg01746 for ietf-pkix-bks; Fri, 10 May 2002 08:28:59 -0700 (PDT)
Received: from e1.ny.us.ibm.com (e1.ny.us.ibm.com [32.97.182.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g4AFSvL01740 for <[e-mail]>; Fri, 10 May 2002 08:28:57 -0700 (PDT)
Received: from northrelay02.pok.ibm.com (northrelay02.pok.ibm.com [9.56.224.150]) by e1.ny.us.ibm.com (8.12.2/8.12.2) with ESMTP id g4AFSrAH046920; Fri, 10 May 2002 11:28:53 -0400
Received: from d01ml062.pok.ibm.com (d01ml062.pok.ibm.com [9.117.250.163]) by northrelay02.pok.ibm.com (8.11.1m3/NCO/VER6.1) with ESMTP id g4AFSo7100966; Fri, 10 May 2002 11:28:50 -0400
Importance: Normal
Sensitivity: 
Subject: Re: EMAIL attribute in x500 name
To: "Markus Lorch" <[e-mail]>
Cc: <[e-mail]>
X-Mailer: Lotus Notes Release 5.0.7  March 21, 2001
Message-ID: <[e-mail]>
From: "Tom Gindin" <[e-mail]>
Date: Fri, 10 May 2002 11:28:53 -0400
X-MIMETrack: Serialize by Router on D01ML062/01/M/IBM(Release 5.0.10 |March 28, 2002) at 05/10/2002 11:28:51 AM
MIME-Version: 1.0
Content-type: text/plain; charset=us-ascii
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

      Markus:

      There are two, not one, major attributes of this type.  You found
EmailAddr { 1 2 840 113549 1 9 1} defined by PKCS#9, apparently.  There is
also Mail or rfc822Mailbox, defined by RFC 1274 { 0 9 2342 19200300 100 1 3
} .  They have essentially similar meanings, although different OID's.

            Tom Gindin


"Markus Lorch" <[e-mail]>@mail.imc.org on 05/10/2002 09:36:42 AM

Sent by:    [e-mail]


To:    <[e-mail]>
cc:
Subject:    EMAIL attribute in x500 name




I ran accross the question if the attribute /EMAIL= in an X.500
name (issuer or subject in a X.509v3 cert) is standardized or at
least what OID is assigned to it.

I can only find the attribute /EMAILADDR which apprears to have an
RSA security OID. The /EMAIL attribute is often found in x.509
certificates from "openCA" CA's. However, it is not supported by
Sun's java implementation of an X.500 name.

I have been pointed to use the /EMAILADDR attribute - however
from rfc2459 it appears that this attribute should no longer
be used (it mentions it is deprecated).

It would be great if somebody has a pointer for me

Thanks

Markus
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Markus Lorch
Doctoral Student in Computer Science
Virginia Tech
http://csgrad.cs.vt.edu/~mlorch







Received: by above.proper.com (8.11.6/8.11.3) id g4AFEbU00975 for ietf-pkix-bks; Fri, 10 May 2002 08:14:37 -0700 (PDT)
Received: from lennier.cc.vt.edu (lennier.cc.vt.edu [198.82.162.213]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g4AFEaL00971 for <[e-mail]>; Fri, 10 May 2002 08:14:36 -0700 (PDT)
Received: from zidane.cc.vt.edu (IDENT:[e-mail] [10.1.1.13]) by lennier.cc.vt.edu (8.11.4/8.11.4) with ESMTP id g4AFEbZ493782 for <[e-mail]>; Fri, 10 May 2002 11:14:37 -0400 (EDT)
Received: from vaio (zuni.cs.vt.edu [128.173.54.49]) by zidane.cc.vt.edu (Mirapoint Messaging Server MOS 3.1.0.54-GA) with SMTP id ACJ30597; Fri, 10 May 2002 11:14:36 -0400 (EDT)
From: "Markus Lorch" <[e-mail]>
To: <[e-mail]>
Subject: C implementation of X509 attribute certificates 
Date: Fri, 10 May 2002 11:14:48 -0400
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.50.4807.1700
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Does anybody know of code (C) to parse attribute
certificates (based on draft-ietf-pkix-ac509prof)? I know
of the IAIK Java implementation but would need some C-code
to parse ACs (preferably from PEM files).

Markus




Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g4AF7lO00679 for ietf-pkix-bks; Fri, 10 May 2002 08:07:47 -0700 (PDT)
Received: from dymwsm14.mailwatch.com (dymwsm14.mailwatch.com [204.253.83.38]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g4AF7kL00675 for <[e-mail]>; Fri, 10 May 2002 08:07:46 -0700 (PDT)
Received: from MWSC0215.mw4.mailwatch.com (mwsc0215.mw4.mailwatch.com [204.253.83.251]) by dymwsm14.mailwatch.com (8.11.0/8.11.0) with ESMTP id g4AF7b709211 for <[e-mail]>; Fri, 10 May 2002 11:07:37 -0400
Received: from mail pickup service by MWSC0215.mw4.mailwatch.com with Microsoft SMTPSVC; Fri, 10 May 2002 11:07:37 -0400
Received: from 204.253.83.39 ([204.253.83.39]) by MWSC0215 with SMTP id 00020002974b52c1-4c17-4002-b832-b479723dd907;	 Fri, 10 May 2002 11:07:35 -0500
Received: from bigbird.entegrity.com (bigbird.gradient.com [192.92.110.50])	by dymwsm15.mailwatch.com (8.11.0/8.11.0) with ESMTP id g4AF7Yc01891;	Fri, 10 May 2002 11:07:34 -0400
Received: by bigbird.gradient.com with Internet Mail Service (5.5.2650.10)	id <KPCDABF6>; Fri, 10 May 2002 11:03:43 -0400
Message-ID: <[e-mail]>
From: Hal Lockhart <[e-mail]>
To: "'[e-mail]'" <[e-mail]>, [e-mail], [e-mail], [e-mail]
Cc: [e-mail], [e-mail]
Subject: RE: "Authentication" and "Signature" bits...
Date: Fri, 10 May 2002 11:03:43 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.10)
Content-Type: multipart/alternative;	boundary="----_=_NextPart_001_01C1F833.E048BE2E"
HOP-COUNT: 1
X-MAILWATCH-INSTANCEID: 01020002974b52c1-4c17-4002-b832-b479723dd907
X-OriginalArrivalTime: 10 May 2002 15:07:37.0236 (UTC) FILETIME=[6BB90540:01C1F834]
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

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_01C1F833.E048BE2E
Content-Type: text/plain;
	charset="ISO-8859-1"


> Tony Bartoletti <[e-mail]> writes:
> 
> >But why should a CA ever have access to even a NR=0 private 
> key?  Why should
> >they need to attest to that which should be standard practice?
>
> Peter Gutmann responded:
> 
> Having the CA generate the user's key and send it to them as 
> a PKCS #12 file is
> depressingly common.  With a number of CAs, that's the only 
> way to get a cert
> from them (I have a paper on this and other stupidity at 
> Usenix Security '02).
> 

Commonly cited reasons include ability to generate higher quality random
numbers and performance issues around time to generate large keys. (You
might think the random number issue would be moot by now, but I have yet to
see a commercial security product of any kind, not just PKI, that uses the
Pentium III hardware RNG.)

Also of particular interest to you Tony, all of the  US government RFPs I
have seen (including DOE) demand a key recovery capability. I don't know if
this is really being used, but it has become a product checkoff item.

Hal

------_=_NextPart_001_01C1F833.E048BE2E
Content-Type: text/html;
	charset="ISO-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3DISO-8859-1">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2448.0">
<TITLE>RE: &quot;Authentication&quot; and &quot;Signature&quot; =
bits...</TITLE>
</HEAD>
<BODY>
<BR>

<P><FONT SIZE=3D2>&gt; Tony Bartoletti &lt;[e-mail]&gt; =
writes:</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; &gt;But why should a CA ever have access to =
even a NR=3D0 private </FONT>
<BR><FONT SIZE=3D2>&gt; key?&nbsp; Why should</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;they need to attest to that which should be =
standard practice?</FONT>
<BR><FONT SIZE=3D2>&gt;</FONT>
<BR><FONT SIZE=3D2>&gt; Peter Gutmann responded:</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; Having the CA generate the user's key and send =
it to them as </FONT>
<BR><FONT SIZE=3D2>&gt; a PKCS #12 file is</FONT>
<BR><FONT SIZE=3D2>&gt; depressingly common.&nbsp; With a number of =
CAs, that's the only </FONT>
<BR><FONT SIZE=3D2>&gt; way to get a cert</FONT>
<BR><FONT SIZE=3D2>&gt; from them (I have a paper on this and other =
stupidity at </FONT>
<BR><FONT SIZE=3D2>&gt; Usenix Security '02).</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
</P>

<P><FONT SIZE=3D2>Commonly cited reasons include ability to generate =
higher quality random numbers and performance issues around time to =
generate large keys. (You might think the random number issue would be =
moot by now, but I have yet to see a commercial security product of any =
kind, not just PKI, that uses the Pentium III hardware RNG.)</FONT></P>

<P><FONT SIZE=3D2>Also of particular interest to you Tony, all of =
the&nbsp; US government RFPs I have seen (including DOE) demand a key =
recovery capability. I don't know if this is really being used, but it =
has become a product checkoff item.</FONT></P>

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

</BODY>
</HTML>
------_=_NextPart_001_01C1F833.E048BE2E--


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g4ADqO428596 for ietf-pkix-bks; Fri, 10 May 2002 06:52:24 -0700 (PDT)
Received: from SOTTMXS01.entrust.com (mail.entrust.com [216.191.251.35]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g4ADqML28592 for <[e-mail]>; Fri, 10 May 2002 06:52:22 -0700 (PDT)
Received: by SOTTMXS01.entrust.com with Internet Mail Service (5.5.2653.19) id <KVB02CRM>; Fri, 10 May 2002 09:52:08 -0400
Message-ID: <[e-mail]>
From: Sharon Boeyen <[e-mail]>
To: "'500 list (E-mail)'" <[e-mail]>, [e-mail]
Cc: "Trevor Freeman (E-mail)" <[e-mail]>, "Stefan Santeeson (E-mail)" <[e-mail]>
Subject: RE: "Authentication" and "Signature" bits...
Date: Fri, 10 May 2002 09:52:07 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1F829.DFAC4080"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

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_01C1F829.DFAC4080
Content-Type: text/plain

I'd like to try to bring the discussion back full circle and separate what I
believe are two distinct issues.
 
Issue 1: The current text that describes the digital signature and non
repudiation bits in X.509 have caused confusion and a request was made to
separate the description of digital signature from that for non-repudiation
and to clarify the meaning of the non-repudiation bit in the keyUsage
extension.
 
Issue 2: Some people would like a way to be able indicate that one key
should be used for authentication and another for signing docs (I know I'm
oversimplifying it).
 
I do not believe that we can or even should attempt to address issue 2 as
part of the solution to issue 1. I agree with Trevor that making this change
to the semantics of the bits is not backward compatible and we cannot do
that with keeping the same OID for the keyUsage extension. 
 
The keyUsage extension is in wide use today and I firmly believe we should
not do anything that would cause most deployed environments to break. I
believe that replacing the current 2 bits with the proposed new bits would
do so. The digital signature bit is widely used today to sign all sorts of
objects including all of those mentioned in this whole debate. In some cases
it is used for challenge/response authentication, in others it is used for
data origin authentication and integrity. The certificate that used to
verify my digital signature on signed emails AND the certificate that is
used by me for online banking with my bank both have the digital signature
bit set. We should not do anything that would render such implementations
non-conformant. 
 
To address issue 1 I believe we should, as Stefan originally requested,
separate the description of digital signature from non repudiation for the
bits and try to clarify the role of the non-repudiation bit if that is
possible. However, fundamentally it is the non-repudiation bit and the other
is the digital signature bit. They are not authentication and data signing
bits, never were and never should be.
 
To address issue 2, I'm not yet convinced that X.509, or PKIX really need
this separation. However, if there is a requirement, I see this more along
the lines of the APPLICATION of keys that we currently define through the
extended key usage extension. I would not want to see the current keyUsage
extension replaced in favor of this new flavor. Rather, leave the current
extension with its original semantics (just clarify them) and address this
other aspect through some other mechanism, if required at all. 
 
>From my own standpoint, I'd prefer to focus on issue 1 first, as that is the
one that raised to the X.509 group as a potential defect in that standard.
 
>From a process standpoint re X.509 I wanted to let folks know that Hoyt and
I do plan to discuss the whole set of messages that have been flowing on the
X.500, PKIX and ABA lists on this topic and then decide what, if anything,
we should propose be done in X.509. However because of our overlapping
vacation schedule, you won't be hearing that from us until the end of the
month. 
 
Cheers,
Sharon
 
 

------_=_NextPart_001_01C1F829.DFAC4080
Content-Type: text/html

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=us-ascii">
<TITLE>RE: "Authentication" and "Signature" bits...</TITLE>

<META content="MSHTML 5.50.4913.1100" name=GENERATOR></HEAD>
<BODY>
<DIV><FONT face=Arial color=#0000ff size=2><SPAN class=460502913-10052002>I'd 
like to try to bring the discussion back full circle and separate what I believe 
are two distinct issues.</SPAN></FONT></DIV>
<DIV><FONT face=Arial color=#0000ff size=2><SPAN 
class=460502913-10052002></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT face=Arial color=#0000ff size=2><SPAN class=460502913-10052002>Issue 
1: The current text that describes the digital signature and non repudiation 
bits in X.509 have caused confusion and a request was made to separate the 
description of digital signature from that for non-repudiation and to clarify 
the meaning of the non-repudiation bit in the keyUsage 
extension.</SPAN></FONT></DIV>
<DIV><FONT face=Arial color=#0000ff size=2><SPAN 
class=460502913-10052002></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT face=Arial color=#0000ff size=2><SPAN class=460502913-10052002>Issue 
2: Some people would like a way to be able indicate that one key should be used 
for authentication and another for signing docs (I know I'm oversimplifying 
it).</SPAN></FONT></DIV>
<DIV><FONT face=Arial color=#0000ff size=2><SPAN 
class=460502913-10052002></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT face=Arial color=#0000ff size=2><SPAN class=460502913-10052002>I do 
not believe that we can or even should attempt to address issue 2 as part of the 
solution to issue 1. I agree with Trevor that making this change to the 
semantics of the bits is not backward compatible and we cannot do that with 
keeping the same OID for the keyUsage extension. </SPAN></FONT></DIV>
<DIV><FONT face=Arial color=#0000ff size=2><SPAN 
class=460502913-10052002></SPAN></FONT><FONT face=Arial color=#0000ff 
size=2><SPAN class=460502913-10052002></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT face=Arial color=#0000ff size=2><SPAN class=460502913-10052002>The 
keyUsage extension is in wide use today and I firmly believe we should not do 
anything that would cause most deployed environments to break. I believe that 
replacing the current 2 bits with the proposed new bits would do so. The digital 
signature bit is widely used today to sign all sorts of objects including all of 
those mentioned in this whole debate. In some cases it is used for 
challenge/response authentication, in others it is used for data origin 
authentication and integrity. The certificate that used to verify my digital 
signature on signed emails AND the certificate that is used by me for online 
banking with my bank both have the digital signature bit set. We should not do 
anything that would render such implementations non-conformant. 
</SPAN></FONT></DIV>
<DIV><FONT face=Arial color=#0000ff size=2><SPAN 
class=460502913-10052002></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT face=Arial color=#0000ff size=2><SPAN class=460502913-10052002>To 
address issue 1 I believe we should, as Stefan originally requested, separate 
the description of digital signature from non repudiation for the bits and try 
to clarify the role of the non-repudiation bit if that is possible. However, 
fundamentally it is the non-repudiation bit and the other is the digital 
signature bit. They are not authentication and data signing bits, never were and 
never should be.</SPAN></FONT></DIV>
<DIV><FONT face=Arial color=#0000ff size=2><SPAN 
class=460502913-10052002></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT face=Arial color=#0000ff size=2><SPAN class=460502913-10052002>To 
address issue 2, I'm not yet convinced that X.509, or PKIX really need this 
separation. However, if there is a requirement, I see this more along the lines 
of the APPLICATION of keys that we currently define through the extended key 
usage extension. I would not want to see the current keyUsage extension replaced 
in favor of this new flavor. Rather, leave the current extension with its 
original semantics (just clarify them) and address this other aspect through 
some other mechanism, if required at all. </SPAN></FONT></DIV>
<DIV><FONT face=Arial color=#0000ff size=2><SPAN 
class=460502913-10052002></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT face=Arial color=#0000ff size=2><SPAN class=460502913-10052002>From 
my own standpoint, I'd prefer to focus on issue 1 first, as that is the one that 
raised to the X.509 group as a potential defect in that 
standard.</SPAN></FONT></DIV>
<DIV><FONT face=Arial color=#0000ff size=2><SPAN 
class=460502913-10052002></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT face=Arial color=#0000ff size=2><SPAN class=460502913-10052002>From a 
process standpoint re X.509 I wanted to let folks know that Hoyt and I do plan 
to discuss the whole set of messages that have been flowing on the X.500, PKIX 
and ABA lists on this topic and then decide what, if anything, we should propose 
be done in X.509. However because of our overlapping vacation schedule, you 
won't be hearing that from us until the end of the month. </SPAN></FONT></DIV>
<DIV><FONT face=Arial color=#0000ff size=2><SPAN 
class=460502913-10052002></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT face=Arial color=#0000ff size=2><SPAN 
class=460502913-10052002>Cheers,</SPAN></FONT></DIV>
<DIV><FONT face=Arial color=#0000ff size=2><SPAN 
class=460502913-10052002>Sharon</SPAN></FONT></DIV>
<DIV><FONT face=Arial color=#0000ff size=2><SPAN 
class=460502913-10052002></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT face=Arial color=#0000ff size=2><SPAN 
class=460502913-10052002></SPAN></FONT>&nbsp;</DIV></BODY></HTML>

------_=_NextPart_001_01C1F829.DFAC4080--


Received: by above.proper.com (8.11.6/8.11.3) id g4ADaWS28140 for ietf-pkix-bks; Fri, 10 May 2002 06:36:32 -0700 (PDT)
Received: from lennier.cc.vt.edu (lennier.cc.vt.edu [198.82.162.213]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g4ADaVL28135 for <[e-mail]>; Fri, 10 May 2002 06:36:31 -0700 (PDT)
Received: from vivi.cc.vt.edu (IDENT:[e-mail] [10.1.1.12]) by lennier.cc.vt.edu (8.11.4/8.11.4) with ESMTP id g4ADaWZ513080 for <[e-mail]>; Fri, 10 May 2002 09:36:32 -0400 (EDT)
Received: from vaio (zuni.cs.vt.edu [128.173.54.49]) by vivi.cc.vt.edu (Mirapoint Messaging Server MOS 3.1.0.54-GA) with SMTP id ABZ76287; Fri, 10 May 2002 09:36:30 -0400 (EDT)
From: "Markus Lorch" <[e-mail]>
To: <[e-mail]>
Subject: EMAIL attribute in x500 name
Date: Fri, 10 May 2002 09:36:42 -0400
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.50.4807.1700
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

I ran accross the question if the attribute /EMAIL= in an X.500
name (issuer or subject in a X.509v3 cert) is standardized or at
least what OID is assigned to it. 

I can only find the attribute /EMAILADDR which apprears to have an
RSA security OID. The /EMAIL attribute is often found in x.509 
certificates from "openCA" CA's. However, it is not supported by
Sun's java implementation of an X.500 name.

I have been pointed to use the /EMAILADDR attribute - however 
from rfc2459 it appears that this attribute should no longer 
be used (it mentions it is deprecated).
 
It would be great if somebody has a pointer for me

Thanks

Markus
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Markus Lorch
Doctoral Student in Computer Science
Virginia Tech
http://csgrad.cs.vt.edu/~mlorch


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g4ACf4l26423 for ietf-pkix-bks; Fri, 10 May 2002 05:41:04 -0700 (PDT)
Received: from mtiwmhc23.worldnet.att.net (mtiwmhc23.worldnet.att.net [204.127.131.48]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g4ACf3L26419 for <[e-mail]>; Fri, 10 May 2002 05:41:03 -0700 (PDT)
Received: from Chokhani ([12.91.130.80]) by mtiwmhc23.worldnet.att.net (InterMail vM.4.01.03.27 201-229-121-127-20010626) with ESMTP id <20020510124057.ZEVR28245.mtiwmhc23.worldnet.att.net@Chokhani>; Fri, 10 May 2002 12:40:57 +0000
From: "Santosh Chokhani" <[e-mail]>
To: "'Peter Williams'" <[e-mail]>
Cc: <[e-mail]>
Subject: RE: "Authentication" and "Signature" bits...
Date: Fri, 10 May 2002 08:42:29 -0400
Message-ID: <000901c1f820$2619c6f0$a300a8c0@Chokhani>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.2627
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4910.0300
In-Reply-To: <[e-mail]>
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id g4ACf3L26420
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Peter:

There are several misunderstandings (in my mind) on your part of what I
suggest.  First of all, I do not say that there is NR or there is no NR.
That is why when people on this list talk about intent and software and
hardware between the human actions, I get lost.

My proposal is very simple, just the way a key can be used for
encryption and signature verification or you can have two different keys
for encryption and signature verification, I want to differential
between signing challenges for entity authentication and signing data
that the user/application has formed/blessed.

In these scenarios for OCSP and DPV, the digital signature (and not the
authentication) bit will be required to be set.  If both are set, it is
ok.  I realize that the protocol, includes echoing the challenge, but
the responder is formulating a transaction as opposed to signing a
challenge in order to provide authentication.

Those who want to solve NR problem, are welcome to.  My precise point is
that NR is not a problem to be solved by PKC.  As it so happens, a key
that is used for digital signature and not for signing challenges may
have a better luck on NR, just like a key that is not used for dual
purpose of signature and encryption (since encryption key may have key
escrow feature to it). 

-----Original Message-----
From: Peter Williams [mailto:[e-mail]] 
Sent: Thursday, May 09, 2002 5:43 PM
To: 'Santosh Chokhani'
Cc: [e-mail]
Subject: RE: "Authentication" and "Signature" bits...


Let me ask the dumb questions, and
then comment, publicly.


A1: 

An OCSP responder inevitably signs
an OCSP responses, which contains a
nonce and highly-legalistic reliance data. The
data is sent, sometimes by a TTP grade
operator, to influence reliance
on certificates. There is
no intention that the OCSP response
is necessarily a set of NR assertions,
however.

I think in your scheme, we
use:

"nonceSign", "digitalSignature|dataSign"

Is this correct?

A2:

A DPV responder will act
similarly to an OCSP responder,
with the added twist that its operator
necessarily makes NR assertions 
(by requirements of this WG), in 
addition to signing a nonce,
and various pieces of reliance
data to be used by a relying
party application in deciding
how to use a certificate path.

I think in your scheme, we
use:

"nonceSign", "digitalSignature|dataSign"

Is this correct?

Conclusion 1: in the new scheme, there
is now no way - using certificates - for an OCSP 
provider to signal that it intends to upgrade its 
OCSP-based validation service to make NR-grade 
assertions. If an OCSP entity
is to upgrade its assurance level to
offer NR, then it would have to signal
this in an OCSP response extension. That is,
we tag the grade of OCSP signing assurance
via an attribute of the signature (essentially)
in the response, not the certificate.

Conclusion 2: in the case of DPV, with
the new scheme, there is no need
to tag the DPV response with any
NR extension/field signal, as ALL DPV responses 
are NR assertions, by protocol definition. That
is, one cannot run a DPV server
except as a NR service provider. Obviously
the precise meaning of a given signer's NR
semantics will be a function 
of the posted "signing policy" of the 
subscriber.

If this is all correct, I'm happy with all this. It 
removes from the CA the technical perogative of controlling what
subscribers can do with NR assertions - placing control in the hands of
the protocol designers (just like 
X.400/EDIFACT did) and the  protocol 
operators who perform the act
of signing. This scheme aligns
with the model of PMI's
NR assertions.

In terms of PKIX architecture, relying parties
determine when a security service is a subclass
of NR assertions - based on the protocol
definition, and by inspecting the subscribers
signing policy. This contrasts with
the current scheme - built into PKIX-1 and replacements, 
in which one looks to the CA CP.

Peter.


>>>>-----Original Message-----
>>>>From: Tom Gindin [mailto:[e-mail]]
>>>>Sent: Thursday, May 09, 2002 1:42 PM
>>>>To: Carlisle Adams
>>>>Cc: 'David P. Kemp'; 'Santosh Chokhani'; '500 list (E-mail)'; 
>>>>[e-mail]
>>>>Subject: RE: "Authentication" and "Signature" bits...
>>>>
>>>>
>>>>
>>>>
>>>>      Carlisle:
>>>>
>>>>      Actually, distinguishing nonces from documents is not
>>>>a very hard
>>>>problem (the lengths are radically different).  The 
>>>>difficulty would be in
>>>>distinguishing challenges which are inside larger objects 
>>>>from otherwise
>>>>similar objects.
>>>>
>>>>            Tom Gindin
>>>>
>>>>Carlisle Adams <[e-mail]>@mail.imc.org on
>>>>05/08/2002
>>>>02:15:28 PM
>>>>
>>>>Sent by:    [e-mail]
>>>>
>>>>
>>>>To:    Carlisle Adams <[e-mail]>, "'David 
>>>>P. Kemp'"
>>>>       <[e-mail]>, "'Santosh Chokhani'"
>>>>       <[e-mail]>
>>>>cc:    "'500 list (E-mail)'" <[e-mail]>,
>>>>       [e-mail]
>>>>Subject:    RE: "Authentication" and "Signature" bits...
>>>>
>>>>
>>>>Hi Santosh,
>>>>
>>>>
>>>>      ----------
>>>>      From:   Santosh Chokhani[SMTP:[e-mail]]
>>>>      Sent:   Wednesday, May 08, 2002 2:07 PM
>>>>      To:     'Carlisle Adams'; 'David P. Kemp'
>>>>      Cc:     '500 list (E-mail)'; [e-mail]
>>>>      Subject:        RE: "Authentication" and "Signature" bits...
>>>>
>>>>
>>>>      Carlisle:
>>>>
>>>>      You make persuasive arguments in favor of existing
>>>>implementation.
>>>>
>>>>      But, on technical grounds, there is a difference
>>>>between signing a
>>>>      challenge and signing to some contents that you want 
>>>>to provide
>>>>      digital signatures for.  We have this distinction for 
>>>>certificate and
>>>>      CRL and what we have proposed is meaningful and useful without
>>>>      getting into all the legal mumbo-jumbo.
>>>>
>>>>
>>>>
>>>>I'm not talking about legal mumbo-jumbo.  All I'm saying is
>>>>that a human
>>>>may be able to readily see the difference between random 
>>>>data that has been
>>>>signed and meaningful data that has been signed, but in many cases,
>>>>software can't.  Certificates and CRLs have a very 
>>>>specific, well-known
>>>>syntax, so software *can* distinguish between these and 
>>>>other data.  But
>>>>deciding whether the thing that has been signed had the 
>>>>intent of being for
>>>>authentication purposes (e.g., a random challenge, or a data origin
>>>>authentication e-mail) is a very hard problem.
>>>>
>>>>
>>>>I disagree that the distinction that has been proposed is
>>>>meaningful and
>>>>useful, completely independent of any legal interpretation.
>>>>
>>>>
>>>>Carlisle.
>>>>
>>>>
>>>>
>>>>
>>>>



Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g4ABuEr23396 for ietf-pkix-bks; Fri, 10 May 2002 04:56:14 -0700 (PDT)
Received: from e1.ny.us.ibm.com (e1.ny.us.ibm.com [32.97.182.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g4ABuCL23387 for <[e-mail]>; Fri, 10 May 2002 04:56:13 -0700 (PDT)
Received: from northrelay02.pok.ibm.com (northrelay02.pok.ibm.com [9.56.224.150]) by e1.ny.us.ibm.com (8.12.2/8.12.2) with ESMTP id g4ABrNAH004528; Fri, 10 May 2002 07:53:23 -0400
Received: from d01ml062.pok.ibm.com (d01ml062.pok.ibm.com [9.117.250.163]) by northrelay02.pok.ibm.com (8.11.1m3/NCO/VER6.1) with ESMTP id g4ABrL7137962; Fri, 10 May 2002 07:53:21 -0400
Importance: Normal
Sensitivity: 
Subject: RE: "Authentication" and "Signature" bits...
To: Carlisle Adams <[e-mail]>
Cc: "'500 list (E-mail)'" <[e-mail]>, [e-mail]
X-Mailer: Lotus Notes Release 5.0.7  March 21, 2001
Message-ID: <[e-mail]>
From: "Tom Gindin" <[e-mail]>
Date: Fri, 10 May 2002 07:53:16 -0400
X-MIMETrack: Serialize by Router on D01ML062/01/M/IBM(Release 5.0.10 |March 28, 2002) at 05/10/2002 07:53:21 AM
MIME-Version: 1.0
Content-type: text/plain; charset=us-ascii
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

      Carlisle:

      Responses below.  In general IMO, a nonce and an NR message can
certainly be distinguished from each other by software, but not all objects
to be signed fall into these two categories.  Short of declaring that the
only objects to be signed in NR mode must be from a (fairly small)
enumerated set of formats (SignedData, XMLDSIG, and maybe a few more) and
have specific indicators that they are NR (which must be standardized from
each format), I don't see any way to block the use of a signature by a
non-NR certificate for NR in software.  One of the purposes of having the
NR bit (perhaps the strongest) is to warn a relying party that NOTHING
signed by the key in a DS=1,NR=0 certificate is to be considered as
non-repudiable.

            Tom Gindin

Carlisle Adams <[e-mail]> on 05/09/2002 05:49:06 PM

To:    Tom Gindin/Watson/IBM@IBMUS
cc:    "'David P. Kemp'" <[e-mail]>, "'Santosh Chokhani'"
       <[e-mail]>, "'500 list (E-mail)'"
       <[e-mail]>, [e-mail]
Subject:    RE: "Authentication" and "Signature" bits...


Hi Tom,


      ----------
      From:   Tom Gindin[SMTP:[e-mail]]
      Sent:   Thursday, May 09, 2002 4:42 PM
      To:     Carlisle Adams
      Cc:     'David P. Kemp'; 'Santosh Chokhani'; '500 list (E-mail)';
      [e-mail]
      Subject:        RE: "Authentication" and "Signature" bits...


            Carlisle:


            Actually, distinguishing nonces from documents is not a very
      hard
      problem (the lengths are radically different).



Often, yes; but of course this can't be universally true.  There are
certainly some meaningful messages that are short.  And there is a whole
grey area if the thing that is signed happens to be the hash of a larger
document, since the hash may very well be the same size as a nonce.


      [TG] Any meaningful application verification of such a hash would
      have to go back and verify the hash, so the size would be
      distinguishable.


      The difficulty would be in
      distinguishing challenges which are inside larger objects from
      otherwise
      similar objects.



Agreed.


The only point I'm making is that there is no hard-and-fast rule that will
allow software to distinguish (every time!) between a meaningful message
and a nonce.  If you can't guarantee this distinction, then two separate A
and DS bits leads to the same quagmire we've had for the DS and NR bits.





It has been suggested (in an off-list message to me) that applications know
their own contexts and therefore can always make this distinction in the
messages they process.  Perhaps that's true, but I'm skeptical.  I'm of the
belief that signing a message with the sole intent of data origin
authentication ("Carlisle originated this message") is as much
'authentication' as signing a nonce.  It's proof-of-possession of a private
key; it's challenge-response without the challenge (or perhaps with an
implied challenge); it's a mechanism for letting the receiver know who is
at the other end of the channel.  This use is not for non-repudiation
purposes; this is simply DOA.  Given that premise (i.e., that DOA is a
valid form of authentication), then I don't see how even applications that
know their contexts can make the distinction.


[TG] I don't think this holds up well.  If I present a CMS message with an
NR assertion in it (say one of the Signature Policies that purports to be
non-repudiable), you'd better not sign it in challenge-response mode.


I don't think that separating A and DS into two bits serves any meaningful
purpose.  It's all DS.


Carlisle.






Received: by above.proper.com (8.11.6/8.11.3) id g4AA9WC18273 for ietf-pkix-bks; Fri, 10 May 2002 03:09:32 -0700 (PDT)
Received: from mailout09.sul.t-online.com (mailout09.sul.t-online.com [194.25.134.84]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g4AA9UL18269 for <[e-mail]>; Fri, 10 May 2002 03:09:31 -0700 (PDT)
Received: from fwd06.sul.t-online.de  by mailout09.sul.t-online.com with smtp  id 1767L6-0000Sa-03; Fri, 10 May 2002 12:09:28 +0200
Received: from junker.stroeder.com (520010731148-0001@[62.224.169.124]) by fmrl06.sul.t-online.com with esmtp id 1767Kv-1udmGuC; Fri, 10 May 2002 12:09:17 +0200
Received: from stroeder.com (junker [127.0.0.1]) by junker.stroeder.com (Postfix) with ESMTP id 72B7915716D; Fri, 10 May 2002 12:09:09 +0200 (CEST)
Message-ID: <[e-mail]>
Date: Fri, 10 May 2002 12:09:09 +0200
From: =?ISO-8859-15?Q?Michael_Str=F6der?= <[e-mail]>
Reply-To: [e-mail]
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.0+) Gecko/20020507
X-Accept-Language: de-DE, de, en
MIME-Version: 1.0
To: Carlisle Adams <[e-mail]>
Cc: [e-mail]
Subject: Re: "Authentication" and "Signature" bits...
References: <[e-mail]>
Content-Type: text/plain; charset=ISO-8859-15; format=flowed
Content-Transfer-Encoding: 7bit
X-Sender: [e-mail]
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Carlisle Adams wrote:
>  
> Separating authentication and signature seems somewhat attractive on a 
> first glance, but I would personally be very reluctant to pursue this.  
> There are three reasons for this.  The first is fairly simple and 
> perhaps of minor significance:  because authentication in this context 
> is accomplished through a signature (e.g., signing a random challenge), 
> this doesn't "feel" like a different key usage to me.  Both bits tell 
> the relying party that it can use the public key in this certificate to 
> verify a signature.

Am I the only one who is scared to use the very same private key 
for signing orders and client authentication? Think about a web 
server initiating some action with your private key by serving a 
banner ad via HTTP/SSL.

Another issue with authentication certs is privacy.

Ciao, Michael.



Received: by above.proper.com (8.11.6/8.11.3) id g4A9lRY14454 for ietf-pkix-bks; Fri, 10 May 2002 02:47:27 -0700 (PDT)
Received: from hermes.cs.auckland.ac.nz (hermes.cs.auckland.ac.nz [130.216.35.151]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g4A9lPL14443 for <[e-mail]>; Fri, 10 May 2002 02:47:25 -0700 (PDT)
Received: from ruru.cs.auckland.ac.nz (ruru-nfs.cs.auckland.ac.nz [130.216.35.12]) by hermes.cs.auckland.ac.nz (8.12.3/8.12.3) with ESMTP id g4A9egaq024072; Fri, 10 May 2002 21:40:42 +1200
Received: (from pgut001@localhost) by ruru.cs.auckland.ac.nz (8.9.3/8.8.6/cs-slave) id VAA344196; Fri, 10 May 2002 21:40:42 +1200 (NZST) (sender [e-mail])
Date: Fri, 10 May 2002 21:40:42 +1200 (NZST)
Message-ID: <[e-mail]>
From: [e-mail] (Peter Gutmann)
To: [e-mail], [e-mail], [e-mail]
Subject: Re: "Authentication" and "Signature" bits...
Cc: [e-mail], [e-mail]
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Tony Bartoletti <[e-mail]> writes:

>But why should a CA ever have access to even a NR=0 private key?  Why should
>they need to attest to that which should be standard practice?

Having the CA generate the user's key and send it to them as a PKCS #12 file is
depressingly common.  With a number of CAs, that's the only way to get a cert
from them (I have a paper on this and other stupidity at Usenix Security '02).

Peter.


Received: by above.proper.com (8.11.6/8.11.3) id g4A7YR029763 for ietf-pkix-bks; Fri, 10 May 2002 00:34:27 -0700 (PDT)
Received: from hermes.cs.auckland.ac.nz (hermes.cs.auckland.ac.nz [130.216.35.151]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g4A7YFL29719 for <[e-mail]>; Fri, 10 May 2002 00:34:25 -0700 (PDT)
Received: from ruru.cs.auckland.ac.nz (ruru-nfs.cs.auckland.ac.nz [130.216.35.12]) by hermes.cs.auckland.ac.nz (8.12.3/8.12.3) with ESMTP id g4A7RSaq021938; Fri, 10 May 2002 19:27:28 +1200
Received: (from pgut001@localhost) by ruru.cs.auckland.ac.nz (8.9.3/8.8.6/cs-slave) id TAA343261; Fri, 10 May 2002 19:26:58 +1200 (NZST) (sender [e-mail])
Date: Fri, 10 May 2002 19:26:58 +1200 (NZST)
Message-ID: <[e-mail]>
From: [e-mail] (Peter Gutmann)
To: [e-mail], [e-mail]
Subject: Re: Meaning of Non-repudiation
Cc: [e-mail]
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

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

>I have no problem with X.509 and PKIX following Trevor's approach. Deprecate
>(using the strongest possible terms) the existing KeyUsage OID, and define a
>new KeyUsage OID identical to the old one except that bits 0 and 1 are
>replaced by nonceSign and dataSign.

I agree fully with the theory [0], but I'm not sure about the practicality.
The current keyUsage is going to take a long time (possibly forever) to be
displaced (no matter how strongly it's deprecated), which will lead to problems
unless you're very careful with how you define the semantics, since people are
going to keep using the current keyUsage for backwards-compatibility alongside
the new one.  You'd have to do something like require that if both are present,
the new one overrides the old one, and then use it in combination with the
critical flag if you absolutely require the new semantics and nothing else.

Peter.

[0] That's too mild a term.  I would really, *really* like to see this
    confusion finally sorted out so we can get back to arguing over the meaning
    of DPD.



Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g49LnKb00510 for ietf-pkix-bks; Thu, 9 May 2002 14:49:20 -0700 (PDT)
Received: from SOTTMXS01.entrust.com (mail.entrust.com [216.191.251.35]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g49LnJL00505 for <[e-mail]>; Thu, 9 May 2002 14:49:19 -0700 (PDT)
Received: by SOTTMXS01.entrust.com with Internet Mail Service (5.5.2653.19) id <KT1RBT1V>; Thu, 9 May 2002 17:49:07 -0400
Message-ID: <[e-mail]>
From: Carlisle Adams <[e-mail]>
To: "'Tom Gindin'" <[e-mail]>
Cc: "'David P. Kemp'" <[e-mail]>, "'Santosh Chokhani'" <[e-mail]>, "'500 list (E-mail)'" <[e-mail]>, [e-mail]
Subject: RE: "Authentication" and "Signature" bits...
Date: Thu, 9 May 2002 17:49:06 -0400 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1F7A3.577B68C0"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

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_01C1F7A3.577B68C0
Content-Type: text/plain

Hi Tom,

> ----------
> From: 	Tom Gindin[SMTP:[e-mail]]
> Sent: 	Thursday, May 09, 2002 4:42 PM
> To: 	Carlisle Adams
> Cc: 	'David P. Kemp'; 'Santosh Chokhani'; '500 list (E-mail)';
> [e-mail]
> Subject: 	RE: "Authentication" and "Signature" bits...
> 
>       Carlisle:
> 
>       Actually, distinguishing nonces from documents is not a very hard
> problem (the lengths are radically different).  
 
Often, yes; but of course this can't be universally true.  There are
certainly some meaningful messages that are short.  And there is a whole
grey area if the thing that is signed happens to be the hash of a larger
document, since the hash may very well be the same size as a nonce.

> The difficulty would be in
> distinguishing challenges which are inside larger objects from otherwise
> similar objects.
 
Agreed.

The only point I'm making is that there is no hard-and-fast rule that will
allow software to distinguish (every time!) between a meaningful message and
a nonce.  If you can't guarantee this distinction, then two separate A and
DS bits leads to the same quagmire we've had for the DS and NR bits.

It has been suggested (in an off-list message to me) that applications know
their own contexts and therefore can always make this distinction in the
messages they process.  Perhaps that's true, but I'm skeptical.  I'm of the
belief that signing a message with the sole intent of data origin
authentication ("Carlisle originated this message") is as much
'authentication' as signing a nonce.  It's proof-of-possession of a private
key; it's challenge-response without the challenge (or perhaps with an
implied challenge); it's a mechanism for letting the receiver know who is at
the other end of the channel.  This use is not for non-repudiation purposes;
this is simply DOA.  Given that premise (i.e., that DOA is a valid form of
authentication), then I don't see how even applications that know their
contexts can make the distinction.

I don't think that separating A and DS into two bits serves any meaningful
purpose.  It's all DS.

Carlisle.


------_=_NextPart_001_01C1F7A3.577B68C0
Content-Type: text/html
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Dus-ascii">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2653.12">
<TITLE>RE: &quot;Authentication&quot; and &quot;Signature&quot; =
bits...</TITLE>
</HEAD>
<BODY>

<P><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Times New Roman">Hi =
Tom,</FONT>
</P>
<UL>
<P><FONT SIZE=3D2 FACE=3D"MS Sans Serif">----------</FONT>
<BR><B><FONT SIZE=3D2 FACE=3D"MS Sans Serif">From:</FONT></B> &nbsp; =
<FONT SIZE=3D2 FACE=3D"MS Sans Serif">Tom =
Gindin[SMTP:[e-mail]]</FONT>
<BR><B><FONT SIZE=3D2 FACE=3D"MS Sans Serif">Sent:</FONT></B> &nbsp; =
<FONT SIZE=3D2 FACE=3D"MS Sans Serif">Thursday, May 09, 2002 4:42 =
PM</FONT>
<BR><B><FONT SIZE=3D2 FACE=3D"MS Sans Serif">To:</FONT></B> =
&nbsp;&nbsp;&nbsp; <FONT SIZE=3D2 FACE=3D"MS Sans Serif">Carlisle =
Adams</FONT>
<BR><B><FONT SIZE=3D2 FACE=3D"MS Sans Serif">Cc:</FONT></B> =
&nbsp;&nbsp;&nbsp; <FONT SIZE=3D2 FACE=3D"MS Sans Serif">'David P. =
Kemp'; 'Santosh Chokhani'; '500 list (E-mail)'; =
[e-mail]</FONT>
<BR><B><FONT SIZE=3D2 FACE=3D"MS Sans Serif">Subject:</FONT></B> =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT SIZE=3D2 FACE=3D"MS Sans =
Serif">RE: &quot;Authentication&quot; and &quot;Signature&quot; =
bits...</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
Carlisle:</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
Actually, distinguishing nonces from documents is not a very =
hard</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">problem (the lengths are radically =
different).&nbsp; </FONT>
</UL>
<P><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Times New =
Roman">&nbsp;</FONT>
<BR><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Times New Roman">Often, =
yes; but of course this can't be universally true.&nbsp; There are =
certainly some meaningful messages that are short.&nbsp; And there is a =
whole grey area if the thing that is signed happens to be the hash of a =
larger document, since the hash may very well be the same size as a =
nonce.</FONT></P>
<UL>
<P><FONT SIZE=3D2 FACE=3D"Arial">The difficulty would be in</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">distinguishing challenges which are =
inside larger objects from otherwise</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">similar objects.</FONT>
</UL>
<P><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Times New =
Roman">&nbsp;</FONT>
<BR><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Times New =
Roman">Agreed.</FONT>
</P>

<P><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Times New Roman">The only =
point I'm making is that there is no hard-and-fast rule that will allow =
software to distinguish (every time!) between a meaningful message and =
a nonce.&nbsp; If you can't guarantee this distinction, then two =
separate A and DS bits leads to the same quagmire we've had for the DS =
and NR bits.</FONT></P>

<P><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Times New Roman">It has =
been suggested (in an off-list message to me) that applications know =
their own contexts and therefore can always make this distinction in =
the messages they process.&nbsp; Perhaps that's true, but I'm =
skeptical.&nbsp; I'm of the belief that signing a message with the sole =
intent of data origin authentication (&quot;Carlisle originated this =
message&quot;) is as much 'authentication' as signing a nonce.&nbsp; =
It's proof-of-possession of a private key; it's challenge-response =
without the challenge (or perhaps with an implied challenge); it's a =
mechanism for letting the receiver know who is at the other end of the =
channel.&nbsp; This use is not for non-repudiation purposes; this is =
simply DOA.&nbsp; Given that premise (i.e., that DOA is a valid form of =
authentication), then I don't see how even applications that know their =
contexts can make the distinction.</FONT></P>

<P><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Times New Roman">I don't =
think that separating A and DS into two bits serves any meaningful =
purpose.&nbsp; It's all DS.</FONT>
</P>

<P><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Times New =
Roman">Carlisle.</FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C1F7A3.577B68C0--


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g49Lhml00406 for ietf-pkix-bks; Thu, 9 May 2002 14:43:48 -0700 (PDT)
Received: from ext-mail.valicert.com ([66.206.205.11]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g49LhkL00402 for <[e-mail]>; Thu, 9 May 2002 14:43:46 -0700 (PDT)
Received: from CONVERSION-DAEMON by ext-mail.valicert.com (PMDF V5.2-33 #46613) id <[e-mail]> for [e-mail]; Thu, 9 May 2002 14:39:45 -0700 (PDT)
Received: from polaris.valicert.com ([192.168.2.34]) by ext-mail.valicert.com (PMDF V5.2-33 #46613) with ESMTP id <[e-mail]>; Thu, 09 May 2002 14:39:45 -0700 (PDT)
Received: by polaris.valicert.com with Internet Mail Service (5.5.2653.19) id <JQL5CQ4T>; Thu, 09 May 2002 14:43:32 -0700
Content-return: allowed
Date: Thu, 09 May 2002 14:43:25 -0700
From: Peter Williams <[e-mail]>
Subject: RE: "Authentication" and "Signature" bits...
To: "'Santosh Chokhani'" <[e-mail]>
Cc: [e-mail]
Message-id: <[e-mail]>
MIME-version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-type: text/plain; charset=iso-8859-1
Content-transfer-encoding: 8BIT
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Let me ask the dumb questions, and
then comment, publicly.


A1: 

An OCSP responder inevitably signs
an OCSP responses, which contains a
nonce and highly-legalistic reliance data. The
data is sent, sometimes by a TTP grade
operator, to influence reliance
on certificates. There is
no intention that the OCSP response
is necessarily a set of NR assertions,
however.

I think in your scheme, we
use:

"nonceSign", "digitalSignature|dataSign"

Is this correct?

A2:

A DPV responder will act
similarly to an OCSP responder,
with the added twist that its operator
necessarily makes NR assertions 
(by requirements of this WG), in 
addition to signing a nonce,
and various pieces of reliance
data to be used by a relying
party application in deciding
how to use a certificate path.

I think in your scheme, we
use:

"nonceSign", "digitalSignature|dataSign"

Is this correct?

Conclusion 1: in the new scheme, there
is now no way - using certificates - for an OCSP 
provider to signal that it intends to upgrade its 
OCSP-based validation service to make NR-grade 
assertions. If an OCSP entity
is to upgrade its assurance level to
offer NR, then it would have to signal
this in an OCSP response extension. That is,
we tag the grade of OCSP signing assurance
via an attribute of the signature (essentially)
in the response, not the certificate.

Conclusion 2: in the case of DPV, with
the new scheme, there is no need
to tag the DPV response with any
NR extension/field signal, as ALL DPV responses 
are NR assertions, by protocol definition. That
is, one cannot run a DPV server
except as a NR service provider. Obviously
the precise meaning of a given signer's NR
semantics will be a function 
of the posted "signing policy" of the 
subscriber.

If this is all correct, I'm happy with all this. It 
removes from the CA the technical perogative of controlling
what subscribers can do with NR assertions -
placing control in the hands
of the protocol designers (just like 
X.400/EDIFACT did) and the  protocol 
operators who perform the act
of signing. This scheme aligns
with the model of PMI's
NR assertions.

In terms of PKIX architecture, relying parties
determine when a security service is a subclass
of NR assertions - based on the protocol
definition, and by inspecting the subscribers
signing policy. This contrasts with
the current scheme - built into PKIX-1 and replacements, 
in which one looks to the CA CP.

Peter.


>>>>-----Original Message-----
>>>>From: Tom Gindin [mailto:[e-mail]]
>>>>Sent: Thursday, May 09, 2002 1:42 PM
>>>>To: Carlisle Adams
>>>>Cc: 'David P. Kemp'; 'Santosh Chokhani'; '500 list (E-mail)';
>>>>[e-mail]
>>>>Subject: RE: "Authentication" and "Signature" bits...
>>>>
>>>>
>>>>
>>>>
>>>>      Carlisle:
>>>>
>>>>      Actually, distinguishing nonces from documents is not 
>>>>a very hard
>>>>problem (the lengths are radically different).  The 
>>>>difficulty would be in
>>>>distinguishing challenges which are inside larger objects 
>>>>from otherwise
>>>>similar objects.
>>>>
>>>>            Tom Gindin
>>>>
>>>>Carlisle Adams <[e-mail]>@mail.imc.org on 
>>>>05/08/2002
>>>>02:15:28 PM
>>>>
>>>>Sent by:    [e-mail]
>>>>
>>>>
>>>>To:    Carlisle Adams <[e-mail]>, "'David 
>>>>P. Kemp'"
>>>>       <[e-mail]>, "'Santosh Chokhani'"
>>>>       <[e-mail]>
>>>>cc:    "'500 list (E-mail)'" <[e-mail]>,
>>>>       [e-mail]
>>>>Subject:    RE: "Authentication" and "Signature" bits...
>>>>
>>>>
>>>>Hi Santosh,
>>>>
>>>>
>>>>      ----------
>>>>      From:   Santosh Chokhani[SMTP:[e-mail]]
>>>>      Sent:   Wednesday, May 08, 2002 2:07 PM
>>>>      To:     'Carlisle Adams'; 'David P. Kemp'
>>>>      Cc:     '500 list (E-mail)'; [e-mail]
>>>>      Subject:        RE: "Authentication" and "Signature" bits...
>>>>
>>>>
>>>>      Carlisle:
>>>>
>>>>      You make persuasive arguments in favor of existing 
>>>>implementation.
>>>>
>>>>      But, on technical grounds, there is a difference 
>>>>between signing a
>>>>      challenge and signing to some contents that you want 
>>>>to provide
>>>>      digital signatures for.  We have this distinction for 
>>>>certificate and
>>>>      CRL and what we have proposed is meaningful and useful without
>>>>      getting into all the legal mumbo-jumbo.
>>>>
>>>>
>>>>
>>>>I'm not talking about legal mumbo-jumbo.  All I'm saying is 
>>>>that a human
>>>>may be able to readily see the difference between random 
>>>>data that has been
>>>>signed and meaningful data that has been signed, but in many cases,
>>>>software can't.  Certificates and CRLs have a very 
>>>>specific, well-known
>>>>syntax, so software *can* distinguish between these and 
>>>>other data.  But
>>>>deciding whether the thing that has been signed had the 
>>>>intent of being for
>>>>authentication purposes (e.g., a random challenge, or a data origin
>>>>authentication e-mail) is a very hard problem.
>>>>
>>>>
>>>>I disagree that the distinction that has been proposed is 
>>>>meaningful and
>>>>useful, completely independent of any legal interpretation.
>>>>
>>>>
>>>>Carlisle.
>>>>
>>>>
>>>>
>>>>
>>>>


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g49KkE628390 for ietf-pkix-bks; Thu, 9 May 2002 13:46:14 -0700 (PDT)
Received: from e1.ny.us.ibm.com (e1.ny.us.ibm.com [32.97.182.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g49KkCL28386 for <[e-mail]>; Thu, 9 May 2002 13:46:12 -0700 (PDT)
Received: from northrelay02.pok.ibm.com (northrelay02.pok.ibm.com [9.56.224.150]) by e1.ny.us.ibm.com (8.12.2/8.12.2) with ESMTP id g49KhTAH070304; Thu, 9 May 2002 16:43:29 -0400
Received: from d01ml062.pok.ibm.com (d01ml062.pok.ibm.com [9.117.250.163]) by northrelay02.pok.ibm.com (8.11.1m3/NCO/VER6.1) with ESMTP id g49KhCT25084; Thu, 9 May 2002 16:43:12 -0400
Importance: Normal
Sensitivity: 
Subject: RE: "Authentication" and "Signature" bits...
To: Carlisle Adams <[e-mail]>
Cc: "'David P. Kemp'" <[e-mail]>, "'Santosh Chokhani'" <[e-mail]>, "'500 list (E-mail)'" <[e-mail]>, [e-mail]
X-Mailer: Lotus Notes Release 5.0.7  March 21, 2001
Message-ID: <[e-mail]>
From: "Tom Gindin" <[e-mail]>
Date: Thu, 9 May 2002 16:42:00 -0400
X-MIMETrack: Serialize by Router on D01ML062/01/M/IBM(Release 5.0.10 |March 28, 2002) at 05/09/2002 04:43:16 PM
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 above.proper.com id g49KkDL28387
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

      Carlisle:

      Actually, distinguishing nonces from documents is not a very hard
problem (the lengths are radically different).  The difficulty would be in
distinguishing challenges which are inside larger objects from otherwise
similar objects.

            Tom Gindin

Carlisle Adams <[e-mail]>@mail.imc.org on 05/08/2002
02:15:28 PM

Sent by:    [e-mail]


To:    Carlisle Adams <[e-mail]>, "'David P. Kemp'"
       <[e-mail]>, "'Santosh Chokhani'"
       <[e-mail]>
cc:    "'500 list (E-mail)'" <[e-mail]>,
       [e-mail]
Subject:    RE: "Authentication" and "Signature" bits...


Hi Santosh,


      ----------
      From:   Santosh Chokhani[SMTP:[e-mail]]
      Sent:   Wednesday, May 08, 2002 2:07 PM
      To:     'Carlisle Adams'; 'David P. Kemp'
      Cc:     '500 list (E-mail)'; [e-mail]
      Subject:        RE: "Authentication" and "Signature" bits...


      Carlisle:

      You make persuasive arguments in favor of existing implementation.

      But, on technical grounds, there is a difference between signing a
      challenge and signing to some contents that you want to provide
      digital signatures for.  We have this distinction for certificate and
      CRL and what we have proposed is meaningful and useful without
      getting into all the legal mumbo-jumbo.



I'm not talking about legal mumbo-jumbo.  All I'm saying is that a human
may be able to readily see the difference between random data that has been
signed and meaningful data that has been signed, but in many cases,
software can't.  Certificates and CRLs have a very specific, well-known
syntax, so software *can* distinguish between these and other data.  But
deciding whether the thing that has been signed had the intent of being for
authentication purposes (e.g., a random challenge, or a data origin
authentication e-mail) is a very hard problem.


I disagree that the distinction that has been proposed is meaningful and
useful, completely independent of any legal interpretation.


Carlisle.






Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g49KXOB28143 for ietf-pkix-bks; Thu, 9 May 2002 13:33:24 -0700 (PDT)
Received: from mtiwmhc26.worldnet.att.net (mtiwmhc26.worldnet.att.net [204.127.131.51]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g49KXNL28139 for <[e-mail]>; Thu, 9 May 2002 13:33:23 -0700 (PDT)
Received: from Chokhani ([12.91.133.248]) by mtiwmhc26.worldnet.att.net (InterMail vM.4.01.03.27 201-229-121-127-20010626) with ESMTP id <20020509203319.YAXF7485.mtiwmhc26.worldnet.att.net@Chokhani>; Thu, 9 May 2002 20:33:19 +0000
From: "Santosh Chokhani" <[e-mail]>
To: "'Tony Bartoletti'" <[e-mail]>, "'Carlisle Adams'" <[e-mail]>, "'David P. Kemp'" <[e-mail]>
Cc: "'500 list \(E-mail\)'" <[e-mail]>, <[e-mail]>
Subject: RE: "Authentication" and "Signature" bits...
Date: Thu, 9 May 2002 16:34:51 -0400
Message-ID: <002a01c1f798$f9389850$a300a8c0@Chokhani>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.2627
Importance: Normal
In-Reply-To: <[e-mail]>
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4910.0300
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Tony:

You make a good argument.  But, your very first point while may appear
persuasive at first glance, but as I have said that this is not a
definition of key usage.  Also, please note that none of the other bits
issuing CA can attest to.  They are under the control of relying party
clients.

-----Original Message-----
From: Tony Bartoletti [mailto:[e-mail]] 
Sent: Thursday, May 09, 2002 3:03 PM
To: Carlisle Adams; 'David P. Kemp'
Cc: '500 list (E-mail)'; [e-mail]
Subject: Re: "Authentication" and "Signature" bits...


Relegating the NR-bit to the CA-assertion "I have never seen/touched the

private key" is at least a "do-able" assertion, something under the CA's

control and to which they can attest.  (But why should a CA ever have 
access to even a NR=0 private key?  Why should they need to attest to
that 
which should be standard practice?  I would be no happier that someone 
"authenticated as me" in a malicious telnet session than if they signed
a 
contract in my name.  I could be in hot water, either way.)

I agree with those who feel that NR needs to be asserted in the document

signed, or the signature, rather than in the certificate.

In order to have the NR-bit "mean what we 'thought' it meant", the 
following is as close as I can come to something that might work (if it 
could be relied upon):

Suppose NR=1 in a certificate means that the signing-application must 
"pop-up" a dialog, ASKING the user "which intent is to be employed in
this 
signing".  Basically it would give them the *option* of embedding either
a 
"AUTH-ONLY" intent-token/bit into the data over which the signature
occurs, 
OR an "ATTESTATION" (fuzzy notion that it is) intent-token/bit gets
embedded.

When NR=0, the dialog is never triggered, and no token gets embedded.

Thus, NR=1 does not mean "Non-Repudiable" per se.  Rather, it means 
"message includes the intent-token/bit".  This would allow me to sign 
emails for auth-only, and yet if someone says "I need you to attest to
this 
statement", I can select signature with the ATTESTATION bit included.

One would then assume that if NR=0 in the certificate, a conforming 
application would not allow the insertion of such a token.

Of course, any NR=1 certified private key would need to be protected
just 
as strongly as if any signature intended NR, since it becomes a possible

assertion.

(Whether any of this is enforceable, or useful, or breaks existing 
applications, I haven't thought through.  But at least the case NR=0
would 
not change anything ...)


FWIW ...

____tony____

Tony Bartoletti 925-422-3881 <[e-mail]>
Information Operations, Warfare and Assurance Center
Lawrence Livermore National Laboratory
Livermore, CA 94551-9900






Received: by above.proper.com (8.11.6/8.11.3) id g49IoaY24843 for ietf-pkix-bks; Thu, 9 May 2002 11:50:36 -0700 (PDT)
Received: from smtp-2.llnl.gov (smtp-2.llnl.gov [128.115.250.82]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g49IoZL24839 for <[e-mail]>; Thu, 9 May 2002 11:50:35 -0700 (PDT)
Received: from poptop.llnl.gov (localhost [127.0.0.1]) by smtp-2.llnl.gov (8.9.3/8.9.3/LLNL-gateway-1.0) with ESMTP id LAA02693; Thu, 9 May 2002 11:50:31 -0700 (PDT)
Received: from catalyst.llnl.gov (catalyst.llnl.gov [128.115.222.68]) by poptop.llnl.gov (8.8.8/LLNL-3.0.2/pop.llnl.gov-5.1) with ESMTP id LAA02453; Thu, 9 May 2002 11:50:31 -0700 (PDT)
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Version 4.3.2
Date: Thu, 09 May 2002 12:02:35 -0700
To: Carlisle Adams <[e-mail]>, "'David P. Kemp'" <[e-mail]>
From: Tony Bartoletti <[e-mail]>
Subject: Re: "Authentication" and "Signature" bits...
Cc: "'500 list (E-mail)'" <[e-mail]>, [e-mail]
In-Reply-To: <[e-mail] .com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Relegating the NR-bit to the CA-assertion "I have never seen/touched the 
private key" is at least a "do-able" assertion, something under the CA's 
control and to which they can attest.  (But why should a CA ever have 
access to even a NR=0 private key?  Why should they need to attest to that 
which should be standard practice?  I would be no happier that someone 
"authenticated as me" in a malicious telnet session than if they signed a 
contract in my name.  I could be in hot water, either way.)

I agree with those who feel that NR needs to be asserted in the document 
signed, or the signature, rather than in the certificate.

In order to have the NR-bit "mean what we 'thought' it meant", the 
following is as close as I can come to something that might work (if it 
could be relied upon):

Suppose NR=1 in a certificate means that the signing-application must 
"pop-up" a dialog, ASKING the user "which intent is to be employed in this 
signing".  Basically it would give them the *option* of embedding either a 
"AUTH-ONLY" intent-token/bit into the data over which the signature occurs, 
OR an "ATTESTATION" (fuzzy notion that it is) intent-token/bit gets embedded.

When NR=0, the dialog is never triggered, and no token gets embedded.

Thus, NR=1 does not mean "Non-Repudiable" per se.  Rather, it means 
"message includes the intent-token/bit".  This would allow me to sign 
emails for auth-only, and yet if someone says "I need you to attest to this 
statement", I can select signature with the ATTESTATION bit included.

One would then assume that if NR=0 in the certificate, a conforming 
application would not allow the insertion of such a token.

Of course, any NR=1 certified private key would need to be protected just 
as strongly as if any signature intended NR, since it becomes a possible 
assertion.

(Whether any of this is enforceable, or useful, or breaks existing 
applications, I haven't thought through.  But at least the case NR=0 would 
not change anything ...)


FWIW ...

____tony____

Tony Bartoletti 925-422-3881 <[e-mail]>
Information Operations, Warfare and Assurance Center
Lawrence Livermore National Laboratory
Livermore, CA 94551-9900






Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g491b8X16704 for ietf-pkix-bks; Wed, 8 May 2002 18:37:08 -0700 (PDT)
Received: from spitfire.law.miami.edu (spitfire.law.miami.edu [129.171.187.10]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g491b6L16699 for <[e-mail]>; Wed, 8 May 2002 18:37:06 -0700 (PDT)
Received: from spitfire.law.miami.edu (localhost [127.0.0.1]) by spitfire.law.miami.edu (Postfix) with ESMTP id 412B45C3AEA; Wed,  8 May 2002 21:37:05 -0400 (EDT)
Received: by spitfire.law.miami.edu (Postfix, from userid 1113) id C54695C3AEA; Wed,  8 May 2002 21:37:04 -0400 (EDT)
Received: from localhost (localhost [127.0.0.1]) by spitfire.law.miami.edu (Postfix) with ESMTP id B468C5D3A64; Wed,  8 May 2002 21:37:04 -0400 (EDT)
Date: Wed, 8 May 2002 21:37:04 -0400 (EDT)
From: "Michael Froomkin - U.Miami School of Law" <[e-mail]>
To: todd glassey <[e-mail]>
Cc: PKIX-IETF <[e-mail]>, LISTS - IETF-IESG <[e-mail]>, [e-mail]
Subject: Re: Open issue: requester identifier in DPV response
In-Reply-To: <05fe01c1f6b3$24ab0090$020aff0a@tsg1>
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Merely having a bias, even one that hurts someone, is not a violation of
US (or, insofar as I understand it, EU) anti-trust/competition law.

Oversimplifying slightly, in order to find an offense, you would have to
show concerted action, by a person or persons with a financial interest,
against one or more competitors.

Generally speaking, and again oversimplifying, valid technical grounds is
a defense against many if not most otherwise valid claims of abuse of
standard making.

You will find a less simplistic discussion of these issues, in the context
of US law and ICANN-as-a=standards-body, in an article I am co-authoring
with Mark Lemely, a leading antitrust authority.  A copy of the working
draft is here:
http://personal.law.miami.edu/~froomkin/articles/icann-antitrust.pdf

The statement in your last 3.5 lines of the post quoted below is false as
a matter of US law.  I'd be mildly curious to learn at what law school you
acquired this view, or which non-US (or non-Earth?) legal system you are
referring to with your assurance.

On Wed, 8 May 2002, todd glassey wrote:

> Michael restraint of trade is actionable. refusing to allow any effort to
> pass without a definition of the formal processes to be applied to all
> submissions, i.e. how the IETF  is setup today, leaves the entirety to the
> WG Chairs and their AD's and that it the problem and I assure you that if it
> can be demonstrated to any level that anyone in a standards organization
> gave undue advantage to one protocol over an other and anyone suffered a
> financial loss because of this act, that this is assuredly actionable.
> 
> Todd
> 
> ----- Original Message -----
> From: "Michael Froomkin - U.Miami School of Law" <[e-mail]>
> To: "todd glassey" <[e-mail]>
> Cc: "PKIX-IETF" <[e-mail]>; "LISTS - IETF-IESG" <[e-mail]>;
> <[e-mail]>
> Sent: Monday, April 29, 2002 8:10 PM
> Subject: Re: Open issue: requester identifier in DPV response
> 
> 
> > "Actionable"?  I rather doubt it.  At least not in the US, and not without
> > many aggravating circumstances.
> >
> > On Sat, 27 Apr 2002, todd glassey wrote:
> >
> > > Stephen - I think that it is very likely that ANY involvement by a WG
> Chair
> > > in ANY protocol at any level is a conflict of interest and actionable as
> > > such. It shows a predudicial predisposition towards that protocol and
> favors
> > > it over all others. This is why I am demanding the rewriting of the WG's
> > > charter as well as the approriate sections of RFC2026 et al..
> > >
> > [....]
> > --
> > Please visit http://www.icannwatch.org
> >
> > A. Michael Froomkin   |    Professor of Law    |   [e-mail]
> > U. Miami School of Law, P.O. Box 248087, Coral Gables, FL 33124 USA
> > [phone]  |  [phone] (fax)  |  http://www.law.tm
> >                         -->It's hot here.<--
> >
> 
> 

-- 
		Please visit http://www.icannwatch.org
A. Michael Froomkin   |    Professor of Law    |   [e-mail]
U. Miami School of Law, P.O. Box 248087, Coral Gables, FL 33124 USA
[phone]  |  [phone] (fax)  |  http://www.law.tm
                        -->It's hot here.<--



Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g48IaqT03239 for ietf-pkix-bks; Wed, 8 May 2002 11:36:52 -0700 (PDT)
Received: from mtiwmhc24.worldnet.att.net (mtiwmhc24.worldnet.att.net [204.127.131.49]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g48IapL03235 for <[e-mail]>; Wed, 8 May 2002 11:36:51 -0700 (PDT)
Received: from Chokhani ([12.91.132.6]) by mtiwmhc24.worldnet.att.net (InterMail vM.4.01.03.27 201-229-121-127-20010626) with ESMTP id <20020508183642.ZUDW18857.mtiwmhc24.worldnet.att.net@Chokhani>; Wed, 8 May 2002 18:36:42 +0000
From: "Santosh Chokhani" <[e-mail]>
To: "'Peter Williams'" <[e-mail]>, "'David P. Kemp'" <[e-mail]>, <[e-mail]>
Subject: RE: Meaning of Non-repudiation
Date: Wed, 8 May 2002 14:38:12 -0400
Message-ID: <001801c1f6bf$8333a1b0$06845b0c@Chokhani>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.2627
Importance: Normal
In-Reply-To: <[e-mail]>
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4910.0300
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

I would still call the entity authentication and it will come under one
bit for entity authentication as opposed to the other bit for digital
signature.

-----Original Message-----
From: Peter Williams [mailto:[e-mail]] 
Sent: Wednesday, May 08, 2002 2:25 PM
To: 'Santosh Chokhani'; 'David P. Kemp'; [e-mail]
Subject: RE: Meaning of Non-repudiation



Does this mean that in a challenge-response scheme that does not use
nonces (it specifically uses timestamps instead, e.g. X.509 
procedures) that one uses dataSign?

 
>>>>Bill,
>>>>
>>>>I have no problem with X.509 and PKIX following Trevor's approach. 
>>>>Deprecate (using the strongest possible terms) the existing KeyUsage

>>>>OID, and define a new KeyUsage OID identical to the old one except 
>>>>that bits 0 and 1 are replaced by nonceSign and dataSign.
>>>>
>>>>Dave



Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g48IPHI02849 for ietf-pkix-bks; Wed, 8 May 2002 11:25:17 -0700 (PDT)
Received: from ext-mail.valicert.com ([66.206.205.11]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g48IPFL02840 for <[e-mail]>; Wed, 8 May 2002 11:25:15 -0700 (PDT)
Received: from CONVERSION-DAEMON by ext-mail.valicert.com (PMDF V5.2-33 #46613) id <[e-mail]> for [e-mail]; Wed, 8 May 2002 11:21:11 -0700 (PDT)
Received: from polaris.valicert.com ([192.168.2.34]) by ext-mail.valicert.com (PMDF V5.2-33 #46613) with ESMTP id <[e-mail]>; Wed, 08 May 2002 11:21:10 -0700 (PDT)
Received: by polaris.valicert.com with Internet Mail Service (5.5.2653.19) id <JQL5CKHW>; Wed, 08 May 2002 11:24:58 -0700
Content-return: allowed
Date: Wed, 08 May 2002 11:24:45 -0700
From: Peter Williams <[e-mail]>
Subject: RE: Meaning of Non-repudiation
To: "'Santosh Chokhani'" <[e-mail]>, "'David P. Kemp'" <[e-mail]>, [e-mail]
Message-id: <[e-mail]>
MIME-version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-type: text/plain
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Does this mean that in a challenge-response scheme that does not
use nonces (it specifically uses timestamps instead, e.g. X.509 
procedures) that one uses dataSign?

 
>>>>Bill,
>>>>
>>>>I have no problem with X.509 and PKIX following Trevor's approach.
>>>>Deprecate (using the strongest possible terms) the existing KeyUsage
>>>>OID, and define a new KeyUsage OID identical to the old one 
>>>>except that
>>>>bits 0 and 1 are replaced by nonceSign and dataSign.
>>>>
>>>>Dave


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g48IFYn02587 for ietf-pkix-bks; Wed, 8 May 2002 11:15:34 -0700 (PDT)
Received: from SOTTMXS01.entrust.com (mail.entrust.com [216.191.251.35]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g48IFXL02583 for <[e-mail]>; Wed, 8 May 2002 11:15:33 -0700 (PDT)
Received: by SOTTMXS01.entrust.com with Internet Mail Service (5.5.2653.19) id <KQ6A91TK>; Wed, 8 May 2002 14:15:29 -0400
Message-ID: <[e-mail]>
From: Carlisle Adams <[e-mail]>
To: Carlisle Adams <[e-mail]>, "'David P. Kemp'" <[e-mail]>, "'Santosh Chokhani'" <[e-mail]>
Cc: "'500 list (E-mail)'" <[e-mail]>, [e-mail]
Subject: RE: "Authentication" and "Signature" bits...
Date: Wed, 8 May 2002 14:15:28 -0400 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1F6BC.55523520"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

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_01C1F6BC.55523520
Content-Type: text/plain

Hi Santosh,

> ----------
> From: 	Santosh Chokhani[SMTP:[e-mail]]
> Sent: 	Wednesday, May 08, 2002 2:07 PM
> To: 	'Carlisle Adams'; 'David P. Kemp'
> Cc: 	'500 list (E-mail)'; [e-mail]
> Subject: 	RE: "Authentication" and "Signature" bits...
> 
> Carlisle:
>  
> You make persuasive arguments in favor of existing implementation.  
>  
> But, on technical grounds, there is a difference between signing a
> challenge and signing to some contents that you want to provide digital
> signatures for.  We have this distinction for certificate and CRL and what
> we have proposed is meaningful and useful without getting into all the
> legal mumbo-jumbo.
 
I'm not talking about legal mumbo-jumbo.  All I'm saying is that a human may
be able to readily see the difference between random data that has been
signed and meaningful data that has been signed, but in many cases, software
can't.  Certificates and CRLs have a very specific, well-known syntax, so
software *can* distinguish between these and other data.  But deciding
whether the thing that has been signed had the intent of being for
authentication purposes (e.g., a random challenge, or a data origin
authentication e-mail) is a very hard problem.

I disagree that the distinction that has been proposed is meaningful and
useful, completely independent of any legal interpretation.

Carlisle.


------_=_NextPart_001_01C1F6BC.55523520
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.2653.12">
<TITLE>RE: &quot;Authentication&quot; and &quot;Signature&quot; =
bits...</TITLE>
</HEAD>
<BODY>

<P><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Times New Roman">Hi =
Santosh,</FONT>
</P>
<UL>
<P><FONT SIZE=3D2 FACE=3D"MS Sans Serif">----------</FONT>
<BR><B><FONT SIZE=3D2 FACE=3D"MS Sans Serif">From:</FONT></B> &nbsp; =
<FONT SIZE=3D2 FACE=3D"MS Sans Serif">Santosh =
Chokhani[SMTP:[e-mail]]</FONT>
<BR><B><FONT SIZE=3D2 FACE=3D"MS Sans Serif">Sent:</FONT></B> &nbsp; =
<FONT SIZE=3D2 FACE=3D"MS Sans Serif">Wednesday, May 08, 2002 2:07 =
PM</FONT>
<BR><B><FONT SIZE=3D2 FACE=3D"MS Sans Serif">To:</FONT></B> =
&nbsp;&nbsp;&nbsp; <FONT SIZE=3D2 FACE=3D"MS Sans Serif">'Carlisle =
Adams'; 'David P. Kemp'</FONT>
<BR><B><FONT SIZE=3D2 FACE=3D"MS Sans Serif">Cc:</FONT></B> =
&nbsp;&nbsp;&nbsp; <FONT SIZE=3D2 FACE=3D"MS Sans Serif">'500 list =
(E-mail)'; [e-mail]</FONT>
<BR><B><FONT SIZE=3D2 FACE=3D"MS Sans Serif">Subject:</FONT></B> =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT SIZE=3D2 FACE=3D"MS Sans =
Serif">RE: &quot;Authentication&quot; and &quot;Signature&quot; =
bits...</FONT>
</P>

<P><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Arial">Carlisle:</FONT>
<BR><FONT FACE=3D"Arial">=A0</FONT>
<BR><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Arial">You make persuasive =
arguments in favor of existing implementation.=A0</FONT>=20
<BR><FONT FACE=3D"Arial">=A0</FONT>
<BR><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Arial">But, on technical =
grounds, there is a difference between signing a challenge and signing =
to some contents that you want to provide digital signatures for.=A0 We =
have this distinction for certificate and CRL and what we have proposed =
is meaningful and useful without getting into all the legal =
mumbo-jumbo.</FONT></P>
</UL>
<P><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Times New =
Roman">&nbsp;</FONT>
<BR><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Times New Roman">I'm not =
talking about legal mumbo-jumbo.&nbsp; All I'm saying is that a human =
may be able to readily see the difference between random data that has =
been signed and meaningful data that has been signed, but in many =
cases, software can't.&nbsp; Certificates and CRLs have a very =
specific, well-known syntax, so software *can* distinguish between =
these and other data.&nbsp; But deciding whether the thing that has =
been signed had the intent of being for authentication purposes (e.g., =
a random challenge, or a data origin authentication e-mail) is a very =
hard problem.</FONT></P>

<P><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Times New Roman">I disagree =
that the distinction that has been proposed is meaningful and useful, =
completely independent of any legal interpretation.</FONT></P>

<P><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Times New =
Roman">Carlisle.</FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C1F6BC.55523520--


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g48I5m602325 for ietf-pkix-bks; Wed, 8 May 2002 11:05:48 -0700 (PDT)
Received: from mtiwmhc21.worldnet.att.net (mtiwmhc21.worldnet.att.net [204.127.131.46]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g48I5lL02321 for <[e-mail]>; Wed, 8 May 2002 11:05:47 -0700 (PDT)
Received: from Chokhani ([12.91.132.6]) by mtiwmhc21.worldnet.att.net (InterMail vM.4.01.03.27 201-229-121-127-20010626) with ESMTP id <20020508180540.LUR24238.mtiwmhc21.worldnet.att.net@Chokhani>; Wed, 8 May 2002 18:05:40 +0000
From: "Santosh Chokhani" <[e-mail]>
To: "'Carlisle Adams'" <[e-mail]>, "'David P. Kemp'" <[e-mail]>
Cc: "'500 list \(E-mail\)'" <[e-mail]>, <[e-mail]>
Subject: RE: "Authentication" and "Signature" bits...
Date: Wed, 8 May 2002 14:07:10 -0400
Message-ID: <000f01c1f6bb$2d745340$06845b0c@Chokhani>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_0010_01C1F699.A662B340"
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.2627
Importance: Normal
In-Reply-To: <[e-mail]>
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4910.0300
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

This is a multi-part message in MIME format.

------=_NextPart_000_0010_01C1F699.A662B340
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit

Carlisle:
 
You make persuasive arguments in favor of existing implementation.  
 
But, on technical grounds, there is a difference between signing a
challenge and signing to some contents that you want to provide digital
signatures for.  We have this distinction for certificate and CRL and
what we have proposed is meaningful and useful without getting into all
the legal mumbo-jumbo.

-----Original Message-----
From: Carlisle Adams [mailto:[e-mail]] 
Sent: Wednesday, May 08, 2002 1:25 PM
To: 'David P. Kemp'
Cc: '500 list (E-mail)'; [e-mail]
Subject: "Authentication" and "Signature" bits...



Hi Dave, 

	---------- 
From:   David P. Kemp[SMTP:[e-mail]] 
Sent:   Wednesday, May 08, 2002 10:49 AM 
To:     [e-mail] 
Cc:     '500 list (E-mail)' 
Subject:        Re: Meaning of Non-repudiation 

	Bill, 

	I have no problem with X.509 and PKIX following Trevor's
approach. 
Deprecate (using the strongest possible terms) the existing KeyUsage 
OID, and define a new KeyUsage OID identical to the old one except 
that bits 0 and 1 are replaced by nonceSign and dataSign. 


Separating authentication and signature seems somewhat attractive on a
first glance, but I would personally be very reluctant to pursue this.
There are three reasons for this.  The first is fairly simple and
perhaps of minor significance:  because authentication in this context
is accomplished through a signature (e.g., signing a random challenge),
this doesn't "feel" like a different key usage to me.  Both bits tell
the relying party that it can use the public key in this certificate to
verify a signature.

The second reason is of slightly higher significance:  it is not always
clear when someone is signing with intent and when someone is
authenticating.  Dean Adams (no relation :-) recently sent the following
examples.

	In the first case, we are using a digital signature technical
capability to authenticate ourselves, much as we have done in the past
with passwords.  The real action that we are undertaking is
authentication - the fact it is accomplished via a digital signature
mechanism is interesting to cryptographers but not necessariliy to
systems administrators, business managers and the like.

	
In the second case, we are putting our name on a communication,
transaction or document for a variety of reasons (as we do in real life
with real signatures) - perhaps to indicate approval of some action
(that the transaction should go ahead, or that the contents of this
document or communication are accepted or formally issued by me), or as
in the case of a written memo from the CEO to all staff - that the
contents actually come from the the CEO.

The very last example he gave (that the contents actually come from the
CEO) was very clearly put in the "digital signature" category.  But to
me, this is data origin authentication, pure and simple.  So, if there
were two certificates, one with an authentication bit set and the other
with a DS bit set, which one should the CEO use?  Whichever he picks
will be rejected by either Dean or me when we go to verify this message.

The third reason is the most fundamental and so, to me, is the most
significant.  One of the main reasons we've had so much trouble
distinguishing between the DS bit and the NR bit is that it requires the
relying party (as well as the sender) to understand the nature of the
data that is signed.  "Is this just 'ordinary' data, or is it 'special'
in some way?"  Making this distinction can be very difficult (perhaps
impossible?) for relying party software; humans often need to be
involved.  But distinguishing between data that has been signed for the
purpose of authentication and data that has been signed for any other
purpose can also be very difficult (perhaps impossible?) for relying
party software.  If I send a random challenge and receive back that
challenge signed, then of course I know what the data is.  But what
other relying party software anywhere in the world will be able to tell
if this data is a random string or a meaningful message encoded in some
way?  What software can tell the difference between an e-mail signed
purely for data origin authentication and one signed to signify that the
sender agrees with the content?

I contend that, in the general case, trying to make a distinction (in
standards specifications and in products) between an A bit and a DS bit
will be no easier than trying to make a distinction between an NR bit
and a DS bit.  Consequently, we will find ourselves no further ahead if
we deprecate the current key usage extension and create a new one that
begins with A and DS instead.

My vote is solidly in favour of retaining the current extension.  The DS
bit is, I think, clear:  "the public key in this certificate can be used
to verify signatures on any data except certificates or CRLs (which are
easy to recognize, so there's no confusion)".  The NR bit could be
deprecated, or could be given the interpretation suggested by Bill Burr
(the CA attests that it has never had access to the corresponding
private key).  I personally prefer Bill's interpretation.  I think it is
very clear, even in the situation that Stefan raised (whether the keys
were produced on the smart card, or produced in a separate box and
injected onto the card, the CA itself did not have access to the private
key and so can still validly set this bit).  It is something concrete
and explicit that the CA can say in a certificate, and it can certainly
support non-repudiation in accordance with other policies and
procedures.  The only possible drawback with this interpretation is that
it is in no sense a "key usage", but the NR bit has never really been
that, so we haven't lost anything.  Furthermore, as Bill suggested, this
narrower interpretation is highly unlikely to break any existing
software.  So I can't think of a single reason not to use this
interpretation.

Carlisle. 


------=_NextPart_000_0010_01C1F699.A662B340
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Dus-ascii">
<TITLE>Message</TITLE>

<META content=3D"MSHTML 5.50.4915.500" name=3DGENERATOR></HEAD>
<BODY>
<DIV><SPAN class=3D719440118-08052002><FONT face=3DArial color=3D#0000ff =

size=3D2>Carlisle:</FONT></SPAN></DIV>
<DIV><SPAN class=3D719440118-08052002><FONT face=3DArial color=3D#0000ff =

size=3D2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=3D719440118-08052002><FONT face=3DArial color=3D#0000ff =
size=3D2>You=20
make persuasive arguments in favor of existing implementation.&nbsp;=20
</FONT></SPAN></DIV>
<DIV><SPAN class=3D719440118-08052002><FONT face=3DArial color=3D#0000ff =

size=3D2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=3D719440118-08052002><FONT face=3DArial color=3D#0000ff =
size=3D2>But,=20
on technical grounds, there is a difference between signing a challenge =
and=20
signing to some contents that you want to provide digital signatures =
for.&nbsp;=20
We have this distinction for certificate and CRL and what we have =
proposed is=20
meaningful and useful without getting into all the legal=20
mumbo-jumbo.</FONT></SPAN></DIV>
<BLOCKQUOTE dir=3Dltr style=3D"MARGIN-RIGHT: 0px">
  <DIV></DIV>
  <DIV class=3DOutlookMessageHeader lang=3Den-us dir=3Dltr =
align=3Dleft><FONT=20
  face=3DTahoma size=3D2>-----Original Message-----<BR><B>From:</B> =
Carlisle Adams=20
  [mailto:[e-mail]] <BR><B>Sent:</B> Wednesday, May =
08, 2002=20
  1:25 PM<BR><B>To:</B> 'David P. Kemp'<BR><B>Cc:</B> '500 list =
(E-mail)';=20
  [e-mail]<BR><B>Subject:</B> "Authentication" and "Signature"=20
  bits...<BR><BR></FONT></DIV>
  <P><FONT face=3D"Times New Roman" color=3D#0000ff size=3D2>Hi =
Dave,</FONT> </P>
  <UL>
    <P><FONT face=3D"MS Sans Serif" size=3D2>----------</FONT> =
<BR><B><FONT=20
    face=3D"MS Sans Serif" size=3D2>From:</FONT></B> &nbsp; <FONT=20
    face=3D"MS Sans Serif" size=3D2>David P. =
Kemp[SMTP:[e-mail]]</FONT>=20
    <BR><B><FONT face=3D"MS Sans Serif" size=3D2>Sent:</FONT></B> &nbsp; =
<FONT=20
    face=3D"MS Sans Serif" size=3D2>Wednesday, May 08, 2002 10:49 =
AM</FONT>=20
    <BR><B><FONT face=3D"MS Sans Serif" size=3D2>To:</FONT></B> =
&nbsp;&nbsp;&nbsp;=20
    <FONT face=3D"MS Sans Serif" size=3D2>[e-mail]</FONT> =
<BR><B><FONT=20
    face=3D"MS Sans Serif" size=3D2>Cc:</FONT></B> &nbsp;&nbsp;&nbsp; =
<FONT=20
    face=3D"MS Sans Serif" size=3D2>'500 list (E-mail)'</FONT> =
<BR><B><FONT=20
    face=3D"MS Sans Serif" size=3D2>Subject:</FONT></B>=20
    &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT face=3D"MS Sans Serif" =
size=3D2>Re:=20
    Meaning of Non-repudiation</FONT> </P>
    <P><FONT face=3DArial size=3D2>Bill,</FONT> </P>
    <P><FONT face=3DArial size=3D2>I have no problem with X.509 and PKIX =
following=20
    Trevor's approach.</FONT> <BR><FONT face=3DArial size=3D2>Deprecate =
(using the=20
    strongest possible terms) the existing KeyUsage</FONT> <BR><FONT =
face=3DArial=20
    size=3D2>OID, and define a new KeyUsage OID identical to the old one =

    except</FONT> <BR><FONT face=3DArial size=3D2>that bits 0 and 1 are =
replaced by=20
    nonceSign and dataSign.</FONT> </P></UL>
  <P><FONT face=3D"Times New Roman" color=3D#0000ff size=3D2></FONT> =
<BR><FONT=20
  face=3D"Times New Roman" color=3D#0000ff size=3D2>Separating =
authentication and=20
  signature seems somewhat attractive on a first glance, but I would =
personally=20
  be very reluctant to pursue this.&nbsp; There are three reasons for=20
  this.&nbsp; The first is fairly simple and perhaps of minor=20
  significance:&nbsp; because authentication in this context is =
accomplished=20
  through a signature (e.g., signing a random challenge), this doesn't =
"feel"=20
  like a different key usage to me.&nbsp; Both bits tell the relying =
party that=20
  it can use the public key in this certificate to verify a=20
signature.</FONT></P>
  <P><FONT face=3D"Times New Roman" color=3D#0000ff size=3D2>The second =
reason is of=20
  slightly higher significance:&nbsp; it is not always clear when =
someone is=20
  signing with intent and when someone is authenticating.&nbsp; Dean =
Adams (no=20
  relation :-) recently sent the following examples.</FONT></P>
  <UL>
    <P><FONT face=3DArial size=3D2>In the first case, we are using a =
digital=20
    signature technical capability to authenticate ourselves, much as we =
have=20
    done in the past with passwords.&nbsp; The real action that we are=20
    undertaking is authentication - the fact it is accomplished via a =
digital=20
    signature mechanism is interesting to cryptographers but not =
necessariliy to=20
    systems administrators, business managers and the like.</FONT></P>
    <P><FONT face=3DArial></FONT> <BR><FONT face=3DArial size=3D2>In the =
second case,=20
    we are putting our name on a communication, transaction or document =
for a=20
    variety of reasons (as we do in real life with real signatures) - =
perhaps to=20
    indicate approval of some action (that the transaction should go =
ahead, or=20
    that the contents of this document or communication are accepted or =
formally=20
    issued by me), or as in the case of a written memo from the CEO to =
all staff=20
    - that the contents actually come from the the CEO.</FONT></P></UL>
  <P><FONT face=3D"Times New Roman" color=3D#0000ff size=3D2>The very =
last example he=20
  gave (that the contents actually come from the CEO) was very clearly =
put in=20
  the "digital signature" category.&nbsp; But to me, this is data origin =

  authentication, pure and simple.&nbsp; So, if there were two =
certificates, one=20
  with an authentication bit set and the other with a DS bit set, which =
one=20
  should the CEO use?&nbsp; Whichever he picks will be rejected by =
either Dean=20
  or me when we go to verify this message.</FONT></P>
  <P><FONT face=3D"Times New Roman" color=3D#0000ff size=3D2>The third =
reason is the=20
  most fundamental and so, to me, is the most significant.&nbsp; One of =
the main=20
  reasons we've had so much trouble distinguishing between the DS bit =
and the NR=20
  bit is that it requires the relying party (as well as the sender) to=20
  understand the nature of the data that is signed.&nbsp; "Is this just=20
  'ordinary' data, or is it 'special' in some way?"&nbsp; Making this=20
  distinction can be very difficult (perhaps impossible?) for relying =
party=20
  software; humans often need to be involved.&nbsp; But distinguishing =
between=20
  data that has been signed for the purpose of authentication and data =
that has=20
  been signed for any other purpose can also be very difficult (perhaps=20
  impossible?) for relying party software.&nbsp; If I send a random =
challenge=20
  and receive back that challenge signed, then of course I know what the =
data=20
  is.&nbsp; But what other relying party software anywhere in the world =
will be=20
  able to tell if this data is a random string or a meaningful message =
encoded=20
  in some way?&nbsp; What software can tell the difference between an =
e-mail=20
  signed purely for data origin authentication and one signed to signify =
that=20
  the sender agrees with the content?</FONT></P>
  <P><FONT face=3D"Times New Roman" color=3D#0000ff size=3D2>I contend =
that, in the=20
  general case, trying to make a distinction (in standards =
specifications and in=20
  products) between an A bit and a DS bit will be no easier than trying =
to make=20
  a distinction between an NR bit and a DS bit.&nbsp; Consequently, we =
will find=20
  ourselves no further ahead if we deprecate the current key usage =
extension and=20
  create a new one that begins with A and DS instead.</FONT></P>
  <P><FONT face=3D"Times New Roman" color=3D#0000ff size=3D2>My vote is =
solidly in=20
  favour of retaining the current extension.&nbsp; The DS bit is, I =
think,=20
  clear:&nbsp; "the public key in this certificate can be used to verify =

  signatures on any data except certificates or CRLs (which are easy to=20
  recognize, so there's no confusion)".&nbsp; The NR bit could be =
deprecated, or=20
  could be given the interpretation suggested by Bill Burr (the CA =
attests that=20
  it has never had access to the corresponding private key).&nbsp; I =
personally=20
  prefer Bill's interpretation.&nbsp; I think it is very clear, even in =
the=20
  situation that Stefan raised (whether the keys were produced on the =
smart=20
  card, or produced in a separate box and injected onto the card, the CA =
itself=20
  did not have access to the private key and so can still validly set =
this=20
  bit).&nbsp; It is something concrete and explicit that the CA can say =
in a=20
  certificate, and it can certainly support non-repudiation in =
accordance with=20
  other policies and procedures.&nbsp; The only possible drawback with =
this=20
  interpretation is that it is in no sense a "key usage", but the NR bit =
has=20
  never really been that, so we haven't lost anything.&nbsp; =
Furthermore, as=20
  Bill suggested, this narrower interpretation is highly unlikely to =
break any=20
  existing software.&nbsp; So I can't think of a single reason not to =
use this=20
  interpretation.</FONT></P>
  <P><FONT face=3D"Times New Roman" color=3D#0000ff =
size=3D2>Carlisle.</FONT>=20
</P></BLOCKQUOTE></BODY></HTML>

------=_NextPart_000_0010_01C1F699.A662B340--



Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g48HOgb00661 for ietf-pkix-bks; Wed, 8 May 2002 10:24:42 -0700 (PDT)
Received: from SOTTMXS01.entrust.com (mail.entrust.com [216.191.251.35]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g48HOfL00657 for <[e-mail]>; Wed, 8 May 2002 10:24:41 -0700 (PDT)
Received: by SOTTMXS01.entrust.com with Internet Mail Service (5.5.2653.19) id <KQ6A9D4S>; Wed, 8 May 2002 13:24:32 -0400
Message-ID: <[e-mail]>
From: Carlisle Adams <[e-mail]>
To: "'David P. Kemp'" <[e-mail]>
Cc: "'500 list (E-mail)'" <[e-mail]>, [e-mail]
Subject: "Authentication" and "Signature" bits...
Date: Wed, 8 May 2002 13:24:32 -0400 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1F6B5.37773FC0"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

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

Hi Dave,

> ----------
> From: 	David P. Kemp[SMTP:[e-mail]]
> Sent: 	Wednesday, May 08, 2002 10:49 AM
> To: 	[e-mail]
> Cc: 	'500 list (E-mail)'
> Subject: 	Re: Meaning of Non-repudiation
> 
> Bill,
> 
> I have no problem with X.509 and PKIX following Trevor's approach.
> Deprecate (using the strongest possible terms) the existing KeyUsage
> OID, and define a new KeyUsage OID identical to the old one except
> that bits 0 and 1 are replaced by nonceSign and dataSign.
 
Separating authentication and signature seems somewhat attractive on a first
glance, but I would personally be very reluctant to pursue this.  There are
three reasons for this.  The first is fairly simple and perhaps of minor
significance:  because authentication in this context is accomplished
through a signature (e.g., signing a random challenge), this doesn't "feel"
like a different key usage to me.  Both bits tell the relying party that it
can use the public key in this certificate to verify a signature.

The second reason is of slightly higher significance:  it is not always
clear when someone is signing with intent and when someone is
authenticating.  Dean Adams (no relation :-) recently sent the following
examples.

	In the first case, we are using a digital signature technical
capability to authenticate ourselves, much as we have done in the past with
passwords.  The real action that we are undertaking is authentication - the
fact it is accomplished via a digital signature mechanism is interesting to
cryptographers but not necessariliy to systems administrators, business
managers and the like.
	 
	In the second case, we are putting our name on a communication,
transaction or document for a variety of reasons (as we do in real life with
real signatures) - perhaps to indicate approval of some action (that the
transaction should go ahead, or that the contents of this document or
communication are accepted or formally issued by me), or as in the case of a
written memo from the CEO to all staff - that the contents actually come
from the the CEO.

The very last example he gave (that the contents actually come from the CEO)
was very clearly put in the "digital signature" category.  But to me, this
is data origin authentication, pure and simple.  So, if there were two
certificates, one with an authentication bit set and the other with a DS bit
set, which one should the CEO use?  Whichever he picks will be rejected by
either Dean or me when we go to verify this message.

The third reason is the most fundamental and so, to me, is the most
significant.  One of the main reasons we've had so much trouble
distinguishing between the DS bit and the NR bit is that it requires the
relying party (as well as the sender) to understand the nature of the data
that is signed.  "Is this just 'ordinary' data, or is it 'special' in some
way?"  Making this distinction can be very difficult (perhaps impossible?)
for relying party software; humans often need to be involved.  But
distinguishing between data that has been signed for the purpose of
authentication and data that has been signed for any other purpose can also
be very difficult (perhaps impossible?) for relying party software.  If I
send a random challenge and receive back that challenge signed, then of
course I know what the data is.  But what other relying party software
anywhere in the world will be able to tell if this data is a random string
or a meaningful message encoded in some way?  What software can tell the
difference between an e-mail signed purely for data origin authentication
and one signed to signify that the sender agrees with the content?

I contend that, in the general case, trying to make a distinction (in
standards specifications and in products) between an A bit and a DS bit will
be no easier than trying to make a distinction between an NR bit and a DS
bit.  Consequently, we will find ourselves no further ahead if we deprecate
the current key usage extension and create a new one that begins with A and
DS instead.

My vote is solidly in favour of retaining the current extension.  The DS bit
is, I think, clear:  "the public key in this certificate can be used to
verify signatures on any data except certificates or CRLs (which are easy to
recognize, so there's no confusion)".  The NR bit could be deprecated, or
could be given the interpretation suggested by Bill Burr (the CA attests
that it has never had access to the corresponding private key).  I
personally prefer Bill's interpretation.  I think it is very clear, even in
the situation that Stefan raised (whether the keys were produced on the
smart card, or produced in a separate box and injected onto the card, the CA
itself did not have access to the private key and so can still validly set
this bit).  It is something concrete and explicit that the CA can say in a
certificate, and it can certainly support non-repudiation in accordance with
other policies and procedures.  The only possible drawback with this
interpretation is that it is in no sense a "key usage", but the NR bit has
never really been that, so we haven't lost anything.  Furthermore, as Bill
suggested, this narrower interpretation is highly unlikely to break any
existing software.  So I can't think of a single reason not to use this
interpretation.

Carlisle.


------_=_NextPart_001_01C1F6B5.37773FC0
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.2653.12">
<TITLE>&quot;Authentication&quot; and &quot;Signature&quot; =
bits...</TITLE>
</HEAD>
<BODY>

<P><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Times New Roman">Hi =
Dave,</FONT>
</P>
<UL>
<P><FONT SIZE=3D2 FACE=3D"MS Sans Serif">----------</FONT>
<BR><B><FONT SIZE=3D2 FACE=3D"MS Sans Serif">From:</FONT></B> &nbsp; =
<FONT SIZE=3D2 FACE=3D"MS Sans Serif">David P. =
Kemp[SMTP:[e-mail]]</FONT>
<BR><B><FONT SIZE=3D2 FACE=3D"MS Sans Serif">Sent:</FONT></B> &nbsp; =
<FONT SIZE=3D2 FACE=3D"MS Sans Serif">Wednesday, May 08, 2002 10:49 =
AM</FONT>
<BR><B><FONT SIZE=3D2 FACE=3D"MS Sans Serif">To:</FONT></B> =
&nbsp;&nbsp;&nbsp; <FONT SIZE=3D2 FACE=3D"MS Sans =
Serif">[e-mail]</FONT>
<BR><B><FONT SIZE=3D2 FACE=3D"MS Sans Serif">Cc:</FONT></B> =
&nbsp;&nbsp;&nbsp; <FONT SIZE=3D2 FACE=3D"MS Sans Serif">'500 list =
(E-mail)'</FONT>
<BR><B><FONT SIZE=3D2 FACE=3D"MS Sans Serif">Subject:</FONT></B> =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT SIZE=3D2 FACE=3D"MS Sans =
Serif">Re: Meaning of Non-repudiation</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">Bill,</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">I have no problem with X.509 and PKIX =
following Trevor's approach.</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">Deprecate (using the strongest =
possible terms) the existing KeyUsage</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">OID, and define a new KeyUsage OID =
identical to the old one except</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">that bits 0 and 1 are replaced by =
nonceSign and dataSign.</FONT>
</UL>
<P><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Times New =
Roman">&nbsp;</FONT>
<BR><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Times New =
Roman">Separating authentication and signature seems somewhat =
attractive on a first glance, but I would personally be very reluctant =
to pursue this.&nbsp; There are three reasons for this.&nbsp; The first =
is fairly simple and perhaps of minor significance:&nbsp; because =
authentication in this context is accomplished through a signature =
(e.g., signing a random challenge), this doesn't &quot;feel&quot; like =
a different key usage to me.&nbsp; Both bits tell the relying party =
that it can use the public key in this certificate to verify a =
signature.</FONT></P>

<P><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Times New Roman">The second =
reason is of slightly higher significance:&nbsp; it is not always clear =
when someone is signing with intent and when someone is =
authenticating.&nbsp; Dean Adams (no relation :-) recently sent the =
following examples.</FONT></P>
<UL>
<P><FONT SIZE=3D2 FACE=3D"Arial">In the first case, we are using a =
digital signature technical capability to authenticate ourselves, much =
as we have done in the past with passwords.=A0 The real action that we =
are undertaking is authentication - the fact it is accomplished via a =
digital signature mechanism is interesting to cryptographers but not =
necessariliy to systems administrators, business managers and the =
like.</FONT></P>

<P><FONT FACE=3D"Arial">=A0</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">In the second case, we are putting =
our name on a communication, transaction or document for a variety of =
reasons (as we do in real life with real signatures) - perhaps to =
indicate approval of some action (that the transaction should go ahead, =
or that the contents of this document or communication are accepted or =
formally issued by me), or as in the case of a written memo from the =
CEO to all staff - that the contents actually come from the the =
CEO.</FONT></P>
</UL>
<P><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Times New Roman">The very =
last example he gave (that the contents actually come from the CEO) was =
very clearly put in the &quot;digital signature&quot; category.&nbsp; =
But to me, this is data origin authentication, pure and simple.&nbsp; =
So, if there were two certificates, one with an authentication bit set =
and the other with a DS bit set, which one should the CEO use?&nbsp; =
Whichever he picks will be rejected by either Dean or me when we go to =
verify this message.</FONT></P>

<P><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Times New Roman">The third =
reason is the most fundamental and so, to me, is the most =
significant.&nbsp; One of the main reasons we've had so much trouble =
distinguishing between the DS bit and the NR bit is that it requires =
the relying party (as well as the sender) to understand the nature of =
the data that is signed.&nbsp; &quot;Is this just 'ordinary' data, or =
is it 'special' in some way?&quot;&nbsp; Making this distinction can be =
very difficult (perhaps impossible?) for relying party software; humans =
often need to be involved.&nbsp; But distinguishing between data that =
has been signed for the purpose of authentication and data that has =
been signed for any other purpose can also be very difficult (perhaps =
impossible?) for relying party software.&nbsp; If I send a random =
challenge and receive back that challenge signed, then of course I know =
what the data is.&nbsp; But what other relying party software anywhere =
in the world will be able to tell if this data is a random string or a =
meaningful message encoded in some way?&nbsp; What software can tell =
the difference between an e-mail signed purely for data origin =
authentication and one signed to signify that the sender agrees with =
the content?</FONT></P>

<P><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Times New Roman">I contend =
that, in the general case, trying to make a distinction (in standards =
specifications and in products) between an A bit and a DS bit will be =
no easier than trying to make a distinction between an NR bit and a DS =
bit.&nbsp; Consequently, we will find ourselves no further ahead if we =
deprecate the current key usage extension and create a new one that =
begins with A and DS instead.</FONT></P>

<P><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Times New Roman">My vote is =
solidly in favour of retaining the current extension.&nbsp; The DS bit =
is, I think, clear:&nbsp; &quot;the public key in this certificate can =
be used to verify signatures on any data except certificates or CRLs =
(which are easy to recognize, so there's no confusion)&quot;.&nbsp; The =
NR bit could be deprecated, or could be given the interpretation =
suggested by Bill Burr (the CA attests that it has never had access to =
the corresponding private key).&nbsp; I personally prefer Bill's =
interpretation.&nbsp; I think it is very clear, even in the situation =
that Stefan raised (whether the keys were produced on the smart card, =
or produced in a separate box and injected onto the card, the CA itself =
did not have access to the private key and so can still validly set =
this bit).&nbsp; It is something concrete and explicit that the CA can =
say in a certificate, and it can certainly support non-repudiation in =
accordance with other policies and procedures.&nbsp; The only possible =
drawback with this interpretation is that it is in no sense a &quot;key =
usage&quot;, but the NR bit has never really been that, so we haven't =
lost anything.&nbsp; Furthermore, as Bill suggested, this narrower =
interpretation is highly unlikely to break any existing software.&nbsp; =
So I can't think of a single reason not to use this =
interpretation.</FONT></P>

<P><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Times New =
Roman">Carlisle.</FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C1F6B5.37773FC0--


Received: by above.proper.com (8.11.6/8.11.3) id g48HChR00317 for ietf-pkix-bks; Wed, 8 May 2002 10:12:43 -0700 (PDT)
Received: from mtiwmhc23.worldnet.att.net (mtiwmhc23.worldnet.att.net [204.127.131.48]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g48HCfL00312 for <[e-mail]>; Wed, 8 May 2002 10:12:41 -0700 (PDT)
Received: from tsg1 ([12.81.64.245]) by mtiwmhc23.worldnet.att.net (InterMail vM.4.01.03.27 201-229-121-127-20010626) with SMTP id <20020508171227.KWSC28245.mtiwmhc23.worldnet.att.net@tsg1>; Wed, 8 May 2002 17:12:27 +0000
Message-ID: <05fe01c1f6b3$24ab0090$020aff0a@tsg1>
From: "todd glassey" <[e-mail]>
To: "Michael Froomkin - U.Miami School of Law" <[e-mail]>
Cc: "PKIX-IETF" <[e-mail]>, "LISTS - IETF-IESG" <[e-mail]>, <[e-mail]>
References: <[e-mail]>
Subject: Re: Open issue: requester identifier in DPV response
Date: Wed, 8 May 2002 10:08:49 -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.50.4522.1200
X-MIMEOLE: Produced By Microsoft MimeOLE V5.50.4522.1200
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Michael restraint of trade is actionable. refusing to allow any effort to
pass without a definition of the formal processes to be applied to all
submissions, i.e. how the IETF  is setup today, leaves the entirety to the
WG Chairs and their AD's and that it the problem and I assure you that if it
can be demonstrated to any level that anyone in a standards organization
gave undue advantage to one protocol over an other and anyone suffered a
financial loss because of this act, that this is assuredly actionable.

Todd

----- Original Message -----
From: "Michael Froomkin - U.Miami School of Law" <[e-mail]>
To: "todd glassey" <[e-mail]>
Cc: "PKIX-IETF" <[e-mail]>; "LISTS - IETF-IESG" <[e-mail]>;
<[e-mail]>
Sent: Monday, April 29, 2002 8:10 PM
Subject: Re: Open issue: requester identifier in DPV response


> "Actionable"?  I rather doubt it.  At least not in the US, and not without
> many aggravating circumstances.
>
> On Sat, 27 Apr 2002, todd glassey wrote:
>
> > Stephen - I think that it is very likely that ANY involvement by a WG
Chair
> > in ANY protocol at any level is a conflict of interest and actionable as
> > such. It shows a predudicial predisposition towards that protocol and
favors
> > it over all others. This is why I am demanding the rewriting of the WG's
> > charter as well as the approriate sections of RFC2026 et al..
> >
> [....]
> --
> Please visit http://www.icannwatch.org
>
> A. Michael Froomkin   |    Professor of Law    |   [e-mail]
> U. Miami School of Law, P.O. Box 248087, Coral Gables, FL 33124 USA
> [phone]  |  [phone] (fax)  |  http://www.law.tm
>                         -->It's hot here.<--
>



Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g48FXvv26588 for ietf-pkix-bks; Wed, 8 May 2002 08:33:57 -0700 (PDT)
Received: from mtiwmhc21.worldnet.att.net (mtiwmhc21.worldnet.att.net [204.127.131.46]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g48FXuL26584 for <[e-mail]>; Wed, 8 May 2002 08:33:56 -0700 (PDT)
Received: from Chokhani ([12.91.132.226]) by mtiwmhc21.worldnet.att.net (InterMail vM.4.01.03.27 201-229-121-127-20010626) with ESMTP id <20020508153352.XWQI24238.mtiwmhc21.worldnet.att.net@Chokhani>; Wed, 8 May 2002 15:33:52 +0000
From: "Santosh Chokhani" <[e-mail]>
To: "'David P. Kemp'" <[e-mail]>, <[e-mail]>
Cc: "'500 list \(E-mail\)'" <[e-mail]>
Subject: RE: Meaning of Non-repudiation
Date: Wed, 8 May 2002 11:35:23 -0400
Message-ID: <002001c1f6a5$f8e46940$e2845b0c@Chokhani>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.2627
Importance: Normal
In-Reply-To: <[e-mail]>
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4910.0300
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

I support Dave's viewpoint also.

-----Original Message-----
From: [e-mail]
[mailto:[e-mail]] On Behalf Of David P. Kemp
Sent: Wednesday, May 08, 2002 10:50 AM
To: [e-mail]
Cc: '500 list (E-mail)'
Subject: Re: Meaning of Non-repudiation


Bill,

I have no problem with X.509 and PKIX following Trevor's approach.
Deprecate (using the strongest possible terms) the existing KeyUsage
OID, and define a new KeyUsage OID identical to the old one except that
bits 0 and 1 are replaced by nonceSign and dataSign.

Dave



Bill Burr wrote:
> 
> Santosh, Trevor and Sharon
> 
> My observation in the Federal PKI TWG meeting last week about 
> nonRepudiation meaning only that the CA never knew the private key is 
> the counsel of despair.  I think that the only thing most folks would 
> agree to about nonRepudiation is that you shouldn't set it if the CA 
> ever knew the private key.  That interpretation does have the 
> advantage that the CA is attesting to something truly under it's 
> control, while the word nonRepudiation carries so much other baggage 
> that no CA could hope to control it.
> 
> I broke down and went back and read most of the messages in this 
> thread, as well as the words that are now in son of  2459 and the 
> latest draft of X.509 that I have.  Neither son of nor X.509 seem to 
> me to stand up to a close reading on this subject.
> 
> It does seem to me that the place to indicate that a particular 
> signature is meant as a nonrepudiable, binding legal signature is in 
> the signature itself, or the document that is signed, and not in the 
> certificate.
> 
> I think that Santosh's construction of the digitalSignature and 
> nonRepudiation bits and four resulting cases is probably useful and 
> workable, and generally in line with my understanding of the more 
> "enlightened" interpretations of these bits.  I wish we could rename 
> them signChallenges and signData.
> 
> I don't understand what Trevor's precise interpretation of these bits 
> is, nor where it conflicts with Santosh's.  I suppose that Trevor must

> have some software that uses these bits in a way that conflicts with 
> Santosh's.  It would help me to understand what is at steak here if 
> Trevor could explain:
> -       what his interpretation of the exact meaning of these bits is
> (perhaps Trevor has, and I just haven't gone far enough back to find 
> it
> - if so I apologize);
> -       how specifically these bits are then used in his products in
> ways that conflict with Santosh's rules;
> -       why Trevor's interpretation of the meaning of the words in the
> standards is more consistent with them than Santosh's clarification.
> 
> It does seem to me that where we have an ambiguity it's wrong to 
> clarify it in a way that clearly contradicts whatever meaning can be 
> clearly drawn from the existing text.  I think that Trevor is claiming

> that Santosh's proposal does that.  But where we have an ambiguity 
> that is then clarified, we must accept that the clarification may 
> break existing products.  We shouldn't do that lightly however, and 
> should generally seek a clarification that breaks as little as 
> possible.
> 
> To assign to nonRepudiation the meaning that the CA never knew the 
> private key probably doesn't break any products (I hope).  I'm sure 
> it's not the most informative or useful interpretation we could put on

> that bit, but it might be the only one that breaks no products.
> 
> Regards,
> 
> Bill Burr



Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g48FUt926464 for ietf-pkix-bks; Wed, 8 May 2002 08:30:55 -0700 (PDT)
Received: from mtiwmhc26.worldnet.att.net (mtiwmhc26.worldnet.att.net [204.127.131.51]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g48FUsL26460 for <[e-mail]>; Wed, 8 May 2002 08:30:54 -0700 (PDT)
Received: from Chokhani ([12.91.132.226]) by mtiwmhc26.worldnet.att.net (InterMail vM.4.01.03.27 201-229-121-127-20010626) with ESMTP id <20020508153042.ZINZ7485.mtiwmhc26.worldnet.att.net@Chokhani>; Wed, 8 May 2002 15:30:42 +0000
From: "Santosh Chokhani" <[e-mail]>
To: "'Bill Burr'" <[e-mail]>, "'Sharon Boeyen'" <[e-mail]>, <[e-mail]>, "'500 list \(E-mail\)'" <[e-mail]>, <[e-mail]>
Subject: RE: Meaning of Non-repudiation
Date: Wed, 8 May 2002 11:32:12 -0400
Message-ID: <000a01c1f6a5$8791f190$e2845b0c@Chokhani>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_000B_01C1F684.00805190"
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.2627
Importance: Normal
In-Reply-To: <[e-mail]>
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4910.0300
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

This is a multi-part message in MIME format.

------=_NextPart_000_000B_01C1F684.00805190
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit

I agree with Bill's summary.

-----Original Message-----
From: Bill Burr [mailto:[e-mail]] 
Sent: Wednesday, May 08, 2002 9:58 AM
To: Santosh Chokhani; 'Sharon Boeyen'; [e-mail]; '500 list
(E-mail)'; [e-mail]
Subject: RE: Meaning of Non-repudiation


Santosh, Trevor and Sharon

My observation in the Federal PKI TWG meeting last week about
nonRepudiation meaning only that the CA never knew the private key is
the counsel of despair. I think that the only thing most folks would
agree to about nonRepudiation is that you shouldn't set it if the CA
ever knew the private key. That interpretation does have the advantage
that the CA is attesting to something truly under it's control, while
the word nonRepudiation carries so much other baggage that no CA could
hope to control it.

I broke down and went back and read most of the messages in this thread,
as well as the words that are now in son of 2459 and the latest draft of
X.509 that I have. Neither son of nor X.509 seem to me to stand up to a
close reading on this subject.

It does seem to me that the place to indicate that a particular
signature is meant as a nonrepudiable, binding legal signature is in the
signature itself, or the document that is signed, and not in the
certificate. 

I think that Santosh's construction of the digitalSignature and
nonRepudiation bits and four resulting cases is probably useful and
workable, and generally in line with my understanding of the more
"enlightened" interpretations of these bits. I wish we could rename them
signChallenges and signData.

I don't understand what Trevor's precise interpretation of these bits
is, nor where it conflicts with Santosh's. I suppose that Trevor must
have some software that uses these bits in a way that conflicts with
Santosh's. It would help me to understand what is at steak here if
Trevor could explain:
- what his interpretation of the exact meaning of these bits is (perhaps
Trevor has, and I just haven't gone far enough back to find it - if so I
apologize); 
- how specifically these bits are then used in his products in ways that
conflict with Santosh's rules;
- why Trevor's interpretation of the meaning of the words in the
standards is more consistent with them than Santosh's clarification.

It does seem to me that where we have an ambiguity it's wrong to clarify
it in a way that clearly contradicts whatever meaning can be clearly
drawn from the existing text. I think that Trevor is claiming that
Santosh's proposal does that. But where we have an ambiguity that is
then clarified, we must accept that the clarification may break existing
products. We shouldn't do that lightly however, and should generally
seek a clarification that breaks as little as possible.

To assign to nonRepudiation the meaning that the CA never knew the
private key probably doesn't break any products (I hope). I'm sure it's
not the most informative or useful interpretation we could put on that
bit, but it might be the only one that breaks no products.

Regards,

Bill Burr


At 07:31 AM 5/8/02 -0400, Santosh Chokhani wrote: 
>>>>


All:

Personally, I do not have a problem with this, but two of the major
objections to my proposal make this even worse.

Folks say that we do not want to change the semantics of this extension.
Well, all the other bits in the keyUsage say what cryptographic
operation clients can use the bit for. This bit does not do that. Also,
the them key usage means what operations the key can be used for. Please
read the introduction to X.509 definition of the extension.

I really believe the two bit distinction is only useful using what I
have recommended. I am not saying this because I finally got the
religion or anything. I think the proposal is in line with how all the
other bits are used for: what type of crypto operation on what type of
data.

But, since some key players are in violent disagreement, the best course
seems to be the language son of 2459 has.




-----Original Message-----
From: [e-mail] [mailto:[e-mail]]
On Behalf Of Sharon Boeyen
Sent: Tuesday, May 07, 2002 9:28 AM
To: [e-mail]; 500 list (E-mail)
Cc: Bill Burr (E-mail)
Subject: Meaning of Non-repudiation


I'd like to introduce another perspective on this topic, one that I
really think helps add some fundamental clarity to the topic. During the
US FPKI TWG meeting last week, this topic was raised and a short
discussion was held. Bill Burr commented that he understood the meaning
of the non-repudiation bit being set to be a statement by the
certificate issuer (CA) that they at no point had any access to the
private key corresponding to the public key being certified. I really
like this because it states what role this bit plays in a
non-repudiation context. It is simply that and nothing more. The
remaining mechanisms for supporting a non-repudiation service are
outside the scope of the definition of this bit. Legal and policy
schemes can determine the behaviour of relying parties and users when
this bit is set. The bit itself cannot do that. If an assertion that a
user who signed something "knew and intended to sign whatever", then
that assertion should be something that accompanies a specific
signature. This bit cannot be expected to act as that assertion. 

I also agree with Stefan that we need describe the digital signature bit
separate from the description of the non-repudiation bit in 509. Then it
is left to profiling groups, as it shoud be, what combinations of bits
they want set in their own environments. 

Re the debate on changing the meaning - The reason we are having this
discussion (at least one of the reasons) is because the meaning of these
bits is not clear to many readers. Both the process of defect reports as
well as the enhancement process allows us to clarify text in the
standard, as well as to fix bugs etc). Part of the problem is that there
isn't agreement on what the original text meant, hence the
clarification. Once there is some sort of agreement on what the "right
thing to do" is, then we'll determine what the process is to achieve the
intended result. That's part of the reason why we are having the
discussion before writing up a DR or an enhancement request.

Sharon 

Sharon Boeyen 
Principal, Advanced Security 
Tel: [phone] 
www.entrust.com 

Entrust, Inc. 
Securing the Internet 




<<<<




------=_NextPart_000_000B_01C1F684.00805190
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Dus-ascii">
<TITLE>Message</TITLE>

<META content=3D"MSHTML 5.50.4915.500" name=3DGENERATOR></HEAD>
<BODY>
<DIV><SPAN class=3D594283115-08052002><FONT face=3DArial color=3D#0000ff =
size=3D2>I=20
agree with Bill's summary.</FONT></SPAN></DIV>
<BLOCKQUOTE style=3D"MARGIN-RIGHT: 0px">
  <DIV></DIV>
  <DIV class=3DOutlookMessageHeader lang=3Den-us dir=3Dltr =
align=3Dleft><FONT=20
  face=3DTahoma size=3D2>-----Original Message-----<BR><B>From:</B> Bill =
Burr=20
  [mailto:[e-mail]] <BR><B>Sent:</B> Wednesday, May 08, =
2002 9:58=20
  AM<BR><B>To:</B> Santosh Chokhani; 'Sharon Boeyen'; [e-mail]; =
'500=20
  list (E-mail)'; [e-mail]<BR><B>Subject:</B> RE: =
Meaning=20
  of Non-repudiation<BR><BR></FONT></DIV>Santosh, Trevor and =
Sharon<BR><BR>My=20
  observation in the Federal PKI TWG meeting last week about =
nonRepudiation=20
  meaning only that the CA never knew the private key is the counsel of =
despair.=20
  I think that the only thing most folks would agree to about =
nonRepudiation is=20
  that you shouldn't set it if the CA ever knew the private key. That=20
  interpretation does have the advantage that the CA is attesting to =
something=20
  truly under it's control, while the word nonRepudiation carries so =
much other=20
  baggage that no CA could hope to control it.<BR><BR>I broke down and =
went back=20
  and read most of the messages in this thread, as well as the words =
that are=20
  now in son of 2459 and the latest draft of X.509 that I have. Neither =
son of=20
  nor X.509 seem to me to stand up to a close reading on this =
subject.<BR><BR>It=20
  does seem to me that the place to indicate that a particular signature =
is=20
  meant as a nonrepudiable, binding legal signature is in the signature =
itself,=20
  or the document that is signed, and not in the certificate. <BR><BR>I =
think=20
  that Santosh's construction of the digitalSignature and nonRepudiation =
bits=20
  and four resulting cases is probably useful and workable, and =
generally in=20
  line with my understanding of the more "enlightened" interpretations =
of these=20
  bits. I wish we could rename them signChallenges and =
signData.<BR><BR>I don't=20
  understand what Trevor's precise interpretation of these bits is, nor =
where it=20
  conflicts with Santosh's. I suppose that Trevor must have some =
software that=20
  uses these bits in a way that conflicts with Santosh's. It would help =
me to=20
  understand what is at steak here if Trevor could explain:<BR>- what =
his=20
  interpretation of the exact meaning of these bits is (perhaps Trevor =
has, and=20
  I just haven't gone far enough back to find it - if so I apologize); =
<BR>- how=20
  specifically these bits are then used in his products in ways that =
conflict=20
  with Santosh's rules;<BR>- why Trevor's interpretation of the meaning =
of the=20
  words in the standards is more consistent with them than Santosh's=20
  clarification.<BR><BR>It does seem to me that where we have an =
ambiguity it's=20
  wrong to clarify it in a way that clearly contradicts whatever meaning =
can be=20
  clearly drawn from the existing text. I think that Trevor is claiming =
that=20
  Santosh's proposal does that. But where we have an ambiguity that is =
then=20
  clarified, we must accept that the clarification may break existing =
products.=20
  We shouldn't do that lightly however, and should generally seek a=20
  clarification that breaks as little as possible.<BR><BR>To assign to=20
  nonRepudiation the meaning that the CA never knew the private key =
probably=20
  doesn't break any products (I hope). I'm sure it's not the most =
informative or=20
  useful interpretation we could put on that bit, but it might be the =
only one=20
  that breaks no products.<BR><BR>Regards,<BR><BR>Bill =
Burr<BR><BR><BR>At 07:31=20
  AM 5/8/02 -0400, Santosh Chokhani wrote: <BR>&gt;&gt;&gt;&gt;<BR>
  <BLOCKQUOTE><?fontfamily><?param Arial><?color><?param =
0000,0000,ffff><?smaller>All:<BR><?/smaller><?/color><?/fontfamily><BR><?=
fontfamily><?param Arial><?color><?param =
0000,0000,ffff><?smaller>Personally,=20
    I do not have a problem with this, but two of the major objections =
to my=20
    proposal make this even =
worse.<BR><?/smaller><?/color><?/fontfamily><BR><?fontfamily><?param =
Arial><?color><?param 0000,0000,ffff><?smaller>Folks=20
    say that we do not want to change the semantics of this extension. =
Well, all=20
    the other bits in the keyUsage say what cryptographic operation =
clients can=20
    use the bit for. This bit does not do that. Also, the them key usage =
means=20
    what operations the key can be used for. Please read the =
introduction to=20
    X.509 definition of the =
extension.<BR><?/smaller><?/color><?/fontfamily><BR><?fontfamily><?param =
Arial><?color><?param 0000,0000,ffff><?smaller>I=20
    really believe the two bit distinction is only useful using what I =
have=20
    recommended. I am not saying this because I finally got the religion =
or=20
    anything. I think the proposal is in line with how all the other =
bits are=20
    used for: what type of crypto operation on what type of =
data.<BR><?/smaller><?/color><?/fontfamily><BR><?fontfamily><?param =
Arial><?color><?param 0000,0000,ffff><?smaller>But,=20
    since some key players are in violent disagreement, the best course =
seems to=20
    be the language son of 2459 =
has.<BR><?/smaller><?/color><?/fontfamily><BR>
    <BLOCKQUOTE><BR><?fontfamily><?param Tahoma><?smaller>-----Original=20
      Message-----<BR><B>From:</B> [e-mail]=20
      [mailto:[e-mail]] <B>On Behalf Of </B>Sharon=20
      Boeyen<BR><B>Sent:</B> Tuesday, May 07, 2002 9:28 AM<BR><B>To:</B> =

      [e-mail]; 500 list (E-mail)<BR><B>Cc:</B> Bill Burr=20
      (E-mail)<BR><B>Subject:</B> Meaning of =
Non-repudiation<BR><BR><?/smaller><?/fontfamily><BR><?fontfamily><?param =
Arial><?smaller>I'd=20
      like to introduce another perspective on this topic, one that I =
really=20
      think helps add some fundamental clarity to the topic. During the =
US FPKI=20
      TWG meeting last week, this topic was raised and a short =
discussion was=20
      held. Bill Burr commented that he understood the meaning of the=20
      non-repudiation bit being set to be a statement by the certificate =
issuer=20
      (CA) that they at no point had any access to the private key =
corresponding=20
      to the public key being certified. I really like this because it =
states=20
      what role this bit plays in a non-repudiation context. It is =
simply that=20
      and nothing more. The remaining mechanisms for supporting a=20
      non-repudiation service are outside the scope of the definition of =
this=20
      bit. Legal and policy schemes can determine the behaviour of =
relying=20
      parties and users when this bit is set. The bit itself cannot do =
that. If=20
      an assertion that a user who signed something "knew and intended =
to sign=20
      whatever", then that assertion should be something that =
accompanies a=20
      specific signature. This bit cannot be expected to act as that =
assertion.=20
      <BR><?/smaller><?/fontfamily><BR><?fontfamily><?param =
Arial><?smaller>I=20
      also agree with Stefan that we need describe the digital signature =
bit=20
      separate from the description of the non-repudiation bit in 509. =
Then it=20
      is left to profiling groups, as it shoud be, what combinations of =
bits=20
      they want set in their own environments. =
<BR><?/smaller><?/fontfamily><BR><?fontfamily><?param Arial><?smaller>Re =

      the debate on changing the meaning - The reason we are having this =

      discussion (at least one of the reasons) is because the meaning of =
these=20
      bits is not clear to many readers. Both the process of defect =
reports as=20
      well as the enhancement process allows us to clarify text in the =
standard,=20
      as well as to fix bugs etc). Part of the problem is that there =
isn't=20
      agreement on what the original text meant, hence the =
clarification. Once=20
      there is some sort of agreement on what the "right thing to do" =
is, then=20
      we'll determine what the process is to achieve the intended =
result. That's=20
      part of the reason why we are having the discussion before writing =
up a DR=20
      or an enhancement =
request.<BR><?/smaller><?/fontfamily><BR><?fontfamily><?param =
Arial><?smaller>Sharon<?/smaller><?/fontfamily>=20
      <BR><BR><?smaller>Sharon Boeyen<?/smaller> =
<BR><?smaller>Principal,=20
      Advanced Security<?/smaller> <BR><?smaller>Tel: [phone]=20
      <BR>www.entrust.com<?/smaller> <BR><BR><?smaller>Entrust, =
Inc.<?/smaller>=20
      <BR><?smaller>Securing the Internet<?/smaller>=20
  =
<BR><BR></BLOCKQUOTE><BR></BLOCKQUOTE>&lt;&lt;&lt;&lt;<BR><BR></BLOCKQUOT=
E></BODY></HTML>

------=_NextPart_000_000B_01C1F684.00805190--



Received: by above.proper.com (8.11.6/8.11.3) id g48Ett823860 for ietf-pkix-bks; Wed, 8 May 2002 07:55:55 -0700 (PDT)
Received: from mta7.pltn13.pbi.net (mta7.pltn13.pbi.net [64.164.98.8]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g48EttL23854 for <[e-mail]>; Wed, 8 May 2002 07:55:55 -0700 (PDT)
Received: from localhost ([207.214.211.55]) by mta7.pltn13.pbi.net (iPlanet Messaging Server 5.1 (built May  7 2001)) with ESMTP id <[e-mail]> for [e-mail]; Wed, 08 May 2002 07:55:56 -0700 (PDT)
Date: Wed, 08 May 2002 07:56:26 -0700
From: Aram Perez <[e-mail]>
Subject: Re: Words, Books, and Key Usage
In-reply-to: <[e-mail]>
To: PKIX <[e-mail]>
Message-id: <[e-mail]>
MIME-version: 1.0
X-Mailer: Apple Mail (2.481)
Content-type: text/plain; charset=US-ASCII; format=flowed
Content-transfer-encoding: 7BIT
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

On Tuesday, May 7, 2002, at 10:19  PM, Peter Gutmann wrote:

> "David P. Kemp" <[e-mail]> writes:
>
>> The first step to recovery is admitting that something is wrong.
>
> Hi.  My name is Peter and I have a keyUsage problem.  Initially it
> was just small things, a little digitalSignature after lunch, maybe
> a dataEncipherment after dinner and keyAgreement as a nightcap.  Then
> I started combining digitalSignature and keyEncipherment in the same
> certificate.  It just got worse and worse.  In the end I was
> experimenting with mixing digitalSignature and nonRepudiation, and
> even freebasing keyCertSigns.  One morning I woke up in bed next to
> a giant lizard wearing a Mozilla t-shirt, and knew I had a problem.
>
> It's now been six weeks since my last nonRepudiation...

Where can I get my two bits of nonRepudiation?

Aram



Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g48Eqn123624 for ietf-pkix-bks; Wed, 8 May 2002 07:52:49 -0700 (PDT)
Received: from stingray.missi.ncsc.mil (stingray.missi.ncsc.mil [144.51.50.20]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g48EqmL23620 for <[e-mail]>; Wed, 8 May 2002 07:52:48 -0700 (PDT)
Received: from stingray.missi.ncsc.mil (root@localhost) by stingray.missi.ncsc.mil with ESMTP id g48Eknc09827; Wed, 8 May 2002 10:46:49 -0400 (EDT)
Message-ID: <[e-mail]>
Date: Wed, 08 May 2002 10:49:41 -0400
From: "David P. Kemp" <[e-mail]>
X-Mailer: Mozilla 4.77 [en] (X11; U; SunOS 5.7 sun4u)
X-Accept-Language: en
MIME-Version: 1.0
To: [e-mail]
CC: "'500 list (E-mail)'" <[e-mail]>
Subject: Re: Meaning of Non-repudiation
References: <[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
X-H-S-Loop-Check-Ejzfr: 
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Bill,

I have no problem with X.509 and PKIX following Trevor's approach.
Deprecate (using the strongest possible terms) the existing KeyUsage
OID, and define a new KeyUsage OID identical to the old one except
that bits 0 and 1 are replaced by nonceSign and dataSign.

Dave



Bill Burr wrote:
> 
> Santosh, Trevor and Sharon
> 
> My observation in the Federal PKI TWG meeting last week about
> nonRepudiation meaning only that the CA never knew the private key is
> the counsel of despair.  I think that the only thing most folks would
> agree to about nonRepudiation is that you shouldn't set it if the CA
> ever knew the private key.  That interpretation does have the advantage
> that the CA is attesting to something truly under it's control, while
> the word nonRepudiation carries so much other baggage that no CA could
> hope to control it.
> 
> I broke down and went back and read most of the messages in this thread,
> as well as the words that are now in son of  2459 and the latest draft
> of X.509 that I have.  Neither son of nor X.509 seem to me to stand up
> to a close reading on this subject.
> 
> It does seem to me that the place to indicate that a particular
> signature is meant as a nonrepudiable, binding legal signature is in the
> signature itself, or the document that is signed, and not in the
> certificate.
> 
> I think that Santosh's construction of the digitalSignature and
> nonRepudiation bits and four resulting cases is probably useful and
> workable, and generally in line with my understanding of the more
> "enlightened" interpretations of these bits.  I wish we could rename
> them signChallenges and signData.
> 
> I don't understand what Trevor's precise interpretation of these bits
> is, nor where it conflicts with Santosh's.  I suppose that Trevor must
> have some software that uses these bits in a way that conflicts with
> Santosh's.  It would help me to understand what is at steak here if
> Trevor could explain:
> -       what his interpretation of the exact meaning of these bits is
> (perhaps Trevor has, and I just haven't gone far enough back to find it
> - if so I apologize);
> -       how specifically these bits are then used in his products in
> ways that conflict with Santosh's rules;
> -       why Trevor's interpretation of the meaning of the words in the
> standards is more consistent with them than Santosh's clarification.
> 
> It does seem to me that where we have an ambiguity it's wrong to clarify
> it in a way that clearly contradicts whatever meaning can be clearly
> drawn from the existing text.  I think that Trevor is claiming that
> Santosh's proposal does that.  But where we have an ambiguity that is
> then clarified, we must accept that the clarification may break existing
> products.  We shouldn't do that lightly however, and should generally
> seek a clarification that breaks as little as possible.
> 
> To assign to nonRepudiation the meaning that the CA never knew the
> private key probably doesn't break any products (I hope).  I'm sure it's
> not the most informative or useful interpretation we could put on that
> bit, but it might be the only one that breaks no products.
> 
> Regards,
> 
> Bill Burr


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g48C4NR13359 for ietf-pkix-bks; Wed, 8 May 2002 05:04:23 -0700 (PDT)
Received: from mail12.svr.pol.co.uk (mail12.svr.pol.co.uk [195.92.193.215]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g48C4ML13355 for <[e-mail]>; Wed, 8 May 2002 05:04:22 -0700 (PDT)
Received: from modem-3683.leopard.dialup.pol.co.uk ([217.135.158.99] helo=badger) by mail12.svr.pol.co.uk with smtp (Exim 3.35 #1) id 175QB7-0002gl-00 for [e-mail]; Wed, 08 May 2002 13:04:18 +0100
From: "Dean Adams" <[e-mail]>
To: <[e-mail]>
Subject: RE: Meaning of Non-repudiation
Date: Wed, 8 May 2002 13:04:30 +0100
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_0035_01C1F690.E436BA80"
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0)
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200
Importance: Normal
In-Reply-To: <[e-mail]>
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

This is a multi-part message in MIME format.

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

RE: Meaning of Non-repudiationHi,
    Not having been involved in the original round of debates that led to
the establishment of the so called NR bit, I'm probably covering old ground
that was effectively discussed and resolved some time ago, but here goes
anyway.

It seems to me that we are talking about an element in a technical spec, and
which is somehow trying to address what is primarily a policy, procedural
and legal issue.

>From a technical perpective, surely we can only specify those things of a
technical nature.  At its most basic, indicating allowable technical usages
such as keyEncipherment, dataEncipherment, keyCertSign, cRLSign etc.  The
difficulty appears to surround the issue of when the subscriber signs
something as a part of his/her intentional day-to-day operations.  In
general as subscribers, we do two things: - (1) sign a challenge to prove
who we are so we can gain access to something, or (2) sign a transaction,
email communication or document to attach our electronic moniker to it.

In the first case, we are using a digital signature technical capability to
authenticate ourselves, much as we have done in the past with passwords.
The real action that we are undertaking is authentication - the fact it is
accomplished via a digital signature mechanism is interesting to
cryptographers but not necessariliy to systems administrators, business
managers and the like.

In the second case, we are putting our name on a communication, transaction
or document for a variety of reasons (as we do in real life with real
signatures) - perhaps to indicate approval of some action (that the
transaction should go ahead, or that the contents of this document or
communication are accepted or formally issued by me), or as in the case of a
written memo from the CEO to all staff - that the contents actually come
from the the CEO.

I suppose the point I'm trying to make, is that we undertake two technical
actions - authentication and signing.  Non-repudiation is not a technical
matter, it is the subject of policy, procedural and legal/regulatory
controls and interpretations.  For example, a policy may exist that states
that the act of signing a communication, transaction or document, will will
be interpreted as ... (acceptance of the published terms, authorising
payment, etc.).  The bits in keyUsage should straightforwardly reflect these
two types of action and no more.

Any instance of repudiation has to be dealt with by policy, procedural,
legal/regulatory mechanisms that should be made aware to signers at the
outset.  Just as they are with respect to hand-written signatures.  These
non-technical mechanisms may draw upon technical protective mechanisms (such
as signing key being generated on smartcards and never being exposed outside
it, etc), to strengthen the means of arbitrating claims of repudiation, but
that is all.  Setting a bit called non-repudiation in a certificate does
nothing for anyone.

IMHO the current assignment of these bits should be declared deprecated, to
allow existing deployments to gradually move to a new specification, with a
new assignment declared for these bits reflecting the two actions described
above.  Most subscriber certs have a limited lifetime, and so it shouldn't
take too long for everyone to be able to move to a new assignment of
keyUsage bits.

Sorry for rambling on a while - just my two cents worth as you folks say.

    Dean


----------------------------------------------------------------------------
----
      Dean Adams Mobile: [phone]
      Trustis Limited Direct Tel/Fax: [phone]
      49 Whitehall Office Tel: [phone]
      London SW1A 2BX Office Fax: [phone]
      email: [e-mail] Web: http://www.trustis.com

The information in this message is confidential. It is intended solely for
the addressee. Access to this message by anyone else is unauthorised. If you
are not the intended recipient, any disclosure, copying, distribution or any
action taken or omitted to be taken in reliance on it, is prohibited and may
be unlawful.

Any attachments to this message have been checked for viruses, but please
rely on your own virus checker and procedures.

If you contact us by e-mail, we may store your name and address to
facilitate communications.

  -----Original Message-----
  From: [e-mail] [mailto:[e-mail]]On
Behalf Of Sharon Boeyen
  Sent: 07 May 2002 19:53
  To: 'Tom Gindin'; Sharon Boeyen
  Cc: [e-mail]; 500 list (E-mail); Bill Burr (E-mail)
  Subject: RE: Meaning of Non-repudiation


  Tom, I absolutely agree that this would be insufficient for
non-repudiation. However,
  non-repudiation is not a technical operation, but a policy/legal one. This
bit is only
  one very small component of non-repudiation. It is the CAs statement. The
user's statement
  should be something that accompanies their signature. In the example you
cite, perhaps in
  one environment, the policy dictates that all browser generated keys are
solely to be used
  for online authentication of a user to a service and not for signatures
that could be used
  in a non-repudiation context. In that environment, the policy would
dictate that the CA set
  only the digital signature bit and not the non-repudiation bit, regardless
of the fact that
  the CA hadn't seen the private key. In another environment, the policy
might dictate that
  all client side generated private keys could be used for signatures in a
non-repudiation
  context. In that particular environment the policy could dictate that the
CA does set the
  non-repudiation bit. The policy would also dictate the key-usage bits that
need to be set
  for the different types of operations a user performs (perhaps tied to
specific local applications
  e.g. if signing a purchase order must use a key that has this bit set). So
all the combinations
  would still be possible, but if the non-repudiation bit was set it would
be purely a statement
  by the CA (as dictated by policy) that it did not generate and never had
access to the private
  key. That is different that 'requiring' that the bit always be set if the
CA didn't generate the
  key. Hope that helps.

  Sharon

  -----Original Message-----
  From: Tom Gindin [mailto:[e-mail]]
  Sent: Tuesday, May 07, 2002 1:32 PM
  To: Sharon Boeyen
  Cc: [e-mail]; 500 list (E-mail); Bill Burr (E-mail)
  Subject: Re: Meaning of Non-repudiation




        Sharon:

        With all due respect, IMHO this would be a step backward because the
  condition is certainly not sufficient for an NR key.  If a browser
  generated a key pair locally for authentication purposes, stored it on its
  local disk database, and submitted a PKCS#10 or CR requesting signatures
  for authentication it would meet this criterion.  I don't know if this is
  even a necessary criterion, but it is certainly insufficient.

              Tom Gindin

  Sharon Boeyen <[e-mail]>@mail.imc.org on 05/07/2002
  09:28:23 AM

  Sent by:    [e-mail]



  To:    [e-mail], "500 list (E-mail)" <[e-mail]>
  cc:    "Bill Burr (E-mail)" <[e-mail]>
  Subject:    Meaning of Non-repudiation



  I'd like to introduce another perspective on this topic, one that I really
  think helps add some fundamental clarity to the topic. During the US FPKI
  TWG meeting last week, this topic was raised and a short discussion was
  held. Bill Burr commented that he understood the meaning of the
  non-repudiation bit being set to be a statement by the certificate issuer
  (CA) that they at no point had any access to the private key corresponding
  to the public key being certified. I really like this because it states
  what role this bit plays in a non-repudiation context. It is simply that
  and nothing more. The remaining mechanisms for supporting a
non-repudiation
  service are outside the scope of the definition of this bit. Legal and
  policy schemes can determine the behaviour of relying parties and users
  when this bit is set. The bit itself cannot do that. If an assertion that
a
  user who signed something "knew and intended to sign whatever", then that
  assertion should be something that accompanies a specific signature. This
  bit cannot be expected to act as that assertion.



  I also agree with Stefan that we need describe the digital signature bit
  separate from the description of the non-repudiation bit in 509. Then it
is
  left to profiling groups, as it shoud be, what combinations of bits they
  want set in their own environments.



  Re the debate on changing the meaning - The reason we are having this
  discussion (at least one of the reasons) is because the meaning of these
  bits is not clear to many readers. Both the process of defect reports as
  well as the enhancement process allows us to clarify text in the standard,
  as well as to fix bugs etc). Part of the problem is that there isn't
  agreement on what the original text meant, hence the clarification. Once
  there is some sort of agreement on what the "right thing to do" is, then
  we'll determine what the process is to achieve the intended result. That's
  part of the reason why we are having the discussion before writing up a DR
  or an enhancement request.



  Sharon



  Sharon Boeyen
  Principal, Advanced Security
  Tel: [phone]
  www.entrust.com



  Entrust, Inc.
  Securing the Internet








------=_NextPart_000_0035_01C1F690.E436BA80
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: Meaning of Non-repudiation</TITLE>
<META http-equiv=3DContent-Type content=3D"text/html; =
charset=3Diso-8859-1">
<META content=3D"MSHTML 5.50.4727.700" name=3DGENERATOR></HEAD>
<BODY>
<DIV><FONT face=3DArial color=3D#0000ff size=3D2><SPAN=20
class=3D260100311-08052002>Hi,</SPAN></FONT></DIV>
<DIV><FONT face=3DArial color=3D#0000ff size=3D2><SPAN=20
class=3D260100311-08052002>&nbsp;&nbsp;&nbsp; Not having been involved =
in the=20
original round of debates that led to the establishment of the so called =
NR bit,=20
I'm probably covering old ground that was effectively discussed and =
resolved=20
some time ago, but here goes anyway.</SPAN></FONT></DIV>
<DIV><FONT face=3DArial color=3D#0000ff size=3D2><SPAN=20
class=3D260100311-08052002></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial color=3D#0000ff size=3D2><SPAN =
class=3D260100311-08052002>It=20
seems to me that we are talking about an element in a technical spec, =
and which=20
is somehow trying to address what is primarily a policy, procedural and =
legal=20
issue.</SPAN></FONT></DIV>
<DIV><FONT face=3DArial color=3D#0000ff size=3D2><SPAN=20
class=3D260100311-08052002></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial color=3D#0000ff size=3D2><SPAN =
class=3D260100311-08052002>From a=20
technical perpective, surely we can only specify those things of a =
technical=20
nature.&nbsp; At its most basic, indicating allowable technical usages =
such as=20
keyEncipherment, dataEncipherment, keyCertSign, cRLSign =
etc.&nbsp;&nbsp;The=20
difficulty appears to surround the issue of when the&nbsp;subscriber =
signs=20
something as a part of his/her intentional day-to-day operations.&nbsp; =
In=20
general as subscribers, we do two things:&nbsp;- (1) sign a challenge to =
prove=20
who we are so we can gain access to something, or (2) sign a =
transaction, email=20
communication or document to attach our electronic moniker to=20
it.</SPAN></FONT></DIV>
<DIV><FONT face=3DArial color=3D#0000ff size=3D2><SPAN=20
class=3D260100311-08052002></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial color=3D#0000ff size=3D2><SPAN =
class=3D260100311-08052002>In the=20
first case, we are using a digital signature technical capability to=20
authenticate ourselves, much as we have done in the past with =
passwords.&nbsp;=20
The real action that we are undertaking is authentication - the fact it =
is=20
accomplished via a digital signature mechanism is interesting to =
cryptographers=20
but not necessariliy to systems administrators, business managers and =
the=20
like.</SPAN></FONT></DIV>
<DIV><FONT face=3DArial color=3D#0000ff size=3D2><SPAN=20
class=3D260100311-08052002></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial color=3D#0000ff size=3D2><SPAN =
class=3D260100311-08052002>In the=20
second case, we are putting our name on a communication, transaction or =
document=20
for a variety of reasons (as we do in real life with real signatures) - =
perhaps=20
to indicate approval of some action (that the transaction should go =
ahead, or=20
that the contents of this document or communication are accepted or =
formally=20
issued by me), or as in the case of a written memo from the CEO to all =
staff -=20
that the contents actually come from the the CEO.</SPAN></FONT></DIV>
<DIV><FONT face=3DArial color=3D#0000ff size=3D2><SPAN=20
class=3D260100311-08052002></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial color=3D#0000ff size=3D2><SPAN =
class=3D260100311-08052002>I=20
suppose the point I'm trying to make, is that we undertake two technical =
actions=20
- authentication and signing.&nbsp; Non-repudiation is not a technical =
matter,=20
it is the subject of policy, procedural and legal/regulatory controls =
and=20
interpretations.&nbsp; For example, a policy may exist that states that =
the act=20
of signing a communication, transaction or document, will will be =
interpreted as=20
... (acceptance of the published terms, authorising payment, =
etc.).&nbsp; The=20
bits in keyUsage should straightforwardly reflect these two types of =
action and=20
no more.</SPAN></FONT></DIV>
<DIV><FONT face=3DArial color=3D#0000ff size=3D2><SPAN=20
class=3D260100311-08052002></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial color=3D#0000ff size=3D2><SPAN =
class=3D260100311-08052002>Any=20
instance of repudiation has to be dealt with by policy, procedural,=20
legal/regulatory mechanisms that should be made aware to signers at the=20
outset.&nbsp; Just as they are with respect to hand-written =
signatures.&nbsp;=20
These non-technical mechanisms may draw upon technical protective =
mechanisms=20
(such as signing key being generated on smartcards and never being =
exposed=20
outside it, etc), to strengthen the means of arbitrating claims of =
repudiation,=20
but that is all.&nbsp; Setting a bit called non-repudiation in a =
certificate=20
does nothing for anyone.</SPAN></FONT></DIV>
<DIV><FONT face=3DArial color=3D#0000ff size=3D2><SPAN=20
class=3D260100311-08052002></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial color=3D#0000ff size=3D2><SPAN =
class=3D260100311-08052002>IMHO=20
the current assignment of these bits should be declared deprecated, to =
allow=20
existing deployments to gradually move to a new specification, with a =
new=20
assignment declared for these bits reflecting the two actions described=20
above.&nbsp; Most subscriber certs have a limited lifetime, and so it =
shouldn't=20
take too long for everyone to be able to move to a new assignment of =
keyUsage=20
bits.</SPAN></FONT></DIV>
<DIV><FONT face=3DArial color=3D#0000ff size=3D2></FONT>&nbsp;</DIV>
<DIV><SPAN class=3D260100311-08052002><FONT face=3DArial color=3D#0000ff =
size=3D2>Sorry=20
for rambling on a while - just my two cents worth as you folks=20
say.</FONT></SPAN></DIV>
<DIV><SPAN class=3D260100311-08052002><FONT face=3DArial color=3D#0000ff =

size=3D2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=3D260100311-08052002>&nbsp;&nbsp;&nbsp; <FONT =
face=3DArial=20
color=3D#0000ff size=3D2>Dean</FONT></SPAN></DIV>
<DIV><FONT face=3DArial color=3D#0000ff size=3D2></FONT>&nbsp;</DIV>
<HR>

<TABLE width=3D433 border=3D0>
  <TBODY>
  <TR>
    <TD width=3D203 colSpan=3D2><FONT face=3DArial size=3D2>Dean =
Adams</FONT></TD>
    <TD width=3D143><FONT face=3DArial size=3D2>Mobile:</FONT></TD>
    <TD width=3D135><FONT face=3DArial size=3D2>+44 (0) 7989 =
385914</FONT></TD></TR>
  <TR>
    <TD width=3D203 colSpan=3D2><FONT face=3DArial size=3D2>Trustis =
Limited</FONT></TD>
    <TD width=3D143><FONT face=3DArial size=3D2>Direct =
Tel/Fax:</FONT></TD>
    <TD width=3D135><FONT face=3DArial size=3D2>+44 (0) 1252 =
734320</FONT></TD></TR>
  <TR>
    <TD width=3D203 colSpan=3D2><FONT face=3DArial size=3D2>49 =
Whitehall</FONT></TD>
    <TD width=3D143><FONT face=3DArial size=3D2>Office Tel:</FONT></TD>
    <TD width=3D135><FONT face=3DArial size=3D2>[phone] =
1490</FONT></TD></TR>
  <TR>
    <TD width=3D203 colSpan=3D2><FONT face=3DArial size=3D2>London SW1A =
2BX</FONT></TD>
    <TD width=3D143><FONT face=3DArial size=3D2>Office Fax:</FONT></TD>
    <TD width=3D135><FONT face=3DArial size=3D2>[phone] =
7961</FONT></TD></TR>
  <TR>
    <TD width=3D61><FONT face=3DArial size=3D2>email:</FONT></TD>
    <TD width=3D142><FONT face=3DArial size=3D2><A=20
      href=3D"mailto:[e-mail]">[e-mail]</A></FONT></TD>
    <TD width=3D143><FONT face=3DArial size=3D2>Web:</FONT></TD>
    <TD width=3D135><FONT face=3DArial size=3D2><A target=3D_blank=20
      =
href=3D"http://www.trustis.com/">http://www.trustis.com</A></FONT></TD></=
TR></TBODY></TABLE>
<P><FONT face=3DArial size=3D2>The information in this message is =
confidential. It=20
is intended solely for the addressee. Access to this message by anyone =
else is=20
unauthorised. If you are not the intended recipient, any disclosure, =
copying,=20
distribution or any action taken or omitted to be taken in reliance on =
it, is=20
prohibited and may be unlawful.</FONT></P>
<P><FONT face=3DArial size=3D2>Any attachments to this message have been =
checked for=20
viruses, but please rely on your own virus checker and =
procedures.</FONT></P>
<P><FONT face=3DArial size=3D2>If you contact us by e-mail, we may store =
your name=20
and address to facilitate communications. </FONT></P>
<BLOCKQUOTE=20
style=3D"PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #0000ff 2px =
solid">
  <DIV class=3DOutlookMessageHeader dir=3Dltr align=3Dleft><FONT =
face=3DTahoma=20
  size=3D2>-----Original Message-----<BR><B>From:</B> =
[e-mail]=20
  [mailto:[e-mail]]<B>On Behalf Of </B>Sharon=20
  Boeyen<BR><B>Sent:</B> 07 May 2002 19:53<BR><B>To:</B> 'Tom Gindin'; =
Sharon=20
  Boeyen<BR><B>Cc:</B> [e-mail]; 500 list (E-mail); Bill Burr=20
  (E-mail)<BR><B>Subject:</B> RE: Meaning of=20
Non-repudiation<BR><BR></FONT></DIV>
  <P><FONT size=3D2>Tom, I absolutely agree that this would be =
insufficient for=20
  non-repudiation. However,</FONT> <BR><FONT size=3D2>non-repudiation is =
not a=20
  technical operation, but a policy/legal one. This bit is only =
</FONT><BR><FONT=20
  size=3D2>one very small component of non-repudiation. It is the CAs =
statement.=20
  The user's statement</FONT> <BR><FONT size=3D2>should be something =
that=20
  accompanies their signature. In the example you cite, perhaps in=20
  </FONT><BR><FONT size=3D2>one environment, the policy dictates that =
all browser=20
  generated keys are solely to be used </FONT><BR><FONT size=3D2>for =
online=20
  authentication of a user to a service and not for signatures that =
could be=20
  used</FONT> <BR><FONT size=3D2>in a non-repudiation context. In that=20
  environment, the policy would dictate that the CA set </FONT><BR><FONT =

  size=3D2>only the digital signature bit and not the non-repudiation =
bit,=20
  regardless of the fact that </FONT><BR><FONT size=3D2>the CA hadn't =
seen the=20
  private key. In another environment, the policy might dictate that=20
  </FONT><BR><FONT size=3D2>all client side generated private keys could =
be used=20
  for signatures in a non-repudiation </FONT><BR><FONT size=3D2>context. =
In that=20
  particular environment the policy could dictate that the CA does set =
the=20
  </FONT><BR><FONT size=3D2>non-repudiation bit. The policy would also =
dictate the=20
  key-usage bits that need to be set </FONT><BR><FONT size=3D2>for the =
different=20
  types of operations a user performs (perhaps tied to specific local=20
  applications</FONT> <BR><FONT size=3D2>e.g. if signing a purchase =
order must use=20
  a key that has this bit set). So all the combinations</FONT> <BR><FONT =

  size=3D2>would still be possible, but if the non-repudiation bit was =
set it=20
  would be purely a statement </FONT><BR><FONT size=3D2>by the CA (as =
dictated by=20
  policy) that it did not generate and never had access to the private=20
  </FONT><BR><FONT size=3D2>key. That is different that 'requiring' that =
the bit=20
  always be set if the CA didn't generate the </FONT><BR><FONT =
size=3D2>key. Hope=20
  that helps.</FONT> </P>
  <P><FONT size=3D2>Sharon</FONT> </P>
  <P><FONT size=3D2>-----Original Message-----</FONT> <BR><FONT =
size=3D2>From: Tom=20
  Gindin [<A=20
  =
href=3D"mailto:[e-mail]">mailto:[e-mail]</A>]</FONT> =

  <BR><FONT size=3D2>Sent: Tuesday, May 07, 2002 1:32 PM</FONT> =
<BR><FONT=20
  size=3D2>To: Sharon Boeyen</FONT> <BR><FONT size=3D2>Cc: =
[e-mail]; 500=20
  list (E-mail); Bill Burr (E-mail)</FONT> <BR><FONT size=3D2>Subject: =
Re: Meaning=20
  of Non-repudiation</FONT> </P><BR><BR>
  <P><FONT size=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Sharon:</FONT> </P>
  <P><FONT size=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; With all due respect, =
IMHO this=20
  would be a step backward because the</FONT> <BR><FONT =
size=3D2>condition is=20
  certainly not sufficient for an NR key.&nbsp; If a browser</FONT> =
<BR><FONT=20
  size=3D2>generated a key pair locally for authentication purposes, =
stored it on=20
  its</FONT> <BR><FONT size=3D2>local disk database, and submitted a =
PKCS#10 or CR=20
  requesting signatures</FONT> <BR><FONT size=3D2>for authentication it =
would meet=20
  this criterion.&nbsp; I don't know if this is</FONT> <BR><FONT =
size=3D2>even a=20
  necessary criterion, but it is certainly insufficient.</FONT> </P>
  <P><FONT=20
  =
size=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p; Tom=20
  Gindin</FONT> </P>
  <P><FONT size=3D2>Sharon Boeyen =
&lt;[e-mail]&gt;@mail.imc.org=20
  on 05/07/2002</FONT> <BR><FONT size=3D2>09:28:23 AM</FONT> </P>
  <P><FONT size=3D2>Sent by:&nbsp;&nbsp;&nbsp; =
[e-mail]</FONT>=20
  </P><BR>
  <P><FONT size=3D2>To:&nbsp;&nbsp;&nbsp; [e-mail], "500 list =
(E-mail)"=20
  &lt;[e-mail]&gt;</FONT> <BR><FONT=20
  size=3D2>cc:&nbsp;&nbsp;&nbsp; "Bill Burr (E-mail)"=20
  &lt;[e-mail]&gt;</FONT> <BR><FONT=20
  size=3D2>Subject:&nbsp;&nbsp;&nbsp; Meaning of Non-repudiation</FONT> =
</P><BR>
  <P><FONT size=3D2>I'd like to introduce another perspective on this =
topic, one=20
  that I really</FONT> <BR><FONT size=3D2>think helps add some =
fundamental clarity=20
  to the topic. During the US FPKI</FONT> <BR><FONT size=3D2>TWG meeting =
last=20
  week, this topic was raised and a short discussion was</FONT> =
<BR><FONT=20
  size=3D2>held. Bill Burr commented that he understood the meaning of =
the</FONT>=20
  <BR><FONT size=3D2>non-repudiation bit being set to be a statement by =
the=20
  certificate issuer</FONT> <BR><FONT size=3D2>(CA) that they at no =
point had any=20
  access to the private key corresponding</FONT> <BR><FONT size=3D2>to =
the public=20
  key being certified. I really like this because it states</FONT> =
<BR><FONT=20
  size=3D2>what role this bit plays in a non-repudiation context. It is =
simply=20
  that</FONT> <BR><FONT size=3D2>and nothing more. The remaining =
mechanisms for=20
  supporting a non-repudiation</FONT> <BR><FONT size=3D2>service are =
outside the=20
  scope of the definition of this bit. Legal and</FONT> <BR><FONT =
size=3D2>policy=20
  schemes can determine the behaviour of relying parties and =
users</FONT>=20
  <BR><FONT size=3D2>when this bit is set. The bit itself cannot do =
that. If an=20
  assertion that a</FONT> <BR><FONT size=3D2>user who signed something =
"knew and=20
  intended to sign whatever", then that</FONT> <BR><FONT =
size=3D2>assertion should=20
  be something that accompanies a specific signature. This</FONT> =
<BR><FONT=20
  size=3D2>bit cannot be expected to act as that assertion.</FONT> =
</P><BR>
  <P><FONT size=3D2>I also agree with Stefan that we need describe the =
digital=20
  signature bit</FONT> <BR><FONT size=3D2>separate from the description =
of the=20
  non-repudiation bit in 509. Then it is</FONT> <BR><FONT size=3D2>left =
to=20
  profiling groups, as it shoud be, what combinations of bits =
they</FONT>=20
  <BR><FONT size=3D2>want set in their own environments.</FONT> </P><BR>
  <P><FONT size=3D2>Re the debate on changing the meaning - The reason =
we are=20
  having this</FONT> <BR><FONT size=3D2>discussion (at least one of the =
reasons)=20
  is because the meaning of these</FONT> <BR><FONT size=3D2>bits is not =
clear to=20
  many readers. Both the process of defect reports as</FONT> <BR><FONT=20
  size=3D2>well as the enhancement process allows us to clarify text in =
the=20
  standard,</FONT> <BR><FONT size=3D2>as well as to fix bugs etc). Part =
of the=20
  problem is that there isn't</FONT> <BR><FONT size=3D2>agreement on =
what the=20
  original text meant, hence the clarification. Once</FONT> <BR><FONT=20
  size=3D2>there is some sort of agreement on what the "right thing to =
do" is,=20
  then</FONT> <BR><FONT size=3D2>we'll determine what the process is to =
achieve=20
  the intended result. That's</FONT> <BR><FONT size=3D2>part of the =
reason why we=20
  are having the discussion before writing up a DR</FONT> <BR><FONT =
size=3D2>or an=20
  enhancement request.</FONT> </P><BR>
  <P><FONT size=3D2>Sharon</FONT> </P><BR>
  <P><FONT size=3D2>Sharon Boeyen</FONT> <BR><FONT size=3D2>Principal, =
Advanced=20
  Security</FONT> <BR><FONT size=3D2>Tel: [phone]</FONT> <BR><FONT=20
  size=3D2>www.entrust.com</FONT> </P><BR>
  <P><FONT size=3D2>Entrust, Inc.</FONT> <BR><FONT size=3D2>Securing the =

  Internet</FONT> </P><BR><BR><BR><BR><BR></BLOCKQUOTE></BODY></HTML>

------=_NextPart_000_0035_01C1F690.E436BA80--



Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g48BVrA11631 for ietf-pkix-bks; Wed, 8 May 2002 04:31:53 -0700 (PDT)
Received: from mtiwmhc22.worldnet.att.net (mtiwmhc22.worldnet.att.net [204.127.131.47]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g48BVqL11627 for <[e-mail]>; Wed, 8 May 2002 04:31:52 -0700 (PDT)
Received: from Chokhani ([12.91.131.140]) by mtiwmhc22.worldnet.att.net (InterMail vM.4.01.03.27 201-229-121-127-20010626) with ESMTP id <20020508113142.CPIV28991.mtiwmhc22.worldnet.att.net@Chokhani>; Wed, 8 May 2002 11:31:42 +0000
From: "Santosh Chokhani" <[e-mail]>
To: "'Trevor Freeman'" <[e-mail]>, "'David P. Kemp'" <[e-mail]>, <[e-mail]>
Subject: RE: Words, Books, and Key Usage
Date: Wed, 8 May 2002 07:33:14 -0400
Message-ID: <002401c1f684$24997fc0$a300a8c0@Chokhani>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.2627
Importance: Normal
In-Reply-To: <[e-mail]>
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4910.0300
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Trevor:

I think you are off-base and have not provide argument as to how I have
changed the semantics.  Just like you have certSign and cRLSign bits to
check signatures on objects, I have the entity authentication and
digital signature separate.

I would not go into mathematical detail, but taken to extreme, in RSA,
there is no difference in encryption and digital signature.

Your most cogent argument may be backward compatibility and none of the
vendors (including you) have responded as to which of the four choices
break interoperability.

-----Original Message-----
From: [e-mail] [mailto:[e-mail]]
On Behalf Of Trevor Freeman
Sent: Tuesday, May 07, 2002 4:56 PM
To: David P. Kemp; [e-mail]
Subject: RE: Words, Books, and Key Usage



Dave,

Semantics 
1) The branch of linguistics and logic concerned with meaning
2) The meaning of a word, phrase, sentence or text.
Concise Oxford English Dictionary - Queens English edition

If you are changing the meaning of bits when they are asserted in an
extension, then its semantics not structure we are dealing with. I don't
dispute that the semantics behind non-repudiation are a little fuzzy to
say the least, but there are some basic ground rules in there which have
been agreed and included in RFCs. If you want to define new semantics
with cleaner definitions, feel free to do so, but you cannot do so
within the confines of the existing extension as identified by the
existing OID. I don't have a problem with what you are doing, just don't
do it in such a way as you break existing standards.

Trevor

-----Original Message-----
From: David P. Kemp [mailto:[e-mail]] 
Sent: Tuesday, May 07, 2002 7:50 AM
To: [e-mail]
Subject: Words, Books, and Key Usage


    "Fiction - A literary work whose content is produced by
     the imagination and is not necessarily based on fact."

    "Non-fiction - Prose works other than fiction."

          -- www.dictionary.com


Trevor Freeman wrote:
> Santosh,
> Stop the spin doctoring ...
> 
> I really don't care which course you choose to achieve your
> objective, but you cannot redefine the semantics of the
> existing key usage extension and retain the same identifier.

The problem is not semantics being redefined, the problem is that many
thoughtful people have been trying to figure out, without success, the
semantics of an ill-structured specification.

Consider the parts of speech: nouns, verbs, adjectives, etc. Then X.509,
if applied to the English language, might read:

  Bits in the WordUsage type are as follows:
   a) word: for words that have purposes other than those
      identified in b, f, or g below;
   b) nonFiction: for words used in non-fiction whose content
      is fact-based prose (excluding verbs and adverbs, as in
      f or g below);
   ...
   f) verb: for words that express existence, action,
      or occurrence;
   g) adverb: for words that modify a verb, adjective,
      or other adverb;
   

As many others have observed, the problem with key usage
is not semantic, it is structural - non-repudiation is
not something that can be provided by a certificate or
certain type of signature, it is provided by a system.
As Peter Williams rightly observed some time ago, and you recently
repeated, even SSL can play a role in supporting some forms of
non-repudiation systems.  

Even though signed objects are more commonly associated with
non-repudiation than are signed challenges, and adjectives are more
common in novels than in technical papers, there is no one-to-one
correspondence.  Calling "non-repudiation" a key usage is as
structurally flawed as calling "non-fiction" a part of speech.  They
belong to two entirely different taxonomies.

The first step to recovery is admitting that something
is wrong.  I believe there is universal recognition and consensus that
non-repudiation is a different *kind* of thing than certificate signing,
key agreement, and data encipherment, and that the resulting confusion
is a problem for product developers, lawyers, and users alike.

The next step is to believe that the problem can be
fixed, and make a decision to fix it.  We're not there
yet.  But if we ever resolve to do more than talk about
it, we will find that a certain amount of semantic
redefinition is necessary -- you can't gain coherence
by retaining 100% compatibility with an incoherent
definition.

Even the ancients were smart enough to know that
the fundamental building blocks of the universe
are NOT "Earth", "Fire", "Elements Used in a Cave",
and "All Elements Except Earth, Fire, and those
used in a Cave".

Regards,
Dave



Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g48BTgc11582 for ietf-pkix-bks; Wed, 8 May 2002 04:29:42 -0700 (PDT)
Received: from mtiwmhc23.worldnet.att.net (mtiwmhc23.worldnet.att.net [204.127.131.48]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g48BTgL11578 for <[e-mail]>; Wed, 8 May 2002 04:29:42 -0700 (PDT)
Received: from Chokhani ([12.91.131.140]) by mtiwmhc23.worldnet.att.net (InterMail vM.4.01.03.27 201-229-121-127-20010626) with ESMTP id <20020508112930.FKXN28245.mtiwmhc23.worldnet.att.net@Chokhani>; Wed, 8 May 2002 11:29:30 +0000
From: "Santosh Chokhani" <[e-mail]>
To: "'Sharon Boeyen'" <[e-mail]>, <[e-mail]>, "'500 list \(E-mail\)'" <[e-mail]>
Cc: "'Bill Burr \(E-mail\)'" <[e-mail]>
Subject: RE: Meaning of Non-repudiation
Date: Wed, 8 May 2002 07:31:02 -0400
Message-ID: <001f01c1f683$d5e2be00$a300a8c0@Chokhani>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_0020_01C1F662.4ED11E00"
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.2627
Importance: Normal
In-Reply-To: <[e-mail]>
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4910.0300
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

This is a multi-part message in MIME format.

------=_NextPart_000_0020_01C1F662.4ED11E00
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit

All:
 
Personally, I do not have a problem with this, but two of the major
objections to my proposal make this even worse.
 
Folks say that we do not want to change the semantics of this extension.
Well, all the other bits in the keyUsage say what cryptographic
operation clients can use the bit for.  This bit does not do that.
Also, the them key usage means what operations the key can be used for.
Please read the introduction to X.509 definition of the extension.
 
I really believe the two bit distinction is only useful using what I
have recommended.  I am not saying this because I finally got the
religion or anything.  I think the proposal is in line with how all the
other bits are used for: what type of crypto operation on what type of
data.
 
But, since some key players are in violent disagreement, the best course
seems to be the language son of 2459 has.
 

-----Original Message-----
From: [e-mail] [mailto:[e-mail]]
On Behalf Of Sharon Boeyen
Sent: Tuesday, May 07, 2002 9:28 AM
To: [e-mail]; 500 list (E-mail)
Cc: Bill Burr (E-mail)
Subject: Meaning of Non-repudiation



I'd like to introduce another perspective on this topic, one that I
really think helps add some fundamental clarity to the topic. During the
US FPKI TWG meeting last week, this topic was raised and a short
discussion was held. Bill Burr commented that he understood the meaning
of the non-repudiation bit being set to be a statement by the
certificate issuer (CA) that they at no point had any access to the
private key corresponding to the public key being certified. I really
like this because it states what role this bit plays in a
non-repudiation context. It is simply that and nothing more. The
remaining mechanisms for supporting a non-repudiation service are
outside the scope of the definition of this bit. Legal and policy
schemes can determine the behaviour of relying parties and users when
this bit is set. The bit itself cannot do that. If an assertion that a
user who signed something "knew and intended to sign whatever", then
that assertion should be something that accompanies a specific
signature. This bit cannot be expected to act as that assertion. 

I also agree with Stefan that we need describe the digital signature bit
separate from the description of the non-repudiation bit in 509. Then it
is left to profiling groups, as it shoud be, what combinations of bits
they want set in their own environments.  

Re the debate on changing the meaning - The reason we are having this
discussion (at least one of the reasons) is because the meaning of these
bits is not clear to many readers. Both the process of defect reports as
well as the enhancement process allows us to clarify text in the
standard, as well as to fix bugs etc). Part of the problem is that there
isn't agreement on what the original text meant, hence the
clarification. Once there is some sort of agreement on what the "right
thing to do" is, then we'll determine what the process is to achieve the
intended result. That's part of the reason why we are having the
discussion before writing up a DR or an enhancement request.

Sharon 

Sharon Boeyen 
Principal, Advanced Security 
Tel: [phone] 
www.entrust.com 

Entrust, Inc. 
Securing the Internet 



------=_NextPart_000_0020_01C1F662.4ED11E00
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Dus-ascii">
<TITLE>Message</TITLE>

<META content=3D"MSHTML 5.50.4915.500" name=3DGENERATOR></HEAD>
<BODY>
<DIV><SPAN class=3D438352111-08052002><FONT face=3DArial color=3D#0000ff =

size=3D2>All:</FONT></SPAN></DIV>
<DIV><SPAN class=3D438352111-08052002><FONT face=3DArial color=3D#0000ff =

size=3D2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=3D438352111-08052002><FONT face=3DArial color=3D#0000ff =

size=3D2>Personally, I do not have a problem with this, but two of the =
major=20
objections to my proposal make this even worse.</FONT></SPAN></DIV>
<DIV><SPAN class=3D438352111-08052002><FONT face=3DArial color=3D#0000ff =

size=3D2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=3D438352111-08052002><FONT face=3DArial color=3D#0000ff =
size=3D2>Folks=20
say that we do not want to change the semantics of this extension.&nbsp; =
Well,=20
all the other bits in the keyUsage say what cryptographic operation =
clients can=20
use the bit for.&nbsp; This bit does not do that.&nbsp; Also, the them =
key usage=20
means what operations the key can be used for.&nbsp; Please read the=20
introduction to X.509 definition of the extension.</FONT></SPAN></DIV>
<DIV><SPAN class=3D438352111-08052002><FONT face=3DArial color=3D#0000ff =

size=3D2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=3D438352111-08052002><FONT face=3DArial color=3D#0000ff =
size=3D2>I=20
really believe the two bit distinction is only useful using what I have=20
recommended.&nbsp; I am not saying this because I finally got the =
religion or=20
anything.&nbsp; I think the proposal is in line with how all the other =
bits are=20
used for: what type of crypto operation on what type of=20
data.</FONT></SPAN></DIV>
<DIV><SPAN class=3D438352111-08052002><FONT face=3DArial color=3D#0000ff =

size=3D2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=3D438352111-08052002><FONT face=3DArial color=3D#0000ff =
size=3D2>But,=20
since some key players are in violent disagreement, the best course =
seems to be=20
the language son of 2459 has.</FONT></SPAN></DIV>
<DIV><SPAN class=3D438352111-08052002><FONT face=3DArial color=3D#0000ff =

size=3D2></FONT></SPAN>&nbsp;</DIV>
<BLOCKQUOTE style=3D"MARGIN-RIGHT: 0px">
  <DIV></DIV>
  <DIV class=3DOutlookMessageHeader lang=3Den-us dir=3Dltr =
align=3Dleft><FONT=20
  face=3DTahoma size=3D2>-----Original Message-----<BR><B>From:</B>=20
  [e-mail] [mailto:[e-mail]] =
<B>On=20
  Behalf Of </B>Sharon Boeyen<BR><B>Sent:</B> Tuesday, May 07, 2002 9:28 =

  AM<BR><B>To:</B> [e-mail]; 500 list (E-mail)<BR><B>Cc:</B> =
Bill Burr=20
  (E-mail)<BR><B>Subject:</B> Meaning of =
Non-repudiation<BR><BR></FONT></DIV>
  <P><FONT face=3DArial size=3D2>I'd like to introduce another =
perspective on this=20
  topic, one that I really think helps add some fundamental clarity to =
the=20
  topic. During the US FPKI TWG meeting last week, this topic was raised =
and a=20
  short discussion was held. Bill Burr commented that he understood the =
meaning=20
  of the non-repudiation bit being set to be a statement by the =
certificate=20
  issuer (CA) that they at no point had any access to the private key=20
  corresponding to the public key being certified. I really like this =
because it=20
  states what role this bit plays in a non-repudiation context. It is =
simply=20
  that and nothing more. The remaining mechanisms for supporting a=20
  non-repudiation service are outside the scope of the definition of =
this bit.=20
  Legal and policy schemes can determine the behaviour of relying =
parties and=20
  users when this bit is set. The bit itself cannot do that. If an =
assertion=20
  that a user who signed something "knew and intended to sign whatever", =
then=20
  that assertion should be something that accompanies a specific =
signature. This=20
  bit cannot be expected to act as that assertion. </FONT></P>
  <P><FONT face=3DArial size=3D2>I also agree with Stefan that we need =
describe the=20
  digital signature bit separate from the description of the =
non-repudiation bit=20
  in 509. Then it is left to profiling groups, as it shoud be, what =
combinations=20
  of bits they want set in their own environments.&nbsp; </FONT></P>
  <P><FONT face=3DArial size=3D2>Re the debate on changing the meaning - =
The reason=20
  we are having this discussion (at least one of the reasons) is because =
the=20
  meaning of these bits is not clear to many readers. Both the process =
of defect=20
  reports as well as the enhancement process allows us to clarify text =
in the=20
  standard, as well as to fix bugs etc). Part of the problem is that =
there isn't=20
  agreement on what the original text meant, hence the clarification. =
Once there=20
  is some sort of agreement on what the "right thing to do" is, then =
we'll=20
  determine what the process is to achieve the intended result. That's =
part of=20
  the reason why we are having the discussion before writing up a DR or =
an=20
  enhancement request.</FONT></P>
  <P><FONT face=3DArial size=3D2>Sharon</FONT> </P>
  <P><FONT face=3D"Courier New" size=3D2>Sharon Boeyen</FONT> <BR><FONT=20
  face=3D"Courier New" size=3D2>Principal, Advanced Security</FONT> =
<BR><FONT=20
  face=3D"Courier New" size=3D2>Tel: [phone] </FONT><BR><FONT=20
  face=3D"Courier New" size=3D2>www.entrust.com</FONT> </P>
  <P><FONT face=3D"Courier New" size=3D2>Entrust, Inc.</FONT> <BR><FONT=20
  face=3D"Courier New" size=3D2>Securing the Internet</FONT>=20
</P><BR></BLOCKQUOTE></BODY></HTML>

------=_NextPart_000_0020_01C1F662.4ED11E00--



Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g489Pip00987 for ietf-pkix-bks; Wed, 8 May 2002 02:25:44 -0700 (PDT)
Received: from exafix.addtrust.com ([212.112.175.83]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g489PgL00982 for <[e-mail]>; Wed, 8 May 2002 02:25:42 -0700 (PDT)
Received: from stsIBMT20.addtrust.com ([192.168.101.118]) by exafix.addtrust.com with Microsoft SMTPSVC(5.0.2195.2966); Wed, 8 May 2002 11:25:20 +0200
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Version 5.1
Date: Wed, 08 May 2002 11:25:20 +0200
To: Sharon Boeyen <[e-mail]>, "'Tom Gindin'" <[e-mail]>, Sharon Boeyen <[e-mail]>
From: Stefan Santesson <[e-mail]>
Subject: RE: Meaning of Non-repudiation
Cc: [e-mail], "500 list (E-mail)" <[e-mail]>, "Bill Burr (E-mail)" <[e-mail]>
In-Reply-To: <[e-mail] .com>
Mime-Version: 1.0
Content-Type: multipart/alternative; boundary="=====================_183622625==_.ALT"
X-OriginalArrivalTime: 08 May 2002 09:25:20.0643 (UTC) FILETIME=[46221D30:01C1F672]
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

--=====================_183622625==_.ALT
Content-Type: text/plain; charset="us-ascii"; format=flowed

Sharon,

I agree to almost everything you say but I will have to disagree on this 
particular issue.

The fact that the CA have never possessed or processed the private key is 
neither a clear statement and nor is it always necessary in order 
to  obtain non-repudiation.

One example where you could encounter problem with such definition is when 
you use centrally produced smart cards or key tokens with pre-produced 
keys. Even if the keys have never been exposed in the process, one could 
argue that they have been processed and possessed by the CA system.

Such cards are in use today as national ID-cards and are used to provide NR.

/Stefan



At 14:53 2002-05-07 -0400, Sharon Boeyen wrote:

>Tom, I absolutely agree that this would be insufficient for 
>non-repudiation. However,
>non-repudiation is not a technical operation, but a policy/legal one. This 
>bit is only
>one very small component of non-repudiation. It is the CAs statement. The 
>user's statement
>should be something that accompanies their signature. In the example you 
>cite, perhaps in
>one environment, the policy dictates that all browser generated keys are 
>solely to be used
>for online authentication of a user to a service and not for signatures 
>that could be used
>in a non-repudiation context. In that environment, the policy would 
>dictate that the CA set
>only the digital signature bit and not the non-repudiation bit, regardless 
>of the fact that
>the CA hadn't seen the private key. In another environment, the policy 
>might dictate that
>all client side generated private keys could be used for signatures in a 
>non-repudiation
>context. In that particular environment the policy could dictate that the 
>CA does set the
>non-repudiation bit. The policy would also dictate the key-usage bits that 
>need to be set
>for the different types of operations a user performs (perhaps tied to 
>specific local applications
>e.g. if signing a purchase order must use a key that has this bit set). So 
>all the combinations
>would still be possible, but if the non-repudiation bit was set it would 
>be purely a statement
>by the CA (as dictated by policy) that it did not generate and never had 
>access to the private
>key. That is different that 'requiring' that the bit always be set if the 
>CA didn't generate the
>key. Hope that helps.
>
>Sharon
>
>-----Original Message-----
>From: Tom Gindin [<mailto:[e-mail]>mailto:[e-mail]]
>Sent: Tuesday, May 07, 2002 1:32 PM
>To: Sharon Boeyen
>Cc: [e-mail]; 500 list (E-mail); Bill Burr (E-mail)
>Subject: Re: Meaning of Non-repudiation
>
>
>       Sharon:
>
>       With all due respect, IMHO this would be a step backward because the
>condition is certainly not sufficient for an NR key.  If a browser
>generated a key pair locally for authentication purposes, stored it on its
>local disk database, and submitted a PKCS#10 or CR requesting signatures
>for authentication it would meet this criterion.  I don't know if this is
>even a necessary criterion, but it is certainly insufficient.
>
>             Tom Gindin
>
>Sharon Boeyen <[e-mail]>@mail.imc.org on 05/07/2002
>09:28:23 AM
>
>Sent by:    [e-mail]
>
>To:    [e-mail], "500 list (E-mail)" <[e-mail]>
>cc:    "Bill Burr (E-mail)" <[e-mail]>
>Subject:    Meaning of Non-repudiation
>
>I'd like to introduce another perspective on this topic, one that I really
>think helps add some fundamental clarity to the topic. During the US FPKI
>TWG meeting last week, this topic was raised and a short discussion was
>held. Bill Burr commented that he understood the meaning of the
>non-repudiation bit being set to be a statement by the certificate issuer
>(CA) that they at no point had any access to the private key corresponding
>to the public key being certified. I really like this because it states
>what role this bit plays in a non-repudiation context. It is simply that
>and nothing more. The remaining mechanisms for supporting a non-repudiation
>service are outside the scope of the definition of this bit. Legal and
>policy schemes can determine the behaviour of relying parties and users
>when this bit is set. The bit itself cannot do that. If an assertion that a
>user who signed something "knew and intended to sign whatever", then that
>assertion should be something that accompanies a specific signature. This
>bit cannot be expected to act as that assertion.
>
>I also agree with Stefan that we need describe the digital signature bit
>separate from the description of the non-repudiation bit in 509. Then it is
>left to profiling groups, as it shoud be, what combinations of bits they
>want set in their own environments.
>
>Re the debate on changing the meaning - The reason we are having this
>discussion (at least one of the reasons) is because the meaning of these
>bits is not clear to many readers. Both the process of defect reports as
>well as the enhancement process allows us to clarify text in the standard,
>as well as to fix bugs etc). Part of the problem is that there isn't
>agreement on what the original text meant, hence the clarification. Once
>there is some sort of agreement on what the "right thing to do" is, then
>we'll determine what the process is to achieve the intended result. That's
>part of the reason why we are having the discussion before writing up a DR
>or an enhancement request.
>
>Sharon
>
>Sharon Boeyen
>Principal, Advanced Security
>Tel: [phone]
>www.entrust.com
>
>Entrust, Inc.
>Securing the Internet
>
>
>
>

--=====================_183622625==_.ALT
Content-Type: text/html; charset="us-ascii"

<html>
Sharon,<br><br>
I agree to almost everything you say but I will have to disagree on this
particular issue.<br><br>
The fact that the CA have never possessed or processed the private key is
neither a clear statement and nor is it always necessary in order
to&nbsp; obtain non-repudiation.<br><br>
One example where you could encounter problem with such definition is
when you use centrally produced smart cards or key tokens with
pre-produced keys. Even if the keys have never been exposed in the
process, one could argue that they have been processed and possessed by
the CA system.<br><br>
Such cards are in use today as national ID-cards and are used to provide
NR.<br><br>
/Stefan<br><br>
<br><br>
At 14:53 2002-05-07 -0400, Sharon Boeyen wrote:<br><br>
<blockquote type=cite class=cite cite><font size=2>Tom, I absolutely
agree that this would be insufficient for non-repudiation.
However,</font> <br>
<font size=2>non-repudiation is not a technical operation, but a
policy/legal one. This bit is only </font><br>
<font size=2>one very small component of non-repudiation. It is the CAs
statement. The user's statement</font> <br>
<font size=2>should be something that accompanies their signature. In the
example you cite, perhaps in </font><br>
<font size=2>one environment, the policy dictates that all browser
generated keys are solely to be used </font><br>
<font size=2>for online authentication of a user to a service and not for
signatures that could be used</font> <br>
<font size=2>in a non-repudiation context. In that environment, the
policy would dictate that the CA set </font><br>
<font size=2>only the digital signature bit and not the non-repudiation
bit, regardless of the fact that </font><br>
<font size=2>the CA hadn't seen the private key. In another environment,
the policy might dictate that </font><br>
<font size=2>all client side generated private keys could be used for
signatures in a non-repudiation </font><br>
<font size=2>context. In that particular environment the policy could
dictate that the CA does set the </font><br>
<font size=2>non-repudiation bit. The policy would also dictate the
key-usage bits that need to be set </font><br>
<font size=2>for the different types of operations a user performs
(perhaps tied to specific local applications</font> <br>
<font size=2>e.g. if signing a purchase order must use a key that has
this bit set). So all the combinations</font> <br>
<font size=2>would still be possible, but if the non-repudiation bit was
set it would be purely a statement </font><br>
<font size=2>by the CA (as dictated by policy) that it did not generate
and never had access to the private </font><br>
<font size=2>key. That is different that 'requiring' that the bit always
be set if the CA didn't generate the </font><br>
<font size=2>key. Hope that helps.</font> <br><br>
<font size=2>Sharon</font> <br><br>
<font size=2>-----Original Message-----</font> <br>
<font size=2>From: Tom Gindin
[<a href="mailto:[e-mail]">mailto:[e-mail]</a>]</font>
<br>
<font size=2>Sent: Tuesday, May 07, 2002 1:32 PM</font> <br>
<font size=2>To: Sharon Boeyen</font> <br>
<font size=2>Cc: [e-mail]; 500 list (E-mail); Bill Burr
(E-mail)</font> <br>
<font size=2>Subject: Re: Meaning of Non-repudiation</font> <br><br>
<br>
<font size=2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Sharon:</font> <br><br>
<font size=2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; With all due respect, IMHO
this would be a step backward because the</font> <br>
<font size=2>condition is certainly not sufficient for an NR key.&nbsp;
If a browser</font> <br>
<font size=2>generated a key pair locally for authentication purposes,
stored it on its</font> <br>
<font size=2>local disk database, and submitted a PKCS#10 or CR
requesting signatures</font> <br>
<font size=2>for authentication it would meet this criterion.&nbsp; I
don't know if this is</font> <br>
<font size=2>even a necessary criterion, but it is certainly
insufficient.</font> <br><br>
<font size=2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Tom Gindin</font> <br><br>
<font size=2>Sharon Boeyen &lt;[e-mail]&gt;@mail.imc.org
on 05/07/2002</font> <br>
<font size=2>09:28:23 AM</font> <br><br>
<font size=2>Sent by:&nbsp;&nbsp;&nbsp;
[e-mail]</font> <br><br>
<font size=2>To:&nbsp;&nbsp;&nbsp; [e-mail], &quot;500 list
(E-mail)&quot; &lt;[e-mail]&gt;</font> <br>
<font size=2>cc:&nbsp;&nbsp;&nbsp; &quot;Bill Burr (E-mail)&quot;
&lt;[e-mail]&gt;</font> <br>
<font size=2>Subject:&nbsp;&nbsp;&nbsp; Meaning of Non-repudiation</font>
<br><br>
<font size=2>I'd like to introduce another perspective on this topic, one that I really</font> <br>
<font size=2>think helps add some fundamental clarity to the topic. During the US FPKI</font> <br>
<font size=2>TWG meeting last week, this topic was raised and a short discussion was</font> <br>
<font size=2>held. Bill Burr commented that he understood the meaning of the</font> <br>
<font size=2>non-repudiation bit being set to be a statement by the certificate issuer</font> <br>
<font size=2>(CA) that they at no point had any access to the private key corresponding</font> <br>
<font size=2>to the public key being certified. I really like this because it states</font> <br>
<font size=2>what role this bit plays in a non-repudiation context. It is simply that</font> <br>
<font size=2>and nothing more. The remaining mechanisms for supporting a non-repudiation</font> <br>
<font size=2>service are outside the scope of the definition of this bit. Legal and</font> <br>
<font size=2>policy schemes can determine the behaviour of relying parties and users</font> <br>
<font size=2>when this bit is set. The bit itself cannot do that. If an assertion that a</font> <br>
<font size=2>user who signed something &quot;knew and intended to sign whatever&quot;, then that</font> <br>
<font size=2>assertion should be something that accompanies a specific signature. This</font> <br>
<font size=2>bit cannot be expected to act as that assertion.</font> <br><br>
<font size=2>I also agree with Stefan that we need describe the digital signature bit</font> <br>
<font size=2>separate from the description of the non-repudiation bit in 509. Then it is</font> <br>
<font size=2>left to profiling groups, as it shoud be, what combinations of bits they</font> <br>
<font size=2>want set in their own environments.</font> <br><br>
<font size=2>Re the debate on changing the meaning - The reason we are having this</font> <br>
<font size=2>discussion (at least one of the reasons) is because the meaning of these</font> <br>
<font size=2>bits is not clear to many readers. Both the process of defect reports as</font> <br>
<font size=2>well as the enhancement process allows us to clarify text in the standard,</font> <br>
<font size=2>as well as to fix bugs etc). Part of the problem is that there isn't</font> <br>
<font size=2>agreement on what the original text meant, hence the clarification. Once</font> <br>
<font size=2>there is some sort of agreement on what the &quot;right thing to do&quot; is, then</font> <br>
<font size=2>we'll determine what the process is to achieve the intended result. That's</font> <br>
<font size=2>part of the reason why we are having the discussion before writing up a DR</font> <br>
<font size=2>or an enhancement request.</font> <br><br>
<font size=2>Sharon</font> <br><br>
<font size=2>Sharon Boeyen</font> <br>
<font size=2>Principal, Advanced Security</font> <br>
<font size=2>Tel: [phone]</font> <br>
<font size=2><a href="http://www.entrust.com/" eudora="autourl">www.entrust.com</a></font> <br><br>
<font size=2>Entrust, Inc.</font> <br>
<font size=2>Securing the Internet</font> <br><br>
<br><br>
<br>
</blockquote></html>

--=====================_183622625==_.ALT--



Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g485JmO27253 for ietf-pkix-bks; Tue, 7 May 2002 22:19:48 -0700 (PDT)
Received: from hermes.cs.auckland.ac.nz (hermes.cs.auckland.ac.nz [130.216.35.151]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g485JeL27246 for <[e-mail]>; Tue, 7 May 2002 22:19:45 -0700 (PDT)
Received: from ruru.cs.auckland.ac.nz (ruru-nfs.cs.auckland.ac.nz [130.216.35.12]) by hermes.cs.auckland.ac.nz (8.12.3/8.12.3) with ESMTP id g485JXaq013693; Wed, 8 May 2002 17:19:33 +1200
Received: (from pgut001@localhost) by ruru.cs.auckland.ac.nz (8.9.3/8.8.6/cs-slave) id RAA82824; Wed, 8 May 2002 17:19:31 +1200 (NZST) (sender [e-mail])
Date: Wed, 8 May 2002 17:19:31 +1200 (NZST)
Message-ID: <[e-mail]>
From: [e-mail] (Peter Gutmann)
To: [e-mail], [e-mail]
Subject: Re:  Words, Books, and Key Usage
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

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

>The first step to recovery is admitting that something is wrong. 

Hi.  My name is Peter and I have a keyUsage problem.  Initially it
was just small things, a little digitalSignature after lunch, maybe
a dataEncipherment after dinner and keyAgreement as a nightcap.  Then
I started combining digitalSignature and keyEncipherment in the same
certificate.  It just got worse and worse.  In the end I was
experimenting with mixing digitalSignature and nonRepudiation, and 
even freebasing keyCertSigns.  One morning I woke up in bed next to
a giant lizard wearing a Mozilla t-shirt, and knew I had a problem.

It's now been six weeks since my last nonRepudiation...

Peter.



Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g47NMRY16979 for ietf-pkix-bks; Tue, 7 May 2002 16:22:27 -0700 (PDT)
Received: from nymelsmtp.internet.ny.fdms.firstdata.com ([204.124.248.17]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g47NMPL16969 for <[e-mail]>; Tue, 7 May 2002 16:22:25 -0700 (PDT)
Subject: RE: Words, Books, and Key Usage
To: "Trevor Freeman" <[e-mail]>
Cc: "David P. Kemp" <[e-mail]>, [e-mail], [e-mail]
X-Mailer: Lotus Notes Release 5.0.5  September 22, 2000
Message-ID: <[e-mail]>
From: [e-mail]
Date: Tue, 7 May 2002 17:21:18 -0600
X-MIMETrack: Serialize by Router on NYMELSMTP/NY/FDMS/FDC(Release 5.0.8 |June 18, 2001) at 05/07/2002 07:19:25 PM
MIME-Version: 1.0
Content-type: text/plain; charset=us-ascii
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

however, it is possible that a lable for a bit has some semantic meaning
that is no way related to the feature/function implemented for the bit.

If the bit means that the CA has never seen the originator's private key
... it is possible for the CA to certify that by turning the bit on in a
certificate, signing the certificate and attesting to the fact that the CA
has never seen the originator's private key.

If the originator wants to have a certificate that has a bit turned on
indicating the originator's intention not to have ever shared the private
key with anybody ... then possibly, the originator can sign a message sent
to the CA with that assertion; the CA just copies the assertion to its
certificate ... not actually certifying anything other than it has copied
some assertion by the originator into the certificate.

The NSA Intrustion glossary

non-repudiation
Method by which the sender of data is provided with proof of delivery and
the recipient is assured of the sender's identity, so that neither can
later deny having processed the data.

obviously, the CA turning on a bit in a certificate doesn't meet that
definition. somewhere lurking behind the scenes is the stuff about being
able to disproving non-repudiation by showing that entities other than the
sender may have had access to the private key.  Having the CA certify that
they have no knowledge of the private key (at least at the time of the
creation of the certificate) ... isn't an exhaustive proof that there is
nobody else that might have knowledge of the private key (or that the CA
might acquire knowledge of the private key in the future).

earlier parts of this thread also brought up non-repudiation in the context
of "processing" signed data ... which might imply some agreement or
intention regarding any possible semantic meaning of the data processed.
The simplest is being able to demonstrate that the sender sent the data ...
w/o implying anything about any knowledge, intention, and/or agreement that
the sender might have with regard to the semantic meaning of the data
transmitted. Being able to show that somebody else could have sent the
message ... would obviously negate assertions about non-repudiation.
However, not being to find anybody else with knowledge of the private key
... isn't necessary proof that there isn't somebody else with knowledge of
the private key. Also, even if it is possible to proove that nobody else
has knowledge or access of the private key ... doesn't proove that the
sender did anything else but transmit the data .... it doesn't proove any
knowledge or processing of the data ... other than the transmission.

in any case, the bit seems to represent a meaning that isn't consistent
with the meaning of the label applied to the bit (aka non-repudiation).

somewhat total aside did have a booth a couple weeks ago in new orleans at
cardtech/securetech with a hardware token where there is public/private
key-pair generated in the chip ... and the private key is never divulged
(leaves the chip) ... basically aads chip strawman
http://www.garlic.com/~lynn/index.html#aads

with couple twists ... like PIN-mode (and shortly biometric-scoring-mode)
operation ... and able to operate in both access & financial token
personality mode (aka earlier post in this thread):
http://www.garlic.com/~lynn/aadsm11.htm#5



<[e-mail] on 5/7/2002 2:55 pm wrote:


Dave,

Semantics
1) The branch of linguistics and logic concerned with meaning
2) The meaning of a word, phrase, sentence or text.
Concise Oxford English Dictionary - Queens English edition

If you are changing the meaning of bits when they are asserted in an
extension, then its semantics not structure we are dealing with. I don't
dispute that the semantics behind non-repudiation are a little fuzzy to
say the least, but there are some basic ground rules in there which have
been agreed and included in RFCs. If you want to define new semantics
with cleaner definitions, feel free to do so, but you cannot do so
within the confines of the existing extension as identified by the
existing OID. I don't have a problem with what you are doing, just don't
do it in such a way as you break existing standards.

Trevor






Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g47KtoQ12264 for ietf-pkix-bks; Tue, 7 May 2002 13:55:50 -0700 (PDT)
Received: from mail3.microsoft.com (mail3.microsoft.com [131.107.3.123]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g47KtnL12260 for <[e-mail]>; Tue, 7 May 2002 13:55:49 -0700 (PDT)
Received: from INET-VRS-03.redmond.corp.microsoft.com ([157.54.5.27]) by mail3.microsoft.com with Microsoft SMTPSVC(5.0.2195.4905); Tue, 7 May 2002 13:55:46 -0700
Received: from 157.54.6.150 by INET-VRS-03.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Tue, 07 May 2002 13:55:46 -0700
Received: from red-imc-01.redmond.corp.microsoft.com ([157.54.9.102]) by inet-hub-05.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.4905); Tue, 7 May 2002 13:55:46 -0700
Received: from win-imc-02.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.84]) by red-imc-01.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.4905); Tue, 7 May 2002 13:55:43 -0700
Received: from win-msg-01.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.52]) by win-imc-02.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3590.0); Tue, 7 May 2002 13:55:44 -0700
X-MimeOLE: Produced By Microsoft Exchange V6.0.6177.0
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Subject: RE: Words, Books, and Key Usage
Date: Tue, 7 May 2002 13:55:39 -0700
Message-ID: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: Words, Books, and Key Usage
Thread-Index: AcH116r6RqTu0rstS6KDMuCvMk7BDgALl13A
From: "Trevor Freeman" <[e-mail]>
To: "David P. Kemp" <[e-mail]>, <[e-mail]>
X-OriginalArrivalTime: 07 May 2002 20:55:44.0708 (UTC) FILETIME=[8E631040:01C1F609]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id g47KtnL12261
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Dave,

Semantics 
1) The branch of linguistics and logic concerned with meaning
2) The meaning of a word, phrase, sentence or text.
Concise Oxford English Dictionary - Queens English edition

If you are changing the meaning of bits when they are asserted in an
extension, then its semantics not structure we are dealing with. I don't
dispute that the semantics behind non-repudiation are a little fuzzy to
say the least, but there are some basic ground rules in there which have
been agreed and included in RFCs. If you want to define new semantics
with cleaner definitions, feel free to do so, but you cannot do so
within the confines of the existing extension as identified by the
existing OID. I don't have a problem with what you are doing, just don't
do it in such a way as you break existing standards.

Trevor

-----Original Message-----
From: David P. Kemp [mailto:[e-mail]] 
Sent: Tuesday, May 07, 2002 7:50 AM
To: [e-mail]
Subject: Words, Books, and Key Usage


    "Fiction - A literary work whose content is produced by
     the imagination and is not necessarily based on fact."

    "Non-fiction - Prose works other than fiction."

          -- www.dictionary.com


Trevor Freeman wrote:
> Santosh,
> Stop the spin doctoring ...
> 
> I really don't care which course you choose to achieve your 
> objective, but you cannot redefine the semantics of the
> existing key usage extension and retain the same identifier.

The problem is not semantics being redefined, the problem is that
many thoughtful people have been trying to figure out, without
success, the semantics of an ill-structured specification.

Consider the parts of speech: nouns, verbs, adjectives, etc.
Then X.509, if applied to the English language, might read:

  Bits in the WordUsage type are as follows:
   a) word: for words that have purposes other than those
      identified in b, f, or g below;
   b) nonFiction: for words used in non-fiction whose content
      is fact-based prose (excluding verbs and adverbs, as in
      f or g below);
   ...
   f) verb: for words that express existence, action,
      or occurrence;
   g) adverb: for words that modify a verb, adjective,
      or other adverb;
   

As many others have observed, the problem with key usage
is not semantic, it is structural - non-repudiation is
not something that can be provided by a certificate or
certain type of signature, it is provided by a system.
As Peter Williams rightly observed some time ago, and you
recently repeated, even SSL can play a role in supporting
some forms of non-repudiation systems.  

Even though signed objects are more commonly associated with
non-repudiation than are signed challenges, and adjectives
are more common in novels than in technical papers, there is
no one-to-one correspondence.  Calling "non-repudiation"
a key usage is as structurally flawed as calling
"non-fiction" a part of speech.  They belong to two
entirely different taxonomies.

The first step to recovery is admitting that something
is wrong.  I believe there is universal recognition and
consensus that non-repudiation is a different *kind* of
thing than certificate signing, key agreement, and
data encipherment, and that the resulting confusion
is a problem for product developers, lawyers, and users
alike.

The next step is to believe that the problem can be
fixed, and make a decision to fix it.  We're not there
yet.  But if we ever resolve to do more than talk about
it, we will find that a certain amount of semantic
redefinition is necessary -- you can't gain coherence
by retaining 100% compatibility with an incoherent
definition.

Even the ancients were smart enough to know that
the fundamental building blocks of the universe
are NOT "Earth", "Fire", "Elements Used in a Cave",
and "All Elements Except Earth, Fire, and those
used in a Cave".

Regards,
Dave


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g47KMQd11037 for ietf-pkix-bks; Tue, 7 May 2002 13:22:26 -0700 (PDT)
Received: from nymelsmtp.internet.ny.fdms.firstdata.com ([204.124.248.17]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g47KMPL11026 for <[e-mail]>; Tue, 7 May 2002 13:22:25 -0700 (PDT)
Subject: Re: Meaning of Non-repudiation
To: [e-mail]
Cc: [e-mail], "500 list (E-mail)" <[e-mail]>, [e-mail], Sharon Boeyen <[e-mail]>, "Bill Burr (E-mail)" <[e-mail]>
X-Mailer: Lotus Notes Release 5.0.5  September 22, 2000
Message-ID: <[e-mail]>
From: [e-mail]
Date: Tue, 7 May 2002 14:21:12 -0600
X-MIMETrack: Serialize by Router on NYMELSMTP/NY/FDMS/FDC(Release 5.0.8 |June 18, 2001) at 05/07/2002 04:19:24 PM
MIME-Version: 1.0
Content-type: text/plain; charset=us-ascii
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

sorry, finger fumble with the keys ... or the fingers movingfaster than the
brain.

http://www.garlic.com/~lynn/secure.htm

is the merged security glossary.

for more info about merged glossaries and sources see:
http://www.garlic.com/~lynn/index.html#glossary



[e-mail] on 5/7/2002 11:28 am wrote:

as aside ... definition for "non-repudation" (from nsa intrustion glossary)
and "non-repudation sevice" (from rfc2828) are in merged security glossary:
http://www.garlic.com/~lynn/security.htm

... quick path is to click on "PAIN" in acronym fastpath ... and then click
on "non-repudiation".






Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g47IrZJ07329 for ietf-pkix-bks; Tue, 7 May 2002 11:53:35 -0700 (PDT)
Received: from SOTTMXS01.entrust.com (mail.entrust.com [216.191.251.35]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g47IrYL07323 for <[e-mail]>; Tue, 7 May 2002 11:53:34 -0700 (PDT)
Received: by SOTTMXS01.entrust.com with Internet Mail Service (5.5.2653.19) id <K3ZDVG1M>; Tue, 7 May 2002 14:53:21 -0400
Message-ID: <[e-mail]>
From: Sharon Boeyen <[e-mail]>
To: "'Tom Gindin'" <[e-mail]>, Sharon Boeyen <[e-mail]>
Cc: [e-mail], "500 list (E-mail)" <[e-mail]>, "Bill Burr (E-mail)" <[e-mail]>
Subject: RE: Meaning of Non-repudiation
Date: Tue, 7 May 2002 14:53:19 -0400 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1F5F8.748F08B0"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

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_01C1F5F8.748F08B0
Content-Type: text/plain

Tom, I absolutely agree that this would be insufficient for non-repudiation.
However,
non-repudiation is not a technical operation, but a policy/legal one. This
bit is only 
one very small component of non-repudiation. It is the CAs statement. The
user's statement
should be something that accompanies their signature. In the example you
cite, perhaps in 
one environment, the policy dictates that all browser generated keys are
solely to be used 
for online authentication of a user to a service and not for signatures that
could be used
in a non-repudiation context. In that environment, the policy would dictate
that the CA set 
only the digital signature bit and not the non-repudiation bit, regardless
of the fact that 
the CA hadn't seen the private key. In another environment, the policy might
dictate that 
all client side generated private keys could be used for signatures in a
non-repudiation 
context. In that particular environment the policy could dictate that the CA
does set the 
non-repudiation bit. The policy would also dictate the key-usage bits that
need to be set 
for the different types of operations a user performs (perhaps tied to
specific local applications
e.g. if signing a purchase order must use a key that has this bit set). So
all the combinations
would still be possible, but if the non-repudiation bit was set it would be
purely a statement 
by the CA (as dictated by policy) that it did not generate and never had
access to the private 
key. That is different that 'requiring' that the bit always be set if the CA
didn't generate the 
key. Hope that helps.

Sharon

-----Original Message-----
From: Tom Gindin [mailto:[e-mail]]
Sent: Tuesday, May 07, 2002 1:32 PM
To: Sharon Boeyen
Cc: [e-mail]; 500 list (E-mail); Bill Burr (E-mail)
Subject: Re: Meaning of Non-repudiation



      Sharon:

      With all due respect, IMHO this would be a step backward because the
condition is certainly not sufficient for an NR key.  If a browser
generated a key pair locally for authentication purposes, stored it on its
local disk database, and submitted a PKCS#10 or CR requesting signatures
for authentication it would meet this criterion.  I don't know if this is
even a necessary criterion, but it is certainly insufficient.

            Tom Gindin

Sharon Boeyen <[e-mail]>@mail.imc.org on 05/07/2002
09:28:23 AM

Sent by:    [e-mail]


To:    [e-mail], "500 list (E-mail)" <[e-mail]>
cc:    "Bill Burr (E-mail)" <[e-mail]>
Subject:    Meaning of Non-repudiation


I'd like to introduce another perspective on this topic, one that I really
think helps add some fundamental clarity to the topic. During the US FPKI
TWG meeting last week, this topic was raised and a short discussion was
held. Bill Burr commented that he understood the meaning of the
non-repudiation bit being set to be a statement by the certificate issuer
(CA) that they at no point had any access to the private key corresponding
to the public key being certified. I really like this because it states
what role this bit plays in a non-repudiation context. It is simply that
and nothing more. The remaining mechanisms for supporting a non-repudiation
service are outside the scope of the definition of this bit. Legal and
policy schemes can determine the behaviour of relying parties and users
when this bit is set. The bit itself cannot do that. If an assertion that a
user who signed something "knew and intended to sign whatever", then that
assertion should be something that accompanies a specific signature. This
bit cannot be expected to act as that assertion.


I also agree with Stefan that we need describe the digital signature bit
separate from the description of the non-repudiation bit in 509. Then it is
left to profiling groups, as it shoud be, what combinations of bits they
want set in their own environments.


Re the debate on changing the meaning - The reason we are having this
discussion (at least one of the reasons) is because the meaning of these
bits is not clear to many readers. Both the process of defect reports as
well as the enhancement process allows us to clarify text in the standard,
as well as to fix bugs etc). Part of the problem is that there isn't
agreement on what the original text meant, hence the clarification. Once
there is some sort of agreement on what the "right thing to do" is, then
we'll determine what the process is to achieve the intended result. That's
part of the reason why we are having the discussion before writing up a DR
or an enhancement request.


Sharon


Sharon Boeyen
Principal, Advanced Security
Tel: [phone]
www.entrust.com


Entrust, Inc.
Securing the Internet







------_=_NextPart_001_01C1F5F8.748F08B0
Content-Type: text/html

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=us-ascii">
<META NAME="Generator" CONTENT="MS Exchange Server version 5.5.2653.12">
<TITLE>RE: Meaning of Non-repudiation</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=2>Tom, I absolutely agree that this would be insufficient for non-repudiation. However,</FONT>
<BR><FONT SIZE=2>non-repudiation is not a technical operation, but a policy/legal one. This bit is only </FONT>
<BR><FONT SIZE=2>one very small component of non-repudiation. It is the CAs statement. The user's statement</FONT>
<BR><FONT SIZE=2>should be something that accompanies their signature. In the example you cite, perhaps in </FONT>
<BR><FONT SIZE=2>one environment, the policy dictates that all browser generated keys are solely to be used </FONT>
<BR><FONT SIZE=2>for online authentication of a user to a service and not for signatures that could be used</FONT>
<BR><FONT SIZE=2>in a non-repudiation context. In that environment, the policy would dictate that the CA set </FONT>
<BR><FONT SIZE=2>only the digital signature bit and not the non-repudiation bit, regardless of the fact that </FONT>
<BR><FONT SIZE=2>the CA hadn't seen the private key. In another environment, the policy might dictate that </FONT>
<BR><FONT SIZE=2>all client side generated private keys could be used for signatures in a non-repudiation </FONT>
<BR><FONT SIZE=2>context. In that particular environment the policy could dictate that the CA does set the </FONT>
<BR><FONT SIZE=2>non-repudiation bit. The policy would also dictate the key-usage bits that need to be set </FONT>
<BR><FONT SIZE=2>for the different types of operations a user performs (perhaps tied to specific local applications</FONT>
<BR><FONT SIZE=2>e.g. if signing a purchase order must use a key that has this bit set). So all the combinations</FONT>
<BR><FONT SIZE=2>would still be possible, but if the non-repudiation bit was set it would be purely a statement </FONT>
<BR><FONT SIZE=2>by the CA (as dictated by policy) that it did not generate and never had access to the private </FONT>
<BR><FONT SIZE=2>key. That is different that 'requiring' that the bit always be set if the CA didn't generate the </FONT>
<BR><FONT SIZE=2>key. Hope that helps.</FONT>
</P>

<P><FONT SIZE=2>Sharon</FONT>
</P>

<P><FONT SIZE=2>-----Original Message-----</FONT>
<BR><FONT SIZE=2>From: Tom Gindin [<A HREF="mailto:[e-mail]">mailto:[e-mail]</A>]</FONT>
<BR><FONT SIZE=2>Sent: Tuesday, May 07, 2002 1:32 PM</FONT>
<BR><FONT SIZE=2>To: Sharon Boeyen</FONT>
<BR><FONT SIZE=2>Cc: [e-mail]; 500 list (E-mail); Bill Burr (E-mail)</FONT>
<BR><FONT SIZE=2>Subject: Re: Meaning of Non-repudiation</FONT>
</P>
<BR>
<BR>

<P><FONT SIZE=2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Sharon:</FONT>
</P>

<P><FONT SIZE=2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; With all due respect, IMHO this would be a step backward because the</FONT>
<BR><FONT SIZE=2>condition is certainly not sufficient for an NR key.&nbsp; If a browser</FONT>
<BR><FONT SIZE=2>generated a key pair locally for authentication purposes, stored it on its</FONT>
<BR><FONT SIZE=2>local disk database, and submitted a PKCS#10 or CR requesting signatures</FONT>
<BR><FONT SIZE=2>for authentication it would meet this criterion.&nbsp; I don't know if this is</FONT>
<BR><FONT SIZE=2>even a necessary criterion, but it is certainly insufficient.</FONT>
</P>

<P><FONT SIZE=2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Tom Gindin</FONT>
</P>

<P><FONT SIZE=2>Sharon Boeyen &lt;[e-mail]&gt;@mail.imc.org on 05/07/2002</FONT>
<BR><FONT SIZE=2>09:28:23 AM</FONT>
</P>

<P><FONT SIZE=2>Sent by:&nbsp;&nbsp;&nbsp; [e-mail]</FONT>
</P>
<BR>

<P><FONT SIZE=2>To:&nbsp;&nbsp;&nbsp; [e-mail], &quot;500 list (E-mail)&quot; &lt;[e-mail]&gt;</FONT>
<BR><FONT SIZE=2>cc:&nbsp;&nbsp;&nbsp; &quot;Bill Burr (E-mail)&quot; &lt;[e-mail]&gt;</FONT>
<BR><FONT SIZE=2>Subject:&nbsp;&nbsp;&nbsp; Meaning of Non-repudiation</FONT>
</P>
<BR>

<P><FONT SIZE=2>I'd like to introduce another perspective on this topic, one that I really</FONT>
<BR><FONT SIZE=2>think helps add some fundamental clarity to the topic. During the US FPKI</FONT>
<BR><FONT SIZE=2>TWG meeting last week, this topic was raised and a short discussion was</FONT>
<BR><FONT SIZE=2>held. Bill Burr commented that he understood the meaning of the</FONT>
<BR><FONT SIZE=2>non-repudiation bit being set to be a statement by the certificate issuer</FONT>
<BR><FONT SIZE=2>(CA) that they at no point had any access to the private key corresponding</FONT>
<BR><FONT SIZE=2>to the public key being certified. I really like this because it states</FONT>
<BR><FONT SIZE=2>what role this bit plays in a non-repudiation context. It is simply that</FONT>
<BR><FONT SIZE=2>and nothing more. The remaining mechanisms for supporting a non-repudiation</FONT>
<BR><FONT SIZE=2>service are outside the scope of the definition of this bit. Legal and</FONT>
<BR><FONT SIZE=2>policy schemes can determine the behaviour of relying parties and users</FONT>
<BR><FONT SIZE=2>when this bit is set. The bit itself cannot do that. If an assertion that a</FONT>
<BR><FONT SIZE=2>user who signed something &quot;knew and intended to sign whatever&quot;, then that</FONT>
<BR><FONT SIZE=2>assertion should be something that accompanies a specific signature. This</FONT>
<BR><FONT SIZE=2>bit cannot be expected to act as that assertion.</FONT>
</P>
<BR>

<P><FONT SIZE=2>I also agree with Stefan that we need describe the digital signature bit</FONT>
<BR><FONT SIZE=2>separate from the description of the non-repudiation bit in 509. Then it is</FONT>
<BR><FONT SIZE=2>left to profiling groups, as it shoud be, what combinations of bits they</FONT>
<BR><FONT SIZE=2>want set in their own environments.</FONT>
</P>
<BR>

<P><FONT SIZE=2>Re the debate on changing the meaning - The reason we are having this</FONT>
<BR><FONT SIZE=2>discussion (at least one of the reasons) is because the meaning of these</FONT>
<BR><FONT SIZE=2>bits is not clear to many readers. Both the process of defect reports as</FONT>
<BR><FONT SIZE=2>well as the enhancement process allows us to clarify text in the standard,</FONT>
<BR><FONT SIZE=2>as well as to fix bugs etc). Part of the problem is that there isn't</FONT>
<BR><FONT SIZE=2>agreement on what the original text meant, hence the clarification. Once</FONT>
<BR><FONT SIZE=2>there is some sort of agreement on what the &quot;right thing to do&quot; is, then</FONT>
<BR><FONT SIZE=2>we'll determine what the process is to achieve the intended result. That's</FONT>
<BR><FONT SIZE=2>part of the reason why we are having the discussion before writing up a DR</FONT>
<BR><FONT SIZE=2>or an enhancement request.</FONT>
</P>
<BR>

<P><FONT SIZE=2>Sharon</FONT>
</P>
<BR>

<P><FONT SIZE=2>Sharon Boeyen</FONT>
<BR><FONT SIZE=2>Principal, Advanced Security</FONT>
<BR><FONT SIZE=2>Tel: [phone]</FONT>
<BR><FONT SIZE=2>www.entrust.com</FONT>
</P>
<BR>

<P><FONT SIZE=2>Entrust, Inc.</FONT>
<BR><FONT SIZE=2>Securing the Internet</FONT>
</P>
<BR>
<BR>
<BR>
<BR>
<BR>

</BODY>
</HTML>
------_=_NextPart_001_01C1F5F8.748F08B0--


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g47HYiY04094 for ietf-pkix-bks; Tue, 7 May 2002 10:34:44 -0700 (PDT)
Received: from e1.ny.us.ibm.com (e1.ny.us.ibm.com [32.97.182.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g47HYgL04088 for <[e-mail]>; Tue, 7 May 2002 10:34:42 -0700 (PDT)
Received: from northrelay02.pok.ibm.com (northrelay02.pok.ibm.com [9.56.224.150]) by e1.ny.us.ibm.com (8.12.2/8.12.2) with ESMTP id g47HVr6r102810; Tue, 7 May 2002 13:31:53 -0400
Received: from d01ml062.pok.ibm.com (d01ml062.pok.ibm.com [9.117.250.163]) by northrelay02.pok.ibm.com (8.11.1m3/NCO/VER6.1) with ESMTP id g47HVoc22496; Tue, 7 May 2002 13:31:50 -0400
Importance: Normal
Sensitivity: 
Subject: Re: Meaning of Non-repudiation
To: Sharon Boeyen <[e-mail]>
Cc: [e-mail], "500 list (E-mail)" <[e-mail]>, "Bill Burr (E-mail)" <[e-mail]>
X-Mailer: Lotus Notes Release 5.0.7  March 21, 2001
Message-ID: <[e-mail]>
From: "Tom Gindin" <[e-mail]>
Date: Tue, 7 May 2002 13:31:48 -0400
X-MIMETrack: Serialize by Router on D01ML062/01/M/IBM(Release 5.0.10 |March 28, 2002) at 05/07/2002 01:31:51 PM
MIME-Version: 1.0
Content-type: text/plain; charset=us-ascii
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

      Sharon:

      With all due respect, IMHO this would be a step backward because the
condition is certainly not sufficient for an NR key.  If a browser
generated a key pair locally for authentication purposes, stored it on its
local disk database, and submitted a PKCS#10 or CR requesting signatures
for authentication it would meet this criterion.  I don't know if this is
even a necessary criterion, but it is certainly insufficient.

            Tom Gindin

Sharon Boeyen <[e-mail]>@mail.imc.org on 05/07/2002
09:28:23 AM

Sent by:    [e-mail]


To:    [e-mail], "500 list (E-mail)" <[e-mail]>
cc:    "Bill Burr (E-mail)" <[e-mail]>
Subject:    Meaning of Non-repudiation


I'd like to introduce another perspective on this topic, one that I really
think helps add some fundamental clarity to the topic. During the US FPKI
TWG meeting last week, this topic was raised and a short discussion was
held. Bill Burr commented that he understood the meaning of the
non-repudiation bit being set to be a statement by the certificate issuer
(CA) that they at no point had any access to the private key corresponding
to the public key being certified. I really like this because it states
what role this bit plays in a non-repudiation context. It is simply that
and nothing more. The remaining mechanisms for supporting a non-repudiation
service are outside the scope of the definition of this bit. Legal and
policy schemes can determine the behaviour of relying parties and users
when this bit is set. The bit itself cannot do that. If an assertion that a
user who signed something "knew and intended to sign whatever", then that
assertion should be something that accompanies a specific signature. This
bit cannot be expected to act as that assertion.


I also agree with Stefan that we need describe the digital signature bit
separate from the description of the non-repudiation bit in 509. Then it is
left to profiling groups, as it shoud be, what combinations of bits they
want set in their own environments.


Re the debate on changing the meaning - The reason we are having this
discussion (at least one of the reasons) is because the meaning of these
bits is not clear to many readers. Both the process of defect reports as
well as the enhancement process allows us to clarify text in the standard,
as well as to fix bugs etc). Part of the problem is that there isn't
agreement on what the original text meant, hence the clarification. Once
there is some sort of agreement on what the "right thing to do" is, then
we'll determine what the process is to achieve the intended result. That's
part of the reason why we are having the discussion before writing up a DR
or an enhancement request.


Sharon


Sharon Boeyen
Principal, Advanced Security
Tel: [phone]
www.entrust.com


Entrust, Inc.
Securing the Internet









Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g47HTmd03931 for ietf-pkix-bks; Tue, 7 May 2002 10:29:48 -0700 (PDT)
Received: from nymelsmtp.internet.ny.fdms.firstdata.com ([204.124.248.17]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g47HTkL03921 for <[e-mail]>; Tue, 7 May 2002 10:29:46 -0700 (PDT)
Subject: Re: Meaning of Non-repudiation
To: Sharon Boeyen <[e-mail]>
Cc: [e-mail], "500 list (E-mail)" <[e-mail]>, [e-mail], "Bill Burr (E-mail)" <[e-mail]>
X-Mailer: Lotus Notes Release 5.0.5  September 22, 2000
Message-ID: <[e-mail]>
From: [e-mail]
Date: Tue, 7 May 2002 11:28:19 -0600
X-MIMETrack: Serialize by Router on NYMELSMTP/NY/FDMS/FDC(Release 5.0.8 |June 18, 2001) at 05/07/2002 01:26:45 PM
MIME-Version: 1.0
Content-type: text/plain; charset=us-ascii
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

so the bit in the certificate just means that the CA dsavows all knowledge
of the private key ... aka "private key not divulged".

then possibly if it can be prooven that the private key was also not
divulged to anybody else ... then some conditions for meeting
non-repudiation requirements might be met (i.e. a CA not having knowledge
of the private key is several steps removed from non-repudiation).

as aside ... definition for "non-repudation" (from nsa intrustion glossary)
and "non-repudation sevice" (from rfc2828) are in merged security glossary:
http://www.garlic.com/~lynn/security.htm

... quick path is to click on "PAIN" in acronym fastpath ... and then click
on "non-repudiation".




<[e-mail]> on 5/7/2002 7:28 am wrote:
                                                                                   
                                                                                   
                                                                                   




I'd like to introduce another perspective on this topic, one that I really
think helps add some fundamental clarity to the topic. During the US FPKI
TWG meeting last week, this topic was raised and a short discussion was
held. Bill Burr commented that he understood the meaning of the
non-repudiation bit being set to be a statement by the certificate issuer
(CA) that they at no point had any access to the private key corresponding
to the public key being certified. I really like this because it states
what role this bit plays in a non-repudiation context. It is simply that
and nothing more. The remaining mechanisms for supporting a non-repudiation
service are outside the scope of the definition of this bit. Legal and
policy schemes can determine the behaviour of relying parties and users
when this bit is set. The bit itself cannot do that. If an assertion that a
user who signed something "knew and intended to sign whatever", then that
assertion should be something that accompanies a specific signature. This
bit cannot be expected to act as that assertion.


I also agree with Stefan that we need describe the digital signature bit
separate from the description of the non-repudiation bit in 509. Then it is
left to profiling groups, as it shoud be, what combinations of bits they
want set in their own environments.


Re the debate on changing the meaning - The reason we are having this
discussion (at least one of the reasons) is because the meaning of these
bits is not clear to many readers. Both the process of defect reports as
well as the enhancement process allows us to clarify text in the standard,
as well as to fix bugs etc). Part of the problem is that there isn't
agreement on what the original text meant, hence the clarification. Once
there is some sort of agreement on what the "right thing to do" is, then
we'll determine what the process is to achieve the intended result. That's
part of the reason why we are having the discussion before writing up a DR
or an enhancement request.


Sharon


Sharon Boeyen
Principal, Advanced Security
Tel: [phone]
www.entrust.com


Entrust, Inc.
Securing the Internet












Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g47Ex9P26568 for ietf-pkix-bks; Tue, 7 May 2002 07:59:09 -0700 (PDT)
Received: from mail.utfors.se (mail.utfors.se [195.58.103.125]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g47Ex8L26563 for <[e-mail]>; Tue, 7 May 2002 07:59:08 -0700 (PDT)
Received: from arport ([62.119.75.13]) by mail.utfors.se (8.8.8/8.8.8) with SMTP id QAA05753; Tue, 7 May 2002 16:58:56 +0200 (MET DST)
Message-ID: <00a601c1f5df$ac8257e0$0500a8c0@arport>
From: "Anders Rundgren" <[e-mail]>
To: "Sharon Boeyen" <[e-mail]>, <[e-mail]>
Cc: "Bill Burr \(E-mail\)" <[e-mail]>
References: <[e-mail]>
Subject: Re: Meaning of Non-repudiation
Date: Tue, 7 May 2002 17:55:55 +0200
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_00A1_01C1F5F0.6F601AD0"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.50.4133.2400
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

This is a multi-part message in MIME format.

------=_NextPart_000_00A1_01C1F5F0.6F601AD0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Meaning of Non-repudiationSharon,

  I'd like to introduce another perspective on this topic, one that I =
really think helps add some fundamental clarity to the topic. During the =
US FPKI TWG meeting last week, this topic was raised and a short =
discussion was held. Bill Burr commented that he understood the meaning =
of the non-repudiation bit being set to be a statement by the =
certificate issuer (CA) that they at no point had any access to the =
private key corresponding to the public key being certified. I really =
like this because it states what role this bit plays in a =
non-repudiation context. It is simply that and nothing more.
An interesting definition indeed.  Being deeply involved in server-based =
PKI, where a portal "CA" and portal "clients" may live in full symbiosis =
including access to private keys, I note that it would mean that it =
would be an error to set the NR-bit in such systems.  Therefore I feel =
some "bad vibes" to this definition of what an NR-bit really is.  But =
OTOH the "granularity" in the e-commerce world is not that great, so it =
probably just a no-issue. :-)

cheers,
Anders

------=_NextPart_000_00A1_01C1F5F0.6F601AD0
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>Meaning of Non-repudiation</TITLE>
<META content=3D"text/html; charset=3Diso-8859-1" =
http-equiv=3DContent-Type>
<META content=3D"MSHTML 5.00.3103.1000" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY background=3D"" bgColor=3D#ffffff>
<DIV><FONT size=3D2><FONT face=3DArial>Sharon,</FONT></FONT></DIV>
<BLOCKQUOTE style=3D"MARGIN-RIGHT: 0px">
  <DIV><FONT size=3D2><FONT face=3DArial><BR><FONT color=3D#0000ff>I'd =
like to=20
  introduce another perspective on this topic, one that I really think =
helps add=20
  some fundamental clarity to the topic. During the US FPKI TWG meeting =
last=20
  week, this topic was raised and a short discussion was held. Bill Burr =

  commented that he understood the meaning of the non-repudiation bit =
being set=20
  to be a statement by the certificate issuer (CA) that they at no point =
had any=20
  access to the private key corresponding to the public key being =
certified. I=20
  really like this because it states what role this bit plays in a=20
  non-repudiation context. It is simply that and nothing=20
  more.</FONT></FONT></FONT></DIV></BLOCKQUOTE>
<DIV><FONT face=3DArial size=3D2>An interesting definition indeed.&nbsp; =

Being&nbsp;deeply involved in server-based PKI, where&nbsp;a portal "CA" =
and=20
portal "clients"&nbsp;may live in full symbiosis including access to =
private=20
keys, I&nbsp;note that it would mean that it would be an error to set =
the NR-bit=20
in such systems.&nbsp; Therefore I feel some&nbsp;"bad vibes" to this =
definition=20
of what an NR-bit really is.&nbsp; But OTOH the "granularity" in the =
e-commerce=20
world&nbsp;is not that great, so it probably just&nbsp;a no-issue.=20
:-)</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>cheers,</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>Anders</FONT></DIV></BODY></HTML>

------=_NextPart_000_00A1_01C1F5F0.6F601AD0--



Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g47EoGZ26289 for ietf-pkix-bks; Tue, 7 May 2002 07:50:16 -0700 (PDT)
Received: from stingray.missi.ncsc.mil (stingray.missi.ncsc.mil [144.51.50.20]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g47EoDL26284 for <[e-mail]>; Tue, 7 May 2002 07:50:13 -0700 (PDT)
Received: from stingray.missi.ncsc.mil (root@localhost) by stingray.missi.ncsc.mil with ESMTP id g47El6128838 for <[e-mail]>; Tue, 7 May 2002 10:47:06 -0400 (EDT)
Message-ID: <[e-mail]>
Date: Tue, 07 May 2002 10:49:45 -0400
From: "David P. Kemp" <[e-mail]>
X-Mailer: Mozilla 4.77 [en] (X11; U; SunOS 5.7 sun4u)
X-Accept-Language: en
MIME-Version: 1.0
To: [e-mail]
Subject: Words, Books, and Key Usage
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms97040F6CCB66C157546369A3"
X-H-S-Loop-Check-Ejzfr: 
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

This is a cryptographically signed message in MIME format.

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


    "Fiction - A literary work whose content is produced by
     the imagination and is not necessarily based on fact."

    "Non-fiction - Prose works other than fiction."

          -- www.dictionary.com


Trevor Freeman wrote:
> Santosh,
> Stop the spin doctoring ...
> 
> I really don't care which course you choose to achieve your 
> objective, but you cannot redefine the semantics of the
> existing key usage extension and retain the same identifier.

The problem is not semantics being redefined, the problem is that
many thoughtful people have been trying to figure out, without
success, the semantics of an ill-structured specification.

Consider the parts of speech: nouns, verbs, adjectives, etc.
Then X.509, if applied to the English language, might read:

  Bits in the WordUsage type are as follows:
   a) word: for words that have purposes other than those
      identified in b, f, or g below;
   b) nonFiction: for words used in non-fiction whose content
      is fact-based prose (excluding verbs and adverbs, as in
      f or g below);
   ...
   f) verb: for words that express existence, action,
      or occurrence;
   g) adverb: for words that modify a verb, adjective,
      or other adverb;
   

As many others have observed, the problem with key usage
is not semantic, it is structural - non-repudiation is
not something that can be provided by a certificate or
certain type of signature, it is provided by a system.
As Peter Williams rightly observed some time ago, and you
recently repeated, even SSL can play a role in supporting
some forms of non-repudiation systems.  

Even though signed objects are more commonly associated with
non-repudiation than are signed challenges, and adjectives
are more common in novels than in technical papers, there is
no one-to-one correspondence.  Calling "non-repudiation"
a key usage is as structurally flawed as calling
"non-fiction" a part of speech.  They belong to two
entirely different taxonomies.

The first step to recovery is admitting that something
is wrong.  I believe there is universal recognition and
consensus that non-repudiation is a different *kind* of
thing than certificate signing, key agreement, and
data encipherment, and that the resulting confusion
is a problem for product developers, lawyers, and users
alike.

The next step is to believe that the problem can be
fixed, and make a decision to fix it.  We're not there
yet.  But if we ever resolve to do more than talk about
it, we will find that a certain amount of semantic
redefinition is necessary -- you can't gain coherence
by retaining 100% compatibility with an incoherent
definition.

Even the ancients were smart enough to know that
the fundamental building blocks of the universe
are NOT "Earth", "Fire", "Elements Used in a Cave",
and "All Elements Except Earth, Fire, and those
used in a Cave".

Regards,
Dave
--------------ms97040F6CCB66C157546369A3
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

MIIOhgYJKoZIhvcNAQcCoIIOdzCCDnMCAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC
DIkwggQxMIIDmqADAgECAgMDOtQwDQYJKoZIhvcNAQEFBQAwZDELMAkGA1UEBhMCVVMxGDAW
BgNVBAoTD1UuUy4gR292ZXJubWVudDEMMAoGA1UECxMDRG9EMQwwCgYDVQQLEwNQS0kxHzAd
BgNVBAMTFkRPRCBDTEFTUyAzIEVNQUlMIENBLTMwHhcNMDIwNDI1MTQ1ODQyWhcNMDUwNDI1
MTQ1ODQyWjB3MQswCQYDVQQGEwJVUzEYMBYGA1UEChMPVS5TLiBHb3Zlcm5tZW50MQwwCgYD
VQQLEwNEb0QxDDAKBgNVBAsTA1BLSTEQMA4GA1UECxMHTlNBL0NTUzEgMB4GA1UEAxMXS2Vt
cC5EYXZpZC5QLjA1MTQxMDE0MDQwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAOrsDFPo
087+VZ15OuyrJedIwjkRXWrtqRBzEpkk6Ct+Bkn/uiKzLn7AZ5IxbGDnZvjbvmEzPYkA/tm8
ng0IVxNpKEjdw7O1TbNLnwLSDkckcmq8AzW6se/Dm5nZ7l3ggVx8XuYifnr9E163atD9JxjR
nVM1vcPx262lVck4wTXrAgMBAAGjggHcMIIB2DAOBgNVHQ8BAf8EBAMCBsAwHwYDVR0jBBgw
FoAU7BNbvCGMZpsKi38HXyWwFPkQ9ZswHQYDVR0OBBYEFIs+vTwgtAcXc7Wa3lN5TOdFB2v4
MBYGA1UdIAQPMA0wCwYJYIZIAWUCAQsFMCAGA1UdEQQZMBeBFWRwa2VtcEBtaXNzaS5uY3Nj
Lm1pbDCBjwYDVR0SBIGHMIGEhoGBbGRhcDovL2VtYWlsLWRzLTMuYzNwa2kuY2hhbWIuZGlz
YS5taWwvY24lM2RET0QlMjBDTEFTUyUyMDMlMjBFTUFJTCUyMENBLTMlMmNvdSUzZFBLSSUy
Y291JTNkRG9EJTJjbyUzZFUuUy4lMjBHb3Zlcm5tZW50JTJjYyUzZFVTMIG5BgNVHR8EgbEw
ga4wgauggaiggaWGgaJsZGFwOi8vZW1haWwtZHMtMy5jM3BraS5jaGFtYi5kaXNhLm1pbC9j
biUzZERPRCUyMENMQVNTJTIwMyUyMEVNQUlMJTIwQ0EtMyUyY291JTNkUEtJJTJjb3UlM2RE
b0QlMmNvJTNkVS5TLiUyMEdvdmVybm1lbnQlMmNjJTNkVVM/Y2VydGlmaWNhdGVyZXZvY2F0
aW9ubGlzdDtiaW5hcnkwDQYJKoZIhvcNAQEFBQADgYEA0kEbsqISaLdMPsBZSuefbL8k2fU2
V6nAVrq890J8s7Sf2vlm+Z9SkRqo+KebaeHRCS8Pg5S8YhxRHz6jmvGV9+CqOBhJp/DsW2Iu
tHXUMy46iPxLQfFT75LIjOAGXk929TSgnqk/3ygIVP6/E+6culxD7hTKh4FFa/Dto/V4T6ww
ggQbMIIDhKADAgECAgETMA0GCSqGSIb3DQEBBQUAMGExCzAJBgNVBAYTAlVTMRgwFgYDVQQK
Ew9VLlMuIEdvdmVybm1lbnQxDDAKBgNVBAsTA0RvRDEMMAoGA1UECxMDUEtJMRwwGgYDVQQD
ExNEb0QgQ0xBU1MgMyBSb290IENBMB4XDTAwMDgxMTE3NDUyOVoXDTA2MDgxMDE3NDUyOVow
ZDELMAkGA1UEBhMCVVMxGDAWBgNVBAoTD1UuUy4gR292ZXJubWVudDEMMAoGA1UECxMDRG9E
MQwwCgYDVQQLEwNQS0kxHzAdBgNVBAMTFkRPRCBDTEFTUyAzIEVNQUlMIENBLTMwgZ8wDQYJ
KoZIhvcNAQEBBQADgY0AMIGJAoGBAO98vchr6/EuN4Vw2h1ovziIBzOml88LKtiNQxMFN07J
V04JFR2kZtuOxlCcvNnL2fXv9lRG4teiwqBldt36ekVY/1LDkW6xDecvHnS4BuJhQPnmMdnu
HF47TwK7O/bxvevAKpKeS1/sw1wuyKJN9Bi7jezH36gY+CdT9VwfP4QJAgMBAAGjggHeMIIB
2jAdBgNVHQ4EFgQU7BNbvCGMZpsKi38HXyWwFPkQ9ZswDgYDVR0PAQH/BAQDAgGGMA8GA1Ud
EwEB/wQFMAMBAf8wDAYDVR0kBAUwA4ABADAfBgNVHSMEGDAWgBRsnKXwXI9tQY3EFzuQV8IP
o81t/jAwBgNVHSAEKTAnMAsGCWCGSAFlAgELBTALBglghkgBZQIBCwkwCwYJYIZIAWUCAQsK
MIGDBgNVHRIEfDB6hnhsZGFwOi8vZHMtMy5jM3BraS5jaGFtYi5kaXNhLm1pbC9jbiUzZERv
RCUyMENMQVNTJTIwMyUyMFJvb3QlMjBDQSUyY291JTNkUEtJJTJjb3UlM2REb0QlMmNvJTNk
VS5TLiUyMEdvdmVybm1lbnQlMmNjJTNkVVMwgbAGA1UdHwSBqDCBpTCBoqCBn6CBnIaBmWxk
YXA6Ly9kcy0zLmMzcGtpLmNoYW1iLmRpc2EubWlsL2NuJTNkRG9EJTIwQ0xBU1MlMjAzJTIw
Um9vdCUyMENBJTJjb3UlM2RQS0klMmNvdSUzZERvRCUyY28lM2RVLlMuJTIwR292ZXJubWVu
dCUyY2MlM2RVUz9jZXJ0aWZpY2F0ZXJldm9jYXRpb25saXN0O2JpbmFyeTANBgkqhkiG9w0B
AQUFAAOBgQAmpY01OHZr/vRBJsgxGUX7diGsCGrzYM1C0fhrJknH4L7Lm61Nt1bSZ4/obHjl
QxBQyDx9ovISBAi//TVUd1UKbdqNW7Inso2enmK9beG9eK5M0ZfEdj3S0UxmJAgRXSgVsnE7
xzP3uZ1/mJx++gSwcpd+/NPBVJNjFJPf8RvL4DCCBDEwggOaoAMCAQICAwM61jANBgkqhkiG
9w0BAQUFADBkMQswCQYDVQQGEwJVUzEYMBYGA1UEChMPVS5TLiBHb3Zlcm5tZW50MQwwCgYD
VQQLEwNEb0QxDDAKBgNVBAsTA1BLSTEfMB0GA1UEAxMWRE9EIENMQVNTIDMgRU1BSUwgQ0Et
MzAeFw0wMjA0MjUxNDU5NDZaFw0wNTA0MjUxNDU5NDZaMHcxCzAJBgNVBAYTAlVTMRgwFgYD
VQQKEw9VLlMuIEdvdmVybm1lbnQxDDAKBgNVBAsTA0RvRDEMMAoGA1UECxMDUEtJMRAwDgYD
VQQLEwdOU0EvQ1NTMSAwHgYDVQQDExdLZW1wLkRhdmlkLlAuMDUxNDEwMTQwNDCBnzANBgkq
hkiG9w0BAQEFAAOBjQAwgYkCgYEApfaxUWfMcxUPKtb9p7FeItF5DkWiDmO8i0uiC0VpUPoz
t+9gx4pUo4lOeqcSGMRfFwv7llBtPte7NqtbDefDW2tIFIzzFrv07VPrq0MNCo6rRK/IGCK/
Zmrf/UOfx8Hzvn6dIF+S9YktXZsFpbtJT49v6+E2nmKLpO7OCtW582kCAwEAAaOCAdwwggHY
MA4GA1UdDwEB/wQEAwIFIDAfBgNVHSMEGDAWgBTsE1u8IYxmmwqLfwdfJbAU+RD1mzAdBgNV
HQ4EFgQUYrtZ7SslM3nXtC47SpLr4YEu02AwFgYDVR0gBA8wDTALBglghkgBZQIBCwUwIAYD
VR0RBBkwF4EVZHBrZW1wQG1pc3NpLm5jc2MubWlsMIGPBgNVHRIEgYcwgYSGgYFsZGFwOi8v
ZW1haWwtZHMtMy5jM3BraS5jaGFtYi5kaXNhLm1pbC9jbiUzZERPRCUyMENMQVNTJTIwMyUy
MEVNQUlMJTIwQ0EtMyUyY291JTNkUEtJJTJjb3UlM2REb0QlMmNvJTNkVS5TLiUyMEdvdmVy
bm1lbnQlMmNjJTNkVVMwgbkGA1UdHwSBsTCBrjCBq6CBqKCBpYaBomxkYXA6Ly9lbWFpbC1k
cy0zLmMzcGtpLmNoYW1iLmRpc2EubWlsL2NuJTNkRE9EJTIwQ0xBU1MlMjAzJTIwRU1BSUwl
MjBDQS0zJTJjb3UlM2RQS0klMmNvdSUzZERvRCUyY28lM2RVLlMuJTIwR292ZXJubWVudCUy
Y2MlM2RVUz9jZXJ0aWZpY2F0ZXJldm9jYXRpb25saXN0O2JpbmFyeTANBgkqhkiG9w0BAQUF
AAOBgQDIzhLKkB3qMsN45svSI+hEJN0hjuhiz7hGNFOUco1YnyoyfwvShlJHrl85ptr9mt/L
hMuLunqBCS2tfTKTLWAK9RjR20MRI7evK0qu/OxpxfMI9TFPwHPXSOINrgILbIVvuwOkIYcm
IBcfD2OReXE7+WcRoZDUjZGD4X+80lIm4jGCAcUwggHBAgEBMGswZDELMAkGA1UEBhMCVVMx
GDAWBgNVBAoTD1UuUy4gR292ZXJubWVudDEMMAoGA1UECxMDRG9EMQwwCgYDVQQLEwNQS0kx
HzAdBgNVBAMTFkRPRCBDTEFTUyAzIEVNQUlMIENBLTMCAwM61DAJBgUrDgMCGgUAoIGxMBgG
CSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTAyMDUwNzE0NDk0NVow
IwYJKoZIhvcNAQkEMRYEFBV1B79qEt2zWQQZo+b3tJJU3tPDMFIGCSqGSIb3DQEJDzFFMEMw
CgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgFAMA0G
CCqGSIb3DQMCAgEoMA0GCSqGSIb3DQEBAQUABIGAZnf4JfGIallBq9GFT6PmGmfZy2SSkMAd
PGcE8gAO6x1tLKvN6czuSpIQEFwAFqj7/cM9ROJ8bqlFB405KuQOk9G0Rn1rt1CXQqIYKoZx
lmNY7XglKY4I02wh8cnnNdi8Tsb+rB37NeDR+9Tl56ImoJeSBH38D+/LsJ05muc3PWc=
--------------ms97040F6CCB66C157546369A3--



Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g47DSZ322868 for ietf-pkix-bks; Tue, 7 May 2002 06:28:35 -0700 (PDT)
Received: from SOTTMXS01.entrust.com (mail.entrust.com [216.191.251.35]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g47DSXL22863 for <[e-mail]>; Tue, 7 May 2002 06:28:33 -0700 (PDT)
Received: by SOTTMXS01.entrust.com with Internet Mail Service (5.5.2653.19) id <K3ZD40HH>; Tue, 7 May 2002 09:28:24 -0400
Message-ID: <[e-mail]>
From: Sharon Boeyen <[e-mail]>
To: [e-mail], "500 list (E-mail)" <[e-mail]>
Cc: "Bill Burr (E-mail)" <[e-mail]>
Subject: Meaning of Non-repudiation
Date: Tue, 7 May 2002 09:28:23 -0400 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1F5CB.0FC0E2F0"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

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

I'd like to introduce another perspective on this topic, one that I really
think helps add some fundamental clarity to the topic. During the US FPKI
TWG meeting last week, this topic was raised and a short discussion was
held. Bill Burr commented that he understood the meaning of the
non-repudiation bit being set to be a statement by the certificate issuer
(CA) that they at no point had any access to the private key corresponding
to the public key being certified. I really like this because it states what
role this bit plays in a non-repudiation context. It is simply that and
nothing more. The remaining mechanisms for supporting a non-repudiation
service are outside the scope of the definition of this bit. Legal and
policy schemes can determine the behaviour of relying parties and users when
this bit is set. The bit itself cannot do that. If an assertion that a user
who signed something "knew and intended to sign whatever", then that
assertion should be something that accompanies a specific signature. This
bit cannot be expected to act as that assertion. 

I also agree with Stefan that we need describe the digital signature bit
separate from the description of the non-repudiation bit in 509. Then it is
left to profiling groups, as it shoud be, what combinations of bits they
want set in their own environments.  

Re the debate on changing the meaning - The reason we are having this
discussion (at least one of the reasons) is because the meaning of these
bits is not clear to many readers. Both the process of defect reports as
well as the enhancement process allows us to clarify text in the standard,
as well as to fix bugs etc). Part of the problem is that there isn't
agreement on what the original text meant, hence the clarification. Once
there is some sort of agreement on what the "right thing to do" is, then
we'll determine what the process is to achieve the intended result. That's
part of the reason why we are having the discussion before writing up a DR
or an enhancement request.

Sharon

Sharon Boeyen
Principal, Advanced Security
Tel: [phone] 
www.entrust.com

Entrust, Inc.
Securing the Internet



------_=_NextPart_001_01C1F5CB.0FC0E2F0
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.2653.12">
<TITLE>Meaning of Non-repudiation</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=3D2 FACE=3D"Arial">I'd like to introduce another =
perspective on this topic, one that I really think helps add some =
fundamental clarity to the topic. During the US FPKI TWG meeting last =
week, this topic was raised and a short discussion was held. Bill Burr =
commented that he understood the meaning of the non-repudiation bit =
being set to be a statement by the certificate issuer (CA) that they at =
no point had any access to the private key corresponding to the public =
key being certified. I really like this because it states what role =
this bit plays in a non-repudiation context. It is simply that and =
nothing more. The remaining mechanisms for supporting a non-repudiation =
service are outside the scope of the definition of this bit. Legal and =
policy schemes can determine the behaviour of relying parties and users =
when this bit is set. The bit itself cannot do that. If an assertion =
that a user who signed something &quot;knew and intended to sign =
whatever&quot;, then that assertion should be something that =
accompanies a specific signature. This bit cannot be expected to act as =
that assertion. </FONT></P>

<P><FONT SIZE=3D2 FACE=3D"Arial">I also agree with Stefan that we need =
describe the digital signature bit separate from the description of the =
non-repudiation bit in 509. Then it is left to profiling groups, as it =
shoud be, what combinations of bits they want set in their own =
environments.&nbsp; </FONT></P>

<P><FONT SIZE=3D2 FACE=3D"Arial">Re the debate on changing the meaning =
- The reason we are having this discussion (at least one of the =
reasons) is because the meaning of these bits is not clear to many =
readers. Both the process of defect reports as well as the enhancement =
process allows us to clarify text in the standard, as well as to fix =
bugs etc). Part of the problem is that there isn't agreement on what =
the original text meant, hence the clarification. Once there is some =
sort of agreement on what the &quot;right thing to do&quot; is, then =
we'll determine what the process is to achieve the intended result. =
That's part of the reason why we are having the discussion before =
writing up a DR or an enhancement request.</FONT></P>

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

<P><FONT SIZE=3D2 FACE=3D"Courier New">Sharon Boeyen</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Courier New">Principal, Advanced =
Security</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Courier New">Tel: [phone] </FONT>
<BR><FONT SIZE=3D2 FACE=3D"Courier New">www.entrust.com</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Courier New">Entrust, Inc.</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Courier New">Securing the Internet</FONT>
</P>
<BR>

</BODY>
</HTML>
------_=_NextPart_001_01C1F5CB.0FC0E2F0--


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g470Zdb10227 for ietf-pkix-bks; Mon, 6 May 2002 17:35:39 -0700 (PDT)
Received: from mail5.microsoft.com (mail5.microsoft.com [131.107.3.121]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g470ZbL10219 for <[e-mail]>; Mon, 6 May 2002 17:35:37 -0700 (PDT)
Received: from inet-vrs-05.redmond.corp.microsoft.com ([157.54.6.148]) by mail5.microsoft.com with Microsoft SMTPSVC(5.0.2195.4905); Mon, 6 May 2002 17:35:35 -0700
Received: from 157.54.8.155 by inet-vrs-05.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Mon, 06 May 2002 17:35:35 -0700
Received: from red-imc-04.redmond.corp.microsoft.com ([157.54.2.168]) by inet-hub-04.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.4905); Mon, 6 May 2002 17:35:35 -0700
Received: from win-imc-02.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.84]) by red-imc-04.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.2966); Mon, 6 May 2002 17:35:35 -0700
Received: from win-msg-01.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.52]) by win-imc-02.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3590.0); Mon, 6 May 2002 17:35:34 -0700
X-MimeOLE: Produced By Microsoft Exchange V6.0.6177.0
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Subject: RE: Redefining the Key Usage bits 0 and 1
Date: Mon, 6 May 2002 17:31:40 -0700
Message-ID: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: Redefining the Key Usage bits 0 and 1
Thread-Index: AcH1WIrIiqmZDWNjQJadiil6gZscAwAAnfIQ
From: "Trevor Freeman" <[e-mail]>
To: "Santosh Chokhani" <[e-mail]>
Cc: <[e-mail]>
X-OriginalArrivalTime: 07 May 2002 00:35:34.0638 (UTC) FILETIME=[19C8E8E0:01C1F55F]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id g470ZbL10220
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

I think the question you need to ask is which of the four scenarios you outlines are inconstant with the current RFC of topic. The RFC also make no dependencies between the two bits other than via the certificate policies extension and the only thing excluded from being signed when bit 0 is asserted is signing certs and CRLs.
Therfore only scenario 1 listed below is consistent with the RFC as drafted.

Trevor

-----Original Message-----
From: Santosh Chokhani [mailto:[e-mail]] 
Sent: Monday, May 06, 2002 4:54 PM
To: Trevor Freeman
Cc: [e-mail]
Subject: RE: Redefining the Key Usage bits 0 and 1

Trevor:

This is likely to be my last e-mail on the topic.  I do not mean to
belabor the point.  But, which of the four scenarios are out of line
with current implementations?

-----Original Message-----
From: Trevor Freeman [mailto:[e-mail]] 
Sent: Monday, May 06, 2002 1:22 AM
To: Santosh Chokhani
Cc: [e-mail]
Subject: Redefining the Key Usage bits 0 and 1


Santosh,
Stop the spin doctoring semantic examples. We are not talking about NR
here. You are proposing redefining the scope of the key usage bits 0 and
1. That is changing semantics. If you truly want to express this kind of
policy in certificates, that is fine and a reasonable request, and you
have several courses of action open to you.
1) Define the new semantics for use in an extension of identical
structure to the existing key usage extension but use a different OID to
identify the extension.
2) Define new OIDs for use with the EKU extension.
3) Define an entirely new extension.
4) Define a new policy qualifier (Russ will love that option)

I really don't care which course you choose to achieve your objective,
but you cannot redefine the semantics of the existing key usage
extension and retain the same identifier. That course of action as they
say is a dead parrot. It is deceased. It is no alive. It is kaput. It
will not fly. It is pushing up daises. Get the picture.

Trevor 

-----Original Message-----
From: Santosh Chokhani [mailto:[e-mail]] 
Sent: Saturday, May 04, 2002 6:16 AM
To: Trevor Freeman
Cc: [e-mail]
Subject: RE: Meaning of Non-repudiation

Trevor:

I am not trying to define new mechanisms.  I am simply suggesting how to
differentiate between the two bits that has some technical meaning.  If
you know of any technical meaning between the two bits, let me know.

Compliant implementations that set both bits so that the same key is
used for signing data and signing challenges can continue to do so.

Thus, in order to validate if I am changing the semantics of the
implementation and/or if my proposal will fly in the face of backward
compatibility, we need to determine how the current implementations use
the two bits.

Let us call NR bit bit A and DS bit bit B.

You are welcome to show how you interpret the bits.  What I am proposing
is as follows:

A = 0, B = 0 => The public key may not be used to verify signature on
data on random challenges.

A = 1, B = 0 => The public key may be used to verify signature on data,
but not on random challenges.

A = 0, B = 1 => The public key may not be used to verify signature on
data, but can be used to verify signature on random challenges.

A = 1, B = 1 => The public key may be used to verify signature on data
and can be used to verify signature on random challenges.

I suspect of these, case "c" may be the most controversial, if any.  How
many implementations use case c and use the public key to verify the
signature on data?

-----Original Message-----
From: Trevor Freeman [mailto:[e-mail]] 
Sent: Friday, May 03, 2002 8:21 PM
To: Santosh Chokhani
Cc: [e-mail]
Subject: RE: Meaning of Non-repudiation


Santosh,
Your suggestion is not backwards compatible with the exiting standard.
If you want to introduce new ways to further restrict what can be signed
with a digital signature key then I suggest you look to the existing key
usage extension mechanisms and if you still want to define a new
mechanism justify why since those extension mechanisms are inadequate
since they were designed for such a purpose. Changing the existing
semantics of existing extensions is out of scope no matter how
inadequate those semantics may seem. Trevor



-----Original Message-----
From: Santosh Chokhani [mailto:[e-mail]] 
Sent: Friday, May 03, 2002 3:07 PM
To: Trevor Freeman; [e-mail]; 'Omer Hasret'
Cc: [e-mail]
Subject: RE: Meaning of Non-repudiation

Trevor:

How am I changing the semantics of the extension?  The extension is used
for defining which of the security services the key pair can be used
for.  I am adhere to that.  All I am doing is giving some useful
distinction between DS and NR.

If you are saying that I am providing a meaningful distinction between
the two bits and that distinction may not be backward compatible with
some commercial products, I agree.

-----Original Message-----
From: [e-mail] [mailto:[e-mail]]
On Behalf Of Trevor Freeman
Sent: Friday, May 03, 2002 4:14 PM
To: Santosh Chokhani; [e-mail]; Omer Hasret
Cc: [e-mail]
Subject: RE: Meaning of Non-repudiation



Santosh,
Either you are proposing changing the semantics of the existing
definition of the key usage extension, or you are advocating a policy
which may be implanted. The first is a none starter - you don't change
the semantics of existing extensions. The second is perfectly acceptable
policy that you may want follow, but is not mandatory on all parties.
Trevor

-----Original Message-----
From: Santosh Chokhani [mailto:[e-mail]] 
Sent: Friday, May 03, 2002 10:56 AM
To: [e-mail]; 'Omer Hasret'
Cc: [e-mail]
Subject: RE: Meaning of Non-repudiation


I think EKU provide application specific refinement, e.g., code signing.

But, key usage has the basic operations.  The distinction between
signing a challenge and data that you take some ownership to belongs in
key usage.

-----Original Message-----
From: [e-mail] [mailto:[e-mail]]
On Behalf Of [e-mail]
Sent: Friday, May 03, 2002 9:43 AM
To: Omer Hasret
Cc: 'Santosh Chokhani'; [e-mail]
Subject: RE: Meaning of Non-repudiation






"Extended Key Usage" is meant for that purpose, isn't it ? Or "Policy
Identifier" could provide this kind of information.
|------------------------+------------------------+---------------------
---|
|                        |   "Omer Hasret"        |
|
|                        |   <[e-mail]>  |           To:
|
|                        |                        |
<Olaf.Schlueter@secar|
|                        |   03.05.2002 14:53     |   tis.com>,
|
|                        |                        |
<[e-mail]>  |
|                        |                        |           cc:
|
|                        |                        |   "'Santosh
Chokhani'" |
|                        |                        |
<[e-mail]|
|                        |                        |   m>
|
|                        |                        |           Subject:
|
|                        |                        |   RE: Meaning of
|
|                        |                        |   Non-repudiation
|
|------------------------+------------------------+---------------------
---|








Olaf,

See below,

> -----Original Message-----
> From: [e-mail]
> [mailto:[e-mail]] On Behalf Of 
> [e-mail]
> Sent: vendredi 3 mai 2002 12:43
> To: [e-mail]
> Cc: 'Santosh Chokhani'; [e-mail];
> [e-mail]; 'Trevor Freeman'
> Subject: RE: Meaning of Non-repudiation
>
>
>
>
>
>
> The NR bit in a certifiicate does not proof anything. It is a
> statement made by the signer and/or the CA about the intended use of 
> the key. KeyUsage bits are currently used to support key pair 
> separation for the three basic use cases of public key cryptography: 
> encryption, authentication and digital signing. Most application 
> choose public key certificates needed for a certain type of operation 
> based on the keyUsage
> bits: with keyEncipherment to encrypt a message, with digitalSignature

> to verify the response to a challenge for authentication, or to verify

> signature made on e-mail. These two bits are essential (and
> sufficient) to support key pair seperation per RSA operation 
> capability (decryption or
> signing) of the private key as the RSA operation capabilities of
> private keys may be restricted by hardware implementation (i.e. a 
> crypto processor card may be configured to allow only signing with a 
> private key, or decryption, and check padding and format of 
> input/output before and after the operation or even include part or 
> all of the hashing procedure).
>
> If one wants to ensure that a private key is only used to sign data,
> but not to sign an arbitrary challenge, (which practically means "can 
> be used within S/MIME but not within
> SSL")  which is the case e.g. within the signature law compliant use
> cases, a new bit is needed to clearly distinguish between public keys 
> used for authentication and for signature verification. In all specs 
> that adress this seperation the nonRepudiation bit is used for that 
> purpose. And I cannot see a need for changing that..

Therefore you say that the NR bit is set when we want to use the
certificate for "digital signature" which actually is just the
authentication of the sender for S/MIME messages and nothing else. No
one is trying to change this. However, everyone should know that this
does not prove anything. So if you give different CPs the freedom of
loading whatever meaning they want to the NR bit, there will be
problems.

Besides, I also see the need for another bit which actually states that
"I have read and agree with the content of this message" like real
signatures. (I think the DS bit can be used for this. But everyone
should have exactly the same understanding of these bits.)




> |------------------------+------------------------+-----------
-------------|
> |                        |   "Omer Hasret"        |
>              |
> |                        |   <[e-mail]>  |
> To:          |
> |                        |   Sent by:             |
> "'Trevor Freeman'"   |
> |                        |   owner-ietf-pkix@mail.|
> <[e-mail]|
> |                        |   imc.org              |
> osoft.com>, "'Santosh|
> |                        |                        |
> Chokhani'"           |
> |                        |   03.05.2002 10:52     |
> <[e-mail]|
> |                        |                        |   m>
>              |
> |                        |                        |
> cc:          |
> |                        |                        |
> <[e-mail]>  |
> |                        |                        |
> Subject:     |
> |                        |                        |   RE:
> Meaning of       |
> |                        |                        |
> Non-repudiation      |
> |------------------------+------------------------+-----------
-------------|
>
>
>
>
>
>
>
>
> Trevor, Santosh,
>
> It is certain that everybody will need some means of proving that he
> is the originator of a specific message, document, whatever. And when 
> we talk about the NR bit on a certificate, I believe the only thing 
> this proves is that a specific data is signed by the holder of this 
> certificate. This never means that the signer agrees with the content 
> or not. Therefore there is no need to load other meanings to this one 
> bit changing from policy to policy. Just standardize its use only for 
> authentication and let others who want to implement their own NR 
> systems do it by other means. (Some ways to do this have been posted 
> on the list a day or two days ago.) And I really do not think this as 
> a "dictation" because you don't have to use that bit just because its 
> name is NR.
>
> >
> >
> >
> > Hi Santosh,
> > That still sounds like a policy decision.
> > A signature over an SSL challenge is potentially just as
> valid a piece
> > of a NR jigsaw puzzle as any other signature. Why are we dictating
> > what someone wants as a NR process? If you want to build a system 
> > where NR signatures only occur over documents - fine by me,
> but don't
> > dictate how I build my NR system. Trevor
> >
> > -----Original Message-----
> > From: Santosh Chokhani [mailto:[e-mail]]
> > Sent: Thursday, May 02, 2002 2:03 PM
> > To: Trevor Freeman; 'Denis Pinkas'; 'David P. Kemp'
> > Cc: [e-mail]
> > Subject: RE: Meaning of Non-repudiation
> >
> > Trevor:
> >
> > I also made a resolution long time back when ABA started a
> debate on
> > this.  But, I also broke it.
> >
> > I do think that there is a value in SSL case to say that I am not
> > owning up to signature (as attesting to something) except I
> signed a
> > challenge. Thus, subscriber (possessor of the private key)
> should be
> > able to use a separate key so that he can claim he simply signed a
> > random challenge.
> >
> > -----Original Message-----
> > From: [e-mail]
> > [mailto:[e-mail]]
> > On Behalf Of Trevor Freeman
> > Sent: Thursday, May 02, 2002 2:53 PM
> > To: Denis Pinkas; David P. Kemp
> > Cc: [e-mail]
> > Subject: RE: Meaning of Non-repudiation
> >
> >
> >
> > I am breaking one of my New Year resolutions by mailing on
> this topic,
> > but here goes...
> >
> > Signing anything is always a challenge to prove position of
> a private
> > key to authenticate whether it's in the context of a
> protocol like SSL
> > or over a SMIME message. Technically all we can say is the
> signature
> > occurred. The intent behind why the signature occurred is
> beyond the
> > scope of this discussion. Use of certificates with the NR
> bit asserted
> > is ultimately a matter of local policy on what constitutes usage as
> > part of a non-repudiation service since two organisations could have

> > two separate non repudiation serves where one requires a NR
> > signature as part of an SSL session, and the other only wants NR 
> > signatures over SMIME messages.
> >
> > Never in the course of IETF has history so much been written over
> > something so small.
> >
> > Trevor
> >
> > -----Original Message-----
> > From: Denis Pinkas [mailto:[e-mail]]
> > Sent: Thursday, May 02, 2002 2:27 AM
> > To: David P. Kemp
> > Cc: [e-mail]
> > Subject: Re: Meaning of Non-repudiation
> >
> >
> > Dave,
> >
> > > Russ,
> > >
> > > I believe we are all sorry to resurrect this topic.
> > > But it is currently the subject of an X.509 defect,
> >
> > Not exactly. Someone would like this topic to be the subject of an
> > X.509 defect report, but this is is currently *not* the
> subject of an
> > X.509 defect that has been officially raised.
> >
> > > and if the text of X.509 eventually changes in a way
> > > that is incompatible with Son-of-2459, then Grandson-of-2459 will
> > > need to take that into consideration.
> >
> > Very unlikely to happen.
> >
> > Additional *explanations* without changing the meaning
> > *could* be provided and we are (nearly) all saying the same thing
> > using different words. Santosh in a subsequent e-mail
> provided one of
> > these
> > explanations:
> >
> > "In my analysis, DS means you are signing some challenge to prove
> > possession of a private key and thus authenticate yourself whereas 
> > with NR you are saying that I know what this data is and I
> am signing
> > it."
> >
> > I would add that a certificate with the the DS bit set can also be
> > used to authenticate data (this does not mean that the
> signer has read
> > the data).
> >
> > Now, there are cases where, beyond the fact that the signer
> did know
> > what he signed, he wants to say exactly what its signature means.
> >
> > This can be achieved using three ways:
> >
> > 1) the document that is signed is unambiguous and its
> semantics says
> > that the signature means XXX.
> >
> > 2) a signed attribute (using the CMS language) is signed in
> addition
> > to the document and indicates a signature policy that is explicit
> > about the meaning of all signatures performed under that
> policy (note
> > that one single meaning is possible in that case).
> >
> > 3) another signed attribute (using the CMS language) is signed in
> > addition to the document and the previous attribute. It
> indicates the
> > type of commitment being made under the signature policy for that
> > signature (note that multiple meanings are possible in that case).
> >
> > As a result, the variety of meanings is NOT placed in the
> Certificate
> > Policy from the CA.
> >
> > > We can all live with the text because we have no consensus
> > on anything
> > > better.
> >
> > Fine.
> >
> > Denis
> >
> > > That doesn't rule out the faint hope that the ITU can develop a
> > > meaningful replacement in the future.
> > >
> > > Dave
> > >
> > > "Housley, Russ" wrote:
> > > >
> > > > Dave:
> > > >
> > > > I am sorry that I replied to this thread at all.  This topic has
> > been debated
> > > > before, and the text in Son-of-RFC 2459 is the result of that
> > debate.
> > > > Obviously, everyone can live with that text because no
> objections
> > were raised
> > > > during WG Last Call or IETF Last Call.
> > > >
> > > > I am not surprised that there is not 100% agreement....
> > > >
> > > > Russ
> >
>
>
>
>






Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g46NqbR08667 for ietf-pkix-bks; Mon, 6 May 2002 16:52:37 -0700 (PDT)
Received: from mtiwmhc24.worldnet.att.net (mtiwmhc24.worldnet.att.net [204.127.131.49]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g46NqaL08663 for <[e-mail]>; Mon, 6 May 2002 16:52:36 -0700 (PDT)
Received: from Chokhani ([12.91.134.162]) by mtiwmhc24.worldnet.att.net (InterMail vM.4.01.03.27 201-229-121-127-20010626) with ESMTP id <20020506235216.UXTZ18857.mtiwmhc24.worldnet.att.net@Chokhani>; Mon, 6 May 2002 23:52:16 +0000
From: "Santosh Chokhani" <[e-mail]>
To: "'Trevor Freeman'" <[e-mail]>
Cc: <[e-mail]>
Subject: RE: Redefining the Key Usage bits 0 and 1
Date: Mon, 6 May 2002 19:53:48 -0400
Message-ID: <001701c1f559$4477c940$a300a8c0@Chokhani>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.2627
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4910.0300
Importance: Normal
In-Reply-To: <[e-mail]>
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id g46NqbL08664
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Trevor:

This is likely to be my last e-mail on the topic.  I do not mean to
belabor the point.  But, which of the four scenarios are out of line
with current implementations?

-----Original Message-----
From: Trevor Freeman [mailto:[e-mail]] 
Sent: Monday, May 06, 2002 1:22 AM
To: Santosh Chokhani
Cc: [e-mail]
Subject: Redefining the Key Usage bits 0 and 1


Santosh,
Stop the spin doctoring semantic examples. We are not talking about NR
here. You are proposing redefining the scope of the key usage bits 0 and
1. That is changing semantics. If you truly want to express this kind of
policy in certificates, that is fine and a reasonable request, and you
have several courses of action open to you.
1) Define the new semantics for use in an extension of identical
structure to the existing key usage extension but use a different OID to
identify the extension.
2) Define new OIDs for use with the EKU extension.
3) Define an entirely new extension.
4) Define a new policy qualifier (Russ will love that option)

I really don't care which course you choose to achieve your objective,
but you cannot redefine the semantics of the existing key usage
extension and retain the same identifier. That course of action as they
say is a dead parrot. It is deceased. It is no alive. It is kaput. It
will not fly. It is pushing up daises. Get the picture.

Trevor 

-----Original Message-----
From: Santosh Chokhani [mailto:[e-mail]] 
Sent: Saturday, May 04, 2002 6:16 AM
To: Trevor Freeman
Cc: [e-mail]
Subject: RE: Meaning of Non-repudiation

Trevor:

I am not trying to define new mechanisms.  I am simply suggesting how to
differentiate between the two bits that has some technical meaning.  If
you know of any technical meaning between the two bits, let me know.

Compliant implementations that set both bits so that the same key is
used for signing data and signing challenges can continue to do so.

Thus, in order to validate if I am changing the semantics of the
implementation and/or if my proposal will fly in the face of backward
compatibility, we need to determine how the current implementations use
the two bits.

Let us call NR bit bit A and DS bit bit B.

You are welcome to show how you interpret the bits.  What I am proposing
is as follows:

A = 0, B = 0 => The public key may not be used to verify signature on
data on random challenges.

A = 1, B = 0 => The public key may be used to verify signature on data,
but not on random challenges.

A = 0, B = 1 => The public key may not be used to verify signature on
data, but can be used to verify signature on random challenges.

A = 1, B = 1 => The public key may be used to verify signature on data
and can be used to verify signature on random challenges.

I suspect of these, case "c" may be the most controversial, if any.  How
many implementations use case c and use the public key to verify the
signature on data?

-----Original Message-----
From: Trevor Freeman [mailto:[e-mail]] 
Sent: Friday, May 03, 2002 8:21 PM
To: Santosh Chokhani
Cc: [e-mail]
Subject: RE: Meaning of Non-repudiation


Santosh,
Your suggestion is not backwards compatible with the exiting standard.
If you want to introduce new ways to further restrict what can be signed
with a digital signature key then I suggest you look to the existing key
usage extension mechanisms and if you still want to define a new
mechanism justify why since those extension mechanisms are inadequate
since they were designed for such a purpose. Changing the existing
semantics of existing extensions is out of scope no matter how
inadequate those semantics may seem. Trevor



-----Original Message-----
From: Santosh Chokhani [mailto:[e-mail]] 
Sent: Friday, May 03, 2002 3:07 PM
To: Trevor Freeman; [e-mail]; 'Omer Hasret'
Cc: [e-mail]
Subject: RE: Meaning of Non-repudiation

Trevor:

How am I changing the semantics of the extension?  The extension is used
for defining which of the security services the key pair can be used
for.  I am adhere to that.  All I am doing is giving some useful
distinction between DS and NR.

If you are saying that I am providing a meaningful distinction between
the two bits and that distinction may not be backward compatible with
some commercial products, I agree.

-----Original Message-----
From: [e-mail] [mailto:[e-mail]]
On Behalf Of Trevor Freeman
Sent: Friday, May 03, 2002 4:14 PM
To: Santosh Chokhani; [e-mail]; Omer Hasret
Cc: [e-mail]
Subject: RE: Meaning of Non-repudiation



Santosh,
Either you are proposing changing the semantics of the existing
definition of the key usage extension, or you are advocating a policy
which may be implanted. The first is a none starter - you don't change
the semantics of existing extensions. The second is perfectly acceptable
policy that you may want follow, but is not mandatory on all parties.
Trevor

-----Original Message-----
From: Santosh Chokhani [mailto:[e-mail]] 
Sent: Friday, May 03, 2002 10:56 AM
To: [e-mail]; 'Omer Hasret'
Cc: [e-mail]
Subject: RE: Meaning of Non-repudiation


I think EKU provide application specific refinement, e.g., code signing.

But, key usage has the basic operations.  The distinction between
signing a challenge and data that you take some ownership to belongs in
key usage.

-----Original Message-----
From: [e-mail] [mailto:[e-mail]]
On Behalf Of [e-mail]
Sent: Friday, May 03, 2002 9:43 AM
To: Omer Hasret
Cc: 'Santosh Chokhani'; [e-mail]
Subject: RE: Meaning of Non-repudiation






"Extended Key Usage" is meant for that purpose, isn't it ? Or "Policy
Identifier" could provide this kind of information.
|------------------------+------------------------+---------------------
---|
|                        |   "Omer Hasret"        |
|
|                        |   <[e-mail]>  |           To:
|
|                        |                        |
<Olaf.Schlueter@secar|
|                        |   03.05.2002 14:53     |   tis.com>,
|
|                        |                        |
<[e-mail]>  |
|                        |                        |           cc:
|
|                        |                        |   "'Santosh
Chokhani'" |
|                        |                        |
<[e-mail]|
|                        |                        |   m>
|
|                        |                        |           Subject:
|
|                        |                        |   RE: Meaning of
|
|                        |                        |   Non-repudiation
|
|------------------------+------------------------+---------------------
---|








Olaf,

See below,

> -----Original Message-----
> From: [e-mail]
> [mailto:[e-mail]] On Behalf Of 
> [e-mail]
> Sent: vendredi 3 mai 2002 12:43
> To: [e-mail]
> Cc: 'Santosh Chokhani'; [e-mail];
> [e-mail]; 'Trevor Freeman'
> Subject: RE: Meaning of Non-repudiation
>
>
>
>
>
>
> The NR bit in a certifiicate does not proof anything. It is a
> statement made by the signer and/or the CA about the intended use of 
> the key. KeyUsage bits are currently used to support key pair 
> separation for the three basic use cases of public key cryptography: 
> encryption, authentication and digital signing. Most application 
> choose public key certificates needed for a certain type of operation 
> based on the keyUsage
> bits: with keyEncipherment to encrypt a message, with digitalSignature

> to verify the response to a challenge for authentication, or to verify

> signature made on e-mail. These two bits are essential (and
> sufficient) to support key pair seperation per RSA operation 
> capability (decryption or
> signing) of the private key as the RSA operation capabilities of
> private keys may be restricted by hardware implementation (i.e. a 
> crypto processor card may be configured to allow only signing with a 
> private key, or decryption, and check padding and format of 
> input/output before and after the operation or even include part or 
> all of the hashing procedure).
>
> If one wants to ensure that a private key is only used to sign data,
> but not to sign an arbitrary challenge, (which practically means "can 
> be used within S/MIME but not within
> SSL")  which is the case e.g. within the signature law compliant use
> cases, a new bit is needed to clearly distinguish between public keys 
> used for authentication and for signature verification. In all specs 
> that adress this seperation the nonRepudiation bit is used for that 
> purpose. And I cannot see a need for changing that..

Therefore you say that the NR bit is set when we want to use the
certificate for "digital signature" which actually is just the
authentication of the sender for S/MIME messages and nothing else. No
one is trying to change this. However, everyone should know that this
does not prove anything. So if you give different CPs the freedom of
loading whatever meaning they want to the NR bit, there will be
problems.

Besides, I also see the need for another bit which actually states that
"I have read and agree with the content of this message" like real
signatures. (I think the DS bit can be used for this. But everyone
should have exactly the same understanding of these bits.)




> |------------------------+------------------------+-----------
-------------|
> |                        |   "Omer Hasret"        |
>              |
> |                        |   <[e-mail]>  |
> To:          |
> |                        |   Sent by:             |
> "'Trevor Freeman'"   |
> |                        |   owner-ietf-pkix@mail.|
> <[e-mail]|
> |                        |   imc.org              |
> osoft.com>, "'Santosh|
> |                        |                        |
> Chokhani'"           |
> |                        |   03.05.2002 10:52     |
> <[e-mail]|
> |                        |                        |   m>
>              |
> |                        |                        |
> cc:          |
> |                        |                        |
> <[e-mail]>  |
> |                        |                        |
> Subject:     |
> |                        |                        |   RE:
> Meaning of       |
> |                        |                        |
> Non-repudiation      |
> |------------------------+------------------------+-----------
-------------|
>
>
>
>
>
>
>
>
> Trevor, Santosh,
>
> It is certain that everybody will need some means of proving that he
> is the originator of a specific message, document, whatever. And when 
> we talk about the NR bit on a certificate, I believe the only thing 
> this proves is that a specific data is signed by the holder of this 
> certificate. This never means that the signer agrees with the content 
> or not. Therefore there is no need to load other meanings to this one 
> bit changing from policy to policy. Just standardize its use only for 
> authentication and let others who want to implement their own NR 
> systems do it by other means. (Some ways to do this have been posted 
> on the list a day or two days ago.) And I really do not think this as 
> a "dictation" because you don't have to use that bit just because its 
> name is NR.
>
> >
> >
> >
> > Hi Santosh,
> > That still sounds like a policy decision.
> > A signature over an SSL challenge is potentially just as
> valid a piece
> > of a NR jigsaw puzzle as any other signature. Why are we dictating
> > what someone wants as a NR process? If you want to build a system 
> > where NR signatures only occur over documents - fine by me,
> but don't
> > dictate how I build my NR system. Trevor
> >
> > -----Original Message-----
> > From: Santosh Chokhani [mailto:[e-mail]]
> > Sent: Thursday, May 02, 2002 2:03 PM
> > To: Trevor Freeman; 'Denis Pinkas'; 'David P. Kemp'
> > Cc: [e-mail]
> > Subject: RE: Meaning of Non-repudiation
> >
> > Trevor:
> >
> > I also made a resolution long time back when ABA started a
> debate on
> > this.  But, I also broke it.
> >
> > I do think that there is a value in SSL case to say that I am not
> > owning up to signature (as attesting to something) except I
> signed a
> > challenge. Thus, subscriber (possessor of the private key)
> should be
> > able to use a separate key so that he can claim he simply signed a
> > random challenge.
> >
> > -----Original Message-----
> > From: [e-mail]
> > [mailto:[e-mail]]
> > On Behalf Of Trevor Freeman
> > Sent: Thursday, May 02, 2002 2:53 PM
> > To: Denis Pinkas; David P. Kemp
> > Cc: [e-mail]
> > Subject: RE: Meaning of Non-repudiation
> >
> >
> >
> > I am breaking one of my New Year resolutions by mailing on
> this topic,
> > but here goes...
> >
> > Signing anything is always a challenge to prove position of
> a private
> > key to authenticate whether it's in the context of a
> protocol like SSL
> > or over a SMIME message. Technically all we can say is the
> signature
> > occurred. The intent behind why the signature occurred is
> beyond the
> > scope of this discussion. Use of certificates with the NR
> bit asserted
> > is ultimately a matter of local policy on what constitutes usage as
> > part of a non-repudiation service since two organisations could have

> > two separate non repudiation serves where one requires a NR
> > signature as part of an SSL session, and the other only wants NR 
> > signatures over SMIME messages.
> >
> > Never in the course of IETF has history so much been written over
> > something so small.
> >
> > Trevor
> >
> > -----Original Message-----
> > From: Denis Pinkas [mailto:[e-mail]]
> > Sent: Thursday, May 02, 2002 2:27 AM
> > To: David P. Kemp
> > Cc: [e-mail]
> > Subject: Re: Meaning of Non-repudiation
> >
> >
> > Dave,
> >
> > > Russ,
> > >
> > > I believe we are all sorry to resurrect this topic.
> > > But it is currently the subject of an X.509 defect,
> >
> > Not exactly. Someone would like this topic to be the subject of an
> > X.509 defect report, but this is is currently *not* the
> subject of an
> > X.509 defect that has been officially raised.
> >
> > > and if the text of X.509 eventually changes in a way
> > > that is incompatible with Son-of-2459, then Grandson-of-2459 will
> > > need to take that into consideration.
> >
> > Very unlikely to happen.
> >
> > Additional *explanations* without changing the meaning
> > *could* be provided and we are (nearly) all saying the same thing
> > using different words. Santosh in a subsequent e-mail
> provided one of
> > these
> > explanations:
> >
> > "In my analysis, DS means you are signing some challenge to prove
> > possession of a private key and thus authenticate yourself whereas 
> > with NR you are saying that I know what this data is and I
> am signing
> > it."
> >
> > I would add that a certificate with the the DS bit set can also be
> > used to authenticate data (this does not mean that the
> signer has read
> > the data).
> >
> > Now, there are cases where, beyond the fact that the signer
> did know
> > what he signed, he wants to say exactly what its signature means.
> >
> > This can be achieved using three ways:
> >
> > 1) the document that is signed is unambiguous and its
> semantics says
> > that the signature means XXX.
> >
> > 2) a signed attribute (using the CMS language) is signed in
> addition
> > to the document and indicates a signature policy that is explicit
> > about the meaning of all signatures performed under that
> policy (note
> > that one single meaning is possible in that case).
> >
> > 3) another signed attribute (using the CMS language) is signed in
> > addition to the document and the previous attribute. It
> indicates the
> > type of commitment being made under the signature policy for that
> > signature (note that multiple meanings are possible in that case).
> >
> > As a result, the variety of meanings is NOT placed in the
> Certificate
> > Policy from the CA.
> >
> > > We can all live with the text because we have no consensus
> > on anything
> > > better.
> >
> > Fine.
> >
> > Denis
> >
> > > That doesn't rule out the faint hope that the ITU can develop a
> > > meaningful replacement in the future.
> > >
> > > Dave
> > >
> > > "Housley, Russ" wrote:
> > > >
> > > > Dave:
> > > >
> > > > I am sorry that I replied to this thread at all.  This topic has
> > been debated
> > > > before, and the text in Son-of-RFC 2459 is the result of that
> > debate.
> > > > Obviously, everyone can live with that text because no
> objections
> > were raised
> > > > during WG Last Call or IETF Last Call.
> > > >
> > > > I am not surprised that there is not 100% agreement....
> > > >
> > > > Russ
> >
>
>
>
>






Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g46Kl1g00473 for ietf-pkix-bks; Mon, 6 May 2002 13:47:01 -0700 (PDT)
Received: from mail6.microsoft.com (mail6.microsoft.com [131.107.3.126]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g46KkxL00469 for <[e-mail]>; Mon, 6 May 2002 13:46:59 -0700 (PDT)
Received: from inet-vrs-06.redmond.corp.microsoft.com ([157.54.6.201]) by mail6.microsoft.com with Microsoft SMTPSVC(5.0.2195.4905); Mon, 6 May 2002 13:46:57 -0700
Received: from 157.54.8.155 by inet-vrs-06.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Mon, 06 May 2002 13:46:56 -0700
Received: from red-imc-04.redmond.corp.microsoft.com ([157.54.2.168]) by inet-hub-04.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.4905); Mon, 6 May 2002 13:46:56 -0700
Received: from win-imc-02.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.84]) by red-imc-04.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.2966); Mon, 6 May 2002 13:46:56 -0700
Received: from win-msg-01.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.52]) by win-imc-02.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3590.0); Mon, 6 May 2002 13:46:58 -0700
X-MimeOLE: Produced By Microsoft Exchange V6.0.6177.0
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Subject: RE: Meaning of Non-repudiation
Date: Mon, 6 May 2002 13:43:02 -0700
Message-ID: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: Meaning of Non-repudiation
Thread-Index: AcH1OCHytCAzyzzCQ2q4oyJcknSSqQABKBPA
From: "Trevor Freeman" <[e-mail]>
To: "David P. Kemp" <[e-mail]>, <[e-mail]>
X-OriginalArrivalTime: 06 May 2002 20:46:58.0190 (UTC) FILETIME=[2A250AE0:01C1F53F]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id g46KkxL00470
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Dave,
I realise the intent, but there is a distinction between clarification
and redefinition. The exact intent indicated by bit 1 may be fizzy, but
it does have some boundaries and these proposals are not consistent with
the existing boundaries so are not clarifications but changes of
semantics. 
Trevor

-----Original Message-----
From: David P. Kemp [mailto:[e-mail]] 
Sent: Monday, May 06, 2002 12:53 PM
To: [e-mail]
Subject: Re: Meaning of Non-repudiation


Trevor Freeman wrote:
> 
> Dave,
> If you truly were just changing the names - I could not care one jolt,
> but you are proposing changing the semantics, and that is
unacceptable.
> DS today means sign anything but certs and CRLS. That definition has
to
> stand for that bit.
> Trevor


Trevor,

You can read the standard as well as anyone, and know that
DS today means sign anything but certs, CRLs, *and bit 1 stuff*.

This discussion is trying to de-fuzzy the definition
of bit 1 stuff.  Your claim that {bit 1 stuff} == {the empty set}
may reflect the behavior of some existing products.  And
it is definitely about as non-fuzzy as you can get :-).

But X.509 and 2459 say that, whatever bit 1 stuff is,
it is *not* the empty set.  The X.509 definition, not the
Trevor definition, is what must stand.

Dave


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g46Jqmk27347 for ietf-pkix-bks; Mon, 6 May 2002 12:52:48 -0700 (PDT)
Received: from stingray.missi.ncsc.mil (stingray.missi.ncsc.mil [144.51.50.20]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g46JqlL27342 for <[e-mail]>; Mon, 6 May 2002 12:52:47 -0700 (PDT)
Received: from stingray.missi.ncsc.mil (root@localhost) by stingray.missi.ncsc.mil with ESMTP id g46JnjX05395 for <[e-mail]>; Mon, 6 May 2002 15:49:45 -0400 (EDT)
Message-ID: <[e-mail]>
Date: Mon, 06 May 2002 15:52:33 -0400
From: "David P. Kemp" <[e-mail]>
X-Mailer: Mozilla 4.77 [en] (X11; U; SunOS 5.7 sun4u)
X-Accept-Language: en
MIME-Version: 1.0
To: [e-mail]
Subject: Re: Meaning of Non-repudiation
References: <[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
X-H-S-Loop-Check-Ejzfr: 
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Trevor Freeman wrote:
> 
> Dave,
> If you truly were just changing the names - I could not care one jolt,
> but you are proposing changing the semantics, and that is unacceptable.
> DS today means sign anything but certs and CRLS. That definition has to
> stand for that bit.
> Trevor


Trevor,

You can read the standard as well as anyone, and know that
DS today means sign anything but certs, CRLs, *and bit 1 stuff*.

This discussion is trying to de-fuzzy the definition
of bit 1 stuff.  Your claim that {bit 1 stuff} == {the empty set}
may reflect the behavior of some existing products.  And
it is definitely about as non-fuzzy as you can get :-).

But X.509 and 2459 say that, whatever bit 1 stuff is,
it is *not* the empty set.  The X.509 definition, not the
Trevor definition, is what must stand.

Dave


Received: by above.proper.com (8.11.6/8.11.3) id g46I0Sp23632 for ietf-pkix-bks; Mon, 6 May 2002 11:00:28 -0700 (PDT)
Received: from nymelsmtp.internet.ny.fdms.firstdata.com ([204.124.248.17]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g46I0RL23627 for <[e-mail]>; Mon, 6 May 2002 11:00:27 -0700 (PDT)
Subject: Re: Meaning of Non-repudiation
To: Denis Pinkas <[e-mail]>
Cc: [e-mail]
X-Mailer: Lotus Notes Release 5.0.5  September 22, 2000
Message-ID: <[e-mail]>
From: [e-mail]
Date: Mon, 6 May 2002 11:59:19 -0600
X-MIMETrack: Serialize by Router on NYMELSMTP/NY/FDMS/FDC(Release 5.0.8 |June 18, 2001) at 05/06/2002 01:57:26 PM
MIME-Version: 1.0
Content-type: text/plain; charset=us-ascii
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

a "problem" is that certificates are suppose to be something that a relying
party ... can rely on ... because relying parties supposedly can't directly
trust the signer/sender.

if you are going to be able to always trust the signer/sender in all things
... then why do you need certificates ... which certify information by
independent parties ... just trust the signer/sender and completely do away
with certificates.

says that the relying party can't trust the signer ... but can trust the CA
... except it has to trust the signer  to not have two certificates with
different meanings and the same key ... so that if there is a dispute ...
the signer can repudiate the transaction by saying that the sender had sent
the certificate with the "random data" bit set ... but somebody substituted
another certificate w/o the random data bit set  .... unless somebody gets
a law passed saying a signer can't repudiate a transaction if they ever had
two different certificates issued for the same key. Even at that,
certificates don't include the signature on the data in a certificate by
the sender ... only by the CA ... what is to prevent the claim that some CA
generated an arbritrary certificate containing my public key ... w/o
adequately prooving the corresponding private key?

so the movement of all flags/indications ... especially related as to the
intention/belief of the sender associated with a specific message ... into
the signed body of the message. In effect, if there is some trust issue as
to what I believe or intend ... then I need to have explicitly signed it.
If there is some dependency on some state  with respect to some specific
signed message/content ... then the signer  can repudiate it if it isn't
covered by the signature. That is somewhat independent of whether a signer
can also repudiate stuff they've signed. This is specifically that signers
can repudiate a "not random bit" in an appended certificate that isn't
actually part of the signed message.




denis pinkas <[e-mail]> on 5/6/2002 10:42 am wrote:

It is the problem of the signer (not of the CA) to make sure that when it
uses these two different certificates, two different keys are being used.






Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g46Gha121552 for ietf-pkix-bks; Mon, 6 May 2002 09:43:36 -0700 (PDT)
Received: from odin2.bull.net (odin2.bull.net [192.90.70.84]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g46GhYL21548 for <[e-mail]>; Mon, 6 May 2002 09:43:34 -0700 (PDT)
Received: from lvn-m002.frlv.bull.fr (lvn-m002.frlv.bull.fr [129.184.62.72]) by odin2.bull.net (8.9.3/8.9.3) with ESMTP id SAA13404; Mon, 6 May 2002 18:46:21 +0200
Received: from bull.net ([129.184.37.97]) by lvn-m002.frlv.bull.fr (Lotus Domino Release 5.0.8) with ESMTP id 2002050618424927:354 ; Mon, 6 May 2002 18:42:49 +0200 
Message-ID: <[e-mail]>
Date: Mon, 06 May 2002 18:42:47 +0200
From: Denis Pinkas <[e-mail]>
Organization: Bull SA.
X-Mailer: Mozilla 4.7 [fr] (Win98; I)
X-Accept-Language: fr
MIME-Version: 1.0
To: [e-mail]
CC: [e-mail]
Subject: Re: Meaning of Non-repudiation
References: <[e-mail]>
X-MIMETrack: Itemize by SMTP Server on LVN-M002/FR/BULL(Release 5.0.8 |June 18, 2001) at 06/05/2002 18:42:49, Serialize by Router on LVN-M002/FR/BULL(Release 5.0.8 |June 18, 2001) at 06/05/2002 18:43:20, Serialize complete at 06/05/2002 18:43:20
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset=us-ascii
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Lynn,

A few words before going on vacations for the remaining of the week.

:-)

> somewhat as aside,  in theory the whole point of certificates & the
> "certified" information is for use/reliance by relying parties.
> 
> having a
> 
> 1) bit that says the sender believes that they are signing something with
> no meaning (random data) and
> 
> 2) diffferent bit that says the sender believes that they are signing
> something with meaning (not random bits) containing some semantic meaning
> with possible implication that the signing operation indicates the sender
> is in some agreement with the contents of the signed message.

This is the general understanding. This meaning is backward compatible with
the current meaning.

> backing those bits out of the actual signed message and into an appended
> certificate could work if there was an exact one-to-one correspondance
> between the key doing the signing and the appended certificate. However, if
> it is a certificate with both of the bits on ... then it is somewhat
> defeating the purpose of having the bits .... 
> because the relying party no
> longer can rely on specific deterministic meaning (aka the sender believes
> that they are signing something with no meaning ... or signing something
> with meaning ... but relying party isn't able to tell which because both
> bits are on, defeating the purpose of having the bits at all).

Hence why a certificate with these two bits set together would be dangerous.

If the client is always under the control of the signer, this could work if
the client makes sure, before using the private key, that the protocol used
is "safe". An "unsafe" protocol would be a protocol where a server asks to
sign a challenge. A safe protocol would be a protocol where the server asks 
to sign both a random number chosen by the client and a challenge chosen by 
the server.
 
> The other problem is being able to proove that sender has never acquired
> multiple certificates for the same key pair with different bits set. Since
> the appended certificates aren't part of the signed message ... the sender
> could claim that they had appended the certificate with the  "no meaning
> message" ... and somebody substituted a certificate  the "no meaning" bit
> off and the "meaning" bit on. That problem then suggests two extremes:

It is the problem of the signer (not of the CA) to make sure that when it
uses these two different certificates, two different keys are being used.

> 1) never allow people to generate their own keys and supply them to 3rd
> parties for certification. CAs can guarentee that key pairs are never
> submitted for multiple certificates if they only certify random keys that
> the CA generate themselves .. and that creating a new certificate always
> requires generating a new key pair (unless there is a global repository
> used by all CAs checking to see if a specific key-pair had ever previously
> been certified).
> 
> 2) moving the certificate inside the signed message. the reason to do this
> is the original suggestion involving the flag bits indicating the senders
> belief as to the flag indicating message type/characteristic  needs to be
> part of the signed message. moving the whole certificate inside the signed
> message is somewhat overkill just to get a couple bit indicators moved
> inside. this solution requires a convention that signers always include
> flags indicating their belief as to the type of message (people doing
> brain-dead signing of messages w/o looking at the contents might get
> themselves into situation similar to people signing blank checks or blank
> pieces of paper).

This is roughly what is being done in RFC 3126 (Electronic Signature Formats
for long term electronic signatures) : an unambiguous reference to the
certificate is part of the signature, hence the full certificate does not
need to be directly protected by the signature.

This allows to work with multiples certificates that have both the same
public key and the NR bit set, but which contains different attributes.

The use of such certificates must always be restricted to environments 
(i.e. clients) that the signer can control.

Denis

> previous pieces of thread:
> http://www.garlic.com/~lynn/aadsm11.htm#5 Meaning of Non-repudiation
> http://www.garlic.com/~lynn/aadsm11.htm#6 Meaning of Non-repudiation
> http://www.garlic.com/~lynn/aadsm11.htm#7 Meaning of Non-repudiation


Received: by above.proper.com (8.11.6/8.11.3) id g46G0nR20488 for ietf-pkix-bks; Mon, 6 May 2002 09:00:49 -0700 (PDT)
Received: from nymelsmtp.internet.ny.fdms.firstdata.com ([204.124.248.17]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g46G0lL20484 for <[e-mail]>; Mon, 6 May 2002 09:00:47 -0700 (PDT)
Subject: RE: Meaning of Non-repudiation
To: [e-mail], [e-mail]
X-Mailer: Lotus Notes Release 5.0.5  September 22, 2000
Message-ID: <[e-mail]>
From: [e-mail]
Date: Mon, 6 May 2002 09:58:51 -0600
X-MIMETrack: Serialize by Router on NYMELSMTP/NY/FDMS/FDC(Release 5.0.8 |June 18, 2001) at 05/06/2002 11:57:47 AM
MIME-Version: 1.0
Content-type: text/plain; charset=us-ascii
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

somewhat as aside,  in theory the whole point of certificates & the
"certified" information is for use/reliance by relying parties.

having a

1) bit that says the sender believes that they are signing something with
no meaning (random data) and

2) diffferent bit that says the sender believes that they are signing
something with meaning (not random bits) containing some semantic meaning
with possible implication that the signing operation indicates the sender
is in some agreement with the contents of the signed message.

backing those bits out of the actual signed message and into an appended
certificate could work if there was an exact one-to-one correspondance
between the key doing the signing and the appended certificate. However, if
it is a certificate with both of the bits on ... then it is somewhat
defeating the purpose of having the bits .... because the relying party no
longer can rely on specific deterministic meaning (aka the sender believes
that they are signing something with no meaning ... or signing something
with meaning ... but relying party isn't able to tell which because both
bits are on, defeating the purpose of having the bits at all).

The other problem is being able to proove that sender has never acquired
multiple certificates for the same key pair with different bits set. Since
the appended certificates aren't part of the signed message ... the sender
could claim that they had appended the certificate with the  "no meaning
message" ... and somebody substituted a certificate  the "no meaning" bit
off and the "meaning" bit on. That problem then suggests two extremes:

1) never allow people to generate their own keys and supply them to 3rd
parties for certification. CAs can guarentee that key pairs are never
submitted for multiple certificates if they only certify random keys that
the CA generate themselves .. and that creating a new certificate always
requires generating a new key pair (unless there is a global repository
used by all CAs checking to see if a specific key-pair had ever previously
been certified).

2) moving the certificate inside the signed message. the reason to do this
is the original suggestion involving the flag bits indicating the senders
belief as to the flag indicating message type/characteristic  needs to be
part of the signed message. moving the whole certificate inside the signed
message is somewhat overkill just to get a couple bit indicators moved
inside. this solution requires a convention that signers always include
flags indicating their belief as to the type of message (people doing
brain-dead signing of messages w/o looking at the contents might get
themselves into situation similar to people signing blank checks or blank
pieces of paper).

previous pieces of thread:
http://www.garlic.com/~lynn/aadsm11.htm#5 Meaning of Non-repudiation
http://www.garlic.com/~lynn/aadsm11.htm#6 Meaning of Non-repudiation
http://www.garlic.com/~lynn/aadsm11.htm#7 Meaning of Non-repudiation





Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g465Pdm04790 for ietf-pkix-bks; Sun, 5 May 2002 22:25:39 -0700 (PDT)
Received: from mail6.microsoft.com (mail6.microsoft.com [131.107.3.126]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g465PbL04785 for <[e-mail]>; Sun, 5 May 2002 22:25:37 -0700 (PDT)
Received: from inet-vrs-06.redmond.corp.microsoft.com ([157.54.6.201]) by mail6.microsoft.com with Microsoft SMTPSVC(5.0.2195.4905); Sun, 5 May 2002 22:25:36 -0700
Received: from 157.54.5.25 by inet-vrs-06.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Sun, 05 May 2002 22:25:36 -0700
Received: from red-imc-04.redmond.corp.microsoft.com ([157.54.2.168]) by inet-hub-03.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.4905); Sun, 5 May 2002 22:25:36 -0700
Received: from win-imc-02.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.84]) by red-imc-04.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.2966); Sun, 5 May 2002 22:25:35 -0700
Received: from win-msg-01.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.52]) by win-imc-02.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3590.0); Sun, 5 May 2002 22:21:42 -0700
X-MimeOLE: Produced By Microsoft Exchange V6.0.6177.0
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Subject: Redefining the Key Usage bits 0 and 1
Date: Sun, 5 May 2002 22:21:42 -0700
Message-ID: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: Redefining the Key Usage bits 0 and 1
Thread-Index: AcHzbQcFC8H/ydf6TOOWDh6PDn5saABTEkMg
From: "Trevor Freeman" <[e-mail]>
To: "Santosh Chokhani" <[e-mail]>
Cc: <[e-mail]>
X-OriginalArrivalTime: 06 May 2002 05:21:42.0784 (UTC) FILETIME=[E8625800:01C1F4BD]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id g465PbL04786
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Santosh,
Stop the spin doctoring semantic examples. We are not talking about NR here. You are proposing redefining the scope of the key usage bits 0 and 1. That is changing semantics. If you truly want to express this kind of policy in certificates, that is fine and a reasonable request, and you have several courses of action open to you.
1) Define the new semantics for use in an extension of identical structure to the existing key usage extension but use a different OID to identify the extension.
2) Define new OIDs for use with the EKU extension.
3) Define an entirely new extension.
4) Define a new policy qualifier (Russ will love that option)

I really don't care which course you choose to achieve your objective, but you cannot redefine the semantics of the existing key usage extension and retain the same identifier. That course of action as they say is a dead parrot. It is deceased. It is no alive. It is kaput. It will not fly. It is pushing up daises.
Get the picture.

Trevor 

-----Original Message-----
From: Santosh Chokhani [mailto:[e-mail]] 
Sent: Saturday, May 04, 2002 6:16 AM
To: Trevor Freeman
Cc: [e-mail]
Subject: RE: Meaning of Non-repudiation

Trevor:

I am not trying to define new mechanisms.  I am simply suggesting how to
differentiate between the two bits that has some technical meaning.  If
you know of any technical meaning between the two bits, let me know.

Compliant implementations that set both bits so that the same key is
used for signing data and signing challenges can continue to do so.

Thus, in order to validate if I am changing the semantics of the
implementation and/or if my proposal will fly in the face of backward
compatibility, we need to determine how the current implementations use
the two bits.

Let us call NR bit bit A and DS bit bit B.

You are welcome to show how you interpret the bits.  What I am proposing
is as follows:

A = 0, B = 0 => The public key may not be used to verify signature on
data on random challenges.

A = 1, B = 0 => The public key may be used to verify signature on data,
but not on random challenges.

A = 0, B = 1 => The public key may not be used to verify signature on
data, but can be used to verify signature on random challenges.

A = 1, B = 1 => The public key may be used to verify signature on data
and can be used to verify signature on random challenges.

I suspect of these, case "c" may be the most controversial, if any.  How
many implementations use case c and use the public key to verify the
signature on data?

-----Original Message-----
From: Trevor Freeman [mailto:[e-mail]] 
Sent: Friday, May 03, 2002 8:21 PM
To: Santosh Chokhani
Cc: [e-mail]
Subject: RE: Meaning of Non-repudiation


Santosh,
Your suggestion is not backwards compatible with the exiting standard.
If you want to introduce new ways to further restrict what can be signed
with a digital signature key then I suggest you look to the existing key
usage extension mechanisms and if you still want to define a new
mechanism justify why since those extension mechanisms are inadequate
since they were designed for such a purpose. Changing the existing
semantics of existing extensions is out of scope no matter how
inadequate those semantics may seem. Trevor



-----Original Message-----
From: Santosh Chokhani [mailto:[e-mail]] 
Sent: Friday, May 03, 2002 3:07 PM
To: Trevor Freeman; [e-mail]; 'Omer Hasret'
Cc: [e-mail]
Subject: RE: Meaning of Non-repudiation

Trevor:

How am I changing the semantics of the extension?  The extension is used
for defining which of the security services the key pair can be used
for.  I am adhere to that.  All I am doing is giving some useful
distinction between DS and NR.

If you are saying that I am providing a meaningful distinction between
the two bits and that distinction may not be backward compatible with
some commercial products, I agree.

-----Original Message-----
From: [e-mail] [mailto:[e-mail]]
On Behalf Of Trevor Freeman
Sent: Friday, May 03, 2002 4:14 PM
To: Santosh Chokhani; [e-mail]; Omer Hasret
Cc: [e-mail]
Subject: RE: Meaning of Non-repudiation



Santosh,
Either you are proposing changing the semantics of the existing
definition of the key usage extension, or you are advocating a policy
which may be implanted. The first is a none starter - you don't change
the semantics of existing extensions. The second is perfectly acceptable
policy that you may want follow, but is not mandatory on all parties.
Trevor

-----Original Message-----
From: Santosh Chokhani [mailto:[e-mail]] 
Sent: Friday, May 03, 2002 10:56 AM
To: [e-mail]; 'Omer Hasret'
Cc: [e-mail]
Subject: RE: Meaning of Non-repudiation


I think EKU provide application specific refinement, e.g., code signing.

But, key usage has the basic operations.  The distinction between
signing a challenge and data that you take some ownership to belongs in
key usage.

-----Original Message-----
From: [e-mail] [mailto:[e-mail]]
On Behalf Of [e-mail]
Sent: Friday, May 03, 2002 9:43 AM
To: Omer Hasret
Cc: 'Santosh Chokhani'; [e-mail]
Subject: RE: Meaning of Non-repudiation






"Extended Key Usage" is meant for that purpose, isn't it ? Or "Policy
Identifier" could provide this kind of information.
|------------------------+------------------------+---------------------
---|
|                        |   "Omer Hasret"        |
|
|                        |   <[e-mail]>  |           To:
|
|                        |                        |
<Olaf.Schlueter@secar|
|                        |   03.05.2002 14:53     |   tis.com>,
|
|                        |                        |
<[e-mail]>  |
|                        |                        |           cc:
|
|                        |                        |   "'Santosh
Chokhani'" |
|                        |                        |
<[e-mail]|
|                        |                        |   m>
|
|                        |                        |           Subject:
|
|                        |                        |   RE: Meaning of
|
|                        |                        |   Non-repudiation
|
|------------------------+------------------------+---------------------
---|








Olaf,

See below,

> -----Original Message-----
> From: [e-mail] 
> [mailto:[e-mail]] On Behalf Of 
> [e-mail]
> Sent: vendredi 3 mai 2002 12:43
> To: [e-mail]
> Cc: 'Santosh Chokhani'; [e-mail];
> [e-mail]; 'Trevor Freeman'
> Subject: RE: Meaning of Non-repudiation
>
>
>
>
>
>
> The NR bit in a certifiicate does not proof anything. It is a 
> statement made by the signer and/or the CA about the intended use of 
> the key. KeyUsage bits are currently used to support key pair 
> separation for the three basic use cases of public key cryptography: 
> encryption, authentication and digital signing. Most application 
> choose public key certificates needed for a certain type of operation 
> based on the keyUsage
> bits: with keyEncipherment to encrypt a message, with digitalSignature

> to verify the response to a challenge for authentication, or to verify

> signature made on e-mail. These two bits are essential (and
> sufficient) to support key pair seperation per RSA operation
> capability (decryption or
> signing) of the private key as the RSA operation capabilities of 
> private keys may be restricted by hardware implementation (i.e. a 
> crypto processor card may be configured to allow only signing with a 
> private key, or decryption, and check padding and format of 
> input/output before and after the operation or even include part or 
> all of the hashing procedure).
>
> If one wants to ensure that a private key is only used to sign data, 
> but not to sign an arbitrary challenge, (which practically means "can 
> be used within S/MIME but not within
> SSL")  which is the case e.g. within the signature law compliant use
> cases, a new bit is needed to clearly distinguish between public keys 
> used for authentication and for signature verification. In all specs 
> that adress this seperation the nonRepudiation bit is used for that 
> purpose. And I cannot see a need for changing that..

Therefore you say that the NR bit is set when we want to use the
certificate for "digital signature" which actually is just the
authentication of the sender for S/MIME messages and nothing else. No
one is trying to change this. However, everyone should know that this
does not prove anything. So if you give different CPs the freedom of
loading whatever meaning they want to the NR bit, there will be
problems.

Besides, I also see the need for another bit which actually states that
"I have read and agree with the content of this message" like real
signatures. (I think the DS bit can be used for this. But everyone
should have exactly the same understanding of these bits.)




> |------------------------+------------------------+-----------
-------------|
> |                        |   "Omer Hasret"        |
>              |
> |                        |   <[e-mail]>  |
> To:          |
> |                        |   Sent by:             |
> "'Trevor Freeman'"   |
> |                        |   owner-ietf-pkix@mail.|
> <[e-mail]|
> |                        |   imc.org              |
> osoft.com>, "'Santosh|
> |                        |                        |
> Chokhani'"           |
> |                        |   03.05.2002 10:52     |
> <[e-mail]|
> |                        |                        |   m>
>              |
> |                        |                        |
> cc:          |
> |                        |                        |
> <[e-mail]>  |
> |                        |                        |
> Subject:     |
> |                        |                        |   RE:
> Meaning of       |
> |                        |                        |
> Non-repudiation      |
> |------------------------+------------------------+-----------
-------------|
>
>
>
>
>
>
>
>
> Trevor, Santosh,
>
> It is certain that everybody will need some means of proving that he 
> is the originator of a specific message, document, whatever. And when 
> we talk about the NR bit on a certificate, I believe the only thing 
> this proves is that a specific data is signed by the holder of this 
> certificate. This never means that the signer agrees with the content 
> or not. Therefore there is no need to load other meanings to this one 
> bit changing from policy to policy. Just standardize its use only for 
> authentication and let others who want to implement their own NR 
> systems do it by other means. (Some ways to do this have been posted 
> on the list a day or two days ago.) And I really do not think this as 
> a "dictation" because you don't have to use that bit just because its 
> name is NR.
>
> >
> >
> >
> > Hi Santosh,
> > That still sounds like a policy decision.
> > A signature over an SSL challenge is potentially just as
> valid a piece
> > of a NR jigsaw puzzle as any other signature. Why are we dictating 
> > what someone wants as a NR process? If you want to build a system 
> > where NR signatures only occur over documents - fine by me,
> but don't
> > dictate how I build my NR system. Trevor
> >
> > -----Original Message-----
> > From: Santosh Chokhani [mailto:[e-mail]]
> > Sent: Thursday, May 02, 2002 2:03 PM
> > To: Trevor Freeman; 'Denis Pinkas'; 'David P. Kemp'
> > Cc: [e-mail]
> > Subject: RE: Meaning of Non-repudiation
> >
> > Trevor:
> >
> > I also made a resolution long time back when ABA started a
> debate on
> > this.  But, I also broke it.
> >
> > I do think that there is a value in SSL case to say that I am not 
> > owning up to signature (as attesting to something) except I
> signed a
> > challenge. Thus, subscriber (possessor of the private key)
> should be
> > able to use a separate key so that he can claim he simply signed a 
> > random challenge.
> >
> > -----Original Message-----
> > From: [e-mail] 
> > [mailto:[e-mail]]
> > On Behalf Of Trevor Freeman
> > Sent: Thursday, May 02, 2002 2:53 PM
> > To: Denis Pinkas; David P. Kemp
> > Cc: [e-mail]
> > Subject: RE: Meaning of Non-repudiation
> >
> >
> >
> > I am breaking one of my New Year resolutions by mailing on
> this topic,
> > but here goes...
> >
> > Signing anything is always a challenge to prove position of
> a private
> > key to authenticate whether it's in the context of a
> protocol like SSL
> > or over a SMIME message. Technically all we can say is the
> signature
> > occurred. The intent behind why the signature occurred is
> beyond the
> > scope of this discussion. Use of certificates with the NR
> bit asserted
> > is ultimately a matter of local policy on what constitutes usage as 
> > part of a non-repudiation service since two organisations could have

> > two separate non repudiation serves where one requires a NR 
> > signature as part of an SSL session, and the other only wants NR 
> > signatures over SMIME messages.
> >
> > Never in the course of IETF has history so much been written over 
> > something so small.
> >
> > Trevor
> >
> > -----Original Message-----
> > From: Denis Pinkas [mailto:[e-mail]]
> > Sent: Thursday, May 02, 2002 2:27 AM
> > To: David P. Kemp
> > Cc: [e-mail]
> > Subject: Re: Meaning of Non-repudiation
> >
> >
> > Dave,
> >
> > > Russ,
> > >
> > > I believe we are all sorry to resurrect this topic.
> > > But it is currently the subject of an X.509 defect,
> >
> > Not exactly. Someone would like this topic to be the subject of an 
> > X.509 defect report, but this is is currently *not* the
> subject of an
> > X.509 defect that has been officially raised.
> >
> > > and if the text of X.509 eventually changes in a way
> > > that is incompatible with Son-of-2459, then Grandson-of-2459 will 
> > > need to take that into consideration.
> >
> > Very unlikely to happen.
> >
> > Additional *explanations* without changing the meaning
> > *could* be provided and we are (nearly) all saying the same thing 
> > using different words. Santosh in a subsequent e-mail
> provided one of
> > these
> > explanations:
> >
> > "In my analysis, DS means you are signing some challenge to prove 
> > possession of a private key and thus authenticate yourself whereas 
> > with NR you are saying that I know what this data is and I
> am signing
> > it."
> >
> > I would add that a certificate with the the DS bit set can also be 
> > used to authenticate data (this does not mean that the
> signer has read
> > the data).
> >
> > Now, there are cases where, beyond the fact that the signer
> did know
> > what he signed, he wants to say exactly what its signature means.
> >
> > This can be achieved using three ways:
> >
> > 1) the document that is signed is unambiguous and its
> semantics says
> > that the signature means XXX.
> >
> > 2) a signed attribute (using the CMS language) is signed in
> addition
> > to the document and indicates a signature policy that is explicit 
> > about the meaning of all signatures performed under that
> policy (note
> > that one single meaning is possible in that case).
> >
> > 3) another signed attribute (using the CMS language) is signed in 
> > addition to the document and the previous attribute. It
> indicates the
> > type of commitment being made under the signature policy for that 
> > signature (note that multiple meanings are possible in that case).
> >
> > As a result, the variety of meanings is NOT placed in the
> Certificate
> > Policy from the CA.
> >
> > > We can all live with the text because we have no consensus
> > on anything
> > > better.
> >
> > Fine.
> >
> > Denis
> >
> > > That doesn't rule out the faint hope that the ITU can develop a 
> > > meaningful replacement in the future.
> > >
> > > Dave
> > >
> > > "Housley, Russ" wrote:
> > > >
> > > > Dave:
> > > >
> > > > I am sorry that I replied to this thread at all.  This topic has
> > been debated
> > > > before, and the text in Son-of-RFC 2459 is the result of that
> > debate.
> > > > Obviously, everyone can live with that text because no
> objections
> > were raised
> > > > during WG Last Call or IETF Last Call.
> > > >
> > > > I am not surprised that there is not 100% agreement....
> > > >
> > > > Russ
> >
>
>
>
>






Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g44G1f415441 for ietf-pkix-bks; Sat, 4 May 2002 09:01:41 -0700 (PDT)
Received: from nymelsmtp.internet.ny.fdms.firstdata.com ([204.124.248.17]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g44G1da15437 for <[e-mail]>; Sat, 4 May 2002 09:01:39 -0700 (PDT)
Subject: RE: Meaning of Non-repudiation
To: "Santosh Chokhani" <[e-mail]>
Cc: [e-mail], "'Trevor Freeman'" <[e-mail]>, [e-mail]
X-Mailer: Lotus Notes Release 5.0.5  September 22, 2000
Message-ID: <[e-mail]>
From: [e-mail]
Date: Sat, 4 May 2002 10:00:06 -0600
X-MIMETrack: Serialize by Router on NYMELSMTP/NY/FDMS/FDC(Release 5.0.8 |June 18, 2001) at 05/04/2002 11:58:40 AM
MIME-Version: 1.0
Content-type: text/plain; charset=us-ascii
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

i still think the semantics are confusing .... rather than random
challenges ... lets say authentication vis-a-vis
approval/agreement/intention ... is much more sensible semantics from
business and/or process orientation.

an authentication could be a radius implementation sending

time-value LOGIN:

the respondent creates a PPP radius response that includes the time-value,
the entities userid and a FIPS-186 digital signature. FIPS186 digital
signature contains a random component by definition. simple authentication,
no sense of approval/agreement/intention.

 this is as opposed to something like a financial transaction or other
physical signature analog that carries with it the sense of human
approval/agreement/intention. non-repudiation is something of a legal issue
that may use something about human approval or intention as part of proving
something, An electronic device that perform digital signatures
automagically doesn't carry with it the same implicit connotation that a
physical signature does ... which requires an explicit human interaction.
The human interaction of executing a physical signature carries with it
some concept that the person, in fact intended to write the signature that
they were writing. An automagic electronic device creating digital
signatures doesn't carry with it the same connotation that the person was
explicitly involved in the execution of that specific digital signature.

>From a process standpoint involving automagic electronic digital signing
devices ... there is no difference between the signing of random bits and
the signing of data. There may be a business reason to distinquish between
signature operations on challenge information vis-a-vis signature
operations on non-random data. However, in that case, the signer should get
to contribute a field to the signed message indicating what it believes it
is signing. Since an appended certificate isn't part of the signed message
... it wouldn't directly establish what the person believed (if they even
knew) that they were signing.

Trying to load a static certificate with semantic meaning as to what a
person believed to be signing ...  for each signing operation ... leads
down this garden path that there needs to be a unique certificate for each
possible signing business case ... and since a static appended certificate
can't directly indicate what a person believe they were signing ...  then
there would also have to be a unique public/private key pair for each
possible certificate for each possible business case. Given that you can
proove that a person has only registered a public key for one and only one
type of business process, and there exists one and only unique certificate
for that public key ... specificying one and only one unique signing
business process ... then you may be able to infer that the use of a
corresponding private key with the corresponding appended certificate
indicates what type of data  the person believed they were signing.

Moving the type of (business/process) data indication (that the person
believed they were signing) out of the certificate and into the content of
the signed message  .... eliminates having to infer it from a static
appended certificate (along with the corresponding requirement of being
able to proove that a specific public/private key pair has only been
registered for a certificate with a unique business type indication).
Having a public/private key registered with multiple different certificate
business types .... or the same certificate indicating multiple possible
business uses (types of data being signed) .... creates ambiquity as to
what type of data the person believed it was signing (i.e. no longer able
to infer unique type of data the person believed it was signing based on
the business use indications in the certificates(s)).

The issue of type of data the person believed it was signing (by inferring
it from their choice of a unique signing key that  is uniquely associated
with each specific type of business data) is orthogonal to the business
process issue that may require some physical act on part of a person in
conjunction with a signing operation which can be used to infer
approval/agreement/intention for the execution of that specific digital
signature.




santosh chokhani <[e-mail]> on 5/4/2002 7:15 am wrote:

Let us call NR bit bit A and DS bit bit B.

You are welcome to show how you interpret the bits.  What I am proposing
is as follows:

A = 0, B = 0 => The public key may not be used to verify signature on
data on random challenges.

A = 1, B = 0 => The public key may be used to verify signature on data,
but not on random challenges.

A = 0, B = 1 => The public key may not be used to verify signature on
data, but can be used to verify signature on random challenges.

A = 1, B = 1 => The public key may be used to verify signature on data
and can be used to verify signature on random challenges.

I suspect of these, case "c" may be the most controversial, if any.  How
many implementations use case c and use the public key to verify the
signature on data?






Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g44DE8U12374 for ietf-pkix-bks; Sat, 4 May 2002 06:14:08 -0700 (PDT)
Received: from mtiwmhc23.worldnet.att.net (mtiwmhc23.worldnet.att.net [204.127.131.48]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g44DE7a12370 for <[e-mail]>; Sat, 4 May 2002 06:14:07 -0700 (PDT)
Received: from Chokhani ([12.91.132.79]) by mtiwmhc23.worldnet.att.net (InterMail vM.4.01.03.27 201-229-121-127-20010626) with ESMTP id <20020504131400.WTJY28245.mtiwmhc23.worldnet.att.net@Chokhani>; Sat, 4 May 2002 13:14:00 +0000
From: "Santosh Chokhani" <[e-mail]>
To: "'Trevor Freeman'" <[e-mail]>
Cc: <[e-mail]>
Subject: RE: Meaning of Non-repudiation
Date: Sat, 4 May 2002 09:15:32 -0400
Message-ID: <000901c1f36d$c5c2b020$a300a8c0@Chokhani>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.2627
Importance: Normal
In-Reply-To: <[e-mail]>
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4910.0300
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id g44DE7a12371
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Trevor:

I am not trying to define new mechanisms.  I am simply suggesting how to
differentiate between the two bits that has some technical meaning.  If
you know of any technical meaning between the two bits, let me know.

Compliant implementations that set both bits so that the same key is
used for signing data and signing challenges can continue to do so.

Thus, in order to validate if I am changing the semantics of the
implementation and/or if my proposal will fly in the face of backward
compatibility, we need to determine how the current implementations use
the two bits.

Let us call NR bit bit A and DS bit bit B.

You are welcome to show how you interpret the bits.  What I am proposing
is as follows:

A = 0, B = 0 => The public key may not be used to verify signature on
data on random challenges.

A = 1, B = 0 => The public key may be used to verify signature on data,
but not on random challenges.

A = 0, B = 1 => The public key may not be used to verify signature on
data, but can be used to verify signature on random challenges.

A = 1, B = 1 => The public key may be used to verify signature on data
and can be used to verify signature on random challenges.

I suspect of these, case "c" may be the most controversial, if any.  How
many implementations use case c and use the public key to verify the
signature on data?

-----Original Message-----
From: Trevor Freeman [mailto:[e-mail]] 
Sent: Friday, May 03, 2002 8:21 PM
To: Santosh Chokhani
Cc: [e-mail]
Subject: RE: Meaning of Non-repudiation


Santosh,
Your suggestion is not backwards compatible with the exiting standard.
If you want to introduce new ways to further restrict what can be signed
with a digital signature key then I suggest you look to the existing key
usage extension mechanisms and if you still want to define a new
mechanism justify why since those extension mechanisms are inadequate
since they were designed for such a purpose. Changing the existing
semantics of existing extensions is out of scope no matter how
inadequate those semantics may seem. Trevor



-----Original Message-----
From: Santosh Chokhani [mailto:[e-mail]] 
Sent: Friday, May 03, 2002 3:07 PM
To: Trevor Freeman; [e-mail]; 'Omer Hasret'
Cc: [e-mail]
Subject: RE: Meaning of Non-repudiation

Trevor:

How am I changing the semantics of the extension?  The extension is used
for defining which of the security services the key pair can be used
for.  I am adhere to that.  All I am doing is giving some useful
distinction between DS and NR.

If you are saying that I am providing a meaningful distinction between
the two bits and that distinction may not be backward compatible with
some commercial products, I agree.

-----Original Message-----
From: [e-mail] [mailto:[e-mail]]
On Behalf Of Trevor Freeman
Sent: Friday, May 03, 2002 4:14 PM
To: Santosh Chokhani; [e-mail]; Omer Hasret
Cc: [e-mail]
Subject: RE: Meaning of Non-repudiation



Santosh,
Either you are proposing changing the semantics of the existing
definition of the key usage extension, or you are advocating a policy
which may be implanted. The first is a none starter - you don't change
the semantics of existing extensions. The second is perfectly acceptable
policy that you may want follow, but is not mandatory on all parties.
Trevor

-----Original Message-----
From: Santosh Chokhani [mailto:[e-mail]] 
Sent: Friday, May 03, 2002 10:56 AM
To: [e-mail]; 'Omer Hasret'
Cc: [e-mail]
Subject: RE: Meaning of Non-repudiation


I think EKU provide application specific refinement, e.g., code signing.

But, key usage has the basic operations.  The distinction between
signing a challenge and data that you take some ownership to belongs in
key usage.

-----Original Message-----
From: [e-mail] [mailto:[e-mail]]
On Behalf Of [e-mail]
Sent: Friday, May 03, 2002 9:43 AM
To: Omer Hasret
Cc: 'Santosh Chokhani'; [e-mail]
Subject: RE: Meaning of Non-repudiation






"Extended Key Usage" is meant for that purpose, isn't it ? Or "Policy
Identifier" could provide this kind of information.
|------------------------+------------------------+---------------------
---|
|                        |   "Omer Hasret"        |
|
|                        |   <[e-mail]>  |           To:
|
|                        |                        |
<Olaf.Schlueter@secar|
|                        |   03.05.2002 14:53     |   tis.com>,
|
|                        |                        |
<[e-mail]>  |
|                        |                        |           cc:
|
|                        |                        |   "'Santosh
Chokhani'" |
|                        |                        |
<[e-mail]|
|                        |                        |   m>
|
|                        |                        |           Subject:
|
|                        |                        |   RE: Meaning of
|
|                        |                        |   Non-repudiation
|
|------------------------+------------------------+---------------------
---|








Olaf,

See below,

> -----Original Message-----
> From: [e-mail] 
> [mailto:[e-mail]] On Behalf Of 
> [e-mail]
> Sent: vendredi 3 mai 2002 12:43
> To: [e-mail]
> Cc: 'Santosh Chokhani'; [e-mail];
> [e-mail]; 'Trevor Freeman'
> Subject: RE: Meaning of Non-repudiation
>
>
>
>
>
>
> The NR bit in a certifiicate does not proof anything. It is a 
> statement made by the signer and/or the CA about the intended use of 
> the key. KeyUsage bits are currently used to support key pair 
> separation for the three basic use cases of public key cryptography: 
> encryption, authentication and digital signing. Most application 
> choose public key certificates needed for a certain type of operation 
> based on the keyUsage
> bits: with keyEncipherment to encrypt a message, with digitalSignature

> to verify the response to a challenge for authentication, or to verify

> signature made on e-mail. These two bits are essential (and
> sufficient) to support key pair seperation per RSA operation
> capability (decryption or
> signing) of the private key as the RSA operation capabilities of 
> private keys may be restricted by hardware implementation (i.e. a 
> crypto processor card may be configured to allow only signing with a 
> private key, or decryption, and check padding and format of 
> input/output before and after the operation or even include part or 
> all of the hashing procedure).
>
> If one wants to ensure that a private key is only used to sign data, 
> but not to sign an arbitrary challenge, (which practically means "can 
> be used within S/MIME but not within
> SSL")  which is the case e.g. within the signature law compliant use
> cases, a new bit is needed to clearly distinguish between public keys 
> used for authentication and for signature verification. In all specs 
> that adress this seperation the nonRepudiation bit is used for that 
> purpose. And I cannot see a need for changing that..

Therefore you say that the NR bit is set when we want to use the
certificate for "digital signature" which actually is just the
authentication of the sender for S/MIME messages and nothing else. No
one is trying to change this. However, everyone should know that this
does not prove anything. So if you give different CPs the freedom of
loading whatever meaning they want to the NR bit, there will be
problems.

Besides, I also see the need for another bit which actually states that
"I have read and agree with the content of this message" like real
signatures. (I think the DS bit can be used for this. But everyone
should have exactly the same understanding of these bits.)




> |------------------------+------------------------+-----------
-------------|
> |                        |   "Omer Hasret"        |
>              |
> |                        |   <[e-mail]>  |
> To:          |
> |                        |   Sent by:             |
> "'Trevor Freeman'"   |
> |                        |   owner-ietf-pkix@mail.|
> <[e-mail]|
> |                        |   imc.org              |
> osoft.com>, "'Santosh|
> |                        |                        |
> Chokhani'"           |
> |                        |   03.05.2002 10:52     |
> <[e-mail]|
> |                        |                        |   m>
>              |
> |                        |                        |
> cc:          |
> |                        |                        |
> <[e-mail]>  |
> |                        |                        |
> Subject:     |
> |                        |                        |   RE:
> Meaning of       |
> |                        |                        |
> Non-repudiation      |
> |------------------------+------------------------+-----------
-------------|
>
>
>
>
>
>
>
>
> Trevor, Santosh,
>
> It is certain that everybody will need some means of proving that he 
> is the originator of a specific message, document, whatever. And when 
> we talk about the NR bit on a certificate, I believe the only thing 
> this proves is that a specific data is signed by the holder of this 
> certificate. This never means that the signer agrees with the content 
> or not. Therefore there is no need to load other meanings to this one 
> bit changing from policy to policy. Just standardize its use only for 
> authentication and let others who want to implement their own NR 
> systems do it by other means. (Some ways to do this have been posted 
> on the list a day or two days ago.) And I really do not think this as 
> a "dictation" because you don't have to use that bit just because its 
> name is NR.
>
> >
> >
> >
> > Hi Santosh,
> > That still sounds like a policy decision.
> > A signature over an SSL challenge is potentially just as
> valid a piece
> > of a NR jigsaw puzzle as any other signature. Why are we dictating 
> > what someone wants as a NR process? If you want to build a system 
> > where NR signatures only occur over documents - fine by me,
> but don't
> > dictate how I build my NR system. Trevor
> >
> > -----Original Message-----
> > From: Santosh Chokhani [mailto:[e-mail]]
> > Sent: Thursday, May 02, 2002 2:03 PM
> > To: Trevor Freeman; 'Denis Pinkas'; 'David P. Kemp'
> > Cc: [e-mail]
> > Subject: RE: Meaning of Non-repudiation
> >
> > Trevor:
> >
> > I also made a resolution long time back when ABA started a
> debate on
> > this.  But, I also broke it.
> >
> > I do think that there is a value in SSL case to say that I am not 
> > owning up to signature (as attesting to something) except I
> signed a
> > challenge. Thus, subscriber (possessor of the private key)
> should be
> > able to use a separate key so that he can claim he simply signed a 
> > random challenge.
> >
> > -----Original Message-----
> > From: [e-mail] 
> > [mailto:[e-mail]]
> > On Behalf Of Trevor Freeman
> > Sent: Thursday, May 02, 2002 2:53 PM
> > To: Denis Pinkas; David P. Kemp
> > Cc: [e-mail]
> > Subject: RE: Meaning of Non-repudiation
> >
> >
> >
> > I am breaking one of my New Year resolutions by mailing on
> this topic,
> > but here goes...
> >
> > Signing anything is always a challenge to prove position of
> a private
> > key to authenticate whether it's in the context of a
> protocol like SSL
> > or over a SMIME message. Technically all we can say is the
> signature
> > occurred. The intent behind why the signature occurred is
> beyond the
> > scope of this discussion. Use of certificates with the NR
> bit asserted
> > is ultimately a matter of local policy on what constitutes usage as 
> > part of a non-repudiation service since two organisations could have

> > two separate non repudiation serves where one requires a NR 
> > signature as part of an SSL session, and the other only wants NR 
> > signatures over SMIME messages.
> >
> > Never in the course of IETF has history so much been written over 
> > something so small.
> >
> > Trevor
> >
> > -----Original Message-----
> > From: Denis Pinkas [mailto:[e-mail]]
> > Sent: Thursday, May 02, 2002 2:27 AM
> > To: David P. Kemp
> > Cc: [e-mail]
> > Subject: Re: Meaning of Non-repudiation
> >
> >
> > Dave,
> >
> > > Russ,
> > >
> > > I believe we are all sorry to resurrect this topic.
> > > But it is currently the subject of an X.509 defect,
> >
> > Not exactly. Someone would like this topic to be the subject of an 
> > X.509 defect report, but this is is currently *not* the
> subject of an
> > X.509 defect that has been officially raised.
> >
> > > and if the text of X.509 eventually changes in a way
> > > that is incompatible with Son-of-2459, then Grandson-of-2459 will 
> > > need to take that into consideration.
> >
> > Very unlikely to happen.
> >
> > Additional *explanations* without changing the meaning
> > *could* be provided and we are (nearly) all saying the same thing 
> > using different words. Santosh in a subsequent e-mail
> provided one of
> > these
> > explanations:
> >
> > "In my analysis, DS means you are signing some challenge to prove 
> > possession of a private key and thus authenticate yourself whereas 
> > with NR you are saying that I know what this data is and I
> am signing
> > it."
> >
> > I would add that a certificate with the the DS bit set can also be 
> > used to authenticate data (this does not mean that the
> signer has read
> > the data).
> >
> > Now, there are cases where, beyond the fact that the signer
> did know
> > what he signed, he wants to say exactly what its signature means.
> >
> > This can be achieved using three ways:
> >
> > 1) the document that is signed is unambiguous and its
> semantics says
> > that the signature means XXX.
> >
> > 2) a signed attribute (using the CMS language) is signed in
> addition
> > to the document and indicates a signature policy that is explicit 
> > about the meaning of all signatures performed under that
> policy (note
> > that one single meaning is possible in that case).
> >
> > 3) another signed attribute (using the CMS language) is signed in 
> > addition to the document and the previous attribute. It
> indicates the
> > type of commitment being made under the signature policy for that 
> > signature (note that multiple meanings are possible in that case).
> >
> > As a result, the variety of meanings is NOT placed in the
> Certificate
> > Policy from the CA.
> >
> > > We can all live with the text because we have no consensus
> > on anything
> > > better.
> >
> > Fine.
> >
> > Denis
> >
> > > That doesn't rule out the faint hope that the ITU can develop a 
> > > meaningful replacement in the future.
> > >
> > > Dave
> > >
> > > "Housley, Russ" wrote:
> > > >
> > > > Dave:
> > > >
> > > > I am sorry that I replied to this thread at all.  This topic has
> > been debated
> > > > before, and the text in Son-of-RFC 2459 is the result of that
> > debate.
> > > > Obviously, everyone can live with that text because no
> objections
> > were raised
> > > > during WG Last Call or IETF Last Call.
> > > >
> > > > I am not surprised that there is not 100% agreement....
> > > >
> > > > Russ
> >
>
>
>
>






Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g44BuC810756 for ietf-pkix-bks; Sat, 4 May 2002 04:56:12 -0700 (PDT)
Received: from mailout10.sul.t-online.com (mailout10.sul.t-online.com [194.25.134.21]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g44BuBa10752 for <[e-mail]>; Sat, 4 May 2002 04:56:11 -0700 (PDT)
Received: from fwd03.sul.t-online.de  by mailout10.sul.t-online.com with smtp  id 173y94-0006j9-04; Sat, 04 May 2002 13:56:10 +0200
Received: from junker.stroeder.com (520010731148-0001@[217.1.21.189]) by fmrl03.sul.t-online.com with esmtp id 173y91-0a0a4uC; Sat, 4 May 2002 13:56:07 +0200
Received: from stroeder.com (junker [127.0.0.1]) by junker.stroeder.com (Postfix) with ESMTP id 44124157869; Sat,  4 May 2002 13:33:10 +0200 (CEST)
Message-ID: <[e-mail]>
Date: Sat, 04 May 2002 13:33:10 +0200
From: =?ISO-8859-1?Q?Michael_Str=F6der?= <[e-mail]>
Reply-To: [e-mail]
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.0+) Gecko/20020502
X-Accept-Language: de-DE, de, en
MIME-Version: 1.0
To: [e-mail]
Cc: pkix <[e-mail]>
Subject: Re: I-D ACTION:draft-ietf-pkix-warranty-extn-00.txt
References: <[e-mail]>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
X-Sender: [e-mail]
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Alice Sturgeon wrote:
> While I agree with Yuriy that warranty provisions need to be covered in
> contract, the existence of an extension in the certificate can serve to
> highlight the warranty provisions and to facilitate risk management through
> automation of certain decisions.

Sorry, but this assumption about "automation of certain decisions" 
is totally wrong. You should talk to a financial worker about how 
complex warranty/credit decisions are - not to speak of resolving 
conflicts with claims, privacy problems etc. It simply does not 
work in such a simple automatic way.
Been there, *not* done that. ;-)

Personally I don't want to hold anybody back from defining such an 
extension. If someone has spare cycles he/she can do that for 
personal fun but should not be disappointed if it turns out not be 
useful at all for anything serious.

Ciao, Michael.



Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g440P3O27020 for ietf-pkix-bks; Fri, 3 May 2002 17:25:03 -0700 (PDT)
Received: from mail3.microsoft.com (mail3.microsoft.com [131.107.3.123]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g440P1a27016 for <[e-mail]>; Fri, 3 May 2002 17:25:01 -0700 (PDT)
Received: from INET-VRS-03.redmond.corp.microsoft.com ([157.54.5.27]) by mail3.microsoft.com with Microsoft SMTPSVC(5.0.2195.4905); Fri, 3 May 2002 17:24:59 -0700
Received: from 157.54.5.25 by INET-VRS-03.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Fri, 03 May 2002 17:24:59 -0700
Received: from red-imc-02.redmond.corp.microsoft.com ([157.54.9.107]) by inet-hub-03.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.4905); Fri, 3 May 2002 17:24:59 -0700
Received: from win-imc-02.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.84]) by red-imc-02.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.4905); Fri, 3 May 2002 17:24:59 -0700
Received: from win-msg-01.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.52]) by win-imc-02.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3590.0); Fri, 3 May 2002 17:21:08 -0700
X-MimeOLE: Produced By Microsoft Exchange V6.0.6177.0
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Subject: RE: Meaning of Non-repudiation
Date: Fri, 3 May 2002 17:21:07 -0700
Message-ID: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: Meaning of Non-repudiation
Thread-Index: AcHy7iC/xkN+2gVFT/i8CWjCoVwJrgAD233g
From: "Trevor Freeman" <[e-mail]>
To: "Santosh Chokhani" <[e-mail]>
Cc: <[e-mail]>
X-OriginalArrivalTime: 04 May 2002 00:21:08.0357 (UTC) FILETIME=[9633AB50:01C1F301]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id g440P1a27017
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Santosh,
Your suggestion is not backwards compatible with the exiting standard. If you want to introduce new ways to further restrict what can be signed with a digital signature key then I suggest you look to the existing key usage extension mechanisms and if you still want to define a new mechanism justify why since those extension mechanisms are inadequate since they were designed for such a purpose. Changing the existing semantics of existing extensions is out of scope no matter how inadequate those semantics may seem.
Trevor



-----Original Message-----
From: Santosh Chokhani [mailto:[e-mail]] 
Sent: Friday, May 03, 2002 3:07 PM
To: Trevor Freeman; [e-mail]; 'Omer Hasret'
Cc: [e-mail]
Subject: RE: Meaning of Non-repudiation

Trevor:

How am I changing the semantics of the extension?  The extension is used
for defining which of the security services the key pair can be used
for.  I am adhere to that.  All I am doing is giving some useful
distinction between DS and NR.

If you are saying that I am providing a meaningful distinction between
the two bits and that distinction may not be backward compatible with
some commercial products, I agree.

-----Original Message-----
From: [e-mail] [mailto:[e-mail]]
On Behalf Of Trevor Freeman
Sent: Friday, May 03, 2002 4:14 PM
To: Santosh Chokhani; [e-mail]; Omer Hasret
Cc: [e-mail]
Subject: RE: Meaning of Non-repudiation



Santosh,
Either you are proposing changing the semantics of the existing
definition of the key usage extension, or you are advocating a policy
which may be implanted. The first is a none starter - you don't change
the semantics of existing extensions. The second is perfectly acceptable
policy that you may want follow, but is not mandatory on all parties.
Trevor

-----Original Message-----
From: Santosh Chokhani [mailto:[e-mail]] 
Sent: Friday, May 03, 2002 10:56 AM
To: [e-mail]; 'Omer Hasret'
Cc: [e-mail]
Subject: RE: Meaning of Non-repudiation


I think EKU provide application specific refinement, e.g., code signing.

But, key usage has the basic operations.  The distinction between
signing a challenge and data that you take some ownership to belongs in
key usage.

-----Original Message-----
From: [e-mail] [mailto:[e-mail]]
On Behalf Of [e-mail]
Sent: Friday, May 03, 2002 9:43 AM
To: Omer Hasret
Cc: 'Santosh Chokhani'; [e-mail]
Subject: RE: Meaning of Non-repudiation






"Extended Key Usage" is meant for that purpose, isn't it ? Or "Policy
Identifier" could provide this kind of information.
|------------------------+------------------------+---------------------
---|
|                        |   "Omer Hasret"        |
|
|                        |   <[e-mail]>  |           To:
|
|                        |                        |
<Olaf.Schlueter@secar|
|                        |   03.05.2002 14:53     |   tis.com>,
|
|                        |                        |
<[e-mail]>  |
|                        |                        |           cc:
|
|                        |                        |   "'Santosh
Chokhani'" |
|                        |                        |
<[e-mail]|
|                        |                        |   m>
|
|                        |                        |           Subject:
|
|                        |                        |   RE: Meaning of
|
|                        |                        |   Non-repudiation
|
|------------------------+------------------------+---------------------
---|








Olaf,

See below,

> -----Original Message-----
> From: [e-mail]
> [mailto:[e-mail]] On Behalf Of 
> [e-mail]
> Sent: vendredi 3 mai 2002 12:43
> To: [e-mail]
> Cc: 'Santosh Chokhani'; [e-mail]; 
> [e-mail]; 'Trevor Freeman'
> Subject: RE: Meaning of Non-repudiation
>
>
>
>
>
>
> The NR bit in a certifiicate does not proof anything. It is a
> statement made by the signer and/or the CA about the intended use of 
> the key. KeyUsage bits are currently used to support key pair 
> separation for the three basic use cases of public key cryptography: 
> encryption, authentication and digital signing. Most application 
> choose public key certificates needed for a certain type of operation 
> based on the keyUsage
> bits: with keyEncipherment to encrypt a message, with digitalSignature

> to verify the response to a challenge for authentication, or to verify

> signature made on e-mail. These two bits are essential (and
> sufficient) to support key pair seperation per RSA operation 
> capability (decryption or
> signing) of the private key as the RSA operation capabilities of 
> private keys may be restricted by hardware implementation (i.e. a 
> crypto processor card may be configured to allow only signing with a 
> private key, or decryption, and check padding and format of 
> input/output before and after the operation or even include part or 
> all of the hashing procedure).
>
> If one wants to ensure that a private key is only used to sign data,
> but not to sign an arbitrary challenge, (which practically means "can 
> be used within S/MIME but not within
> SSL")  which is the case e.g. within the signature law compliant use 
> cases, a new bit is needed to clearly distinguish between public keys 
> used for authentication and for signature verification. In all specs 
> that adress this seperation the nonRepudiation bit is used for that 
> purpose. And I cannot see a need for changing that..

Therefore you say that the NR bit is set when we want to use the
certificate for "digital signature" which actually is just the
authentication of the sender for S/MIME messages and nothing else. No
one is trying to change this. However, everyone should know that this
does not prove anything. So if you give different CPs the freedom of
loading whatever meaning they want to the NR bit, there will be
problems.

Besides, I also see the need for another bit which actually states that
"I have read and agree with the content of this message" like real
signatures. (I think the DS bit can be used for this. But everyone
should have exactly the same understanding of these bits.)




> |------------------------+------------------------+-----------
-------------|
> |                        |   "Omer Hasret"        |
>              |
> |                        |   <[e-mail]>  |
> To:          |
> |                        |   Sent by:             |
> "'Trevor Freeman'"   |
> |                        |   owner-ietf-pkix@mail.|
> <[e-mail]|
> |                        |   imc.org              |
> osoft.com>, "'Santosh|
> |                        |                        |
> Chokhani'"           |
> |                        |   03.05.2002 10:52     |
> <[e-mail]|
> |                        |                        |   m>
>              |
> |                        |                        |
> cc:          |
> |                        |                        |
> <[e-mail]>  |
> |                        |                        |
> Subject:     |
> |                        |                        |   RE:
> Meaning of       |
> |                        |                        |
> Non-repudiation      |
> |------------------------+------------------------+-----------
-------------|
>
>
>
>
>
>
>
>
> Trevor, Santosh,
>
> It is certain that everybody will need some means of proving that he
> is the originator of a specific message, document, whatever. And when 
> we talk about the NR bit on a certificate, I believe the only thing 
> this proves is that a specific data is signed by the holder of this 
> certificate. This never means that the signer agrees with the content 
> or not. Therefore there is no need to load other meanings to this one 
> bit changing from policy to policy. Just standardize its use only
> for authentication and let others who want to implement their
> own NR systems do it by other means. (Some ways to do this
> have been posted on the list a day or two days ago.) And I
> really do not think this as a "dictation" because you don't
> have to use that bit just because its name is NR.
>
> >
> >
> >
> > Hi Santosh,
> > That still sounds like a policy decision.
> > A signature over an SSL challenge is potentially just as
> valid a piece
> > of a NR jigsaw puzzle as any other signature. Why are we dictating
> > what someone wants as a NR process? If you want to build a system 
> > where NR signatures only occur over documents - fine by me,
> but don't
> > dictate how I build my NR system. Trevor
> >
> > -----Original Message-----
> > From: Santosh Chokhani [mailto:[e-mail]]
> > Sent: Thursday, May 02, 2002 2:03 PM
> > To: Trevor Freeman; 'Denis Pinkas'; 'David P. Kemp'
> > Cc: [e-mail]
> > Subject: RE: Meaning of Non-repudiation
> >
> > Trevor:
> >
> > I also made a resolution long time back when ABA started a
> debate on
> > this.  But, I also broke it.
> >
> > I do think that there is a value in SSL case to say that I am not
> > owning up to signature (as attesting to something) except I
> signed a
> > challenge. Thus, subscriber (possessor of the private key)
> should be
> > able to use a separate key so that he can claim he simply signed a
> > random challenge.
> >
> > -----Original Message-----
> > From: [e-mail]
> > [mailto:[e-mail]]
> > On Behalf Of Trevor Freeman
> > Sent: Thursday, May 02, 2002 2:53 PM
> > To: Denis Pinkas; David P. Kemp
> > Cc: [e-mail]
> > Subject: RE: Meaning of Non-repudiation
> >
> >
> >
> > I am breaking one of my New Year resolutions by mailing on
> this topic,
> > but here goes...
> >
> > Signing anything is always a challenge to prove position of
> a private
> > key to authenticate whether it's in the context of a
> protocol like SSL
> > or over a SMIME message. Technically all we can say is the
> signature
> > occurred. The intent behind why the signature occurred is
> beyond the
> > scope of this discussion. Use of certificates with the NR
> bit asserted
> > is ultimately a matter of local policy on what constitutes usage as
> > part of a non-repudiation service since two organisations could have

> > two separate non repudiation serves where one requires a NR
> > signature as part of an SSL session, and the other only wants NR 
> > signatures over SMIME messages.
> >
> > Never in the course of IETF has history so much been written over
> > something so small.
> >
> > Trevor
> >
> > -----Original Message-----
> > From: Denis Pinkas [mailto:[e-mail]]
> > Sent: Thursday, May 02, 2002 2:27 AM
> > To: David P. Kemp
> > Cc: [e-mail]
> > Subject: Re: Meaning of Non-repudiation
> >
> >
> > Dave,
> >
> > > Russ,
> > >
> > > I believe we are all sorry to resurrect this topic.
> > > But it is currently the subject of an X.509 defect,
> >
> > Not exactly. Someone would like this topic to be the subject of an
> > X.509 defect report, but this is is currently *not* the
> subject of an
> > X.509 defect that has been officially raised.
> >
> > > and if the text of X.509 eventually changes in a way
> > > that is incompatible with Son-of-2459, then Grandson-of-2459 will
> > > need to take that into consideration.
> >
> > Very unlikely to happen.
> >
> > Additional *explanations* without changing the meaning
> > *could* be provided and we are (nearly) all saying the same thing
> > using different words. Santosh in a subsequent e-mail
> provided one of
> > these
> > explanations:
> >
> > "In my analysis, DS means you are signing some challenge to prove
> > possession of a private key and thus authenticate yourself whereas 
> > with NR you are saying that I know what this data is and I
> am signing
> > it."
> >
> > I would add that a certificate with the the DS bit set can also be
> > used to authenticate data (this does not mean that the
> signer has read
> > the data).
> >
> > Now, there are cases where, beyond the fact that the signer
> did know
> > what he signed, he wants to say exactly what its signature means.
> >
> > This can be achieved using three ways:
> >
> > 1) the document that is signed is unambiguous and its
> semantics says
> > that the signature means XXX.
> >
> > 2) a signed attribute (using the CMS language) is signed in
> addition
> > to the document and indicates a signature policy that is explicit
> > about the meaning of all signatures performed under that
> policy (note
> > that one single meaning is possible in that case).
> >
> > 3) another signed attribute (using the CMS language) is signed in
> > addition to the document and the previous attribute. It
> indicates the
> > type of commitment being made under the signature policy for that
> > signature (note that multiple meanings are possible in that case).
> >
> > As a result, the variety of meanings is NOT placed in the
> Certificate
> > Policy from the CA.
> >
> > > We can all live with the text because we have no consensus
> > on anything
> > > better.
> >
> > Fine.
> >
> > Denis
> >
> > > That doesn't rule out the faint hope that the ITU can develop a
> > > meaningful replacement in the future.
> > >
> > > Dave
> > >
> > > "Housley, Russ" wrote:
> > > >
> > > > Dave:
> > > >
> > > > I am sorry that I replied to this thread at all.  This topic has
> > been debated
> > > > before, and the text in Son-of-RFC 2459 is the result of that
> > debate.
> > > > Obviously, everyone can live with that text because no
> objections
> > were raised
> > > > during WG Last Call or IETF Last Call.
> > > >
> > > > I am not surprised that there is not 100% agreement....
> > > >
> > > > Russ
> >
>
>
>
>






Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g43MRXO24179 for ietf-pkix-bks; Fri, 3 May 2002 15:27:33 -0700 (PDT)
Received: from mx1.magmacom.com (mx1.magmacom.com [206.191.0.217]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g43MRWa24174 for <[e-mail]>; Fri, 3 May 2002 15:27:32 -0700 (PDT)
Received: from mail3.magma.ca (mail3.magma.ca [206.191.0.221]) by mx1.magmacom.com (Magma's Mail Server) with ESMTP id g43MRTSF016917; Fri, 3 May 2002 18:27:29 -0400 (EDT)
Received: from asturgeonpc (ottawa-dial-64-26-139-31.d-ip.magma.ca [64.26.139.31]) by mail3.magma.ca (Magma's Mail Server) with SMTP id g43MRNWY011826; Fri, 3 May 2002 18:27:26 -0400 (EDT)
Reply-To: <[e-mail]>
From: "Alice Sturgeon" <[e-mail]>
To: "Yuriy Dzambasow" <[e-mail]>, "Housley, Russ" <[e-mail]>, "Denis Pinkas" <[e-mail]>, "Al Arsenault" <[e-mail]>
Cc: "pkix" <[e-mail]>
Subject: RE: I-D ACTION:draft-ietf-pkix-warranty-extn-00.txt
Date: Fri, 3 May 2002 18:36:00 -0400
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.2911.0)
Importance: Normal
In-Reply-To: <000401c1f1f3$4d28c8f0$c06fa8c0@DL20860>
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Hi folks,
While I agree with Yuriy that warranty provisions need to be covered in
contract, the existence of an extension in the certificate can serve to
highlight the warranty provisions and to facilitate risk management through
automation of certain decisions.  For a third party, it can be useful to
have salient information right in the certificate, where it is clearly seen,
and a decision more easily made.  The extension can point to terms and
conditions (T&C), in much the same manner that a certificate contains a
pointer to the CP and CPS.  While doing so, the certificate also contains
the most salient points of CP/CPS in the various fields, such as validity
period, usage, etc (I won't mention non-repudiation!) - the most important
aspects of the system and applications, right up front and visible for
users.  The warranty extension can serve this same purpose.  The analogy was
made on the ABA list about warranties for tires, and that this proposed
extension was analogous to the warranty being found on the inside of the
tire.  A more correct analogous statement would be that the warranty appears
on the *outside* of the tire for all to see.
It is unrealistic to expect an RP to go through contractual T&C when the RP
wants to rely on a certificate.  It is much more realistic, more practical,
to put the most salient points right into the certificate.  No need, then,
to go searching for a related document, nor to search through the T&C
legalese.  Yet the contractual T&C are not absent but clearly referenced.
Note that the very first statement in the I-D Abstract is: "This document
describes a certificate extension to explicitly state the warranty offered
by a CA for the certificate containing the extension."  Key word, I think,
is "explicitly".
Previous contributions have also noted the similarities of this proposed
extension to EU Directive 1999/93/EC, consequent IETF RFC 3039, and ETSI TS
101 862, concerning express statements of limitations on value of
transactions and consequent limitation of liability of a CA (for
transactions exceeding the express limitation).  Perhaps some language
clarity is in order to address the comments concerning warranty provision
versus warranty disclaimer, and warranty in favour of the subscriber versus
the meaning of the warranty to the relying party.  Assuming successful
clarification, the proposed extension can be useful, as a succinct statement
to those involved in the transaction, to highlight warranty protection to
all parties.
Some suggested changes:
Introduction, para. 2:
The certificate warranty provides an extended monetary coverage for the
legal liability of the CA, in favor of the subscriber. [Delete ", in favor
of the subscriber".] The certificate warranty primarily concerns the use,
storage, and reliance on a certificate by a third party and the CA. [Change
to: "by a subscriber, a relying party and the CA".]
Introduction, para. 3:
Add a new last sentence: "A relying party may have redress from a CA
depending on the conditions for such redress expressed in either the CA's
Certificate Policy or the CA's insurance policy, or both.  Where the relying
party and the subscriber are the same entity, then the terms and conditions
of the insurance policy clearly cover the entity; however, where the relying
party is not a subscriber to the CA, then any redress will be available only
through the conditions expressed in the CP and the CA's insurance policy, if
any.  Risk for a non-subscriber relying party may be reduced by the presence
of a warranty extension with an explicit warranty stated.  The warranty
extension in the process automates this aspect of risk management for the
relying party (whether subscriber or non-subscriber)."

It has been noted that the overall intent is to enhance trust in the
transactions and to facilitate automation of certain risk management
decisions.  Look at the proposed syntax for the extension:  first is a
choice between no warranty provided and explicit warranty.  If the choice is
the first - no warranty provided - then that immediately tells relying
parties several things, amongst them, first, that this cannot be a Qualified
Certificate as proposed by the EU Directive and defined by 3039.  A
certificate that contains the second choice should be recognizably more
trustworthy, and may be sufficient for a relying party to trust it.


Alice Sturgeon
Chair
Canadian Advisory Committee - Information Technology Security
ISO/IEC JTC1 SC 27
and
System Policy Architect
SPYRUS
Phone:     [phone]
Cell:         613-291-0331



-----Original Message-----
From: [e-mail] [mailto:[e-mail]]On
Behalf Of Yuriy Dzambasow
Sent: May 2, 2002 12:06 PM
To: Housley, Russ; Denis Pinkas; Al Arsenault
Cc: pkix
Subject: Re: I-D ACTION:draft-ietf-pkix-warranty-extn-00.txt


Russ:

----- Original Message -----
From: "Housley, Russ" <[e-mail]>
To: "Denis Pinkas" <[e-mail]>; "Al Arsenault"
<[e-mail]>
Cc: "pkix" <[e-mail]>
Sent: Thursday, May 02, 2002 9:44 AM
Subject: Re: I-D ACTION:draft-ietf-pkix-warranty-extn-00.txt


>
> Al & Denis:
>
> Maybe the language needs to be made more clear, but that is not what I
> think this proposed extension is about.  The second paragraph in the
> Introduction says:
>
>    The certificate warranty provides an extended monetary coverage for
>    the legal liability of the CA, in favor of the subscriber.  The
>    certificate warranty primarily concerns the use, storage, and reliance
>    on a certificate by a third party and the CA.  It is common for a CA
>    to limit liability by establishing reliance limits on the use of a
>    certificate.  It is not uncommon for a CA to attempt through
>    contractual means to exclude its liability entirely.  However, this
>    has the effect of undermining the confidence that commerce requires to
>    gainfully use certificates.
>
> I think that this means the third party (the RP in your notes) can go to
> the CA to file a claim against the warranty.  The RP says: "I relied on
the
> certificate that you issued, and I was harmed, therefore I expect to be
> compensated."  The warranty extension will tell the RP the extent of the
> possible compensation.  Knowing this up front, the RP can decide whether
to
> enter into a business transaction or not.  The whole point, as I see it,
is
> to allow automation of as many of the risk-related decisions as possible.

I still think contracts are the more effective way of handling this.  Then
again, and as Al said, since this is an optional extension, I'm not going to
argue it much.  If other folks think its useful...fine.

Yuriy




>
> Russ
>
> At 07:24 PM 5/1/2002 -0400, Al Arsenault wrote:
> >The more I think about this, the more I sort of agree with Denis.  It's
not
> >clear to me what good this extension is.  It indicates a relationship
> >between a subscriber and a CA, NOT an RP and a CA or an RP and a
subscriber.
> >Therefore, what good is it?  Why do I as an RP care - or even have to
know -
> >for how much a CA will indemnify the subscriber if something goes wrong?
> >That's the kind of thing that can easily be covered in some sort of
contract
> >between the CA and subscriber, not in the certificate.
> >
> >This extension may give me as an RP a hint that "well, the CA has at
least
> >this much insurance/cash in the bank, and is willing to fork it over to
the
> >subscriber if need be, so I can start my lawsuit by asking for at least
this
> >much in damages". But I can't see any real use to it.
> >
> >So I'm not a big fan of pushing this forward; I think it will likely
cause
> >more confusion than anything else among the non-PKI-astute.
> >
> >All that being said, since it's all optional and I don't actually have to
> >implement it, I really won't fight too strongly against it, if somebody
else
> >thinks that there's an actual use case.
> >
> >         Al Arsenault
> >
> >----- Original Message -----
> >From: "Housley, Russ" <[e-mail]>
> >To: "Denis Pinkas" <[e-mail]>
> >Cc: "pkix" <[e-mail]>
> >Sent: Wednesday, May 01, 2002 1:17 PM
> >Subject: Re: I-D ACTION:draft-ietf-pkix-warranty-extn-00.txt
> >
> >
> > >
> > > Denis:
> > >
> > > It seems to me that the warranty in this case does have to do with the
> > > relationship between the CA and the subscriber.  If a replying party
is
> > > harmed, they will go after the CA (assuming that the subscriber has
> > > vanished or is a less attractive target).  The CA will likely have
> > > insurance to back up the warranty, and this extension indication the
terms
> > > of that warranty.
> > >
> > > Russ
> > >
> > > At 02:59 PM 4/30/2002 +0200, Denis Pinkas wrote:
> > >
> > > >Comments on the Warranty certificate extension
> > > >
> > > >Before looking at the technical details of the warranty, it is
important
> >to
> > > >make sure that practical cases can be solved. Since a warranty is
> >mentioned,
> > > >legal considerations cannot be left aside.
> > > >
> > > >The current proposal states that "the certificate warranty provides
an
> > > >extended monetary coverage for the legal liability of the CA, in
favor of
> > > >the *subscriber*".
> > > >
> > > >The problem is that the warranty should also apply in favor of one or
> >more
> > > >*relying parties*. Are the relaying parties going to complain to the
> > > >subscriber only and will then the subscriber makes arrangement with
the
> >CA
> > > >only ?
> > > >
> > > >For the extreme cases where there are, let us say, 10.000 plaintiffs
each
> > > >one claiming for a damage of 1.000 $ and when the upper limit of the
> > > >warranty will be altogether, for example, 100.000 $ (called
"aggregated
> > > >damage" in the draft). What would be the criteria to reimburse the
> > > >plaintiffs ? Since the total damage is 10.000.000 $, are only 10 % of
the
> > > >first plaintiffs to be reimbursed ? or will a random choice will be
done
> > > >among the 10.000 plaintiffs ? Since the warranty is for the
subscriber
> >and
> > > >not for the plaintiffs, will the subscriber deal with the 10.000
> >plaintiffs
> > > >directly ?
> > > >
> > > >The second point is that no conditions to get advantage of the
warranty
> >are
> > > >mentioned. Should a relying party only check the revocation status of
the
> > > >certificate ? Should the relying party check the certificate against
a
> > > >validation policy ? What kind of proof of its checking should the
relying
> > > >party present to the CA;  or to the subscriber ? An OSCP response? A
DPV
> > > >response ? Should the details of the transaction involved be provided
?
> > > >
> > > >For all these reasons, the difficulty of use of such an extension is
very
> > > >questionable.
> > > >
> > > >Now, it should be noticed that such a similar extension has already
been
> > > >defined in ETSI TS 101 862. This extension takes advantage of the
> > > >qcStatement defined in RFC 3039 and specifies a statement regarding
> >limits
> > > >on the value of transactions.
> > > >
> > > >This optional statement contains:
> > > >
> > > >- an identifier of this statement (represented by an OID);
> > > >- a monetary value expressing the limit on the value of transactions.
> > > >
> > > >This statement is a statement by the issuer which impose a limitation
on
> >the
> > > >value of transaction for which this certificate can be used to the
> >specified
> > > >amount (MonetaryValue), according to the Directive 1999/93/EC of the
> > > >European Parliament and of the Council of 13 December 1999 on a
Community
> > > >framework for electronic signatures, as implemented in the law of the
> > > >country specified in the issuer field of this certificate.
> > > >
> > > >In fact the Directive is requiring (in Annex I) a field to specify
> >"limits
> > > >on the value of transactions for which the certificate can be used,
if
> > > >applicable". The reason for that field is specified in the Directive
in
> > > >these terms:
> > > >
> > > >"The certification-service-provider shall not be liable for damage
> >arising
> > > >from use of a qualified certificate which exceeds the limitations
placed
> >on
> > > >it".
> > > >
> > > >The text does *not* say: "The certification-service-provider *shall
be*
> > > >liable for damage arising from use of a qualified certificate which
> >*meets*
> > > >the limitations placed on it".
> > > >
> > > >So it is more a *disclaimer of warranty* rather than a warranty. If
the
> > > >proposal was for a warranty disclaimer extension, then it would be
more
> > > >appropriate. In such a case it would not be necessary to indicate the
> > > >conditions to meet to get the warranty since there would be no
warranty.
> > > >
> > > >It is doubtful that an off-line indication in a certificate will be
the
> > > >right answer to a problem that is commonly solved using an on-line
> >protocol
> > > >(e.g. money withdrawal on an ATM).
> > > >
> > > >Denis
> > > >
> > > >
> > > > > 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           : Warranty Certificate Extension
> > > > >         Author(s)       : D. Linsenbardt, S. Pontius
> > > > >         Filename        : draft-ietf-pkix-warranty-extn-00.txt
> > > > >         Pages           : 7
> > > > >         Date            : 18-Apr-02
> > > > >
> > > > > This document describes a certificate extension to explicitly
state
> > > > > the warranty offered by a Certificate Authority (CA) for a the
> > > > > certificate containing the extension.
> > > > >
> > > > > A URL for this Internet-Draft is:
> > > > >
> >http://www.ietf.org/internet-drafts/draft-ietf-pkix-warranty-extn-00.txt
>



Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g43M5SS23808 for ietf-pkix-bks; Fri, 3 May 2002 15:05:28 -0700 (PDT)
Received: from mtiwmhc25.worldnet.att.net (mtiwmhc25.worldnet.att.net [204.127.131.50]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g43M5Ra23804 for <[e-mail]>; Fri, 3 May 2002 15:05:27 -0700 (PDT)
Received: from Chokhani ([12.91.131.81]) by mtiwmhc25.worldnet.att.net (InterMail vM.4.01.03.27 201-229-121-127-20010626) with ESMTP id <20020503220522.FOCE2855.mtiwmhc25.worldnet.att.net@Chokhani>; Fri, 3 May 2002 22:05:22 +0000
From: "Santosh Chokhani" <[e-mail]>
To: "'Trevor Freeman'" <[e-mail]>, <[e-mail]>, "'Omer Hasret'" <[e-mail]>
Cc: <[e-mail]>
Subject: RE: Meaning of Non-repudiation
Date: Fri, 3 May 2002 18:06:52 -0400
Message-ID: <008f01c1f2ee$d4ed3c20$a300a8c0@Chokhani>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.2627
Importance: Normal
In-Reply-To: <[e-mail]>
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4910.0300
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id g43M5Ra23805
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Trevor:

How am I changing the semantics of the extension?  The extension is used
for defining which of the security services the key pair can be used
for.  I am adhere to that.  All I am doing is giving some useful
distinction between DS and NR.

If you are saying that I am providing a meaningful distinction between
the two bits and that distinction may not be backward compatible with
some commercial products, I agree.

-----Original Message-----
From: [e-mail] [mailto:[e-mail]]
On Behalf Of Trevor Freeman
Sent: Friday, May 03, 2002 4:14 PM
To: Santosh Chokhani; [e-mail]; Omer Hasret
Cc: [e-mail]
Subject: RE: Meaning of Non-repudiation



Santosh,
Either you are proposing changing the semantics of the existing
definition of the key usage extension, or you are advocating a policy
which may be implanted. The first is a none starter - you don't change
the semantics of existing extensions. The second is perfectly acceptable
policy that you may want follow, but is not mandatory on all parties.
Trevor

-----Original Message-----
From: Santosh Chokhani [mailto:[e-mail]] 
Sent: Friday, May 03, 2002 10:56 AM
To: [e-mail]; 'Omer Hasret'
Cc: [e-mail]
Subject: RE: Meaning of Non-repudiation


I think EKU provide application specific refinement, e.g., code signing.

But, key usage has the basic operations.  The distinction between
signing a challenge and data that you take some ownership to belongs in
key usage.

-----Original Message-----
From: [e-mail] [mailto:[e-mail]]
On Behalf Of [e-mail]
Sent: Friday, May 03, 2002 9:43 AM
To: Omer Hasret
Cc: 'Santosh Chokhani'; [e-mail]
Subject: RE: Meaning of Non-repudiation






"Extended Key Usage" is meant for that purpose, isn't it ? Or "Policy
Identifier" could provide this kind of information.
|------------------------+------------------------+---------------------
---|
|                        |   "Omer Hasret"        |
|
|                        |   <[e-mail]>  |           To:
|
|                        |                        |
<Olaf.Schlueter@secar|
|                        |   03.05.2002 14:53     |   tis.com>,
|
|                        |                        |
<[e-mail]>  |
|                        |                        |           cc:
|
|                        |                        |   "'Santosh
Chokhani'" |
|                        |                        |
<[e-mail]|
|                        |                        |   m>
|
|                        |                        |           Subject:
|
|                        |                        |   RE: Meaning of
|
|                        |                        |   Non-repudiation
|
|------------------------+------------------------+---------------------
---|








Olaf,

See below,

> -----Original Message-----
> From: [e-mail]
> [mailto:[e-mail]] On Behalf Of 
> [e-mail]
> Sent: vendredi 3 mai 2002 12:43
> To: [e-mail]
> Cc: 'Santosh Chokhani'; [e-mail]; 
> [e-mail]; 'Trevor Freeman'
> Subject: RE: Meaning of Non-repudiation
>
>
>
>
>
>
> The NR bit in a certifiicate does not proof anything. It is a
> statement made by the signer and/or the CA about the intended use of 
> the key. KeyUsage bits are currently used to support key pair 
> separation for the three basic use cases of public key cryptography: 
> encryption, authentication and digital signing. Most application 
> choose public key certificates needed for a certain type of operation 
> based on the keyUsage
> bits: with keyEncipherment to encrypt a message, with digitalSignature

> to verify the response to a challenge for authentication, or to verify

> signature made on e-mail. These two bits are essential (and
> sufficient) to support key pair seperation per RSA operation 
> capability (decryption or
> signing) of the private key as the RSA operation capabilities of 
> private keys may be restricted by hardware implementation (i.e. a 
> crypto processor card may be configured to allow only signing with a 
> private key, or decryption, and check padding and format of 
> input/output before and after the operation or even include part or 
> all of the hashing procedure).
>
> If one wants to ensure that a private key is only used to sign data,
> but not to sign an arbitrary challenge, (which practically means "can 
> be used within S/MIME but not within
> SSL")  which is the case e.g. within the signature law compliant use 
> cases, a new bit is needed to clearly distinguish between public keys 
> used for authentication and for signature verification. In all specs 
> that adress this seperation the nonRepudiation bit is used for that 
> purpose. And I cannot see a need for changing that..

Therefore you say that the NR bit is set when we want to use the
certificate for "digital signature" which actually is just the
authentication of the sender for S/MIME messages and nothing else. No
one is trying to change this. However, everyone should know that this
does not prove anything. So if you give different CPs the freedom of
loading whatever meaning they want to the NR bit, there will be
problems.

Besides, I also see the need for another bit which actually states that
"I have read and agree with the content of this message" like real
signatures. (I think the DS bit can be used for this. But everyone
should have exactly the same understanding of these bits.)




> |------------------------+------------------------+-----------
-------------|
> |                        |   "Omer Hasret"        |
>              |
> |                        |   <[e-mail]>  |
> To:          |
> |                        |   Sent by:             |
> "'Trevor Freeman'"   |
> |                        |   owner-ietf-pkix@mail.|
> <[e-mail]|
> |                        |   imc.org              |
> osoft.com>, "'Santosh|
> |                        |                        |
> Chokhani'"           |
> |                        |   03.05.2002 10:52     |
> <[e-mail]|
> |                        |                        |   m>
>              |
> |                        |                        |
> cc:          |
> |                        |                        |
> <[e-mail]>  |
> |                        |                        |
> Subject:     |
> |                        |                        |   RE:
> Meaning of       |
> |                        |                        |
> Non-repudiation      |
> |------------------------+------------------------+-----------
-------------|
>
>
>
>
>
>
>
>
> Trevor, Santosh,
>
> It is certain that everybody will need some means of proving that he
> is the originator of a specific message, document, whatever. And when 
> we talk about the NR bit on a certificate, I believe the only thing 
> this proves is that a specific data is signed by the holder of this 
> certificate. This never means that the signer agrees with the content 
> or not. Therefore there is no need to load other meanings to this one 
> bit changing from policy to policy. Just standardize its use only
> for authentication and let others who want to implement their
> own NR systems do it by other means. (Some ways to do this
> have been posted on the list a day or two days ago.) And I
> really do not think this as a "dictation" because you don't
> have to use that bit just because its name is NR.
>
> >
> >
> >
> > Hi Santosh,
> > That still sounds like a policy decision.
> > A signature over an SSL challenge is potentially just as
> valid a piece
> > of a NR jigsaw puzzle as any other signature. Why are we dictating
> > what someone wants as a NR process? If you want to build a system 
> > where NR signatures only occur over documents - fine by me,
> but don't
> > dictate how I build my NR system. Trevor
> >
> > -----Original Message-----
> > From: Santosh Chokhani [mailto:[e-mail]]
> > Sent: Thursday, May 02, 2002 2:03 PM
> > To: Trevor Freeman; 'Denis Pinkas'; 'David P. Kemp'
> > Cc: [e-mail]
> > Subject: RE: Meaning of Non-repudiation
> >
> > Trevor:
> >
> > I also made a resolution long time back when ABA started a
> debate on
> > this.  But, I also broke it.
> >
> > I do think that there is a value in SSL case to say that I am not
> > owning up to signature (as attesting to something) except I
> signed a
> > challenge. Thus, subscriber (possessor of the private key)
> should be
> > able to use a separate key so that he can claim he simply signed a
> > random challenge.
> >
> > -----Original Message-----
> > From: [e-mail]
> > [mailto:[e-mail]]
> > On Behalf Of Trevor Freeman
> > Sent: Thursday, May 02, 2002 2:53 PM
> > To: Denis Pinkas; David P. Kemp
> > Cc: [e-mail]
> > Subject: RE: Meaning of Non-repudiation
> >
> >
> >
> > I am breaking one of my New Year resolutions by mailing on
> this topic,
> > but here goes...
> >
> > Signing anything is always a challenge to prove position of
> a private
> > key to authenticate whether it's in the context of a
> protocol like SSL
> > or over a SMIME message. Technically all we can say is the
> signature
> > occurred. The intent behind why the signature occurred is
> beyond the
> > scope of this discussion. Use of certificates with the NR
> bit asserted
> > is ultimately a matter of local policy on what constitutes usage as
> > part of a non-repudiation service since two organisations could have

> > two separate non repudiation serves where one requires a NR
> > signature as part of an SSL session, and the other only wants NR 
> > signatures over SMIME messages.
> >
> > Never in the course of IETF has history so much been written over
> > something so small.
> >
> > Trevor
> >
> > -----Original Message-----
> > From: Denis Pinkas [mailto:[e-mail]]
> > Sent: Thursday, May 02, 2002 2:27 AM
> > To: David P. Kemp
> > Cc: [e-mail]
> > Subject: Re: Meaning of Non-repudiation
> >
> >
> > Dave,
> >
> > > Russ,
> > >
> > > I believe we are all sorry to resurrect this topic.
> > > But it is currently the subject of an X.509 defect,
> >
> > Not exactly. Someone would like this topic to be the subject of an
> > X.509 defect report, but this is is currently *not* the
> subject of an
> > X.509 defect that has been officially raised.
> >
> > > and if the text of X.509 eventually changes in a way
> > > that is incompatible with Son-of-2459, then Grandson-of-2459 will
> > > need to take that into consideration.
> >
> > Very unlikely to happen.
> >
> > Additional *explanations* without changing the meaning
> > *could* be provided and we are (nearly) all saying the same thing
> > using different words. Santosh in a subsequent e-mail
> provided one of
> > these
> > explanations:
> >
> > "In my analysis, DS means you are signing some challenge to prove
> > possession of a private key and thus authenticate yourself whereas 
> > with NR you are saying that I know what this data is and I
> am signing
> > it."
> >
> > I would add that a certificate with the the DS bit set can also be
> > used to authenticate data (this does not mean that the
> signer has read
> > the data).
> >
> > Now, there are cases where, beyond the fact that the signer
> did know
> > what he signed, he wants to say exactly what its signature means.
> >
> > This can be achieved using three ways:
> >
> > 1) the document that is signed is unambiguous and its
> semantics says
> > that the signature means XXX.
> >
> > 2) a signed attribute (using the CMS language) is signed in
> addition
> > to the document and indicates a signature policy that is explicit
> > about the meaning of all signatures performed under that
> policy (note
> > that one single meaning is possible in that case).
> >
> > 3) another signed attribute (using the CMS language) is signed in
> > addition to the document and the previous attribute. It
> indicates the
> > type of commitment being made under the signature policy for that
> > signature (note that multiple meanings are possible in that case).
> >
> > As a result, the variety of meanings is NOT placed in the
> Certificate
> > Policy from the CA.
> >
> > > We can all live with the text because we have no consensus
> > on anything
> > > better.
> >
> > Fine.
> >
> > Denis
> >
> > > That doesn't rule out the faint hope that the ITU can develop a
> > > meaningful replacement in the future.
> > >
> > > Dave
> > >
> > > "Housley, Russ" wrote:
> > > >
> > > > Dave:
> > > >
> > > > I am sorry that I replied to this thread at all.  This topic has
> > been debated
> > > > before, and the text in Son-of-RFC 2459 is the result of that
> > debate.
> > > > Obviously, everyone can live with that text because no
> objections
> > were raised
> > > > during WG Last Call or IETF Last Call.
> > > >
> > > > I am not surprised that there is not 100% agreement....
> > > >
> > > > Russ
> >
>
>
>
>






Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g43KIVH21431 for ietf-pkix-bks; Fri, 3 May 2002 13:18:31 -0700 (PDT)
Received: from mail4.microsoft.com (mail4.microsoft.com [131.107.3.122]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g43KIUa21426 for <[e-mail]>; Fri, 3 May 2002 13:18:30 -0700 (PDT)
Received: from inet-vrs-04.redmond.corp.microsoft.com ([157.54.8.154]) by mail4.microsoft.com with Microsoft SMTPSVC(5.0.2195.4905); Fri, 3 May 2002 13:18:27 -0700
Received: from 157.54.5.25 by inet-vrs-04.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Fri, 03 May 2002 13:18:26 -0700
Received: from red-imc-02.redmond.corp.microsoft.com ([157.54.9.107]) by inet-hub-03.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.4905); Fri, 3 May 2002 13:18:26 -0700
Received: from win-imc-01.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.39]) by red-imc-02.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.4905); Fri, 3 May 2002 13:18:25 -0700
Received: from win-msg-01.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.52]) by win-imc-01.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3604.0); Fri, 3 May 2002 13:14:30 -0700
X-MimeOLE: Produced By Microsoft Exchange V6.0.6177.0
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Subject: RE: Meaning of Non-repudiation
Date: Fri, 3 May 2002 13:14:29 -0700
Message-ID: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: Meaning of Non-repudiation
Thread-Index: AcHyy71uWtpQyyXRR0OkDnoNhncRxwAE29tg
From: "Trevor Freeman" <[e-mail]>
To: "Santosh Chokhani" <[e-mail]>, <[e-mail]>, "Omer Hasret" <[e-mail]>
Cc: <[e-mail]>
X-OriginalArrivalTime: 03 May 2002 20:14:30.0458 (UTC) FILETIME=[21F779A0:01C1F2DF]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id g43KIUa21427
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Santosh,
Either you are proposing changing the semantics of the existing definition of the key usage extension, or you are advocating a policy which may be implanted. The first is a none starter - you don't change the semantics of existing extensions. The second is perfectly acceptable policy that you may want follow, but is not mandatory on all parties.
Trevor

-----Original Message-----
From: Santosh Chokhani [mailto:[e-mail]] 
Sent: Friday, May 03, 2002 10:56 AM
To: [e-mail]; 'Omer Hasret'
Cc: [e-mail]
Subject: RE: Meaning of Non-repudiation


I think EKU provide application specific refinement, e.g., code signing.

But, key usage has the basic operations.  The distinction between
signing a challenge and data that you take some ownership to belongs in
key usage.

-----Original Message-----
From: [e-mail] [mailto:[e-mail]]
On Behalf Of [e-mail]
Sent: Friday, May 03, 2002 9:43 AM
To: Omer Hasret
Cc: 'Santosh Chokhani'; [e-mail]
Subject: RE: Meaning of Non-repudiation






"Extended Key Usage" is meant for that purpose, isn't it ? Or "Policy
Identifier" could provide this kind of information.
|------------------------+------------------------+---------------------
---|
|                        |   "Omer Hasret"        |
|
|                        |   <[e-mail]>  |           To:
|
|                        |                        |
<Olaf.Schlueter@secar|
|                        |   03.05.2002 14:53     |   tis.com>,
|
|                        |                        |
<[e-mail]>  |
|                        |                        |           cc:
|
|                        |                        |   "'Santosh
Chokhani'" |
|                        |                        |
<[e-mail]|
|                        |                        |   m>
|
|                        |                        |           Subject:
|
|                        |                        |   RE: Meaning of
|
|                        |                        |   Non-repudiation
|
|------------------------+------------------------+---------------------
---|








Olaf,

See below,

> -----Original Message-----
> From: [e-mail] 
> [mailto:[e-mail]] On Behalf Of 
> [e-mail]
> Sent: vendredi 3 mai 2002 12:43
> To: [e-mail]
> Cc: 'Santosh Chokhani'; [e-mail]; 
> [e-mail]; 'Trevor Freeman'
> Subject: RE: Meaning of Non-repudiation
>
>
>
>
>
>
> The NR bit in a certifiicate does not proof anything. It is a 
> statement made by the signer and/or the CA about the intended use of 
> the key. KeyUsage bits are currently used to support key pair 
> separation for the three basic use cases of public key cryptography: 
> encryption, authentication and digital signing. Most application 
> choose public key certificates needed for a certain type of operation 
> based on the keyUsage
> bits: with keyEncipherment to encrypt a message, with digitalSignature

> to verify the response to a challenge for authentication, or to verify

> signature made on e-mail. These two bits are essential (and 
> sufficient) to support key pair seperation per RSA operation 
> capability (decryption or
> signing) of the private key as the RSA operation capabilities of 
> private keys may be restricted by hardware implementation (i.e. a 
> crypto processor card may be configured to allow only signing with a 
> private key, or decryption, and check padding and format of 
> input/output before and after the operation or even include part or 
> all of the hashing procedure).
>
> If one wants to ensure that a private key is only used to sign data, 
> but not to sign an arbitrary challenge, (which practically means "can 
> be used within S/MIME but not within
> SSL")  which is the case e.g. within the signature law compliant use 
> cases, a new bit is needed to clearly distinguish between public keys 
> used for authentication and for signature verification. In all specs 
> that adress this seperation the nonRepudiation bit is used for that 
> purpose. And I cannot see a need for changing that..

Therefore you say that the NR bit is set when we want to use the
certificate for "digital signature" which actually is just the
authentication of the sender for S/MIME messages and nothing else. No
one is trying to change this. However, everyone should know that this
does not prove anything. So if you give different CPs the freedom of
loading whatever meaning they want to the NR bit, there will be
problems.

Besides, I also see the need for another bit which actually states that
"I have read and agree with the content of this message" like real
signatures. (I think the DS bit can be used for this. But everyone
should have exactly the same understanding of these bits.)




> |------------------------+------------------------+-----------
-------------|
> |                        |   "Omer Hasret"        |
>              |
> |                        |   <[e-mail]>  |
> To:          |
> |                        |   Sent by:             |
> "'Trevor Freeman'"   |
> |                        |   owner-ietf-pkix@mail.|
> <[e-mail]|
> |                        |   imc.org              |
> osoft.com>, "'Santosh|
> |                        |                        |
> Chokhani'"           |
> |                        |   03.05.2002 10:52     |
> <[e-mail]|
> |                        |                        |   m>
>              |
> |                        |                        |
> cc:          |
> |                        |                        |
> <[e-mail]>  |
> |                        |                        |
> Subject:     |
> |                        |                        |   RE:
> Meaning of       |
> |                        |                        |
> Non-repudiation      |
> |------------------------+------------------------+-----------
-------------|
>
>
>
>
>
>
>
>
> Trevor, Santosh,
>
> It is certain that everybody will need some means of proving that he 
> is the originator of a specific message, document, whatever. And when 
> we talk about the NR bit on a certificate, I believe the only thing 
> this proves is that a specific data is signed by the holder of this 
> certificate. This never means that the signer agrees with the content 
> or not. Therefore there is no need to load other meanings to this one 
> bit changing from policy to policy. Just standardize its use only
> for authentication and let others who want to implement their
> own NR systems do it by other means. (Some ways to do this
> have been posted on the list a day or two days ago.) And I
> really do not think this as a "dictation" because you don't
> have to use that bit just because its name is NR.
>
> >
> >
> >
> > Hi Santosh,
> > That still sounds like a policy decision.
> > A signature over an SSL challenge is potentially just as
> valid a piece
> > of a NR jigsaw puzzle as any other signature. Why are we dictating 
> > what someone wants as a NR process? If you want to build a system 
> > where NR signatures only occur over documents - fine by me,
> but don't
> > dictate how I build my NR system. Trevor
> >
> > -----Original Message-----
> > From: Santosh Chokhani [mailto:[e-mail]]
> > Sent: Thursday, May 02, 2002 2:03 PM
> > To: Trevor Freeman; 'Denis Pinkas'; 'David P. Kemp'
> > Cc: [e-mail]
> > Subject: RE: Meaning of Non-repudiation
> >
> > Trevor:
> >
> > I also made a resolution long time back when ABA started a
> debate on
> > this.  But, I also broke it.
> >
> > I do think that there is a value in SSL case to say that I am not 
> > owning up to signature (as attesting to something) except I
> signed a
> > challenge. Thus, subscriber (possessor of the private key)
> should be
> > able to use a separate key so that he can claim he simply signed a 
> > random challenge.
> >
> > -----Original Message-----
> > From: [e-mail] 
> > [mailto:[e-mail]]
> > On Behalf Of Trevor Freeman
> > Sent: Thursday, May 02, 2002 2:53 PM
> > To: Denis Pinkas; David P. Kemp
> > Cc: [e-mail]
> > Subject: RE: Meaning of Non-repudiation
> >
> >
> >
> > I am breaking one of my New Year resolutions by mailing on
> this topic,
> > but here goes...
> >
> > Signing anything is always a challenge to prove position of
> a private
> > key to authenticate whether it's in the context of a
> protocol like SSL
> > or over a SMIME message. Technically all we can say is the
> signature
> > occurred. The intent behind why the signature occurred is
> beyond the
> > scope of this discussion. Use of certificates with the NR
> bit asserted
> > is ultimately a matter of local policy on what constitutes usage as 
> > part of a non-repudiation service since two organisations could have

> > two separate non repudiation serves where one requires a NR 
> > signature as part of an SSL session, and the other only wants NR 
> > signatures over SMIME messages.
> >
> > Never in the course of IETF has history so much been written over 
> > something so small.
> >
> > Trevor
> >
> > -----Original Message-----
> > From: Denis Pinkas [mailto:[e-mail]]
> > Sent: Thursday, May 02, 2002 2:27 AM
> > To: David P. Kemp
> > Cc: [e-mail]
> > Subject: Re: Meaning of Non-repudiation
> >
> >
> > Dave,
> >
> > > Russ,
> > >
> > > I believe we are all sorry to resurrect this topic.
> > > But it is currently the subject of an X.509 defect,
> >
> > Not exactly. Someone would like this topic to be the subject of an 
> > X.509 defect report, but this is is currently *not* the
> subject of an
> > X.509 defect that has been officially raised.
> >
> > > and if the text of X.509 eventually changes in a way
> > > that is incompatible with Son-of-2459, then Grandson-of-2459 will 
> > > need to take that into consideration.
> >
> > Very unlikely to happen.
> >
> > Additional *explanations* without changing the meaning
> > *could* be provided and we are (nearly) all saying the same thing 
> > using different words. Santosh in a subsequent e-mail
> provided one of
> > these
> > explanations:
> >
> > "In my analysis, DS means you are signing some challenge to prove 
> > possession of a private key and thus authenticate yourself whereas 
> > with NR you are saying that I know what this data is and I
> am signing
> > it."
> >
> > I would add that a certificate with the the DS bit set can also be 
> > used to authenticate data (this does not mean that the
> signer has read
> > the data).
> >
> > Now, there are cases where, beyond the fact that the signer
> did know
> > what he signed, he wants to say exactly what its signature means.
> >
> > This can be achieved using three ways:
> >
> > 1) the document that is signed is unambiguous and its
> semantics says
> > that the signature means XXX.
> >
> > 2) a signed attribute (using the CMS language) is signed in
> addition
> > to the document and indicates a signature policy that is explicit 
> > about the meaning of all signatures performed under that
> policy (note
> > that one single meaning is possible in that case).
> >
> > 3) another signed attribute (using the CMS language) is signed in 
> > addition to the document and the previous attribute. It
> indicates the
> > type of commitment being made under the signature policy for that 
> > signature (note that multiple meanings are possible in that case).
> >
> > As a result, the variety of meanings is NOT placed in the
> Certificate
> > Policy from the CA.
> >
> > > We can all live with the text because we have no consensus
> > on anything
> > > better.
> >
> > Fine.
> >
> > Denis
> >
> > > That doesn't rule out the faint hope that the ITU can develop a 
> > > meaningful replacement in the future.
> > >
> > > Dave
> > >
> > > "Housley, Russ" wrote:
> > > >
> > > > Dave:
> > > >
> > > > I am sorry that I replied to this thread at all.  This topic has
> > been debated
> > > > before, and the text in Son-of-RFC 2459 is the result of that
> > debate.
> > > > Obviously, everyone can live with that text because no
> objections
> > were raised
> > > > during WG Last Call or IETF Last Call.
> > > >
> > > > I am not surprised that there is not 100% agreement....
> > > >
> > > > Russ
> >
>
>
>
>






Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g43KDVw21268 for ietf-pkix-bks; Fri, 3 May 2002 13:13:31 -0700 (PDT)
Received: from mail1.microsoft.com (mail1.microsoft.com [131.107.3.125]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g43KDTa21262 for <[e-mail]>; Fri, 3 May 2002 13:13:29 -0700 (PDT)
Received: from inet-vrs-01.redmond.corp.microsoft.com ([157.54.8.27]) by mail1.microsoft.com with Microsoft SMTPSVC(5.0.2195.4905); Fri, 3 May 2002 13:13:27 -0700
Received: from 157.54.8.109 by inet-vrs-01.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Fri, 03 May 2002 13:13:26 -0700
Received: from red-imc-04.redmond.corp.microsoft.com ([157.54.2.168]) by inet-hub-02.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.4905); Fri, 3 May 2002 13:13:26 -0700
Received: from win-imc-01.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.39]) by red-imc-04.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.2966); Fri, 3 May 2002 13:13:24 -0700
Received: from win-msg-01.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.52]) by win-imc-01.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3604.0); Fri, 3 May 2002 13:09:30 -0700
X-MimeOLE: Produced By Microsoft Exchange V6.0.6177.0
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Subject: RE: Meaning of Non-repudiation
Date: Fri, 3 May 2002 13:09:30 -0700
Message-ID: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: Meaning of Non-repudiation
Thread-Index: AcHyrYC4PyrOwbZgRu66I0jCXgCfGQAMRVNw
From: "Trevor Freeman" <[e-mail]>
To: "David P. Kemp" <[e-mail]>, <[e-mail]>
X-OriginalArrivalTime: 03 May 2002 20:09:30.0763 (UTC) FILETIME=[6F55A5B0:01C1F2DE]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id g43KDTa21263
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Dave,
If you truly were just changing the names - I could not care one jolt,
but you are proposing changing the semantics, and that is unacceptable.
DS today means sign anything but certs and CRLS. That definition has to
stand for that bit.
Trevor

-----Original Message-----
From: David P. Kemp [mailto:[e-mail]] 
Sent: Friday, May 03, 2002 7:17 AM
To: [e-mail]
Subject: Re: Meaning of Non-repudiation


Olaf,

I concur as well.   Nothing needs to change about how the bit is used;
only its name needs changing.

Dave

Denis Pinkas wrote:
> 
> Olaf,
> 
> Thank you for these comprehensive explanations.
> 
> I concur.
> 
> Denis
> 
> > The NR bit in a certifiicate does not proof anything. It is a
statement
> > made by the signer and/or the CA about the intended use of the key.
> > KeyUsage bits are currently used to support key pair separation for
the
> > three basic use cases of public key cryptography: encryption,
> > authentication and digital signing. Most application choose public
key
> > certificates needed for a certain type of operation based on the
keyUsage
> > bits: with keyEncipherment to encrypt a message, with
digitalSignature to
> > verify the response to a challenge for authentication, or to verify
> > signature made on e-mail. These two bits are essential (and
sufficient) to
> > support key pair seperation per RSA operation capability (decryption
or
> > signing) of the private key as the RSA operation capabilities of
private
> > keys may be restricted by hardware implementation (i.e. a crypto
processor
> > card may be configured to allow only signing with a private key, or
> > decryption, and check padding and format of input/output before and
after
> > the operation or even include part or all of the hashing procedure).
> 
> > If one wants to ensure that a private key is only used to sign data,
but
> > not to sign an arbitrary challenge, (which practically means "can be
used
> > within S/MIME but not within SSL")  which is the case e.g. within
the
> > signature law compliant use cases, a new bit is needed to clearly
> > distinguish between public keys used for authentication and for
signature
> > verification. In all specs that adress this seperation the
nonRepudiation
> >
-----------------------------------------------------------
> > bit is used for that purpose. And I cannot see a need for changing
that.
> >
------------------------------------------------------------------------


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g43KAcE21202 for ietf-pkix-bks; Fri, 3 May 2002 13:10:38 -0700 (PDT)
Received: from mail1.microsoft.com (mail1.microsoft.com [131.107.3.125]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g43KAba21198 for <[e-mail]>; Fri, 3 May 2002 13:10:37 -0700 (PDT)
Received: from inet-vrs-01.redmond.corp.microsoft.com ([157.54.8.27]) by mail1.microsoft.com with Microsoft SMTPSVC(5.0.2195.4905); Fri, 3 May 2002 13:10:34 -0700
Received: from 157.54.8.23 by inet-vrs-01.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Fri, 03 May 2002 13:10:34 -0700
Received: from red-imc-01.redmond.corp.microsoft.com ([157.54.9.102]) by inet-hub-01.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.4905); Fri, 3 May 2002 13:10:34 -0700
Received: from win-imc-01.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.39]) by red-imc-01.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.4905); Fri, 3 May 2002 13:10:30 -0700
Received: from win-msg-01.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.52]) by win-imc-01.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3604.0); Fri, 3 May 2002 13:06:27 -0700
X-MimeOLE: Produced By Microsoft Exchange V6.0.6177.0
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Subject: RE: Meaning of Non-repudiation
Date: Fri, 3 May 2002 13:06:27 -0700
Message-ID: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: Meaning of Non-repudiation
Thread-Index: AcHyrAsMUfdjJJkvRVe2LruVSjwShQAMdBTg
From: "Trevor Freeman" <[e-mail]>
To: "David P. Kemp" <[e-mail]>, <[e-mail]>
X-OriginalArrivalTime: 03 May 2002 20:06:27.0751 (UTC) FILETIME=[02403B70:01C1F2DE]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id g43KAba21199
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Hi Dave,
You CANNOT change the semantics of existing bits. That kind of behaviour
breaks things, leads to even more ambiguity etc, etc. You can add new
bits with more precise meaning - though in the case of the KU extension
- that to breaks things so that is a less than optimal route as well.
Trevor

-----Original Message-----
From: David P. Kemp [mailto:[e-mail]] 
Sent: Friday, May 03, 2002 7:03 AM
To: [e-mail]
Subject: Re: Meaning of Non-repudiation


Trevor Freeman wrote:
> 
> Hi Santosh,
> That still sounds like a policy decision.
> A signature over an SSL challenge is potentially just as valid a piece
> of a NR jigsaw puzzle as any other signature. Why are we dictating
what
> someone wants as a NR process? If you want to build a system where NR
> signatures only occur over documents - fine by me, but don't dictate
how
> I build my NR system.
> Trevor




Trevor,

I agree completely.

That is why if:
  key usage bit 0 = digital signature on a "nonce" (*)
        and bit 1 = digital signature on other data

then the name of bit 1 should be changed to something
other than nonRepudiation.  As you say, even a signed
challenge could play a role in some NR systems.

Nonetheless, there is a benefit to having separate key
usage bits for four different categories of data to
be signed: certificates, CRLs, nonces, and
everything else.

The word "non-repudiation" is an obstacle to achieving
that benefit.  Therefore the word must be removed from
the definition of Key Usage, and instead be discussed
in the context of Extended Key Usage, certificate
policies, and best of all, the methods described by
Denis Pinkas: document contents and signed attributes.

Dave



(*) A nonce is data explicitly designed to be
non-replayable in its primary application (e.g. SSL).
The protocol would not serve its primary purpose if
the signed nonce could be replayed, even if there is
a secondary forensic or NR reason for verifying the
signed nonce at a later time.


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g43KALb21196 for ietf-pkix-bks; Fri, 3 May 2002 13:10:21 -0700 (PDT)
Received: from mail.coastside.net (mail.coastside.net [207.213.212.6]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g43KAKa21192 for <[e-mail]>; Fri, 3 May 2002 13:10:20 -0700 (PDT)
Received: from laptop (dsl-63-194-153-52.coastside.net [63.194.153.52]) by poseidon.coastside.net  with SMTP id g43K2ZvY019322; Fri, 3 May 2002 13:02:35 -0700 (PDT)
From: "Michael Myers" <[e-mail]>
To: "Sharon Boeyen" <[e-mail]>, "'Denis Pinkas'" <[e-mail]>, "David P. Kemp" <[e-mail]>, "500 list \(E-mail\)" <[e-mail]>
Cc: <[e-mail]>
Subject: RE: Meaning of Non-repudiation
Date: Fri, 3 May 2002 12:59:38 -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.2911.0)
In-Reply-To: <[e-mail]>
X-MIMEOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
Importance: Normal
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Sharon,

I agree with this direction and hope others do too.

Mike




-----Original Message-----
On Friday, May 03, 2002 11:41 AM Sharon Boeyen wrote:

. . .

I, for one, hope the changes move in the direction of leaving
non-repudiation to the legal and policy realm rather than the
technical one. All other key usages are technical processes that
can be easily verified by the relying party system.
Non-repudiation is not.

Sharon



Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g43JORI19157 for ietf-pkix-bks; Fri, 3 May 2002 12:24:27 -0700 (PDT)
Received: from mail6.microsoft.com (mail6.microsoft.com [131.107.3.126]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g43JOPa19153 for <[e-mail]>; Fri, 3 May 2002 12:24:25 -0700 (PDT)
Received: from inet-vrs-06.redmond.corp.microsoft.com ([157.54.6.201]) by mail6.microsoft.com with Microsoft SMTPSVC(5.0.2195.4905); Fri, 3 May 2002 12:24:22 -0700
Received: from 157.54.8.155 by inet-vrs-06.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Fri, 03 May 2002 12:24:22 -0700
Received: from red-imc-02.redmond.corp.microsoft.com ([157.54.9.107]) by inet-hub-04.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.4905); Fri, 3 May 2002 12:24:22 -0700
Received: from win-imc-01.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.39]) by red-imc-02.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.4905); Fri, 3 May 2002 12:24:21 -0700
Received: from win-msg-01.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.52]) by win-imc-01.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3604.0); Fri, 3 May 2002 12:20:15 -0700
X-MimeOLE: Produced By Microsoft Exchange V6.0.6177.0
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Subject: RE: Meaning of Non-repudiation
Date: Fri, 3 May 2002 12:20:18 -0700
Message-ID: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: Meaning of Non-repudiation
Thread-Index: AcHyj4YyT/jYypKkRPKQPi3s7LyuPwARpn3A
From: "Trevor Freeman" <[e-mail]>
To: <[e-mail]>
Cc: <[e-mail]>
X-OriginalArrivalTime: 03 May 2002 19:20:15.0801 (UTC) FILETIME=[8E0A3A90:01C1F2D7]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id g43JOPa19154
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Hi Olaf,
You are making the same leap as Santosh. Just because you don't want to use SSL as part of your NR system, does not preclude others from doing so. That is a policy decision, not a technology issue. Let me put it another way - setting the NR bit does not by itself assert that this certificate cannot be used for SSL client authentication. You may have a policy to that effect, and that policy may be called out in the certificate policy, bit the NR bit alone is not good enough to define the policy in the way you describe.
Trevor

-----Original Message-----
From: [e-mail] [mailto:[e-mail]] 
Sent: Friday, May 03, 2002 3:43 AM
To: [e-mail]
Cc: 'Santosh Chokhani'; [e-mail]; [e-mail]; Trevor Freeman
Subject: RE: Meaning of Non-repudiation




The NR bit in a certifiicate does not proof anything. It is a statement
made by the signer and/or the CA about the intended use of the key.
KeyUsage bits are currently used to support key pair separation for the
three basic use cases of public key cryptography: encryption,
authentication and digital signing. Most application choose public key
certificates needed for a certain type of operation based on the keyUsage
bits: with keyEncipherment to encrypt a message, with digitalSignature to
verify the response to a challenge for authentication, or to verify
signature made on e-mail. These two bits are essential (and sufficient) to
support key pair seperation per RSA operation capability (decryption or
signing) of the private key as the RSA operation capabilities of private
keys may be restricted by hardware implementation (i.e. a crypto processor
card may be configured to allow only signing with a private key, or
decryption, and check padding and format of input/output before and after
the operation or even include part or all of the hashing procedure).

If one wants to ensure that a private key is only used to sign data, but
not to sign an arbitrary challenge, (which practically means "can be used
within S/MIME but not within SSL")  which is the case e.g. within the
signature law compliant use cases, a new bit is needed to clearly
distinguish between public keys used for authentication and for signature
verification. In all specs that adress this seperation the nonRepudiation
bit is used for that purpose. And I cannot see a need for changing that..
|------------------------+------------------------+------------------------|
|                        |   "Omer Hasret"        |                        |
|                        |   <[e-mail]>  |           To:          |
|                        |   Sent by:             |   "'Trevor Freeman'"   |
|                        |   owner-ietf-pkix@mail.|   <[e-mail]|
|                        |   imc.org              |   osoft.com>, "'Santosh|
|                        |                        |   Chokhani'"           |
|                        |   03.05.2002 10:52     |   <[e-mail]|
|                        |                        |   m>                   |
|                        |                        |           cc:          |
|                        |                        |   <[e-mail]>  |
|                        |                        |           Subject:     |
|                        |                        |   RE: Meaning of       |
|                        |                        |   Non-repudiation      |
|------------------------+------------------------+------------------------|








Trevor, Santosh,

It is certain that everybody will need some means of proving that he is
the originator of a specific message, document, whatever. And when we
talk about the NR bit on a certificate, I believe the only thing this
proves is that a specific data is signed by the holder of this
certificate. This never means that the signer agrees with the content or
not. Therefore there is no need to load other meanings to this one bit
changing from policy to policy. Just standardize its use only for
authentication and let others who want to implement their own NR systems
do it by other means. (Some ways to do this have been posted on the list
a day or two days ago.) And I really do not think this as a "dictation"
because you don't have to use that bit just because its name is NR.

>
>
>
> Hi Santosh,
> That still sounds like a policy decision.
> A signature over an SSL challenge is potentially just as
> valid a piece of a NR jigsaw puzzle as any other signature.
> Why are we dictating what someone wants as a NR process? If
> you want to build a system where NR signatures only occur
> over documents - fine by me, but don't dictate how I build my
> NR system. Trevor
>
> -----Original Message-----
> From: Santosh Chokhani [mailto:[e-mail]]
> Sent: Thursday, May 02, 2002 2:03 PM
> To: Trevor Freeman; 'Denis Pinkas'; 'David P. Kemp'
> Cc: [e-mail]
> Subject: RE: Meaning of Non-repudiation
>
> Trevor:
>
> I also made a resolution long time back when ABA started a
> debate on this.  But, I also broke it.
>
> I do think that there is a value in SSL case to say that I am
> not owning up to signature (as attesting to something) except
> I signed a challenge. Thus, subscriber (possessor of the
> private key) should be able to use a separate key so that he
> can claim he simply signed a random challenge.
>
> -----Original Message-----
> From: [e-mail]
> [mailto:[e-mail]]
> On Behalf Of Trevor Freeman
> Sent: Thursday, May 02, 2002 2:53 PM
> To: Denis Pinkas; David P. Kemp
> Cc: [e-mail]
> Subject: RE: Meaning of Non-repudiation
>
>
>
> I am breaking one of my New Year resolutions by mailing on
> this topic, but here goes...
>
> Signing anything is always a challenge to prove position of a
> private key to authenticate whether it's in the context of a
> protocol like SSL or over a SMIME message. Technically all we
> can say is the signature occurred. The intent behind why the
> signature occurred is beyond the scope of this discussion.
> Use of certificates with the NR bit asserted is ultimately a
> matter of local policy on what constitutes usage as part of a
> non-repudiation service since two organisations could have
> two separate non repudiation serves where one requires a NR
> signature as part of an SSL session, and the other only wants
> NR signatures over SMIME messages.
>
> Never in the course of IETF has history so much been written
> over something so small.
>
> Trevor
>
> -----Original Message-----
> From: Denis Pinkas [mailto:[e-mail]]
> Sent: Thursday, May 02, 2002 2:27 AM
> To: David P. Kemp
> Cc: [e-mail]
> Subject: Re: Meaning of Non-repudiation
>
>
> Dave,
>
> > Russ,
> >
> > I believe we are all sorry to resurrect this topic.
> > But it is currently the subject of an X.509 defect,
>
> Not exactly. Someone would like this topic to be the subject
> of an X.509 defect report, but this is is currently *not* the
> subject of an X.509 defect that has been officially raised.
>
> > and if the text of X.509 eventually changes in a way
> > that is incompatible with Son-of-2459, then
> > Grandson-of-2459 will need to take that into
> > consideration.
>
> Very unlikely to happen.
>
> Additional *explanations* without changing the meaning
> *could* be provided and we are (nearly) all saying the same
> thing using different words. Santosh in a subsequent e-mail
> provided one of these
> explanations:
>
> "In my analysis, DS means you are signing some challenge to
> prove possession of a private key and thus authenticate
> yourself whereas with NR you are saying that I know what this
> data is and I am signing it."
>
> I would add that a certificate with the the DS bit set can
> also be used to authenticate data (this does not mean that
> the signer has read the data).
>
> Now, there are cases where, beyond the fact that the signer
> did know what he signed, he wants to say exactly what its
> signature means.
>
> This can be achieved using three ways:
>
> 1) the document that is signed is unambiguous and its
> semantics says that the signature means XXX.
>
> 2) a signed attribute (using the CMS language) is signed in
> addition to the document and indicates a signature policy
> that is explicit about the meaning of all signatures
> performed under that policy (note that one single meaning is
> possible in that case).
>
> 3) another signed attribute (using the CMS language) is
> signed in addition to the document and the previous
> attribute. It indicates the type of commitment being made
> under the signature policy for that signature
> (note that multiple meanings are possible in that case).
>
> As a result, the variety of meanings is NOT placed in the
> Certificate Policy from the CA.
>
> > We can all live with the text because we have no consensus
> on anything
> > better.
>
> Fine.
>
> Denis
>
> > That doesn't rule out the faint hope that the ITU can develop a
> > meaningful replacement in the future.
> >
> > Dave
> >
> > "Housley, Russ" wrote:
> > >
> > > Dave:
> > >
> > > I am sorry that I replied to this thread at all.  This topic has
> been debated
> > > before, and the text in Son-of-RFC 2459 is the result of that
> debate.
> > > Obviously, everyone can live with that text because no objections
> were raised
> > > during WG Last Call or IETF Last Call.
> > >
> > > I am not surprised that there is not 100% agreement....
> > >
> > > Russ
>






Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g43IfLb17735 for ietf-pkix-bks; Fri, 3 May 2002 11:41:21 -0700 (PDT)
Received: from SOTTMXS01.entrust.com (mail.entrust.com [216.191.251.35]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g43IfJa17731 for <[e-mail]>; Fri, 3 May 2002 11:41:19 -0700 (PDT)
Received: by SOTTMXS01.entrust.com with Internet Mail Service (5.5.2653.19) id <KG0KR6PH>; Fri, 3 May 2002 14:41:16 -0400
Message-ID: <[e-mail]>
From: Sharon Boeyen <[e-mail]>
To: "'Denis Pinkas'" <[e-mail]>, "David P. Kemp" <[e-mail]>, "500 list (E-mail)" <[e-mail]>
Cc: [e-mail]
Subject: RE: Meaning of Non-repudiation
Date: Fri, 3 May 2002 14:41:15 -0400 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1F2D2.1B5B3260"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

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_01C1F2D2.1B5B3260
Content-Type: text/plain

I want to clarify the X.509 "status" of this topic. There are 2 reasons that

you don't see a formal defect report on this at present. The topic was
discussed 
at the X.509 meeting in February and the agreement made at that meeting was
that 
the group would initiate a study to see if we could clear up the confusion
around 
the DS and NR bits in keyUsage. As a result of that study we would then
raise a 
DR if necessary, or progress a fix through the enhancement process. We have
agreed 
that there is confusion that needs to be clarified in the 509 text. We have
not 
yet agreed on what the fix should be or which mechanism to use to repair the
text. 

I started a thread on the 500 list and did not copy to this PKIX, FPKI or
other lists,
with the naive hope that we'd reach some sort of consensus on a direction
there and 
then we could take that direction to the 509 profiling groups as a target
for them 
to review BEFORE we actually finalize either a DR or an enhancement text.
However, 
the discussion have flowed over and now there is some on the 500 list, some
on PKIX 
and some on ABA. 

I haven't seen all the traffic on the ABA list yet, but I think there is at
least a 
growing consensus around the need to retain 2 bits. I don't see consensus
yet around 
what they represent though and expect this discussion will continue a while
yet. However,
I do hope that we are able to reach a reasonable consensus and are able to
move forward. 

When (yes I naively said when and not if :-) consensus is reached on a
resolution then I fully 
expect modifications will be made to the text in X.509. I, for one, hope the
changes move 
in the direction of leaving non-repudiation to the legal and policy realm
rather than the 
technical one. All other key usages are technical processes that can be
easily verified by 
the relying party system. Non-repudiation is not.

Sharon
-----Original Message-----
From: Denis Pinkas [mailto:[e-mail]]
Sent: Thursday, May 02, 2002 5:27 AM
To: David P. Kemp
Cc: [e-mail]
Subject: Re: Meaning of Non-repudiation



Dave,
 
> Russ,
> 
> I believe we are all sorry to resurrect this topic.
> But it is currently the subject of an X.509 defect,

Not exactly. Someone would like this topic to be the subject of an X.509
defect report, but this is is currently *not* the subject of an X.509 defect
that has been officially raised.

> and if the text of X.509 eventually changes in a way
> that is incompatible with Son-of-2459, then
> Grandson-of-2459 will need to take that into
> consideration.

Very unlikely to happen.

Additional *explanations* without changing the meaning *could* be provided
and we are (nearly) all saying the same thing using different words. Santosh
in a subsequent e-mail provided one of these explanations:

"In my analysis, DS means you are signing some challenge to prove
possession of a private key and thus authenticate yourself whereas with
NR you are saying that I know what this data is and I am signing it." 

I would add that a certificate with the the DS bit set can also be used to
authenticate data (this does not mean that the signer has read the data).

Now, there are cases where, beyond the fact that the signer did know what he
signed, he wants to say exactly what its signature means.

This can be achieved using three ways:

1) the document that is signed is unambiguous and its semantics says that
the signature means XXX.

2) a signed attribute (using the CMS language) is signed in addition to the
document and indicates a signature policy that is explicit about the meaning
of all signatures performed under that policy (note that one single meaning
is possible in that case).

3) another signed attribute (using the CMS language) is signed in addition
to the document and the previous attribute. It indicates the type of
commitment being made under the signature policy for that signature 
(note that multiple meanings are possible in that case).

As a result, the variety of meanings is NOT placed in the Certificate Policy
from the CA.

> We can all live with the text because we have no consensus on 
> anything better.  

Fine.

Denis

> That doesn't rule out the faint hope that the ITU can develop a
> meaningful replacement in the future.
> 
> Dave
> 
> "Housley, Russ" wrote:
> >
> > Dave:
> >
> > I am sorry that I replied to this thread at all.  This topic has been
debated
> > before, and the text in Son-of-RFC 2459 is the result of that debate.
> > Obviously, everyone can live with that text because no objections were
raised
> > during WG Last Call or IETF Last Call.
> >
> > I am not surprised that there is not 100% agreement....
> >
> > Russ

------_=_NextPart_001_01C1F2D2.1B5B3260
Content-Type: text/html

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=us-ascii">
<META NAME="Generator" CONTENT="MS Exchange Server version 5.5.2653.12">
<TITLE>RE: Meaning of Non-repudiation</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=2>I want to clarify the X.509 &quot;status&quot; of this topic. There are 2 reasons that </FONT>
<BR><FONT SIZE=2>you don't see a formal defect report on this at present. The topic was discussed </FONT>
<BR><FONT SIZE=2>at the X.509 meeting in February and the agreement made at that meeting was that </FONT>
<BR><FONT SIZE=2>the group would initiate a study to see if we could clear up the confusion around </FONT>
<BR><FONT SIZE=2>the DS and NR bits in keyUsage. As a result of that study we would then raise a </FONT>
<BR><FONT SIZE=2>DR if necessary, or progress a fix through the enhancement process. We have agreed </FONT>
<BR><FONT SIZE=2>that there is confusion that needs to be clarified in the 509 text. We have not </FONT>
<BR><FONT SIZE=2>yet agreed on what the fix should be or which mechanism to use to repair the text. </FONT>
</P>

<P><FONT SIZE=2>I started a thread on the 500 list and did not copy to this PKIX, FPKI or other lists,</FONT>
<BR><FONT SIZE=2>with the naive hope that we'd reach some sort of consensus on a direction there and </FONT>
<BR><FONT SIZE=2>then we could take that direction to the 509 profiling groups as a target for them </FONT>
<BR><FONT SIZE=2>to review BEFORE we actually finalize either a DR or an enhancement text. However, </FONT>
<BR><FONT SIZE=2>the discussion have flowed over and now there is some on the 500 list, some on PKIX </FONT>
<BR><FONT SIZE=2>and some on ABA. </FONT>
</P>

<P><FONT SIZE=2>I haven't seen all the traffic on the ABA list yet, but I think there is at least a </FONT>
<BR><FONT SIZE=2>growing consensus around the need to retain 2 bits. I don't see consensus yet around </FONT>
<BR><FONT SIZE=2>what they represent though and expect this discussion will continue a while yet. However,</FONT>
<BR><FONT SIZE=2>I do hope that we are able to reach a reasonable consensus and are able to move forward. </FONT>
</P>

<P><FONT SIZE=2>When (yes I naively said when and not if :-) consensus is reached on a resolution then I fully </FONT>
<BR><FONT SIZE=2>expect modifications will be made to the text in X.509. I, for one, hope the changes move </FONT>
<BR><FONT SIZE=2>in the direction of leaving non-repudiation to the legal and policy realm rather than the </FONT>
<BR><FONT SIZE=2>technical one. All other key usages are technical processes that can be easily verified by </FONT>
<BR><FONT SIZE=2>the relying party system. Non-repudiation is not.</FONT>
</P>

<P><FONT SIZE=2>Sharon</FONT>
<BR><FONT SIZE=2>-----Original Message-----</FONT>
<BR><FONT SIZE=2>From: Denis Pinkas [<A HREF="mailto:[e-mail]">mailto:[e-mail]</A>]</FONT>
<BR><FONT SIZE=2>Sent: Thursday, May 02, 2002 5:27 AM</FONT>
<BR><FONT SIZE=2>To: David P. Kemp</FONT>
<BR><FONT SIZE=2>Cc: [e-mail]</FONT>
<BR><FONT SIZE=2>Subject: Re: Meaning of Non-repudiation</FONT>
</P>
<BR>
<BR>

<P><FONT SIZE=2>Dave,</FONT>
<BR><FONT SIZE=2>&nbsp;</FONT>
<BR><FONT SIZE=2>&gt; Russ,</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; I believe we are all sorry to resurrect this topic.</FONT>
<BR><FONT SIZE=2>&gt; But it is currently the subject of an X.509 defect,</FONT>
</P>

<P><FONT SIZE=2>Not exactly. Someone would like this topic to be the subject of an X.509</FONT>
<BR><FONT SIZE=2>defect report, but this is is currently *not* the subject of an X.509 defect</FONT>
<BR><FONT SIZE=2>that has been officially raised.</FONT>
</P>

<P><FONT SIZE=2>&gt; and if the text of X.509 eventually changes in a way</FONT>
<BR><FONT SIZE=2>&gt; that is incompatible with Son-of-2459, then</FONT>
<BR><FONT SIZE=2>&gt; Grandson-of-2459 will need to take that into</FONT>
<BR><FONT SIZE=2>&gt; consideration.</FONT>
</P>

<P><FONT SIZE=2>Very unlikely to happen.</FONT>
</P>

<P><FONT SIZE=2>Additional *explanations* without changing the meaning *could* be provided</FONT>
<BR><FONT SIZE=2>and we are (nearly) all saying the same thing using different words. Santosh</FONT>
<BR><FONT SIZE=2>in a subsequent e-mail provided one of these explanations:</FONT>
</P>

<P><FONT SIZE=2>&quot;In my analysis, DS means you are signing some challenge to prove</FONT>
<BR><FONT SIZE=2>possession of a private key and thus authenticate yourself whereas with</FONT>
<BR><FONT SIZE=2>NR you are saying that I know what this data is and I am signing it.&quot; </FONT>
</P>

<P><FONT SIZE=2>I would add that a certificate with the the DS bit set can also be used to</FONT>
<BR><FONT SIZE=2>authenticate data (this does not mean that the signer has read the data).</FONT>
</P>

<P><FONT SIZE=2>Now, there are cases where, beyond the fact that the signer did know what he</FONT>
<BR><FONT SIZE=2>signed, he wants to say exactly what its signature means.</FONT>
</P>

<P><FONT SIZE=2>This can be achieved using three ways:</FONT>
</P>

<P><FONT SIZE=2>1) the document that is signed is unambiguous and its semantics says that</FONT>
<BR><FONT SIZE=2>the signature means XXX.</FONT>
</P>

<P><FONT SIZE=2>2) a signed attribute (using the CMS language) is signed in addition to the</FONT>
<BR><FONT SIZE=2>document and indicates a signature policy that is explicit about the meaning</FONT>
<BR><FONT SIZE=2>of all signatures performed under that policy (note that one single meaning</FONT>
<BR><FONT SIZE=2>is possible in that case).</FONT>
</P>

<P><FONT SIZE=2>3) another signed attribute (using the CMS language) is signed in addition</FONT>
<BR><FONT SIZE=2>to the document and the previous attribute. It indicates the type of</FONT>
<BR><FONT SIZE=2>commitment being made under the signature policy for that signature </FONT>
<BR><FONT SIZE=2>(note that multiple meanings are possible in that case).</FONT>
</P>

<P><FONT SIZE=2>As a result, the variety of meanings is NOT placed in the Certificate Policy</FONT>
<BR><FONT SIZE=2>from the CA.</FONT>
</P>

<P><FONT SIZE=2>&gt; We can all live with the text because we have no consensus on </FONT>
<BR><FONT SIZE=2>&gt; anything better.&nbsp; </FONT>
</P>

<P><FONT SIZE=2>Fine.</FONT>
</P>

<P><FONT SIZE=2>Denis</FONT>
</P>

<P><FONT SIZE=2>&gt; That doesn't rule out the faint hope that the ITU can develop a</FONT>
<BR><FONT SIZE=2>&gt; meaningful replacement in the future.</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; Dave</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; &quot;Housley, Russ&quot; wrote:</FONT>
<BR><FONT SIZE=2>&gt; &gt;</FONT>
<BR><FONT SIZE=2>&gt; &gt; Dave:</FONT>
<BR><FONT SIZE=2>&gt; &gt;</FONT>
<BR><FONT SIZE=2>&gt; &gt; I am sorry that I replied to this thread at all.&nbsp; This topic has been debated</FONT>
<BR><FONT SIZE=2>&gt; &gt; before, and the text in Son-of-RFC 2459 is the result of that debate.</FONT>
<BR><FONT SIZE=2>&gt; &gt; Obviously, everyone can live with that text because no objections were raised</FONT>
<BR><FONT SIZE=2>&gt; &gt; during WG Last Call or IETF Last Call.</FONT>
<BR><FONT SIZE=2>&gt; &gt;</FONT>
<BR><FONT SIZE=2>&gt; &gt; I am not surprised that there is not 100% agreement....</FONT>
<BR><FONT SIZE=2>&gt; &gt;</FONT>
<BR><FONT SIZE=2>&gt; &gt; Russ</FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C1F2D2.1B5B3260--


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g43HsJT16708 for ietf-pkix-bks; Fri, 3 May 2002 10:54:19 -0700 (PDT)
Received: from mtiwmhc22.worldnet.att.net (mtiwmhc22.worldnet.att.net [204.127.131.47]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g43HsJa16704 for <[e-mail]>; Fri, 3 May 2002 10:54:19 -0700 (PDT)
Received: from Chokhani ([12.91.130.3]) by mtiwmhc22.worldnet.att.net (InterMail vM.4.01.03.27 201-229-121-127-20010626) with ESMTP id <20020503175413.IUNF28991.mtiwmhc22.worldnet.att.net@Chokhani>; Fri, 3 May 2002 17:54:13 +0000
From: "Santosh Chokhani" <[e-mail]>
To: <[e-mail]>, "'Omer Hasret'" <[e-mail]>
Cc: <[e-mail]>
Subject: RE: Meaning of Non-repudiation
Date: Fri, 3 May 2002 13:55:44 -0400
Message-ID: <005d01c1f2cb$c02a8720$a300a8c0@Chokhani>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.2627
Importance: Normal
In-Reply-To: <[e-mail]>
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4910.0300
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id g43HsJa16705
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

I think EKU provide application specific refinement, e.g., code signing.

But, key usage has the basic operations.  The distinction between
signing a challenge and data that you take some ownership to belongs in
key usage.

-----Original Message-----
From: [e-mail] [mailto:[e-mail]]
On Behalf Of [e-mail]
Sent: Friday, May 03, 2002 9:43 AM
To: Omer Hasret
Cc: 'Santosh Chokhani'; [e-mail]
Subject: RE: Meaning of Non-repudiation






"Extended Key Usage" is meant for that purpose, isn't it ? Or "Policy
Identifier" could provide this kind of information.
|------------------------+------------------------+---------------------
---|
|                        |   "Omer Hasret"        |
|
|                        |   <[e-mail]>  |           To:
|
|                        |                        |
<Olaf.Schlueter@secar|
|                        |   03.05.2002 14:53     |   tis.com>,
|
|                        |                        |
<[e-mail]>  |
|                        |                        |           cc:
|
|                        |                        |   "'Santosh
Chokhani'" |
|                        |                        |
<[e-mail]|
|                        |                        |   m>
|
|                        |                        |           Subject:
|
|                        |                        |   RE: Meaning of
|
|                        |                        |   Non-repudiation
|
|------------------------+------------------------+---------------------
---|








Olaf,

See below,

> -----Original Message-----
> From: [e-mail] 
> [mailto:[e-mail]] On Behalf Of 
> [e-mail]
> Sent: vendredi 3 mai 2002 12:43
> To: [e-mail]
> Cc: 'Santosh Chokhani'; [e-mail]; 
> [e-mail]; 'Trevor Freeman'
> Subject: RE: Meaning of Non-repudiation
>
>
>
>
>
>
> The NR bit in a certifiicate does not proof anything. It is a 
> statement made by the signer and/or the CA about the intended use of 
> the key. KeyUsage bits are currently used to support key pair 
> separation for the three basic use cases of public key cryptography: 
> encryption, authentication and digital signing. Most application 
> choose public key certificates needed for a certain type of operation 
> based on the keyUsage
> bits: with keyEncipherment to encrypt a message, with digitalSignature

> to verify the response to a challenge for authentication, or to verify

> signature made on e-mail. These two bits are essential (and 
> sufficient) to support key pair seperation per RSA operation 
> capability (decryption or
> signing) of the private key as the RSA operation capabilities of 
> private keys may be restricted by hardware implementation (i.e. a 
> crypto processor card may be configured to allow only signing with a 
> private key, or decryption, and check padding and format of 
> input/output before and after the operation or even include part or 
> all of the hashing procedure).
>
> If one wants to ensure that a private key is only used to sign data, 
> but not to sign an arbitrary challenge, (which practically means "can 
> be used within S/MIME but not within
> SSL")  which is the case e.g. within the signature law compliant use 
> cases, a new bit is needed to clearly distinguish between public keys 
> used for authentication and for signature verification. In all specs 
> that adress this seperation the nonRepudiation bit is used for that 
> purpose. And I cannot see a need for changing that..

Therefore you say that the NR bit is set when we want to use the
certificate for "digital signature" which actually is just the
authentication of the sender for S/MIME messages and nothing else. No
one is trying to change this. However, everyone should know that this
does not prove anything. So if you give different CPs the freedom of
loading whatever meaning they want to the NR bit, there will be
problems.

Besides, I also see the need for another bit which actually states that
"I have read and agree with the content of this message" like real
signatures. (I think the DS bit can be used for this. But everyone
should have exactly the same understanding of these bits.)




> |------------------------+------------------------+-----------
-------------|
> |                        |   "Omer Hasret"        |
>              |
> |                        |   <[e-mail]>  |
> To:          |
> |                        |   Sent by:             |
> "'Trevor Freeman'"   |
> |                        |   owner-ietf-pkix@mail.|
> <[e-mail]|
> |                        |   imc.org              |
> osoft.com>, "'Santosh|
> |                        |                        |
> Chokhani'"           |
> |                        |   03.05.2002 10:52     |
> <[e-mail]|
> |                        |                        |   m>
>              |
> |                        |                        |
> cc:          |
> |                        |                        |
> <[e-mail]>  |
> |                        |                        |
> Subject:     |
> |                        |                        |   RE:
> Meaning of       |
> |                        |                        |
> Non-repudiation      |
> |------------------------+------------------------+-----------
-------------|
>
>
>
>
>
>
>
>
> Trevor, Santosh,
>
> It is certain that everybody will need some means of proving that he 
> is the originator of a specific message, document, whatever. And when 
> we talk about the NR bit on a certificate, I believe the only thing 
> this proves is that a specific data is signed by the holder of this 
> certificate. This never means that the signer agrees with the content 
> or not. Therefore there is no need to load other meanings to this one 
> bit changing from policy to policy. Just standardize its use only
> for authentication and let others who want to implement their
> own NR systems do it by other means. (Some ways to do this
> have been posted on the list a day or two days ago.) And I
> really do not think this as a "dictation" because you don't
> have to use that bit just because its name is NR.
>
> >
> >
> >
> > Hi Santosh,
> > That still sounds like a policy decision.
> > A signature over an SSL challenge is potentially just as
> valid a piece
> > of a NR jigsaw puzzle as any other signature. Why are we dictating 
> > what someone wants as a NR process? If you want to build a system 
> > where NR signatures only occur over documents - fine by me,
> but don't
> > dictate how I build my NR system. Trevor
> >
> > -----Original Message-----
> > From: Santosh Chokhani [mailto:[e-mail]]
> > Sent: Thursday, May 02, 2002 2:03 PM
> > To: Trevor Freeman; 'Denis Pinkas'; 'David P. Kemp'
> > Cc: [e-mail]
> > Subject: RE: Meaning of Non-repudiation
> >
> > Trevor:
> >
> > I also made a resolution long time back when ABA started a
> debate on
> > this.  But, I also broke it.
> >
> > I do think that there is a value in SSL case to say that I am not 
> > owning up to signature (as attesting to something) except I
> signed a
> > challenge. Thus, subscriber (possessor of the private key)
> should be
> > able to use a separate key so that he can claim he simply signed a 
> > random challenge.
> >
> > -----Original Message-----
> > From: [e-mail] 
> > [mailto:[e-mail]]
> > On Behalf Of Trevor Freeman
> > Sent: Thursday, May 02, 2002 2:53 PM
> > To: Denis Pinkas; David P. Kemp
> > Cc: [e-mail]
> > Subject: RE: Meaning of Non-repudiation
> >
> >
> >
> > I am breaking one of my New Year resolutions by mailing on
> this topic,
> > but here goes...
> >
> > Signing anything is always a challenge to prove position of
> a private
> > key to authenticate whether it's in the context of a
> protocol like SSL
> > or over a SMIME message. Technically all we can say is the
> signature
> > occurred. The intent behind why the signature occurred is
> beyond the
> > scope of this discussion. Use of certificates with the NR
> bit asserted
> > is ultimately a matter of local policy on what constitutes usage as 
> > part of a non-repudiation service since two organisations could have

> > two separate non repudiation serves where one requires a NR 
> > signature as part of an SSL session, and the other only wants NR 
> > signatures over SMIME messages.
> >
> > Never in the course of IETF has history so much been written over 
> > something so small.
> >
> > Trevor
> >
> > -----Original Message-----
> > From: Denis Pinkas [mailto:[e-mail]]
> > Sent: Thursday, May 02, 2002 2:27 AM
> > To: David P. Kemp
> > Cc: [e-mail]
> > Subject: Re: Meaning of Non-repudiation
> >
> >
> > Dave,
> >
> > > Russ,
> > >
> > > I believe we are all sorry to resurrect this topic.
> > > But it is currently the subject of an X.509 defect,
> >
> > Not exactly. Someone would like this topic to be the subject of an 
> > X.509 defect report, but this is is currently *not* the
> subject of an
> > X.509 defect that has been officially raised.
> >
> > > and if the text of X.509 eventually changes in a way
> > > that is incompatible with Son-of-2459, then Grandson-of-2459 will 
> > > need to take that into consideration.
> >
> > Very unlikely to happen.
> >
> > Additional *explanations* without changing the meaning
> > *could* be provided and we are (nearly) all saying the same thing 
> > using different words. Santosh in a subsequent e-mail
> provided one of
> > these
> > explanations:
> >
> > "In my analysis, DS means you are signing some challenge to prove 
> > possession of a private key and thus authenticate yourself whereas 
> > with NR you are saying that I know what this data is and I
> am signing
> > it."
> >
> > I would add that a certificate with the the DS bit set can also be 
> > used to authenticate data (this does not mean that the
> signer has read
> > the data).
> >
> > Now, there are cases where, beyond the fact that the signer
> did know
> > what he signed, he wants to say exactly what its signature means.
> >
> > This can be achieved using three ways:
> >
> > 1) the document that is signed is unambiguous and its
> semantics says
> > that the signature means XXX.
> >
> > 2) a signed attribute (using the CMS language) is signed in
> addition
> > to the document and indicates a signature policy that is explicit 
> > about the meaning of all signatures performed under that
> policy (note
> > that one single meaning is possible in that case).
> >
> > 3) another signed attribute (using the CMS language) is signed in 
> > addition to the document and the previous attribute. It
> indicates the
> > type of commitment being made under the signature policy for that 
> > signature (note that multiple meanings are possible in that case).
> >
> > As a result, the variety of meanings is NOT placed in the
> Certificate
> > Policy from the CA.
> >
> > > We can all live with the text because we have no consensus
> > on anything
> > > better.
> >
> > Fine.
> >
> > Denis
> >
> > > That doesn't rule out the faint hope that the ITU can develop a 
> > > meaningful replacement in the future.
> > >
> > > Dave
> > >
> > > "Housley, Russ" wrote:
> > > >
> > > > Dave:
> > > >
> > > > I am sorry that I replied to this thread at all.  This topic has
> > been debated
> > > > before, and the text in Son-of-RFC 2459 is the result of that
> > debate.
> > > > Obviously, everyone can live with that text because no
> objections
> > were raised
> > > > during WG Last Call or IETF Last Call.
> > > >
> > > > I am not surprised that there is not 100% agreement....
> > > >
> > > > Russ
> >
>
>
>
>






Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g43HnoK16589 for ietf-pkix-bks; Fri, 3 May 2002 10:49:50 -0700 (PDT)
Received: from nymelsmtp.internet.ny.fdms.firstdata.com ([204.124.248.17]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g43Hnga16584 for <[e-mail]>; Fri, 3 May 2002 10:49:42 -0700 (PDT)
Subject: RE: Meaning of Non-repudiation
To: [e-mail]
Cc: [e-mail]
X-Mailer: Lotus Notes Release 5.0.5  September 22, 2000
Message-ID: <[e-mail]>
From: [e-mail]
Date: Fri, 3 May 2002 11:48:41 -0600
X-MIMETrack: Serialize by Router on NYMELSMTP/NY/FDMS/FDC(Release 5.0.8 |June 18, 2001) at 05/03/2002 01:46:43 PM
MIME-Version: 1.0
Content-type: text/plain; charset=us-ascii
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

in the X9A10 working group (for financial payment standards) provisions
were made for a token acceptor device to also be able to sign a
transaction. the operational characteristic  of the token acceptor device
(like finread standard) would be registered (RA; with or w/o a certificate
necessary) which would indicate whether it operated in such a manner as to
require a human interaction implying intention.

a simple hardware token digital signature by itself wasn't sufficient for
implying intention (a necessary pre-requisite before even talking about NR)
... but the process around the execution of the token digital signature was
also necessary for  implying intention. A finread complient reader provides
basis for inferring intention ... but then you still need proof that such a
reader was used for the specific transaction (either because of some
physical boundary, like ATM machines on private networks  ... or because
the token acceptance device is certified and also signs the transaction).

whether or not the digital signing environment was operated according to
acceptable mechanism for implying intention ... is pretty much independent
of whether there is a NR bit flag in a certificate. The additional
signature by a complient/registered token acceptor device attests to the
fact that specific operations were actually observed in conjunction with
the specific signing operation that might then be used to imply intention
on part of a person (as a necessary prerequisite for any attempt at
establishing non-repudiation).

Nominally a person would have to make some indication as to their intention
... that could be done up front to a device ... which would then know to
also only select a public key that had a certificate with a NR bit set.
Note however, it isn't whether a certificate with a NR flag that is
important ... it is important that the process of performing the digital
signature followed precedures necessary for infering intention (and some
registered device can attest to the intention infering process was
followed).

__________________

previous ref:


2) financial card personality ... the card requires that a PIN be entered
for every signature; this has an implicit "intention" or "approval" in
addition to authentication; the card has the aspect of an access card
personality (two factor authentication) as well as the additional implicit
aspect of "intention" or  "approval" because a human interaction is
required for every signature ... aka the re-entry of the PIN for every
signature implying intention. The finread reader standard goes further ...
in that there needs to be a "secure" card acceptor device with secure
display & secure pin-entry (further increasing the probability that the
specific human was involved in the re-entry of the PIN ... and it was done
specifically in conjunction with a specific transaction being displayed).

http://www.garlic.com/~lynn/aadsm11.htm#5 Meaning of non-repudiation




Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g43FgO712839 for ietf-pkix-bks; Fri, 3 May 2002 08:42:24 -0700 (PDT)
Received: from worldtalk1.cooley.com (worldtalk1.cooley.com [63.251.53.135]) by above.proper.com (8.11.6/8.11.3) with SMTP id g43FgMa12834 for <[e-mail]>; Fri, 3 May 2002 08:42:22 -0700 (PDT)
Received: from 10.11.50.23 by worldtalk1.cooley.com with ESMTP ( WorldSecure Server SMTP Relay(WSS) v4.5); Fri, 03 May 2002 08:36:50 -0700
X-Server-Uuid: c4da1ae6-7048-11d2-bc8e-00a083360239
Received: by reexchange.cooley.com with Internet Mail Service ( 5.5.2653.19) id <HYHA1Q4L>; Fri, 3 May 2002 11:38:34 -0400
Message-ID: <[e-mail]>
From: "Sabett, Randy" <[e-mail]>
To: "'Santosh Chokhani'" <[e-mail]>, "'Tony Bartoletti'" <[e-mail]>, "'Omer Hasret'" <[e-mail]>
cc: [e-mail]
Subject: RE: Meaning of Non-repudiation
Date: Fri, 3 May 2002 11:38:32 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
X-WSS-ID: 10CC7118151436-01-04
Content-Type: text/plain;  charset=iso-8859-1
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

All:

I agree with Santosh from a legal perspective as long as the statement that
"we should offer implementations flexibility of having two bits" means that
it will be up to each specific application as to specifically how the bits
will be interpreted, including how the NR bit (or whatever it ends up being
called) is to be used for that application.  I don't believe that we would
ever be able to get every business sector to come to agreement as to exactly
what NR=1 means.  As Russ pointed out, how a particular application uses the
bit can be refined in the CP.

The points made by a number of different people make it clear to me that
most of us are in violent agreement, though we may come at the argument from
different angles.  From a legal perspective, we are dealing with what I view
as a continuous repudiation/nonrepudiation spectrum that cannot be
shoehorned into just two bits.  While, as Tony pointed out, the customer may
want NR=1 to mean "you shall be unable to repudiate", from a legal
perspective you can ALWAYS repudiate.  Then, it becomes a judgment call by a
judge or jury as to whether you really can or cannot repudiate, based on the
particular facts of the case (of which NR=1 may be just one piece of the
evidence).

Steve, in an email from a week ago, elegantly restated the conclusion
reached at the joint ABA ISC and IETF meeting in Washington from a couple of
years ago, where the DS and NR bits were discussed.  The conclusion reached
was that the assertion of the NR bit was necessary but not sufficient for
showing that a party would be bound by a digital signature.  This means that
other dynamics that CANNOT be captured in bits must be considered (since it
would be difficult to implement a repudiation bit that, e.g., could be used
to indicate someone being forced to sign did so because that person had a
gun pointed to his or her head).

Regards,

R.

	_______________________________
	Randy V. Sabett, J.D., CISSP
	Cooley Godward LLP
	One Freedom Square, Reston Town Center
	11951 Freedom Drive
	Reston, VA  20190-5656
	Direct:		703.456.8137
	Main:		703.456.8000
	Cell:		703.597.6521
	Fax:		[phone]
	E-Mail:	[e-mail]
	http://www.cooley.com
	
http://www.cooley.com/practice_and_people.ixe?section=Attorney+Biographies&i
d=SABETTRV
	Broomfield * Kirkland * Menlo Park * Palo Alto * Reston * San Diego
* San Francisco

-----Original Message-----
From: Santosh Chokhani [mailto:[e-mail]]
Sent: Friday, May 03, 2002 8:56 AM
To: 'Tony Bartoletti'; 'Omer Hasret'
Cc: [e-mail]
Subject: RE: Meaning of Non-repudiation



Folks:

I am a bit confused.  I have NOT said that NR = 1 means non-repudiation.
All I have said is that we have two bits.  They may be a bit of
misnomer.  We should use one bit for signing challenges for
authentication and another one for signing data for the purposes of
"source authentication" and "data integrity"

What we call them is up to us.  Thus, we should offer implementations
flexibility of having two bits.

-----Original Message-----
From: Tony Bartoletti [mailto:[e-mail]] 
Sent: Thursday, May 02, 2002 9:06 PM
To: Omer Hasret; 'Santosh Chokhani'
Cc: [e-mail]
Subject: RE: Meaning of Non-repudiation


At 10:46 AM 5/2/02 +0200, Omer Hasret wrote:

>Even if it is like Santosh says for the signing and the relying party, 
>my opinion is that it is not enough. I also think that the meaning of 
>these concepts should be the same for all parties including the 
>software developer.

I agree.  And if we allow this bit to represent something "sufficiently 
mechanical" (ala Tom Ginden's "Technical Nonrepudiation") we might
someday 
arrive at a "concept" that all can come close to recognizing.

Unfortunately, the customer expects NR=1 to mean, "If you signed
something 
with this key, you shall be unable to repudiate ... something" (that you

signed, and signed willfully, and signed knowingly, etc.)  This is just
too 
foggy for all of the interested parties to come to an agreement, except 
over certain specific types of situations (which would make the NR-bit 
useful to certain communities and not so much to others).

Indeed, in some contexts, NR "trumps the facts".  That is, the holder of
an 
NR-signed item can act "as if" you signed it, even if it can be
otherwise 
proven that you actually did not.  In this context, you have entered
into 
an agreement that "you will abide by the outcome, irrespective of intent
or 
even of involvement."  This is (loosely) analogous to the $50 you agree
to 
forfeit if your credit card is abused, irrespective of who actually used

it, how it was subverted, etc.

Cheers!

___tony___


Tony Bartoletti 925-422-3881 <[e-mail]>
Information Operations, Warfare and Assurance Center
Lawrence Livermore National Laboratory
Livermore, CA 94551-9900





=======================================================
This email message is for the sole use of the intended recipient(s) and may contain confidential and privileged information. Any unauthorized review, use, disclosure or distribution is prohibited.  If you are not the intended recipient, please contact the sender by reply email and destroy all copies of the original message




Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g43FbkI12686 for ietf-pkix-bks; Fri, 3 May 2002 08:37:46 -0700 (PDT)
Received: from fw1.gdm.de (fw1.gdm.de [193.108.184.254]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g43Fbia12677; Fri, 3 May 2002 08:37:44 -0700 (PDT)
Received: (from root@localhost) by fw1.gdm.de (8.11.6/8.11.6) id g43FbaJ03684; Fri, 3 May 2002 17:37:36 +0200 (CEST)
Received: (from localhost) by fw1.gdm.de (MSCAN) id 3/fw1.gdm.de/smtp-gw/mscan; Fri May  3 17:37:36 2002
To: Aram Perez <[e-mail]>
Cc: PKIX <[e-mail]>, [e-mail]
Subject: Re: Meaning of Non-repudiation
MIME-Version: 1.0
X-Mailer: Lotus Notes Release 5.07a  May 14, 2001
Message-ID: <[e-mail]>
From: [e-mail]
Date: Fri, 3 May 2002 17:32:32 +0200
X-MIMETrack: MIME-CD by tm_grab on NOTESGDM1/SRV/GuD(Release 5.0.8 |June 18, 2001) at 05/03/2002 05:38:34 PM, MIME-CD complete at 05/03/2002 05:38:35 PM, Serialize by Router on NOTESDMZ1/SRV/GuD(Release 5.0.8 |June 18, 2001) at 05/03/2002 05:39:43 PM
Content-type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id g43Fbja12679
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

You can configure bullsh*t in many ways without disobeying technical specs
:-). A configuration like the one you cited, although technically possible,
is rather unlikely to happen in practice. Either you want deny the use of
the key for a certain operation or not. (by the way, all specs I am aware
of specify the combinations DS=1, NR=0 and DS=1, NR=1 as meaningful, NR=1
with DS=0 is specified as "does not make sense" - I actually do not like
this, but I am used to live with it). However, with the situation as
described by you, an authenticator will happily use the first certificate,
and a signature verifier the second, and hopefully the private key of the
user/signer is able to perform all corresponding operations.
|------------------------+------------------------+------------------------|
|                        |   Aram Perez           |                        |
|                        |   <[e-mail]>   |           To:          |
|                        |   Sent by:             |   PKIX                 |
|                        |   owner-ietf-pkix@mail.|   <[e-mail]>  |
|                        |   imc.org              |           cc:          |
|                        |                        |           Subject:     |
|                        |   03.05.2002 15:42     |   Re: Meaning of       |
|                        |                        |   Non-repudiation      |
|------------------------+------------------------+------------------------|









Hi Olaf,

The trouble is that the bits are applied to the certificate and not to
the public key or the private key. Thus, I can have two certificates,
one with DS=1, NR=0, and another with DS=0, NR=1, for the same key pair.

Regards,
Aram Perez

On Friday, May 3, 2002, at 03:43  AM, [e-mail] wrote:

> The NR bit in a certifiicate does not proof anything. It is a statement
> made by the signer and/or the CA about the intended use of the key.
> KeyUsage bits are currently used to support key pair separation for the
> three basic use cases of public key cryptography: encryption,
> authentication and digital signing. Most application choose public key
> certificates needed for a certain type of operation based on the
> keyUsage
> bits: with keyEncipherment to encrypt a message, with digitalSignature
> to
> verify the response to a challenge for authentication, or to verify
> signature made on e-mail. These two bits are essential (and sufficient)
> to
> support key pair seperation per RSA operation capability (decryption or
> signing) of the private key as the RSA operation capabilities of private
> keys may be restricted by hardware implementation (i.e. a crypto
> processor
> card may be configured to allow only signing with a private key, or
> decryption, and check padding and format of input/output before and
> after
> the operation or even include part or all of the hashing procedure).
>
> If one wants to ensure that a private key is only used to sign data, but
> not to sign an arbitrary challenge, (which practically means "can be
> used
> within S/MIME but not within SSL")  which is the case e.g. within the
> signature law compliant use cases, a new bit is needed to clearly
> distinguish between public keys used for authentication and for
> signature
> verification. In all specs that adress this seperation the
> nonRepudiation
> bit is used for that purpose. And I cannot see a need for changing
> that..
>
|------------------------+------------------------+------------------------|
> |                        |   "Omer
> Hasret"        |                        |
> |                        |   <[e-mail]>  |
> To:          |
> |                        |   Sent by:             |   "'Trevor
> Freeman'"   |
> |                        |   owner-ietf-pkix@mail.|
> <[e-mail]|
> |                        |   imc.org              |   osoft.com>,
> "'Santosh|
> |                        |                        |
> Chokhani'"           |
> |                        |   03.05.2002 10:52     |
> <[e-mail]|
> |                        |                        |
> m>                   |
> |                        |                        |
> cc:          |
> |                        |                        |   <ietf-
> [e-mail]>  |
> |                        |                        |
> Subject:     |
> |                        |                        |   RE: Meaning
> of       |
> |                        |                        |
> Non-repudiation      |
>
|------------------------+------------------------+------------------------|
>
> [snip]






Received: by above.proper.com (8.11.6/8.11.3) id g43EHYR09164 for ietf-pkix-bks; Fri, 3 May 2002 07:17:34 -0700 (PDT)
Received: from stingray.missi.ncsc.mil (stingray.missi.ncsc.mil [144.51.50.20]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g43EHXa09149 for <[e-mail]>; Fri, 3 May 2002 07:17:33 -0700 (PDT)
Received: from stingray.missi.ncsc.mil (root@localhost) by stingray.missi.ncsc.mil with ESMTP id g43EEn616747 for <[e-mail]>; Fri, 3 May 2002 10:14:49 -0400 (EDT)
Message-ID: <[e-mail]>
Date: Fri, 03 May 2002 10:17:23 -0400
From: "David P. Kemp" <[e-mail]>
X-Mailer: Mozilla 4.77 [en] (X11; U; SunOS 5.7 sun4u)
X-Accept-Language: en
MIME-Version: 1.0
To: [e-mail]
Subject: Re: Meaning of Non-repudiation
References: <[e-mail]> <[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
X-H-S-Loop-Check-Ejzfr: 
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Olaf,

I concur as well.   Nothing needs to change about how the bit is used;
only its name needs changing.

Dave

Denis Pinkas wrote:
> 
> Olaf,
> 
> Thank you for these comprehensive explanations.
> 
> I concur.
> 
> Denis
> 
> > The NR bit in a certifiicate does not proof anything. It is a statement
> > made by the signer and/or the CA about the intended use of the key.
> > KeyUsage bits are currently used to support key pair separation for the
> > three basic use cases of public key cryptography: encryption,
> > authentication and digital signing. Most application choose public key
> > certificates needed for a certain type of operation based on the keyUsage
> > bits: with keyEncipherment to encrypt a message, with digitalSignature to
> > verify the response to a challenge for authentication, or to verify
> > signature made on e-mail. These two bits are essential (and sufficient) to
> > support key pair seperation per RSA operation capability (decryption or
> > signing) of the private key as the RSA operation capabilities of private
> > keys may be restricted by hardware implementation (i.e. a crypto processor
> > card may be configured to allow only signing with a private key, or
> > decryption, and check padding and format of input/output before and after
> > the operation or even include part or all of the hashing procedure).
> 
> > If one wants to ensure that a private key is only used to sign data, but
> > not to sign an arbitrary challenge, (which practically means "can be used
> > within S/MIME but not within SSL")  which is the case e.g. within the
> > signature law compliant use cases, a new bit is needed to clearly
> > distinguish between public keys used for authentication and for signature
> > verification. In all specs that adress this seperation the nonRepudiation
> >               -----------------------------------------------------------
> > bit is used for that purpose. And I cannot see a need for changing that.
> > ------------------------------------------------------------------------


Received: by above.proper.com (8.11.6/8.11.3) id g43E39f08535 for ietf-pkix-bks; Fri, 3 May 2002 07:03:09 -0700 (PDT)
Received: from stingray.missi.ncsc.mil (stingray.missi.ncsc.mil [144.51.50.20]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g43E38a08531 for <[e-mail]>; Fri, 3 May 2002 07:03:08 -0700 (PDT)
Received: from stingray.missi.ncsc.mil (root@localhost) by stingray.missi.ncsc.mil with ESMTP id g43E0Oe16078 for <[e-mail]>; Fri, 3 May 2002 10:00:24 -0400 (EDT)
Message-ID: <[e-mail]>
Date: Fri, 03 May 2002 10:02:56 -0400
From: "David P. Kemp" <[e-mail]>
X-Mailer: Mozilla 4.77 [en] (X11; U; SunOS 5.7 sun4u)
X-Accept-Language: en
MIME-Version: 1.0
To: [e-mail]
Subject: Re: Meaning of Non-repudiation
References: <[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
X-H-S-Loop-Check-Ejzfr: 
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Trevor Freeman wrote:
> 
> Hi Santosh,
> That still sounds like a policy decision.
> A signature over an SSL challenge is potentially just as valid a piece
> of a NR jigsaw puzzle as any other signature. Why are we dictating what
> someone wants as a NR process? If you want to build a system where NR
> signatures only occur over documents - fine by me, but don't dictate how
> I build my NR system.
> Trevor




Trevor,

I agree completely.

That is why if:
  key usage bit 0 = digital signature on a "nonce" (*)
        and bit 1 = digital signature on other data

then the name of bit 1 should be changed to something
other than nonRepudiation.  As you say, even a signed
challenge could play a role in some NR systems.

Nonetheless, there is a benefit to having separate key
usage bits for four different categories of data to
be signed: certificates, CRLs, nonces, and
everything else.

The word "non-repudiation" is an obstacle to achieving
that benefit.  Therefore the word must be removed from
the definition of Key Usage, and instead be discussed
in the context of Extended Key Usage, certificate
policies, and best of all, the methods described by
Denis Pinkas: document contents and signed attributes.

Dave



(*) A nonce is data explicitly designed to be
non-replayable in its primary application (e.g. SSL).
The protocol would not serve its primary purpose if
the signed nonce could be replayed, even if there is
a secondary forensic or NR reason for verifying the
signed nonce at a later time.


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g43DmN107680 for ietf-pkix-bks; Fri, 3 May 2002 06:48:23 -0700 (PDT)
Received: from fw1.gdm.de (fw1.gdm.de [193.108.184.254]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g43DmMa07674 for <[e-mail]>; Fri, 3 May 2002 06:48:22 -0700 (PDT)
Received: (from root@localhost) by fw1.gdm.de (8.11.6/8.11.6) id g43Dm9b14426; Fri, 3 May 2002 15:48:09 +0200 (CEST)
Received: (from localhost) by fw1.gdm.de (MSCAN) id 3/fw1.gdm.de/smtp-gw/mscan; Fri May  3 15:48:09 2002
To: "Omer Hasret" <[e-mail]>
Cc: "'Santosh Chokhani'" <[e-mail]>, [e-mail]
Subject: RE: Meaning of Non-repudiation
MIME-Version: 1.0
X-Mailer: Lotus Notes Release 5.07a  May 14, 2001
Message-ID: <[e-mail]>
From: [e-mail]
Date: Fri, 3 May 2002 15:43:03 +0200
X-MIMETrack: MIME-CD by tm_grab on NOTESGDM1/SRV/GuD(Release 5.0.8 |June 18, 2001) at 05/03/2002 03:49:03 PM, MIME-CD complete at 05/03/2002 03:49:03 PM, Serialize by Router on NOTESDMZ1/SRV/GuD(Release 5.0.8 |June 18, 2001) at 05/03/2002 03:50:21 PM
Content-type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id g43DmMa07676
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

"Extended Key Usage" is meant for that purpose, isn't it ? Or "Policy
Identifier" could provide this kind of information.
|------------------------+------------------------+------------------------|
|                        |   "Omer Hasret"        |                        |
|                        |   <[e-mail]>  |           To:          |
|                        |                        |   <Olaf.Schlueter@secar|
|                        |   03.05.2002 14:53     |   tis.com>,            |
|                        |                        |   <[e-mail]>  |
|                        |                        |           cc:          |
|                        |                        |   "'Santosh Chokhani'" |
|                        |                        |   <[e-mail]|
|                        |                        |   m>                   |
|                        |                        |           Subject:     |
|                        |                        |   RE: Meaning of       |
|                        |                        |   Non-repudiation      |
|------------------------+------------------------+------------------------|








Olaf,

See below,

> -----Original Message-----
> From: [e-mail]
> [mailto:[e-mail]] On Behalf Of
> [e-mail]
> Sent: vendredi 3 mai 2002 12:43
> To: [e-mail]
> Cc: 'Santosh Chokhani'; [e-mail];
> [e-mail]; 'Trevor Freeman'
> Subject: RE: Meaning of Non-repudiation
>
>
>
>
>
>
> The NR bit in a certifiicate does not proof anything. It is a
> statement made by the signer and/or the CA about the intended
> use of the key. KeyUsage bits are currently used to support
> key pair separation for the three basic use cases of public
> key cryptography: encryption, authentication and digital
> signing. Most application choose public key certificates
> needed for a certain type of operation based on the keyUsage
> bits: with keyEncipherment to encrypt a message, with
> digitalSignature to verify the response to a challenge for
> authentication, or to verify signature made on e-mail. These
> two bits are essential (and sufficient) to support key pair
> seperation per RSA operation capability (decryption or
> signing) of the private key as the RSA operation capabilities
> of private keys may be restricted by hardware implementation
> (i.e. a crypto processor card may be configured to allow only
> signing with a private key, or decryption, and check padding
> and format of input/output before and after the operation or
> even include part or all of the hashing procedure).
>
> If one wants to ensure that a private key is only used to
> sign data, but not to sign an arbitrary challenge, (which
> practically means "can be used within S/MIME but not within
> SSL")  which is the case e.g. within the signature law
> compliant use cases, a new bit is needed to clearly
> distinguish between public keys used for authentication and
> for signature verification. In all specs that adress this
> seperation the nonRepudiation bit is used for that purpose.
> And I cannot see a need for changing that..

Therefore you say that the NR bit is set when we want to use the
certificate for "digital signature" which actually is just the
authentication of the sender for S/MIME messages and nothing else. No
one is trying to change this. However, everyone should know that this
does not prove anything. So if you give different CPs the freedom of
loading whatever meaning they want to the NR bit, there will be
problems.

Besides, I also see the need for another bit which actually states that
"I have read and agree with the content of this message" like real
signatures. (I think the DS bit can be used for this. But everyone
should have exactly the same understanding of these bits.)




> |------------------------+------------------------+-----------
-------------|
> |                        |   "Omer Hasret"        |
>              |
> |                        |   <[e-mail]>  |
> To:          |
> |                        |   Sent by:             |
> "'Trevor Freeman'"   |
> |                        |   owner-ietf-pkix@mail.|
> <[e-mail]|
> |                        |   imc.org              |
> osoft.com>, "'Santosh|
> |                        |                        |
> Chokhani'"           |
> |                        |   03.05.2002 10:52     |
> <[e-mail]|
> |                        |                        |   m>
>              |
> |                        |                        |
> cc:          |
> |                        |                        |
> <[e-mail]>  |
> |                        |                        |
> Subject:     |
> |                        |                        |   RE:
> Meaning of       |
> |                        |                        |
> Non-repudiation      |
> |------------------------+------------------------+-----------
-------------|
>
>
>
>
>
>
>
>
> Trevor, Santosh,
>
> It is certain that everybody will need some means of proving
> that he is the originator of a specific message, document,
> whatever. And when we talk about the NR bit on a certificate,
> I believe the only thing this proves is that a specific data
> is signed by the holder of this certificate. This never means
> that the signer agrees with the content or not. Therefore
> there is no need to load other meanings to this one bit
> changing from policy to policy. Just standardize its use only
> for authentication and let others who want to implement their
> own NR systems do it by other means. (Some ways to do this
> have been posted on the list a day or two days ago.) And I
> really do not think this as a "dictation" because you don't
> have to use that bit just because its name is NR.
>
> >
> >
> >
> > Hi Santosh,
> > That still sounds like a policy decision.
> > A signature over an SSL challenge is potentially just as
> valid a piece
> > of a NR jigsaw puzzle as any other signature. Why are we dictating
> > what someone wants as a NR process? If you want to build a system
> > where NR signatures only occur over documents - fine by me,
> but don't
> > dictate how I build my NR system. Trevor
> >
> > -----Original Message-----
> > From: Santosh Chokhani [mailto:[e-mail]]
> > Sent: Thursday, May 02, 2002 2:03 PM
> > To: Trevor Freeman; 'Denis Pinkas'; 'David P. Kemp'
> > Cc: [e-mail]
> > Subject: RE: Meaning of Non-repudiation
> >
> > Trevor:
> >
> > I also made a resolution long time back when ABA started a
> debate on
> > this.  But, I also broke it.
> >
> > I do think that there is a value in SSL case to say that I am not
> > owning up to signature (as attesting to something) except I
> signed a
> > challenge. Thus, subscriber (possessor of the private key)
> should be
> > able to use a separate key so that he can claim he simply signed a
> > random challenge.
> >
> > -----Original Message-----
> > From: [e-mail]
> > [mailto:[e-mail]]
> > On Behalf Of Trevor Freeman
> > Sent: Thursday, May 02, 2002 2:53 PM
> > To: Denis Pinkas; David P. Kemp
> > Cc: [e-mail]
> > Subject: RE: Meaning of Non-repudiation
> >
> >
> >
> > I am breaking one of my New Year resolutions by mailing on
> this topic,
> > but here goes...
> >
> > Signing anything is always a challenge to prove position of
> a private
> > key to authenticate whether it's in the context of a
> protocol like SSL
> > or over a SMIME message. Technically all we can say is the
> signature
> > occurred. The intent behind why the signature occurred is
> beyond the
> > scope of this discussion. Use of certificates with the NR
> bit asserted
> > is ultimately a matter of local policy on what constitutes usage as
> > part of a non-repudiation service since two organisations could have
> > two separate non repudiation serves where one requires a NR
> > signature as part of an SSL session, and the other only wants
> > NR signatures over SMIME messages.
> >
> > Never in the course of IETF has history so much been written over
> > something so small.
> >
> > Trevor
> >
> > -----Original Message-----
> > From: Denis Pinkas [mailto:[e-mail]]
> > Sent: Thursday, May 02, 2002 2:27 AM
> > To: David P. Kemp
> > Cc: [e-mail]
> > Subject: Re: Meaning of Non-repudiation
> >
> >
> > Dave,
> >
> > > Russ,
> > >
> > > I believe we are all sorry to resurrect this topic.
> > > But it is currently the subject of an X.509 defect,
> >
> > Not exactly. Someone would like this topic to be the subject of an
> > X.509 defect report, but this is is currently *not* the
> subject of an
> > X.509 defect that has been officially raised.
> >
> > > and if the text of X.509 eventually changes in a way
> > > that is incompatible with Son-of-2459, then Grandson-of-2459 will
> > > need to take that into consideration.
> >
> > Very unlikely to happen.
> >
> > Additional *explanations* without changing the meaning
> > *could* be provided and we are (nearly) all saying the same thing
> > using different words. Santosh in a subsequent e-mail
> provided one of
> > these
> > explanations:
> >
> > "In my analysis, DS means you are signing some challenge to prove
> > possession of a private key and thus authenticate yourself whereas
> > with NR you are saying that I know what this data is and I
> am signing
> > it."
> >
> > I would add that a certificate with the the DS bit set can also be
> > used to authenticate data (this does not mean that the
> signer has read
> > the data).
> >
> > Now, there are cases where, beyond the fact that the signer
> did know
> > what he signed, he wants to say exactly what its signature means.
> >
> > This can be achieved using three ways:
> >
> > 1) the document that is signed is unambiguous and its
> semantics says
> > that the signature means XXX.
> >
> > 2) a signed attribute (using the CMS language) is signed in
> addition
> > to the document and indicates a signature policy that is explicit
> > about the meaning of all signatures performed under that
> policy (note
> > that one single meaning is possible in that case).
> >
> > 3) another signed attribute (using the CMS language) is signed in
> > addition to the document and the previous attribute. It
> indicates the
> > type of commitment being made under the signature policy for that
> > signature (note that multiple meanings are possible in that case).
> >
> > As a result, the variety of meanings is NOT placed in the
> Certificate
> > Policy from the CA.
> >
> > > We can all live with the text because we have no consensus
> > on anything
> > > better.
> >
> > Fine.
> >
> > Denis
> >
> > > That doesn't rule out the faint hope that the ITU can develop a
> > > meaningful replacement in the future.
> > >
> > > Dave
> > >
> > > "Housley, Russ" wrote:
> > > >
> > > > Dave:
> > > >
> > > > I am sorry that I replied to this thread at all.  This topic has
> > been debated
> > > > before, and the text in Son-of-RFC 2459 is the result of that
> > debate.
> > > > Obviously, everyone can live with that text because no
> objections
> > were raised
> > > > during WG Last Call or IETF Last Call.
> > > >
> > > > I am not surprised that there is not 100% agreement....
> > > >
> > > > Russ
> >
>
>
>
>






Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g43Dff507041 for ietf-pkix-bks; Fri, 3 May 2002 06:41:41 -0700 (PDT)
Received: from mta7.pltn13.pbi.net (mta7.pltn13.pbi.net [64.164.98.8]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g43Dffa07037 for <[e-mail]>; Fri, 3 May 2002 06:41:41 -0700 (PDT)
Received: from localhost ([206.170.2.121]) by mta7.pltn13.pbi.net (iPlanet Messaging Server 5.1 (built May  7 2001)) with ESMTP id <[e-mail]> for [e-mail]; Fri, 03 May 2002 06:41:42 -0700 (PDT)
Date: Fri, 03 May 2002 06:42:08 -0700
From: Aram Perez <[e-mail]>
Subject: Re: Meaning of Non-repudiation
In-reply-to: <[e-mail]>
To: PKIX <[e-mail]>
Message-id: <[e-mail]>
MIME-version: 1.0
X-Mailer: Apple Mail (2.481)
Content-type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id g43Dffa07038
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Hi Olaf,

The trouble is that the bits are applied to the certificate and not to 
the public key or the private key. Thus, I can have two certificates, 
one with DS=1, NR=0, and another with DS=0, NR=1, for the same key pair.

Regards,
Aram Perez

On Friday, May 3, 2002, at 03:43  AM, [e-mail] wrote:

> The NR bit in a certifiicate does not proof anything. It is a statement
> made by the signer and/or the CA about the intended use of the key.
> KeyUsage bits are currently used to support key pair separation for the
> three basic use cases of public key cryptography: encryption,
> authentication and digital signing. Most application choose public key
> certificates needed for a certain type of operation based on the 
> keyUsage
> bits: with keyEncipherment to encrypt a message, with digitalSignature 
> to
> verify the response to a challenge for authentication, or to verify
> signature made on e-mail. These two bits are essential (and sufficient) 
> to
> support key pair seperation per RSA operation capability (decryption or
> signing) of the private key as the RSA operation capabilities of private
> keys may be restricted by hardware implementation (i.e. a crypto 
> processor
> card may be configured to allow only signing with a private key, or
> decryption, and check padding and format of input/output before and 
> after
> the operation or even include part or all of the hashing procedure).
>
> If one wants to ensure that a private key is only used to sign data, but
> not to sign an arbitrary challenge, (which practically means "can be 
> used
> within S/MIME but not within SSL")  which is the case e.g. within the
> signature law compliant use cases, a new bit is needed to clearly
> distinguish between public keys used for authentication and for 
> signature
> verification. In all specs that adress this seperation the 
> nonRepudiation
> bit is used for that purpose. And I cannot see a need for changing 
> that..
> |------------------------+------------------------+------------------------|
> |                        |   "Omer 
> Hasret"        |                        |
> |                        |   <[e-mail]>  |           
> To:          |
> |                        |   Sent by:             |   "'Trevor 
> Freeman'"   |
> |                        |   owner-ietf-pkix@mail.|   
> <[e-mail]|
> |                        |   imc.org              |   osoft.com>, 
> "'Santosh|
> |                        |                        |   
> Chokhani'"           |
> |                        |   03.05.2002 10:52     |   
> <[e-mail]|
> |                        |                        |   
> m>                   |
> |                        |                        |           
> cc:          |
> |                        |                        |   <ietf-
> [e-mail]>  |
> |                        |                        |           
> Subject:     |
> |                        |                        |   RE: Meaning 
> of       |
> |                        |                        |   
> Non-repudiation      |
> |------------------------+------------------------+------------------------|
>
> [snip]



Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g43DIS906192 for ietf-pkix-bks; Fri, 3 May 2002 06:18:28 -0700 (PDT)
Received: from mtiwmhc26.worldnet.att.net (mtiwmhc26.worldnet.att.net [204.127.131.51]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g43DIRa06187 for <[e-mail]>; Fri, 3 May 2002 06:18:27 -0700 (PDT)
Received: from Chokhani ([12.91.131.51]) by mtiwmhc26.worldnet.att.net (InterMail vM.4.01.03.27 201-229-121-127-20010626) with ESMTP id <20020503131822.WLPV7485.mtiwmhc26.worldnet.att.net@Chokhani>; Fri, 3 May 2002 13:18:22 +0000
From: "Santosh Chokhani" <[e-mail]>
To: "'Trevor Freeman'" <[e-mail]>, "'Denis Pinkas'" <[e-mail]>, "'David P. Kemp'" <[e-mail]>
Cc: <[e-mail]>
Subject: RE: Meaning of Non-repudiation
Date: Fri, 3 May 2002 09:19:54 -0400
Message-ID: <001a01c1f2a5$3766e3a0$a300a8c0@Chokhani>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.2627
Importance: Normal
In-Reply-To: <[e-mail]>
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4910.0300
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Trevor:

I am a bit late in posting and I know a lot of other folks have seconded
your view.  I look at the whole matter little differently.  My reasoning
is as follows:

The standard does not mandate using separate keys for encryption and
signature, but offers the implementations that opportunity by having two
bits.  Thus, one implementation can set both bits for dual usage, while
another implementation can use two keys.

Same way, we should keep two bits: one for data originated by signer to
which the signer takes some ownership and another one for signing random
challenges in authentication protocols.

This approach accommodates both implementations: 1. use of a single key
to sign anything and everything and 2. use to separate key for digital
signature and another for authentication.

As aside, I for one have never mentioned non-repudiation in this.  I do
think having separate keys is step towards eliminating some of the
non-repudiation related concerns, how so ever small.


-----Original Message-----
From: [e-mail] [mailto:[e-mail]]
On Behalf Of Trevor Freeman
Sent: Thursday, May 02, 2002 5:10 PM
To: Santosh Chokhani; Denis Pinkas; David P. Kemp
Cc: [e-mail]
Subject: RE: Meaning of Non-repudiation



Hi Santosh,
That still sounds like a policy decision. 
A signature over an SSL challenge is potentially just as valid a piece
of a NR jigsaw puzzle as any other signature. Why are we dictating what
someone wants as a NR process? If you want to build a system where NR
signatures only occur over documents - fine by me, but don't dictate how
I build my NR system. Trevor

-----Original Message-----
From: Santosh Chokhani [mailto:[e-mail]] 
Sent: Thursday, May 02, 2002 2:03 PM
To: Trevor Freeman; 'Denis Pinkas'; 'David P. Kemp'
Cc: [e-mail]
Subject: RE: Meaning of Non-repudiation

Trevor:

I also made a resolution long time back when ABA started a debate on
this.  But, I also broke it.

I do think that there is a value in SSL case to say that I am not owning
up to signature (as attesting to something) except I signed a challenge.
Thus, subscriber (possessor of the private key) should be able to use a
separate key so that he can claim he simply signed a random challenge.

-----Original Message-----
From: [e-mail] [mailto:[e-mail]]
On Behalf Of Trevor Freeman
Sent: Thursday, May 02, 2002 2:53 PM
To: Denis Pinkas; David P. Kemp
Cc: [e-mail]
Subject: RE: Meaning of Non-repudiation



I am breaking one of my New Year resolutions by mailing on this topic,
but here goes...

Signing anything is always a challenge to prove position of a private
key to authenticate whether it's in the context of a protocol like SSL
or over a SMIME message. Technically all we can say is the signature
occurred. The intent behind why the signature occurred is beyond the
scope of this discussion. Use of certificates with the NR bit asserted
is ultimately a matter of local policy on what constitutes usage as part
of a non-repudiation service since two organisations could have two
separate non repudiation serves where one requires a NR signature as
part of an SSL session, and the other only wants NR signatures over
SMIME messages.

Never in the course of IETF has history so much been written over
something so small.

Trevor

-----Original Message-----
From: Denis Pinkas [mailto:[e-mail]] 
Sent: Thursday, May 02, 2002 2:27 AM
To: David P. Kemp
Cc: [e-mail]
Subject: Re: Meaning of Non-repudiation


Dave,
 
> Russ,
> 
> I believe we are all sorry to resurrect this topic.
> But it is currently the subject of an X.509 defect,

Not exactly. Someone would like this topic to be the subject of an X.509
defect report, but this is is currently *not* the subject of an X.509
defect that has been officially raised.

> and if the text of X.509 eventually changes in a way
> that is incompatible with Son-of-2459, then
> Grandson-of-2459 will need to take that into
> consideration.

Very unlikely to happen.

Additional *explanations* without changing the meaning *could* be
provided and we are (nearly) all saying the same thing using different
words. Santosh in a subsequent e-mail provided one of these
explanations:

"In my analysis, DS means you are signing some challenge to prove
possession of a private key and thus authenticate yourself whereas with
NR you are saying that I know what this data is and I am signing it." 

I would add that a certificate with the the DS bit set can also be used
to authenticate data (this does not mean that the signer has read the
data).

Now, there are cases where, beyond the fact that the signer did know
what he signed, he wants to say exactly what its signature means.

This can be achieved using three ways:

1) the document that is signed is unambiguous and its semantics says
that the signature means XXX.

2) a signed attribute (using the CMS language) is signed in addition to
the document and indicates a signature policy that is explicit about the
meaning of all signatures performed under that policy (note that one
single meaning is possible in that case).

3) another signed attribute (using the CMS language) is signed in
addition to the document and the previous attribute. It indicates the
type of commitment being made under the signature policy for that
signature 
(note that multiple meanings are possible in that case).

As a result, the variety of meanings is NOT placed in the Certificate
Policy from the CA.

> We can all live with the text because we have no consensus on anything

> better.

Fine.

Denis

> That doesn't rule out the faint hope that the ITU can develop a
> meaningful replacement in the future.
> 
> Dave
> 
> "Housley, Russ" wrote:
> >
> > Dave:
> >
> > I am sorry that I replied to this thread at all.  This topic has
been debated
> > before, and the text in Son-of-RFC 2459 is the result of that
debate.
> > Obviously, everyone can live with that text because no objections
were raised
> > during WG Last Call or IETF Last Call.
> >
> > I am not surprised that there is not 100% agreement....
> >
> > Russ



Received: by above.proper.com (8.11.6/8.11.3) id g43CsS805419 for ietf-pkix-bks; Fri, 3 May 2002 05:54:28 -0700 (PDT)
Received: from mtiwmhc22.worldnet.att.net (mtiwmhc22.worldnet.att.net [204.127.131.47]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g43CsRa05415 for <[e-mail]>; Fri, 3 May 2002 05:54:27 -0700 (PDT)
Received: from Chokhani ([12.91.131.51]) by mtiwmhc22.worldnet.att.net (InterMail vM.4.01.03.27 201-229-121-127-20010626) with ESMTP id <20020503125422.DUAH28991.mtiwmhc22.worldnet.att.net@Chokhani>; Fri, 3 May 2002 12:54:22 +0000
From: "Santosh Chokhani" <[e-mail]>
To: "'Tony Bartoletti'" <[e-mail]>, "'Omer Hasret'" <[e-mail]>
Cc: <[e-mail]>
Subject: RE: Meaning of Non-repudiation
Date: Fri, 3 May 2002 08:55:55 -0400
Message-ID: <000601c1f2a1$dd803d30$a300a8c0@Chokhani>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.2627
Importance: Normal
In-Reply-To: <[e-mail]>
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4910.0300
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Folks:

I am a bit confused.  I have NOT said that NR = 1 means non-repudiation.
All I have said is that we have two bits.  They may be a bit of
misnomer.  We should use one bit for signing challenges for
authentication and another one for signing data for the purposes of
"source authentication" and "data integrity"

What we call them is up to us.  Thus, we should offer implementations
flexibility of having two bits.

-----Original Message-----
From: Tony Bartoletti [mailto:[e-mail]] 
Sent: Thursday, May 02, 2002 9:06 PM
To: Omer Hasret; 'Santosh Chokhani'
Cc: [e-mail]
Subject: RE: Meaning of Non-repudiation


At 10:46 AM 5/2/02 +0200, Omer Hasret wrote:

>Even if it is like Santosh says for the signing and the relying party, 
>my opinion is that it is not enough. I also think that the meaning of 
>these concepts should be the same for all parties including the 
>software developer.

I agree.  And if we allow this bit to represent something "sufficiently 
mechanical" (ala Tom Ginden's "Technical Nonrepudiation") we might
someday 
arrive at a "concept" that all can come close to recognizing.

Unfortunately, the customer expects NR=1 to mean, "If you signed
something 
with this key, you shall be unable to repudiate ... something" (that you

signed, and signed willfully, and signed knowingly, etc.)  This is just
too 
foggy for all of the interested parties to come to an agreement, except 
over certain specific types of situations (which would make the NR-bit 
useful to certain communities and not so much to others).

Indeed, in some contexts, NR "trumps the facts".  That is, the holder of
an 
NR-signed item can act "as if" you signed it, even if it can be
otherwise 
proven that you actually did not.  In this context, you have entered
into 
an agreement that "you will abide by the outcome, irrespective of intent
or 
even of involvement."  This is (loosely) analogous to the $50 you agree
to 
forfeit if your credit card is abused, irrespective of who actually used

it, how it was subverted, etc.

Cheers!

___tony___


Tony Bartoletti 925-422-3881 <[e-mail]>
Information Operations, Warfare and Assurance Center
Lawrence Livermore National Laboratory
Livermore, CA 94551-9900






Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g43CrPd05401 for ietf-pkix-bks; Fri, 3 May 2002 05:53:25 -0700 (PDT)
Received: from mailbu.belbone.be (mailbu.belbone.be [195.13.2.31]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g43CrOa05397 for <[e-mail]>; Fri, 3 May 2002 05:53:24 -0700 (PDT)
Received: from ETRUST001 (195.13.18.125) by mailbu.belbone.be; 3 May 2002 14:53:24 +0200
From: "Omer Hasret" <[e-mail]>
To: <[e-mail]>, <[e-mail]>
Cc: "'Santosh Chokhani'" <[e-mail]>
Subject: RE: Meaning of Non-repudiation
Date: Fri, 3 May 2002 14:53:24 +0200
Message-ID: <004d01c1f2a1$8339bc20$0900a8c0@ETRUST001>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.2627
In-Reply-To: <[e-mail]>
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
Importance: Normal
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id g43CrPa05398
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Olaf,

See below,

> -----Original Message-----
> From: [e-mail] 
> [mailto:[e-mail]] On Behalf Of 
> [e-mail]
> Sent: vendredi 3 mai 2002 12:43
> To: [e-mail]
> Cc: 'Santosh Chokhani'; [e-mail]; 
> [e-mail]; 'Trevor Freeman'
> Subject: RE: Meaning of Non-repudiation
> 
> 
> 
> 
> 
> 
> The NR bit in a certifiicate does not proof anything. It is a 
> statement made by the signer and/or the CA about the intended 
> use of the key. KeyUsage bits are currently used to support 
> key pair separation for the three basic use cases of public 
> key cryptography: encryption, authentication and digital 
> signing. Most application choose public key certificates 
> needed for a certain type of operation based on the keyUsage
> bits: with keyEncipherment to encrypt a message, with 
> digitalSignature to verify the response to a challenge for 
> authentication, or to verify signature made on e-mail. These 
> two bits are essential (and sufficient) to support key pair 
> seperation per RSA operation capability (decryption or
> signing) of the private key as the RSA operation capabilities 
> of private keys may be restricted by hardware implementation 
> (i.e. a crypto processor card may be configured to allow only 
> signing with a private key, or decryption, and check padding 
> and format of input/output before and after the operation or 
> even include part or all of the hashing procedure).
> 
> If one wants to ensure that a private key is only used to 
> sign data, but not to sign an arbitrary challenge, (which 
> practically means "can be used within S/MIME but not within 
> SSL")  which is the case e.g. within the signature law 
> compliant use cases, a new bit is needed to clearly 
> distinguish between public keys used for authentication and 
> for signature verification. In all specs that adress this 
> seperation the nonRepudiation bit is used for that purpose. 
> And I cannot see a need for changing that..

Therefore you say that the NR bit is set when we want to use the
certificate for "digital signature" which actually is just the
authentication of the sender for S/MIME messages and nothing else. No
one is trying to change this. However, everyone should know that this
does not prove anything. So if you give different CPs the freedom of
loading whatever meaning they want to the NR bit, there will be
problems.

Besides, I also see the need for another bit which actually states that
"I have read and agree with the content of this message" like real
signatures. (I think the DS bit can be used for this. But everyone
should have exactly the same understanding of these bits.)




> |------------------------+------------------------+-----------
-------------|
> |                        |   "Omer Hasret"        |           
>              |
> |                        |   <[e-mail]>  |           
> To:          |
> |                        |   Sent by:             |   
> "'Trevor Freeman'"   |
> |                        |   owner-ietf-pkix@mail.|   
> <[e-mail]|
> |                        |   imc.org              |   
> osoft.com>, "'Santosh|
> |                        |                        |   
> Chokhani'"           |
> |                        |   03.05.2002 10:52     |   
> <[e-mail]|
> |                        |                        |   m>      
>              |
> |                        |                        |           
> cc:          |
> |                        |                        |   
> <[e-mail]>  |
> |                        |                        |           
> Subject:     |
> |                        |                        |   RE: 
> Meaning of       |
> |                        |                        |   
> Non-repudiation      |
> |------------------------+------------------------+-----------
-------------|
> 
> 
> 
> 
> 
> 
> 
> 
> Trevor, Santosh,
> 
> It is certain that everybody will need some means of proving 
> that he is the originator of a specific message, document, 
> whatever. And when we talk about the NR bit on a certificate, 
> I believe the only thing this proves is that a specific data 
> is signed by the holder of this certificate. This never means 
> that the signer agrees with the content or not. Therefore 
> there is no need to load other meanings to this one bit 
> changing from policy to policy. Just standardize its use only 
> for authentication and let others who want to implement their 
> own NR systems do it by other means. (Some ways to do this 
> have been posted on the list a day or two days ago.) And I 
> really do not think this as a "dictation" because you don't 
> have to use that bit just because its name is NR.
> 
> >
> >
> >
> > Hi Santosh,
> > That still sounds like a policy decision.
> > A signature over an SSL challenge is potentially just as 
> valid a piece 
> > of a NR jigsaw puzzle as any other signature. Why are we dictating 
> > what someone wants as a NR process? If you want to build a system 
> > where NR signatures only occur over documents - fine by me, 
> but don't 
> > dictate how I build my NR system. Trevor
> >
> > -----Original Message-----
> > From: Santosh Chokhani [mailto:[e-mail]]
> > Sent: Thursday, May 02, 2002 2:03 PM
> > To: Trevor Freeman; 'Denis Pinkas'; 'David P. Kemp'
> > Cc: [e-mail]
> > Subject: RE: Meaning of Non-repudiation
> >
> > Trevor:
> >
> > I also made a resolution long time back when ABA started a 
> debate on 
> > this.  But, I also broke it.
> >
> > I do think that there is a value in SSL case to say that I am not 
> > owning up to signature (as attesting to something) except I 
> signed a 
> > challenge. Thus, subscriber (possessor of the private key) 
> should be 
> > able to use a separate key so that he can claim he simply signed a 
> > random challenge.
> >
> > -----Original Message-----
> > From: [e-mail] 
> > [mailto:[e-mail]]
> > On Behalf Of Trevor Freeman
> > Sent: Thursday, May 02, 2002 2:53 PM
> > To: Denis Pinkas; David P. Kemp
> > Cc: [e-mail]
> > Subject: RE: Meaning of Non-repudiation
> >
> >
> >
> > I am breaking one of my New Year resolutions by mailing on 
> this topic, 
> > but here goes...
> >
> > Signing anything is always a challenge to prove position of 
> a private 
> > key to authenticate whether it's in the context of a 
> protocol like SSL 
> > or over a SMIME message. Technically all we can say is the 
> signature 
> > occurred. The intent behind why the signature occurred is 
> beyond the 
> > scope of this discussion. Use of certificates with the NR 
> bit asserted 
> > is ultimately a matter of local policy on what constitutes usage as 
> > part of a non-repudiation service since two organisations could have
> > two separate non repudiation serves where one requires a NR
> > signature as part of an SSL session, and the other only wants
> > NR signatures over SMIME messages.
> >
> > Never in the course of IETF has history so much been written over 
> > something so small.
> >
> > Trevor
> >
> > -----Original Message-----
> > From: Denis Pinkas [mailto:[e-mail]]
> > Sent: Thursday, May 02, 2002 2:27 AM
> > To: David P. Kemp
> > Cc: [e-mail]
> > Subject: Re: Meaning of Non-repudiation
> >
> >
> > Dave,
> >
> > > Russ,
> > >
> > > I believe we are all sorry to resurrect this topic.
> > > But it is currently the subject of an X.509 defect,
> >
> > Not exactly. Someone would like this topic to be the subject of an 
> > X.509 defect report, but this is is currently *not* the 
> subject of an 
> > X.509 defect that has been officially raised.
> >
> > > and if the text of X.509 eventually changes in a way
> > > that is incompatible with Son-of-2459, then Grandson-of-2459 will 
> > > need to take that into consideration.
> >
> > Very unlikely to happen.
> >
> > Additional *explanations* without changing the meaning
> > *could* be provided and we are (nearly) all saying the same thing 
> > using different words. Santosh in a subsequent e-mail 
> provided one of 
> > these
> > explanations:
> >
> > "In my analysis, DS means you are signing some challenge to prove 
> > possession of a private key and thus authenticate yourself whereas 
> > with NR you are saying that I know what this data is and I 
> am signing 
> > it."
> >
> > I would add that a certificate with the the DS bit set can also be 
> > used to authenticate data (this does not mean that the 
> signer has read 
> > the data).
> >
> > Now, there are cases where, beyond the fact that the signer 
> did know 
> > what he signed, he wants to say exactly what its signature means.
> >
> > This can be achieved using three ways:
> >
> > 1) the document that is signed is unambiguous and its 
> semantics says 
> > that the signature means XXX.
> >
> > 2) a signed attribute (using the CMS language) is signed in 
> addition 
> > to the document and indicates a signature policy that is explicit 
> > about the meaning of all signatures performed under that 
> policy (note 
> > that one single meaning is possible in that case).
> >
> > 3) another signed attribute (using the CMS language) is signed in 
> > addition to the document and the previous attribute. It 
> indicates the 
> > type of commitment being made under the signature policy for that 
> > signature (note that multiple meanings are possible in that case).
> >
> > As a result, the variety of meanings is NOT placed in the 
> Certificate 
> > Policy from the CA.
> >
> > > We can all live with the text because we have no consensus
> > on anything
> > > better.
> >
> > Fine.
> >
> > Denis
> >
> > > That doesn't rule out the faint hope that the ITU can develop a 
> > > meaningful replacement in the future.
> > >
> > > Dave
> > >
> > > "Housley, Russ" wrote:
> > > >
> > > > Dave:
> > > >
> > > > I am sorry that I replied to this thread at all.  This topic has
> > been debated
> > > > before, and the text in Son-of-RFC 2459 is the result of that
> > debate.
> > > > Obviously, everyone can live with that text because no 
> objections
> > were raised
> > > > during WG Last Call or IETF Last Call.
> > > >
> > > > I am not surprised that there is not 100% agreement....
> > > >
> > > > Russ
> >
> 
> 
> 
> 



Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g43Cbr205045 for ietf-pkix-bks; Fri, 3 May 2002 05:37:53 -0700 (PDT)
Received: from vulcan.rsasecurity.com (vulcan.rsasecurity.com [204.167.114.130]) by above.proper.com (8.11.6/8.11.3) with SMTP id g43Cbpa05041 for <[e-mail]>; Fri, 3 May 2002 05:37:51 -0700 (PDT)
Received: from sdtihq24.securitydynamics.com by vulcan.rsasecurity.com via smtpd (for mail.imc.org [208.184.76.43]) with SMTP; 3 May 2002 12:36:24 UT
Received: from ebola.securitydynamics.com (ebola.securid.com [192.80.211.4]) by sdtihq24.securid.com (Pro-8.9.3/Pro-8.9.3) with ESMTP id IAA22530 for <[e-mail]>; Fri, 3 May 2002 08:36:05 -0400 (EDT)
Received: from exna00.securitydynamics.com (localhost [127.0.0.1]) by ebola.securitydynamics.com (8.10.2+Sun/8.9.1) with ESMTP id g43CbsN27076 for <[e-mail]>; Fri, 3 May 2002 08:37:54 -0400 (EDT)
Received: by exna00.securitydynamics.com with Internet Mail Service (5.5.2653.19) id <HKX15Y77>; Fri, 3 May 2002 08:35:18 -0400
Received: from HOUSLEY-LAP.rsasecurity.com (HOUSLEY-LAP [10.3.16.82]) by exna00.securitydynamics.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id HKX15Y7Z; Fri, 3 May 2002 08:35:15 -0400
From: "Housley, Russ" <[e-mail]>
To: [e-mail]
Cc: [e-mail]
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Version 5.1
Date: Fri, 03 May 2002 08:29:05 -0400
Subject: Re: I-D ACTION:draft-ietf-pkix-logotypes-02.txt
In-Reply-To: <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Peter:

We could clearly support any image format in the manner that you 
suggest.  We want to strike a balance between flexibility and 
interoperability.  Supporting formats that do not have widespread viewer 
software is not really useful.

Russ

At 07:58 PM 5/3/2002 +1200, Peter Gutmann wrote:

>Simon Josefsson <[e-mail]> writes:
>
> >Has the SVG format [1] been considered?  It seems to me that it has some
> >advantages:
>
>Looks like yet another future orphaned graphics format (c.f. "future 
>ex-wife").
>If you really want scalable vector graphics, a better (in the sense of "less
>suboptimal") choice would be EPS, although no vector graphics format is
>terribly practical for display purposes because of the lack of support.
>Probably the most viable (ie least suboptimal) vector format is WMF because
>about 95% of desktop platforms support it by default (actually somewhat more
>than that with libwmf, which will display them under X).
>
>Why not just use the usual { type, value } combination, with selected OIDs for
>common formats?  I can see Shockwave and the usual other stuff used in web
>pages being added fairly quickly if this does take off.  A problem with
>standardising things in this area is that most of the widely-used formats are
>proprietary (SWF, WMF, etc), so you either need to standardise proprietary
>formats or go with open formats which no-one actually uses.
>
>Peter.


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g43B1h326537 for ietf-pkix-bks; Fri, 3 May 2002 04:01:43 -0700 (PDT)
Received: from odin2.bull.net (odin2.bull.net [192.90.70.84]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g43B1fa26533 for <[e-mail]>; Fri, 3 May 2002 04:01:41 -0700 (PDT)
Received: from lvn-m002.frlv.bull.fr (lvn-m002.frlv.bull.fr [129.184.62.72]) by odin2.bull.net (8.9.3/8.9.3) with ESMTP id NAA14960; Fri, 3 May 2002 13:04:26 +0200
Received: from bull.net ([129.184.37.97]) by lvn-m002.frlv.bull.fr (Lotus Domino Release 5.0.8) with ESMTP id 2002050313005611:173 ; Fri, 3 May 2002 13:00:56 +0200 
Message-ID: <[e-mail]>
Date: Fri, 03 May 2002 13:00:55 +0200
From: Denis Pinkas <[e-mail]>
Organization: Bull SA.
X-Mailer: Mozilla 4.7 [fr] (Win98; I)
X-Accept-Language: fr
MIME-Version: 1.0
To: [e-mail]
CC: [e-mail]
Subject: Re: Meaning of Non-repudiation
References: <[e-mail]>
X-MIMETrack: Itemize by SMTP Server on LVN-M002/FR/BULL(Release 5.0.8 |June 18, 2001) at 03/05/2002 13:00:56, Serialize by Router on LVN-M002/FR/BULL(Release 5.0.8 |June 18, 2001) at 03/05/2002 13:01:28, Serialize complete at 03/05/2002 13:01:28
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset=us-ascii
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Olaf,

Thank you for these comprehensive explanations.

I concur.

Denis

> The NR bit in a certifiicate does not proof anything. It is a statement
> made by the signer and/or the CA about the intended use of the key.
> KeyUsage bits are currently used to support key pair separation for the
> three basic use cases of public key cryptography: encryption,
> authentication and digital signing. Most application choose public key
> certificates needed for a certain type of operation based on the keyUsage
> bits: with keyEncipherment to encrypt a message, with digitalSignature to
> verify the response to a challenge for authentication, or to verify
> signature made on e-mail. These two bits are essential (and sufficient) to
> support key pair seperation per RSA operation capability (decryption or
> signing) of the private key as the RSA operation capabilities of private
> keys may be restricted by hardware implementation (i.e. a crypto processor
> card may be configured to allow only signing with a private key, or
> decryption, and check padding and format of input/output before and after
> the operation or even include part or all of the hashing procedure).
 
> If one wants to ensure that a private key is only used to sign data, but
> not to sign an arbitrary challenge, (which practically means "can be used
> within S/MIME but not within SSL")  which is the case e.g. within the
> signature law compliant use cases, a new bit is needed to clearly
> distinguish between public keys used for authentication and for signature
> verification. In all specs that adress this seperation the nonRepudiation
> bit is used for that purpose. And I cannot see a need for changing that..


> |------------------------+------------------------+------------------------|
> |                        |   "Omer Hasret"        |                        |
> |                        |   <[e-mail]>  |           To:          |
> |                        |   Sent by:             |   "'Trevor Freeman'"   |
> |                        |   owner-ietf-pkix@mail.|   <[e-mail]|
> |                        |   imc.org              |   osoft.com>, "'Santosh|
> |                        |                        |   Chokhani'"           |
> |                        |   03.05.2002 10:52     |   <[e-mail]|
> |                        |                        |   m>                   |
> |                        |                        |           cc:          |
> |                        |                        |   <[e-mail]>  |
> |                        |                        |           Subject:     |
> |                        |                        |   RE: Meaning of       |
> |                        |                        |   Non-repudiation      |
> |------------------------+------------------------+------------------------|
> 
> Trevor, Santosh,
> 
> It is certain that everybody will need some means of proving that he is
> the originator of a specific message, document, whatever. And when we
> talk about the NR bit on a certificate, I believe the only thing this
> proves is that a specific data is signed by the holder of this
> certificate. This never means that the signer agrees with the content or
> not. Therefore there is no need to load other meanings to this one bit
> changing from policy to policy. Just standardize its use only for
> authentication and let others who want to implement their own NR systems
> do it by other means. (Some ways to do this have been posted on the list
> a day or two days ago.) And I really do not think this as a "dictation"
> because you don't have to use that bit just because its name is NR.
> 
> >
> >
> >
> > Hi Santosh,
> > That still sounds like a policy decision.
> > A signature over an SSL challenge is potentially just as
> > valid a piece of a NR jigsaw puzzle as any other signature.
> > Why are we dictating what someone wants as a NR process? If
> > you want to build a system where NR signatures only occur
> > over documents - fine by me, but don't dictate how I build my
> > NR system. Trevor
> >
> > -----Original Message-----
> > From: Santosh Chokhani [mailto:[e-mail]]
> > Sent: Thursday, May 02, 2002 2:03 PM
> > To: Trevor Freeman; 'Denis Pinkas'; 'David P. Kemp'
> > Cc: [e-mail]
> > Subject: RE: Meaning of Non-repudiation
> >
> > Trevor:
> >
> > I also made a resolution long time back when ABA started a
> > debate on this.  But, I also broke it.
> >
> > I do think that there is a value in SSL case to say that I am
> > not owning up to signature (as attesting to something) except
> > I signed a challenge. Thus, subscriber (possessor of the
> > private key) should be able to use a separate key so that he
> > can claim he simply signed a random challenge.
> >
> > -----Original Message-----
> > From: [e-mail]
> > [mailto:[e-mail]]
> > On Behalf Of Trevor Freeman
> > Sent: Thursday, May 02, 2002 2:53 PM
> > To: Denis Pinkas; David P. Kemp
> > Cc: [e-mail]
> > Subject: RE: Meaning of Non-repudiation
> >
> >
> >
> > I am breaking one of my New Year resolutions by mailing on
> > this topic, but here goes...
> >
> > Signing anything is always a challenge to prove position of a
> > private key to authenticate whether it's in the context of a
> > protocol like SSL or over a SMIME message. Technically all we
> > can say is the signature occurred. The intent behind why the
> > signature occurred is beyond the scope of this discussion.
> > Use of certificates with the NR bit asserted is ultimately a
> > matter of local policy on what constitutes usage as part of a
> > non-repudiation service since two organisations could have
> > two separate non repudiation serves where one requires a NR
> > signature as part of an SSL session, and the other only wants
> > NR signatures over SMIME messages.
> >
> > Never in the course of IETF has history so much been written
> > over something so small.
> >
> > Trevor
> >
> > -----Original Message-----
> > From: Denis Pinkas [mailto:[e-mail]]
> > Sent: Thursday, May 02, 2002 2:27 AM
> > To: David P. Kemp
> > Cc: [e-mail]
> > Subject: Re: Meaning of Non-repudiation
> >
> >
> > Dave,
> >
> > > Russ,
> > >
> > > I believe we are all sorry to resurrect this topic.
> > > But it is currently the subject of an X.509 defect,
> >
> > Not exactly. Someone would like this topic to be the subject
> > of an X.509 defect report, but this is is currently *not* the
> > subject of an X.509 defect that has been officially raised.
> >
> > > and if the text of X.509 eventually changes in a way
> > > that is incompatible with Son-of-2459, then
> > > Grandson-of-2459 will need to take that into
> > > consideration.
> >
> > Very unlikely to happen.
> >
> > Additional *explanations* without changing the meaning
> > *could* be provided and we are (nearly) all saying the same
> > thing using different words. Santosh in a subsequent e-mail
> > provided one of these
> > explanations:
> >
> > "In my analysis, DS means you are signing some challenge to
> > prove possession of a private key and thus authenticate
> > yourself whereas with NR you are saying that I know what this
> > data is and I am signing it."
> >
> > I would add that a certificate with the the DS bit set can
> > also be used to authenticate data (this does not mean that
> > the signer has read the data).
> >
> > Now, there are cases where, beyond the fact that the signer
> > did know what he signed, he wants to say exactly what its
> > signature means.
> >
> > This can be achieved using three ways:
> >
> > 1) the document that is signed is unambiguous and its
> > semantics says that the signature means XXX.
> >
> > 2) a signed attribute (using the CMS language) is signed in
> > addition to the document and indicates a signature policy
> > that is explicit about the meaning of all signatures
> > performed under that policy (note that one single meaning is
> > possible in that case).
> >
> > 3) another signed attribute (using the CMS language) is
> > signed in addition to the document and the previous
> > attribute. It indicates the type of commitment being made
> > under the signature policy for that signature
> > (note that multiple meanings are possible in that case).
> >
> > As a result, the variety of meanings is NOT placed in the
> > Certificate Policy from the CA.
> >
> > > We can all live with the text because we have no consensus
> > on anything
> > > better.
> >
> > Fine.
> >
> > Denis
> >
> > > That doesn't rule out the faint hope that the ITU can develop a
> > > meaningful replacement in the future.
> > >
> > > Dave
> > >
> > > "Housley, Russ" wrote:
> > > >
> > > > Dave:
> > > >
> > > > I am sorry that I replied to this thread at all.  This topic has
> > been debated
> > > > before, and the text in Son-of-RFC 2459 is the result of that
> > debate.
> > > > Obviously, everyone can live with that text because no objections
> > were raised
> > > > during WG Last Call or IETF Last Call.
> > > >
> > > > I am not surprised that there is not 100% agreement....
> > > >
> > > > Russ
> >


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g43Aofd26140 for ietf-pkix-bks; Fri, 3 May 2002 03:50:41 -0700 (PDT)
Received: from osprey.wedgetail.com (starling.wedgetail.com [202.83.95.124]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g43Aoda26131 for <[e-mail]>; Fri, 3 May 2002 03:50:39 -0700 (PDT)
Received: from wedgetail.com (coot.wedgetail.com [10.10.10.4]) by osprey.wedgetail.com (8.12.2/8.12.2) with ESMTP id g43AnnIU005781; Fri, 3 May 2002 20:49:50 +1000 (EST)
Message-Id: <[e-mail]>
X-Mailer: exmh exmh 2.5 (2001-07-13) with nmh-1.0.4
From: Dean Povey <[e-mail]>
To: [e-mail] (Peter Gutmann)
cc: [e-mail], [e-mail], [e-mail]
Subject: Re: I-D ACTION:draft-ietf-pkix-logotypes-02.txt 
In-reply-to: Your message of "Fri, 03 May 2002 19:58:10 +1200." <[e-mail]> 
Mime-Version: 1.0
Content-Type: multipart/mixed ; boundary="==_Exmh_-3969926960"
Date: Fri, 03 May 2002 20:49:49 +1000
X-Scanned-By: MIMEDefang 2.6 (www dot roaringpenguin dot com slash mimedefang)
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

This is a multipart MIME message.

--==_Exmh_-3969926960
Content-Type: text/plain; charset=us-ascii

On Fri, 03 May 2002 19:58:10 +1200, Peter Gutmann wrote: 

>If you really want scalable vector graphics, a better (in the sense of "less
>suboptimal") choice would be EPS, although no vector graphics format is
>terribly practical for display purposes because of the lack of support.
>Probably the most viable (ie least suboptimal) vector format is WMF because
>about 95% of desktop platforms support it by default (actually somewhat more
>than that with libwmf, which will display them under X).
>
>Why not just use the usual { type, value } combination, with selected OIDs for
>common formats?  I can see Shockwave and the usual other stuff used in web
>pages being added fairly quickly if this does take off.  A problem with
>standardising things in this area is that most of the widely-used formats are
>proprietary (SWF, WMF, etc), so you either need to standardise proprietary
>formats or go with open formats which no-one actually uses.

Argghhh. Make it stop! Let's:

a) recommend a small standard size/aspect ratio
b) recommend 1 or 2 non-proprietary formats
c) use a mime type rather than manage another OID space.

Anyone else that wants to put shockwave in a certificate can do that 
madness in some other way.  The spec should specifically 
_exclude_ non static images, as it may be possible to influence the timing 
of images such that the CA and the relying party are given different views 
of the image (depending on the software used).

Having another look, I think that the logotype extension is probably too
complex. I think perhaps we can solve the problem of people complaining
that the selected image is not in their favourite format or color *and*
simplifying the logotype extension, by doing something like:

LogotypeInfo ::= SEQUENCE OF LogotypeData

LogotypeData ::= SEQUENCE {
	logotypeId    OBJECT IDENTIFIER,
	imageMimeType IA5String, -- e.g. image/jpeg
	reference     LogotypeReference OPTIONAL, -- At least one
	embedded      OCTET STRING OPTIONAL       -- must be present 
}

LogotypeReference ::= SEQUENCE {
	-- if omitted hashAlgorithm is the same as the signature hash 
	-- algorithm. 
	hashAlgorithm     AlgorithmIdentifier OPTIONAL, 
	logotypeHash      OCTET STRING,
	logotypeUri       IA5String 
}

id-logotype-communityLogo OBJECT IDENTIFIER ::= { ... } 
id-logotype-issuerLogo    OBJECT IDENTIFIER ::= { ... }
id-logotype-subjectLogo   OBJECT IDENTIFIER ::= { ... }

Then define a logotypeId for each _type_ of logotype (kind of like a 
policy identifier).  We then severely restrict the standard ones in terms 
of size and formats, and then allow people to dream up their own usage and 
interpretation for any others.

If you want to pick a size for the logotype then I would choose 32x32 for
an embedded image which is the standard Windows icon size and has the 
benefit of being able to be displayed on nearly any sized display.  Some people
might find this unecessarily restrictive, but I think that you have to err
on the side of small.  For external references stick to a square aspect
ratio and allow 128x128 (or at worst 256x256) which is more than enough for
any logo as far as I am concerned [I have attached jpegs of this size 
below for people to compare].  Image type should be static JPEG or PNG
which are both non-proprietary, non royalty incurring formats with wide
support. But the important thing is that this is definitive of one policy
for logotypes which we would expect to be widely supported (e.g. by
browsers).  People can do what other mad stuff they'd like in their own
policy.  Regardless of what is chosen the information on how to display the
image is clear and unambiguous which is how it should be.

The only problem is I couldn't tell if Peter was being sarcastic or not 
*sigh*.

--==_Exmh_-3969926960
Content-Type: image/jpeg ; name="32x32.jpg"
Content-Description: 32x32.jpg
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="32x32.jpg"

/9j/4AAQSkZJRgABAQEBLAEsAAD/2wBDAAgGBgcGBQgHBwcJCQgKDBQNDAsLDBkSEw8UHRof
Hh0aHBwgJC4nICIsIxwcKDcpLDAxNDQ0Hyc5PTgyPC4zNDL/2wBDAQkJCQwLDBgNDRgyIRwh
MjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjL/wAAR
CAAgACADASIAAhEBAxEB/8QAHwAAAQUBAQEBAQEAAAAAAAAAAAECAwQFBgcICQoL/8QAtRAA
AgEDAwIEAwUFBAQAAAF9AQIDAAQRBRIhMUEGE1FhByJxFDKBkaEII0KxwRVS0fAkM2JyggkK
FhcYGRolJicoKSo0NTY3ODk6Q0RFRkdISUpTVFVWV1hZWmNkZWZnaGlqc3R1dnd4eXqDhIWG
h4iJipKTlJWWl5iZmqKjpKWmp6ipqrKztLW2t7i5usLDxMXGx8jJytLT1NXW19jZ2uHi4+Tl
5ufo6erx8vP09fb3+Pn6/8QAHwEAAwEBAQEBAQEBAQAAAAAAAAECAwQFBgcICQoL/8QAtREA
AgECBAQDBAcFBAQAAQJ3AAECAxEEBSExBhJBUQdhcRMiMoEIFEKRobHBCSMzUvAVYnLRChYk
NOEl8RcYGRomJygpKjU2Nzg5OkNERUZHSElKU1RVVldYWVpjZGVmZ2hpanN0dXZ3eHl6goOE
hYaHiImKkpOUlZaXmJmaoqOkpaanqKmqsrO0tba3uLm6wsPExcbHyMnK0tPU1dbX2Nna4uPk
5ebn6Onq8vP09fb3+Pn6/9oADAMBAAIRAxEAPwDHorROh6gsqxtAqEqSWeVFWPGAQ7E4RgSo
KsQQWUYyRmhJHJDK8UqMkiMVZGGCpHUEdjX6TGcZfC7n5/KEo7qw2itE6HqCyrG0CoSpJZ5U
VY8YBDsThGBKgqxBBZRjJGaEkckMrxSoySIxVkYYKkdQR2NEZxl8LuEoSjurHQh9KuIrW3uL
+Flt1kkQmF4o3B8sIkgRSQ/DFmAOQAN54KxzakJba6WfUVlvZWlZbhYSAqliWjBwGAkJJ4GB
nHHmSbcCisVho9W/w/yNXiJdvz/zOjD6VcRWtvcX8LLbrJIhMLxRuD5YRJAikh+GLMAcgAbz
wVw72aS4v7iaWZZ5JJWdpVGA5JJLAYGAevQfQVBRV06Kg73uTOq5q1j/2Q==

--==_Exmh_-3969926960
Content-Type: image/jpeg ; name="128x128.jpg"
Content-Description: 128x128.jpg
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="128x128.jpg"

/9j/4AAQSkZJRgABAQEBLAEsAAD/2wBDAAgGBgcGBQgHBwcJCQgKDBQNDAsLDBkSEw8UHRof
Hh0aHBwgJC4nICIsIxwcKDcpLDAxNDQ0Hyc5PTgyPC4zNDL/2wBDAQkJCQwLDBgNDRgyIRwh
MjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjL/wAAR
CACAAIEDASIAAhEBAxEB/8QAHwAAAQUBAQEBAQEAAAAAAAAAAAECAwQFBgcICQoL/8QAtRAA
AgEDAwIEAwUFBAQAAAF9AQIDAAQRBRIhMUEGE1FhByJxFDKBkaEII0KxwRVS0fAkM2JyggkK
FhcYGRolJicoKSo0NTY3ODk6Q0RFRkdISUpTVFVWV1hZWmNkZWZnaGlqc3R1dnd4eXqDhIWG
h4iJipKTlJWWl5iZmqKjpKWmp6ipqrKztLW2t7i5usLDxMXGx8jJytLT1NXW19jZ2uHi4+Tl
5ufo6erx8vP09fb3+Pn6/8QAHwEAAwEBAQEBAQEBAQAAAAAAAAECAwQFBgcICQoL/8QAtREA
AgECBAQDBAcFBAQAAQJ3AAECAxEEBSExBhJBUQdhcRMiMoEIFEKRobHBCSMzUvAVYnLRChYk
NOEl8RcYGRomJygpKjU2Nzg5OkNERUZHSElKU1RVVldYWVpjZGVmZ2hpanN0dXZ3eHl6goOE
hYaHiImKkpOUlZaXmJmaoqOkpaanqKmqsrO0tba3uLm6wsPExcbHyMnK0tPU1dbX2Nna4uPk
5ebn6Onq8vP09fb3+Pn6/9oADAMBAAIRAxEAPwDHooor9MPz0KKKKACiiigAooooAKKKKACi
iigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAoooo
AKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACi
iigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAoooo
AKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACi
iigAooooAKKKKACiiigAooooAKKKKACiiigAooooAuWOmzagJzC8KiCJ5W8yVVJCqzHavVjh
T0Bx3wOadBpjXNqZY7q387Y8i224mRkUEseBtGArHBIOBwORlum3cdndPLIGKtbzxDaOcvEy
D8MsKs2s+mwaTKFnuo9QkVlZlt1ZduMBFbeCob+I4JwcDjdu56kppu3lbT13N4Rg0r+fX0I7
7R5rGJ3aaGRoZRDcJGWzDIc/K2QAT8rcqSPl68jNM20678wyDYiyNlT8qtjDH0B3Lg+49a19
Z1mDULVo43uJN8wljjmUBLNQG/dRfMcr8wHRf9WvHpWmv4JNHjsA1x+6xIrEjDMeqkdlXLFT
k8lzj958qpzq8q5lr/X9f57t1I0+Z8r/AK/r+uigOmzDSf7SLw+T5qxbRKpfJDHlRyo+Q9cZ
4xmrK6DNIAYbu1mVW2ztGzEQEKzncduGG1HOU3Z28ZyM1o7uNNGubMhvMluIZVOOMIsgOff5
x+taqalpVkbZbGa9MaZ3h7dUbeUZfO3CQ5ZC2UXgDHBBJYqpKqr236aeQ4Rpu1/nr5mPe2TW
Tx/vY5opU8yKWPO11yVJAYAj5lYcgdPTBqtWjrF9Hf3ELJJNO0cWx7icYknO5juYZPIBCjk8
KPoM6tqbk4py3/r+v0RjUSUny7BRRRWhB//Z

--==_Exmh_-3969926960
Content-Type: text/plain; charset=us-ascii

Dean Povey,              |em: [e-mail] |  JCSI: Java security toolkit
Senior S/W Developer     |ph:  [phone]    | uPKI: Embedded/C PKI toolkit
Wedgetail Communications |fax: [phone]    | uSSL: Embedded/C SSL toolkit
Brisbane, Australia      |www: www.wedgetail.com  | XML Security: XML Signatures 

--==_Exmh_-3969926960--




Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g43AmAu25783 for ietf-pkix-bks; Fri, 3 May 2002 03:48:10 -0700 (PDT)
Received: from fw1.gdm.de (fw1.gdm.de [193.108.184.254]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g43Am8a25766; Fri, 3 May 2002 03:48:08 -0700 (PDT)
Received: (from root@localhost) by fw1.gdm.de (8.11.6/8.11.6) id g43Am2B19846; Fri, 3 May 2002 12:48:02 +0200 (CEST)
Received: (from localhost) by fw1.gdm.de (MSCAN) id 3/fw1.gdm.de/smtp-gw/mscan; Fri May  3 12:48:02 2002
To: [e-mail]
Cc: "'Santosh Chokhani'" <[e-mail]>, [e-mail], [e-mail], "'Trevor Freeman'" <[e-mail]>
Subject: RE: Meaning of Non-repudiation
MIME-Version: 1.0
X-Mailer: Lotus Notes Release 5.07a  May 14, 2001
Message-ID: <[e-mail]>
From: [e-mail]
Date: Fri, 3 May 2002 12:43:06 +0200
X-MIMETrack: MIME-CD by tm_grab on NOTESGDM1/SRV/GuD(Release 5.0.8 |June 18, 2001) at 05/03/2002 12:49:03 PM, MIME-CD complete at 05/03/2002 12:49:04 PM, Serialize by Router on NOTESDMZ1/SRV/GuD(Release 5.0.8 |June 18, 2001) at 05/03/2002 12:50:15 PM
Content-type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id g43Am9a25775
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

The NR bit in a certifiicate does not proof anything. It is a statement
made by the signer and/or the CA about the intended use of the key.
KeyUsage bits are currently used to support key pair separation for the
three basic use cases of public key cryptography: encryption,
authentication and digital signing. Most application choose public key
certificates needed for a certain type of operation based on the keyUsage
bits: with keyEncipherment to encrypt a message, with digitalSignature to
verify the response to a challenge for authentication, or to verify
signature made on e-mail. These two bits are essential (and sufficient) to
support key pair seperation per RSA operation capability (decryption or
signing) of the private key as the RSA operation capabilities of private
keys may be restricted by hardware implementation (i.e. a crypto processor
card may be configured to allow only signing with a private key, or
decryption, and check padding and format of input/output before and after
the operation or even include part or all of the hashing procedure).

If one wants to ensure that a private key is only used to sign data, but
not to sign an arbitrary challenge, (which practically means "can be used
within S/MIME but not within SSL")  which is the case e.g. within the
signature law compliant use cases, a new bit is needed to clearly
distinguish between public keys used for authentication and for signature
verification. In all specs that adress this seperation the nonRepudiation
bit is used for that purpose. And I cannot see a need for changing that..
|------------------------+------------------------+------------------------|
|                        |   "Omer Hasret"        |                        |
|                        |   <[e-mail]>  |           To:          |
|                        |   Sent by:             |   "'Trevor Freeman'"   |
|                        |   owner-ietf-pkix@mail.|   <[e-mail]|
|                        |   imc.org              |   osoft.com>, "'Santosh|
|                        |                        |   Chokhani'"           |
|                        |   03.05.2002 10:52     |   <[e-mail]|
|                        |                        |   m>                   |
|                        |                        |           cc:          |
|                        |                        |   <[e-mail]>  |
|                        |                        |           Subject:     |
|                        |                        |   RE: Meaning of       |
|                        |                        |   Non-repudiation      |
|------------------------+------------------------+------------------------|








Trevor, Santosh,

It is certain that everybody will need some means of proving that he is
the originator of a specific message, document, whatever. And when we
talk about the NR bit on a certificate, I believe the only thing this
proves is that a specific data is signed by the holder of this
certificate. This never means that the signer agrees with the content or
not. Therefore there is no need to load other meanings to this one bit
changing from policy to policy. Just standardize its use only for
authentication and let others who want to implement their own NR systems
do it by other means. (Some ways to do this have been posted on the list
a day or two days ago.) And I really do not think this as a "dictation"
because you don't have to use that bit just because its name is NR.

>
>
>
> Hi Santosh,
> That still sounds like a policy decision.
> A signature over an SSL challenge is potentially just as
> valid a piece of a NR jigsaw puzzle as any other signature.
> Why are we dictating what someone wants as a NR process? If
> you want to build a system where NR signatures only occur
> over documents - fine by me, but don't dictate how I build my
> NR system. Trevor
>
> -----Original Message-----
> From: Santosh Chokhani [mailto:[e-mail]]
> Sent: Thursday, May 02, 2002 2:03 PM
> To: Trevor Freeman; 'Denis Pinkas'; 'David P. Kemp'
> Cc: [e-mail]
> Subject: RE: Meaning of Non-repudiation
>
> Trevor:
>
> I also made a resolution long time back when ABA started a
> debate on this.  But, I also broke it.
>
> I do think that there is a value in SSL case to say that I am
> not owning up to signature (as attesting to something) except
> I signed a challenge. Thus, subscriber (possessor of the
> private key) should be able to use a separate key so that he
> can claim he simply signed a random challenge.
>
> -----Original Message-----
> From: [e-mail]
> [mailto:[e-mail]]
> On Behalf Of Trevor Freeman
> Sent: Thursday, May 02, 2002 2:53 PM
> To: Denis Pinkas; David P. Kemp
> Cc: [e-mail]
> Subject: RE: Meaning of Non-repudiation
>
>
>
> I am breaking one of my New Year resolutions by mailing on
> this topic, but here goes...
>
> Signing anything is always a challenge to prove position of a
> private key to authenticate whether it's in the context of a
> protocol like SSL or over a SMIME message. Technically all we
> can say is the signature occurred. The intent behind why the
> signature occurred is beyond the scope of this discussion.
> Use of certificates with the NR bit asserted is ultimately a
> matter of local policy on what constitutes usage as part of a
> non-repudiation service since two organisations could have
> two separate non repudiation serves where one requires a NR
> signature as part of an SSL session, and the other only wants
> NR signatures over SMIME messages.
>
> Never in the course of IETF has history so much been written
> over something so small.
>
> Trevor
>
> -----Original Message-----
> From: Denis Pinkas [mailto:[e-mail]]
> Sent: Thursday, May 02, 2002 2:27 AM
> To: David P. Kemp
> Cc: [e-mail]
> Subject: Re: Meaning of Non-repudiation
>
>
> Dave,
>
> > Russ,
> >
> > I believe we are all sorry to resurrect this topic.
> > But it is currently the subject of an X.509 defect,
>
> Not exactly. Someone would like this topic to be the subject
> of an X.509 defect report, but this is is currently *not* the
> subject of an X.509 defect that has been officially raised.
>
> > and if the text of X.509 eventually changes in a way
> > that is incompatible with Son-of-2459, then
> > Grandson-of-2459 will need to take that into
> > consideration.
>
> Very unlikely to happen.
>
> Additional *explanations* without changing the meaning
> *could* be provided and we are (nearly) all saying the same
> thing using different words. Santosh in a subsequent e-mail
> provided one of these
> explanations:
>
> "In my analysis, DS means you are signing some challenge to
> prove possession of a private key and thus authenticate
> yourself whereas with NR you are saying that I know what this
> data is and I am signing it."
>
> I would add that a certificate with the the DS bit set can
> also be used to authenticate data (this does not mean that
> the signer has read the data).
>
> Now, there are cases where, beyond the fact that the signer
> did know what he signed, he wants to say exactly what its
> signature means.
>
> This can be achieved using three ways:
>
> 1) the document that is signed is unambiguous and its
> semantics says that the signature means XXX.
>
> 2) a signed attribute (using the CMS language) is signed in
> addition to the document and indicates a signature policy
> that is explicit about the meaning of all signatures
> performed under that policy (note that one single meaning is
> possible in that case).
>
> 3) another signed attribute (using the CMS language) is
> signed in addition to the document and the previous
> attribute. It indicates the type of commitment being made
> under the signature policy for that signature
> (note that multiple meanings are possible in that case).
>
> As a result, the variety of meanings is NOT placed in the
> Certificate Policy from the CA.
>
> > We can all live with the text because we have no consensus
> on anything
> > better.
>
> Fine.
>
> Denis
>
> > That doesn't rule out the faint hope that the ITU can develop a
> > meaningful replacement in the future.
> >
> > Dave
> >
> > "Housley, Russ" wrote:
> > >
> > > Dave:
> > >
> > > I am sorry that I replied to this thread at all.  This topic has
> been debated
> > > before, and the text in Son-of-RFC 2459 is the result of that
> debate.
> > > Obviously, everyone can live with that text because no objections
> were raised
> > > during WG Last Call or IETF Last Call.
> > >
> > > I am not surprised that there is not 100% agreement....
> > >
> > > Russ
>






Received: by above.proper.com (8.11.6/8.11.3) id g439Vko22481 for ietf-pkix-bks; Fri, 3 May 2002 02:31:46 -0700 (PDT)
Received: from edelweb.fr (edelweb.fr [212.234.46.16]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g439Vha22477 for <[e-mail]>; Fri, 3 May 2002 02:31:44 -0700 (PDT)
Received: from champagne.edelweb.fr (localhost.edelweb.fr [127.0.0.1]) by edelweb.fr with ESMTP id LAA22095; Fri, 3 May 2002 11:31:39 +0200 (MET DST)
Received: from champagne.edelweb.fr (champagne.edelweb.fr [193.51.14.161]) by edelweb.fr (nospam/1.4); Fri, 3 May 2002 11:31: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 LAA04007; Fri, 3 May 2002 11:31:38 +0200 (MET DST)
From: Peter Sylvester <[e-mail]>
Received: (sylvest@localhost) by emeriau.edelweb.fr (8.7.6/8.6.6) id LAA15232; Fri, 3 May 2002 11:31:37 +0200 (MET DST)
Date: Fri, 3 May 2002 11:31:37 +0200 (MET DST)
Message-Id: <[e-mail]>
To: [e-mail], [e-mail]
Subject: Re: Open issue: requester identifier in DPV response
Cc: [e-mail]
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

> >
> >What does mean 'SHOULD be able'?  We are talking about requirements for
> >a protocol. Either the protocol has a feature that can be optionally be
> >used or it hasn't.
> 
> It means that a protocol that conforms to these requirements SHOULD include 
> this feature.  It still conforms if it does not include this feature.  In 
> other words, I do not think that a protocol that does not include this 
> feature is unsuitable.

So we are here at a point of discussing whether we can afford to create
a protocol feature which essentially allows a client to specify a data
element of the complexity of let's say GeneralNames in its request,
and to have a server to just copy it to the response, to ignore this,
or to create its own one, all this optionally based on a policy.

I would agree with you that a protocol SHOULD implement optional features,
so that in some really 'small' environments one can still have a conformant
implementation. 

What are some possible sitiuations: The 'small' environment is probably
the 'client' side. Thus: A client may not send identifiers to the server.
That's not a problem for the server. 

It may happen that by some policy, a server always returns the identification 
of the client (derived by some means) and his own. 
if the client does not understand the response, one may consider this
as a configuration error in the server. 
 
> >Why should even an anonymous requester not be allowed to specify an 
> >identifier?
> >As indicated in the followng sentence, a server can always refuse this
> >nased on the policy etc.
> >
> >   How this identifier is matched with the authenticated identity depends
> >   on local server conditions and/or the validation policy. The server
> >   MAY choose to refuse to include an identifier in the response, or MAY
> >   refuse to create a response."
> 
> Doesn't the nonce fulfill this need?
The purpose of requester and server identifiers is to identify 
the requesters and the responders matched in some way against 
the data that are part of the authentication method. Also, after
receiving the response, you can throw away all authentication
data because they do not contain necessary information concerning
the statement made by the server. 

As far as I understand, nonce are only there to provide some
mechanism for replay protection in particular contexts. Overloading
nonces by puting some more or less defined meaning to the content
doesn't seem to me a desirable approach. 

Peter
 


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g438r0x13912 for ietf-pkix-bks; Fri, 3 May 2002 01:53:00 -0700 (PDT)
Received: from mailbu.belbone.be (mailbu.belbone.be [195.13.2.31]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g438qxa13908 for <[e-mail]>; Fri, 3 May 2002 01:52:59 -0700 (PDT)
Received: from ETRUST001 (195.13.18.125) by mailbu.belbone.be; 3 May 2002 10:52:58 +0200
From: "Omer Hasret" <[e-mail]>
To: "'Trevor Freeman'" <[e-mail]>, "'Santosh Chokhani'" <[e-mail]>
Cc: <[e-mail]>
Subject: RE: Meaning of Non-repudiation
Date: Fri, 3 May 2002 10:52:58 +0200
Message-ID: <003801c1f27f$ec4e3000$0900a8c0@ETRUST001>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.2627
In-Reply-To: <[e-mail]>
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
Importance: Normal
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Trevor, Santosh,

It is certain that everybody will need some means of proving that he is
the originator of a specific message, document, whatever. And when we
talk about the NR bit on a certificate, I believe the only thing this
proves is that a specific data is signed by the holder of this
certificate. This never means that the signer agrees with the content or
not. Therefore there is no need to load other meanings to this one bit
changing from policy to policy. Just standardize its use only for
authentication and let others who want to implement their own NR systems
do it by other means. (Some ways to do this have been posted on the list
a day or two days ago.) And I really do not think this as a "dictation"
because you don't have to use that bit just because its name is NR.

> 
> 
> 
> Hi Santosh,
> That still sounds like a policy decision. 
> A signature over an SSL challenge is potentially just as 
> valid a piece of a NR jigsaw puzzle as any other signature. 
> Why are we dictating what someone wants as a NR process? If 
> you want to build a system where NR signatures only occur 
> over documents - fine by me, but don't dictate how I build my 
> NR system. Trevor
> 
> -----Original Message-----
> From: Santosh Chokhani [mailto:[e-mail]] 
> Sent: Thursday, May 02, 2002 2:03 PM
> To: Trevor Freeman; 'Denis Pinkas'; 'David P. Kemp'
> Cc: [e-mail]
> Subject: RE: Meaning of Non-repudiation
> 
> Trevor:
> 
> I also made a resolution long time back when ABA started a 
> debate on this.  But, I also broke it.
> 
> I do think that there is a value in SSL case to say that I am 
> not owning up to signature (as attesting to something) except 
> I signed a challenge. Thus, subscriber (possessor of the 
> private key) should be able to use a separate key so that he 
> can claim he simply signed a random challenge.
> 
> -----Original Message-----
> From: [e-mail] 
> [mailto:[e-mail]]
> On Behalf Of Trevor Freeman
> Sent: Thursday, May 02, 2002 2:53 PM
> To: Denis Pinkas; David P. Kemp
> Cc: [e-mail]
> Subject: RE: Meaning of Non-repudiation
> 
> 
> 
> I am breaking one of my New Year resolutions by mailing on 
> this topic, but here goes...
> 
> Signing anything is always a challenge to prove position of a 
> private key to authenticate whether it's in the context of a 
> protocol like SSL or over a SMIME message. Technically all we 
> can say is the signature occurred. The intent behind why the 
> signature occurred is beyond the scope of this discussion. 
> Use of certificates with the NR bit asserted is ultimately a 
> matter of local policy on what constitutes usage as part of a 
> non-repudiation service since two organisations could have 
> two separate non repudiation serves where one requires a NR 
> signature as part of an SSL session, and the other only wants 
> NR signatures over SMIME messages.
> 
> Never in the course of IETF has history so much been written 
> over something so small.
> 
> Trevor
> 
> -----Original Message-----
> From: Denis Pinkas [mailto:[e-mail]] 
> Sent: Thursday, May 02, 2002 2:27 AM
> To: David P. Kemp
> Cc: [e-mail]
> Subject: Re: Meaning of Non-repudiation
> 
> 
> Dave,
>  
> > Russ,
> > 
> > I believe we are all sorry to resurrect this topic.
> > But it is currently the subject of an X.509 defect,
> 
> Not exactly. Someone would like this topic to be the subject 
> of an X.509 defect report, but this is is currently *not* the 
> subject of an X.509 defect that has been officially raised.
> 
> > and if the text of X.509 eventually changes in a way
> > that is incompatible with Son-of-2459, then
> > Grandson-of-2459 will need to take that into
> > consideration.
> 
> Very unlikely to happen.
> 
> Additional *explanations* without changing the meaning 
> *could* be provided and we are (nearly) all saying the same 
> thing using different words. Santosh in a subsequent e-mail 
> provided one of these
> explanations:
> 
> "In my analysis, DS means you are signing some challenge to 
> prove possession of a private key and thus authenticate 
> yourself whereas with NR you are saying that I know what this 
> data is and I am signing it." 
> 
> I would add that a certificate with the the DS bit set can 
> also be used to authenticate data (this does not mean that 
> the signer has read the data).
> 
> Now, there are cases where, beyond the fact that the signer 
> did know what he signed, he wants to say exactly what its 
> signature means.
> 
> This can be achieved using three ways:
> 
> 1) the document that is signed is unambiguous and its 
> semantics says that the signature means XXX.
> 
> 2) a signed attribute (using the CMS language) is signed in 
> addition to the document and indicates a signature policy 
> that is explicit about the meaning of all signatures 
> performed under that policy (note that one single meaning is 
> possible in that case).
> 
> 3) another signed attribute (using the CMS language) is 
> signed in addition to the document and the previous 
> attribute. It indicates the type of commitment being made 
> under the signature policy for that signature 
> (note that multiple meanings are possible in that case).
> 
> As a result, the variety of meanings is NOT placed in the 
> Certificate Policy from the CA.
> 
> > We can all live with the text because we have no consensus 
> on anything 
> > better.
> 
> Fine.
> 
> Denis
> 
> > That doesn't rule out the faint hope that the ITU can develop a
> > meaningful replacement in the future.
> > 
> > Dave
> > 
> > "Housley, Russ" wrote:
> > >
> > > Dave:
> > >
> > > I am sorry that I replied to this thread at all.  This topic has
> been debated
> > > before, and the text in Son-of-RFC 2459 is the result of that
> debate.
> > > Obviously, everyone can live with that text because no objections
> were raised
> > > during WG Last Call or IETF Last Call.
> > >
> > > I am not surprised that there is not 100% agreement....
> > >
> > > Russ
> 



Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g438j5m13243 for ietf-pkix-bks; Fri, 3 May 2002 01:45:05 -0700 (PDT)
Received: from vulcan.rsasecurity.com (vulcan.rsasecurity.com [204.167.114.130]) by above.proper.com (8.11.6/8.11.3) with SMTP id g438j3a13236 for <[e-mail]>; Fri, 3 May 2002 01:45:03 -0700 (PDT)
Received: from sdtihq24.securitydynamics.com by vulcan.rsasecurity.com via smtpd (for mail.imc.org [208.184.76.43]) with SMTP; 3 May 2002 08:43:35 UT
Received: from ebola.securitydynamics.com (ebola.securid.com [192.80.211.4]) by sdtihq24.securid.com (Pro-8.9.3/Pro-8.9.3) with ESMTP id EAA09066 for <[e-mail]>; Fri, 3 May 2002 04:43:18 -0400 (EDT)
Received: from spirit.dynas.se (localhost [127.0.0.1]) by ebola.securitydynamics.com (8.10.2+Sun/8.9.1) with SMTP id g438j6910070 for <[e-mail]>; Fri, 3 May 2002 04:45:06 -0400 (EDT)
Received: (qmail 8872 invoked from network); 3 May 2002 08:44:59 -0000
Received: from sjosefsson-pc.se.eu.rsa.net (HELO sjosefsson-pc.se.eu.rsa.net.rsasecurity.com) (172.16.13.104) by spirit.se.eu.rsa.net with SMTP; 3 May 2002 08:44:59 -0000
To: [e-mail] (Peter Gutmann)
Cc: [e-mail]
Subject: Re: I-D ACTION:draft-ietf-pkix-logotypes-02.txt
References: <[e-mail]>
From: Simon Josefsson <[e-mail]>
Date: Fri, 03 May 2002 10:44:52 +0200
In-Reply-To: <[e-mail]> ([e-mail]'s message of "Fri, 03 May 2002 07:58:10 GMT")
Message-ID: <[e-mail]>
Lines: 32
User-Agent: Gnus/5.090006 (Oort Gnus v0.06) Emacs/21.2 (i686-pc-linux-gnu)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

[e-mail] (Peter Gutmann) writes:

> Simon Josefsson <[e-mail]> writes:
>
>>Has the SVG format [1] been considered?  It seems to me that it has some
>>advantages:
>
> Looks like yet another future orphaned graphics format (c.f. "future ex-wife").
> If you really want scalable vector graphics, a better (in the sense of "less
> suboptimal") choice would be EPS, although no vector graphics format is
> terribly practical for display purposes because of the lack of support.
> Probably the most viable (ie least suboptimal) vector format is WMF because
> about 95% of desktop platforms support it by default (actually somewhat more
> than that with libwmf, which will display them under X).
>
> Why not just use the usual { type, value } combination, with selected OIDs for
> common formats?  I can see Shockwave and the usual other stuff used in web
> pages being added fairly quickly if this does take off.  A problem with
> standardising things in this area is that most of the widely-used formats are
> proprietary (SWF, WMF, etc), so you either need to standardise proprietary
> formats or go with open formats which no-one actually uses.

I agree with your last suggestion, altough perhaps re-using MIME types
instead of specifying new OIDs requires less work?  My thought was
only that if SVG happens (which isn't unlikely, I think there are free
implementations around) it looks as something that would be
appropriate to use for logotypes.  Hence it might be useful if the
PKIX logotype proposal supported more than two formats, especially
since one of them (GIF) requires license fees when creating images.

EPS requires a postscript interpreter from what I understand, which
seems a bit dangerous to me.


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g438adW12089 for ietf-pkix-bks; Fri, 3 May 2002 01:36:39 -0700 (PDT)
Received: from exafix.addtrust.com ([212.112.175.83]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g438aba12080 for <[e-mail]>; Fri, 3 May 2002 01:36:37 -0700 (PDT)
Received: from stsIBMT20.addtrust.com ([192.168.101.127]) by exafix.addtrust.com with Microsoft SMTPSVC(5.0.2195.2966); Fri, 3 May 2002 10:36:27 +0200
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Version 5.1
Date: Fri, 03 May 2002 10:36:27 +0200
To: "Trevor Freeman" <[e-mail]>, "Santosh Chokhani" <[e-mail]>, "Denis Pinkas" <[e-mail]>, "David P. Kemp" <[e-mail]>
From: Stefan Santesson <[e-mail]>
Subject: RE: Meaning of Non-repudiation
Cc: <[e-mail]>
In-Reply-To: <[e-mail] up.windeploy.ntdev.microsoft.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
X-OriginalArrivalTime: 03 May 2002 08:36:27.0675 (UTC) FILETIME=[9DE1F6B0:01C1F27D]
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Well put Trevor,

I fully agree with this observation.

/Stefan

At 14:09 2002-05-02 -0700, Trevor Freeman wrote:

>Hi Santosh,
>That still sounds like a policy decision.
>A signature over an SSL challenge is potentially just as valid a piece
>of a NR jigsaw puzzle as any other signature. Why are we dictating what
>someone wants as a NR process? If you want to build a system where NR
>signatures only occur over documents - fine by me, but don't dictate how
>I build my NR system.
>Trevor
>
>-----Original Message-----
>From: Santosh Chokhani [mailto:[e-mail]]
>Sent: Thursday, May 02, 2002 2:03 PM
>To: Trevor Freeman; 'Denis Pinkas'; 'David P. Kemp'
>Cc: [e-mail]
>Subject: RE: Meaning of Non-repudiation
>
>Trevor:
>
>I also made a resolution long time back when ABA started a debate on
>this.  But, I also broke it.
>
>I do think that there is a value in SSL case to say that I am not owning
>up to signature (as attesting to something) except I signed a challenge.
>Thus, subscriber (possessor of the private key) should be able to use a
>separate key so that he can claim he simply signed a random challenge.
>
>-----Original Message-----
>From: [e-mail] [mailto:[e-mail]]
>On Behalf Of Trevor Freeman
>Sent: Thursday, May 02, 2002 2:53 PM
>To: Denis Pinkas; David P. Kemp
>Cc: [e-mail]
>Subject: RE: Meaning of Non-repudiation
>
>
>
>I am breaking one of my New Year resolutions by mailing on this topic,
>but here goes...
>
>Signing anything is always a challenge to prove position of a private
>key to authenticate whether it's in the context of a protocol like SSL
>or over a SMIME message. Technically all we can say is the signature
>occurred. The intent behind why the signature occurred is beyond the
>scope of this discussion. Use of certificates with the NR bit asserted
>is ultimately a matter of local policy on what constitutes usage as part
>of a non-repudiation service since two organisations could have two
>separate non repudiation serves where one requires a NR signature as
>part of an SSL session, and the other only wants NR signatures over
>SMIME messages.
>
>Never in the course of IETF has history so much been written over
>something so small.
>
>Trevor
>
>-----Original Message-----
>From: Denis Pinkas [mailto:[e-mail]]
>Sent: Thursday, May 02, 2002 2:27 AM
>To: David P. Kemp
>Cc: [e-mail]
>Subject: Re: Meaning of Non-repudiation
>
>
>Dave,
>
> > Russ,
> >
> > I believe we are all sorry to resurrect this topic.
> > But it is currently the subject of an X.509 defect,
>
>Not exactly. Someone would like this topic to be the subject of an X.509
>defect report, but this is is currently *not* the subject of an X.509
>defect that has been officially raised.
>
> > and if the text of X.509 eventually changes in a way
> > that is incompatible with Son-of-2459, then
> > Grandson-of-2459 will need to take that into
> > consideration.
>
>Very unlikely to happen.
>
>Additional *explanations* without changing the meaning *could* be
>provided and we are (nearly) all saying the same thing using different
>words. Santosh in a subsequent e-mail provided one of these
>explanations:
>
>"In my analysis, DS means you are signing some challenge to prove
>possession of a private key and thus authenticate yourself whereas with
>NR you are saying that I know what this data is and I am signing it."
>
>I would add that a certificate with the the DS bit set can also be used
>to authenticate data (this does not mean that the signer has read the
>data).
>
>Now, there are cases where, beyond the fact that the signer did know
>what he signed, he wants to say exactly what its signature means.
>
>This can be achieved using three ways:
>
>1) the document that is signed is unambiguous and its semantics says
>that the signature means XXX.
>
>2) a signed attribute (using the CMS language) is signed in addition to
>the document and indicates a signature policy that is explicit about the
>meaning of all signatures performed under that policy (note that one
>single meaning is possible in that case).
>
>3) another signed attribute (using the CMS language) is signed in
>addition to the document and the previous attribute. It indicates the
>type of commitment being made under the signature policy for that
>signature
>(note that multiple meanings are possible in that case).
>
>As a result, the variety of meanings is NOT placed in the Certificate
>Policy from the CA.
>
> > We can all live with the text because we have no consensus on
> > anything better.
>
>Fine.
>
>Denis
>
> > That doesn't rule out the faint hope that the ITU can develop a
> > meaningful replacement in the future.
> >
> > Dave
> >
> > "Housley, Russ" wrote:
> > >
> > > Dave:
> > >
> > > I am sorry that I replied to this thread at all.  This topic has
>been debated
> > > before, and the text in Son-of-RFC 2459 is the result of that
>debate.
> > > Obviously, everyone can live with that text because no objections
>were raised
> > > during WG Last Call or IETF Last Call.
> > >
> > > I am not surprised that there is not 100% agreement....
> > >
> > > Russ



Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g437x0h09834 for ietf-pkix-bks; Fri, 3 May 2002 00:59:00 -0700 (PDT)
Received: from hermes.cs.auckland.ac.nz (hermes.cs.auckland.ac.nz [130.216.35.151]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g437wta09814 for <[e-mail]>; Fri, 3 May 2002 00:58:55 -0700 (PDT)
Received: from ruru.cs.auckland.ac.nz (ruru-nfs.cs.auckland.ac.nz [130.216.35.12]) by hermes.cs.auckland.ac.nz (8.12.2/8.12.2) with ESMTP id g437wAK4001832; Fri, 3 May 2002 19:58:10 +1200
Received: (from pgut001@localhost) by ruru.cs.auckland.ac.nz (8.9.3/8.8.6/cs-slave) id TAA72325; Fri, 3 May 2002 19:58:10 +1200 (NZST) (sender [e-mail])
Date: Fri, 3 May 2002 19:58:10 +1200 (NZST)
Message-ID: <[e-mail]>
From: [e-mail] (Peter Gutmann)
To: [e-mail], [e-mail]
Subject: Re: I-D ACTION:draft-ietf-pkix-logotypes-02.txt
Cc: [e-mail]
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Simon Josefsson <[e-mail]> writes:

>Has the SVG format [1] been considered?  It seems to me that it has some
>advantages:

Looks like yet another future orphaned graphics format (c.f. "future ex-wife").
If you really want scalable vector graphics, a better (in the sense of "less
suboptimal") choice would be EPS, although no vector graphics format is
terribly practical for display purposes because of the lack of support.
Probably the most viable (ie least suboptimal) vector format is WMF because
about 95% of desktop platforms support it by default (actually somewhat more
than that with libwmf, which will display them under X).

Why not just use the usual { type, value } combination, with selected OIDs for
common formats?  I can see Shockwave and the usual other stuff used in web
pages being added fairly quickly if this does take off.  A problem with
standardising things in this area is that most of the widely-used formats are
proprietary (SWF, WMF, etc), so you either need to standardise proprietary
formats or go with open formats which no-one actually uses.

Peter.



Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g437jft07210 for ietf-pkix-bks; Fri, 3 May 2002 00:45:41 -0700 (PDT)
Received: from hermes.cs.auckland.ac.nz (hermes.cs.auckland.ac.nz [130.216.35.151]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g437jba07206 for <[e-mail]>; Fri, 3 May 2002 00:45:38 -0700 (PDT)
Received: from ruru.cs.auckland.ac.nz (ruru-nfs.cs.auckland.ac.nz [130.216.35.12]) by hermes.cs.auckland.ac.nz (8.12.2/8.12.2) with ESMTP id g437ipK4001656; Fri, 3 May 2002 19:44:51 +1200
Received: (from pgut001@localhost) by ruru.cs.auckland.ac.nz (8.9.3/8.8.6/cs-slave) id TAA72160; Fri, 3 May 2002 19:44:44 +1200 (NZST) (sender [e-mail])
Date: Fri, 3 May 2002 19:44:44 +1200 (NZST)
Message-ID: <[e-mail]>
From: [e-mail] (Peter Gutmann)
To: [e-mail], [e-mail], [e-mail]
Subject: RE: I-D ACTION:draft-ietf-pkix-logotypes-02.txt
Cc: [e-mail], [e-mail]
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Stefan Santesson <[e-mail]> writes:

>Was 300x200 a serious suggestion or a joke?

It's roughly the size of typical digitised TV video images (usually closer to
320x240, depending on the source and equipment used), thus it'd make a useful
lower limit, unless you prefer QuickTime animated postage stamps.  However, the
suggestion as a whole was a joke.

Peter.


Received: by above.proper.com (8.11.6/8.11.3) id g42Ns1t12109 for ietf-pkix-bks; Thu, 2 May 2002 16:54:01 -0700 (PDT)
Received: from smtp-1.llnl.gov (smtp-1.llnl.gov [128.115.250.81]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g42Ns0a12104 for <[e-mail]>; Thu, 2 May 2002 16:54:00 -0700 (PDT)
Received: from poptop.llnl.gov (localhost [127.0.0.1]) by smtp-1.llnl.gov (8.9.3/8.9.3/LLNL-gateway-1.0) with ESMTP id QAA16823; Thu, 2 May 2002 16:53:58 -0700 (PDT)
Received: from catalyst.llnl.gov (catalyst.llnl.gov [128.115.222.68]) by poptop.llnl.gov (8.8.8/LLNL-3.0.2/pop.llnl.gov-5.1) with ESMTP id QAA09639; Thu, 2 May 2002 16:53:58 -0700 (PDT)
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Version 4.3.2
Date: Thu, 02 May 2002 17:06:13 -0800
To: "Omer Hasret" <[e-mail]>, "'Santosh Chokhani'" <[e-mail]>
From: Tony Bartoletti <[e-mail]>
Subject: RE: Meaning of Non-repudiation
Cc: <[e-mail]>
In-Reply-To: <003501c1f1b5$d177aba0$0900a8c0@ETRUST001>
References: <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

At 10:46 AM 5/2/02 +0200, Omer Hasret wrote:

>Even if it is like Santosh says for the signing and the relying party,
>my opinion is that it is not enough. I also think that the meaning of
>these concepts should be the same for all parties including the software
>developer.

I agree.  And if we allow this bit to represent something "sufficiently 
mechanical" (ala Tom Ginden's "Technical Nonrepudiation") we might someday 
arrive at a "concept" that all can come close to recognizing.

Unfortunately, the customer expects NR=1 to mean, "If you signed something 
with this key, you shall be unable to repudiate ... something" (that you 
signed, and signed willfully, and signed knowingly, etc.)  This is just too 
foggy for all of the interested parties to come to an agreement, except 
over certain specific types of situations (which would make the NR-bit 
useful to certain communities and not so much to others).

Indeed, in some contexts, NR "trumps the facts".  That is, the holder of an 
NR-signed item can act "as if" you signed it, even if it can be otherwise 
proven that you actually did not.  In this context, you have entered into 
an agreement that "you will abide by the outcome, irrespective of intent or 
even of involvement."  This is (loosely) analogous to the $50 you agree to 
forfeit if your credit card is abused, irrespective of who actually used 
it, how it was subverted, etc.

Cheers!

___tony___


Tony Bartoletti 925-422-3881 <[e-mail]>
Information Operations, Warfare and Assurance Center
Lawrence Livermore National Laboratory
Livermore, CA 94551-9900






Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g42MUOb10147 for ietf-pkix-bks; Thu, 2 May 2002 15:30:24 -0700 (PDT)
Received: from smtpout.mac.com (smtpout.mac.com [204.179.120.86]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g42MUNa10142 for <[e-mail]>; Thu, 2 May 2002 15:30:23 -0700 (PDT)
Received: from smtp-relay02.mac.com (smtp-relay02-qfe3 [10.13.10.225]) by smtpout.mac.com (8.12.1/8.10.2/1.0) with ESMTP id g42MUNW5014208 for <[e-mail]>; Thu, 2 May 2002 15:30:26 -0700 (PDT)
Received: from asmtp02.mac.com ([10.13.10.66]) by smtp-relay02.mac.com (Netscape Messaging Server 4.15 relay02 Jun 21 2001 23:53:48) with ESMTP id GVI96I00.65G for <[e-mail]>; Thu, 2 May 2002 15:30:18 -0700 
Received: from localhost ([63.84.37.127]) by asmtp02.mac.com (Netscape Messaging Server 4.15 asmtp02 Jun 21 2001 23:53:48) with ESMTP id GVI96G00.35J for <[e-mail]>; Thu, 2 May 2002 15:30:16 -0700 
Date: Thu, 2 May 2002 15:30:41 -0700
Subject: Re: Meaning of Non-repudiation
Content-Type: text/plain; charset=US-ASCII; format=flowed
Mime-Version: 1.0 (Apple Message framework v481)
From: Aram Perez <[e-mail]>
To: PKIX <[e-mail]>
Content-Transfer-Encoding: 7bit
In-Reply-To: <[e-mail]>
Message-Id: <[e-mail]>
X-Mailer: Apple Mail (2.481)
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Hi Trevor,

I too am breaking my vow of silence on the NR bit. You are absolutely 
correct. I/you should be able to design a NR System where 
"non-reputable" transactions take place using SSL.

Regards,
Aram Perez


On Thursday, May 2, 2002, at 02:09  PM, Trevor Freeman wrote:

>
> Hi Santosh,
> That still sounds like a policy decision.
> A signature over an SSL challenge is potentially just as valid a piece
> of a NR jigsaw puzzle as any other signature. Why are we dictating what
> someone wants as a NR process? If you want to build a system where NR
> signatures only occur over documents - fine by me, but don't dictate how
> I build my NR system.
> Trevor
>
> -----Original Message-----
> From: Santosh Chokhani [mailto:[e-mail]]
> Sent: Thursday, May 02, 2002 2:03 PM
> To: Trevor Freeman; 'Denis Pinkas'; 'David P. Kemp'
> Cc: [e-mail]
> Subject: RE: Meaning of Non-repudiation
>
> Trevor:
>
> I also made a resolution long time back when ABA started a debate on
> this.  But, I also broke it.
>
> I do think that there is a value in SSL case to say that I am not owning
> up to signature (as attesting to something) except I signed a challenge.
> Thus, subscriber (possessor of the private key) should be able to use a
> separate key so that he can claim he simply signed a random challenge.
>
> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]]
> On Behalf Of Trevor Freeman
> Sent: Thursday, May 02, 2002 2:53 PM
> To: Denis Pinkas; David P. Kemp
> Cc: [e-mail]
> Subject: RE: Meaning of Non-repudiation
>
>
>
> I am breaking one of my New Year resolutions by mailing on this topic,
> but here goes...
>
> Signing anything is always a challenge to prove position of a private
> key to authenticate whether it's in the context of a protocol like SSL
> or over a SMIME message. Technically all we can say is the signature
> occurred. The intent behind why the signature occurred is beyond the
> scope of this discussion. Use of certificates with the NR bit asserted
> is ultimately a matter of local policy on what constitutes usage as part
> of a non-repudiation service since two organisations could have two
> separate non repudiation serves where one requires a NR signature as
> part of an SSL session, and the other only wants NR signatures over
> SMIME messages.
>
> Never in the course of IETF has history so much been written over
> something so small.
>
> Trevor
>
> -----Original Message-----
> From: Denis Pinkas [mailto:[e-mail]]
> Sent: Thursday, May 02, 2002 2:27 AM
> To: David P. Kemp
> Cc: [e-mail]
> Subject: Re: Meaning of Non-repudiation
>
>
> Dave,
>
>> Russ,
>>
>> I believe we are all sorry to resurrect this topic.
>> But it is currently the subject of an X.509 defect,
>
> Not exactly. Someone would like this topic to be the subject of an X.509
> defect report, but this is is currently *not* the subject of an X.509
> defect that has been officially raised.
>
>> and if the text of X.509 eventually changes in a way
>> that is incompatible with Son-of-2459, then
>> Grandson-of-2459 will need to take that into
>> consideration.
>
> Very unlikely to happen.
>
> Additional *explanations* without changing the meaning *could* be
> provided and we are (nearly) all saying the same thing using different
> words. Santosh in a subsequent e-mail provided one of these
> explanations:
>
> "In my analysis, DS means you are signing some challenge to prove
> possession of a private key and thus authenticate yourself whereas with
> NR you are saying that I know what this data is and I am signing it."
>
> I would add that a certificate with the the DS bit set can also be used
> to authenticate data (this does not mean that the signer has read the
> data).
>
> Now, there are cases where, beyond the fact that the signer did know
> what he signed, he wants to say exactly what its signature means.
>
> This can be achieved using three ways:
>
> 1) the document that is signed is unambiguous and its semantics says
> that the signature means XXX.
>
> 2) a signed attribute (using the CMS language) is signed in addition to
> the document and indicates a signature policy that is explicit about the
> meaning of all signatures performed under that policy (note that one
> single meaning is possible in that case).
>
> 3) another signed attribute (using the CMS language) is signed in
> addition to the document and the previous attribute. It indicates the
> type of commitment being made under the signature policy for that
> signature
> (note that multiple meanings are possible in that case).
>
> As a result, the variety of meanings is NOT placed in the Certificate
> Policy from the CA.
>
>> We can all live with the text because we have no consensus on
>> anything better.
>
> Fine.
>
> Denis
>
>> That doesn't rule out the faint hope that the ITU can develop a
>> meaningful replacement in the future.
>>
>> Dave
>>
>> "Housley, Russ" wrote:
>>>
>>> Dave:
>>>
>>> I am sorry that I replied to this thread at all.  This topic has
> been debated
>>> before, and the text in Son-of-RFC 2459 is the result of that
> debate.
>>> Obviously, everyone can live with that text because no objections
> were raised
>>> during WG Last Call or IETF Last Call.
>>>
>>> I am not surprised that there is not 100% agreement....
>>>
>>> Russ
>



Received: by above.proper.com (8.11.6/8.11.3) id g42LegP09206 for ietf-pkix-bks; Thu, 2 May 2002 14:40:42 -0700 (PDT)
Received: from smtp-2.llnl.gov (smtp-2.llnl.gov [128.115.250.82]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g42Lega09202 for <[e-mail]>; Thu, 2 May 2002 14:40:42 -0700 (PDT)
Received: from poptop.llnl.gov (localhost [127.0.0.1]) by smtp-2.llnl.gov (8.9.3/8.9.3/LLNL-gateway-1.0) with ESMTP id OAA04456; Thu, 2 May 2002 14:40:28 -0700 (PDT)
Received: from catalyst.llnl.gov (catalyst.llnl.gov [128.115.222.68]) by poptop.llnl.gov (8.8.8/LLNL-3.0.2/pop.llnl.gov-5.1) with ESMTP id OAA19253; Thu, 2 May 2002 14:40:39 -0700 (PDT)
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Version 4.3.2
Date: Thu, 02 May 2002 14:52:54 -0800
To: "Trevor Freeman" <[e-mail]>, "Santosh Chokhani" <[e-mail]>, "Denis Pinkas" <[e-mail]>, "David P. Kemp" <[e-mail]>
From: Tony Bartoletti <[e-mail]>
Subject: RE: Meaning of Non-repudiation
Cc: <[e-mail]>
In-Reply-To: <[e-mail] up.windeploy.ntdev.microsoft.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

At 02:09 PM 5/2/02 -0700, Trevor Freeman wrote:

>A signature over an SSL challenge is potentially just as valid a piece
>of a NR jigsaw puzzle as any other signature. Why are we dictating what
>someone wants as a NR process? If you want to build a system where NR
>signatures only occur over documents - fine by me, but don't dictate how
>I build my NR system.
>Trevor

I think that sums up the situation very well (fortunately or not ;)

____tony____

Tony Bartoletti 925-422-3881 <[e-mail]>
Information Operations, Warfare and Assurance Center
Lawrence Livermore National Laboratory
Livermore, CA 94551-9900






Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g42LDwW08510 for ietf-pkix-bks; Thu, 2 May 2002 14:13:58 -0700 (PDT)
Received: from mail2.microsoft.com (mail2.microsoft.com [131.107.3.124]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g42LDua08506 for <[e-mail]>; Thu, 2 May 2002 14:13:56 -0700 (PDT)
Received: from INET-VRS-02.redmond.corp.microsoft.com ([157.54.8.110]) by mail2.microsoft.com with Microsoft SMTPSVC(5.0.2195.4905); Thu, 2 May 2002 14:13:54 -0700
Received: from 157.54.8.109 by INET-VRS-02.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Thu, 02 May 2002 14:13:54 -0700
Received: from red-imc-02.redmond.corp.microsoft.com ([157.54.9.107]) by inet-hub-02.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.4905); Thu, 2 May 2002 14:13:54 -0700
Received: from win-imc-02.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.84]) by red-imc-02.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.4905); Thu, 2 May 2002 14:13:50 -0700
Received: from win-msg-01.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.52]) by win-imc-02.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3590.0); Thu, 2 May 2002 14:10:11 -0700
X-MimeOLE: Produced By Microsoft Exchange V6.0.6177.0
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Subject: RE: Meaning of Non-repudiation
Date: Thu, 2 May 2002 14:09:59 -0700
Message-ID: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: Meaning of Non-repudiation
Thread-Index: AcHyHC118CDM1nHYQxefxydMabPtRAAAKElA
From: "Trevor Freeman" <[e-mail]>
To: "Santosh Chokhani" <[e-mail]>, "Denis Pinkas" <[e-mail]>, "David P. Kemp" <[e-mail]>
Cc: <[e-mail]>
X-OriginalArrivalTime: 02 May 2002 21:10:11.0062 (UTC) FILETIME=[BEB57160:01C1F21D]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id g42LDva08507
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Hi Santosh,
That still sounds like a policy decision. 
A signature over an SSL challenge is potentially just as valid a piece
of a NR jigsaw puzzle as any other signature. Why are we dictating what
someone wants as a NR process? If you want to build a system where NR
signatures only occur over documents - fine by me, but don't dictate how
I build my NR system.
Trevor

-----Original Message-----
From: Santosh Chokhani [mailto:[e-mail]] 
Sent: Thursday, May 02, 2002 2:03 PM
To: Trevor Freeman; 'Denis Pinkas'; 'David P. Kemp'
Cc: [e-mail]
Subject: RE: Meaning of Non-repudiation

Trevor:

I also made a resolution long time back when ABA started a debate on
this.  But, I also broke it.

I do think that there is a value in SSL case to say that I am not owning
up to signature (as attesting to something) except I signed a challenge.
Thus, subscriber (possessor of the private key) should be able to use a
separate key so that he can claim he simply signed a random challenge.

-----Original Message-----
From: [e-mail] [mailto:[e-mail]]
On Behalf Of Trevor Freeman
Sent: Thursday, May 02, 2002 2:53 PM
To: Denis Pinkas; David P. Kemp
Cc: [e-mail]
Subject: RE: Meaning of Non-repudiation



I am breaking one of my New Year resolutions by mailing on this topic,
but here goes...

Signing anything is always a challenge to prove position of a private
key to authenticate whether it's in the context of a protocol like SSL
or over a SMIME message. Technically all we can say is the signature
occurred. The intent behind why the signature occurred is beyond the
scope of this discussion. Use of certificates with the NR bit asserted
is ultimately a matter of local policy on what constitutes usage as part
of a non-repudiation service since two organisations could have two
separate non repudiation serves where one requires a NR signature as
part of an SSL session, and the other only wants NR signatures over
SMIME messages.

Never in the course of IETF has history so much been written over
something so small.

Trevor

-----Original Message-----
From: Denis Pinkas [mailto:[e-mail]] 
Sent: Thursday, May 02, 2002 2:27 AM
To: David P. Kemp
Cc: [e-mail]
Subject: Re: Meaning of Non-repudiation


Dave,
 
> Russ,
> 
> I believe we are all sorry to resurrect this topic.
> But it is currently the subject of an X.509 defect,

Not exactly. Someone would like this topic to be the subject of an X.509
defect report, but this is is currently *not* the subject of an X.509
defect that has been officially raised.

> and if the text of X.509 eventually changes in a way
> that is incompatible with Son-of-2459, then
> Grandson-of-2459 will need to take that into
> consideration.

Very unlikely to happen.

Additional *explanations* without changing the meaning *could* be
provided and we are (nearly) all saying the same thing using different
words. Santosh in a subsequent e-mail provided one of these
explanations:

"In my analysis, DS means you are signing some challenge to prove
possession of a private key and thus authenticate yourself whereas with
NR you are saying that I know what this data is and I am signing it." 

I would add that a certificate with the the DS bit set can also be used
to authenticate data (this does not mean that the signer has read the
data).

Now, there are cases where, beyond the fact that the signer did know
what he signed, he wants to say exactly what its signature means.

This can be achieved using three ways:

1) the document that is signed is unambiguous and its semantics says
that the signature means XXX.

2) a signed attribute (using the CMS language) is signed in addition to
the document and indicates a signature policy that is explicit about the
meaning of all signatures performed under that policy (note that one
single meaning is possible in that case).

3) another signed attribute (using the CMS language) is signed in
addition to the document and the previous attribute. It indicates the
type of commitment being made under the signature policy for that
signature 
(note that multiple meanings are possible in that case).

As a result, the variety of meanings is NOT placed in the Certificate
Policy from the CA.

> We can all live with the text because we have no consensus on
> anything better.  

Fine.

Denis

> That doesn't rule out the faint hope that the ITU can develop a 
> meaningful replacement in the future.
> 
> Dave
> 
> "Housley, Russ" wrote:
> >
> > Dave:
> >
> > I am sorry that I replied to this thread at all.  This topic has
been debated
> > before, and the text in Son-of-RFC 2459 is the result of that
debate.
> > Obviously, everyone can live with that text because no objections
were raised
> > during WG Last Call or IETF Last Call.
> >
> > I am not surprised that there is not 100% agreement....
> >
> > Russ



Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g42L1Oq08120 for ietf-pkix-bks; Thu, 2 May 2002 14:01:24 -0700 (PDT)
Received: from mtiwmhc23.worldnet.att.net (mtiwmhc23.worldnet.att.net [204.127.131.48]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g42L1Na08116 for <[e-mail]>; Thu, 2 May 2002 14:01:23 -0700 (PDT)
Received: from Chokhani ([12.91.132.4]) by mtiwmhc23.worldnet.att.net (InterMail vM.4.01.03.27 201-229-121-127-20010626) with ESMTP id <20020502210119.UZWM28245.mtiwmhc23.worldnet.att.net@Chokhani>; Thu, 2 May 2002 21:01:19 +0000
From: "Santosh Chokhani" <[e-mail]>
To: "'Trevor Freeman'" <[e-mail]>, "'Denis Pinkas'" <[e-mail]>, "'David P. Kemp'" <[e-mail]>
Cc: <[e-mail]>
Subject: RE: Meaning of Non-repudiation
Date: Thu, 2 May 2002 17:02:51 -0400
Message-ID: <006f01c1f21c$b956bcc0$a300a8c0@Chokhani>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.2627
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4910.0300
In-Reply-To: <[e-mail]>
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Trevor:

I also made a resolution long time back when ABA started a debate on
this.  But, I also broke it.

I do think that there is a value in SSL case to say that I am not owning
up to signature (as attesting to something) except I signed a challenge.
Thus, subscriber (possessor of the private key) should be able to use a
separate key so that he can claim he simply signed a random challenge.

-----Original Message-----
From: [e-mail] [mailto:[e-mail]]
On Behalf Of Trevor Freeman
Sent: Thursday, May 02, 2002 2:53 PM
To: Denis Pinkas; David P. Kemp
Cc: [e-mail]
Subject: RE: Meaning of Non-repudiation



I am breaking one of my New Year resolutions by mailing on this topic,
but here goes...

Signing anything is always a challenge to prove position of a private
key to authenticate whether it's in the context of a protocol like SSL
or over a SMIME message. Technically all we can say is the signature
occurred. The intent behind why the signature occurred is beyond the
scope of this discussion. Use of certificates with the NR bit asserted
is ultimately a matter of local policy on what constitutes usage as part
of a non-repudiation service since two organisations could have two
separate non repudiation serves where one requires a NR signature as
part of an SSL session, and the other only wants NR signatures over
SMIME messages.

Never in the course of IETF has history so much been written over
something so small.

Trevor

-----Original Message-----
From: Denis Pinkas [mailto:[e-mail]] 
Sent: Thursday, May 02, 2002 2:27 AM
To: David P. Kemp
Cc: [e-mail]
Subject: Re: Meaning of Non-repudiation


Dave,
 
> Russ,
> 
> I believe we are all sorry to resurrect this topic.
> But it is currently the subject of an X.509 defect,

Not exactly. Someone would like this topic to be the subject of an X.509
defect report, but this is is currently *not* the subject of an X.509
defect that has been officially raised.

> and if the text of X.509 eventually changes in a way
> that is incompatible with Son-of-2459, then
> Grandson-of-2459 will need to take that into
> consideration.

Very unlikely to happen.

Additional *explanations* without changing the meaning *could* be
provided and we are (nearly) all saying the same thing using different
words. Santosh in a subsequent e-mail provided one of these
explanations:

"In my analysis, DS means you are signing some challenge to prove
possession of a private key and thus authenticate yourself whereas with
NR you are saying that I know what this data is and I am signing it." 

I would add that a certificate with the the DS bit set can also be used
to authenticate data (this does not mean that the signer has read the
data).

Now, there are cases where, beyond the fact that the signer did know
what he signed, he wants to say exactly what its signature means.

This can be achieved using three ways:

1) the document that is signed is unambiguous and its semantics says
that the signature means XXX.

2) a signed attribute (using the CMS language) is signed in addition to
the document and indicates a signature policy that is explicit about the
meaning of all signatures performed under that policy (note that one
single meaning is possible in that case).

3) another signed attribute (using the CMS language) is signed in
addition to the document and the previous attribute. It indicates the
type of commitment being made under the signature policy for that
signature 
(note that multiple meanings are possible in that case).

As a result, the variety of meanings is NOT placed in the Certificate
Policy from the CA.

> We can all live with the text because we have no consensus on
> anything better.  

Fine.

Denis

> That doesn't rule out the faint hope that the ITU can develop a 
> meaningful replacement in the future.
> 
> Dave
> 
> "Housley, Russ" wrote:
> >
> > Dave:
> >
> > I am sorry that I replied to this thread at all.  This topic has
been debated
> > before, and the text in Son-of-RFC 2459 is the result of that
debate.
> > Obviously, everyone can live with that text because no objections
were raised
> > during WG Last Call or IETF Last Call.
> >
> > I am not surprised that there is not 100% agreement....
> >
> > Russ



Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g42KsNf07963 for ietf-pkix-bks; Thu, 2 May 2002 13:54:23 -0700 (PDT)
Received: from nymelsmtp.internet.ny.fdms.firstdata.com ([204.124.248.17]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g42KsMa07959 for <[e-mail]>; Thu, 2 May 2002 13:54:22 -0700 (PDT)
Subject: RE: Meaning of Non-repudiation
To: "Trevor Freeman" <[e-mail]>
Cc: "Denis Pinkas" <[e-mail]>, "David P. Kemp" <[e-mail]>, [e-mail]
X-Mailer: Lotus Notes Release 5.0.5  September 22, 2000
Message-ID: <[e-mail]>
From: [e-mail]
Date: Thu, 2 May 2002 14:53:32 -0600
X-MIMETrack: Serialize by Router on NYMELSMTP/NY/FDMS/FDC(Release 5.0.8 |June 18, 2001) at 05/02/2002 04:51:25 PM
MIME-Version: 1.0
Content-type: text/plain; charset=us-ascii
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

the NR bit in a certificate seems to be almost totally unrelated to whether
a person really intended for a signature to occur. within the chipcard
domain (on the way to showing non-repudiation need to first establish
intention &/or approval) ... there has been two different kinds of ... lets
say personalities;

1) access card personality .... the card powers on, a PIN is entered, and
the card signs an unlimited number of messages ... as an authentication
indication; from 3-factor authentication: two factors, a) something you
have and b) something you know.

2) financial card personality ... the card requires that a PIN be entered
for every signature; this has an implicit "intention" or "approval" in
addition to authentication; the card has the aspect of an access card
personality (two factor authentication) as well as the additional implicit
aspect of "intention" or  "approval" because a human interaction is
required for every signature ... aka the re-entry of the PIN for every
signature implying intention. The finread reader standard goes further ...
in that there needs to be a "secure" card acceptor device with secure
display & secure pin-entry (further increasing the probability that the
specific human was involved in the re-entry of the PIN ... and it was done
specifically in conjunction with a specific transaction being displayed).

Having a "NR" flag in a certificate seems to have little or no bearing on
whether there is an implicit intention of a person that a specific
signature be performed (in the sense of a chipcard with a "financial"
personality that carries with it some action implying approval or
intention).

misc. past "intention" post (aka before getting to non-repudiation ... need
to first establish something like intention &/or approval before there is a
basis for repudiation or non-repudiation).
http://www.garlic.com/~lynn/aadsmore.htm#schneier Schneier: Why Digital
Signatures are not Signatures (was Re :CRYPTO-GRAM, November 15, 2000)
http://www.garlic.com/~lynn/2001g.html#60 PKI/Digital signature doesn't
work
http://www.garlic.com/~lynn/2001g.html#62 PKI/Digital signature doesn't
work
http://www.garlic.com/~lynn/2001j.html#7 No Trusted Viewer possible?

misc. past finread posts:
http://www.garlic.com/~lynn/aadsm9.htm#carnivore Shades of FV's Nathaniel
Borenstein: Carnivore's "Magic Lantern"
http://www.garlic.com/~lynn/aepay7.htm#3dsecure 3D Secure Vulnerabilities?
Photo ID's and Payment Infrastructure
http://www.garlic.com/~lynn/aadsm10.htm#keygen2 Welome to the Internet,
here's your private key
http://www.garlic.com/~lynn/aadsm11.htm#4 AW: Digital signatures as proof
http://www.garlic.com/~lynn/2001g.html#57 Q: Internet banking
http://www.garlic.com/~lynn/2001g.html#60 PKI/Digital signature doesn't
work
http://www.garlic.com/~lynn/2001g.html#61 PKI/Digital signature doesn't
work
http://www.garlic.com/~lynn/2001g.html#62 PKI/Digital signature doesn't
work
http://www.garlic.com/~lynn/2001g.html#64 PKI/Digital signature doesn't
work
http://www.garlic.com/~lynn/2001i.html#25 Net banking, is it safe???
http://www.garlic.com/~lynn/2001i.html#26 No Trusted Viewer possible?
http://www.garlic.com/~lynn/2001k.html#0 Are client certificates really
secure?
http://www.garlic.com/~lynn/2001m.html#6 Smart Card vs. Magnetic Strip
Market
http://www.garlic.com/~lynn/2001m.html#9 Smart Card vs. Magnetic Strip
Market
http://www.garlic.com/~lynn/2002c.html#10 Opinion on smartcard security
requested
http://www.garlic.com/~lynn/2002c.html#21 Opinion on smartcard security
requested
http://www.garlic.com/~lynn/2002f.html#46 Security Issues of using Internet
Banking
http://www.garlic.com/~lynn/2002f.html#55 Security Issues of using Internet
Banking




trevor freeman <[e-mail]> on 5/2/2002 12:52 pm wrote:


I am breaking one of my New Year resolutions by mailing on this topic,
but here goes...

Signing anything is always a challenge to prove position of a private
key to authenticate whether it's in the context of a protocol like SSL
or over a SMIME message. Technically all we can say is the signature
occurred. The intent behind why the signature occurred is beyond the
scope of this discussion. Use of certificates with the NR bit asserted
is ultimately a matter of local policy on what constitutes usage as part
of a non-repudiation service since two organisations could have two
separate non repudiation serves where one requires a NR signature as
part of an SSL session, and the other only wants NR signatures over
SMIME messages.

Never in the course of IETF has history so much been written over
something so small.

Trevor





Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g42Iv1905293 for ietf-pkix-bks; Thu, 2 May 2002 11:57:01 -0700 (PDT)
Received: from mail5.microsoft.com (mail5.microsoft.com [131.107.3.121]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g42Iuxa05288 for <[e-mail]>; Thu, 2 May 2002 11:56:59 -0700 (PDT)
Received: from inet-vrs-05.redmond.corp.microsoft.com ([157.54.6.148]) by mail5.microsoft.com with Microsoft SMTPSVC(5.0.2195.4905); Thu, 2 May 2002 11:56:56 -0700
Received: from 157.54.8.23 by inet-vrs-05.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Thu, 02 May 2002 11:56:56 -0700
Received: from red-imc-01.redmond.corp.microsoft.com ([157.54.9.102]) by inet-hub-01.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.4905); Thu, 2 May 2002 11:56:56 -0700
Received: from win-imc-01.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.39]) by red-imc-01.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.4905); Thu, 2 May 2002 11:56:56 -0700
Received: from win-msg-01.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.52]) by win-imc-01.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3604.0); Thu, 2 May 2002 11:52:51 -0700
X-MimeOLE: Produced By Microsoft Exchange V6.0.6177.0
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Subject: RE: Meaning of Non-repudiation
Date: Thu, 2 May 2002 11:52:50 -0700
Message-ID: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: Meaning of Non-repudiation
Thread-Index: AcHxu7DrJV04BzIRTsOUC5sAptt1rAATSGPQ
From: "Trevor Freeman" <[e-mail]>
To: "Denis Pinkas" <[e-mail]>, "David P. Kemp" <[e-mail]>
Cc: <[e-mail]>
X-OriginalArrivalTime: 02 May 2002 18:52:51.0360 (UTC) FILETIME=[8F76B200:01C1F20A]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id g42Iv0a05289
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

I am breaking one of my New Year resolutions by mailing on this topic,
but here goes...

Signing anything is always a challenge to prove position of a private
key to authenticate whether it's in the context of a protocol like SSL
or over a SMIME message. Technically all we can say is the signature
occurred. The intent behind why the signature occurred is beyond the
scope of this discussion. Use of certificates with the NR bit asserted
is ultimately a matter of local policy on what constitutes usage as part
of a non-repudiation service since two organisations could have two
separate non repudiation serves where one requires a NR signature as
part of an SSL session, and the other only wants NR signatures over
SMIME messages.

Never in the course of IETF has history so much been written over
something so small.

Trevor

-----Original Message-----
From: Denis Pinkas [mailto:[e-mail]] 
Sent: Thursday, May 02, 2002 2:27 AM
To: David P. Kemp
Cc: [e-mail]
Subject: Re: Meaning of Non-repudiation


Dave,
 
> Russ,
> 
> I believe we are all sorry to resurrect this topic.
> But it is currently the subject of an X.509 defect,

Not exactly. Someone would like this topic to be the subject of an X.509
defect report, but this is is currently *not* the subject of an X.509
defect
that has been officially raised.

> and if the text of X.509 eventually changes in a way
> that is incompatible with Son-of-2459, then
> Grandson-of-2459 will need to take that into
> consideration.

Very unlikely to happen.

Additional *explanations* without changing the meaning *could* be
provided
and we are (nearly) all saying the same thing using different words.
Santosh
in a subsequent e-mail provided one of these explanations:

"In my analysis, DS means you are signing some challenge to prove
possession of a private key and thus authenticate yourself whereas with
NR you are saying that I know what this data is and I am signing it." 

I would add that a certificate with the the DS bit set can also be used
to
authenticate data (this does not mean that the signer has read the
data).

Now, there are cases where, beyond the fact that the signer did know
what he
signed, he wants to say exactly what its signature means.

This can be achieved using three ways:

1) the document that is signed is unambiguous and its semantics says
that
the signature means XXX.

2) a signed attribute (using the CMS language) is signed in addition to
the
document and indicates a signature policy that is explicit about the
meaning
of all signatures performed under that policy (note that one single
meaning
is possible in that case).

3) another signed attribute (using the CMS language) is signed in
addition
to the document and the previous attribute. It indicates the type of
commitment being made under the signature policy for that signature 
(note that multiple meanings are possible in that case).

As a result, the variety of meanings is NOT placed in the Certificate
Policy
from the CA.

> We can all live with the text because we have no consensus on 
> anything better.  

Fine.

Denis

> That doesn't rule out the faint hope that the ITU can develop a
> meaningful replacement in the future.
> 
> Dave
> 
> "Housley, Russ" wrote:
> >
> > Dave:
> >
> > I am sorry that I replied to this thread at all.  This topic has
been debated
> > before, and the text in Son-of-RFC 2459 is the result of that
debate.
> > Obviously, everyone can live with that text because no objections
were raised
> > during WG Last Call or IETF Last Call.
> >
> > I am not surprised that there is not 100% agreement....
> >
> > Russ


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g42HI5f03062 for ietf-pkix-bks; Thu, 2 May 2002 10:18:05 -0700 (PDT)
Received: from mailout08.sul.t-online.com (mailout08.sul.t-online.com [194.25.134.20]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g42HI2a03057 for <[e-mail]>; Thu, 2 May 2002 10:18:03 -0700 (PDT)
Received: from fwd06.sul.t-online.de  by mailout08.sul.t-online.com with smtp  id 173KDP-0000bo-01; Thu, 02 May 2002 19:17:59 +0200
Received: from junker.stroeder.com (520010731148-0001@[62.224.165.103]) by fmrl06.sul.t-online.com with esmtp id 173KD7-2Ci3WKC; Thu, 2 May 2002 19:17:41 +0200
Received: from stroeder.com (junker [127.0.0.1]) by junker.stroeder.com (Postfix) with ESMTP id 93439157868 for <[e-mail]>; Thu,  2 May 2002 19:17:25 +0200 (CEST)
Message-ID: <[e-mail]>
Date: Thu, 02 May 2002 19:17:25 +0200
From: =?ISO-8859-1?Q?Michael_Str=F6der?= <[e-mail]>
Reply-To: [e-mail]
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.9+) Gecko/20020423
X-Accept-Language: de-DE, de, en
MIME-Version: 1.0
To: pkix <[e-mail]>
Subject: Re: I-D ACTION:draft-ietf-pkix-warranty-extn-00.txt
References: <[e-mail]> <[e-mail]> <[e-mail]> <000401c1f1f3$4d28c8f0$c06fa8c0@DL20860>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
X-Sender: [e-mail]
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Yuriy Dzambasow wrote:
> 
> I still think contracts are the more effective way of handling this.

Yes! Especially since contracts cover a certain business case.

Ciao, Michael.



Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g42H4vo02593 for ietf-pkix-bks; Thu, 2 May 2002 10:04:57 -0700 (PDT)
Received: from mtiwmhc25.worldnet.att.net (mtiwmhc25.worldnet.att.net [204.127.131.50]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g42H4ua02587 for <[e-mail]>; Thu, 2 May 2002 10:04:56 -0700 (PDT)
Received: from Chokhani ([12.91.131.201]) by mtiwmhc25.worldnet.att.net (InterMail vM.4.01.03.27 201-229-121-127-20010626) with ESMTP id <20020502170450.HEJL2855.mtiwmhc25.worldnet.att.net@Chokhani>; Thu, 2 May 2002 17:04:50 +0000
From: "Santosh Chokhani" <[e-mail]>
To: "'Tony Bartoletti'" <[e-mail]>, "'David P. Kemp'" <[e-mail]>, "'Housley, Russ'" <[e-mail]>
Cc: <[e-mail]>, <[e-mail]>
Subject: RE: Meaning of Non-repudiation
Date: Thu, 2 May 2002 13:03:08 -0400
Message-ID: <002101c1f1fb$b15d94b0$a300a8c0@Chokhani>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.2627
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4910.0300
In-Reply-To: <[e-mail]>
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Tony:

I am not qualified to go into the legal mumbo-jumbo.  I also think that
naming a bit "non-repudiation" was unfortunate.  I think the user and/or
the application do know if they are signing a challenge as a part of an
authentication process or they are performing digital signature to
provide source authentication.

Thus, we do need two bits: one for authentication protocols and one for
digital signatures.  Whether we rename the current two bits or not, is
up to the group.

-----Original Message-----
From: Tony Bartoletti [mailto:[e-mail]] 
Sent: Wednesday, May 01, 2002 8:24 PM
To: Santosh Chokhani; 'David P. Kemp'; 'Housley, Russ'
Cc: [e-mail]; [e-mail]
Subject: RE: Meaning of Non-repudiation


At 06:09 PM 5/1/02 -0400, you wrote:

>Tony:
>
>In my analysis, DS means you are signing some challenge to prove 
>possession of a private key and thus authenticate yourself whereas with

>NR you are saying that I know what this data is and I am signing it.

Santosh,

I understand the intent (and the utility of this distinction).  What you

write is what it "should mean" to the signing party, and the relying 
party.  The real question is, what does it mean to the software
developer 
who must create a product that applies only the right key at the right 
time?  It is easy to distinguish the extremes, but there are perhaps
gray 
areas.

The latter form, "I know what this data is and I am signing it", could
mean:

a.  I demonstrate that I was in possession of this material.
b.  I claim to have authored/authorized this material.
c.  I have read these terms.
d.  I have read and understood these terms.
e.  I have read, understood, and intend to abide by these terms.

If I receive an email, and the application pops-up a message that reads,

"The sender has requested a return receipt to indicate you have received

this email", which form of signature should apply?  What if the pop-up 
read, "... that you have received and understood ..." or "understood and

will abide by"?

As a software engineer, I believe this is quite a bit fuzzier than (say)

cert-sign vs CRL-sign, which are highly formalized objects easy to
distinguish.

Consider also that there is software that "automates click-through".  In

essence, it automates (for instance) web-browsing, identifies certain 
"buttons" and issues the "click" for subsequent action, even with no
human 
present.  Thus, it is problematic to assume that (say) a GUI can be 
restricted to, or imply, activities requiring "human intervention".

___tony___



Tony Bartoletti 925-422-3881 <[e-mail]>
Information Operations, Warfare and Assurance Center
Lawrence Livermore National Laboratory
Livermore, CA 94551-9900






Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g42GOCB01555 for ietf-pkix-bks; Thu, 2 May 2002 09:24:12 -0700 (PDT)
Received: from e1.ny.us.ibm.com (e1.ny.us.ibm.com [32.97.182.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g42GOAa01551 for <[e-mail]>; Thu, 2 May 2002 09:24:10 -0700 (PDT)
Received: from northrelay02.pok.ibm.com (northrelay02.pok.ibm.com [9.56.224.150]) by e1.ny.us.ibm.com (8.12.2/8.12.2) with ESMTP id g42GNP6r060680; Thu, 2 May 2002 12:23:25 -0400
Received: from d01ml062.pok.ibm.com (d01ml062.pok.ibm.com [9.117.250.163]) by northrelay02.pok.ibm.com (8.11.1m3/NCO/VER6.1) with ESMTP id g42GNMx48376; Thu, 2 May 2002 12:23:22 -0400
Importance: Normal
Sensitivity: 
Subject: Re: I-D ACTION:draft-ietf-pkix-warranty-extn-00.txt
To: "Yuriy Dzambasow" <[e-mail]>
Cc: "Michael Myers" <[e-mail]>, "Al Arsenault" <[e-mail]>, "Housley, Russ" <[e-mail]>, "Denis Pinkas" <[e-mail]>, "pkix" <[e-mail]>
X-Mailer: Lotus Notes Release 5.0.7  March 21, 2001
Message-ID: <[e-mail]>
From: "Tom Gindin" <[e-mail]>
Date: Thu, 2 May 2002 12:23:23 -0400
X-MIMETrack: Serialize by Router on D01ML062/01/M/IBM(Release 5.0.9a |January 28, 2002) at 05/02/2002 12:23:24 PM
MIME-Version: 1.0
Content-type: text/plain; charset=us-ascii
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

      Yuri:

      I agree with you and most of the people who've sent in comments that
a warranty from the CA to a single RP or a set of RP's has more evident
reason to be in a certificate than a warranty from the CA to the subject.
However, a warranty from the CA to an RP (or one which limits liability to
all RP's combined) does have some use in a certificate.
      It seems to me that there are several plausible limits which a CA
could impose on its liability:
1     A limit per transaction. This is currently defined as a QCStatement.
2     A limit for all transactions to a given relying party.  This is
fairly similar to the first one.
3     A limit for all transactions to a legally associated set of relying
parties (say all RP's employed by the same corporation), which is also
similar to first case.
4     A global limit for transactions to all relying parties combined.
      Quite evidently, the last of these is most favorable to the CA and
least favorable to the relying parties.  From an RP's standpoint, its main
advantage is that it's better than a statement in the CPS which says "we
aren't liable".
      As should be evident, I think the WarrantyType field in the draft
should have four values rather than two, since "aggregated" could mean any
of the last three cases.

            Tom Gindin


"Yuriy Dzambasow" <[e-mail]>@mail.imc.org on 05/02/2002 10:00:05
AM

Sent by:    [e-mail]


To:    "Michael Myers" <[e-mail]>, "Al Arsenault"
       <[e-mail]>, "Housley, Russ" <[e-mail]>,
       "Denis Pinkas" <[e-mail]>
cc:    "pkix" <[e-mail]>
Subject:    Re: I-D ACTION:draft-ietf-pkix-warranty-extn-00.txt



I agree with Mike and Al.  In my opinion, warranties make more sense if
they
are provided by the CA to the RP.  In addition, I think it makes more sense
to handle these sorts of warranties through contracts, and not through
certificate extensions.

Yuriy


----- Original Message -----
From: "Michael Myers" <[e-mail]>
To: "Al Arsenault" <[e-mail]>; "Housley, Russ"
<[e-mail]>; "Denis Pinkas" <[e-mail]>
Cc: "pkix" <[e-mail]>
Sent: Wednesday, May 01, 2002 8:39 PM
Subject: RE: I-D ACTION:draft-ietf-pkix-warranty-extn-00.txt


>
> Al,
>
> If I'm reading you correctly, I agree the WG should go
> cautiously here.  This is inherently a legal issue which is
> beyond our reach as technologists.  It's more within the scope
> of our friends at ISC.
>
> Mike
>
> > -----Original Message-----
> > From: [e-mail]
> > [mailto:[e-mail]]On Behalf Of Al Arsenault
> > Sent: Wednesday, May 01, 2002 4:25 PM
> > To: Housley, Russ; Denis Pinkas
> > Cc: pkix
> > Subject: Re: I-D ACTION:draft-ietf-pkix-warranty-extn-00.txt
> >
> >
> >
> > The more I think about this, the more I sort of agree
> > with Denis.  It's not
> > clear to me what good this extension is.  It
> > indicates a relationship
> > between a subscriber and a CA, NOT an RP and a CA or
> > an RP and a subscriber.
> > Therefore, what good is it?  Why do I as an RP care -
> > or even have to know -
> > for how much a CA will indemnify the subscriber if
> > something goes wrong?
> > That's the kind of thing that can easily be covered
> > in some sort of contract
> > between the CA and subscriber, not in the certificate.
> >
> > This extension may give me as an RP a hint that
> > "well, the CA has at least
> > this much insurance/cash in the bank, and is willing
> > to fork it over to the
> > subscriber if need be, so I can start my lawsuit by
> > asking for at least this
> > much in damages". But I can't see any real use to it.
> >
> > So I'm not a big fan of pushing this forward; I think
> > it will likely cause
> > more confusion than anything else among the non-PKI-astute.
> >
> > All that being said, since it's all optional and I
> > don't actually have to
> > implement it, I really won't fight too strongly
> > against it, if somebody else
> > thinks that there's an actual use case.
> >
> >         Al Arsenault
>
>







Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g42G5gX01051 for ietf-pkix-bks; Thu, 2 May 2002 09:05:42 -0700 (PDT)
Received: from bach.digsigtrust.com (host65-54.digsigtrust.com [208.30.65.54]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g42G5ea01047 for <[e-mail]>; Thu, 2 May 2002 09:05:40 -0700 (PDT)
Received: from smtp.digsigtrust.com by smtp1.digsigtrust.com  with ESMTP id g42G5bJ12117; Thu, 2 May 2002 10:05:37 -0600 (MDT)
Received: from DL20860 ([65.206.105.101]) by smtp.digsigtrust.com with SMTP id g42G2ag00285; Thu, 2 May 2002 10:02:36 -0600 (MDT)
Message-ID: <000401c1f1f3$4d28c8f0$c06fa8c0@DL20860>
From: "Yuriy Dzambasow" <[e-mail]>
To: "Housley, Russ" <[e-mail]>, "Denis Pinkas" <[e-mail]>, "Al Arsenault" <[e-mail]>
Cc: "pkix" <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]>
Subject: Re: I-D ACTION:draft-ietf-pkix-warranty-extn-00.txt
Date: Thu, 2 May 2002 12:06:15 -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 6.00.2600.0000
X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Russ:

----- Original Message -----
From: "Housley, Russ" <[e-mail]>
To: "Denis Pinkas" <[e-mail]>; "Al Arsenault"
<[e-mail]>
Cc: "pkix" <[e-mail]>
Sent: Thursday, May 02, 2002 9:44 AM
Subject: Re: I-D ACTION:draft-ietf-pkix-warranty-extn-00.txt


>
> Al & Denis:
>
> Maybe the language needs to be made more clear, but that is not what I
> think this proposed extension is about.  The second paragraph in the
> Introduction says:
>
>    The certificate warranty provides an extended monetary coverage for
>    the legal liability of the CA, in favor of the subscriber.  The
>    certificate warranty primarily concerns the use, storage, and reliance
>    on a certificate by a third party and the CA.  It is common for a CA
>    to limit liability by establishing reliance limits on the use of a
>    certificate.  It is not uncommon for a CA to attempt through
>    contractual means to exclude its liability entirely.  However, this
>    has the effect of undermining the confidence that commerce requires to
>    gainfully use certificates.
>
> I think that this means the third party (the RP in your notes) can go to
> the CA to file a claim against the warranty.  The RP says: "I relied on
the
> certificate that you issued, and I was harmed, therefore I expect to be
> compensated."  The warranty extension will tell the RP the extent of the
> possible compensation.  Knowing this up front, the RP can decide whether
to
> enter into a business transaction or not.  The whole point, as I see it,
is
> to allow automation of as many of the risk-related decisions as possible.

I still think contracts are the more effective way of handling this.  Then
again, and as Al said, since this is an optional extension, I'm not going to
argue it much.  If other folks think its useful...fine.

Yuriy




>
> Russ
>
> At 07:24 PM 5/1/2002 -0400, Al Arsenault wrote:
> >The more I think about this, the more I sort of agree with Denis.  It's
not
> >clear to me what good this extension is.  It indicates a relationship
> >between a subscriber and a CA, NOT an RP and a CA or an RP and a
subscriber.
> >Therefore, what good is it?  Why do I as an RP care - or even have to
know -
> >for how much a CA will indemnify the subscriber if something goes wrong?
> >That's the kind of thing that can easily be covered in some sort of
contract
> >between the CA and subscriber, not in the certificate.
> >
> >This extension may give me as an RP a hint that "well, the CA has at
least
> >this much insurance/cash in the bank, and is willing to fork it over to
the
> >subscriber if need be, so I can start my lawsuit by asking for at least
this
> >much in damages". But I can't see any real use to it.
> >
> >So I'm not a big fan of pushing this forward; I think it will likely
cause
> >more confusion than anything else among the non-PKI-astute.
> >
> >All that being said, since it's all optional and I don't actually have to
> >implement it, I really won't fight too strongly against it, if somebody
else
> >thinks that there's an actual use case.
> >
> >         Al Arsenault
> >
> >----- Original Message -----
> >From: "Housley, Russ" <[e-mail]>
> >To: "Denis Pinkas" <[e-mail]>
> >Cc: "pkix" <[e-mail]>
> >Sent: Wednesday, May 01, 2002 1:17 PM
> >Subject: Re: I-D ACTION:draft-ietf-pkix-warranty-extn-00.txt
> >
> >
> > >
> > > Denis:
> > >
> > > It seems to me that the warranty in this case does have to do with the
> > > relationship between the CA and the subscriber.  If a replying party
is
> > > harmed, they will go after the CA (assuming that the subscriber has
> > > vanished or is a less attractive target).  The CA will likely have
> > > insurance to back up the warranty, and this extension indication the
terms
> > > of that warranty.
> > >
> > > Russ
> > >
> > > At 02:59 PM 4/30/2002 +0200, Denis Pinkas wrote:
> > >
> > > >Comments on the Warranty certificate extension
> > > >
> > > >Before looking at the technical details of the warranty, it is
important
> >to
> > > >make sure that practical cases can be solved. Since a warranty is
> >mentioned,
> > > >legal considerations cannot be left aside.
> > > >
> > > >The current proposal states that "the certificate warranty provides
an
> > > >extended monetary coverage for the legal liability of the CA, in
favor of
> > > >the *subscriber*".
> > > >
> > > >The problem is that the warranty should also apply in favor of one or
> >more
> > > >*relying parties*. Are the relaying parties going to complain to the
> > > >subscriber only and will then the subscriber makes arrangement with
the
> >CA
> > > >only ?
> > > >
> > > >For the extreme cases where there are, let us say, 10.000 plaintiffs
each
> > > >one claiming for a damage of 1.000 $ and when the upper limit of the
> > > >warranty will be altogether, for example, 100.000 $ (called
"aggregated
> > > >damage" in the draft). What would be the criteria to reimburse the
> > > >plaintiffs ? Since the total damage is 10.000.000 $, are only 10 % of
the
> > > >first plaintiffs to be reimbursed ? or will a random choice will be
done
> > > >among the 10.000 plaintiffs ? Since the warranty is for the
subscriber
> >and
> > > >not for the plaintiffs, will the subscriber deal with the 10.000
> >plaintiffs
> > > >directly ?
> > > >
> > > >The second point is that no conditions to get advantage of the
warranty
> >are
> > > >mentioned. Should a relying party only check the revocation status of
the
> > > >certificate ? Should the relying party check the certificate against
a
> > > >validation policy ? What kind of proof of its checking should the
relying
> > > >party present to the CA;  or to the subscriber ? An OSCP response? A
DPV
> > > >response ? Should the details of the transaction involved be provided
?
> > > >
> > > >For all these reasons, the difficulty of use of such an extension is
very
> > > >questionable.
> > > >
> > > >Now, it should be noticed that such a similar extension has already
been
> > > >defined in ETSI TS 101 862. This extension takes advantage of the
> > > >qcStatement defined in RFC 3039 and specifies a statement regarding
> >limits
> > > >on the value of transactions.
> > > >
> > > >This optional statement contains:
> > > >
> > > >- an identifier of this statement (represented by an OID);
> > > >- a monetary value expressing the limit on the value of transactions.
> > > >
> > > >This statement is a statement by the issuer which impose a limitation
on
> >the
> > > >value of transaction for which this certificate can be used to the
> >specified
> > > >amount (MonetaryValue), according to the Directive 1999/93/EC of the
> > > >European Parliament and of the Council of 13 December 1999 on a
Community
> > > >framework for electronic signatures, as implemented in the law of the
> > > >country specified in the issuer field of this certificate.
> > > >
> > > >In fact the Directive is requiring (in Annex I) a field to specify
> >"limits
> > > >on the value of transactions for which the certificate can be used,
if
> > > >applicable". The reason for that field is specified in the Directive
in
> > > >these terms:
> > > >
> > > >"The certification-service-provider shall not be liable for damage
> >arising
> > > >from use of a qualified certificate which exceeds the limitations
placed
> >on
> > > >it".
> > > >
> > > >The text does *not* say: "The certification-service-provider *shall
be*
> > > >liable for damage arising from use of a qualified certificate which
> >*meets*
> > > >the limitations placed on it".
> > > >
> > > >So it is more a *disclaimer of warranty* rather than a warranty. If
the
> > > >proposal was for a warranty disclaimer extension, then it would be
more
> > > >appropriate. In such a case it would not be necessary to indicate the
> > > >conditions to meet to get the warranty since there would be no
warranty.
> > > >
> > > >It is doubtful that an off-line indication in a certificate will be
the
> > > >right answer to a problem that is commonly solved using an on-line
> >protocol
> > > >(e.g. money withdrawal on an ATM).
> > > >
> > > >Denis
> > > >
> > > >
> > > > > 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           : Warranty Certificate Extension
> > > > >         Author(s)       : D. Linsenbardt, S. Pontius
> > > > >         Filename        : draft-ietf-pkix-warranty-extn-00.txt
> > > > >         Pages           : 7
> > > > >         Date            : 18-Apr-02
> > > > >
> > > > > This document describes a certificate extension to explicitly
state
> > > > > the warranty offered by a Certificate Authority (CA) for a the
> > > > > certificate containing the extension.
> > > > >
> > > > > A URL for this Internet-Draft is:
> > > > >
> >http://www.ietf.org/internet-drafts/draft-ietf-pkix-warranty-extn-00.txt
>



Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g42DxvH25577 for ietf-pkix-bks; Thu, 2 May 2002 06:59:57 -0700 (PDT)
Received: from vulcan.rsasecurity.com (vulcan.rsasecurity.com [204.167.114.130]) by above.proper.com (8.11.6/8.11.3) with SMTP id g42Dxta25573 for <[e-mail]>; Thu, 2 May 2002 06:59:55 -0700 (PDT)
Received: from sdtihq24.securitydynamics.com by vulcan.rsasecurity.com via smtpd (for mail.imc.org [208.184.76.43]) with SMTP; 2 May 2002 13:58:29 UT
Received: from ebola.securitydynamics.com (ebola.securid.com [192.80.211.4]) by sdtihq24.securid.com (Pro-8.9.3/Pro-8.9.3) with ESMTP id JAA19841; Thu, 2 May 2002 09:58:13 -0400 (EDT)
Received: from exna00.securitydynamics.com (localhost [127.0.0.1]) by ebola.securitydynamics.com (8.10.2+Sun/8.9.1) with ESMTP id g42Dxwg29079; Thu, 2 May 2002 09:59:58 -0400 (EDT)
Received: by exna00.securitydynamics.com with Internet Mail Service (5.5.2653.19) id <HKX15J6G>; Thu, 2 May 2002 09:57:21 -0400
Received: from HOUSLEY-LAP.rsasecurity.com (HOUSLEY-LAP [10.3.16.53]) by exna00.securitydynamics.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id HKX15J6C; Thu, 2 May 2002 09:57:18 -0400
From: "Housley, Russ" <[e-mail]>
To: Denis Pinkas <[e-mail]>, Al Arsenault <[e-mail]>
Cc: pkix <[e-mail]>
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Version 5.1
Date: Thu, 02 May 2002 09:44:19 -0400
Subject: Re: I-D ACTION:draft-ietf-pkix-warranty-extn-00.txt
In-Reply-To: <010f01c1f167$779b3370$6401a8c0@SJOSEPH>
References: <[e-mail]> <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Al & Denis:

Maybe the language needs to be made more clear, but that is not what I 
think this proposed extension is about.  The second paragraph in the 
Introduction says:

   The certificate warranty provides an extended monetary coverage for
   the legal liability of the CA, in favor of the subscriber.  The
   certificate warranty primarily concerns the use, storage, and reliance
   on a certificate by a third party and the CA.  It is common for a CA
   to limit liability by establishing reliance limits on the use of a
   certificate.  It is not uncommon for a CA to attempt through
   contractual means to exclude its liability entirely.  However, this
   has the effect of undermining the confidence that commerce requires to
   gainfully use certificates.

I think that this means the third party (the RP in your notes) can go to 
the CA to file a claim against the warranty.  The RP says: "I relied on the 
certificate that you issued, and I was harmed, therefore I expect to be 
compensated."  The warranty extension will tell the RP the extent of the 
possible compensation.  Knowing this up front, the RP can decide whether to 
enter into a business transaction or not.  The whole point, as I see it, is 
to allow automation of as many of the risk-related decisions as possible.

Russ

At 07:24 PM 5/1/2002 -0400, Al Arsenault wrote:
>The more I think about this, the more I sort of agree with Denis.  It's not
>clear to me what good this extension is.  It indicates a relationship
>between a subscriber and a CA, NOT an RP and a CA or an RP and a subscriber.
>Therefore, what good is it?  Why do I as an RP care - or even have to know -
>for how much a CA will indemnify the subscriber if something goes wrong?
>That's the kind of thing that can easily be covered in some sort of contract
>between the CA and subscriber, not in the certificate.
>
>This extension may give me as an RP a hint that "well, the CA has at least
>this much insurance/cash in the bank, and is willing to fork it over to the
>subscriber if need be, so I can start my lawsuit by asking for at least this
>much in damages". But I can't see any real use to it.
>
>So I'm not a big fan of pushing this forward; I think it will likely cause
>more confusion than anything else among the non-PKI-astute.
>
>All that being said, since it's all optional and I don't actually have to
>implement it, I really won't fight too strongly against it, if somebody else
>thinks that there's an actual use case.
>
>         Al Arsenault
>
>----- Original Message -----
>From: "Housley, Russ" <[e-mail]>
>To: "Denis Pinkas" <[e-mail]>
>Cc: "pkix" <[e-mail]>
>Sent: Wednesday, May 01, 2002 1:17 PM
>Subject: Re: I-D ACTION:draft-ietf-pkix-warranty-extn-00.txt
>
>
> >
> > Denis:
> >
> > It seems to me that the warranty in this case does have to do with the
> > relationship between the CA and the subscriber.  If a replying party is
> > harmed, they will go after the CA (assuming that the subscriber has
> > vanished or is a less attractive target).  The CA will likely have
> > insurance to back up the warranty, and this extension indication the terms
> > of that warranty.
> >
> > Russ
> >
> > At 02:59 PM 4/30/2002 +0200, Denis Pinkas wrote:
> >
> > >Comments on the Warranty certificate extension
> > >
> > >Before looking at the technical details of the warranty, it is important
>to
> > >make sure that practical cases can be solved. Since a warranty is
>mentioned,
> > >legal considerations cannot be left aside.
> > >
> > >The current proposal states that "the certificate warranty provides an
> > >extended monetary coverage for the legal liability of the CA, in favor of
> > >the *subscriber*".
> > >
> > >The problem is that the warranty should also apply in favor of one or
>more
> > >*relying parties*. Are the relaying parties going to complain to the
> > >subscriber only and will then the subscriber makes arrangement with the
>CA
> > >only ?
> > >
> > >For the extreme cases where there are, let us say, 10.000 plaintiffs each
> > >one claiming for a damage of 1.000 $ and when the upper limit of the
> > >warranty will be altogether, for example, 100.000 $ (called "aggregated
> > >damage" in the draft). What would be the criteria to reimburse the
> > >plaintiffs ? Since the total damage is 10.000.000 $, are only 10 % of the
> > >first plaintiffs to be reimbursed ? or will a random choice will be done
> > >among the 10.000 plaintiffs ? Since the warranty is for the subscriber
>and
> > >not for the plaintiffs, will the subscriber deal with the 10.000
>plaintiffs
> > >directly ?
> > >
> > >The second point is that no conditions to get advantage of the warranty
>are
> > >mentioned. Should a relying party only check the revocation status of the
> > >certificate ? Should the relying party check the certificate against a
> > >validation policy ? What kind of proof of its checking should the relying
> > >party present to the CA;  or to the subscriber ? An OSCP response? A DPV
> > >response ? Should the details of the transaction involved be provided ?
> > >
> > >For all these reasons, the difficulty of use of such an extension is very
> > >questionable.
> > >
> > >Now, it should be noticed that such a similar extension has already been
> > >defined in ETSI TS 101 862. This extension takes advantage of the
> > >qcStatement defined in RFC 3039 and specifies a statement regarding
>limits
> > >on the value of transactions.
> > >
> > >This optional statement contains:
> > >
> > >- an identifier of this statement (represented by an OID);
> > >- a monetary value expressing the limit on the value of transactions.
> > >
> > >This statement is a statement by the issuer which impose a limitation on
>the
> > >value of transaction for which this certificate can be used to the
>specified
> > >amount (MonetaryValue), according to the Directive 1999/93/EC of the
> > >European Parliament and of the Council of 13 December 1999 on a Community
> > >framework for electronic signatures, as implemented in the law of the
> > >country specified in the issuer field of this certificate.
> > >
> > >In fact the Directive is requiring (in Annex I) a field to specify
>"limits
> > >on the value of transactions for which the certificate can be used, if
> > >applicable". The reason for that field is specified in the Directive in
> > >these terms:
> > >
> > >"The certification-service-provider shall not be liable for damage
>arising
> > >from use of a qualified certificate which exceeds the limitations placed
>on
> > >it".
> > >
> > >The text does *not* say: "The certification-service-provider *shall be*
> > >liable for damage arising from use of a qualified certificate which
>*meets*
> > >the limitations placed on it".
> > >
> > >So it is more a *disclaimer of warranty* rather than a warranty. If the
> > >proposal was for a warranty disclaimer extension, then it would be more
> > >appropriate. In such a case it would not be necessary to indicate the
> > >conditions to meet to get the warranty since there would be no warranty.
> > >
> > >It is doubtful that an off-line indication in a certificate will be the
> > >right answer to a problem that is commonly solved using an on-line
>protocol
> > >(e.g. money withdrawal on an ATM).
> > >
> > >Denis
> > >
> > >
> > > > 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           : Warranty Certificate Extension
> > > >         Author(s)       : D. Linsenbardt, S. Pontius
> > > >         Filename        : draft-ietf-pkix-warranty-extn-00.txt
> > > >         Pages           : 7
> > > >         Date            : 18-Apr-02
> > > >
> > > > This document describes a certificate extension to explicitly state
> > > > the warranty offered by a Certificate Authority (CA) for a the
> > > > certificate containing the extension.
> > > >
> > > > A URL for this Internet-Draft is:
> > > >
>http://www.ietf.org/internet-drafts/draft-ietf-pkix-warranty-extn-00.txt


Received: by above.proper.com (8.11.6/8.11.3) id g42DxWo25564 for ietf-pkix-bks; Thu, 2 May 2002 06:59:32 -0700 (PDT)
Received: from bach.digsigtrust.com (host65-54.digsigtrust.com [208.30.65.54]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g42DxTa25555 for <[e-mail]>; Thu, 2 May 2002 06:59:29 -0700 (PDT)
Received: from smtp.digsigtrust.com by smtp1.digsigtrust.com  with ESMTP id g42DxPJ08829; Thu, 2 May 2002 07:59:25 -0600 (MDT)
Received: from DL20860 ([65.206.105.101]) by smtp.digsigtrust.com with SMTP id g42DuPj27501; Thu, 2 May 2002 07:56:26 -0600 (MDT)
Message-ID: <002101c1f1e1$ad147820$c06fa8c0@DL20860>
From: "Yuriy Dzambasow" <[e-mail]>
To: "Michael Myers" <[e-mail]>, "Al Arsenault" <[e-mail]>, "Housley, Russ" <[e-mail]>, "Denis Pinkas" <[e-mail]>
Cc: "pkix" <[e-mail]>
References: <[e-mail]>
Subject: Re: I-D ACTION:draft-ietf-pkix-warranty-extn-00.txt
Date: Thu, 2 May 2002 10:00:05 -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 6.00.2600.0000
X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

I agree with Mike and Al.  In my opinion, warranties make more sense if they
are provided by the CA to the RP.  In addition, I think it makes more sense
to handle these sorts of warranties through contracts, and not through
certificate extensions.

Yuriy


----- Original Message -----
From: "Michael Myers" <[e-mail]>
To: "Al Arsenault" <[e-mail]>; "Housley, Russ"
<[e-mail]>; "Denis Pinkas" <[e-mail]>
Cc: "pkix" <[e-mail]>
Sent: Wednesday, May 01, 2002 8:39 PM
Subject: RE: I-D ACTION:draft-ietf-pkix-warranty-extn-00.txt


>
> Al,
>
> If I'm reading you correctly, I agree the WG should go
> cautiously here.  This is inherently a legal issue which is
> beyond our reach as technologists.  It's more within the scope
> of our friends at ISC.
>
> Mike
>
> > -----Original Message-----
> > From: [e-mail]
> > [mailto:[e-mail]]On Behalf Of Al Arsenault
> > Sent: Wednesday, May 01, 2002 4:25 PM
> > To: Housley, Russ; Denis Pinkas
> > Cc: pkix
> > Subject: Re: I-D ACTION:draft-ietf-pkix-warranty-extn-00.txt
> >
> >
> >
> > The more I think about this, the more I sort of agree
> > with Denis.  It's not
> > clear to me what good this extension is.  It
> > indicates a relationship
> > between a subscriber and a CA, NOT an RP and a CA or
> > an RP and a subscriber.
> > Therefore, what good is it?  Why do I as an RP care -
> > or even have to know -
> > for how much a CA will indemnify the subscriber if
> > something goes wrong?
> > That's the kind of thing that can easily be covered
> > in some sort of contract
> > between the CA and subscriber, not in the certificate.
> >
> > This extension may give me as an RP a hint that
> > "well, the CA has at least
> > this much insurance/cash in the bank, and is willing
> > to fork it over to the
> > subscriber if need be, so I can start my lawsuit by
> > asking for at least this
> > much in damages". But I can't see any real use to it.
> >
> > So I'm not a big fan of pushing this forward; I think
> > it will likely cause
> > more confusion than anything else among the non-PKI-astute.
> >
> > All that being said, since it's all optional and I
> > don't actually have to
> > implement it, I really won't fight too strongly
> > against it, if somebody else
> > thinks that there's an actual use case.
> >
> >         Al Arsenault
>
>



Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g42BxGI20541 for ietf-pkix-bks; Thu, 2 May 2002 04:59:16 -0700 (PDT)
Received: from odin2.bull.net (odin2.bull.net [192.90.70.84]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g42BxEa20534 for <[e-mail]>; Thu, 2 May 2002 04:59:15 -0700 (PDT)
Received: from lvn-m002.frlv.bull.fr (lvn-m002.frlv.bull.fr [129.184.62.72]) by odin2.bull.net (8.9.3/8.9.3) with ESMTP id OAA11774; Thu, 2 May 2002 14:02:11 +0200
Received: from bull.net ([129.184.37.97]) by lvn-m002.frlv.bull.fr (Lotus Domino Release 5.0.8) with ESMTP id 2002050213584266:56 ; Thu, 2 May 2002 13:58:42 +0200 
Message-ID: <[e-mail]>
Date: Thu, 02 May 2002 13:58:40 +0200
From: Denis Pinkas <[e-mail]>
Organization: Bull SA.
X-Mailer: Mozilla 4.7 [fr] (Win98; I)
X-Accept-Language: fr
MIME-Version: 1.0
To: "Housley, Russ" <[e-mail]>
CC: pkix <[e-mail]>
Subject: Re: I-D ACTION:draft-ietf-pkix-warranty-extn-00.txt
References: <[e-mail]> <[e-mail]>
X-MIMETrack: Itemize by SMTP Server on LVN-M002/FR/BULL(Release 5.0.8 |June 18, 2001) at 02/05/2002 13:58:42, Serialize by Router on LVN-M002/FR/BULL(Release 5.0.8 |June 18, 2001) at 02/05/2002 13:59:13, Serialize complete at 02/05/2002 13:59:13
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset=us-ascii
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Russ,

> Denis:
 
> It seems to me that the warranty in this case does have to do with the
> relationship between the CA and the subscriber.  If a replying party is
> harmed, they will go after the CA (assuming that the subscriber has
> vanished or is a less attractive target).  The CA will likely have
> insurance to back up the warranty, and this extension indication the terms
> of that warranty.

In that case the certificate warranty will be in favor of the *relying
party* rather than the subscriber.

Now, the basic question is still whether such a field is a warranty or 
a disclaimer of warranty above some amounts, and whether it is needed at
all.

This also still leaves open the question about what shall be presented by 
the RP to the CA to possibly get advantage of the warranty.

Since the proposed extension is an optional element, these (complex)
conditions related to the warranty should *not* be part of the Certificate
Policy.

Denis

 
> Russ
> 
> At 02:59 PM 4/30/2002 +0200, Denis Pinkas wrote:
> 
> >Comments on the Warranty certificate extension
> >
> >Before looking at the technical details of the warranty, it is important to
> >make sure that practical cases can be solved. Since a warranty is mentioned,
> >legal considerations cannot be left aside.
> >
> >The current proposal states that "the certificate warranty provides an
> >extended monetary coverage for the legal liability of the CA, in favor of
> >the *subscriber*".
> >
> >The problem is that the warranty should also apply in favor of one or more
> >*relying parties*. Are the relaying parties going to complain to the
> >subscriber only and will then the subscriber makes arrangement with the CA
> >only ?
> >
> >For the extreme cases where there are, let us say, 10.000 plaintiffs each
> >one claiming for a damage of 1.000 $ and when the upper limit of the
> >warranty will be altogether, for example, 100.000 $ (called "aggregated
> >damage" in the draft). What would be the criteria to reimburse the
> >plaintiffs ? Since the total damage is 10.000.000 $, are only 10 % of the
> >first plaintiffs to be reimbursed ? or will a random choice will be done
> >among the 10.000 plaintiffs ? Since the warranty is for the subscriber and
> >not for the plaintiffs, will the subscriber deal with the 10.000 plaintiffs
> >directly ?
> >
> >The second point is that no conditions to get advantage of the warranty are
> >mentioned. Should a relying party only check the revocation status of the
> >certificate ? Should the relying party check the certificate against a
> >validation policy ? What kind of proof of its checking should the relying
> >party present to the CA;  or to the subscriber ? An OSCP response? A DPV
> >response ? Should the details of the transaction involved be provided ?
> >
> >For all these reasons, the difficulty of use of such an extension is very
> >questionable.
> >
> >Now, it should be noticed that such a similar extension has already been
> >defined in ETSI TS 101 862. This extension takes advantage of the
> >qcStatement defined in RFC 3039 and specifies a statement regarding limits
> >on the value of transactions.
> >
> >This optional statement contains:
> >
> >- an identifier of this statement (represented by an OID);
> >- a monetary value expressing the limit on the value of transactions.
> >
> >This statement is a statement by the issuer which impose a limitation on the
> >value of transaction for which this certificate can be used to the specified
> >amount (MonetaryValue), according to the Directive 1999/93/EC of the
> >European Parliament and of the Council of 13 December 1999 on a Community
> >framework for electronic signatures, as implemented in the law of the
> >country specified in the issuer field of this certificate.
> >
> >In fact the Directive is requiring (in Annex I) a field to specify "limits
> >on the value of transactions for which the certificate can be used, if
> >applicable". The reason for that field is specified in the Directive in
> >these terms:
> >
> >"The certification-service-provider shall not be liable for damage arising
> >from use of a qualified certificate which exceeds the limitations placed on
> >it".
> >
> >The text does *not* say: "The certification-service-provider *shall be*
> >liable for damage arising from use of a qualified certificate which *meets*
> >the limitations placed on it".
> >
> >So it is more a *disclaimer of warranty* rather than a warranty. If the
> >proposal was for a warranty disclaimer extension, then it would be more
> >appropriate. In such a case it would not be necessary to indicate the
> >conditions to meet to get the warranty since there would be no warranty.
> >
> >It is doubtful that an off-line indication in a certificate will be the
> >right answer to a problem that is commonly solved using an on-line protocol
> >(e.g. money withdrawal on an ATM).
> >
> >Denis
> >
> >
> > > 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           : Warranty Certificate Extension
> > >         Author(s)       : D. Linsenbardt, S. Pontius
> > >         Filename        : draft-ietf-pkix-warranty-extn-00.txt
> > >         Pages           : 7
> > >         Date            : 18-Apr-02
> > >
> > > This document describes a certificate extension to explicitly state
> > > the warranty offered by a Certificate Authority (CA) for a the
> > > certificate containing the extension.
> > >
> > > A URL for this Internet-Draft is:
> > > http://www.ietf.org/internet-drafts/draft-ietf-pkix-warranty-extn-00.txt


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g42BhOD19767 for ietf-pkix-bks; Thu, 2 May 2002 04:43:24 -0700 (PDT)
Received: from vulcan.rsasecurity.com (vulcan.rsasecurity.com [204.167.114.130]) by above.proper.com (8.11.6/8.11.3) with SMTP id g42BhMa19763 for <[e-mail]>; Thu, 2 May 2002 04:43:22 -0700 (PDT)
Received: from sdtihq24.securitydynamics.com by vulcan.rsasecurity.com via smtpd (for mail.imc.org [208.184.76.43]) with SMTP; 2 May 2002 11:41:55 UT
Received: from ebola.securitydynamics.com (ebola.securid.com [192.80.211.4]) by sdtihq24.securid.com (Pro-8.9.3/Pro-8.9.3) with ESMTP id HAA09267 for <[e-mail]>; Thu, 2 May 2002 07:41:39 -0400 (EDT)
Received: from spirit.dynas.se (localhost [127.0.0.1]) by ebola.securitydynamics.com (8.10.2+Sun/8.9.1) with SMTP id g42BhQS16042 for <[e-mail]>; Thu, 2 May 2002 07:43:26 -0400 (EDT)
Received: (qmail 5369 invoked from network); 2 May 2002 11:43:19 -0000
Received: from sjosefsson-pc.se.eu.rsa.net (HELO sjosefsson-pc.se.eu.rsa.net.rsasecurity.com) (172.16.13.104) by spirit.se.eu.rsa.net with SMTP; 2 May 2002 11:43:19 -0000
To: Stefan Santesson <[e-mail]>
Cc: [e-mail]
Subject: Re: I-D ACTION:draft-ietf-pkix-logotypes-02.txt
References: <[e-mail]> <[e-mail]>
From: Simon Josefsson <[e-mail]>
Date: Thu, 02 May 2002 13:43:13 +0200
In-Reply-To: <[e-mail]> (Stefan Santesson's message of "Thu, 02 May 2002 10:18:48 GMT")
Message-ID: <[e-mail]>
Lines: 54
User-Agent: Gnus/5.090006 (Oort Gnus v0.06) Emacs/21.2 (i686-pc-linux-gnu)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Stefan Santesson <[e-mail]> writes:

> At 16:30 2002-04-21 +1200, Peter Gutmann wrote:
>
>>"Housley, Russ" <[e-mail]> writes:
>>
>> >At 03:30 PM 4/19/2002 +1200, Peter Gutmann wrote:
>> >>"Housley, Russ" <[e-mail]> writes:
>> >>
>> >>>What maximum size do you suggest?
>> >>
>> >>I would say 320x200 *minimum*, for the MPEGs :-).
>> >
>> >We have not allowed MPEGs, just static images in JPEG or GIF format.
>>
>>Actually that was a dual-purpose comment, firstly to reference Bob Jueneman's
>>joke about putting MPEGs in the DN, and secondly to point out that setting
>>arbitrary limits on image sizes is probably pointless given that companies are
>>going to use whatever size and format they feel like, no matter what the spec
>>says.
>
> I see your point, but I still believe that there are a valid need in this case.
>
> I assume that some GUI's for certificate display will need to know and
> design size properties of a certificate display window. This means
> that the GUI makers have to define size limits for all sorts of things
> such as text fields, logos, etc. If no standard sizes are available
> they must invent their own.
> A standard logotype max-size definition thus gives both the GUI makes
> and the CA's a hint about what they should expect and produce in order
> to get optimal performance.

Has the SVG format [1] been considered?  It seems to me that it has
some advantages:

* No need to define size limits to 320x200 or whatever. Devices render
  the image using the resolution of its own screen.

* Disability; (color) blindness, etc.  To point of PKIX logotypes seem
  to move closer to human behaviour, and human behaviour includes
  various form of disabilities as well.

* Smaller size?  I haven't measured, but I can imagine that some logos
  can be described more compactly using a text langugage.

...and to bost...

* Logos will look _better_ since the device renders the image on the
  screen using its special characteristics, instead of having to
  resize, scale or translate the image into monochrome. (The latter
  can really destroy logos if the algorithm to translate the image
  into monochrome is poor, as can be expected on limited devices.)

[1] http://www.w3.org/Graphics/SVG/


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g42BKIc17687 for ietf-pkix-bks; Thu, 2 May 2002 04:20:18 -0700 (PDT)
Received: from mailout06.sul.t-online.com (mailout06.sul.t-online.com [194.25.134.19]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g42BKFa17683 for <[e-mail]>; Thu, 2 May 2002 04:20:15 -0700 (PDT)
Received: from fwd02.sul.t-online.de  by mailout06.sul.t-online.com with smtp  id 173CPH-0000O5-00; Thu, 02 May 2002 10:57:43 +0200
Received: from junker.stroeder.com (520010731148-0001@[62.224.169.199]) by fmrl02.sul.t-online.com with esmtp id 173CP2-1sHlImC; Thu, 2 May 2002 10:57:28 +0200
Received: from stroeder.com (junker [127.0.0.1]) by junker.stroeder.com (Postfix) with ESMTP id 02FE9157864 for <[e-mail]>; Thu,  2 May 2002 10:42:56 +0200 (CEST)
Message-ID: <[e-mail]>
Date: Thu, 02 May 2002 10:42:56 +0200
From: =?ISO-8859-1?Q?Michael_Str=F6der?= <[e-mail]>
Reply-To: [e-mail]
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.9+) Gecko/20020423
X-Accept-Language: de-DE, de, en
MIME-Version: 1.0
To: pkix <[e-mail]>
Subject: Re: I-D ACTION:draft-ietf-pkix-warranty-extn-00.txt
References: <[e-mail]>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
X-Sender: [e-mail]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id g42BKHa17684
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Michael Myers wrote:
 >
 > If I'm reading you correctly, I agree the WG should go
 > cautiously here.  This is inherently a legal issue which is
 > beyond our reach as technologists.

This is the only reasonable conclusion. I'd like to add that it's 
also a business issue.

Because I'm lazy I just repeat my posting already sent to this
list in a similar thread (see below).

Ciao, Michael.

-------- Original Message --------
Subject: Re: Q: Where should do I put a max amount in a X.509v3
certificate?
Date: Mon, 11 Mar 2002 15:55:22 +0100
From: Michael Ströder <[e-mail]>
Reply-To: [e-mail]
CC: [e-mail]
References: <[e-mail]>


Tom Gindin wrote:
 >
 > Since this "purchase limit" is intended as a constraint on
 > signed orders, and those are signed by PKC's rather than AC's,
 > the constraint needs to go into the PKC. I also don't think the
 > syntax is very complex

I'd suggest to thoroughly discuss a business model first before
thinking about technical aspects (not on PKIX list off course). 
 From some discussion I remember that most drafts for something 
like this just didn't fit into how financial institutions are 
working (although the institutions were committed
to use this particular PKI ;-).

So defining technical specifications was completely useless
because there was no working business model behind it.

Ciao, Michael.



Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g42B6qE16165 for ietf-pkix-bks; Thu, 2 May 2002 04:06:52 -0700 (PDT)
Received: from odin2.bull.net (odin2.bull.net [192.90.70.84]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g42B6oa16156 for <[e-mail]>; Thu, 2 May 2002 04:06:50 -0700 (PDT)
Received: from lvn-m002.frlv.bull.fr (lvn-m002.frlv.bull.fr [129.184.62.72]) by odin2.bull.net (8.9.3/8.9.3) with ESMTP id NAA20280; Thu, 2 May 2002 13:09:45 +0200
Received: from bull.net ([129.184.37.97]) by lvn-m002.frlv.bull.fr (Lotus Domino Release 5.0.8) with ESMTP id 2002050213061626:51 ; Thu, 2 May 2002 13:06:16 +0200 
Message-ID: <[e-mail]>
Date: Thu, 02 May 2002 13:06:15 +0200
From: Denis Pinkas <[e-mail]>
Organization: Bull SA.
X-Mailer: Mozilla 4.7 [fr] (Win98; I)
X-Accept-Language: fr
MIME-Version: 1.0
To: Peter Sylvester <[e-mail]>
CC: [e-mail]
Subject: Re: I-D ACTION:draft-ietf-pkix-rfc3161bis-00.txt
References: <[e-mail]>
X-MIMETrack: Itemize by SMTP Server on LVN-M002/FR/BULL(Release 5.0.8 |June 18, 2001) at 02/05/2002 13:06:16, Serialize by Router on LVN-M002/FR/BULL(Release 5.0.8 |June 18, 2001) at 02/05/2002 13:06:48, Serialize complete at 02/05/2002 13:06:48
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset=us-ascii
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Peter,

> The text contains a changement that fixes some text concerning a MUST
> requirement of the TSA policy to be returned, by changing some
> SHOULD to a 'should'.
> 
> I would like to know whether this text corresponds to group
> consensus.
> 
> As far as I remember there are some group members that
> say that the MUST should be a SHOULD.
> 
> I think the conflict can be summarizes with two paragraphs:
> 
> Actual:
> 
>    The policy field MUST indicate the TSA's policy under which the
>    response was produced.  If a similar field was present in the
>    TimeStampReq, then it MUST have the same value, otherwise an error
>    (unacceptedPolicy) MUST be returned.
> 
> Proposed:
> 
>    The 'policy' field MUST indicate the TSA's policy under which the
>    response was produced.  If the field 'reqPolicy' was present in the
>    TimeStampReq, then 'policy' SHOULD have the same value, or an
>    error (unacceptedPolicy) SHOULD be returned.
> 
> Unfortunately it seems difficult to get a common opinion between
> those who specify and those who implement.

Since you posted this message, I have seen no support on the list for your
change proposal, so let us keep the text as it is.

> ------------------------
> 
> I think that the following text
> 
>       " In that case, at any
>        future time, the tokens signed with the corresponding key will be
>        considered as invalid, but tokens generated before the revocation
>        time will remain valid. "

The text you refer to is no longer in the document, because it has been
pointed as erronous by Antoine Bourrouilh on April 4. It has been changed
and the fix has been advertised on the mailing list on April 5 and no one 
has complained with the fix at that time.

Denis  


> should be accompagnied by something like:
> 
>    It is difficult for a user to claim validity of a token that have a date
>    inferior to the revocation date without additional means, e.g.
>    cooperation of the TSA. It is necessary to provide evidence that the
>    time stamp had been created before revocation BY THE TSA.



> 
>


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g42AJD312524 for ietf-pkix-bks; Thu, 2 May 2002 03:19:13 -0700 (PDT)
Received: from exafix.addtrust.com ([212.112.175.83]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g42AJAa12520 for <[e-mail]>; Thu, 2 May 2002 03:19:11 -0700 (PDT)
Received: from stsIBMT20.addtrust.com ([192.168.101.127]) by exafix.addtrust.com with Microsoft SMTPSVC(5.0.2195.2966); Thu, 2 May 2002 12:18:49 +0200
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Version 5.1
Date: Thu, 02 May 2002 12:18:48 +0200
To: [e-mail] (Peter Gutmann), [e-mail], [e-mail]
From: Stefan Santesson <[e-mail]>
Subject: RE: I-D ACTION:draft-ietf-pkix-logotypes-02.txt
Cc: [e-mail], [e-mail]
In-Reply-To: <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
X-OriginalArrivalTime: 02 May 2002 10:18:49.0719 (UTC) FILETIME=[C069C070:01C1F1C2]
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Peter,

Was 300x200 a serious suggestion or a joke?

Further comments in line.

At 16:30 2002-04-21 +1200, Peter Gutmann wrote:

>"Housley, Russ" <[e-mail]> writes:
>
> >At 03:30 PM 4/19/2002 +1200, Peter Gutmann wrote:
> >>"Housley, Russ" <[e-mail]> writes:
> >>
> >>>What maximum size do you suggest?
> >>
> >>I would say 320x200 *minimum*, for the MPEGs :-).
> >
> >We have not allowed MPEGs, just static images in JPEG or GIF format.
>
>Actually that was a dual-purpose comment, firstly to reference Bob Jueneman's
>joke about putting MPEGs in the DN, and secondly to point out that setting
>arbitrary limits on image sizes is probably pointless given that companies are
>going to use whatever size and format they feel like, no matter what the spec
>says.

I see your point, but I still believe that there are a valid need in this case.

I assume that some GUI's for certificate display will need to know and 
design size properties of a certificate display window. This means that the 
GUI makers have to define size limits for all sorts of things such as text 
fields, logos, etc. If no standard sizes are available they must invent 
their own.
A standard logotype max-size definition thus gives both the GUI makes and 
the CA's a hint about what they should expect and produce in order to get 
optimal performance.

If a CA oversize their logos it doesn't have to mean that their 
certificates are rejected, but the CA may have to accept the fact that 
their attached logos are distorted through down sizing into the GUI's 
maximum display size.

I can't imagine that we will see scroll bars on logotypes (as in text 
windows) :-)

>Can you imagine KPMGCoopersPriceLybrandWaterhouseAnderson distributing a
>single cert without the Official Corporate Logo(tm) with Official Corporate
>Animation(tm) and Official Corporate Song(tm) playing in the background?.

In fact I can, if almost nobody is able to even see the darn thing thanks 
to this feature :-)

Jokes aside. I agree that some of these aspects has to be settled by the 
market players, but I still believe GUI implementers need some limitations 
on what they have to handle.

>You only need to look at the cert policy text size limit set in RFC 2459 as an
>example.  I used to check the size limit given in the RFC, but after finding
>the first dozen or so CAs who went way over the limit (some texts were five
>times the size allowed by the RFC) I changed my code to use 5x the max size as
>the upper limit.  After still getting complaints that certs were being
>rejected, I removed the check altogether, since no-one seems to pay any
>attention to the size limits.  So I think that while a comment that N x M is a
>good upper limit would be useful, you'd have to accept that it's going to be
>ignored by anyone who feels their Corporate Image would be slighted by such a
>constraint (or, more likely, who doesn't bother to read RFCs).

I see your point. But I think the case is different for logos since they 
can be scaled but not scrolled. See comment above.

/Stefan

>Peter.



Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g429R5L10271 for ietf-pkix-bks; Thu, 2 May 2002 02:27:05 -0700 (PDT)
Received: from odin2.bull.net (odin2.bull.net [192.90.70.84]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g429R4a10267 for <[e-mail]>; Thu, 2 May 2002 02:27:04 -0700 (PDT)
Received: from lvn-m002.frlv.bull.fr (lvn-m002.frlv.bull.fr [129.184.62.72]) by odin2.bull.net (8.9.3/8.9.3) with ESMTP id LAA19958; Thu, 2 May 2002 11:29:58 +0200
Received: from bull.net ([129.184.37.97]) by lvn-m002.frlv.bull.fr (Lotus Domino Release 5.0.8) with ESMTP id 2002050211265754:35 ; Thu, 2 May 2002 11:26:57 +0200 
Message-ID: <[e-mail]>
Date: Thu, 02 May 2002 11:26:56 +0200
From: Denis Pinkas <[e-mail]>
Organization: Bull SA.
X-Mailer: Mozilla 4.7 [fr] (Win98; I)
X-Accept-Language: fr
MIME-Version: 1.0
To: "David P. Kemp" <[e-mail]>
CC: [e-mail]
Subject: Re: Meaning of Non-repudiation
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
X-MIMETrack: Itemize by SMTP Server on LVN-M002/FR/BULL(Release 5.0.8 |June 18, 2001) at 02/05/2002 11:26:57, Serialize by Router on LVN-M002/FR/BULL(Release 5.0.8 |June 18, 2001) at 02/05/2002 11:27:02, Serialize complete at 02/05/2002 11:27:02
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset=us-ascii
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Dave,
 
> Russ,
> 
> I believe we are all sorry to resurrect this topic.
> But it is currently the subject of an X.509 defect,

Not exactly. Someone would like this topic to be the subject of an X.509
defect report, but this is is currently *not* the subject of an X.509 defect
that has been officially raised.

> and if the text of X.509 eventually changes in a way
> that is incompatible with Son-of-2459, then
> Grandson-of-2459 will need to take that into
> consideration.

Very unlikely to happen.

Additional *explanations* without changing the meaning *could* be provided
and we are (nearly) all saying the same thing using different words. Santosh
in a subsequent e-mail provided one of these explanations:

"In my analysis, DS means you are signing some challenge to prove
possession of a private key and thus authenticate yourself whereas with
NR you are saying that I know what this data is and I am signing it." 

I would add that a certificate with the the DS bit set can also be used to
authenticate data (this does not mean that the signer has read the data).

Now, there are cases where, beyond the fact that the signer did know what he
signed, he wants to say exactly what its signature means.

This can be achieved using three ways:

1) the document that is signed is unambiguous and its semantics says that
the signature means XXX.

2) a signed attribute (using the CMS language) is signed in addition to the
document and indicates a signature policy that is explicit about the meaning
of all signatures performed under that policy (note that one single meaning
is possible in that case).

3) another signed attribute (using the CMS language) is signed in addition
to the document and the previous attribute. It indicates the type of
commitment being made under the signature policy for that signature 
(note that multiple meanings are possible in that case).

As a result, the variety of meanings is NOT placed in the Certificate Policy
from the CA.

> We can all live with the text because we have no consensus on 
> anything better.  

Fine.

Denis

> That doesn't rule out the faint hope that the ITU can develop a
> meaningful replacement in the future.
> 
> Dave
> 
> "Housley, Russ" wrote:
> >
> > Dave:
> >
> > I am sorry that I replied to this thread at all.  This topic has been debated
> > before, and the text in Son-of-RFC 2459 is the result of that debate.
> > Obviously, everyone can live with that text because no objections were raised
> > during WG Last Call or IETF Last Call.
> >
> > I am not surprised that there is not 100% agreement....
> >
> > Russ


Received: by above.proper.com (8.11.6/8.11.3) id g428kOZ01576 for ietf-pkix-bks; Thu, 2 May 2002 01:46:24 -0700 (PDT)
Received: from mailfe.belbone.be (mailfe.belbone.be [195.13.2.32]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g428kMa01568 for <[e-mail]>; Thu, 2 May 2002 01:46:22 -0700 (PDT)
Received: from ETRUST001 (195.13.18.125) by mailfe.belbone.be; 2 May 2002 10:46:16 +0200
From: "Omer Hasret" <[e-mail]>
To: "'Tony Bartoletti'" <[e-mail]>, "'Santosh Chokhani'" <[e-mail]>
Cc: <[e-mail]>
Subject: RE: Meaning of Non-repudiation
Date: Thu, 2 May 2002 10:46:14 +0200
Message-ID: <003501c1f1b5$d177aba0$0900a8c0@ETRUST001>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.2627
In-Reply-To: <[e-mail]>
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
Importance: Normal
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Comments in between,

>>Tony:
>>
>>In my analysis, DS means you are signing some challenge to prove 
>>possession of a private key and thus authenticate yourself whereas
with 
>>NR you are saying that I know what this data is and I am signing it.
>
>Santosh,
>
>I understand the intent (and the utility of this distinction).  What
you 
>write is what it "should mean" to the signing party, and the relying 
>party.  The real question is, what does it mean to the software
developer 
>who must create a product that applies only the right key at the right 
>time?  It is easy to distinguish the extremes, but there are perhaps
gray 
>areas.


Even if it is like Santosh says for the signing and the relying party,
my opinion is that it is not enough. I also think that the meaning of
these concepts should be the same for all parties including the software
developer.


>
>The latter form, "I know what this data is and I am signing it", could
mean:
>
>a.  I demonstrate that I was in possession of this material.
>b.  I claim to have authored/authorized this material.
>c.  I have read these terms.
>d.  I have read and understood these terms.
>e.  I have read, understood, and intend to abide by these terms.
>

Although I think the options above can be discussed and modified, I
quite agree that we need to have some options that explicitly state what
this signature is for. And rather than having this specified within the
CP, which will definitely lead to different understandings of the same
signature for different PKI domains, I'd like this distinction is made
within the certificate. (If possible) Then, I would be much more
comfortable using my private keys.

Regards,
Omer


>If I receive an email, and the application pops-up a message that
reads, 
>"The sender has requested a return receipt to indicate you have
received 
>this email", which form of signature should apply?  What if the pop-up 
>read, "... that you have received and understood ..." or "understood
and 
>will abide by"?
>
>As a software engineer, I believe this is quite a bit fuzzier than
(say) 
>cert-sign vs CRL-sign, which are highly formalized objects easy to
distinguish.
>
>Consider also that there is software that "automates click-through".
In 
>essence, it automates (for instance) web-browsing, identifies certain 
>"buttons" and issues the "click" for subsequent action, even with no
human 
>present.  Thus, it is problematic to assume that (say) a GUI can be 
>restricted to, or imply, activities requiring "human intervention".
>
>___tony___





Received: by above.proper.com (8.11.6/8.11.3) id g420gsh02205 for ietf-pkix-bks; Wed, 1 May 2002 17:42:54 -0700 (PDT)
Received: from mail.coastside.net (mail.coastside.net [207.213.212.6]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g420gra02201 for <[e-mail]>; Wed, 1 May 2002 17:42:53 -0700 (PDT)
Received: from laptop (dsl-63-194-153-52.coastside.net [63.194.153.52]) by poseidon.coastside.net  with SMTP id g420gnOZ004280; Wed, 1 May 2002 17:42:49 -0700 (PDT)
From: "Michael Myers" <[e-mail]>
To: "Al Arsenault" <[e-mail]>, "Housley, Russ" <[e-mail]>, "Denis Pinkas" <[e-mail]>
Cc: "pkix" <[e-mail]>
Subject: RE: I-D ACTION:draft-ietf-pkix-warranty-extn-00.txt
Date: Wed, 1 May 2002 17:39:54 -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.2911.0)
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
In-Reply-To: <010f01c1f167$779b3370$6401a8c0@SJOSEPH>
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Al,

If I'm reading you correctly, I agree the WG should go
cautiously here.  This is inherently a legal issue which is
beyond our reach as technologists.  It's more within the scope
of our friends at ISC.

Mike

> -----Original Message-----
> From: [e-mail]
> [mailto:[e-mail]]On Behalf Of Al Arsenault
> Sent: Wednesday, May 01, 2002 4:25 PM
> To: Housley, Russ; Denis Pinkas
> Cc: pkix
> Subject: Re: I-D ACTION:draft-ietf-pkix-warranty-extn-00.txt
>
>
>
> The more I think about this, the more I sort of agree
> with Denis.  It's not
> clear to me what good this extension is.  It
> indicates a relationship
> between a subscriber and a CA, NOT an RP and a CA or
> an RP and a subscriber.
> Therefore, what good is it?  Why do I as an RP care -
> or even have to know -
> for how much a CA will indemnify the subscriber if
> something goes wrong?
> That's the kind of thing that can easily be covered
> in some sort of contract
> between the CA and subscriber, not in the certificate.
>
> This extension may give me as an RP a hint that
> "well, the CA has at least
> this much insurance/cash in the bank, and is willing
> to fork it over to the
> subscriber if need be, so I can start my lawsuit by
> asking for at least this
> much in damages". But I can't see any real use to it.
>
> So I'm not a big fan of pushing this forward; I think
> it will likely cause
> more confusion than anything else among the non-PKI-astute.
>
> All that being said, since it's all optional and I
> don't actually have to
> implement it, I really won't fight too strongly
> against it, if somebody else
> thinks that there's an actual use case.
>
>         Al Arsenault



Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g41NPhj00709 for ietf-pkix-bks; Wed, 1 May 2002 16:25:43 -0700 (PDT)
Received: from mtaout05 (smtp.comcast.net [24.153.64.2]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g41NPga00705 for <[e-mail]>; Wed, 1 May 2002 16:25:42 -0700 (PDT)
Received: from SJOSEPH (pcp237514pcs.elictc01.md.comcast.net [68.55.160.145]) by mtaout05.icomcast.net (iPlanet Messaging Server 5.1 HotFix 0.6 (built Apr 26 2002)) with SMTP id <[e-mail]> for [e-mail]; Wed, 01 May 2002 19:25:38 -0400 (EDT)
Date: Wed, 01 May 2002 19:24:59 -0400
From: Al Arsenault <[e-mail]>
Subject: Re: I-D ACTION:draft-ietf-pkix-warranty-extn-00.txt
To: "Housley, Russ" <[e-mail]>, Denis Pinkas <[e-mail]>
Cc: pkix <[e-mail]>
Message-id: <010f01c1f167$779b3370$6401a8c0@SJOSEPH>
MIME-version: 1.0
X-MIMEOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
X-Mailer: Microsoft Outlook Express 5.50.4133.2400
Content-type: text/plain; charset=iso-8859-1
Content-transfer-encoding: 7BIT
X-Priority: 3
X-MSMail-priority: Normal
References: <[e-mail]> <[e-mail]>
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

The more I think about this, the more I sort of agree with Denis.  It's not
clear to me what good this extension is.  It indicates a relationship
between a subscriber and a CA, NOT an RP and a CA or an RP and a subscriber.
Therefore, what good is it?  Why do I as an RP care - or even have to know -
for how much a CA will indemnify the subscriber if something goes wrong?
That's the kind of thing that can easily be covered in some sort of contract
between the CA and subscriber, not in the certificate.

This extension may give me as an RP a hint that "well, the CA has at least
this much insurance/cash in the bank, and is willing to fork it over to the
subscriber if need be, so I can start my lawsuit by asking for at least this
much in damages". But I can't see any real use to it.

So I'm not a big fan of pushing this forward; I think it will likely cause
more confusion than anything else among the non-PKI-astute.

All that being said, since it's all optional and I don't actually have to
implement it, I really won't fight too strongly against it, if somebody else
thinks that there's an actual use case.

        Al Arsenault

----- Original Message -----
From: "Housley, Russ" <[e-mail]>
To: "Denis Pinkas" <[e-mail]>
Cc: "pkix" <[e-mail]>
Sent: Wednesday, May 01, 2002 1:17 PM
Subject: Re: I-D ACTION:draft-ietf-pkix-warranty-extn-00.txt


>
> Denis:
>
> It seems to me that the warranty in this case does have to do with the
> relationship between the CA and the subscriber.  If a replying party is
> harmed, they will go after the CA (assuming that the subscriber has
> vanished or is a less attractive target).  The CA will likely have
> insurance to back up the warranty, and this extension indication the terms
> of that warranty.
>
> Russ
>
> At 02:59 PM 4/30/2002 +0200, Denis Pinkas wrote:
>
> >Comments on the Warranty certificate extension
> >
> >Before looking at the technical details of the warranty, it is important
to
> >make sure that practical cases can be solved. Since a warranty is
mentioned,
> >legal considerations cannot be left aside.
> >
> >The current proposal states that "the certificate warranty provides an
> >extended monetary coverage for the legal liability of the CA, in favor of
> >the *subscriber*".
> >
> >The problem is that the warranty should also apply in favor of one or
more
> >*relying parties*. Are the relaying parties going to complain to the
> >subscriber only and will then the subscriber makes arrangement with the
CA
> >only ?
> >
> >For the extreme cases where there are, let us say, 10.000 plaintiffs each
> >one claiming for a damage of 1.000 $ and when the upper limit of the
> >warranty will be altogether, for example, 100.000 $ (called "aggregated
> >damage" in the draft). What would be the criteria to reimburse the
> >plaintiffs ? Since the total damage is 10.000.000 $, are only 10 % of the
> >first plaintiffs to be reimbursed ? or will a random choice will be done
> >among the 10.000 plaintiffs ? Since the warranty is for the subscriber
and
> >not for the plaintiffs, will the subscriber deal with the 10.000
plaintiffs
> >directly ?
> >
> >The second point is that no conditions to get advantage of the warranty
are
> >mentioned. Should a relying party only check the revocation status of the
> >certificate ? Should the relying party check the certificate against a
> >validation policy ? What kind of proof of its checking should the relying
> >party present to the CA;  or to the subscriber ? An OSCP response? A DPV
> >response ? Should the details of the transaction involved be provided ?
> >
> >For all these reasons, the difficulty of use of such an extension is very
> >questionable.
> >
> >Now, it should be noticed that such a similar extension has already been
> >defined in ETSI TS 101 862. This extension takes advantage of the
> >qcStatement defined in RFC 3039 and specifies a statement regarding
limits
> >on the value of transactions.
> >
> >This optional statement contains:
> >
> >- an identifier of this statement (represented by an OID);
> >- a monetary value expressing the limit on the value of transactions.
> >
> >This statement is a statement by the issuer which impose a limitation on
the
> >value of transaction for which this certificate can be used to the
specified
> >amount (MonetaryValue), according to the Directive 1999/93/EC of the
> >European Parliament and of the Council of 13 December 1999 on a Community
> >framework for electronic signatures, as implemented in the law of the
> >country specified in the issuer field of this certificate.
> >
> >In fact the Directive is requiring (in Annex I) a field to specify
"limits
> >on the value of transactions for which the certificate can be used, if
> >applicable". The reason for that field is specified in the Directive in
> >these terms:
> >
> >"The certification-service-provider shall not be liable for damage
arising
> >from use of a qualified certificate which exceeds the limitations placed
on
> >it".
> >
> >The text does *not* say: "The certification-service-provider *shall be*
> >liable for damage arising from use of a qualified certificate which
*meets*
> >the limitations placed on it".
> >
> >So it is more a *disclaimer of warranty* rather than a warranty. If the
> >proposal was for a warranty disclaimer extension, then it would be more
> >appropriate. In such a case it would not be necessary to indicate the
> >conditions to meet to get the warranty since there would be no warranty.
> >
> >It is doubtful that an off-line indication in a certificate will be the
> >right answer to a problem that is commonly solved using an on-line
protocol
> >(e.g. money withdrawal on an ATM).
> >
> >Denis
> >
> >
> > > 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           : Warranty Certificate Extension
> > >         Author(s)       : D. Linsenbardt, S. Pontius
> > >         Filename        : draft-ietf-pkix-warranty-extn-00.txt
> > >         Pages           : 7
> > >         Date            : 18-Apr-02
> > >
> > > This document describes a certificate extension to explicitly state
> > > the warranty offered by a Certificate Authority (CA) for a the
> > > certificate containing the extension.
> > >
> > > A URL for this Internet-Draft is:
> > >
http://www.ietf.org/internet-drafts/draft-ietf-pkix-warranty-extn-00.txt



Received: by above.proper.com (8.11.6/8.11.3) id g41NCAR00340 for ietf-pkix-bks; Wed, 1 May 2002 16:12:10 -0700 (PDT)
Received: from smtp-1.llnl.gov (smtp-1.llnl.gov [128.115.250.81]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g41NC9a00335 for <[e-mail]>; Wed, 1 May 2002 16:12:09 -0700 (PDT)
Received: from poptop.llnl.gov (localhost [127.0.0.1]) by smtp-1.llnl.gov (8.9.3/8.9.3/LLNL-gateway-1.0) with ESMTP id QAA16700; Wed, 1 May 2002 16:12:07 -0700 (PDT)
Received: from catalyst.llnl.gov (catalyst.llnl.gov [128.115.222.68]) by poptop.llnl.gov (8.8.8/LLNL-3.0.2/pop.llnl.gov-5.1) with ESMTP id QAA15068; Wed, 1 May 2002 16:12:06 -0700 (PDT)
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Version 4.3.2
Date: Wed, 01 May 2002 16:24:23 -0800
To: "Santosh Chokhani" <[e-mail]>, "'David P. Kemp'" <[e-mail]>, "'Housley, Russ'" <[e-mail]>
From: Tony Bartoletti <[e-mail]>
Subject: RE: Meaning of Non-repudiation
Cc: <[e-mail]>, <[e-mail]>
In-Reply-To: <006301c1f15c$dd0f0980$a300a8c0@Chokhani>
References: <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

At 06:09 PM 5/1/02 -0400, you wrote:

>Tony:
>
>In my analysis, DS means you are signing some challenge to prove
>possession of a private key and thus authenticate yourself whereas with
>NR you are saying that I know what this data is and I am signing it.

Santosh,

I understand the intent (and the utility of this distinction).  What you 
write is what it "should mean" to the signing party, and the relying 
party.  The real question is, what does it mean to the software developer 
who must create a product that applies only the right key at the right 
time?  It is easy to distinguish the extremes, but there are perhaps gray 
areas.

The latter form, "I know what this data is and I am signing it", could mean:

a.  I demonstrate that I was in possession of this material.
b.  I claim to have authored/authorized this material.
c.  I have read these terms.
d.  I have read and understood these terms.
e.  I have read, understood, and intend to abide by these terms.

If I receive an email, and the application pops-up a message that reads, 
"The sender has requested a return receipt to indicate you have received 
this email", which form of signature should apply?  What if the pop-up 
read, "... that you have received and understood ..." or "understood and 
will abide by"?

As a software engineer, I believe this is quite a bit fuzzier than (say) 
cert-sign vs CRL-sign, which are highly formalized objects easy to distinguish.

Consider also that there is software that "automates click-through".  In 
essence, it automates (for instance) web-browsing, identifies certain 
"buttons" and issues the "click" for subsequent action, even with no human 
present.  Thus, it is problematic to assume that (say) a GUI can be 
restricted to, or imply, activities requiring "human intervention".

___tony___



Tony Bartoletti 925-422-3881 <[e-mail]>
Information Operations, Warfare and Assurance Center
Lawrence Livermore National Laboratory
Livermore, CA 94551-9900






Received: by above.proper.com (8.11.6/8.11.3) id g41M80V28588 for ietf-pkix-bks; Wed, 1 May 2002 15:08:00 -0700 (PDT)
Received: from mtiwmhc25.worldnet.att.net (mtiwmhc25.worldnet.att.net [204.127.131.50]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g41M7xa28584 for <[e-mail]>; Wed, 1 May 2002 15:07:59 -0700 (PDT)
Received: from Chokhani ([12.91.133.180]) by mtiwmhc25.worldnet.att.net (InterMail vM.4.01.03.27 201-229-121-127-20010626) with ESMTP id <20020501220756.TRTB2855.mtiwmhc25.worldnet.att.net@Chokhani>; Wed, 1 May 2002 22:07:56 +0000
From: "Santosh Chokhani" <[e-mail]>
To: "'Tony Bartoletti'" <[e-mail]>, "'David P. Kemp'" <[e-mail]>, "'Housley, Russ'" <[e-mail]>
Cc: <[e-mail]>, <[e-mail]>
Subject: RE: Meaning of Non-repudiation
Date: Wed, 1 May 2002 18:09:27 -0400
Message-ID: <006301c1f15c$dd0f0980$a300a8c0@Chokhani>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.2627
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4910.0300
In-Reply-To: <[e-mail]>
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Tony:

In my analysis, DS means you are signing some challenge to prove
possession of a private key and thus authenticate yourself whereas with
NR you are saying that I know what this data is and I am signing it.

-----Original Message-----
From: [e-mail] [mailto:[e-mail]]
On Behalf Of Tony Bartoletti
Sent: Wednesday, May 01, 2002 4:17 PM
To: David P. Kemp; Housley, Russ
Cc: [e-mail]; [e-mail]
Subject: Re: Meaning of Non-repudiation



At 10:20 AM 5/1/02 -0400, David P. Kemp wrote:

>Steve has it (almost) right, and Son-of-2459 has it wrong.  Son-of-2459
>should provide *all* the distinction that is needed between key usage
bit 
>0 and bit 1:  If bit 1 is not set, then cryptographic applications are 
>expected to not generate and not validate a signature on any document.
>
>The only thing NR=0 should say about a signature is:  "If the hash of 
>this
>authentication exchange happens to equal the hash of the full text of 
>Romeo and Juliet, it must be a pure coincidence.  The signature using
this 
>cert's key is valid only for non-documents."
>
>The only thing NR=1 should say is: "This is a signature on a 
>document.",
>in a manner entirely analogous to the meaning of crlSign=1: "This is a 
>signature on a CRL".
>
>* No other information about a CRL, such as its validity or its
>   applicability to a specific certificate, is contained in the
>   keyUsage extension.
>* No other information about a document, such as whether a human
>   user saw it or whether it is binding, is contained in the
>   key usage extension.

 From this, it is hard for me to distinguish NR=1 from DS=1.  It seems
to 
imply that a digital signature on a "document" (NR=1) is easily 
distinguished from a signature on (say) a "nonce" (for which I assume
DS=1, 
NR=0).

But this merely pushes the "wiggle-factor" elsewhere (e.g.,
distinguishing 
'documents' from 'nonces').

Mechanically, a digital signature provides both data-integrity assurance

AND sender (signer) identification assurance.  One can argue that both
of 
these really come with any digital signature (DS=1) and thus NR=1 adds 
nothing (and NR=0 denies nothing.)  The "mathematical" assurances are 
equally present, so one must be attempting to inject "semantic" with the

NR-bit.  But "No other information about a document ... is contained in
the 
key usage extension" denies even the application of additional semantic.

This leaves little for the NR bit to do ... :)

____tony____


Tony Bartoletti 925-422-3881 <[e-mail]>
Information Operations, Warfare and Assurance Center
Lawrence Livermore National Laboratory
Livermore, CA 94551-9900






Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g41M4lv28542 for ietf-pkix-bks; Wed, 1 May 2002 15:04:47 -0700 (PDT)
Received: from ext-mail.valicert.com ([66.206.205.11]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g41M4ka28537 for <[e-mail]>; Wed, 1 May 2002 15:04:46 -0700 (PDT)
Received: from CONVERSION-DAEMON by ext-mail.valicert.com (PMDF V5.2-33 #46613) id <[e-mail]> for [e-mail]; Wed, 1 May 2002 15:01:14 -0700 (PDT)
Received: from polaris.valicert.com ([192.168.2.34]) by ext-mail.valicert.com (PMDF V5.2-33 #46613) with ESMTP id <[e-mail]>; Wed, 01 May 2002 15:01:14 -0700 (PDT)
Received: by polaris.valicert.com with Internet Mail Service (5.5.2653.19) id <JQL5BPBZ>; Wed, 01 May 2002 15:04:34 -0700
Content-return: allowed
Date: Wed, 01 May 2002 15:04:24 -0700
From: Peter Williams <[e-mail]>
Subject: RE: Meaning of Non-repudiation
To: "'Housley, Russ'" <[e-mail]>, "David P. Kemp" <[e-mail]>
Cc: [e-mail]
Message-id: <[e-mail]>
MIME-version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-type: multipart/alternative; boundary="Boundary_(ID_rbLSH+Tdo0vo31rRC2zKvA)"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

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.

--Boundary_(ID_rbLSH+Tdo0vo31rRC2zKvA)
Content-type: text/plain

 > Son-of-2459 says:
> 
>        Further distinctions between the digitalSignature and
>        nonRepudiation bits may be provided in specific certificate
>        policies.
> 
> This allows the CA to state what additional meaning is associated with the
> nonRepudiation bit.
> 
> Russ

 
OF course, when the RP - via its DPV & DPD agents - does path processing
and discovery (using CP parms selected by the RP in each case), it gets to
select/handle 
of behalf of the RP which of David's CA's 3 DoD CPs actually control the
additional 
application-oriented semantics that are controlling the subscription-weight 
(legal meaning) of David's signature(s). An issuer can control ambiguity
and RP choice by careful administration of the CPs cited in CA certs.
 
I dont see that David and Russ have any real differences of needs. Perhaps
the
only issue is that David would like his NR and DS semantics to be
uniformly imposed on all PKIX/X.509 CPs. The IETF standard requires the
imposition
of such control policies via CP definition. I think the latter is far more
flexible; and uses
CP-parameterized path processing in the manner ISO intended.
 
[1]Certificate Policy: PolicyIdentifier=2.16.840.1.101.2.1.11.5

[2]Certificate Policy: PolicyIdentifier=2.16.840.1.101.2.1.11.9

[3]Certificate Policy: olicyIdentifier=2.16.840.1.101.2.1.11.10


--Boundary_(ID_rbLSH+Tdo0vo31rRC2zKvA)
Content-type: text/html

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=US-ASCII">


<META content="MSHTML 6.00.2715.400" name=GENERATOR></HEAD>
<BODY>
<DIV><FONT face=Arial size=2><SPAN 
class=280134821-01052002>&nbsp;</SPAN></FONT>&gt; Son-of-2459 says:<BR>&gt; 
<BR>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Further distinctions between 
the digitalSignature and<BR>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
nonRepudiation bits may be provided in specific 
certificate<BR>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; policies.<BR>&gt; 
<BR>&gt; This allows the CA to state what additional meaning is associated with 
the<BR>&gt; nonRepudiation bit.<BR>&gt; <BR>&gt; Russ<BR></DIV>
<DIV><SPAN class=280134821-01052002><FONT face=Arial color=#0000ff 
size=2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=280134821-01052002><FONT face=Arial color=#0000ff size=2>OF 
course, when the RP - via its DPV &amp; DPD&nbsp;agents - does path 
processing</FONT></SPAN></DIV>
<DIV><SPAN class=280134821-01052002><FONT face=Arial color=#0000ff size=2>and 
discovery (using CP parms selected by the RP in each case), it 
</FONT></SPAN><SPAN class=280134821-01052002><FONT face=Arial color=#0000ff 
size=2>gets to select/handle </FONT></SPAN></DIV>
<DIV><SPAN class=280134821-01052002><FONT face=Arial color=#0000ff size=2>of 
behalf of the RP which of David's CA's 3 DoD CPs&nbsp;</FONT></SPAN><SPAN 
class=280134821-01052002><FONT face=Arial color=#0000ff size=2>actually control 
the additional </FONT></SPAN></DIV>
<DIV><SPAN class=280134821-01052002><FONT face=Arial color=#0000ff 
size=2>application-oriented </FONT></SPAN><SPAN class=280134821-01052002><FONT 
face=Arial color=#0000ff size=2>semantics that are controlling the 
</FONT></SPAN><SPAN class=280134821-01052002><FONT face=Arial color=#0000ff 
size=2>subscription-weight </FONT></SPAN></DIV>
<DIV><SPAN class=280134821-01052002><FONT face=Arial color=#0000ff size=2>(legal 
meaning) of&nbsp;David's&nbsp;</FONT></SPAN><SPAN class=280134821-01052002><FONT 
face=Arial color=#0000ff size=2>signature(s)</FONT></SPAN><SPAN 
class=280134821-01052002><FONT face=Arial color=#0000ff size=2>. An issuer can 
control ambiguity</FONT></SPAN></DIV>
<DIV><SPAN class=280134821-01052002><FONT face=Arial color=#0000ff size=2>and RP 
choice by careful administration of the CPs cited in CA 
certs.</FONT></SPAN></DIV>
<DIV><SPAN class=280134821-01052002><FONT face=Arial color=#0000ff 
size=2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=280134821-01052002><FONT face=Arial color=#0000ff size=2>I dont 
see that&nbsp;David and Russ have any real differences of needs. Perhaps 
the</FONT></SPAN></DIV>
<DIV><SPAN class=280134821-01052002><FONT face=Arial color=#0000ff size=2>only 
issue is that David would like his NR and DS semantics to be</FONT></SPAN></DIV>
<DIV><SPAN class=280134821-01052002><FONT face=Arial color=#0000ff 
size=2>uniformly imposed on all PKIX/X.509 CPs. The IETF standard requires the 
imposition</FONT></SPAN></DIV>
<DIV><SPAN class=280134821-01052002><FONT face=Arial color=#0000ff size=2>of 
such control policies via CP definition.&nbsp;I think the latter is far more 
flexible; and uses</FONT></SPAN></DIV>
<DIV><SPAN class=280134821-01052002><FONT face=Arial color=#0000ff 
size=2>CP-parameterized path processing in the manner ISO 
intended.</FONT></SPAN></DIV>
<DIV><SPAN class=280134821-01052002><FONT face=Arial color=#0000ff 
size=2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=280134821-01052002></SPAN><SPAN class=280134821-01052002><FONT 
size=1>[1]Certificate Policy: PolicyIdentifier=2.16.840.1.101.2.1.11.5</DIV>
<DIV>
<P>[2]Certificate Policy:<SPAN class=280134821-01052002><FONT face=Arial 
color=#0000ff 
size=2>&nbsp;</FONT></SPAN>PolicyIdentifier=2.16.840.1.101.2.1.11.9</P>
<P>[3]Certificate Policy: 
olicyIdentifier=2.16.840.1.101.2.1.11.10</P></FONT></SPAN></DIV></BODY></HTML>

--Boundary_(ID_rbLSH+Tdo0vo31rRC2zKvA)--


Received: by above.proper.com (8.11.6/8.11.3) id g41J4l623666 for ietf-pkix-bks; Wed, 1 May 2002 12:04:47 -0700 (PDT)
Received: from smtp-1.llnl.gov (smtp-1.llnl.gov [128.115.250.81]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g41J4la23662 for <[e-mail]>; Wed, 1 May 2002 12:04:47 -0700 (PDT)
Received: from poptop.llnl.gov (localhost [127.0.0.1]) by smtp-1.llnl.gov (8.9.3/8.9.3/LLNL-gateway-1.0) with ESMTP id MAA18916; Wed, 1 May 2002 12:04:44 -0700 (PDT)
Received: from catalyst.llnl.gov (catalyst.llnl.gov [128.115.222.68]) by poptop.llnl.gov (8.8.8/LLNL-3.0.2/pop.llnl.gov-5.1) with ESMTP id MAA04199; Wed, 1 May 2002 12:04:30 -0700 (PDT)
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Version 4.3.2
Date: Wed, 01 May 2002 12:16:47 -0800
To: "David P. Kemp" <[e-mail]>, "Housley, Russ" <[e-mail]>
From: Tony Bartoletti <[e-mail]>
Subject: Re: Meaning of Non-repudiation
Cc: [e-mail], [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
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

At 10:20 AM 5/1/02 -0400, David P. Kemp wrote:

>Steve has it (almost) right, and Son-of-2459 has it wrong.  Son-of-2459 
>should provide *all* the distinction that is needed between key usage bit 
>0 and bit 1:  If bit 1 is not set, then cryptographic applications are 
>expected to not generate and not validate a signature on any document.
>
>The only thing NR=0 should say about a signature is:  "If the hash of this 
>authentication exchange happens to equal the hash of the full text of 
>Romeo and Juliet, it must be a pure coincidence.  The signature using this 
>cert's key is valid only for non-documents."
>
>The only thing NR=1 should say is: "This is a signature on a document.", 
>in a manner entirely analogous to the meaning of crlSign=1: "This is a 
>signature on a CRL".
>
>* No other information about a CRL, such as its validity or its
>   applicability to a specific certificate, is contained in the
>   keyUsage extension.
>* No other information about a document, such as whether a human
>   user saw it or whether it is binding, is contained in the
>   key usage extension.

 From this, it is hard for me to distinguish NR=1 from DS=1.  It seems to 
imply that a digital signature on a "document" (NR=1) is easily 
distinguished from a signature on (say) a "nonce" (for which I assume DS=1, 
NR=0).

But this merely pushes the "wiggle-factor" elsewhere (e.g., distinguishing 
'documents' from 'nonces').

Mechanically, a digital signature provides both data-integrity assurance 
AND sender (signer) identification assurance.  One can argue that both of 
these really come with any digital signature (DS=1) and thus NR=1 adds 
nothing (and NR=0 denies nothing.)  The "mathematical" assurances are 
equally present, so one must be attempting to inject "semantic" with the 
NR-bit.  But "No other information about a document ... is contained in the 
key usage extension" denies even the application of additional semantic.

This leaves little for the NR bit to do ... :)

____tony____


Tony Bartoletti 925-422-3881 <[e-mail]>
Information Operations, Warfare and Assurance Center
Lawrence Livermore National Laboratory
Livermore, CA 94551-9900






Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g41HxO821777 for ietf-pkix-bks; Wed, 1 May 2002 10:59:24 -0700 (PDT)
Received: from stingray.missi.ncsc.mil (stingray.missi.ncsc.mil [144.51.50.20]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g41HxMa21773 for <[e-mail]>; Wed, 1 May 2002 10:59:22 -0700 (PDT)
Received: from stingray.missi.ncsc.mil (root@localhost) by stingray.missi.ncsc.mil with ESMTP id g41HupR07805; Wed, 1 May 2002 13:56:51 -0400 (EDT)
Message-ID: <[e-mail]>
Date: Wed, 01 May 2002 13:57:22 -0400
From: "David P. Kemp" <[e-mail]>
X-Mailer: Mozilla 4.77 [en] (X11; U; SunOS 5.7 sun4u)
X-Accept-Language: en
MIME-Version: 1.0
To: "Housley, Russ" <[e-mail]>
CC: [e-mail]
Subject: Re: Meaning of Non-repudiation
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms437763A003C30ACAB0E8B36D"
X-H-S-Loop-Check-Ejzfr: 
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

This is a cryptographically signed message in MIME format.

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

Russ,

I believe we are all sorry to resurrect this topic.
But it is currently the subject of an X.509 defect,
and if the text of X.509 eventually changes in a way
that is incompatible with Son-of-2459, then
Grandson-of-2459 will need to take that into
consideration.

We can all live with the text because we have no
consensus on anything better.  That doesn't rule
out the faint hope that the ITU can develop a
meaningful replacement in the future.

Dave



"Housley, Russ" wrote:
> 
> Dave:
> 
> I am sorry that I replied to this thread at all.  This topic has been debated
> before, and the text in Son-of-RFC 2459 is the result of that debate.
> Obviously, everyone can live with that text because no objections were raised
> during WG Last Call or IETF Last Call.
> 
> I am not surprised that there is not 100% agreement....
> 
> Russ
--------------ms437763A003C30ACAB0E8B36D
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

MIIOhgYJKoZIhvcNAQcCoIIOdzCCDnMCAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC
DIkwggQxMIIDmqADAgECAgMDOtQwDQYJKoZIhvcNAQEFBQAwZDELMAkGA1UEBhMCVVMxGDAW
BgNVBAoTD1UuUy4gR292ZXJubWVudDEMMAoGA1UECxMDRG9EMQwwCgYDVQQLEwNQS0kxHzAd
BgNVBAMTFkRPRCBDTEFTUyAzIEVNQUlMIENBLTMwHhcNMDIwNDI1MTQ1ODQyWhcNMDUwNDI1
MTQ1ODQyWjB3MQswCQYDVQQGEwJVUzEYMBYGA1UEChMPVS5TLiBHb3Zlcm5tZW50MQwwCgYD
VQQLEwNEb0QxDDAKBgNVBAsTA1BLSTEQMA4GA1UECxMHTlNBL0NTUzEgMB4GA1UEAxMXS2Vt
cC5EYXZpZC5QLjA1MTQxMDE0MDQwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAOrsDFPo
087+VZ15OuyrJedIwjkRXWrtqRBzEpkk6Ct+Bkn/uiKzLn7AZ5IxbGDnZvjbvmEzPYkA/tm8
ng0IVxNpKEjdw7O1TbNLnwLSDkckcmq8AzW6se/Dm5nZ7l3ggVx8XuYifnr9E163atD9JxjR
nVM1vcPx262lVck4wTXrAgMBAAGjggHcMIIB2DAOBgNVHQ8BAf8EBAMCBsAwHwYDVR0jBBgw
FoAU7BNbvCGMZpsKi38HXyWwFPkQ9ZswHQYDVR0OBBYEFIs+vTwgtAcXc7Wa3lN5TOdFB2v4
MBYGA1UdIAQPMA0wCwYJYIZIAWUCAQsFMCAGA1UdEQQZMBeBFWRwa2VtcEBtaXNzaS5uY3Nj
Lm1pbDCBjwYDVR0SBIGHMIGEhoGBbGRhcDovL2VtYWlsLWRzLTMuYzNwa2kuY2hhbWIuZGlz
YS5taWwvY24lM2RET0QlMjBDTEFTUyUyMDMlMjBFTUFJTCUyMENBLTMlMmNvdSUzZFBLSSUy
Y291JTNkRG9EJTJjbyUzZFUuUy4lMjBHb3Zlcm5tZW50JTJjYyUzZFVTMIG5BgNVHR8EgbEw
ga4wgauggaiggaWGgaJsZGFwOi8vZW1haWwtZHMtMy5jM3BraS5jaGFtYi5kaXNhLm1pbC9j
biUzZERPRCUyMENMQVNTJTIwMyUyMEVNQUlMJTIwQ0EtMyUyY291JTNkUEtJJTJjb3UlM2RE
b0QlMmNvJTNkVS5TLiUyMEdvdmVybm1lbnQlMmNjJTNkVVM/Y2VydGlmaWNhdGVyZXZvY2F0
aW9ubGlzdDtiaW5hcnkwDQYJKoZIhvcNAQEFBQADgYEA0kEbsqISaLdMPsBZSuefbL8k2fU2
V6nAVrq890J8s7Sf2vlm+Z9SkRqo+KebaeHRCS8Pg5S8YhxRHz6jmvGV9+CqOBhJp/DsW2Iu
tHXUMy46iPxLQfFT75LIjOAGXk929TSgnqk/3ygIVP6/E+6culxD7hTKh4FFa/Dto/V4T6ww
ggQbMIIDhKADAgECAgETMA0GCSqGSIb3DQEBBQUAMGExCzAJBgNVBAYTAlVTMRgwFgYDVQQK
Ew9VLlMuIEdvdmVybm1lbnQxDDAKBgNVBAsTA0RvRDEMMAoGA1UECxMDUEtJMRwwGgYDVQQD
ExNEb0QgQ0xBU1MgMyBSb290IENBMB4XDTAwMDgxMTE3NDUyOVoXDTA2MDgxMDE3NDUyOVow
ZDELMAkGA1UEBhMCVVMxGDAWBgNVBAoTD1UuUy4gR292ZXJubWVudDEMMAoGA1UECxMDRG9E
MQwwCgYDVQQLEwNQS0kxHzAdBgNVBAMTFkRPRCBDTEFTUyAzIEVNQUlMIENBLTMwgZ8wDQYJ
KoZIhvcNAQEBBQADgY0AMIGJAoGBAO98vchr6/EuN4Vw2h1ovziIBzOml88LKtiNQxMFN07J
V04JFR2kZtuOxlCcvNnL2fXv9lRG4teiwqBldt36ekVY/1LDkW6xDecvHnS4BuJhQPnmMdnu
HF47TwK7O/bxvevAKpKeS1/sw1wuyKJN9Bi7jezH36gY+CdT9VwfP4QJAgMBAAGjggHeMIIB
2jAdBgNVHQ4EFgQU7BNbvCGMZpsKi38HXyWwFPkQ9ZswDgYDVR0PAQH/BAQDAgGGMA8GA1Ud
EwEB/wQFMAMBAf8wDAYDVR0kBAUwA4ABADAfBgNVHSMEGDAWgBRsnKXwXI9tQY3EFzuQV8IP
o81t/jAwBgNVHSAEKTAnMAsGCWCGSAFlAgELBTALBglghkgBZQIBCwkwCwYJYIZIAWUCAQsK
MIGDBgNVHRIEfDB6hnhsZGFwOi8vZHMtMy5jM3BraS5jaGFtYi5kaXNhLm1pbC9jbiUzZERv
RCUyMENMQVNTJTIwMyUyMFJvb3QlMjBDQSUyY291JTNkUEtJJTJjb3UlM2REb0QlMmNvJTNk
VS5TLiUyMEdvdmVybm1lbnQlMmNjJTNkVVMwgbAGA1UdHwSBqDCBpTCBoqCBn6CBnIaBmWxk
YXA6Ly9kcy0zLmMzcGtpLmNoYW1iLmRpc2EubWlsL2NuJTNkRG9EJTIwQ0xBU1MlMjAzJTIw
Um9vdCUyMENBJTJjb3UlM2RQS0klMmNvdSUzZERvRCUyY28lM2RVLlMuJTIwR292ZXJubWVu
dCUyY2MlM2RVUz9jZXJ0aWZpY2F0ZXJldm9jYXRpb25saXN0O2JpbmFyeTANBgkqhkiG9w0B
AQUFAAOBgQAmpY01OHZr/vRBJsgxGUX7diGsCGrzYM1C0fhrJknH4L7Lm61Nt1bSZ4/obHjl
QxBQyDx9ovISBAi//TVUd1UKbdqNW7Inso2enmK9beG9eK5M0ZfEdj3S0UxmJAgRXSgVsnE7
xzP3uZ1/mJx++gSwcpd+/NPBVJNjFJPf8RvL4DCCBDEwggOaoAMCAQICAwM61jANBgkqhkiG
9w0BAQUFADBkMQswCQYDVQQGEwJVUzEYMBYGA1UEChMPVS5TLiBHb3Zlcm5tZW50MQwwCgYD
VQQLEwNEb0QxDDAKBgNVBAsTA1BLSTEfMB0GA1UEAxMWRE9EIENMQVNTIDMgRU1BSUwgQ0Et
MzAeFw0wMjA0MjUxNDU5NDZaFw0wNTA0MjUxNDU5NDZaMHcxCzAJBgNVBAYTAlVTMRgwFgYD
VQQKEw9VLlMuIEdvdmVybm1lbnQxDDAKBgNVBAsTA0RvRDEMMAoGA1UECxMDUEtJMRAwDgYD
VQQLEwdOU0EvQ1NTMSAwHgYDVQQDExdLZW1wLkRhdmlkLlAuMDUxNDEwMTQwNDCBnzANBgkq
hkiG9w0BAQEFAAOBjQAwgYkCgYEApfaxUWfMcxUPKtb9p7FeItF5DkWiDmO8i0uiC0VpUPoz
t+9gx4pUo4lOeqcSGMRfFwv7llBtPte7NqtbDefDW2tIFIzzFrv07VPrq0MNCo6rRK/IGCK/
Zmrf/UOfx8Hzvn6dIF+S9YktXZsFpbtJT49v6+E2nmKLpO7OCtW582kCAwEAAaOCAdwwggHY
MA4GA1UdDwEB/wQEAwIFIDAfBgNVHSMEGDAWgBTsE1u8IYxmmwqLfwdfJbAU+RD1mzAdBgNV
HQ4EFgQUYrtZ7SslM3nXtC47SpLr4YEu02AwFgYDVR0gBA8wDTALBglghkgBZQIBCwUwIAYD
VR0RBBkwF4EVZHBrZW1wQG1pc3NpLm5jc2MubWlsMIGPBgNVHRIEgYcwgYSGgYFsZGFwOi8v
ZW1haWwtZHMtMy5jM3BraS5jaGFtYi5kaXNhLm1pbC9jbiUzZERPRCUyMENMQVNTJTIwMyUy
MEVNQUlMJTIwQ0EtMyUyY291JTNkUEtJJTJjb3UlM2REb0QlMmNvJTNkVS5TLiUyMEdvdmVy
bm1lbnQlMmNjJTNkVVMwgbkGA1UdHwSBsTCBrjCBq6CBqKCBpYaBomxkYXA6Ly9lbWFpbC1k
cy0zLmMzcGtpLmNoYW1iLmRpc2EubWlsL2NuJTNkRE9EJTIwQ0xBU1MlMjAzJTIwRU1BSUwl
MjBDQS0zJTJjb3UlM2RQS0klMmNvdSUzZERvRCUyY28lM2RVLlMuJTIwR292ZXJubWVudCUy
Y2MlM2RVUz9jZXJ0aWZpY2F0ZXJldm9jYXRpb25saXN0O2JpbmFyeTANBgkqhkiG9w0BAQUF
AAOBgQDIzhLKkB3qMsN45svSI+hEJN0hjuhiz7hGNFOUco1YnyoyfwvShlJHrl85ptr9mt/L
hMuLunqBCS2tfTKTLWAK9RjR20MRI7evK0qu/OxpxfMI9TFPwHPXSOINrgILbIVvuwOkIYcm
IBcfD2OReXE7+WcRoZDUjZGD4X+80lIm4jGCAcUwggHBAgEBMGswZDELMAkGA1UEBhMCVVMx
GDAWBgNVBAoTD1UuUy4gR292ZXJubWVudDEMMAoGA1UECxMDRG9EMQwwCgYDVQQLEwNQS0kx
HzAdBgNVBAMTFkRPRCBDTEFTUyAzIEVNQUlMIENBLTMCAwM61DAJBgUrDgMCGgUAoIGxMBgG
CSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTAyMDUwMTE3NTcyM1ow
IwYJKoZIhvcNAQkEMRYEFBKSRs5IZEDi/xTfUAM1d2sPJ3CvMFIGCSqGSIb3DQEJDzFFMEMw
CgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgFAMA0G
CCqGSIb3DQMCAgEoMA0GCSqGSIb3DQEBAQUABIGAA5hoEPSA0hoUht6PV2ZDnZruAT1W/Y9c
joUMiO+5D/bJh/CzsBIQr+VpInJkN0NlwI2c67KMQ4DKzll+CRwO6L7RWNsPTplDFqjeb2E4
E4vV7VfOYLdyTRWslwPNbOwMZX9OWFygb3RfCkZA/jKRXFbExrENU5GmALy8PlHwtZc=
--------------ms437763A003C30ACAB0E8B36D--



Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g41HY2v21062 for ietf-pkix-bks; Wed, 1 May 2002 10:34:02 -0700 (PDT)
Received: from vulcan.rsasecurity.com (vulcan.rsasecurity.com [204.167.114.130]) by above.proper.com (8.11.6/8.11.3) with SMTP id g41HY1a21058 for <[e-mail]>; Wed, 1 May 2002 10:34:01 -0700 (PDT)
Received: from sdtihq24.securitydynamics.com by vulcan.rsasecurity.com via smtpd (for mail.imc.org [208.184.76.43]) with SMTP; 1 May 2002 17:32:36 UT
Received: from ebola.securitydynamics.com (ebola.securid.com [192.80.211.4]) by sdtihq24.securid.com (Pro-8.9.3/Pro-8.9.3) with ESMTP id NAA07926 for <[e-mail]>; Wed, 1 May 2002 13:32:20 -0400 (EDT)
Received: from exna00.securitydynamics.com (localhost [127.0.0.1]) by ebola.securitydynamics.com (8.10.2+Sun/8.9.1) with ESMTP id g41HY6h24247 for <[e-mail]>; Wed, 1 May 2002 13:34:06 -0400 (EDT)
Received: by exna00.securitydynamics.com with Internet Mail Service (5.5.2653.19) id <HKX1Z9ZY>; Wed, 1 May 2002 13:31:30 -0400
Received: from HOUSLEY-LAP.rsasecurity.com (HOUSLEY-LAP [10.3.16.38]) by exna00.securitydynamics.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id HKX1Z9Z4; Wed, 1 May 2002 13:31:18 -0400
From: "Housley, Russ" <[e-mail]>
To: "David P. Kemp" <[e-mail]>
Cc: [e-mail]
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Version 5.1
Date: Wed, 01 May 2002 13:33:37 -0400
Subject: Re: Meaning of Non-repudiation
In-Reply-To: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]>
Mime-Version: 1.0
Content-Type: multipart/related; type="text/html"; boundary="=====================_22317741==_.REL"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

--=====================_22317741==_.REL
Content-Type: text/html; charset="us-ascii"

<html>
Dave:<br><br>
I am sorry that I replied to this thread at all.&nbsp; This topic has
been debated before, and the text in Son-of-RFC 2459 is the result of
that debate.&nbsp; Obviously, everyone can live with that text because no
objections were raised during WG Last Call or IETF Last Call.<br><br>
I am not surprised that there is not 100% agreement....<br><br>
Russ<br><br>
At 10:20 AM 5/1/2002 -0400, David P. Kemp wrote:<br>
<blockquote type=cite class=cite cite><img src="cid:[e-mail].0" width=32 height=32 alt="151488c.jpg"><a href="file://c:\program files\qualcomm\eudora\attach\Re Meaning of Non-repudiation1.ems &lt;0265.0002&gt;" eudora="plugin">&nbsp;Re
Meaning of Non-repudiation1.ems </a><br>
The following are the message properties:<br><br>
&nbsp;&nbsp; Encrypted: No<br>
&nbsp;&nbsp; Signed: Yes<br>
&nbsp;&nbsp; Contents Altered after signing: No<br>
&nbsp;&nbsp; Signature Algorithm: SHA1<br><br>
&quot;Housley, Russ&quot; wrote:<br>
&gt; &gt;Tony,<br>
&gt; &gt;<br>
&gt; &gt;I think the PKIX list discussion ended with the observation that
there<br>
&gt; &gt;might be more benefit to the NR bit in the other direction,
i.e., when it<br>
&gt; &gt;is NOT asserted. In that case the interpretation is that the CA
is<br>
&gt; &gt;signalling that the cert was not issued for use in transactions
requiring<br>
&gt; &gt;NR. Thus one would normally set the NR bit to 0 in certs to be
used for<br>
&gt; &gt;signing authentication data exchanges, vs. binding documents,
etc.&nbsp; When<br>
&gt; &gt;the bit is asserted, it is best viewed as a necessary, but not
sufficient,<br>
&gt; &gt;condition for NR.<br>
&gt; &gt;<br>
&gt; &gt;Steve<br>
&gt; <br>
&gt; Son-of-2459 says:<br>
&gt; <br>
&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Further distinctions
between the digitalSignature and<br>
&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; nonRepudiation bits may be
provided in specific certificate<br>
&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; policies.<br>
&gt; <br>
&gt; This allows the CA to state what additional meaning is associated
with the<br>
&gt; nonRepudiation bit.<br>
&gt; <br>
&gt; Russ<br><br>
<br>
Russ,<br><br>
Steve has it (almost) right, and Son-of-2459 has it wrong.<br>
Son-of-2459 should provide *all* the distinction that is needed
between<br>
key<br>
usage bit 0 and bit 1:&nbsp; If bit 1 is not set, then 
cryptographic<br>
applications<br>
are expected to not generate and not validate a signature on any<br>
document.<br><br>
The only thing NR=0 should say about a signature is:&nbsp; &quot;If the
hash of<br>
this<br>
authentication exchange happens to equal the hash of the full text
of<br>
Romeo and Juliet, it must be a pure coincidence.&nbsp; The 
signature<br>
using this cert's key is valid only for non-documents.&quot;<br><br>
The only thing NR=1 should say is: &quot;This is a signature on a
document.&quot;,<br>
in a manner entirely analogous to the meaning of crlSign=1:<br>
&quot;This is a signature on a CRL&quot;.<br><br>
* No other information about a CRL, such as its validity or its<br>
&nbsp; applicability to a specific certificate, is contained in the<br>
&nbsp; keyUsage extension.<br>
* No other information about a document, such as whether a human<br>
&nbsp; user saw it or whether it is binding, is contained in the<br>
&nbsp; key usage extension.<br><br>
Steve should have omitted the word &quot;binding&quot; before
&quot;documents&quot;.&nbsp; It is<br>
a<br>
dangerously confusing red herring.<br><br>
Dave </blockquote></html>

--=====================_22317741==_.REL
Content-Type: image/jpeg; name="151488c.jpg";
 x-mac-type="4A504547"; x-mac-creator="4A565752"
Content-ID: <[e-mail].0>
Content-Transfer-Encoding: base64
Content-Disposition: inline; filename="151488c.jpg"

/9j/4AAQSkZJRgABAQAAAQABAAD/2wBDAAEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEB
AQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQH/2wBDAQEBAQEBAQEBAQEBAQEBAQEBAQEB
AQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQH/wAARCAAgACADASIA
AhEBAxEB/8QAHwAAAQUBAQEBAQEAAAAAAAAAAAECAwQFBgcICQoL/8QAtRAAAgEDAwIEAwUFBAQA
AAF9AQIDAAQRBRIhMUEGE1FhByJxFDKBkaEII0KxwRVS0fAkM2JyggkKFhcYGRolJicoKSo0NTY3
ODk6Q0RFRkdISUpTVFVWV1hZWmNkZWZnaGlqc3R1dnd4eXqDhIWGh4iJipKTlJWWl5iZmqKjpKWm
p6ipqrKztLW2t7i5usLDxMXGx8jJytLT1NXW19jZ2uHi4+Tl5ufo6erx8vP09fb3+Pn6/8QAHwEA
AwEBAQEBAQEBAQAAAAAAAAECAwQFBgcICQoL/8QAtREAAgECBAQDBAcFBAQAAQJ3AAECAxEEBSEx
BhJBUQdhcRMiMoEIFEKRobHBCSMzUvAVYnLRChYkNOEl8RcYGRomJygpKjU2Nzg5OkNERUZHSElK
U1RVVldYWVpjZGVmZ2hpanN0dXZ3eHl6goOEhYaHiImKkpOUlZaXmJmaoqOkpaanqKmqsrO0tba3
uLm6wsPExcbHyMnK0tPU1dbX2Nna4uPk5ebn6Onq8vP09fb3+Pn6/9oADAMBAAIRAxEAPwD+yf4p
/wDBQz9j/wCC3xO1v4NfEr4uP4f+Jnh22s73V/CcHw9+KfiG8t7O+0LTfEsF3DdeGfBGs6ZfWq6J
q2n311cafe3UNiJzb3r291BcQRcHB/wVX/YMurG01S2+N97caZfq7WOowfCD45y2N6sbFJGtLuP4
Ztb3KxuCjmGRwrAq2CCK/HT9uX9mbwz8bP23f2wPHFr49s/hF8Yfh1p/wMsvh94ytvDOp+J/EfjL
wX4l+EfhRfjF8Pra4i1W30PwnpaeGrDTJr3UdY0fVbrXD4g+xaLLYT6ZdTN+f/7bn7aXxd1T4u/B
K2HwWtf2ivFf7QFvqup20Gs6jZeErfwpB4Rs9P0K+uJLrQ9O0vSWkn0vSrZxH9lt/MaAcPM8kj/k
eV+IefZ34lcQcFZdwtRlknDFTLlmvFEs6wFejSji8vzGvWwssLgKmLq4XO5YxZQsDkeNVDH/ANjz
zPPM3jk2ErcIri7vqYSlSwdHEzrv2ldT5KPs5pvlnBKSc1FSp8rqc1WN4e0UKdN1JKv7D+o9/wDg
ql+wjFPpltJ8a9RjuNaeaPRrd/g78dUn1aS3UvcJpkTfDISX7wIC8y2qytEoLOFAzXzb4b/4LZ/s
zfF/9vb9mT9hn9mOGf49X/xjt/jhc/Gn4jWtv8Svh/afs5J8M/hde/EXwEL3Q/Gfwis9K+JD/Fa8
0PxN4Y8vRvG+gy+B7nREvNXTUptW0zS5/wCW39pX9sj9pv4FeGYfgz8EfGmnQD9s1/C+keGfABu/
CkMHwI1f4Qaw/jO11KPVtTsbnVZw+tSXd5Gi3+nR3coSO8F9bpFAvnP/AAQ3+KngLwF/wV8/ZP8A
gP8AC7UovEureONT/aG1P4z/ABTkjMOo/EHVIP2afjX4vl8MT2UheO1tPCvi/Shd215ZFBeeXg5h
baf7w+jF9H7iDxZ8PPpEeKvHWAy7JuF/CDgzjavw3hsBxHRliM+4jy/h7Os2ybN8xf1dVMuyGjhK
vDUcvweJ+qZtxJxx/bHDeEy+tw5lNXiPMfx7jjxIpZDxdwdwFw3ga3EHFHEWOynGZxQSlQwXDHB9
TM6WFzTPM1xfLVjSq1IUcxw+SYKMZ1s1xlKCpulh8PmmKyz94v249Y/aff8AbV/bE+G37P8Ae33w
x8L/ABQsvgVefFj463Vr4b13wtpVl8LPhH4T8ReGvAd9oGqafc6/BqmvS+INcFlq/hrUNKUpetb6
1/aNrFbwQ/I2n2Gl6Z4P+H1/8QNIi8do2natdaHdxSxaPL4YsLN5ZNZm+3PtYpcLHLcGNJVyvyAM
a/av/go1/wAEn/HX7Y/jjw58R/2d/wBq4fse+MLxtcf416ndfCHxB8e7b4wsmh+BPDXw8aPRL/47
/C/QfAB8BaL4U1iymOg6Zef8JYPEkdxq3kXeixz6h+aX7Vf/AAS6/bH+HP7Ofw8/Z20f4d+Lv+Cn
mmeLrfxRD8RfFvwq174I/sRa58Nf+Efn8NzeGQ5+LP7RF7da9H47/trxEix+FNVvF0ZfCVwuueWu
t6UJP4s4Z4MxWScXcd8VYzOJ5jLi3E5PDAYCVKpKGSZTk2ErRo4KlisZiMZi3GtmWPzXHzwWFrYP
I8NVxdTE4HKMLmWOzrH5p+uVsRGrQwtCNNQ9gqjlK6vUnUkrycYqMdIQhFSkpVWoqMqkoRpxh/Kn
/wAFXP2bPB/x7+Iv7NfxG/Yl1PVfGevftB+I/FHh3RrbStZ1GJRqvhO1eG+tdPN3PDDayQ3Ecsc0
kBjE205Zgc19l/8ABFH9j/4g/srf8FYf+CWlv8cfBl94N+OeueMf2v4fFFve36Xclz4dH7Ffx+u/
D8jLBLLbgyIHl3hzIxyX5r9UPhl/wbWftM/Fj4dfs8+NpP2ob/8A4J9X3wk1XxzrHgn9lfxT8DvA
/wC0/wCKvhHf3nifX9DS71347fDr9qnRPCfj1/Gvhyx0fxtBFpNpH/wj0fiFNA1CaXVtMv8AH6F/
sif8EGfj18Af24P2bf2yfjN/wUYs/wBomP8AZyvPipfaX8OYv2TB8MLnxDP8Tfgr8Qfg4/m+Om/a
R+IUumR6LB46/t2ONvC2qLe/2V/Za/Yft39o2f6lQ4o4yy3A1uHMlzt5XwjnccRV4xyqhVzaFbiT
FYWWDfDccSqOaUsolgslbzmr7PE5TisVWrZnGVLF4eFCVOrwPC4SdX6zUoRni4RjChWcaV6VO83U
ipOm6r524tJVFGPK3ytybP/Z

--=====================_22317741==_.REL--


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g41HIxN20409 for ietf-pkix-bks; Wed, 1 May 2002 10:18:59 -0700 (PDT)
Received: from vulcan.rsasecurity.com (vulcan.rsasecurity.com [204.167.114.130]) by above.proper.com (8.11.6/8.11.3) with SMTP id g41HIqa20403 for <[e-mail]>; Wed, 1 May 2002 10:18:53 -0700 (PDT)
Received: from sdtihq24.securitydynamics.com by vulcan.rsasecurity.com via smtpd (for mail.imc.org [208.184.76.43]) with SMTP; 1 May 2002 17:17:28 UT
Received: from ebola.securitydynamics.com (ebola.securid.com [192.80.211.4]) by sdtihq24.securid.com (Pro-8.9.3/Pro-8.9.3) with ESMTP id NAA06308 for <[e-mail]>; Wed, 1 May 2002 13:17:12 -0400 (EDT)
Received: from exna00.securitydynamics.com (localhost [127.0.0.1]) by ebola.securitydynamics.com (8.10.2+Sun/8.9.1) with ESMTP id g41HIx022330 for <[e-mail]>; Wed, 1 May 2002 13:18:59 -0400 (EDT)
Received: by exna00.securitydynamics.com with Internet Mail Service (5.5.2653.19) id <HKX1Z9R1>; Wed, 1 May 2002 13:16:23 -0400
Received: from HOUSLEY-LAP.rsasecurity.com (HOUSLEY-LAP [10.3.16.38]) by exna00.securitydynamics.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id HKX1Z9RC; Wed, 1 May 2002 13:16:20 -0400
From: "Housley, Russ" <[e-mail]>
To: Denis Pinkas <[e-mail]>
Cc: pkix <[e-mail]>
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Version 5.1
Date: Wed, 01 May 2002 13:17:55 -0400
Subject: Re: I-D ACTION:draft-ietf-pkix-warranty-extn-00.txt
In-Reply-To: <[e-mail]>
References: <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Denis:

It seems to me that the warranty in this case does have to do with the 
relationship between the CA and the subscriber.  If a replying party is 
harmed, they will go after the CA (assuming that the subscriber has 
vanished or is a less attractive target).  The CA will likely have 
insurance to back up the warranty, and this extension indication the terms 
of that warranty.

Russ

At 02:59 PM 4/30/2002 +0200, Denis Pinkas wrote:

>Comments on the Warranty certificate extension
>
>Before looking at the technical details of the warranty, it is important to
>make sure that practical cases can be solved. Since a warranty is mentioned,
>legal considerations cannot be left aside.
>
>The current proposal states that "the certificate warranty provides an
>extended monetary coverage for the legal liability of the CA, in favor of
>the *subscriber*".
>
>The problem is that the warranty should also apply in favor of one or more
>*relying parties*. Are the relaying parties going to complain to the
>subscriber only and will then the subscriber makes arrangement with the CA
>only ?
>
>For the extreme cases where there are, let us say, 10.000 plaintiffs each
>one claiming for a damage of 1.000 $ and when the upper limit of the
>warranty will be altogether, for example, 100.000 $ (called "aggregated
>damage" in the draft). What would be the criteria to reimburse the
>plaintiffs ? Since the total damage is 10.000.000 $, are only 10 % of the
>first plaintiffs to be reimbursed ? or will a random choice will be done
>among the 10.000 plaintiffs ? Since the warranty is for the subscriber and
>not for the plaintiffs, will the subscriber deal with the 10.000 plaintiffs
>directly ?
>
>The second point is that no conditions to get advantage of the warranty are
>mentioned. Should a relying party only check the revocation status of the
>certificate ? Should the relying party check the certificate against a
>validation policy ? What kind of proof of its checking should the relying
>party present to the CA;  or to the subscriber ? An OSCP response? A DPV
>response ? Should the details of the transaction involved be provided ?
>
>For all these reasons, the difficulty of use of such an extension is very
>questionable.
>
>Now, it should be noticed that such a similar extension has already been
>defined in ETSI TS 101 862. This extension takes advantage of the
>qcStatement defined in RFC 3039 and specifies a statement regarding limits
>on the value of transactions.
>
>This optional statement contains:
>
>- an identifier of this statement (represented by an OID);
>- a monetary value expressing the limit on the value of transactions.
>
>This statement is a statement by the issuer which impose a limitation on the
>value of transaction for which this certificate can be used to the specified
>amount (MonetaryValue), according to the Directive 1999/93/EC of the
>European Parliament and of the Council of 13 December 1999 on a Community
>framework for electronic signatures, as implemented in the law of the
>country specified in the issuer field of this certificate.
>
>In fact the Directive is requiring (in Annex I) a field to specify "limits
>on the value of transactions for which the certificate can be used, if
>applicable". The reason for that field is specified in the Directive in
>these terms:
>
>"The certification-service-provider shall not be liable for damage arising
>from use of a qualified certificate which exceeds the limitations placed on
>it".
>
>The text does *not* say: "The certification-service-provider *shall be*
>liable for damage arising from use of a qualified certificate which *meets*
>the limitations placed on it".
>
>So it is more a *disclaimer of warranty* rather than a warranty. If the
>proposal was for a warranty disclaimer extension, then it would be more
>appropriate. In such a case it would not be necessary to indicate the
>conditions to meet to get the warranty since there would be no warranty.
>
>It is doubtful that an off-line indication in a certificate will be the
>right answer to a problem that is commonly solved using an on-line protocol
>(e.g. money withdrawal on an ATM).
>
>Denis
>
>
> > 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           : Warranty Certificate Extension
> >         Author(s)       : D. Linsenbardt, S. Pontius
> >         Filename        : draft-ietf-pkix-warranty-extn-00.txt
> >         Pages           : 7
> >         Date            : 18-Apr-02
> >
> > This document describes a certificate extension to explicitly state
> > the warranty offered by a Certificate Authority (CA) for a the
> > certificate containing the extension.
> >
> > A URL for this Internet-Draft is:
> > http://www.ietf.org/internet-drafts/draft-ietf-pkix-warranty-extn-00.txt


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g41GxhW19726 for ietf-pkix-bks; Wed, 1 May 2002 09:59:43 -0700 (PDT)
Received: from stingray.missi.ncsc.mil (stingray.missi.ncsc.mil [144.51.50.20]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g41Gxea19722 for <[e-mail]>; Wed, 1 May 2002 09:59:40 -0700 (PDT)
Received: from stingray.missi.ncsc.mil (root@localhost) by stingray.missi.ncsc.mil with ESMTP id g41Gv7m25897; Wed, 1 May 2002 12:57:07 -0400 (EDT)
Message-ID: <[e-mail]>
Date: Wed, 01 May 2002 10:20:04 -0400
From: "David P. Kemp" <[e-mail]>
X-Mailer: Mozilla 4.77 [en] (X11; U; SunOS 5.7 sun4u)
X-Accept-Language: en
MIME-Version: 1.0
To: "Housley, Russ" <[e-mail]>
CC: [e-mail], [e-mail], [e-mail]
Subject: Re: Meaning of Non-repudiation
References: <[e-mail]> <[e-mail]> <[e-mail]>
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------msDFE0EF8834D95ECD5F5AE4E6"
X-H-S-Loop-Check-Ejzfr: 
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

This is a cryptographically signed message in MIME format.

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

"Housley, Russ" wrote:
> >Tony,
> >
> >I think the PKIX list discussion ended with the observation that there
> >might be more benefit to the NR bit in the other direction, i.e., when it
> >is NOT asserted. In that case the interpretation is that the CA is
> >signalling that the cert was not issued for use in transactions requiring
> >NR. Thus one would normally set the NR bit to 0 in certs to be used for
> >signing authentication data exchanges, vs. binding documents, etc.  When
> >the bit is asserted, it is best viewed as a necessary, but not sufficient,
> >condition for NR.
> >
> >Steve
> 
> Son-of-2459 says:
> 
>        Further distinctions between the digitalSignature and
>        nonRepudiation bits may be provided in specific certificate
>        policies.
> 
> This allows the CA to state what additional meaning is associated with the
> nonRepudiation bit.
> 
> Russ


Russ,

Steve has it (almost) right, and Son-of-2459 has it wrong.
Son-of-2459 should provide *all* the distinction that is needed between
key
usage bit 0 and bit 1:  If bit 1 is not set, then cryptographic
applications
are expected to not generate and not validate a signature on any
document.

The only thing NR=0 should say about a signature is:  "If the hash of
this
authentication exchange happens to equal the hash of the full text of
Romeo and Juliet, it must be a pure coincidence.  The signature
using this cert's key is valid only for non-documents."

The only thing NR=1 should say is: "This is a signature on a document.",
in a manner entirely analogous to the meaning of crlSign=1:
"This is a signature on a CRL".

* No other information about a CRL, such as its validity or its
  applicability to a specific certificate, is contained in the
  keyUsage extension.
* No other information about a document, such as whether a human
  user saw it or whether it is binding, is contained in the
  key usage extension.

Steve should have omitted the word "binding" before "documents".  It is
a
dangerously confusing red herring.

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

MIIOhgYJKoZIhvcNAQcCoIIOdzCCDnMCAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC
DIkwggQxMIIDmqADAgECAgMDOtQwDQYJKoZIhvcNAQEFBQAwZDELMAkGA1UEBhMCVVMxGDAW
BgNVBAoTD1UuUy4gR292ZXJubWVudDEMMAoGA1UECxMDRG9EMQwwCgYDVQQLEwNQS0kxHzAd
BgNVBAMTFkRPRCBDTEFTUyAzIEVNQUlMIENBLTMwHhcNMDIwNDI1MTQ1ODQyWhcNMDUwNDI1
MTQ1ODQyWjB3MQswCQYDVQQGEwJVUzEYMBYGA1UEChMPVS5TLiBHb3Zlcm5tZW50MQwwCgYD
VQQLEwNEb0QxDDAKBgNVBAsTA1BLSTEQMA4GA1UECxMHTlNBL0NTUzEgMB4GA1UEAxMXS2Vt
cC5EYXZpZC5QLjA1MTQxMDE0MDQwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAOrsDFPo
087+VZ15OuyrJedIwjkRXWrtqRBzEpkk6Ct+Bkn/uiKzLn7AZ5IxbGDnZvjbvmEzPYkA/tm8
ng0IVxNpKEjdw7O1TbNLnwLSDkckcmq8AzW6se/Dm5nZ7l3ggVx8XuYifnr9E163atD9JxjR
nVM1vcPx262lVck4wTXrAgMBAAGjggHcMIIB2DAOBgNVHQ8BAf8EBAMCBsAwHwYDVR0jBBgw
FoAU7BNbvCGMZpsKi38HXyWwFPkQ9ZswHQYDVR0OBBYEFIs+vTwgtAcXc7Wa3lN5TOdFB2v4
MBYGA1UdIAQPMA0wCwYJYIZIAWUCAQsFMCAGA1UdEQQZMBeBFWRwa2VtcEBtaXNzaS5uY3Nj
Lm1pbDCBjwYDVR0SBIGHMIGEhoGBbGRhcDovL2VtYWlsLWRzLTMuYzNwa2kuY2hhbWIuZGlz
YS5taWwvY24lM2RET0QlMjBDTEFTUyUyMDMlMjBFTUFJTCUyMENBLTMlMmNvdSUzZFBLSSUy
Y291JTNkRG9EJTJjbyUzZFUuUy4lMjBHb3Zlcm5tZW50JTJjYyUzZFVTMIG5BgNVHR8EgbEw
ga4wgauggaiggaWGgaJsZGFwOi8vZW1haWwtZHMtMy5jM3BraS5jaGFtYi5kaXNhLm1pbC9j
biUzZERPRCUyMENMQVNTJTIwMyUyMEVNQUlMJTIwQ0EtMyUyY291JTNkUEtJJTJjb3UlM2RE
b0QlMmNvJTNkVS5TLiUyMEdvdmVybm1lbnQlMmNjJTNkVVM/Y2VydGlmaWNhdGVyZXZvY2F0
aW9ubGlzdDtiaW5hcnkwDQYJKoZIhvcNAQEFBQADgYEA0kEbsqISaLdMPsBZSuefbL8k2fU2
V6nAVrq890J8s7Sf2vlm+Z9SkRqo+KebaeHRCS8Pg5S8YhxRHz6jmvGV9+CqOBhJp/DsW2Iu
tHXUMy46iPxLQfFT75LIjOAGXk929TSgnqk/3ygIVP6/E+6culxD7hTKh4FFa/Dto/V4T6ww
ggQbMIIDhKADAgECAgETMA0GCSqGSIb3DQEBBQUAMGExCzAJBgNVBAYTAlVTMRgwFgYDVQQK
Ew9VLlMuIEdvdmVybm1lbnQxDDAKBgNVBAsTA0RvRDEMMAoGA1UECxMDUEtJMRwwGgYDVQQD
ExNEb0QgQ0xBU1MgMyBSb290IENBMB4XDTAwMDgxMTE3NDUyOVoXDTA2MDgxMDE3NDUyOVow
ZDELMAkGA1UEBhMCVVMxGDAWBgNVBAoTD1UuUy4gR292ZXJubWVudDEMMAoGA1UECxMDRG9E
MQwwCgYDVQQLEwNQS0kxHzAdBgNVBAMTFkRPRCBDTEFTUyAzIEVNQUlMIENBLTMwgZ8wDQYJ
KoZIhvcNAQEBBQADgY0AMIGJAoGBAO98vchr6/EuN4Vw2h1ovziIBzOml88LKtiNQxMFN07J
V04JFR2kZtuOxlCcvNnL2fXv9lRG4teiwqBldt36ekVY/1LDkW6xDecvHnS4BuJhQPnmMdnu
HF47TwK7O/bxvevAKpKeS1/sw1wuyKJN9Bi7jezH36gY+CdT9VwfP4QJAgMBAAGjggHeMIIB
2jAdBgNVHQ4EFgQU7BNbvCGMZpsKi38HXyWwFPkQ9ZswDgYDVR0PAQH/BAQDAgGGMA8GA1Ud
EwEB/wQFMAMBAf8wDAYDVR0kBAUwA4ABADAfBgNVHSMEGDAWgBRsnKXwXI9tQY3EFzuQV8IP
o81t/jAwBgNVHSAEKTAnMAsGCWCGSAFlAgELBTALBglghkgBZQIBCwkwCwYJYIZIAWUCAQsK
MIGDBgNVHRIEfDB6hnhsZGFwOi8vZHMtMy5jM3BraS5jaGFtYi5kaXNhLm1pbC9jbiUzZERv
RCUyMENMQVNTJTIwMyUyMFJvb3QlMjBDQSUyY291JTNkUEtJJTJjb3UlM2REb0QlMmNvJTNk
VS5TLiUyMEdvdmVybm1lbnQlMmNjJTNkVVMwgbAGA1UdHwSBqDCBpTCBoqCBn6CBnIaBmWxk
YXA6Ly9kcy0zLmMzcGtpLmNoYW1iLmRpc2EubWlsL2NuJTNkRG9EJTIwQ0xBU1MlMjAzJTIw
Um9vdCUyMENBJTJjb3UlM2RQS0klMmNvdSUzZERvRCUyY28lM2RVLlMuJTIwR292ZXJubWVu
dCUyY2MlM2RVUz9jZXJ0aWZpY2F0ZXJldm9jYXRpb25saXN0O2JpbmFyeTANBgkqhkiG9w0B
AQUFAAOBgQAmpY01OHZr/vRBJsgxGUX7diGsCGrzYM1C0fhrJknH4L7Lm61Nt1bSZ4/obHjl
QxBQyDx9ovISBAi//TVUd1UKbdqNW7Inso2enmK9beG9eK5M0ZfEdj3S0UxmJAgRXSgVsnE7
xzP3uZ1/mJx++gSwcpd+/NPBVJNjFJPf8RvL4DCCBDEwggOaoAMCAQICAwM61jANBgkqhkiG
9w0BAQUFADBkMQswCQYDVQQGEwJVUzEYMBYGA1UEChMPVS5TLiBHb3Zlcm5tZW50MQwwCgYD
VQQLEwNEb0QxDDAKBgNVBAsTA1BLSTEfMB0GA1UEAxMWRE9EIENMQVNTIDMgRU1BSUwgQ0Et
MzAeFw0wMjA0MjUxNDU5NDZaFw0wNTA0MjUxNDU5NDZaMHcxCzAJBgNVBAYTAlVTMRgwFgYD
VQQKEw9VLlMuIEdvdmVybm1lbnQxDDAKBgNVBAsTA0RvRDEMMAoGA1UECxMDUEtJMRAwDgYD
VQQLEwdOU0EvQ1NTMSAwHgYDVQQDExdLZW1wLkRhdmlkLlAuMDUxNDEwMTQwNDCBnzANBgkq
hkiG9w0BAQEFAAOBjQAwgYkCgYEApfaxUWfMcxUPKtb9p7FeItF5DkWiDmO8i0uiC0VpUPoz
t+9gx4pUo4lOeqcSGMRfFwv7llBtPte7NqtbDefDW2tIFIzzFrv07VPrq0MNCo6rRK/IGCK/
Zmrf/UOfx8Hzvn6dIF+S9YktXZsFpbtJT49v6+E2nmKLpO7OCtW582kCAwEAAaOCAdwwggHY
MA4GA1UdDwEB/wQEAwIFIDAfBgNVHSMEGDAWgBTsE1u8IYxmmwqLfwdfJbAU+RD1mzAdBgNV
HQ4EFgQUYrtZ7SslM3nXtC47SpLr4YEu02AwFgYDVR0gBA8wDTALBglghkgBZQIBCwUwIAYD
VR0RBBkwF4EVZHBrZW1wQG1pc3NpLm5jc2MubWlsMIGPBgNVHRIEgYcwgYSGgYFsZGFwOi8v
ZW1haWwtZHMtMy5jM3BraS5jaGFtYi5kaXNhLm1pbC9jbiUzZERPRCUyMENMQVNTJTIwMyUy
MEVNQUlMJTIwQ0EtMyUyY291JTNkUEtJJTJjb3UlM2REb0QlMmNvJTNkVS5TLiUyMEdvdmVy
bm1lbnQlMmNjJTNkVVMwgbkGA1UdHwSBsTCBrjCBq6CBqKCBpYaBomxkYXA6Ly9lbWFpbC1k
cy0zLmMzcGtpLmNoYW1iLmRpc2EubWlsL2NuJTNkRE9EJTIwQ0xBU1MlMjAzJTIwRU1BSUwl
MjBDQS0zJTJjb3UlM2RQS0klMmNvdSUzZERvRCUyY28lM2RVLlMuJTIwR292ZXJubWVudCUy
Y2MlM2RVUz9jZXJ0aWZpY2F0ZXJldm9jYXRpb25saXN0O2JpbmFyeTANBgkqhkiG9w0BAQUF
AAOBgQDIzhLKkB3qMsN45svSI+hEJN0hjuhiz7hGNFOUco1YnyoyfwvShlJHrl85ptr9mt/L
hMuLunqBCS2tfTKTLWAK9RjR20MRI7evK0qu/OxpxfMI9TFPwHPXSOINrgILbIVvuwOkIYcm
IBcfD2OReXE7+WcRoZDUjZGD4X+80lIm4jGCAcUwggHBAgEBMGswZDELMAkGA1UEBhMCVVMx
GDAWBgNVBAoTD1UuUy4gR292ZXJubWVudDEMMAoGA1UECxMDRG9EMQwwCgYDVQQLEwNQS0kx
HzAdBgNVBAMTFkRPRCBDTEFTUyAzIEVNQUlMIENBLTMCAwM61DAJBgUrDgMCGgUAoIGxMBgG
CSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTAyMDUwMTE0MjAwNFow
IwYJKoZIhvcNAQkEMRYEFBZk/cl30vS9wpPyck1yRDs3NqX1MFIGCSqGSIb3DQEJDzFFMEMw
CgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgFAMA0G
CCqGSIb3DQMCAgEoMA0GCSqGSIb3DQEBAQUABIGAD14hgjrg8aDDbDDHoVVA7H3onIBhTP4Z
damzn5Wo9HoxMlY9ShvB9HMixDHkUrmUF2YCEKev3M1HRLsbGHJMr3FBzNkQRrB8VLC38vCs
deX7XmD+YFVdFxr1o3xFAkAiDlUasRWPsd/4lSzdhSin8B/UrgnyTVfFjPLwpABRyog=
--------------msDFE0EF8834D95ECD5F5AE4E6--



Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g41FsAV17839 for ietf-pkix-bks; Wed, 1 May 2002 08:54:10 -0700 (PDT)
Received: from wfhqex05.gfgsi.com (netva01.getronicsgov.com [67.105.229.98]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g41FsAa17835 for <[e-mail]>; Wed, 1 May 2002 08:54:10 -0700 (PDT)
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Subject: Free Public Key Enabled Application Test Suite Available (Update)
X-MimeOLE: Produced By Microsoft Exchange V6.0.4712.0
Date: Wed, 1 May 2002 11:54:04 -0400
Message-ID: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: Free Public Key Enabled Application Test Suite Available
Thread-Index: AcHGBdt5sgloz+TERK6zyu+4LLFDxQrIBeaA
From: "Pawling, John" <[e-mail]>
To: "ietf-pkix@imc. org (E-mail)" <[e-mail]>
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id g41FsAa17836
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

All,

This message is a reminder of the availability of free and openly
available test resources to facilitate vendor development of secure,
interoperable Public Key Enabled applications (see enclosed message from
Dave Fillingham).

Also, Getronics Government Solutions has posted the open source,
freeware Bridge Certification Authority (BCA) Interoperability Test
Suite (BITS) test data generation tool on the "DoD BCA Technology
Demonstration Site" web site <http://bcatest.atl.getronicsgov.com/>.
Anybody can use the test data generation freeware without paying
royalties or licensing fees.  This enables others to use the tool to
generate the equivalent BITS test data or to customize the test data
(such as including different distinguished names).

Please let us know if we can provide further information.

===========================================
John Pawling, [e-mail]
Getronics Government Solutions, LLC
===========================================



-----Original Message-----
From: Fillingham, David W. [mailto:[e-mail]]
Sent: Thursday, February 28, 2002 9:19 AM
To: PKIX (E-mail)
Subject: Free Public Key Enabled Application Test Suite Available


This message announces the availability of free and openly available
test
resources to facilitate vendor development of secure, interoperable
Public
Key Enabled applications.  The US Department of Defense recently
completed
the Bridge Certification Authority (BCA) Technology Demonstration Phase
II.

The BCA Interoperability Test Suite (BITS) is now available from:

http://bcatest.atl.getronicsgov.com. 

It provides a standard set of test data that can be used to determine a
product's degree of interoperability (including error conditions) with
the
BCA Technology Demonstration Phase II architecture including: 

*   discovery and validation of X.509 certification paths in a
cross-certified Public Key Infrastructure (PKI) environment; 

* relying party processing of Certificate Policies and Certificate
Policy
Mapping extensions to accept or reject X.509 certification paths based
on
assurance level in a policy-heterogeneous PKI;

* relying party processing of Name Constraints extensions to limit
transitive trust of X.509 certification paths;

* certificate revocation using Certificate Revocation Lists (CRL);

* demonstration of cryptographic algorithm agility within X.509
certification paths; and

* transfer of signed and encrypted S/MIME messages between applications
constructing X.509 certification paths that include the BCA.

The BITS includes X.509 Certificates, CRLs, and CrossCertificatePairs
that
are equivalent to those created by the products for the BCA
Demonstration
Phase II. This test data is available via the Lightweight Directory
Access
Protocol (LDAP) from: 

ldap://bcatest.atl.getronicsgov.com

This single LDAP directory includes a directory information tree
equivalent
to that hosted on the directory servers used for the BCA Demonstration
Phase
II. This directory can be used to test a product's ability to use LDAP
to
retrieve the data required to build and validate X.509 certification
paths
composed of certificates from multiple PKIs.

The X.509 Certificates, CRLs, CrossCertificatePairs, S/MIME messages,
and
Public-Key Cryptography Standard (PKCS) #12 files (containing test
private
keys required to process the test S/MIME messages) are available in a
zip
file from: 

http://bcatest.atl.getronicsgov.com/. 

The initial BITS goal is to support the testing of S/MIME applications,
but
it is designed to serve as a general X.509 certification path discovery
and
validation test suite that can be used to test any PKI-enabled
application.

The "BCA Interoperability Test Description" documents the BITS test
cases,
procedures, and data. The BITS exercises all of the BCA Demonstration
Phase
II features except for attribute certificates, rule-based access
control,
and border directory concept. Getronics will assist vendors with
executing
BITS tests, answering technical questions, and providing troubleshooting
hints. 


Getronics used the open source, freeware Certificate Management Library
and
S/MIME Freeware Library (both available from:

http://www.getronicsgov.com/hot/sec_libraries.htm 

to successfully validate the BITS test data.


The BCA Demonstration Phase II final report is available from:

http://www.anassoc.com/BCA.html

It describes the BCA concepts, PKI architecture, cross-certification
relationships, test cases, and test results for the demonstration.


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g41CHig11011 for ietf-pkix-bks; Wed, 1 May 2002 05:17:44 -0700 (PDT)
Received: from vulcan.rsasecurity.com (vulcan.rsasecurity.com [204.167.114.130]) by above.proper.com (8.11.6/8.11.3) with SMTP id g41CHga11007 for <[e-mail]>; Wed, 1 May 2002 05:17:42 -0700 (PDT)
Received: from sdtihq24.securitydynamics.com by vulcan.rsasecurity.com via smtpd (for mail.imc.org [208.184.76.43]) with SMTP; 1 May 2002 12:16:17 UT
Received: from ebola.securitydynamics.com (ebola.securid.com [192.80.211.4]) by sdtihq24.securid.com (Pro-8.9.3/Pro-8.9.3) with ESMTP id IAA07445 for <[e-mail]>; Wed, 1 May 2002 08:16:01 -0400 (EDT)
Received: from exna00.securitydynamics.com (localhost [127.0.0.1]) by ebola.securitydynamics.com (8.10.2+Sun/8.9.1) with ESMTP id g41CHl217233 for <[e-mail]>; Wed, 1 May 2002 08:17:47 -0400 (EDT)
Received: by exna00.securitydynamics.com with Internet Mail Service (5.5.2653.19) id <HKX1ZZL5>; Wed, 1 May 2002 08:15:12 -0400
Received: from HOUSLEY-LAP.rsasecurity.com (HOUSLEY-LAP [10.3.16.93]) by exna00.securitydynamics.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id HKX1ZZLV; Wed, 1 May 2002 08:14:57 -0400
From: "Housley, Russ" <[e-mail]>
To: Peter Sylvester <[e-mail]>
Cc: [e-mail]
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Version 5.1
Date: Wed, 01 May 2002 08:16:38 -0400
Subject: Re: Open issue: requester identifier in DPV response
In-Reply-To: <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Peter:

> > > - This text may be created by the server or requested by the client
> > >   or modified by the server.
> >
> > No. See above.
>
>Thus, you are restricting a potential protocol feature. If a proposal
>will allow a client to propose a text, you would consider this
>as in conflict with the requirements doc?
>
> >
> > > I am not in favour that the usages of identififers of the clients
> > > and responders MUST be related to authentication.
> >
> >  ... otherwise it is a field that has an undefined or an ambiguous
> > semantics.
>Russ and you have proposed that the ID are derived from authenticated
>identifiers, it seems that the main difference is that I prefer that
>they are matched against information from authentication.
>
>You propose:
>   "When the request is authenticated, the requestor SHOULD be able, upon
>   request, to indicate an identifier to be included in the response.
>
>What does mean 'SHOULD be able'?  We are talking about requirements for
>a protocol. Either the protocol has a feature that can be optionally be
>used or it hasn't.

It means that a protocol that conforms to these requirements SHOULD include 
this feature.  It still conforms if it does not include this feature.  In 
other words, I do not think that a protocol that does not include this 
feature is unsuitable.

>Why should even an anonymous requester not be allowed to specify an 
>identifier?
>As indicated in the followng sentence, a server can always refuse this
>nased on the policy etc.
>
>   How this identifier is matched with the authenticated identity depends
>   on local server conditions and/or the validation policy. The server
>   MAY choose to refuse to include an identifier in the response, or MAY
>   refuse to create a response."

Doesn't the nonce fulfill this need?

Russ