Subject: RE: The time mark can be used as a simple time stamp substitute

From: "Santosh Chokhani" <[email-masked]>
Date: Mon, 9 Oct 2006 10:13:28 -0700

Peter,

What you propose is doable, how ever the trust will be limited by the
trust in the OCSP Responder.  In other words, who can establish trust in
this Responder will be a factor.  Also, the period for which the
Responder key and associated certificate can be trusted will be another
factor.

To illustrate, many implementation trust OCSP Responder as a trust
anchor.  This will limit the time stamp to those.  Also, as a trust
anchor, there will not be a mechanism to tell that the Responder had
been revoked and previous time stamp may not be acceptable.

Another example implementation has been CA-Delegated model with short
certificate life.  For this OCSP Responders, time stamp will parish as
the OCSP Responder certificate expires in days, weeks, or months.

________________________________

From: [email-masked] [mailto:[email-masked]]
On Behalf Of Peter Rybar
Sent: Monday, October 09, 2006 6:45 AM
To: [email-masked]
Subject: The time mark can be used as a simple time stamp substitute 
Importance: High

A time mark can be used as a simple time stamp substitute when we
specify content of OCSP nonce as a hash value of MessageImprint type as
result of some asymmetric operation.

If someone has a demand for retrieval of an approximate time when
asymmetric operation has happened and   he wants that implementation
will not to have an impact on the present solutions to the future, then
I suggest to use the present widely used protocol which already contains
trusted time inside and attribute like nonce which can encapsulate
useful information.  

For example OCSP protocol (RFC2560) contains the attribute "producedAt"
(trusted time at which the OCSP responder signed OCSP response) and some
OCSP can also contain useful extension "nonce". 

In RFC2560 the nonce is defined as:" 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".

As we can see in RFC2560 the value of nonce is not limited and it can
contain anything. If we will describe one alternative of the value of
nonce, in some RFC2560 update, which can contain value of type
MessageImprint which is defined in RFC3161 (Time-Stamp Protocol) then
any result of asymmetric operation (binary string as result of signing
or encryption) where X509 certificate can be used, can be time marked
with OCSP which contains:

1.      validity status of X509 certificate,

2.      HASH from the result of asymmetric operation which is included
in nonce as a MessageImprint type,

3.      Time of the time mark in the attribute producedAt of time before
which the asymmetric operation could happen.

A definition of MessageImprint is from RFC3161 (Time-Stamp Protocol):

MessageImprint ::= SEQUENCE  {

        hashAlgorithm                AlgorithmIdentifier,

        hashedMessage                OCTET STRING  }.  

Proposed solution has not negative impacts on the present implementation
because present implementation will work with nonce as it does today.
New application will test the value of nonce and if it contains ASN.1
structure of MessageImprint type then they will test the Hash value of
asymmetric operation and the hash value in MessageImprint and if they
have identical Hash value, then application can declare that the
asymmetric operation was realized before OCSP.ProducedAt time.

What do you think about this solution?

Is it possible to add such additional information to the OCSP protocol
(RFC2560)?

Can somebody give an advice how to include this solution into RFC
document, in the easiest way?

Best regards

Peter Rybar

[email-masked]

---

From: "Peter Hesse" <[email-masked]>
Date: Mon, 9 Oct 2006 14:20:33 -0400

Peter,
 
There is another issue with your proposal.  The nonce is contained within
the OCSP request and response to protect against replay attacks.  By
replacing the nonce with a known value, such as the messageImprint of the
thing you would like to time stamp, you provide an opening for certain
classes of replay attacks.
 
Using OCSP as a time stamp substitute may be technically possible and may
meet your goal of a third party notarization... If you want to do this in a
standard, extensible, and commonly accepted way, RFC 3161 time stamping is
the way to go.  In my opinion, the cost of a 3161 time stamp server or
service is not high enough to justify the additional development /
customization work that you would need to retrofit OCSP for this purpose.
 
--Peter
 
+----------------------------------------------------------------+
| Peter Hesse                     [email-masked]     |
| Phone: 703-378-5808 x105      Gemini Security Solutions, Inc.  |
| New! Visit our InfoSecurity industry blog: securitymusings.com
<http://www.securitymusings.com/>  |
+----------------------------------------------------------------+
"Security is mostly a superstition. It does not exist in nature...
 Life is either a daring adventure or nothing." --Helen Keller

  _____  

From: [email-masked] [mailto:[email-masked]] On
Behalf Of Santosh Chokhani
Sent: Monday, October 09, 2006 1:13 PM
To: [email-masked]
Subject: RE: The time mark can be used as a simple time stamp substitute 

Peter,

What you propose is doable, how ever the trust will be limited by the trust
in the OCSP Responder.  In other words, who can establish trust in this
Responder will be a factor.  Also, the period for which the Responder key
and associated certificate can be trusted will be another factor.

To illustrate, many implementation trust OCSP Responder as a trust anchor.
This will limit the time stamp to those.  Also, as a trust anchor, there
will not be a mechanism to tell that the Responder had been revoked and
previous time stamp may not be acceptable.

Another example implementation has been CA-Delegated model with short
certificate life.  For this OCSP Responders, time stamp will parish as the
OCSP Responder certificate expires in days, weeks, or months.

  _____  

From: [email-masked] [mailto:[email-masked]] On
Behalf Of Peter Rybar
Sent: Monday, October 09, 2006 6:45 AM
To: [email-masked]
Subject: The time mark can be used as a simple time stamp substitute 
Importance: High

A time mark can be used as a simple time stamp substitute when we specify
content of OCSP nonce as a hash value of MessageImprint type as result of
some asymmetric operation.

If someone has a demand for retrieval of an approximate time when asymmetric
operation has happened and   he wants that implementation will not to have
an impact on the present solutions to the future, then I suggest to use the
present widely used protocol which already contains trusted time inside and
attribute like nonce which can encapsulate useful information.  

In RFC2560 the nonce is defined as:" 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".

As we can see in RFC2560 the value of nonce is not limited and it can
contain anything. If we will describe one alternative of the value of nonce,
in some RFC2560 update, which can contain value of type MessageImprint which
is defined in RFC3161 (Time-Stamp Protocol) then any result of asymmetric
operation (binary string as result of signing or encryption) where X509
certificate can be used, can be time marked with OCSP which contains:

2.      HASH from the result of asymmetric operation which is included in
nonce as a MessageImprint type,

Proposed solution has not negative impacts on the present implementation
because present implementation will work with nonce as it does today. New
application will test the value of nonce and if it contains ASN.1 structure
of MessageImprint type then they will test the Hash value of asymmetric
operation and the hash value in MessageImprint and if they have identical
Hash value, then application can declare that the asymmetric operation was
realized before OCSP.ProducedAt time.

Can somebody give an advice how to include this solution into RFC document,
in the easiest way?

Best regards

Peter Rybar

[email-masked]