OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

xcbf message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: Re: [xcbf] Discussion document on XCBF spec


Ed Day wrote:

> 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).

We (ASN.1 work) use it regularly with only rarely problems.  It has the 
very distinct merit that what is "said" is recorded in the Chat that can 
be distributed to everyone after the meeting as a record of the meeting.

With a voice conference, you rely on someone taking minutes, and a lot 
gets lost.

Also the shared document facility is *very* useful for progrssing the work.

We can all see what we are talking about.

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: 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
>>
>>
> 
> 
> 
> 


-- 
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]