OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

dss message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: RE: [dss] Policy-wise Server profile doc


Thanks Trevor, responses inline

Paul

>-----Original Message-----
>From: Trevor Perrin [mailto:trevp@trevp.net]
>Sent: Sunday, February 22, 2004 7:29 PM
>To: Paul Madsen; dss@lists.oasis-open.org
>Subject: Re: [dss] Policy-wise Server profile doc
>
>
>At 08:46 AM 2/17/2004 -0500, Paul Madsen wrote:
>
>>Hi, enclosed is the Policy-wise Server Profile, based on 
>Trevor's profile 
>>template.
>
>Hi Paul,
>
>Looks good generally, a few comments:
>
>
>Line 6, Document identifier should be:  
>"oasis-dss-1.0-profiles-pws-spec-wd-01"

Fixed

>
>Lines 12-21, Remove list of contributors

Fixed

>
>Line 75, remove "and signature profiles..."

Fixed

>
>Lines 99-100: I think you don't need a URI identifier, so you 
>could say 
>"This profile does not specify a URI identifier".  I'll update 
>the template 
>doc to mention that.

Fixed

>
>Line 121: <IntendedAudience> instead of <Recipient>
>

Fixed

>Lines 122-132: let's discuss this some more, and try to 
>determine whether 
>it's necessary, or needs to be put into core.
>
Agreed

>Line 161: I forgot the <SignatureObject> section in the template by 
>accident, it's a good section to add.  However, I think the 
>PWS profile 
>could just say: "This profile does not specify or constrain 
>the type of 
>signature object".  Clients are required to send the 
><SignatureObject> by 
>the core.
>

Fixed

>Line 163: so clients MUST send <Document> for signing, but 
>they're allowed 
>to send <Document>s or DocumentHash>es for verifying?
>

My thinking was that, at least for XML data, for the client to be able to
send <DocumentHash>es in a <SignRequest> would imply that it knew over which
elements the signature would be calculated - this incompatible with its
level of policy knowledge.

For a VerifyRequest, this constraint wasn't relevant - a client's ability to
support sending only the <DocumentHash> reflecting only its XML and math
capabilities rather than policy or trust management abilities.

To be honest, I haven;t fully thought through how this constraint (not
sending the hash on a <SignRequest>) can be made compatible with scenarios
where the source data to be signed is non-XML and so the client can more
reasonably be expected/allowed to calculate the hash. Perhaps we should
loosen it here and tighten appropriately in the concrete profiles.

>Line 169-171: This is redundant with the core document, 
>section 4.3 #5.  So 
>I think you could delete this section.

Section 4.3 specifies processing for the 'primary' <Signature> within a
<VerifyRequest>, i.e. that which motivates the request. This section of the
PWS Profile was intended to specify processing to be performed by the DSS
Server for any other <Signature>s, e.g. those calculated by some external
policy authority over a policy statement.

>
>
>Trevor 
>
>
>To unsubscribe from this mailing list (and be removed from the 
>roster of the OASIS TC), go to 
>http://www.oasis-open.org/apps/org/workgroup/dss/members/leave_
workgroup.php.


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]