Skip to content

Bibliography

439 records.

Sections are storage shelves — records/<body>/ — not publisher attribution. Who published a document is publisher; its standing is maturity. See docs/scope.md §4.

academic

  • Direct Anonymous Attestation
    brickell-2004-daa · paper · source
  • BRON — Linking ATT&CK, CAPEC, CWE, CVE, CPE (Hemberg et al., 2020)
    bron · paper · white-paper · summarized · source
    The most directly relevant prior art: a reusable reference implementation of tmodel's CVE→CWE→CAPEC→ATT&CK backbone.
  • Is the Web Ready for OCSP Must-Staple?
    chung-2018-must-staple · paper · source
  • Examining the Impact of Provenance-Enabled Media on Trust and Accuracy Perceptions
    cscw-2023-provenance-trust · paper · source
  • A privacy threat analysis framework: supporting the elicitation and fulfillment of privacy requirements — Mina Deng, Kim Wuyts, Riccardo Scandariato, Bart Preneel, Wouter Joosen. Springer. 2011. doi:10.1007/s00766-010-0115-7
    deng-linddun-2011 · paper · summarized · source
  • Programming Semantics for Multiprogrammed Computations
    dennis-vanhorn-1966 · paper · source
  • New Directions in Cryptography
    diffie-hellman-1976 · paper · source
  • A Public Key Cryptosystem and a Signature Scheme Based on Discrete Logarithms
    elgamal-1985 · paper · source
  • Ten Risks of PKI: What You're not Being Told about Public Key Infrastructure
    ellison-schneier-2000-ten-risks · paper · source
  • Rethinking Trust in Forge-Based Git Security (gittuf)
    gittuf-2025 · paper · source
  • A Paradoxical Solution to The Signature Problem
    gmr-1984-paradoxical · paper · source
  • A Digital Signature Scheme Secure Against Adaptive Chosen-Message Attacks
    gmr-1988-adaptive · paper · source
  • Strong Signature Schemes
    gmy-1983-strong-signatures · paper · source
  • PKI: It's Not Dead, Just Resting
    gutmann-2002-pki-not-dead · paper · source
  • GVU 10th WWW User Survey: webmaster PICS labelling rates
    gvu-1998-webmaster-survey · dataset · source
  • The Confused Deputy (or why capabilities might have been invented)
    hardy-1988-confused-deputy · paper · source
  • Knowledge Graphs (Hogan et al., ACM Computing Surveys 54(4), 2021)
    hogan-kg-survey · paper · white-paper · summarized · source
    Best single orientation document; frames tmodel's RDF-vs-LPG model choice.
  • Signals of Provenance: Navigating Indicators in AI-Generated Media for Sighted and Blind Individuals
    ide-2025-signals-of-provenance · paper · source
  • in-toto: Providing farm-to-table guarantees for bits and bytes
    in-toto-2019 · paper · source
  • Guidelines for performing Systematic Literature Reviews in Software Engineering — 2007
    kitchenham-charters-2007 · paper · source
    The three-stage SLR structure - protocol, conduct, report - that docs/construction.md names as our method and did not hold a record for.
  • Constructing Digital Signatures from a One Way Function
    lamport-1979-one-way · paper · source
  • CRLite: A Scalable System for Pushing All TLS Revocations to All Browsers
    larisch-2017-crlite · paper · source
  • LINDDUN privacy threat modeling framework (linddun.org) — DistriNet Research Unit, KU Leuven. KU Leuven
    linddun-org · web · summarized · source
  • An End-to-End Measurement of Certificate Revocation in the Web's PKI
    liu-2015-revocation · paper · source
  • Exploiting Programmatic Behavior of LLMs: Dual-Use Through Standard Security Attacks — Daniel Kang, Xuechen Li, Ion Stoica, Carlos Guestrin, Matei Zaharia, Tatsunori Hashimoto. accepted at SAGAI'24 (IEEE SPW 2024). 2023-02-11. arXiv:2302.05733
    llm-programmatic-dual-use · paper · summarized · source
    Evidence that content filters are bypassed by classic program-attack techniques; names misuse / filter bypass as an AI threat type.
  • Macaroons: Cookies with Contextual Caveats for Decentralized Authorization in the Cloud
    macaroons-2014 · paper · source
  • Secrecy, Authentication, and Public Key Systems
    merkle-1979-thesis · paper · source
  • Protocols for Public Key Cryptosystems
    merkle-1980-protocols · paper · source
  • A Certified Digital Signature
    merkle-1989-certified · paper · source
  • Content Authenticities: A Discussion on the Values of Provenance Data for Creatives and Their Audiences
    moruzzi-2025-content-authenticities · paper · source
  • MulVAL: A Logic-based Network Security Analyzer (Ou et al., USENIX Security 2005)
    mulval · paper · white-paper · summarized · source
    Reference model for rule-based attack-path derivation; facts=nodes, rules=logic, derivation graph = the reviewable attack-path artifact.
  • Backstabber's Knife Collection: A Review of Open Source Software Supply Chain Attacks
    ohm-2020-backstabbers · paper · source
  • Risk Centric Threat Modeling: Process for Attack Simulation and Threat Analysis — Tony UcedaVélez, Marco M. Morana. John Wiley & Sons. 2015-05. doi:10.1002/9781118988374. ISBN 978-0-470-50096-5
    pasta-risk-centric-threat-modeling · book · source
  • AIP: Agent Identity Protocol for Verifiable Delegation Across MCP and A2A
    prakash-2026-aip · paper · source
  • Pre-trained Encoders in Self-Supervised Learning Improve Secure and Privacy-preserving Supervised Learning — Hongbin Liu, Wenjie Qu, Jinyuan Jia, Neil Zhenqiang Gong. accepted at SAGAI'24 (IEEE SPW 2024). 2022-12-06. arXiv:2212.03334
    pretrained-encoders-secure-learning · paper · summarized · source
    Model-level defenses for image classifiers, not GenAI systems; kept because it is a SAGAI'24 paper.
  • The PRISMA 2020 statement: an updated guideline for reporting systematic reviews — 2021
    prisma-2020 · paper · source
    Transparent reporting of what was found, screened and excluded, and why.
  • Proactive Software Supply Chain Risk Management Framework (P-SSCRM) Version 1 — 2024
    psscrm-v1 · paper · source
    72 tasks unifying SSDF, 800-161r1, SLSA, S2C2F, CNCF and SCVS. The sponsor asked for a task mapping in the final report.
  • Digitalized Signatures and Public-Key Functions as Intractable as Factorization
    rabin-1979-tr212 · paper · source
  • A Method for Obtaining Digital Signatures and Public-Key Cryptosystems
    rsa-1978 · paper · source
  • SAGAI — IEEE Security and Privacy workshop series on securing generative AI (2024–) — Mihai Christodorescu, John Mitchell, Somesh Jha, Khawaja Shams, Earlence Fernandes. IEEE Security and Privacy Workshops (SPW). 2024. https://sites.google.com/ucsd.edu/sagai25-ieee-sp/. https://sites.google.com/view/sagai-2026. https://ieeexplore.ieee.org/xpl/conhome/10579499/proceeding
    sagai-workshop · hierarchy · summarized · source
    The confirmed target of tmodel #13; parent record that groups the SAGAI papers.
  • Efficient Identification and Signatures for Smart Cards
    schnorr-1989-smartcards · paper · source
  • Efficient Signature Generation by Smart Cards
    schnorr-1991-jcryptology · paper · source
  • SDSI — A Simple Distributed Security Infrastructure, version 1.1
    sdsi-1-1 · spec · source
  • SecureChain — Knowledge Graph for Resilient, Trustworthy, Secure Software Supply Chains (Purdue, Proto-OKN)
    securechain-okn · web · implementation · summarized · source
    Direct domain analog: connecting components, artifacts and vulnerabilities as a graph — the pattern tmodel needs for the composition→weakness layer.
  • Introducing OCTAVE Allegro: Improving the Information Security Risk Assessment Process — Richard A. Caralli, James F. Stevens, Lisa R. Young, William R. Wilson. Software Engineering Institute, Carnegie Mellon University. 2007-05. CMU/SEI-2007-TR-012
    sei-octave-allegro-2007 · paper · summarized · source
  • Threat Modeling: A Summary of Available Methods — Nataliya Shevchenko, Timothy A. Chick, Paige O'Riordan, Thomas Patrick Scanlon, Carol Woody. Software Engineering Institute, Carnegie Mellon University. 2018-07. https://www.sei.cmu.edu/documents/569/2018_019_001_524597.pdf
    sei-threat-modeling-methods-2018 · paper · summarized · source
  • AMD SEV-SNP: A Confidential Computing Primer
    sev-snp-primer-2026 · paper · source
  • Algorithms for Quantum Computation: Discrete Logarithms and Factoring
    shor-1994 · paper · source
  • Polynomial-Time Algorithms for Prime Factorization and Discrete Logarithms on a Quantum Computer
    shor-1997 · paper · source
  • Sigstore: Software Signing for Everybody
    sigstore-2022 · paper · source
  • Defending Language Models Against Image-Based Prompt Attacks via User-Provided Specifications — Reshabh K Sharma, Vinayak Gupta, Dan Grossman. IEEE Security and Privacy Workshops (SPW) 2024 — SAGAI'24. 2024. 10579532
    spml-image-prompt-injection · paper · summarized · source
    Shows prompt injection through images and a specification-driven input check; widens the AI threat types the object model must express.
  • Defending Against Indirect Prompt Injection Attacks With Spotlighting — Keegan Hines, Gary Lopez, Matthew Hall, Federico Zarfati, Yonatan Zunger, Emre Kıcıman. Microsoft; accepted at SAGAI'24 (IEEE SPW 2024). 2024-03-20. arXiv:2403.14720
    spotlighting-indirect-prompt-injection · paper · summarized · source
    Defines indirect prompt injection and a cheap system-level defense; the threat applies to any AI feature that reads third-party text, tmodel's included.
  • SUDOKN — Supply and Demand Open Knowledge Network (Arizona State U., Proto-OKN)
    sudokn-okn · web · implementation · summarized · source
    Demonstrates cross-domain linking (products↔companies↔risk) at scale — the supply-chain-security use case tmodel aligns with.
  • Name-constraint prevalence among CCADB-disclosed intermediate CA certificates (original measurement, 2026-09-26)
    survey-2026-nameconstraints-measurement · dataset · source
  • Systems Security Foundations for Agentic Computing — Mihai Christodorescu, Earlence Fernandes, Ashish Hooda, Somesh Jha, Johann Rehberger, Kamalika Chaudhuri, Xiaohan Fu, Khawaja Shams, Guy Amir, Jihye Choi, Sarthak Choudhary, Nils Palumbo, Andrey Labunets, Nishit V. Pandya. 2025-12-01. arXiv:2512.01295
    systems-security-agentic-computing · paper · summarized · source
    Eleven real agent attacks mapped to classic security principles, plus the open problems; the systems view of AI security that the SAGAI papers point to.
  • Survivable key compromise in software update systems
    tuf-2010 · paper · source
  • Investigating the OpenPGP Web of Trust
    ulrich-2011-openpgp-wot · paper · source
  • Unifying Large Language Models and Knowledge Graphs: A Roadmap (Pan et al., IEEE TKDE 2024)
    unifying-llm-kg · paper · white-paper · summarized · source
    The 'synergized' pattern (LLM proposes, KG constrains/verifies) is essentially tmodel's AI-proposes/human-reviews design.
  • CAPMAS: Capability-Based Delegation of Privileges in Multi-Agent Systems
    veski-2026-capmas · paper · source
  • Typosquatting and Combosquatting Attacks on the Python Ecosystem
    vu-2020-typosquatting · paper · source
  • Reducing the Dependence of SPKI/SDSI on PKI
    wang-2006-reducing-spki · paper · source
  • Guidelines for snowballing in systematic literature studies and a replication in software engineering — 2014
    wohlin-2014-snowballing · paper · source
    Backward and forward snowballing iterated to closure. index/frontier.md is this, mechanised.
  • Analysis of SSL Certificate Reissues and Revocations in the Wake of Heartbleed
    zhang-2014-heartbleed · paper · source

c2pa

  • Content Credentials: C2PA Technical Specification 2.4
    c2pa-2-4 · spec · source
  • C2PA Conformance Program and Trust List
    c2pa-conformance-program · web · source
  • C2PA User Experience Guidance for Implementers 2.2
    c2pa-ux-2-2 · spec · source

community

  • Biscuit Specification v3.3
    biscuit-spec-3-3 · spec · source
  • CAWG Identity Assertion 1.2
    cawg-identity-1-2 · spec · source
  • Secure by Design v1.1: A Guide to Assessing Software Security Practices — Center for Internet Security (CIS), Software Assurance Forum for Excellence in Code (SAFECode). Center for Internet Security / SAFECode. 2026-07-09
    cis-safecode-sbd-assessment-1-1 · spec · best-practice · source
    Same content line as ETSI TS 104 219 (held in full); the CIS/SAFECode spreadsheet would be a machine-readable form but is registration-walled.
  • Software Supply Chain Best Practices v2 — CNCF Security Technical Advisory Group (TAG Security). 2025-03. https://github.com/cncf/tag-security/blob/main/community/working-groups/supply-chain-security/supply-chain-security-paper-v2/Software_Supply_Chain_Practices_whitepaper_v2.pdf
    cncf-supply-chain-best-practices-v2 · paper · white-paper · summarized · source
    Supplies the policy-evaluated-against-attestations model for automated gate checks (R-041/R-042), the Distributor party role and VEX status values, and 59 practice rows for the crosswalk (R-044).
  • Agentic AI Threat Modeling Framework: MAESTRO — Ken Huang. Cloud Security Alliance. 2025-02-06
    csa-maestro-2025 · web · summarized · source
  • Citation Style Language — schemas (CSL-JSON) — Citation Style Language project. 2023-01-25
    csl-json-schema · repo · unofficial · source
    CSL-JSON is the interchange format docs/construction.md selected over BibTeX; this repo is its normative schema.
  • CycloneDX Bill of Materials Specification — Jan Kowalleck, Steve Springett. OWASP Foundation / Ecma International. 2025-12. ECMA-424, 2nd edition (December 2025)
    cyclonedx-1-7 · spec · standard · source
  • Cytoscape.js documentation and project
    cytoscape-js · repo · summarized · source
    Primary capability and license evidence for the Cytoscape.js option in RPT-0006.
  • D3.js documentation and project
    d3-js · repo · summarized · source
    Primary capability and license evidence for the low-level D3 visualization path in RPT-0006.
  • The did:key Method v0.9
    did-key-method · spec · source
  • dCBOR: Deterministic CBOR — IETF. 2026-08-10. draft-mcnally-deterministic-cbor-18
    draft-mcnally-deterministic-cbor · draft · source
    An INDIVIDUAL draft with no IETF stream and no WG standing, widely miscited as 'the' deterministic CBOR profile. At -18 it narrows RFC 8949 Sec.4.2 directly and does not mention CDE, contrary to common secondary accounts.
  • event-stream issue #116: I don't know what to say.
    event-stream-issue-116 · web · source
  • FIRST, Common Vulnerability Scoring System (CVSS)
    first-cvss · spec · source
  • FIRST, Common Vulnerability Scoring System v3.1: Specification Document — FIRST (Forum of Incident Response and Security Teams)
    first-cvss-v3-1 · spec · source
  • FIRST, Common Vulnerability Scoring System v4.0: Specification Document — FIRST (Forum of Incident Response and Security Teams). 2023-11-01
    first-cvss-v4-0 · spec · source
  • backdoor in upstream xz/liblzma leading to ssh server compromise
    freund-2024-xz · web · source
  • Gephi desktop documentation and project
    gephi · repo · summarized · source
    Desktop analysis precedent and project scale-claim evidence for RPT-0006.
  • GHSA-mh6f-8j2x-4483 (event-stream / flatmap-stream)
    ghsa-event-stream · web · source
  • GnuPG manual: OpenPGP Key Management (tsign, trustspec)
    gnupg-key-management · web · source
  • in-toto Attestation Framework v1
    in-toto-attestation-v1 · spec · source
  • in-toto Attestation Framework: Envelope
    in-toto-envelope-v1 · spec · source
  • IPLD DAG-CBOR Specification — IPLD project (Protocol Labs)
    ipld-dag-cbor · spec · draft · source
    A deterministic CBOR profile in production use (IPFS/Filecoin); strict-mode evidence for DEC-002.
  • keys.openpgp.org FAQ: third-party certification policy
    keys-openpgp-org-faq · web · source
  • Kùzu graph database
    kuzu · repo · summarized · source
    Provides lifecycle and version context for Kùzu Explorer, but the database repository is archived.
  • Kùzu Explorer
    kuzu-explorer · repo · summarized · source
    Relevant local graph-query UI precedent, but archived and incompletely documented.
  • LinkML — Linked Data Modeling Language
    linkml · repo · implementation · summarized · source
    Author tmodel's threat/asset/CWE/CVE schema once → generate SHACL (validation) + OWL/RDF (graph); aligns with OKN peers for federation.
  • mcp-okn — Model Context Protocol access to NSF OKN graphs
    mcp-okn · repo · implementation · summarized · source
    Prior art for an LLM→governed-KG bridge — the pattern for grounding a threat-modeling assistant against tmodel's graph.
  • OWASP Application Security Verification Standard 5.0.0 — Elar Lang, Josh C Grossman, Jim Manico, Daniel Cuthbert. OWASP Foundation. 2025-05. ASVS-5.0.0. https://github.com/OWASP/ASVS/releases/tag/v5.0.0_release
    owasp-asvs-5 · spec · best-practice · distilled · source
    345 verifiable application requirements with versioned ids, cumulative levels, a stated documentation-vs-implementation split (R-040) and a pass/fail/N/A verification + report model (R-042/R-043); the content of a verification gate, though not an SDL process model.
  • OWASP DevSecOps Maturity Model (DSOMM) — OWASP DSOMM project (leaders: Timo Pagel, Aryan Prasad). OWASP Foundation (DSOMM project). 2026-09-21
    owasp-dsomm · spec · summarized · source
    Secondary: risk→measure activities with per-team implementation/evidence slots and SAMM/ISO/OpenCRE cross-references usable for the R-044 crosswalk.
  • OWASP pytm — OWASP
    owasp-pytm · repo · implementation · summarized · source
    Inspectable model-as-code precedent for a Python object model, rule-based threat generation, and generated diagrams and reports.
  • OWASP Software Assurance Maturity Model (SAMM) v2 — OWASP SAMM project (leaders: Seba Deleersnyder, Bart De Win), Pravir Chandra (original author of SAMM). OWASP Foundation (OWASP SAMM project). 2026-07
    owasp-samm-2 · spec · distilled · source
    The only SDL source published as typed, GUID-linked data, with OWASP's own typed crosswalk to SSDF, BSIMM, IEC 62443-4-1, NIST CSF 2.0 and the Microsoft SDL; the reference import case for R-044 and a scored-maturity input to R-041/R-042.
  • OWASP Threat Dragon — OWASP
    owasp-threat-dragon · repo · implementation · summarized · source
    Inspectable diagram-first implementation with editable threats and mitigations, repository storage, and a tool-specific JSON model.
  • OWASP Developer Guide — Threat Dragon — OWASP
    owasp-threat-dragon-guide · web · documentation · summarized · source
    OWASP guidance for Threat Dragon methods, editing flow, delivery modes, and reporting.
  • OWASP Threat Model Library and TM-BOM — OWASP
    owasp-threat-model-library · repo · draft · summarized · source
    Emerging neutral JSON threat-model interchange effort directly relevant to DEC-002 portability evidence.
  • Trusted Publishers for PyPI
    pypi-trusted-publishers · web · source
  • Fundamental Practices for Secure Software Development: Essential Elements of a Secure Development Lifecycle Program (Third Edition) — Tony Rice, Nazira Carlage, Josh Brown-White, Wendy Poland, Tania Skinner, Eric Heitzman, Nick Ozmore, Danny Dhillon. SAFECode (Software Assurance Forum for Excellence in Code). 2018-03
    safecode-fpssd-3 · spec · white-paper · distilled · source
    Industry practice baseline with the clearest statements of finding dispositions, TSRV risk acceptance with severity-tiered approvers, documentation-kind mitigations and 'controls as structured data' — inputs to R-040/R-042/R-043.
  • Dead Simple Signing Envelope (DSSE) — Secure Systems Lab. Secure Systems Lab (NYU) / secure-systems-lab. 2024-05
    secure-systems-lab-dsse · repo · unofficial · distilled · source
  • Sigma.js documentation and project
    sigma-js · repo · summarized · source
    Primary capability and license evidence for the Sigma.js rendering option in RPT-0006.
  • Sigstore Threat Model
    sigstore-threat-model · web · source
  • Mini Shai-Hulud: Where SLSA's Boundaries Fall
    slsa-2026-mini-shai-hulud · web · source
  • System Package Data Exchange (SPDX) Specification Version 3.0.1 — The Linux Foundation and its Contributors. The Linux Foundation. 2024-12-17
    spdx-3-0-1 · spec · source
  • StrictYAML — Why a restricted YAML subset — HitchDev
    strictyaml-why · web · unofficial · source
    States the case for a YAML subset and the Norway problem — type-inference hazards that bear directly on DEC-002.
  • Threagile — Threagile
    threagile · repo · implementation · summarized · source
    Inspectable YAML model, risk-rule engine, explicit risk tracking, generated outputs, and REST execution mode.
  • Threat Dragon Threat Model File format and TM-BOM direction — OWASP Threat Dragon project
    threat-dragon-tmf-format · web · draft · summarized · source
    Primary project note documenting the limits of Threat Dragon's tool-specific format and the TM-BOM successor direction.
  • Trike v.1 Methodology Document [Draft] — Paul Saitta, Brenda Larcom, Michael Eddington. OctoTrike. 2005-07-13. http://web.archive.org/web/20240117174652/https://www.octotrike.org/papers/Trike_v1_Methodology_Document-draft.pdf
    trike-v1-2005 · paper · summarized · source
  • The Update Framework Specification v1.0.36
    tuf-spec · spec · source
  • TAP 21: ML-DSA signing scheme for TUF metadata
    tuf-tap-21 · spec · source
  • XZ Utils backdoor (upstream project statement)
    tukaani-xz-backdoor · web · source
  • User Controlled Authorization Network (UCAN) Specification v1.0.0
    ucan-1-0 · spec · source
  • Real World Threat Modeling Using the PASTA Methodology — Tony UcedaVélez. OWASP (AppSec EU 2012 presentation). 2012
    ucedavelez-pasta-owasp-2012 · web · summarized · source
  • YAML Ain't Markup Language (YAML) version 1.2.2 — YAML Language Development Team. 2021-10-01
    yaml-1-2-2 · spec · unofficial · source
    The YAML spec our authored sources are written in; the baseline the StrictYAML critique narrows.
  • Authorization Capabilities (ZCAP-LD) v0.4.0-rc.6
    zcap-ld · spec · source

google

  • Android Key and ID Attestation
    android-key-attestation · web · source
  • Distrusting WoSign and StartCom Certificates
    google-2016-wosign · web · source
  • Chrome's Plan to Distrust Symantec Certificates
    google-2017-symantec · web · source
  • Open Profile for DICE
    google-open-dice · spec · source

