<div dir="auto">Hi Phillip, others,</div><div dir="auto"><br></div><div dir="auto">No plan to use passwords. I am not sure if I fully mentioned it, however, let’s say company a and b use certificate chains signed by CA c that allow web access, here a and b having TLS auth server, client extended key flags is correct, however, when the CA has the same extended key flags, if</div><div dir="auto"><br></div><div dir="auto">A. The Credentials SSO/password are leaked, note the use of a common vip application in a brokered access renders SSO unsafe.</div><div dir="auto"><br></div><div dir="auto">B. There are similar weak credentials.</div><div dir="auto"><br></div><div dir="auto">C. An internal attack or insider threat related leak.</div><div dir="auto"><br></div><div dir="auto"><br></div><div dir="auto">In the case of replacing a CA vendor, A rogue CA or a compromised CA with some form of credentials, there is substantial risk of access as the flags in the CA will allow the CA to make requests. In fact, tracing or auditing such attacks can be impossible.</div><div dir="auto"><br></div><div dir="auto">It is under this CA pretense that the EKU flags as required by NIAP NDcPP would be an attack, hence, my question. </div><div dir="auto"><br></div><div dir="auto">Hope this helps in the responses to my questions.</div><div dir="auto"><br></div><div dir="auto">Thx.,</div><div dir="auto">Tushar</div><div dir="auto"><br></div><div dir="auto"><br></div><div dir="auto"><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, Jul 9, 2021 at 7:12 PM Phillip Hallam-Baker <<a href="mailto:phill@hallambaker.com">phill@hallambaker.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div dir="ltr"><div class="gmail_default" style="font-size:small"><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, Jul 9, 2021 at 9:15 PM Tushar Patel <<a href="mailto:tjpatel.tl@gmail.com" target="_blank">tjpatel.tl@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr">For some time, the CA browser forum has been using CAs that have the extended key usage as "TLS Web Server Authentication, TLS Web Client".<div><br></div><div>However, I feel that this can lead to an attack, though CAs can be trusted, the authority for the CA should be the validation of the leaf certificate having the same flags. Yes, one could assume that the CA will safeguard the private key, however, there are cases in which duplicates could be generated and then used (at some later date).</div><div><br></div><div>In the case of SSO, this might be okay, however, in the case of passwords, it could be extremely risky.</div><div><br></div><div>What do you think?</div><div>a. Request a change to CA browser policy?</div><div>b. Will it be okay to support such CA certs?</div></div></blockquote><div><br></div><div><div class="gmail_default" style="font-size:small">If you are using passwords for security, the security of your CA is the least of your problems. </div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">I am not aware of there ever being significant differences in management of root keys for different purposes by any CA. VeriSign Class 1 keys used the same technology as Class 3.</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">A CA issued cert is merely an assertion that the key holder has been validated as holding the right to the specified subject name and attributes according to the policy and practices specified. </div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">Requirements of the form 'this type of certificate must not be used for X' are invariably junk. As long as the practices are sufficient to establish the subject identity for the specified purpose, there is no problem. </div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">CAs do have terms of use etc which may constrain use. But this notion of separate hierarchies for separate purposes and policing off-label uses outside the WebPKI is completely bogus.</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">There seems to be an anti-competitive agenda going on here. Certain companies should consult their anti-trust lawyers now rather than laying up yet more pain when the storm hits.</div><br></div><div><br></div><div><br></div><div> </div></div></div>
</blockquote></div></div>