[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [dss] freezing doc, and next steps
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. 2.1 Corporate Seal Status: Suppported Comments: This is supported via the EPM Sign operation which is configured at installation to use any subscriber private key for signing (i.e. a configuration item) 2.2 SOAP Signing Status: Supported Comments: This I assume to mean inline signing of all SOAP messages traversing a gateway or equivalent proxy setup. This can easily be done with the vanilla EPM and some gateway specific client code again calling our Sign operation. 2.3 Identified Requestor Status: Supported Comments: This is supported in spades !!! See our Participating Parties construct working conjunction with our AccessScope option of the StartLifecycle operation. 2.4 Individual Signatures Status: Supported Comments: The Posts told us that delegated signature creation was not in keeping with prevailing Digital Signature Laws. However, similar to item (2.3) above, we can support configuration of several Individual signing keys. 2.5 Long Term Corporate Signatures Status: Supported Comments: Again this feature is supported in spades through our use of ETSI 101 733 ES-C. 2.6 Delegated Signature Verification Status: Supported Comments: Don't like the title of this requirement as it is not consistent with actual details of the request and response requirements. However RFC 3126 and ETSI 101 733 mandate Signature Policy Usage, which we support in both explicit and implied variations. 2.7 Securing the Transform Chain Status: Partially Supported Comments: I agree with the authors assertion that most transforms are already covered by XMLDSIG. We do not presently sign over stylesheets but easily could add this feature. 2.8 Non-XML Data Signing Status: Supported Comments: No problem. We have been doing this for 2 years. 2.9 eNotarization in Presence of Notary Status: Neutral Comments: We do not agree that this feature should be a protocol issue. For example if we EPM-enabled a Canadian Bar Association application or a specific application utilized within Doyle, Selusci, Jacobs, and Associates ... we would have accompished all that this requirement is intending to achieve without burdening the protocol. Besides this is the domain of RFC 3126 and ETSI 101 733 Signature Policy anyway. 2.10 Court Filings Status: Neutral Comments: We saw no need to standarized the whole Challenge Support and Evidence Submission process due to the huge differences across jurisdictional and country boundaries, ot to mention the distinct court processes across levels of government even withina jurisdiction. We considered this very low priority in terms of relative value and importance. 2.11 Client-Side Hashing Status: Supported Comments: Although client-side activities are out of scipe for a DSS, and the fact that we support numerous client signing technologies, we do support the verification of a signature created over a hash originally performed on the client-side. 2.12 Time-stamping and Time-marking Status: Supported Comments: No problem. Fully support OASIS requirement and much more. 3.1.1 To-Be Signed Format Status: Supported Comments: Fully supported. 3.1.2 Signature Format Status: Supported Comments: Fully suppoprted. No problem. 3.2.1 Requestor Identity Status: Not Applicable Comments: As the requirement states, this will be left the the upper level application standards that make use of DSS. 3.2.2 Signing Time Status: Supported Comments: Fully supported 3.2.3 Signed and Unsigned Attributes Status: Supported Comments: If they like RFC 3126, we have it in spades. No problem. 3.3.1 General This section is guidelines only. Supported by any XMLDSIG implementation. 3.3.2 Input Preparation Status: Supported Comments: Fully supported. 3.3.3 Input Delivery Status: Supported Comments: We use SOAP. 3.3.4 Authentication Status: Supported Comments: Agree with author's options. 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. 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. 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. 3.5.1 Signature Placement Status: Not explicitly supported Comments: Can be added. 3.5.2 Output Delivery Status: Supported Comments: Fully supported. 3.6.1 Selective Verification Status: Not Supported Comments: Not easily acconplished. 3.6.2 General Staus: Partially supported. 3.7.1 Failure Information Status: Supported Comments: See TransactionStatus complexType. 3.7.2 Signature Information Status: Supported Comments: Fully supported 3.7.3 Transformed Signed Data Status: Not supported 3.7.4 Time-stamp and Time-mark Status: Supported Comments: Fully supported 3.7.5 Information used in Verification Status: Supported Comments: Fully supported as per RFC 3126 3.8 Query requirements Status: No suppported Comments: Good Idea, not currently supported, can be added Regards Steve Gray -----Original Message----- From: Robert Zuccherato [mailto:robert.zuccherato@entrust.com] Sent: Monday, May 26, 2003 9:50 PM To: 'Nick Pope'; dss@lists.oasis-open.org Subject: RE: [dss] freezing doc, and next steps Nick; I don't think I necessarily disagree with that approach. I see advantages and disadvantages with either approach. If it is the consensus of the group to develop one basic protocol that can be used for all DSS functionality, I think I can live with that. However, I would like to point out that doing so will likely mean starting from scratch, which is fine, but should be compared with having two or three different protocols which can be developed more quickly (since we have a starting point for some of them). Especially if we decide to go with one protocol framework, I would recommend a face-to-face to kick-off the protocol work and give us a really good starting point. Robert. > -----Original Message----- > From: Nick Pope [mailto:pope@secstan.com] > Sent: Saturday, May 24, 2003 10:20 AM > To: Robert Zuccherato; dss@lists.oasis-open.org > Subject: RE: [dss] freezing doc, and next steps > > > Robert, > > If there is a separate protocol for time-stamping, what about > time-stamp > verification? > > I still believe that the time-stamping and other DSS uses > should be aligned > as far as possible, so that features such as verification can > be applied to > both. I agree that some of the signature attributes will be > different but > any common features should have the same elements. > > I still prefer using the same basic protocol to avoid unnecessary > inconsistencies in the approach and wasted effort. > > Nick > > PS I am away for a few days, back on line Tuesday > > > -----Original Message----- > > From: Robert Zuccherato [mailto:robert.zuccherato@entrust.com] > > Sent: 23 May 2003 18:29 > > To: 'Nick Pope'; dss@lists.oasis-open.org > > Subject: RE: [dss] freezing doc, and next steps > > > > > > Nick; > > > > It seems to me that at least for the signature verification and > > timestamping > > protocols, a number of the submissions, including Entrust's > comes fairly > > close. Of course, nothing is going to have all of the > > requirements exactly, > > but they could be used as good starting points. > > > > I guess the question then is, do we want to have three > separate protocols > > (one for signature generation, one for signature > verification and one for > > timestamping), or do we want to have one protocol that includes > > functionality to support all three? > > > > Robert. > > > > > -----Original Message----- > > > From: Nick Pope [mailto:pope@secstan.com] > > > Sent: Thursday, May 22, 2003 3:49 PM > > > To: Trevor Perrin; Juan Carlos Cruellas; dss@lists.oasis-open.org > > > Subject: RE: [dss] freezing doc, and next steps > > > > > > > > > I would say that we have to use the requirements document as > > > the starting > > > point. None of these documents match what was in the > > > requirements document. > > > > > > Nick > > > > > > > -----Original Message----- > > > > From: Trevor Perrin [mailto:trevp@trevp.net] > > > > Sent: 22 May 2003 18:51 > > > > To: Juan Carlos Cruellas; dss@lists.oasis-open.org > > > > Subject: [dss] freezing doc, and next steps > > > > > > > > > > > > At 04:30 PM 5/20/2003 +0200, Juan Carlos Cruellas wrote: > > > > > > > > >Dear all, > > > > > > > > > >As version 6 of the document on requirements has been > > > issued I think that > > > > >we could try to raise comments as soon as we have had time to > > > > read it in order > > > > >to have an idea of how far we are of freezing it . This > > > would allow to > > > > >elaborate a more suitable agenda for the next meeting. > > > > > > > > I'd be happy with freezing it soon. Not that it's perfect, > > > but I think > > > > it's helped clarify things enough that we're ready to get into > > > > detailed work. > > > > > > > > Robert raised good questions about what the next steps > should be. > > > > Maybe we > > > > should discuss these on-list, and try to make some > > > decisions at the next > > > > meeting: > > > > - should we use a submission as a starting point? > > > > - should we start with a face-to-face meeting? > > > > > > > > Below are the submissions I remember, if this helps: > > > > > > > > Entrust signing, verifying, time-stamping: > > > > > <http://lists.oasis-open.org/archives/dss/200211/msg00003.html>htt > > > p://lists.oasis-open.org/archives/dss/200211/msg00003.<http:// > > lists.oasis-op > > > en.org/archives/dss/200211/msg00003.html>html > > > > > > ISSE time-stamping: > > > <http://lists.oasis-open.org/archives/dss/200212/msg00004.html > > > >http://lists. > > > > > > oasis-open.org/archives/dss/200212/msg00004.<http://lists.oasi > > > s-open.org/arc > > > hives/dss/200212/msg00004.html>html > > > > > > EML time-stamping: > > > <http://lists.oasis-open.org/archives/dss/200212/msg00012.html > > > >http://lists. > > > > > > oasis-open.org/archives/dss/200212/msg00012.<http://lists.oasi > > > s-open.org/arc > > > hives/dss/200212/msg00012.html>html > > > > > > Karel Wouters time-stamping: > > > <http://lists.oasis-open.org/archives/dss/200301/msg00001.html > > > >http<http://l > > > ists.oasis-open.org/archives/dss/200301/msg00001.html>://lists > > > .oasis-open.or > > > g/archives/dss/200301/msg00001.html > > > > > > Electronic > > > > PostMark:http://lists.oasis-open.org/archives/dss/200302/msg00016.html > > > http://lists.oasis-open.org/archives/dss/200304/msg00076.html > > > (more recent) > > > > > > XAdES: > > > http://lists.oasis-open.org/archives/dss/200302/msg00028.html > > > > > > > > > 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_wor > kgroup.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 > > > > 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]