Update on
draft-ietf-smime-cades-02
1
Current Status
• Completed last call.
• Under review by IESG.
• Comments to be incorporated:
– From Pavel Smirnov (during last call)
• 6.3.5: Hash calculation for CAdES-C timestamp
– From Tim Polk (Security Area Director)
• 5.8.1 Expand on procedures for zero hash of
SigPolicy.
• 6.3.2 Clarify note
2
Proposed Comment resolution PS1
Main Comment – Calculation of hash unclear
(Following email exchange with originator)
6.3.5:Hash calculation for CAdES-C timestamp:
1) Add
"NOTE 1: It is recommended that the attributes being
time-stamped are encoded in DER. If DER is not
employed then the binary encoding of the ASN.1
structures being time-stamped should be preserved to
ensure that the recalculation of the data hash is
consistent.“
(Note also to be added to 6.3.6)
3
Proposed Comment resolution PS2
6.3.5:Hash calculation for CAdES-C
timestamp:
2) Add
"NOTE 2: Each attribute is included in the
hash with the attrType and attrValues
(including type and length) but without the
type and length of the outer SEQUENCE”
(Note also to be added to 6.3.6)
4
Proposed Comment resolution PS3
6.3.5:Hash calculation for CAdES-C
timestamp:
3) No change: Inclusion of type and length or
not is a matter of style and and provided it is
explicit this is not considered to be an issue.
5
Proposed comment resolution TP1
In 5.8.1
Comment
(1) In section 5.8.1, I am not clear what the expected behavior of a 3126conformant client will be if it encounters a sigPolicyHash with a hashValue
of zero. I recognize that it won't crash in the ASN.1 decoding, so that is a
real improvement over the original submission. However, I think the
expected results should be clear so a system generating this value
understands the ramifications of choosing not to include a policy hash
value. I suggest expanding the Note in 5.8.1.
Proposed resolution:
• Add to existing text:
“The hashValue within the sigPolicyHash may be set to zero to indicate that
the policy hash value is not known.
NOTE: The use of zero policy hash value is to ensure backward
compatibility with earlier versions of the current document.”
•
The following:
“If hashValue is zero then the hash value should not be checked against the
calculated hash value of signature policy.”
6
Proposed Resolution TP2
Comment
I do not understand Note 1 in section 6.3.2. I lose the thread when I hit
"as long as the CAs are trusted such that". I think this is an
important note, but it isn't obvious what the point is...
Proposed resolution
Replace:
NOTE 1: The CAdES-X Long provides long term proof of a valid
electronic signature as long as the CAs are trusted such that these
keys cannot be compromised or the cryptographic algorithms that
were initially used are broken.
With:
NOTE 1: The CAdES-X-Long signature provides long term proof of the
validity of the signature for as long as the CA keys, CRL Issuers
keys and OCSP responder keys are not compromised and resist to
cryptographic attacks.
7
Next Steps
New Internet Draft to be posted after the
meeting on the web site incorporating
change identified above.
8