Way Forward on Basic Processing in terms of EnvelopedSignatures,ds:Objects (EnvelopingSignatures), client-side splicing plus client-sidetransforms.

[Konrad Lanz <Konrad.Lanz@labs.cio.gv.at>]

Hi Trevor and all,

Trevor Perrin wrote:

> [...]
>  a) making this a typical optional input, i.e. not part of basic 
> processing
>  b) making this a fundamental part of the protocol, i.e. not an 
> optional input
>
> Since you intend profiles to choose it or not, I suggest (a).

Thanks for bringing this up, this is a crucial point however we have to 
think this through and I think the right answer might be somewhere in 
between.

Executive Summary:
Please read Question I (QI ) and Answer III (QI AIII), (QII) (QII AII), 
(QIII AII) and (QIV) (QIV AI) to see my suggestion.

Detailed Discussion:

If in basic processing a <dss:Document> with a same-document Uri appears 
a XMLSig implementation will have to be able to dereference the data 
there (i.e. in the same-document and its context), so we might have to 
ask for further information. If also <dss:IncludeObject> (or 
<dss:SignaturePlacement> in the case of RefURI="") is pointing to the 
<dss:Document> in question we do not have a problem and we can 
understand this request to include the the content of <dss:Document> in 
question as a <ds:Object> (or we create an EnvelopedSignature in the 
case of SignaturePlacement plus RefURI="").

(Q I)
The interesting question now is: Does the same-document Uri imply that 
there also has to be a <dss:IncludeObject>( or a 
<dss:SignaturePlacement>) and hence a <ds:Object> has to be 
embedded/spliced (or an EnvelopedSignature has to be created)?

(QI AI)
An answer could be yes and we hence have to prohibit same-document Uris 
for basic processing and say they MUST have been consumed by optional 
inputs <dss:IncludeObject> or <dss:SignaturePlacement> already and go 
for a). This however would imply that only DetachedSignatures would be 
created by basic processing.

(QI AII)
Or same-document Uris are allowed for basic processing and we move 
towards b) and say <dss:IncludeObject> or <dss:SignaturePlacement> are 
included as fundamental inputs in the basic processing and hence allow 
the full plurality of possible signatures (e.g. an enveloped signature 
with <ds:Objects>) in basic processing.

(QI AIII)
Basic processing supports same-document Uris as well as others but in 
the case of a same-document URI processing has to be overridden by
<dss:IncludeObject> or <dss:SignaturePlacement> plus server side 
splicing as the safe default behavior for the core.
(I.e. If a same document Uri appears that has not been dealt with 
already by an optional input we'll throw an error, as we cannot 
dereference it without having done the splicing beforehand).
 
Alternatively this can be overridden by client-side splicing 
(potentially plus client-side transforms) by using an 
<dss:AdditionalProfile>, which prohibits the optional inputs 
<dss:IncludeObject> and <dss:SignaturePlacement> and defines that the 
<dss:Documents> having same-document references and are assured to be 
dereference able at the server side. Also the client server distribution 
of transforms and parsing that are used have to have properties as 
required and discussed in the thread (Trevors comments in [dss] Core 
spec: client-side transforms, etc... ) plus others more yet to be discussed.

(QII)
Another question is about one special case we also should not forget 
about: What if a client wishes to have a document with a signature in 
it, having one ore more references with same-document Uris pointing to 
some arbitrary NodeSets within this very same document? How do we 
communicate these RefURIs.

(QII AI)
An answer could be that we do not support that.

(QII AII)
We should extend SignedReference to also have an optional RefURI 
attribute for same-document references in combination with the 
WhichDocument overriding the RefURI of <dss:Document>. Or in the case of 
external-Uris allowing to omit the WhichDocument attribute that the 
server can try to retrieve the document from the Internet via http/https 
or so.

This allows us now to answer Question I with yes in any circumstance, 
and every same-document Uri of <dss:Document> is now either (Ref="" or 
Ref=null) in combination with SignaturePlacement or for a <ds:Object>.
If this was not true the client would have sent a SignedReference having 
the optional RefURI attribute set to a same-document reference in 
combination with the WhichDocument.

> I also suggest not deleting the current text about client-side 
> splicing, but adding qualifications (e.g., that it can be used for 
> <DocumentHash>, or with servers that do not normalize inputs).


This is a good point and I think that client-side splicing should still 
be a crucial part of dss provided that we issue appropriate warnings and 
that it is not the default behavior.

(QIII)
How does client-side splicing now fit in?

(QIII AI)
We could add an optional Input to the core and explain the issues with 
client side splicing there, which might a add considerable amount of text.
    <xs:element name="ClientSideSplicing">
        <xs:complexType>
            <xs:attribute name="spliceDsObjects" type="xs:boolean" 
default="false"/>
            <xs:attribute name="spliceEnvelopedDsSignature" 
type="xs:boolean" default="false"/>
        </xs:complexType>
    </xs:element>

(QIII AII)
We should support client side splicing in a profile defining the element 
above to be included by using <dss:AdditionalProfile>
plus using the ClientSideSplicing as optional input and clearly state 
that we recommend core implementations to also implement this profile.

(QIV)
Should we still call <dss:IncludeObject>, <dss:SignaturePlacement> and 
<dss:SignedReference> optional Input.

(QIV AI)
yes, but require basic processing to use them in the case of 
same-document Uris.

(QIV AII)
no.

best regards
Konrad