-----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 Pope, Nick
Sent: Wednesday, September 05, 2007 12:24 PM
To: 'Kenji Urushima'; ietf-smime(_at_)imc(_dot_)org
Subject: RE: Comment on draft-ietf-smime-cades-03.txt (RE: WG
LC: draft-ietf-smime-cades-03.txt)
Kenji,
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.
Nick
-----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-
smime-cades-03.txt)
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
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 postmaster(_at_)thales-esecurity(_dot_)com(_dot_)
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".