80 likes | 221 Views
Update on draft-ietf-smime-cades-02. 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)
E N D
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
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)
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)
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.
Proposed comment resolution TP1 In 5.8.1 Comment • In section 5.8.1, I am not clear what the expected behavior of a 3126-conformant 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.”
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.
Next Steps New Internet Draft to be posted after the meeting on the web site incorporating change identified above.