Comments on XML Key Management (2.0) Requirements

Author: Denis PINKAS. Bull.

General comment

The specification includes many detailed implementation
requirements, while the overall functional goal is not clear.

>From the introduction it seems that two main categories of functions
need to be supported:

1) the creation of a binding between a key, an identifier and some
other information, like a key usage. Using the PKIX vocabulary this
means the creation of a public key certificate. Using the PKIX
vocabulary, it seems to be the support of CMP using XML syntax,
instead of ASN.1 syntax. It seems that retrieval of that information
and revocation of the certificate should also be supported, but this
is unclear.

2) validation of a key against a policy, whereas this concept is
insufficient: it should be validation of a certificate against a
validation policy. The PKIX WG is currently attempting to finalize a
requirements specifications, which includes much more functionality
than this one. Many of the requirements which are in that other
specification could be imported. Even this requirement is not clear.

The document should be clarified to identify what kind of functions
need to be supported.


Detailed comments

1. The introduction does not capture sufficiently the goals of this
specification. The functions to be supported should be described to
a finer level of granularity.


2. [Deferred Request Authentication] The current text is: "For
example, a client request might be directed to a particular URI so
that a specific policy will be enforced as part of the service
processing the request. Inclusion of the URI in the response ensures
that the expected server policy was followed and that the request
was conveyed correctly".

This example is incorrect. A validation policy is not necessarily
tight with a particular validation server. A validation server may
indeed support different validation policies that may have their own
URI belonging to a different name space. Thus a response shall
include both the URI of the validation server *and* the URI of the
validation policy. In some cases, it may be from the same name
space.


3. [Key Validation]. Key validation is defined as : "A service that
verifies the binding of information to a public key and also
determines the current status of that binding".

The determination of the current status of a binding is done using
the OCSP protocol in the PKIX world. It is not the validation of
certificate up to a root key or trust anchor but simply a check on
the revocation status of the certificate.

The term "Key Validation" is confusing since :

a) the term "key" (instead of "certificate") is used and the same
public key MAY be bound to more than one identifier (name) so
validating a key does not mean anything unless the whole information
associated with that key is also validated at the same time.

b) the term "validation" is used and in the PKIX world "validation"
means to validate a certificate up to a root key, which is not what
is said in the explanations. So neither the use of the term "key"
nor "validation" is adequate (or would be very confusing for the
PKIX community).

If the term "certificate" is deliberately avoided, then "Key binding
status check" would be a better wording for that service.

Now, it is unclear if in addition (or as a replacement ?) of this
service, an equivalent of a "certificate validation", using the PKIX
terminology, is also required. Since the definition of this service
by the PKIX WG is close to completion, it might be interesting to
consider to import some of the sentences used in that document.
Should an equivalent of that service be a goal of this
specification, then it could be named: "Key binding validation".


4.  [Trust Service]  A Trust Service is defined as "a service that
is capable of registering public keys and/or providing key
information services, including key validation and location.".

It should be made clear that these functions may be offered by
different Trust Service Providers, in particular the registration of
a public key with its associated information can be done with one
service while the "key binding status check" can be provided by a
different Trust Service Provider.


5.  [Trust Service]  A Trust Service is defined as "a service that
is capable of registering public keys and/or providing key
information services, including key validation and location.".

There is not sufficient information to understand what a "key
location" service is.


6. [2.1 Universality and Usability. Item 2]

In order to allow some interoperability with PKIX, it should be said
that some PKIX structures should be able to be encapsulated in XML
structures (e.g. certificates, CRLs and OCSP responses).


7. [Transaction Security. Item 5]. Including a hash of the request
is fine to detect substitutions of some request parameters, but is
not convenient to be able to prove to someone else that the response
was correct, without the need to memorize the whole request. In many
cases only some parameters of the request are sufficient and thus
should be copied in the response in addition to the inclusion of the
hash of the request. This avoids to memorize the whole request.

The text should be changed to: "The trust server response MUST
include both a digest of the request payload and the request URL,
and a copy of the relevant parameters of the request so that a
response used in isolation may unambiguously determine what the
request was about."


8. [Transaction Security. Item 6]. The current text is: "Techniques
for protection against replay attacks MUST be recommended in the
security considerations section. Specific techniques SHOULD be
defined, such as nonce, origination time, and serial numbers in
requests, for example"

This wording does not follow the meaning of RFC 2116. "MUST be
recommend" is self-contradictory. Either it is recommended or it is
a must. It is important to provide a replay protection mechanism and
thus the requirement should be changed into: "Techniques for
protection against replay attacks MUST be supported, whether the
client has a clock synchronized with UTC or not.


9. [Trust Service Trust. item 8]. The wording being used is a door
opened to any interpretation: "The specification SHOULD support
different means of establishing a trust relationship with the trust
service, and not be limited to client caching of a trusted
certificate or trusted key." Which are these "other" means ?


10. [Capabilities. Item 2]. The current text says: "The
specification MUST describe how to revoke a registered key binding."

This requirement is not very explicit. It should be said: "The
specification MUST describe how revocation of a registered key
binding can be requested". Then it be explained how/if the
revocation is advertised. Is it through the use of "key binding
status check" request and/or a "key binding validation" request ?

If there were some explanations about the architecture, the answers
to these questions would probably be evident.


11. [Capabilities. Item 3]. The current text says: "The
specification MUST describe how to update registered public key
information". Does this function maps to a key binding (i.e.
certificate) revocation followed by the issuance of a new key
binding (i.e. certificate) ? If so, why such a combined function
should be supported instead of two separate functions, since anyway
the first one is needed ?


