[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Further discussion on the encodings we want
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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]