---------- Forwarded message ----------
From:
Neal McBurnett <neal@bcn.boulder.co.us>Date: Fri, Sep 23, 2011 at 7:45 AM
Subject: Drop the newly proposed hash attributes of URL element, in deference to XML Signature Reference/Manifest
To: EML TC <
election-services@lists.oasis-open.org>
I'm sorry I didn't forward the attached input for p1622 to the election-services list earlier - it just slipped my mind, and as I noted last week I even managed to miss the deadline for v7 comments. My appologies. But hopefully better late than never....
In June I sent p1622 this feedback about the new URL attributes:
> Is there an existing standard that uses the same elements that are used here?
> Would it make more sense to just use standard XML DSIG external signatures?
> What is the "text" option for "HMAC"?
> Why "SHA1" vs "SHA-256"?
> Is "SHA-3" appropriate yet? Won't there probably be multiple versions of SHA-3 (like SHA-2) with different lengths and different names?
> How can the "other" hashalgorithm be disambiguated for interoperability?
> "pdf" is not a mime type. That would be "application/pdf"
I agree with John that we should wait for final resolution of P1622's text before finalizing v7. At the p1622 meeting last week, we agreed that 1622 would require that our EML documents "SHOULD" (in the terms of IETF RFC 2119,
http://tools.ietf.org/html/rfc2119), bear an XML Signaure to provide end-to-end protection of the authenticity and integrity of the information. The "Should" requirement means that
"there may exist valid reasons in particular circumstances to ignore a particular item, but the full implications must be understood and carefully weighed before choosing a different course."
This followed from a discussion John Wack and I had with Harold Booth, an expert at NIST about best practices for use of XML Signature. In that discussion Harold agreed with my earlier feedback to p1622 that the newly proposed URL elements Checksum, HashAlgorithm and HMAC of the URL element are inadequately defined, and there was probably a better way to convey this information.
He explained how it should be done. We should simply have EML producers include the same hash information via the Reference element and its DigestMethod and DigestValue sub-elements.
Getting security formats right is very hard. The alternative of specifying our own hash-related attributes, about which I've raised a number of unresolved issues, just adds extra implementation burden to EML producers and consumers, which customers would rarely if ever want to use. It conveys a misunderstanding of security in general. We can't rely on link-by-link integrity measures, e.g. by specifying that every time EML is used it must be sent over a TLS link. The proper way for a data format standard to provide authenticity and integrity protection is via a signature, and that is what XML signature provides.
Even if for some reason an EML producer doesn't want to actually include a full digital signature on a document, they would be much better off just using the carefully specified Reference, DigestMethod, DigestValue and Transforms elements of XML Signature to convey the hash information. Any reasonable XML security library already supports these elements, and the EML implementor won't have to roll their own tricky security code. And the proposed URL attributes don't address all the issues. E.g. they don't allow for any sort of canonicalization of the referenced document, which the Transforms element does provide. Canonicalization is one of the thorniest areas of getting interoperable security, when docmuents are conveyed over the various transport mechanisms that people end up using.
I've attached the input to p1622 which has more details and an example. The example is a bit out-of-date now, and I've also attached the latest version of that.
John Wack of p1622 says that the last revision of the p1622 draft should be out today, for final review which should happen next Tuesday at the latest. I suggest either just dropping the new URL attributes, or waiting until then for final guidance.
Thanks,
Neal McBurnett http://neal.mcburnett.org/
---------- Forwarded message ----------
From: Neal McBurnett <
neal@bcn.boulder.co.us>
To: IEEE P1622 <
stds-1622@listserv.ieee.org>
Date: Tue, 16 Aug 2011 09:54:15 -0500
Subject: A signed EML 505 example with a Manifest, rather than "Checksum"
John and I had a very helpful and productive meeting with Harold Booth
of NIST (CC'd here) about how to properly use XML Signature, based on
his TMSAD standard-in-progress which John shared earlier.
In my June 27 comments to the WG on our draft, I asked some questions about the
proposed attributes of the <BallotStyleImage><URL> element:
> Is there an existing standard that uses the same elements that are used here?
> Would it make more sense to just use standard XML DSIG external signatures?
> What is the "text" option for "HMAC"?
> Is "SHA-3" appropriate yet? Won't there probably be multiple versions of SHA-3 (like SHA-2) with different
lengths and different names?
> How can the "other" hashalgorithm be disambiguated for interoperability?
> "pdf" is not a mime type. That would be "application/pdf"
The most important outcome of the meeting with Harold was much more
clarity on the Reference and Manifest elements of XML Signature for
signing external documents. They are indeed ideally suited to our
task. So I think we should drop the proposed Checksum, HashAlgorithm
and HMAC elements of the URL element, and include the same information
via the Reference element and its DigestMethod and DigestValue
sub-elements.
This means no extra work for implementors, since standard XML
Signature libraries and applications already know how to retrieve
things like pdf files in the References and hash them and incorporate
that in the overall signature. Far better than "rolling our own
crypto formats", I think, which implementors would have to implement,
and surely have the same kind of feedback that I send in earlier.
So based on the earlier signed example that I shared with you all,
I've added an example of an EML 505 with a Manifest and References
that seems to work well. I also changed the MimeType to be a real
MIME type.
It uses a test "rsakey.pem" key from the xmlsec1 library (also
included). See the attached eml-dsig-example.zip file for the
templates, signed xml, and some supporting info.
Please try verifying the signatures yourselves, with the method I
outline in the Readme.md file or (even better) via your own tools.
Cheers,
Neal McBurnett
http://neal.mcburnett.org/