Re: New problematic practice

Erwann Abalea eaba...@gmail.com writes: Has this extension been de-obsoleted? It was already deprecated in RFC2459, it's not even present in RFC5280 anymore. Like other aspects of the web PKI (e.g. wildcard certs), this is one of the areas where you need to ignore what PKIX says and do what

Re: Which SHA-2 algorithm should be used?

Man Ho (Certizen) ma...@certizen.com writes: If there is no constraints on choosing SHA-256, SHA-384 or SHA-512, why CAs are so conservative and prefer SHA-256 rather than SHA-512? I think going directly to a higher security strength should be preferable. What extra security does -512 give you

Re: DigiCert Request to Include Renewed Roots

Rob Stradling rob.stradl...@comodo.com writes: RFC5820 4.2.1.12 seems to say it's _not_ entirely useless in TLS: id-kp-serverAuth OBJECT IDENTIFIER ::= { id-kp 1 } -- TLS WWW server authentication -- Key usage bits that may be consistent: digitalSignature, --

Re: Proposal: Switch generic icon to negative feedback for non-https sites

[Apologies if you've seen this before, it looks like up to a week's worth of mail from here has been lost, this is a resend of the backlog] Chris Palmer pal...@google.com writes: Firefox 31 data: on desktop the median successful OCSP validation took 261ms, and the 95th percentile (looking at

Re: Proposal: Switch generic icon to negative feedback for non-https sites

Chris Palmer pal...@google.com writes: FWIW, that's a misquote; I didn't write that. Ooops, sorry, it was posted by Patrick McManus pmcma...@mozilla.com (I used a script to try and resurrect the lost emails for re-send, I suspect something got mangled somewhere). So the question should have

Re: Cert spam, or certs with huge numbers of hosts.

John Nagle na...@sitetruth.com writes: There's a real risk here. A break-in at any of those sites allows impersonating all of them. This creates a huge attack surface. It's actually a lot worse than that, see Virtual Host Confusion: Weaknesses and Exploits by Antoine Delignat-Lavaud and

Re: [Cryptography] New free TLS CA coming

Mark Atwood m...@mark.atwood.name writes: On Tue, Nov 18, 2014, at 11:25, Salz, Rich wrote: Initial drop of code and specs available here: https://github.com/letsencrypt From https://letsencrypt.org/2014/11/18/announcing-lets-encrypt.html : So Mozilla et al have been giving CAcert the

Re: Propose Removal of E-Guven root

Matt Palmer mpal...@hezmatt.org writes: On Thu, Mar 19, 2015 at 01:01:32PM -0700, Peter Bowen wrote: In the Pilot CT log, which includes every certificate that the Google crawler has seen, I found 19 unexpired certificates issued by this CA. Their subjects are as follows (using the default

Re: Consequences of mis-issuance under CNNIC

Daniel Micay danielmi...@gmail.com writes: CNNIC is known to have produced and distributed malware for the purpose of mass surveillance and censorship. TeliaSonera aided totalitarian governments, Comodo provided the PrivDog MITM software, and that's just the first two off the top of my head. If

Re: Consequences of mis-issuance under CNNIC

Matt Palmer mpal...@hezmatt.org writes: However, given that CNNIC felt it appropriate to violate their CPS with regards to an intermediate CA certificate, I don't see that there's any greater reason to trust their adherence to their CPS in any other aspect. Thus, I'm not not keen on allowing them

Re: Tightening up after the Lenovo and Comodo MITM certificates.

Peter Kurrasch fhw...@gmail.com writes: I think focusing on the trusted root store as a way to resolve this problem is (or will be) less than ideal.? I understand the desire to look there but I don't think it will necessarily end well. I think focusing on the browser as a whole is less than

RE: Certificate with space in CommonName found on deutschepost.de

Did anyone save a copy of the cert chain? I'd like to add it to my collection of broken cer^H^H^H^H^Hcert parser test vectors, but the site has been fixed and the Bugzilla entry doesn't contain it. Peter. ___ dev-security-policy mailing list

Re: Certificate with space in CommonName found on deutschepost.de

Erwann Abalea eaba...@gmail.com writes: That's really an OID, in the Microsoft arc. I don't know what triggered the Error: OID contains random garbage message, Uhh, the fact that it contains random garbage encoded as an OID? This OID is correctly encoded, the fact that it contains somewhat

RE: Certificate with space in CommonName found on deutschepost.de

Kurt Roeckx k...@roeckx.be writes: The site hasn't been fixed, at least not for me. Ah, both Firefox and IE were connecting, but that was because the HTTPS got redirected to plain HTTP, and any of the links to HTTPS sites that I could find on the site led to a bewildering array of affiliated

RE: [FORGED] Name issues in public certificates

Peter Bowen writes: >There are a couple of rules that may create false positives, so please don't >assume every certificate on the sheet is problematic. That's still pretty scary, nearly 50,000 names from a who's-who of commercial CAs. Yet more evidence that, like the output

RE: Firefox security too strict (HSTS?)?

AnilG writes: >This is really big picture here: I've looked up and suddenly seen Firefox >market share trajectory looking like we need some steering input fast. This >is a 3 to 6 year picture of decline so it will take as long to correct. Oh dear, this is really going

RE: [FORGED] Re: Policy Update Proposal -- Remove Email Trust Bit

Eric Mill writes: >can anyone lay out what the steps to doing that would look like so the S/MIME >community can react in more concrete ways? Well, first you'll have to tell the S/MIME community what it is you want them to do... Peter.

RE: [FORGED] Re: Nation State MITM CA's ?

Kai Engert writes: >Independently of the request for inclusion, this group could discuss if the >Kazakhstan's CAs should be blacklisted, by adding them to the Mozilla CA list >using negative distrust flags That would have some pretty bad consequences. With the MITM CA cert

RE: [FORGED] Re: [FORGED] Re: Nation State MITM CA's ?

Paul Wouters writes: >> If you disallow the cert and turn off encryption, Borat can still read >> everyone's traffic, but so can everyone else on the planet. > >Who said "turn off encryption"? If you don't allow the MITM cert, which is needed to enable encryption in the

RE: [FORGED] Re: SSL Certs for Malicious Websites

Gervase Markham writes: >It depends what alternative configuration-free idiot-proof secure >communications technology you have invented in your fantasy world to take its >place. Are you really trying to claim that the sad farce that is current browser PKI is absolutely the

RE: MITM detection in the browser

John Nagle writes: >As an example, suppose a server sending a page sends, at the beginning of the >page, a hash value which is based on the contents of the page about to be >sent, and also based on the first 64 bytes of the crypto bits of the >connection. The browser checks

RE: [FORGED] Re: SSL Certs for Malicious Websites

Ryan Sleevi writes: >This seems both off-topic and not productively addressing the topic at hand. Yeah, maybe it's best taken to another list like cypherpunks or the crypto list. It was intended as an honest, and probably pretty blunt, assessment of the state of HTTPS: It was

RE: [FORGED] Re: SSL Certs for Malicious Websites

Richard Z writes: >If any criminal can easily get EV certificates what is the point of https? The point of HTTPS is twofold: 1. Convince users that the Internet is safe to do business on (financial transfers, medical data). 2. Provide a steady revenue stream for CAs.

RE: Proposed limited exception to SHA-1 issuance

Steve writes: >They state no business case where the 9 payment gateways are accessible by >browsers or that any business case exists on the gateways that uses any >client other than the payment terminal. So these things will never see access by a browser enforcing the

RE: Proposed limited exception to SHA-1 issuance

Gervase Markham writes: >Mozilla is very keen to see SHA-1 eliminated, but understands that for >historical reasons poor decisions were made in private PKIs about which roots >to trust, and such decisions are not easily remedied. I'm curious about what's going on here, as you

RE: Re: Re: Proposed limited exception to SHA-1 issuance

Dean Coclin writes: >The same one they've been using and know works: VeriSign Class 3 >International Server CA - G3. So the devices will trust any cert from this CA? This is a serious question, a contractor once got into USG infrastructure with a $20 or so cert

RE: Private PKIs, Re: Proposed limited exception to SHA-1 issuance

Jürgen Brauckmann writes: >Nice example from the consumer electronics world: Android >= 4.4 is quite >resistant against private PKIs. You cannot import your own/your corporate >private Root CAs for Openvpn- or Wifi access point security without getting >persistent, nasty,

RE: Re: Proposed limited exception to SHA-1 issuance

Dean Coclin writes: >According to WP, as part of the EMV program, they are aggressively rolling >out new devices to replace all old equipment in the field. They expect this >to be completed by the end of the year. They have already moved a large >number of devices to

RE: Proposed limited exception to SHA-1 issuance

Rob Stradling writes: >But if it's an old version of NSS or OpenSSL, then the community could help >find an exploitable bug. If it's a remote-code-exec we could patch their firmware for them to support SHA-256. Think of it as an undocumented remote admin capability.

RE: OCSP Responders Are An Attack Vector For SHA-1 Collisions

Jakob Bohm writes: >2. Find a way to add OCSP responder chosen random data in each OCSP > response. Responder or requester? You've got the OCSP nonce, although since every (public) CA has disabled it that probably won't help much. OTOH since clients won't be checking

RE: [FORGED] Re: OCSP Responders Are An Attack Vector For SHA-1 Collisions

Andrew Ayer [a...@andrewayer.name] writes: >Are there clients that will choke if they receive a response without the >expected nonce? See my previous message, since no public CAs honour nonces [0] I don't think there'd be any problem. Peter. [0] At least as of the last check a few years ago.

RE: SSL Certs for Malicious Websites

Matt Palmer writes: >On Mon, May 16, 2016 at 02:22:08PM +0200, Richard Z wrote: >> knowingly issuing/tolerating certificates for sites known to inject >> malware is >> * contrary to user expectaions > >[Citation needed] So you're saying users expect CAs to certify malware

RE: StartEncrypt considered harmful today

Nick Lamb writes: >Early drafts of SCEP, before it confined itself to "closed networks" even >spell out what the problem is before they basically say they're not going to >make any real attempt to tackle it. CMP, CMC and SCEP all resort to saying >that some "out of band"

RE: [FORGED] Re: StartEncrypt considered harmful today

Patrick Figel <patfi...@gmail.com> writes: >On 08/07/16 08:04, Peter Gutmann wrote: >> Or is it that ACME is just a desperate attempt to derail StartCom's >> StartEncrypt at any cost? > >That doesn't make any sense - ACME has been in production for close to a >yea

RE: StartEncrypt considered harmful today

Nick Lamb writes: >ACME is a protocol intended to become an IETF Standards Track RFC. Oh dear God, another one? We've already got CMP, CMC, SCEP, EST, and a whole slew of other ones that failed to get as far as RFCs, which all do what ACME is trying to do. What's the

Re: [FORGED] Re: Other Curves

Ryan Sleevi writes: >Current (and presently proposed) Mozilla policy does not allow them. Nor are >they supported in Mozilla NSS anymore (and their previous support was not one >you should use for security-critical purposes). Nor are they supported in >other UAs. I should point

Re: Useful Heuristics

Nick Lamb writes: >In practice then I think we should try to ask local experts (ie people at >least resident in the relevant country) when trying to judge whether the >Locality and State elements of a Subject DN are acceptable for identifying >the actual Subject unless it

Re: Taiwan GRCA Root Renewal Request

Kathleen Wilson writes: >Indeed, and as per your comment here: >https://bugzilla.mozilla.org/show_bug.cgi?id=1056341#c24 So just to satisfy my curiosity, it's been known ever since top-down construction was first advocated by PKI loon^H^H^Htheoreticians:

Re: Appropriate role for lists of algorithms and key sizes

Jakob Bohm writes: >This changed the moment SHA-2 came out, though one could interpret that the >length of the signature elements would uniquely indicate the SHA variant. >With SHA-256/160 and SHA-3, that is completely gone as there are now two SHA >hash algorithms for

RE: [FORGED] Re: Incidents involving the CA WoSign

Eddy Nigg <eddy_n...@startcom.org> writes: >On 09/04/2016 09:20 AM, Peter Gutmann wrote: >> This is great stuff, it's like watching a rerun of Diginotar > >.says the audience on the backbenches gleefully Well, it doesn't exactly paint the best picture of a com

Re: [FORGED] Re: Incidents involving the CA WoSign

Nick Lamb <tialara...@gmail.com> writes: >On Tuesday, 6 September 2016 15:11:00 UTC+1, Peter Gutmann wrote: >> Why would a public CA even need cross-certification from other CAs? > >Maybe this question has some subtlety to it that I'm missing? OK, I really meant "that

Re: [FORGED] Re: Incidents involving the CA WoSign

Peter Bowen writes: >In addition to the direct impact, I note that WoSign is the subject of cross- >signatures from a number of other CAs that chain back to roots in the Mozilla >program (or were in the program). This is incredible, it's like a hydra. Do the BRs say anything

Re: Incidents involving the CA WoSign

Matt Palmer writes: >Our of curiosity, is anyone keeping a tally of the number of times WoSign has >said, "yep, they're all logged now", only to have more unlogged certificates >turn up? This is starting to feel like a bit of a repeat of DigiNotar, We apologise for the

RE: Reuse of serial numbers

Rob Stradling writes: >https://crt.sh/?serial=056d1570da645bf6b44c0a7077cc6769=1662 says >"Not Revoked" three times. I wonder if that's causing some confusion here. Just to make sure I'm not misreading this in some way, is this really saying there are 313 certs issued

RE: Reuse of serial numbers

Rob Stradling writes: >>I guess it makes them easy to revoke, if a single revocation can kill 313 >>certs at once. > >That's true. Hey, WoSign has solved the CRL scalability problem! >It'd be impossible to revoke (via CRL and/or OCSP) a subset of those 313 >certs

RE: [FORGED] Re: Incidents involving the CA WoSign

Peter Bowen writes: >It was brought to my attention that there is another incident. This is great stuff, it's like watching a rerun of Diginotar. Definitely the best web soap in the last few weeks... Peter. ___

RE: Incidents involving the CA WoSign

itk98...@gmail.com writes: >Wosign indirectly bought StartSSL, https://www.letsphish.org Has there been any independent investigation into this? We know that CAs are bought and sold like baseball trading cards, but it's usually done publicly and freely acknowledged, whereas

Re: Ambiguous wording or the Mozilla CA security reporting requirement

Jakob Bohm writes: >Am I reading something wrong, or is their an unintended loophole in the >Mozilla Policy, as written, in this regard? A cynic would say that that's the exact intent of the policy, to ensure that anything but a catastrophe-scale event that's so big that

Re: [FORGED] Re: WoSign’s Ownership of StartCom

Peter Kurrasch writes: >I would also ask for confirmation that "Andy Ligg" is in fact a real person >and not a pseudonym adopted by Richard or someone else. The similarity to >Eddy's name is...remarkable. Andy Ligg? The only similar name I saw in Gerv's post was Revital Nigg,

Re: Incidents involving the CA WoSign

Rob Stradling writes: >Today we have revoked (via CRL and OCSP) all 3 of the cross-certificates that >we'd issued to WoSign: This allows us to examine the modern Internet variant of an old philosophical question, "If a certificate is revoked in the web PKI and no one

Re: Incidents involving the CA WoSign

Rob Stradling writes: >Easy. It doesn't make a sound. Unrevoked certificates don't make sounds >either. What I was really asking, in a tongue-in-cheek way, was whether there was any indication of how successfully the information could be propagated to browsers.

Re: Incidents involving the CA WoSign

Kurt Roeckx writes: >This is why browsers have something like OneCRL, so that they actually do >know about it and why Rob added that information to the bug tracker ( >https://bugzilla.mozilla.org/show_bug.cgi?id=906611#c2). That still doesn't necessarily answer the question,

Re: [FORGED] Re: Incidents involving the CA WoSign

Peter Bowen writes: >As someone pointed out on Twitter this morning, it seems that the PSC >notification for Startcom UK was filed recently: >https://s3-eu-west-1.amazonaws.com/document-api-images-prod/docs/UdxHYAlFj6U9DNs6VBJdnIDv4IQAWd4YKYomMERO_2o/application-pdf So if I'm

Re: Sanctions short of distrust

Jakob Bohm writes: >While you are at it: > >1. How many WoSign/StartCom certificates did you find with domains not > on that IANA list? > >2. How many WoSign/StartCom certificates did you find for other uses > than https://www.example.tld: > >2.1 Certificates for "odd"

Re: Time to distrust

Jakob Bohm writes: >This tells me that Firefox OCSP defaults are *insecure* and reaffirms my >impression that Firefox has completely dropped the ball on CRL handling >(Since the security-on setting is for OCSP only). No, it tells me that the Firefox developers applied

Re: Time to distrust

Gijs Kruitbosch writes: >(Some) People who "do" Firefox UI read this group. If you have concrete/ >constructive suggestions, please file bugs or write to more topical mailing >lists - especially if you think there are things we should do "frontend"- >wise to improve

Re: WoSign and StartCom

Percy writes: >On Tuesday, September 27, 2016 at 2:15:38 AM UTC-7, Gervase Markham wrote: >> Participants may be interested in this blog post from Tyro: >> https://tyro.com/blog/merchant-security-is-tyros-priority/ > >So this is almost proof that WoSign/StartCom has been

Re: [FORGED] Re: StartCom & Qihoo Incidents

Percy writes: >As we observed the large scale MITM against iCloud, Outlook, Google and >Github carried out on the backbone router with self-signed certs, and that >the browsers are explicitly loads self-signed certs, I think it's clear that >browsers in China are compelled

Re: StartCom & Qihoo Incidents

Peter Bowen writes: >The CA/Browser Forum is not a regulatory body. They publish guidelines but >do not set requirements nor regulate compliance. It's a bit hard to describe its actual functioning, in theory they just advise, but then so does ISO, IEEE, and others. They're

Re: StartCom & Qihoo Incidents

Ryan Sleevi <r...@sleevi.com> writes: >On Friday, October 14, 2016 at 3:44:50 PM UTC-7, Peter Gutmann wrote: >> Another thing I'd like to bring up is the absolute silence of the CAB forum >> over all this. > >It has not been. I haven't heard anything from them. If

Re: StartCom & Qihoo Incidents

Erwann Abalea writes: >And that's not CABF's duty and responsibility. What the CABF can impose to >CABF members is to follow the bylaws, the internal governance rules. By >following them, all members write the guidelines and decide on what changes >to adopt, and browsers then

Re: StartCom & Qihoo Incidents

Ryan Sleevi writes: >What is the goal of the root program? Should there be a higher bar for >removing CAs than adding them? Does trust increase or decrease over time? Another thing I'd like to bring up is the absolute silence of the CAB forum over all this. Apple have quietly

Re: StartCom & Qihoo Incidents

popcorn writes: >There were comments admonishing StartCom and WoSign for not reporting change >of ownership in a timely manner. > >I am not sure if this has been reported earlier, but if not, then Qihoo 360 >change of ownership may be relevant to the current discussion:

Re: StartCom & Qihoo Incidents

Peter Bowen writes: >I think you found the "wrong" True Thrive Limited. Ah, thanks. >This appears to just be a name collision. Naming is hard :( Actually if you think that's tough, try figuring out who the real Midco is... Peter.

Re: [FORGED] Re: Cerificate Concern about Cloudflare's DNS

Tom Ritter writes: >There's been (some) mention that even if a user moves off Cloudflare, the CA >is not obligated to revoke. Would it matter? I guess it depends on circumstances (whether you control the private key or Cloudflare does, whether you intend to use the same domain

Re: Taiwan GRCA Root Renewal Request

lcchen.ci...@gmail.com writes: >I explained the rollover certificate process outlined in RFC 4210 by signing >the old public key with the new private key and the new public key with the >old private key. Uhh, that stuff was a gedanken experiment dreamed up by some folks

Re: Taiwan GRCA Root Renewal Request

capuchin...@gmail.com writes: >However, that does not means our PKIX (RFC-5280) conforimg implementation >will cause errors or bugs to current implementations of browsers. Given all the bizarre stuff that ended up in the PKIX spec, it would be quite easy to create a fully

Re: Taiwan GRCA Root Renewal Request

Wen-Cheng Wang writes: >Actually, we have tested the capabilities of many browsers in the wild and >found they can live peacefully with our PKIX-compliant root certs. Ah, OK. That's the right way to do it. >They are not so weak as you might think. I bet I can create

Re: [FORGED] Re: Firefox 50.1.0 still does not offer any secure SSL / TLS ciphers

Eric Rescorla writes: >I don't think this really accurately reflects the consensus of the security >community Or of any community AFAIK. Perhaps there could be a special version of Firefox that uses one-time pads for everything, and on startup uses a cryptographically secure

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/ > >

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

  1   2   >