Subject: [pkix] FW: An errata of RFC 3161 (RE: [ESI] Update of RFC 3161 - Time St amping)

From: "Pope, Nick" <[email-masked]>
Date: Fri, 4 Sep 2009 05:02:17 +0100

Forwarding mail on RFC 3161 errata that needs to be taken into account in
RFC 3161 update.

Nick

-----Original Message-----
From: esi : etsi tc esi (electronic signatures and infrastructures)
[mailto:[email-masked]] On Behalf Of Kenji Urushima
Sent: 27 August 2009 09:39
To: [email-masked]
Subject: An errata of RFC 3161 (RE: [ESI] Update of RFC 3161 - Time
Stamping)

Dear Stefan and Nick,

Some years ago, I found an editrial errata in RFC 3161.
Is it possible to include this errata in your draft ?

=== 
 <http://www.ietf.org/rfc/rfc3161.txt> http://www.ietf.org/rfc/rfc3161.txt

3.4. Time-Stamp Protocol via HTTP

Original Text
--------------
   Upon receiving a valid request, the server MUST respond with either a
   valid response with content type application/timestamp-response or
   with an HTTP error.

Corrected Text
--------------
   Upon receiving a valid request, the server MUST respond with either a
   valid response with content type application/timestamp-reply or
   with an HTTP error.

Notes
-----
"application/timestamp-reply" are used in the rest parts of RFC 3161.
Furthermore, I think most of existing implementations are using 
"application/timestamp-reply" such like Thales time stampiing server,
IAIK library or implementations by Japanese vendors.

With best regards,

Kenji

-----

Kenji Urushima ( <mailto:[email-masked]>
[email-masked]), Entrust Japan

  _____  

From: esi : etsi tc esi (electronic signatures and infrastructures)
[mailto:[email-masked]] On Behalf Of Stefan Santesson
Sent: Wednesday, August 26, 2009 8:16 PM
To: [email-masked]
Subject: [ESI] Update of RFC 3161 - Time Stamping

I have together with Nick Pope submitted a new draft to the IETF pkix group
for updating RFC 3161.

http://tools.ietf.org/html/draft-ietf-pkix-rfc3161-update-01
<http://tools.ietf.org/html/draft-ietf-pkix-rfc3161-update-01> 

This draft is limited in scope to allow ESSCertIDv2 for signatures on
time-stamp tokens.
This draft was submitted since the workgroup rejected the proposal to make a
complete revision of RFC 3161 which would include substantial  change of
terminology.

/Stefan 

  _____  

Mail archive for ESI can be browsed at the following url:

http://list.etsi.org/ESI.html <http://list.etsi.org/ESI.html> 

  _____  

  _____  

Mail archive for ESI can be browsed at the following url:

http://list.etsi.org/ESI.html <http://list.etsi.org/ESI.html> 

  _____  

Consider the environment before printing this mail.
"Thales e-Security Limited is incorporated in England and Wales with company
registration number 2518805. Its registered office is located at 2 Dashwood
Lang Road, The Bourne Business Park, Addlestone, Nr. Weybridge, Surrey KT15
2NX.
The information contained in this e-mail is confidential. It may also be
privileged. It is only intended for the stated addressee(s) and access to it
by any other person is unauthorised. If you are not an addressee or the
intended addressee, you must not disclose, copy, circulate or in any other
way use or rely on the information contained in this e-mail. Such
unauthorised use may be unlawful. If you have received this e-mail in error
please delete it (and all copies) from your system, please also inform us
immediately on +44 (0)1844 201800 or email [email-masked].
Commercial matters detailed or referred to in this e-mail are subject to a
written contract signed for and on behalf of Thales e-Security Limited".

---

From: Peter Sylvester <[email-masked]>
Date: Fri, 04 Sep 2009 09:10:44 +0200

Pope, Nick wrote:
>
> Forwarding mail on RFC 3161 errata that needs to be taken into account 
> in RFC 3161 update.
>
If errata are taken into account, the update might get difficult.
There are several others (like the bad wording for encodings).

One would nedd two big chapters: One for the ESS "update" and
one for "corrections" ==>

Somewhere there should be a reminder that application/tsp-response
is still used. and may be tolerated.

In fact, and this goes beyond an update: What is missing is
a complete small http profile telling the minimal requirements
of a client, What errors can be received, redirections, text, etc.
I don't remember in which similar http-based protocol there
is similar text.

---

From: Stefan Santesson <[email-masked]>
Date: Fri, 04 Sep 2009 10:51:05 +0200

I agree,

General maintenance such as incorporating errata and updating reverences
etc, might be valuable abut is an entirely different task than making an
update that explicitly adds the use of ESSCertIDv2.

If there is a general agreement that we need a new revision of RFC 3161,
then we would have to do that in a separate work, which then would include
the ESSCertIDv2 updates handled by the current draft.

/Stefan 

On 09-09-04 9:10 AM, "Peter Sylvester" <[email-masked]> wrote:

> _______________________________________________
> pkix mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/pkix