[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [xcbf] Interpretation of the CS under ballot
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 NOTbe used inactual encodings and message exchanges***, despite thesentence (line1542) that mentions use of BASE-64 for certificates to"minimize theirsize 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 onlyCXER, must beused for encoding the WHOLE messages***, despite the numerous sentences such as "This value is always encoded using theXML EncodingRules" 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. PhilI think that, if my interpretations above are the same as other people's, the current imprecisions in the document shouldnot preventits progress. However, I strongly wish that assurance. Alessandro
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]