[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [dss] freezing doc, and next steps
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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]