G. Ken Holman ha scritto:
7.0.1.0.2.20091130214521.0278beb8@wheresmymailserver.com"
type="cite">(copied to the UBL list again because I cannot post to the
security list)
At 2009-11-30 15:33 +0100, JAVEST by Roberto Cisternino wrote:
>Thus, we are back to my suggestion that
we need to wrap ds:Signature with an aggregate in order to associate a
cbc:ID with >ds:Signature.
In the attached mail I propose to reference the enveloped signature by
using the existing UBLExtension ID:
cac:Signature/cbc:ID ---------reference--------->
ext:UBLExtensions/ext:UBLExtension/cbc:ID
Is it acceptable ?
Not to my understanding ... that is not the identifier of a signature,
it is the identifier of the extension. If I had three different
extensions in one UBL document, I might use ext:UBLExtension/cbc:ID to
distinguish between the three extensions. That identifier semantic is
specified by the UBL committee and has nothing to do with the
information *inside* the extension that is specified by creators of
extensions. They (including, I believe, the UBL Security SC) do not
have the power to change the meaning of constructs defined by the UBL
committee.
We are just using UBLExtensions and I agree IDs are up to the
implementers 1, 2, 3, 4 so we are just saying that one of these IDs
will have to match the ID of the cac:Signature in order to identify an
enveloped signature using an UBLExtension
7.0.1.0.2.20091130214521.0278beb8@wheresmymailserver.com"
type="cite">
We already use internal references between
payment terms and payment means, so I think this is viable.
But those are already specified by the committee as identifiers of
payment terms and payment means. The cbc:ID you are proposing to use
is not an identifier of a signature, it is already specified to be an
identifier of the extension. Not the extension content.
And, anyway, ext:UBLExtension/cbc:ID is optional and as I understand
the signature requirement the associated identifier is mandatory, so
the cardinality is inappropriate.
Of course as UBLExtensions are free noone can impose a cardinality on
all the IDs, this is why we are going to provide a profile where it is
described how an enveloped signature can be expressed into
UBLExtensions.
We are not changing structures we are recommending a base profile to
ensure the use of UBL with enveloped signature will be interoperable
and driven by this guide. (of course we do not specify specific XAdES
settings this is up to the implementers and communities)
7.0.1.0.2.20091130214521.0278beb8@wheresmymailserver.com"
type="cite">
And, finally, if we go with a wrapper aggregate then the top-level of
the extension is under UBL security committee control and not DSIG
control (in case we decide we want to add more information other than a
mandatory cbc:ID).
Okay so you suggest to provide a more specific container inside the
generic extension container...
I am not sure we need to add further information... the cac:Signature
has already many info that are already the domain of XAdES.
So we have to think if this is really necessary as we currently need
just to make a reference as part of a template-guide for using UBL and
enveloped signature with the UBLExtension methodology.
I would like to have other feedback to understand better.
In general I like the idea to better identify extensions using stantard
containers... let's continue the discussion :)
7.0.1.0.2.20091130214521.0278beb8@wheresmymailserver.com"
type="cite">
For all those reasons, I think we need:
cac:Signature/cbc:ID ---------reference--------->
ext:UBLExtensions/ext:UBLExtension/ext:ExtensionContent/sig:Signature/cbc:ID
... with an associated:
ext:UBLExtensions/ext:UBLExtension/ext:ExtensionContent/sig:Signature/ds:Signature
But this is only my idea and I would like to hear the opinion of
others. I feel quite confident, though, that my approach would be
within the expectations of the committee.
I hope this is ocnsidered helpful.
. . . . . . . . . . Ken
--
Vote for your XML training: http://www.CraneSoftwrights.com/o/i/
Crane Softwrights Ltd. http://www.CraneSoftwrights.com/o/
Training tools: Comprehensive interactive XSLT/XPath 1.0/2.0 video
Video lesson: http://www.youtube.com/watch?v=PrNjJCh7Ppg&fmt=18
Video overview: http://www.youtube.com/watch?v=VTiodiij6gE&fmt=18
G. Ken Holman mailto:gkholman@CraneSoftwrights.com
Male Cancer Awareness Nov'07 http://www.CraneSoftwrights.com/o/bc
Legal business disclaimers: http://www.CraneSoftwrights.com/legal
Nessun virus nel messaggio in arrivo.
Controllato da AVG - www.avg.com
Versione: 8.5.426 / Database dei virus: 270.14.87/2535 - Data di rilascio: 11/29/09 19:31:00
--
JAVEST by Roberto Cisternino
* Document Engineering Services Ltd. - Alliance Member
* UBL Italian Localization SubCommittee (ITLSC), co-Chair
* UBL Online Community editorial board member (ubl.xml.org)
* Italian UBL Advisor
Roberto Cisternino
PPlease consider the environment before
printing this email.
|