denis comments proposed response...

My (almost, but not quite, complete) proposed response to Denis'
comments is below for checking on today's call.

Stephen.

Denis,

Firstly the xkms wg thanks you for your 35 comments. Our response
to those as discussed at our 20030806 conference call is below.

To save some time I should preface our responses to these
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" 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.


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 thi>s
statement is correct. The user should provide the previously obtained
certificate and ask for another validity period. There is no need to 
spec>ify
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 
h>is
smart card has been stolen. However he could more easily provide his 
subj>ect
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 tha>t
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 
co>uld
encrypt the authentication code under a key they wish their private key t>o
be recovered (using PKCS#12) and authenticate their request by phone usin>g
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 th>e
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 
bindi>ng.
Information obtained from a Locate service SHOULD NOT be relied upon 
unle>ss
it is validated. Validation may be achieved by forwarding the data to a
Validate service or by performing the necessary trust path verification 
l>ocally.

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 
specifi>es
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 
t>he
requested key binding which may contain only partial information, a key
without a name or a name without a key. The registration service MAY 
requ>ire
the client to provide additional information to authenticate the 
request.> If
the public key pair is generated by the client, the service MAY require 
t>he
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.

Received on Wednesday, 6 August 2003 11:25:38 UTC