63 messages in org.oasis-open.lists.dssRE: [dss] Groups - dss-requirements-1...| From | Sent On | Attachments |
|---|---|---|
| robe...@entrust.com | Mar 24, 2003 12:58 pm | |
| Gregor Karlinger | Mar 25, 2003 7:34 am |  .bin |
| Trevor Perrin | Mar 25, 2003 11:30 am | |
| Nick Pope | Mar 25, 2003 11:35 am | |
| Nick Pope | Mar 25, 2003 12:23 pm | |
| Trevor Perrin | Mar 25, 2003 12:29 pm | |
| Trevor Perrin | Mar 25, 2003 12:33 pm | |
| jmessing | Mar 25, 2003 12:36 pm | |
| Trevor Perrin | Mar 25, 2003 1:18 pm | |
| Nick Pope | Mar 25, 2003 1:21 pm | |
| Nick Pope | Mar 25, 2003 1:21 pm | |
| Nick Pope | Mar 26, 2003 1:21 am | |
| kare...@esat.kuleuven.ac.be | Mar 26, 2003 4:02 am | |
| Nick Pope | Mar 26, 2003 5:22 am | |
| jmessing | Mar 26, 2003 5:26 am | |
| Trevor Perrin | Mar 26, 2003 10:49 am | |
| jmessing | Mar 26, 2003 10:57 am | |
| Trevor Perrin | Mar 26, 2003 11:11 am | |
| Rich Salz | Mar 26, 2003 11:24 am | |
| Trevor Perrin | Mar 26, 2003 1:15 pm | |
| Greg Alvord | Mar 27, 2003 4:37 am | |
| Gregor Karlinger | Mar 27, 2003 9:01 am | .bin |
| Trevor Perrin | Mar 27, 2003 1:17 pm | |
| Nick Pope | Mar 28, 2003 3:54 am | |
| Trevor Perrin | Mar 28, 2003 1:52 pm | |
| Nick Pope | Mar 29, 2003 9:35 am | |
| Rich Salz | Mar 29, 2003 10:10 am | |
| Trevor Perrin | Mar 29, 2003 10:14 am | |
| Rich Salz | Mar 29, 2003 10:36 am | |
| jmessing | Mar 29, 2003 11:19 am | |
| Rich Salz | Mar 29, 2003 11:26 am | |
| Trevor Perrin | Mar 29, 2003 11:46 am | |
| jmessing | Mar 29, 2003 12:31 pm | |
| Rich Salz | Mar 29, 2003 3:35 pm | |
| Trevor Perrin | Mar 30, 2003 1:49 am | |
| Gregor Karlinger | Mar 30, 2003 10:50 am | .bin |
| Gregor Karlinger | Mar 30, 2003 11:07 am | .bin |
| Gregor Karlinger | Mar 30, 2003 11:18 am | .bin |
| Gregor Karlinger | Mar 30, 2003 11:23 am | .bin |
| Gregor Karlinger | Mar 30, 2003 11:31 am | .bin |
| Gregor Karlinger | Mar 30, 2003 11:47 am | .bin |
| Gregor Karlinger | Mar 30, 2003 11:58 am | .bin |
| Gregor Karlinger | Mar 30, 2003 12:14 pm | .bin |
| Gregor Karlinger | Mar 30, 2003 12:23 pm | .bin |
| Rich Salz | Mar 30, 2003 2:25 pm | |
| Gregor Karlinger | Mar 30, 2003 11:14 pm | .bin |
| Gregor Karlinger | Mar 30, 2003 11:20 pm | .bin |
| Gregor Karlinger | Mar 30, 2003 11:26 pm | .bin |
| Gregor Karlinger | Mar 30, 2003 11:30 pm | .bin |
| Gregor Karlinger | Mar 30, 2003 11:37 pm | .bin |
| Trevor Perrin | Mar 31, 2003 1:41 am | |
| Gregor Karlinger | Mar 31, 2003 1:48 am | .bin |
| Gregor Karlinger | Mar 31, 2003 1:56 am | .bin |
| Nick Pope | Mar 31, 2003 4:02 am | |
| Anthony Nadalin | Mar 31, 2003 5:15 am | |
| Karel Wouters | Mar 31, 2003 6:30 am | |
| Gregor Karlinger | Mar 31, 2003 7:22 am | .bin |
| Trevor Perrin | Mar 31, 2003 8:46 am | |
| Gregor Karlinger | Mar 31, 2003 1:20 pm | .bin |
| Nick Pope | Apr 1, 2003 1:32 am | |
| Karel Wouters | Apr 1, 2003 2:52 am | |
| Nick Pope | Apr 1, 2003 2:52 am | |
| Nick Pope | Apr 1, 2003 3:03 am |
| Subject: | RE: [dss] Groups - dss-requirements-1.0-draft-02.doc uploaded | |
|---|---|---|
| From: | Trevor Perrin (tre...@trevp.net) | |
| Date: | Mar 27, 2003 1:17:40 pm | |
| List: | org.oasis-open.lists.dss | |
At 06:11 PM 3/27/2003 +0100, Gregor wrote:
Hi all,
I would like to make some comments on the dss requirements draft:
1. Line 194ff: I think that CMS/PKCS#7 is widely used and therefore important enough to be considered explicitely. Formats apart from XMLDSIG and CMS I deem to be beyond the scope of this TC.
Sounds good. That seemed to be the consensus on the call too.
2. Line 201f: Is it necessary to distinguish between a string and a SAML assertion? The former can be seen as a subset of the latter.
A SAML Assertion is an XML document, so how is a string a subset of one?
I was thinking an XML-DSIG signature would be more likely to have a SAML Assertion in a signed attribute to identify the requestor, whereas a CMS/PKCS#7 signature would be more likely to have a string containing just the requestor's email address (say) in a signed attribute.
3. Line 217: There are additional use cases for time stamps (see the submision from Nick Pope: ETSI TS 101 903 (XAdES) [1]).
Could you suggest some additional text to cover these?
4. Line 230f: The cited ETSI specifications contain many useful attributes. I think we should discuss in detail which of those a DS service must understand/must be able to apply.
yeah, those should be discussed more on the list.
5. Line 245ff: My interpretation of plain and transformed is as follows: Plain - the requester submits the data and instructions which transforms have to be applied by the service prior to computing the digest; Transformed - the requester submits trans- form instructions together with the already transformed data, i. e. the service need not compute the transforms. Right?
Yes. I see we should define "transformed" in the the text.
6. Line 300: I cannot see any impressing arguments to support this.
It was just added to parallel the ability of the requestor to transfer data via URIs. Let's see what other people say about it, probably it should be removed.
7. Line 304ff: If we let the requester decide which dsig:References inside a dsig:SignedInfo should be verified, we are not conform with the processing model of XMLDSIG, which says that verifying a signature means verifying all References in SignedInfo. Regar- ding the verification of a dsig:Manifest, the requester should have the possibility to decide which dsig:References inside a dsig:Manifest should be verified; this makes sense taking into account the processing model of XMLDSIG.
Suppose the client verifies some of the references himself. In fact, suppose the client verifies all the references himself, and they cover 10s of MBs of data. Then the client would just ask the server to perform "Core validation", and wouldn't have to transfer the data that the references refer to. This is just the verifying side of "client-side hashing".
I'll add a bullet "Which references to verify inside each dsig:Manifest". Of course, this could be recursive, right, cause a Manifest could reference a Manifest, and so on?
8. Line 316ff: The question leaves open on which evidence the server bases its knowledge about the key compromise. In order to fullfil verification requests with a date in the past, the service must archive historical revocation information. Then it should be possible for the service to determine the revocation status at the requested verification time.
Right, but when the client wants to determine verification status at some time in the past, does he want to know what the server *thought* the verification status was then, or what the server *currently thinks* the verification status was then. I'm pretty sure it's the latter, just wanted to check.
9. Line 321: I guess "transformed data" means the data used as input for computing the hash of a dsig:Reference?
Right. I think you suggested earlier that the server should be able to return this to the client, and Robert suggested it would be simpler just to make the server a pure validation service. This needs more discussion, but it's in there now for completeness. Like above, "transformed data" should be defined in the text, I'll add that.
10. Line 326: Reason codes should be elaborated in more detail.
Could you suggest something?
11. Line 350ff: Additional query feature: Which signing keys can be used by the requestor?
Right now, that's grouped under "3.4.4 Signature Policy", which the client can query. The tentative idea was that all that stuff would be grouped together as a package and referred to under a single identifier. Is that good enough? Or do these things need to be broken out separately?
12. Line 356f: Is it useful for the requester to know which sig algs and transforms the service supports for signature verification? What can the requester decide upon this information? I. e. isn't it sufficient to send a signature to the service and wait how the service responds (possibly with an error "do not support sig alg xy"?
Saves a roundtrip, but that's probably not that useful, I'll remove it unless someone wants it.
13. Line 364: Profiling is fine, but I think there should be minimum requirements to be fulfilled by each DSS.
Should we add text to clarify this?
14. Some requirements I listed in my mail [2] have not been considered in the draft. Could you please either add the requirements or provide the motivation for not considering them? - req 2.1.2 - req 2.2.2
About 2.1.2, could we add "What transforms to apply" under "3.4.4 Signature Policy"?
About 2.2.2, could you suggest something? I guess "Signing Request Requirements" needs a new requirement, but do we have to send schemas or DTDs, or is there a more efficient way to identify which elements have ID attributes?
On a side note, we've had more discussion of the "Securing the Transform Chain" use case. What are your final thoughts? Do you want to suggest something for 2.7?
Trevor