Re: Intermediates Supporting Many EE Certs

Jakob Bohm via dev-security-policy writes: >Unfortunately, for these not-quite-web-server things (printers, routers >etc.), automating use of the current ACME Let's encrypt protocol with or >without hardcoding the Let's Encrypt URL is a non-starter for

Re: Taiwan GRCA Root Renewal Request

Gervase Markham via dev-security-policy writes: >Peter: you are going to have to re-summarise your question. And then, if you >are asking why Mozilla code works in a certain way, mozilla.dev.security or >mozilla.dev.tech.crypto are almost certainly far

Re: Researcher Says API Flaw Exposed Symantec Certificates, Including Private Keys

Nick Lamb via dev-security-policy writes: >In order for Symantec to reveal anybody's private keys they'd first need to >have those keys That's standard practice for many CAs, they generate the key and certificate for you and email it to you as a PKCS #12.

Re: Over 14K 'Let's Encrypt' SSL Certificates Issued To PayPal Phishing Sites

Martin Heaps via dev-security-policy writes: >This topic is frustrating in that there seems to be a wide attempt by people >to use one form of authentication (DV TLS) to verify another form of >authentication (EV TLS). The overall problem is that browser

Re: CA Validation quality is failing

Kurt Roeckx via dev-security-policy writes: >Both the localityName and stateOrProvinceName are Almere, while the province >is Flevoland. How much checking is a CA expected to do here? I know that OV and DV certs are just "someone at this site responded

Re: CA Validation quality is failing

Ryan Sleevi writes: >For an EV cert, you look in  >https://cabforum.org/wp-content/uploads/EV-V1_6_1.pdf It was meant as a rhetorical question, the OP asked whether doing XYZ in an EV certificate was allowed and I was pointing out that the CAB Forum guidelines should

Re: [FORGED] Criticism of Mozilla Re: Google Trust Services roots

Kurrasch via dev-security-policy writes: >* Types of transfers: I don't think the situation was envisioned where a >single root would be transferred between entities in such a way that company >names and branding would become intermingled. This has

Re: DigiCert-Symantec Announcement

Jeremy Rowley via dev-security-policy writes: >Today, DigiCert and Symantec announced that DigiCert is acquiring the >Symantec CA assets, including the infrastructure, personnel, roots, and >platforms. I realise this is a bit off-topic for the list but

Re: DigiCert-Symantec Announcement

Peter Bowen writes: >Gerv's email was clear that sale to DigiCert will not impact the plan, >saying: "any change of control of some or all of Symantec's roots would not >be grounds for a renegotiation of these dates." > >So the sanctions are still intact. Ah, I phrased my

Re: Certificate with invalid dnsName issued from Baltimore intermediate

Hanno Böck via dev-security-policy writes: >More dotdot-certificates: Given how widespread (meaning from different CAs) these are, is there some quirk of a widely-used resolver library that allows them? I've done a bit of impromptu testing of various

Re: [FORGED] Re: Machine- and human-readable format for root store information?

David Adrian via dev-security-policy writes: >I'd like to see either a reliable URL to fetch that can be converted to PEM >(i.e. what Microsoft does), or some API you can hit to the store (e.g. what >CT does). PEM. You keep using that word... I do not

Re: [FORGED] Re: Machine- and human-readable format for root store information?

Peter Gutmann via dev-security-policy <dev-security-policy@lists.mozilla.org> writes: >You keep using that word... I do not think it means what you think it does. "... what you think it means". Dammit. Peter. ___ dev-security-poli

Re: Certificates with invalidly long serial numbers

Ryan Sleevi via dev-security-policy writes: >>Pragmatically, does anything known break on the extra byte there? > >Yes. NSS does. Because NSS properly implements 5280. I would say that's probably more a flaw in NSS then. Does anyone's implementation

Re: Certificates with invalidly long serial numbers

Matthew Hardeman via dev-security-policy writes: >One question: the choice of 20 bytes of serial number is an unusual length >for an integer type. It's not a nice clean power of 2. It doesn't align to >any native integer data type length on any platform

Re: Certificates with invalidly long serial numbers

