Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Compound attestation statement format is incompatible with attStmtTemplate #2210

Open
emlun opened this issue Nov 20, 2024 · 0 comments · May be fixed by #2216
Open

Compound attestation statement format is incompatible with attStmtTemplate #2210

emlun opened this issue Nov 20, 2024 · 0 comments · May be fixed by #2216

Comments

@emlun
Copy link
Member

emlun commented Nov 20, 2024

6.5.4. Generating an Attestation Object defines a CDDL template for attestation statement formats:

attObj = {
            authData: bytes,
            $$attStmtType
         }

attStmtTemplate = (
                      fmt: text,
                      attStmt: { * tstr => any } ; Map is filled in by each concrete attStmtType
                  )

; Every attestation statement format must have the above fields
attStmtTemplate .within $$attStmtType

Note that the attStmt member is defined as a CBOR map.

§8.9. Compound Attestation Statement Format defines a choice for the $$attStmtType group socket:

$$attStmtType //= (
                      fmt: "compound",
                      attStmt: [2* nonCompoundAttStmt]
                  )

nonCompoundAttStmt = { $$attStmtType } .within { fmt: text .ne "compound" }

Note that the attStmt member here is a CBOR array.

I also don't think the expression attStmtTemplate .within $$attStmtType successfully encodes the intent Every attestation statement format must have the above fields, for two reasons: it does not define a CDDL rule since it contains no = sign, and even if it did, the .within control operator would apply only to the new type defined by that rule, but not to the attObj type.

On the 2024-11-20 WG call it was said that there are implementations of compound attestation shipping, so the preferred resolution to this is to relax the template to allow array-based attestation statements.

Proposed Change

  1. Inline the .within control operator into the attObj definition:

    attObj = {
        authData: bytes,
        $$attStmtType
    } .within attStmtTemplate  ; Every attestation statement format must have the fields below
    
  2. Add a choice to attStmtTemplate to allow an array for attStmt:

    attStmtTemplate = {
        authData: bytes,
        fmt: text,
        attStmt: (
            { * tstr => any } ; Map is filled in by each concrete attStmtType
            //
            [ * any ]         ; attStmt may also be an array
        ),
    }
    
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging a pull request may close this issue.

1 participant