Subject: RE: BER v DER: implementation comment

From: "Liqiang(Larry) Zhu" <[email-masked]>
Date: Fri, 3 Sep 2004 09:11:32 -0700

Lzhu wrote:
> thus are not constrained by the BER encoding rules used by Kerberos
messages.  

Please strike "BER" from above.

-----Original Message-----
From: Liqiang(Larry) Zhu 
Sent: Friday, September 03, 2004 9:01 AM
To: 'D. R. Evans'
Cc: [email-masked]
Subject: RE: BER v DER: implementation comment

> Um.... are you really suggesting that PKINIT-enabled KDCs not enforce 
> DER when they parse incoming messages

The BER vs DER discussion is for the encoding of the CMS objects only.
These objects are encapsulated in OCTET STRING in the Kerberos messages,
thus are not constrained by the BER encoding rules used by Kerberos
messages.  

The Microsoft CMS library (also known as CRYPTO-API) can decode
BER-encoded CMS objects, and the CMS objects it produces are DER
encoded. Thus if your KDC only accepts DER-encoded CMS, it should be
able to interoperate with our implementations.

Our position on this issue is that the PKINIT draft should not discuss
the encoding of CMS objects and leave it to the CMS spec.  I believe
Heimdal has a similar position.

Larry

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]] On Behalf Of D. R. Evans
Sent: Friday, September 03, 2004 7:24 AM
Cc: [email-masked]
Subject: Re: BER v DER: implementation comment

Tom Yu said the following at 2004-09-02 17:07 :

> Valid DER encodings are a subset of valid BER encodings.  As long as 
> you don't enforce strict DER on decode,

Um.... are you really suggesting that PKINIT-enabled KDCs not enforce
DER when they parse incoming messages?

Danger, danger, Will Robinson....

"Why does your KDC not accept my BER-encoded Kerberos messages? This one
over here is much better than yours, because it does...."

   Doc

--
--------------------------------------------------------------
Phone:  +1 303 494 0394
Mobile: +1 720 839 8462
Fax:    +1 781 240 0527
IM:     [email-masked]
--------------------------------------------------------------

---

From: "Liqiang(Larry) Zhu" <[email-masked]>
Date: Fri, 3 Sep 2004 11:22:03 -0700

D. R. Evans wrote:
> Now, either Tom is wasting bandwidth on a completely NOP response
(which I doub

Perhaps Tom wanted to make a point about the amount of code you can
share between the two parsers.

> In our KDC implementation this is a trivial thing to arrange,

This backs up the above claim.

Larry

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]] On Behalf Of D. R. Evans
Sent: Friday, September 03, 2004 10:11 AM
Cc: [email-masked]
Subject: Re: BER v DER: implementation comment

> The BER vs DER discussion is for the encoding of the CMS objects only.

Um, here is what Tom said, including my original observation:

-----

N7DR> Also, one shouldn't generalize it to assume that all 
N7DR> implementations would require similarly small amounts of change. I

N7DR> suspect that adding support for BER decoding of some fields while 
N7DR> maintaining DER decoding for other fields would in fact be a major

N7DR> pain for some implementations, especially clients.

Valid DER encodings are a subset of valid BER encodings.  As long as you
don't enforce strict DER on decode, a BER parser will handle both DER
and BER inputs.

-----

So, to paraphrase:

My original comment: Clients might find it difficult to plement BER for
the CMS layer, because they have to have a DER parser for Kerberos -- so
now they need two parsers.

Now, either Tom is wasting bandwidth on a completely NOP response (which
I doubt) or he's suggesting that you don't need a DER parser because a
BER parser can parse DER. I disagree with that conclusion: you must have
a DER parser for the Kerberos stuff. If you allow BER in CMS, you now
also need a BER parser for the CMS stuff (and a way to switch between
the two, of course). In our KDC implementation this is a trivial thing
to arrange, but that may not be true for other implementations,
especially of clients.

   Doc