Re: [xcbf] Groups - XCBF XML Common Biometric Format CS April 3 2003.zipuploaded (fwd)

["Phillip H. Griffin" <phil.griffin@asn-1.com>]

John,

The CS has been approved by the XCBF TC for submission to
OASIS for consideration as a standard. If I can get the paperwork
done to meet all OASIS requirements, I will try to send in our
submission before the deadline fo April 15.

Phil


John Larmouth wrote:

> Phil,
>
> I think we may be having unnecessary disagrements due to 
> misunderstandings, which I would like to get resolved.
>
> I have no problems with mixing CXER and BASIC-XER, provided the types 
> involved are either in an
>     OCTET STRING (CONTAINING ....  ENCODED BY .... )
> or in an open type, and the spec clearly states (in the open type 
> case), the encoding to be used (in the OCTET STRING case tghe ENCODED 
> BY gives it).
>
> But CXER is actually a subset of BASIC-XER (it is just one of the 
> BASIC-XER encodings with all encoder's options removed, so if the 
> whole thing is encoded in CXER, the encoder is a conforming 
> implementation of the spec.  *** That is an important point for you to 
> note in terms of the number of implementations using the spec. ***
>
> The problem actually comes back (surprise, surprise!) to the Base64 
> issue.  If we can eliminate that confusion, all is done.  At the end 
> of the day, Base64 (over Hex) reduces the bandwidth of the message by 
> only a few percent in most cases.  BASE64 encoding of octet strings, 
> open tupes, and character strings is a nice idea (both for bandwidth 
> reduction and, in the case of character strings, to allow characters 
> forbidden in XML - there the term "armoured" is appropriate), and 
> indeed we *are* standardising it, ***but it would be silly for XCBF to 
> be held up or founder just for that***.
>
> As you have said before, there can always be a second version. 
> (Assuming we manage to get enough support to get the first version 
> through!)
>
> Phil, I want this to go forward.  But the actual "bits-on-the-line" 
> must be very clear, and cannot use Base64 (because of Ed's position) 
> unless we delay.
>
> I say again, if we can get a clear spec that uses (current) standard 
> ASN.1 encoding rules, you will get a whole-hearted YES without comment 
> from me.
>
> John L
>
> Bancroft Scott wrote:
>
>> Phil,
>>
>> The crux of the problem that we are having lies around the fact that 
>> XCBF
>> is using Base64 as an encoding, but Base64 is not available in the 
>> current
>> version of X.693.  Given this, plus the fact that that only the
>> EnvelopedData and SignedData types carry certificates and CRLs, and that
>> even in these cases, the certificates and CRLs components are optional
>> (and in practice never used), it would solve all our problems if XCBF 
>> used
>> straight XER and/or CXER encoding.
>>
>> In other words, I propose that we drop the use of (currently 
>> non-standard
>> in XER/CXER) Base64 in XCBF and instead stick to HEX encoding as 
>> required
>> by XER/CXER.  This would resolve the concerns that everyone, 
>> including Ed
>> Day, has voiced.
>>
>> Bancroft
>>
>>
>>
>
>