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

From: "Larry Masinter" <[email-masked]>
Date: Tue, 28 Jun 2005 00:09:35 -0700

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"

---

From: "Santosh Chokhani" <[email-masked]>
Date: Wed, 29 Jun 2005 22:04:51 -0400

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: [email-masked] [mailto:[email-masked]]
On Behalf Of Larry Masinter
Sent: Tuesday, June 28, 2005 3:10 AM
To: [email-masked]
Subject: Comments on CRL issuance after certificate revocation in
draft-ietf-ltans-notareqs-02

There was a comment on 

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"

From: "Santosh Chokhani" <[email-masked]>
To: <[email-masked]>
Subject: RE: Comments on CRL issuance after certificate revocation in draft-ietf-ltans-notareqs-02
Date: Wed, 29 Jun 2005 22:04:51 -0400
Importance: Normal
Sender: [email-masked]

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: [email-masked] [mailto:[email-masked]]
On Behalf Of Larry Masinter
Sent: Tuesday, June 28, 2005 3:10 AM
To: [email-masked]
Subject: Comments on CRL issuance after certificate revocation in
draft-ietf-ltans-notareqs-02

There was a comment on 

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"

From: "Larry Masinter" <[email-masked]>
To: <[email-masked]>
Subject: Comments on CRL issuance after certificate revocation in draft-ietf-ltans-notareqs-02
Date: Tue, 28 Jun 2005 00:09:35 -0700
Sender: [email-masked]

There was a comment on 

The comment was:

To: [email-masked]
Cc: [email-masked]
From: [email-masked]
Subject: I-D ACTION:draft-ietf-ltans-notareqs-02.txt 
Date: Tue, 21 Jun 2005 15:50:02 -0400
Sender: [email-masked]

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the 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 
[email-masked] 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:
	[email-masked].
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="[email-masked]"

Content-Type: text/plain
Content-ID:	<[email-masked]>

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:	<[email-masked]>

--OtherAccess--

--NextPart--

From: Richard Hansberger <[email-masked]>
To: "[email-masked]'" <[email-masked]>
Subject: RE: New version of 'notareqs' ('Data Certification and Validation ')
Date: Mon, 20 Jun 2005 12:05:16 -0800
Sender: [email-masked]

----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:[email-masked]] 
Sent: Monday, June 20, 2005 8:26 AM
To: [email-masked]
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--

Date: Mon, 20 Jun 2005 09:25:38 -0700
From: Larry Masinter <[email-masked]>
Subject: New version of 'notareqs' ('Data Certification and Validation')
To: [email-masked]
Sender: [email-masked]

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