[Top] [All Lists]

RE: Comment on draft-ietf-smime-cades-03.txt (RE: WG LC: draft-ie tf-smime-cades-03.txt)

2007-09-05 09:24:05


Apologies for the delay in responding.  This hit the holiday period.

The editors agree with these comments and a new internet draft should be
available very shortly.  This will also now references RFC 5035 for the v2
certificate reference.


-----Original Message-----
From: Kenji Urushima [mailto:Kenji(_dot_)Urushima(_at_)entrust(_dot_)com]
Sent: 20 August 2007 06:05
To: ietf-smime(_at_)imc(_dot_)org
Subject: Comment on draft-ietf-smime-cades-03.txt (RE: WG LC: draft-ietf-

Hi all,

I have two comments about Internet-Draft of CAdES

This draft refers "ETSI TS 101 733 V.1.6.3"
however currently it quotes from latest
"ETSI TS 101 733 V.1.7.3 CAdES".
(e.x. 6.4.1 Archive time-stamp attribute definition)

So this I-D should refer v1.7.3.

The following describes informative information about
SigningTime, ContentTimeStamp and SignatureTimeStamp comparision.

--- draft-ietf-smime-cades-03.txt [Page 99] ----
C.3.6. Signing time

Using this attribute a signer may sign over a time which is the claimed
signing time.  When an ES with Time-stamp is created (CAdES-T) then
either a trusted time stamp is obtained and added to the ES or a
trusted time mark exists in an audit trail.  When a verifier accepts a
signature, the two times shall be within acceptable limits.
In all cases, the claimed signing time cannot be after  <<< SHOULD BE
the time identified by the time-stamp or time-mark.     <<< SHOULD BE
--- draft-ietf-smime-cades-03.txt [Page 99] ----

--- draft-ietf-smime-cades-03.txt [Page 100] the last paragraph ----
C.3.6. Signing time

Also, the signing time, if present should be between     <<< SHOULD BE
the time indicated by this time-stamp and time indicated <<< SHOULD BE
by the CAdES-T time-stamp.                               <<< SHOULD BE
--- draft-ietf-smime-cades-03.txt [Page 100] ----

I think above two sentenses should be removed.

- Signing time is not trustworthy time which is based on
  local computer time and may gain or lose some seconds or minutes.
  So such comparision is not important if timestamps are used.

- SigningTime attribute is quite common attribute which
  is defined in CMS.
  So adding this attribute in CAdES may easily raise
  interoperability issue.

Best regards,


-----Original Message-----
From: owner-ietf-smime(_at_)mail(_dot_)imc(_dot_)org
[mailto:owner-ietf-smime(_at_)mail(_dot_)imc(_dot_)org] On Behalf Of Turner, 
Sean P.
Sent: Tuesday, August 07, 2007 5:25 AM
To: ietf-smime(_at_)imc(_dot_)org
Subject: WG LC: draft-ietf-smime-cades-03.txt

This message initiates an SMIME Working Group Last Call on the document:

 Title     : CMS Advanced Electronic Signatures (CAdES)
 Author(s) : J. Ross, et al.
 Filename  : draft-ietf-smime-cades-03.txt
 Pages     : 132
 Date      : 2007-8-6

This document obsoletes RFC 3126.

This document defines the format of an electronic signature that can
remain valid over long periods.  This includes evidence as to its
validity even if the signer or verifying party later attempts to deny
(i.e., repudiates the validity of the signature).

The format can be considered as an extension to RFC 3852 [4] and RFC
2634 [5], where, when appropriate additional signed and unsigned
attributes have been defined.

The contents of this Informational RFC amounts to a transposition of the
ETSI TS 101 733 V.1.6.3 (CMS Advanced Electronic Signatures - CAdES)
[TS101733] and is technically equivalent to it.

A URL for this Internet-Draft is:

The purpose of this WG Last Call is to ensure that the Working Group has
achieved consensus that the document is suitable for publication as an
Informational RFC.

Please review the document for both technical and editorial problems.
Technical issues should be discussed on this list. Editorial issues may
be sent to the document editor.

The Last Call period will end on 20 August 2006.

Upon completion of the last call, the WG chairs will take action based
upon the consensus of the WG. Possible actions include:

    1) recommending to the IETF Security Area Directors
       that the document, after possible editorial or
       other minor changes, be considered by the IESG
       for publication as an Informational RFC
       (which generally involves an IETF-wide Last Call); or

    2) requiring that outstanding issues be adequately
       addressed prior to further action (including,
       possibly, another WG Last Call).

Remember that it is our responsibility as Working Group members to
ensure the quality of our documents and of the Internet Standards
process.  So, please read and comment!


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
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 
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". 

<Prev in Thread] Current Thread [Next in Thread>