Skip to content

sm: make Inband-Security-Id configurable in Client CER#240

Merged
fiorix merged 1 commit into
fiorix:mainfrom
tridentsx:fix/239-configurable-inband-security-id
May 1, 2026
Merged

sm: make Inband-Security-Id configurable in Client CER#240
fiorix merged 1 commit into
fiorix:mainfrom
tridentsx:fix/239-configurable-inband-security-id

Conversation

@tridentsx

Copy link
Copy Markdown
Contributor

Add InbandSecurityID field to sm.Client allowing callers to propose TLS (value 1) during CER/CEA exchange per RFC 6733 §5.3.1. The zero value preserves existing behavior (NO_INBAND_SECURITY).

Changes

  • Add InbandSecurityID uint32 field to sm.Client struct
  • Use the field value in makeCER() instead of hardcoded 0
  • Add two tests verifying default (0) and TLS (1) values are sent

RFC Reference

RFC 6733 §5.3.1 defines Inband-Security-Id AVP (code 299) with values 0 (NO_INBAND_SECURITY) and 1 (TLS).

All existing tests pass.

Fixes #239

Add InbandSecurityID field to sm.Client allowing callers to propose
TLS (value 1) during CER/CEA exchange per RFC 6733 §5.3.1.

The zero value preserves existing behavior (NO_INBAND_SECURITY).

Fixes fiorix#239
@fiorix

fiorix commented May 1, 2026

Copy link
Copy Markdown
Owner

LGTM. Minimal, backwards-compatible (zero-value preserves prior behavior), tests cover both the default and TLS=1 paths. Will merge.

@fiorix fiorix merged commit 3513c6c into fiorix:main May 1, 2026
1 check passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Client CER hardcodes Inband-Security-Id=0 — cannot propose TLS to peers (RFC 6733 §5.3.1)

2 participants