XKMS Issues


1. General Questions/Issues

Issue #
ResultAbstractType is missing a Not-Implemented error status.
ResultAbstractType is missing a place for a detailed error message.
In case of XKMS implemented on top of X.509-based PKI, what should Id attribute in a KeyBinding map to? Should specify if it is to be certificate serial number. See also question 2.29 below
In UseKeyWith, SSL/SMTP is a dnsname and SSL/HTTP is a URI. However only dnsname is looked at for SSL. In other words, only one key and one certificate chain is being returned by a server for all SSL connection made on the same port. Moreover, SSL handshake happens before server even knows which URL is being requested. Therefore binding a key to an HTTP URL more specific than host:port is not really useful. Also the distinction between SSL for SMTP and SSL for HTTP seems excessive since SSL is really bound to the underlying TCP endpoint

Section, ResultMinor codes table, for ResultMinor=Failure, the possible ResultMajor codes should be Sender and Receiver instead of Success and Receiver.
Section, ResultMinor codes table, for ResultMinor=Refused, the possible ResultMajor codes should be Sender and Receiver, instead of Success and Receiver.
When should a server returnResultMajor=Receiver, ResultMinor=TooManyResponses

(server returned no responses) ? 

or ResultMajor=Success, ResultMinor=TooManyResponses (server returned some responses) ?

What is the difference between ResultMajor=Success, ResultMinor=TooManyResponses (server returned some responses) and ResultMajor=Success, ResultMinor=Incomplete (only part of the information requested could be provided) ?
When should service URI be used to specify a policy versus policy identifier in a KeyBindingAbstractType? Spec should clarify or remove one.
Is there a relation between Policy Identifiers and Policy Object Identifiers in the policy constraints extension of X509 ? If so, is there a standard format for encoding a list of policy OIDs as anyURI ?
Section 2.8.4, under PendingNotification, the last sentence should say “If the <PendingNotification> element is present the value ‘Asnychrounous’ MUST be specified in the ResponseMechanim.

(the value pending is removed from RespondWith items 10/23 spec)

Section 3.3.1, [123] last sentence, “priori some means” should be “prior means”.
Section 4.1, [130] “XKMS specifies three elements” should be “four elements”
What should be done with a KeyBinding ID if it is specified in a request ?See also question 2.29 below
Section 4.1.6 [148] 

<!--LocateKeyBinding--> should be 


[67] Why have <OpaqueClientData> which is an unbounded sequence of <OpaqueData> rather than just single <OpaqueData>. How is this having sequence of opaque data blobs is better than a single opaque data blob?
Editorial: [71] Table has <ds:Keyinfo>Element column which is empty and not applicable


Issue #
In a ValidateRequest more than one key can be specified in KeyInfo but with the same KeyUsage, UseKeyWith and PolicyIdentifiers. Does it make sense to allow more than one key in KeyInfo ? Should spec specify that there should only be one ? 
Provide guidelines for how to map KeyUsage, UseKeyWith and PolicyIdentifier to extensions in x509 certs for Locate and Validate.
For implementations on top of x509, if server found more than one cert that matched the KeyUsage, UseKeyWith and PolicyIdentifiers in a ValidateRequest should multiple assertions be returned ? or should this be an error ?
Consider <QueryKeyBinding> with multiple <UseKeyWith> elements. What is the interpretation for matching: 
  1. Target key binding must be a SUPERSET of the <UseKeyWith> from the <QueryKeyBinding>
  2. Target key binding must have EXACTLY SAME set of the <UseKeyWith> as <QueryKeyBinding>
  3. Target key binding must have ANY one of the <UseKeyWith> from the <QueryKeyBinding>
Is this interpretation different for Locate and Validate requests ?
Example 3.1.1 is of dubious value:

If Locate response is not trusted, why would one want to use it to encrypt one’s message. Using Validate for the example seems more logical.

Example 3.1.2 is of dubious value:

If Locate service is not trusted, how does one know if the key value returned actually matches the certificate in the request. Using Validate for the example seems more logical

Editorial: [116] “has a valid validity interval” should be rephrased
[119] seems pretty vague and ambiguous. 
[120] Locate service is only useful to collect the information which then will have to be validated by other means:
  1. by doing X.509 cert chain validation
  2. by issuing separate Validate requests
In case 1 if app can deal with X.509 PKI directly why mix XKMS and X.509 ?

In case 2 why not issue Validate directly instead of using Locate/Validate combination ?

[124] Since DNS is not a trusted source, how does one establish trust in Validate Service whose location is retrieved from DNS? Two possible answers: 
  1. one has to have upfront knowledge of the service in a form of trusted key
  2. one can then use another trusted Validate service to get a proper key binding for this new discovered XKMS service.
In case 1 one has local configuration entry for the XKMS service which needs to be indexed on some service attribute. DNS name seems like the right attribute for this and therefore external XKMS-specific DNS lookup does not seem necessary.

