After quoting a passage from ITU document X.690, whose title is:
ASN.1 encoding rules:
Specification of Basic Encoding Rules (BER),
Canonical Encoding Rules (CER) and
Distinguished Encoding Rules (DER)
on 2009-02-26 01:40 PST, Kyle Hamilton wrote,
> I have not received a specific answer as to my query:
> is "-----BEGIN X509 CRL-----" a valid DER sequence?
Kyle, the answer to that question is in the document from which you
quoted. See the section entitled "Basic Encoding Rules". All other
forms of encoding are derivatives of BER, so understanding BER is
the foundation. I encourage you to read it.
The short answer is: No. No data made up entirely of printable ASCII
strings is a valid DER or BER encoding.
PEM's only real value is that it allows data to be copied and pasted
into and out of text documents. The base64 content is no more
enlightening, and IMO is significantly less informative, than the
binary DER. PEM encoding adds a MINIMUM 33% overhead in amount of data
that must be sent. That's a 33% tax on all the bandwidth providers and
memory chips, just to allow copying into text documents. It also requires
an additional pass over all the data to translated it to/from PEM form,
because the binary form is always the one that is valuable to the software.
Use of PEM may be appropriate in text documents, but CRLs being fetched over
the wire are fundamentally NOT text documents.
To make all users pay a 33% bandwidth tax, so that the occasional and rare
person who wants to actually look at the contents can avoid binary, is
silly. Further, you can find out what kind of document it is from the
MIME content type of the http response, so the PEM header is redundant.
The main point here is that, on the Internet, interoperability is all
achieved based on compliance to Standards. A standard that says
"There's one way to do this" is generally preferred in the IETF
(but not in the ITU, obviously) to a standard that says "there are
many ways to do this and you must implement them all to be interoperable."
Many of the places where software products already permit a variety of
data formats to be used exist simply because, at the time that the
specification for that software was written, it failed to adequately
specify data formats, usually because it never occurred to the authors
that more than one format was likely to ever be used. It seemed "obvious"
which was the right format, so no comment about format was provided.
That is the reason for utterly absurd implementations like the one
described in
https://developer.mozilla.org/en/NSS_Certificate_Download_Specification
which accepts certificates in no less than 8 different formats of data.
I applaud the IETF for specifying the formats for CRLs in sufficient
detail that products need not carry multiple implementations in order to
find one that works. I lament products that promote the use of non-standard
formats, and that some so-called "authorities" are unaware of the
standards' requirements.
--
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto
