Subject: RE: The BER vs DER proposal

From: "Liqiang(Larry) Zhu" <[email-masked]>
Date: Wed, 20 Oct 2004 02:25:08 -0700

Ken Raeburn wrote:
> >   Furthermore, even RFC 3369 fell
> >   short of demanding its decoders being able to decode all valid BER
> >   encoded objects.

> I'm not sure what this means, or why it matters.

I wanted to say you will have no interoperability guarantee when you
specify full BER, in reality 
any real decoder can only decode a subset of BER and the subset that
matters (but it may claim full BER for the purpose of propaganda). I
suspect that was the reason why I could find a MUST BER in RFC 3369. any
thoughts?

-- Larry

-----Original Message-----
From: Ken Raeburn [mailto:[email-masked]] 
Sent: Wednesday, October 20, 2004 2:18 AM
To: Liqiang(Larry) Zhu
Cc: Eric Rosenfeld; <[email-masked]>; IETF Kerberos Working Group
Subject: Re: The BER vs DER proposal

On Oct 20, 2004, at 04:06, Liqiang(Larry) Zhu wrote:
>   Many early and current implementations can only decode DER encoded
>   CMS objects.

Are these "early and current implementations" of the current spec?  Or
of the old drafts with which the final PKINIT spec is expected not to be
compatible anyways?

>   Furthermore, even RFC 3369 fell
>   short of demanding its decoders being able to decode all valid BER
>   encoded objects.

I'm not sure what this means, or why it matters.

Ken

---

From: Ken Raeburn <[email-masked]>
Date: Thu, 21 Oct 2004 16:11:26 -0400

"Liqiang\(Larry\) Zhu" <[email-masked]> writes:
> matters (but it may claim full BER for the purpose of propaganda).

Seems to me your chances of interoperability are just the same as for
CMS interoperability.  In other words, if you can't get CMS right, you
probably won't get PKINIT's use of CMS right.  That seems obvious
enough to me to go without comment.  And, in fact, I don't think we
want to encourage people to solve the "what subset" problem
differently for PKINIT than for CMS, and I think the best way to avoid
that is just to imply that they should be doing PKINIT's CMS stuff
however they do CMS otherwise, which would be at odds with a SHOULD
DER specification.

On the other hand, writing down some observations somewhere about what
subset of BER actually tends to be implemented and used for CMS might
be worthwhile, and perhaps useful to but with no basis in PKINIT.

>  I

RFC 3369 says, "The CMS values are generated using ASN.1 [X.208-88],
using BER-encoding [X.209-88]."  I don't think a "MUST" is required,
if you view it as a specification of how to perform a calculation
instead of a procedure with acceptable variations.  Kind of like how
RFC 2040 (RC5) says "this is how it's done" instead of "MUST this,
MUST that".

Ken

---

From: Martin Rex <[email-masked]>
Date: Thu, 21 Oct 2004 23:04:51 +0200 (MET DST)

> RFC 2040 (RC5) says "this is how it's done" instead of "MUST this,

I would say that RFC 3369 is sufficiently ambiguous to allow anything
with that above sentence.  To me it says that encoding and decoding
to the BER encoding rules is OK, it doesn't need to be the 
canonical/shortest encoding of DER.

Since DER is always a correct subset of BER, any CMS library that produces
DER always has produced a valid BER encoding.

The interesting part is really about the decoder.  What the spec doesn't
say is whether the decoder MUST be capable to deal with the worst of
BER imaginable.

Anything that involves ASN.1 is sufficiently ambiguous to allow
anything so that noone can come up with a fully compliant implementation.

There are no size limits on objects encoded with ASN.1, but
in reality, most implementations will impose size limits on objects.
Even with DER one can create extremely large objects which probably
no COTS software will be able to deal with.

AFAIK there is no restriction on the size of the subject distinguished
name in a certificate, and it is possible to encode a 5 Gigabyte Movie
with a custom OID tag into the distinguished name of an X.509 cert
-- still conforming to the relevant X-Series of standards.
However I don't expect any software to be able to deal with such
a certificate (neither SSL/TLS in transfering such a cert in
the forward certificat path), nor the ASN.1-decoder of most
PKI-Software on 32-bit CPUs, nor the PKI-application software on top
of it.

So whenever someone refers only to ASN.1 specs without clearly outlining
restrictions/expectations, the result is sufficiently ambiguous in many
respects, and if you're pedantic, then there is NONE, ZERO, NIL
ASN.1-implementation out there that is *FULLY* compliant, or you're
liberal, and then there are several common-sense implementations
out there with conservative assumptions and some implementations
with bold assumptions that cause every body else's headaches when
attempting interoperability.

-Martin

---

From: Nicolas Williams <[email-masked]>
Date: Thu, 21 Oct 2004 16:15:48 -0500

> say is whether the decoder MUST be capable to deal with the worst of

The spec quite clearly requires BER.  It quite clearly speaks of the
benefits of indefinite length encodings and specifically requires DER
only for a subset of CMS.

Specifying BER for encoding implicitly, and _obviously_ means that BER
decoders are required.

> anything so that noone can come up with a fully compliant implementation.

I don't agree nor do I care to debate this point as that would lead to
an off-topic discussion -- I point out my disagreement only for the
record.

Nico
--