Subject: RE: I-D ACTION:draft-ietf-pkix-lightweight-ocsp-profile-01.txt

From: "Santosh Chokhani" <[email-masked]>
Date: Mon, 1 Nov 2004 16:28:35 -0500

Ryan,

This sounds fine.

If the purpose is to give the hint as to when check back, I suggest
renaming.

-----Original Message-----
From: Ryan Hurst [mailto:[email-masked]] 
Sent: Monday, November 01, 2004 4:18 PM
To: Santosh Chokhani; [email-masked]
Subject: RE: I-D ACTION:draft-ietf-pkix-lightweight-ocsp-profile-01.txt

No problem, as for the nextPublish extension I was noodling on what I could
do to make the text more clear, what if we say:

     Support for this extension is optional. This extension indicates the
     earliest time at which the server will be issuing new information about
     the status of the certificate. If present it can be used by the relying
     party to determine when it is acceptable to begin attempts for new 
     revocation information.  
 
     The time specified in the nextPublish extension SHOULD be before 
     the time specified in the nextUpdate field. 

So if nextUpdate indicates "The time at or before which newer information
will be available about the status of the certificate" then nextPublish
indicates "The time at or after newer information will be available about
the status of the certificate". Having both ends of the timeline allows for
the client to make intelligent decisions related to how to update its local
cache.

I am not apposed to re-naming the extension but am more concerned about the
description being clear. Does this new text alleviate your concerns?

Ryan

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
On Behalf Of Santosh Chokhani
Sent: Monday, November 01, 2004 10:26 AM
To: [email-masked]
Subject: RE: I-D ACTION:draft-ietf-pkix-lightweight-ocsp-profile-01.txt

Ryan,

Thanks.

I had some further thought on the nextPublish extension.  If this is purely
a hint for the client when to poll back and it does not further reduce the
revocation replay window, some other neutral name such as suggestedPollBack
may be more appropriate.

If this field can be used by the client to reduce the replay window, that
should be explained in terms of how to use this time in addition to polling
back.

-----Original Message-----
From: Ryan Hurst [mailto:[email-masked]] 
Sent: Monday, November 01, 2004 1:15 PM
To: Santosh Chokhani; [email-masked]
Cc: Deacon, Alex
Subject: RE: I-D ACTION:draft-ietf-pkix-lightweight-ocsp-profile-01.txt

Santosh - Thanks for your comments we will address these in the next
revision of the document...

Ryan

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
On Behalf Of Santosh Chokhani
Sent: Saturday, October 30, 2004 6:09 PM
To: [email-masked]
Subject: RE: I-D ACTION:draft-ietf-pkix-lightweight-ocsp-profile-01.txt

Alex,

I have a small number of comments on the revised draft.

1.  Section 1.2.2, There does not appear to be security benefit to the
Responder certificate validity period covering the response window.
Actually, this could cause deadlocks.  This requirement should be deleted.
May be the requirement should be for the responder to send its latest
certificate which contains the appropriate verification public key and whose
notBefore is at or before the current time.

2. Section 5.1, typo, replace "who's signature has" with "whose signature
has been"

3.  Section 5.1, type replace i.e. 48 hours with e.g., 48 hours.

4.  Appendix A, It is not clear how this extension differs from nextUpdate.
Is this something like "when new responses will be produced"?  Some further
clarification is required. 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
On
Behalf Of [email-masked]
Sent: Thursday, October 28, 2004 11:06 AM
To: [email-masked]
Cc: [email-masked]
Subject: I-D ACTION:draft-ietf-pkix-lightweight-ocsp-profile-01.txt

A New Internet-Draft is available from the on-line Internet-Drafts
directories. This draft is a work item of the Public-Key Infrastructure
(X.509) Working Group of the IETF.

	Title		: Lightweight OCSP Profile  for High Volume
Environments
	Author(s)	: A. Deacon,  R. Hurst
	Filename	:
draft-ietf-pkix-lightweight-ocsp-profile-01.txt
	Pages		: 21
	Date		: 2004-10-27
	
This specification defines a profile of the Online Certificate
   Status Protocol (OCSP) that addresses the scalability issues
   inherent when using OCSP in large scale (high volume) PKI
   environments and/or PKI environments that require a lightweight
   solution to minimize bandwidth and client side processing.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-pkix-lightweight-ocsp-pro
file
-01.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-pkix-lightweight-ocsp-profile-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:
	[email-masked].
In the body type:
	"FILE
/internet-drafts/draft-ietf-pkix-lightweight-ocsp-profile-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.

---

From: "Ryan Hurst" <[email-masked]>
Date: Mon, 1 Nov 2004 13:18:19 -0800

No problem, as for the nextPublish extension I was noodling on what I
could do to make the text more clear, what if we say:

     Support for this extension is optional. This extension indicates
the
     earliest time at which the server will be issuing new information
about
     the status of the certificate. If present it can be used by the
relying
     party to determine when it is acceptable to begin attempts for new 
     revocation information.  

So if nextUpdate indicates "The time at or before which newer
information will be available about the status of the certificate" then
nextPublish indicates "The time at or after newer information will be
available about the status of the certificate". Having both ends of the
timeline allows for the client to make intelligent decisions related to
how to update its local cache.

I am not apposed to re-naming the extension but am more concerned about
the description being clear. Does this new text alleviate your concerns?

Ryan

-----Original Message-----

Ryan,

Thanks.

I had some further thought on the nextPublish extension.  If this is
purely
a hint for the client when to poll back and it does not further reduce
the
revocation replay window, some other neutral name such as
suggestedPollBack
may be more appropriate.

If this field can be used by the client to reduce the replay window,
that
should be explained in terms of how to use this time in addition to
polling
back.

-----Original Message-----
From: Ryan Hurst [mailto:[email-masked]] 
Sent: Monday, November 01, 2004 1:15 PM
To: Santosh Chokhani; [email-masked]
Cc: Deacon, Alex
Subject: RE: I-D ACTION:draft-ietf-pkix-lightweight-ocsp-profile-01.txt

Ryan

-----Original Message-----

Alex,

1.  Section 1.2.2, There does not appear to be security benefit to the
Responder certificate validity period covering the response window.
Actually, this could cause deadlocks.  This requirement should be
deleted.
May be the requirement should be for the responder to send its latest
certificate which contains the appropriate verification public key and
whose
notBefore is at or before the current time.

2. Section 5.1, typo, replace "who's signature has" with "whose
signature
has been"

4.  Appendix A, It is not clear how this extension differs from
nextUpdate.
Is this something like "when new responses will be produced"?  Some
further
clarification is required. 

-----Original Message-----

	

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-pkix-lightweight-ocsp-profile-01.txt".

Send a message to:
	[email-masked].
In the body type:
	"FILE
	
	a MIME-compliant mail reader.  Different MIME-compliant mail
readers