[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [dss] freezing doc, and next steps
I have just posted to the TC website two documents from Steve Gray relating to the USPS EPM. I would encourage TC members to take a look at these as we will discuss the EPM at the meeting on Monday. The EPM Project Overview Powerpoint presentation is available at: http://www.oasis-open.org/apps/org/workgroup/dss/download.php/2345/EPM%20Pro ject%20Overview%20May%202003%20V3Short.ppt What is the Electronic Postmark Word document is available at: http://www.oasis-open.org/apps/org/workgroup/dss/download.php/2346/What%20is %20the%20Electronic%20PostMark%20V4.doc Thanks, Robert. > -----Original Message----- > From: Gray Steve [mailto:steve.gray@upu.int] > Sent: Wednesday, May 28, 2003 12:30 PM > To: 'Trevor Perrin'; dss@lists.oasis-open.org > 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 > > 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]