Gregor's comments on req draft 02 (WAS: RE: [dss] Groups - dss-requirements-1.0-draft-02.doc uploaded)

["Gregor Karlinger" <gregor.karlinger@cio.gv.at>]

Trevor,

[I changed the subject since almost all of our discussion during the
 last 10 days has the same subject ...]   

> -----Original Message-----
> From: Trevor Perrin [mailto:trevp@trevp.net] 
> Sent: Thursday, March 27, 2003 10:26 PM
> To: Gregor Karlinger
> Cc: dss@lists.oasis-open.org
> Subject: RE: [dss] Groups - dss-requirements-1.0-draft-02.doc uploaded

[...]

> >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 am arguing that everything expressible with a string, is also
expressible with a SAML assertion ;-)

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

OK, agreeed.

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

Please see the messages from Nick [1] and myself [2] on this issue.

---
[1] http://www.oasis-open.org/archives/dss/200303/msg00044.html
[2] http://www.oasis-open.org/archives/dss/200303/msg00104.html

[...]

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

Yes, this would make sense.

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

I agree with Robert, that we should only have the possibility for the
requestor to deliver data via URIs, but not for the service.

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

Telling the service only to perform "signature validation" (compare [3])
instead of "reference validation" (compare [4]) and "signature
validation"
makes sense for me.

But this is different from telling the service only to validate some
references.

---
[3] http://www.w3.org/TR/xmldsig-core/#sec-CoreValidation, sec. 3.3.2
[4] http://www.w3.org/TR/xmldsig-core/#sec-CoreValidation, sec. 3.3.1
 
> I'll add a bullet "Which references to verify inside each 
> dsig:Manifest".  

Fine.

> Of course, this could be recursive, right, cause a 
> Manifest could reference a Manifest, and so on?

Basically yes. However I am not convinced that it is necessary to
support
nested manifests. Does anyone know convincing use cases for this?

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

No. The service should verify the signature based on revocation info
for the date requested by the client. What would be the sense of pro-
viding a date in the past, if the service verified based on current
revocation info? 

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

Yes, I think more discussion is needed here. I am still of the opinion,
that the service should also report back the data actually signed if
desired by the requester. This would disburden the requester from
employing a transform processing framework.

> >10. Line 326: Reason codes should be elaborated in more detail.
> 
> Could you suggest something?

At least basic error categories should be specified, such as:

- failure in reference validation
- failure in signature validation
- failure in validating key information (not trusted, ...)

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

Difficult to estimate. For the while I would say we can leave it. Maybe
we find out that splitting profile information into several categories
makes sense.

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

OK.

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

Yes, a single sentence stating that there will be minimum requirements
would be fine.

> >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"?

I think that a "transform profile" is not static enough that it should
go in a "signature policy". I would prefer to have this as a special
profile.

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

A set of pairs (XPath selecting an Element, ID-Value) could be an
alternative. Additional discussion seems necessary here.

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

Please see my message [5].

---
[5] http://lists.oasis-open.org/archives/dss/200303/msg00089.html


/Gregor

smime.p7s