RE: [dss] comments on DSS requirements

["Nick Pope" <pope@secstan.com>]

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.
>
>
> >---
> >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.

>
>
> >In addition, the protocol design may be generalized to allow
> other formats
> >such as CMS or OpenPGP to support a wider range of applications."
> >
> >---
> >3.3.2
> >This section should be renamed "Requestor Confirmation", it is
> more than a
> >name, but the powerful concept of defining how the requestor has been
> >identified satisfactorily.
>
> I don't see how this is a confirmation, and we've been using Requestor
> Identity ever since the use case was proposed, so I'd prefer to
> stick with
> it.  What do other people think?
>
I agree with you Trevor.


>
>
> >I think having a bullet for optional "Authentication Context" is useful,
> >specifically the Liberty definition. That covers a lot of ground
> that can
> >be reused as I mentioned before.
>
> It fits into the 2nd bullet, as one of many ways a name can be
> supplemented.  Is that good enough?
>
>
I agree with Trevor one of the items specifically mentioned in 3.2.2 2nd
bullet is a Liberty Authentication Context.



> >-----
> >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.


>
>
>
> >----
> >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.


>
>
> >----
> >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.

>
> 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").

Nick