[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [dss] Groups - dss-requirements-1.0-draft-03.pdf - Process an dDeadline information?
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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]