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] Why do you say "ridiculous"?


No offense intended, sir. I understand that you are trying
to make a constructive contribution.

But I stand by my criticism of your remarks. The textual
description of the content of the certificate and crls types
in XCBF does not depend on where they are referenced.

It would have been preferable to reuse the EnvelopedData
text as you suggested, so that readers would see the text
in two places instead of one.

When we start shortly on a version two of XCBF, I intend
to base our work on the very latest proposed CS. This one
was approved by 71% of the TC and includes this minor
correction and others that you suggested.

I do appreciate and highly value your efforts.


Alessandro Triglia wrote:
Your views about the precision required in a standard are quite interesting. 
What do my past comments have to do with the present content of the document?
Please stop using the OASIS XCBF mailing list as a theater for public attacks against members of the TC that you chair.
-----Original Message-----
From: Phillip H. Griffin [mailto:phil.griffin@asn-1.com]
Sent: Saturday, April 12, 2003 22:55
To: Alessandro Triglia
Cc: 'Bancroft Scott'; xcbf@lists.oasis-open.org
Subject: Re: [xcbf] Groups - XCBF XML Common Biometric Format CS April 3 2003.zip uploaded (fwd)

Alessandro Triglia wrote:
-----Original Message-----
From: Bancroft Scott [mailto:baos@oss.com] 
Sent: Saturday, April 12, 2003 17:57
To: xcbf@lists.oasis-open.org
Subject: Re: [xcbf] Groups - XCBF XML Common Biometric Format 
CS April 3 2003.zip uploaded (fwd)


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, 

Also notice that the text mentions BASE-64 only in relation to
EnvelopedData (OriginatorInfo) and NOT in relation to SignedData,
although both EnvelopedData and SignedData may carry certificates.

Therefore the use of BASE-64, as specified by the current normative
text, only applies to the certificates included in EnvelopedData and not
to those included in SignedData, which are probably more common.  The
latter are encoded in hex.
You're really straining at a gnat Alessandro.

In both places in the CS, in SignedData and EnvelopedData,
the exact same certificate and crl ASN.1 types are used. The
Base64 processing requirement applies to the type, not the

The detailed description appears only in one place, not both.
You first suggested that an editorial change be made to reuse
the EnvelopedData description. And I added clairifying text
to the SignedData clauses. But then you voted against amending
the CS.

Now you complain that the edit has not been made? Ridiculous.



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.




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