Re: [xcbf] Discussion document on XCBF spec

["Ed Day" <eday@obj-sys.com>]

> If we are saying that some (random) types have to be CXER-encoded and
> others can be XER, then the "clearly" bit gets quite problematic.
> (There will be border issues, for example on white-space where the two
> encoding rules change over.  But maybe we accept the presence of bugs
> until an interworking problem arises, in the interests of getting this
> stuff out of the door.)

I have no problems with the potential bugs because it is standard practice
today to mix BER and DER in messages and I would think its parallel (XER and
CXER) would be no different.

I guess it is up to Tyky if we have a NetMeeting or phone conference.  I
personally would prefer a conference call as I think NetMeeting is too buggy
(dropped connections and the like).

Ed

----- Original Message -----
From: "John Larmouth" <j.larmouth@salford.ac.uk>
To: "Ed Day" <eday@obj-sys.com>
Cc: "xcbf" <xcbf@lists.oasis-open.org>
Sent: Thursday, May 08, 2003 9:29 AM
Subject: Re: [xcbf] Discussion document on XCBF spec


> Ed Day wrote:
> > I don't know that any open types are involved.  When I follow the chain
down
> > from BiometricSyntax through IntegrityObjects to SignedData, I see the
> > certificate options as OCTET STRINGS.
> >
> > Perhaps outer-level encoding is not the right way to say this.  If you
look
> > at the sample encodings in the back, they show  complete messages
encoded in
> > XER and CXER form.  I think all we are saying is that the CXER form
can't be
> > used if the integrityObject option of the CHOICE is used and it contains
one
> > of the Base64 encoded certificate options.
>
> I am not sure I understand this.  Is there a typo with the last CXER
> above - should be XER????
>
> One of the problems is with:
>
> DigitalSignature ::= SEQUENCE {
>    back  algorithmID  SignatureAlgorithmIdentifier,
>     signature    OCTET STRING
>                   ( CONSTRAINED BY { -- signature on a value of --
>                                               EncodedBiometricObjects })
> }
>
> Signature "on a value of" is misleading, but other text makes it clear
> that the signature OCTET STRING contains an encryption transform
> (identified by the SignatureAlgorithmIdentifier) of the *C*XER encodig
> of EncodedBiometricObjects, which is an Open Type containing
> BiometricObjects (as in my previous e-mail).  Note that this formally
> means that the signature is applied to the XER wrapper round
> BiometricObjects, not just to the content.  I suspect this was an error,
> but I do not intend to try to correct it, and I have noticed similar
> "error"s in other earlier pieces of Phil's specs, so we will let that lie.
>
> > Granted this is a deviation from standard XER encoding, but we have
already
> > established that to be the case.
>
> I guess I still need clarity on what encodings we want to apply to what
> parts of the spec, and whether we are prepared to DEVIATE from the ASN.1
> encoding rules, or just (as was agreed in the telecon) merely to
> ANTICIPATE them.
>
> I think doing something which neither conforms to the current ASN.1 text
> NOR to the expected text for EXTENDED-XER would be a very BAD idea, and
> is not what was agreed.
>
> But I suppose that if we can't keep everyone happy without defining our
> own deviations, then we can in theory do that, but we must do it openly,
> clearly, and honestly.
>
> If we are saying that some (random) types have to be CXER-encoded and
> others can be XER, then the "clearly" bit gets quite problematic.
> (There will be border issues, for example on white-space where the two
> encoding rules change over.  But maybe we accept the presence of bugs
> until an interworking problem arises, in the interests of getting this
> stuff out of the door.)
>
> I don't know if we are really serious about an application that starts
> off with an XML encoding and goes to a relay (that knows only the ASN.1
> spec) which converts to PER, and then to another that also knows only
> the ASN.1 spec and converts to a new XML encoding, but if we ARE serious
> about that application, we have to be very careful about changing
> encoding rules in a non-formal way.
>
> I fear that the more we discuss this stuff, the less clear I get on
> where we are heading.
>
> Ed, you seem to be saying "Let's treat the examples as normative, and
> try to fix the formal spec to fit them."  We can try to do that, but I
> am not sure it will be easy, and it will probably raise the same
> questions we have above about deviation rather than anticipation.
>
> I guess I want to repeat my suggestion of a NetMeeting.  At present, I
> am not sure we are converging.
>
> John L
>
>
> >
> > Ed
> >
> > ----- Original Message -----
> > From: "John Larmouth" <j.larmouth@salford.ac.uk>
> > To: "Ed Day" <eday@obj-sys.com>
> > Cc: "xcbf" <xcbf@lists.oasis-open.org>
> > Sent: Wednesday, May 07, 2003 3:55 PM
> > Subject: Re: [xcbf] Discussion document on XCBF spec
> >
> >
> >
> >>I take your point on not using BASIC-XER, although I would prefer to use
> >>  "basic XER" if you are agreeable, to avoid confusion.
> >>
> >>But your point b) unfortunately is not possible unless the Open Type is
> >>changed to an OCTET STRING.  Open types are *always* (in all encoding
> >>rules) encoded according to the same encoding as the outer-level
encoding.
> >>
> >>So even if you start with a CXER encoding (which indeed *is* a valid
> >>basic XER encoding), going through a PER relay can produce a non-CXER
> >>encoding (some other basic XER encoding, as there is no formal knowledge
> >>that it should be CXER), so the receiving application will need to
> >>decode and re-encode with CXER in order to check the signature etc.  But
> >>provided that is understood and clearly spelled out, this is a workable
> >>solution.
> >>
> >>John L
> >>
> >>
> >>Ed Day wrote:
> >>
> >>>The combination we were closest to at the end was:
> >>>
> >>>a) BASE64 for the CertificateSet and CertificateRevocationList OCTET
> >>>STRING's
> >>>
> >>>b) XER for the outer level encoding and CXER for the BiometricObjects
> >>
> > (note:
> >
> >>>for the purpose of this document, the term "BASIC-XER" is not
recognized
> >>>because it does not exist in any published standard).
> >>>
> >>>Regards,
> >>>
> >>>Ed
> >>>
> >>>
> >>>----- Original Message -----
> >>>From: "John Larmouth" <j.larmouth@salford.ac.uk>
> >>>To: "Ed Day" <eday@obj-sys.com>
> >>>Cc: "xcbf" <xcbf@lists.oasis-open.org>
> >>>Sent: Wednesday, May 07, 2003 2:23 PM
> >>>Subject: Re: [xcbf] Discussion document on XCBF spec
> >>>
> >>>
> >>>
> >>>
> >>>>A further reply:
> >>>>
> >>>>We have four options now (combinations of a) and b) below):
> >>>>
> >>>>a) Use of BASE64 or not for the DER encodings in the OCTET STRINGs
> >>>>
> >>>>b) Use of CXER or BASIC-XER as the outer-level encoding.
> >>>>
> >>>>It is my honest belief that clear conformant text can be produced for
> >>>>all four combinations (but with very different imlications for the
> >>>>complexity of implementations, particularly if relaying in and out of
> >>>>PER is being envisaged - see an earlier e-mail).  I am prepared to
> >>>>produce draft text for **any two** out of the four, but not for all
> >>>>four!  You can then decide which you like best.
> >>>>
> >>>>Let me know which two you want text for.  (Noting that BASE64 is
> >>>>currently in, but that the current text is ambiguous/inconsistent on
b)
> >>>>above.)
> >>>>
> >>>>Would a NetMeeting, once Paul is back from holiday and can host it, be
a
> >>>>useful way of resolving this, or do you want to try to settle it
sooner
> >>>>by e-mail?
> >>>>
> >>>>John L
> >>>>
> >>>>
> >>>>Ed Day wrote:
> >>>>
> >>>>
> >>>>>It was my understanding from Phil that CXER could not be used for the
> >>>>
> >>>entire
> >>>
> >>>
> >>>>>message because the Base-64 encoded DER components would violate the
> >>>>
> >>>CXER
> >>>
> >>>
> >>>>>rules for OCTET STRING encodings.
> >>>>>
> >>>>>Regards,
> >>>>>
> >>>>>Ed
> >>>>>
> >>>>>----- Original Message -----
> >>>>>From: "John Larmouth" <j.larmouth@salford.ac.uk>
> >>>>>To: "Ed Day" <eday@obj-sys.com>
> >>>>>Cc: "xcbf" <xcbf@lists.oasis-open.org>
> >>>>>Sent: Wednesday, May 07, 2003 12:52 PM
> >>>>>Subject: Re: [xcbf] Discussion document on XCBF spec
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>>>The document is currently inconsistent, Ed.  Do we intend CXER
> >>>>>
> > encoding
> >
> >>>>>>for everything excpet DER, or use of basic XER at the outer-level?
> >>>>>>
> >>>>>>I think minimum changes mean we do everything with CXER (and DER),
and
> >>>>>>remove any text that implies the opposite - probably only a sentence
> >>>>>
> > or
> >
> >>>>>>two, at most.
> >>>>>>
> >>>>>>I will produce a document to that effect in the next few days.
> >>>>>>
> >>>>>>John L
> >>>>>>
> >>>>>>Ed Day wrote:
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>>I think given this late date that changes should be kept to a
> >>>>>>
> > minimum.
> >
> >>>>>What
> >>>>>
> >>>>>
> >>>>>
> >>>>>>>is there has already been approved for the most part.  Only a few
> >>>>>>
> >>>tweaks
> >>>
> >>>
> >>>>>>>describing how the Base64 encoding is to be accomplished should be
> >>>>>>>necessary.  I think any big changes need to be deferred to the next
> >>>>>>
> >>>>>version.
> >>>>>
> >>>>>
> >>>>>
> >>>>>>>Regards,
> >>>>>>>
> >>>>>>>Ed Day
> >>>>>>>
> >>>>>>>
> >>>>>>>----- Original Message -----
> >>>>>>>From: "John Larmouth" <j.larmouth@salford.ac.uk>
> >>>>>>>To: <j.larmouth@salford.ac.uk>
> >>>>>>>Cc: "xcbf" <xcbf@lists.oasis-open.org>
> >>>>>>>Sent: Sunday, May 04, 2003 4:26 PM
> >>>>>>>Subject: Re: [xcbf] Discussion document on XCBF spec
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>>To reply to my own message:
> >>>>>>>>
> >>>>>>>>John Larmouth wrote:
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>>I understand that you should be getting notification of that
upload
> >>>>>>>>>automatically, but it has not come back to *me* yet.
> >>>>>>>>
> >>>>>>>>It still has not come (but I understand that others have got it).
> >>>>>>>
> >>>Maybe
> >>>
> >>>
> >>>>>>>>the person posting the document does not get the noticiation?  But
> >>>>>>>
> >>>this
> >>>
> >>>
> >>>>>>>>is not the first time that OASIS mailings have taken a couple of
> >>>>>>>
> > days
> >
> >>>to
> >>>
> >>>
> >>>>>>>>reach me when others have got them (don't know why - guess the
> >>>>>>>
> > server
> >
> >>>is
> >>>
> >>>
> >>>>>>>>anti-English!).
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>>(There is no formal mechanism - even with Amendment 1 in place -
to
> >>>>>>>>>formally forbid a HEX encoding.  You can allow a BASE64 encoding
as
> >>>>>>>>
> >>>an
> >>>
> >>>
> >>>>>>>>>encoder's option, but you cannot express formally that you
require
> >>>>>>>>>(only) that to be used instead of HEX.
> >>>>>>>>
> >>>>>>>>I got this wrong - getting too old!  The BASE64 encoding
instruction
> >>>>>>>>*does* prohibit use of HEX (otherwise we would have ambiguous
> >>>>>>>>encodings), but it does NOT mandate BASE64 - use of XML mark-up
for
> >>>>>>>
> >>>the
> >>>
> >>>
> >>>>>>>>contents is still allowed as an encoders option.
> >>>>>>>>
> >>>>>>>>Sorry for the wrong information.
> >>>>>>>>
> >>>>>>>>(I don't think this affects the main discussion on what we want
for
> >>>>>>>
> >>>>>XCBF.)
> >>>>>
> >>>>>
> >>>>>
> >>>>>>>>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
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>--
> >>>>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
> >>>>
> >>>>
> >>>
> >>>
> >>>
> >>>
> >>
> >>--
> >>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
> >>
> >>
> >
> >
> >
> >
>
>
> --
> 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
>
>