Re: Mozilla Root Policy: ECC Curves and Signature Length (Mass Certificate Problem Report)

I think there's still some confusion here. On Thu, May 30, 2024 at 10:23 AM Wayne wrote: > That is also why the censys queries are crafted as you saw, I expected any > algorithm choices to be more constrained, i.e. RSA intermediary must issue > RSA certs, ECDSA intermediary must issue ECDSA

Re: Mozilla Root Policy: ECC Curves and Signature Length (Mass Certificate Problem Report)

On Thu, May 30, 2024 at 9:58 AM Wayne wrote: > Yes the part that threw me off was the jump from the intermediary signing > key to the signature of an end-user certificate. I didn't expect a leap to > that extent without requirements on RSA/ECDSA public keys given where the > chain of trust

Re: Mozilla Root Policy: ECC Curves and Signature Length (Mass Certificate Problem Report)

Seconding Amir: your Censys query is looking for the wrong thing. It's specifying two primary criteria (using your P-384 query as an example): - parsed.subject_key_info.ecdsa.length=`384`, i.e. looking for certificates whose *public key* is an ECDSA P-384 key; and - not

Re: Vulnurability Disclosure - How does it happen?

Although it was not the result of a security breach or other directed attack, I can provide this bugzilla bug as an example of what an embargoed incident report followed by public disclosure has looked like in the past. Aaron On Thu, May 23,

Re: OCSP responde for serial number that exist but out of scope of OCSP reponder?

Sections 4.9.9 and 4.9.10 of version 2.0.2 of the BRs say that they apply "for communicating the status of Certificates which include an Authority Information Access extension with an id-ad-ocsp accessMethod." My reading of that is very simple: if the cert doesn't have an OCSP URI in it, you don't

Re: BR revocation question

On Thu, Feb 15, 2024 at 12:47 AM Peter Mate Erdosi wrote: > So, we have an allowed solution, which provides three different > certificate status answers based on the verifier's software: > based on the CARL: > - good > - revoked > - crashed. > Right, which means that revocation of a self-signed

Re: Public Discussion of Acquisition of e-commerce monitoring GmbH by AUSTRIA CARD-Plastikkarten und Ausweissysteme GmbH

e-commerce monitoring GmbH currently has multiple open bugzilla tickets which have not had any updates from their staff in multiple months: - https://bugzilla.mozilla.org/show_bug.cgi?id=1815534 - https://bugzilla.mozilla.org/show_bug.cgi?id=1862004 Does the behavior of the CA being acquired

Re: Let's Encrypt New Intermediate Certificates

On Wednesday, December 6, 2023 at 5:27:11 AM UTC-8 Peter Gutmann wrote: I meant the use of certificate pinning, so trusting the known-good cert you've seen before If a client or relying party wants to enforce key continuity, they still can. If they want continuity of a CA key operated by

Re: Let's Encrypt New Intermediate Certificates

On Tue, Dec 5, 2023 at 2:30 PM Jeffrey Walton wrote: > Key continuity is a much better security property than what key > rotation provides. Loss of key continuity exposed Diginotar. Why would > LE discourage it? > This is contrary to the current industry consensus. Root programs are moving to

Re: Let's Encrypt New Intermediate Certificates

On Tue, Dec 5, 2023, 12:35 Hanno Böck wrote: > On Mon, 4 Dec 2023 14:20:34 -0500 > "'Phil Porada' via dev-security-policy@mozilla.org" > wrote: > > >1. We will be generating 5 RSA and 5 ECDSA intermediates, instead > > of 2 each. We plan to automatically rotate issuance between multiple > >

Re: CP/CPS intra-document cross-references

To provide some additional context, I'm currently conducting a thought experiment around the following question: What would a CP/CPS look like if it dedicated one sentence to every requirement (MUST/SHALL/etc) in the BRs, in the same section that the requirement appears? A CP/CPS with this format

CP/CPS intra-document cross-references

The Baseline Requirements have a few places where they require that a CA include specific information in a specific section of their CP/CPS. Two examples: Section 2.2 Publication of information > Section 4.2 of a CA's Certificate Policy and/or Certification Practice Statement SHALL state the CA's

Re: Improvements to Vulnerability Disclosure wiki page

I don't believe that Wayne was suggesting that *currently* exploitable vulnerabilities be disclosed -- responsible disclosure is critical. I think he was making a distinction between theoretical vulnerabilities (e.g. a machine was discovered to have a version of openssl vulnerable to Heart bleed)

Re: Unrestricted cross-signed Subordinate CA profile questions

