Subject: Re: Tom You has an alternate extensions proposal

From: Love <[email-masked]>
Date: Thu, 04 Mar 2004 02:19:21 +0100

[email-masked] (Sam Hartman) writes:

> I'd like to draw people's attention to
> draft-yu-krb-wg-kerberos-extensions-00.txt.  This is an individual
> submission from Tom.  I haven't read it yet, but we seem not to have a
> draft announcement.

It was unclear that this was about reordering the structure of the document
so I just read it doing review of the ASN1 and not the structure of the
document.

The asn1 is really painful. Its just way too much new asn1 feature used. I
found it unclear from the boulder minuts that this was the way it going to
take. I'm not pleased and talked to Tom about it at last IETF.

the proposeal to have to version (where one is expanded) I find really bad,
just do one of them.

Love

---

From: Jeffrey Altman <[email-masked]>
Date: Wed, 03 Mar 2004 20:40:12 -0500

>the proposeal to have to version (where one is expanded) I find really bad,
I find the updated ASN.1 conceptually much easier to
understand.  If I was forced to choose one, it would
be the one with the new ASN.1 features.

- Jeff

---

From: "D. R. Evans" <[email-masked]>
Date: Thu, 04 Mar 2004 10:42:08 -0700

Jeffrey Altman said the following at 03/03/2004 06:40 PM:-
> be the one with the new ASN.1 features.

I agree with Love. I was under the strong impression from the Boulder 
meeting that at the very least there was agreement that there was going 
to be an Appendix or something that provided completely equivalent 
"old-style" ASN.1.

I see now that this is listed only as a "perhaps" in the Boulder 
minutes. I know that I am getting old and my memory is failing, but I 
clearly remember a much stronger agreement than that. Perhaps Sam and/or 
the MS attendees can either confirm or refute my meory....

Requiring implementors to manually convert the new fancy ASN.1 (or, I 
suppose, to buy a compiler that can handle it properly, which I doubt 
that many would want to do) seems bound to lead to errors. Much better 
that the document include ASN.1 written in a style with which poeple 
have experience.

   Doc

-- 

-----------------------------------------------------------
Phone:  +1 303 494 0394
Mobile: +1 720 839 8462
Fax:    +1 781 240 0527
-----------------------------------------------------------

---

From: Jeffrey Altman <[email-masked]>
Date: Thu, 04 Mar 2004 13:39:14 -0500

From my memory, what Tom said at the end of the Boulder was that we 
would develop the specification
using the new ASN.1 and then produce from that a version of the 
old-style ASN.1 which could be used
by implementers without access to tools supporting the new extensions.  
This proposal received significant
objection from Love and at least one other on the list because it would 
result in doubt as to which ASN.1
is the official standard. 

The new-style ASN.1 is much easier in my mind to be able to look at 
independent of the English text
and be able to determine which fields are actually used in which 
messages and what value constraints
are applied.  I find that extremely useful when discussing the protocol 
as it has significantly less ambiguity.
For example in yesterday's Jabber session there was extensive discussion 
between Larry, JHutz, and myself
on whether or not the cname field in an AS-REQ message is required.  The 
English text in clarifications
does not include the word "MUST" and therefore Larry believed the field 
to be optional.  However, the
new-style ASN.1 provided at the Boulder meeting makes it quite clear 
that the cname field is required:

      AS-REQ  ::= CHOICE {
          rfc1510     [APPLICATION 10] KDC-REQ-1510
          (WITH COMPONENTS {
              ...,
              msg-type (10),
              -- AS-REQ must include client name
              req-body (WITH COMPONENTS { ..., cname PRESENT })
          }),
          ext         [APPLICATION 6]  Signed {
              -- APPLICATION tag goes inside Signed{} as well as outside,
              -- to prevent possible substitution attacks.
              [APPLICATION 6] KDC-REQ-EXT,
              -- not sure this is correct key to use; do we even want
              -- to sign AS-REQ?
              { key-client },
              { ku-ASReq-cksum }
          }
          (WITH COMPONENTS {
              ...,
              msg-type  (6),
              -- AS-REQ must include client name
              req-body (WITH COMPONENTS { ..., cname PRESENT })
          })
      }

For me this is an overwhelming argument as to why the new-style ASN.1 
must be used.  The ASN.1
when provided with constraints is unambiguous even if the actual on the 
wire formats produced
from it might be.

Jeffrey Altman

