[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: [regrep-security] Re: [regrep] RS 1.08 distribution
Here are my comments on the security section. Comments on RS_v1.08.pdf document Here are my comments on Version 1.08 of the spec. They are all related to the security sections of the document. The lines numbers refer to line numbers in the RS_v1.08 document. Suresh, some (but not all) of the issues that I have listed here are with respect to the edits that you have made to the document. I have marked your name next to those issues - so you can locate them easily. 1. line 343 reads "Note that the same entity may take on multiple roles." The word "role" should be avoided here. The reason is that this section is talking about security. In the context of security, "role" has specific meaning. I think the above statement should be restated as: "Note that the same entity may represent different actors." 2. lines 358-364. Section numbers for conformance are incorrect. There is no section 5.4.1 and 5.4.2. These probably should be 5.5.1 and 5.5.2 respectively. 3. section 9.1 "Security Concerns" Much of this section should be moved out of the main document into an appendix. Reason: a lot of it is futures and has not relevant to the current version of the V2.0 document. Suggestion: move lines 3542 - 3583 to an appendix. Keep: 3584-3588 and minor edits to referece the appendix. 4. lines 3591-3593 The word "must" implies a requirement. But the requirements are not clear. These two sentences need clarification. 5. Use of the term "public key" instead of "validation key" [ Suresh, this is your edit ] Throughout the Security Chapter 9, in your latest edit, you repalced the term "validation key" with "public key". I specifically chose the term "validation key" instead of "public key" for non normative sections of the document. Only when a requirement needed to be stated, I chose the term public key. I chose to do this so as not to give the idea that public key/certificate based was the only method of signing being considered - although this is the most common scenario. ( it is difficult to do non repudiation and authentication with shared secret key). One can look at the XMLDSIG spec and see how most of the spec uses terms such as "key for verification" instead of "public key". I would like to change the term "public key" back to "validation key" as it was before for the non-normative parts of the document. 6. lines 3673-3675 reads [ Suresh, this is your edit ] "The signing algorithm can be any valid algorithm permitted in [XMLDSIG], though we suggest using the following Algorithm attribute while signing of interoperability:" I would like to change the above similar to what is stated for the header signature (lines 3769-3772) i.e. "ds:SignatureMethod must be present. [XMLDSIG] requires that the algorithm be identified using the Algorithm attribute. While [XMLDSIG] allows more than on Algorithm attribute, a client must be capable of signing using only the following Algorithm attribute: http://www.w3.org/2000/09/xmldsig/#dsa-sha1. Note that the above does not mean that a client *MUST* sign using DSA-SHA1 just that it must be capable of doing so. 7. line 3681 which reads "Must identify the payload to be signed using the URI attribute of the ds:Reference element." The URI needs to be specified more clearly. For e.g. this may be the Content-Location, Content-ID etc. 8. lines 3711-3717 The word "must" is used in at least two places but the requirements are not clear. Issue is how exactly must the registry authenticate the identity of the principal associated with client requests on a per message basis. I think in V2.0 we have said that this would be based on the header signature ( ignoring the replay attacks which we have already recognized that we don't handle). The requirements for how the registry authenticates the client need to be specified clearly. 9. line 3723-3724 The sentence "Note that the signature within the message header also signs the digests of the payloads." should be deleted. I am not sure where this came from. Reason: The digest of the payloads are signed by the payload signature not the message header signature. 10. line 3838 [ Suresh, I think this is your edit. ] Along with the scenarios on the use of KeyInfo field ( which presumably were moved to Appendix F.8), normative text has been deleted from the version I gave prior to Thanksgiving. Both the normative text and the non normative examples need to be moved back from the Appendix. 11. line 3830 [ Suresh, I think this is your edit ] The sentence "Therefore, the KeyInfo field must contain a X509 Certificate, if the KeyInfo field is present." has been added in lie of 10. This is not normative enough. The specification in 10. was more normative. It specified the exact sub element within the ds:KeyInfo element. 12. line 3843. There is a reference to [SEC] document. It was this document that contained dangling references and looked very much like work in progress. In particular, there used to be reference to S/MIME for payload signatures which are no longer required. Thus reference to this document needs to be removed. 13. line 3843. the word "must" implies encryption requirements. If reference to [SEC] is removed, then what are the encryption requirements. 14. lines 3874-3876 need to be arranged as shown The Registry must implement the default AccessControlPolicy and associate it with all the Objects in the Registry. The following list summarizes the default role-based AccessControlPolicy: <bullet items> 15. Appendix F, "Security Implementation Guideline" A few items in this section appear to be normative and really are more requirements. These should be moved back to the main document rather than being in the appendix. a. line 4184 in section "Content Submisssion - Client Responsibility" The sentence, "The Registry Client has to sign the contents before submission - otherwise the content will be rejected." The above should be moved back to chapter 9. The word "has" should be replaced by "must". b. lines 4194-4196 , section "Content Delete/Deprecate - Client Responsibility" lines 4195-4196 are incorrect. It reads "The Registry client has to sign the payload (not entire message)..." It should read "The Registry client has to sign the header (not the payload) ....." - assuming the content delete contains a SOAP header but no SOAP attachments. The word "has" to be replaced with "must". c. lines 4205-4206, section "Content Delete/Deprecate - Registry Responsibility" If authorization fails, then generation of an AuthorizationException is a requirement and therefore should be stated in chapter 9. Sekhar
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC