RE: Overuse of KeyBindingType

I generally like the structure Yassir has proposed.  I have a few
specific comments in-line below.

Blair

> -----Original Message-----
> From: Yassir Elley [mailto:yassir.elley@sun.com] 
> Sent: Wednesday, July 10, 2002 12:51 AM
> To: www-xkms@w3.org
> Cc: yassir.elley@sun.com
> Subject: Re: Overuse of KeyBindingType
> 
> 
> 
> 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.

Seems reasonable as its never been clear to me what this would be used
for.

> 
> 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 somewhere.]
> 
> 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 ValidateResult.

Not sure I agree with this.  Reasons explained under #3 below.

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

I agree.

> 
> <element name="AssertionStatus" type="AssertionStatusType" /> 
> <complexType name="AssertionStatusType">
>     <sequence>
>         <element ref="xkms:Status" />
>         <element ref="xkms:Reason" minOccurs="0" 
> maxOccurs="unbounded" />
>     </sequence>
> </complexType>
> 
> 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.

Agreed.

> 
> 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"

Perhaps, "I would like information on keys that match the KeyInfo and
are/were valid during the entire interval specified."  Or, should we
interpret this as 'at some point during the interval'?

> [KeyUsage*]: "I would like the key to be usable for ALL of 
> these KeyUsage's"

"I would like information on keys that were Registered with all the
specified KeyUsages".  XKMS can't enforce that keys are actually usable
or not usable for a given purpose, it can only inform relying parties as
to what a key was Registered for.

> [UseKeyWith*]: "I would like the key to be usable by ALL of 
> these UseKeyWith's"

Ditto KeyUsage - Registered for 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"]

I'd like to stay with the 3 we have and avoid the apparently
unresolvable differences of opinion regarding what other key usages,
such as some defined for PKIX, mean.

> 
> 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">
>     <sequence>
>         <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" />
>     </sequence>
> </complexType>
> <!-- /KeyBindingAbstractType -->
> 
> <!-- RequestKeyBinding -->
> <element name="RequestKeyBinding" 
> type="xkms:RequestKeyBindingType" /> <complexType 
> name="RequestKeyBindingType">
>     <complexContent>
>         <extension base="xkms:KeyBindingAbstractType">
>             <sequence>
>                 <element ref="xkms:KeyInfo" />
>             </sequence>
>         </extension>
>     </complexContent>
> </complexType>
> <!-- /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">
>         <sequence>
>             <element ref="xkms:RequestKeyBinding">
>         </sequence>
> </complexType>
> <!-- /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).

I don't believe the LocateResult should include AssertionStatus.  I have
always viewed the Locate service as logically equivalent to a directory
query.  I trust the Locate result to the extent I believe the service
keeps its DB up to date and prevents malicious modifications.  But I
expect the response to a Locate is simply whatever was in the DB at the
time of the query.  I don't expect any checking of the result nor do I
expect any attestation as to the correctness of the result.  Given that
view, any AssertionStatus would represent some status check done in the
past - but I don't know when it was done or by whom - so it isn't really
useful information.

I do expect accurate AssertionStatus results with each of the key
attributes returned in response to a Validate.  To my view this is
precisely what differentiates Validate from Locate.


> 
> 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"

I believe this should only be in Validate per the above.  If so, then
the 'I think' qualifier can be removed.

> [ValidityInterval]: "[I think] the key is valid during this interval"

I've had some minor concerns about the meaning of the KeyBinding
ValidityInterval in relationship to a Validity Interval as specified in
a certification returned as part of the KeyInfo.  Should this be
interpreted to mean the interval over which the XKMS service believes
the AssertionStatus associated with the key is correct?  This is
somewhat different than the time over which the key is expected to be
valid in the context of the returned KeyInfo attributes, which is what I
assume something like an X509 Cert validity interval is telling me.

> [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 Response?]
> 
> <!-- ResultKeyBinding -->
> <element name="ResultKeyBinding" 
> type="xkms:ResultKeyBindingType" /> <complexType 
> name="ResultKeyBindingType">
>     <complexContent>
>         <extension base="xkms:KeyBindingAbstractType">
>             <sequence>
>                 <element ref="xkms:KeyInfo" minOccurs="0" />
>                 <element ref="xkms:AssertionStatus" 
> minOccurs="0" maxOccurs="unbounded">
>             </sequence>
>         </extension>
>     </complexContent>
> </complexType>
> <!-- /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 
> RequestKeyBinding.]
> 
> <!-- XKISSResult -->
> <element name="XKISSResult" type="xkms:XKISSResultType" /> 
> <complexType name="XKISSResultType">
>     <extension base="xkms:ResultAbstractType">
>         <sequence>
>             <element ref="xkms:ResultKeyBinding" 
> minOccurs="0" maxOccurs="unbounded" />
>         </sequence>
> </complexType>
> <!-- /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 -->
> 
> Regards,
> Yassir.
> 
> 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, 17 July 2002 20:01:30 UTC