D. R. Evans wrote:

> meeting that at the very least there was agreement that there was 
> going to be an Appendix or something that provided completely 
> equivalent "old-style" ASN.1.
>
> clearly remember a much stronger agreement than that. Perhaps Sam 
> and/or the MS attendees can either confirm or refute my meory....
>

---

From: Nicolas Williams <[email-masked]>
Date: Thu, 4 Mar 2004 13:10:47 -0600

> when provided with constraints is unambiguous even if the actual on the 

Exactly.  I couldn't agree more.

Formal languages really are better than English for complex protocol
specifications.

As for the old-style ASN.1 modules, which might be useful to
implementors lacking sufficiently upto date ASN.1 tools, I think I might
prefer an Informational document to go along with the Extensions
document that would: a) describe what transformations to apply to the
full-featured Extensions ASN.1 module to obtain two modules
(clarifications and extensions) using simpler ASN.1, plus an appendix to
this same document listing the two modules.

A separate document would be useful for two reasons: a) to reduce
clutter in the primary Extensions document, and b) to make absolutely
clear that nothing in the informational document is normative with
respect to Extensions.

Nico
--

---

From: Jeffrey Altman <[email-masked]>
Date: Thu, 04 Mar 2004 14:26:11 -0500

There is a crucial missing "not".  "... even if the actual on the wire 
formats produced from it might not be."

Jeffrey Altman wrote:

> when provided with constraints is unambiguous even if the actual on 
> the wire formats produced
> from it might be.
>
> Jeffrey Altman
>

---

From: "D. R. Evans" <[email-masked]>
Date: Thu, 04 Mar 2004 13:24:21 -0700

Nicolas Williams said the following at 03/04/2004 12:10 PM:-
> Formal languages really are better than English for complex protocol

Well I certainly agree with that. Hmmm let's compare what RFC1510 says 
about cname and AS-REQ in the formal ASN.1 as compared to the English... 
Whoops! Did I really say that?

> clear that nothing in the informational document is normative with

I don't care how it's done, but I am strongly of the opinion that we 
have to do a bit more than just "define [the] transformations", and 
indeed I thought that we had agreed that more would be produced. I 
somehow missed the later debate that seems to have changed this. My 
apologies for not noticing this debate and chiming in at that time.

 > is the official standard.

There doesn't need to be any doubt, does there? Surely it can be made 
clear in the documents themselves which is controlling. I just want to 
help the poor developer, that's all.

   Doc

--

---

From: Nicolas Williams <[email-masked]>
Date: Thu, 4 Mar 2004 14:39:41 -0600

> Whoops! Did I really say that?

I'm not advocating that we interpret RFC1510's intention without
reference to the English language text in it.

I'm advocating that for extensions we describe as many protocol syntax
constraints as possible through a formal specification language (ASN.1)
rather than through English, precisely because it's easier to be precise
about such contraints in formal languages than in natural languages.

(We can make mistakes in the ASN.1, but at least they'll be less
ambiguous!)

There is a limit of course.  I won't advocate the use of SDL...  :)

> apologies for not noticing this debate and chiming in at that time.

To begin with, we have a very early draft.  I'm sure that Tom put into
it as much as he could given time constraints.  I for one still think
that should have a document that shows the unentangled ASN.1 modules.

> help the poor developer, that's all.

Right.

Nico
--

---

From: Brian Tung <[email-masked]>
Date: Thu, 4 Mar 2004 13:07:39 -0800

> formats produced from it might not be."

Actually, I understood the word "ambiguous" to be elided out from your
sentence.  It comes to much the same thing.

Along the same lines, Sam had occasion yesterday to refer to MitM as
Malary yesterday on Jabber.  As I mentioned, that name didn't ring a
bell to me, although I know I certainly used some name for it when we
studied that in primary school.

The problem, as it happened, is that when Sam wrote Malary, I read it
as "muh-LAH-ree," and I couldn't get that out of my head, since a friend
of mine has that last name.  It wasn't until I got home that I recalled
the name we used was "Mallory."  (At least, that's the spelling in
Schneier.)

So I guess Jabber isn't perfect for everything.

Brian Tung <[email-masked]>

---

From: Ken Hornstein <[email-masked]>
Date: Fri, 05 Mar 2004 06:52:26 +0900

>However, the
>[...]