Matthew Hardeman via dev-security-policy writes: >I merely raise the point that IF the framers of the 20 bytes rule did, in >fact, simultaneously intend that arbitrary SHA-1 hash results should be able >to be stuffed into the serial number field AND

Re: [FORGED] Re: Configuring Graduated Trust for Non-Browser Consumption

Ryan Sleevi writes: >Mozilla updates every six to eight weeks. And that works. That's all that >matters for this discussion. Do all the world's CAs know this? Peter. ___ dev-security-policy mailing list

Re: [FORGED] Re: Configuring Graduated Trust for Non-Browser Consumption

Ryan Sleevi writes: >I can't help but feel you're raising concerns that aren't relevant. CAs issue roots with effectively infinite (20 to 40-year) lifetimes because it's too painful to do otherwise. You're proposing instead: require that all CAs must generate (new) roots on

Re: [FORGED] Re: Configuring Graduated Trust for Non-Browser Consumption

Ryan Sleevi via dev-security-policy writes: >An alternative solution to the ossification that Alex muses about is to >require that all CAs must generate (new) roots on some interval (e.g. 3 >years) for inclusion. That is, the 'maximum' a root can be

Re: April CA Communication: Results

Jakob Bohm via dev-security-policy writes: >Indeed, I strongly suspect Microsoft *customers* combined with Microsoft >untrustworthiness (they officially closed their Trustworthy Computing >initiative!) may be the major hold out, specifically: > >1. [...]

Re: [FORGED] Re: Configuring Graduated Trust for Non-Browser Consumption

Michael Casadevall via dev-security-policy writes: >I learned something new today. I'm about to run out the door right now so I >can't read the RFCs but do you know off the top of your head why that was >removed? >From the PKIX RFC? There was never any

Re: [FORGED] Re: P-521

Alex Gaynor via dev-security-policy writes: >I'll take the opposite side: let's disallow it before it's use expands :-) >P-521 isn't great, and there's really no value in proliferation of crypto >algorithms, as someone told me: "Ciphersuites aren't

Re: Machine- and human-readable format for root store information?

Jos Purvis (jopurvis) via dev-security-policy writes: >One possibility would be to look at the Trust Anchor Management Protocol >(TAMP - RFC5934). Note that TAMP is one of PKIX' many, many gedanken experiments that were created with little, most likely

Re: [FORGED] Re: CA generated keys

Matthew Hardeman via dev-security-policy writes: >In principle, I support Mr. Sleevi's position, practically I lean toward Mr. >Thayer's and Mr. Hollebeek's position. I probably support at least one of those, if I can figure out who's been quoted as

Re: On the value of EV

Tim Shirley via dev-security-policy writes: >But regardless of which (or neither) is true, the very fact that EV certs are >rarely (never?) used on phishing sites There's no need:

Re: CA generated keys

Ryan Hurst via dev-security-policy writes: >Unfortunately, the PKCS#12 format, as supported by UAs and Operating Systems >is not a great candidate for the role of carrying keys anymore. You can see >my blog post on this topic here:

Re: OCSP Responder monitoring (was Re: Violations of Baseline Requirements 4.9.10)

Rob Stradling via dev-security-policy writes: >CAs / Responder URLs that are in scope for, but violate, the BR prohibition >on returning a signed a "Good" response for a random serial number Isn't that perfectly valid? Despite the misleading name,

Re: Francisco Partners acquires Comodo certificate authority business

mw--- via dev-security-policy writes: >So they sell multiple roots over to a company that is "the leader in Deep >Packet Inspection (DPI) and we've got a lot going on in that space" and >enable them to issue trusted certificates and mitm all encrypted

Re: Disallowed company name

Matthew Hardeman writes: >>On Thu, May 31, 2018 at 8:38 PM, Peter Gutmann >>wrote: >> >>>Banks, trade vendors, etc, tend to reject accounts with names like this. >> >>Do they? >> >>https://www.flickr.com/photos/nzphoto/6038112443/ > >I would hope that we could agree that there is generally a

Re: [FORGED] Re: Disallowed company name

