Change paragraphs 4,5,6 appropriately
Insert glyphs for (C), TM
Change ' to ', also at [19] [check whole document]
The NotBefore and NotOnOrAfter attributes are optional. If the NotBefore attribute is omitted the assertion is valid on any date up to but excluding the date specified in the NotOnOrAfter attribute . If the NotOnOrAfter attribute is omitted the assertion is valid from the NotBefore attribute with no expiry. If both elements are omitted the assertion is valid at any time.
The document begins using "assertion" quite a lot, which is not defined. We mean the response, right?
Typo
Super-encrypted should link to the xenc doc for documentation and I don't see any discussion of super-encryption in XKRSS.
Typo / Clarification
Identifier: URN:blahblahblah:w3.org:xkms:payload-I
No mechanism is used to authenticate the client These should be URIs, e.g.,: http://www.w3.org/2002/03/xkms#:payload-II
Typo
Typo in formatting
In Example 5.1.1 when Alice does a registration request I am a bit confused on the nature of the certificate chain that the server sends back. Is it a terminated chain or does it contain an intermediate certificate authority? How does Alice get to choose who the certificate authority is authenticated by? What if she wants to be authenticated by CA Foo instead of CA Bar? Does she get to choose? Should she send a preferred distinguished name of who she wants to be authenticated by? The service might have access to more than one CA.
The data returned is governed by the certification policy of the XKMS Service. In the example it is a rooted trust chain.
Loss of a private key is a serious problem if that means that previously encrypted data is also lost. Loss of a signing key is not a problem
Can someone explain this to me in more detail? The way it reads now it implies that the service sends back a revoked private key (but it is recovered!). What use does it have if it is now revoked?
The fact that a recovery process has been performed may require the key to be revoked as policy. This is quite usual in the case of high security keys since the fact that the recovery process is necessary indicates that there has been some security failure. Also the recovery process itself may involve an actual or potential compromise of the key.
Add in clarification to state that the key is recovered to allow access to previously encrypted data but the end user is now required to register a new key to receive future encrypted data since the recovery process means that the escrow agents have reconstructed the key.
[34] XKMS services MUST support synchronous processing.
In synchronous processing the service returns the final response to the requestor using the same communication channel used to issue the request. What is a channel? Also, this synchronous and asynchronous... For example, HTTP typically doesn't have the concept of a channel, so is the question here whether I send back the response with 5 minutes, or 5 hours?
Add in clarifying text
[53] The following schema defines the <RespondWith> element::
<!-- RespondWith -->
<element name="RespondWith" type="QName"/>
<!-- /RespondWith -->
Is it a string, or a QName? I think they should be QNames (or URIs). To that end, I'm still concerned with the design of the query. We now are not only including identifiers of element types from other namespaces, we are adding are own qualifiers to the query semantic such as and Multiple, PrivateKey, Pending, Represent. At the very least, these should be xkms:Multiple, xkms:PrivateKey, etc.
Add in clarifying text, correct as typo
That is a message sent by A and authenticated by B may be subject to forwarding and authentication by C. In addition some applications may require further measures to ensure that messages meet certain legal standards to prevent repudiation.
I thought for simplicity's sake, there was only one relationship, between the client and service. If the client trusted the service, then it's up to the service to determine who/how it deals with under the specified policy?
(This is something I've remained confused on.)
Why then, does Bob use "KeyValue" as a <RespondWith> value? The example assumes he already has the capability to parse the X.509 certificate to extract the public key. If he has the key already, why does he need the service to give it back to him? He has already performed cryptographic signature verification.
The TBS slots in the protocol document need to be filled in.
Need to pull this from X-Bulk if we fold in X-Bulk
Enter text for both documents (group membership + original authors)
Remove??
What sort of semantics would something like the following have should one omit the StatusValue attribute (as allowed):
<Status> <Reason> IssuerTrust</Reason></Status>
Locate and Validate services are both expected to attempt to provide correct information to the requestor. The Locate and Validate services differ in the extent to which the Trust Service verifies the information returned. A Location service SHOULD attempt to provide only information which is trustworthy to the best of its knowledge. A Validation service undertakes to only return information which has been positively validated by the Trust Service as meeting its validation criteria. "Under a specified policy." (Note, I continue to hold a minority opinion (of one I presume <smile/>) that there's not much of a difference between locate and validate. There's an implicit query (validate requests more elements) and policy, and I prefer such things to be explicit.
Proposal - add in protocol for a multiple request request - i.e. locate 20 keys for different people, register 20,000 keys etc.
Separate out the protocol layer of the schema and roll into the protocol document.
For establishing correspondence of response to a specific request.
Register, Revoke, Reissue and Recover can all return multiple responses, it appears however that multiple responses are not appropriate here,
Remove? will we do finish first? write doc and sneak into the OASIS TC?
Typo
Issue
Typo
Issue
Issue
Clarification
Issue
1. [103] The schema def is missing for KeyBindingAbstractType in the prose
Typo
2. When I first read the description of <KeyUsage> my initial thought
was akin to PKIX keyUsageExtension. I suppose I'm wondering if the three options
provided (Signature,Encryption,Exchange) are going to be augmented to allow
other key usage semantics. Doing this, however, would simply move the complexity
from the underlying PKI back to the message syntax. What argument is there to
keep the three choices that do exist there while leaving others out (for
example, keyCertSign, crlSign)?
Deliberate Design Constraint, there shalt not be a Non-Repudiation bit
The element specifies a cryptographic key usage, not a policy. keyCert, crlSign etc. are policies
Could add a separate optional element to allow communication of X.509 certificate attributes [OID value...]
3. [125] Is the StatusValue attribute on the <Status> element really optional? What sort of semantics would something like the following have should one omit the StatusValue attribute (as allowed):
<Status> <Reason> IssuerTrust</Reason></Status>
Raised as an issue
4. [158] Can someone explain why we must MAC twice for a <RevocationCodeIdentifier>? MACing more than once is useful for meeting a certain size constraint, but I don't see a specific size constraint on the <RevocationCodeIdentifier>.
We MAC twice so that the value H(H(x)) is the RevocationCodeIdentifier, H(x) is the RevocationCode.
This stops pinheads who chose a well used password as their revocation code from coming to grief.
Also beneficial for space reasons and to ensure that character set issues are not problematic
5. [163] I think there is a typo here. All of a sudden an element called KeyInfoQuery is referred to. What is this? Is it supposed to be QueryKeyBinding instead? There is no mention of KeyInfoQuery in the provided schema definition in the prose.
Typo
6. [168] Sort of the same thing as issue #5 above. An element called KeyBindingQuery is suddenly introduced here and it doesn't fit. This should read something like: "A single QueryKeyBinding element that represents a request for the status of a specific key binding." There is also no mention of <KeyBindingQuery> anywhere in the spec. Correct me here if I am wrong please.
Typo
7. In Example 5.1.1 when Alice does a registration request I am a bit confused on the nature of the certificate chain that the server sends back. Is it a terminated chain or does it contain an intermediate certificate authority? How does Alice get to choose who the certificate authority is authenticated by? What if she wants to be authenticated by CA Foo instead of CA Bar? Does she get to choose? Should she send a preferred distinguished name of who she wants to be authenticated by? The service might have access to more than one CA.
Add in clarifying text
8. [186] The last sentence here states: "The request specifies only Encryption and Exchange Key uses as the key is to be escrowed." Can someone explain to me why (by implication) a key cannot be used for digital signature if it is escrowed for recovery?
Add in clarifying text
9. [201]. I don't understand why revoking a key is tied to recovering a key. Can someone explain this to me in more detail? The way it reads now it implies that the service sends back a revoked private key (but it is recovered!). What use does it have if it is now revoked?
Add in clarifying text
10. The example following [201] has a random extra XML document inserted. It looks like an unencrypted private key. Is this a typo?
Typo
http://www.w3.org/2001/XKMS/Drafts/XKMS/xkms-part-1.html
It'd be the nice if the IDs for sections and defined words were human grokkable instead of: id="Auto631643354419997500Z442".
Sorry, this is so not happening, reasons will become apparent.
[34] XKMS services MUST support synchronous processing.
In synchronous processing the service returns the final response to the requestor using the same communication channel used to issue the request. What is a channel? Also, this synchronous and asynchronous... For example, HTTP typically doesn't have the concept of a channel, so is the question here whether I send back the response with 5 minutes, or 5 hours?
Add in clarifying text
[45] The <OpaqueClientData> contains data specified by the client that is opaque to the service. An XKMS service SHOULD return the value of an <OpaqueClientData> element specified in a request unmodified in a response with status code Success.
I must've missed this bit, what's the motivation for this?
We discussed this on the con call, it is required in the async case, people argued that it is useful for the synchronous case. Suggest we do not reopen unless there is someone who really wants to.
[49] The <RespondWith> element in the request specifies one or more strings included in the request that specify data elements to be provided in the <ds:Keyinfo> element of the response.
[53] The following schema defines the <RespondWith> element::
<!-- RespondWith -->
<element name="RespondWith" type="QName"/>
<!-- /RespondWith -->
Is it a string, or a QName? I think they should be QNames (or URIs). To that end, I'm still concerned with the design of the query. We now are not only including identifiers of element types from other namespaces, we are adding are own qualifiers to the query semantic such as and Multiple, PrivateKey, Pending, Represent. At the very least, these should be xkms:Multiple, xkms:PrivateKey, etc.
Add in clarifying text, correct as typo
Locate and Validate services are both expected to attempt to provide correct information to the requestor. The Locate and Validate services differ in the extent to which the Trust Service verifies the information returned. A Location service SHOULD attempt to provide only information which is trustworthy to the best of its knowledge. A Validation service undertakes to only return information which has been positively validated by the Trust Service as meeting its validation criteria. "Under a specified policy." (Note, I continue to hold a minority opinion (of one I presume <smile/>) that there's not much of a difference between locate and validate. There's an implicit query (validate requests more elements) and policy, and I prefer such things to be explicit.
Added to issues
[101] XKMS specifies three elements that specify key bindings, all of which are derived from the KeyBindingAbstractType. These elements are:
KeyBinding
Specifies the parameters of a particular instance of a key binding
QueryKeyBinding
A template used to specify one or more key bindings using query by example.
PrototypeKeyBinding
A template used to specify the key binding parameters requested in a registration request. I don't understand the distinction between these types...? Perhaps links to their motivation/example?
The NotBefore and NotOnOrAfter attributes are optional. If the NotBefore attribute is omitted the assertion is valid on any date up to but excluding the date specified in the NotOnOrAfter attribute . If the NotOnOrAfter attribute is omitted the assertion is valid from the NotBefore attribute with no expiry. If both elements are omitted the assertion is valid at any time.
The document begins using "assertion" quite a lot, which is not defined. We mean the response, right?
Typo
http://www.w3.org/2001/XKMS/Drafts/XKMS/xkms-part-2.html
Super-encrypted should link to the xenc doc for documentation and I don't see any discussion of super-encryption in XKRSS.
Typo / Clarification
That is a message sent by A and authenticated by B may be subject to forwarding and authentication by C. In addition some applications may require further measures to ensure that messages meet certain legal standards to prevent repudiation.
I thought for simplicity's sake, there was only one relationship, between the client and service. If the client trusted the service, then it's up to the service to determine who/how it deals with under the specified policy?
(This is something I've remained confused on.)
Clarification
Identifier: URN:blahblahblah:w3.org:xkms:payload-I
No mechanism is used to authenticate the client These should be URIs, e.g.,: http://www.w3.org/2002/03/xkms#:payload-II
Typo
Why then, does Bob use "KeyValue" as a <RespondWith> value? The example assumes he already has the capability to parse the X.509 certificate to extract the public key. If he has the key already, why does he need the service to give it back to him? He has already performed cryptographic signature verification.
Clarification / oops