[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [ubl-security] Re: Sample instances
At 2010-08-15 11:25 +0200, Andrea Caccia wrote:
>I agree with the "scaffolding approach" and the solutions found.
Thank you for making the time to comment.
Two issues come up with your post:
>If we still need to relate signature with parts
>of the UBL document I suggest to use this scaffolding in the UBL extension:
><ublsig:document-signatures>
> <ds:signature>…</ds:signature>
>...
> <ublsig:IdentifiedSignature>
> <cac:ID>…<cac:ID>
> <ds:signature>…</ds:signature>
> </ublsig:IdentifiedSignature>
>...
></ublsig:document-signatures>
I like distinguishing between those signatures with an ID and those without.
>I think a schema can be implemented with a
>sequence of choices so that inside a
>ublsig:document-signatures container could be
>found a sequence of <ds:signature> or
><ublsig:IdentifiedSignature> in any order and quantity.
In order to better follow the UBL modeling concepts we need to think of:
(a) - "document-signatures" should be either "DocumentSignatures" or,
since some of the signatures do not have document scope, perhaps
just "Signatures"
(b) - the arbitrary mixing of order breaks one of the modeling instructions
so we have to have an order
(c) - I wonder if we need a UBL container for all <ds:signature> since it
already is, itself, a container, but I think this will be a better
instruction to software implementers: without an identifier find
or create the <sig:UnidentifiedSignatures> element and put the
<ds:signature> in it
- the problem with this is that it has to be a singular noun, not
plural, so perhaps <sig:UnidentifiedSignatureSet>
(d) - I realized my earlier suggestion was mixing two namespaces as siblings
which is fine for <cbc:*> and <cac:*> but is it acceptable for the
<ds:*> non-UBL namespace?
>The <ublsig:IdentifiedSignature> element can
>refer to a specific section of the UBL document
>via the cac:ID if this is required to
>disambiguate the reference and, as most of the
>UBL documents have just the document-wise
>signature, in this case there is no need to do
>any preparation work, they will contain just the
>simple scaffolding we already defined:
><ublsig:document-signatures>
> <ds:signature>…</ds:signature>
> <ds:signature>…</ds:signature>
>…
></ublsig:document-signatures>
>
>For other documents it should be quite easy to add something like:
>
><ublsig:document-signatures>
> <ds:signature>…</ds:signature>
> <ds:signature>…</ds:signature> … (these are the document-wise signature(s) )
> <ublsig:IdentifiedSignature>
> <cac:ID>…<cac:ID> (ID of
> cac:CertificateOfOriginApplication when required)
> <ds:signature>…</ds:signature>
> <ds:signature>…</ds:signature> …
> </ublsig:IdentifiedSignature>
> <ublsig:IdentifiedSignature>
> <cac:ID>…<cac:ID> (ID of cac:IssuerEndorsement when required)
> <ds:signature>…</ds:signature>
> <ds:signature>…</ds:signature> …
> </ublsig:IdentifiedSignature>
> <ublsig:IdentifiedSignature>
> <cac:ID>…<cac:ID> (ID of
> cac:EmbassyEndorsement when required)
> <<ds:signature>…</ds:signature>
> <ds:signature>…</ds:signature> …
> </ublsig:IdentifiedSignature>
> <ublsig:IdentifiedSignature>
> <cac:ID>…<cac:ID> (ID of
> cac:InsuranceEndorsement when required)
> <ds:signature>…</ds:signature>
> <ds:signature>…</ds:signature> …
> </ublsig:IdentifiedSignature>
>...
></ublsig:document-signatures>
I like the above (repairing cac: with cbc:) if
Tim approves of mixing <cbc:*> with <ds:*> ... so it would read as follows:
<sig:Signatures>
<ds:signature>…</ds:signature>
(these are the document-wise signature(s) )
<ds:signature>…</ds:signature>
<sig:IdentifiedSignature>
<cbc:ID>…</cbc:ID> (ID of
cac:CertificateOfOriginApplication when required)
<ds:signature>…</ds:signature>
...
<ds:signature>…</ds:signature>
</sig:IdentifiedSignature>
<sig:IdentifiedSignature>
<cbc:ID>…</cbc:ID> (ID of cac:IssuerEndorsement when required)
<ds:signature>…</ds:signature>
...
<ds:signature>…</ds:signature>
</sig:IdentifiedSignature>
<sig:IdentifiedSignature>
<cbc:ID>…</cbc:ID> (ID of cac:EmbassyEndorsement when required)
<ds:signature>…</ds:signature>
...
<ds:signature>…</ds:signature>
</sig:IdentifiedSignature>
<sig:IdentifiedSignature>
<cbc:ID>…</cbc:ID> (ID of cac:InsuranceEndorsement when required)
<ds:signature>…</ds:signature>
...
<ds:signature>…</ds:signature>
</sig:IdentifiedSignature>
...
</sig:Signatures>
If we want to not mix <ds:*> and UBL namespaces
as siblings, and also tell implementers that in
UBL there is only ever one parent of
<ds:signature> elements and it is named
<sig:SignatureGroup>, then we could have:
<sig:Signatures>
<sig:SignatureGroup>
<ds:signature>…</ds:signature>
(these are the document-wise signature(s) )
<ds:signature>…</ds:signature>
</sig:SignatureGroup>
<sig:IdentifiedSignatureGroup>
<cbc:ID>…</cbc:ID> (ID of
cac:CertificateOfOriginApplication when required)
<sig:SignatureGroup>
<ds:signature>…</ds:signature>
...
<ds:signature>…</ds:signature>
</sig:SignatureGroup>
</sig:IdentifiedSignatureGroup>
<sig:IdentifiedSignatureGroup>
<cbc:ID>…</cbc:ID> (ID of cac:IssuerEndorsement when required)
<sig:SignatureGroup>
<ds:signature>…</ds:signature>
...
<ds:signature>…</ds:signature>
</sig:SignatureGroup>
</sig:IdentifiedSignatureGroup>
<sig:IdentifiedSignatureGroup>
<cbc:ID>…</cbc:ID> (ID of cac:EmbassyEndorsement when required)
<sig:SignatureGroup>
<ds:signature>…</ds:signature>
...
<ds:signature>…</ds:signature>
</sig:SignatureGroup>
</sig:IdentifiedSignatureGroup>
<sig:IdentifiedSignatureGroup>
<cbc:ID>…</cbc:ID> (ID of cac:InsuranceEndorsement when required)
<sig:SignatureGroup>
<ds:signature>…</ds:signature>
...
<ds:signature>…</ds:signature>
</sig:SignatureGroup>
</sig:IdentifiedSignatureGroup>
...
</sig:Signatures>
Both of the above preserve the rule of "the
absence of information does not convey
meaning". And since we cannot have choice, we
put all of the <sig:SignatureGroup> elements
before the <sig:IdentifiedSignatureGroup> elements.
I can go with either of the above, but I do like
that the second example does not mix a foreign
namespace with a UBL namespace as siblings, and I
like telling implementers that <ds:signature> has
only a single parent in UBL. It also reminds UBL
users that a set of electronic signatures is
applicable to both the entire document or to any
identified signature. Someone new to UBL might
not realize that a repeating <ds:signature> is
allowed for a single signature concept in UBL.
Actually, I'm talking myself into the second
example more and more with that explanation. I
don't worry about the amount of scaffolding (the
length of the element names or the number of
them) ... I'm more worried about what our users
need to think about and how to convey the
concepts to our users. While <ds:signature> is
implicitly repeated, it doesn't convey to the UBL
user that the signatures are grouped.
But does the above grouping have an impact on the
XPath address of what is signed and what is
not? My thought here is that a signature group
is a self-contained set of signatures and that
the signatures in the group apply to everything
outside of the group. This would limit any group
of signatures being closed once another group of signatures has started.
Or do we simply have an XPath that says anything
that is outside of the ancestor <sig:Signatures>
is what is signed and everything under
<sig:Signatures> is out of bounds? I'm not sure
I like that because I might want to sign the
document-wide signature with the targeted
signatures as part of my signature because I've
approved what someone else has approved.
So, I'm back to making it a workflow issue: once
a group of signatures is started, every signature
for that group must be added before another group
of signatures is started. Then the workflow
leaves the document-wide signatures for when all
of the other signatures are added, and the
document is complete. And the scope of a
signature, then, is everything outside of the
parent of the <ds:signature> element being created.
But overriding all, I think, is conveying to the
UBL user that there can be many <ds:signature>
elements as siblings, all representing the same
content being signed. So this promotes the concept of a <sig:SignatureGroup>.
Tim, what about the ancestor element named
<sig:Signatures> ... this isn't a singular noun it is plural. Should it be:
<sig:SignatureInformation>
to follow the naming and design rules?
>For detached signatures I think it's better to
>avoid any scaffolding other than the standard
><ocf:signatures>…</ocf:signatures> container to
>allow standard packaging. With detached
>signatures we do not solve all the possible
>issues but we still have an useful tool for
>packaging i.e. an invoice, its stylesheet(s),
>the signature(s) and whatever element we need
>for a human readable object ready to be archived long term.
>
>Another useful signature field is the Commitment
>Type. This is an URI that can be defined by the
>user but it's better to stay with the types
>already defined in XAdES (and CAdES), i.e.:
>• Proof of origin indicates that the signer
>recognizes to have created, approved and sent
>the signed data object. The URI for this
>commitment is http://uri.etsi.org/01903/v1.2.2#ProofOfOrigin.
>• Proof of receipt indicates that signer
>recognizes to have received the content of the
>signed data object. The URI for this commitment
>is http://uri.etsi.org/01903/v1.2.2#ProofOfReceipt.
>• Proof of delivery indicates that the TSP
>providing that indication has delivered a signed
>data object in a local store accessible to the
>recipient of the signed data object. The URI for
>this commitment is http://uri.etsi.org/01903/v1.2.2#ProofOfDelivery.
>• Proof of sender indicates that the entity
>providing that indication has sent the signed
>data object (but not necessarily created it).
>The URI for this commitment is http://uri.etsi.org/01903/v1.2.2#ProofOfSender.
>• Proof of approval indicates that the signer
>has approved the content of the signed data
>object. The URI for this commitment is
>http://uri.etsi.org/01903/v1.2.2#ProofOfApproval.
>• Proof of creation indicates that the signer
>has created the signed data object (but not
>necessarily approved, nor sent it). The URI for
>this commitment is http://uri.etsi.org/01903/v1.2.2#ProofOfCreation.
>
>Staying aligned with these definitions allow us
>to be compatible with CEFACT security project
>rules. About this point, we can explicitly
>recommend to comply with the CEFACT
>recommendation as soon as it is published (this
>can be done later during the public review of
>our document, when the CEFACT one will be officially published).
>
>About XAdES itself, it is under standardization
>in ISO/TC154 as the format for long term
>signatures for business documents, so it is not
>limited to Europe. The fact that XAdES, CAdES
>and PAdES are the only technical implementation
>in the CEFACT recommendation, even if in a not
>normative annex, is another reason to sustain its use.
For detached signatures I agree with doing
anything that promotes the reuse of existing approaches.
Thanks, Andrea! I look forward to your comments
on the above. I am delayed this morning from
continuing my work because of problems with the
main schemas, so I have a few hours today for us
to think about this and consider the best names
that follow the UBL conventions.
Tim McGrath is not subscribed to the SecuritySC,
so please copy him on your responses.
. . . . . . . . . . . Ken
--
XSLT/XQuery training: after http://XMLPrague.cz 2011-03-28/04-01
Vote for your XML training: http://www.CraneSoftwrights.com/o/i/
Crane Softwrights Ltd. http://www.CraneSoftwrights.com/o/
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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]