RE: [dss] status of core

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

Trevor

This is a useful set of proposals, thanks to you Ed, and Gregor.  If we can
agree on these changes and close of the outstanding issues by the end of the
next conf call then I should think that we would be in a position to produce
a further DSS working draft.

Can I ask for clarification on the first functional change:
" 1) Lines 278-282, 370-376, 937-943: Replace use of transmitted DTDs with
XML Schema.  Probably doesn't need to be base64 encoded any more."

Can the XML schema be the subset of the document schema needed to identify
the ID attributes?  If so can a few words be added to claify this.

Why was the base64 encoding applied to the DTD?  Was this to hid the non-XML
syntax?  If so then I agree this is not needed, although keeping it in
Base64 may possibly help handling this as one information object.

Regarding Outstanding Issues and following on from the discuss at the conf
call;
1) I agree with your suggestion to add clarification that the input document
may be a [document], signature or manifest to be timestamped / coutersigned.

2)
- I believe that we concluded that manifest should be prepared by the
client.
- If it is easy to define structures to return more information for
<VerifyManifest> this would be useful.
- I don't think that adding more complexity to <ReturnedTransormedDocument>
is necessary at this stage.

3) More specific <ProcessingDetails> would be useful as long as we can
identify what is required easily.  Alternatively pass on to profiles that
warrent such details.

Nick






> -----Original Message-----
> From: Trevor Perrin [mailto:trevp@trevp.net]
> Sent: 20 September 2004 09:04
> To: dss@lists.oasis-open.org
> Subject: [dss] status of core
>
>
>
>
> Here's the current status of core.  Discussions with Ed and Gregor have
> settled on a bunch of changes we'd like to make, and some open
> issues.  I'm
> just batching the changes for now, so other people can review, and so we
> can add any other changes to the list and apply them all at once.
>  Now that
> we're at a Committee Draft, we probably don't want to rev the
> document too
> many more times.
>
> Functionality Changes:
>   1) Lines 278-282, 370-376, 937-943: Replace use of transmitted
> DTDs with
> XML Schema.  Probably doesn't need to be base64 encoded any more.
>   2) Line 834-841, Change <DocumentWithSignature> to contain a
> <Document>.  Add text stating that if neither XPathAfter nor
> XPathFirstChildOf are present, the server is being asked to
> decide where to
> place the signature.
>   3) Line 842-851, add 'ObjId' to <EnvelopingSignature> to set the 'Id'
> attribute in the created <ds:Object> (Gregor's suggestion was
> 'IdAttr', but
> 'ObjId' mirrors 'RefId')
>   4) Line 920-931, add another sentence or two explaining that if
> <SignaturePtr> points to multiple signatures, they should all be verified.
>   5) Line 1132 - 1134, if no signing time could be found, the output
> element may be omitted
>   6) Line 1334, use application/xml instead of text/xml for the binding.
>
> Text Changes:
>   - Line 570 - 571: clarify somehow
>   - Line 975, "Upon receiving this >>>result<<< code"
>   - Line 1018 - 1019, "Otherwise, if the CMS signature is enveloping, it
> contains its own input data>>>, and there MUST NOT be an input document
> present<<<."
>
> Outstanding:
>   1) Mention that a DSS "Input Document" could be a signature to be
> counter-signed or timestamped, or a Manifest.  Probably can be
> done with a
> sentence or two in 2.4.  Profiles can offer more detail.
>   2) How to handle manifests? - right now we don't do much special for
> them, except clients can specify manifest verification with the
> <VerifyManifests> optional input.  For creating manifests, or
> using custom
> verification logic (such as ignoring verification errors), clients are on
> their own (i.e., a client can prepare a Manifest, and send it or its hash
> as an Input Document).   Gregor has proposed:
>     - Client can instruct the server to create a single, first-level
> Manifest and add references inside it with an AddToManifest attribute on
> SignedReference.
>     - Change <VerifyManifests> processing to have server ignore
> errors, and
> just return more sophisticated error details, so the client can see what
> happened.
>     - Change <ReturnTransformedDocument> so it can reference a document
> within a first-level Manifest.
>   3) Should we have more specific <ProcessingDetails>, to return in a
> structured form exactly which signature failed, or which
> Reference failed,
> or how it failed?
>
>
> 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_wor
kgroup.php.