comments on DSS requirements

[<Frederick.Hirsch@nokia.com>]

Comments on DSS Use Case Requirements, Draft 8, 12-July 2003

---
2.11 Client side hashing

Wouldn't a recipient of a signature send the entire signature for verification, either with referenced documents, document pointers or document hashes? Sending hashes is not enough, what is to be verified must also be sent.
----
2.12 Time stamps

The time stamp use cases included a number of variations that suggest additional cases, such as the following:

Verification: Verify that signature was valid at the specified time, both in terms of certificate/key validity period as well as certificate validation at that time.

(Re use case document 3.3 [243],
I do not understand why a item needs to be re-signed periodically given certificate validity expiration - can't the old key still be used to verify the signature, the old certificate to bind that key to identity, as long as there is proof of validity at the time in the past (archived OCSP response for example)? Perhaps this use case raises an additional requirement:
"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.)

---
3.1.1 
In addition to XML time stamp token and Requestor identity element, we might want an additional
"Generic Signature Properties" work item with optional components determined to be of value.

I would prefer to call "Requestor identity element" "Requestor Identity Confirmation Element" since it confirms that the requestor identity is as expected.
---
3.1.2

Should we limit the initial Binding focus to HTTP/SOAP and say this?

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

----
3.2.2
Rephrase to be more positive about XML Sig

"XML Signature is an extensible and flexible mechanism that is compatible with XML applications supporting advanced features such as transforms, multiple references, sectional signing, and the ability to combine signatures with XML content or to provide detached signatures. 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.

Add a bullet "Confirmation method" (much like SAML confirmation method if we want bind the requestor identity to the request)

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.
-----
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) 
----
3.5.2 Signature placement

We should mention detached signatures as an option.

----
3.5.3 Output delivery

We may have to define an XML element/multipart-mime/zip mechanism to package output, especially if a signature is detached and references multiple documents, such as for example an HTML page and 2 images referenced from the HTML. Receiving the document back means receiving three documents + a detached signature. We could decide to stay with simple enveloped XML signatures for XML content but eventually the issue of conveying multiple components will come up.

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

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)
----
3.5.5 
[326] "Requestor may provide additional attributes or request additional server attributes be included in Signature Properties.

----
3.6.1 
We should mention possibility to return URL or reference # to retrieve signature, either from URL or from signing server (respectively)

----
3.7.1 Selective Verification

[366] Don't the XML DigSig processing rules require both signature validation and SignedInfo reference validation (hash generation and comparison), with the optional Manifest providing a way out? Why is this listed as optional here? We need to be clear that we support both SignedInfo and Manifest ds:References, but obey the DSig SignedInfo processing rules.

----
3.7.2 Verification time

Should add the following:

"This is possible only if the credentials for that time are either presented in the request with supporting validation information (e.g. OCSP responses) or have been stored at the server earlier."

----
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, or do we plan to define rule mechanisms or other ways of stating policy? What is the representation of policy.

---
3.7.7

Is the request for specific signature verification steps a request to use a specific verification policy? 

In general will we support policy both implicitly (URI defined as policy) and explicitly (say the confirmation steps desired)?
----
3.9 Binding requirements

Add a requirement to address replay and man-in-the-middle attacks.
----

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.

This can also be applied to content that includes other content etc

The requirement could be: "Explicitly address 'what you see is what you sign' requirement."

regards, Frederick
 
Frederick Hirsch
Nokia Mobile Phones