rotection >> KeyPurposeIds in the same certificate.” >> >> >> >> So, although this EKU-less cross-certificate issued to CA Gamma is >> perfectly compliant with the BRs, it would run afoul of MRSP as CA Gamma’s >> key is not certified by a root certificate in

Re: Unrestricted cross-signed Subordinate CA profile questions

liant with the BRs, it would run afoul of MRSP as CA Gamma’s > key is not certified by a root certificate in the Mozilla root store. > > > > Thanks, > > Corey > > > > *From:* 'Aaron Gable' via dev-security-policy@mozilla.org < > dev-security-policy@mozilla.org&g

Re: Unrestricted cross-signed Subordinate CA profile questions

Yes, I completely agree that that *should* be the interpretation; I think it's clear that this is the *intended* interpretation. And to be clear, yes, we're imagining that Intermediate CA Gamma was issued in compliance with the current profiles, and therefore is a 7.1.2.6 Subordinate CA

Re: Unrestricted cross-signed Subordinate CA profile questions

Thomas, Apologies, you're totally correct -- but the prompt was not fully specified. Suppose further that CA Alpha and CA Beta are operated by the same organization. Thanks, Aaron On Tue, Aug 8, 2023 at 10:03 AM Thomas Zermeno wrote: > Phil, > > Presuming that CA Alpha and CA Beta are

Re: MRSP Policy v. 2.8.1 Finalization

Hi Ben, No objection to a Feb 15th date from me, everything here looks good. Aaron On Tue, Jan 24, 2023 at 3:08 PM Ben Wilson wrote: > Hi, > I haven't had anyone ask about the proposed effective date of this version > 2.8.1. I don't see any new requirements that would require lead time for >

Re: Policy 2.8.1: MRSP Issue #256: Requirement that Partitioned CRLs include an Issuing Distribution Point extension

nk of any issues that may arise with such an arrangement. I attempted > to capture this consideration in my language proposal on Github [1]. > > > > Thanks, > > Corey > > > > [1] > https://github.com/mozilla/pkipolicy/issues/256#issuecomment-1315648591 > > >

Re: Policy 2.8.1: MRSP Issue #256: Requirement that Partitioned CRLs include an Issuing Distribution Point extension

Github [1]. > > > > Thanks, > > Corey > > > > [1] > https://github.com/mozilla/pkipolicy/issues/256#issuecomment-1315648591 > > > > *From:* 'Aaron Gable' via dev-security-policy@mozilla.org < > dev-security-policy@mozilla.org> > *Sent:* Thur

Re: Policy 2.8.1: MRSP Issue #256: Requirement that Partitioned CRLs include an Issuing Distribution Point extension

Thanks Ben, this language seems reasonable to me (with one edit: the last acronym "CRL" needs to be plural). That said, rather than repeating-and-extending the BRs language, I would consider turning this requirement on its head: "Each URL listed in the JSON Array of Partitioned CRLs MUST match a

Re: Policy 2.8.1: MRSP Issue #243: Update periods for CPs and CPSes

Thoughts, in no particular order: - I am in favor of changing the requirement from "annually" to "every X days"; we've made similar changes to other requirements in the BRs and consistency even across requirement-sets is good. - Again from a consistency perspective, it's understood that "398 days"

Re: Creating 'CA Program' Bugzilla Product

Sounds like a great change! One question: I'm "subscribed" to the "NSS :: CA Certificate Compliance" component, and get emails for all new issues and updates in that component. Will that subscription automatically get moved over, or will I want to recreate it after the move? Thanks! Aaron On

Re: Clarifications for MRSP v.2.8 Effective Dates

It has generally been my belief that new requirements affect all *actions* (usually, but not always, signing actions) which take place after their effective date. If the requirement concerns the contents of certificates, then certificates issued on or after the effective date are covered. If the

Re: Certificate vulnerable to fermat factorization

Zlint also has a check for this in version 3.4.0 (released this month), and on master since July. On Sat, Oct 29, 2022 at 12:45 PM Hanno Böck wrote: > Hi, > > https://crt.sh/?id=7581884753=ocsp > is

Re: CRL partitioning and IDPs

> -Tim > > > > *From:* 'Aaron Gable' via dev-security-policy@mozilla.org < > dev-security-policy@mozilla.org> > *Sent:* Friday, October 14, 2022 3:44 PM > *To:* Corey Bonnell > *Cc:* Andrew Ayer ; 'Aaron Gable' via > dev-security-policy@mozilla.org > *Subje

Re: CRL partitioning and IDPs

On Fri, Oct 14, 2022 at 11:19 AM Corey Bonnell wrote: > Are you also considering filing an erratum against 5280 so this particular > PKI footgun can be addressed at the IETF? > Thank you for the reminder! I have done so just now. I'm not sure how long that process will take to work through

