RE: Overuse of KeyBindingType

I concur, I really want to be able to distinguish between what is
essentially a directory service that supports a Locate function and a
Validation service and I want to be able to do it in the WSDL.

There are currently two problems which are a barrier to the deplopyment of
PKI. The complexity of trust path processing in realistic PKI topologies is
one of those, but the sheer problem of finding out any information about the
keys is a much bigger one.

Time after time PKI projects get derailed because an enterprise gets
captured by the X.500 mafia, many of whom have yet to realise that OSI is
deader than John Clease's parrot. We need to drive a steak through it heart.


I would like to see the barriers to establishing some form of 'border
directory' for key lookup to be set very low. Someone should be able to take
a standard XKMS locate server that supports secondary registration and
locate services and link it into the DNS to provide a key location service.
I don't want to force a high level of validation requirement onto such a
service, validation is a matter for the relying party, not the subject.


Perhaps that is what this comes down to, locate is a subject centric service
that undertakes to do no more than publish the subject's claims. The
Validate service is trusted by the relying party and acts on its behalf.


		Phill


> -----Original Message-----
> From: Stephen Farrell [mailto:stephen.farrell@baltimore.ie]
> Sent: Wednesday, July 24, 2002 10:37 AM
> To: Blair Dillaway
> Cc: Yassir Elley; www-xkms@w3.org
> Subject: Re: Overuse of KeyBindingType
> 
> 
> 
> 
> Some of Blair's comments on this are similar to thoughts we've
> been having here. We'd like our implementation to be liberal
> in processing Locates and downright pernickety in processing
> Validates.
> 
> If anyone has an idea for how to phrase that in a useful way
> in the spec (i.e. without reference to an implementation) I
> think that'd be good text to include.
> 
> Stephen.
> 
> Blair Dillaway wrote:
> > 
> > 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.
> > >
> > >
> 
> -- 
> ____________________________________________________________
> Stephen Farrell         				   
> Baltimore Technologies,   tel: (direct line) +353 1 881 6716
> 39 Parkgate Street,                     fax: +353 1 881 7000
> Dublin 8.                mailto:stephen.farrell@baltimore.ie
> Ireland                             http://www.baltimore.com
>

Received on Thursday, 25 July 2002 10:49:48 UTC