OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

regrep-security message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]

Subject: RE: [regrep-security] Re: [regrep] RS 1.08 distribution


Thanks for your detailed and helpful comments - these will definitely
add clarity to the document. 

I support making changes corresponding to
1, 2, 5, 12 ,14, 15b along the lines you suggested.

I do not support changes corresponding to 
	9 : the header signature IS signed over the
digests of the payloads as per XMLDSIG. I added this sentence for
	10: I believe the usage scenarios of the KeyInfo are non-normative,
	are helpful, but not prescriptive. 

I agree broadly with comments 3,4,6,7,8,11,13,15a,c, (with mild
disagreements in some cases)
 and my suggestion on the lines to add are inlined below.


-----Original Message-----
From: Sekhar Vajjhala - Sun Microsystems
Sent: Wednesday, November 28, 2001 2:28 PM
To: regrep-security@lists.oasis-open.org
Cc: regrep@lists.oasis-open.org; sekhar.vajjhala@sun.com
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.
I agree. Move it as F.1.

4. lines 3591-3593 

   The word "must" implies a requirement. But the requirements
   are not clear. These two sentences need clarification.

I suggest we replace the two sentences starting with "Registry must
ensure..." by
"The mechanisms described in this section can be used to ensure that any
tampering with the content submitted by a Submitting Organization can be
detected. Furthermore, these mechanisms support identification of the
Responsible Organization for any registry content unambiguously."

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.

I mage the change to add clarity, though I concede you have a point here.
I am fine with this reversal, though I am not sure the value of changing
it only in non-normative sections.

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
    be identified using the Algorithm attribute. While [XMLDSIG] allows
    than on Algorithm attribute, a client must be capable of signing
    only the following Algorithm attribute:


   Note that the above does not mean that a client *MUST* sign using
   just that it must be capable of doing so.

I don't see what we get by saying the client "must be capable" when we are
not insisting on its use for payloads. 
Besides, for signing the header, client must be capable
of signing with dsa-sha1.

I suggest we say
"[XMLDSIG] requires that the algorithm be identified using the Algorithm
attribute. [XMLDSIG] allows more than one Algorithm attribute, and a client
may use any of these attributes. However, signing using the following
Algorithm attribute: http://www.w3.org/2000/09/xmldsig/#dsa-sha1 will allow
interoperability with all XMLDSIG compliant implementations, since XMLDSIG
requires the implementation of this algorithm.
7. line 3681 which reads

   "Must identify the payload to be signed using the URI attribute of
    ds:Reference element."

    The URI needs to be specified more clearly. For e.g. this may be
    the Content-Location, Content-ID etc.

I would like to leave this ambiguity for now, though if you can craft a
which clarifies it, it would be fine too. I am partial to Content-ID.

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.
I agree.
How about we add a sentence
"The identity of the Principal can be identified using the message header

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
            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.
Because XMLDSIG specifies where in KeyInfo X509Certificate would need be,
I suggest rewording it as
    "Therefore, the KeyInfo field must contain a  X509 Certificate as
specified in [XMLDSIG],
    if the KeyInfo field is present."

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
The requirement is that it be encrypted! We may add a sentence saying that
"This specification does not specify how payload encryption is to be done."

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

       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".
I agree. I suggest we add this line it to section 9.2, on 3493, before "Note
that ..."
For the sake of completion, we may leave the section here.

    b. lines 4194-4196 , section "Content Delete/Deprecate - Client

       lines 4195-4196 are incorrect. It reads 
       "The Registry client has to sign the payload (not entire

       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

       The word "has" to be replaced with "must".

    c. lines 4205-4206, section "Content Delete/Deprecate - Registry
       If authorization fails, then generation of an
AuthorizationException is a
       requirement and therefore should be stated in chapter 9.
I am not sure I want to move it at this time. We will deal with it with

To subscribe or unsubscribe from this elist use the subscription
manager: <http://lists.oasis-open.org/ob/adm.pl>

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]

Powered by eList eXpress LLC