Subject: CONSENSUS CALL - BER vs DER

From: Jeffrey Hutzelman <[email-masked]>
Date: Thu, 07 Oct 2004 17:45:52 -0400

On Wednesday, September 29, 2004 13:59:37 -0500 Nicolas Williams 
<[email-masked]> wrote:

> Short version:
>
>  - We reached tentative consensus, with some participants neither
>    supporting nor objecting, and some supporting with reservations, that
>    PKINIT should REQUIRE the use of DER encoding for CMS objects and
>    that PKINIT should RECOMMEND the support for BER decoding of CMS
>    objects.
>
>    We now seek consensus on the mailing list.

I would like to be able to make a determination on Monday as to whether we 
have concensus in the working group to go ahead with the results arrived at 
during the conference calls.  To do that, I need to hear from the 
membership of the working group, as soon as possible.

If you support this approach, say so.
If you don't care for this approach but will live with it, say so.
If you object to this approach, say so.

I don't want to hear more rehashing of the same arguments we've been having 
for months.  However, if, after reading Nico's summaries of both calls, you 
have an issue that you believe was not considered, say so.

Ultimately, this is a case where we have two more or less equally valid 
choices, and to make progress we must pick one.  We can keep arguing 
forever, but that will not change these facts -- it will only delay PKINIT.

-- Jeff

---

From: Jeffrey Altman <[email-masked]>
Date: Thu, 07 Oct 2004 23:52:11 -0400

I object to the proposal of "MUST DER for encoding and SHOULD BER for 
decoding of CMS objects.

I am not aware of any commercial or open source implementations of CMS 
which encode in DER.  OpenSSL certainly does not and it is the most
popular open source CMS implementation.  Most importantly the only 
reason for providing a SHOULD decode that is different from the MUST 
encode is because you expect a significant number of implementations
to violate the MUST.  To be completely honest, if we are going to expect
that there be implementations that violate a MUST it should not be the
public implementations which need to be able to interoperate using
standard off the shelf RFC compliant tools.  As the CMS specification
requires BER, the CMS objects used by Kerberos MUST require BER as well
for both encoding and decoding.

The funny part is that even if the document is written to say "MUST 
encode BER and SHOULD encode BER", the Packet Cable implementations
are still compliant.  They just won't interoperate with non-Packet
Cable implementations.

Jeffrey Altman

---

From: Love <[email-masked]>
Date: Fri, 08 Oct 2004 10:34:44 +0200

Jeffrey Hutzelman <[email-masked]> writes:

> I would like to be able to make a determination on Monday as to
> whether we have concensus in the working group to go ahead with the
> results arrived at during the conference calls.  To do that, I need to
> hear from the membership of the working group, as soon as possible.
>
>

I object to "MUST encode DER, SHOULD decode BER", the answer is "MUST
encode and decode according to CMS".

Love

---

From: Nicolas Williams <[email-masked]>
Date: Fri, 8 Oct 2004 11:57:49 -0500

On Thu, Oct 07, 2004 at 11:52:11PM -0400, Jeffrey Altman wrote:
> to violate the MUST.

This was most definitely NOT the reason we gave for the SHOULD.

It was not discussed at the second conference call, where we discussed
the SHOULD matter.

The participants all agreed that only an interoperable solution would be
agreeable -- at the first conf call, and we reported as much.  There was
zero expectation amongst us at either conf call that any implementor
would violate that MUST -- indeed, we agreed on the contrary.

>                       To be completely honest, if we are going to expect

I agree on the principle that the encoding of CMS objects is up to the
CMS implementation.

Would that it were so easy to achieve consensus on this matter.

> are still compliant.  They just won't interoperate with non-Packet

We decided at the first conference call that a non-interoperable
solution to this would satisfy noone there and most likely be rejected
by the IESG.  If we called for consensus on that I'm pretty sure we'll
all agree.

That left us with two mutually exclusive approaches to consider, only
one of which should, IMO, be agreeable on principle.  We selected the
other one.

Perhaps you reject the method by which we selected one alternative at
the second conf call.  It seems to me that how we select a solution and
which solution we select are likely to be similarly controversial.

If there are insurmountable objections to the proposal that came out of
the second conf call then we're back to being deadlocked.

Cheers,

Nico
--

---

From: Jeffrey Altman <[email-masked]>
Date: Fri, 08 Oct 2004 14:38:07 -0400

> would violate that MUST -- indeed, we agreed on the contrary.

If all implementations are expected to adhere to the "MUST encode DER",
what additional interoperability is gained by stating "SHOULD decode 
BER" in the RFC?