ietf

  • Verifiable Attenuated Delegation for AI Agent Chains — IETF. draft-asor-wimse-agent-delegation-chain
    draft-asor-wimse-agent-delegation-chain · draft · source
  • Arm CCA Reference Attestation Token — IETF. draft-ffm-rats-cca-token
    draft-ffm-rats-cca-token · draft · source
  • An Attenuated Delegation Profile for Automated Agents — IETF. draft-hamr-oauth-agent-delegation
    draft-hamr-oauth-agent-delegation · draft · source
  • CDDL Module Structure — IETF. 2026-09-02. draft-ietf-cbor-cddl-modules-07
    draft-ietf-cbor-cddl-modules · draft · source
    Module structure for CDDL. Relevant the moment our schema stops being one file, which WP1 will reach quickly.
  • CBOR Common Deterministic Encoding (CDE) — IETF. 2026-04-16. draft-ietf-cbor-cde-13
    draft-ietf-cbor-cde · draft · source
    EXPIRED 2026-04-17 and parked. Recorded because it is still widely cited as the deterministic CBOR profile; the live work is draft-ietf-cbor-serialization.
  • Concise Diagnostic Notation (CDN) — IETF. 2026-07-20. draft-ietf-cbor-edn-literals-27
    draft-ietf-cbor-edn-literals · draft · source
    Diagnostic notation is how test vectors and spec examples are written. A product without it has no readable debug path.
  • Packed CBOR — IETF. 2026-08-06. draft-ietf-cbor-packed-19
    draft-ietf-cbor-packed · draft · source
    EXPIRED 2026-08-06 and not progressing. A compression layer we do not need; recorded so it is not presented as near-term.
  • CBOR Serialization and Determinism — IETF. 2026-07-30. draft-ietf-cbor-serialization-08
    draft-ietf-cbor-serialization · draft · source
    The live WG determinism work and the document a signing profile must target. The WG has not said it replaces CDE, so the edge is see_also, not supersedes.
  • SLH-DSA for JOSE and COSE — M. Prorock, O. Steele, H. Tschofenig. IETF. 2026-07-28. draft-ietf-cose-sphincs-plus-10
    draft-ietf-cose-sphincs-plus · draft · summarized · source
    The only wire binding for SLH-DSA. Answers what fips-205 could not: what an SLH-DSA signature looks like in COSE - and that only two of twelve parameter sets are registered.
  • Post-Quantum Key Encapsulation Mechanisms (PQ KEMs) for COSE — T. Reddy, A. Banerjee, H. Tschofenig. IETF. 2026-07-06. draft-ietf-jose-pqc-kem-06
    draft-ietf-jose-pqc-kem · draft · summarized · source
    Key encapsulation is confidentiality, not attestation - the same negative verdict recorded on fips-203. Held so the post-quantum COSE picture is complete, and because the WG rename makes it easy to miss.
  • Composite ML-DSA for use in X.509 Public Key Infrastructure — IETF. draft-ietf-lamps-pq-composite-sigs
    draft-ietf-lamps-pq-composite-sigs · draft · source
  • Concise Reference Integrity Manifest (CoRIM) — IETF. draft-ietf-rats-corim
    draft-ietf-rats-corim · draft · source
  • SCITT Reference APIs (SCRAPI) — IETF. draft-ietf-scitt-scrapi
    draft-ietf-scitt-scrapi · draft · source
  • Simple Public Key Certificate (expired, never published) — IETF. draft-ietf-spki-cert-structure
    draft-ietf-spki-cert-structure · draft · source
  • The vCon - Conversation Data Container - Overview — IETF. 2026-09. draft-ietf-vcon-overview-02
    draft-ietf-vcon-overview-02 · draft · informational · source
    Not yet read. Held as the informational companion to draft-ietf-vcon-vcon-core-04, whose FX-1 extraction is library#9. Deliberately carries no bears_on: DEC-005 is the envelope decision and R-M-11 is ArtifactId identification, and an informational overview settles neither. If reading it shows otherwise, add the edge then.
  • The JSON format for vCon - Conversation Data Container — IETF. 2026-09. draft-ietf-vcon-vcon-core-04
    draft-ietf-vcon-vcon-core-04 · draft · distilled · source
    An independently-designed signed container with must-understand extension semantics and a supersession model - the best available test of whether our statement form can express something we did not design.
  • An Agent Action Capsule Profile for SCITT — S. Mih. IETF. 2026-09-26. draft-mih-scitt-agent-action-capsule-05
    draft-mih-scitt-agent-action-capsule · draft · source
  • Attenuating Authorization Tokens for Agentic Delegation Chains — IETF. draft-niyikiza-oauth-attenuating-agent-tokens
    draft-niyikiza-oauth-attenuating-agent-tokens · draft · source
  • IETF Concise Binary Object Representation Maintenance and Extensions (CBOR) Working Group — IETF
    ietf-cbor-wg · consortium · source
    The body that controls the CBOR spec line and its extension points. Parent record for every CBOR WG document held here.
  • IETF CBOR Object Signing and Encryption (COSE) Working Group — IETF
    ietf-cose-wg · consortium · source
    The body that controls the COSE spec line. Parent record for every COSE document held here.
  • IETF SPKI Working Group charter and documents
    ietf-spki-wg · web · source
  • IETF Virtualized Conversations (vcon) Working Group — IETF. vcon
    ietf-vcon-wg · consortium · source
    _The WG record and the charter are one record by this library's convention (cf. ietf-cbor-wg, ietf-cose-wg): content.url is /wg//about/, which is where the charter lives. Members link here with part_of. Two things in the charter text worth checking when this is summarised, both bearing on library#9's extraction of the core draft. It charters "the use of an EXISTING mechanism for proving integrity and optionally authenticity" - which is the layering question the core record's design notes tested and rejected, and the charter's wording cuts both ways, since "define/specify the use of" still leaves the WG owing the placement rules that section 5.2 attempts. And it charters encryption "such that some parts of the vCon may be disclosed to different parties" - selective disclosure - which the extraction found the core draft cannot do: JWS signs the whole payload as opaque octets, so there is no partial verification and every change mints a new signed document. _
  • PEM Part II: Certificate-Based Key Management — IETF. RFC 1422
    rfc-1422 · rfc · source
  • GZIP — IETF. RFC 1952
    rfc-1952 · rfc · source
  • SPKI Requirements — C. Ellison. IETF. 1999-09. RFC 2692
    rfc-2692 · rfc · experimental · summarized · source
    The requirements document explaining WHY SPKI looks as it does. It is also the only place R-M-01 is argued from first principles rather than asserted: ASN.1 is ruled out, and sign-as-transmitted is stated as a requirement, which is R-O-03's problem posed before any canonical form existed.
  • SPKI Certificate Theory — C. Ellison, B. Frantz, B. Lampson, R. Rivest, B. Thomas, T. Ylonen. IETF. 1999-09. RFC 2693
    rfc-2693 · rfc · experimental · distilled · source
    The direct ancestor of this architecture. Its 5-tuple and AIntersect are what R-M-05 and R-M-08 restate, its ACL is R-M-02's unsigned local root, and its boolean-delegation decision is R-M-10. DEC-004 option 1 IS this document's tag language.
  • Internet X.509 PKI Certificate and CRL Profile (2002) — IETF. RFC 3280
    rfc-3280 · rfc · source
  • Timestamps — IETF. RFC 3339
    rfc-3339 · rfc · source
  • Internet X.509 PKI Proxy Certificate Profile — IETF. RFC 3820
    rfc-3820 · rfc · source
  • tel URI — IETF. RFC 3966
    rfc-3966 · rfc · source
  • GEOPRIV — IETF. RFC 4119
    rfc-4119 · rfc · source
  • UUID — IETF. RFC 4122
    rfc-4122 · rfc · source
  • OpenPGP Message Format — IETF. RFC 4880
    rfc-4880 · rfc · source
  • Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile — D. Cooper, S. Santesson, S. Farrell, S. Boeyen, R. Housley, W. Polk. IETF. 2008-05. RFC 5280
    rfc-5280 · rfc · standard · distilled · source
    R-M-01 names this document as what the native encoding SHALL NOT be, so the claim is only defensible if the record is real. Section 4.2.1.10 plus the 6.1.4 state variables are the closest thing in deployed PKI to scoped delegation, and #14 cannot be written honestly without them.
  • SMTP — IETF. RFC 5321
    rfc-5321 · rfc · source
  • Trust Anchor Format — IETF. RFC 5914
    rfc-5914 · rfc · source
  • Using Trust Anchor Constraints during Certification Path Processing — IETF. RFC 5937
    rfc-5937 · rfc · source
  • mailto URI — IETF. RFC 6068
    rfc-6068 · rfc · source
  • The OAuth 2.0 Authorization Framework — IETF. RFC 6749
    rfc-6749 · rfc · source
  • The OAuth 2.0 Authorization Framework: Bearer Token Usage — IETF. RFC 6750
    rfc-6750 · rfc · source
  • Updates to the Internet X.509 PKI Certificate and CRL Profile — IETF. RFC 6818
    rfc-6818 · rfc · source
  • X.509 Internet PKI Online Certificate Status Protocol (OCSP) — IETF. RFC 6960
    rfc-6960 · rfc · source
  • Certificate Transparency — IETF. RFC 6962
    rfc-6962 · rfc · source
  • Concise Binary Object Representation (CBOR) — C. Bormann, P. Hoffman. IETF. 2013-10. RFC 7049
    rfc-7049 · rfc · standard · source
    Obsoleted by RFC 8949; kept because deployed decoders and older profiles still cite it.
  • JWS — IETF. RFC 7515
    rfc-7515 · rfc · source
  • JWE — IETF. RFC 7516
    rfc-7516 · rfc · source
  • JSON Web Algorithms (JWA) — M. Jones. IETF. 2015-05. RFC 7518
    rfc-7518 · rfc · standard · summarized · source
    The JOSE half of the algorithm registry. COSE's design is legible as a set of deliberate departures from it, so holding both is what makes the comparison possible.
  • ChaCha20 and Poly1305 for IETF Protocols — IETF. 2015-05. RFC 7539
    rfc-7539 · rfc · informational · source
  • X.509v3 TLS Feature Extension (OCSP Must-Staple) — IETF. RFC 7633
    rfc-7633 · rfc · source
  • Proof-of-Possession Key Semantics for JSON Web Tokens (JWTs) — IETF. RFC 7800
    rfc-7800 · rfc · source
  • Edwards-Curve Digital Signature Algorithm (EdDSA) — IETF. RFC 8032
    rfc-8032 · rfc · source
  • CBOR Object Signing and Encryption (COSE) — J. Schaad. IETF. 2017-07. RFC 8152
    rfc-8152 · rfc · standard · source
    Obsoleted by RFC 9052 and RFC 9053; kept because deployed COSE stacks and older profiles still cite it.
  • Using RSA Algorithms with CBOR Object Signing and Encryption (COSE) Messages — M. Jones. IETF. 2017-09. RFC 8230
    rfc-8230 · rfc · standard · source
    Algorithm profile. ARCH-0001 NG3 defers the algorithm suite, so this is needed only if RSA is later admitted.
  • JSON — IETF. RFC 8259
    rfc-8259 · rfc · source
  • XMSS: eXtended Merkle Signature Scheme — IETF. RFC 8391
    rfc-8391 · rfc · source
  • CBOR Web Token (CWT) — M. Jones, E. Wahlstroem, S. Erdtman, H. Tschofenig. IETF. 2018-05. RFC 8392
    rfc-8392 · rfc · standard · source
    ARCH-0001 Sec.6 names COSE_Sign1 + CWT as an envelope candidate and asks that iss/sub align with the KeyId profile.
  • ChaCha20 and Poly1305 for IETF Protocols — Y. Nir, A. Langley. IRTF. 2018-06. RFC 8439
    rfc-8439 · rfc · informational · summarized · source
    The AEAD behind COSE alg 24. Held so that code point resolves, and because its standing - IRTF Informational, not IETF Standards Track - is exactly the trap library/CLAUDE.md warns about.
  • S/MIME Version 4.0 Certificate Handling — IETF. RFC 8550
    rfc-8550 · rfc · source
  • Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 4.0 Message Specification — J. Schaad, B. Ramsdell, S. Turner. IETF. 2019-04. RFC 8551
    rfc-8551 · rfc · standard · summarized · source
    It is a column in #14's table and the honest finding is a negative one: S/MIME 4.0 specifies no delegation and no trust model, deferring certificates entirely. Recording that is what stops the report inventing an S/MIME delegation story.
  • Leighton-Micali Hash-Based Signatures — IETF. RFC 8554
    rfc-8554 · rfc · source
  • Automatic Certificate Management Environment (ACME) — IETF. RFC 8555
    rfc-8555 · rfc · source
  • Concise Data Definition Language (CDDL): A Notational Convention to Express Concise Binary Object Representation (CBOR) and JSON Data Structures — H. Birkholz, C. Vigano, C. Bormann. IETF. 2019-06. RFC 8610
    rfc-8610 · rfc · standard · source
    DEC-002 option 2 is 'CBOR + CDDL as canonical'; this is the schema half of that option.
  • JMAP — IETF. RFC 8620
    rfc-8620 · rfc · source
  • Concise Binary Object Representation (CBOR) Sequences — C. Bormann. IETF. 2020-02. RFC 8742
    rfc-8742 · rfc · standard · source
    Framing for concatenated items: how a log or stream of statements is carried without an outer array.
  • Concise Binary Object Representation (CBOR) Tags for Typed Arrays — C. Bormann, Ed.. IETF. 2020-02. RFC 8746
    rfc-8746 · rfc · standard · source
    A registry-allocated extension point — the exact shape R-M-12 rules out of the native model.
  • Proof-of-Possession Key Semantics for CBOR Web Tokens (CWTs) — M. Jones, L. Seitz, G. Selander, S. Erdtman, H. Tschofenig. IETF. 2020-03. RFC 8747
    rfc-8747 · rfc · standard · source
    PoP confirmation claim for CWT. Prior art for binding a token to a key; not required by the current envelope options.
  • Cryptographic Message Syntax (CMS) Content Types for Concise Binary Object Representation (CBOR) — J. Schaad. IETF. 2020-03. RFC 8769
    rfc-8769 · rfc · informational · source
    Wraps CBOR in CMS. m-of-n does not use CMS; recorded so the question is not reopened.
  • Use of the HSS/LMS Hash-Based Signature Algorithm with CBOR Object Signing and Encryption (COSE) — R. Housley. IETF. 2020-04. RFC 8778
    rfc-8778 · rfc · standard · source
    Stateful hash-based signatures in COSE. Algorithm suite is deferred by NG3; relevant if post-quantum signing is admitted.
  • JSON Canonicalization Scheme (JCS) — A. Rundgren, B. Jordan, S. Erdtman. RFC Editor (Independent Submission stream — not IETF consensus). 2020-06. RFC 8785
    rfc-8785 · rfc · informational · distilled · source
  • CBOR Object Signing and Encryption (COSE) and JSON Object Signing and Encryption (JOSE) Registrations for Web Authentication (WebAuthn) Algorithms — M. Jones. IETF. 2020-08. RFC 8812
    rfc-8812 · rfc · standard · source
    The WebAuthn/COSE algorithm bridge. Evidence for the FIDO half of the ecosystem survey, not for our envelope.
  • Concise Binary Object Representation (CBOR) Tags for Date — M. Jones, A. Nadalin, J. Richter. IETF. 2020-11. RFC 8943
    rfc-8943 · rfc · standard · source
    Date tags 100/1004. Registry-dependent extension point; evidence for the R-M-12 argument.
  • Concise Binary Object Representation (CBOR) — C. Bormann, P. Hoffman. IETF. 2020-12. RFC 8949
    rfc-8949 · rfc · standard · distilled · source
    STD 94. DEC-002 option 2 makes this the candidate native encoding, and Sec.4.2 is the deterministic-encoding text every signing profile starts from.
  • Use of the Walnut Digital Signature Algorithm with CBOR Object Signing and Encryption (COSE) — D. Atkins. IETF. 2021-05. RFC 9021
    rfc-9021 · rfc · informational · source
    Informational registration for an algorithm outside any suite m-of-n would consider. Recorded so it is not re-evaluated.
  • CBOR Object Signing and Encryption (COSE): Structures and Process — J. Schaad. IETF. 2022-08. RFC 9052
    rfc-9052 · rfc · standard · distilled · source
    STD 96 with RFC 9338. COSE_Sign1 is one of the two envelope options in DEC-005, and its header parameters are IANA-allocated, so R-M-12 applies.
  • CBOR Object Signing and Encryption (COSE): Initial Algorithms — J. Schaad. IETF. 2022-08. RFC 9053
    rfc-9053 · rfc · informational · summarized · source
    The algorithm half of COSE. Updated by RFC 9864 — read them together or you will implement under-specified algorithm identifiers.
  • CBOR Object Signing and Encryption (COSE): Hash Algorithms — J. Schaad. IETF. 2022-08. RFC 9054
    rfc-9054 · rfc · informational · source
    R-M-07 requires artifact statements to bind a content digest; this registers the COSE hash algorithm identifiers for doing so.
  • JSON Web Token (JWT) Profile for OAuth 2.0 Access Tokens — IETF. RFC 9068
    rfc-9068 · rfc · source
  • Concise Binary Object Representation (CBOR) Tags for Object Identifiers — C. Bormann. IETF. 2021-07. RFC 9090
    rfc-9090 · rfc · standard · source
    OID tags — a second global naming authority inside the encoding. Directly contrary to key-relative naming (ARCH-0002 P1).
  • HTTP Semantics — IETF. RFC 9110
    rfc-9110 · rfc · source
  • Certificate Transparency Version 2.0 — IETF. RFC 9162
    rfc-9162 · rfc · source
  • Concise Binary Object Representation (CBOR) Tags for IPv4 and IPv6 Addresses and Prefixes — M. Richardson, C. Bormann. IETF. 2021-12. RFC 9164
    rfc-9164 · rfc · standard · source
    Address tags are not in our data model; kept as further evidence of registry-dependent extension points.
  • Additional Control Operators for the Concise Data Definition Language (CDDL) — C. Bormann. IETF. 2021-12. RFC 9165
    rfc-9165 · rfc · standard · source
    Control operators a real CDDL schema needs; a CDDL tool that omits them cannot validate our fixtures.
  • Encoding of Data Modeled with YANG in the Concise Binary Object Representation (CBOR) — M. Veillette, Ed., I. Petrov, Ed., A. Pelov, C. Bormann, M. Richardson. IETF. 2022-07. RFC 9254
    rfc-9254 · rfc · standard · source
    An application of CBOR (CORECONF), not a component of implementing it. Kept as prior art for schema-driven integer-key maps.
  • On Stable Storage for Items in Concise Binary Object Representation (CBOR) — M. Richardson, C. Bormann. IETF. 2022-08. RFC 9277
    rfc-9277 · rfc · standard · source
    Defines the CBOR file magic / labelled-content convention — how a stored statement file identifies itself.
  • Remote ATtestation procedureS (RATS) Architecture — IETF. RFC 9334
    rfc-9334 · rfc · source
  • CBOR Object Signing and Encryption (COSE): Countersignatures — J. Schaad. IETF. 2022-12. RFC 9338
    rfc-9338 · rfc · standard · source
    Part of STD 96 with RFC 9052. Countersignature is the closest COSE primitive to an endorsement over someone else's statement.
  • CBOR Object Signing and Encryption (COSE): Header Parameters for Carrying and Referencing X.509 Certificates — J. Schaad. IETF. 2023-02. RFC 9360
    rfc-9360 · rfc · standard · source
    X.509 carriage is the identifier model m-of-n is arguing against, but DEC-003 must say why, and interop may need it.
  • OAuth 2.0 Rich Authorization Requests — IETF. RFC 9396
    rfc-9396 · rfc · source
  • HTTP Message Signatures — IETF. RFC 9421
    rfc-9421 · rfc · source
  • OAuth 2.0 Demonstrating Proof of Possession (DPoP) — IETF. RFC 9449
    rfc-9449 · rfc · source
  • CBOR Object Signing and Encryption (COSE): AES-CTR and AES-CBC — R. Housley, H. Tschofenig. IETF. 2023-09. RFC 9459
    rfc-9459 · rfc · standard · source
    Content encryption modes. m-of-n signs rather than encrypts; kept for completeness of the COSE algorithm picture.
  • Ephemeral Diffie-Hellman Over COSE (EDHOC) — G. Selander, J. Preuss Mattsson, F. Palombini. IETF. 2024-03. RFC 9528
    rfc-9528 · rfc · standard · source
    A key exchange over COSE for constrained devices. Ecosystem evidence — m-of-n does not do key agreement.
  • Traces of Ephemeral Diffie-Hellman Over COSE (EDHOC) — G. Selander, J. Preuss Mattsson, M. Serafin, M. Tiloca, M. Vucinic. IETF. 2024-03. RFC 9529
    rfc-9529 · rfc · informational · source
    Test vectors for EDHOC, which we do not implement. Recorded to close the question.
  • Internationalization Updates to RFC 5280 — IETF. RFC 9549
    rfc-9549 · rfc · source
  • OpenPGP — P. Wouters, D. Huigens, J. Winter, Y. Niibe. IETF. 2024-07. RFC 9580
    rfc-9580 · rfc · standard · distilled · source
    The only record in this lane whose delegation mechanism is both a distinct subpacket and name-scoped by expression, and the only one that chose INTEGER delegation depth — the option RFC 2693 considered and rejected. R-I-04 names OpenPGP identity signatures explicitly, so the import mapping needs this document.
  • Concise Binary Object Representation (CBOR) Tags for Time, Duration, and Period — C. Bormann, B. Gamari, H. Birkholz. IETF. 2024-08. RFC 9581
    rfc-9581 · rfc · standard · source
    Validity windows on a certificate are time values; this is the registry-based way to carry them.
  • CBOR Object Signing and Encryption (COSE) "typ" (type) Header Parameter — M.B. Jones, O. Steele. IETF. 2024-06. RFC 9596
    rfc-9596 · rfc · standard · source
    Explicit typing of a signed object — the standard defence against cross-protocol confusion between statement kinds.
  • CBOR Web Token (CWT) Claims in COSE Headers — T. Looker, M.B. Jones. IETF. 2024-06. RFC 9597
    rfc-9597 · rfc · standard · source
    Puts CWT claims in the protected header, so a verifier reads issuer and subject without parsing the payload.
  • Internationalized Email Addresses in X.509 Certificates — IETF. RFC 9598
    rfc-9598 · rfc · source
  • No Revocation Available for X.509 Public Key Certificates — IETF. RFC 9608
    rfc-9608 · rfc · source
  • Updates to X.509 Policy Validation — IETF. RFC 9618
    rfc-9618 · rfc · source
  • Using Ephemeral Diffie-Hellman Over COSE (EDHOC) with the Constrained Application Protocol (CoAP) and Object Security for Constrained RESTful Environments (OSCORE) — F. Palombini, M. Tiloca, R. Hoglund, S. Hristozov, G. Selander. IETF. 2024-11. RFC 9668
    rfc-9668 · rfc · standard · source
    EDHOC/CoAP integration. Outside m-of-n's transport story; recorded to close the question.
  • CBOR Object Signing and Encryption (COSE) Key Thumbprint — K. Isobe, H. Tschofenig, O. Steele. IETF. 2024-12. RFC 9679
    rfc-9679 · rfc · standard · source
    DEC-003 lists 'COSE key thumbprint' as an option and requires canonical key bytes before hashing. This is that specification.
  • Updates to the Concise Data Definition Language (CDDL) Grammar — C. Bormann. IETF. 2024-11. RFC 9682
    rfc-9682 · rfc · standard · source
    Normative grammar corrections to RFC 8610; both remain current, so an implementation must read them together.
  • The Entity Attestation Token (EAT) — IETF. RFC 9711
    rfc-9711 · rfc · source
  • Concise Data Definition Language (CDDL): Additional Control Operators for the Conversion and Processing of Text — C. Bormann. IETF. 2025-03. RFC 9741
    rfc-9741 · rfc · standard · source
    Text-conversion control operators; needed where a CDDL schema constrains text representations.
  • A Concise Binary Object Representation (CBOR) Tag for Unprotected CBOR Web Token Claims Sets (UCCS) — H. Birkholz, J. O'Donoghue, N. Cam-Winget, C. Bormann. IETF. 2025-05. RFC 9781
    rfc-9781 · rfc · standard · source
    An unsigned claims set — the shape AclEntry takes in ARCH-0001. Also another registry-allocated tag, so it bears on R-M-12.
  • Simple Public Key Infrastructure (SPKI) S-Expressions — R. Rivest, D. Eastlake 3rd. IETF. 2025-06. RFC 9804
    rfc-9804 · rfc · informational · distilled · source
    DEC-002 option 1, and the only candidate whose canonical form states uniqueness as an explicit design goal (§6.2). Its §6.2/§6.4 canonical-for-signing versus advanced-for-display split is the architectural ancestor of R-O-05, and §10 imposes no verification ordering, so unlike RFC 8785 it does not conflict with R-O-05.
  • Fully-Specified Algorithms for JSON Object Signing and Encryption (JOSE) and CBOR Object Signing and Encryption (COSE) — M.B. Jones, O. Steele. IETF. 2025-10. RFC 9864
    rfc-9864 · rfc · standard · source
    Removes polymorphic algorithm identifiers. Anything implementing RFC 9053 today must apply this.
  • Internet X.509 Public Key Infrastructure — Algorithm Identifiers for the Module-Lattice-Based Digital Signature Algorithm (ML-DSA) — J. Massimo, P. Kampanakis, S. Turner, B. E. Westerbaan. IETF. 2025-10. RFC 9881
    rfc-9881 · rfc · standard · summarized · source
    Holds the argument RFC 9964 7.2 defers to. Without it the reason COSE excludes HashML-DSA was a citation the library could not check.
  • CBOR Object Signing and Encryption (COSE) Header Parameter for Timestamp Tokens as Defined in RFC 3161 — H. Birkholz, T. Fossati, M. Riechert. IETF. 2026-02. RFC 9921
    rfc-9921 · rfc · standard · source
    Carries an RFC 3161 timestamp in a COSE header. Relevant only if we need third-party time attestation.
  • CBOR Object Signing and Encryption (COSE) Receipts — O. Steele, H. Birkholz, A. Delignat-Lavaud, C. Fournet. IETF. 2026-06. RFC 9942. draft-ietf-cose-merkle-tree-proofs
    rfc-9942 · rfc · standard · distilled · source
    The receipt format the SCITT architecture (RFC 9943, already held) relies on. Directly relevant to the transparency story.
  • An Architecture for Trustworthy and Transparent Digital Supply Chains — H. Birkholz, A. Delignat-Lavaud, C. Fournet, Y. Deshpande, S. Lasker. IETF. 2026-06. RFC 9943
    rfc-9943 · rfc · standard · distilled · source
    The ratified, fully-worked version of the shape this project is designing — and its self-contradiction on rollback (§9.4.2 against §5.1.3) is a problem we inherit.
  • ML-DSA for JSON Object Signing and Encryption (JOSE) and CBOR Object Signing and Encryption (COSE) — M. Prorock, O. Steele. IETF. 2026-05. RFC 9964
    rfc-9964 · rfc · standard · summarized · source
    The current post-quantum signature binding for COSE, and the concrete mechanism behind R-M-02 for PQ keys: its AKP thumbprint rules (6) fix exactly which parameters enter a key digest. Upgraded from marginal on 2026-10-03 after reading 6 against rfc-9679.
  • CBOR Object Signing and Encryption (COSE) Hash Envelope — O. Steele, S. Lasker, H. Birkholz. IETF. 2026-07. RFC 9995
    rfc-9995 · rfc · standard · source
    Signing over a detached payload digest — the pattern R-M-07 describes for artifact statements that must not carry the artifact.
  • YANG-CBOR: Allocating SID Ranges for Private Enterprise Number (PEN) Holders — C. Bormann. IETF. 2026-07. RFC 9997
    rfc-9997 · rfc · standard · source
    SID range allocation for YANG-CBOR. Prior art for delegating an identifier space without a central registry per entry.

