I've stayed out of this discussion so far, because my opinion has already been
noted, but since you've changed the subject...
On Jan 27, 2010, at 12:50 AM, Kemp, David P. wrote:
> Yes. I agree that SCSV could be defined to convey only 1 bit of
> information while RI conveys 2 bits, and agree th
On Wed, Jan 27, 2010 at 1:05 AM, Martin Rex wrote:
>> That's been the standard for PKIX RFCs for at least ten years
>> (actively acknowledged by WG mmembers), although perhaps its spread
>> to other groups should be discouraged.
>
> I fully agree.
>
> That may be attributed to the fact that a lar
Concerning the SCSV behavior I prefer publishing the specification as-is.
regards,
Nikos
On Tue, Jan 26, 2010 at 9:49 AM, wrote:
> Concerns have been raised that the IESG may have judged community
> consensus about one specific detail of draft-ietf-tls-renegotiation
> prematurely. In particular
At 6:57 PM +0100 1/26/10, Martin Rex wrote:
>The two MUST NOTs that popped up in -03 are in violation of rfc2119 section 6!
...as are about half of all MUSTs and SHOULDs in modern IETF standards.
>Did anyone of you review the new sections in the -03 draft?
Yes.
>I do not think that rushing the
(1) I prefer publishing the specification as-is.
Steve.
--
Dr Stephen N. Henson.
Core developer of the OpenSSL project: http://www.openssl.org/
Freelance consultant see: http://www.drh-consultancy.co.uk/
Email: shen...@drh-consultancy.co.uk, PGP key: via homepage.
___
I confirm that I support publishing Version -03 as-is.
Rationale:
Version -01 states that the semantics of SCSV is identical to the
semantics an empty RI, namely: "this client is capable of supporting
secure renegotiation, and this ClientHello message is an initial
handshake, not a renegotiation
Concerns have been raised that the IESG may have judged community
consensus about one specific detail of draft-ietf-tls-renegotiation
prematurely. In particular, the discussion that happened just after
the IETF Last Call ended might have caused some people to change their
opinion, and also the holi
