Thanks for the comments. I've updated the PRs appropriately. On Tue, Jun 13, 2017 at 12:56 AM Ilari Liusvaara <ilariliusva...@welho.com> wrote:
> On Tue, Jun 13, 2017 at 12:32:12AM +0000, Nick Sullivan wrote: > > All, > > > > I've collected a few changes that help clarify some ambiguities brought > up > > on the list and during implementation of the draft. These changes are > laid > > out as the following PRs in Github: > > > > Restrict the Certificate type to standard X.509 certificates. > > https://github.com/grittygrease/tls-exported-authenticator/pull/20 > > Supporting certificates that are not X.509 actually brings major > complications in protocol like this. The TLS library must > recognize those types in order to properly extract the key > needed to verify the CertificateVerify. The type extension can't > just be skipped. > > > Also, for related reasons, when implementing client certificates > in TLS library I am working on, I only implemented X.509, despite the > library supporting authentication based on keys, and RPK being > supported for server authentication. The reason for this was the > pretty nasty interaction of certificate types with client > certificates. > > > Relax requirement for the certificate_request_context to be unique, > clarify > > the benefits of doing so. > > https://github.com/grittygrease/tls-exported-authenticator/pull/18 > > Might also note unpredictability. And then note what happens if > uniqueness (replays of the same certificate) or unpredictability > (pregenerating responses) fails. Neither seems catastrophic (unlike, > say repeating a nonce in AEAD). > > After all, the certificate contexts in TLS 1.3 discuss > unpredictability. > Good comment. I added some text to reflect this. > > > Be more explicit about how signature schemes are chosen and supported. > > https://github.com/grittygrease/tls-exported-authenticator/pull/18 > > This seems to be only place where non-standard APIs are required from > the TLS library itself (I don't think most TLS APIs that do have > exporters and EMS indication have facility to obtain the list of > algorithms supported). > For this API, the server needs to know which signature algorithms the client supports and use that to make the correct choice of certificate. The signature schemes will have to be available already for servers to do dynamic certificate selection, so I don't see this as a big ask. > > And the client side is supposed to have a call for obtaining the > supported algorithms anyway. > > Why not always operate on TLS 1.3 semantics, regardless of transport > version? Main implications would be always using PSS with RSA and > not mixing ECDSA curves and hashes. > This would simplify the logic substantially. I don't see any problems with eliminating PKCS#1 1.5 altogether. I have updated the PR. > > > -Ilari >
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
