Next Steps for XML Signature & Encryption

Phillip Hallam-Baker
Principal Scientist, VeriSign Inc.

Signature Profiles

A recurring problem in application development is determining what form of security enhancement is required in a particular circumstance. What algorithms are acceptable, what transformations, how is the keying material to be identified.

One approach to meeting this need is to develop a elaborate description language to allow each aspect of a security enhancement to be specified 'a la carte'. This approach is typified by the IPSEC ISAKMP negotiation mechanism which allows the parties to perform a multi-dimensional negotiation of the security context.

The a la carte approach becomes particularly intractable when the choices on option are not orthogonal. This is frequently the case when cryptographic hardware is employed. While the machine may be capable of using signature algorithm X and digest algorithm Y it may not be able to use both at the same time.

An approach that has proven rather more tractable in practice is to employ suites of matched cipher algorithms. This approach is taken in SSL where the parties chose one 'plat du jour' from a limited menu.

In practice the vast majority of applications call for use of a very limited set of options. Limiting the scope for unexpected interactions between code paths makes implementation and in particular testing easier.

Requirement Specific Profiles

From time to time there are proposals for technology to meet 'legal requirements' for digital signatures. In practice no amount of technology can ever eliminate all possibility of doubt and no flaw in a technology can render a signature of no consequence whatsoever.

Legal requirements for signatures represent simply a set of risk mitigation controls that are appropriate for certain application and it is the application task that determines the need for risk mitigation, recourse to law being merely the last recourse in a risk mitigation strategy.

Requirement specific profiles would target a specific requirement such as a need for signatures that cannot be repudiated under a given set of assumptions or the need to create a signature on material to be archived for extended periods of time. In each case the suite of technologies to be employed would be specified (e.g. X.509v3 digital signatures, PKIX timestamp, OCSP token) together with the assumptions under which the specified requirement is met (e.g. the trusted third party does not default).

It is impractical for the working group to attempt to track legislative initiatives in every jurisdiction in which XML signatures are to be used and highly undesirable for a technical group to attempt to track legislation. Presenting a limited menu of requirement specific profiles allows developers and users to determine whether a particular legal criterion is met.

General Updates

Support for ECC cipher suites

Support for the NIST Suite B algorithms is required for certain government applications and will become increasingly necessary for other applications. Public key cryptography in discrete fields suffers from diminishing returns as the key length is extended making 2048 bits the practical limit.

While there are few algorithms that require ECC cryptography today it is clear that this will become an increasing need within the lifetime of the specification and particularly so with the expiry of patents alleged to encumber certain modes of use.

Description of X.509v3 Trust Path