I realized I hadn't had a chance to look at the new ASN.1 constructs
completely, but this finally motivated me.  I've realized something
important: I don't understand it at _all_.  I know you think this
is much clearer, Jeff, and I guess if you know a lot about ASN.1
it is, but I really can't make sense of the PDU this construct is
describing, and the only thing that gives me a hint about the cname
not being option for AS-REQ is the comment; otherwise, I would have
no clue.

So I think it is extrememly important to include the "simplified" ASN.1,
because it's what some of us humans are going to refer to when they read
this document.  And my recollection matches Larry's and DR's from Boulder;
there was very strong consensus in my mind to include the simplified ASN.1
in an appendix.  However, I think it's reasonable to make the new ASN.1
the normative reference, and clearly mark the appendix as informative
and non-authoritative.

--Ken

---

From: "D. R. Evans" <[email-masked]>
Date: Thu, 04 Mar 2004 16:07:32 -0700

Ken Hornstein said the following at 03/04/2004 02:52 PM:-
> not being option for AS-REQ is the comment; otherwise, I would have

If you do s/clear/unambiguous/ then I think that Jeff is right. But I am 
all but certain that if you threw the line
              req-body (WITH COMPONENTS { ..., cname PRESENT })
at most developers, they'd look at you kinda funny and go off and find 
something else to do instead.

> the normative reference, and clearly mark the appendix as informative

Obviously, I agree with all that.

   Doc

--

---

From: Nicolas Williams <[email-masked]>
Date: Thu, 4 Mar 2004 17:46:31 -0600

> something else to do instead.

We can all learn enough ASN.1 to parse that (not that long ago I would
not have known what to make of that example either).

Some ASN.1 constructs, like this one, are syntactic operators, meaning
that you can manually evaluate and thus remove the operator -- if you
find the result simpler to understand, then by all means do this.

In fact, that's one of the steps towards producing the simpler,
disentangled ASN.1 modules for clarifications and extensions out of the
ASN.1 module in the proposal.

> >the normative reference, and clearly mark the appendix as informative

No objection.

Nico
--

---

From: Martin Rex <[email-masked]>
Date: Fri, 5 Mar 2004 19:10:49 +0100 (MET)

> the normative reference, and clearly mark the appendix as informative

I'm not a Kerberos implementor and therefore some of you may simply
ignore my opinion, but the discussion here doesn't sound very
promising to me.

If an appendix with simplified ASN.1 is going to be included because
that is what quite many readers are going to understand, then it
this OUGHT to be just as normative as the "full blown" ASN.1
in the document--otherwise this is going to be a real mess!

There are very few people ASN.1-literate enough to feedback/review the
full blown ASN.1--which makes it an extremely poor candidate for
both, discussion and normative reference.

And if the small elite (which has designed and reviewed the full blown
ASN.1 part) is unable to **implement** it correctly in simplified ASN.1,
how could we expect that those Kerberos implementors that use home-grown
parsers based on the simplified ASN.1 will interoperate with those
implementations that mindlessly employ a bleeding-edge ASN.1 compiler?

The beauty of a specification is in its simplicity.

One other thing that worries me: if it is possible with the new ASN.1
language to be precise about whether something is optional or not,
then this will be a result of what the document author writes,
and he may not even think about whether it's worth discussing this
decision.

As long as such details need to be in English language, they will
be decided more conciously, receive more explanation/reasoning in
the natural language and trigger more thought/feedback from
the reviewers--which is a Good Thing!

-Martin

---

From: "D. R. Evans" <[email-masked]>
Date: Fri, 05 Mar 2004 14:26:08 -0700

Martin Rex said the following at 03/05/2004 11:10 AM:-

> The beauty of a specification is in its simplicity.

While I am arguing quite forcefully for the inclusion of what I am 
calling "old-style" ASN.1, I have to take issue with this sentence on 
two grounds:

