Markup versus Semantics

I started developing our first signature engine for XFDL during the last
quarter of '97.  The engine used Microsoft CryptoAPI.  You can download a
copy of our code from the Dr. Dobb's Journal website (www.ddj.com) by
looking for the June '98 issue.

If you take the trouble to also get the article, you'll find that it also
talks about a security hole in the Microsoft example code.  The example code
would attach the signer's certificate to the signature (which we really
wanted), and the verification phase would obtain the certificate and use it
to check the signature.  The check did not include checking the signature on
the signer's certificate using the CA certificate appearing on the
verification box.  Absurdly, the example code trusted the message to provide
the public key to the verification, which is wide open to a substitution
attack.

The point here is possible to write a signing module that offers Sign() and
Verify() to signed XML and yet the module itself introduces a security hole.
I don't think any amount of markup is going to change that.  The reason is
that markup is declarative yet this is an error in process.  Since this is
an error in the expected 'meaning', it doesn't matter whether you declare
what you want in binary or in markup.

The question really is, how much semantics should be specified in the signed
XML spec to ensure security.  Should we say how particular signature
technologies should be used?  The more I think about this, the more I
realize that it is not our job to specify how signature technologies should
be used to ensure security.  We should write a specification that does not
introduce any new security holes, but if the underlying module is insecure,
then that cannot be held against signed XML itself.  It must be held against
the security module.

What's the difference?

The above problem is an example of a security hole in the underlying module.
A security whole we could introduce at the markup level would be failing to
include the hash algorithm in the message to be signed.  (Obviously, the
current proposals don't have this problem; this is just an example to show
the difference).

The actual problem we need to address is interoperability.  Part of the
signature manifest should declare the signing engine.  This will be a simple
string that identifies equipment used to create the signature.  However, a
generalized , but particular signing technologies can generate many
different binary blobs.  For example, CryptoAPI can create a blob based on
an MD5 hash or SHA-1 hash, it can choose to not add the signer certificate,
or add any number of certificates.  CryptoAPI itself can support crypto
drivers that provide numerous algorithms (RSA, DSA, Fortezza, etc.), and the
list of parameterizations goes on.

The natural reaction to this is probably "Geez, John, this is precisely what
efforts like the Richard Brown draft are trying to solve.  The markup is
carrying these parameterizations so we can define exactly what a given
signature engine is supposed to do".

I agree that precise parameterization is required to get the right
semantics, but I don't think the parameterization can be marked up.  The
reason is that "signature parameters" as a sublanguage must itself be
extensible.  XML is an "extensible" language in the sense that it defines
grammar without (much) vocabulary.  XML extensions provide vocabulary.
However, XML doesn't have much support for extensible vocabularies.  In
particular, the notions of namespace and DTD are intertwined, and DTD's do
not support extensible vocabularies.

Why must the signature parameters be extensible?

This is really the question of whether we can define a set of markup that
satisfies all security needs going forward.  We can't.  The parameters to a
signature engine are specific to the technology it offers.  Parameters for
different kinds of technologies (like pen versus cryptography) will vary
widely.  We obviously need signature parameters, but they should be included
in the character content of the signing engine tag, but not as actual
markup.  If they were markup, you'd have to change the DSIG DTD for every
new type of signature technology.

So, who should standardize the parameters to a new signature technology?

The creators of that technology.  RSA has produced volumes of information
(PKCS) about how their signature technology should be put together.  These
are exactly the people who are best equipped to tell us these things.

So, any new technology that comes along need only have some organization
specify how their signing engine character content string should be put
together.  Signed XML itself need not change because the DTD recognizes the
signing engine content as PCData.

John Boyer
Software Development Manager
UWI.Com -- The Internet Forms Company
jboyer@uwi.com