Re: [dss] FW: Here is the TimeStamp scope question to post to the list.

[Trevor Perrin <trevp@trevp.net>]

At 01:32 PM 9/17/2003 -0400, Rich Salz wrote:
>Content-Transfer-Encoding: 7bit
>
>>You'd like to see a sorta "micro-core" which has the *bare minimum* 
>>required to process signatures.  Maybe this is just the ability to send 
>>document(s) and get back a signature/signed document or verification response?
>
>Yes.  Let's get the bare minimum specified so that products can be built 
>and applications deployed.
>
>>Then everything else would be relegated to options, and profiles would 
>>mix-in some set of options into the micro-core?
>
>Yes.

Tim suggested the same approach at the F2F.  Sorta like pizza toppings - 
you've got a pizza, you've got some toppings, and the Profiles just name a 
set of toppings - Hawaiian = ham+pineapple, etc..

You're saying the core, cheese pizza should be easy to implement and 
deploy.  I was thinking of the core as more just a base that people derive 
Profiles from.

Another view on this stuff - there's 3 categories:
1) the micro-core, really core stuff
2) some important "core options" that we define, and that lots of profiles 
would re-use
3) other options that profiles introduce

So is (2) more like (1) or more like (3)?  I was thinking the "core 
options" would be part of the core schema (more like 1), and you're saying 
the "core options" should be treated like other options (more like 3).  Or 
rather - looking at your schema - that *everything* is just options.

Some questions about your approach -
  - can we agree on a minimal core?  If so, will it contain enough to be 
useful?  If every use-case is going to require some set of options and thus 
a Profile, then focusing on the core might not gain us anything.
  - If we treat lots of things as options, then they're not part of the 
core schema, right?  Or any schema?  So we lose the ability to organize 
things into nice groups, and we lose schema validation.  The protocol just 
becomes an unordered list of unstructured stuff.

But I don't think we can answer these, or determine their importance, till 
we look further -


>>If this makes sense, what exactly do you see in the micro-core?  For 
>>example, where would you allocate these things -
>
>Well, let me take a look.  Just my opinion, not any more valid than anyone 
>else's.
>
>>  - RequestID (to correlate requests/responses)
>
>If we define DSS to run over SOAP (we are doing that, right?)  Than this 
>isn't needed.  SOAP over HTTP is request/response.  Bindings for other 
>transports will have to be able to correlate request/response, so I don't 
>see a need to put this into the application protocol.

At the F2F people wanted it, so it could be an option.


>    Unlike XKMS, we're not defining a "I will get back to you" protocol, 
> where clients can get asynchronous responses.

It's a possible v2 feature, we could ignore for now.



>>  - ClaimedIdentity (the requestor's identity)
>
>Not in core.
>
>>  - IntendedAudience (who the signature is meant for)
>
>Not in core.

Make sense.



>>  - KeySelector (which key to use)
>
>Yes, a ds:KeyInfo can be a parameter.  DSS servers MUST support at least 
>the ds:KeyInfo/ds:KeyName element.

I'd leave this out of the minimal core, since the server will usually 
decide which key to use.



>>  - SignedProperties/UnsignedProperties (explicit properties to add into 
>> signature)
>
>I'm not opposed.  They are really ds:Object's, with a boolean saying 
>whether or not the server should add a ds:Reference to them or not.

We were going to do them as type/value pairs, with the idea that a lot of 
these types would have a CMS interpretation as well.

But again, I'd call this a low-level detail that the server will usually 
decide.



>>  - SignaturePlacement (where to stick the signature)
>
>I don't think we should require servers to have to be able to rewrite 
>input documents, so this is not in core.  However, the server does need to 
>know whether it is generating an enveloped signature or not, so I added that.

So you view the core server as generating signatures, not signed documents?

I think a server that takes a document and returns a signed document would 
be more useful to stupid clients.  Then the client doesn't even have to 
know where the signature goes.



>>  - SignatureContents (what the signature covers, and what transforms to 
>> apply to each thing)
>
>We need something like that, but I wonder how much of this is overlap with 
>the SignedProperties?

I'd separate them - input documents have transforms covering them, and they 
can be passed as "predigested" values, or URI 
references.  SignatureProperties wouldn't need these characteristics - 
instead they could be passed as type/value pairs, and could be handled 
uniformly for CMS or DSIG.


>   I also want to look at the Document types in more detail.  I think 
> there are really only five types to support in the core:
>      embeded base64 which server decodes to get the bytes to be signed
>      embedded xml fragment which is "safe" since user will use a c14n
>      embedded text fragment
>      external URI
>      a wrapper around dsig:DigestMethod and dsig:DivestValue elements (I 
> like the name dss:PreDigsted, myself :)
>
>>  - OutputOptions (what outputs to return - just the signature?  the 
>> document containing the signature?  The post-transformed Input documents?)
>
>Not sure yet.  post-transformed input seems like overkill;

Agreed, that shouldn't go in a minimal core.


>  we shouldn't require DSS servers to basically be XSLT engines.  In most 
> cases I believe the signature will be detached, so just returning the 
> signature should be in core.

Even if it's detached, does the client know where/how to splice it in?



>>I'm just curious what's the bare essentials you think our "core" or 
>>"micro-core" or whatever should support.
>
>These are, of course, just my opinions.  I think the hard part for us 
>would be to come to consensus on what the minimal set is -- what meets the 
>80/20 rule.

Yeah, exactly.  And if all our use cases are different enough, there may 
not *be* an 80/20 solution that we can agree on.

For example, my minimal schema would focus entirely on the Input/Output of 
Documents.  In fact, I'm inspired to make one.  I'll send it in another mail.


Trevor