RE: [dss] Request for core: SignedReference

["Edward Shallow" <ed.shallow@rogers.com>]

Trevor and Co.,

    I have attached the thread between Juan Carlos and myself which started
this discussion (off list) thinking it might help.  See <ed> ... </ed>
blocks for the previous SignedReference discussion. I agree with Juan Carlos
that since we are reusing a majority of the SignedReference construct and in
fact XAdES's intent here is to qualify which objects get covered by the
scope of the timestamp, it is entirely appropriate is it not ?. Isn't that
why we resisted making TimeStamp a separate protocol and decided to treat it
fundamentally as a Sign operation in the first place. I contend the better
approach is to extend rather than repeat the schema section in question. It
is a natural. Am I missing something ?

Ed

     

-----Original Message-----
From: Juan Carlos Cruellas Ibarz [mailto:cruellas@ac.upc.es] 
Sent: March 26, 2004 5:16 AM
To: Trevor Perrin; dss@lists.oasis-open.org
Subject: Re: [dss] Request for core: SignedReference

Trevor,

In fact, I think that the only thing that I would not use would be the
ds:Transforms element, which as it is optional would profile to not present
And I think that the RefId could also be needed as the structure supporting
time-stamp would point to the corresponding ds:Reference.

Anyway, I repeat that  I do not have any problem with repeating the schema
(except the ds:Transforms) in the profile.....in fact that was my first
approach, and my question was only that: one question.

Regards

Juan Carlos.

>Do you really want to re-use SignedReference?  This element has a very 
>specific purpose: to control the creation of a <ds:Reference>.  So it 
>has <ds:Transforms> which will go inside the <ds:Reference>, and a 
>RefId attribute which will be used to set the the <ds:Reference>'s Id.
>
>The only thing generic about it is the "WhichDocument" attribute.  Is 
>that what you want to re-use?  If so, that doesn't seem worth factoring 
>out and re-using.  Am I missing something?
>
>Trevor
>
>
 
....... copied thread starts here .......


-----Original Message-----
From: Edward Shallow [mailto:ed.shallow@rogers.com] 
Sent: March 21, 2004 4:43 PM
To: 'Juan Carlos Cruellas Ibarz'; 'Nick Pope'
Subject: RE: Colapsing XAdES and TS101 management in one profile

Hi Juan Carlos and Nick,

     I have reviewed Juan Carlos' Initial XAdES profile submission as well
as related eMail threads and have the following comments. In general I think
it is a good start. Hopefully we can add some clarity and perhaps even
simplify things for the profile implementors. Please see comments
inter-mixed. Talk to you on the call Monday.

Cheers,
Ed

    

-----Original Message-----
From: Juan Carlos Cruellas Ibarz [mailto:cruellas@ac.upc.es]
Sent: March 18, 2004 7:09 AM
To: Nick Pope; ed.shallow@rogers.com
Subject: RE: Colapsing XAdES and TS101 management in one profile

>>
>> Would the
>> >XAdES ineroperability test be the basis of a simple example
>> concrete profile
>> >for XAdES?
>>
>> Do you mean the plugtest event at etsi?
>>
>Yes
Well, in fact, in the first event we gave Philippe the idea of organizing an
event of XAdES and PKI related stuff, mentioning DSS protocol as one of the
candidates... the problem may be that the next event is in May, a bit too
early for having lots of implementations. I would say that if a third event
is organized in September, then it would be a good place for what you
mention.

<ed>Not sure this event would accommodate hybrid protocols like the DSS
XAdES profile. However it could, a DSS XAdES implementation would have to at
a minimum generate all mandatory signature forms the event mandates, and 2)
verify all mandated signature forms from at least one other exhibitor. In
order to do either, the DSS XAdES profile solution would have to prepare DSS
XAdES compliant Verify requests whose signature forms originated within the
exhibitor's solution for verification by us. Conversely, we would have to
"tee up" a request for the 3rd party exhibitor's verification of our DSS
XAdES gernerated signature. Probably a bit of work here on top of the DSS
XAdES implementation itself.
</ed>
   
>
>> >
>> >What do you by a "profile manage ...".  Do you mean how to control 
>> >an implementation that would support both?  Is this provided by 
>> ><SignatureType>?
>> >
>> One profle that would be usable for both ASN1 and XML requests and 
>> deliveries.
>> See my comment on the SignatureType and SignatureForm.
>>
>>
>I'll see below
>