Subject: Re: [pkix] TLS Security Policy Specification

From: Phillip Hallam-Baker <[email-masked]>
Date: Wed, 2 May 2012 22:45:20 -0400

On Mon, Apr 30, 2012 at 10:48 AM, Adam Langley <[email-masked]> wrote:
> On Fri, Apr 27, 2012 at 2:48 PM, Phillip Hallam-Baker <[email-masked]> wrote:
>> 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.
>
> 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?)

The problem is that TLS 1.0 has a version ID of 3,1 because 3,0 was
taken for SSL.

OK so if we never update the major version number it doesn't matter.
But if we did we would have a new policy oid for TLS 2.0 and that
would probably start from identifier {4,0}

> 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?

You MUST conclude that there is a policy violation because the site
has said it will support the higher version and it isn't doing that.

What action you then take would be for client policy. I would
recommend abort in that case as it is really very rare for a version
number to go backwards like that... but it is not a compatibility
issue so it is for the client policy to decide.

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

Ignore it. I will make that explicit.

The only thing that the policy says is that the extension will be
offered. If you don't understand the extension you MUST NOT ask for it
anyway as it would probably break you anyway.

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