Re: Unknown Intermediates
On Thu, Jun 29, 2017 at 3:56 PM, Bruce via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > > I'm trying to understand this posting. I think the CAs have an obligation > to disclose all Intermediate certificates to the CCADB. I don't think that > the CAs have an obligation to disclose through CT. Am I right? > Correct. ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Unknown Intermediates
On Friday, June 16, 2017 at 1:05:37 AM UTC-4, Tavis Ormandy wrote: > Hello, I was crawling the pkcs7 blobs in public pdf files and found some > intermediate certificates that don't appear in crt.sh. > > I forwarded them to Rob, I don't know if this is useful to anyone else, but > they're available here. > > https://lock.cmpxchg8b.com/intermediates.zip > > Tavis. > > (I have a larger collection if anyone wants them, but many have unknown > critical extensions, or are name or usage constrained, etc) I'm trying to understand this posting. I think the CAs have an obligation to disclose all Intermediate certificates to the CCADB. I don't think that the CAs have an obligation to disclose through CT. Am I right? I did review the zip above and found 3 Entrust/AffirmTrust certificates. These were all disclosed in the CCADB. Thanks, Bruce. ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Machine- and human-readable format for root store information?
On Wednesday, June 28, 2017 at 7:39:37 PM UTC-4, Gervase Markham wrote: > Well, we should ask Kai what methods he uses to maintain it right now, > and whether he uses a tool. For the recent name constraints, it was a tool. > > You can have a JSON file, but that doesn't mean it's human-readable in the > > least. > > You mean you can stick it all one one line? Or you can choose opaque key > and value names? Or something else? Well, the current certdata.txt is a text file. Do you believe it's human-readable, especially sans-comments? > > > The CI tools don't check in artifacts. You're proposing giving some piece > > of infrastructure the access to generate and check in files? > > I am led to understand this is a fairly common pattern these days. Please realize that this makes it impossible to effectively test changes, without running said tool. This is, again, why certdata.txt being generated is part of the build - so that when you change a file, it's reflected in the build and code and you can effectively test. Moving to a CI system undermines the ability to effectively contribute and test. That's why "machine-readable" is, in effect, a must-have. Whether or not "human-readable" is (and what constitutes human-readable) is the point of discussion, but if you check in the machine-readable form, then anyone can generate the human-readable form at any time. > > >> If Apple said "we are happy to use the MS format", I guess the next > >> thing I would do is find Kai or whoever maintains certdata.txt and say > >> "hey, it's not ideal, but what do you think, for the sake of everyone > >> using the same thing?". > > > > Thought experiment: Why not have certdata.txt generate a CI artifact that > > interoperates for other consumers to use? > > Because certdata.txt's format is not rich enough to support all the data > we would want to encode in a root store. We could consider extending it, > but why would we roll our own container format when there exist > perfectly good ones? Could you explain how you arrive at that conclusion? That may simply be a technical misunderstanding, as certdata.txt's format allows for the expression of arbitrary attributes (as recently added with the "Mozilla Root" attribute) in an appropriate form. Which may be why we're at cross-purposes here - the existing certdata.txt is already technically capable of expressing the constraints. However, it is a complex technical burden to express that in metadata, rather than in code - and that is true no matter what format you choose. If your understanding was based on a misunderstanding that "certdata.txt cannot be extended to support arbitrary metadata", then I can easily tell you that's not the case. It's a matter of changing NSS to, rather than express something simply and cleanly in code (relatively speaking), finding an ontology to express the constraint in a machine-readable (but not-code) format, and then code to parse that and apply in 100 lines what might take 5 lines in code. This is the same as the authroot.stl - both are quite robust, arbitrarily-extensible formats. The choice to not extend is not one about technical limitation, but about unreasonable return for the cost to implement. > > >> Mozilla's opinions on roots are defined by the sum total of: > >> > >> 1) certdata.txt > >> 2) ExtendedValidation.cpp > >> 3) The changes listed on > >> https://wiki.mozilla.org/CA/Additional_Trust_Changes > > > > 1 & 2 for sure. I don't believe #3 can or should be, certainly not > > effectively maintained. Certainly, Google cannot and would not be able to > > find an acceptable solution on #3, just looking at things like CT, without > > introducing otherwise meaningless ontologies such as "Follows > > implementation #37 for this root". > > There are seven items on the list in #3. The first one is item 2, above. > The second is not a root store modification, technically. The third, > fifth and sixth would be accommodated if the new format had a "notAfter" > field. The fourth and seventh would be accommodated if the new format > had a "name constraints" field. > > So putting all of #3, as it currently stands, into a new format seems > eminently doable. That doesn't mean every restriction we ever think of > could be covered, but the current ones (which are ones I can see us > using again in the future) could be. That takes a very Mozilla-centric view, but that doesn't align with, say, the goal of supporting Apple. For example, Apple has three CAs where only certain, previously disclosed (via CT) certificates are trusted - https://opensource.apple.com/source/security_certificates/security_certificates-55070.30.7/certificates/allowlist/ - CNNIC and WoSign. In a machine-readable form, either you put that in a unified file, or you come up with an ontology for expressing dependencies that stretches well beyond the sane bounds. Mozilla's solution to this was, unsurprisingly, with code ( see
Re: P-521
On 29/06/17 00:11, Arkadiusz Ławniczak wrote: > P-256, P-384 and P-521 curves are commonly implemented in all popular > cryptographic libraries such as OpenSSL, Microsoft Crypto API NB (CNG) or > Bouncy Castle, popular web browsers and FIPS 140-2 certified hardware > cryptographic modules. Are you aware of any libraries or browsers which do not support P-521? > But it seems that Mozilla (like the NSA in its "Suite B" recommendation) has > limited its policy to only two curves P-256 and P-384. > The reasons for this decision are known only to this agency and Mozilla. It > can be assumed that stronger cryptography is currently embarrassing for the > NSA, and the safety margin over the operation time is low. Do you believe that P-521 is usefully stronger than P-384? Gerv ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
RE: P-521
Hello all As CERTUM, we would like to create and submit to Mozilla our two new root CAs. There would be nothing unusual about this but I've found that Mozilla Policy doesn't allow to use algorithm P-521 and that is what we want to use in our root CA. NIST FIPS PUB 186-4 recommends 4 curves over Prime Fields for use in US public administration. These are: P-192, P-256, P-384, P-521 Baseline Requirements require: P-256, P-384 or P-521 Key Requirements for Microsoft Trusted Root Program: P-256, P-384, P-521 Mozilla Root Store Policy: P-256, P-384 P-256, P-384 and P-521 curves are commonly implemented in all popular cryptographic libraries such as OpenSSL, Microsoft Crypto API NB (CNG) or Bouncy Castle, popular web browsers and FIPS 140-2 certified hardware cryptographic modules. But it seems that Mozilla (like the NSA in its "Suite B" recommendation) has limited its policy to only two curves P-256 and P-384. The reasons for this decision are known only to this agency and Mozilla. It can be assumed that stronger cryptography is currently embarrassing for the NSA, and the safety margin over the operation time is low. >From the point of view of Certum CA, the two alleged reasons are irrelevant. This is true that, according to NSA "Suite B" recommendations, standards have been developed such as: 1) IETF RFC 6460, for TLS 2) IETF RFC 6379, for IPsec 3) IETF RFC 6318, for SMIME 4) IETF RFC 5759, for X.509 certificate and CRL However, we must recognize that X.509 end entities and service certificates are issued for one year, up to three years. CA root certificates are issued for 25 years. They must rely on stronger cryptography as well as the ARLs they publish. Not every commercial organization must also apply to NSA recommendations and its depleted cryptographic algorithms. Especially if it operates in Europe and cares for the safety of its customers. -- Arkadiusz Ławniczak Analyst Security and Trust Services Division Asseco Data Systems S.A. Biuro w Szczecinie ul. Królowej Korony Polskiej 21 70-486 Szczecin mob. +48 669992104 arkadiusz.lawnic...@assecods.pl assecods.pl -Original Message- From: dev-security-policy [mailto:dev-security-policy-bounces+arkadiusz.lawniczak=assecods...@lists.mozilla.org] On Behalf Of Ryan Sleevi via dev-security-policy Sent: Wednesday, June 28, 2017 3:42 PM To: Alex Gaynor Cc: Gervase Markham; MozPol; Kurt Roeckx Subject: Re: P-521 On Tue, Jun 27, 2017 at 2:44 PM, Alex Gaynor via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > 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 pokemon, > you shouldn't try to catch 'em all". There's no real use cases P-521 > enables, and not supporting it means one less piece of code to drag > around as we move towards better curves/signature algorithms like Ed25519 and > co. +1 to this. P-521 is specified for negotiation because negotiation is just that - negotiation. It's not mandatory to implement all of those algorithms, and it's not necessarily desirable to either (e.g. rsa_pkcs1_sha1 ) P-521 does not have widespread deployment on the Web PKI, and does not meaningfully or substantially improve security relevant to the attacks, at a computational and interoperability cost that is justified. ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
