RE: Fwd: RE: [dss] Fwd: RE: UPU CPC EPM Positioning Proposal vis-a-vis the OASIS DSS

[Trevor Perrin <trevp@trevp.net>]

At 12:00 PM 7/11/2003 -0400, Edward Shallow wrote:

>Trevor, (please post)
>
>      A WSDL is a communications tool, and must convey service consumption
>information clearly and succinctly. The world understands timestamping and
>can easily associate with it and relate to it's nuances. You are losing
>focus by turning the interface definition into an exercise in normalization
>(or should I say abstraction and generalization). The final product will be
>a painfully flat WSDL.

I've pointed out how a protocol to produce timestamps, like RFC 3161, has 
identical requirements to a protocol to produce signatures:

"most of the requirements in the signing protocol would also apply to the 
timestamping protocol:
3.4.1 Selective Signing (you might want to selectively timestamp parts of a 
document)
3.4.2 Signature Placement (where to place the timestamp in the document)
3.4.3 Output Delivery (return the timestamped document, or just the timestamp)
3.4.4 Intended Audience (I just added this per Tim's request - who is going 
to process the timestamp)
3.4.5 Signing Policy (maybe the TSA has multiple timestamping certs it 
could use)"

"In each case, the client sends a hash or a bunch of documents to be hashed 
as input to creation of a "thingie", and receives back the document with a 
thingie (signature or timestamp) attached, or just the thingie itself.  The 
client tells the server what the thingie covers, where to place it, whether 
to return just it or the whole document, what audience it's intended for, 
under what policy it should be produced, and other things that should be 
placed inside it."

These commonalities result from the fact that a TST "is-a" signature.  Look 
at it, that's all it is - a signature over the input document and a time 
value.  Since a TST is just a type of signature, then a timestamping 
protocol is just a type of signature protocol.

Now I don't know WSDL.  If you'd like the timestamping protocol "to 
inherit" from the signature protocol, so it has a different name, or 
interface, or whatever, or if you'd like them both to inherit from an 
"abstract base protocol", or just be copies of each other with different 
names, that's fine, I don't care, and that seems like a detail we can 
hammer out later, about how profiles of the Signing protocol are related to 
each other.

But if you're arguing they need to have different *contents*, then I 
disagree, and I think you need to present more detailed arguments showing 
the differences.



>      Are saying that a SignAndVerifyAndTimeStamp request, which might
>legitimately take place at origin by a document author wishing 1) to have
>something signed (delegated), 2) have his own certificate Verified, and then
>3) have that signature TimeStamped poses no problem for your 2 verb protocol
>in terms of succinctness and callability ? Please show me.

I said,

"there's 2 issues here:
  - whether we need a separate Timestamp protocol, or can use the Sign protocol
  - how to support a Verify / ApplyPostmark operation (i.e. Verify and then 
Timestamp)

I'll tackle the first..."

I agree that Verify / ApplyPostmark is a challenging use case that's come 
from EPM, and I don't think we know how to handle it yet.  I've proposed 
some things that haven't impressed anyone, least of all yourself.

But my last comments weren't addressed to that case.


>      Will you be disallowing use of the optional nonce attribute in the DSS
>based on your arguments against its usefullness ?

I said:

"The nonce could be added to a "Timestamp profile" (as Nick suggested) of 
our Signing protocol, as an "Other Signed/Unsigned Attribute" that the 
client requests to be added into the produced signature or timestamp.

[As a side note, is it really needed?...."

I should have kept my musings to myself.  But if a nonce is needed, it can 
easily be acommodated per 3.2.3 which lets the Signer make additional 
contributions to the contents of the signature/timestamp.


>      You claim that your Signing Policy construct (as yet expalined or
>detailed) can handle the TSA policy separate from the SignaturePolicy
>associated with signature being produced (in a Sign call). These are 2
>separate policies. Will the DSS be able to delegate to a separate TSA, or
>are you saying that the DSS will be a TSA ?

Either would work.  The DSS protocol could be used by a TSA, or it could be 
used to produce other types of signatures, which it could return 
timestamped (by itself or someone else) or not.

>Do you honestly think it will be
>simpler for the caller ? As we get down into the detailed protocol
>development this will become much more apparent. You refuse to even
>ackowledge this possibility.

unsure what this is in reference to.


>      At a minimum, why don't you postpone this decision (i.e. to separate
>TimeStamp or not) ?

If the decision is how to name the wsdl interface/service/whatever for 
timestamping, and you just think it should have a name like 
"TimeStampProtocol" instead of "SigningProtocol", then I agree we should 
postpone this.

If you're arguing the Timestamp protocol needs different *contents* than 
the Signing protocol, then this is something we need to take into account 
in the requirements doc, if true.

Trevor