Re: [xcbf] Interpretation of the CS under ballot

["Phillip H. Griffin" <phil.griffin@asn-1.com>]

Title:

Bancroft,

I agree that a doubling of the encoding (hex->Base64->hex)
or simply transferring hex would be a poor solution. That is why
we simply transfer Base64. 

The text I placed in the document, "This component shall contain 
a Base64 armored value", is needed because there is no Base64
type in ASN.1 and the type is defined in the schema as an OCTET
STRING. 

Phil


Bancroft Scott wrote:
> On Thu, 10 Apr 2003, Phillip H. Griffin wrote:
>
> > > 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.
> >   
> Base64 is preferred to HEX because it yields a smaller encoding, but if we
> further encode the Base64 encoded value in HEX we end up with a larger
> encoding and with an application that is unnecessarily larger and more
> complex than if HEX alone or Base64 alone were used.  Since XER and CXER
> do not currently support Base64, the solution that yields the smallest
> encoding and simplest application is HEX.
>
> This double encoding in Base64 and HEX is a poor solution.  I see no
> benefit to it.
>
> Bancroft