Re: [pkix] [TLS] New version of the TLS feature draft

[Tom Ritter <[e-mail]>]

On 5 September 2014 10:34, Nikos Mavrogiannopoulos <[e-mail]> wrote:
> I don't see how it does close the door. What should the client do if the
> server administrator sets up an old version of a valid ocsp staple?

Section 3.1.1 specifies "a server MUST return a valid OCSP token".   I
would consider an expired ocsp staple to not actually be valid.  I
would refer to it as expired, with the implication that the signature
is correct, because if it wasn't a person probably would have said
that in addition to describing it as expired.

> This
> case is not discussed in the security considerations at all.

Because I don't consider an expired staple to be valid, I don't feel
this case is appropriate for Security Considerations.  If for some
reason expired OCSP staples are actually accepted by end entities,
then yea, Security Considerations fits.



Other Comments:

Section 3.2.3, omitting status_request results in a SHOULD reject, and
omitting in general results in a MAY reject.  I agree with the
sentiment: we can't predict if future uses of this would be a MUST or
SHOULD or MAY, but to someone reading the document, it seems
contradictory at first read.  I would suggest that this detail be
included to explain the apparent contradiction.


Section 3.2.2, regarding an Intermediate Cert with the extension.
a) I don't understand "primarily intended for use by parties seeking
to evaluate the performance of certificate issuers".
b) For the status_request extension, I would actually prefer that a
client MUST or SHOULD reject certificates that omit the extension if
signed by a cert that has the extension. I say this because I see a
use case of a CA standing up such an Intermediate, and end entities
purchasing certificates off that Intermediate, and then pinning to
that Intermediate. This is effectively one mechanism of ensuring that
all certificates for a domain contain the extension.  Just like 3.2.3,
this is another example of the specific case seemingly-but-not
contradicting the general case.

Minor Grammar:

Section 2, Paragraph 3, First sentence.  'is' should be 'are', there
should be an 'and', and a period before "These extensions".
Section 2, Paragraph 9: "a client request for the status_request or
status_request_v2 features" - features should be singular




Overall, and I know you went to pains to reduce this, the terminology
is confusing.  I think the definition you set out with extension =
x509 extension and feature = TLS extension works well. But I think it
gets confusing because you also define TLS Feature (capital F) as the
name of the thingie you are writing the draft about.  I'm not saying
it should be called this, but I took the draft and replaced 'TLS
Feature' with 'Required Data'.  This read must nicer, and also exposed
a few places where the terminology/grammar was extra confusing or
inconsistent.

 - Features ::= SEQUENCE OF INTEGER - rather than calling it Features,
perhaps some word that is not used in so many contexts?  Such as
'Requirements', 'RequiredData', 'RequiredExtensions',
'MandatedExtensions', 'MandatedData'...

 - Section 2, Paragraph two: "the TLS Feature is only" - this should
either be 'the TLS Feature extension is only' or if you want to use it
as if it's a proper noun, 'TLS Feature is only'.  I don't think it
should be used as a proper noun, and should be generally referred to
as 'the TLS Feature extension'
 - Section 2, Paragraph three, first sentence: "the only TLS feature
extensions that are relevant" - should be "the only features" or
expand the definition this once and say "the only TLS extensions"
 - Section 2, Paragraph three, second sentence: In this sentence
'extension' refers to the TLS extensions.
 - Section 2, Paragraph five: "The inclusion of a TLS feature
extension" - feature should be capitalised as it refers to the thingie
defined in the draft.

 - Section 2, Paragraph six:  "Nevertheless a Certification Authority
MAY consider the presence or absence of a required TLS feature as one
factor" - a) I think you should remove 'required' as it gets confusing
as who is requiring what. Whether the client requires Comodo to
include the x509 extension or requests it to be included is not
relevant. It's also not necessary accurate.  Is the presence of a x509
extension in a CSR a requirement?  Nay, as I include BasicConstraints
ca:True and don't get what I require ;)   b) feature should again by
capitalized, as you're referring to the thingie defined in the draft.
I would suggest saying "absence of the TLS Feature extension in the
certificate signing transaction as one factor".  I said 'transaction'
vs 'request' to encompass both a CSR and a (e.g.) phone call.

 - Section 2, Paragraph seven: "A server offering an end entity
certificate with a TLS feature extension MUST" - again, feature should
be capitalized to refer to the thingie being defined
 - Section 2, Paragraph seven: "that the server is capable of
verifying that its configuration is compatible with the feature
declaration of the certificates it offers" - strongly suggest this be
re-worded to 'with the TLS Feature declaration it offers'.
Technically feature could be correct, if it was interpreted not as a
defined term but as the colloquial word - but lets try to avoid that.
 - Section 2, Paragraph seven: "Ideally, the TLS feature declaration"
- again, feature should be capitalised to refer to the thingie being
defined
 - Section 2, Paragraph ten: "This document describes the use of the
TLS feature in PKIX end entity" - feature should be capitalised, and I
would suggest adding 'extension' after it.
 - Section 3.1 Paragraph one: "server compliant with the feature
declaration" - I think omitting 'feature' is actually more
descriptive.  Otherwise, perhaps 'the object member declaration'?
 - Section 3.1 Paragraph three: "offering the certificate MUST support
the extension specified" - extension refers to TLS extension, and so
should be 'feature'
 - Section 3.1 Paragraph three: "specified for that feature in this
document or in the document that specifies the TLS feature" - suggest
maintaining consistency and saying 'that TLS feature' in both of these
two instances
 - Section 3.2.3 "a server MUST meet to be compliant with the feature
declaration" (and the other two instances of 'feature declaration' in
this section) - perhaps replace feature declaration with 'the TLS
Feature extension'?
 - Section 3.3.1 "For example the use of a Feature extension in the
CSR" - should be full name, "TLS Feature"
 - Section 3.3.2 "A server SHOULD support generation of the Feature
extension in CSRs if key generation is supported." - same

I realize this is an intense number of minor suggestions with
tough-to-follow context.  If you send the .xml or post it on Github,
I'd be happy to make these suggestions in the form of text changes. (I
particularly like drafts on Github, as I can logically separate
different changes into different commits and you can review them as
such.)

-tom