[Cryptography] Request for a second opinion

Tushar Patel tjpatel.tl at gmail.com
Fri Jul 9 22:59:49 EDT 2021


Hi Phillip, others,

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

A. The Credentials SSO/password are leaked, note the use of a common vip
application in a brokered access renders SSO unsafe.

B. There are similar weak credentials.

C. An internal attack or insider threat related leak.


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.

It is under this CA pretense that the EKU flags as required by NIAP NDcPP
would be an attack, hence, my question.

Hope this helps in the responses to my questions.

Thx.,
Tushar


On Fri, Jul 9, 2021 at 7:12 PM Phillip Hallam-Baker <phill at hallambaker.com>
wrote:

>
>
> On Fri, Jul 9, 2021 at 9:15 PM Tushar Patel <tjpatel.tl at gmail.com> wrote:
>
>> 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".
>>
>> 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).
>>
>> In the case of SSO, this might be okay, however, in the case of
>> passwords, it could be extremely risky.
>>
>> What do you think?
>> a. Request a change to CA browser policy?
>> b. Will it be okay to support such CA certs?
>>
>
> If you are using passwords for security, the security of your CA is the
> least of your problems.
>
> 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.
>
> 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.
>
> 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.
>
> 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.
>
> 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.
>
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://www.metzdowd.com/pipermail/cryptography/attachments/20210709/8e0396dd/attachment.htm>


More information about the cryptography mailing list