Comments on draft-hernandez-ardieta-smime-eesp-00
1. The topic of the document is interesting. However, the overall ASN.1 syntax
that is proposed is too complicated. It should be simplified.
2. On page 6, the text states:
?This document defines but does not mandate the form of the ext-SP
Specification?.
The point is well taken, however the structure of the document should be
changed
to follow this statement: the document should first describe the new signed
attributes
able to identify the extended signature policy and have a second part which
describes the ASN.1 format.
It would be nice to support both CAdES and XAdES signatures, so two new signed
attributes
would need to be defined: one for XAdES and another one for CAdES.
The XAdES format has currently limitations: a XAdES signature contains one and
only one
signature that can be countersigned. A CAdES signature is more flexible: it may
contain
parallel signatures; where each of them can be countersigned.
There is some work being done in ESTI TC ESI to allow supporting XAdES parallel
signatures.
3. Since XAdES support IODs as URNs and OIDs as URIs, the syntax being
developed should be able
to accommodate both. Change ExtSignPolicyId accordingly.
4. On page 7, the syntax includes:
extSignPolicyProtection ExtSignPolicyProtection OPTIONAL
I do not believe that this field is needed. It is unnecessary to sign such
structures.
If you really would like it to be signed, a simple cryptographic checksum would
be
insufficient, since you don?t know which key or certificate to use to verify
it.
A CAdES signature would be fine but too complicated (and not necessary).
Delete extSignPolicyProtection.
5. The signingPeriod is mandatory. For more flexibility, it would be better to
make it OPTIONAL.
6. The major part is contained in section 3.3.1. Three types of signatures are
identified.
ETSI TC ESI currently only considers two types: parallel and embedded.
I wonder whether sequential signatures make sense. How such signatures would
look like,
when you look at the bit string level ?
I would guess that you would need a new signed attribute. This would complicate
the basic format
of a CAdES signature or a XAdES signature. Unless you have strong arguments on
this point,
sequential signatures should be discarded.
7. The tree graph is too complicated. Avoid recursive methods.
The CAdES format is simple: n parallel signatures each of them can be
countersigned any number of times.
There needs to be n parallel signatures (called PS in the draft) and for each
primary signature (PS)
from 1 to n tell how many numbers of countersignatures are needed.
Note that countersignatures are necessarily made in sequence. I do not think
the figure is appropriate
when CS1 and CS2 are represented on the same line.
The current description for TreesOfSolutions is too complicated.
?identifier? and ?signer? are not understandable. Please try to adopt a simpler
structure.
8. For the timingAndSequence the draft states: ?The time frame during which a
signature must be generated?.
SigningPeriod is defined as:
SigningPeriod ::= SEQUENCE {
notBefore GeneralizedTime,
notAfter GeneralizedTime OPTIONAL }
This does not make sense: it is impossible to use an absolute time.
It is only possible to say, e.g. that the second signature *should* be done
within x hours
after the first one and that the first countersignature *should* be done within
y hours.
It is only an indication of the speed of the workflow, no more. Note that
*shall* is not used.
This is more or less the idea behind relativeTimingAndSequence. It is however
debatable whether
this level of complexity is really needed. I would suppress it for making the
structure simpler.
9. The concept of signing role as defined in section 3.5 is inappropriate. This
should be replaced
by the notions of claimed role and/or certified role where the identity of the
signer is not important,
but its functional role is fundamental.
10. Section 5 should be placed before the ASN.1 description of the ext-SP.
11. Another section should come after dedicated to ?Integration in XAdES
formats?.
12. A minor editing: on page 5, the text states:
?The Signer is the entity that creates one or more electronic signatures
represented
in the ext-SP content. The signer MUST digitally sign over a signature policy
identifier and
an extended signature policy identifier.?
The sentences should be reworded as follows:
?A Signer is an entity that creates one or more electronic signatures
represented in the ext-SP content.
Every signer MUST digitally sign using signature policy identifier and an
extended signature policy identifier.?
13. One typo: on page 4: Frenquently
Denis
PS. I copy this mail to the ETSI TC ESI list.
---------
De : smime-bounces
À : smime
Date : 2011-01-06, 20:04:34
Sujet : [smime] Fwd: I-D Action:draft-hernandez-ardieta-smime-eesp-00.txt
Pièce(s) Jointe(s) au message original :
(1). draft-hernandez-ardieta-smime-eesp-00.txt
(2). Attached Message Part
Some on this mailing list might find this of interest. It's headed for
experimental.
The authors have asked for comments.
spt
-------- Original Message --------
Subject: I-D Action:draft-hernandez-ardieta-smime-eesp-00.txt
Date: Thu, 23 Dec 2010 10:00:02 -0800
From: Internet-Drafts(_at_)ietf(_dot_)org
Reply-To: internet-drafts(_at_)ietf(_dot_)org
To: i-d-announce(_at_)ietf(_dot_)org
A New Internet-Draft is available from the on-line Internet-Drafts
directories.
Title : Extended Electronic Signature Policies
Author(s) : J. Hernandez-Ardieta
Filename : draft-hernandez-ardieta-smime-eesp-00.txt
Pages : 21
Date : 2010-12-23
This document defines extended electronic signature policies (ext-SP)
that extend the boundaries of the electronic signature policy defined in
[RFC3125] in a manner that the relationships and dependences among
multiple electronic signatures generated within the scope of the same
electronic transaction can be established. A given legal/contractual
context may recognize a particular ext-SP as meeting its requirements.
An ext-SP has a globally unique reference, which is bound to an
electronic signature by the signer as part of the signature calculation.
The ext-SP can be defined in human readable form so that it can be
assessed to meet the requirements of the legal and contractual context
in which it is being applied.
To allow for the automatic processing, the ext-SP specifies, using a
computer processable form, the timing and sequence dependencies of the
set of signatures that must be generated to make the transaction
effective along with the set of attributes and rules that each signature
must comply with. In the current document the format of the ext-SP is
defined using ASN.1.
The content of this document is based on the requirements and needs
established in ETSI TR 102 045 V1.1.1 (2003-03) Copyright (C).
Individual copies of this ETSI deliverable can be downloaded from
http://www.etsi.org.
Discussion
This draft is being discussed on the 'ietf-smime' mailing list. To
subscribe, send a message to smime-request(_at_)ietf(_dot_)org with the
single word subscribe in the body of the message. There is a Web site
for the mailing list at https://www.ietf.org/mailman/listinfo/smime.
A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-hernandez-ardieta-smime-eesp-00.txt
Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.
_____________________ next part ______________________
_______________________________________________
smime mailing list
smime(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/smime
_______________________________________________
smime mailing list
smime(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/smime