As I see it there is none.  All that specifying "SHOULD decode BER" does
is weaken the "MUST encode DER" because it indicates that a non-broken
implementation should be able to process BER in any case.  If you are
going to say "MUST encode DER" then you must be willing to accept it
unconditionally.  I am not.

> the second conf call then we're back to being deadlocked.

Quoting your text from the summary of the call:

"A related, but far less contentious matter that also needed to be
resolved was whether PKINIT should RECOMMEND support for BER for CMS
objects.  On this matter we agreed that PKINIT should do so, and for a
number of reasons, including that buggy DER encoders can emit
BER-but-not-DER encodings that BER decoders can decode but DER decoders
may not, and also to allow for evolution towards requiring BER instead
of DER in some far, far off future.  Implementors that find it too
difficult to modify their decoders to support BER will probably consider
that sufficient reason not to follow this recommendation."

This paragraph argues strongly that the consensus is really

	MUST encode BER; MAY decode DER

Encouraging the use of BER decoding for the purpose of being nice to
broken DER encoders simply says that working group encourages the
development of broken DER encoders.  Unless you perform interop testing
against a DER only decoder it is unlikely that you will ever have a DER
only encoder.  Thus you will not have gained the level of
interoperability which has been stated as a requirement for the
acceptability of the solution.

If the consensus of the working group is that the standard should be
BER encoding sometime in the future there is no reason it should not be
the standard today.  All putting off the decision point does is cause
there to be a larger number of deployed instances of the code which must
be replaced.

 > I agree on the principle that the encoding of CMS objects is up to the

I think there are many here that believe that this is the only possible
answer.

 > Would that it were so easy to achieve consensus on this matter.

At least in my mind we are still deadlocked because I do not believe
that the selected compromise meets the requirements of the working
group.  It does not enhance the level of interoperability in any
significant way and in fact can result in a failure to discover
potentially serious bugs.

Before we torture ourselves any further I have a question that I would
like Packet Cable Labs to answer:

Leaving aside the questions regarding pkinit, how much interop
testing has been performed between a Packet Cable Labs compliant
Kerberos implementation and any of the big three implementations:
Microsoft, Heimdal, or MIT?

I would like to be satisfied that the two worlds actually interoperate.
If they don't, given the existing deployments of Kerberos
implementations by those following the Packet Cable Labs specifications,
it would seem to be next to impossible to make them work together anyway.

Jeffrey Altman

---

From: Nicolas Williams <[email-masked]>
Date: Fri, 8 Oct 2004 14:05:07 -0500

> unconditionally.  I am not.

[For the record I prefer MUST-send-BER, for the same reasons as you do,
but do not oppose the proposal from the second conf call.  It is not
remotely my goal here to change your mind, but to address the SHOULD
matter.]

I don't think the SHOULD issue mattered that much to the conf call
participants; it was more of an after thought, and perhaps that decision
is not easily defended.

No matter.  The deadlock was not about RECOMMENDations, but about
REQUIREments; the MUST matter received the most attention and was
settled first.

The MUST-send-DER decision was based on analysis of which of
MUST-send-BER or DER would be hardest to implement for the opposing
camp.  A rather subjective decision based on reports by implementors
that we expect are accurate.

Perhaps this is not a good way to settle the matter; I have my doubts.

Perhaps the WG cannot reach consensus without any further breakthroughs.

Perhaps the IAB could provide such a breakthrough.  This did come up as
an option at one of the conf calls, but we concluded that asking the IAB
for advice would delay PKINIT quite a lot and consequently decided
against it.  (Please correct me if my recollection is wrong.)

Perhaps the chair can enlighten us on methods for resolving deadlocks in
IETF WGs.

Nico
--

---

From: Doug Mitchell <[email-masked]>
Date: Fri, 8 Oct 2004 12:15:07 -0700

I object to the proposed "MUST encode in DER" for the same reasons 
enumerated by Jeffrey Altman. In particular, Apple's CMS implementation 
- which is fully conforming to RFC 3369 (and 3852 AFAIK) - is incapable 
of encoding with DER. It would be a nontrivial amount of work to make 
it do so.

--dpm

On Oct 7, 2004, at 2:45 PM, Jeffrey Hutzelman wrote:

> I don't want to hear more rehashing of the same arguments we've been 
> having for months.  However, if, after reading Nico's summaries of 
> both calls, you have an issue that you believe was not considered, say 
> so.
>
> Ultimately, this is a case where we have two more or less equally 
> valid choices, and to make progress we must pick one.  We can keep 
> arguing forever, but that will not change these facts -- it will only 
> delay PKINIT.
>
> -- Jeff
>
>

---

From: Jeffrey Altman <[email-masked]>
Date: Fri, 08 Oct 2004 15:24:18 -0400