12. [Capabilities. Item 8 and 9]. This list of 10 items lists first
the functions related to key binding registration and revocation,
and finally introduce in the last two items what is specific to
validation or status check. This should be separated.

Now item 8 is confusing since it considers "validating the status of
a public key and additionally validating the binding between a
public key and other related information". Validating a public key
alone, without he binding information does not mean anything. The
text could be reworded to say: "This specification MUST define a
protocol for validating the status of a key binding", but this would
still be confusing: is the revocation status of a key binding being
checked or the validity of a key binding against a validation policy
? This is not the same.

>From the next item, one possible interpretation could be: "This
specification MUST define a protocol for validating a key binding
against a particular context".


13. [Capabilities. Item 9]. Another example of a "context" would be
a validation policy as meant by the PKIX WG. Adding such an example
would be appreciated.


14. [Formats. Item 11]. The current text says: "The specification
MUST define how to convey application context in requests/responses,
e.g. transaction amount, arbitrary XML".

Conveying arbitrary XML from the applications both in the request
and in the response has a drawback: interoperability. This should be
changed into: "The specification MUST be able to support extensions
to convey application context in requests/responses, e.g.
transaction amount, arbitrary XML". These extensions SHALL be
defined in further specifications". It should also be noticed that
these extensions may add additional service to the basic service.


15. [Formats. Item 14]. The current text says: "The specification
MUST permit opaque data to be associated with a request and returned
with the corresponding response." Conveying opaque data in the
request has a drawback: interoperability. This requirement SHALL be
deleted.


16. [2.5. Objects and Processing. Item 1]. The current text says:
"The specification SHOULD define how to register a key for specific
uses and how to update the allowed uses over time". This relates to
the comment made for [Capabilities. Item 3] where the current text
says: "The specification MUST describe how to update registered
public key information". Why such a combined function should be
supported instead of two separate functions, since anyway revocation
is first needed ?


17. [2.5. Objects and Processing. Item 2]. The current text says:
"The specification SHOULD enable finer granularity of key usage
definition to support compliance requirements. Signatures may be
supported for specific purposes, such as approval, authorship or
integrity for example. One possible way of meeting this requirement
is to define a <Purpose> subtype for the <KeyUsage> element. "

There is a fully different way to address this issue, which does not
require to support a new element or extension in a PKIX certificate.
Signature will be verified against a signature policy ("signature
validation context" seems to be the equivalent term that could be
used by the XML community). The signature policy may define which
"purposes" like approval or authorship are recognized under the
policy. Then signers may indicate the "purpose" of the signature
when they sign. The main advantage is that a single key binding can
be used for many different "purposes", thus avoiding the creation of
multiple key bindings.

The current requirement is in fact a solution to a problem. It is
really questionable whether this requirement should be maintained at
all. Supporting it in the way that is described above means no
change on the key usage definition, but the support of a specific
signed property in the XML DigSIG format.

In the ETSI documents this property is called a "commitment type".
See RFC 3125 and RFC 3126 for more information where this concept
has been first used. Also see the definition of a format for
electronic signature defined in XML and based on XML DigSIG: ETSI TS
101 903 XML Advanced Electronic Signatures (XAdES)
available from: http://portal.etsi.org/sec/el-sign.asp


18.  [2.5. Objects and Processing. Item 4]. The current text says:
"The following KeyInfo formats MUST be supported by a trust server
if the service claims interoperability with PX509: X509Cert,
X509Chain and X509CRL."

In order to provide interoperability with RFC2459bis, OCSP MUST also
be supported (see section 4.2.2.1 Authority Information Access).


19. [2.5. Objects and Processing. Item 10]. The current text says:
"The specification MUST describe how to provide proof of possession
of private keys.". This requirement should be mentioned as being
optional: The specification SHOULD describe how to provide proof of
possession of private keys."

Proof of possession of a private key is not needed for decryption
keys used for confidentiality purposes. If someone registers a
public key and does not possess the corresponding private key, it
will not be able to decipher. So there is no security threat.

If the key is used for authentication, data origin authentication or
non repudiation, then, if the "key binding information" (alias the
certificate itself or an unambiguous reference of the certificate)
is protected under the private key, then proof of possession will be
done at the time of use of the key private rather than the time of
registration of the key. It is even safer. PKIX has mandated proof
of possession of private keys because of backward compatibility with
some old protocols which were omitting to protect the certificate or
a certificate identifier (and which otherwise would have been
insecure). Since the XML community is building new protocols, these
protocols should be built secure from the beginning.


20. [3. Out of Scope. Item 2]. The current places in this list :
"Issues of non-repudiation, including but not limited to 'technical
non-repudiation' and 'contractual non-repudiation". This is
contradictory with [2.5. Objects and Processing. Item 2 ] which
mentions" Signatures may be supported for specific purposes, such as
approval, authorship ". After having done such a signature, the
signer will not be able to deny that he did it. This is called
non-repudiation. If non repudiation was indeed out of the scope,
then such purposes would not be supported or an authorship which
could be denied would be of no interest. This item should be removed
from the list.


21. [3. Out of Scope. Item 2]. The current places in this list :
"Expression of existing PKI data structures in XML". This item
should be removed from the list. It does make sense to encapsulate
X509certificates in an XML container. See ETSI TS 101 903 .

Denis