Matthew Hardeman writes: >On Thu, May 31, 2018 at 5:03 PM, Kristian Fiskerstrand wrote: > >> New business enterprise name: ';UPDATE TAXRATE SET RATE = 0 WHERE NAME = >> 'EDVIN SYSE' > >That's hilarious. Where I'm from they'd accuse you of attempting to hack >them, though likely not actually

Re: [FORGED] Re: Disallowed company name

Matthew Hardeman writes: >I wonder if you've ever annoyed a taxing authority? They have far less humor >than one might imagine. I used to have the account name administrator@, after trying various SQLI@ names and being somewhat disappointed that no fireworks ensued. They were rather amused,

Re: Disallowed company name

Matthew Hardeman writes: >Banks, trade vendors, etc, tend to reject accounts with names like this. Do they? https://www.flickr.com/photos/nzphoto/6038112443/ Peter. ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org

Re: DYMO Root CA installed by Label Printing Software

Nicholas Humfrey via dev-security-policy writes: >What is the correct way for them to achieve what they are trying to do? I'm not sure if there is a correct way, just a least awful way. The problem is that the browser vendors have decreed that you can

Re: DYMO Root CA installed by Label Printing Software

Ryan Sleevi writes: >Of course, if that doesn’t tickle your fancy, there are other ways that are >supported that you may not have heard about - for example: >https://docs.microsoft.com/en-us/microsoft-edge/extensions/guides/native-messaging >

Re: DYMO Root CA installed by Label Printing Software

Ryan Sleevi writes: >First, there are non-commercial CAs that are trusted. By "commercial CAs" I meant external business entities, not an in-house CA that the key or cert owner controls. Doesn't matter if they charge money or not, you still need to go to an external

Re: DYMO Root CA installed by Label Printing Software

Jonathan Rudenberg writes: >For communicating with other machines, the correct thing to do is to issue a >unique certificate for each device from a publicly trusted CA. The way Plex >does this is a good example:

Re: DYMO Root CA installed by Label Printing Software

Ryan Sleevi writes: >Or is your viewpoint that because this happened in the past, one should >assume that it will forever happen, no matter how much the ecosystem changes - >including explicitly prohibiting it for years? Pretty much. See the followup message, which shows it

Re: DYMO Root CA installed by Label Printing Software

Ryan Sleevi writes: >I hope you can see how I responded to precisely the problem provided. You responded to that one specific limited instance. That doesn't work for anything else where you've got a service that you want to make available over HTTPS. Native messaging is a

Re: DYMO Root CA installed by Label Printing Software

Ryan Sleevi writes: >I similarly suspect you’re unaware of https://wicg.github.io/cors-rfc1918/ in >which browsers seek to limit or restrict communication to such devices? A... blog post? Not sure what that is, it's labelled "A Collection of Interesting Ideas", stashed on

Re: A vision of an entirely different WebPKI of the future...

Matthew Hardeman via dev-security-policy writes: >What if the various user agents' root programs all lobbied ICANN to impose a >new technical requirement upon TLD REGISTRY operators? That was actually debated by one country, that whenever anyone bought a domain they'd automatically get a

Re: A vision of an entirely different WebPKI of the future...

Matthew Hardeman via dev-security-policy writes: >That's very interesting. I would be curious to know the timing of this. Was >this before or after massive deployment of DNSSEC by the registries? Some time before. To the best of my knowledge DNSSEC considerations had nothing to do with this

Re: [FORGED] Re: [FORGED] TeletexString

​Ryan Sleevi writes: >Is that because you believe it forbidden by spec, or simply unwise? The spec allows almost anything, and in particular because there isn't any one definitive "spec" you can have ten incompatible interpretations that are all compliant to something that can claim to be the

Re: [FORGED] TeletexString

Kurt Roeckx writes: >I have yet to see a certificate that doesn't just put latin1 in it, which >should get rejected. There were some Deutsche Telekom certificates from the late 1990s that used T61String floating diacritics for which I had some custom code to identify the two-character sequences

Re: [FORGED] TeletexString