iso

  • IANA Concise Binary Object Representation (CBOR) Simple Values Registry
    iana-cbor-simple-values · dataset · source
    The second CBOR extension point. Smaller than the tag registry but governed the same way, so the R-M-12 argument must cover it.
  • IANA Concise Binary Object Representation (CBOR) Tags Registry
    iana-cbor-tags · dataset · source
    The central extension point of CBOR, and the single strongest piece of evidence for R-M-12: a native model built on it is registry-dependent.
  • IANA COSE Algorithms registry — IANA. 2026-10-03
    iana-cose-algorithms · dataset · summarized · source
    The authoritative list of what a COSE alg value may be. The RFCs each register a slice; only the registry says what is actually assigned, and checking it caught a stale code point in draft-ietf-cose-sphincs-plus.
  • IANA JSON Web Signature and Encryption Algorithms registry — IANA. 2026-10-03
    iana-jose-algorithms · dataset · summarized · source
    The JOSE counterpart to iana-cose-algorithms. Its Implementation Requirements column is the comparison COSE has no equivalent of, and it is where JOSE records which algorithms are Prohibited.
  • Security for industrial automation and control systems – Part 4-1: Secure product development lifecycle requirements — IEC TC 65. International Electrotechnical Commission (IEC) / ISA (ANSI/ISA-62443-4-1-2018). 2018-01-15. ANSI/ISA-62443-4-1-2018. EN IEC 62443-4-1:2018. IEC 62443-4-1:2018. ISBN 978-2-8322-5239-0
    iec-62443-4-1-2018 · spec · standard · summarized · source
    The most prescriptive SDL process standard: SR-2 is a DFD-shaped threat-model schema, SR-2 k)+SVV-2 define the threats-mitigated conformance check, SM-11/SM-12 define a release gate, and it is being harmonised for the EU CRA.
  • Health software and health IT systems safety, effectiveness and security – Part 5-1: Security – Activities in the product life cycle — IEC SC 62A / ISO TC 215 Joint Working Group. International Electrotechnical Commission (IEC) / International Organization for Standardization (ISO) — double logo. 2021-12. EN IEC 81001-5-1:2022. 13-122. IEC 81001-5-1:2021. IEC 81001-5-1:2021/ISH1:2025. https://www.iso.org/standard/76097.html
    iec-81001-5-1-2021 · spec · standard · summarized · source
    The medical-software derivative of 62443-4-1 (FDA-recognised, EN-adopted): contributes the 62304-ordered phase line, the two conformance routes, and ISH1's software-item support classes / risk-transfer model; normative activities unread (paywalled).
  • ISO 24089:2023, Road vehicles: Software update engineering — ISO. 2023-02-08. ISO 24089:2023
    iso-24089-2023 · spec · standard · source
  • ISO 26262-3:2018, Road vehicles — Functional safety — Part 3: Concept phase
    iso-26262-3-2018 · spec · source
  • ISO/IEC 11889:2015 Trusted Platform Module Library
    iso-iec-11889-2015 · spec · source
  • ISO/IEC 15408 (all parts), Evaluation criteria for IT security (Common Criteria)
    iso-iec-15408 · spec · source
  • ISO/IEC 18045, Methodology for IT security evaluation (attack potential)
    iso-iec-18045 · spec · source
  • ISO/IEC 19790:2012, Security requirements for cryptographic modules
    iso-iec-19790 · spec · source
  • ISO/IEC 24759:2017, Test requirements for cryptographic modules
    iso-iec-24759 · spec · source
  • Information technology — Security techniques — Application security — Part 1: Overview and concepts — ISO/IEC JTC 1/SC 27. ISO/IEC. 2011-11-21. ISO/IEC 27034-1:2011. 44378. ISO/IEC 27034-1:2011/Cor 1:2014
    iso-iec-27034-1 · spec · standard · summarized · source
    The most object-model-like SDL standard: ONF/ANF (catalogue vs per-application instantiation), the self-verifying ASC (activity + verification measurement + levels of trust, free official XSD), and Targeted vs Actual Level of Trust as the audit-gated 'declared secure' rule — direct input to R-041/R-042/R-043. Only the preview of Part 1 could be read.
  • ISO/IEC 29100:2024, Information technology: Security techniques: Privacy framework — ISO/IEC. 2024-02-16. ISO/IEC 29100:2024
    iso-iec-29100-2024 · spec · standard · source
  • Information technology — Security techniques — Vulnerability disclosure — ISO/IEC JTC 1/SC 27. ISO/IEC (JTC 1/SC 27). 2018-10. ISO/IEC 29147:2018
    iso-iec-29147-2018 · spec · standard · summarized · source
    The role vocabulary and verified/not-verified gate for vulnerability disclosure; field list for advisories; paired with 30111 it is the response phase of every SDL in MAP-0001. Full value needs a purchased copy (Clauses 6-9, Annex D).
  • Information technology — Security techniques — Vulnerability handling processes — ISO/IEC JTC 1/SC 27. ISO/IEC (JTC 1/SC 27). 2019-10. EN ISO/IEC 30111:2020. ISO/IEC 30111:2019
    iso-iec-30111-2019 · spec · standard · summarized · source
    Vendor-side vulnerability handling: the per-vulnerability lifecycle (DEC-009), a mandatory internal policy with checkable contents incl. a target remediation schedule (R-042/R-043), PSIRT organisation. Clause 7 needs a purchased copy.
  • ISO/IEC 5962:2021 SPDX Specification V2.2.1
    iso-iec-5962 · spec · source
  • Information technology — SPDX Specification V2.2.1 — ISO/IEC JTC 1/SC 7. International Organization for Standardization. 2021-08. ISO/IEC 5962:2021
    iso-iec-5962-2021 · spec · standard · source
    Held for the standing it establishes, not for its text: it is the one SBOM format with ISO ratification, and it carries SPDX 2.2.1, which SPDX 3.0.1 has moved past. Paywalled, so we work from the 3.0.1 record.
  • ISO/PAS 5112:2022, Road vehicles: Guidelines for auditing cybersecurity engineering — ISO. 2022-03-31. ISO/PAS 5112:2022
    iso-pas-5112-2022 · spec · source
  • Road vehicles — Cybersecurity engineering — ISO/SAE International. 2021-08. ISO/SAE 21434:2021
    iso-sae-21434-2021 · spec · standard · distilled · source
    The reference method for automotive threat modeling and risk: a structured TARA pipeline (asset -> threat scenario -> impact rating S/F/O/P -> attack path -> attack feasibility -> risk value -> treatment), a normative object model (Fig 3), and a requirement/work-product structure that is itself the template for automating conformance audits (tmodel #15).
  • ISO/SAE PAS 8475, Road vehicles: Cybersecurity Assurance Levels (CAL) and Targeted Attack Feasibility (TAF) — ISO/SAE International. ISO/SAE PAS 8475
    iso-sae-pas-8475 · spec · source
  • ISO/SAE TR 8477, Road vehicles: Cybersecurity verification and validation — ISO/SAE International. ISO/SAE TR 8477
    iso-sae-tr-8477 · spec · source
  • ITU-T X.509: The Directory - Public-key and attribute certificate frameworks
    itu-x509 · spec · source
  • ITU-T X.509 (1988): The Directory - Authentication framework
    itu-x509-1988 · spec · source

nist

  • CVE-2024-3094 (xz-utils backdoor, CVSS 10.0)
    cve-2024-3094 · dataset · source
  • FIPS 140-2, Security Requirements for Cryptographic Modules (superseded by FIPS 140-3)
    fips-140-2 · spec · source
  • FIPS 140-3, Security Requirements for Cryptographic Modules — NIST. 2019-03. doi:10.6028/NIST.FIPS.140-3. FIPS 140-3
    fips-140-3 · spec · standard · distilled · source
    A second, contrasting requirement framework: it ADOPTS another standard (ISO/IEC 19790) rather than restating requirements, and structures conformance as a 4-level x 11-area matrix validated by a program (CMVP). Exercises cross-document conformance (FIPS -> ISO 19790, modified by SP 800-140x) and shows requirement granularity varies by source (tmodel #5/#15).
  • Secure Hash Standard (SHS) — NIST. 2015-08. doi:10.6028/NIST.FIPS.180-4. FIPS 180-4
    fips-180-4 · spec · standard · summarized · source
    Defines the SHA-2 family. A principal named by key digest under R-M-02 is named by one of these functions, so which are approved is load-bearing on that naming.
  • FIPS 186: Digital Signature Standard (DSS), 1994
    fips-186 · spec · source
  • FIPS 186-1: Digital Signature Standard (DSS), 1998
    fips-186-1 · spec · source
  • FIPS 186-2: Digital Signature Standard (DSS), 2000
    fips-186-2 · spec · source
  • FIPS 186-3: Digital Signature Standard (DSS), 2009
    fips-186-3 · spec · source
  • Digital Signature Standard (DSS), FIPS 186-4 — NIST
    fips-186-4 · spec · historic · source
  • Digital Signature Standard (DSS) — NIST. 2023-02-03. doi:10.6028/NIST.FIPS.186-5. FIPS 186-5
    fips-186-5 · spec · standard · summarized · source
    Defines the signature schemes a key-centric model will actually use; supplies publisher test vectors for PROC-0002 stage 8.
  • Advanced Encryption Standard (AES) — National Institute of Standards and Technology. NIST. 2001-11-26. doi:10.6028/NIST.FIPS.197-upd1. FIPS 197
    fips-197 · spec · standard · summarized · source
    The block cipher every COSE and JOSE symmetric algorithm is built on. Held because rfc-9053 assigns code points for AES-GCM and AES-CCM and the library could not say what they were.
  • SHA-3 Standard: Permutation-Based Hash and Extendable-Output Functions — NIST. 2015-08. doi:10.6028/NIST.FIPS.202. FIPS 202
    fips-202 · spec · standard · summarized · source
    Defines SHA-3 and the SHAKE extendable-output functions. It does not replace FIPS 180-4 — both are approved, which is itself the finding a key-digest naming scheme has to resolve.
  • Module-Lattice-Based Key-Encapsulation Mechanism Standard — NIST. 2024-08-13. doi:10.6028/NIST.FIPS.203. FIPS 203
    fips-203 · spec · standard · summarized · source
    ML-KEM is key ENCAPSULATION - confidentiality, not authentication. Nothing in a key-centric statement model turns on it. Held as the post-quantum counterpart to the signature records, not because it bears on a requirement.
  • Module-Lattice-Based Digital Signature Standard — NIST. 2024-08-13. doi:10.6028/NIST.FIPS.204. FIPS 204
    fips-204 · spec · standard · summarized · source
    The NIST post-quantum signature standard most likely to be the default. Its key and signature sizes are what a key-centric statement model would actually carry, and its 255-byte context string is a domain-separation hook that lands near P4.
  • Stateless Hash-Based Digital Signature Standard — NIST. 2024-08-13. doi:10.6028/NIST.FIPS.205. FIPS 205
    fips-205 · spec · standard · summarized · source
    The conservative post-quantum signature fallback: its security rests only on hash functions, with no lattice assumption. Held as the hedge against ML-DSA, and as the record that shows what signature size a hash-based scheme actually costs.
  • NIST SP 800-140, FIPS 140-3 Derived Test Requirements (DTR): CMVP updates to ISO/IEC 24759 — NIST. SP 800-140
    nist-sp-800-140 · spec · best-practice · distilled · source
    Part of the FIPS 140-3 modification stack (SP 800-140); The Derived Test Requirements (DTR): the Test Evidence (TE) / Vendor Evidence (VE) items a CMVP lab uses to test a modul
  • NIST SP 800-140A, CMVP Documentation Requirements — NIST. SP 800-140A
    nist-sp-800-140a · spec · best-practice · distilled · source
    Part of the FIPS 140-3 modification stack (SP 800-140A); Additional vendor documentation requirements (VE additions) a module submission must provide.
  • NIST SP 800-140B, CMVP Security Policy Requirements — NIST. SP 800-140B
    nist-sp-800-140b · spec · best-practice · distilled · source
    Part of the FIPS 140-3 modification stack (SP 800-140B); Defines the content and tabular format of the cryptographic module security policy — the primary PUBLIC, auditable deliv
  • NIST SP 800-140C, CMVP Approved Security Functions — NIST. SP 800-140C
    nist-sp-800-140c · spec · best-practice · distilled · source
    Part of the FIPS 140-3 modification stack (SP 800-140C); The maintained LIST of CMVP-approved security functions (cryptographic algorithms), by reference to the NIST FIPS/SP cry
  • NIST SP 800-140D, CMVP Approved Sensitive Security Parameter Generation and Establishment Methods — NIST. SP 800-140D
    nist-sp-800-140d · spec · best-practice · distilled · source
    Part of the FIPS 140-3 modification stack (SP 800-140D); The maintained LIST of approved SSP (key) generation and establishment methods.
  • NIST SP 800-140E, CMVP Approved Authentication Mechanisms — NIST. SP 800-140E
    nist-sp-800-140e · spec · best-practice · distilled · source
    Part of the FIPS 140-3 modification stack (SP 800-140E); Approved authentication mechanisms and their strength requirements for module roles.
  • NIST SP 800-140F, CMVP Approved Non-Invasive Attack Mitigation Test Metrics — NIST. SP 800-140F
    nist-sp-800-140f · spec · best-practice · distilled · source
    Part of the FIPS 140-3 modification stack (SP 800-140F); Approved test metrics for non-invasive attack (e.g. side-channel) mitigation.
  • NIST SP 800-160, Systems Security Engineering (Ross et al., 2018)
    nist-sp-800-160 · spec · source
  • NIST IR 8547 ipd: Transition to Post-Quantum Cryptography Standards
    nistir-8547 · spec · source
  • NIST IR 8610: Status Report on the Second Round of the Additional Digital Signature Schemes
    nistir-8610 · spec · source
  • SP 1800-38: Migration to Post-Quantum Cryptography
    sp-1800-38 · spec · source
  • Cybersecurity Supply Chain Risk Management Practices for Systems and Organizations — Jon Boyens, Angela Smith, Nadya Bartol, Kris Winkler, Alex Holbrook, Matthew Fallon. NIST. 2022-05. doi:10.6028/NIST.SP.800-161r1-upd1. SP 800-161r1-upd1
    sp-800-161r1 · spec · best-practice · source
    Enterprise process guidance, not a mechanism specification. Supplies the vocabulary and the institutional frame that an attestation is consumed by, but we conform to no clause in it.
  • Recommendations for Discrete Logarithm-based Cryptography: Elliptic Curve Domain Parameters — Lily Chen, Dustin Moody, Karen Randall, Andrew Regenscheid, Angela Robinson. NIST. 2023-02. doi:10.6028/NIST.SP.800-186. SP 800-186
    sp-800-186 · spec · best-practice · summarized · source
    Fixes the curve set a federal-facing ECDSA or EdDSA key may come from. A principal named by key or key digest under R-M-02 is named by a point on one of these curves, so which curves are approved bounds that naming — even though ARCH-0001 NG3 defers the suite choice itself.
  • SP 800-204D: Strategies for the Integration of Software Supply Chain Security in DevSecOps CI/CD Pipelines — Ramaswamy Chandramouli, Frederick Kautz, Santiago Torres-Arias. National Institute of Standards and Technology (NIST). 2024-02. doi:10.6028/NIST.SP.800-204D. SP 800-204D
    sp-800-204d · spec · best-practice · distilled · source
    Pipeline-level operationalisation of SSDF PO/PS/PW.5-9 with a source-published SSDF mapping; its signed-policy-over-typed-attestations admission pattern is the clearest template for an automatable SDL Gate / conformance check (R-041/R-042).
  • Recommendation for Stateful Hash-Based Signature Schemes — NIST. 2020-10. doi:10.6028/NIST.SP.800-208. SP 800-208
    sp-800-208 · spec · best-practice · summarized · source
    Approves LMS/HSS and XMSS/XMSS-MT - signature schemes whose security rests only on the hash function, and whose STATEFULNESS makes key reuse a correctness failure rather than a weakness. That constraint bears directly on signing canonical bytes.
  • SP 800-218: Secure Software Development Framework (SSDF) Version 1.1: Recommendations for Mitigating the Risk of Software Vulnerabilities — Murugiah Souppaya, Karen Scarfone, Donna Dodson. National Institute of Standards and Technology (NIST). 2022-02. doi:10.6028/NIST.SP.800-218. NIST SP 800-218
    sp-800-218 · spec · best-practice · distilled · source
    Backbone requirement set for the SDL object: 42 stable, machine-readable task ids with the source's own crosswalk to 29 practice documents (1,483 identifiers) and to EO 14028; PW.1.1/PW.1.2/PW.2.1 make the threat model a reviewed SDL artifact.
  • Secure Software Development Practices for Generative AI and Dual-Use Foundation Models: An SSDF Community Profile — Harold Booth, Murugiah Souppaya, Apostol Vassilev, Michael Ogata, Martin Stanley, Karen Scarfone. National Institute of Standards and Technology (NIST); co-author from CISA. 2024-07. doi:10.6028/NIST.SP.800-218A. NIST SP 800-218A
    sp-800-218a · spec · best-practice · distilled · source
    The only NIST SSDF Community Profile: it shows the overlay mechanism (priority + R/C/N additions + modified/new tasks over a base requirement set) that the R-044 crosswalk and R-042 conformance need, and it supplies the AI-specific threat types and artifacts (weights, datasets, training pipelines) that a threat model of an AI system has to cover.
  • Secure Software Development Framework (SSDF) Version 1.2: Recommendations for Mitigating the Risk of Software Vulnerabilities (Initial Public Draft) — Harold Booth, Michael Ogata, Murugiah Souppaya, Karen Kent, Donna Dodson. National Institute of Standards and Technology (NIST). 2025-12-17. doi:10.6028/NIST.SP.800-218r1.ipd. NIST SP 800-218r1 ipd
    sp-800-218r1 · spec · draft · distilled · source
    Draft successor to the SSDF backbone: adds PO.6 (continuous improvement) and PS.4 (robust updates/rollback), remaps SP 800-53 to Release 5.2.0, drops EO 14028 mapping. Use as a delta over sp-800-218 until final.
  • Recommendation for Block Cipher Modes of Operation: Methods and Techniques — Morris Dworkin. NIST. 2001-12. doi:10.6028/NIST.SP.800-38A. SP 800-38A
    sp-800-38a · spec · best-practice · summarized · source
    Defines CBC, which JOSE uses in the A128CBC-HS256 family. Held for that one mode; the other four are background.
  • Recommendation for Block Cipher Modes of Operation: The CCM Mode for Authentication and Confidentiality — Morris Dworkin. NIST. 2004-05. doi:10.6028/NIST.SP.800-38C. SP 800-38C
    sp-800-38c · spec · best-practice · summarized · source
    CCM is the mode behind the eight AES-CCM-* code points in rfc-9053 4.2 — the largest single algorithm family in the COSE initial set.
  • Recommendation for Block Cipher Modes of Operation: Galois/Counter Mode (GCM) and GMAC — Morris Dworkin. NIST. 2007-11. doi:10.6028/NIST.SP.800-38D. SP 800-38D
    sp-800-38d · spec · best-practice · summarized · source
    GCM is A128GCM/A192GCM/A256GCM in both rfc-9053 and rfc-7518. Its IV-uniqueness requirement is the sharpest operational constraint in the symmetric set and belongs on record.
  • Recommendation for Block Cipher Modes of Operation: Methods for Key Wrapping — Morris Dworkin. NIST. 2012-12. doi:10.6028/NIST.SP.800-38F. SP 800-38F
    sp-800-38f · spec · best-practice · summarized · source
    AES Key Wrap is the KW half of JOSE A128KW/A192KW/A256KW and of every ML-KEM+AxxxKW composite in draft-ietf-jose-pqc-kem. #8 lists it as ingest-if-needed; the post-quantum KEM draft is the path that needs it.
  • SP 800-53 Rev. 5: Security and Privacy Controls for Information Systems and Organizations — Joint Task Force. National Institute of Standards and Technology (NIST), Joint Task Force. 2020-09. doi:10.6028/NIST.SP.800-53r5. SP 800-53 Rev. 5. https://github.com/usnistgov/oscal-content/blob/main/nist.gov/SP800-53/rev5/json/NIST_SP-800-53_rev5_catalog.json
    sp-800-53r5 · spec · best-practice · summarized · source
    The federal control catalog every SDL framework maps into: SSDF and SP 800-161 cite SP80053 ids per task, so SA/SR ids are the join key of the R-044 crosswalk; SA-11(2) mandates developer threat modeling with contextual information, tools, rigor and acceptance criteria — a ready-made R-042 conformance shape.
  • Recommendation for Pair-Wise Key-Establishment Schemes Using Discrete Logarithm Cryptography — Elaine Barker, Lily Chen, Allen Roginsky, Apostol Vassilev, Richard Davis. NIST. 2018-04. doi:10.6028/NIST.SP.800-56Ar3. SP 800-56Ar3
    sp-800-56ar3 · spec · best-practice · summarized · source
    Named in SP 800-186 Table 2 as the authority for the allowed key-establishment usage of P-224/256/384/521. The library cited that table without holding the document it points at.
  • Recommendation for Key Management: Part 1 - General — NIST. 2020-05. doi:10.6028/NIST.SP.800-57pt1r5. SP 800-57pt1r5
    sp-800-57pt1r5 · spec · best-practice · summarized · source
    Supplies the key-lifecycle vocabulary - cryptoperiod, key state, algorithm strength, transition - that a model naming principals by key needs in order to say what happens when a key expires. We conform to no clause in it.

oasis

  • STIX Version 2.1 (OASIS Standard)
    stix-2-1 · spec · standard · summarized · source
    Proven graph schema to align tmodel to (Vulnerability↔CVE, Attack Pattern↔threat, Course of Action↔mitigation); Opinion/Note map onto the human-review layer.

openssf

  • GUAC — Graph for Understanding Artifact Composition (OpenSSF)
    guac · repo · implementation · summarized · source
    Closest working analog to tmodel's supply-chain portion; its 3-tree split maps to assets/components vs threats/mitigations vs review provenance.
  • Concise Guide for Developing More Secure Software — OpenSSF (Best Practices Working Group). 2023-06-14
    openssf-concise-guide-secure-software · web · best-practice · summarized · source
    Useful as a crosswalk row source and as a map of which heavier frameworks OpenSSF delegates to; no structure, levels or conformance criteria of its own.
  • Open Source Project Security Baseline (OSPS Baseline) v2026.08.28 — OSPS Baseline Authors (OpenSSF Security Baseline SIG). OpenSSF (Security Baseline SIG, ORBIT WG). 2026-08-28. osps-baseline (ControlCatalog, gemara-version 1.2.0)
    openssf-osps-baseline · spec · best-practice · distilled · source
    MUST-only, level-scoped, machine-readable conformance catalog with source-published crosswalks to 14 frameworks; the template for the R-042 automatable conformance check and the R-044 Requirement/maps_to model.
  • OpenSSF Scorecard — Check Documentation (v5.5.0) — OpenSSF (Scorecard project). 2026-04-23
    openssf-scorecard-checks · web · implementation · summarized · source
    Working model of automated, graded, evidence-backed conformance checks (Check -> Probe -> Finding with six-valued outcome) for R-042, and the probe set is the unit the OSPS Baseline maps to (R-044).
  • OSV Schema (OpenSSF)
    osv-schema · spec · best-practice · summarized · source
    Best template for linking tmodel vuln nodes to specific component/version nodes.
  • SLSA Specification v1.2 — OpenSSF (SLSA project). 2025-11-24. https://slsa.dev/provenance/v1. https://slsa.dev/verification_summary/v1
    slsa-1-2 · spec · standard · distilled · source
    Template for the R-042 conformance result (VSA: verifier, policy pin, input attestations, PASSED/FAILED, levels), Level/Track vs Gate distinction for R-041, supply-chain threat categories A-I for R-037, and a source-control sub-model tmodel lacks.
  • SLSA Provenance v1.1 (SLSA Specification v1.2) — Open Source Security Foundation (OpenSSF)
    slsa-provenance-1-2 · spec · source
    Named in the PLAN-0001 §15 seed; not yet assessed against a decision.
  • SLSA Verification Summary Attestation (VSA) v1.1 — Open Source Security Foundation (OpenSSF)
    slsa-vsa-1-2 · spec · source
    Named in the PLAN-0001 §15 seed; not yet assessed against a decision.

other

  • Ballot SC-063v4: Make OCSP Optional, Require CRLs
    cabforum-sc063 · web · source
  • CA/Browser Forum Baseline Requirements for S/MIME Certificates
    cabforum-smime-br · spec · source
  • CA/Browser Forum Baseline Requirements for TLS Server Certificates
    cabforum-tls-br · spec · source
  • MITRE CAPEC — Common Attack Pattern Enumeration and Classification
    capec · dataset · best-practice · summarized · source
    Supplies tmodel's weakness→attack-pattern→technique edges.
  • Common CA Database (CCADB) public reports
    ccadb · dataset · source
  • Timeline of the xz open source attack
    cox-2024-xz-timeline · web · source
  • CVE JSON Record Format v5
    cve-json-5 · spec · standard · summarized · source
    Canonical ingestion schema for tmodel's Vulnerability nodes; defines CVE→CWE edge + severity.
  • MITRE CWE — Common Weakness Enumeration
    cwe · dataset · best-practice · summarized · source
    Source for tmodel's Weakness nodes and their hierarchy; XSD validates ingestion. Ties to ARCH-0001 §3.
  • MITRE D3FEND — defensive countermeasures knowledge graph (OWL)
    d3fend · spec · recommendation · summarized · source
    Authoritative mitigations layer with defense→offense edges; directly importable if tmodel is RDF; DAO seeds asset/component modeling.
  • ECMA-424 CycloneDX Bill of Materials Specification, 2nd Edition
    ecma-424 · spec · source
  • An Observatory for the SSLiverse
    eff-2010-ssliverse · paper · source
  • Securing Artificial Intelligence (SAI); Baseline Cyber Security Requirements for AI Models and Systems — ETSI Technical Committee Securing Artificial Intelligence (SAI). ETSI. 2025-12. EN 304 223 V2.1.1. REN/SAI-0022
    etsi-en-304-223 · spec · standard · distilled · source
    The only ratified, testable requirement set in the #13 source family: 72 provisions across the AI lifecycle, including AI-specific threat modelling (5.1.3-1) and human oversight (5.1.4).
  • ETSI TS 102 165-1, CYBER; Methods and protocols; Part 1: Method and proforma for Threat, Vulnerability, Risk Analysis (TVRA)
    etsi-ts-102-165-1 · spec · source
  • Cyber Security (CYBER); Software Security Development and Implementation Framework (SSDIF) — ETSI Technical Committee Cyber Security (CYBER). ETSI (European Telecommunications Standards Institute). 2026-03. ETSI TS 104 219 V1.1.1 (2026-03). DTS/CYBER-00190
    etsi-ts-104-219 · spec · standard · distilled · source
    SSDF-native, normative (183 shall/should actions) SDL with tiered applicability (Development Groups), per-task evidence (DG Artifacts) and roles, and a published SSDF-pivot crosswalk to 29 frameworks plus CRA and UK CRT APC — direct input to MAP-0001, R-042 and R-044.
  • EVITA Deliverable D2.3: Security requirements for automotive on-board networks based on dark-side scenarios — 2009-12. doi:10.5281/zenodo.1188418
    evita-d2-3 · paper · source
  • Black Tulip: Report of the investigation into the DigiNotar CA breach
    foxit-2012-black-tulip · article · source
  • FRINK — FabRic Integrating Networked Knowledge (RENCI, Proto-OKN Theme 2)
    frink-fabric · repo · implementation · summarized · source
    Concrete blueprint for federating multiple KGs under one endpoint with per-graph provenance and stable identifiers — the mechanism tmodel needs for attribution/governance and any OKN federation.
  • Go crypto/x509 name-constraint defects (five CVEs, 2025-2026)
    go-nameconstraint-cves · dataset · source
  • TUBITAK Kamu SM root should be constrained (golang/go#61963)
    golang-61963 · web · source
  • GraphRAG (Microsoft Research, 2024)
    graphrag-ms · repo · implementation · summarized · source
    Models the build-graph-then-reason pipeline over a security corpus for grounding AI-proposed threats.
  • Revocation doesn't work
    langley-2011-revocation · web · source
  • No, don't enable revocation checking
    langley-2014-revchecking · web · source
  • OCSP Service Has Reached End of Life
    letsencrypt-ocsp-eol · web · source
  • MITRE ATT&CK (knowledge base + STIX 2.1 data)
    mitre-attack · dataset · best-practice · summarized · source
    Canonical vocabulary/IDs for tmodel's threat + attack-path layer; ready-made graph-ingestion source.
  • MITRE ATT&CK: Design and Philosophy — Blake E. Strom, Andy Applebaum, Doug P. Miller, Kathryn C. Nickels, Adam G. Pennington, Cody B. Thomas. The MITRE Corporation. 2020-03
    mitre-attack-design-philosophy · paper · summarized · source
  • NSF 23-571: Building the Prototype Open Knowledge Network (Proto-OKN) — U.S. National Science Foundation. 2023
    nsf-23-571 · web · informational · summarized · source
    Defines / demonstrates a national federated knowledge-graph infrastructure with a verifiable, attributed, governed knowledge layer for grounding AI — the properties tmodel wants for human-reviewed threat models — and treats supply-chain cybersecurity as a use case tmodel could align or federate with.
  • NSF Open Knowledge Network (NSF OKN) — public launch — U.S. National Science Foundation. 2026
    nsf-okn-launch · web · informational · summarized · source
    Defines / demonstrates a national federated knowledge-graph infrastructure with a verifiable, attributed, governed knowledge layer for grounding AI — the properties tmodel wants for human-reviewed threat models — and treats supply-chain cybersecurity as a use case tmodel could align or federate with.
  • Open Knowledge Network Roadmap: Powering the Next Data Revolution (NSF/OSTP, 2022)
    okn-roadmap-2022 · web · informational · summarized · source
    Method for eliciting use cases + end-user requirements — reusable for scoping tmodel's KG; sets the OKN vision tmodel could federate with.
  • CVE-2022-3786 and CVE-2022-3602: X.509 Email Address Buffer Overflows
    openssl-2022-email-overflow · web · source
  • PCI Secure Software Lifecycle (Secure SLC) Standard v2.0 — PCI Security Standards Council. PCI Security Standards Council, LLC. 2026-09-28
    pci-secure-slc-2 · spec · standard · summarized · source
    Process-level SDL standard with a formal assessor/listing programme, but the v2.0 text is licence-walled; only public programme facts are usable until a licensed copy is reviewed.
  • SAE J3061, Cybersecurity Guidebook for Cyber-Physical Vehicle Systems (superseded by ISO/SAE 21434)
    sae-j3061 · spec · source
  • Attack Trees — Bruce Schneier. Dr. Dobb's Journal. 1999-12
    schneier-attack-trees-1999 · article · summarized · source
  • SolarWinds Form 8-K, Item 8.01, 14 December 2020
    solarwinds-8k · web · source
  • DICE Certificate Profiles r01
    tcg-dice-cert-profiles · spec · source
  • Hardware Requirements for a Device Identifier Composition Engine r78
    tcg-dice-hw-requirements · spec · source
  • Implicit Identity Based Device Attestation v1 r0.93
    tcg-dice-implicit-identity · spec · source
  • DICE Layering Architecture v1.0 r0.19
    tcg-dice-layering · spec · source
  • Symmetric Identity Based Device Attestation v1 r0p94
    tcg-dice-symmetric · spec · source
  • TCG Guidance on Integrity Measurements and Event Log Processing v1 r0p118
    tcg-integrity-event-log · spec · source
  • TCG PC Client Platform Firmware Profile Specification r1.05
    tcg-pc-client-pfp · spec · source
  • TCG PC Client Platform TPM Profile (PTP) for TPM 2.0 v1.06 r32
    tcg-pc-client-ptp · spec · source
  • TPM Main Specification Version 1.2, Level 2, Revision 116
    tcg-tpm-1-2-main · spec · source
  • TPM 2.0 Library Specification, Parts 0-4, Version 184
    tcg-tpm-2-0-library-184 · spec · source
  • TPM 2.0 Library Specification v1.85 (PQC: ML-KEM, ML-DSA)
    tcg-tpm-2-0-library-185 · spec · source
  • TPM 2.0 Keys for Device Identity and Attestation v1 r12
    tcg-tpm2-keys-device-identity · spec · source
  • Names: Decentralized, Secure, Human-Meaningful: Choose Two
    zooko-2001-names · article · source

regulator

  • BSI TR-03183-1 Cyber Resilience Requirements for Manufacturers and Products, Part 1: General requirements — Bundesamt für Sicherheit in der Informationstechnik (BSI). Bundesamt für Sicherheit in der Informationstechnik (BSI) / Federal Office for Information Security. 2026-07-31. TR-03183-1
    bsi-tr-03183-1 · spec · best-practice · distilled · source
    BSI's CRA interpretation: an assessable risk-handling method (11 MUST activity controls), Activity/Mechanism/Documentation control types matching R-040, PASS/FAIL/N/A verdict and applicability statement for R-042, CRA Annex I sub-ids for R-044, and machine-matchable risk-scenario control selection.
  • BSI TR-03185 Secure Software Lifecycle — Bundesamt für Sicherheit in der Informationstechnik (BSI). Bundesamt für Sicherheit in der Informationstechnik (BSI) / Federal Office for Information Security. 2026-07-02. TR-03185
    bsi-tr-03185 · spec · best-practice · distilled · source
    National SDL requirement set with native ids, a mandatory content-specified threat model (PROD.DEV.C), an explicit release gate, a certification/audit scheme, and a BSI-published requirement-level crosswalk to IEC 62443-4-1 / SSDF / NESAS / IT-Grundschutz.
  • California AI Transparency Act SB 942, as amended by AB 853
    ca-sb-942 · spec · source
  • 2026 Minimum Elements for a Software Bill of Materials (SBOM)
    cisa-2026-sbom-minimum · spec · source
  • Principles for the Secure Integration of Artificial Intelligence in Operational Technology — CISA, Australian Signals Directorate's Australian Cyber Security Centre (ASD's ACSC), NSA Artificial Intelligence Security Center, FBI, Canadian Centre for Cyber Security, German Federal Office for Information Security (BSI), Netherlands National Cyber Security Centre (NCSC-NL), New Zealand National Cyber Security Centre (NCSC-NZ), United Kingdom National Cyber Security Centre (NCSC-UK). Cybersecurity and Infrastructure Security Agency. 2025-12-03
    cisa-ai-in-ot-principles · spec · best-practice · summarized · source
    Seed source for #13. Asks for AI-specific attack vectors and MITRE ATLAS in threat models (DEC-001) and for human-in-the-loop review with an audit trail (R-018).
  • Emergency Directive 21-01: Mitigate SolarWinds Orion Code Compromise
    cisa-ed-21-01 · web · source
  • Framing Software Component Transparency: Establishing a Common Software Bill of Materials (SBOM) — CISA SBOM Tooling and Implementation Working Group. Cybersecurity and Infrastructure Security Agency. 2024-09-03
    cisa-framing-software-component-transparency · spec · best-practice · summarized · source
    Promotes the cryptographic hash from NTIA's recommended tier to Minimum Expected, and defines relationship completeness with an explicit open-world default. Both are directly load-bearing for R-M-07 and R-M-11.
  • Secure by Demand Guide: How Software Customers Can Drive a Secure Technology Ecosystem — Cybersecurity and Infrastructure Security Agency (CISA), Federal Bureau of Investigation (FBI). Cybersecurity and Infrastructure Security Agency (CISA) / Federal Bureau of Investigation (FBI). 2024-08-06. https://web.archive.org/web/20260128130827id_/https://www.cisa.gov/sites/default/files/2024-08/SecureByDemandGuide_080624_508c.pdf. https://www.cisa.gov/sites/default/files/2024-08/SecureByDemandGuide_080624_508c.pdf
    cisa-secure-by-demand-guide-2024 · spec · best-practice · distilled · source
    Customer-side questions and evidence checklist mirroring the SbD pledge; concrete automatable checks; distinguishes supplier-supplied vs customer-collected evidence.
  • Secure by Demand: Priority Considerations for Operational Technology Owners and Operators when Selecting Digital Products — Cybersecurity and Infrastructure Security Agency (CISA), National Security Agency (NSA), Federal Bureau of Investigation (FBI), Environmental Protection Agency (EPA), Transportation Security Administration (TSA), Australian Signals Directorate's Australian Cyber Security Centre (ASD's ACSC), Canadian Centre for Cyber Security (CCCS), European Commission DG CONNECT, Federal Office for Information Security (BSI), Netherlands' National Cyber Security Centre (NCSC-NL), New Zealand's National Cyber Security Centre (NCSC-NZ), United Kingdom's National Cyber Security Centre (NCSC-UK). Cybersecurity and Infrastructure Security Agency (CISA), with 11 partner agencies. 2025-01-13. https://www.cisa.gov/sites/default/files/2025-01/joint-guide-secure-by-demand-priority-considerations-for-ot-owners-and-operators-508c_0.pdf. https://www.cisa.gov/sites/default/files/2025-04/Priority-Considerations-for-OT-508c.pdf. TLP:CLEAR
    cisa-secure-by-demand-ot-2025 · spec · best-practice · summarized · source
    Buyers are told to demand a 'full and detailed threat model' from OT manufacturers (element 10) — direct demand-side motivation for tmodel's exportable, governed threat-model view.
  • Shifting the Balance of Cybersecurity Risk: Principles and Approaches for Secure by Design Software — Cybersecurity and Infrastructure Security Agency (CISA), National Security Agency (NSA), Federal Bureau of Investigation (FBI), Australian Cyber Security Centre (ACSC), Canadian Centre for Cyber Security (CCCS), United Kingdom National Cyber Security Centre (NCSC-UK), Federal Office for Information Security (BSI), Netherlands National Cyber Security Centre (NCSC-NL), Norway National Cyber Security Center (NCSC-NO), Computer Emergency Response Team New Zealand (CERT NZ), New Zealand National Cyber Security Centre (NCSC-NZ), Korea Internet & Security Agency (KISA), Israel National Cyber Directorate (INCD), Japan National Center of Incident Readiness and Strategy for Cybersecurity (NISC), Japan Computer Emergency Response Team Coordination Center (JPCERT/CC), OAS/CICTE CSIRT Americas Network, Cyber Security Agency of Singapore (CSA), Czech National Cyber and Information Security Agency (NUKIB). Cybersecurity and Infrastructure Security Agency (CISA), with NSA, FBI and 15 international partner agencies. 2023-10-25. https://web.archive.org/web/20260928143252id_/https://www.cisa.gov/sites/default/files/2023-10/SecureByDesign_1025_508c.pdf. https://www.cisa.gov/sites/default/files/2023-10/SecureByDesign_1025_508c.pdf. TLP:CLEAR
    cisa-secure-by-design-2023 · spec · best-practice · distilled · source
    The acquirer-facing SDL reference: 3 principles, 37 demonstration practices and 20 tactics, each tied to a public artifact (roadmap, SBOM, VDP, CVE+CWE, threat model, self-attestation). It prints SSDF mappings (R-044) and exposes model gaps: configuration/secure-default, class-level mitigation, public governed views.
  • Secure by Design Pledge — Cybersecurity and Infrastructure Security Agency (CISA). Cybersecurity and Infrastructure Security Agency (CISA). 2024-05. https://web.archive.org/web/20260109103624id_/https://www.cisa.gov/sites/default/files/2024-05/CISA%20Secure%20by%20Design%20Pledge_508c.pdf. https://www.cisa.gov/sites/default/files/2024-05/CISA%20Secure%20by%20Design%20Pledge_508c.pdf. https://www.cisa.gov/securebydesign/pledge/progress-reports. https://www.cisa.gov/resources-tools/resources/cisa-secure-design-pledge
    cisa-secure-by-design-pledge-2024 · spec · best-practice · distilled · source
    Seven time-boxed, publicly evidenced goals; Goals 5 and 6 are precise enough to automate as checks over Vulnerability/Weakness nodes; contrasts commitment vs attestation.
  • Secure Software Development Attestation Form (with Instructions) — Cybersecurity and Infrastructure Security Agency (CISA), Department of Homeland Security. U.S. Department of Homeland Security, Cybersecurity and Infrastructure Security Agency. 2024-03-11. https://web.archive.org/web/20260823183523id_/https://www.cisa.gov/sites/default/files/2024-04/Self_Attestation_Common_Form_FINAL_508c.pdf. 1670-0052. https://softwaresecurity.cisa.gov. https://www.cisa.gov/sites/default/files/2024-04/Self_Attestation_Common_Form_FINAL_508c.pdf
    cisa-ssdf-attestation-form-2024 · spec · distilled · source
    A real, signed conformance document: field schema, signatory rules, revocation and a source-published form -> EO 14028 §4(e) -> SSDF crosswalk; template for R-043 governed views and R-044 mappings. Optional for agencies since OMB M-26-05.
  • Commercial National Security Algorithm Suite 2.0 (CNSA 2.0) Algorithms and FAQ
    cnsa-2-0 · spec · source
  • ENISA Secure by Design and Default Playbook: A Practical Guide to Secure by Design and Default Principles for SMEs — European Union Agency for Cybersecurity (ENISA). European Union Agency for Cybersecurity (ENISA). 2026-07. doi:10.2824/4422633. TP-01-26-016-EN-N. ISBN 978-92-9204-802-0
    enisa-sbd-playbook-2026 · spec · best-practice · distilled · source
    22 principle playbooks each with checklist, minimum evidence and pass/fail release-gate criteria (125), an attestation cascade (control -> implementation -> verification) for R-042 export, and an indicative principle -> CRA Annex I mapping (62 rows).
  • Executive Order 14028: Improving the Nation's Cybersecurity — Joseph R. Biden Jr. (President of the United States). Executive Office of the President; published in the Federal Register (86 FR 26633, 2021-05-17). 2021-05-12. 14028. 86 FR 26633. 2021-10460
    eo-14028 · spec · distilled · source
    §4(e)(i)-(x) is the US-federal SDL practice hub that the CISA form and SSDF map to; §4(e)(iv) release gate and §4(e)(v) public risk summary inform R-041/R-043.
  • Executive Order 14144: Strengthening and Promoting Innovation in the Nation's Cybersecurity — Joseph R. Biden Jr. (President of the United States). Executive Office of the President; published in the Federal Register (90 FR 6755, 2025-01-17). 2025-01-16. 14144. 90 FR 6755. 2025-01470
    eo-14144 · spec · summarized · source
    Records the high-water mark of the US attestation regime (machine-readable attestations, CISA validation, public results) and the SSDF-update directive; its attestation part was struck by EO 14306.
  • Executive Order 14306: Sustaining Select Efforts To Strengthen the Nation's Cybersecurity and Amending Executive Order 13694 and Executive Order 14144 — Donald J. Trump (President of the United States). Executive Office of the President; published in the Federal Register (90 FR 24723, 2025-06-11). 2025-06-06. 14306. 90 FR 24723. 2025-10804
    eo-14306 · spec · summarized · source
    Removed the CISA attestation-validation / FAR-attestation directives of EO 14144 while keeping a dated SSDF update; explains why the US attestation regime contracted in 2025-2026.
  • Securing the Software Supply Chain: Recommended Practices Guide for Developers — Enduring Security Framework (ESF) Software Supply Chain Working Panel, National Security Agency (NSA), Cybersecurity and Infrastructure Security Agency (CISA), Office of the Director of National Intelligence (ODNI). NSA / CISA / ODNI (Enduring Security Framework). 2022-08
    esf-sscs-developers-2022 · spec · best-practice · distilled · source
    Organised as threat scenario -> recommended mitigation -> lifecycle phase; concrete threat-model governance (2 independent approvers, annual refresh), release criteria and a 60-item SSDF-mapped conformance checklist.
  • EU AI Act Article 50: Transparency Obligations
    eu-ai-act-art-50 · spec · source
  • EU Code of Practice on marking and labelling AI-generated content
    eu-code-of-practice-marking · web · source
  • Regulation (EU) 2024/2847 of the European Parliament and of the Council of 23 October 2024 on horizontal cybersecurity requirements for products with digital elements and amending Regulations (EU) No 168/2013 and (EU) 2019/1020 and Directive (EU) 2020/1828 (Cyber Resilience Act) — European Parliament, Council of the European Union. European Parliament and Council of the European Union (Official Journal of the European Union, OJ L, 2024/2847, 20.11.2024). 2024-10-23. 32024R2847. http://data.europa.eu/eli/reg/2024/2847/oj. OJ L, 2024/2847, 20.11.2024
    eu-cra-2024-2847 · spec · standard · distilled · source
    The first binding horizontal SDL law in a major market: risk assessment (threat model), a no-known-exploitable-vulnerabilities release gate, SBOM, CVD and Art 14 reporting clocks (in force since 2026-09-11) are legal obligations evidenced by governed technical documentation — the strongest external anchor for R-041..R-043.
  • Cybersecurity in Medical Devices: Quality Management System Considerations and Content of Premarket Submissions — Guidance for Industry and Food and Drug Administration Staff — U.S. Food and Drug Administration, Center for Devices and Radiological Health, U.S. Food and Drug Administration, Center for Biologics Evaluation and Research. U.S. Food and Drug Administration (CDRH / CBER). 2026-02-03. FDA-2021-D-1158. GUI00001825
    fda-premarket-cybersecurity-guidance · spec · best-practice · distilled · source
    A regulator's premarket review expectation built on a threat model plus traceability (threat model -> risk assessment -> controls -> requirements -> tests, assets -> SBOM): the closest external statement of the R-042 conformance check; 524B makes plan, processes and SBOM statutory for cyber devices.
  • Content Credentials: Strengthening Multimedia Integrity in the Generative AI Era
    nsa-2025-content-credentials · paper · source
  • The Minimum Elements For a Software Bill of Materials (SBOM)
    ntia-2021-sbom-minimum · spec · source
  • The Minimum Elements For a Software Bill of Materials (SBOM) — National Telecommunications and Information Administration. United States Department of Commerce. 2021-07-12. Executive Order 14028 §4(f)
    ntia-sbom-minimum-elements · spec · best-practice · summarized · source
    Establishes the floor for what an SBOM must contain, and — decisively for us — puts the component hash OUTSIDE that floor. That omission is the evidence R-M-07 needs.
  • M-22-18: Enhancing the Security of the Software Supply Chain through Secure Software Development Practices — Shalanda D. Young (Director, OMB). Executive Office of the President, Office of Management and Budget. 2022-09-14. M-22-18. https://www.whitehouse.gov/wp-content/uploads/2022/09/M-22-18.pdf
    omb-m-22-18 · spec · distilled · source
    Rescinded, but the clearest worked example of an acquirer-run conformance gate (attest / 3PAO / POA&M / waiver) with dated milestones; informs R-041/R-042 conformance states.
  • M-23-16: Update to Memorandum M-22-18, Enhancing the Security of the Software Supply Chain through Secure Software Development Practices — Shalanda D. Young (Director, OMB). Executive Office of the President, Office of Management and Budget. 2023-06-09. M-23-16. https://www.whitehouse.gov/wp-content/uploads/2023/06/M-23-16-Update-to-M-22-18-Enhancing-Software-Security.pdf
    omb-m-23-16 · spec · distilled · source
    Rescinded; useful for the end-product accountability rule, the compound POA&M+extension guard and an OMB-stated six-phase SDL list.
  • M-26-05: Adopting a Risk-based Approach to Software and Hardware Security — Russell T. Vought (Director, OMB). Executive Office of the President, Office of Management and Budget. 2026-01-23. M-26-05
    omb-m-26-05 · spec · distilled · source
    Current US federal policy (2026): rescinds the mandatory attestation; conformance becomes an agency-owned, risk-based profile — informs R-042/R-044 design (no single fixed baseline).
  • Software Security Code of Practice — Department for Science, Innovation and Technology, National Cyber Security Centre. UK Department for Science, Innovation and Technology (DSIT) / National Cyber Security Centre (NCSC). 2025-05-07. https://www.gov.uk/government/publications/software-security-code-of-practice/software-security-code-of-practice. https://www.ncsc.gov.uk/guidance/software-security-code-of-practice-assurance-principles-claims. https://www.ncsc.gov.uk/collection/software-security-code-of-practice-implementation-guidance
    uk-software-security-code-of-practice · spec · best-practice · distilled · source
    Government SDL conformance profile with a Principle -> Claim -> Evidence chain (APC) that is exactly R-042's missing middle layer, a threat-modelling claim a tmodel model can evidence, all three R-040 mitigation kinds, and a source-published framework mapping (IG Appendix 1).

vendor

  • Fahrenheit 451.2: Is Cyberspace Burning?
    aclu-fahrenheit-451-2 · web · source
  • DCAppAttestService / App Attest
    apple-app-attest · web · source
  • Learn the architecture: Introducing Arm Confidential Compute Architecture
    arm-cca-den0125 · spec · source
  • Attest an Amazon EC2 instance with AMD SEV-SNP
    aws-snp-attestation · web · source
  • AWS Threat Composer — Amazon Web Services
    aws-threat-composer · repo · implementation · summarized · source
    Inspectable structured-threat model covering assumptions, threat statements, mitigations, diagrams, and machine-assisted interfaces.
  • BSIMM16 — Building Security In Maturity Model (Report 2026) — Black Duck Software, Inc. (BSIMM team; no individual authors named). Black Duck Software, Inc.. 2026-01
    bsimm-16 · spec · informational · distilled · source
    Observational catalogue of 128 SDL activities with counts over 111 firms; gives the most concrete published vocabulary for SDL gates (checkpoint, release condition, exception, sign-off) and edition lineage needed for R-044 crosswalk ids.
  • SUNSPOT: An Implant in the Build Process
    crowdstrike-sunspot · web · source
  • CVE-2019-13050: SKS keyserver certificate spamming attack
    cve-2019-13050 · web · source
  • Devici–SD Elements integration generally available — Security Compass
    devici-sd-elements-integration · web · implementation · source
    Primary release evidence for OTM handoff and downstream work-item delivery between Devici and SD Elements.
  • Highly Evasive Attacker Leverages SolarWinds Supply Chain with SUNBURST Backdoor
    fireeye-sunburst · web · source
  • Intel SGX ECDSA QuoteLibReference (DCAP API)
    intel-sgx-dcap-quotelib · spec · source
  • Intel TDX DCAP Quoting Library API
    intel-tdx-dcap-quoting · spec · source
  • Intel Trust Domain Extensions (white paper)
    intel-tdx-whitepaper · spec · source
  • IriusRisk — Creating a threat model — IriusRisk. 2025-09-01
    iriusrisk-creating-threat-model · web · implementation · summarized · source
    First-party evidence for architecture-input, generated-finding, and analyst-review workflows in a commercial threat-modeling product.
  • Intelligence-Driven Computer Network Defense Informed by Analysis of Adversary Campaigns and Intrusion Kill Chains — Eric M. Hutchins, Michael J. Cloppert, Rohan M. Amin. Lockheed Martin Corporation. 2011
    lockheed-kill-chain-2011 · paper · summarized · source
  • Memgraph Lab documentation
    memgraph-lab · web · summarized · source
    Product precedent for query/graph views, data-driven styling, and LLM-assisted querying in RPT-0006.
  • Microsoft Security Development Lifecycle (SDL) Practices — Microsoft Corporation. Microsoft Corporation. 2024
    microsoft-sdl · spec · recommendation · distilled · source
    Microsoft's current SDL; its threat-modeling practice matches tmodel's core layers, its exception process gives the risk-acceptance lifecycle, and its sub-practice ids are what OWASP SAMM's crosswalk targets.
  • Microsoft Security Development Lifecycle (SDL) Process Guidance – Version 5.2 — Microsoft Corporation. Microsoft Corporation. 2012-05-23
    microsoft-sdl-5-2 · spec · historic · distilled · source
    Legacy, but the most complete public SDL with a real release gate: the Final Security Review's entry guard, reviewer, checks, outcomes, exception path and carry-over are the template for the R-041 Gate and the R-042 threats-mitigated check.
  • Simplified Implementation of the Microsoft SDL — Microsoft Corporation. Microsoft Corporation. 2010-11-04
    microsoft-sdl-simplified-2010 · paper · white-paper · distilled · source
    Microsoft's portable minimum SDL: sixteen numbered mandatory practices, per-phase quality gates approved by an independent advisor, and a compliance-tracking application holding process attestations — precursors of R-041/R-042/R-043.
  • Microsoft Threat Modeling Tool feature overview — Microsoft. 2017-08-17
    microsoft-threat-modeling-tool-features · web · implementation · summarized · source
    Documents design and analysis views, templates, threat status, and reports relevant to review interaction and lifecycle evidence.
  • Microsoft Threat Modeling Tool overview — Microsoft. 2017-02-16
    microsoft-threat-modeling-tool-overview · web · implementation · summarized · source
    First-party overview of STRIDE-per-element analysis and mitigation workflow in an established diagram-first tool.
  • Revoking Trust in one ANSSI Certificate
    mozilla-2013-anssi · web · source
  • Revoking Trust in Two TurkTrust Certificates
    mozilla-2013-turktrust · web · source
  • Name Constraints ignored by libPKIX verification engine
    mozilla-bug-856060 · web · source
  • Neo4j Bloom user guide
    neo4j-bloom · web · summarized · source
    Product precedent for graph exploration, saved presentation state, and database editing in RPT-0006.
  • Details about the event-stream incident
    npm-event-stream · web · source
  • Open Threat Model specification and JSON Schema — IriusRisk
    open-threat-model · repo · specification · summarized · source
    Machine-readable threat-model object and interchange schema directly relevant to DEC-001 and DEC-002.
  • Macaroons Escalated Quickly
    ptacek-2024-macaroons · web · source
  • SD Elements Threat Modeling Datasheet — Security Compass
    sd-elements-threat-modeling-datasheet · web · implementation · summarized · source
    Primary vendor datasheet for automated findings, countermeasures, training, and verification workflow claims.
  • VAST (Visual, Agile, and Simple Threat) modeling — ThreatModeler — ThreatModeler Software. ThreatModeler Software, Inc.
    threatmodeler-vast · web · summarized · source
  • ThreatTree Help Center — ThreatTree
    threattree-help · web · implementation · summarized · source
    First-party technical documentation for linked DFD, attack-tree, risk-register, export, collaboration, and ticket-lifecycle behavior.
  • yFiles for HTML developer documentation
    yfiles-html · web · summarized · source
    Primary documentation and licensing evidence for the commercial SDK path in RPT-0006.
  • Zoom Acquires Keybase
    zoom-keybase-2020 · web · source

w3c

  • OWL 2 Web Ontology Language Primer
    owl-2-primer · spec · recommendation · summarized · source
    Type the asset/weakness/threat hierarchy; use RL profile (PROV-O targets it) where inference matters, scoped for scale.
  • PICS 1.1 Label Distribution: Label Syntax and Communication Protocols
    pics-1-1-labels · spec · source
  • PICS 1.1 Rating Services and Rating Systems and Their Machine Readable Descriptions
    pics-1-1-services · spec · source
  • PICS, Censorship, and Intellectual Freedom FAQ
    pics-censorship-faq · web · source
  • PICS Signed Labels (DSig) 1.0 Specification
    pics-dsig-1-0 · spec · source
  • POWDER: Description Resources
    powder-description-resources · spec · source
  • PROV-O: The PROV Ontology
    prov-o · spec · recommendation · summarized · source
    The backbone for tmodel's provenance + human-review annotations: model each assertion's source, the analysis activity, and the human reviewer as an agent — full audit trail.
  • RDF 1.1 Concepts and Abstract Syntax
    rdf-1-1-concepts · spec · recommendation · summarized · source
    Named graphs are the natural container for per-source / per-review-batch provenance partitioning in tmodel.
  • Shapes Constraint Language (SHACL)
    shacl · spec · recommendation · summarized · source
    The human-in-the-loop gate: enforce every risk node carries provenance + a review status before acceptance; report violations to reviewers.
  • SPARQL 1.1 Query Language
    sparql-1-1 · spec · recommendation · summarized · source
    Powers attack-path queries and federated queries against OKN/external graphs.
  • W3C Platform for Internet Content Selection (PICS)
    w3-org-pics · web · source
  • Decentralized Identifiers (DIDs) v1.1
    w3c-did-1-1 · spec · source
  • Decentralized Identifiers (DIDs) v1.0
    w3c-did-core · spec · source
  • DID Extensions: Methods registry
    w3c-did-extensions-methods · spec · source
  • PROV-DM: The PROV Data Model — W3C. 2013-04-30
    w3c-prov-dm · spec · standard · source
    The provenance data model a predicate vocabulary would be measured against (DEC-007).
  • PROV-O: The PROV Ontology — W3C. 2013-04-30
    w3c-prov-o · spec · standard · source
    The OWL rendering of PROV-DM; the RDF-shaped alternative to our own predicate encoding (DEC-007).
  • RDF Dataset Canonicalization (RDFC-1.0) — Dave Longley, Gregg Kellogg, Dan Yamamoto. World Wide Web Consortium. 2024-05-21. REC-rdf-canon-20240521
    w3c-rdf-canon-1-0 · spec · standard · summarized · source
    Prior art, not a candidate. RDFC canonicalises unordered RDF datasets, so it is not a DEC-002 option for our tree-shaped statements; its value is §5 plus Appendix A, the one ratified construction for canonically ordering a SET, which lowers the R-O-03 cost of writing the condition (5) ordering rule.
  • Shapes Constraint Language (SHACL) — W3C. 2017-07-20
    w3c-shacl · spec · standard · source
    Constraint-language prior art for validating statement shapes (DEC-007).
  • W3C TAG proposal to obsolete CC/PP and POWDER (issue 86)
    w3c-tag-obsolete-powder · web · source

By topic

Each topic's records, regrouped from the shelves above.

Topic: algorithm-bindings

Which algorithm identifiers do COSE and JOSE actually define, and what does a verifier learn from one?

  • SLH-DSA for JOSE and COSE — M. Prorock, O. Steele, H. Tschofenig. IETF. 2026-07-28. draft-ietf-cose-sphincs-plus-10
    draft-ietf-cose-sphincs-plus · draft · summarized · source
    The only wire binding for SLH-DSA. Answers what fips-205 could not: what an SLH-DSA signature looks like in COSE - and that only two of twelve parameter sets are registered.
  • Post-Quantum Key Encapsulation Mechanisms (PQ KEMs) for COSE — T. Reddy, A. Banerjee, H. Tschofenig. IETF. 2026-07-06. draft-ietf-jose-pqc-kem-06
    draft-ietf-jose-pqc-kem · draft · summarized · source
    Key encapsulation is confidentiality, not attestation - the same negative verdict recorded on fips-203. Held so the post-quantum COSE picture is complete, and because the WG rename makes it easy to miss.
  • JSON Web Algorithms (JWA) — M. Jones. IETF. 2015-05. RFC 7518
    rfc-7518 · rfc · standard · summarized · source
    The JOSE half of the algorithm registry. COSE's design is legible as a set of deliberate departures from it, so holding both is what makes the comparison possible.
  • ChaCha20 and Poly1305 for IETF Protocols — IETF. 2015-05. RFC 7539
    rfc-7539 · rfc · informational · source
  • ChaCha20 and Poly1305 for IETF Protocols — Y. Nir, A. Langley. IRTF. 2018-06. RFC 8439
    rfc-8439 · rfc · informational · summarized · source
    The AEAD behind COSE alg 24. Held so that code point resolves, and because its standing - IRTF Informational, not IETF Standards Track - is exactly the trap library/CLAUDE.md warns about.
  • Internet X.509 Public Key Infrastructure — Algorithm Identifiers for the Module-Lattice-Based Digital Signature Algorithm (ML-DSA) — J. Massimo, P. Kampanakis, S. Turner, B. E. Westerbaan. IETF. 2025-10. RFC 9881
    rfc-9881 · rfc · standard · summarized · source
    Holds the argument RFC 9964 7.2 defers to. Without it the reason COSE excludes HashML-DSA was a citation the library could not check.

Topic: artifact-statements

How do in-toto, SLSA and PICS structure claims about objects?

  • The vCon - Conversation Data Container - Overview — IETF. 2026-09. draft-ietf-vcon-overview-02
    draft-ietf-vcon-overview-02 · draft · informational · source
    Not yet read. Held as the informational companion to draft-ietf-vcon-vcon-core-04, whose FX-1 extraction is library#9. Deliberately carries no bears_on: DEC-005 is the envelope decision and R-M-11 is ArtifactId identification, and an informational overview settles neither. If reading it shows otherwise, add the edge then.
  • The JSON format for vCon - Conversation Data Container — IETF. 2026-09. draft-ietf-vcon-vcon-core-04
    draft-ietf-vcon-vcon-core-04 · draft · distilled · source
    An independently-designed signed container with must-understand extension semantics and a supersession model - the best available test of whether our statement form can express something we did not design.
  • IETF Virtualized Conversations (vcon) Working Group — IETF. vcon
    ietf-vcon-wg · consortium · source
    _The WG record and the charter are one record by this library's convention (cf. ietf-cbor-wg, ietf-cose-wg): content.url is /wg//about/, which is where the charter lives. Members link here with part_of. Two things in the charter text worth checking when this is summarised, both bearing on library#9's extraction of the core draft. It charters "the use of an EXISTING mechanism for proving integrity and optionally authenticity" - which is the layering question the core record's design notes tested and rejected, and the charter's wording cuts both ways, since "define/specify the use of" still leaves the WG owing the placement rules that section 5.2 attempts. And it charters encryption "such that some parts of the vCon may be disclosed to different parties" - selective disclosure - which the extraction found the core draft cannot do: JWS signs the whole payload as opaque octets, so there is no partial verification and every change mints a new signed document. _
  • in-toto Attestation Framework v1
    in-toto-attestation-v1 · spec · source
  • GZIP — IETF. RFC 1952
    rfc-1952 · rfc · source
  • Timestamps — IETF. RFC 3339
    rfc-3339 · rfc · source
  • tel URI — IETF. RFC 3966
    rfc-3966 · rfc · source
  • GEOPRIV — IETF. RFC 4119
    rfc-4119 · rfc · source
  • UUID — IETF. RFC 4122
    rfc-4122 · rfc · source
  • SMTP — IETF. RFC 5321
    rfc-5321 · rfc · source
  • mailto URI — IETF. RFC 6068
    rfc-6068 · rfc · source
  • JWS — IETF. RFC 7515
    rfc-7515 · rfc · source
  • JWE — IETF. RFC 7516
    rfc-7516 · rfc · source
  • JSON — IETF. RFC 8259
    rfc-8259 · rfc · source
  • JMAP — IETF. RFC 8620
    rfc-8620 · rfc · source
  • HTTP Semantics — IETF. RFC 9110
    rfc-9110 · rfc · source
  • An Architecture for Trustworthy and Transparent Digital Supply Chains — H. Birkholz, A. Delignat-Lavaud, C. Fournet, Y. Deshpande, S. Lasker. IETF. 2026-06. RFC 9943
    rfc-9943 · rfc · standard · distilled · source
    The ratified, fully-worked version of the shape this project is designing — and its self-contradiction on rollback (§9.4.2 against §5.1.3) is a problem we inherit.
  • Decentralized Identifiers (DIDs) v1.0
    w3c-did-core · spec · source

Topic: authorization-reduction

How do 5-tuple reduction and tag intersection compose?

  • SPKI Requirements — C. Ellison. IETF. 1999-09. RFC 2692
    rfc-2692 · rfc · experimental · summarized · source
    The requirements document explaining WHY SPKI looks as it does. It is also the only place R-M-01 is argued from first principles rather than asserted: ASN.1 is ruled out, and sign-as-transmitted is stated as a requirement, which is R-O-03's problem posed before any canonical form existed.
  • SPKI Certificate Theory — C. Ellison, B. Frantz, B. Lampson, R. Rivest, B. Thomas, T. Ylonen. IETF. 1999-09. RFC 2693
    rfc-2693 · rfc · experimental · distilled · source
    The direct ancestor of this architecture. Its 5-tuple and AIntersect are what R-M-05 and R-M-08 restate, its ACL is R-M-02's unsigned local root, and its boolean-delegation decision is R-M-10. DEC-004 option 1 IS this document's tag language.
  • Internet X.509 PKI Proxy Certificate Profile — IETF. RFC 3820
    rfc-3820 · rfc · source

Topic: canonical-encoding

What must hold for a canonical encoding to be safe to sign, and to derive a stable identifier from?

  • JSON Canonicalization Scheme (JCS) — A. Rundgren, B. Jordan, S. Erdtman. RFC Editor (Independent Submission stream — not IETF consensus). 2020-06. RFC 8785
    rfc-8785 · rfc · informational · distilled · source
  • Concise Binary Object Representation (CBOR) — C. Bormann, P. Hoffman. IETF. 2020-12. RFC 8949
    rfc-8949 · rfc · standard · distilled · source
    STD 94. DEC-002 option 2 makes this the candidate native encoding, and Sec.4.2 is the deterministic-encoding text every signing profile starts from.
  • Simple Public Key Infrastructure (SPKI) S-Expressions — R. Rivest, D. Eastlake 3rd. IETF. 2025-06. RFC 9804
    rfc-9804 · rfc · informational · distilled · source
    DEC-002 option 1, and the only candidate whose canonical form states uniqueness as an explicit design goal (§6.2). Its §6.2/§6.4 canonical-for-signing versus advanced-for-display split is the architectural ancestor of R-O-05, and §10 imposes no verification ordering, so unlike RFC 8785 it does not conflict with R-O-05.
  • Dead Simple Signing Envelope (DSSE) — Secure Systems Lab. Secure Systems Lab (NYU) / secure-systems-lab. 2024-05
    secure-systems-lab-dsse · repo · unofficial · distilled · source
  • RDF Dataset Canonicalization (RDFC-1.0) — Dave Longley, Gregg Kellogg, Dan Yamamoto. World Wide Web Consortium. 2024-05-21. REC-rdf-canon-20240521
    w3c-rdf-canon-1-0 · spec · standard · summarized · source
    Prior art, not a candidate. RDFC canonicalises unordered RDF datasets, so it is not a DEC-002 option for our tree-shaped statements; its value is §5 plus Appendix A, the one ratified construction for canonically ordering a SET, which lowers the R-O-03 cost of writing the condition (5) ordering rule.

Topic: capability-delegation

Why did the field abandon SPKI's authorization intersection for containment checking?

  • Biscuit Specification v3.3
    biscuit-spec-3-3 · spec · source
  • Programming Semantics for Multiprogrammed Computations
    dennis-vanhorn-1966 · paper · source
  • Verifiable Attenuated Delegation for AI Agent Chains — IETF. draft-asor-wimse-agent-delegation-chain
    draft-asor-wimse-agent-delegation-chain · draft · source
  • An Attenuated Delegation Profile for Automated Agents — IETF. draft-hamr-oauth-agent-delegation
    draft-hamr-oauth-agent-delegation · draft · source
  • Attenuating Authorization Tokens for Agentic Delegation Chains — IETF. draft-niyikiza-oauth-attenuating-agent-tokens
    draft-niyikiza-oauth-attenuating-agent-tokens · draft · source
  • The Confused Deputy (or why capabilities might have been invented)
    hardy-1988-confused-deputy · paper · source
  • Macaroons: Cookies with Contextual Caveats for Decentralized Authorization in the Cloud
    macaroons-2014 · paper · source
  • AIP: Agent Identity Protocol for Verifiable Delegation Across MCP and A2A
    prakash-2026-aip · paper · source
  • Macaroons Escalated Quickly
    ptacek-2024-macaroons · web · source
  • The OAuth 2.0 Authorization Framework — IETF. RFC 6749
    rfc-6749 · rfc · source
  • The OAuth 2.0 Authorization Framework: Bearer Token Usage — IETF. RFC 6750
    rfc-6750 · rfc · source
  • Proof-of-Possession Key Semantics for JSON Web Tokens (JWTs) — IETF. RFC 7800
    rfc-7800 · rfc · source
  • JSON Web Token (JWT) Profile for OAuth 2.0 Access Tokens — IETF. RFC 9068
    rfc-9068 · rfc · source
  • OAuth 2.0 Rich Authorization Requests — IETF. RFC 9396
    rfc-9396 · rfc · source
  • HTTP Message Signatures — IETF. RFC 9421
    rfc-9421 · rfc · source
  • OAuth 2.0 Demonstrating Proof of Possession (DPoP) — IETF. RFC 9449
    rfc-9449 · rfc · source
  • User Controlled Authorization Network (UCAN) Specification v1.0.0
    ucan-1-0 · spec · source
  • CAPMAS: Capability-Based Delegation of Privileges in Multi-Agent Systems
    veski-2026-capmas · paper · source
  • Authorization Capabilities (ZCAP-LD) v0.4.0-rc.6
    zcap-ld · spec · source

Topic: cbor-ecosystem

Who ships CBOR, in what markets, on whose code, and who governs the extension points?

  • IANA Concise Binary Object Representation (CBOR) Simple Values Registry
    iana-cbor-simple-values · dataset · source
    The second CBOR extension point. Smaller than the tag registry but governed the same way, so the R-M-12 argument must cover it.
  • IANA Concise Binary Object Representation (CBOR) Tags Registry
    iana-cbor-tags · dataset · source
    The central extension point of CBOR, and the single strongest piece of evidence for R-M-12: a native model built on it is registry-dependent.
  • IETF Concise Binary Object Representation Maintenance and Extensions (CBOR) Working Group — IETF
    ietf-cbor-wg · consortium · source
    The body that controls the CBOR spec line and its extension points. Parent record for every CBOR WG document held here.
  • IETF CBOR Object Signing and Encryption (COSE) Working Group — IETF
    ietf-cose-wg · consortium · source
    The body that controls the COSE spec line. Parent record for every COSE document held here.
  • Cryptographic Message Syntax (CMS) Content Types for Concise Binary Object Representation (CBOR) — J. Schaad. IETF. 2020-03. RFC 8769
    rfc-8769 · rfc · informational · source
    Wraps CBOR in CMS. m-of-n does not use CMS; recorded so the question is not reopened.
  • CBOR Object Signing and Encryption (COSE) and JSON Object Signing and Encryption (JOSE) Registrations for Web Authentication (WebAuthn) Algorithms — M. Jones. IETF. 2020-08. RFC 8812
    rfc-8812 · rfc · standard · source
    The WebAuthn/COSE algorithm bridge. Evidence for the FIDO half of the ecosystem survey, not for our envelope.
  • Encoding of Data Modeled with YANG in the Concise Binary Object Representation (CBOR) — M. Veillette, Ed., I. Petrov, Ed., A. Pelov, C. Bormann, M. Richardson. IETF. 2022-07. RFC 9254
    rfc-9254 · rfc · standard · source
    An application of CBOR (CORECONF), not a component of implementing it. Kept as prior art for schema-driven integer-key maps.
  • Ephemeral Diffie-Hellman Over COSE (EDHOC) — G. Selander, J. Preuss Mattsson, F. Palombini. IETF. 2024-03. RFC 9528
    rfc-9528 · rfc · standard · source
    A key exchange over COSE for constrained devices. Ecosystem evidence — m-of-n does not do key agreement.
  • Traces of Ephemeral Diffie-Hellman Over COSE (EDHOC) — G. Selander, J. Preuss Mattsson, M. Serafin, M. Tiloca, M. Vucinic. IETF. 2024-03. RFC 9529
    rfc-9529 · rfc · informational · source
    Test vectors for EDHOC, which we do not implement. Recorded to close the question.
  • Using Ephemeral Diffie-Hellman Over COSE (EDHOC) with the Constrained Application Protocol (CoAP) and Object Security for Constrained RESTful Environments (OSCORE) — F. Palombini, M. Tiloca, R. Hoglund, S. Hristozov, G. Selander. IETF. 2024-11. RFC 9668
    rfc-9668 · rfc · standard · source
    EDHOC/CoAP integration. Outside m-of-n's transport story; recorded to close the question.
  • YANG-CBOR: Allocating SID Ranges for Private Enterprise Number (PEN) Holders — C. Bormann. IETF. 2026-07. RFC 9997
    rfc-9997 · rfc · standard · source
    SID range allocation for YANG-CBOR. Prior art for delegating an identifier space without a central registry per entry.

Topic: cbor-implementation

What does a complete, production-grade CBOR implementation have to get right?

  • CDDL Module Structure — IETF. 2026-09-02. draft-ietf-cbor-cddl-modules-07
    draft-ietf-cbor-cddl-modules · draft · source
    Module structure for CDDL. Relevant the moment our schema stops being one file, which WP1 will reach quickly.
  • Concise Diagnostic Notation (CDN) — IETF. 2026-07-20. draft-ietf-cbor-edn-literals-27
    draft-ietf-cbor-edn-literals · draft · source
    Diagnostic notation is how test vectors and spec examples are written. A product without it has no readable debug path.
  • Packed CBOR — IETF. 2026-08-06. draft-ietf-cbor-packed-19
    draft-ietf-cbor-packed · draft · source
    EXPIRED 2026-08-06 and not progressing. A compression layer we do not need; recorded so it is not presented as near-term.
  • Concise Binary Object Representation (CBOR) — C. Bormann, P. Hoffman. IETF. 2013-10. RFC 7049
    rfc-7049 · rfc · standard · source
    Obsoleted by RFC 8949; kept because deployed decoders and older profiles still cite it.
  • CBOR Object Signing and Encryption (COSE) — J. Schaad. IETF. 2017-07. RFC 8152
    rfc-8152 · rfc · standard · source
    Obsoleted by RFC 9052 and RFC 9053; kept because deployed COSE stacks and older profiles still cite it.
  • Using RSA Algorithms with CBOR Object Signing and Encryption (COSE) Messages — M. Jones. IETF. 2017-09. RFC 8230
    rfc-8230 · rfc · standard · source
    Algorithm profile. ARCH-0001 NG3 defers the algorithm suite, so this is needed only if RSA is later admitted.
  • CBOR Web Token (CWT) — M. Jones, E. Wahlstroem, S. Erdtman, H. Tschofenig. IETF. 2018-05. RFC 8392
    rfc-8392 · rfc · standard · source
    ARCH-0001 Sec.6 names COSE_Sign1 + CWT as an envelope candidate and asks that iss/sub align with the KeyId profile.
  • Concise Data Definition Language (CDDL): A Notational Convention to Express Concise Binary Object Representation (CBOR) and JSON Data Structures — H. Birkholz, C. Vigano, C. Bormann. IETF. 2019-06. RFC 8610
    rfc-8610 · rfc · standard · source
    DEC-002 option 2 is 'CBOR + CDDL as canonical'; this is the schema half of that option.
  • Concise Binary Object Representation (CBOR) Sequences — C. Bormann. IETF. 2020-02. RFC 8742
    rfc-8742 · rfc · standard · source
    Framing for concatenated items: how a log or stream of statements is carried without an outer array.
  • Concise Binary Object Representation (CBOR) Tags for Typed Arrays — C. Bormann, Ed.. IETF. 2020-02. RFC 8746
    rfc-8746 · rfc · standard · source
    A registry-allocated extension point — the exact shape R-M-12 rules out of the native model.
  • Proof-of-Possession Key Semantics for CBOR Web Tokens (CWTs) — M. Jones, L. Seitz, G. Selander, S. Erdtman, H. Tschofenig. IETF. 2020-03. RFC 8747
    rfc-8747 · rfc · standard · source
    PoP confirmation claim for CWT. Prior art for binding a token to a key; not required by the current envelope options.
  • Use of the HSS/LMS Hash-Based Signature Algorithm with CBOR Object Signing and Encryption (COSE) — R. Housley. IETF. 2020-04. RFC 8778
    rfc-8778 · rfc · standard · source
    Stateful hash-based signatures in COSE. Algorithm suite is deferred by NG3; relevant if post-quantum signing is admitted.
  • Concise Binary Object Representation (CBOR) Tags for Date — M. Jones, A. Nadalin, J. Richter. IETF. 2020-11. RFC 8943
    rfc-8943 · rfc · standard · source
    Date tags 100/1004. Registry-dependent extension point; evidence for the R-M-12 argument.
  • Concise Binary Object Representation (CBOR) — C. Bormann, P. Hoffman. IETF. 2020-12. RFC 8949
    rfc-8949 · rfc · standard · distilled · source
    STD 94. DEC-002 option 2 makes this the candidate native encoding, and Sec.4.2 is the deterministic-encoding text every signing profile starts from.
  • Use of the Walnut Digital Signature Algorithm with CBOR Object Signing and Encryption (COSE) — D. Atkins. IETF. 2021-05. RFC 9021
    rfc-9021 · rfc · informational · source
    Informational registration for an algorithm outside any suite m-of-n would consider. Recorded so it is not re-evaluated.
  • CBOR Object Signing and Encryption (COSE): Structures and Process — J. Schaad. IETF. 2022-08. RFC 9052
    rfc-9052 · rfc · standard · distilled · source
    STD 96 with RFC 9338. COSE_Sign1 is one of the two envelope options in DEC-005, and its header parameters are IANA-allocated, so R-M-12 applies.
  • CBOR Object Signing and Encryption (COSE): Initial Algorithms — J. Schaad. IETF. 2022-08. RFC 9053
    rfc-9053 · rfc · informational · summarized · source
    The algorithm half of COSE. Updated by RFC 9864 — read them together or you will implement under-specified algorithm identifiers.
  • CBOR Object Signing and Encryption (COSE): Hash Algorithms — J. Schaad. IETF. 2022-08. RFC 9054
    rfc-9054 · rfc · informational · source
    R-M-07 requires artifact statements to bind a content digest; this registers the COSE hash algorithm identifiers for doing so.
  • Concise Binary Object Representation (CBOR) Tags for Object Identifiers — C. Bormann. IETF. 2021-07. RFC 9090
    rfc-9090 · rfc · standard · source
    OID tags — a second global naming authority inside the encoding. Directly contrary to key-relative naming (ARCH-0002 P1).
  • Concise Binary Object Representation (CBOR) Tags for IPv4 and IPv6 Addresses and Prefixes — M. Richardson, C. Bormann. IETF. 2021-12. RFC 9164
    rfc-9164 · rfc · standard · source
    Address tags are not in our data model; kept as further evidence of registry-dependent extension points.
  • Additional Control Operators for the Concise Data Definition Language (CDDL) — C. Bormann. IETF. 2021-12. RFC 9165
    rfc-9165 · rfc · standard · source
    Control operators a real CDDL schema needs; a CDDL tool that omits them cannot validate our fixtures.
  • On Stable Storage for Items in Concise Binary Object Representation (CBOR) — M. Richardson, C. Bormann. IETF. 2022-08. RFC 9277
    rfc-9277 · rfc · standard · source
    Defines the CBOR file magic / labelled-content convention — how a stored statement file identifies itself.
  • CBOR Object Signing and Encryption (COSE): Countersignatures — J. Schaad. IETF. 2022-12. RFC 9338
    rfc-9338 · rfc · standard · source
    Part of STD 96 with RFC 9052. Countersignature is the closest COSE primitive to an endorsement over someone else's statement.
  • CBOR Object Signing and Encryption (COSE): Header Parameters for Carrying and Referencing X.509 Certificates — J. Schaad. IETF. 2023-02. RFC 9360
    rfc-9360 · rfc · standard · source
    X.509 carriage is the identifier model m-of-n is arguing against, but DEC-003 must say why, and interop may need it.
  • CBOR Object Signing and Encryption (COSE): AES-CTR and AES-CBC — R. Housley, H. Tschofenig. IETF. 2023-09. RFC 9459
    rfc-9459 · rfc · standard · source
    Content encryption modes. m-of-n signs rather than encrypts; kept for completeness of the COSE algorithm picture.
  • Concise Binary Object Representation (CBOR) Tags for Time, Duration, and Period — C. Bormann, B. Gamari, H. Birkholz. IETF. 2024-08. RFC 9581
    rfc-9581 · rfc · standard · source
    Validity windows on a certificate are time values; this is the registry-based way to carry them.
  • CBOR Object Signing and Encryption (COSE) "typ" (type) Header Parameter — M.B. Jones, O. Steele. IETF. 2024-06. RFC 9596
    rfc-9596 · rfc · standard · source
    Explicit typing of a signed object — the standard defence against cross-protocol confusion between statement kinds.
  • CBOR Web Token (CWT) Claims in COSE Headers — T. Looker, M.B. Jones. IETF. 2024-06. RFC 9597
    rfc-9597 · rfc · standard · source
    Puts CWT claims in the protected header, so a verifier reads issuer and subject without parsing the payload.
  • CBOR Object Signing and Encryption (COSE) Key Thumbprint — K. Isobe, H. Tschofenig, O. Steele. IETF. 2024-12. RFC 9679
    rfc-9679 · rfc · standard · source
    DEC-003 lists 'COSE key thumbprint' as an option and requires canonical key bytes before hashing. This is that specification.
  • Updates to the Concise Data Definition Language (CDDL) Grammar — C. Bormann. IETF. 2024-11. RFC 9682
    rfc-9682 · rfc · standard · source
    Normative grammar corrections to RFC 8610; both remain current, so an implementation must read them together.
  • Concise Data Definition Language (CDDL): Additional Control Operators for the Conversion and Processing of Text — C. Bormann. IETF. 2025-03. RFC 9741
    rfc-9741 · rfc · standard · source
    Text-conversion control operators; needed where a CDDL schema constrains text representations.
  • A Concise Binary Object Representation (CBOR) Tag for Unprotected CBOR Web Token Claims Sets (UCCS) — H. Birkholz, J. O'Donoghue, N. Cam-Winget, C. Bormann. IETF. 2025-05. RFC 9781
    rfc-9781 · rfc · standard · source
    An unsigned claims set — the shape AclEntry takes in ARCH-0001. Also another registry-allocated tag, so it bears on R-M-12.
  • Fully-Specified Algorithms for JSON Object Signing and Encryption (JOSE) and CBOR Object Signing and Encryption (COSE) — M.B. Jones, O. Steele. IETF. 2025-10. RFC 9864
    rfc-9864 · rfc · standard · source
    Removes polymorphic algorithm identifiers. Anything implementing RFC 9053 today must apply this.
  • CBOR Object Signing and Encryption (COSE) Header Parameter for Timestamp Tokens as Defined in RFC 3161 — H. Birkholz, T. Fossati, M. Riechert. IETF. 2026-02. RFC 9921
    rfc-9921 · rfc · standard · source
    Carries an RFC 3161 timestamp in a COSE header. Relevant only if we need third-party time attestation.
  • CBOR Object Signing and Encryption (COSE) Receipts — O. Steele, H. Birkholz, A. Delignat-Lavaud, C. Fournet. IETF. 2026-06. RFC 9942. draft-ietf-cose-merkle-tree-proofs
    rfc-9942 · rfc · standard · distilled · source
    The receipt format the SCITT architecture (RFC 9943, already held) relies on. Directly relevant to the transparency story.
  • ML-DSA for JSON Object Signing and Encryption (JOSE) and CBOR Object Signing and Encryption (COSE) — M. Prorock, O. Steele. IETF. 2026-05. RFC 9964
    rfc-9964 · rfc · standard · summarized · source
    The current post-quantum signature binding for COSE, and the concrete mechanism behind R-M-02 for PQ keys: its AKP thumbprint rules (6) fix exactly which parameters enter a key digest. Upgraded from marginal on 2026-10-03 after reading 6 against rfc-9679.
  • CBOR Object Signing and Encryption (COSE) Hash Envelope — O. Steele, S. Lasker, H. Birkholz. IETF. 2026-07. RFC 9995
    rfc-9995 · rfc · standard · source
    Signing over a detached payload digest — the pattern R-M-07 describes for artifact statements that must not carry the artifact.

Topic: delegation-models

All four models can bind an email address to a key and can scope a delegate to a name subtree — so what is actually delegated, authority over a name space or authority to make a statement, and who decides where the chain starts?

  • SPKI Requirements — C. Ellison. IETF. 1999-09. RFC 2692
    rfc-2692 · rfc · experimental · summarized · source
    The requirements document explaining WHY SPKI looks as it does. It is also the only place R-M-01 is argued from first principles rather than asserted: ASN.1 is ruled out, and sign-as-transmitted is stated as a requirement, which is R-O-03's problem posed before any canonical form existed.
  • SPKI Certificate Theory — C. Ellison, B. Frantz, B. Lampson, R. Rivest, B. Thomas, T. Ylonen. IETF. 1999-09. RFC 2693
    rfc-2693 · rfc · experimental · distilled · source
    The direct ancestor of this architecture. Its 5-tuple and AIntersect are what R-M-05 and R-M-08 restate, its ACL is R-M-02's unsigned local root, and its boolean-delegation decision is R-M-10. DEC-004 option 1 IS this document's tag language.
  • Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile — D. Cooper, S. Santesson, S. Farrell, S. Boeyen, R. Housley, W. Polk. IETF. 2008-05. RFC 5280
    rfc-5280 · rfc · standard · distilled · source
    R-M-01 names this document as what the native encoding SHALL NOT be, so the claim is only defensible if the record is real. Section 4.2.1.10 plus the 6.1.4 state variables are the closest thing in deployed PKI to scoped delegation, and #14 cannot be written honestly without them.
  • Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 4.0 Message Specification — J. Schaad, B. Ramsdell, S. Turner. IETF. 2019-04. RFC 8551
    rfc-8551 · rfc · standard · summarized · source
    It is a column in #14's table and the honest finding is a negative one: S/MIME 4.0 specifies no delegation and no trust model, deferring certificates entirely. Recording that is what stops the report inventing an S/MIME delegation story.
  • OpenPGP — P. Wouters, D. Huigens, J. Winter, Y. Niibe. IETF. 2024-07. RFC 9580
    rfc-9580 · rfc · standard · distilled · source
    The only record in this lane whose delegation mechanism is both a distinct subpacket and name-scoped by expression, and the only one that chose INTEGER delegation depth — the option RFC 2693 considered and rejected. R-I-04 names OpenPGP identity signatures explicitly, so the import mapping needs this document.
  • Simple Public Key Infrastructure (SPKI) S-Expressions — R. Rivest, D. Eastlake 3rd. IETF. 2025-06. RFC 9804
    rfc-9804 · rfc · informational · distilled · source
    DEC-002 option 1, and the only candidate whose canonical form states uniqueness as an explicit design goal (§6.2). Its §6.2/§6.4 canonical-for-signing versus advanced-for-display split is the architectural ancestor of R-O-05, and §10 imposes no verification ordering, so unlike RFC 8785 it does not conflict with R-O-05.

Topic: deterministic-cbor-profiles

Do the emerging deterministic CBOR profiles converge, and which one should a key-centric profile cite rather than invent?

  • CBOR Common Deterministic Encoding (CDE) — IETF. 2026-04-16. draft-ietf-cbor-cde-13
    draft-ietf-cbor-cde · draft · source
    EXPIRED 2026-04-17 and parked. Recorded because it is still widely cited as the deterministic CBOR profile; the live work is draft-ietf-cbor-serialization.
  • CBOR Serialization and Determinism — IETF. 2026-07-30. draft-ietf-cbor-serialization-08
    draft-ietf-cbor-serialization · draft · source
    The live WG determinism work and the document a signing profile must target. The WG has not said it replaces CDE, so the edge is see_also, not supersedes.
  • dCBOR: Deterministic CBOR — IETF. 2026-08-10. draft-mcnally-deterministic-cbor-18
    draft-mcnally-deterministic-cbor · draft · source
    An INDIVIDUAL draft with no IETF stream and no WG standing, widely miscited as 'the' deterministic CBOR profile. At -18 it narrows RFC 8949 Sec.4.2 directly and does not mention CDE, contrary to common secondary accounts.
  • IPLD DAG-CBOR Specification — IPLD project (Protocol Labs)
    ipld-dag-cbor · spec · draft · source
    A deterministic CBOR profile in production use (IPFS/Filecoin); strict-mode evidence for DEC-002.

Topic: device-attestation

What does a hardware root of trust add that a key alone cannot, and what does it still not prove?

  • Android Key and ID Attestation
    android-key-attestation · web · source
  • DCAppAttestService / App Attest
    apple-app-attest · web · source
  • Learn the architecture: Introducing Arm Confidential Compute Architecture
    arm-cca-den0125 · spec · source
  • Attest an Amazon EC2 instance with AMD SEV-SNP
    aws-snp-attestation · web · source
  • Direct Anonymous Attestation
    brickell-2004-daa · paper · source
  • Arm CCA Reference Attestation Token — IETF. draft-ffm-rats-cca-token
    draft-ffm-rats-cca-token · draft · source
  • Concise Reference Integrity Manifest (CoRIM) — IETF. draft-ietf-rats-corim
    draft-ietf-rats-corim · draft · source
  • Open Profile for DICE
    google-open-dice · spec · source
  • Intel SGX ECDSA QuoteLibReference (DCAP API)
    intel-sgx-dcap-quotelib · spec · source
  • Intel TDX DCAP Quoting Library API
    intel-tdx-dcap-quoting · spec · source
  • Intel Trust Domain Extensions (white paper)
    intel-tdx-whitepaper · spec · source
  • ISO/IEC 11889:2015 Trusted Platform Module Library
    iso-iec-11889-2015 · spec · source
  • Remote ATtestation procedureS (RATS) Architecture — IETF. RFC 9334
    rfc-9334 · rfc · source
  • The Entity Attestation Token (EAT) — IETF. RFC 9711
    rfc-9711 · rfc · source
  • AMD SEV-SNP: A Confidential Computing Primer
    sev-snp-primer-2026 · paper · source
  • DICE Certificate Profiles r01
    tcg-dice-cert-profiles · spec · source
  • Hardware Requirements for a Device Identifier Composition Engine r78
    tcg-dice-hw-requirements · spec · source
  • Implicit Identity Based Device Attestation v1 r0.93
    tcg-dice-implicit-identity · spec · source
  • DICE Layering Architecture v1.0 r0.19
    tcg-dice-layering · spec · source
  • Symmetric Identity Based Device Attestation v1 r0p94
    tcg-dice-symmetric · spec · source
  • TCG Guidance on Integrity Measurements and Event Log Processing v1 r0p118
    tcg-integrity-event-log · spec · source
  • TCG PC Client Platform Firmware Profile Specification r1.05
    tcg-pc-client-pfp · spec · source
  • TCG PC Client Platform TPM Profile (PTP) for TPM 2.0 v1.06 r32
    tcg-pc-client-ptp · spec · source
  • TPM Main Specification Version 1.2, Level 2, Revision 116
    tcg-tpm-1-2-main · spec · source
  • TPM 2.0 Library Specification, Parts 0-4, Version 184
    tcg-tpm-2-0-library-184 · spec · source
  • TPM 2.0 Keys for Device Identity and Attestation v1 r12
    tcg-tpm2-keys-device-identity · spec · source

Topic: library-construction

How should this library itself be built?

  • Citation Style Language — schemas (CSL-JSON) — Citation Style Language project. 2023-01-25
    csl-json-schema · repo · unofficial · source
    CSL-JSON is the interchange format docs/construction.md selected over BibTeX; this repo is its normative schema.
  • Guidelines for performing Systematic Literature Reviews in Software Engineering — 2007
    kitchenham-charters-2007 · paper · source
    The three-stage SLR structure - protocol, conduct, report - that docs/construction.md names as our method and did not hold a record for.
  • The PRISMA 2020 statement: an updated guideline for reporting systematic reviews — 2021
    prisma-2020 · paper · source
    Transparent reporting of what was found, screened and excluded, and why.
  • StrictYAML — Why a restricted YAML subset — HitchDev
    strictyaml-why · web · unofficial · source
    States the case for a YAML subset and the Norway problem — type-inference hazards that bear directly on DEC-002.
  • Guidelines for snowballing in systematic literature studies and a replication in software engineering — 2014
    wohlin-2014-snowballing · paper · source
    Backward and forward snowballing iterated to closure. index/frontier.md is this, mechanised.
  • YAML Ain't Markup Language (YAML) version 1.2.2 — YAML Language Development Team. 2021-10-01
    yaml-1-2-2 · spec · unofficial · source
    The YAML spec our authored sources are written in; the baseline the StrictYAML critique narrows.

Topic: namespace-governance

Who allocates identifiers, and what does key-relative allocation cost?

  • Ballot SC-063v4: Make OCSP Optional, Require CRLs
    cabforum-sc063 · web · source
  • CA/Browser Forum Baseline Requirements for S/MIME Certificates
    cabforum-smime-br · spec · source
  • CA/Browser Forum Baseline Requirements for TLS Server Certificates
    cabforum-tls-br · spec · source
  • Common CA Database (CCADB) public reports
    ccadb · dataset · source
  • Is the Web Ready for OCSP Must-Staple?
    chung-2018-must-staple · paper · source
  • The did:key Method v0.9
    did-key-method · spec · source
  • Simple Public Key Certificate (expired, never published) — IETF. draft-ietf-spki-cert-structure
    draft-ietf-spki-cert-structure · draft · source
  • An Observatory for the SSLiverse
    eff-2010-ssliverse · paper · source
  • Black Tulip: Report of the investigation into the DigiNotar CA breach
    foxit-2012-black-tulip · article · source
  • GnuPG manual: OpenPGP Key Management (tsign, trustspec)
    gnupg-key-management · web · source
  • Go crypto/x509 name-constraint defects (five CVEs, 2025-2026)
    go-nameconstraint-cves · dataset · source
  • TUBITAK Kamu SM root should be constrained (golang/go#61963)
    golang-61963 · web · source
  • Distrusting WoSign and StartCom Certificates
    google-2016-wosign · web · source
  • Chrome's Plan to Distrust Symantec Certificates
    google-2017-symantec · web · source
  • IANA COSE Algorithms registry — IANA. 2026-10-03
    iana-cose-algorithms · dataset · summarized · source
    The authoritative list of what a COSE alg value may be. The RFCs each register a slice; only the registry says what is actually assigned, and checking it caught a stale code point in draft-ietf-cose-sphincs-plus.
  • IANA JSON Web Signature and Encryption Algorithms registry — IANA. 2026-10-03
    iana-jose-algorithms · dataset · summarized · source
    The JOSE counterpart to iana-cose-algorithms. Its Implementation Requirements column is the comparison COSE has no equivalent of, and it is where JOSE records which algorithms are Prohibited.
  • ITU-T X.509: The Directory - Public-key and attribute certificate frameworks
    itu-x509 · spec · source
  • ITU-T X.509 (1988): The Directory - Authentication framework
    itu-x509-1988 · spec · source
  • Revocation doesn't work
    langley-2011-revocation · web · source
  • No, don't enable revocation checking
    langley-2014-revchecking · web · source
  • CRLite: A Scalable System for Pushing All TLS Revocations to All Browsers
    larisch-2017-crlite · paper · source
  • OCSP Service Has Reached End of Life
    letsencrypt-ocsp-eol · web · source
  • An End-to-End Measurement of Certificate Revocation in the Web's PKI
    liu-2015-revocation · paper · source
  • Revoking Trust in one ANSSI Certificate
    mozilla-2013-anssi · web · source
  • Revoking Trust in Two TurkTrust Certificates
    mozilla-2013-turktrust · web · source
  • Name Constraints ignored by libPKIX verification engine
    mozilla-bug-856060 · web · source
  • CVE-2022-3786 and CVE-2022-3602: X.509 Email Address Buffer Overflows
    openssl-2022-email-overflow · web · source
  • PEM Part II: Certificate-Based Key Management — IETF. RFC 1422
    rfc-1422 · rfc · source
  • Internet X.509 PKI Certificate and CRL Profile (2002) — IETF. RFC 3280
    rfc-3280 · rfc · source
  • OpenPGP Message Format — IETF. RFC 4880
    rfc-4880 · rfc · source
  • Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile — D. Cooper, S. Santesson, S. Farrell, S. Boeyen, R. Housley, W. Polk. IETF. 2008-05. RFC 5280
    rfc-5280 · rfc · standard · distilled · source
    R-M-01 names this document as what the native encoding SHALL NOT be, so the claim is only defensible if the record is real. Section 4.2.1.10 plus the 6.1.4 state variables are the closest thing in deployed PKI to scoped delegation, and #14 cannot be written honestly without them.
  • Trust Anchor Format — IETF. RFC 5914
    rfc-5914 · rfc · source
  • Using Trust Anchor Constraints during Certification Path Processing — IETF. RFC 5937
    rfc-5937 · rfc · source
  • Updates to the Internet X.509 PKI Certificate and CRL Profile — IETF. RFC 6818
    rfc-6818 · rfc · source
  • X.509 Internet PKI Online Certificate Status Protocol (OCSP) — IETF. RFC 6960
    rfc-6960 · rfc · source
  • Certificate Transparency — IETF. RFC 6962
    rfc-6962 · rfc · source
  • X.509v3 TLS Feature Extension (OCSP Must-Staple) — IETF. RFC 7633
    rfc-7633 · rfc · source
  • S/MIME Version 4.0 Certificate Handling — IETF. RFC 8550
    rfc-8550 · rfc · source
  • Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 4.0 Message Specification — J. Schaad, B. Ramsdell, S. Turner. IETF. 2019-04. RFC 8551
    rfc-8551 · rfc · standard · summarized · source
    It is a column in #14's table and the honest finding is a negative one: S/MIME 4.0 specifies no delegation and no trust model, deferring certificates entirely. Recording that is what stops the report inventing an S/MIME delegation story.
  • Certificate Transparency Version 2.0 — IETF. RFC 9162
    rfc-9162 · rfc · source
  • Internationalization Updates to RFC 5280 — IETF. RFC 9549
    rfc-9549 · rfc · source
  • OpenPGP — P. Wouters, D. Huigens, J. Winter, Y. Niibe. IETF. 2024-07. RFC 9580
    rfc-9580 · rfc · standard · distilled · source
    The only record in this lane whose delegation mechanism is both a distinct subpacket and name-scoped by expression, and the only one that chose INTEGER delegation depth — the option RFC 2693 considered and rejected. R-I-04 names OpenPGP identity signatures explicitly, so the import mapping needs this document.
  • Internationalized Email Addresses in X.509 Certificates — IETF. RFC 9598
    rfc-9598 · rfc · source
  • No Revocation Available for X.509 Public Key Certificates — IETF. RFC 9608
    rfc-9608 · rfc · source
  • Updates to X.509 Policy Validation — IETF. RFC 9618
    rfc-9618 · rfc · source
  • SDSI — A Simple Distributed Security Infrastructure, version 1.1
    sdsi-1-1 · spec · source
  • Name-constraint prevalence among CCADB-disclosed intermediate CA certificates (original measurement, 2026-09-26)
    survey-2026-nameconstraints-measurement · dataset · source
  • Decentralized Identifiers (DIDs) v1.1
    w3c-did-1-1 · spec · source
  • DID Extensions: Methods registry
    w3c-did-extensions-methods · spec · source
  • Analysis of SSL Certificate Reissues and Revocations in the Wake of Heartbleed
    zhang-2014-heartbleed · paper · source
  • Names: Decentralized, Secure, Human-Meaningful: Choose Two
    zooko-2001-names · article · source

Topic: nist-cryptography

Which primitives does NIST approve for naming, signing and protecting a key, and what does approval settle for a principal named by its key?

  • Secure Hash Standard (SHS) — NIST. 2015-08. doi:10.6028/NIST.FIPS.180-4. FIPS 180-4
    fips-180-4 · spec · standard · summarized · source
    Defines the SHA-2 family. A principal named by key digest under R-M-02 is named by one of these functions, so which are approved is load-bearing on that naming.
  • Digital Signature Standard (DSS), FIPS 186-4 — NIST
    fips-186-4 · spec · historic · source
  • Digital Signature Standard (DSS) — NIST. 2023-02-03. doi:10.6028/NIST.FIPS.186-5. FIPS 186-5
    fips-186-5 · spec · standard · summarized · source
    Defines the signature schemes a key-centric model will actually use; supplies publisher test vectors for PROC-0002 stage 8.
  • Advanced Encryption Standard (AES) — National Institute of Standards and Technology. NIST. 2001-11-26. doi:10.6028/NIST.FIPS.197-upd1. FIPS 197
    fips-197 · spec · standard · summarized · source
    The block cipher every COSE and JOSE symmetric algorithm is built on. Held because rfc-9053 assigns code points for AES-GCM and AES-CCM and the library could not say what they were.
  • SHA-3 Standard: Permutation-Based Hash and Extendable-Output Functions — NIST. 2015-08. doi:10.6028/NIST.FIPS.202. FIPS 202
    fips-202 · spec · standard · summarized · source
    Defines SHA-3 and the SHAKE extendable-output functions. It does not replace FIPS 180-4 — both are approved, which is itself the finding a key-digest naming scheme has to resolve.
  • Module-Lattice-Based Key-Encapsulation Mechanism Standard — NIST. 2024-08-13. doi:10.6028/NIST.FIPS.203. FIPS 203
    fips-203 · spec · standard · summarized · source
    ML-KEM is key ENCAPSULATION - confidentiality, not authentication. Nothing in a key-centric statement model turns on it. Held as the post-quantum counterpart to the signature records, not because it bears on a requirement.
  • Module-Lattice-Based Digital Signature Standard — NIST. 2024-08-13. doi:10.6028/NIST.FIPS.204. FIPS 204
    fips-204 · spec · standard · summarized · source
    The NIST post-quantum signature standard most likely to be the default. Its key and signature sizes are what a key-centric statement model would actually carry, and its 255-byte context string is a domain-separation hook that lands near P4.
  • Stateless Hash-Based Digital Signature Standard — NIST. 2024-08-13. doi:10.6028/NIST.FIPS.205. FIPS 205
    fips-205 · spec · standard · summarized · source
    The conservative post-quantum signature fallback: its security rests only on hash functions, with no lattice assumption. Held as the hedge against ML-DSA, and as the record that shows what signature size a hash-based scheme actually costs.
  • Recommendations for Discrete Logarithm-based Cryptography: Elliptic Curve Domain Parameters — Lily Chen, Dustin Moody, Karen Randall, Andrew Regenscheid, Angela Robinson. NIST. 2023-02. doi:10.6028/NIST.SP.800-186. SP 800-186
    sp-800-186 · spec · best-practice · summarized · source
    Fixes the curve set a federal-facing ECDSA or EdDSA key may come from. A principal named by key or key digest under R-M-02 is named by a point on one of these curves, so which curves are approved bounds that naming — even though ARCH-0001 NG3 defers the suite choice itself.
  • Recommendation for Stateful Hash-Based Signature Schemes — NIST. 2020-10. doi:10.6028/NIST.SP.800-208. SP 800-208
    sp-800-208 · spec · best-practice · summarized · source
    Approves LMS/HSS and XMSS/XMSS-MT - signature schemes whose security rests only on the hash function, and whose STATEFULNESS makes key reuse a correctness failure rather than a weakness. That constraint bears directly on signing canonical bytes.
  • Recommendation for Block Cipher Modes of Operation: Methods and Techniques — Morris Dworkin. NIST. 2001-12. doi:10.6028/NIST.SP.800-38A. SP 800-38A
    sp-800-38a · spec · best-practice · summarized · source
    Defines CBC, which JOSE uses in the A128CBC-HS256 family. Held for that one mode; the other four are background.
  • Recommendation for Block Cipher Modes of Operation: The CCM Mode for Authentication and Confidentiality — Morris Dworkin. NIST. 2004-05. doi:10.6028/NIST.SP.800-38C. SP 800-38C
    sp-800-38c · spec · best-practice · summarized · source
    CCM is the mode behind the eight AES-CCM-* code points in rfc-9053 4.2 — the largest single algorithm family in the COSE initial set.
  • Recommendation for Block Cipher Modes of Operation: Galois/Counter Mode (GCM) and GMAC — Morris Dworkin. NIST. 2007-11. doi:10.6028/NIST.SP.800-38D. SP 800-38D
    sp-800-38d · spec · best-practice · summarized · source
    GCM is A128GCM/A192GCM/A256GCM in both rfc-9053 and rfc-7518. Its IV-uniqueness requirement is the sharpest operational constraint in the symmetric set and belongs on record.
  • Recommendation for Block Cipher Modes of Operation: Methods for Key Wrapping — Morris Dworkin. NIST. 2012-12. doi:10.6028/NIST.SP.800-38F. SP 800-38F
    sp-800-38f · spec · best-practice · summarized · source
    AES Key Wrap is the KW half of JOSE A128KW/A192KW/A256KW and of every ML-KEM+AxxxKW composite in draft-ietf-jose-pqc-kem. #8 lists it as ingest-if-needed; the post-quantum KEM draft is the path that needs it.
  • Recommendation for Pair-Wise Key-Establishment Schemes Using Discrete Logarithm Cryptography — Elaine Barker, Lily Chen, Allen Roginsky, Apostol Vassilev, Richard Davis. NIST. 2018-04. doi:10.6028/NIST.SP.800-56Ar3. SP 800-56Ar3
    sp-800-56ar3 · spec · best-practice · summarized · source
    Named in SP 800-186 Table 2 as the authority for the allowed key-establishment usage of P-224/256/384/521. The library cited that table without holding the document it points at.
  • Recommendation for Key Management: Part 1 - General — NIST. 2020-05. doi:10.6028/NIST.SP.800-57pt1r5. SP 800-57pt1r5
    sp-800-57pt1r5 · spec · best-practice · summarized · source
    Supplies the key-lifecycle vocabulary - cryptoperiod, key state, algorithm strength, transition - that a model naming principals by key needs in order to say what happens when a key expires. We conform to no clause in it.

Topic: post-quantum-migration

Which attestation systems have a stated post-quantum path, and which have a gap?

  • Commercial National Security Algorithm Suite 2.0 (CNSA 2.0) Algorithms and FAQ
    cnsa-2-0 · spec · source
  • Composite ML-DSA for use in X.509 Public Key Infrastructure — IETF. draft-ietf-lamps-pq-composite-sigs
    draft-ietf-lamps-pq-composite-sigs · draft · source
  • in-toto Attestation Framework: Envelope
    in-toto-envelope-v1 · spec · source
  • NIST IR 8547 ipd: Transition to Post-Quantum Cryptography Standards
    nistir-8547 · spec · source
  • NIST IR 8610: Status Report on the Second Round of the Additional Digital Signature Schemes
    nistir-8610 · spec · source
  • XMSS: eXtended Merkle Signature Scheme — IETF. RFC 8391
    rfc-8391 · rfc · source
  • Leighton-Micali Hash-Based Signatures — IETF. RFC 8554
    rfc-8554 · rfc · source
  • Algorithms for Quantum Computation: Discrete Logarithms and Factoring
    shor-1994 · paper · source
  • Polynomial-Time Algorithms for Prime Factorization and Discrete Logarithms on a Quantum Computer
    shor-1997 · paper · source
  • SP 1800-38: Migration to Post-Quantum Cryptography
    sp-1800-38 · spec · source
  • TPM 2.0 Library Specification v1.85 (PQC: ML-KEM, ML-DSA)
    tcg-tpm-2-0-library-185 · spec · source
  • TAP 21: ML-DSA signing scheme for TUF metadata
    tuf-tap-21 · spec · source

Topic: predicate-rendering

How is the meaning of a claim conveyed to a person?

  • Content Credentials: C2PA Technical Specification 2.4
    c2pa-2-4 · spec · source
  • C2PA Conformance Program and Trust List
    c2pa-conformance-program · web · source
  • C2PA User Experience Guidance for Implementers 2.2
    c2pa-ux-2-2 · spec · source
  • CAWG Identity Assertion 1.2
    cawg-identity-1-2 · spec · source
  • Examining the Impact of Provenance-Enabled Media on Trust and Accuracy Perceptions
    cscw-2023-provenance-trust · paper · source
  • An Agent Action Capsule Profile for SCITT — S. Mih. IETF. 2026-09-26. draft-mih-scitt-agent-action-capsule-05
    draft-mih-scitt-agent-action-capsule · draft · source
  • Signals of Provenance: Navigating Indicators in AI-Generated Media for Sighted and Blind Individuals
    ide-2025-signals-of-provenance · paper · source
  • Content Authenticities: A Discussion on the Values of Provenance Data for Creatives and Their Audiences
    moruzzi-2025-content-authenticities · paper · source
  • Content Credentials: Strengthening Multimedia Integrity in the Generative AI Era
    nsa-2025-content-credentials · paper · source
  • PICS 1.1 Label Distribution: Label Syntax and Communication Protocols
    pics-1-1-labels · spec · source
  • PICS 1.1 Rating Services and Rating Systems and Their Machine Readable Descriptions
    pics-1-1-services · spec · source
  • PICS Signed Labels (DSig) 1.0 Specification
    pics-dsig-1-0 · spec · source
  • POWDER: Description Resources
    powder-description-resources · spec · source
  • W3C Platform for Internet Content Selection (PICS)
    w3-org-pics · web · source
  • PROV-DM: The PROV Data Model — W3C. 2013-04-30
    w3c-prov-dm · spec · standard · source
    The provenance data model a predicate vocabulary would be measured against (DEC-007).
  • PROV-O: The PROV Ontology — W3C. 2013-04-30
    w3c-prov-o · spec · standard · source
    The OWL rendering of PROV-DM; the RDF-shaped alternative to our own predicate encoding (DEC-007).
  • Shapes Constraint Language (SHACL) — W3C. 2017-07-20
    w3c-shacl · spec · standard · source
    Constraint-language prior art for validating statement shapes (DEC-007).

Topic: sagai

What do the SAGAI workshops and related AI-security guidance require of systems built on generative AI, and which of those requirements bear on tmodel?

  • Principles for the Secure Integration of Artificial Intelligence in Operational Technology — CISA, Australian Signals Directorate's Australian Cyber Security Centre (ASD's ACSC), NSA Artificial Intelligence Security Center, FBI, Canadian Centre for Cyber Security, German Federal Office for Information Security (BSI), Netherlands National Cyber Security Centre (NCSC-NL), New Zealand National Cyber Security Centre (NCSC-NZ), United Kingdom National Cyber Security Centre (NCSC-UK). Cybersecurity and Infrastructure Security Agency. 2025-12-03
    cisa-ai-in-ot-principles · spec · best-practice · summarized · source
    Seed source for #13. Asks for AI-specific attack vectors and MITRE ATLAS in threat models (DEC-001) and for human-in-the-loop review with an audit trail (R-018).
  • Securing Artificial Intelligence (SAI); Baseline Cyber Security Requirements for AI Models and Systems — ETSI Technical Committee Securing Artificial Intelligence (SAI). ETSI. 2025-12. EN 304 223 V2.1.1. REN/SAI-0022
    etsi-en-304-223 · spec · standard · distilled · source
    The only ratified, testable requirement set in the #13 source family: 72 provisions across the AI lifecycle, including AI-specific threat modelling (5.1.3-1) and human oversight (5.1.4).
  • Exploiting Programmatic Behavior of LLMs: Dual-Use Through Standard Security Attacks — Daniel Kang, Xuechen Li, Ion Stoica, Carlos Guestrin, Matei Zaharia, Tatsunori Hashimoto. accepted at SAGAI'24 (IEEE SPW 2024). 2023-02-11. arXiv:2302.05733
    llm-programmatic-dual-use · paper · summarized · source
    Evidence that content filters are bypassed by classic program-attack techniques; names misuse / filter bypass as an AI threat type.
  • Pre-trained Encoders in Self-Supervised Learning Improve Secure and Privacy-preserving Supervised Learning — Hongbin Liu, Wenjie Qu, Jinyuan Jia, Neil Zhenqiang Gong. accepted at SAGAI'24 (IEEE SPW 2024). 2022-12-06. arXiv:2212.03334
    pretrained-encoders-secure-learning · paper · summarized · source
    Model-level defenses for image classifiers, not GenAI systems; kept because it is a SAGAI'24 paper.
  • SAGAI — IEEE Security and Privacy workshop series on securing generative AI (2024–) — Mihai Christodorescu, John Mitchell, Somesh Jha, Khawaja Shams, Earlence Fernandes. IEEE Security and Privacy Workshops (SPW). 2024. https://sites.google.com/ucsd.edu/sagai25-ieee-sp/. https://sites.google.com/view/sagai-2026. https://ieeexplore.ieee.org/xpl/conhome/10579499/proceeding
    sagai-workshop · hierarchy · summarized · source
    The confirmed target of tmodel #13; parent record that groups the SAGAI papers.
  • Defending Language Models Against Image-Based Prompt Attacks via User-Provided Specifications — Reshabh K Sharma, Vinayak Gupta, Dan Grossman. IEEE Security and Privacy Workshops (SPW) 2024 — SAGAI'24. 2024. 10579532
    spml-image-prompt-injection · paper · summarized · source
    Shows prompt injection through images and a specification-driven input check; widens the AI threat types the object model must express.
  • Defending Against Indirect Prompt Injection Attacks With Spotlighting — Keegan Hines, Gary Lopez, Matthew Hall, Federico Zarfati, Yonatan Zunger, Emre Kıcıman. Microsoft; accepted at SAGAI'24 (IEEE SPW 2024). 2024-03-20. arXiv:2403.14720
    spotlighting-indirect-prompt-injection · paper · summarized · source
    Defines indirect prompt injection and a cheap system-level defense; the threat applies to any AI feature that reads third-party text, tmodel's included.
  • Systems Security Foundations for Agentic Computing — Mihai Christodorescu, Earlence Fernandes, Ashish Hooda, Somesh Jha, Johann Rehberger, Kamalika Chaudhuri, Xiaohan Fu, Khawaja Shams, Guy Amir, Jihye Choi, Sarthak Choudhary, Nils Palumbo, Andrey Labunets, Nishit V. Pandya. 2025-12-01. arXiv:2512.01295
    systems-security-agentic-computing · paper · summarized · source
    Eleven real agent attacks mapped to classic security principles, plus the open problems; the systems view of AI security that the SAGAI papers point to.

Topic: sbom

What does an SBOM prove about an artifact, and which of its claims survive being signed by a principal named by its key?

  • Framing Software Component Transparency: Establishing a Common Software Bill of Materials (SBOM) — CISA SBOM Tooling and Implementation Working Group. Cybersecurity and Infrastructure Security Agency. 2024-09-03
    cisa-framing-software-component-transparency · spec · best-practice · summarized · source
    Promotes the cryptographic hash from NTIA's recommended tier to Minimum Expected, and defines relationship completeness with an explicit open-world default. Both are directly load-bearing for R-M-07 and R-M-11.
  • CycloneDX Bill of Materials Specification — Jan Kowalleck, Steve Springett. OWASP Foundation / Ecma International. 2025-12. ECMA-424, 2nd edition (December 2025)
    cyclonedx-1-7 · spec · standard · source
  • Information technology — SPDX Specification V2.2.1 — ISO/IEC JTC 1/SC 7. International Organization for Standardization. 2021-08. ISO/IEC 5962:2021
    iso-iec-5962-2021 · spec · standard · source
    Held for the standing it establishes, not for its text: it is the one SBOM format with ISO ratification, and it carries SPDX 2.2.1, which SPDX 3.0.1 has moved past. Paywalled, so we work from the 3.0.1 record.
  • The Minimum Elements For a Software Bill of Materials (SBOM) — National Telecommunications and Information Administration. United States Department of Commerce. 2021-07-12. Executive Order 14028 §4(f)
    ntia-sbom-minimum-elements · spec · best-practice · summarized · source
    Establishes the floor for what an SBOM must contain, and — decisively for us — puts the component hash OUTSIDE that floor. That omission is the evidence R-M-07 needs.
  • Cybersecurity Supply Chain Risk Management Practices for Systems and Organizations — Jon Boyens, Angela Smith, Nadya Bartol, Kris Winkler, Alex Holbrook, Matthew Fallon. NIST. 2022-05. doi:10.6028/NIST.SP.800-161r1-upd1. SP 800-161r1-upd1
    sp-800-161r1 · spec · best-practice · source
    Enterprise process guidance, not a mechanism specification. Supplies the vocabulary and the institutional frame that an attestation is consumed by, but we conform to no clause in it.
  • System Package Data Exchange (SPDX) Specification Version 3.0.1 — The Linux Foundation and its Contributors. The Linux Foundation. 2024-12-17
    spdx-3-0-1 · spec · source

Topic: scitt

What does SCITT's transparency service and receipt model settle that a signed statement on its own does not, and what does it cost?

  • SCITT Reference APIs (SCRAPI) — IETF. draft-ietf-scitt-scrapi
    draft-ietf-scitt-scrapi · draft · source
  • An Agent Action Capsule Profile for SCITT — S. Mih. IETF. 2026-09-26. draft-mih-scitt-agent-action-capsule-05
    draft-mih-scitt-agent-action-capsule · draft · source
  • CBOR Object Signing and Encryption (COSE) Receipts — O. Steele, H. Birkholz, A. Delignat-Lavaud, C. Fournet. IETF. 2026-06. RFC 9942. draft-ietf-cose-merkle-tree-proofs
    rfc-9942 · rfc · standard · distilled · source
    The receipt format the SCITT architecture (RFC 9943, already held) relies on. Directly relevant to the transparency story.
  • An Architecture for Trustworthy and Transparent Digital Supply Chains — H. Birkholz, A. Delignat-Lavaud, C. Fournet, Y. Deshpande, S. Lasker. IETF. 2026-06. RFC 9943
    rfc-9943 · rfc · standard · distilled · source
    The ratified, fully-worked version of the shape this project is designing — and its self-contradiction on rollback (§9.4.2 against §5.1.3) is a problem we inherit.

Topic: sdl

What does a secure development lifecycle require — which practices, gates, work products and evidence do the core SDL specifications share, and what object model do they assume?

  • BSI TR-03183-1 Cyber Resilience Requirements for Manufacturers and Products, Part 1: General requirements — Bundesamt für Sicherheit in der Informationstechnik (BSI). Bundesamt für Sicherheit in der Informationstechnik (BSI) / Federal Office for Information Security. 2026-07-31. TR-03183-1
    bsi-tr-03183-1 · spec · best-practice · distilled · source
    BSI's CRA interpretation: an assessable risk-handling method (11 MUST activity controls), Activity/Mechanism/Documentation control types matching R-040, PASS/FAIL/N/A verdict and applicability statement for R-042, CRA Annex I sub-ids for R-044, and machine-matchable risk-scenario control selection.
  • BSI TR-03185 Secure Software Lifecycle — Bundesamt für Sicherheit in der Informationstechnik (BSI). Bundesamt für Sicherheit in der Informationstechnik (BSI) / Federal Office for Information Security. 2026-07-02. TR-03185
    bsi-tr-03185 · spec · best-practice · distilled · source
    National SDL requirement set with native ids, a mandatory content-specified threat model (PROD.DEV.C), an explicit release gate, a certification/audit scheme, and a BSI-published requirement-level crosswalk to IEC 62443-4-1 / SSDF / NESAS / IT-Grundschutz.
  • BSIMM16 — Building Security In Maturity Model (Report 2026) — Black Duck Software, Inc. (BSIMM team; no individual authors named). Black Duck Software, Inc.. 2026-01
    bsimm-16 · spec · informational · distilled · source
    Observational catalogue of 128 SDL activities with counts over 111 firms; gives the most concrete published vocabulary for SDL gates (checkpoint, release condition, exception, sign-off) and edition lineage needed for R-044 crosswalk ids.
  • Secure by Design v1.1: A Guide to Assessing Software Security Practices — Center for Internet Security (CIS), Software Assurance Forum for Excellence in Code (SAFECode). Center for Internet Security / SAFECode. 2026-07-09
    cis-safecode-sbd-assessment-1-1 · spec · best-practice · source
    Same content line as ETSI TS 104 219 (held in full); the CIS/SAFECode spreadsheet would be a machine-readable form but is registration-walled.
  • Secure by Demand Guide: How Software Customers Can Drive a Secure Technology Ecosystem — Cybersecurity and Infrastructure Security Agency (CISA), Federal Bureau of Investigation (FBI). Cybersecurity and Infrastructure Security Agency (CISA) / Federal Bureau of Investigation (FBI). 2024-08-06. https://web.archive.org/web/20260128130827id_/https://www.cisa.gov/sites/default/files/2024-08/SecureByDemandGuide_080624_508c.pdf. https://www.cisa.gov/sites/default/files/2024-08/SecureByDemandGuide_080624_508c.pdf
    cisa-secure-by-demand-guide-2024 · spec · best-practice · distilled · source
    Customer-side questions and evidence checklist mirroring the SbD pledge; concrete automatable checks; distinguishes supplier-supplied vs customer-collected evidence.
  • Secure by Demand: Priority Considerations for Operational Technology Owners and Operators when Selecting Digital Products — Cybersecurity and Infrastructure Security Agency (CISA), National Security Agency (NSA), Federal Bureau of Investigation (FBI), Environmental Protection Agency (EPA), Transportation Security Administration (TSA), Australian Signals Directorate's Australian Cyber Security Centre (ASD's ACSC), Canadian Centre for Cyber Security (CCCS), European Commission DG CONNECT, Federal Office for Information Security (BSI), Netherlands' National Cyber Security Centre (NCSC-NL), New Zealand's National Cyber Security Centre (NCSC-NZ), United Kingdom's National Cyber Security Centre (NCSC-UK). Cybersecurity and Infrastructure Security Agency (CISA), with 11 partner agencies. 2025-01-13. https://www.cisa.gov/sites/default/files/2025-01/joint-guide-secure-by-demand-priority-considerations-for-ot-owners-and-operators-508c_0.pdf. https://www.cisa.gov/sites/default/files/2025-04/Priority-Considerations-for-OT-508c.pdf. TLP:CLEAR
    cisa-secure-by-demand-ot-2025 · spec · best-practice · summarized · source
    Buyers are told to demand a 'full and detailed threat model' from OT manufacturers (element 10) — direct demand-side motivation for tmodel's exportable, governed threat-model view.
  • Shifting the Balance of Cybersecurity Risk: Principles and Approaches for Secure by Design Software — Cybersecurity and Infrastructure Security Agency (CISA), National Security Agency (NSA), Federal Bureau of Investigation (FBI), Australian Cyber Security Centre (ACSC), Canadian Centre for Cyber Security (CCCS), United Kingdom National Cyber Security Centre (NCSC-UK), Federal Office for Information Security (BSI), Netherlands National Cyber Security Centre (NCSC-NL), Norway National Cyber Security Center (NCSC-NO), Computer Emergency Response Team New Zealand (CERT NZ), New Zealand National Cyber Security Centre (NCSC-NZ), Korea Internet & Security Agency (KISA), Israel National Cyber Directorate (INCD), Japan National Center of Incident Readiness and Strategy for Cybersecurity (NISC), Japan Computer Emergency Response Team Coordination Center (JPCERT/CC), OAS/CICTE CSIRT Americas Network, Cyber Security Agency of Singapore (CSA), Czech National Cyber and Information Security Agency (NUKIB). Cybersecurity and Infrastructure Security Agency (CISA), with NSA, FBI and 15 international partner agencies. 2023-10-25. https://web.archive.org/web/20260928143252id_/https://www.cisa.gov/sites/default/files/2023-10/SecureByDesign_1025_508c.pdf. https://www.cisa.gov/sites/default/files/2023-10/SecureByDesign_1025_508c.pdf. TLP:CLEAR
    cisa-secure-by-design-2023 · spec · best-practice · distilled · source
    The acquirer-facing SDL reference: 3 principles, 37 demonstration practices and 20 tactics, each tied to a public artifact (roadmap, SBOM, VDP, CVE+CWE, threat model, self-attestation). It prints SSDF mappings (R-044) and exposes model gaps: configuration/secure-default, class-level mitigation, public governed views.
  • Secure by Design Pledge — Cybersecurity and Infrastructure Security Agency (CISA). Cybersecurity and Infrastructure Security Agency (CISA). 2024-05. https://web.archive.org/web/20260109103624id_/https://www.cisa.gov/sites/default/files/2024-05/CISA%20Secure%20by%20Design%20Pledge_508c.pdf. https://www.cisa.gov/sites/default/files/2024-05/CISA%20Secure%20by%20Design%20Pledge_508c.pdf. https://www.cisa.gov/securebydesign/pledge/progress-reports. https://www.cisa.gov/resources-tools/resources/cisa-secure-design-pledge
    cisa-secure-by-design-pledge-2024 · spec · best-practice · distilled · source
    Seven time-boxed, publicly evidenced goals; Goals 5 and 6 are precise enough to automate as checks over Vulnerability/Weakness nodes; contrasts commitment vs attestation.
  • Secure Software Development Attestation Form (with Instructions) — Cybersecurity and Infrastructure Security Agency (CISA), Department of Homeland Security. U.S. Department of Homeland Security, Cybersecurity and Infrastructure Security Agency. 2024-03-11. https://web.archive.org/web/20260823183523id_/https://www.cisa.gov/sites/default/files/2024-04/Self_Attestation_Common_Form_FINAL_508c.pdf. 1670-0052. https://softwaresecurity.cisa.gov. https://www.cisa.gov/sites/default/files/2024-04/Self_Attestation_Common_Form_FINAL_508c.pdf
    cisa-ssdf-attestation-form-2024 · spec · distilled · source
    A real, signed conformance document: field schema, signatory rules, revocation and a source-published form -> EO 14028 §4(e) -> SSDF crosswalk; template for R-043 governed views and R-044 mappings. Optional for agencies since OMB M-26-05.
  • Software Supply Chain Best Practices v2 — CNCF Security Technical Advisory Group (TAG Security). 2025-03. https://github.com/cncf/tag-security/blob/main/community/working-groups/supply-chain-security/supply-chain-security-paper-v2/Software_Supply_Chain_Practices_whitepaper_v2.pdf
    cncf-supply-chain-best-practices-v2 · paper · white-paper · summarized · source
    Supplies the policy-evaluated-against-attestations model for automated gate checks (R-041/R-042), the Distributor party role and VEX status values, and 59 practice rows for the crosswalk (R-044).
  • ENISA Secure by Design and Default Playbook: A Practical Guide to Secure by Design and Default Principles for SMEs — European Union Agency for Cybersecurity (ENISA). European Union Agency for Cybersecurity (ENISA). 2026-07. doi:10.2824/4422633. TP-01-26-016-EN-N. ISBN 978-92-9204-802-0
    enisa-sbd-playbook-2026 · spec · best-practice · distilled · source
    22 principle playbooks each with checklist, minimum evidence and pass/fail release-gate criteria (125), an attestation cascade (control -> implementation -> verification) for R-042 export, and an indicative principle -> CRA Annex I mapping (62 rows).
  • Executive Order 14028: Improving the Nation's Cybersecurity — Joseph R. Biden Jr. (President of the United States). Executive Office of the President; published in the Federal Register (86 FR 26633, 2021-05-17). 2021-05-12. 14028. 86 FR 26633. 2021-10460
    eo-14028 · spec · distilled · source
    §4(e)(i)-(x) is the US-federal SDL practice hub that the CISA form and SSDF map to; §4(e)(iv) release gate and §4(e)(v) public risk summary inform R-041/R-043.
  • Executive Order 14144: Strengthening and Promoting Innovation in the Nation's Cybersecurity — Joseph R. Biden Jr. (President of the United States). Executive Office of the President; published in the Federal Register (90 FR 6755, 2025-01-17). 2025-01-16. 14144. 90 FR 6755. 2025-01470
    eo-14144 · spec · summarized · source
    Records the high-water mark of the US attestation regime (machine-readable attestations, CISA validation, public results) and the SSDF-update directive; its attestation part was struck by EO 14306.
  • Executive Order 14306: Sustaining Select Efforts To Strengthen the Nation's Cybersecurity and Amending Executive Order 13694 and Executive Order 14144 — Donald J. Trump (President of the United States). Executive Office of the President; published in the Federal Register (90 FR 24723, 2025-06-11). 2025-06-06. 14306. 90 FR 24723. 2025-10804
    eo-14306 · spec · summarized · source
    Removed the CISA attestation-validation / FAR-attestation directives of EO 14144 while keeping a dated SSDF update; explains why the US attestation regime contracted in 2025-2026.
  • Securing the Software Supply Chain: Recommended Practices Guide for Developers — Enduring Security Framework (ESF) Software Supply Chain Working Panel, National Security Agency (NSA), Cybersecurity and Infrastructure Security Agency (CISA), Office of the Director of National Intelligence (ODNI). NSA / CISA / ODNI (Enduring Security Framework). 2022-08
    esf-sscs-developers-2022 · spec · best-practice · distilled · source
    Organised as threat scenario -> recommended mitigation -> lifecycle phase; concrete threat-model governance (2 independent approvers, annual refresh), release criteria and a 60-item SSDF-mapped conformance checklist.
  • Cyber Security (CYBER); Software Security Development and Implementation Framework (SSDIF) — ETSI Technical Committee Cyber Security (CYBER). ETSI (European Telecommunications Standards Institute). 2026-03. ETSI TS 104 219 V1.1.1 (2026-03). DTS/CYBER-00190
    etsi-ts-104-219 · spec · standard · distilled · source
    SSDF-native, normative (183 shall/should actions) SDL with tiered applicability (Development Groups), per-task evidence (DG Artifacts) and roles, and a published SSDF-pivot crosswalk to 29 frameworks plus CRA and UK CRT APC — direct input to MAP-0001, R-042 and R-044.
  • Regulation (EU) 2024/2847 of the European Parliament and of the Council of 23 October 2024 on horizontal cybersecurity requirements for products with digital elements and amending Regulations (EU) No 168/2013 and (EU) 2019/1020 and Directive (EU) 2020/1828 (Cyber Resilience Act) — European Parliament, Council of the European Union. European Parliament and Council of the European Union (Official Journal of the European Union, OJ L, 2024/2847, 20.11.2024). 2024-10-23. 32024R2847. http://data.europa.eu/eli/reg/2024/2847/oj. OJ L, 2024/2847, 20.11.2024
    eu-cra-2024-2847 · spec · standard · distilled · source
    The first binding horizontal SDL law in a major market: risk assessment (threat model), a no-known-exploitable-vulnerabilities release gate, SBOM, CVD and Art 14 reporting clocks (in force since 2026-09-11) are legal obligations evidenced by governed technical documentation — the strongest external anchor for R-041..R-043.
  • Cybersecurity in Medical Devices: Quality Management System Considerations and Content of Premarket Submissions — Guidance for Industry and Food and Drug Administration Staff — U.S. Food and Drug Administration, Center for Devices and Radiological Health, U.S. Food and Drug Administration, Center for Biologics Evaluation and Research. U.S. Food and Drug Administration (CDRH / CBER). 2026-02-03. FDA-2021-D-1158. GUI00001825
    fda-premarket-cybersecurity-guidance · spec · best-practice · distilled · source
    A regulator's premarket review expectation built on a threat model plus traceability (threat model -> risk assessment -> controls -> requirements -> tests, assets -> SBOM): the closest external statement of the R-042 conformance check; 524B makes plan, processes and SBOM statutory for cyber devices.
  • Security for industrial automation and control systems – Part 4-1: Secure product development lifecycle requirements — IEC TC 65. International Electrotechnical Commission (IEC) / ISA (ANSI/ISA-62443-4-1-2018). 2018-01-15. ANSI/ISA-62443-4-1-2018. EN IEC 62443-4-1:2018. IEC 62443-4-1:2018. ISBN 978-2-8322-5239-0
    iec-62443-4-1-2018 · spec · standard · summarized · source
    The most prescriptive SDL process standard: SR-2 is a DFD-shaped threat-model schema, SR-2 k)+SVV-2 define the threats-mitigated conformance check, SM-11/SM-12 define a release gate, and it is being harmonised for the EU CRA.
  • Health software and health IT systems safety, effectiveness and security – Part 5-1: Security – Activities in the product life cycle — IEC SC 62A / ISO TC 215 Joint Working Group. International Electrotechnical Commission (IEC) / International Organization for Standardization (ISO) — double logo. 2021-12. EN IEC 81001-5-1:2022. 13-122. IEC 81001-5-1:2021. IEC 81001-5-1:2021/ISH1:2025. https://www.iso.org/standard/76097.html
    iec-81001-5-1-2021 · spec · standard · summarized · source
    The medical-software derivative of 62443-4-1 (FDA-recognised, EN-adopted): contributes the 62304-ordered phase line, the two conformance routes, and ISH1's software-item support classes / risk-transfer model; normative activities unread (paywalled).
  • Information technology — Security techniques — Application security — Part 1: Overview and concepts — ISO/IEC JTC 1/SC 27. ISO/IEC. 2011-11-21. ISO/IEC 27034-1:2011. 44378. ISO/IEC 27034-1:2011/Cor 1:2014
    iso-iec-27034-1 · spec · standard · summarized · source
    The most object-model-like SDL standard: ONF/ANF (catalogue vs per-application instantiation), the self-verifying ASC (activity + verification measurement + levels of trust, free official XSD), and Targeted vs Actual Level of Trust as the audit-gated 'declared secure' rule — direct input to R-041/R-042/R-043. Only the preview of Part 1 could be read.
  • Information technology — Security techniques — Vulnerability disclosure — ISO/IEC JTC 1/SC 27. ISO/IEC (JTC 1/SC 27). 2018-10. ISO/IEC 29147:2018
    iso-iec-29147-2018 · spec · standard · summarized · source
    The role vocabulary and verified/not-verified gate for vulnerability disclosure; field list for advisories; paired with 30111 it is the response phase of every SDL in MAP-0001. Full value needs a purchased copy (Clauses 6-9, Annex D).
  • Information technology — Security techniques — Vulnerability handling processes — ISO/IEC JTC 1/SC 27. ISO/IEC (JTC 1/SC 27). 2019-10. EN ISO/IEC 30111:2020. ISO/IEC 30111:2019
    iso-iec-30111-2019 · spec · standard · summarized · source
    Vendor-side vulnerability handling: the per-vulnerability lifecycle (DEC-009), a mandatory internal policy with checkable contents incl. a target remediation schedule (R-042/R-043), PSIRT organisation. Clause 7 needs a purchased copy.
  • Microsoft Security Development Lifecycle (SDL) Practices — Microsoft Corporation. Microsoft Corporation. 2024
    microsoft-sdl · spec · recommendation · distilled · source
    Microsoft's current SDL; its threat-modeling practice matches tmodel's core layers, its exception process gives the risk-acceptance lifecycle, and its sub-practice ids are what OWASP SAMM's crosswalk targets.
  • Microsoft Security Development Lifecycle (SDL) Process Guidance – Version 5.2 — Microsoft Corporation. Microsoft Corporation. 2012-05-23
    microsoft-sdl-5-2 · spec · historic · distilled · source
    Legacy, but the most complete public SDL with a real release gate: the Final Security Review's entry guard, reviewer, checks, outcomes, exception path and carry-over are the template for the R-041 Gate and the R-042 threats-mitigated check.
  • Simplified Implementation of the Microsoft SDL — Microsoft Corporation. Microsoft Corporation. 2010-11-04
    microsoft-sdl-simplified-2010 · paper · white-paper · distilled · source
    Microsoft's portable minimum SDL: sixteen numbered mandatory practices, per-phase quality gates approved by an independent advisor, and a compliance-tracking application holding process attestations — precursors of R-041/R-042/R-043.
  • M-22-18: Enhancing the Security of the Software Supply Chain through Secure Software Development Practices — Shalanda D. Young (Director, OMB). Executive Office of the President, Office of Management and Budget. 2022-09-14. M-22-18. https://www.whitehouse.gov/wp-content/uploads/2022/09/M-22-18.pdf
    omb-m-22-18 · spec · distilled · source
    Rescinded, but the clearest worked example of an acquirer-run conformance gate (attest / 3PAO / POA&M / waiver) with dated milestones; informs R-041/R-042 conformance states.
  • M-23-16: Update to Memorandum M-22-18, Enhancing the Security of the Software Supply Chain through Secure Software Development Practices — Shalanda D. Young (Director, OMB). Executive Office of the President, Office of Management and Budget. 2023-06-09. M-23-16. https://www.whitehouse.gov/wp-content/uploads/2023/06/M-23-16-Update-to-M-22-18-Enhancing-Software-Security.pdf
    omb-m-23-16 · spec · distilled · source
    Rescinded; useful for the end-product accountability rule, the compound POA&M+extension guard and an OMB-stated six-phase SDL list.
  • M-26-05: Adopting a Risk-based Approach to Software and Hardware Security — Russell T. Vought (Director, OMB). Executive Office of the President, Office of Management and Budget. 2026-01-23. M-26-05
    omb-m-26-05 · spec · distilled · source
    Current US federal policy (2026): rescinds the mandatory attestation; conformance becomes an agency-owned, risk-based profile — informs R-042/R-044 design (no single fixed baseline).
  • Concise Guide for Developing More Secure Software — OpenSSF (Best Practices Working Group). 2023-06-14
    openssf-concise-guide-secure-software · web · best-practice · summarized · source
    Useful as a crosswalk row source and as a map of which heavier frameworks OpenSSF delegates to; no structure, levels or conformance criteria of its own.
  • Open Source Project Security Baseline (OSPS Baseline) v2026.08.28 — OSPS Baseline Authors (OpenSSF Security Baseline SIG). OpenSSF (Security Baseline SIG, ORBIT WG). 2026-08-28. osps-baseline (ControlCatalog, gemara-version 1.2.0)
    openssf-osps-baseline · spec · best-practice · distilled · source
    MUST-only, level-scoped, machine-readable conformance catalog with source-published crosswalks to 14 frameworks; the template for the R-042 automatable conformance check and the R-044 Requirement/maps_to model.
  • OpenSSF Scorecard — Check Documentation (v5.5.0) — OpenSSF (Scorecard project). 2026-04-23
    openssf-scorecard-checks · web · implementation · summarized · source
    Working model of automated, graded, evidence-backed conformance checks (Check -> Probe -> Finding with six-valued outcome) for R-042, and the probe set is the unit the OSPS Baseline maps to (R-044).
  • OWASP Application Security Verification Standard 5.0.0 — Elar Lang, Josh C Grossman, Jim Manico, Daniel Cuthbert. OWASP Foundation. 2025-05. ASVS-5.0.0. https://github.com/OWASP/ASVS/releases/tag/v5.0.0_release
    owasp-asvs-5 · spec · best-practice · distilled · source
    345 verifiable application requirements with versioned ids, cumulative levels, a stated documentation-vs-implementation split (R-040) and a pass/fail/N/A verification + report model (R-042/R-043); the content of a verification gate, though not an SDL process model.
  • OWASP DevSecOps Maturity Model (DSOMM) — OWASP DSOMM project (leaders: Timo Pagel, Aryan Prasad). OWASP Foundation (DSOMM project). 2026-09-21
    owasp-dsomm · spec · summarized · source
    Secondary: risk→measure activities with per-team implementation/evidence slots and SAMM/ISO/OpenCRE cross-references usable for the R-044 crosswalk.
  • OWASP Software Assurance Maturity Model (SAMM) v2 — OWASP SAMM project (leaders: Seba Deleersnyder, Bart De Win), Pravir Chandra (original author of SAMM). OWASP Foundation (OWASP SAMM project). 2026-07
    owasp-samm-2 · spec · distilled · source
    The only SDL source published as typed, GUID-linked data, with OWASP's own typed crosswalk to SSDF, BSIMM, IEC 62443-4-1, NIST CSF 2.0 and the Microsoft SDL; the reference import case for R-044 and a scored-maturity input to R-041/R-042.
  • PCI Secure Software Lifecycle (Secure SLC) Standard v2.0 — PCI Security Standards Council. PCI Security Standards Council, LLC. 2026-09-28
    pci-secure-slc-2 · spec · standard · summarized · source
    Process-level SDL standard with a formal assessor/listing programme, but the v2.0 text is licence-walled; only public programme facts are usable until a licensed copy is reviewed.
  • Fundamental Practices for Secure Software Development: Essential Elements of a Secure Development Lifecycle Program (Third Edition) — Tony Rice, Nazira Carlage, Josh Brown-White, Wendy Poland, Tania Skinner, Eric Heitzman, Nick Ozmore, Danny Dhillon. SAFECode (Software Assurance Forum for Excellence in Code). 2018-03
    safecode-fpssd-3 · spec · white-paper · distilled · source
    Industry practice baseline with the clearest statements of finding dispositions, TSRV risk acceptance with severity-tiered approvers, documentation-kind mitigations and 'controls as structured data' — inputs to R-040/R-042/R-043.
  • SLSA Specification v1.2 — OpenSSF (SLSA project). 2025-11-24. https://slsa.dev/provenance/v1. https://slsa.dev/verification_summary/v1
    slsa-1-2 · spec · standard · distilled · source
    Template for the R-042 conformance result (VSA: verifier, policy pin, input attestations, PASSED/FAILED, levels), Level/Track vs Gate distinction for R-041, supply-chain threat categories A-I for R-037, and a source-control sub-model tmodel lacks.
  • SP 800-204D: Strategies for the Integration of Software Supply Chain Security in DevSecOps CI/CD Pipelines — Ramaswamy Chandramouli, Frederick Kautz, Santiago Torres-Arias. National Institute of Standards and Technology (NIST). 2024-02. doi:10.6028/NIST.SP.800-204D. SP 800-204D
    sp-800-204d · spec · best-practice · distilled · source
    Pipeline-level operationalisation of SSDF PO/PS/PW.5-9 with a source-published SSDF mapping; its signed-policy-over-typed-attestations admission pattern is the clearest template for an automatable SDL Gate / conformance check (R-041/R-042).
  • SP 800-218: Secure Software Development Framework (SSDF) Version 1.1: Recommendations for Mitigating the Risk of Software Vulnerabilities — Murugiah Souppaya, Karen Scarfone, Donna Dodson. National Institute of Standards and Technology (NIST). 2022-02. doi:10.6028/NIST.SP.800-218. NIST SP 800-218
    sp-800-218 · spec · best-practice · distilled · source
    Backbone requirement set for the SDL object: 42 stable, machine-readable task ids with the source's own crosswalk to 29 practice documents (1,483 identifiers) and to EO 14028; PW.1.1/PW.1.2/PW.2.1 make the threat model a reviewed SDL artifact.
  • Secure Software Development Practices for Generative AI and Dual-Use Foundation Models: An SSDF Community Profile — Harold Booth, Murugiah Souppaya, Apostol Vassilev, Michael Ogata, Martin Stanley, Karen Scarfone. National Institute of Standards and Technology (NIST); co-author from CISA. 2024-07. doi:10.6028/NIST.SP.800-218A. NIST SP 800-218A
    sp-800-218a · spec · best-practice · distilled · source
    The only NIST SSDF Community Profile: it shows the overlay mechanism (priority + R/C/N additions + modified/new tasks over a base requirement set) that the R-044 crosswalk and R-042 conformance need, and it supplies the AI-specific threat types and artifacts (weights, datasets, training pipelines) that a threat model of an AI system has to cover.
  • Secure Software Development Framework (SSDF) Version 1.2: Recommendations for Mitigating the Risk of Software Vulnerabilities (Initial Public Draft) — Harold Booth, Michael Ogata, Murugiah Souppaya, Karen Kent, Donna Dodson. National Institute of Standards and Technology (NIST). 2025-12-17. doi:10.6028/NIST.SP.800-218r1.ipd. NIST SP 800-218r1 ipd
    sp-800-218r1 · spec · draft · distilled · source
    Draft successor to the SSDF backbone: adds PO.6 (continuous improvement) and PS.4 (robust updates/rollback), remaps SP 800-53 to Release 5.2.0, drops EO 14028 mapping. Use as a delta over sp-800-218 until final.
  • SP 800-53 Rev. 5: Security and Privacy Controls for Information Systems and Organizations — Joint Task Force. National Institute of Standards and Technology (NIST), Joint Task Force. 2020-09. doi:10.6028/NIST.SP.800-53r5. SP 800-53 Rev. 5. https://github.com/usnistgov/oscal-content/blob/main/nist.gov/SP800-53/rev5/json/NIST_SP-800-53_rev5_catalog.json
    sp-800-53r5 · spec · best-practice · summarized · source
    The federal control catalog every SDL framework maps into: SSDF and SP 800-161 cite SP80053 ids per task, so SA/SR ids are the join key of the R-044 crosswalk; SA-11(2) mandates developer threat modeling with contextual information, tools, rigor and acceptance criteria — a ready-made R-042 conformance shape.
  • Software Security Code of Practice — Department for Science, Innovation and Technology, National Cyber Security Centre. UK Department for Science, Innovation and Technology (DSIT) / National Cyber Security Centre (NCSC). 2025-05-07. https://www.gov.uk/government/publications/software-security-code-of-practice/software-security-code-of-practice. https://www.ncsc.gov.uk/guidance/software-security-code-of-practice-assurance-principles-claims. https://www.ncsc.gov.uk/collection/software-security-code-of-practice-implementation-guidance
    uk-software-security-code-of-practice · spec · best-practice · distilled · source
    Government SDL conformance profile with a Principle -> Claim -> Evidence chain (APC) that is exactly R-042's missing middle layer, a threat-modelling claim a tmodel model can evidence, all three R-040 mitigation kinds, and a source-published framework mapping (IG Appendix 1).

