xcbf message

Subject: Re: [xcbf] Interpretation of the CS under ballot

From: "Phillip H. Griffin" <phil.griffin@asn-1.com>
To: Bancroft Scott <baos@oss.com>
Date: Thu, 10 Apr 2003 06:28:32 -0400

Title:

I am sure that there are several places in the document that
can be improved. I hope that we will continue to improve the
text and examples as we move past the current CS into new
work.

Phil

Bancroft Scott wrote:

On Thu, 10 Apr 2003, Phillip H. Griffin wrote:

Alessandro,

By these remarks, you seem very confused. Please see below.

I too am confused.  I'm re-reading what you wrote below, and rereading the
XCBF document and I am not sure what is meant.

One interpretation of what you wrote can be seen in the response I just
sent - that the value is first encoded in Base64 then in HEX.  I assumed
that this is what you meant since throughout the document it says that the
encoding rules in use is XER, which implies that Base64 cannot be visible
without first decoding the value.

Another interpretation of what you wrote is that the value is encoded in
Base64 in lieu of HEX.  That is, the Base64 encoding is not wrapped in
HEX.  Is this the case?  If so, it contradicts what is said throughout the
XCBF document - that the values are encoded according to XER, for the
version of XER that the document claims to conform to does not support
Base64 encodings.

The document is in need of clarification on this point.

Bancroft

Alessandro Triglia wrote:

Phil, All,

Please confirm my interpretation of the XCBF CS document in the
following two areas:

1) Use of BASE64
2) Use of CXER vs. BASIC-XER


As for (1), my interpretation is that  ***BASE-64 must NOT be used in
actual encodings and message exchanges***,  despite the sentence (line
1542) that mentions use of BASE-64 for certificates to  "minimize their
size when represented using XML markup"

The document states clearly at line 1018 that for both the "crls" and
"certificates" components of  type "SignedData",

"This component shall contain a Base64 armored value. "

This is the opposite of your interpretation.

As for (2), my interpretation is that  ***CXER, and only CXER, must be
used for encoding the WHOLE messages***,  despite the numerous sentences
such as  "This value is always encoded using the XML Encoding Rules"
and the numerous exampes of BASIC-XER encoding.

Clearly, since CXER is a subset of XER, CXER may be used to
encode entire messages. But this is not required. As you say above,
there are numerous sentences in the document such as

"This value is always encoded using the XML Encoding Rules"

and it is these sentences that specify all of the CXER requirements.

If you carefully examine all cases, you will see that a canonical
encoding of XER is only required for cryptographic processing
of protected message components, and not for the message
wrapper.

This requirement is identical for the same message schemas when
they are encoded in BER and DER in X9.84. This should come as
no surprise, as it is common practice in many cryptographic protocols.

The idea is to give implementers flexibility in what they send in all
places in the message where doing so does not affect inter working
of implementations. Where additional rigor is required, a canonical
encoding is specified.

As an example that may be familiar to many people involved in
security, consider X.509 certificates. The signed content must be
encoded in the canonical DER encoding rules. But the wrapper
that encapsulates the signed content may be encoded using the
Basic Encoding Rules of ASN.1. XCBF signed objects are
treated the same.

Phil

I think that, if my interpretations above are the same as other
people's, the current imprecisions in the document should not prevent
its progress.  However, I strongly wish that assurance.

Alessandro

References:
- Re: [xcbf] Interpretation of the CS under ballot
  - From: Bancroft Scott <baos@oss.com>