Re: [secdir] Review of draft-merkle-tls-brainpool-03

[Simon Josefsson <[e-mail]>]

You wrote:

> > When I read the document, it seems to be missing its "gut".  There
> > is one section "Introduction" and then you would expect the actual
> > specification.  But instead comes the Security Considerations and
> > the rest of the usual IETF boiler plate.  The contribution of this
> > document is hidden in the IANA Considerations.
> 
> If you have a look at version 01, you see that such a section 2 was
> present. Sean suggested to remove it. It seems that your tastes as to
> the structure differ... I am willing to change the structure and
> wording as long as there is consensus on that.

I wasn't aware of this earlier discussion -- it was just my reaction
reading the current document, so you shouldn't take it too seriously.
Version 01 seems to contain a lot more normative language in that
section, maybe that was the issue.
 
> > --->>>
> > 2. Brainpool NamedCurve Types
> > 
> > This document adds three new NamedCurve types as follows.
> > 
> >         enum {
> > 	     brainpoolP256r1(TBD1),
> > 	     brainpoolP384r1(TBD2),
> > 	     brainpoolP512r1(TBD3)
> >         } NamedCurve;
> > 
> > These curves are suitable for use with DTLS [RFC6347].
> > <<<---
> > 
> This is much less verbose as our previous section 2. Maybe this could
> be a compromise between Sean's preference of being compact and your
> preference of the draft having "guts".

Yes.
 
> But isn't this syntax incorrect as there are already code points
> defined for namedCurve? Your text defines namedCurve as comprising of
> three values which is not true.

No, the TLS meta language is not strictly defined, and the above is
fine. If you compare other TLS documents inroduce new types, this is
how you often express adding new enums.  Compare RFC5878 and RFC6042.

/Simon