Re: [regrep] RS 1.08 distribution

[Sekhar Vajjhala - Sun Microsystems <sekhar.vajjhala@sun.com>]

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