Topic: signature-foundations

What does a digital signature actually prove, and what did its definition deliberately leave out?

  • New Directions in Cryptography
    diffie-hellman-1976 · paper · source
  • A Public Key Cryptosystem and a Signature Scheme Based on Discrete Logarithms
    elgamal-1985 · paper · source
  • FIPS 186: Digital Signature Standard (DSS), 1994
    fips-186 · spec · source
  • FIPS 186-1: Digital Signature Standard (DSS), 1998
    fips-186-1 · spec · source
  • FIPS 186-2: Digital Signature Standard (DSS), 2000
    fips-186-2 · spec · source
  • FIPS 186-3: Digital Signature Standard (DSS), 2009
    fips-186-3 · spec · source
  • A Paradoxical Solution to The Signature Problem
    gmr-1984-paradoxical · paper · source
  • A Digital Signature Scheme Secure Against Adaptive Chosen-Message Attacks
    gmr-1988-adaptive · paper · source
  • Strong Signature Schemes
    gmy-1983-strong-signatures · paper · source
  • Constructing Digital Signatures from a One Way Function
    lamport-1979-one-way · paper · source
  • Secrecy, Authentication, and Public Key Systems
    merkle-1979-thesis · paper · source
  • Protocols for Public Key Cryptosystems
    merkle-1980-protocols · paper · source
  • A Certified Digital Signature
    merkle-1989-certified · paper · source
  • Digitalized Signatures and Public-Key Functions as Intractable as Factorization
    rabin-1979-tr212 · paper · source
  • Edwards-Curve Digital Signature Algorithm (EdDSA) — IETF. RFC 8032
    rfc-8032 · rfc · source
  • A Method for Obtaining Digital Signatures and Public-Key Cryptosystems
    rsa-1978 · paper · source
  • Efficient Identification and Signatures for Smart Cards
    schnorr-1989-smartcards · paper · source
  • Efficient Signature Generation by Smart Cards
    schnorr-1991-jcryptology · paper · source

