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
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
On Thu, Oct 06, 2016 at 01:59:33PM +1100, Martin Thomson wrote:
> On 6 October 2016 at 06:40, Ilari Liusvaara wrote:
> > The only issue that comes to mind is where extensions that are specific
> > to the certificate chain instead to the certificate go.
>
> Let's keep it simple. I would put these
On 6 October 2016 at 06:40, Ilari Liusvaara wrote:
> The only issue that comes to mind is where extensions that are specific
> to the certificate chain instead to the certificate go.
Let's keep it simple. I would put these on the EE cert. That is the
entry that has the most chance of being look
On Wed, Oct 05, 2016 at 03:06:25PM -0400, Sean Turner wrote:
> I’m not seeing objections to this PR so please let us know by Friday
> (7 October) whether you see any issues with what’s been proposed.
>
> > On Sep 22, 2016, at 20:42, Nick Sullivan
> > wrote:
> >
> > PR: https://github.com/tlsw
I’m not seeing objections to this PR so please let us know by Friday (7
October) whether you see any issues with what’s been proposed.
spt
> On Sep 22, 2016, at 20:42, Nick Sullivan wrote:
>
> PR: https://github.com/tlswg/tls13-spec/pull/654
>
> Hello,
>
> I'd like to propose a small to the
On Sat, Sep 24, 2016 at 09:31:51PM +1000, Martin Thomson wrote:
> On 24 September 2016 at 19:17, Ilari Liusvaara
> wrote:
> > It occured to me that certain extensions might be considered to be per-
> > chain. Like e.g. type of the certificate. Where do extensions like that
> > go? Always to the e
On 24 September 2016 at 19:17, Ilari Liusvaara wrote:
> It occured to me that certain extensions might be considered to be per-
> chain. Like e.g. type of the certificate. Where do extensions like that
> go? Always to the extension block of the first certificate (except that
> might cause somewhat
On Fri, Sep 23, 2016 at 11:05:10PM +, Nick Sullivan wrote:
> Thanks for the suggestions. I've restructured my PR to include an array of
> SingleCertificate objects in the Certificate structure.
It occured to me that certain extensions might be considered to be per-
chain. Like e.g. type of the
Thanks for the suggestions. I've restructured my PR to include an array of
SingleCertificate objects in the Certificate structure.
Ilari: I agree that the post-hanshake auth mechanism as currently described
is a bit lacking, but I'd like to sort this out first.
Victor: For cached_info, OCSP respo
This seems like a reasonable direction.
-Ekr
On Thu, Sep 22, 2016 at 7:26 PM, Nick Sullivan
wrote:
> This suggestion makes sense to me.
>
> Both the SCT and OCSP v2 extension allow for multiple objects in order to
> cover multiple certificates in a chain, but your suggestion makes the
> groupi
On Fri, Sep 23, 2016 at 12:42:09AM +, Nick Sullivan wrote:
> PR: https://github.com/tlswg/tls13-spec/pull/654
>
> Hello,
>
> I'd like to propose a small to the Certificate message format to allow for
> future extensibility of the protocol.
>
> This change adds a set of extensions to the Cert
This suggestion makes sense to me.
Both the SCT and OCSP v2 extension allow for multiple objects in order to
cover multiple certificates in a chain, but your suggestion makes the
grouping much more explicit and obviates the need for OCSPv2. I'd
definitely consider a modification like this.
Nick
O
Nick Sullivan wrote:
> PR: https://github.com/tlswg/tls13-spec/pull/654
>
> This change adds a set of extensions to the Certificate message. With this
> change, the Certificate message can now hold all extension messages that
> are certificate-specific (rather than connection-specific). This chan
14 matches
Mail list logo
