Subject: Resolving DER vs BER

From: Jeffrey Hutzelman <[email-masked]>
Date: Wed, 25 Aug 2004 21:49:10 -0400

It's been a while since the WG meeting, and there doesn't seem to have been 
much discussion.  Which means that on at least some of our work items, 
we're not making any progress.

With regard to PKINIT, I think the biggest remaining hurdle before we can 
finish this document and start a last call is resolving the encoding issues 
(tickets 523 and 527 in RT).  To that end, I want to review what happened 
at the working group meeting in San Diego, and try to start some discussion 
on the remaining issue.

* The concensus of those present in San Diego was that any CMS objects
  contained within PKINIT PDU's _will_ get IMPLICIT OCTET-STRING wrappers.

So now, we have three layers of messages:

(a) Kerberos PDU's.
(b) PKINIT PDU's, contained in OCTET-STRING extension fields in Kerberos.
(c) CMS objects, contained in IMPLICIT OCTET-STRING wrappers in PKINIT.

Now, RFC1510 and kerberos-clarifications require DER for layer (a).
For layer (b), we reached a decision in San Diego:

* The concensus of those present in San Diego was that PKINIT PDU's
  (without speaking to CMS objects) MUST be DER-encoded.

That leaves us with layer (c).

On the one hand, several implementors have indicated they want the ability 
to implement PKINIT using off-the-shelf CMS libraries, some of which are 
incapable of generating DER-encoded output.  These folks want the spec to 
permit the sending of BER-not-DER-encoded objects, and correspondingly to 
REQUIRE the ability to decode full BER.

On the other hand, we have a participant preparing standards for a fairly 
large community of operators.  They want to be able to deploy PKINIT using 
off-the-shelf KDC's, in an environment using specialized embedded client 
implementations for which implementing BER decoders would be a significant 
burden.  These folks want to REQUIRE the sending of DER-encoded objects, 
and correspondingly to allow implementations which are capable of decoding 
only DER.

I've seen several proposals...

(1) REQUIRE generation of DER, because Kerberos does this at higher levels.

(2) REQUIRE full BER support, because CMS does.

(3) REQUIRE full BER support, RECOMMEND generating only DER.  Then let
    the PacketCable spec promote the SHOULD to a MUST and and allow
    clients to violate the Kerberos spec by decoding only DER.

(4) REQUIRE that KDC's send DER but be able to decode full BER, thereby
    making client implementors' lives easier at the expense of requiring
    more work for the (relatively few) KDC implementors.

(5) Apply Postel's Golden Rule, and REQUIRE generation of DER but the
    ability to decode full BER, making everyone's life hard.

I really would like to see this WG come up with a compromise that satisfies 
everyone.  The key to this, I think, is to discuss in more detail the 
desire expressed by Eric and CableLabs for operators to be able to deploy 
PacketCable using off-the-shelf KDC's.

Regardless of what we write in the PKINIT spec, the only way that is going 
to happen is if one of the following happens:

(A) PacketCable client implementations become capable of decoding full BER.
(B) General-purpose KDC implementors implement PKINIT in such a fashion
    that they send only DER.

This is where I want to see the focus of the current discussion.  We've 
heard all the technical, aesthetic, and ideological arguments; let's 
discuss the practical issues.

-- Jeff

---

From: Sam Hartman <[email-masked]>
Date: Thu, 26 Aug 2004 10:46:04 -0400

Speaking as an implementer, I need the flexibility to use whatever CMS
library is available on the platform I'm using.  For licensing and
technical resaons there is simply not a single library I can use on
all platforms.

On some platforms, there does not appear to be an option that
generates DER.  It seems wrong for the IETF to require that I not
support pkinit on those platforms in order to guarantee that Cable
Labs can choose any KDC they like.

As a practical matter, if we say :SHOULD generate DER, I think that
Cable Labs will have several KDCs to choose from.  They will
technically be violating the letter of the spec.  However, they will
be able to buy off-the-shelf KDCs and deploy a working environment.

If we say MUST DER, we will get into a situation where some
implementers may not be able to ship pkinit on some platforms.  This
may be true even for environments where no one plans to use the KDC
with Cable Labs clients.

--Sam