RE: Fw: XML versus ASN.1/DER blob

John,

I think I start to understand your point, though I am still far from being
sure that I agree with it. It seems that you would like to replace algorithm
definitions such as SignatureAlgorithm and KeyAgreementAlgorithm (at least)
by a single "CryptoEngine" identifier. Assuming that signers and verifiers
are both provided with a common set of engines, this should be sufficient
and would free XML-DSIG from having to specify signature encoding.

But, I have still a few concerns, which are nicely illustrated by your last
email. Please consider the following that you have sent early on:

>
> The relationship is that both have this form
>     SignatureBlob = Sign(M, ...);
>     Verified = Verify(M, SignatureBlob, ...);
>

Though apparently a trivial interface, you have made use of '...' and in
most circumstances this is where the problem lies. Every crypto engine
requires a given set of parameters, which should be provided or at least
referenced during the call to the engine. It appears that adopting your
approach would only change the nature of the problem. Instead of argueing
about encoding of the cryptographic parameters we will argue about the
interface to the crypto engines. Being exhaustive in this matter will
probably be as difficult as defining adequate encoding of the signature
parameters. My feeling in that we have a broader experience with
well-established crypto pratices than we have with packaged crypto-engines.

I have also a few concerns regarding mandatory binding mechanics. As a
matter of fact, verifying a signature value is usually insufficient. You
need also to establish a secure link between the signer's "identification"
and a trusted root (I do not necessarily mean a CA but rather some entry
point of yours in a trusted framework). If the credentials (if any) remain
opaque to the application logic, then you cannot establish that link. At the
most you know that some credential in the "signature blob" verifies the
signature. You need more. The crypto engine should either externalize such
credentials or be aware of the signification of "OriginatorInfo", which is
contrary to your approach.

Finally, whatever the approach we adopt, we will have to specify what is
MANDATORY - either crypto algorithms or crypto engines - by default. In
other words, specific frameworks such as IOTP, BIPS, or E-Check may elect or
specify whatever they want - interoperability is guaranteed within the
confine of these frameworks. But this is not duable in general. Assume that
Netscape adopts PKCS#7 while Microsoft adopts CMS-V3 in their respective
browsers. Though similar in many respects, these two standards are not fully
compatible (CMS being broader than PKCS#7). One more time, we will put the
burden on the server side that will have to deal with these discrepencies -
and this will be insufficient for three-party exchanges.

Sincerely,

Richard D. Brown

Received on Wednesday, 21 April 1999 21:17:15 UTC