Subject: RE: XKMS Version 2

From: "Hallam-Baker, Phillip" <[email-masked]>
Date: Wed, 25 Jun 2003 07:08:25 -0700

Denis,

	The last call has closed and I am currently working on composing
replies to the points raised in last call and making appropriate edits to
the document.

		Phill

> -----Original Message-----
> From: Denis Pinkas [mailto:[email-masked]]
> Sent: Wednesday, June 25, 2003 3:44 AM
> To: Hallam-Baker, Phillip
> Cc: Stephen Kent; [email-masked]
> Subject: XKMS Version 2
> 
> 
> 
> Phill,
> 
> You wrote:
> 
> >> In which case the IETF PKIX group will kindly stop work on 
> SCVP which
> >> duplicates functionality of the XKMS specification which 
> has already
> >> passed last call.
> 
> Following a request made to the PKIX WG on May 7, I sent 35 
> comments on XKMS 
> Version 2 (April 18, 2003) to the editor - 
> [email-masked] and cc: 
> [email-masked]. The Last Call review period ended on 23 May, 2003.
> 
> I am quite surprised you say that the XKMS specification has 
> already passed 
> last call, since my 35 comments have never been discussed 
> with me, nor answered.
> 
> Hereafter is again a copy of my comments (note sure that this 
> message will 
> go to the list, since it might be too long):
> 
> 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="[email-masked]"/>
> <UseKeyWith Application="http://ca.example.com/cps/20030401/class3"
> Identifier="[email-masked]"/>
> 
> 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.
> 
> Denis
> 
> 
> 
> 
>