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

[Robert Zuccherato <robert.zuccherato@entrust.com>]

Trevor;

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

I think that is a realistic goal.  I would like to see a candidate final
version in time for the next telecon, if at all possible.

> Securing the Transform Chain
> ----------------------------------------------

...snip....

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

That seems reasonable to me.

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

I agree.

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

It seems to me that SAML assertions work and are easily included in our
spec.  Thus, I think we should certainly support their use.  It's not clear
to me that we necessarily need to support any other method until/unless we
receive a concrete proposal of something else to use or find a specific
deficiency.

> 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 think that your proposal on this subject is entirely reasonable, however
we should definitely discuss this topic again at the next telecon.

Thanks,

	Robert.