- From: Hallam-Baker, Phillip <pbaker@verisign.com>
- Date: Wed, 23 Jul 2003 10:36:50 -0700
- To: "Www-Xkms (E-mail)" <www-xkms@w3.org>
- Message-ID: <2A1D4C86842EE14CA9BC80474919782E8A92C4@mou1wnexm02.verisign.com>
It seemed easier to deal with these as a separate issues list.
Message-ID: <3EB9270F.5060509@bull.net>
Date: Wed, 07 May 2003 17:32:31 +0200
From: Denis Pinkas <
<mailto:Denis.Pinkas@bull.net?Subject=Re:%20XML%20Key%20Management%20Specifi
cation%20Last%20Call%20-%20need%20review/feedback&In-Reply-To=<3EB927
0F.5060509@bull.net>&References=<3EB9270F.5060509@bull.net>>
Denis.Pinkas@bull.net>
To:
<mailto:stephen.farrell@baltimore.ie?Subject=Re:%20XML%20Key%20Management%20
Specification%20Last%20Call%20-%20need%20review/feedback&In-Reply-To=<
;3EB9270F.5060509@bull.net>&References=<3EB9270F.5060509@bull.net&
gt;> stephen.farrell@baltimore.ie
Cc: Shivaram Mysore <
<mailto:Shivaram.Mysore@sun.com?Subject=Re:%20XML%20Key%20Management%20Speci
fication%20Last%20Call%20-%20need%20review/feedback&In-Reply-To=<3EB9
270F.5060509@bull.net>&References=<3EB9270F.5060509@bull.net>>
Shivaram.Mysore@sun.com>,
<mailto:pbaker@verisign.com?Subject=Re:%20XML%20Key%20Management%20Specifica
tion%20Last%20Call%20-%20need%20review/feedback&In-Reply-To=<3EB9270F
.5060509@bull.net>&References=<3EB9270F.5060509@bull.net>>
pbaker@verisign.com,
<mailto:www-xkms@w3.org?Subject=Re:%20XML%20Key%20Management%20Specification
%20Last%20Call%20-%20need%20review/feedback&In-Reply-To=<3EB9270F.506
0509@bull.net>&References=<3EB9270F.5060509@bull.net>>
www-xkms@w3.org
Subject: 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
Specific>ation"
> Last Call Working Draft. This is one of the deliverables of the WG. T>he
> document address is:
>
> <http://www.w3.org/TR/2003/WD-xkms2-20030418/Overview.html>
http://www.w3.org/TR/2003/WD-xkms2-20030418/Overview.html
> <http://www.w3.org/TR/2003/WD-xkms2-bindings-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 revie>w
> comments by that date to the editor -
<mailto:pbaker@verisign.com?Subject=Re:%20XML%20Key%20Management%20Specifica
tion%20Last%20Call%20-%20need%20review/feedback&In-Reply-To=<3EB9270F
.5060509@bull.net>&References=<3EB9270F.5060509@bull.net>>
pbaker@verisign.com and cc:
>
<mailto:www-xkms@w3.org?Subject=Re:%20XML%20Key%20Management%20Specification
%20Last%20Call%20-%20need%20review/feedback&In-Reply-To=<3EB9270F.506
0509@bull.net>&References=<3EB9270F.5060509@bull.net>>
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.
This is not the case, XKMS does not assume that a name is unique by its
structure, it does however assume that a particular XKMS service will choose
to impose a unique interpretation of a given name.
Resolution - Editorial - add text to discussion of UseKeyWith to point out
that certain names are not globally unique and that in such cases the
response from an XKMS service will require an interpretation of the name.
"Note that in some applications, in particular X.509 an application
identifier is not guaranteed to be globally unique. In such circumstances
the XKMS service is responsible for specifying rules to unambiguously
interpret identifiers."
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 the>re
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 bindi>ng
with a public key but only an unambiguous binding with a (public key)
certificate.
This is not an error, it is a deliberate design decision. XKMS is a key
centric model. There is no requirement that any key be backed by a
certificate. It is the statement about the key holder that is significant in
every case.
Resolution - no action
3. The Certification Policy is a concept which seems to be ignored at the>
level of the interfaces that are being proposed.
See comment #2
Resolution - no action
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 mak>e
sure that at least someone read the specification: "Key Information Servi>ce
Specification" should be changed into "Key *Registration* Service
Specification".
Resolution - Editorial - fixed
5. The <ds:KeyInfo> (see [135]) is described as an "hint". This should no>t
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 k>ey
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 a>nd
is indeed protected by the signature. Without that link certificates coul>d
be substituted without notice. The concept is similar to ESSCertID that i>s
used in CMS (see RFC 2634).
This attack has been considered at length in WS-Security. In this case the
text is describing a known property of ds:KeyInfo, not a feature of XKMS
itself.
Resolution - No Action
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.
The weakness is a feature of the certificate model, not the key centric
model. In the key centric model it is the key that is relevant, not
arbitrary attributes that are casually bound to the key.
If the purpose of a signature format is to express the intention of the
signer that should be done explicitly through authenticated signature
attributes such as 'yes I really want to loose my house'. The reference to
casual attributes bound through the certificate seems to be altogether too
weak a model for the purpose intended.
Resolution - No Action
7. The XKISS Validate service verifies a binding with a public key, while>
the binding should be verified with a certificate (which contains a publi>c
key), instead of directly a public key value. CAs may deliver different
certificates with the same public key but with different attributes in
th>em.
It is important to know which certificate has been used, rather than whic>h
public key has been used, since several certificates may include the same>
public key.
As the text makes clear any such requirement should be communicated through
the UseKeyWith mechanism. XKMS does not address policy, it addresses only
PURPOSE. It is the job of the XKMS service to determine the mapping of
purpose to policy
Resolution - No Action
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.
Resolution - Editorial - some text to be merged - Not yet complete
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
explanati>ons
would be insufficient. It is thus requested to add more normative text an>d
to move the examples in an informative annex.
The core of a standard should not include examples which are not
mechanically verified against the specification itself. In this case the
examples have been mechanically validated against the schema. Moving the
examples to an appendix is unlikely to discourage engineers from programming
against them.
Resolution - No Change
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.
The remainder of the section goes on to specify this behavior.
Resolution - No action
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 nam>e
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 verificati>on
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 o>f
the certificate, otherwise a validity date should be included in the
request. The certification policy contained in the certificate may also b>e
helpful, unless it is specified in the request.
The KeyUsage Encryption is specified. The request asks for the certificate
and key value information. The example is therefore correct in this respect.
Resolution - No Action
12. The XKISS Validate service is defined as : "The XKISS Validate Servic>e
allows all that the Locate Service does, and in addition, the client may >
obtain an assertion specifying the status of the binding between the publ>ic
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>.
The exact processing is a matter for the service to decide as a matter of
policy. XKMS does not specify that the underlying PKI meet any particular
requirements.
Resolution No Action.
13. In [152] it is mentioned: "Furthermore the service represents that th>e
status of each of the data elements returned is valid and that all are
bo>und
to the same public key". A <ds:Keyinfo> element may contain a <ds:X509Dat>a>
element. Therefore the binding is not with a key but with a certificate.
No, the binding is of a key to an optional set of attributes that may
include a set of certificates.
Resolution No action
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
sect>ion
[215], but this should be clearly advertised upfront.
The means of specifying a request for a time in the past or future via the
<TimeInstant> element of <QueryBinding> is described in the detailed
description.
Resolution No Action
15. From its name, the XKISS Validate Service present a few similarities >
with the validation service requirements that have been defined by the PK>IX
WG from the IETF. This working group has produced RFC 3379 (Delegated Pat>h
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 th>e
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
s>ome
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.
The group was appraised of the existence of the document in question and
declined to consider it. RFC 3379 is based on very different assumptions as
to the purpose of the protocol.
Resolution: No action
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 text describes the possible use of the DNS srv record for this purpose.
Clearly other mechanisms can be proposed for this purpose, these are outside
the specification scope.
Resolution No action
17. The text in [168] states: "the Service represents to the client
accessing the service and to that client alone that the binding between t>he
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
pol>icy
is not supported, but should be supported.
The client is in no position to evaluate trust policies, if it were capable
of that it would not be necessary to delegate trust path processing in the
first place.
The facility being proposed may be defined using WS-Policy at a future date.
Resolution No Action
18. The text under [171] mentions: "The Id identifier is defined to provi>de
a means by which the key binding may be signed using XML Signature. Clien>ts
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. Th>e
ESSCertID from RFC 2634 is a good example of such a unique binding.
The Id in question is an XML construct that is provided for the sole purpose
described. It is not a key identifier in the PKIX sense. the XML element
KeyName should be used for that purpose.
Resolution No Action
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".
These uses would be specified using the UseKeyWith mechanism.
Non-repudiation is considered to be a property of a protocol or application
and not the result of a cryptographic operation itself. The purpose of these
element is to describe the purely cryptographic key usage purposes.
Resolution No Action
20. The text under [177] mentions the <UseKeyWith> element which specifie>s
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
wit>hin
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 shou>ld
be extended to make such difference.
Noted, the issue is not one of 'sender' and receiver but instead 'self' and
'other'. It is possible to imagine that a client might have need to ask
which key it should itself use for a particular protocol.
Resolution Editorial fix
21. The text under [180] mentions S/MIME as a protocol. Why is CMS
(Cryptographic Message Syntax) not considered as a protocol as well ?
In general it is advantageous to avoid proliferation of identifiers. CMS was
considered a component of a protocol rather than a protocol in its own
right.
Resolution - Discuss
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
structu>res.
There is clearly a utility in being able to specify that a key binding
should be usable with PKIX. This problem can be resolved by referring
instead to application
Resolution - Editorial
23. The text under [180] mentions the use of "Certificate Subject Name" a>s
an appropriate identifier. It should be observed that this name only is
insufficient to correctly identify an entity, since two CAs may certify t>he
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 t>o
a
root key, such names are ambiguous. This relates to the non-uniqueness of>
DN
names already mentioned.
This is the same point raised earlier. A comment to the effect is probably
warranted at this point
Resolution Editorial
24. The text under [180] identifies various protocols. To this list, XAdE>S
(XML Advanced Electronic Signature) which is a W3C Note issued on Februar>y
20, 2003 should be added (see: <http://www.w3.org/TR/XAdES/>
http://www.w3.org/TR/XAdES/). The
"identifier" type is such a case is a SigningCertificate element, i.e.
*n>ot*
a DN.
This is a status issue. A standard should not make a normative reference to
a note. However the XKMS group can request that the group in question amend
their draft to specify a URI to be employed in conjunction with
'usekeywith'.
In addition a note to state the default rules for constructing identifiers.
Resolution - Communicate issue to the group. Editorial
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
Valid>ate
Service is not sufficiently detailed.
Resolution Editorial
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
m>ade
against the proposed binding.
That is what happens if there is no binding found.
Resolution No Action
27. In the case of validation, the "yet not valid" response should be
considered, in particular when a certificate is suspended. This means tha>t
another validation request made later on may succeed.
These semantics can be adequately communicated through use of the validity
interval on an assertion. Each request is bound to a single instant in time.
Any additional information provided is optional, services should take care
not to send information that might become invalid while cached.
Resolution No action
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 inclu>de
the question to be answered.
2° it is necessary to have a face to face contact with the LRA before b>eing
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 th>e
end-user. However, this method is time consuming and does not allow a cos>t
effective deployment of a PKI.
It is suggested to use another technique that places all the burden of th>e
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 protocols support in face registration but do not require it. The
VeriSign XKMS interface is using the protocol described for non-in person
registration today.
Resolution No Action
29. In the example [241] several identifiers are included :
<UseKeyWith Application="urn:ietf:rfc:2459"
Identifier="C="US" O="Alice Corp"
CN="Alice Aardvark""/>
<UseKeyWith Application="urn:ietf:rfc:2633"
Identifier="alice@alicecorp.test"/>
<UseKeyWith Application=" <http://ca.example.com/cps/20030401/class3>
http://ca.example.com/cps/20030401/class3"
Identifier="alice@alicecorp.test"/>
It is unclear to understand how the concept of "UseKeyWith Application"
w>ill
be translated in an X.509 certificate, since an X.509 certificate does no>t
support the concept of "UseKeyWith Application".
There is a generic set of applications for which an X.509 certificate may be
used. If this use is specified with no greater precision then this
application identifier is appropriate.
Resolution No Action
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
wo>uld
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
generat>ed.
The main advantage is that no secret information is being used and no
out-of-bands mechanism is necessary.
The user is not expected to memorize the code. The server generated key case
is specifically for use in applications where the client is unable to
generate the key - typically because key recovery is being used.
Resolution No action
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.
OK, similar
Resolution Editorial
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).
This is a proposed semantic change.
Resolution Discuss
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.
The idea is that the revocation request should allow a request to be made
using minimal information for identification and authentication
Resolution Editorial
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.
I don't understand the second half of the comment.
Resolution Editorial
35. The security considerations section should be augmented to mention th>e
severe limitations that are indicated above.
These issues have already been addressed in the preceding text and changes
noted where necessary.
Resolution - No additional action
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, 23 July 2003 13:36:57 UTC