Re: CRL partitioning and IDPs

ine. The proximity to the winter holidays and year rollover causes > all sorts of fun silliness that’s generally best avoided. > > > > -Tim > > > > *From:* 'Aaron Gable' via dev-security-policy@mozilla.org < > dev-security-policy@mozilla.org> > *Sent:* Frid

Re: CRL partitioning and IDPs

To ensure that future parties don't have to have this same discussion again, I have put together a CA/BF ballot to update the BRs to explicitly require the distributionPoint field in sharded CRLs: https://github.com/cabforum/servercert/pull/396 I'm seeking endorsers so it can be given a ballot

Re: CRL partitioning and IDPs

On Wed, Oct 12, 2022 at 1:02 PM Corey Bonnell wrote: > My interpretation of this passage is that it is defining the required > scope of the CRL in the absence of the distributionPoint field. Namely, all > revoked certificates issued by the CA must be contained within the scope of > the CRL.

Re: CRL partitioning and IDPs

On Wed, Oct 12, 2022 at 7:07 AM Corey Bonnell wrote: > > A simple fix would be to require that CAs use HTTPS URLs for CRL shards, > > though this wouldn't be as strong as relying on indicators within the > CRL > > itself. > > I believe including the IDP is the better solution, for three reasons:

Re: CRL partitioning and IDPs

On Fri, Oct 7, 2022 at 8:49 AM Rob Stradling wrote: > > Although this "defect" remains in RFC5280, ISTM that the original X.509 > requirement is restored by MRSP section 5.2 [2], which says: > > *"CA operators MUST NOT issue ... partial/scoped CRLs that lack a > distributionPoint in a critical

Re: CRL partitioning and IDPs

and could not be relied upon in the general case. Aaron On Thu, Oct 6, 2022 at 12:43 PM Andrew Ayer wrote: > On Thu, 6 Oct 2022 12:33:17 -0700 > "'Aaron Gable' via dev-security-policy@mozilla.org" > wrote: > > > An older but still sufficiently-recent version of a different

Re: CRL partitioning and IDPs

On Thu, Oct 6, 2022 at 10:09 AM 'Corey Bonnell' via dev-security-policy@mozilla.org wrote: > > > Although the wording could be improved, this passage is rather clear that > the IDP extension with the distributionPoint field (which contains the URI > of the CRL, in the WebPKI case) must be

Re: Malformed Trustwave certificates in Mozilla's ca cert collection

Just to close the loop on this: Christopher Henderson has done some great work to get two new checks added to zlint testing for this circumstance: - https://github.com/zmap/zlint/pull/682 ensures that there is not a whole byte of zeros at the end of an encoded BIT STRING; and -

Re: CRL Issuance Frequency for non-published CRLs

ific cadence. >> >> >> >> Given this, I believe that it’s compliant to not publish CRLs that are >> signed by the CA. >> >> >> >> Thanks, >> >> Corey >> >> >> >> *From:* 'Aaron Gable' via dev-security-poli

CRL Issuance Frequency for non-published CRLs

Hi MDSP, Section 4.9.7 of the Baseline Requirements says (emphasis added): > If the CA *publishes* a CRL, then the CA SHALL update and reissue CRLs at least once every seven days, and the value of the nextUpdate field MUST NOT be more than ten days beyond the value of the thisUpdate field.

Re: Malformed Trustwave certificates in Mozilla's ca cert collection

On Tuesday, June 21, 2022 at 6:38:27 PM UTC-7 nolo...@gmail.com wrote: > > A small nit about this... The ITU standards says (from X.690, Section > 6.2): > > For the purposes of this Recommendation | International Standard only, > the bits of an octet are numbered from 8 to 1, where bit 8 is

Re: Malformed Trustwave certificates in Mozilla's ca cert collection

I just had to do a bunch of digging to fully understand what's going on here, so I figured I'd share for the benefit of everyone else. The keyUsage extension bitstring in these certificates is encoded as

Re: Use of crt.sh ID in Incident Reports

Fantastic! I will say that Let's Encrypt used this format for our recent reports and going into the process knowing that we had a well-specified format that didn't require querying crt.sh for unique IDs made putting together the lists of affected certs very nice. Aaron On Fri, Feb 18, 2022 at

Re: Revocation Reason Codes for TLS End-Entity Certificates

I think your position, that "revoke with reason X" is more specific than "revoke", and may compel CA action to update the reasonCode, makes sense. However, I think that interpretation has an unintended consequence that would need to be resolved before that interpretation could be taken as

Re: Revocation Reason Codes for TLS End-Entity Certificates

