OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

dss message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: RE: [dss] Signature Gateway Profile



Trevor,

Your recommendation for XAdES is sound; and I will include it in the
Signature Gateway Profile.  In addition, per Burt's suggestion, the profile
will explicitly reference the possibility of out-of-band conventions
indicated by the signing key.  For example, if the Signature Gateway Server
validated the manifest, then it signs with key1; otherwise, it signs with
key2.

I concur with your suggestion for including the Type attribute in the
updated signature.

Glenn





                                                                                                                                    
                      Trevor Perrin                                                                                                 
                      <trevp@trevp.net>        To:       <dss@lists.oasis-open.org>                                                 
                                               cc:                                                                                  
                      11/06/2004 03:27         Subject:  RE: [dss] Signature Gateway Profile                                        
                      PM                                                                                                            
                                                                                                                                    
                                                                                                                                    




At 11:26 AM 11/6/2004 -0500, Glenn.Benson@chase.com wrote:

>[...] When the VerifyRequest does not contain a
>RequestUpdatedSiganture, the requester communicates with the DSS server
for
>the purpose of discovering ephemeral information.  The requester can use
>this information any way that it wishes.  However, if the request contains
>a RequestUpdatedSignature, the requester obtains a token of consequential
>evidence that can be re-validated by other parties.
>
>Unfortunately, the third party cannot unequivocally determine the intent
of
>the DSS server.  For example, the third party does not know if the DSS
>server validated the manifest before producing the signature.

The updated signature can contain an indication of signature policy.  For
example, if the updated signature is an XAdES signature, it can contain a
SignaturePolicyIdentifier specifying whether or not Manifest Verification
was performed.


>[...]I would also like to expand the requester's flexibility when it
submits a
>request for the signature.  The requester should, for example, request a
>signature of (i) the original document, (ii) a countersignature of the
>original signature, or (iii) both of the above.

For (i) and (ii), simply define different URIs for the
ReturnUpdatedSignature/@Type attribute.  For (iii), right now only one
occurrence of ReturnUpdatedSignature can be sent per request (see section
2.7, 4th paragraph).

We could change that, and have the returned <UpdatedSignature> elements
contain a 'Type' attribute so clients can match outputs with inputs.  That
seems like a worthwhile feature, what do you (or anyone else) think?


Trevor


To unsubscribe from this mailing list (and be removed from the roster of
the OASIS TC), go to
http://www.oasis-open.org/apps/org/workgroup/dss/members/leave_workgroup.php
.







[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]