In case 2 we would need to introduce XKMS as one of the protocols for <UseKeyWith> and use trusted Validate service to retrieve trusted binding between service info returned by DNS and its key. In this case one could have used the Validate service directly without intermediate DNS lookup

Editorial: [117] Request asks for <KeyName>, response contains just X509Data. This seems inconsistent and unintentional
[129] Requirement “Service represents to the client accessing the service and to that client alone” needs to be explained a little more and, perhaps, justified. Does it mean that the response can not be transferred to another entity for later verification? What is the rationale behind this ? Does it constraint our ability to create verifiable audit trails of the XKMS interactions ?
[132] What is the scope/lifetime of KeyBinding ID ? Potential options:
  1. single XKMS request or response
  2. single matching XKMS request/response pair
  3. single instance of XKMS service
  4. globally unique and stable
Some other more specific questions related to this are below
[132][136][137] What are the matching rules between <QueryKeyBinding> and target <KeyBinding> when multiple <UseKeyWith> or <PolicyIdentifier>or <KeyUsage> are used ?“ANY”, “EXACT”, “SUPERSET” ? Explicit description for the general case is needed
[150] <Status> must not be Optional in <KeyBinding>
[162] StatusValue must not be optional
Editorial: 4.1.8 should be moved up to be before 4.1.7
Editorial: Should 4.1.13 be moved to XKRSS section ?
[129][205] What is <KeyID> or <ds:KeyID ? I can not seem to find the definition anywhere 
Editorial: [208] Reference to Locate operation should be replaced with Validate operation


Issue #
In section 6 on KRSS, more explanation should be provided for each schema.
In section on KeyBindingAuthentication, provide more explanation and an example of a shared secret used in keyBindingAuthentication.
In section on RegisterRequest, provide an example that is does not assume underlying x509.
PassPhraseAuthentication is defined in the schema in the appendix but not used/mentioned anywhere.
Why is the signature for KeyBindingAuthentication applied over PrototypeKeyBinding versus the whole message or something else ? See also question 3.35 below.
What should a privateKey be encrypted with in a RegisterResult ? 
In RegisterRequest, when would there be signature over the whole message ? One possibility is that the message is coming a Registration Authority. See also question 3.35 below.
Should PrototypeKeyBinding have a place for x509 extensions ? If not is there a standard place and format for x509 cert extensions in a RegisterRequest ? 
Can the spec suggest what to use for keyname for an underlying x509 implementation ?
RegisterResult is missing a place for Rejection Reason.
Should keybinding ID in a RegisterResult be the cert’s serial number for underlying x509 implementations. See also 1.5 and 2.29
Spec should provide recommendations on how KeyUsage, UseKeyWith, Policy Id, and other elements in PrototypeKeyBinding should map to X509 certificate fields and extensions.
In RegisterRequest, if RetrievalMethod is specified in RespondWith, should server return a URI to pick up the certificate or get the request status ? 
Should a RegisterRequest have a validity period in PrototypeKeyBinding? Is this intentional or an oversight ? 
Shouldthere be a message for checking (polling) on the status of a pending request ? 
Section 2.0.4, [268], under explanation of <ds:Signature>, “… over the <KeyBinding> element” should be “over the <PrototypeKeyBinding> element”
[227] Status contains <ValidityInterval> reason in Register response, but no <ValidityInterval> in either Request or Response. What is the validity period in this example ?
[235] Is there any relationship between <KeyBinding> ID attribute and other <KeyBinding> elements ? Must ID be the same one as returned in previous Register (or earlier Reissue) response ?

Is ID alone sufficient to identify specific <KeyBinding> instance ? See alsoquestion 2.29

[235] Is key used for <KeyBindingAuthentication> the same one used in <KeyBinding>. If yes, is it a requirement ? If no, why there is no <ds:keyInfo> in the <Signature> ?
[240]Is KeyBinding ID random or should match the one returned in Register or Reissue ? See alsoquestion 2.29
Editorial: [245] The purpose of the sentence “In this case the code is read over the telephone and so it would be inconvenient to be required to specify spacing between the code blocks or capitalization” is unclear.
[246] Why only KeyBinding is signed and not the entire request ? Is it for the purpose of forwarding it from one service to another? So one can then morph intercepted request to another request type: e.g.,Recovery into Reissue or Revocation etc. This is a potential security problem
Editorial: [247]

<Status StatusValue="Invalid">





should be replaced with

<Status StatusValue="Invalid">

<ValidReason>Signature</ ValidReason >

      <ValidReason>IssuerTrust</ValidReason >







[273] How does one specify which MAC algorithm is used ? Is it an implicit agreement between XKMS service and its client ?
[282] What is the minimal requirements for “identifying” a key binding in Reissue request:
  1. exact match of the key binding returned by earlier Register or Reissue (does that include ID ?) 
  2. match by public key value only
  3. match by KeyBinding ID only
[282] Should POP be “required” for Reissue request ? If yes, is authentication necessary ? See also question 3.35