RE: Comments on CRL issuance after certificate revocation in draft-ietf-ltans-notareqs-02

["Santosh Chokhani" <[e-mail]>]

Larry,

Section 4.2 deals with the issue of repudiability when the certificate is
revoked and relying party does not have the current information.

But, that is not the only repudiation.  Practically, the private key holder
might come to know of the compromise after T5 and hence the certificate
might be legitimately revoked after T5.

I think the requirement should be validation of signature at a point in time
as opposed to saying that it is not repudiable.

In addition or alternatively, we could define a policy that if a transaction
is signed at time t1, then we need a CRL with thisUpdate > t1 to verify the
signature and we hold the verification until that CRL is available.  The
transaction may need two time stamps: one for t1 and one for when the
verification is done after the CRL is received.  Then you get in the debate
of is the newer CRL for signer certificate is sufficient or do we need newer
CRL for all certificates in the path.  I would think the CRL for signer
certificate is sufficient. 

If some one needs to repudiate a signature due to revocation coming to the
signer's attention later, we may need additional requirements or say that
the signer's needs to take some proactive action to retract what may have
been signed in his/her name.

-----Original Message-----
From: [e-mail] [mailto:[e-mail]]
On Behalf Of Larry Masinter
Sent: Tuesday, June 28, 2005 3:10 AM
To: [e-mail]
Subject: Comments on CRL issuance after certificate revocation in
draft-ietf-ltans-notareqs-02



We were sent some comments on the -02 draft, I thought
I should forward the substantive comment for mailing
list discussion:

There was a comment on 
   The problem with CRLs is that they might not be synchronized with
   revocation mechanisms and there is no real information whether a
   signature is valid or not at specific point in time. In theory CRLs
   should be issued immediately after a certificate is revoked.

The comment was:

This is not advisable, because this "on the spot" CRL issuance paves the way
to man in the middle / replay attacks.

