Re: XML Key Management Specification Last Call - need review/feedback

Stephen,

Since you asked, ... here are my 35 comments.

A feedback would be appreciated.

Denis


> Dear IETF security folks,
> 
> Firstly, apologies if (or when) you get more than one copy of this.
> 
> On behalf of the W3C XML Key Managment Service WG [XKMS-WG], we are
> pleased to announce the publication of the "XML Key Management Specification"
> Last Call Working Draft.  This is one of the deliverables of the WG.  The
> document address is:
> 
>   http://www.w3.org/TR/2003/WD-xkms2-20030418/Overview.html
>   http://www.w3.org/TR/2003/WD-xkms2-bindings-20030418/Overview.html
> 
> The Last Call review period will end on 23 May, 2003. Please send review
> comments by that date to the editor - pbaker@verisign.com and cc:
> www-xkms@w3.org
> 
> Thanks,
> Stephen.


Comments on XKMS Version 2 (April 18, 2003)

The model has severe limitations which are not mentioned in the document.

1. The overall model is making the silent assumption that only names that 
are unique by their structure, i.e. DNS names, RFC 822 names or IP 
addresses, shall be used. Since DNS names, RFC 822 names and IP addresses 
are unique, there is no difference between such names certified by CA1 or 
CA2. If Distinguished Names (DNs) were being used, a DN certified by CA1 and 
the same DN certified by CA2 could correspond to the same or to different 
entities. XKMS currently prohibits the use of DNs or, said in other words, 
exhibits security problems if such names were being used. This should be 
clearly advertised, or a fix to this problem should be made.


2. A major error in XKMS is to consider to obtain information about keys, 
rather than information against certificates, which bind a public key to a 
name for a specific key usage and under a Certification Policy. Since there 
is not a one-to-one relationship between a key and a certificate, but a 
one-to-many relationship, it is not possible to make an unambiguous binding 
with a public key but only an unambiguous binding with a (public key) 
certificate.


3. The Certification Policy is a concept which seems to be ignored at the 
level of the interfaces that are being proposed.


4. In section [46] the text says:

"The XKMS specification defines three types of request:

X-KRSS Request
      A Register, Reissue, Revoke or Recover request as specified by the Key 
Information Service Specification".

There is indeed a typo, probably intentionally left by the editor, to make 
sure that at least someone read the specification: "Key Information Service 
Specification" should be changed into "Key *Registration* Service 
Specification".


5. The <ds:KeyInfo> (see [135]) is described as an "hint". This should not 
be the case since it is important to make sure under which certificate a 
signer wanted to sign. Several certificates may include the same public key 
and for that reason it is important to make sure that the certificate (or an 
unambiguous reference to it) is linked to the data that has been signed and 
is indeed protected by the signature. Without that link certificates could 
be substituted without notice. The concept is similar to ESSCertID that is 
used in CMS (see RFC 2634).


6. The fact that ds:KeyInfo> may or may not be cryptographically bound to 
the signature itself is advertised as an important property (see [136]). It 
is said: "This allows the <ds:KeyInfo> to be substituted or supplemented 
without "breaking" the digital signature". This should be considered as a 
severe weakness, since such a substitution is not desirable (see above). A 
certificate could be added, but the reference to the certificate should 
remain unchanged and unchangeable.


7. The XKISS Validate service verifies a binding with a public key, while 
the binding should be verified with a certificate (which contains a public 
key), instead of directly a public key value. CAs may deliver different 
certificates with the same public key but with different attributes in them. 
It is important to know which certificate has been used, rather than which 
public key has been used, since several certificates may include the same 
public key.


8. The two overviews from sections 1.5 and 1.6 do not provide a clear 
picture of the functions that are supported. They should be both revised. A 
text is proposed as an annex at the end of these comments.


9. The document provides several examples which are quite interesting. 
However the core of a standard should not include examples. Such examples 
should be placed in an annex. However if these examples were removed the 
text would not be understandable anymore, because the remaining explanations 
would be insufficient. It is thus requested to add more normative text and 
to move the examples in an informative annex.


