RE: [xcbf] Interpretation of the CS under ballot

["Alessandro Triglia" <sandro@oss.com>]

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:phil.griffin@asn-1.com] 
> 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
> >
> >
> >
> >  
> >
> 
>