Hello
i just saw this in the news... a SHA-1 collision has been achieved.
https://arstechnica.com/security/2017/02/at-deaths-door-for-years-widely-used-sha1-function-is-now-dead/
proof site: https://shattered.io/
authors:
Marc Stevens (1), Elie Bursztein (2), Pierre Karpman (1), Ange
a small question:
what's going to happen with https://www.freessl.com/ ?
under Symantec's leadership it was intended for the site to become a free
alternative to StartCom and LetsEncrypt, but it was not quite opened for
issuance except for non-profits.
Now with the transition of the CA
Pedro Fuentes wrote:
> Just to say that looking at this from Europe, I don't see this feasible.
>
> Citizens getting their personal eIDAS-compliant certificate go through
> face-to-face validation and will give virtually any valid e-mail address to
> appear in their certificate.
>
Then that
Hello,
this question is somewhat outside the current Baseline Requirements, but...
wouldn't it be normal for the same CAA rules for server certificates to also
apply to client certificates when the email address is for a domain that
already has a valid CAA policy published in DNS?
RFC 6844
1) get a virtual machine
2) install windows, install the Blizzard BattleNet client.
3) create a BattleNet account with any email address - it's free,
subscription/payment is not required for this.
4) login in the BattleNet app client with the account from step 3.
5) after the main BattleNet
since it's a webserver running on the local machine and is using that
certificate key/pair, i think that someone more capable than me can easily
extract the key from it.
>From my point of view as an observer it's plainly obvious that the private key
>must be on my local machine too, even if i
those cases can be easily ruled out like this:
1) after authentication in the BattleNet app and the app starts properly,
disconnect the device from any network.
In my case i physically unplugged the ethernet cable from the PC, and it has
no other connection available, not even wireless.
2)
> Bug Blizzard:
> https://bugzilla.mozilla.org/show_bug.cgi?id=1425166
> Cert Blizzard:
> https://crt.sh/?id=26142
>
Blizzard went to DigiCert and got another certificate instead:
on any computer with BattleNet installed and active go to this url:
https://127.0.0.1:22886/
and currently it
p.s.
1) i posted here because i don't even have access to viewing the Blizzard bug
on Bugzilla, even if i'm logged in with a Bugzilla account I get the message "
You are not authorized to access bug 1425166. "
2) i also sent the same message to the certificate problem-reporting address
OR82PbAnjipHzg0KXZWZdbRh3IliYgoH31ygkuVKLd3HrmsDIXYe+zN/nWLA6tw0
O9NKI7THpe62be+Anarbvj9x3/78+rojqMl/oXpiNEKl/lOYuFKomtt+sA7NxNL0
kg==
-END CERTIFICATE-
On Monday, 25 December 2017 12:17:36 UTC+2, Hanno Böck wrote:
> On Sun, 24 Dec 2017 23:07:56 -0800 (PST)
> "Adrian R. via dev-security-policy"
> &
Side question: why wasn't the certificate from DigiCert logged into Certificate
Transparency logs when it was issued and it had to be discovered this way?
On Monday, 25 December 2017 12:42:05 UTC+2, Hanno Böck wrote:
> Thanks, I also got it in the meantime and submitted it to CT:
>
+1
imho that would be the best idea, and the local/non-local check should happen
inside the same PKI-validation logic flow that is used for certificate
validation.
If the url resource resolves to local IP addresses then only reserved names
from
P.S. i assumed only a TLS context, but the same rule should probably apply for
any connection, whether plaintext or SSL/TLS:
> If the url resource resolves to local IP addresses then only reserved names
> from
> https://cabforum.org/wp-content/uploads/Guidance-Deprecated-Internal-Names.pdf
>
Matthew Hardeman wrote:
> 6. Thus, the direction this goes is that the developer creates a self-signed
> cert and imports it into the trust store. The developer may do this on the
> software host, but historically is more likely to just create one and package
> it just like they did with the
Then we go back to: what's the point of becoming a globally-recognized CA if
you are not allowed by law to recognize as legal the English language version?
Some user from the other part of the world might not know YOUR local language,
but they are more likely to know English.
A local country
On Tuesday, 3 April 2018 20:19:40 UTC+3, Ryan Hurst wrote:
>
> Reading this thread and thinking the current text, based on the
> interpretation discussed, does not accommodate a few cases that I think are
> useful.
>
> For example, if we consider a CA supporting a large mail provider in
>
On Thursday, 5 April 2018 03:08:44 UTC+3, Wayne Thayer wrote:
[...]
> If a CA first confirms that it is a condition of a
> particular federated authentication system that a user must have proven
> control over the email account that constitutes their username to activate
> their account, then
Hello
can you please sign the PDF files on that site?
the very first page of CPS_eidas_EN_v_1_2_3.pdf says
"Document valid only in digital format digitally signed by the Policy Authority"
but the PDF that i was offered to download is not signed and was delivered via
a plain http link, are those
Hello
Today, as part of an "upgrade" to version 19.5 Avast Antivirus has forcefully
enabled the entire Microsoft PKI for all Firefox users that also happen to be
users of Avast [Free] Antivirus.
They now forcefully set this Mozilla enterprise policy for all users of Avast:
Wayne Thayer wrote:
>
>
> That is not my understanding of how this setting works: it only imports
> roots that have been added to the Windows root store, e.g. by a program
> such as Avast, or an administrator. It does not import roots Microsoft
> ships with Windows.
>
The problem is that if a
On Monday, 19 August 2019 17:26:06 UTC+3, Mathew Hodson wrote:
[...]
> If these situations were common, it could create a chilling effect on
> problem reporting that would hurt the WebPKI ecosystem. Are specific
> procedures and handling of contact information in these situations
> covered by the
21 matches
Mail list logo