10. The XKISS Locate service is defined as " The XKISS Locate service 
resolves a <ds:Keyinfo> element but does NOT REQUIRE the service to make an 
assertion concerning the validity of the binding between the data in the 
<ds:Keyinfo> element". What means "resolving <ds:Keyinfo> element" is not 
self-understandable. The exact processing that is supposed to be done by the 
service should be described in details.


11. The example (see [145]) is insufficient to describe what that service 
really does. The various input (and output) parameters should be clearly 
described. This is not the case.

The service seems to return only a key value, while it should return the 
main components from a certificate.

 From the example, it can be seen that the input parameters are a DNS name 
and the name of a protocol. Since no key usage is mentioned, the service is 
unable to know whether a certificate that includes a signature verification 
key or includes an encryption key is requested. A certificate should be 
returned and not a key, so that the user can verify the validity period of 
the certificate, otherwise a validity date should be included in the 
request. The certification policy contained in the certificate may also be 
helpful, unless it is specified in the request.


12. The XKISS Validate service is defined as : "The XKISS Validate Service 
allows all that the Locate Service does, and in addition, the client may 
obtain an assertion specifying the status of the binding between the public 
key and other data, for example a name or a set of extended attributes". 
What means "other data" is not self-understandable. The exact processing 
that is supposed to be done by the service should be described in details.


13. In [152] it is mentioned: "Furthermore the service represents that the 
status of each of the data elements returned is valid and that all are bound 
to the same public key". A <ds:Keyinfo> element may contain a <ds:X509Data> 
element. Therefore the binding is not with a key but with a certificate.


14. The example (see [155]) is insufficient to describe what that service 
really does. The various input (and output) parameters should be clearly 
described. This is not the case.
In particular, is the validation done only for the current time or can it be 
done for a time in the past ? Even, if this is the current time, is that 
time indicated in the response? The answer is only given (hidden) in section 
[215], but this should be clearly advertised upfront.


15. From its name, the XKISS Validate Service present a few similarities 
with the validation service requirements that have been defined by the PKIX 
WG from the IETF. This working group has produced RFC 3379 (Delegated Path 
Validation and Delegated Path Discovery Protocol Requirements) which is a 
set of requirements.

However, the XKMS specification is leaving aside many, if not most, of the 
these requirements. An important concept from RFC3379 is the concept of 
"validation policy". When a validation is done, it must be done according to 
a set of rules. These rules depends upon the application. In particular some 
root keys may be adequate for an application, but not for another. Trust 
elements cannot be uniform and cannot be left open to the Validate Server.

The text is speaking of a "validation criteria (see [161]), but it is 
unclear what it really is. This is one of the most severe limitations of 
XKMS and this limitation is not advertised.

It would be quite interesting to understand why the requirements from 
RFC3379 have not been followed.


16. The text is speaking of some means to locate the correct XKMS service 
(see [163]) but does not provide any guidance in order to solve this 
problem, in particular in the context of multiple servers offering their 
services to the users.


17. The text in [168] states: "the Service represents to the client 
accessing the service and to that client alone that the binding between the 
data elements is valid under whatever trust policy the service offers to 
that client." Unless the service can clearly advertise which trust policy is 
being used, the client cannot use any kind of trust policy without even 
knowing which one it is. As already stated, the concept of validation policy 
is not supported, but should be supported.


18. The text under [171] mentions: "The Id identifier is defined to provide 
a means by which the key binding may be signed using XML Signature. Clients 
MUST NOT rely on the key binding identifier being either unique or stable". 
On the contrary it is believed that a key identifier should be unique. The 
ESSCertID from RFC 2634 is a good example of such a unique binding.


19. The text under [174] considers only three intended uses of the key:

   1) Encryption : The key pair may be used for encryption and decryption,
   2) Signature : The key pair may be used for signature and verification,
   3) Exchange: The key pair may be used for key exchange.