1. Simplicity is in the eye of the beholder. I sympathize with (although 
I'm not sure I agree with) anyone who argues that new-style ASN.1 is 
simpler. I certainly wouldn't reject new-style ASN.1 simply on the basis 
of old-style being "simpler".

2. The beauty of a specification is surely in its:
   a. Correctness
   b. Completeness
   c. Implementability (which is usually a synonym for "clarity")
Personally, I think that "simplicity" is basically irrelevant to 
Kerberos. Implementing any ASN.1-based specification is fundamentally 
not "simple", for reasonable values of the word "simple".

   Doc

--

---

From: Ken Hornstein <[email-masked]>
Date: Mon, 08 Mar 2004 10:57:25 -0500

>in the document--otherwise this is going to be a real mess!

Well, sure ... in a perfect world, we would do that.  But we don't
live in such a world.

I understand the people who want the use the "new" ASN.1 to create a
much more precise specification.  No problem with that.  I even think
that it's reasonable for people who create Kerberos implementations to
be required to understand it.  However, the number of Kerberos
implementors is relatively small, but there is a large community of
people who are _not_ Kerberos implementors but need/want/find it useful
to understand the format of Kerberos messages.  _These_ are the people
I am thinking of when I am asking that the simplified ASN.1 be included
(I include myself in this boat).  I was able to pick up enough ASN.1
from reading RFC 1510 to make sense of the messages without a problem;
I think requiring people to understand the full extent of ASN.1 to
comprehend the Kerberos Extensions document is unreasonable.

Now, as for making both normative ... well, my problem with that is that
there might be a conflict between the simplified ASN.1 and the full-blown
ASN.1 (yes, that would be a bug, but it wouldn't be the first, now would
it?).  So in my mind, we need to make one and only one normative ... and
clearly the full-blown ASN.1 is a better choice, since it is more precise.

>the reviewers--which is a Good Thing!

Well, I guess I can't agree.  People got this wrong by implementing the
ASN.1 in RFC 1510 without reading the English language text that specified
whether some fields were optional or not.  A formal specification would
have helped there.

--Ken

---

From: Sam Hartman <[email-masked]>
Date: Mon, 08 Mar 2004 14:11:37 -0500

>>>>> "D" == D R Evans <[email-masked]> writes:

    D> I agree with Love. I was under the strong impression from the
    D> Boulder meeting that at the very least there was agreement that
    D> there was going to be an Appendix or something that provided
    D> completely equivalent "old-style" ASN.1.

I was under that impression as well.  I was actually under the
impression we had not even committed to shipping the new ASN.1 as part
of the final extensions document.

We were going to use it to develop the specification, but might end up
changing over to the old ASN.1 at the end of the process if people
were too concerned about the possibility of conflicts between the two
specifications.

One question I have: do we actually plan to be able to develop the
tools to automatically produce ASN.1 without constraints,
parameterized types or object notation in a timely manner?

If we don't have time to produce these tools, then I don't think we
can afford to use the new ASN.1.

--Sam

---

From: Nicolas Williams <[email-masked]>
Date: Mon, 8 Mar 2004 13:50:34 -0600

> were too concerned about the possibility of conflicts between the two

I remember this also.

For the time being and for as long as the differences between
clarifications and extensions are not yet settled I believe it will be
best to stick to the entangled module.

> parameterized types or object notation in a timely manner?

Oh, I wished I could devote some time to that.  I've barely even thought
about such tools since, oh, say one week after the interim meeting.

> can afford to use the new ASN.1.

I disagree -- see above.  Once the design of extensions is more firmly
agreed to by all we can disentangle the modules and get rid of *some*
but not all of the new ASN.1 syntax -- that is, we should still use
constraints more effectively than in clarifications.

Nico
--

---

From: Sam Hartman <[email-masked]>
Date: Tue, 09 Mar 2004 14:11:52 -0500

>>>>> "Nicolas" == Nicolas Williams <[email-masked]> writes:

    Nicolas> On Mon, Mar 08, 2004 at 02:11:37PM -0500, Sam Hartman
    >> One question I have: do we actually plan to be able to develop
    >> the tools to automatically produce ASN.1 without constraints,

    Nicolas> Oh, I wished I could devote some time to that.  I've
    Nicolas> barely even thought about such tools since, oh, say one
    Nicolas> week after the interim meeting.

    >> If we don't have time to produce these tools, then I don't
    >> think we can afford to use the new ASN.1.

    Nicolas> I disagree -- see above.  Once the design of extensions
    Nicolas> is more firmly agreed to by all we can disentangle the
    Nicolas> modules and get rid of *some* but not all of the new
    Nicolas> ASN.1 syntax -- that is, we should still use constraints
    Nicolas> more effectively than in clarifications.

I think that our tools need to be good enough so that at the time we
last call the document we can produce ASN.1 that implementers can use.
I think this is an absolute requirement.

So, as our time to work on tools decreases, our ASN.1 should become
simpler until our tools match our ASN.1.