Aspect
Section: 3.1 Profile objective & scope
Orientation relevance: both
A "profile" is simply a checklist of which cryptography facts to report for one particular job. Before anyone can build a useful checklist, the profile has to say plainly what job it is for and where it begins and ends. This issue decides how every profile states its purpose and its boundaries up front, so the checklist stays focused instead of trying to cover everything.
Examples
A Supply-chain PQC-migration profile, asked of vendors so an operator can sequence a quantum-safe migration across a multi-vendor estate. This profile is created by the suppliers: for each product it declares the current PQC posture, whether hybrid key exchange is supported, the planned dates for PQC support, whether the change will ship as a software update or needs a hardware refresh, and any certification dependencies that gate it. Its boundary is drawn by what the operator needs to coordinate migration across suppliers, the forward-looking commitments and dependencies that determine the order in which things can move, rather than the full cryptographic inventory of each product
A regulatory-reporting profile exists so an operator can show a regulator that it meets its cybersecurity obligations. Here the reader is an auditor rather than a buyer, and the decision is "are we compliant?" Its boundary is drawn by what the regulation designates as in-scope, perhaps only the network elements officially classed as critical infrastructure — rather than every system the operator runs. This shows how the same organisation can need several profiles, each scoped to a different audience.
A certificate-reporting profile gives a PKI or operations team a view of the certificates across its estate, what they are, who issued them, when they expire, and what cryptography they rely on. Its reader is the team responsible for keeping services valid and trusted, and the decisions it supports are avoiding expiry-driven outages, knowing which certificate authorities and trust anchors are relied upon, and judging how quantum-ready the certificates' signatures are. Its boundary is drawn by asset type: it covers certificates, their issuers and trust anchors, validity periods, and the key and signature algorithms they use, and leaves aside the protocol and library detail that a procurement or migration profile would need. Where a procurement profile describes the estate product-by-product, this one describes it certificate-by-certificate, because the job is watching the certificate estate rather than evaluating a purchase.
Objective
Decide how a profile states the decision or process it exists to support, declares its orientation, and bounds what it covers, so that attribute selection has an anchor and conformance can be judged.
Background & links
Scoping document §3.1 (rationale and decisions) and §2.1–2.2 (why a profile needs a stated
objective and a floor/ceiling). The orientation distinction is set out in §2.5. This aspect
produces the "preamble" that every other aspect's output hangs from.
Options under consideration
- Mandatory structured preamble — every profile opens with required fields: objective,
intended consumers, supported decision(s), orientation, and an explicit in-scope / out-of-scope
boundary. (Trade-off: more upfront rigour; slightly heavier to author.)
- Light objective statement + minimal metadata — free-text objective plus a small fixed
field set. (Trade-off: lower barrier; weaker comparability across profiles.)
- Scope boundary expression — by component type, asset domain, interface, or lifecycle
stage, or a declared combination of these.
Open questions
Dependencies
Feeds the obligation rules (3.4 #6) and roadmap scope (3.10 #10). Largely independent
to start; no hard upstream blocker.
Decision
Not yet decided.
Impact on the specification
Spec section "Defining a profile: objective, scope, and orientation."
Aspect
Section: 3.1 Profile objective & scope
Orientation relevance: both
A "profile" is simply a checklist of which cryptography facts to report for one particular job. Before anyone can build a useful checklist, the profile has to say plainly what job it is for and where it begins and ends. This issue decides how every profile states its purpose and its boundaries up front, so the checklist stays focused instead of trying to cover everything.
Examples
A Supply-chain PQC-migration profile, asked of vendors so an operator can sequence a quantum-safe migration across a multi-vendor estate. This profile is created by the suppliers: for each product it declares the current PQC posture, whether hybrid key exchange is supported, the planned dates for PQC support, whether the change will ship as a software update or needs a hardware refresh, and any certification dependencies that gate it. Its boundary is drawn by what the operator needs to coordinate migration across suppliers, the forward-looking commitments and dependencies that determine the order in which things can move, rather than the full cryptographic inventory of each product
A regulatory-reporting profile exists so an operator can show a regulator that it meets its cybersecurity obligations. Here the reader is an auditor rather than a buyer, and the decision is "are we compliant?" Its boundary is drawn by what the regulation designates as in-scope, perhaps only the network elements officially classed as critical infrastructure — rather than every system the operator runs. This shows how the same organisation can need several profiles, each scoped to a different audience.
A certificate-reporting profile gives a PKI or operations team a view of the certificates across its estate, what they are, who issued them, when they expire, and what cryptography they rely on. Its reader is the team responsible for keeping services valid and trusted, and the decisions it supports are avoiding expiry-driven outages, knowing which certificate authorities and trust anchors are relied upon, and judging how quantum-ready the certificates' signatures are. Its boundary is drawn by asset type: it covers certificates, their issuers and trust anchors, validity periods, and the key and signature algorithms they use, and leaves aside the protocol and library detail that a procurement or migration profile would need. Where a procurement profile describes the estate product-by-product, this one describes it certificate-by-certificate, because the job is watching the certificate estate rather than evaluating a purchase.
Objective
Decide how a profile states the decision or process it exists to support, declares its orientation, and bounds what it covers, so that attribute selection has an anchor and conformance can be judged.
Background & links
Scoping document §3.1 (rationale and decisions) and §2.1–2.2 (why a profile needs a stated
objective and a floor/ceiling). The orientation distinction is set out in §2.5. This aspect
produces the "preamble" that every other aspect's output hangs from.
Options under consideration
intended consumers, supported decision(s), orientation, and an explicit in-scope / out-of-scope
boundary. (Trade-off: more upfront rigour; slightly heavier to author.)
field set. (Trade-off: lower barrier; weaker comparability across profiles.)
stage, or a declared combination of these.
Open questions
Dependencies
Feeds the obligation rules (3.4 #6) and roadmap scope (3.10 #10). Largely independent
to start; no hard upstream blocker.
Decision
Not yet decided.
Impact on the specification
Spec section "Defining a profile: objective, scope, and orientation."