RE: [dss] Groups - dss-requirements-1.0-draft-03.pdf - Process an dDeadline information?

[Trevor Perrin <trevp@trevp.net>]

At 01:27 PM 4/24/2003 +0200, Gray Steve wrote:

>Is there a specific deadline for when we have to return comments by on this
>draft requirements specification?

Hi Steve,

I'm not sure when we want to get this done.  The sooner the better, I 
guess.  Do people think it's realistic to get a candidate final version 
that we can discuss on May 5, the next meeting?

Here's some thoughts on the remaining issues.  Love to hear people's 
opinions (especially from those who haven't already expressed one on these 
points) -


Securing the Transform Chain
----------------------------------------------
Steve Gray mentioned that XML-DSIG already has some text that addresses the 
risks of the relying party relying on the pre-transformed data, and some 
modifications are being considered:
http://www.w3.org/TR/xmldsig-core (current text - 8.1.3)
http://lists.oasis-open.org/archives/dss/200304/msg00086.html (new text - 
8.1.3)

Joseph Reagle mentioned the notion of a "secure cache" that associates URIs 
with hashes of their dereferenced content - a dsig:Reference to the cache 
would be included in the SignedInfo, and the relying party would then 
ensure that each contributing URI in the transform sequence is mentioned in 
the cache.
http://lists.w3.org/Archives/Public/w3c-ietf-xmldsig/2003AprJun/0004.html

Offlist, I mentioned the idea of "secure URIs", which would be a URI tagged 
with cryptographic data, ie:
http://www.somesite.com/SomeTransform.xml[sha256=A8j2kVW9u...]

would be a URI tagged with a hash of its dereferenced content (calculated 
on the HTTP entity body and the Content-Type header, probably).  Then 
remote transform data could just be referred to with secure URIs.  But 
that's basically science fiction, and way out of scope for both us and 
XML-DSIG, so never mind.

So this is a complicated issue.  I think the one requirement we should add, 
is that if the client sends transformed input to the server when requesting 
a signature (per 3.3.2), then the client should have the ability to send 
dsig:References for external transform data, which the server can choose to 
incorporate in a manifest (per Gregor's initial suggestion) or a "secure 
cache" (per Joseph's suggestion) or do something else (such as ignore 
them).  So I'd append this sentence to 3.3.2, if people agree:

"The client may send a list of dsig:References for URIs that contribute to 
the transform sequence, so that the server may incorporate these into the 
signature in some fashion".

and say that the details of how the server does this are out of scope.


Signing Human-Readable data and XML
----------------------------------------------
For this, I agree with Ed Simon that "you could sign both the raw data and 
the transformed result, AND have your protocol define the exact requirement 
in relating the two".  This wouldn't have any impact on our protocol, the 
client could just request the signature of two dsig:References that happen 
to be related in this way, under some Signature Policy (per 3.4.4) that 
specifies this relation.

The other proposed approach is to sign the transforms that produce the 
human-readable data.  I don't think this would affect the protocol either, 
the client could again request the signature of two dsig:References, one 
referring to the raw document, one to some transforms.

So I don't believe we need to make any changes to the requirements doc to 
accomodate this.


How to Identify Requestor
----------------------------------------------
I think 3.2.1 bullets 2 and 3, about what types of signed attributes are 
used to identify the requestor, should be changed to:
  - RFC 3280 GeneralName (for a CMS signature)
  - SAML Assertion (for an XML-DSIG signature)

There's several questions around the use of SAML Assertions, though:
  - SAML Assertions specify how someone authenticated - if the server 
doesn't want to say how the requestor authenticated, but just give the 
requestor's name, the SAML Assertion is overkill.  Here's some proposals to 
deal with this:
http://lists.oasis-open.org/archives/dss/200304/msg00054.html
  - Anthony Nadalin suggests extensibility to allow non-SAML 
assertions/tokens as signed attributes:
http://lists.oasis-open.org/archives/dss/200304/msg00056.html
  - John Messing was suggesting extensibility to cryptographic methods 
besides signed attributes, I'm not sure if he still is.
  - John also raised the question of what semantics a SAML Authentication 
Assertion issued by a 3rd-party (that isn't the DSS service), as a signed 
attribute, should have.  Does it come with the implicit guarantee that the 
signer (i.e. the DSS Service) agrees with everything in the Assertion (such 
as authentication time and type), or is it just being passed on to the 
relying party, so the relying party can use its contents if he has his own 
trust relationship with the Assertion issuer?  Or should we not allow 
3rd-party asssertions?  More discussion here:
http://lists.oasis-open.org/archives/dss/200304/msg00071.html
  - should CMS signatures be able to have SAML Assertions attached as well?

Linked Timestamps
----------------------------------------------
Unsure where we are on this.  My feeling is that unless we could spec these 
out completely, so that any relying party can figure out how to parse and 
verify timestamps produced by any TSA, including the supporting protocols 
used to retrieve data from trusted archives and the 2-phase protocols to 
produce these and so on, than there's no point to just doing this 
half-way.  And spec'ing this out fully would be very complicated.  And then 
there's IPR issues..

So I think we should just make sure that we can extend our time stamps to 
support linking schemes in the future, but not grapple with their details:
http://lists.oasis-open.org/archives/dss/200304/msg00011.html


I encourage people to bring up other issues.

Trevor