RE: xkms requirements last call

Hi Al,

 

Much thanks for taking the time to look at our Requirements document [1] and
provide your comments and suggestions.

Responses to each of your comments are included below.  We believe these
issues have been sufficiently resolved.  A current update of the
Requirements document is available [2].

 

-----Original Message-----
From: Alfred Arsenault [mailto:AArsenault@diversinet.com]
Sent: Friday, April 05, 2002 1:37 PM
To: 'stephen.farrell@baltimore.ie'; 'mike.just@entrust.com'
Subject: RE: xkms requirements last call




Mike & Stephen, 

 <...snip...>

Most of these are questions and/or editorial nits, but here goes: 

        (Note: page numbers are what I got when I printed this out in
standard mode.  I realize that this is all hypertext stuff so section
numbers are more important than page numbers, but I'm just trying to help
you locate stuff quicker.)

1. p. 3, definition of 4-Corner Model:  unless this is an
"offically-approved definition" that can't be changed, I'd suggest changing
"where end-entities interact" to "where each end-entity interacts".  It
makes it a little clearer who these 4 entities are (i.e., that there's
(possibly) a different single trusted point of contact for each end-entity
in a communication). 

 

[MJ] This was not an approved definition.  We've made the change.

 

2. p. 4, last sentence before the start of section :  Okay, so if I
understand this correctly, these words will be applied to spec writers
rather than software.  That is, a "SHOULD" means that the spec writers
really should put something in the spec about this, unless they come up with
a really good reason not to. And, a "SHOULD NOT" means that the spec writers
are advised to leave it out of the spec, unless they come up with a really
good reason to put it in.  That seems a little unusual, but I guess it's
okay.  I've made my comments in that vein. 

 

[MJ] This was confusing for others as well.  We've added text to the end of
the first paragraph of Section 1 to indicate the scope of the requirements:
"This specification provides requirements for XML key management consistent
with these goals, including requirements on the XML key management
specification, server implementations and the protocol messages.".  In most,
if not all cases, of requirements on the XML Key Management specification,
we've made these a MUST or MUST NOT.

 

3. pp.5 and 6, sections 2.1 and 2.2:  It seems somewhat inconsistent to say
that the design MUST be transport agnostic (item 5 in section 2.1) and also
say that every trust service MUST support TLS (item 1 in Section 2.2).
Also, I'm not sure why you're treating TLS differently from IPSEC (in item 1
in Section 2.2). There seems to be a mentality that "TLS is a Web service,
and IPSEC is something else."  From a technical security standpoint, I don't
think I necessarily accept that. If I'm missing something, I apologize, but
that just seems inconsistent to me. 

 

[MJ] 2.1.5 is meant to ensure that the design is agnostic.  However, for
reasons of interoperability we are mandating that some security services be
implemented by servers.  The wording of 2.2.1 has changed slightly, but the
intent remains. We have to have some baseline support for interoperability
and TLS and payload security seem to be an acceptable minimum.

 

4.  p. 6, Section 2.2, item 3: The second "sentence" in this item isn't a
sentence.  What's  missing?  Should it say something like "In particular,
the specification MUST define how the use of transport layer security such
as SSL/TLS can be used to protect XML Key Management messages"? 

 

[MJ] Wording has been fixed.

 

5. p. 6, Section 2.2, item 9: This doesn't parse.  If you change "key(s)" to
"key's" it's at least a legal sentence, but I'm still not sure what the
point is.   

 

[MJ] This requirement has been updated, including a change to reflect your
concern above.

 

6.  p. 7, Section 2.3, item 1: change "...services trust server" to
"...services the trust server"  

 

[MJ] This requirement has been changed all together.

 

7. p. 7, Section 2.4, item 4 under [Capabilities]: Will this be a
mandatory-to-implement feature?  Many systems do not allow users to recover
their own private encryption keys; e.g., if it's stored on a smartcard and
the card breaks, the key could be permanently lost.  You just get a new key
and try to recover data the best you can.  I think that, short of mandating
functions for all possible clients, the best you can do is suggest ways that
users can securely make backup copies of keys and recover encrypted data.
I'd suggest changing this item to "The specification MUST address the issue
of users losing access to private encryption keys.  The specification SHOULD
suggest options that could allow for the recovery of encrypted demo (e.g.,
ways to recover private encryption keys) for different types of clients." 

 

[MJ] Wording has been updated to enforce the point that this is a
requirement on the specification and not on implementations.

 

8. p. 8, Section 2.4, item 5: This is really a requirement on the protocol,
not on the specification.  I don't object to it, but it doesn't seem to
really belong here - somebody's just laying a foundation for his/her feature
of choice. 

 

[MJ] The specification must ensure that this option is not precluded. One
way to do this is for the specification to demonstrate how it can be done. 

 

9. p. 8, Section 2.4, item 10: This seems to be saying that "there must be a
version 2 of the XKMS Solution.  It will be defined to include bindings to
the XML protocol once that protocol is defined."  I'd suggest saying that
more clearly. 

 

[MJ] Sections 2.1.4 and 2.1.5 have been updated to reflect the relationship
of XKMS to SOAP.

 

10.  p. 9, section 2.5, item 4: In the last sentence, delete the word
"which".  

 

[MJ] Done. 

 

11. p. 10, section 2.5, item 9: I think you want "SHOULD not" changed to
"SHOULD NOT", to be consistent with your term usage.  Looking back at my
comment 2, above, this is telling the spec writers "don't you dare define
any new authentication mechanisms other than for PoP of keys, unless you
believe that there's a really good reason to do that."  Is that what you
really want? 

 

[MJ] This have been moved to 3.19 (Out of Scope) and generalized to say that
"[d]efining authentication mechanisms" is out of scope.  It's just a means
of limiting the scope of the workgroup.

 

For what they're worth, there they are.  Good luck.  Use these as you see
fit, and please let me know if you need more information or a better
explanation on any of these.

                Al Arsenault  

 

Cheers,
Mike

 

[1]  <http://www.w3.org/TR/xkms2-req> http://www.w3.org/TR/xkms2-req

[2] http://www.w3.org/2001/XKMS/Drafts/xkms-req.html
<http://www.w3.org/2001/XKMS/Drafts/xkms-req.html>