[no subject]

<ed>
I personally find the introduction of the 3 DSS-XAdES profile specific
SignatureForm values which are NOT the same as the 6 officially published
XAdES forms (i.e. XAdES, XAdES-T, XAdES-C, XAdES-X, XAdES-X-L, and XAdES-A)
confusing. Getting back to the inter-op discussion above, it is very likely
that XAdES implementors would naturally gravitate to the standard forms and
their definitions. I will pick this discussion up below where more
appropriate.
<ed> 

>> >Is there any difference between controlling XML signature properites 
>> >and CMS signature attributes (except the name?)
<ed>
This is a good question. Our intent with core things like 3.4.6's Properties
and SignedProperties certainly can apply to both pre signature production
activities.
</ed>

>>
>> I guess that once you have read below, you have the answer...
>I'll see below
>
Same comment as above
>
>> >
>> >> 	.This element is not enough in XAdES for 
>> >> IndividualDataObjectTimeStamp.
>> >> A XML signature can collectively sign more than one object, and 
>> >> this property may only affects some of the signed objects. This 
>> >> property needs mechanisms to identify which documents the 
>> >> requester wants to be time-stamped. This problem does not occur in 
>> >> TS 101703.

<ed>
Remember the XAdES IndividualDataObjectTimeStamp and its corresponding
TimeStampType and unbound HashDataType array are produced before insertion
of the resulting timestamp into the document as a "signed" property
(attribute). Our DSS core SignedReferences construct could be extended to
include another child specifying which references should be included
(excluded) in (from) the scope of the timestamp and thus factor in the
timestamp's hash iteration. This is a perfect example of why we treated
timestamping as a specific case within a more generalized signing activity.

</ed>

>> >>
>> >
>> >How about certain attributes / elements of this optional input only 
>> >being applicable to XAdES.
>> >
>> Yes, this is what I had in mind. Allowing some extensibility 
>> mechanism to derive new types...
>
>Will see what this means with specific cases.
OK
>
>> >
>>I think
>> that I have heard sometimes the word "authentication" associated to 
>>ClaimedIdentity.
>> I think that the authentication of the requester will be a must in 
>>certain  use cases
>>
>When we discussed this earlier the conclusion is that the requester is 
>authenticated using the underlying access protocol (e.g. TLS 
>certificates, HTTP authentication).  I am still unsure whether an 
>option is also needed to carry an authentication token with Claimed
Identity.
>
Mmmmm, is this something that we could re-raise in the group? I mean, if a
decision was taken after discussion....On the other side would it not be
worth to be able to trace the authentication tokens in the server for
allowing auditing of potential problematic situations?

<ed>
Good discussion, by just outside the scope of my required feedback. See also
the more recent thread on the possible support/use of SAML assertion tokens.
</ed>  

Anyway, what perhaps would be good
is to allow that element at least to indicate that the requester has been
authenticated and the authentication means.
>> >
>> >> -DataObjectFormat. Here again, the XadES and TS101733 could 
>> >> differ, as XMLDSIG may be applied to more than one document, and 
>> >> we need identify
>> which one this
>> >> property
>> >> pertains to.
>> >>

<ed>
I saw this as another justification for extending the core's
SignedReferences construct. DataObjectFormat is optional and is only
required when relying parties MUST be presented the signed info in human
readable form and thus need more info as to its rendering (I assume beyond
what transforms support).
</ed> 

>>
>> ???
>> Yes, in CMS you encapsulate a blob of bytes and sign it. In XML you 
>> are able to sign different objects (each one with its own 
>> ds:Reference element). Each object may have a different format, so 
>> you may have different instances of dataobjectformat values, each one 
>> corresponding to one or more objects.

<ed>
This is true. Again they are optional, and like the
IndividualDataObjectTimeStamp may be on a subset of all those ds:References.
</ed>

>>
>?? If this is a property of the XAdES signature as a whole, isn't there 
>a similar problem in XAdES!!!
>
Mmm I am not sure what you mean here.... In XAdES the DataObjectFormat may
be a property of the each one of the signed objects, not of the signature
itself.
Each signed object may have a different format. This can not happen in CMS,
because whatever you sign comes within an OCTECT STRING.... so in XAdES if
you want to specify the formats of two signed objects, and these formats are
different, you must include two properties, not one, and each one will be
associated to one of the two objects.

<ed>
Not solely based on potentially different formats, but anything that changes
human-readable rendering (e.g. stylesheet, transform, special printing
instructions, font download pre-requisites, etc ...). Yes there is a bit of
an overlap with transforms here. If a stylesheet can render the data object
in human readble form, does not the presence of a transform algo in the
reference suffice. Yes, but shouldn't you sign that transformation if it
indeed is a separate artifact ? I believe this is where DataObjectFormat
fills in gaps.
</ed>

>> >
>> >> 	-Timestamps: to decide how to request them: by Property or by 
>> >> AddTimeStamp
>> >> 	 IndividualDataObjectTimeStamp for XAdES: additional infor.
>> >>
>> >Possibly recommend by "AddTimeStamp"?
>> I have to check whether we would need some additional info 
>> (identifier of the kind of time-.stamp that we are requesting) that 
>> could impact the definition of the time-stamp. I mean, something that 
>> would qualify the request implicitly
>> saying: "add a time-stamp that covers this element and this and this 
>> and this of the signature" (in fact each time-stamp defined in
>> TS101733 and in XAdES covers its own repertorie of elements.
>
>This could be getting complicated.

<ed>
No. No. I did not resist this complexity when I first looked at it. I looked
at the complexity as having been taklen care of. By XAdES of course. In fact
does the core's current extensibility points not allow these additional
inputs and outputs ?  
</ed>

Perhaps is my writing what makes it to appear more complicated than it could
actually be. 
I think that it would be enough to add an attribute (URI) identifying the
kind of time-stamp requested.

<ed>
Yes, but stick to the XAdES forms and there corresponding TimeStampTypes and
their corresponding input and output elements. In a nutshell. Resue and
delegate and leverage XAdES right from the core as much as possible.
</ed>

Regards 

Juan Carlos.