Re: [keyassure] Bare keys again

[Eric Rescorla <[e-mail]>]

On Mon, Mar 21, 2011 at 12:57 PM, Paul Wouters <[e-mail]> wrote:
> On Mon, 21 Mar 2011, Eric Rescorla wrote:
>
>> [Speaking as an individual]
>> IMO the requirements of 5246 are fairly clear here:
>
>> In other words, when using any of the ordinarily certificate-based cipher
>> suites
>> (i.e., all the ones that everyone actually uses), it is not
>> permissible either to omit the
>> Certificate message or to have it be empty. This is not to say, of
>> course, that you
>> could not design an extension which would modify this behavior, but in the
>> absence of such an extension, any server which does not send its
>> certificate
>> would not comply with RFC 5246.
>
> That extension seems to already have been made in RFC 6066.

In my opinion, RFC 6066 does not relax the restriction to send Certificates
nor does it relax the restriction that it contain the EE's certificate.



>> [Speaking as TLS WG Chair]
>> An extension along the lines indicated would change basic properties of
>> TLS and
>> IMO would need to go through the TLS WG, and certainly is outside the
>> remit
>> of this WG.
>
> Didn't 6066 go through that process?

Yes.


> Should an errata be issued stating that RFC6066, section 6,
> TrustedAuthority case "pre_agreed" is deprecated?
>
> I do feel one of these choices has to be made. Either pre_agreed is a valid
> part of
> TLS, or it is not. It cannot be both.

It is a valid part of TLS, but it is not designed to be used for the purpose you
indicate. I think that's quite clear from the context of 6066.

Obviously, nobody is going to stop you from doing whatever you want
in your implementation. However, if you want to have an IETF standards
track document that specifies that a TLS stack behave in a certain way then
it would be good for that to match the TLS WG's understanding of what the
documents say.

-Ekr