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] Interpretation of the CS under ballot


If you read the comment resolutions document that I posted to this list
prior to the current ballot, you will see that the comment you refer to
below was rejected. Instead, the more simple approach offered by
member Ed Day was adopted.

As Ed pointed out, in using his approach there will be no backwards
compatibility problems with existing implementations if we should adopt
your "encoding control" idea in the future - assuming the solution you
now propose actually becomes a part of the ASN.1 standards.

Your approach would cause problems later with existing applications
of XCBF. By adopting Ed's solution, users can deploy today with
confidence that future XCBF work will not cause problems for their


Alessandro Triglia wrote:

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

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.  


-----Original Message-----
From: Phillip H. Griffin [mailto:phil.griffin@asn-1.com] 
Sent: Thursday, April 10, 2003 00:02
To: Alessandro Triglia
Subject: Re: [xcbf] Interpretation of the CS under ballot


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.


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.





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