ietf-smime
[Top] [All Lists]

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

2007-08-19 22:34:41

Hi all,

I have two comments about Internet-Draft of CAdES
(draft-ietf-smime-cades-03.txt).

1) 
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.

2) 
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
REMOVED
the time identified by the time-stamp or time-mark.     <<< SHOULD BE
REMOVED
--- 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
REMOVED
the time indicated by this time-stamp and time indicated <<< SHOULD BE
REMOVED
by the CAdES-T time-stamp.                               <<< SHOULD BE
REMOVED
--- draft-ietf-smime-cades-03.txt [Page 100] ----

I think above two sentenses should be removed.
Since:

- 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,

- Kenji URUSHIMA 

-----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:
http://ietf.org/internet-drafts/draft-ietf-smime-cades-03.txt

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!

spt





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