Even with a "default MUST" reading, I cannot see how it could be argued that updating the metadata of an already-revoked certificate falls under the definition of "to revoke", a term which is not defined in BRs 1.6.1 and so instead takes its default English definition of "to put an end to the

Re: Revocation Reason Codes for TLS End-Entity Certificates

It seems clear to me that a CSR cannot be proof of possession. It doesn't require a poorly-behaving reseller or RA. It just requires that a subscriber both a) upload their CSR somewhere, and then b) allow their domain registration to lapse. Then some other actor can register the same domain and

Re: Revocation Reason Codes for TLS End-Entity Certificates

All relevant language in the Baseline Requirements (for example, "The CA SHALL revoke a certificate within 24 hours if...") is related to when and how quickly a CA must revoke a certificate. I am not aware of any language in any root program requirements that requires a CA to update the reason

Re: Revocation Reason Codes for TLS End-Entity Certificates

I think there's been one additional piece of confusion here that I'd like cleared up. Kathleen's proposed text says: > - If the certificate subscriber requests that the CA revoke the certificate for keyCompromise, and has not previously demonstrated and cannot currently demonstrate possession of

Re: Revocation Reason Codes for TLS End-Entity Certificates

I appreciate the effort to balance the concerns of 1) How do we let a subscriber revoke for keyCompromise even if their key has been stolen and deleted?; and 2) How do we prevent a third party who has never held the key from revoking for keyCompromise? I think that the currently-proposed text

Re: Policy 2.8: MRSP Issue #178: Sunset SHA1

For the sake of completeness: Let's Encrypt / ISRG does not sign SHA-1 hashes for any purpose, and would be amenable to any sunset date. We do accept signatures over SHA-1 hashes of CSRs provided by subscribers, and of course accept SHA-1 hashes for the issuerKeyHash and issuerNameHash in OCSP

Re: Policy 2.8: MRSP Issue #226: Update the incorrect extensions item in section 5.2

A recently-relevant example could be "an OCSP Delegated Responder without the id-pkix-ocsp-nocheck extension". I think it is important to remove/improve the "SSL certificates that exclude SSL usage", given that a cert which does not have the TLSServerAuth EKU is by definition not an SSL

Re: Revocation Reason Codes for TLS End-Entity Certificates

Kathleen and Sam, comments inline: On Wed, Dec 29, 2021 at 2:11 PM Kathleen Wilson wrote: > 1) The first sentence of the second paragraph has been changed to make my > intent more clear, and I added a comment that we will need to determine an > effective-date because this means code changes

Re: Policy 2.8: MRSP Issue #235: Require CCADB Disclosure of Full CRLs (or equivalent JSON array) for CRLite

dev-security-policy@mozilla.org wrote: > Is there a preference for which provides the greatest clarity to CAs > (thinking especially of those that haven’t followed the ongoing development > of this over the last ~18 months)? > > On Nov 18, 2021, at 12:51 PM, 'Aaron Gable' via >

Re: Revocation Reason Codes for TLS End-Entity Certificates

I don't follow your argument about torturing the meaning of "provide". The other analogous instances of the word "provide" in the BRs are: - The CA SHALL provide a process for Subscribers to request revocation of their own Certificates. - The CA SHALL provide Subscribers... with clear instructions

Re: Revocation Reason Codes for TLS End-Entity Certificates

The language being used in this discussion so far does not seem to reflect the actual text of the BRs. A CA is currently under no obligation to "notify" the subscriber prior to revocation. Rather, a CA is under obligation to "work with the Subscriber... to establish whether or not the

Re: Revocation Reason Codes for TLS End-Entity Certificates

Comments inline: On Wed, Dec 1, 2021 at 5:16 PM Kathleen Wilson wrote: > *affiliationChanged* (3) > The CRLReason affiliationChanged (3) MUST be used when the subscriber has > requested that their certificate be revoked for this reason, or the CA has > verifiable evidence that the subscriber no

Re: Policy 2.8: MRSP Issue #235: Require CCADB Disclosure of Full CRLs (or equivalent JSON array) for CRLite

One point of interest here: although Apple's requirements reference the "Pertaining to Certificates Issued By This CA" section, and the github issue and email above reference the "Full CRL Issued by this CA" and "JSON Array of Partitioned CRLs" fields, these are in fact the same thing: those two

Re: Introducing Ryan Dickson

Welcome, Ryan, and enjoy your sabbatical, Ryan! Good to see that conservation-of-Ryans is alive and well. On Friday, October 29, 2021 at 11:01:45 AM UTC-7 Ryan Sleevi wrote: > Six months ago, I shared [1] that the Chrome Root Program was hiring and > building out a fuller team. I'm happy to