OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

dss message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]

Subject: RE: [dss] Groups - Signature Gateway Profile 08 (oasis-dss-1[1].0-profiles-siggty-spec-wd-08.doc) uploaded


A few suggestions:

1) In 1.1

I think that the text "may ensure interoperability" overstates what can be achieved.  I suggest "should be interoperable at the levels of protocol defined in the profile."

2) In 1.1

Suggest "An implementer does not require a security binding; and may consider security bindings to be optional." ->

 "The addition of security to these bindings is optional."

2+) 1.2

It would be useful to describe that "ServicePolicy" is used to control the transformation function from input signature to output signature.

Also, it should be made clear that the profile only supports XML signatures.

3) In 2.1.3

It states "Full DSS Signature Gateway compliance restricts <AdditionalProfile> identifiers to those explicitly standardized as concrete identifiers."

What do you mean by "standardized as concrete identifiers"?  Are you expecting other concrete profiles to be standardized?  Or is there to be a registration scheme for the identifiers?

4) In 2.3

It states "This profile is an abstract profile which is not implementable directly.  This profile is intended to be combined with a transport binding of the [DSSCore], or a transport binding defined in a subordinate sub-profile"

This does not match with earlier statements that:
a) this document defines concrete profiles: 
b) an identified concrete profile is required.

5) 2.5

This needs to be updated to specify the two transport bindings defined for concrete profiles.

6) 3.1, 3.2 

To allow this profile to be used on a server in conjunction with others I would suggest "Is prohibited" is changed to "is not supported".

7) Content of Service policy

I suggest that the signature policy defines the requirements of form of signature coming in and going out (e.g. set / class of algorithms, signature properties).

Under validation policies "Manifest".  I suggest that this is extended to cover not just manifest by all references in the main <ds:signature><signedInfo> reference element.

Also, I suggest that the policy should identify whether it validates signatures on timestamps.


What does "the syntax of the defined <dss:ServicePolicy> constant" mean. 

Also, what is meant by "Otherwise, the Gateway may advertise both the syntax and semantics through out-of-band means."  Isn't always necessary to have a precisely defined policy?   Isn't the definition always going to be made available by means outside the scope of this profile.

I would suggest text is required that makes the following points:

The service policy must be specified (in a human readable format???).   The specification must include topics identified in this section.  This specification must be available to clients.  How the specification is made available is outside the scope of this profile.

8) A thought: Is it this a simple extension to apply the profile to CMS based signatures???? 


Also if you feel that the latest comments justify it I would welcome being added to the list of contributors.

> -----Original Message-----
> From: glenn.benson@chase.com [mailto:glenn.benson@chase.com]
> Sent: 29 March 2005 16:02
> To: dss@lists.oasis-open.org
> Subject: [dss] Groups - Signature Gateway Profile 08
> (oasis-dss-1[1].0-profiles-siggty-spec-wd-08.doc) uploaded
> Signature Gateway Profile: Version 08
>  -- Glenn Benson
> The document named Signature Gateway Profile 08
> (oasis-dss-1[1].0-profiles-siggty-spec-wd-08.doc) has been submitted by
> Glenn Benson to the OASIS Digital Signature Services (DSS) TC document
> repository.
> Document Description:
> Action 05-03-21-1:
> - single document with one abstract and two concrete identifiers: See
> changes in Section 1.1, 2.1, 2.1.3
> - identifier should only reference the major version number: See 
> changes in
> Section 2.1
> - additional concrete profiles may be made by either extending
>  current document, or adding new documents: See changes in Section 1.1,
> 2.1, 2.1.3
> Other changes: Appendix A: Revision History
> View Document Details:
> http://www.oasis-open.org/apps/org/workgroup/dss/document.php?docu

Download Document:  

PLEASE NOTE:  If the above links do not work for you, your email application
may be breaking the link into two pieces.  You may be able to copy and paste
the entire link address into the address field of your web browser.

-OASIS Open Administration

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]