RE: 2.0 Draft 9

Thanks for all the work you put in getting this updated.  Helps a lot to
see all of the changes we've discussed pulled together with examples.
Also, love those paragraph numbers.  

My one substantive comment regards the revisions to KeyBinding and its
use.  
1. I thought we had agreed to re-factoring KeyBinding into a set layered
types targeted to the needs of each of the services.  I still believe we
need to do this.  Has there been any progress on this front?
2. I do not agree with removal of the Status element from KeyBinding (as
used in Validate).  As you noted, without this we have no way to
indicate the status of each returned KeyBinding.  Trying to determine
this by interpreting reason codes doesn't seem straightforward.
3. By using the single defined KeyBinding in both Locate and Validate,
we have effectively made these two indistinquishable.  I would argue for
keeping the current KeyBinding usage for Locate and creating a new
KeyBinding sub-type with additional members for use with Validate.

Other stuff:

[Paragraph 12] 1st sentence should be something like "Both protocols are
defined in terms of structures expressed in the XML Schema Language.
Bindings of these structures into SOAP v1.1 messages are defined and the
relationship among these  messages defined using WSDL.

[Section 3.2] The discussion refers several times to Validate returning
status about the binding between a key and other data, but we no longer
have an status element to return this in.  I assume the idea is one can
figure it out from the reason code, which I'm not comfortable with.

[Section 4.2.8] The reason codes dicussion no longer makes any sense as
the 'AssertionStatus' element it refers to is no longer present.

I'll send comments on the protocol binding section separately now that
you've moved it into a separate doc.

Blair

-----Original Message-----
From: Hallam-Baker, Phillip [mailto:pbaker@verisign.com] 
Sent: Thursday, June 20, 2002 10:02 AM
To: Www-Xkms (E-mail)
Subject: 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

Received on Monday, 1 July 2002 19:26:57 UTC