status of core

[Trevor Perrin <trevp@trevp.net>]

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