[saag] Security review request: draft-hezami-pulseproof-sent inel (PPS)

--===============5533626198779978881==
Content-Type: multipart/alternative; boundary="00000000000089e08d0657447ac2"

--00000000000089e08d0657447ac2
Content-Type: text/plain; charset="UTF-8"

Hi,

I would appreciate security review and feedback on an individual
Internet-Draft:

Title: PulseProof Sentinel Protocol
Draft: draft-hezami-pulseproof-sentinel
Datatracker:
https://datatracker.ietf.org/doc/draft-hezami-pulseproof-sentinel/
Repository: https://github.com/pps-protocol/pulseproof-sentinel
Documentation: https://pps-protocol.github.io/pulseproof-sentinel/docs/

PPS is an experimental protocol for time-bound asymmetric authentication
proofs. It replaces shared-secret TOTP-style codes with signed, time-bound,
asymmetric proofs called Pulses.

The protocol is intended to complement WebAuthn/FIDO2, not replace it.
WebAuthn remains preferred for browser-based passkey authentication. PPS
focuses on offline OTP-style flows, constrained terminals, transaction
signing, silent duress signaling, and offline threshold approval.

I would particularly appreciate security feedback on the following areas:

1. Scope and positioning
   - Is the relationship to WebAuthn/FIDO2 clear?
   - Is the target deployment model sufficiently well-defined?

2. Forward-secure ratchet
   - The protocol defines an optional verifiable asymmetric key ratchet
     using signed rotation to a next public key.
   - Are there concerns with this model?

3. Silent duress / Honey-Pulse
   - PPS allows a hidden duress key. A Pulse signed by the duress key is
     cryptographically valid but should trigger silent restrictions.
   - Are there privacy, safety, or protocol-design concerns?

4. Threshold mode
   - Version 1 uses n-of-m Ed25519 multisignature over the same payload.
   - Is this model clear and safe for offline transaction approval?

5. Trust Code derivation
   - PPS derives a short human-verifiable Trust Code from the signature
     using HKDF-SHA256 and rejection sampling.
   - Are there concerns with this construction?

The draft is experimental and has not been independently audited. I am
looking for early community review before considering any further
standardization steps.

Thanks,
Hossein Hezami
Independent

--00000000000089e08d0657447ac2
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">Hi,<br><br>I would appreciate security review and feedback=
 on an individual<br>Internet-Draft:<br><br>Title: PulseProof Sentinel Prot=
ocol<br>Draft: draft-hezami-pulseproof-sentinel<br>Datatracker: <a href=3D"=
https://datatracker.ietf.org/doc/draft-hezami-pulseproof-sentinel/">https:/=
/datatracker.ietf.org/doc/draft-hezami-pulseproof-sentinel/</a><br>Reposito=
ry: <a href=3D"https://github.com/pps-protocol/pulseproof-sentinel">https:/=
/github.com/pps-protocol/pulseproof-sentinel</a><br>Documentation: <a href=
=3D"https://pps-protocol.github.io/pulseproof-sentinel/docs/">https://pps-p=
rotocol.github.io/pulseproof-sentinel/docs/</a><br><br>PPS is an experiment=
al protocol for time-bound asymmetric authentication<br>proofs. It replaces=
 shared-secret TOTP-style codes with signed, time-bound,<br>asymmetric proo=
fs called Pulses.<br><br>The protocol is intended to complement WebAuthn/FI=
DO2, not replace it.<br>WebAuthn remains preferred for browser-based passke=
y authentication. PPS<br>focuses on offline OTP-style flows, constrained te=
rminals, transaction<br>signing, silent duress signaling, and offline thres=
hold approval.<br><br>I would particularly appreciate security feedback on =
the following areas:<br><br>1. Scope and positioning<br>=C2=A0 =C2=A0- Is t=
he relationship to WebAuthn/FIDO2 clear?<br>=C2=A0 =C2=A0- Is the target de=
ployment model sufficiently well-defined?<br><br>2. Forward-secure ratchet<=
br>=C2=A0 =C2=A0- The protocol defines an optional verifiable asymmetric ke=
y ratchet<br>=C2=A0 =C2=A0 =C2=A0using signed rotation to a next public key=
.<br>=C2=A0 =C2=A0- Are there concerns with this model?<br><br>3. Silent du=
ress / Honey-Pulse<br>=C2=A0 =C2=A0- PPS allows a hidden duress key. A Puls=
e signed by the duress key is<br>=C2=A0 =C2=A0 =C2=A0cryptographically vali=
d but should trigger silent restrictions.<br>=C2=A0 =C2=A0- Are there priva=
cy, safety, or protocol-design concerns?<br><br>4. Threshold mode<br>=C2=A0=
 =C2=A0- Version 1 uses n-of-m Ed25519 multisignature over the same payload=
.<br>=C2=A0 =C2=A0- Is this model clear and safe for offline transaction ap=
proval?<br><br>5. Trust Code derivation<br>=C2=A0 =C2=A0- PPS derives a sho=
rt human-verifiable Trust Code from the signature<br>=C2=A0 =C2=A0 =C2=A0us=
ing HKDF-SHA256 and rejection sampling.<br>=C2=A0 =C2=A0- Are there concern=
s with this construction?<br><br>The draft is experimental and has not been=
 independently audited. I am<br>looking for early community review before c=
onsidering any further<br>standardization steps.<br><br>Thanks,<br>Hossein =
Hezami<br>Independent</div>

--00000000000089e08d0657447ac2--


--===============5533626198779978881==
Content-Type: text/plain; charset="utf-8"
MIME-Version: 1.0
Content-Transfer-Encoding: base64
Content-Disposition: inline

X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18Kc2FhZyBtYWls
aW5nIGxpc3QgLS0gc2FhZ0BpZXRmLm9yZwpUbyB1bnN1YnNjcmliZSBzZW5kIGFuIGVtYWlsIHRv
IHNhYWctbGVhdmVAaWV0Zi5vcmcK

--===============5533626198779978881==--