Re: [TLS] Proposed Change to Certificate message (#654)

[Nick Sullivan]

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_certificate_type extension sent from the server in RFC 7250 can
go in either the encrypted extensions or the proposed CertificateRequest
extension field, but that has no bearing on this proposal.



On Thu, Oct 6, 2016 at 2:26 AM Martin Thomson 
wrote:

> 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 extension field,
> for the client certificate anyway.
>
> ___
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Proposed Change to Certificate message (#654)

[Martin Thomson]

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 extension field,
for the client certificate anyway.

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Proposed Change to Certificate message (#654)

[Ilari Liusvaara]

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 the EE cert.  That is the
> entry that has the most chance of being looked at.

Yeah, if there is no separate slot, then EE cert slot is the most
logical.

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.

However, with client_certificate_type, one has to be careful, since
server support also matters. So presumably one would have server
send a list of supported formats.


-Ilari

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Proposed Change to Certificate message (#654)

[Martin Thomson]

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 looked at.

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Proposed Change to Certificate message (#654)

[Sean Turner]

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 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 extension messages that are 
> certificate-specific (rather than connection-specific). This change also 
> resolves the anomaly of OCSP messages appearing before certificates in the 
> handshake.
> 
> Reasoning: 
> I've come to the conclusion that the current mechanism in TLS 1.3 for OCSP 
> and SCT is lacking forsight. OCSP and SCT are per-certificate metadata, not 
> per-connection metadata. By putting these responses in the 
> EncryptedExtensions, you limit these extensions to being shown once per 
> connection. This restricts future protocol extensions from using multiple 
> Certificate messages to support multiple certificates on the same connection. 
> An example of this is the post-handshake authentication proposal 
> (https://tools.ietf.org/html/draft-sullivan-tls-post-handshake-auth-00), 
> which currently requires a modified post-handshake Certificate message. This 
> proposed change would simplify the post-handshake auth proposal significantly 
> and generally make more sense as more certificate-specific extensions are 
> created.
> 
> Nick
> ___
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Proposed Change to Certificate message (#654)

[Ilari Liusvaara]

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 extension block of the first certificate (except that
> > might cause somewhat of a cyclic dependency in parsing)?
> 
> The type of which certificate?  The end-entity?  Seems like that
> belongs with the end-entity cert then.

I mean equivalent of the client_certificate_type/server_certificate_type
extensions.

And the way those extensions are defined, those scope the entiere chain.

E.g. There was some discussion about "subcerts"[1]. One way to add those
would be as a new certificate type.

... Or are new certificate types like new CLASSes in DNS: Heavy objects
dropped by bad idea fairy? :->


But in the future, there might very well be new extensions that are
scoped to certificate chain and not and individual certificate. And
those can't be put into EncryptedExtensions if server can send multiple
certificates (like it can in post-handshake auth extension) or if
client needs to send one.


[1] The usecases can't be practically accomplished today: The mode of
operation is just plain alien to X.509.


-Ilari

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Proposed Change to Certificate message (#654)

[Ilari Liusvaara]

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 certificate. Where do extensions like that
go? Always to the extension block of the first certificate (except that
might cause somewhat of a cyclic dependency in parsing)?

And then there is the user_mapping. I presume mechanism like this is to
be used to transport it (avoiding need to mess with new handshake
messages and such.
 
> 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.

Well, more like I was annoyed at having to implement that at all and the
fact that it requires remembering a hash state (which may be a quite
harsh requirement in some cases).


-Ilari

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Proposed Change to Certificate message (#654)

[Nick Sullivan]

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 responses are relatively long-lived and the
server should know whether or not a cached OCSP is close to expiration, so
cached_info is still useful, but I agree that this makes it less useful.


On Fri, Sep 23, 2016 at 2:53 PM Victor Vasiliev  wrote:

> The version where each certificate gets its own extension sounds like a
> step in the right direction.
>
> One concern I have is the way this would interact with cached_info
> extension.  Currently, it allows the entire Certificate message to be
> cached -- which just meant the entire chain in 1.2.  With the suggested
> change, this makes less sense: while you still want to cache SCTs, this
> might be much less desirable for OCSP responses.
>
> On Fri, Sep 23, 2016 at 3:49 PM, Eric Rescorla  wrote:
>
>> This seems like a reasonable direction.
>>
>> -Ekr
>>
>>
>> On Thu, Sep 22, 2016 at 7:26 PM, Nick Sullivan <
>> nicholas.sulli...@gmail.com> 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
>>> grouping much more explicit and obviates the need for OCSPv2. I'd
>>> definitely consider a modification like this.
>>>
>>> Nick
>>>
>>> On Thu, Sep 22, 2016 at 7:17 PM Brian Smith 
>>> wrote:
>>>
 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
> change also resolves the anomaly of OCSP messages appearing before
> certificates in the handshake.
>

 There are two ways that such a thing could be done. How your proposal
 suggests:

 opaque ASN1Cert<1..2^24-1>;
 struct {
 opaque certificate_request_context<0..2^8-1>;
 ASN1Cert certificate_list<0..2^24-1>;
 Extension extensions<0..2^16-1>;
 } Certificate;

 or:

 opaque ASN1CertData<1..2^24-1>;
 struct {
 ASN1CertData cert_data;
 Extension extensions<0..2^16-1>;
 }

 struct {
 opaque certificate_request_context<0..2^8-1>;
 ASN1Cert certificate_list<0..2^24-1>;
 } Certificate;

 I think you are right that the SCT and the OCSP response are
 per-certificate. In particular, they are not per-certificate-chain, so to
 me the latter form, where each certificate in the chain gets its own
 extension list, makes more sense to me. Would you consider changing the
 proposal to the second form?

 Cheers,
 Brian
 --
 https://briansmith.org/


>>> ___
>>> TLS mailing list
>>> TLS@ietf.org
>>> https://www.ietf.org/mailman/listinfo/tls
>>>
>>>
>>
>> ___
>> TLS mailing list
>> TLS@ietf.org
>> https://www.ietf.org/mailman/listinfo/tls
>>
>>
>
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Proposed Change to Certificate message (#654)

[Eric Rescorla]

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
> grouping much more explicit and obviates the need for OCSPv2. I'd
> definitely consider a modification like this.
>
> Nick
>
> On Thu, Sep 22, 2016 at 7:17 PM Brian Smith  wrote:
>
>> 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
>>> change also resolves the anomaly of OCSP messages appearing before
>>> certificates in the handshake.
>>>
>>
>> There are two ways that such a thing could be done. How your proposal
>> suggests:
>>
>> opaque ASN1Cert<1..2^24-1>;
>> struct {
>> opaque certificate_request_context<0..2^8-1>;
>> ASN1Cert certificate_list<0..2^24-1>;
>> Extension extensions<0..2^16-1>;
>> } Certificate;
>>
>> or:
>>
>> opaque ASN1CertData<1..2^24-1>;
>> struct {
>> ASN1CertData cert_data;
>> Extension extensions<0..2^16-1>;
>> }
>>
>> struct {
>> opaque certificate_request_context<0..2^8-1>;
>> ASN1Cert certificate_list<0..2^24-1>;
>> } Certificate;
>>
>> I think you are right that the SCT and the OCSP response are
>> per-certificate. In particular, they are not per-certificate-chain, so to
>> me the latter form, where each certificate in the chain gets its own
>> extension list, makes more sense to me. Would you consider changing the
>> proposal to the second form?
>>
>> Cheers,
>> Brian
>> --
>> https://briansmith.org/
>>
>>
> ___
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>
>
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Proposed Change to Certificate message (#654)

[Ilari Liusvaara]

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 Certificate message. With this
> change, the Certificate message can now hold all extension messages that
> are certificate-specific (rather than connection-specific). This change
> also resolves the anomaly of OCSP messages appearing before certificates in
> the handshake.
> 
> Reasoning:
> I've come to the conclusion that the current mechanism in TLS 1.3 for OCSP
> and SCT is lacking forsight. OCSP and SCT are per-certificate metadata, not
> per-connection metadata. By putting these responses in the
> EncryptedExtensions, you limit these extensions to being shown once per
> connection. This restricts future protocol extensions from using multiple
> Certificate messages to support multiple certificates on the same
> connection. An example of this is the post-handshake authentication
> proposal (
> https://tools.ietf.org/html/draft-sullivan-tls-post-handshake-auth-00),
> which currently requires a modified post-handshake Certificate message.
> This proposed change would simplify the post-handshake auth proposal
> significantly and generally make more sense as more certificate-specific
> extensions are created.

Also, this would presumably solve the user_mapping problem without
introducing a new handshake message. Basically, there is extension
user_mapping, that wants to send some certificate-associated auxillary
data from client to server. Currnently, there is no place to put such
data.

And yeah, with post-handshake auth, it looks like one would want a lot
more flexibility than currently exists.


BTW: I would rather dump the current post-handshake auth for such
extension proposal. The current post-handshake authentication is just
plain annoying to implement in contexts where the client has no
intention of ever supporting it.

And the current post-handshake auth mechanism seems to be insufficient
for real-world uses too...

I recently got an idea of implementing freezing session state into
octet stream and being able to thaw such. I quickly discovered I
can't implement that without either having freezable hashes (which I
don't have available) or just saying screw it with post-handshake auth
and never responding to the requests, even to reject them.



-Ilari

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Proposed Change to Certificate message (#654)

[Nick Sullivan]

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
On Thu, Sep 22, 2016 at 7:17 PM Brian Smith  wrote:

> 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
>> change also resolves the anomaly of OCSP messages appearing before
>> certificates in the handshake.
>>
>
> There are two ways that such a thing could be done. How your proposal
> suggests:
>
> opaque ASN1Cert<1..2^24-1>;
> struct {
> opaque certificate_request_context<0..2^8-1>;
> ASN1Cert certificate_list<0..2^24-1>;
> Extension extensions<0..2^16-1>;
> } Certificate;
>
> or:
>
> opaque ASN1CertData<1..2^24-1>;
> struct {
> ASN1CertData cert_data;
> Extension extensions<0..2^16-1>;
> }
>
> struct {
> opaque certificate_request_context<0..2^8-1>;
> ASN1Cert certificate_list<0..2^24-1>;
> } Certificate;
>
> I think you are right that the SCT and the OCSP response are
> per-certificate. In particular, they are not per-certificate-chain, so to
> me the latter form, where each certificate in the chain gets its own
> extension list, makes more sense to me. Would you consider changing the
> proposal to the second form?
>
> Cheers,
> Brian
> --
> https://briansmith.org/
>
>
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Proposed Change to Certificate message (#654)

[Brian Smith]

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 change
> also resolves the anomaly of OCSP messages appearing before certificates in
> the handshake.
>

There are two ways that such a thing could be done. How your proposal
suggests:

opaque ASN1Cert<1..2^24-1>;
struct {
opaque certificate_request_context<0..2^8-1>;
ASN1Cert certificate_list<0..2^24-1>;
Extension extensions<0..2^16-1>;
} Certificate;

or:

opaque ASN1CertData<1..2^24-1>;
struct {
ASN1CertData cert_data;
Extension extensions<0..2^16-1>;
}

struct {
opaque certificate_request_context<0..2^8-1>;
ASN1Cert certificate_list<0..2^24-1>;
} Certificate;

I think you are right that the SCT and the OCSP response are
per-certificate. In particular, they are not per-certificate-chain, so to
me the latter form, where each certificate in the chain gets its own
extension list, makes more sense to me. Would you consider changing the
proposal to the second form?

Cheers,
Brian
-- 
https://briansmith.org/
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

[TLS] Proposed Change to Certificate message (#654)

[Nick Sullivan]

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 extension messages that
are certificate-specific (rather than connection-specific). This change
also resolves the anomaly of OCSP messages appearing before certificates in
the handshake.

Reasoning:
I've come to the conclusion that the current mechanism in TLS 1.3 for OCSP
and SCT is lacking forsight. OCSP and SCT are per-certificate metadata, not
per-connection metadata. By putting these responses in the
EncryptedExtensions, you limit these extensions to being shown once per
connection. This restricts future protocol extensions from using multiple
Certificate messages to support multiple certificates on the same
connection. An example of this is the post-handshake authentication
proposal (
https://tools.ietf.org/html/draft-sullivan-tls-post-handshake-auth-00),
which currently requires a modified post-handshake Certificate message.
This proposed change would simplify the post-handshake auth proposal
significantly and generally make more sense as more certificate-specific
extensions are created.

Nick
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls