Re: [TLS] Regulations for EKU validation for CA certificates in the certificate chain

[Carl Wallace]

On 1/28/23, 8:10 AM, "TLS on behalf of Ilari Liusvaara" mailto:tls-boun...@ietf.org> on behalf of ilariliusva...@welho.com 
> wrote:


On Sat, Jan 28, 2023 at 11:57:46AM +0200, Oleg Pekar wrote:


> Example: if the client sends a chain Root->CA1->CA2->End-Entity, then the
> End-Entity certificate, if EKU is present in it, must include
> EKU=clientAuth. But Root, CA1, CA2 can have EKU=serverAuth (and don't
> include EKU=clientAuth at all). Such a chain would be considered valid from
> the RFC perspective, nevertheless it is counter-intuitive. Due to this
> potential gap some implementations (including OpenSSL) apply the same
> validation rules for client end-entity certificate to client's chain CA
> certificates and this creates incompatibility between implementations.
> 
> * Am I missing a standard that explicitly regulates EKU for CA certificates
> in the party's chain?


The standard interpretation in WebPKI is that EKU of CA certificates
does matter, and I guess this has spilled over to a number of non-Web
TLS implementations.

[CW] A short RFC that describes WebPKI EKU processing rules along with a new 
flag for the path validation algorithm that signifies WebPKI EKU processing is 
in effect may help clarify the situation. Implementations that use WebPKI EKU 
rules would claim conformance to the new RFC, which would be a superset of 5280.


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

Re: [TLS] Regulations for EKU validation for CA certificates in the certificate chain

[Carl Wallace]

 

 

From: Oleg Pekar 
Date: Saturday, January 28, 2023 at 10:03 AM
To: Carl Wallace 
Cc: Ilari Liusvaara , 
Subject: Re: [TLS] Regulations for EKU validation for CA certificates in the 
certificate chain

 

Great, I will prepare the initial draft then. Are there any informal documents 
where WebPKI rules are captured? 

 

>a new flag for the path validation algorithm that signifies WebPKI EKU 
>processing is in effect

Do you mean a flag that one party presents to the other party as an indication 
that it expects from the other party the following: all other party's CA 
certificates in the chain must have the relevant EKU purpose?

 

[CW] No. I meant a flag like the inputs in section 6.1.1 of RFC5280. The flag 
would instruct a path validation implementation when the WebPKI EKU processing 
rules are to be used. The flag would not manifest itself on the wire. I’d 
define the flag as defaulting to false (for backwards compatibility) while 
recognizing that implementations can hardcode the flag to true as desired. This 
would more or less match the status quo but give a stable reference for the 
practice. 

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

Re: [TLS] Regulations for EKU validation for CA certificates in the certificate chain

[Carl Wallace]

Good reference. That shows modifying initialization steps and using new 
variables. RFC5937 has an example of a new input flag. Between those two the 
basic skeleton is there. The effort just needs to make sure status quo is 
captured. 

> On Jan 31, 2023, at 9:34 AM, Corey Bonnell  wrote:
> 
> 
> Hello,
> Unfortunately, I don’t think that the CABF BRs or other CABF documents will 
> provide much insight here; they mainly just say that CAs MUST include EKUs in 
> CA certificates. Instead, I’d recommend starting with reading this discussion 
> on m.d.s.p., which prompted the “EKU chaining” rules that we know today: 
> https://groups.google.com/g/mozilla.dev.security.policy/c/0jnELviAxxo/m/VF1564nFcgwJ.
>  
> As for some inspiration on how to write the path validation procedure, I 
> recommend taking a look at Russ Housley’s (expired) I-D on the EKU 
> Constraints extension: 
> https://datatracker.ietf.org/doc/html/draft-housley-spasm-eku-constraints-01. 
> This extension was not standardized, but the way that Russ presents the 
> algorithm could likely be reused for this draft.
>  
> Thanks,
> Corey
>  
> From: TLS  On Behalf Of Salz, Rich
> Sent: Saturday, January 28, 2023 10:57 AM
> To: Oleg Pekar ; Carl Wallace 
> 
> Cc: TLS@ietf.org
> Subject: Re: [TLS] Regulations for EKU validation for CA certificates in the 
> certificate chain
>  
> Great, I will prepare the initial draft then. Are there any informal 
> documents where WebPKI rules are captured? 
>  
> I would start by looking at the CA/Browser forum documents.


smime.p7s
Description: S/MIME cryptographic signature
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Fwd: New Version Notification for draft-davidben-tls-trust-expr-00.txt

[Carl Wallace]

A few comments and nits are below but I have one high level question. Why limit 
the manifest produced by root programs to trust anchors? Root programs could 
produce a structure that represents CA certificates and all possible partial 
paths that can be validated by a trust store as well. This would remove the 
need for CAs or subscribers (or anyone who used the root program) to do path 
building. Root program users could look up paths that end with the issuer of a 
given certificate then validate using the corresponding trust store. This 
approach may remove the need for CAs to take any action relative to this 
mechanism and should require fewer moving parts to move in concert. The 
signaling mechanism seems like something that is long overdue, and I don't 
think would need to change if the manifest were augmented. Though, if CA certs 
were included in the manifest, indices could be returned instead of CA certs to 
represent the path, which may be useful in the PQ scenario.

 

Questions/Comments

In section 4, the ability to drop old versions seems like a need-to-have over 
time. If preserving indexing is the concern, maybe define the versions field as 
featuring an array of trust-store-version or null. 

 

In section 4, why include entire TAs in the manifest instead of a reference 
(i.e., hash)? Including the TAs may promote misuse. If TAs are necessary, CBOR 
may be a better choice given the bulk of the contents are binary data. 

 

In section 4.1, the sum may exceed the lifetime of the trust anchor. For 
example, if a trust anchor is five years from decommissioning when expiration 
is calculated but its max_lifetime per current definition is six years. Should 
max_lifetime be the number of seconds of the maximum lifetime of subscriber 
certificates issued by subordinate/leaf CAs?

 

In section 4.2, why not use indices to identify each trust anchor and limit the 
usage of labels to the optional grouping of TAs? This may help eliminate 
possible mistakes when a relying party prepares an exclusion list, i.e., by 
referencing a group when an individual TA was intended. Does "repurpose" 
include adding or removing a trust anchor from a label or can label members 
vary freely across versions?

 

In section 5, it's not clear to me that exclusively tasking CAs with preparing 
CertificatePropertyLists is desirable. If a CA is not aware of a root program a 
subscriber needs to support, the subscriber could prepare the structure 
directly (possibly by augmenting a structure provided by the CA as a hint). 
Paths with more than one intermediate CA may complicate preparation for CAs as 
well.

 

In section 6.5, the second and third paragraphs (and security considerations) 
suggest the root program prepares trust expressions but the next to last 
paragraph suggests software versions influence trust expression contents. 
Requiring root programs to be aware of software versions seems like a stretch. 
Trust expressions seem inherently local, i.e., to capture trust anchors a 
relying party has explicitly disabled. There is also potential for a relying 
party to utilize trust anchors from more than one root program, which would 
require relying party to do final preparation. Re: the "should get moved to the 
manifest" note, why is the ability to omit a TA from the entries list not 
sufficient for this?

 

Nits

In 2.2, a trust anchor typically also has a name in addition to a key.

 

In last bullet of section 3, ‘all’ seems like an either an overstatement or a 
tautology. Maybe "...assured that relying parties with compatible trust stores 
will be satisfied..." or just delete.

 

In section 4, the "expected to issue" in the max_lifetime definition should be 
"expected to validate". It probably means "subscriber certificates" instead of 
"certification paths", as well.

 

Section 4.1 "all unexpired certificates" should probably be "all unexpired 
subscriber certificates."

 

In the last paragraph of 4.2, the "MAY repurpose...after" should be "MUST NOT 
repurpose...before" relative to expiration of all references. If label reuse is 
the primary motivation for expiration, is expiration worth the complexity?

 

In section 5, the entry sorting language should indicate ascending or 
descending.

 

In 6.2, it may be worth adding "and MUST use one of the trust anchor stores 
indicated in the trust_expressions extension to validate the result."

 

Section 6.5 should define "desired subset." It should also relate "trust store 
version" and "specified version" in steps 2 and 3 to the actual trust store 
that a relying party is using. It seems a bit odd not to factor in comparison 
of manifest contents against the trust store used for path validation when 
preparing the excluded_labels list.

 

As noted above, the last sentence of the security considerations section 
doesn't seem necessary.

 

In Appendix A, the type field may be better as a group socket than text. Do you 
intend to make Appendix A normative at some 

