Re: [FORGED] Re: Germany's cyber-security agency [BSI] recommends Firefox as most secure browser

2019-10-20 Thread Daniel Marschall via dev-security-policy
I think the only really important purpose of OV and EV over DV is that they are 
visible on the first sight. Nobody opens the X.509 file to look at the EKU OIDs 
or the subject DN. The requirement could just say that x.509 must be supported, 
but they do differentiale DV, OV and EV.
dev-security-policy mailing list

Re: An honest viewpoint: Move Extended Validation Information out of the URL bar

2019-09-08 Thread Daniel Marschall via dev-security-policy
> Okay... we know that people might now know what "TO" or "AX" means...

Typo: I meant "people might not know"
dev-security-policy mailing list

Re: Intent to Ship: Move Extended Validation Information out of the URL bar

2019-08-23 Thread Daniel Marschall via dev-security-policy
Am Freitag, 23. August 2019 00:50:35 UTC+2 schrieb Ronald Crane:
> On 8/22/2019 1:43 PM, kirkhalloregon--- via dev-security-policy wrote:
> Whatever the merits of EV (and perhaps there are some -- I'm not 
> convinced either way) this data is negligible evidence of them. A DV 
> cert is sufficient for phishing, so there's no reason for a phisher to 
> obtain an EV cert, hence very few phishing sites use them, hence EV 
> sites are (at present) mostly not phishing sites.

Can you proove that your assumption "very few phishing sites use EV (only) 
because DV is sufficient" is correct? I do think the truth is "very few 
phishing sites use EV, because EV is hard to get".

I do not think EV certificates are easy to get. The black market stories are 
probably more about code signing certificates, I guess. And even if you would 
find an EV SSL certificate on the black market, then it would be revoked as 
soon as it is used, and that organization will never get an EV certificate 
again. So the harm that black market certificates (if there are any at all...) 
is very small!
dev-security-policy mailing list

Re: CA handling of contact information when reporting problems

2019-08-20 Thread Daniel Marschall via dev-security-policy

I am a bit shocked about this case.

The fact that this happened to someone would restrain myself from reporting key 

Even though it is the company's fault to protect their private key, their 
lawers still might sue the incident-reporter. A judge might not understand the 
PKI system and therefore might tend to decide in favor of the company, because 
the company can proove that they lost XXX dollars revenue because of the 
service outtage. I think big companies have a lot of expensive lawers who might 
win such a case against a private person who might not even have the money for 
a good lawer at all.

In re privacy: Telling someone the name and/or email address of a person 
without their consent is a clear violation of the GDPR (European General Data 
Protection Regulation), in case European law applies. Publishing the name 
and/or email address online (e.g. in the incident template) is even worse.

Take care,