Topic: supply-chain-attestation

Why does the supply-chain stack have a strong evidence layer and no entitlement layer?

  • 2026 Minimum Elements for a Software Bill of Materials (SBOM)
    cisa-2026-sbom-minimum · spec · source
  • Emergency Directive 21-01: Mitigate SolarWinds Orion Code Compromise
    cisa-ed-21-01 · web · source
  • Timeline of the xz open source attack
    cox-2024-xz-timeline · web · source
  • SUNSPOT: An Implant in the Build Process
    crowdstrike-sunspot · web · source
  • CVE-2024-3094 (xz-utils backdoor, CVSS 10.0)
    cve-2024-3094 · dataset · source
  • SCITT Reference APIs (SCRAPI) — IETF. draft-ietf-scitt-scrapi
    draft-ietf-scitt-scrapi · draft · source
  • ECMA-424 CycloneDX Bill of Materials Specification, 2nd Edition
    ecma-424 · spec · source
  • Executive Order 14028: Improving the Nation's Cybersecurity — Joseph R. Biden Jr. (President of the United States). Executive Office of the President; published in the Federal Register (86 FR 26633, 2021-05-17). 2021-05-12. 14028. 86 FR 26633. 2021-10460
    eo-14028 · spec · distilled · source
    §4(e)(i)-(x) is the US-federal SDL practice hub that the CISA form and SSDF map to; §4(e)(iv) release gate and §4(e)(v) public risk summary inform R-041/R-043.
  • Executive Order 14144: Strengthening and Promoting Innovation in the Nation's Cybersecurity — Joseph R. Biden Jr. (President of the United States). Executive Office of the President; published in the Federal Register (90 FR 6755, 2025-01-17). 2025-01-16. 14144. 90 FR 6755. 2025-01470
    eo-14144 · spec · summarized · source
    Records the high-water mark of the US attestation regime (machine-readable attestations, CISA validation, public results) and the SSDF-update directive; its attestation part was struck by EO 14306.
  • Executive Order 14306: Sustaining Select Efforts To Strengthen the Nation's Cybersecurity and Amending Executive Order 13694 and Executive Order 14144 — Donald J. Trump (President of the United States). Executive Office of the President; published in the Federal Register (90 FR 24723, 2025-06-11). 2025-06-06. 14306. 90 FR 24723. 2025-10804
    eo-14306 · spec · summarized · source
    Removed the CISA attestation-validation / FAR-attestation directives of EO 14144 while keeping a dated SSDF update; explains why the US attestation regime contracted in 2025-2026.
  • Regulation (EU) 2024/2847 of the European Parliament and of the Council of 23 October 2024 on horizontal cybersecurity requirements for products with digital elements and amending Regulations (EU) No 168/2013 and (EU) 2019/1020 and Directive (EU) 2020/1828 (Cyber Resilience Act) — European Parliament, Council of the European Union. European Parliament and Council of the European Union (Official Journal of the European Union, OJ L, 2024/2847, 20.11.2024). 2024-10-23. 32024R2847. http://data.europa.eu/eli/reg/2024/2847/oj. OJ L, 2024/2847, 20.11.2024
    eu-cra-2024-2847 · spec · standard · distilled · source
    The first binding horizontal SDL law in a major market: risk assessment (threat model), a no-known-exploitable-vulnerabilities release gate, SBOM, CVD and Art 14 reporting clocks (in force since 2026-09-11) are legal obligations evidenced by governed technical documentation — the strongest external anchor for R-041..R-043.
  • event-stream issue #116: I don't know what to say.
    event-stream-issue-116 · web · source
  • Highly Evasive Attacker Leverages SolarWinds Supply Chain with SUNBURST Backdoor
    fireeye-sunburst · web · source
  • backdoor in upstream xz/liblzma leading to ssh server compromise
    freund-2024-xz · web · source
  • GHSA-mh6f-8j2x-4483 (event-stream / flatmap-stream)
    ghsa-event-stream · web · source
  • Rethinking Trust in Forge-Based Git Security (gittuf)
    gittuf-2025 · paper · source
  • in-toto: Providing farm-to-table guarantees for bits and bytes
    in-toto-2019 · paper · source
  • ISO/IEC 5962:2021 SPDX Specification V2.2.1
    iso-iec-5962 · spec · source
  • Details about the event-stream incident
    npm-event-stream · web · source
  • The Minimum Elements For a Software Bill of Materials (SBOM)
    ntia-2021-sbom-minimum · spec · source
  • Backstabber's Knife Collection: A Review of Open Source Software Supply Chain Attacks
    ohm-2020-backstabbers · paper · source
  • Trusted Publishers for PyPI
    pypi-trusted-publishers · web · source
  • Sigstore: Software Signing for Everybody
    sigstore-2022 · paper · source
  • Sigstore Threat Model
    sigstore-threat-model · web · source
  • SLSA Specification v1.2 — OpenSSF (SLSA project). 2025-11-24. https://slsa.dev/provenance/v1. https://slsa.dev/verification_summary/v1
    slsa-1-2 · spec · standard · distilled · source
    Template for the R-042 conformance result (VSA: verifier, policy pin, input attestations, PASSED/FAILED, levels), Level/Track vs Gate distinction for R-041, supply-chain threat categories A-I for R-037, and a source-control sub-model tmodel lacks.
  • Mini Shai-Hulud: Where SLSA's Boundaries Fall
    slsa-2026-mini-shai-hulud · web · source
  • SLSA Provenance v1.1 (SLSA Specification v1.2) — Open Source Security Foundation (OpenSSF)
    slsa-provenance-1-2 · spec · source
    Named in the PLAN-0001 §15 seed; not yet assessed against a decision.
  • SLSA Verification Summary Attestation (VSA) v1.1 — Open Source Security Foundation (OpenSSF)
    slsa-vsa-1-2 · spec · source
    Named in the PLAN-0001 §15 seed; not yet assessed against a decision.
  • SolarWinds Form 8-K, Item 8.01, 14 December 2020
    solarwinds-8k · web · source
  • SP 800-218: Secure Software Development Framework (SSDF) Version 1.1: Recommendations for Mitigating the Risk of Software Vulnerabilities — Murugiah Souppaya, Karen Scarfone, Donna Dodson. National Institute of Standards and Technology (NIST). 2022-02. doi:10.6028/NIST.SP.800-218. NIST SP 800-218
    sp-800-218 · spec · best-practice · distilled · source
    Backbone requirement set for the SDL object: 42 stable, machine-readable task ids with the source's own crosswalk to 29 practice documents (1,483 identifiers) and to EO 14028; PW.1.1/PW.1.2/PW.2.1 make the threat model a reviewed SDL artifact.
  • Survivable key compromise in software update systems
    tuf-2010 · paper · source
  • The Update Framework Specification v1.0.36
    tuf-spec · spec · source
  • XZ Utils backdoor (upstream project statement)
    tukaani-xz-backdoor · web · source
  • Typosquatting and Combosquatting Attacks on the Python Ecosystem
    vu-2020-typosquatting · paper · source

