RE: [dss] plans for next draft- extensibility

["Nick Pope" <pope@secstan.com>]

I suggest that we either add a "mustUnderstand" flag, or make it clear that
any extensions to the TSTInfo may be ignored.

Similarly, for all the options & other areas of extensibility we make it
clear what is done if the extension is not understood (reject or ignore).  I
presume that the options must be understood?

Nick


>
> Questions
> -------------------------
> 1)  Should we add an optional <Extensions> to the current <TstInfo>, per
> Nick's suggestion [1]?  Tim had a bit of skepticism towards this
> [4], or at
> least thought we should clarify what it might be used for, and how
> extensions should be processed if not recognized.
>
> RFC 3161 has an extension field, borrowed from X.509 certificates, which
> tags each extension with a "criticality" flag.  So far we've avoided
> criticality/mustUnderstand bits.
>
> So if we added a TstInfo/Extensions, should we add it as type
> <xs:any>, or
> do we want it more RFC 3161-like, with critical/noncritical extensions?
>
> 2)  Should we update the <dss:Signature> element so that it can contain a
> <dss:Timestamp> (thus you can sign/verify time-stamps)?
>
> 3)  Should we change the text to clarify that time-stamping is just a
> profile of the Signing and Verifying Protocols, and not a separate
> profile?  And start work on such a profile?
>
>
>
> Trevor
>
> [1] http://lists.oasis-open.org/archives/dss/200311/msg00093.html
>
> [2] http://lists.oasis-open.org/archives/dss/200311/msg00061.html
>
> [3] http://lists.oasis-open.org/archives/dss/200311/msg00100.html
>
> [4] http://lists.oasis-open.org/archives/dss/200311/msg00095.html
>
>
> 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_wor
kgroup.php.