Subject: The BER vs DER proposal

From: "Liqiang(Larry) Zhu" <[email-masked]>
Date: Wed, 20 Oct 2004 01:06:38 -0700

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: Love <[email-masked]>
Date: Wed, 20 Oct 2004 10:47:52 +0200

> get into the next version

I can live with this.

I read this as that the "Many early and current implementations" are wrong
and should be corrected, so if you want to talk to them, only generate DER
for CMS.

Love

---

From: Ken Raeburn <[email-masked]>
Date: Wed, 20 Oct 2004 05:18:05 -0400

On Oct 20, 2004, at 04:06, Liqiang(Larry) Zhu wrote:
>   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
>   encoded objects.

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

Ken

---

From: Sam Hartman <[email-masked]>
Date: Wed, 20 Oct 2004 10:11:39 -0400

This proposal seems fine to me.

--Sam

---

From: Nicolas Williams <[email-masked]>
Date: Wed, 20 Oct 2004 12:10:34 -0500

> get into the next version

I can live with this, though it's not ideal.

> Specific text (this can be in a separate section, just need to make it

s/Many/Some/

>                 Tags encoded with indefinite length can be quite 
>   difficult to decode correctly.

Not if one designs for it from day one.  What's hard is modifying an
existing DER decoder to support BER indefinite length encodings.

Nit: it's not the tags that are hard to decode either :)

>   short of demanding its decoders being able to decode all valid BER 

Nonsense; rfc3369 quite clearly and repeatedly refers to BER for
encoding and even indefinite length encoding -- there is no need to
state that decoders must support BER decoding given that it's quite
clearly implicit.

I suspect this sentence was added to sugarcoat the SHOULD-send-DER that
follows.  I don't think such sugarcoating is necessary, particularly if
it would be controversial, as this bit of sugarcoating most certainly
is.

>                     To maximize interoperability and security, it is 

"and security?"

s/ and security//

>   libraries that can guarantee the encoding is DER.

s/strongly recommended/RECOMMENDED/

(That is, I object to the word "strongly" in that sentence.)

Will the IESG object to it?  If not I'm game.

Nico
--

---

From: Jeffrey Altman <[email-masked]>
Date: Thu, 21 Oct 2004 17:20:22 -0400

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

---

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

> interoperability implementers SHOULD encode CMS objects used in PKINIT

I support this proposal.

Nico
--

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Thu, 21 Oct 2004 18:04:22 -0400

For those who've forgotten, this is ticket #523.

> interoperability implementers SHOULD encode CMS objects used in PKINIT

OK, folks; Jeff has made a concrete proposal for a change to the document 
to address this issue.  Please comment and indicate whether you support or 
oppose this proposal.

Given that the I-D submission deadline is Monday morning, I don't think 
we'll be able to consider this resolved in time to meet the deadline. 
However, I'd like to see a resolution on this issue before the meeting next 
month.

-- Jeff

---

From: Ken Raeburn <[email-masked]>
Date: Thu, 21 Oct 2004 18:07:31 -0400

On Oct 21, 2004, at 18:04, Jeffrey Hutzelman wrote:
> OK, folks; Jeff has made a concrete proposal for a change to the 
> document to address this issue.  Please comment and indicate whether 
> you support or oppose this proposal.

Grumpily support. :-)

Ken

---

From: Tom Yu <[email-masked]>
Date: Thu, 21 Oct 2004 18:08:51 -0400

>>>>> "jaltman" == Jeffrey Altman <[email-masked]> writes:

jaltman> Replace in section 3.1.2:

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

jaltman> with

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

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

I support this proposal.  If there is someone with the time and
resources to do so, we should also check for the existence of CMS
implementations which use non-minimal length encodings and extend the
interoperability note to include that.  I seem to recall that at least
some SNMP implementations used non-minimal length encodings.

I also think that the wording could be improved a little, e.g.,

    "Some implementations may only be able to decode DER-encoded CMS
    objects, while being unable to decode more generalized BER
    encodings of these objects.  Specifically, such implementations
    may be unable to decode indefinite length encodings [or
    non-minimal length encodings]."

---Tom

---

From: Sam Hartman <[email-masked]>
Date: Thu, 21 Oct 2004 18:16:57 -0400

I support Jeff's proposal.

---

From: Martin Rex <[email-masked]>
Date: Fri, 22 Oct 2004 16:17:10 +0200 (MET DST)

> interoperability implementers SHOULD encode CMS objects used in PKINIT

I like that!

-Martin

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Fri, 29 Oct 2004 14:59:03 -0400

On Thursday, October 21, 2004 18:04:22 -0400 Jeffrey Hutzelman 
<[email-masked]> wrote:

> to address this issue.  Please comment and indicate whether you support
> or oppose this proposal.

After reading the responses to this thread over the last week, I think I am 
ready to declare a consensus.  It's been a long and difficult road, but 
we've finally reached our destination.

Thanks to everyone who participated in this difficult process.

> we'll be able to consider this resolved in time to meet the deadline.

As it turns out, Brian anticipated this result and included Jeff's proposed 
text in pkinit-21.  So, the current version of the document already 
reflects this result.

-- Jeffrey T. Hutzelman (N3NHS) <[email-masked]>
   Co-chair, IETF Kerberos Working Group
   Carnegie Mellon University - Pittsburgh, PA