Subject: RE: Resolving DER vs BER

From: "Eric Rosenfeld" <[email-masked]>
Date: Tue, 31 Aug 2004 13:31:56 -0600

Jeff,

Thanks for putting together this email. I am not too keen on having the
PacketCable spec deviate from an RFC. So I am working with PacketCable
vendors to get some feedback on the impact of supporting BER encoding of
CMS objects. I hope to have some feedback by next week.

I am also interested in getting some feedback from WG members on whether
this level of complexity is really necessary. I do understand the goal
of supporting off-the-shelf CMS libraries, but is PKINIT's use of CMS
object extensive enough to really mandate BER support?

Thanks,
Eric

Eric S. Rosenfeld
Project Director, PacketCable Security
CableLabs
858 Coal Creek Circle
Louisville, CO  80027-9750
Phone: 303-661-9100
Fax: 303-661-9199
Web: www.cablelabs.com
Email: [email-masked]
Direct Phone: 303-661-3841
Direct Fax: 303-664-8195

-----Original Message-----
From: Jeffrey Hutzelman [mailto:[email-masked]] 
Sent: Wednesday, August 25, 2004 7:49 PM
To: [email-masked]
Subject: Resolving DER vs BER

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