RE: [dss] freezing doc, and next steps

[Gray Steve <steve.gray@upu.int>]

Hi Trevor

Yes, I can certainly provide quite a lot of additional supporting
documentation. How does this work, because I have various documents,
powerpoint presentations, etc, but I am reluctant to send some of this to
the general list.

Yes, the USPS EPM is associated with this project. 

There are a number of EPM services currently offered by the Posts, such as
USPS. This standard will harmonise those and establish the foundation for
those countries about to offer new services.  We are currently preparing to
move to the pilot stage with pilot customers to test the EPM in accordance
with our published standard. The UPU is also a standards organisation and we
have been through the first stage of that process to have the documented
standard approved. the next stage is to test and prove the standard using at
least two different applications.  Therefore, there are certainly
opportunities to change the standard and we would welcome any feedback and
recommendations from the DSS group.

I will prepare some more information to assist further discussions.


Regards


Steve Gray



-----Original Message-----
From: Trevor Perrin [mailto:trevp@trevp.net]
Sent: Wednesday, May 28, 2003 12:44 AM
To: Gray Steve; dss@lists.oasis-open.org
Subject: RE: [dss] freezing doc, and next steps


At 07:21 AM 5/27/2003 +0200, Gray Steve wrote:

>Dear Colleagues
>
>In reference to this discussion and the position of the postal industry's
>Electronic PostMark submission, I can provide a analysis below of the
>compliance status of our EPM interface standard to the Use Case
requirements
>document. I look forward to being able to discuss this further during
>Monday's teleconference.

Hi Steve,

Thanks for this analysis.  Is there other supporting documention for EPM 
besides the schema?  Though it's well commented, a doc explaining usage 
scenarios and rationales would be helpful.

Also, what's the status and schedule of EPM?  Is it currently being 
deployed?  Does it have any relation with US Postal Service EPM?  Is the 
standard pretty much finalized, or would it be possible for the DSS group 
to provide input and request features?

I don't understand EPM enough to comment much on the below analysis, but I 
can clarify a few points where the requirements doc isn't that clear:


>3.2.3 Signed and Unsigned Attributes
>
>Status: Supported
>
>Comments: If they like RFC 3126, we have it in spades. No problem.

The intention was that the client could send arbitrary signed/unsigned 
attributes.  Certain DSSs might allow the client to do this (e.g., if the 
DSS is just a "keyholder" for the client's convenience), certain ones might 
not.


>3.3.1 General
>
>This section is guidelines only. Supported by any XMLDSIG implementation.

These requirements need to be supported by the protocol also - the idea is 
that a single XML Signature might cover several different documents or 
fragments of documents, so the client would need to be able to send all 
these different documents and fragments to the server to sign/verify.

This is one of several cases where our requirements are complexified by the 
extreme flexibility of XML-DSIG compared to something like PKCS#7/CMS 
(other cases are the notions of Transforms, Signature Placement, and 
Selective Verification).  We were sort of designing to XML-DSIG, with the 
idea that anything simpler would just require a subset of this 
functionality.  In contrast, EPM seems designed to PKCS#7, with the idea 
that XML-DSIG could be plugged in instead, but without much special support 
for the complications of XML-DSIG.

That's not necessarily bad.  Maybe DSS should give up trying to support all 
these complications too.  Or maybe EPM can be extended.  But as things 
stand, this seems a big difference between the DSS requirements and EPM.

>3.3.3 Input Delivery
>
>Status: Supported
>
>Comments: We use SOAP.

This requirement is supposed to mean that the client can communicate a 
to-be-signed document either directly or via a URI.  I'm not sure, but if 
EPM's "Data" element within "SignRequestType" is how the to-be-signed 
document is communicated, then we'd want to generalize this to support a 
URI as well as base64-coded data,


>3.4.1 Selective Signing
>
>Status: Neutral
>
>Comments: This is the domain of XMLDSIG.
>
>
>3.4.2 Signature Placement
>
>Status: Neutral
>
>Comments: This is the domain of XMLDSIG.

What do you mean by this, exactly?  That these requirements are out of 
scope for EPM?  Could EPM be extended to handle them?



>3.4.3 Output Delivery
>
>Status: Not Applicable
>
>Comments: We believe that this is outside the scope of the protocol.
>Presently we handle an RPC-style request/response paradigm as provisioned
by
>SOAP.
>
>
>3.4.4 Signature Policy
>
>Status: Supported
>
>Comments: This again is outside the core protocol and already covered by
RFC
>3126 and ETSI 101 733. We do support Signature Policy as mandated by these
>standards.

This requirement is poorly named.  We meant a policy identifier that's only 
used by the client to signal to the server what type of signature he (the 
client) wants (see the bullet points).



>3.4.5 Explicit Signed / Unsigned Attributes
>
>Status: Too Vague to Ascertain
>
>Comments: Needs to be further specified. RFC 3126 mandates Signature Policy
>signed attributes which we support. Others must be examined on an
individual
>basis.

See my response to 3.2.3 above.


Trevor 


You may leave a Technical Committee at any time by visiting
http://www.oasis-open.org/apps/org/workgroup/dss/members/leave_workgroup.php