Subject: [TLS] AD comments on draft-ietf-tls-rfc3546bis

From: Eric Rescorla <[email-masked]>
Date: Fri, 19 Aug 2005 12:55:01 -0700

Can one of the authors please fix this...

X-Mailer: QUALCOMM Windows Eudora Version 6.2.1.2
Date: Fri, 19 Aug 2005 15:39:11 -0400
To: [email-masked]
From: Russ Housley <[email-masked]>
Subject: IANA Comments: draft-ietf-tls-rfc3546bis-01.txt

Eric:

I have been waiting for these Last Call comments from IANA to be addressed.

I think that we can generate the information needed to resolve this
comment without updating the document.

I just put this document on the Telechat agenda for September 1st.  If
I do not get this information before the telechat, I will enter a
DISCUSS to hold the document until I get it.  Hopefully, it will be
very straightforward,

Russ

= = = = = = = = =

IANA Last Call Comments:
Upon approval of this document the IANA will create a new registry for
ExtensionType values.  It is not clear as to what the initial list of
values are (even after looking in section 2.3).  Can a list be put in
the IANA Consideration section of what to populate the registry with?

The IANA will also change the reference for the MIME Media Type pkix-pkipath
to be this document.

_______________________________________________
TLS mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/tls

---

From: David Hopwood <[email-masked]>
Date: Thu, 25 Aug 2005 22:26:42 +0100

Wright, Timothy, VF-Group wrote:
> No hollering forthcoming from me!

No objection from me, either. I think it's unnecessary to change the
spec from RFC 3546.

It's worth pointing out that:

  - ciphersuite-specific extensions are useful only if the TLS *client*
    has extension options that depend on the ciphersuite. If the server
    has such options, no additional mechanism or conventions are needed,
    since the server can choose the ciphersuite and its extension replies
    together.

    Note that the issue of hardware that only supports certain ECC curves
    *mainly* affects servers, not clients.

  - not discussing ciphersuite-specific extensions in RFC3546bis will
    not prevent ECC (or anything else) from using a ciphersuite-specific
    extension. It just defers the issue of how to define such extensions
    to the documents that actually use them.

(While I remember, although it's not very important: Simon's proposal in
Message ID <05d801c58d6d$36c3f210$3200a8c0@simon> would have had a minor
incompatibility with RFC 3546 -- it depended on sending multiple extensions
of the same type, and section 2.3 of RFC 3546 explicitly disallows that.
A spec that wanted to define ciphersuite-specific extensions would have
to encode them all into a single extension to avoid this. I don't think
that's a problem, though.)

-- 
David Hopwood <[email-masked]>