RE: [dss] Comments on Core Draft 11, 3 Feb 04 (long, resend)

[Paul Madsen <p.madsen@entrust.com>]

Hi Frederick, wrt 11) below, why do you feel it would not make sense to
allow the client to include an embedded (and presumably signed) policy
statement rather than simply a URI in <ServicePolicy>?

I am currently trying to model this within policy-wiser server profile as a
<ds:Signature> object within <OptionalInputs> but placing it within
<Serviceprofile> would be more consistent.

Thanks

Paul

>-----Original Message-----
>From: Frederick.Hirsch@nokia.com [mailto:Frederick.Hirsch@nokia.com]
>Sent: Saturday, February 07, 2004 10:32 AM
>To: trevp@trevp.net; dss@lists.oasis-open.org
>Subject: [dss] Comments on Core Draft 11, 3 Feb 04 (long, resend)
>
>
>Comments and proposals for Draft 11 of DSS Core, 3 Feb 04.
>
>Line numbers refer to pdf:
>http://www.oasis-open.org/apps/org/workgroup/dss/download.php/5
>292/oasis-dss-1.0-core-spec-wd-11.pdf
>
>(1). I propose we switch from QNames to URLs for consistency and to
>avoid various known issues with QNames used as values (e.g.
>canonicalization if signed)
>
> Properties/Identifier, section 3.4.6, line 685-7, schema line 713
> Change from QName to anyURI
> 
> (2) I propose we use URL(s) for the dss namespace(s). This has the
>advantage that optionally the schema can be retrieved from the URL.
>OASIS is defining a standard for defining such persistent URLs, other
>TCs like WSS have adopted this approach. 
>
>(3) Editorial comments on overview (section 1.3, line 163)
>
>Might help reader to add subsections:
>1.3.1 Signing and Verifying Protocol (before line 163)
>1.3.2 XML TimestampToken (break line 197, before First...)
>1.3.3 RequesterIdentity XML Element (break line 199, before Second...) 
>
>Update line 180:
>bandwidth and protect the privacy of the document content.
>
>(The input documents to be signed or verified can be transferred in
>their entirety, or the client can hash the documents itself and only
>send the hash values, to save bandwidth and protect the privacy of the
>document content. )
> 
> Change line 190 from "data to use in verifying" to:
> 
> data necessary to verify the signature (such as certificates and
>CRLs)...
>
>(4) Since Document and DocumentHash share common document structure, it
>might make sense to derive them from a common type, something like
>follows:
>
><xs:complexType name="DocumentBaseType" abstract="true">
>        <xs:sequence>
>            <xs:element ref="ds:Transforms" minOccurs="0"/> 
>        </xs:sequence>
>        <xs:attribute name="ID" type="xs:ID" use="optional"/>
>        <xs:attribute name="RefURI" type="xs:anyURI" use="optional"/>
>        <xs:attribute name="RefType" type="xs:anyURI" use="optional"/>
>    </xs:complexType>
></xs:element>
>
><xs:element name="Document" type="DocumentType" />
><xs:complexType name="DocumentType">
>  <xs:complexContent>
>    <xs:extension base="DocumentBaseType">
>      <xs:choice>
>        <xs:element ref="dss:XMLData"/>
>        <xs:element ref="dss:Base64Data"/>
>      </xs:choice>
>    </xs:extension>
>  </xs:complexContent>
></xs:complexType>
>
>
><xs:element name="DocumentHash" type="DocumentHashType" />
><xs:complexType name="DocumentHashType">
>  <xs:complexContent>
>    <xs:extension base="DocumentBaseType">
>      <xs:sequence>
>        <xs:element ref="ds:DigestMethod"/>
>        <xs:element ref="ds:DigestValue"/>
>      </xs:sequence>
>     </xs:extension>
>  </xs:complexContent>
></xs:complexType>
>
>(5) Add text to RefURI definition, line 272:
> 
> "The RefURI attribute SHOULD be specified, no more than one RefURI
>attribute may be omitted in a single signing request."
>
>(6) Add clarification to Document element description before line 291:
>
>"The document hash for signing is created from the element content of
>XMLData (i.e. the <XMLData> tags are not included), or from the content
>of the <Base64Data> element after it is base64 decoded. "
>
>(yes this reinforces the processing rules here for the reader)
>
>Do we need to say something about spaces in the XMLData 
>element content?
>
>(7) Why can't a SignaturePtr point outside the document and hence have
>type anyURI instead of IDREF?
>(Schema, line 390)
>
>(8) Editorial - it may make sense to put the non-optional 
>result section
>before the optional input sections (e.g 2.8 before 2.6)
>
>(9) Why is resultMajor a string instead of a URI? Seems URI would be
>consistent with minorCode and better defined? (schema, line 462)
>
>(10) Editorial
>section 2.7.1 ine 428, replace "the client thinks he does" with "the
>client expects"
>
>section 2.7.2, same change, line 435
>
>(11) Does it ever make sense to include an embedded policy statement
>rather than a policy URI? Probably not.
>
>(12) Editorial, 2.7.3 ClaimedIdentity, change "MUST further" to "MUST"
>
>(13) SignResponse, line 525 section 3.2
>Why must a SignResponse not include a SignaturePointer? If such a
>pointer used a URI then the client could retrieve the signature later
>from a server via HTTPS GET and the URI?
>
>(14) Add to processing rule step 2a at end, line 562:
>
>"A signature MUST NOT be created if more than one RefURI is omitted in
>the set of input documents."
>
>(this is explicit in ds:Signature rules, but probably worth making
>explicit here)
>
>(15) IntendedAudience, section 3.4.3 line 611
>
>Presumably this does not have the same meaning as a SAML
>AudienceRestriction, ie. the signature may be passed to other audiences
>later.
>
>(16) SignedReferences processing rule implication is not clear
>At 3.4.5 line 638-640, this is not clear. Which second step is referred
>to? Is a mixture of SignedReferences and non-SignedReferences possible?
>
>(17) Properties, Value. Can a Property have more than one Value?
>Should schema have maxOccurs="1" (line 715)
>
>(18) Editorial, VerifyRequest, section 4.1, line 771
>
>remove "(i.e. deleting the signature)" - the signature isn't actually
>deleted, but the signature processing rules must exclude the 
>signature -
>this parenthetical might make it more confusing.
>
>(19) Editorial, line 773, replace "A list of" with "The"
>
>(20) Would it make processing of SignaturePtrs easier if InputDocuments
>were first in VerifyRequests?
>
>If so, move InputDocuments element first in schema sequence, lines
>777-779
>
>(21) Basic Processing, step 3, line 815, it isn't clear how the
>transform verification will work if some transforms are added
>transparently by a signing server. If the verification is done at a
>different server with different rules, how are transforms known other
>than trusting the list?
>
>(22) Why aren't ReturnTimestampTime and Output TimestampTime defined in
>the Timestamp profile instead of core? Sec 4.5.6, line 971
>
>(23) Clarify that a signature may only be updated by adding unsigned
>attributes. Otherwise a new signature must be created to apply the key
>to changed content. Section 4.5.8, line 991
>
>(24) Transformed Document line 4.5.9
>Might a client want to see the result of applying combinations (1 or
>more of the transforms)?
>
>Is use of an index fragile for references - is order always guaranteed?
>Should XPath be considered?
>
>Should the result include the Transform(s) used, to confirm correctness
>of operation?
>
>(25) 5.1.1 , line 1081, XMLTimeStampToken
>Shouldn't Reference for "this document" contain "" for URI? This would
>Sign entire XMLTimeStampToken, excluding enveloped signature. Is this
>what is wanted and being said here? 
>
>(26), Creation Time ins section 5.1.2, line 1099
>
>Shouldn't we replace "was started" with "completed". Ie time is from
>when entire request has been received (effective start) until entire
>operation done.
>
>(27) SAML reference should be updated to SAML 1.1, line 1355
>http://www.oasis-open.org/committees/download.php/3405/oasis-sstc-saml-
>bindings-1.1.pdf
>
>
>(28) Draft 11 is missing revision history entry
>
>regards,
>
>Frederick
>
>Frederick Hirsch
>Nokia
>
>
>
>
>To unsubscribe from this mailing list (and be removed from the 
>roster of the OASIS TC), go to 
>http://www.oasis-open.org/apps/org/workgroup/dss/members/leave_
workgroup.php.