[lamps] Re: [PROPOSAL] Cryptographic Binding for draft-bonnell-lamps-chameleon-certs (DCD-Base Binding)

[Sarat G <[e-mail]>]

Hi Russ,

Thanks for the feedback. Making baseBinding mandatory (non-OPTIONAL) makes
sense: it keeps the binding as a core part of the Chameleon structure and
helps prevent downgrade or stripping attacks.

To stay consistent with the draft’s tagging, I propose adding the binding
as a mandatory field with tag [5], placed before the signature value to
ensure it is covered by the descriptor's integrity check.

Proposed ASN.1:

DeltaCertificateDescriptor ::= SEQUENCE {
serialNumber CertificateSerialNumber,
signature [0] EXPLICIT AlgorithmIdentifier OPTIONAL,
issuer [1] EXPLICIT Name OPTIONAL,
validity [2] EXPLICIT Validity OPTIONAL,
subject [3] EXPLICIT Name OPTIONAL,
subjectPublicKeyInfo SubjectPublicKeyInfo,
extensions [4] EXPLICIT Extensions OPTIONAL,
baseBinding [5] EXPLICIT BaseBinding,
signatureValue BIT STRING
}

BaseBinding ::= SEQUENCE {
hashAlgorithm AlgorithmIdentifier,
bindingValue OCTET STRING -- Hash of Base's subjectPublicKeyInfo
}

This keeps the DCD compact while adding the needed binding. I’d be
interested in feedback from the draft authors (Corey, John) on any
implementation impact of making this mandatory from the start.

Regards,
Sarat G




On Mon, Feb 23, 2026 at 8:52 PM Russ Housley <[e-mail]> wrote:

> I think that baseBinding should not be OPTIONAL.
>
> Russ
>
>
> > On Feb 23, 2026, at 8:56 AM, Sarat G <[e-mail]>
> wrote:
> >
> > Dear LAMPS Working Group and Authors,
> >
> > I have been reviewing draft-bonnell-lamps-chameleon-certs and would like
> to propose a technical addition to the Delta Certificate Descriptor (DCD)
> extension: a cryptographic binding between the Base certificate and the
> Delta it carries.
> >
> > 1. The Problem: DCD Substitution (Grafting)
> >
> > The DCD extension is part of the Base certificate's TBS and is covered
> by the CA's signature. However, there is no field within the DCD that
> cryptographically links the Delta to the specific Base that carries it.
> >
> > In scenarios where a verifier processes only the PQC (Delta) path, or
> where the classical (Base) issuer key is compromised, an attacker could
> theoretically graft a valid DCD from one certificate onto a different Base.
> A PQC-only verifier would have no way to cryptographically confirm that the
> Delta belongs to the Base it is paired with.
> >
> > 2. The Proposal: DCD–Base Binding
> >
> > Add an optional baseBinding field to the DeltaCertificateDescriptor
> containing a hash of the Base certificate's subjectPublicKeyInfo (SPKI).
> >
> > Why SPKI?
> >
> > - Avoids circularity: The DCD is inside the Base's TBS, so hashing the
> full TBS would be self-referential.
> > - Identity link: The Base's SPKI identifies the subject's classical key.
> Binding ensures the Delta is tied to that same subject.
> >
> > 3. Proposed ASN.1 Addition
> >
> > Add to DeltaCertificateDescriptor (new optional field with context tag
> [5]):
> >
> > DeltaCertificateDescriptor ::= SEQUENCE {
> > serialNumber CertificateSerialNumber,
> > signature [0] EXPLICIT AlgorithmIdentifier OPTIONAL,
> > issuer [1] EXPLICIT Name OPTIONAL,
> > validity [2] EXPLICIT Validity OPTIONAL,
> > subject [3] EXPLICIT Name OPTIONAL,
> > subjectPublicKeyInfo SubjectPublicKeyInfo,
> > extensions [4] EXPLICIT Extensions OPTIONAL,
> > baseBinding [5] EXPLICIT BaseBinding OPTIONAL, -- NEW
> > signatureValue BIT STRING
> > }
> >
> > BaseBinding ::= SEQUENCE {
> > hashAlgorithm AlgorithmIdentifier,
> > bindingValue OCTET STRING -- Hash of Base's subjectPublicKeyInfo
> > }
> >
> > 4. Verification Logic
> >
> > A PQC-aware verifier would:
> >
> > 1. Extract baseBinding from the DCD (if present).
> > 2. Compute Hash(Base.subjectPublicKeyInfo) using the specified algorithm.
> > 3. Reject the Delta if the hashes do not match, regardless of signature
> validity.
> >
> > 5. Rationale
> >
> > - Defense-in-depth: Strengthens the model for PQC-only or PQC-preferred
> verifiers.
> > - Minimal overhead: Hashing a public key is cheap; certificate size
> increase is small.
> > - Backward compatibility: OPTIONAL with explicit tagging; existing
> implementations ignore unknown fields.
> >
> > I would appreciate the group's feedback on whether this is a useful
> addition to the draft or if it should be pursued as a standalone extension.
> >
> > Regards,
> > Sarat G
> >
> >
> > _______________________________________________
> > Spasm mailing list -- [e-mail]
> > To unsubscribe send an email to [e-mail]
>
>