Further discussion on the encodings we want

[John Larmouth <j.larmouth@salford.ac.uk>]

I want to discuss a little more what we want.  (Good text is easy, once 
we know what we want.)  I have no strong views on what follows.  We just 
need to decide which way to go and then to get clear text.

First, the X.509 stuff in OCTET STRINGS with BASE64 used is not really a 
problem using English language text, and I can sort that.  Doing it 
formally raises the problem that the contents of the octet strings are 
not fully specified at present - a concatenation of DER certificate 
encodings (which I think is what is intended, but there is no precise 
reference to what "certificate" means in this place), rather than 
formally specifying a DER encoding of "SEQUENCE OF Certificate" with 
"Certificate" IMPORTED into the module, (the two are **very** different) 
is not well-specified at present.  (Then we get into the BASE64 area on 
this.)   *** It is my belief that Phil intended a concatenation of DER 
encodings, rather than the encoding of a defined type. ***  I can 
produce text for this, (and then apply BASE64) but tools will not 
directly support it, and the formal notation in Amendment 1 will not 
support it either, so this is not just "in anticipation of a standard". 
  ***But I think this is the way we should go***.  I am pretty sure it 
is what Phil intended.

Second, BiometricObjects.  This one is more tricky. I initially 
recommended that all encodings outside of the OCTET STRINGs carrying DER 
material should be CXER.  That works.  But it does indeed mean that 
*all* XML markup is CXER.  Which actually means there is no 
non-significant white-space.  This means that sending it to a text 
display system will produce something pretty unreadable.  Sending it to 
an XML-aware tool such as a browser may well produce good formatting, so 
  use of CXER everywhere may still be OK.  (It is certainly simplest, 
and is what I orginally recommended.)

However, the alternative of BASIC-XER as the overall encoding needs 
exploring as an option.  Suppose we do that.  The cryptographic 
algorithms applied to a BiometricObject produce a signature (for 
example) based on the **CXER** encoding of that object (it *has* to be a 
canonical encoding for the cryptographic algorithms).  A CXER encoding 
is essential for these transfotmations.  This is the old, very old, 
OSI/X.509 issue - cannonical encoding rules are needed.  You need to do 
the CXER encoding in order to produce the signature OCTET STRING using 
the cryptographic transforms.  You can then (if you wish) use that 
encoding for sending the material, because a CXER encoding *is* a valid 
BASIC-XER encoding.  *** But if you relay into a PER encoding, and then 
out again in a later relay to a new XML encoding, the relay system only 
knows that the overall encoding has to be BASIC-XER (because we are 
saying we are doing BASIC-XER, not CXER overall), and will produce a 
BASIC-XER encoding that is highly likely to be not the original CXER 
encoding. ***

So the signature validation at the receiving end will fail.  The 
receiver then needs to decode to the abstract value,  re-encode with 
CXER, and then check again, when the signature will succeed.  This has 
been well understood for about twenty years, and is described in .... (I 
tried to find this.  I thought it was  an X.690 Annex, but it is not, at 
least, not in the current version, but it may be in an older version. 
It could also be an Annex to the OSI Presentation Layer Protocol Spec. 
If I can find it, I will forward it, but hopefully what I have said 
above is clear enough.

*** ON BALANCE ***:  I still recommend that we do CXER (apart from the 
OCTET STRINGS that contain DER with BASE64 applied) everywhere, as I 
originally recommended, but a consensus is needed.

Please note that the current text is ambiguous on this issue of 
BASIC-XER v CXER for the outer-level stuff.  The Abstract clearly states 
CXER everywhere, but later text says (or certainly implies) CXER for 
BiometricObejcts and BASIC-XER for the outer-level stuff.  You can argue 
that the Abstract was not intended to be precise.  I think the issue is 
up for grabs.  We can go either way.  I can easily produce text for either.

What do we want to do?

All I really care about (as ad hoc Editor) is precise text!

John L

-- 
PLEASE NOTE - As an anti-SPAM measure, e-mails will shortly
not be accepted by my machine from an unknown sender unless
the subject contains the phrase "Hi John".

If you pass my e-mail address to others (which I am very happy
for you to do) please tell them to include this phrase in the
subject line of their first mailing to me.  Thanks.

    Prof John Larmouth
    Larmouth T&PDS Ltd
    (Training and Protocol Development Services Ltd)
    1 Blueberry Road
    Bowdon                               j.larmouth@salford.ac.uk
    Cheshire WA14 3LS                    (put "Hi John" in subject)
    England			
    Tel: +44 161 928 1605		Fax: +44 161 928 8069