RE: [dss] Groups - dss-requirements-1.0-draft-02.doc uploaded

[Trevor Perrin <trevp@trevp.net>]

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