RE: Requirements comments

Hi Sébastien,

Thanks for the comments, and apologies for the delay responding.

-----Original Message-----
From: spouliot@motus.com [mailto:spouliot@motus.com]
Sent: Thursday, January 17, 2002 8:47 AM
To: www-xkms@w3.org
Subject: Requirements comments


Here are my comments...


2.1.12.   "Support for legacy formats such as PKCS#10 and PKCS#7 should be
defined."

     add "but their support MUST be optional".

---
[MJ] Agreed, though I prefer Joseph's suggested wording
(http://lists.w3.org/Archives/Public/www-xkms/2002Jan/0021.html).
---

2.2.3     "Individual elements of XML Key Management protocol messages will
not be encrypted."

     Current implementation encrypt the Private element (containing the
Private key).
     Is this really a requirement or more a wish (i.e. "should not" in
place of "will not") ?

---
[MJ] At the December F2F, it was agreed that we did not want to deal with
specifying how a subset of the elements of a request or response might be
encrypted. The private key element is a special case. It will typically be
doubly encrypted (and I think that is fine). The text should indicate the
special case with the private key.
---

2.3.5.    I assume that this is about registring multiple keys (multiple
usage) for a single user ? As written this could be confused with bulk
registration (2.3.7).

---
[MJ] I think these are different requirements. 2.3.5 talks about registering
multiple keys similar to how a single key is registered in X-KRSS. 2.3.7
talks of a template mode in which the request says little more than "Give me
1000 key pairs".   
---

2.4. Should we split this section between the
     - out of scope for XKMS
     - out of scope for the initial specification of XKMS ?
     Or does everyone agree about which items will never gets into XKMS ?
(i doubt)

---
[MJ] I agree with your doubt. I don't think we know yet and it offers little
advantage to speculate in this document.
---


2.4.7.    "Authorization and Authorization Assertions"

     Must be "Authentication and Authorization Assertions" ?

---
[MJ] I think it might be correct the way that it is. In general, XKMS will
not deal with authorization questions, more specifically with authorization
assertions. XKMS can provide authentication assertions though, e.g. an X.509
certificate. Maybe the text could say, "Authorization issues, including
authorization assertions."
---

2.4.14.   Private key retrieval is out of scope here but a requirement in
3.1.1

---
[MJ] Yes, I think 3.1.1 should be removed.
---

2.4.16    "XML Key Management of symmetric keys."

     The introduction says that "it is a goal of XML key management to
support the key management requirements of XML Encryption". AFAIK XMLEnc
deals with both symmetric as asymmetric keys.
     If this is out of scope for XKMS then the introduction should be
modified to specify "public key management", else (if this is out of scope
for the initial specification of XKMS) we should make the requirements (and
other documents) neutral about the keys.

---
[MJ] The goal is still to support XML Encryption, but at least for the first
release, symmetric keys are not considered. I think you're right though that
we can qualify as you suggest.
---

3.1.1.    Private key retrieval is a requirement but out of scope 2.4.14.


3.4.1.    "Exclusive Canonicalization support is required to..."

     What's the status of the document ? The reference points to an undated
(october 2001) draft ? Is there a conflict between the EC and XKMS schedule
?

---
[MJ] I don't recall this being an issue at the Dec F2F. If you're on the
call today, maybe you can bring it up again.
---

Cheers,
Mike