Subject: [pkix] TLS Security Policy Specification

From: Phillip Hallam-Baker <[email-masked]>
Date: Fri, 27 Apr 2012 14:48:51 -0400

In response to a CABForum working group meeting, I wrote up the
proposal for improving revocation checking by allowing certificates to
specify that a server supports stapling:

http://www.ietf.org/id/draft-hallambaker-tlssecuritypolicy-00.txt
http://www.ietf.org/id/draft-hallambaker-tlssecuritypolicy-00.pdf

The approach is slightly broader in principle but as the draft
explains, stapling is the only feature for which a certificate based
security policy is currently relevant.

Given that we have already had a long discussion of the merits of the
scheme here, I suggest that people address the implementation approach
unless they have something new to add. As the security considerations
state, this control does not attempt to prevent every form of
revocation based downgrade attacks, merely the ones that account for
99% of the reported incidents. There are other controls being
developed to deal with the remaining cases.

-- 
Website: http://hallambaker.com/

---

From: Adam Langley <[email-masked]>
Date: Mon, 30 Apr 2012 10:48:54 -0400

> security policy is currently relevant.

Generally, looks good to me.

For the minVersion, using x to mean TLS 1.(x-1) seems unnecessarily
complex. Why not have x mean TLS 1.x? (i.e. 0 -> TLS 1.0, 1 -> TLS 1.1
etc?)

I think the following client behaviour needs to be specified:

1) what happens when minVersion is greater than what I support? Should
I abort, or carry on as best I can?

2) what happens when extensions contains a value that I don't know
about? Should I ignore it?

Cheers

AGL