Re: [TLS] Proposed Change to Certificate message (#654)
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)
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)
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)
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)
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/tlswg/tls13-spec/pull/654 The only issue that comes to mind is where extensions that are specific to the certificate chain instead to the certificate go. E.g. if a new kind of certificate chain[1] is ever implemented using client_certificate_type/server_certificate_type (or anything similar for that matter). [1] E.g. for allowing multisigning EE certificates (currently one can multisign CA certificates, but not EE ones). -Ilari ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Proposed Change to Certificate message (#654)
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)
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)
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. ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Proposed Change to Certificate message (#654)
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)
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)
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)
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)
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)
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