requester identity as signature property

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

Further the possible issue that I raised at today's DSS meeting:

In further looking at this I have come to the conclusion this is a non-issue
but for the record here is the problem that I was looking at, and my
conclusion.  If you have time I would welcome confirmation that my
conclusion is correct, otherwise you do not need to read further.


In looking at the entity seal profile which carries signed properties:
- 	<xades:SigningTime>
- 	<dss:RequesterIdentity>
In addition, the following may be present:
-	<xades:CommitmentTypeIndication>

I had originally considered that all three may be carried within the XAdES
SignedProperties element.  I have since noted that this element was not made
extensible to maximise interopability.  Hence I had the question how should
<dss:RequesterIdentity> be carried.

Since looking at this further the <SignatureProperty> element defined in
XMLDSig provides a carrier for such properties.  In line with the example
give in XMLDig separate <Reference> elements will be required for the XAdES
SignedProperties and the dss:RequesterIdentity.

If this approach that should be taken for other SignatureProperties added,
in that each additional SignatureProperty should have a separate <Reference>
if it is to be signed.  I was considering whether DSS should defined an
equivalent to the XAdES SignedProperties to bring together RequesterIdentity
with other additional properties to be signed.  However, I now realise that
it is simpler to keep to use the XMLDSig SignatureProperty.

So my conclusion is that I need to update the entity-seal profile to put
<dss:RequestorIdentity> in a <ds: SignatureProperty> and describe how two
<Reference> elements are required in the signature one <Rerference> to the
two <xades: Signedproperties (containing SigningTime and optionally
CommitmentTypeIndication) and the other as <Reference> to the <ds:
SignatureProperty> (containing the RequestorIdentity).

Thanks for your time to those who have read thus far.

Nick