Peter Bowen via dev-security-policy writes: >In reviewing a recent CA application, the question came up of what is allowed >in a certificate in data encoded as "TeletexString" (which is also sometimes >called T61String). For the full story of T.61 strings, see the X.509 style guide,

Re: [FORGED] TeletexString

Kurt Roeckx writes: >I think it should generate an error on any character not defined in 102 and >the space character. So any time you try to use anything in C0, C1 and G1, >and those 6 in 102 that are not defined. Yep, sounds good. With a possible check for latin-1 validity as well in case

Re: [FORGED] TeletexString

Kurt Roeckx writes: >As I understand it, it was the Swedish government, and they claimed that >Microsoft said it was ok. They just contained latin1. That sounds right then, latin-1 would cover Sweden, and given the T61String = latin1 that most (all?) implementations apply it should work fine.

Re: Sigh. stripe.ian.sh back with EV certificate for Stripe, Inc of Kentucky....

Jakob Bohm via dev-security-policy writes: >It's like a fire drill where the mayor "pretends" that an old school building >is on fire, and the firemen then proceed to evacuate the building and douse >it in enough water to put out a real fire. Well, not

Re: DigiCert Assured ID Root CA and Global Root CA EV Request

Rob Stradling via dev-security-policy writes: >The public exponent (65537) in https://crt.sh/?asn1=628933973 is encoded as >02 04 00 01 00 01 (02=INTEGER, 04=length in bytes), whereas the only valid >encoding is 02 03 01 00 01. Yep, this is what dumpasn1 says about it: 5574:

Re: [FORGED] Re: [FORGED] Re: Incident report - Misissuance of CISCO VPN server certificates by Microsec

Paul Wouters via dev-security-policy writes: >I'm not sure how that is helpful for those crypto libraries who mistakenly >believe a certificate is a TLS certificate and thus if the EKU is not empty >it should have serverAuth or clientAuth. Sure, it wouldn't help with current libraries that

Re: [FORGED] Re: Incident report - Misissuance of CISCO VPN server certificates by Microsec

Paul Wouters via dev-security-policy writes: >Usually X509 is validated using standard libraries that only think of the TLS >usage. So most certificates for VPN usage still add EKUs like serverAuth or >clientAuth, or there will be interop problems. So just to make sure I've got this right,

Re: P-521 Certificates

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

Re: P-521 Certificates

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.

Re: Online exposed keys database

Ryan Hurst via dev-security-policy writes: >My first thought is by using SPKI you have limited the service unnecessarily >to X.509 related keys, I imagined something like this covering PGP, JWT as >well as other formats. It would be nice to see the scope increased >accordingly. You can't do it

Re: DarkMatter Concerns

tomasshredder--- via dev-security-policy writes: >We still get asked by customers to implement sequential serial numbers from >time to time, but it's getting more and more rare. Another reason for using random data, from the point of view of a software toolkit provider, is that it's the only

Re: DarkMatter Concerns

Mike Kushner via dev-security-policy writes: >EJBCA was possible the first (certainly one of the first) CA products to use >random serial numbers. Random serial numbers have been in use for a long, long time, principally to hide the number of certs a CA was (or wasn't) issuing. Here's the

Re: DarkMatter Concerns

Matt Palmer via dev-security-policy writes: >Imagine if a CA said "we generate a 64-bit serial by getting values from the >CSPRNG repeatedly until the value is one greater than the previously issued >certificate, and use that as the serial number.". Well, something pretty close to that works

Re: [FORGED] Re: What's the meaning of "non-sequential"? (AW: EJBCA defaulting to 63 bit serial numbers)

Matthew Hardeman via dev-security-policy writes: >But, maybe "non-sequential" doesn't mean that. It's a pity a concept like >that isn't clearly objective. I assume what the text was meaning to say was "unpredictable", but it was unfortunately phrased badly, presumably as a rushed response to

Re: Serial Number Origin Transparency proposal (was Re: A modest proposal for a better BR 7.1)

Rob Stradling via dev-security-policy writes: >I've been working on an alternative proposal for a serial number generation >scheme, for which I intend to write an I-D and propose to the LAMPS WG. This seems really, really complicated. In all of the endless debate over this, the one thing that

Re: Pre-Incident Report - GoDaddy Serial Number Entropy

Daymion Reynolds via dev-security-policy writes: >Our goal is to reissue all the certificates within the next 30 days. Before everyone goes into an orgy of mass revocation, see the message I just posted "Why BR 7.1 allows any serial number except 0". As long as your serial number isn't zero,

Re: A modest proposal for a better BR 7.1

Matthew Hardeman via dev-security-policy writes: >shall be 0x75 Not 0x71? >If anyone thinks any of this has merit, by all means run with it. Sounds good, and saves me having to come up with something (the bitsort(CSPRNG64()) nonsense took enough time to type up). The only thing I somewhat

Re: EJBCA defaulting to 63 bit serial numbers

Dimitris Zacharopoulos via dev-security-policy writes: >If we have to count every CA that had this interpretation, then I suppose all >CAs that were using EJBCA with the default configuration have the same >interpretation. There's also an unknown number of CAs not using EJBCA that may have

Why BR 7.1 allows any serial number except 0

I didn't post this as part of yesterday's message because I didn't want to muddy the waters even further, but let's look at the exact wording of BR 7.1: CAs SHALL generate non-sequential Certificate serial numbers greater than zero (0) containing at least 64 bits of output from a CSPRNG Note

Re: Why BR 7.1 allows any serial number except 0

I wrote: >So the immediate application of this observation is to make any 64-bit value >comply with the ASN.1 encoding rules: If the first bit is 1 (so the sign bit >is set), swap it with any convenient zero bit elsewhere in the value. >Similarly, if the first 9 bits are zero, swap one of them

Re: Why BR 7.1 allows any serial number except 0

Ryan Sleevi writes: >I'm not sure this will be a very productive or valuable line of discussion. What I'm pointing out is that beating up CAs over an interpretation of the requirements that didn't exist until about a week ago when it was pointed out in relation to DarkMatter is unfair on the

Re: Pre-Incident Report - GoDaddy Serial Number Entropy

Jaime Hablutzel via dev-security-policy writes: >>>Again, maths were wrong here, sorry. Correct calculation is: >>> >>>log2(18446744073708551615) = 63.93 >> >>I love the way that people are calculating data on an arbitrarily-chosen value >>pulled entirely out of thin air > >Can

Re: Pre-Incident Report - GoDaddy Serial Number Entropy

Jaime Hablutzel via dev-security-policy writes: >Again, maths were wrong here, sorry. Correct calculation is: > >log2(18446744073708551615) = 63.93 I love the way that people are calculating data on an arbitrarily-chosen value pulled entirely out of thin air to 14 decimal places.

Re: EJBCA defaulting to 63 bit serial numbers

Matthew Hardeman writes: >Can the CA's agent just request the cert, review the to-be-signed certificate >data, and reject and retry until they land on a prime? Then issue that >certificate? > >Does current policy address that? Should it? Yeah, you can get arbitrarily silly with this. For

Re: EJBCA defaulting to 63 bit serial numbers

Jakob Bohm via dev-security-policy writes: >This raises 3 derived concerns: And a fourth, which has been overlooked during all the bikeshedding... actually I'll call it question 0, since that's what it should have been: 0. Given that the value of 64 bits was pulled out of thin air (or

Re: EJBCA defaulting to 63 bit serial numbers

Matthew Hardeman writes: >As if on queue, comes now GoDaddy with its confession. I swear I didn't plan that in advance :-). Peter. ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org

Re: EJBCA defaulting to 63 bit serial numbers

I wrote: As I said above, you can get arbitrarily silly with this. I'm sure if we looked at other CA's code at the insane level of nitpickyness that DarkMatter's use of EJBCA has been examined, we'd find reasons why their implementations are non-compliant as well. Seconds after sending

Re: EJBCA defaulting to 63 bit serial numbers

Matt Palmer via dev-security-policy writes: >If you generate a 64-bit random value, then discard some values based on any >sort of quality test, the end result is a 64-bit value with less-than-64-bits >of randomness. That's not what 7.1 says, merely: CAs SHALL generate non-sequential

Re: Pre-Incident Report - GoDaddy Serial Number Entropy

Richard Moore via dev-security-policy writes: >If any other CA wants to check theirs before someone else does, then now is >surely the time to speak up. I'd already asked previously whether any CA wanted to indicate publicly that they were compliant with BR 7.1, which zero CAs responded to (I

Re: Arabtec Holding public key?

admin--- via dev-security-policy writes: >The risk here, of course, is low in that having a certificate you do not >control a key for doesn't give you the ability to do anything. As far as we know. Presumably someone has an interesting (mis)use for it otherwise they wouldn't have bothered

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

Daniel Marschall via dev-security-policy writes: >I share the opinion with Jakob, except with the CVE. Please remove this >change. It is unnecessary and kills the EV market. And that was my motivation for the previous question: We know from a decade of data that EV certs haven't made any

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

Peter Bowen via dev-security-policy writes: >I have to admit that I'm a little confused by this whole discussion. While >I've been involved with PKI for a while, I've never been clear on the >problem(s) that need to be solved that drove the browser UIs and creation of >EV certificates. Oh,

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

Leo Grove via dev-security-policy writes: >Are you referring to EV Code Signing certificates? I agree that needs to be >addressed in another forum, but this discussion in on EV SSL/TLS and their >value (or lack thereof) in the browser UI. Browsers do not support EV Code >Signing in the UI as

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

Daniel Marschall via dev-security-policy writes: >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. Does anyone know when Opera made the change? They had EV UI at one point, and then

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

Eric Mill writes: >CAs should be careful about casually and dramatically overestimating the >roadblocks that EV certificates present to attackers. See also the screenshot I posted earlier.  That was from a black-market web site selling EV certificates to anyone with the stolen credit cards to

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

Doug Beattie writes: >So far I see is a number of contrived test cases picking apart small >components of EV, and no real data to back it up. See the phishing stats from any source you care to use. I've already mentioned the APWG which I consider the premier source, and also linked to the SSL

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

Doug Beattie writes: >Do you have any empirical data to backup the claims that there is no benefit >from EV certificates? Uhhh... I don't even know where to start. We have over ten years of data and research publications on this, and the lack of benefit was explicitly cited by Google and

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

Wayne Thayer via dev-security-policy writes: >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. Just out of interest, how are the CAs taking this? If there's no more reason to pay a substantial premium to

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

Doug Beattie writes: >One of the reasons that phishers don’t get EV certificates is because the >vetting process requires several interactions and corporate repositories >which end up revealing more about their identity. This leaves a trail back >to the individual that set up the fake site

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

Corey Bonnell via dev-security-policy writes: >the effectiveness of the EV UI treatment is predicated on whether or not the >user can memorize which websites always use EV certificates *and* no longer >proceed with using the website if the EV treatment isn't shown. That's a huge >cognitive

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

Jakob Bohm via dev-security-policy writes: >Your legendary dislike for all things X.509 is showing. My dislike for persisting mindlessly with stuff we already know doesn't work is showing (see in particular the quote typically misattributed to Einstein about the definition of insanity), and

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

Jakob Bohm via dev-security-policy writes: > and > both took advantage of weaknesses in two >government registries They weren't "weaknesses in government registries", they were registries working as designed, and as

Re: DigiCert OCSP services returns 1 byte

Curt Spann via dev-security-policy writes: >I created the following bug: >https://bugzilla.mozilla.org/show_bug.cgi?id=1577014 Maybe it's an implementation of OCSP SuperDietLite, 1 = revoked, 0 = not revoked. In terms of it being unsigned, you can get the same effect by setting respStatus =

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

Kirk Hall via dev-security-policy writes: >does GSB use any EV certificate identity data in its phishing algorithms. Another way to think about this this is to look at it from the criminals' perspective: What's the value to criminals? To use a silly example, the value to criminals of an

Re: PrintableString, UTF8String, and RFC 5280

Ryan Sleevi writes: >I don't think the hyperbole helps here. It wasn't hyperbole, it was extreme surprise. When someone told me about this I couldn't believe it was still happening after the massive amount of publicity it got at the time, so it was more a giant "WTF?!??" than anything else.

Re: [FORGED] Re: Firefox removes UI for site identity

Paul Walsh via dev-security-policy writes: >we conducted the same research with 85,000 active users over a period of >12 months As I've already pointed out weeks ago when you first raised this, your marketing department conducted a survey of EV marketing effectiveness. If you have a

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

Paul Walsh via dev-security-policy writes: >I have no evidence to prove what I’m about to say, but I *suspect* that the >people at BSI specified “EV” over the use of other terms because of the >consumer-visible UI associated with EV (I might be wrong). Except that, just like your claims about

Re: [FORGED] Re: How Certificates are Verified by Firefox

Ben Laurie via dev-security-policy writes: >In short: caching considered harmful. Or "cacheing considered necessary to make things work"? In particular: >caching them and filling in missing ones means that failure to present >correct cert chains is common behaviour. Which came first? Was

Re: PrintableString, UTF8String, and RFC 5280

Ryan Sleevi writes: >Do you believe it’s still applicable in the Web PKI of the past decade? Yes, the specific cert I referenced is current valid and passed WebTrust and EV audits. >If you could link to the crt.sh entry, that might be easier. Here's the Microsoft one I mentioned: Microsoft

Re: PrintableString, UTF8String, and RFC 5280

Ryan Sleevi via dev-security-policy writes: >In https://bugzilla.mozilla.org/show_bug.cgi?id=1593814 , Rob Stradling, >Jeremy Rowley, and I started discussing possible steps that might be taken to >prevent misencoding strings in certificates Is there any official position on strings that have

Re: Website owner survey data on identity, browser UIs, and the EV UI

Kirk Hall via dev-security-policy writes: >To remedy this, Entrust Datacard surveyed all of its TLS/SSL web server >certificate customers And what a marvellously disingenous "survey" it is too, artfully constructed to produce exactly the result the CA's marketing department wants. Mixed in

Re: [FORGED] Re: [FORGED] Re: Website owner survey data on identity, browser UIs, and the EV UI

Ronald Crane via dev-security-policy writes: >Please cite the best study you know about on this topic (BTW, I am *not* >snidely >implying that there isn't one). Sure, gimme a day or two since I'm away at the moment. Alternatively, there's been such a vast amount of work done on this that a

Re: [FORGED] Mozilla's Expectations for OCSP Incident Reporting

Wayne Thayer via dev-security-policy writes: >It was recently reported [1] that IdenTrust experienced a multi-day OCSP >outage about two weeks ago. Just to understand the scope of this, what was the impact on end users? If it went on for multiple days then presumably no-one noticed it, the

Re: Mozilla's Expectations for OCSP Incident Reporting

>Just to understand the scope of this, what was the impact on end users? Following up on this, would it be correct to assume that, since no-one has pointed out any impact that this had on anything, that it's more a certificational issue than anything with real-world consequences? Peter.

Re: Mozilla's Expectations for OCSP Incident Reporting

Ryan Sleevi writes: >>Following up on this, would it be correct to assume that, since no-one has >>pointed out any impact that this had on anything, that it's more a >>certificational issue than anything with real-world consequences? > >That seems quite a suppositional leap, don't you think?

Re: Digicert issued certificate with let's encrypts public key

Kurt Roeckx via dev-security-policy writes: >Browsing crt.sh, I found this: https://crt.sh/?id=1902422627 > >It's a certificate for api.pillowz.kz with the public key of Let's Encrypt >Authority X1 and X3 CAs. How could that have been issued? Since a (PKCS #10) request has to be self- signed,

Re: Digicert issued certificate with let's encrypts public key

Peter Bowen writes: >There is no requirement to submit a PKCS#10 CSR.  Hmm, so what sort of issue process allows you to obtain a certificate for a key you don't control? Peter. ___ dev-security-policy mailing list

Re: Digicert issued certificate with let's encrypts public key

Corey Bonnell writes: >Certificate renewal that uses the existing certificate as input, rather than >a CSR. The (presumably expiring) certificate supplies the domains, >organization info, and the public key for the renewal certificate request. In >this case there is no proof of key possession

  1   2   >