> Perhaps this is not a good way to settle the matter; I have my doubts.

Two weeks ago we had three proposals.  One was ruled out because it did 
not meet the criteria of providing interoperability between 
implementations.  This left us with:

	MUST encode DER
	MUST decode BER

My position is simply that MUST encode DER does not result in 
interoperability given the reality of the existing implementations of
CMS libraries used by vendors that plan to deploy RFC compliant PKINIT 
with Clarifications and Kcrypto compliant Kerberos implementations.
Therefore, that leaves us with a single choice which is MUST decode BER 
otherwise known as "leave it up to the CMS specification".

I don't think there is anything else for me to say.  It is unlikely
that at this point my position will be altered on this matter.  I am
very happy that I am not chairing this working group at the moment.
I'm not sure I would want to be the responsible Area Director either.

Jeffrey Altman

---

From: Ken Raeburn <[email-masked]>
Date: Fri, 8 Oct 2004 16:24:33 -0400

> encode and decode according to CMS".

What he said.

Ken

---

From: Sam Hartman <[email-masked]>
Date: Fri, 08 Oct 2004 16:34:43 -0400

>>>>> "Ken" == Ken Raeburn <[email-masked]> writes:

    Ken> On Oct 8, 2004, at 04:34, Love wrote:
    >> I object to "MUST encode DER, SHOULD decode BER", the answer is
    >> "MUST encode and decode according to CMS".

    Ken> What he said.

me too.  When I left the conference call I thought MUST encode DER was
a bad idea, but I thought I could live with it.  Based on additional
input, I have come to object to the MUST encode DER proposal.

--Sam

---

From: "Douglas E. Engert" <[email-masked]>
Date: Fri, 08 Oct 2004 15:59:54 -0500

> otherwise known as "leave it up to the CMS specification".

I agree with Jeff. Use CMS as defined.

-- 

  Douglas E. Engert  <[email-masked]>
  Argonne National Laboratory
  9700 South Cass Avenue
  Argonne, Illinois  60439
  (630) 252-5444

---

From: Brian Tung <[email-masked]>
Date: Sun, 10 Oct 2004 09:37:58 -0700

> If you object to this approach, say so.

I'm rather inclined to agree with Jeff Altman, too.

Brian Tung <[email-masked]>

---

From: Nicolas Williams <[email-masked]>
Date: Wed, 13 Oct 2004 15:55:21 -0500

On Wed, Oct 13, 2004 at 10:33:02PM +0200, Martin Rex wrote:
<snip>

Martin, this is not really about which is a better choice, BER or DER.

This is about the boundaries between Kerberos V, PKINIT and CMS (PKINIT
makes use of CMS).

Kerberos V uses DER.  CMS uses BER.

Some PKINIT implementors have assumed DER for CMS.  At the time there
was no OCTET STRING wrapping of the CMS objects in the then-current
PKINIT draft, so PKINIT's PDUs (which fit into OCTET STRING typed holes
in Kerberos) had to use the same encoding as CMS; but ALSO at that time
the then implementors had support for DER only (i.e., they did not
properly implement CMS; if they had tried the boundary issue would have
come up much sooner).

So, now we have implementors with off-the-shelf CMS implementations that
use BER.  And historical implementors with in-house CMS implementations
that implement only DER.

(And we also have this wrinkle that the PKINIT will ultimately be
incompatible with presently-deployed implementations of earlier drafts.)

So, then, the issue is: should PKINIT require DER for CMS to save some
implementors the pain of implementing BER?  Or should PKINIT require,
directly or indirectly, BER for CMS and save other implementors similar
pains.

If at least one implementor on each side refuses to concede the matter
on account of the amount of effort it would take to adjust their
[potentially 3rd-party] CMS implementations then we can't really reach a
consensus in the WG.

Nico
--

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Wed, 13 Oct 2004 17:19:15 -0400

> [potentially 3rd-party] CMS implementations then we can't really reach a

