Hello Carl, sorry for the late answer. Carl Wallace schrieb:
Here are a few comments on DSSC. I'll send an off list email with some editorial comments.- In section 4.1, the fifth element in the sequence should be named SuitableAlgorithm to be consistent with the schema in Appendix B
- The draft should provide some guidance regarding constraints. For example, should one define key size constraints per public key algorithm or per each signature algorithm? For policy brevity, the former would be better. Perhaps an alternative would be to bind constraints and validity periods within SuitableAlgorithm.
I would also prefer the definition of constraints per public key algorithm.
- Section 5 should include processing for constraints.
- The spec should prohibit including multiple instances of the same algorithm identifier w/ the same constraints.
- If an ASN.1 version is to be produced, using an enveloping signature would make the mapping to CMS easier.
OK. An ASN.1 version should come with the next version of the draft.
- The assumption in Section 3.2 that one must find an old policy in order to determine if an algorithm was valid at a point in the past is too complicated. Suitability definitions should accumulate in a single policy definition. An enterprise could maintain several policies. For example, one complete, one current and one past policy could be maintained.In our notion, the policies are published by specific institutions (e.g. annually) and one policy represents the evaluations based on current knowledge (e.g. on current findings, RSA with 1024 bit key length could be valid until end of 2007, but next year a new policy could be published which states that RSA 1024 is valid until end of 2008). To expect, that a policy also contains all past evaluations of an algorithms could be error-prone. In our opinion, the question, if the evaluation of an algorithm in an old policy is different from that in the current policy is primarily important in law cases. And there you cannot trust, that the current policy correctly quotes past evaluations, instead you will have to look in the old policy.
Best regards, Thomas
Description: S/MIME Cryptographic Signature