However, the key usages should be defined in terms of security services (see 
ISO 7498-2), i.e. authentication service, confidentiality service and 
non-repudiation service.

To avoid some security problems it is particularly important to make a 
difference between a key usable for authentication and a key usable for 
non-repudiation. This cannot be covered by a single key usage called 
"signature".


20. The text under [177] mentions the <UseKeyWith> element which specifies a 
subject identifier and application identifier that determine a use of the 
key. The <UseKeyWith> must contain "Application" which is a URI that 
specifies the application protocol with which the key may be used and 
"Identifier" which specifies the subject to which the key corresponds within 
the specified application protocol. A protocol can support a sender and a 
receiver. It is unclear whether the Identifier corresponds to the sender or 
the receiver. It seems that the notion is by itself insufficient and should 
be extended to make such difference.


21. The text under [180] mentions S/MIME as a protocol. Why is CMS 
(Cryptographic Message Syntax) not considered as a protocol as well ?


22. The text under [180] mentions PKIX. It is very unclear to understand why 
PKIX is considered as a "protocol" since it is only a set of data structures.


23. The text under [180] mentions the use of "Certificate Subject Name" as 
an appropriate identifier. It should be observed that this name only is 
insufficient to correctly identify an entity, since two CAs may certify the 
same name and that this name may correspond to the same or to different 
entities. Unless a sequence of CAs names is added to the entity name up to a 
root key, such names are ambiguous. This relates to the non-uniqueness of DN 
names already mentioned.


