Subject: RE: The BER vs DER proposal

From: "Liqiang(Larry) Zhu" <[email-masked]>
Date: Thu, 21 Oct 2004 20:13:37 -0700

If "MUST - epsilon" were a word, I would have asked to use it to replace the word SHOULD here. 

From day 1, Eric was asking for something stronger than a SHOULD, I do not know what is the concession folks made here with this text. This was why I chose (as I told Jeff off-list) to use informal language and that was the key piece of my proposal.

-- larry

________________________________

From: [email-masked] on behalf of Jeffrey Altman
Sent: Thu 10/21/2004 2:20 PM
To: [email-masked]
Subject: Re: The BER vs DER proposal

I was hoping to get feedback from Eric before I posted this response
but for whatever reason I have not received any.  The following is
formal proposed text which follows the direction set by Eric and
Larry.  I believe that this text will meet with agreement of most
parties on this list.  If the Packet Cable representative concur
I think that we will have our rough consensus.

Replace in section 3.1.2:

"All structures MUST be encoded using Distinguished Encoding Rules (DER).".

with

"All data structures defined in this document MUST be encoded using
Distinguished Encoding Rules (DER).  All imported data structures must
be encoded according to the rules specified in Kerberos [1] and CMS [2]
as appropriate.

"Interoperability note:  Some implementations may not be able to
decode CMS objects encoded with BER but not DER, specifically they may
not be able to decode indefinite length encodings.  To maximize
interoperability implementers SHOULD encode CMS objects used in PKINIT
using DER."

Jeffrey Altman

Liqiang(Larry) Zhu wrote:

> Eric and I finally came to an agreement. Hopefully this proposal will
> get into the next version
> ========================================================================
> ===============
>
> Summary of the proposal
> ----------------------
> We shall leave the encoding of CMS objects to the CMS spec, but we
> should also add a section on interoperability that recommends DER.
>
>
>
> Specific text (this can be in a separate section, just need to make it
> easy to spot)
> ------------------------------------------------------------------------
> ------------
>    Interoperability note on the encoding of CMS objects:
>
>
>   Many early and current implementations can only decode DER encoded
>   CMS objects.  Tags encoded with indefinite length can be quite
>   difficult to decode correctly.  Furthermore, even RFC 3369 fell
>   short of demanding its decoders being able to decode all valid BER
>   encoded objects.  To maximize interoperability and security, it is
>   strongly recommended that implementers of this specification should
>   encode all CMS objects in DER or select only those off-the-shelf CMS
>   libraries that can guarantee the encoding is DER.
>
> =========================================================
>
> Would this working group accept this proposal and move on.
>
> -- Larry
>

---

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

> From day 1, Eric was asking for something stronger than a SHOULD, I do not know what is the concession folks made here with this text. This was why I chose (as I told Jeff off-list) to use informal…

I think we should hear from Eric.

Informal language won't fly.

Nico
--

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Fri, 22 Oct 2004 12:41:53 -0400

> If "MUST - epsilon" were a word, I would have asked to use it to replace

Evaluated in the context of RFC2119, SHOULD is actually pretty strong:

  3. SHOULD   This word, or the adjective "RECOMMENDED", mean that there
     may exist valid reasons in particular circumstances to ignore a
     particular item, but the full implications must be understood and
     carefully weighed before choosing a different course.

---

From: Nicolas Williams <[email-masked]>
Date: Fri, 22 Oct 2004 11:52:40 -0500

>     carefully weighed before choosing a different course.

Yup.  Which makes this a decent compromise.

The SHOULD should give CMS implementors, indirectly, through PKINIT
implementors, an incentive to make the output encoding configurable.
The MUST will provide incentive to support BER decoding.

Nico
--

---

From: Martin Rex <[email-masked]>
Date: Fri, 22 Oct 2004 23:58:38 +0200 (MET DST)

> The MUST will provide incentive to support BER decoding.

I do agree that the SHOULD encode DER is a useful incentive
for CMS implementors.

BER decoding with a RFC-2119 captial MUST would not be an "incentive",
it would rather be an extremely painful burden.

DER is also a burden, but not quite as bad as full BER.

Of course you can put the screws of the backplane of your Swatch wristwatch
back into place with a Sledgehammer after replacing the battery, but it
requires significant skill not to break things that way.  Full BER is
a pretty big Sledgehammer (only to be topped by worst-of-XML).

Requiring people to spent their time learning to use a Sledehammer for
this task without breaking the wrist watch is a bad idea.

Allowing people to use (or better allowing them to require) a
better suited tool to perform this task, like a tiny screwdriver,
is by far the preferable approach.

We don't have to require paved roads that can bear 40 ton trucks to each
and every chalet no matter how far out, just because 40 ton trucks
are common vehicles on many roads.  

-Martin

---

From: Jeffrey Altman <[email-masked]>
Date: Fri, 22 Oct 2004 18:10:16 -0400

> it would rather be an extremely painful burden.

Folks, lets stay on topic.  The current proposal is not "MUST BER" but
"MUST RFC 3852".  Everyone who has spoken up so far on the currently
proposed text (including both of you who are talking at each other)
have voiced their support of the text.  Can we please enjoy this brief
moment of universal agreement while we await Eric or someone else from
Packet Cable to speak either for or against the proposal.

Thanks. (as I drink another shot of tequila.)

- Jeff