pulseproof-sentinel

Security Policy

PulseProof Sentinel Protocol, abbreviated PPS, is an experimental protocol.

It has not been independently audited.

Do not use PPS in production systems without proper cryptographic review, security audit, and operational risk assessment.

Supported Versions

Only the latest published draft and repository materials are considered for security review.

Version / Draft	Status	Security Issues Accepted
`draft-hezami-pulseproof-sentinel-00`	Experimental	Yes
Older revisions	Obsolete	No

Reporting a Vulnerability

Please do not open public GitHub issues for security vulnerabilities.

If you discover a security issue in the specification, documentation, examples, or reference implementations, please report it privately.

Preferred Reporting Methods

Use GitHub Private Vulnerability Reporting if enabled.
Or send an email to:

hossein.hezami@gmail.com

What to Include

Please include as much of the following as possible:

description of the vulnerability
affected specification section, file, or implementation
protocol version and draft revision
proof of concept, if available
impact analysis
suggested mitigation, if known
whether the issue affects:
- specification
- CBOR encoding rules
- cryptographic derivation
- duress model
- threshold mode
- ratchet model
- example code
- documentation

Response Timeline

The maintainers will make a best-effort attempt to follow these timelines:

Event	Target
Acknowledgement of report	7 days
Initial triage	14 days
Status update	30 days
Public disclosure coordination	as appropriate

Because PPS is experimental, response times may vary.

Scope

Security reports may cover:

protocol design flaws
cryptographic misuse
ambiguity leading to insecure implementations
replay or downgrade issues
duress leakage
threshold bypass
CBOR canonicalization issues
Trust Code derivation issues
example implementation vulnerabilities
documentation security gaps

Out of Scope

The following are generally out of scope unless they reveal a protocol-level issue:

social engineering
physical coercion beyond the documented duress model
compromised operating systems with full control
denial-of-service attacks without protocol impact
missing rate limiting in third-party deployments
production misconfiguration
unsupported or obsolete draft revisions

Safe Harbor

Good-faith security research conducted in accordance with this policy is welcome.

Researchers should:

avoid privacy violations
avoid data destruction
avoid service disruption
avoid accessing other users’ data
report issues privately before public disclosure

IETF IPR Note

PPS is submitted as an IETF Internet-Draft.

Intellectual property disclosures related to IETF work should follow the IETF IPR policy.

See:

https://datatracker.ietf.org/ipr/

Because PPS includes an optional silent duress mechanism, special care is required for vulnerabilities that could reveal duress state.

Examples of serious duress-related issues:

server response differs for duress authentication
timing side-channel reveals duress detection
error messages reveal duress public key matching
client UI leaks duress mode
logs exposed to attackers reveal duress events

Such issues should be treated as high severity.

Public Disclosure Policy

Please do not publicly disclose a security issue before coordinating with maintainers.

If no response is received within a reasonable time, or if the issue is clearly low risk, responsible disclosure may proceed.

Security Checklist for Implementers

Before reporting an implementation-specific issue, check whether the issue is caused by:

non-canonical CBOR parsing
standard base64 instead of base64url
missing nonce validation
counter update before signature verification
missing rate limiting
weak private key storage
non-constant-time Trust Code comparison
incorrect policy hash comparison
incorrect AmountMark handling
returning different responses for duress mode

These are common implementation mistakes and may not be protocol vulnerabilities.