Dear Dev.Sec.Policy,
Following you can find our report about the problem reported about the Bug
1462423.
1. How your CA first became aware of the problem (e.g. via a problem report
submitted to your Problem Reporting Mechanism, a discussion in
mozilla.dev.security.policy, a Bugzilla
A few of us have been discussing the usareally.com "issue" recently. In
case you didn't know, the US Treasure put out a notice that US companies
must not do business with USA Really:
https://home.treasury.gov/news/press-releases/sm577
Let's Encrypt mapped that release to
I don't think it's reasonable to push the problem to your CA software
vendor.
If Verizon does not provide this support, what steps will your CA take? If
you know what those steps are, is there reason not to take them now? If you
do not know what those steps are, when will you know?
Your software
Jakob Bohm via dev-security-policy
writes:
>On 11/01/2019 13:04, Peter Gutmann wrote:
>> Jason via dev-security-policy writes:
>>
>>> I would say that the problem here would be that a child certificate can't
>>> use
>>> a higher cryptography level than the issuer
>>
>>Why not? If the
On 11/01/2019 13:04, Peter Gutmann wrote:
> Jason via dev-security-policy writes:
>
>> I would say that the problem here would be that a child certificate can't use
>> a higher cryptography level than the issuer
>
> Why not? If the issuer uses strong-enough crypto, what difference does it
>
Jason via dev-security-policy writes:
>I would say that the problem here would be that a child certificate can't use
>a higher cryptography level than the issuer
Why not? If the issuer uses strong-enough crypto, what difference does it
make what the child uses?
Peter.
Hello Wayne,
Thank you for your email.
I think it is still the same incident. In my opinion there is no need to create
another thread. Let me explain how it happened.
As I said in previous emails we have requested urgent need for pre-linting
feature from Verizon just after the incident was
7 matches
Mail list logo
