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

Stephen,

At least one single comment (i.e. comment 4) among my 35 "xkms-friendly"
comments has been accepted.

:-|

Regards,

Denis


> Hi Denis,
> 
> The xkms wg thanks you for your 35 comments. Our responses
> to those as discussed at our 20030806 conference call is
> below.
> 
> To save some time I should preface our individual responses
> by saying that the wg felt that many of the comments reflect
> a misaphrehenshion of the goals of xkms - in particular, xkms
> is not intended to be an xml variant of x.509 and therefore
> concepts such as "CA" (etc.) do not make sense in and of
> themselves. That is, while it is a goal to be able to sensibly
> place an xkms responder "in front of" and x.509 based pki, there
> is no requirement that all xkms responders operate like that.
> It is entirely within the xkms wg's remit to consider single
> server, certificate-less (i.e. raw keys only) systems. This
> made it impossible for the wg to do other than to note many
> of your comments, since they could not be accepted given
> the wg's charter[1], which in its first sentence states:
> 
> "The mission of this working group is to develop a
> specification of anXML application/protocol that allows a
> simple client to obtain key information (values,
> certificates, management or trust data) from a web
> service."
> 
> [1] http://www.w3.org/2001/XKMS/2002/11/charter.html
> 
> Where your comments appear to require that xkms embody such
> x.509 concepts as "certificates", or "CAs" then we have
> simply referred to this preface since the wg cannot process
> those.
> 
> If you would care to "translate" your comments into more
> "xkms-friendly" terminology, then the wg would be happy
> to consider those after this last call process is completed.
> 
> Regards,
> Stephen.
> 
> Detailed responses below.
> 
>> 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.
> 
> 
> See the preface above.
> 
>> 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.
> 
> 
> See the preface above.
> 
>> 3. The Certification Policy is a concept which seems to be
>> ignored at the level of the interfaces that are being
>> proposed.
> 
> 
> See the preface above.
> 
>> 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".
> 
> 
> Thanks.
> 
>> 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).
> 
> 
> See the preface above.
> 
>> 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.
> 
> 
> See the preface above.
> 
>> 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.
> 
> 
> See the preface above.
> 
>> 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.
> 
> 
> And responed to there.
> 
>> 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.
> 
> 
> The wg has attempted to match the style from previous standards
> like xkmsig and saml.
> 
>> 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.
> 
> 
> See the preface above. The exact processing to be done is
> deliberately not determined here - that is one of the differences
> between xkms and x.509. "Resolves" means that the service
> attempts to provide fuller information about the keyinfo.
> 
> (SF comment: "self-understandable" is not "self-understandable"...
> ...I think:-)
> 
>> 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.
> 
> 
> See the preface above.
> 
>> 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.
> 
> 
> See the preface above. And the response to #10.
> 
>> 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.
> 
> 
> See the preface above.
> 
>> 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.
> 
> 
> The wg felt that the current section was sufficient.
> 
>> 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.
> 
> 
> xkms is a w3c activity and as such there is no onus on the group to
> take account of works-in-progress from elsewhere. However, as you
> say, there is a similarity with the on-going pkix work on on-line
> services. The wg has produced its own requirements document, which
> differs from rfc3379, and which was finalised well before rfc 3379.
> We would indeed be interested were someone to compare those documents,
> but the wg has no intention of doing so at present.
> 
>> 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.
> 
> 
> The wg decided to omit this from its scope, given that w3c is also
> working on other mechanisms for service discovery.
> 
>> 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.
> 
> 
> See the preface above.
> 
>> 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.
> 
> 
> See the preface above.
> 
>> 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".
> 
> 
> The wg explicitly decided not to tackle issues to do with repudiation
> using the key usage mechanism.
> 
>> 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.
> 
> 
> UseKeyWith is intended to be extensible. A protocol where the
> sender/recipient distinction is required can define its own
> variant UseKeyWith URI.
> 
>> 21. The text under [180] mentions S/MIME as a protocol. Why is CMS
>> (Cryptographic Message Syntax) not considered as a protocol as well ?
> 
> 
> CMS is used much more broadly. The wg felt happy to define the
> identifier for s/mime but not for all cms based protocols.
> 
>> 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.
> 
> 
> The intent was to define the identifier and uri for protocols which
> abide by "pkix rules".
> 
>> 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.
> 
> 
> The wg felt that a single name was sufficient. A service deployment
> which faces that challenge might define something else.
> 
> 
>> 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.
> 
> 
> The wg felt that referencing a Note in that way conflicts with
> our goal for xkms to become a recommendation. When the XAdES
> specification becomes a (type of) recommendation then the wg
> would consider this.
> 
>> 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.
> 
> 
> The wg felt otherwise.
> 
>> 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.
> 
> 
> The service is free to return additional information.
> 
>> 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.
> 
> 
> (We assume you meant "not valid yet".) The wg didn't feel that this
> was of sufficient interest to warrant inclusion at this point.
> 
>> 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.
> 
> 
> The wg felt that the current text was fine, given, as you
> say, that they are examples.
> 
>> 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".
> 
> 
> There is no direct equivalent of UseKeyWith in x.509. The wg
> has no requirement to be compatible with everything in x.509,
> nor vice versa. In this case, probably the most common thing
> will be for services to map between UseKeyWith and various
> x.509 extensions (in particular some policy oids) with the
> help of local configuration. The wg felt that such mappings
> were easier done locally.
> 
>> 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.
> 
> 
> The wg felt that the example is sufficient.
> 
>> 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.
> 
> 
> See the preface above.
> 
>> 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).
> 
> 
> See the preface above.
> 
>> 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.
> 
> 
> The wg felt that the example text was sufficient.
> 
>> 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.
> 
> 
> "In the same manner" does not mean *exactly* the same, just
> similar, so the wg feels that the text is fine.
> 
>> 35. The security considerations section should be augmented to
>> mention the severe limitations that are indicated above.
> 
> 
> See the preface 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.
> 
> 
> The wg felt that the current text was sufficient.
> 
> 
> 
>

Received on Tuesday, 26 August 2003 07:58:48 UTC