2.0 Draft 9

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