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] full schema for signing request


At 07:46 PM 9/24/2003 -0400, you wrote:

> > If we rewrote it that way, the only function of dss:Parameter would be to
> > contain the "mustUnderstand" attribute.  At the f2f we decided that the
> > server should *have* to understand any client parameters, or reject the
> > entire request.  Just made things simpler.  We could revisit that.  But if
> > we got rid of mustUnderstand we wouldn't need dss:Parameter, we could 
> just do:
>
>The biggest drawback I can see is that it prevents re-using elements;
>you can't say "this ds:KeyInfo is for signing, and this ds:KeyInfo
>is for timestamping".  Instead you'd have to wrap each ds:KeyInfo element
>inside a namespaced container that identified the semantics.

True, but with a dss:Parameter you have to wrap each element 
regardless.  With this, at least some elements can avoid that:

<parameters>
   <claimedIdentity>alice@acme.com</claimedIdentity>
   <intendedAudience>bob@acme.com</intendedAudience>
   <applicationProfile>urn:oasis:dss:code-signing</applicationProfile>
   <returnDocumentContainingSignature/>
   <signingKey>
       <ds:KeyInfo>...
   </signingKey>
   <timestampingKey>
       <ds:KeyInfo>...
   </timestampingKey>
</parameters>


>   I think it's
>cleaner to identify the semantics and leave the content open.
>
>If mustUnderstand goes away from the core, that's okay.  I'd like to leave
>open the possibility of adding it (with default value true) in future
>versions, tho.

yeah, doing what I suggest precludes that.


Trevor 



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