Practice Cryptography!

So I'm looking at ITU Recommendation X.693, identically published as ISO/IEC 8825-4. This is actually a fairly short one, as these things go -- it's an 18 page PDF, 4 pages of boilerplate at the beginning, 1 page for the Table of Contents, 1 page Introduction, and then finally (on page 7 of 18) get into the meat of it. However, page 9 actually starts the definition at the bottom of the page, and page 13 completes it.

Pages 14 and 15 are "Annex A": examples of each of the "Basic XML Encoding Rules" and the "Canonical XML Encoding Rules". There's also this (very sour-sounding, to my ears) note:

The length of this encoding in BASIC-XER is 653 octets ignoring all "white-space". For comparison, the same PersonnelRecord value encoded with the UNALIGNED variant of PER (see ITU-T Rec. X.690 | ISO/IEC 8825-1) is 84 octets, with the ALIGNED variant of PER it is 94 octets, with BER (see ITU-T Rec. X.691 | ISO/IEC 8825-2) using the definite length form it is a mininum of 136 octets, and with BER using the indefinite length form it is a minimum of 161 octets.

I suppose worrying about record sizes does make some sense if you're worrying about information being transmitted over a 56kbps link... but it doesn't make sense nowadays, as far as I'm able to tell, with the Web.

I wonder if I can coax Sleepycat DBXML to let me put something in in BASIC-XER and pull it out as CANONICAL-XER.

But anyway, after all of this, there's 2 blank pages (without even the self-defeating "this page intentionally left blank" text), and then 1 last page of boilerplate.

How someone's supposed to actually use this in any kind of signature system is outside of my realm of ability to think at the moment -- then again, I'm also rather ill, so I'm not thinking as clearly as I otherwise would be.