Military Communications and Information Technology: A Trusted ...

Chapter 4: Information Assurance & Cyber Defence
451
Although we do not consider them here, the possible additional levels of metadata
are easily added as another (recursive) children of cbis:securityMetadata.
The new type cbis:Signature is inherited from W3C XML-signatures
type ds:Signature by adding a type qualifier. It should be noted that while
ds:SignatureMethod requires fixed mandatory and a number of optional
implementations, user-specified algorithms may be used as well, and this allows
also n-tuple signature-values (though under one identifier only).
The following (extra) namespaces are used:
• xmlns:ds=”http://www.w3.org/2000/09/xmldsig#”,
the XML-signature types (specifically, ds:Signature). This is the base
type of cbis:Signature, and is used mainly to differentiate between
different versions of integrity, if the public key management architecture
so requires (in addition to containing the actual signature value).
• xmlns:xenc=”http://www.w3.org/2001/04/xmlenc#”,
the XML-encryption types (specifically, xenc:encryptedData and
xenc:encryptedKey). It should be noted that we use one-to-many
relation from the encrypted data blob to the encrypted key, which may not
directly be supported by standard implementations. Thus we leave the link
from the encrypted key to the actual element one-way only, and leave it to
the application (here: the user agent or filter) to decide which key to use
based on the related information in cbis:AccessSet.
• wsml=”http://www.wsmo.org/wsml/wsml-syntax#”
the cbis:roleExpression is extended from a single role-identifier
to a propositional logic formula (to support more expressive PKMAs).
Actually, the wsml:logicalExpression – schema checks for first
order logic, but the application-level function should ignore any quantifiers
it finds.
In the application space, the decrypting / verifying component (most commonly
the User Agent) must interpret the cbis:permission to mean how to
use the associated cryptographic key:
• If the permission is READ, that particular role’s (or a logical expression
involving roles and activities) private key is able to open the block key.
• If the permission is WRITE, the encryptedKey-structure contains
information about the public key related to the role or logical expression
involving roles and activities, or the public key itself (in unencrypted
form). In either case, the public key indicated by the role is only one
of the possibilities used to verify the element’s content signature. There may
be only one such, but in general case it could be anyone’s who is granted
the write-permissions to this particular element. The verifier should try
to verify the signature with all those public keys, which have a permission
of type WRITE. If any one of them passes, the element should be
accepted as valid.