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

Re: 2.0 Draft 9

From: yassir elley <yassir.elley@Sun.COM>
Date: Thu, 27 Jun 2002 11:14:14 -0400
Message-ID: <3D1B2BC6.263A1A02@Sun.COM>
To: "Hallam-Baker, Phillip" <pbaker@verisign.com>
CC: "Www-Xkms (E-mail)" <www-xkms@w3.org>

Hi Phil,

For some reason, I am able to unzip the Draft 7 TestData.zip,
but am unable to unzip the Draft 8 or Draft 9 TestData.zip.
Would it be possible to just post the html for Drafts 8 and 9
to the list.


"Hallam-Baker, Phillip" wrote:
> All,
>         Attached is draft 9 of XKMS. This draft is very similar to draft 8
> except that the examples have been changed completely. The examples are now
> generated from code and so should be more representative. The file to look
> at is OverView.html, the subdirectories contain source.
>         There are a couple of oddities in the examples:
> 1) The certificates don't match the RSA Key values.
>         This is because I could not find an (easy) way to access the CAPI
> keys from the .NET framework. The private keys corresponding to the
> certificates are packaged up in P12s in the directory 'Certificates'. What I
> need to complete the example is a bit of code to break apart the P12 and
> export the private key values in XML syntax.
> 2) The canonicalization of the dsig signature elements may not be quite what
> is intended.
>         I can't quite figure out if transforming the xml signature element
> so that the namespace identifier is prefixed with DS is going to break the
> signature or not, I suspect it kinda mighta but did not have time to check
> it out fully or work out a fix.
>         While doing the examples I think I hit upon the problem with
> PassPhraseAuthentication. The element at present is being used for 2
> purposes which leads to ambiguity. These are:
>         1) Transport of a plaintext authentication key (e.g. from a SecureID
> or ActiveCard token)
>         2) Transport of a digested passphrase for revocation
>         I addressed this problem by introducing a new element for
> PassPhraseSecretAuthentication, the name might be better chose as
> 'RevocationPassphrase' or something.
>         The main outstanding protocol issue at this stage is the removal of
> status. I think we really do need it back in now I did the examples. In
> particular there is no way at present for a trust service to definitively
> specify that the status of a key binding is invalid.
>         The other issue I think still needs a bit of tweakage is the
> specification of the validity interval in a query as opposed to a response.
>         I think that what should happen is as follows:
>         1) No Validity interval specified
>                 The query is for the current time
>         2) Only a notBefore is specified
>                 The query is for that specific time instant
>                 The response should include the specified time instant
>         3) Only a notOnOrAfter is specified
>                 The query is for that specific time instant
>                 The response should include the specified time instant
>         4) Both specified
>                 The response should include the whole of the specified time
> interval
>         The revocation status of keys in the past needs some thought. There
> are multiple possibilities:
> 1) The key binding was valid
> 2) The key binding had been revoked
> 3) The key binding was advertised as valid at that time instant but was
> subsequently advertised as having been revoked and the revocation
> advertisement is predated to include the specified time instant
> 4) The key binding was advertised as valid, is currently revoked but the
> revocation advertisement does not indicate compromise at the specified time
> instant.
> I propose we reinstate 'Status' and specify the following values:
> Valid
>         The key binding is definitively valid at the specified time instant
> or interval
> Invalid
>         The key binding is definitively invalid at the specified time
> instant or interval
> Indeterminate
>         The key binding status could not be definitively determined at the
> specified time instant or interval
> And a sub-status (combine this with reason??) as follows:
> CompromiseAdvertised
> So thes match as follows:
> 1 Valid
> 2 Invalid
> 3 Invalid / CompromiseAdvertised
> 4 Valid / CompromiseAdvertised
> This means that a client looking to check the signature on a document will
> 'do the right thing' using status alone.
> However an application can still use an XKMS service to audit the operation
> of another party. In this case a discrepancy between the decision in the
> past and the current XKMS query may be explained by the existence of a
> CompromiseAdvertised sub-code reason. equally this would be the only case in
> which a client would normally ask for status for a time interval rather than
> an instant.
>         I am currently working on the partitioned draft with the bindings
> info separated into a different document...
>                 Phill
>   --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
>                    Name: TestData.zip
>    TestData.zip    Type: Zip Compressed Data (application/x-zip-compressed)
>                Encoding: base64
Received on Thursday, 27 June 2002 11:14:16 UTC

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