Re: [Trans] [trans] #74 (rfc6962-bis): normative statement of TLS client behavior in Section 3

On Tue, 7 Jul 2015 at 16:38 Stephen Kent <kent@bbn.com> wrote:

> Ben,
>
> > A certificate not accompanied by an SCT is not CT compliant.
> > This seems redundant: I would've thought that in general everything in
> > an RFC only applies to things that are compliant with that RFC. But if
> > the WG wants I don't really mind either way.
> I prefer the wording I suggested because it emphasizes the status of the
> cert relative
> to this spec, rather than intimating any TLS client behavior.
> >
> > OK, I get your point here, and I am happy to go either way:
> >
> > a) Update TLS to require CT, or
> that's not what I meant to suggest. I don't think CT is destined to become
> a mandatory aspect of TLS; it's an optional feature.
> > b) Update the I-D to say something like "CT compliant TLS clients" or
> > as you use below "TLS clients claiming conformance with CT", which
> > presumably does not update TLS?
> TLS is the definitive spec for the messages exchanged during its
> handshake. So
> the specs in Section 3.4 represent an update to TLS (1.2). That does not
> make
> support for CT mandatory, but it informs implementers of the new TLS
> extensions
> defined here and the processing they imply.
>

Ah, I see what you mean.

A couple of observations:

1. The TLS extension was allocated for 6962, so surely this should already
have happened?

2. I notice other extensions exist which are not referenced in the "update
by" section of 5246.

3. If this is a requirement for new extensions, why is it not part of the
process followed to get an extension allocated?

>
> Steve
>
> _______________________________________________
> Trans mailing list
> Trans@ietf.org
> https://www.ietf.org/mailman/listinfo/trans
>