Phil,
Please see Phil Griffin's comments to the previous ballot:
-------------------------
The OCTET STRING type can be used to transfer these objects and to
verify that the data is "ASN.1-valid" with respect to the XCBF ASN.1
Schema. This data, then represented as hexadecimal characters, can be
subsequently transformed by a receiving application into Base64
characters.
-------------------------
Anyway, thanks for the clarification. At least we are all aware that
much work is still needed on this document before it has a reasonable
level of quality.
Alessandro
> -----Original Message-----
> From: Phillip H. Griffin [mailto:]
> Sent: Thursday, April 10, 2003 00:02
> To: Alessandro Triglia
> Cc: [OASIS XCBF]
> Subject: Re: [xcbf] Interpretation of the CS under ballot
>
>
> Alessandro,
>
> By these remarks, you seem very confused. Please
> see below.
>
> 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
> >
> >
> >
> >
> >
>
>