Re: [TLS] Breaking into TLS for enterprise "visibility" (don't do it)

[Carl Wallace]

From:  TLS  on behalf of Tony Arcieri

Date:  Saturday, March 24, 2018 at 11:31 AM
Subject:  Re: [TLS] Breaking into TLS for enterprise "visibility" (don't do
it)

> On Fri, Mar 23, 2018 at 11:26 PM, Alex C  wrote:
>> As I understand it (poorly!) the idea is exactly to have a single system on
>> the network that monitors all traffic in cleartext.
> 
> And more specifically: to be able to *passively* intercept traffic and allow
> it to be decrypted by a central system. "Visibility" with an active MitM is a
> solved problem: have the MitM appliance double as an on-the-fly CA and install
> its root certificate in the trust stores of all the clients you intend to
> MitM.

It's not a solved problem for mutual authentication scenarios even if you
drop the passive requirement (as should be done in such cases anyway).



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

[TLS]Re: [EXTERNAL] Re: WG Adoption for TLS Trust Expressions

[Carl Wallace]

 

 

From: Joseph Salowey 
Date: Wednesday, May 22, 2024 at 5:04 PM
To: "tls@ietf.org" 
Subject: [TLS]Re: [EXTERNAL] Re: WG Adoption for TLS Trust Expressions

 

Thanks to the working group for all the discussion on this document. We will 
kick off an official adoption call soon. While this work is clearly applicable 
to TLS, the topic of trust stores is broader. 

 

[CW] Path building is broader too. 

 

The working group should be aware that if the document is adopted as a working 
group item, It's possible that work will be identified that would be better 
addressed in other forums. It is also possible that this situation will not 
arise and all the work will be completed in TLS. 

 

On Wed, May 22, 2024 at 8:45 AM Andrei Popov 
 wrote:

While a TLS extension could be used to identify which 
approaches/algorithms/protocols the client supports, the server also needs to 
know which of its certificate chains the client trusts.
To me, these are two separate issues: 
Selecting a certificate chain based on the client’s signature suite support and 
Selecting a certificate chain the client trusts.
 

#1 is already solved: we have signature_algorithms_cert and 
signature_algorithms extensions. Some TLS implementations have support for 
deploying multiple cert chains per endpoint and selecting the appropriate cert 
chain based on peer-supported signature suites. This should work fine for PQC, 
once we define PQC and hybrid SignatureScheme code points.

 

#2 has an existing solution as well (certificate_authorities extension), but in 
practice it’s not efficient and in some cases not secure. This is where we need 
improvement and Trust Expressions appears to be an option, although we will 
likely want to change the details of the design a bit and make it better.

 

Cheers,

 

Andrei

 

From: Nick Harper  
Sent: Tuesday, May 21, 2024 11:29 PM
To: Dennis Jackson 
Cc: tls@ietf.org
Subject: [EXTERNAL] [TLS]Re: WG Adoption for TLS Trust Expressions

 

You don't often get email from i...@nharper.org. Learn why this is important
On Tue, May 21, 2024 at 3:00 PM Dennis Jackson 
 wrote:

This thread is now 40+ messages deep and I guess you might have not seen much 
of the previous discussion. I actually agree with much of your analysis, but it 
focused on the wrong question, as I wrote earlier in this thread:

The question we're evaluating is NOT "If we were in a very unhappy world where 
governments controlled root certificates on client devices and used them for 
mass surveillance, does Trust Expressions make things worse?" Although Watson 
observed that the answer to this is at least 'somewhat', I agree such a world 
is already maxed at 10/10 on the bad worlds to live in scale and so it's not by 
itself a major problem in my view.

I don't see Watson saying that in any of his messages [5] [6] [7]. Message [7] 
does mention an intermediate cross-signed by a government CA, but my 
understanding of Watson's argument is that Trust Expressions doesn't do 
anything to enable that since the "chain" of certificates sent by a TLS server 
is really just a grab bag for the client to use when it does path building. 
Specifically, in today's world, a CA could send to ACME clients a leaf cert 
with intermediates and cross-signs so that the root of the path could be either 
that CA or a government CA, and when that server sends that bag of 
intermediates to a client to verify, the client will build one of those two 
paths, depending on what's in the client's trust store.


The actual concern is: to what extent do Trust Expressions increase the 
probability that we end up in this unhappy world of government CAs used for 
mass surveillance?

This is a good question to ask, and I see you attempted to address it in 
message [4]. You argue that Trust Expressions provides an "on-ramp" for 
deploying a government CA to reach a certain level of legitimacy or adoption. I 
don't see the connection between that and mass surveillance, nor do I see you 
make a claim that Trust Expressions does increase this probability. In [1] you 
describe this "on-ramp", which has step 1 being to ship support for trust 
negotiation (which could be more accurately described as a trust store 
advertisement mechanism), and step 2 as the following:

 

>  * A large country or federation pushes for recognition of their
>domestic trust regime as a distinct trust store which browsers must
>advertise. Browsers agree because the relevant market is too big to
>leave.

 

I see two ways this happens: The first is that the recognition of the domestic 
trust regime is done in a way that does not circumvent root store policy. By 
this, I mean that the CAs in this domestic trust regime must meet all audit and 
other policy requirements of the browser's root store, and a brower root store 
can remove trust in a CA from that set if it violates the root store 
requirements (in the same way that root stores currently operate to distrust a 
CA when it is no lon