[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: RE: [regrep-security] Re: [regrep] RS 1.08 distribution
Sekhar,
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
clarification.
10: I believe the usage scenarios of the KeyInfo are non-normative,
and
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.
Regards,
-Suresh
-----Original Message-----
From: Sekhar Vajjhala - Sun Microsystems
[mailto:sekhar.vajjhala@sun.com]
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.
<sd>
I agree. Move it as F.1.
</sd>
4. lines 3591-3593
The word "must" implies a requirement. But the requirements
are not clear. These two sentences need clarification.
<sd>
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."
</sd>
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.
<sd>
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.
</sd>
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.
<sd>
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
the
ds:Reference element."
The URI needs to be specified more clearly. For e.g. this may be
the Content-Location, Content-ID etc.
<sd>
I would like to leave this ambiguity for now, though if you can craft a
sentence
which clarifies it, it would be fine too. I am partial to Content-ID.
</sd>
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.
<sd>
I agree.
How about we add a sentence
"The identity of the Principal can be identified using the message header
signature."
</sd>
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.
<sd>
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."
</sd>
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.
<sd>
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."
</sd>
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".
<sd>
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.
</sd>
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.
<sd>
I am not sure I want to move it at this time. We will deal with it with
authorization
later
</sd>
Sekhar
----------------------------------------------------------------
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