RE: [dss] comments on DSS requirements

[Trevor Perrin <trevp@trevp.net>]

At 10:27 PM 7/19/2003 +0100, Nick Pope wrote:
>Content-Transfer-Encoding: 7bit
>
>Frederick, Trevor,
>
>I generally agree with Trevor, adding a few thoughts to some of the points -
>see below.
>
>Nick
>
>
> >
> > >"For long term signatures the server must retain all signatures and
> > >associated credentials as well as maintaining credential
> > histories." - (I
> > >note that we do not have server requirements so far, just representation
> > >and protocol requirements.)
> >
> > Yeah, I think we should stick to protocol requirements.
> >
>
>My view is different.  If we are specify a service then I suggest that we
>may need to include requirements om the operation of the server, not just
>the protocol.  The core may be to generic to include such service specific
>requirements but I would suggest that the profiles may need to include such
>items.

I agree that service requirements shouldn't be in the Protocol and Core 
Elements doc.

Whether they should be in later docs we produce, I dunno.  Maybe we can 
just table the issue until we get there, and deal with the Protocols and 
Core Elements for the time being.


> >
> >
> > >---
> > >3.1.2
> > >
> > >Should we limit the initial Binding focus to HTTP/SOAP and say this?
> >
> > Fine by me, if people agree.
> >
> > Do we want to commit to WSDL, also?  People have mentioned this a
> > number of
> > times, but I don't recall a discussion.
> >
>I am not familiar with WSDL but looking at the description if we map to WSDL
>then there are mappings defined through WSDL Part 3 (WSDL Version 1.2
>Bindings) to "SOAP 1.2, HTTP/1.1 GET/POST, and MIME".  My feeling is that by
>mapping to WSDL we can save ourselves some work.
>
> >
> >
> > >---
> > >3.2
> > >"The Signing Protocol takes as input documents optionally with
> > transforms
> > >or document hashes, and creates a signature."
> > >
> > >I think we should clearly say "XML Signature" in this
> > introduction, and I
> > >note that XML Sig can handle a variety of signature algorithms.
> > I propose
> > >the following text:
> > >
> > >Although our focus is on XML Signatures, the intent is to define
> > protocols
> > >and mechanisms that can be extended to other types of cryptographic
> > >signature representations such as CMS. In addition, various
> > cryptographic
> > >signing mechanisms are to supported, as XML Signature allows, including
> > >public key based signatures as well as symmetric key MACs. We also
> > >consider applications of signing that deserve special mention such as
> > >Timestamps that require additional information to be included as
> > signature
> > >properties (e.g. RFC 3161 timestamp token).
> > >
> > >----
> > >3.2.1
> > >I suggest we remove the bullet "Extensible to others" since
> > binary and XML
> > >pretty much covers it.
> >
> > I'll do that, unless people disagree.
> >
>I am loath to claim that the DSS protocol is generic to all signature
>syntaxes.  We can provide a "Bucket" to carry information required for other
>types of signature but I am not sure how meaning that is.  If this can be
>achieved all well and good but at the moment I would prefer not to change
>the requirements that we are commiting to support.

3.2.1 is about the type of *documents* we can sign, not about *signature* 
types (I added text in the beginning of 3.2 to define these terms as 
they're used here, I'm not sure if that helps).


