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
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
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
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
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
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
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
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
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
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
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
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
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 Certificate message. With this
change, the Certificate message can now hold all
13 matches
Mail list logo