Well, that's not entirely true.  The magic phrase is "rough concensus", 
which means we don't always all have to agree.  However, in this case it's 
looking kind of hard to get even rough concensus. :-(

---

From: Nicolas Williams <[email-masked]>
Date: Wed, 13 Oct 2004 16:32:28 -0500

> looking kind of hard to get even rough concensus. :-(

Thanks for the clarification.

Nico
--

---

From: Martin Rex <[email-masked]>
Date: Wed, 13 Oct 2004 23:36:55 +0200 (MET DST)

> Kerberos V uses DER.  CMS uses BER.

IIRC, Kerberos V does not use DER, it uses almost-DER.

That's what Microsoft realized when implemeting rfc1510 and
what resulted several sections in the clarifications document.

I think what we desperately need is something in between BER and DER,
i.e. something that is as easy to decode as (relaxed) DER, and something
that is as easy to encode as (non-bloated) BER.

100%-correct DER encoding is quite difficult, and there are lots of
implementations out there that proof it, and 100%-correct BER decoding
is difficult because of the potential complexity (particularly of
the indefinite length encoding).

It's similar as with public key pairs.  Upon generation it is possible
to choose parameters (was it the modulus size?--I'm bad at math stuff)
so that on of the operations (sign or verify) is fast and the other
is slow.  But why do we require either or?

A compromise would be to meet in the middle.

-Martin

---

From: Nicolas Williams <[email-masked]>
Date: Wed, 13 Oct 2004 16:46:13 -0500

> IIRC, Kerberos V does not use DER, it uses almost-DER.

Martin, this doesn't help us right now.

This consensus call is not about which encoding is better, or whether
early Kerberos V implementations got some details wrong in such ways
that it actually uses an "almost-DER" rather than DER.

This consensus call is about whether PKINIT should use "almost-CMS" or
CMS.

> that is as easy to encode as (non-bloated) BER.

Again, this is way off-topic and not helpful in this context.

> A compromise would be to meet in the middle.

There is no middle in this particular situation.  There is no compromise
here, unless that compromise is that one camp caves in fully to the
other.

Please read the various posts on this threads and immediately preceding
it to get acquainted with the actual matter at hand.

Cheers,

Nico
--

---

From: Jeffrey Altman <[email-masked]>
Date: Wed, 13 Oct 2004 17:51:15 -0400

> A compromise would be to meet in the middle.

The point that I and several other have been trying to make
during this discussion is that the question of whether to use
DER, BER, or something in between is really not ours to make.
We are specifying the use of Cryptographic Message Syntax (CMS).
One of the reasons why CMS blobs are to be stored as octet strings
in the PKINIT messages is to ensure a boundary between the
requirements of Kerberos and the requirements of CMS.

It should be possible for a Kerberos implementor to pick up
any RFC3852 compatible CMS implementation and use it to encode
and decode the CMS content in the PKINIT message.

When people say in this discussion that we should encode BER
instead of DER, what they are really saying is that CMS encoded
messages should be encoded as loosely as is required by the CMS
RFC.  What is also being said is that the Kerberos PKINIT
specification should not place arbitrary restrictions on the
encodings of CMS objects which would prevent an RFC3852 compatible
implementation from being able to generate CMS messages for use
with PKINIT.

Jeffrey Altman

---

From: Martin Rex <[email-masked]>
Date: Thu, 14 Oct 2004 00:37:14 +0200 (MET DST)

> and decode the CMS content in the PKINIT message.

The use of unconstrained BER in CMS is a *HUGE* mistake.

The underlying problem is that lots of implementors don't write the
code themselves, but by others code; in particular they buy COTS
ASN.1 compilers.  And because the ASN.1 spec so far only offers the
two extremes DER and BER, but no useful middle ground without
the many constraints of DER and without the complexity of BER,
no-one seems to be willing to think about *reasonable* solutions.

One of the reasons why CMS uses BER might be that PKCS#7 used BER
and CMS is an extension of PKCS#7.

What I don't like about the discussion is this: we all realize
that we're stuck at some point that we don't like.  But we should
we resign and accept this situation forever and always?

I thought that no matter what we decide, we may formally or factually
break interoperability with some implementations.

How many interoperability problems do you expect if the spec would
say:   SHOULD encode DER, MAY encode BER without indefinite-length encoding
       MUST decode BER without indefinite-length encoding

and ask the current DER-only proponents whether the indefinite-length
encoding is the only BER-misfeature that would cause them headaches?

IMHO, if we limit our solutions to the features of a particular COTS tools
at a certain point in time, then we're pretty bad engineers.

-Martin

---

From: Sam Hartman <[email-masked]>
Date: Wed, 13 Oct 2004 18:48:02 -0400

>>>>> "Martin" == Martin Rex <[email-masked]> writes:

    Martin> How many interoperability problems do you expect if the
    Martin> spec would say: SHOULD encode DER, MAY encode BER without
    Martin> indefinite-length encoding MUST decode BER without
    Martin> indefinite-length encoding

One of the primary features CMS implementations want from BER is
indefinite-length encoding.

--Sam

---

From: Jeffrey Altman <[email-masked]>
Date: Wed, 13 Oct 2004 18:47:33 -0400

> and CMS is an extension of PKCS#7.

If you read the CMS RFC you will find that the reason for the use
of BER in CMS is that there is a need to support single pass encoding
and that cannot be done with DER.

Jeffrey Altman