W3C home > Mailing lists > Public > www-xkms@w3.org > July 2002

Re: Overuse of KeyBindingType

From: Yassir Elley <yassir.elley@sun.com>
Date: Wed, 10 Jul 2002 03:51:25 -0400
Message-ID: <3D2BE77D.84B920F7@sun.com>
To: www-xkms@w3.org
CC: yassir.elley@sun.com

As promised, here is a proposal for redesigning the XKMS
schema so it is clearer. I have intentionally tried to make bold statements
so that those who disagree can challenge me. I think this approach will lead to a
more precise specification. Also, I have not rolled in any of Blair's
multiple request stuff since it is not currently in Draft 9.

First, some shorthand:

element without any qualifiers means one and only one element allowed:
    (i.e. minOccurs="1", maxOccurs="1")
element in brackets (e.g. [element]) means element is optional:
    (i.e. minOccurs="0")
element followed by * (e.g. element*) means multiple elements allowed:
    (i.e. maxOccurs="unbounded")
element followed by star in brackets (e.g. [element*]) means element is optional,
 but multiple elements allowed
    (i.e. minOccurs="0", maxOccurs="unbounded")

0) ProcessInfo
ProcessInfo is currently on the Outstanding Issues list and is probably going to be
deleted unless there is a compelling reason not to. As a result, I have dropped it for
the rest of this proposal. If we decide to keep it, we can just additionally insert it
everywhere that  we currently have the <other> element.

1) AssertionStatus = Status + Reason(s)
1a) The Reason element is used to qualify a Status element. Therefore, the Reason
element only makes sense in conjunction with a Status element. As a result, we
introduce a NEW AssertionStatus element (not to be confused with the OLD
AssertionStatus element), which consists of a single Status, along with zero or more
Reasons. [Issue: In theory, the Reason element could be used without a Status
element in the case where a client sends a ValidateRequest with a request parameter
of Reason="IssuerTrust" meaning that the client only wants the Validate service
to return an assertion about the "IssuerTrust" and "ValidityInterval" aspects, but not
about the "RevocationStatus" aspect or any other aspect. This may be a common
case in deployments where revocation is not supported. However, perhaps this
would be better solved by having a separate checkRevocation boolean element

1b) A particular Result may have more than one AssertionStatus, with each AssertionStatus
having different Reason(s). For example, a particular Result for a single KeyBinding
may assert that the "IssuerTrust" Reason is "Valid", the "ValidityInterval" Reason is
"Invalid", and the "RevocationStatus" Reason is "Indeterminate".

1c) The acceptable values for the Reason element MUST be extensible.
[Issue: Is Reason already extensible?]

1d) The AssertionStatus element MAY be included in LocateResult and

1e) The AssertionStatus element MUST NOT be included in LocateRequest,
ValidateRequest, or any of the Register/Reissue/Revoke/Recover
Request/Result  messages.

<element name="AssertionStatus" type="AssertionStatusType" />
<complexType name="AssertionStatusType">
        <element ref="xkms:Status" />
        <element ref="xkms:Reason" minOccurs="0" maxOccurs="unbounded" />

2) Locate/Validate Requests
2a) A client MUST be able to specify exactly the same request parameters
whether they are calling Locate or Validate. As a result, LocateRequest and
ValidateRequest MUST be identical. Of course, the Locate service does
not vouch for the correctness of the result, while the Validate service does
vouch for the correctness of the result, but this has no effect on the requests.

2b) The request parameters for Locate/Validate includes:
KeyInfo: "I would like the key described by this KeyInfo"
[ValidityInterval]: "I would like the key to be valid during this interval"
[KeyUsage*]: "I would like the key to be usable for ALL of these KeyUsage's"
[UseKeyWith*]: "I would like the key to be usable by ALL of these UseKeyWith's"
[other*]: placeholder for extensibility

[Issue: Currently KeyUsage is limited to only 3 values. Do we want this to be
extensible? I am assuming we do, resulting in the maxOccurs for KeyUsage being
"unbounded" rather than being "3"]

2c) The request parameters for Locate/Validate MUST NOT include:
AssertionStatus: client is always going to be implicitly asking for a Status of "Valid"
PassPhrase: this is only useful for Register/Reissue/Revoke/Recover

2d) We introduce a new RequestKeyBinding element which handles (2b) and (2c)

<!-- KeyBindingAbstractType -->
<complexType name="KeyBindingAbstractType" abstract="true">
        <element ref="xkms:ValidityInterval" minOccurs="0" />
        <element ref="xkms:KeyUsage" minOccurs="0" maxOccurs="unbounded" />
        <element ref="xkms:UseKeyWith" minOccurs="0" maxOccurs="unbounded" />
        <any namespace="##other" processContents="lax" minOccurs="0" maxOccurs="unbounded" />
<!-- /KeyBindingAbstractType -->

<!-- RequestKeyBinding -->
<element name="RequestKeyBinding" type="xkms:RequestKeyBindingType" />
<complexType name="RequestKeyBindingType">
        <extension base="xkms:KeyBindingAbstractType">
                <element ref="xkms:KeyInfo" />
<!-- /RequestKeyBinding -->

