wd-09

[Trevor Perrin <trevp@trevp.net>]

Happy new years all,

Here's the core spec with only slight changes (typo fixed, added a sentence 
for clarification, changed order of <SignResponse> child elements).  Plus a 
pdf version.  I'll put these on the OASIS site once it's recovered from the 
holidays.
http://trevp.net/dss/oasis-dss-1.0-core-spec-wd-09.doc
http://trevp.net/dss/oasis-dss-1.0-core-spec-wd-09.pdf
http://trevp.net/dss/oasis-dss-1.0-core-schema-wd-09.xsd


This is the start of the timestamping profile, which could hopefully serve 
as a template/example for other profiles, at least once it's improved:
http://trevp.net/dss/oasis-dss-1.0-timestamping-profile-spec-wd-01.doc
http://trevp.net/dss/oasis-dss-1.0-timestamping-profile-spec-wd-01.pdf


While looking at timestamping, some interesting questions popped up:

Bindings
--------------
We'll probably only have a few bindings.  Since most profiles will use one 
of these, maybe the bindings should be described in the core document?  Or 
we could have a "bindings and profiles" document, with our initial set of 
bindings and profiles; that would be more SAML-like, however in our last 
meeting we were leaning towards putting each profile in a separate document.

So we could add a "Bindings" section to the core spec, right after the "DSS 
Core Elements" section.  It might be a good idea for someone else to tackle 
this, to speed things up and bring in more expertise.

It could be a fair amount of work - we'll have to decide which bindings to 
support (SOAP 1.1 or 1.2?  Both?  Should we support a straight-HTTP POST 
binding, without SOAP, for greater simplicity?).  We should also discuss 
bindings in the context of security (things like TLS and WS-Security, 
etc.).  There's lots of examples to look at, at least: XKMS, SAML, RFC 
3161, etc...


Which Security Binding is required for Timestamping?
-----------------------------
It's possible for the client to authenticate the signing server by 
verifying the returned signature.  This is more efficient than using a 
separate signature, or negotiating TLS.  This approach does require a nonce 
to be sent by the client, and placed in the returned signature - see Tim's 
point #4:
http://lists.oasis-open.org/archives/dss/200308/msg00015.html

I think this is how RFC 3161 is usually deployed.  In fact, this approach 
could work with *any* use of the signing protocol, if you add nonces to the 
signing requests and returned signatures.  However, the efficiency gains 
have some downsides:
  1) in the case of errors, the server's result codes aren't authenticated
  2) any unsigned signature attributes or other signature parts (e.g. 
<ds:KeyInfo>) aren't authenticated
  3) any returned optional outputs aren't authenticated
  4) compared to, say, TLS, there's less confidentiality

For now, the timestamping profile says to use server-authenticated 
TLS.  However, the timestamping protocol doesn't have optional outputs (3), 
and it sends document hashes so confidentiality (4) isn't much of an 
issue.  So this is worth thinking about...


Profiling XMLTimeStampToken
----------------------------------------------
We can produce "protocol profiles" for the DSS signing/verifying protocols, 
for use in creating/verifying XMLTimeStampTokens.

Do we need "XMLTimeStampToken profiles" as well?  In particular, the 
<ds:KeyInfo> field within a <dss:XMLTimeStampToken> could carry different 
types of key info - X.509, XKMS, PGP, etc..  Do we want <XMLTimeStampToken> 
to be flexible to allow TSAs from these different infrastructures?  If so, 
we'll need the added complexity of profiling <XMLTimeStampToken>, and 
different <XMLTimeStampToken>-producing TSAs can't be assumed to be 
interoperable.

Otherwise, we could say that <XMLTimeStampToken> is just an XML version of 
an X.509-based RFC 3161 TimeStampToken, and so it should be X.509-based as 
well.  In this case, the definition of <XMLTimeStampToken> in the core spec 
should restrict <ds:KeyInfo> to containing a Distinguished Name, to be like 
RFC 3161 (assuming that's a good way of identifying a TSA and its key; I'm 
not sure).

If we decide to make <XMLTimeStampToken> flexible and profilable, then we 
could still probably use a single timestamping profile for creating and 
verifying XML timestamps.


Trevor