X.509v3 Transport Layer Security (TLS) Feature Extension
draft-hallambaker-tlsfeature-10

Expanding OCSP (and maybe pointing to RFC6960 for further reference) would be nice.

General comment: in a number of places you add an explanation of WHY.  I appreciate that, and I think it helps a lot -- especially when you're explaining a SHOULD.  Thanks.

-- Section 1.2 --

   In order to avoid the confusion that would occur in attempting to 
   describe an X.509 extension describing the use of TLS extensions, in 
   this document the term 'extension' is reserved to refer to X.509v3 
   extensions and the term 'feature' is used to refer to a TLS 
   extension.

I applaud the attempt to avoid confusion.  Yet this sentence itself confuses me.  What, then, is a "TLS feature extension"?  From the above, because it's an "extension", it's an X.509v3 extension.  But it sure sounds like it ought to be a TLS extension, and maybe it kinda is, because it has "feature" in it... but that's all very confusing and unclear, despite the attempt at clarity.

-- Section 2 --

   A Certification Authority SHOULD NOT issue certificates that specify 
   a TLS feature extension advertising features that the server does not
   support.

How does the CA avoid it?  The next sentence basically says that the server self-declares what it supporte.  How does the CA know for sure?  Do you mean that the CA SHOULD NOT issue certs that specify features that the server does not CLAIM to support (you seem to say exactly that in 3.3.1)?  Or is there a way the CA can check, and it should do that?

-- Section 3.1 --

   If these 
   features are requested by the client in its ClientHello message, then
   they MUST be present in the server's ServerHello.

I don't understand the MUST there.  Isn't the ClientHello making requests and the ServerHello responding with those the server agrees to offer?  Can you explain what you're trying to say with that MUST?

-- Section 3.2.2 --

   Specifically, a certificate that is signed by a Certificate 
   Signing Certificate that contains a TLS feature extension MUST 
   contain a TLS feature extension which MUST offer the same set or a 
   superset of the features advertised in the signing certificate.

A small point, but the double MUST is unnecessary and awkward. I would change "which MUST offer" to "that offers" -- the first MUST has the requirement covered.

-- Section 5.2 --
I agree that this is probably not a big deal, but I posit that issuing a cert that clients will reject is likely a much more disruptive attack than refusing to issue the cert in the first place.  With a refusal to issue, the server admins know up front that there's an issue and can deal with it directly.  With the other, it may take some time to find out that something is amiss, and many customers might be angered in the process (because they couldn't get access to their accounts, or some such).  Sure, servers should test their new certs with strict clients before they roll them out... but I'm sure many don't.

I shared Barry's confusion about the term "TLS Feature Extension" in the context of section 1.2. I had to spin on this a bit to realize we were talking about an X509 extension that advertised TLS features rather than an "extension" of TLS "features".