Dear Denis,
Thanks for your valuable and prompt comments on the draft. Answers inline.
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.
[JORGE] Agree.
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.
[JORGE] We are interested in this work. Is there any draft we could take a
look at?
3. Since XAdES support IODs as URNs and OIDs as URIs, the syntax being
developed should be able
to accommodate both. Change ExtSignPolicyId accordingly.
[JORGE] Do you mean Information Object Definition (IOD)? OK, we’ll take a
look at that.
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.
[JORGE] Agree. To solve this, we propose to incorporate a hash algorithm and
hash value fields to allow the parties to distinguish between different
policies in an easy manner. A remark indicating that an external protection
mechanism SHOULD be used would be incorporated.
5. The signingPeriod is mandatory. For more flexibility, it would be better
to make it OPTIONAL.
[JORGE] We think that this field is paramount to permit signers to ascertain
whether an extended policy can be used or not, and relying parties to
conclude about the validity of a signature generated according to certain
extended policy. RFC 3125 follows this criterion. What is reasonable is to
change MUST by SHOULD in the field explanation (page 9).
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 ?
[JORGE] Sequential signatures have been defined in several documents,
including ETSI TR 102 045 v1.1.1 (see section 9.2): “Sequential signatures
are of variation parallel signatures, but where the ordering of the
signatures is significant”. As ETSI recognizes, “Parallel and embedded
signatures have been described in previous literature: sequential signatures
are not a well-recognized entity”. However, it does not mean that they are
not important to implement certain business models. In our opinion, there
are many situations where the existence of sequential signatures is
absolutely necessary or more appropriate than the usage of
countersignatures. As defined by ETSI TR, “sequential signatures also may or
may not be applied to the same data content”. In our Draft, however, we do
restrict the data to which sequential signatures can be applied to the same
piece of information.
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.
[JORGE] We don’t think that a new signed attribute is needed. We agree that
it would make current formats and signature processing more complicated. In
our opinion, sequential signatures are a conceptual type of signature, with
no factual difference respecting a parallel signature. That is, looking at
the bit string level, there is no difference. The decision about whether a
signature is (or should be) parallel or sequential stems from the contextual
requirements, and as stipulated in the extended policy.
7. The tree graph is too complicated. Avoid recursive methods.
[JORGE] We do not see how a tree of signatures without a predefined
structure in terms of breadth, depth, nodes at each level, etc. could be
defined in the extended policy without using a recursive method. Please take
into account that this draft should permit to instantiate any potential tree
of signatures according to the specific business needs. Some people may need
to specify just two parallel signatures while others may need a complex tree
of, say, three levels of depth and several signatures at each level.
Suggestions are welcomed.
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.
[JORGE] Mm, we don’t see your point here. Do you mean that the figure is
confusing respecting CS1 and CS2? If so, what changes should be made? Please
note that we intended to represent two countersignatures generated over the
same signature (PS2). The order in which both countersignatures are
generated are not (or we did not intended to) represented in the figure.
The current description for TreesOfSolutions is too complicated.
“identifier” and “signer” are not understandable. Please try to adopt a
simpler structure.
[JORGE] Agree. We’ll try to accommodate the descriptions.
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.
[JORGE] You are right Denis. Defining an absolute time would imply having a
priori the knowledge about when the signatures are going to be generated.
This is a limitation we found out after publishing our work. Assuming that
this constraint may be interesting in certain scenarios, we came up with a
solution that consists of dynamically instantiating the extended policy
before the transaction is going to be carried out. This solution does not
have an impact on the policy definition. However, it has important drawbacks
in terms of performance. As we would like to include this “functionality” in
the extended policy, we would welcome any proposal in this direction.
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.
[JORGE] We strongly believe that the benefits are worth the added
complexity. In our opinion, reducing the complexity of the structure would
lead to a dangerously limited policy.
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.
[JORGE] We borrowed the definition from ETSI TR 102 045 v1.1.1 (section
9.4.1), though we also agree that this section does not provide much
information to the document. We will delete this section.
10. Section 5 should be placed before the ASN.1 description of the ext-SP.
[JORGE] Agree.
11. Another section should come after dedicated to “Integration in XAdES
formats”.
[JORGE] Agree, though we are interested to know if it is common to make
references to XML-based issues in RFCs, which are usually purely ASN.1
based.
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.”
[JORGE] OK.
13. One typo: on page 4: Frenquently
[JORGE] OK.
Denis
PS. I copy this mail to the ETSI TC ESI list.
2011/1/20 Denis Pinkas <denis(_dot_)pinkas(_at_)bull(_dot_)net>
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
<+Internet-Drafts(_at_)ietf(_dot_)org>
Reply-To: internet-drafts(_at_)ietf(_dot_)org
<+internet-drafts(_at_)ietf(_dot_)org>
To: i-d-announce(_at_)ietf(_dot_)org <+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<+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 <+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