2e) Since XKISS consists of Locate and Validate, and since LocateRequest is
identical to ValidateRequest, we introduce a new XKISSRequest, which subsumes
the previous LocateRequest and ValidateRequest.

<!-- XKISSRequest -->
<element name="XKISSRequest" type="xkms:XKISSRequestType" />
<complexType name="XKISSRequestType">
    <extension base="xkms:RequestAbstractType">
            <element ref="xkms:RequestKeyBinding">
<!-- /XKISSRequest -->

3) Locate/Validate Results
3a) While a Locate service "SHOULD attempt to provide only information which
is trustworthy to the best of its knowledge," the Locate service is not required to
make an assertion about the information it provides. On the other hand, a Validate
service is required to make an assertion about the information it provides.

3b) The Locate and Validate results are identical, with the exception that
the LocateResult is purely advisory (i.e. the Locate service doesn't vouch for the
response) while the ValidateResult is more definitive (i.e. the Validate service
vouches for the response).

3c) The response parameters for Locate/Validate include:
[KeyInfo]: "[I think] this is a KeyInfo for the key you requested"
[AssertionStatus*]: "[I think] the key has these AssertionStatus's"
[ValidityInterval]: "[I think] the key is valid during this interval"
[KeyUsage*]: "[I think] the key is usable for ALL of these KeyUsage's"
[UseKeyWith*]: "[I think] the key is usable for ALL of these UseKeyWith's"
[other*]: placeholder for extensibility

Note: The [I think] clauses are included for Locate and deleted for Validate.

3d) The response parameters for LocateResult MUST NOT include:
PassPhrase: this is only useful for Register/Reissue/Revoke/Recover

3e) We introduce a new ResultKeyBinding element which handles (3c) and (3d)

[Issue: The term Request/Response is more familiar than the term
Request/Result. Should we change all instance of the word Result to

<!-- ResultKeyBinding -->
<element name="ResultKeyBinding" type="xkms:ResultKeyBindingType" />
<complexType name="ResultKeyBindingType">
        <extension base="xkms:KeyBindingAbstractType">
                <element ref="xkms:KeyInfo" minOccurs="0" />
                <element ref="xkms:AssertionStatus" minOccurs="0" maxOccurs="unbounded">
<!-- /ResultKeyBinding -->

[Note: The only difference between RequestKeyBinding and ResultKeyBinding is
that ResultKeyBinding has an AssertionStatus element and also
that the KeyInfo element in ResultKeyBinding is optional, whereas it is required in

<!-- XKISSResult -->
<element name="XKISSResult" type="xkms:XKISSResultType" />
<complexType name="XKISSResultType">
    <extension base="xkms:ResultAbstractType">
            <element ref="xkms:ResultKeyBinding" minOccurs="0" maxOccurs="unbounded" />
<!-- /XKISSResult -->

4) PassPhrase
[Note: I'm somewhat unsure about this one since PHB just changed this stuff in
Draft  9, but I'll take a stab at it anyway]
4a) The PassPhrase element is needed only when PassPhraseAuthentication is used.
As a result, the value of PassPhraseAuthentication can simply be the
PassPhraseValueType rather than what it currently is (i.e. a String).
[Issue: The spec includes a separate PassPhraseSecretAuthentication element only
used for revocation messages. However, no schema is specified for this. I'm also
not sure what this is used for.]

<!-- PassPhraseAuthentication -->
<element name="PassPhraseAuthentication" type="PassPhraseAuthenticationType" />
<element name="PassPhraseAuthenticationType" value="PassPhraseValueType"/>
<!-- /PassPhraseAuthentication -->


Yassir Elley wrote:

> KeyBindingType is used in both the ValidateRequest and the ValidateResponse.
> This is somewhat forced since some of the elements of KeyBindingType don't
> make sense for the ValidateRequest (such as status, which will always be valid implcitly, as Joseph
> pointed out). Other elements, such as ValidityInterval and KeyUsage could make sense (i.e. the
> client is requesting the service to find a key that has the specified KeyUsage or that that is valid
> during the specified ValidityInterval), but it is unclear whether they are there just as hacks (such
> as Status), or whether they are actually meant to be there. In any case, we need additional text
> specifying exactly what is meant by a ValidateRequest. I must say that Joseph's query approach
> certainly makes it clearer (to me) and more explicit what is going on in the Request.
> Additionally, the KeyBindingType is also used with
> {Register,Reissue,Revoke,Recover}Request/Response. This is also awkward
> because it forces us to include the PassPhrase element in KeyBindingType, even
> though this will never be used with the ValidateRequest/Response (right?). I realize that
> many of these elements are optional, but it is just confusing the way it is now.
> If all of these Requests and Responses do indeed use some of the same data that we
> don't want to bother duplicating, we should
> create another abstract type (KeyBindingAbstractType?) that can be extended (or even a non-abstract
> type that can be included) that contains common elements, and have additional
> elements that are specific to a particular kind of request or response be included in the
> declaration of that request or response.
> By the way, I noticed we have a catch-all called ProcessInfoType. We should include
> some text giving an example use of this. Can someone give a compelling example of its
> use?
> -Yassir.
Received on Wednesday, 10 July 2002 03:53:56 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:31:39 UTC