[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 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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]