Topic: uptake-failure

Why did SPKI and PICS fail to take hold?

  • Fahrenheit 451.2: Is Cyberspace Burning?
    aclu-fahrenheit-451-2 · web · source
  • California AI Transparency Act SB 942, as amended by AB 853
    ca-sb-942 · spec · source
  • CVE-2019-13050: SKS keyserver certificate spamming attack
    cve-2019-13050 · web · source
  • Ten Risks of PKI: What You're not Being Told about Public Key Infrastructure
    ellison-schneier-2000-ten-risks · paper · source
  • EU AI Act Article 50: Transparency Obligations
    eu-ai-act-art-50 · spec · source
  • EU Code of Practice on marking and labelling AI-generated content
    eu-code-of-practice-marking · web · source
  • PKI: It's Not Dead, Just Resting
    gutmann-2002-pki-not-dead · paper · source
  • GVU 10th WWW User Survey: webmaster PICS labelling rates
    gvu-1998-webmaster-survey · dataset · source
  • IETF SPKI Working Group charter and documents
    ietf-spki-wg · web · source
  • keys.openpgp.org FAQ: third-party certification policy
    keys-openpgp-org-faq · web · source
  • PICS, Censorship, and Intellectual Freedom FAQ
    pics-censorship-faq · web · source
  • Proactive Software Supply Chain Risk Management Framework (P-SSCRM) Version 1 — 2024
    psscrm-v1 · paper · source
    72 tasks unifying SSDF, 800-161r1, SLSA, S2C2F, CNCF and SCVS. The sponsor asked for a task mapping in the final report.
  • Automatic Certificate Management Environment (ACME) — IETF. RFC 8555
    rfc-8555 · rfc · source
  • Investigating the OpenPGP Web of Trust
    ulrich-2011-openpgp-wot · paper · source
  • W3C TAG proposal to obsolete CC/PP and POWDER (issue 86)
    w3c-tag-obsolete-powder · web · source
  • Reducing the Dependence of SPKI/SDSI on PKI
    wang-2006-reducing-spki · paper · source
  • Zoom Acquires Keybase
    zoom-keybase-2020 · web · source