> > >3.4.1
> > >
> > >Maybe we should change the bullet "ID references need special
> > support" to
> > >be "Mechanisms to support ds:References to elements without requiring
> > >schema access are required."
> > >
> > >Can we say that schemas should not be required when referenced XML is in
> > >canonical form and well known identifier attributes are used?
> > (e.g. wsu:Id
> > >attributes or saml:AssertionIds?) Mention of the SOAP Message Security
> > >SecurityTokenReference transform might be appropriate (this
> > transform says
> > >don't hash what is referenced, but dereference that and then hash)
>
>??? No comment on this one Tervor?
>
>  I think this needs further thought.  I agree with Frederick that the
>practicality is doubtful of the server doing canicalisation in general on
>all the different syntaxes that may appear in documents.

I missed that.  I agree it needs further thought.  Frederick's suggestion I 
think is just to add text clarifying that sending this information won't 
always be required.  That sounds reasonable, should we add that?




> >
> >
> >
> > >----
> > >3.5.4 Intended audience
> > >
> > >I assume this is just meta-information included in the signature to list
> > >who the intended audience is (limit liability). Like the SAML
> > >AudienceRestrictionCondition.
> >
> > No.  All the things in 3.5. are part of the Signing Request protocol
> > message, they don't go in the signature.
> >
> >
>Trying to include such application specific information in the signature is
>likely to be in appropriate.  It is better to specify this as a part of the
>signature policy or within the application.
>
> >
> > >The reason I mention it, is that this is not a means to restrict viewing
> > >by other audiences (i.e a confidentiality requirement) because
> > we have no
> > >intention of supporting XML Encryption with the developed services
> > >(despite some potential commonalities)
> >
> > No - it's just something the server can use to determine the various
> > "Implicit Parameters" (see 3.5.6), such as what key to sign with.
> >
>I suggest that this is one for extensibilty mechanisms to enable encryption
>related services to be added to DSS if required.

As in doing sign/encrypt in a single exchange?  This is similar to Ed's 
stacking operations.  What do you think of the text he suggested?



> >
> >
> > >----
> > >3.7.4
> > >
> > >We mention policy a lot and that can mean different things. Do we mean a
> > >URI and the rest is out of scope,
> >
> > We now have "Implicit Parameters" (3.5.6 and 3.7.8), which are
> > things that
> > are selected just by which URI you access.  We aren't calling
> > these things
> > policies anymore, cause that was confusing.
>
>I am not sure whether we are throwing away too much by just ignoring
>"policies".  I think that we do need to have the concept of something that
>defines the rules under which the signature is created / verified.

According to the doc, there's an "Application Profile", and which 
application profile is used is determined implicitly by which URI you 
access the server at.

So if the "Application Profile" defines all these rules (for example, EPM 
could be an application profile, as would eNotary), and the URI determines 
the application profile, is that sufficient?



> >
> > 3.7.4 is talking only about the SignaturePolicyIdentifier of XAdES or
> > equivalent - 3.7.4 is about the server parsing things out of the
> > signature
> > and then handing them to the client, to make the client's job easier, and
> > that's one of the things the server could parse out.
> >
> >
> > >  or do we plan to define rule mechanisms or other ways of
> > stating policy?
> > > What is the representation of policy.
> > >
> > >---
> >
> >
> >
> > >In general will we support policy both implicitly (URI defined
> > as policy)
> > >and explicitly (say the confirmation steps desired)?
> >
> > I would prefer not to say "URI defined as policy", but to say "Implicit
> > parameters", cause the word policy gets too overloaded.
> >
> >
> > >----
> >
> >
> > >----
> > >
> > >We may be missing one requirement that could impact the protocol.  To
> > >satisfy "what you see is what you sign" we may need a 2 round-trip
> > >protocol, a "Signing Confirmation", as follows:
> > >
> > >1. Request to sign something viewed involving underlying XML along with
> > >XSLT transform (e.g. want to sign what is seen)
> > >2. Server signs a) XML b) XSLT (neither was seen)
> > >3. Server applies XSLT to XML returns to client
> > >4. Client displays verifies it is what they saw, confirming
> > correctness of
> > >mapping to XML+XSLT.
> >
> > 3.7.5 allows the client to request, on a Verification request, that the
> > server should return the transformed data.  Do we want to add something
> > like that onto the Sign protocol too?
> >
>I am unclear how the DSS gets involved in the "signing confirmation".  Are
>you suggesting that the server sign the information twice?  Isn't WYSIWYS a
>user interface and signing procedures problem.  I would be loath a
>significant complexity to the protocol to make it a protocol involving a
>sequence of two request / responses (if thats what you mean by "2 round trip
>protocol").

If the only requirement is that there's an option for the server to return 
the transformed data that he actually signed, along with the signature, 
then that might not be too bad.  It wouldn't require 2 round trips.  And we 
already have the analogous option on the Verifying Protocol (3.7.5).

Trevor