24. The text under [180] identifies various protocols. To this list, XAdES 
(XML Advanced Electronic Signature) which is a W3C Note issued on February 
20, 2003 should be added (see: http://www.w3.org/TR/XAdES/). The 
"identifier" type is such a case is a SigningCertificate element, i.e. *not* 
a DN.


25. The description of the Validate Service are confusing. It seems to 
relate more to the Locate Service rather than the Validate Service where the 
primary response should be "valid according to some policy" or "invalid 
according to some trust policy". The exact service performed by the Validate 
Service is not sufficiently detailed.


26. In [221] it is mentioned: "The server returns one or more <KeyBinding> 
elements that meet the criteria specified in the request." It is 
questionable why not simply a valid, invalid or don't know assertion is made 
against the proposed binding.


27. In the case of validation, the "yet not valid" response should be 
considered, in particular when a certificate is suspended. This means that 
another validation request made later on may succeed.


28. The Register Service from KRSS is not sufficiently described. The two 
examples provide more information, but that information is not normative. 
 From the example, two features are mentioned:

1° authentication information to be used later on for revocation can be 
transmitted. However, it is unfortunate that the data does not also include 
the question to be answered.

2° it is necessary to have a face to face contact with the LRA before being 
able to use the register request. During that face to face information is 
captured by the LRA and the secret "authentication code" is provide to the 
end-user. However, this method is time consuming and does not allow a cost 
effective deployment of a PKI.

It is suggested to use another technique that places all the burden of the 
typing for the end-user, who receives back both a registration number and 
the hash of his request (signed by the service) so that the end-user can 
then authenticate to the LRA in a face to face where the Register Service 
has only to verify the information (and to only "click" to accept or 
reject). Another advantage is that no secret information is being used.


29. In the example [241] several identifiers are included :

<UseKeyWith Application="urn:ietf:rfc:2459"
Identifier="C=&quot;US&quot; O=&quot;Alice Corp&quot;
CN=&quot;Alice Aardvark&quot;"/>
<UseKeyWith Application="urn:ietf:rfc:2633"
Identifier="alice@alicecorp.test"/>
<UseKeyWith Application="http://ca.example.com/cps/20030401/class3"
Identifier="alice@alicecorp.test"/>

It is unclear to understand how the concept of "UseKeyWith Application" will 
be translated in an X.509 certificate, since an X.509 certificate does not 
support the concept of "UseKeyWith Application".


30. In the example [245] the private key is returned in the response. It 
will be quite uneasy for the end-user to memorize the authentication code 
3n9cj-jk4jk-s04jf-20934-jsr09-jwik4 previously obtained through some 
out-of-band mechanism. This method would be quite difficult to use and would 
not allow an easy and cost effective deployment of a PKI. It is suggested to 
use another technique that allows the end user to locally generate a key 
pair, so that the public key can be sent in the Register Service request and 
then used by the Register Service to encrypt the private key once generated. 
The main advantage is that no secret information is being used and no 
out-of-bands mechanism is necessary.


31. The Reissue request mentions "A reissue request is made in the same 
manner as the initial registration of a key". It is not believed that this 
statement is correct. The user should provide the previously obtained 
certificate and ask for another validity period. There is no need to specify 
again secret information obtained through an out of bands mechanism.


32. The Revocation request should allow the possibility to carry a reason 
code and an Invalidity Date (RFC 2459 sates that CRL issuers are strongly 
encouraged to include meaningful reason codes in CRL entries).


33. The Revocation request example includes the certificate. It is very 
doubtful that the user will be able to provide its full certificate, if his 
smart card has been stolen. However he could more easily provide his subject 
name instead. The input and the output parameters are not sufficiently 
described.


34. The Recovery request mentions "A key recovery request is made in the 
same manner as the initial registration of a key". It is not believed that 
this statement is correct. There is no need to specify again secret 
information obtained through an out of bands mechanism.
Users do not have only a confidentiality key, but also an authentication 
key. They could use it to authenticate. If they loose everything, they could 
encrypt the authentication code under a key they wish their private key to 
be recovered (using PKCS#12) and authenticate their request by phone using 
the non-secret registration number of their request. For this to be 
possible, a hash of the request should be present in the response.


35. The security considerations section should be augmented to mention the 
severe limitations that are indicated above.


ANNEX

The following text is proposed as a global overview of these two sections.

Note: This text is re-using text already present and does not include 
changes that are suggested in the other comments.


"The XKMS specification defines three types of requests:

1. X-KISS (Key Information Service Specification) Request : A Locate or a 
Validate request.

The XKISS Locate service provides one or more unverified key bindings to the 
best of its knowledge but does not provide any assurance about that binding. 
Information obtained from a Locate service SHOULD NOT be relied upon unless 
it is validated. Validation may be achieved by forwarding the data to a 
Validate service or by performing the necessary trust path verification locally.

The XKISS Validate service allows a client to query the binding between a 
<ds:Keyinfo> element (i.e. <ds:X509Data>, <ds:X509Data>*, <ds:KeyName>, 
<ds:KeyValue>) and one or more <UseKeyWith> elements (i.e. an application 
protocol with which the key may be used and an "identifier" which specifies 
the subject to which the key corresponds within the specified application 
protocol).

2. X-KRSS (Key Registration Service Specification) Request :The XML Key 
Registration Service Specification permits management of information that is 
bound to a public key pair. The XKRSS service specification supports the 
following operations:

a)  Register : The Registration request message contains a prototype of the 
requested key binding which may contain only partial information, a key 
without a name or a name without a key. The registration service MAY require 
the client to provide additional information to authenticate the request. If 
the public key pair is generated by the client, the service MAY require the 
client to provide Proof of Possession of the private key.

b)  Reissue : A previously registered key binding is reissued unchanged 
except the validity period.

c)  Revoke : A previously registered key binding is revoked.

d)  Recover : The private key associated with a key binding is recovered.

3. Compound Request : A compound request allows multiple X-KISS or X-KRSS 
requests and the corresponding responses to be sent in a single message. 
This allows considerable processing resources to be saved as a single 
signature on the compound message may be used in place of multiple 
signatures on the individual requests or responses.




> 
> [XKMS-WG]  http://www.w3.org/2001/XKMS
> 
>