Am Montag, 19. August 2019 16:26:06 UTC+2 schrieb Mathew Hodson:
> Tom Wassenberg on Twitter reported an experience he had with Sectigo
> when reporting a compromised private key.
> "So a few weeks ago, I came across a private key used for a TLS
> certificate, posted online. These should never be public (hence the
> "private"), and every trusted CA is obliged to revoke any certificate
> they issued when they become aware its private key is compromised.
> "So when I informed the issuing CA (@SectigoHQ) about this, they
> promptly revoked the cert. Two weeks later however, I receive an angry
> email from the company using the cert (cc'd to their lawyer), blaming
> me for a disruption in the services they provide.
> "The company explicitly mentioned @SectigoHQ "was so kind" to give
> them my contact info! It was a complete surprise for me that
> @SectigoHQ would do this without my consent. Especially seeing how the
> info was used to badger me."
> 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 BRs or Mozilla policy?

dev-security-policy mailing list

Re: Request to Include 4 Microsoft Root CAs

2019-08-19 Thread Daniel Marschall via dev-security-policy


Is there an EV Policy OID assigned? I can't find it.

- Daniel

Am Mittwoch, 14. August 2019 00:42:44 UTC+2 schrieb Wayne Thayer:
> This request is for inclusion of the Microsoft RSA Root Certificate
> Authority 2017, Microsoft ECC Root Certificate Authority 2017, Microsoft EV
> RSA Root Certificate Authority 2017, and Microsoft EV ECC Root Certificate
> Authority 2017 trust anchors as documented in the following bug:
> * BR Self Assessment is
> * Summary of Information Gathered and Verified:
> * Root Certificate Download URL:
> * CP/CPS:
> ** CP:
> ** CPS:
> * This request is to include the roots with the websites trust bit enabled,
> and with EV treatment.
> * Test Websites
> ** Valid:,
> ** Expired:,
> ** Revoked:,
> * CRL URLs:
> ** ECC:
> ** RSA:
> ** EV ECC:
> ** EV RSA:
> * Audit: Annual audits are performed by BDO according to the WebTrust for
> CA, BR, and EV audit criteria.
> ** WebTrust for CA:
> ** BR:
> ** EV:
> I’ve reviewed the CP, CPS, BR Self Assessment, and related information for
> inclusion of the Microsoft roots that are being tracked in this bug and
> have the following comments:
> ==Good==
> * A root key generation ceremony audit report has been provided [1].
> ==Meh==
> * CPS section 3.2.4 stated that OU is not verified, however, BR section
> does place requirements on this field, and the CPS made it
> unclear if these requirements are met. This was clarified in the latest
> version of the CPS.
> * CPS section 3.2.5 stated that Microsoft PKI Services shall verify
> authority for all certificate requests, and that for Domain Validated
> requests, this is done using one of the methods described in the BRs.
> Section 3.2.5 of the BRs only describes validation of authority for OV
> certificates using a reliable method of communication. This was clarified
> in the latest version of the CPS.
> * CPS section 6.1.5 indicated that P-512 keys may be used, which would
> violate Mozilla policy. This was corrected in the latest version of the CPS.
> * The content-type header in CRL responses is not set to
> 'application/pkix-crl' but to 'application/octet-stream' (RFC 5280, section
> Microsoft explanation: the reason for the content-type being set
> to octet-stream is that we use a content upload service at Microsoft that
> hosts different types of content. All of the content in the service is
> hosted in Azure’s BLOB storage and the content type by default is octet
> stream. This has not been an issue because the browsers will resolve the
> file type based on the extension in the file name. It should also be noted
> that the RFC 5280 shows SHOULD rather than MUST.
> ==Bad==
> * It had been more than a year since the CP was updated when I reviewed
> this request. CPS and BR section 2 require annual updates. The CP was
> updated on 5-August.
> * CP/CPS section 1.5.2 did not meet the BR 4.9.3 requirement to provide
> clear problem reporting instructions. This was corrected in the latest
> versions of the CP and CPS.
> * A number of unrevoked certificates chaining to the Microsoft RSA Root
> Certificate Authority 2017 have recently been issued with BR violations [2]
> This begins the 3-week comment period for this request [3].
> I will greatly appreciate your thoughtful and constructive feedback on the
> acceptance of these roots into the Mozilla CA program.
> - Wayne

Re: Fwd: Intent to Ship: Move Extended Validation Information out of the URL bar

2019-08-18 Thread Daniel Marschall via dev-security-policy
Am Sonntag, 18. August 2019 07:18:56 UTC+2 schrieb Matt Palmer:
> [...] From what I can see so far,
> browser vendors aren't "ending" EV certificates, a couple of them are merely
> modifying their UIs guided by relevant research into the efficacy (or lack
> thereof) of the current UI.
> - Matt

Matt, I don't understand this. Isn't removing the UI bling the same as 
"removing" EV from the browser? The UI difference is either so tiny or even 
not-existant, so I guess that EV will eventually ended by the Customers/CAs. I 
just looked at Opera and noticed that they don't have any UI difference at all, 
which means I have to open the X.509 certificate to see if it is EV or not.
dev-security-policy mailing list

Re: Intent to Ship: Move Extended Validation Information out of the URL bar

2019-08-16 Thread Daniel Marschall via dev-security-policy
I have a few more comments/annotations:

(1) Pro EV persons argue "Criminals have problems getting an EV certificate, so 
most of them are using only DV certificates".

Anti EV persons argue "Criminals just don't use EV certificates, because they 
know that end users don't look at the EV indicator anyway".

I assume, we do not know which of these two assumptions fits to the majority of 
criminals. So why should we make a decision (change of UI) based on such 

(2) I am a pro EV person, and I do not have any financial benefit from EV 
certificates. I do not own EV certificates, instead my own websites use Let's 
Encrypt DV certificates. But when I visit important pages like Google or 
PayPal, I do look at the EV indicator bar, because I know that these pages 
always have an EV certificate. If I would visit PayPal and only see a normal 
pad lock (DV), then I would instantly leave the page because I know that PayPal 
always has an EV certificate. So, at least for me, the UI change is very 
negative (except if you color the pad lock in a different color, that would be 
OK for me). We cannot say that all users don't care about the EV indicator. For 
some users like me, it is important.

(3) Also, I wanted to ask, if you want to remove the UI indicator, because you 
think that EV certificates give the feeling of false security, then please tell 
me: What is the alternative? Removing the UI bling without giving any 
alternative solution is just wrong in my opinion. Yes, there might be a tiny 
amount of phishing sites that use EV certificates, but the EV indicator bar is 
still better than just nothing. AntiPhishing filters are not a good alternative 
because they only protect when the harm is already done to some users.
dev-security-policy mailing list

Re: Intent to Ship: Move Extended Validation Information out of the URL bar

2019-08-15 Thread Daniel Marschall via dev-security-policy
Please tell me if I understand this correctly...
Is it that DV and EV certificates now both show the same lock symbol?
That would be a great harm in my opinion. And I do not understand why you want 
this change.

I think EV is very important and I explain why.

Let's look at following hypothetical case: We have, as 
well as and . Notice the two number 1 (one) instead of a 
lower case L in the latter two domains. (lowecase "L" and "one" look perfectly 
equal in Times New Roman. And lowercase "L" looks perfectly equal to uppercase 
"i" in Arial.)

In old Firefox, I get a green bar if I visit and, telling 
me that this is a well-known company that got the EV certificate.
The other fake domains and only have DV certificates by 
Let's Encrypt.

In the newer Firefox, both domains, the real one and the fake one both get a 
lock symbol. And I need to click the lock to see if it is DV or EV.

Do I understand that correctly?

And in regards to the comparison of Peter Bowen: If we assume that an 
improvement is that a fire sprinkler does react faster and more accurate, then 
why it is an improvement that old Firefox shows something, and the new Firefox 
does not show something? Is that an enhancement? No, it's removing something 
from the UI.

Am Montag, 12. August 2019 20:31:22 UTC+2 schrieb Wayne Thayer:
> Mozilla has announced that we plan to relocate the EV UI in Firefox 70,
> which is expected to be released on 22-October. Details below.
> If the before and after images are stripped from the email, you can view
> them here:
> Before:
> After:
> - Wayne
> -- Forwarded message -
> From: Johann Hofmann 
> Date: Mon, Aug 12, 2019 at 1:05 AM
> Subject: Intent to Ship: Move Extended Validation Information out of the
> URL bar
> To: Firefox Dev 
> Cc: dev-platform , Wayne Thayer <
> In desktop Firefox 70, we intend to remove Extended Validation (EV)
> indicators from the identity block (the left hand side of the URL bar which
> is used to display security / privacy information). We will add additional
> EV information to the identity panel instead, effectively reducing the
> exposure of EV information to users while keeping it easily accessible.
> Before:
> After:
> The effectiveness of EV has been called into question numerous times over
> the last few years, there are serious doubts whether users notice the
> absence of positive security indicators and proof of concepts have been 
> pitting
> EV against domains  for
> phishing.
> More recently, it has been shown  that EV
> certificates with colliding entity names can be generated by choosing a
> different jurisdiction. 18 months have passed since then and no changes
> that address this problem have been identified.
> The Chrome team recently removed EV indicators from the URL bar in Canary
> and announced their intent to ship this change in Chrome 77
> .
> Safari is also no longer showing the EV entity name instead of the domain
> name in their URL bar, distinguishing EV only by the green color. Edge is
> also no longer showing the EV entity name in their URL bar.
> On our side a pref for this
> (security.identityblock.show_extended_validation) was added in bug 1572389
>  (thanks :evilpie for
> working on it!). We're planning to flip this pref to false in bug 1572936
> .
> Please let us know if you have any questions or concerns,
> Wayne & Johann
dev-security-policy mailing list

Re: Fwd: Intent to Ship: Move Extended Validation Information out of the URL bar

2019-08-13 Thread Daniel Marschall via dev-security-policy
I share the opinion with Jakob, except with the CVE. Please remove this change. 
It is unnecessary and kills the EV market.
But if you insist on keeping that UI change, maybe you can at least give the 
lock symbol a different color if it is an EV cert?
dev-security-policy mailing list

RE: Reported Digicert key compromise but not revoked

2019-05-09 Thread Daniel Marschall via dev-security-policy
I personally do think that it matters to this forum. A CA - no matter what kind 
of certificates it issues - must take revocation requests seriously and act 
immediately, even if the email is sent to the wrong address. If an employee at 
the help desk is unable to forward revocation requests, or needs several weeks 
to reply, then there is something not correct with the CA, no matter if the 
revocation request is related to a web certificate or code signing certificate. 
That's my opinion on this case.
dev-security-policy mailing list

Re: Improvement suggestions for (Hyperlinking OIDs + TLS features decoding)

2019-05-03 Thread Daniel Marschall via dev-security-policy
Hello Ryan,

thank you for your reply! I actually saw the github link, but I was't sure in 
which repository I should open a ticket. As for the forum, I didn't knew it and 
I don't see a link at

I have posted an email there

Take care,
dev-security-policy mailing list

Improvement suggestions for (Hyperlinking OIDs + TLS features decoding)

2019-05-02 Thread Daniel Marschall via dev-security-policy

I have two improvement suggestions for the page

I often stumble across extentions or other kind of OIDs which are not 
known/named by the system. For example the extention

(1) It would be great if all OIDs could automatically get a hyperlink pointing 
to , e.g. , so you can quickly 
get information about an OID by clicking on it.

(2) About the OID in particular: Since I think this 
extention becomes more and more popular as OCSP MustStaple evolves, maybe it 
would be good to decode it, showing the TLS features in plaintext. For example, 
to see the list of features for a certificate, I need to
copy paste the hex dump (e.g. "30 03 02 01 05") into an ASN.1 decoder, e.g. , to get the list of extention IDs. (e.g. 5)
Then I need to lookup these extention IDs at the IANA registry
 (e.g. 5 = status_request).

What do you think?

Take care,
dev-security-policy mailing list