On 6 October 2016 at 17:42, Ilari Liusvaara wrote:
> Perhaps also put server_certificate_type/client_certificate_type
> there? That would eliminate the anomaly that one must know the
> server certificate type before sending the certiifcate.
Sounds like a perfect use for the CertificateRequest ex
Changed milestone "CBC Fixes to IESG", resolved as "Done - See RFC
7525 & MTI AEAD algs in TLS1.3".
Changed milestone "RC4 replacement to IESG", resolved as "Done - See
RFC 7465 & RFC 7905", added draft-ietf-tls-prohibiting-rc4,
draft-ietf-tls-chacha20-poly1305 to milestone.
Changed milestone "(D
It was suggested that I update the milestones. So I did. All dates are ones I
guessed at.
spt
> On Oct 06, 2016, at 15:57, IETF Secretariat
> wrote:
>
> Changed milestone "CBC Fixes to IESG", resolved as "Done - See RFC
> 7525 & MTI AEAD algs in TLS1.3".
>
> Changed milestone "RC4 replacem
All,
It’s time to put this one to bed. ekr’s going to put back user_mapping for
Andrei/MS, but we’re going to ban/orphan the client_authz and server_authz
extensions. If it turns out that there’s some need to later unban/unorphan
them, then somebody can write a draft that specifies how they’r
This seems resolved.
I'll update the text to reflect that per-chain extensions should be
included as extensions of the end-entity certificate. For RFC 7250
client/server_certificate_type values (such as X.509) that apply to the
entire chain should be extensions of the EE cert.
The client_certific