An attacker could store a CRL issued before implementing a, say, 
private key compromise attack. After the attack the attacker could 
intercept CRL retrieval requests issued before the CRL nextUpdate  time and
send back the requester the previous CRL, where the revoked 
certificate is not listed. If the nextUpdate time has not yet expired 
the relying parties would trust the CRL they receive, without having 
a means to realise it is the old one. If instead CRLs are issued only 
at nextUpdate time, or just slightly before, RPs would be aware they 
should wait until the so called "grace period" expires. CAs could 
take no responsibility on verifications based on CRLs issued before 
the "grace period". By grace period it is intended the time necessary 
for a revocation request to be processed by the revocation management 
service to make it available to relying parties. If such request is 
submitted to the revocation service too close to the next CRL issuance 
time to be included in it, then the revocation will be published in 
the subsequent CRL. Please see CWA 14171 section 5.3 for details
(http://www.uninfo.polito.it/WS_Esign/doc/cwa14171.pdf or 
ftp://ftp.cenorm.be/PUBLIC/CWAs/e-Europe/eSign/cwa14172-01-2004-Mar.pdf).




(There were a couple of editorial comments, e.g., "When speed is not of
essence" should probably be "When speed is not of the essence"





Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j5U250vh072469; Wed, 29 Jun 2005 19:05:00 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j5U250A8072468; Wed, 29 Jun 2005 19:05:00 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from host15.websitesource.com (host15.websitesource.com [209.239.32.38]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j5U24xYe072446 for <[e-mail]>; Wed, 29 Jun 2005 19:04:59 -0700 (PDT) (envelope-from [e-mail])
Received: from wchokhani3 (pcp09271453pcs.arlngt01.va.comcast.net [69.143.129.49]) by host15.websitesource.com (8.12.10/8.12.10) with ESMTP id j5U24ut2009621 for <[e-mail]>; Wed, 29 Jun 2005 22:04:58 -0400
From: "Santosh Chokhani" <[e-mail]>
To: <[e-mail]>
Subject: RE: Comments on CRL issuance after certificate revocation in draft-ietf-ltans-notareqs-02
Date: Wed, 29 Jun 2005 22:04:51 -0400
Message-ID: <003301c57d18$1d4ba130$[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.6626
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180
Importance: Normal
In-Reply-To: <[e-mail]>
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id j5U24xYe072459
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-ltans/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-ltans.imc.org>

Larry,

Section 4.2 deals with the issue of repudiability when the certificate is
revoked and relying party does not have the current information.

But, that is not the only repudiation.  Practically, the private key holder
might come to know of the compromise after T5 and hence the certificate
might be legitimately revoked after T5.

I think the requirement should be validation of signature at a point in time
as opposed to saying that it is not repudiable.

In addition or alternatively, we could define a policy that if a transaction
is signed at time t1, then we need a CRL with thisUpdate > t1 to verify the
signature and we hold the verification until that CRL is available.  The
transaction may need two time stamps: one for t1 and one for when the
verification is done after the CRL is received.  Then you get in the debate
of is the newer CRL for signer certificate is sufficient or do we need newer
CRL for all certificates in the path.  I would think the CRL for signer
certificate is sufficient. 

If some one needs to repudiate a signature due to revocation coming to the
signer's attention later, we may need additional requirements or say that
the signer's needs to take some proactive action to retract what may have
been signed in his/her name.

-----Original Message-----
From: [e-mail] [mailto:[e-mail]]
On Behalf Of Larry Masinter
Sent: Tuesday, June 28, 2005 3:10 AM
To: [e-mail]
Subject: Comments on CRL issuance after certificate revocation in
draft-ietf-ltans-notareqs-02



We were sent some comments on the -02 draft, I thought
I should forward the substantive comment for mailing
list discussion:

There was a comment on 
   The problem with CRLs is that they might not be synchronized with
   revocation mechanisms and there is no real information whether a
   signature is valid or not at specific point in time. In theory CRLs
   should be issued immediately after a certificate is revoked.

The comment was:

This is not advisable, because this "on the spot" CRL issuance paves the way
to man in the middle / replay attacks.

An attacker could store a CRL issued before implementing a, say, 
private key compromise attack. After the attack the attacker could 
intercept CRL retrieval requests issued before the CRL nextUpdate  time and
send back the requester the previous CRL, where the revoked 
certificate is not listed. If the nextUpdate time has not yet expired 
the relying parties would trust the CRL they receive, without having 
a means to realise it is the old one. If instead CRLs are issued only 
at nextUpdate time, or just slightly before, RPs would be aware they 
should wait until the so called "grace period" expires. CAs could 
take no responsibility on verifications based on CRLs issued before 
the "grace period". By grace period it is intended the time necessary 
for a revocation request to be processed by the revocation management 
service to make it available to relying parties. If such request is 
submitted to the revocation service too close to the next CRL issuance 
time to be included in it, then the revocation will be published in 
the subsequent CRL. Please see CWA 14171 section 5.3 for details
(http://www.uninfo.polito.it/WS_Esign/doc/cwa14171.pdf or 
ftp://ftp.cenorm.be/PUBLIC/CWAs/e-Europe/eSign/cwa14172-01-2004-Mar.pdf).




(There were a couple of editorial comments, e.g., "When speed is not of
essence" should probably be "When speed is not of the essence"





Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j5S79olO076556; Tue, 28 Jun 2005 00:09:50 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j5S79osa076555; Tue, 28 Jun 2005 00:09:50 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from ylpvm43.prodigy.net (ylpvm43-ext.prodigy.net [207.115.57.74]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j5S79n1A076400 for <[e-mail]>; Tue, 28 Jun 2005 00:09:49 -0700 (PDT) (envelope-from [e-mail])
Received: from pimout2-ext.prodigy.net (pimout2-int.prodigy.net [207.115.4.217]) by ylpvm43.prodigy.net (8.12.10 outbound/8.12.10) with ESMTP id j5S79cmn016899 for <[e-mail]>; Tue, 28 Jun 2005 03:09:40 -0400
X-ORBL: [67.125.232.60]
Received: from MasinterT43p (adsl-67-125-232-60.dsl.snfc21.pacbell.net [67.125.232.60]) by pimout2-ext.prodigy.net (8.13.4 outbound domainkey aix/8.13.4) with ESMTP id j5S79aJX208356 for <[e-mail]>; Tue, 28 Jun 2005 03:09:37 -0400
Message-Id: <[e-mail]>
From: "Larry Masinter" <[e-mail]>
To: <[e-mail]>
Subject: Comments on CRL issuance after certificate revocation in draft-ietf-ltans-notareqs-02
Date: Tue, 28 Jun 2005 00:09:35 -0700
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
X-Mailer: Microsoft Office Outlook, Build 11.0.6353
Thread-Index: AcV7sFbV1fIF0HCXTrWFwYM71w4zzw==
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id j5S79o1A076549
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-ltans/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-ltans.imc.org>

We were sent some comments on the -02 draft, I thought
I should forward the substantive comment for mailing
list discussion:

There was a comment on 
   The problem with CRLs is that they might not be synchronized with
   revocation mechanisms and there is no real information whether a
   signature is valid or not at specific point in time. In theory CRLs
   should be issued immediately after a certificate is revoked.

The comment was:

This is not advisable, because this “on the spot” CRL issuance
paves the way to man in the middle / replay attacks.

An attacker could store a CRL issued before implementing a, say, 
private key compromise attack. After the attack the attacker could 
intercept CRL retrieval requests issued before the CRL nextUpdate
 time and send back the requester the previous CRL, where the revoked 
certificate is not listed. If the nextUpdate time has not yet expired 
the relying parties would trust the CRL they receive, without having 
a means to realise it is the old one. If instead CRLs are issued only 
at nextUpdate time, or just slightly before, RPs would be aware they 
should wait until the so called “grace period” expires. CAs could 
take no responsibility on verifications based on CRLs issued before 
the “grace period”. By grace period it is intended the time necessary 
for a revocation request to be processed by the revocation management 
service to make it available to relying parties. If such request is 
submitted to the revocation service too close to the next CRL issuance 
time to be included in it, then the revocation will be published in 
the subsequent CRL. Please see CWA 14171 section 5.3 for details
 (http://www.uninfo.polito.it/WS_Esign/doc/cwa14171.pdf or 
ftp://ftp.cenorm.be/PUBLIC/CWAs/e-Europe/eSign/cwa14172-01-2004-Mar.pdf).




(There were a couple of editorial comments, e.g., "When speed is not of essence"
should probably be "When speed is not of the essence"




Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j5LJo3Hj039940; Tue, 21 Jun 2005 12:50:03 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j5LJo35d039939; Tue, 21 Jun 2005 12:50:03 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from newodin.ietf.org ([132.151.6.50]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j5LJo3mK039929 for <[e-mail]>; Tue, 21 Jun 2005 12:50:03 -0700 (PDT) (envelope-from [e-mail])
Received: from mlee by newodin.ietf.org with local (Exim 4.43) id 1Dkol0-0002b9-Fx; Tue, 21 Jun 2005 15:50:02 -0400
Content-Type: Multipart/Mixed; Boundary="NextPart"
Mime-Version: 1.0
To: [e-mail]
Cc: [e-mail]
From: [e-mail]
Subject: I-D ACTION:draft-ietf-ltans-notareqs-02.txt 
Message-Id: <[e-mail]>
Date: Tue, 21 Jun 2005 15:50:02 -0400
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-ltans/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-ltans.imc.org>

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Long-Term Archive and Notary Services Working Group of the IETF.

	Title		: Requirements for Data Validation and 
                          Certification  Services
	Author(s)	: T. Gondrom, et al.
	Filename	: draft-ietf-ltans-notareqs-02.txt
	Pages		: 11
	Date		: 2005-6-21
	
This document establishes the goals and requirements for protocols
   and data structures for use with services that provide additional
   means for users to ensure and prove the validity of data, especially
   digitally signed data, in a common and reproducible way.  The data
   being validated may correspond to assertions about real-world facts
   or events.  This document establishes the need for components to be
   used in addition to or in conjunction with long-term archive
   services.  It provides some use cases and scenarios, and establishes
   technical requirements for protocols and data structures to support
   them.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-ltans-notareqs-02.txt

To remove yourself from the I-D Announcement list, send a message to 
[e-mail] with the word unsubscribe in the body of the message.  
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce 
to change your subscription settings.


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-ltans-notareqs-02.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-ltans-notareqs-02.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-ltans-notareqs-02.txt

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

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

--OtherAccess--

--NextPart--



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j5KJ7EKp035119; Mon, 20 Jun 2005 12:07:14 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j5KJ7ExZ035118; Mon, 20 Jun 2005 12:07:14 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from MessageInpector.nationalnotary.org (mail.nationalnotary.org [65.115.114.141]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j5KJ774B034824 for <[e-mail]>; Mon, 20 Jun 2005 12:07:11 -0700 (PDT) (envelope-from [e-mail])
Received: from louise2.nationalnotary.org (LOUISE2 [192.168.1.247]) by MessageInpector.nationalnotary.org (Switch-2.2.8/Switch-2.2.4) with ESMTP id X5KK05K100000884 for <[e-mail]>; Mon, 20 Jun 2005 12:05:20 -0800
Received: by Louise2 with Internet Mail Service (5.5.2657.72) id <M63360NJ>; Mon, 20 Jun 2005 12:05:18 -0800
Message-ID: <561F9357D239EB428AE3A4F1424443130138B868@Louise2>
From: Richard Hansberger <[e-mail]>
To: "'[e-mail]'" <[e-mail]>
Subject: RE: New version of 'notareqs' ('Data Certification and Validation ')
Date: Mon, 20 Jun 2005 12:05:16 -0800
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2657.72)
Content-Type: multipart/mixed; boundary="--123456789-987654321-abcdefg"
X-MessageInspectorSig: b3379824f95f5c7db0f07bdc87e415f0
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-ltans/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-ltans.imc.org>

----123456789-987654321-abcdefg
Content-Type: text/plain

Hello all,

I haven't spoken up on this list for some time, but I think this latest
draft is extremely good and very, very useful. Kudos to all whose hard work
made it possible.

Take care,

Richard J. Hansberger
Director of eNotarization
National Notary Association
818-739-4027

-----Original Message-----
From: Larry Masinter [mailto:[e-mail]] 
Sent: Monday, June 20, 2005 8:26 AM
To: [e-mail]
Subject: New version of 'notareqs' ('Data Certification and Validation')


Just submitted a new version to internet-drafts;
it will appear as

  draft-ietf-ltans-notareqs-02.txt

You may preview at:

  http://larry.masinter.net/ltans-notary-req.txt
  http://larry.masinter.net/ltans-notary-req.html
  http://larry.masinter.net/ltans-notary-req.xml

Larry
-- 
http://larry.masinter.net
----123456789-987654321-abcdefg
Content-Type: text/plain
Content-Disposition: inline

This email message and any files transmitted with it contain confidential information intended only for the person(s) to whom this email message is addressed.  If you have received this email message in error, please notify the sender immediately.

----123456789-987654321-abcdefg--



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j5KGQ6lV071996; Mon, 20 Jun 2005 09:26:06 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j5KGQ6XZ071995; Mon, 20 Jun 2005 09:26:06 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from psmtp.com (exprod6og4.obsmtp.com [64.18.1.124]) by above.proper.com (8.12.11/8.12.9) with SMTP id j5KGQ5i3071954 for <[e-mail]>; Mon, 20 Jun 2005 09:26:05 -0700 (PDT) (envelope-from [e-mail])
Received: from source ([192.150.11.134]) by exprod6ob4.obsmtp.com ([64.18.5.12]) with SMTP; Mon, 20 Jun 2005 09:26:04 PDT
Received: from inner-relay-1.corp.adobe.com ([153.32.1.51]) by outbound-smtp-1.corp.adobe.com (8.12.10/8.12.10) with ESMTP id j5KGJWBM006116 for <[e-mail]>; Mon, 20 Jun 2005 09:19:37 -0700 (PDT)
Received: from calsj-dev (calsj-dev.corp.adobe.com [153.32.1.193]) by inner-relay-1.corp.adobe.com (8.12.10/8.12.10) with ESMTP id j5KGPdn2016603 for <[e-mail]>; Mon, 20 Jun 2005 09:25:49 -0700 (PDT)
Received: from calsj-dev (localhost [127.0.0.1]) by mailsj-v1.corp.adobe.com (iPlanet Messaging Server 5.2 HotFix 2.02 (built Oct 21 2004)) with ESMTP id <[e-mail]> for [e-mail]; Mon, 20 Jun 2005 09:25:39 -0700 (PDT)
Received: from MasinterT40 (c-130-169.corp.adobe.com [153.32.130.169]) by mailsj-v1.corp.adobe.com (iPlanet Messaging Server 5.2 HotFix 2.02 (built Oct 21 2004)) with ESMTP id <[e-mail]> for [e-mail]; Mon, 20 Jun 2005 09:25:38 -0700 (PDT)
Date: Mon, 20 Jun 2005 09:25:38 -0700
From: Larry Masinter <[e-mail]>
Subject: New version of 'notareqs' ('Data Certification and Validation')
To: [e-mail]
Message-id: <[e-mail]>
MIME-version: 1.0
X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2180
X-Mailer: Microsoft Office Outlook, Build 11.0.6353
Content-type: text/plain; charset=us-ascii
Content-transfer-encoding: 7BIT
Thread-index: AcV1tLFvtA8gXA/KQLW05qZVqV/p4g==
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-ltans/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-ltans.imc.org>

Just submitted a new version to internet-drafts;
it will appear as

  draft-ietf-ltans-notareqs-02.txt

You may preview at:

  http://larry.masinter.net/ltans-notary-req.txt
  http://larry.masinter.net/ltans-notary-req.html
  http://larry.masinter.net/ltans-notary-req.xml

Larry
-- 
http://larry.masinter.net