Open thomas-fossati opened 2 months ago
6.4.2. Initial Registry Contents references I-D.ietf-rats-msg-wrap (oid 1.3.6.1.5.5.7.1.35) and then lists DiceConceptualMessageWrapper (oid 2.23.133.5.4.9) as the item to register.
1.3.6.1.5.5.7.1.35 represents a superset of 2.23.133.5.4.9, I think. Should we consider using that oid instead?
1.3.6.1.5.5.7.1.35 represents a superset of 2.23.133.5.4.9, I think. Should we consider using that oid instead?
Yes, two reasons:
Here's proposed ASN.1 for Section B.1 I noted there was no name given to the DEFINITIONS section that defined EvidenceStatementSet. Was there a reason? I found it helpful to give it a name so I can write the IMPORTS section, namely: EvidenceStatementSet FROM CsrAttestation
Should I give it a name in a PR to add the other ASN.1?
Note also the TcgDice block defines the other DICE OIDs that show up in the OID registry in the IANA section.
I also noticed the B.2 section is mislabeled as it is showing a DiceTcbInfo example. The updated ASN.1 shows construction of an EvidenceStatementSet containing both Dice CMW and Dice TcbInfo structures.
CsrAttestationDiceExample DEFINITIONS IMPLICIT TAGS ::= BEGIN
IMPORTS
tcg-dice-conceptual-message-wrapper FROM TcgDice
DiceConceptualMessageWrapper FROM TcgDice
EvidenceStatementSet FROM CsrAttestation
;
tcgDiceCmwEvidenceStatementES EVIDENCE-STATEMENT ::=
{ DiceConceptualMessageWrapper IDENTIFIED BY tcg-dice-conceptual-message-wrapper }
tcgDiceTcbInfoEvidenceStatementES EVIDENCE-STATEMENT ::=
{ DiceTcbInfo IDENTIFIED BY tcg-dice-TcbInfo }
-- where ConceptualMessageWrapper, tcg-dice-conceptual-message-wrapper, DiceTcbInfo, and tcg-dice-TcbInfo
-- are defined in DICE-Attestation-Architecture-Version-1.1-Revision-17_1August2023.pdf
EvidenceStatementSet EVIDENCE-STATEMENT ::= {
tcgDiceEvidenceStatementES,
tcgDiceTcbInfoEvidenceStatementES,
...
}
END
TcgDice DEFINITIONS IMPLICIT TAGS ::= BEGIN
EXPORTS ALL;
tcg OBJECT IDENTIFIER ::= { 2 23 133 }
tcg-dice OBJECT IDENTIFIER ::= { tcg platformClass(5) dice(4) }
tcg-dice-TcbInfo OBJECT IDENTIFIER ::= { tcg-dice tcbinfo(1) }
tcg-dice-MultiTcbInfo OBJECT IDENTIFIER ::= {tcg-dice multitcbinfo(5) }
tcg-dice-UCCS-evidence OBJECT IDENTIFIER ::= {tcg-dice uccs-evidence(6) }
tcg-dice-manifest-evidence OBJECT IDENTIFIER ::= {tcg-dice manifest-evidience(7) }
tcg-dice-MultiTcbInfoComp OBJECT IDENTIFIER ::= {tcg-dice multitcbinfocomp(8) }
tcg-dice-conceptual-message-wrapper OBJECT IDENTIFIER ::= { tcg-dice cmw(9) }
DiceConceptualMessageWrapper ::= SEQUENCE {
cmw OCTECT STRING
}
DiceTcbInfo ::== SEQUENCE {
vendor [0] IMPLICIT UTF8String OPTIONAL,
model [1] IMPLICIT UTF8String OPTIONAL,
version [2] IMPLICIT UTF8String OPTIONAL,
svn [3] IMPLICIT INTEGER OPTIONAL,
layer [4] IMPLICIT INTEGER OPTIONAL,
index [5] IMPLICIT INTEGER OPTIONAL,
fwids [6] IMPLICIT FWIDLIST OPTIONAL,
flags [7] IMPLICIT OperationalFlags OPTIONAL,
vendorInfo [8] IMPLICIT OCTET STRING OPTIONAL,
type [9] IMPLICIT OCTET STRING OPTIONAL,
flagsMask [10]IMPLICIT OperationalFlagsMask OPTIONAL
}
FWIDLIST ::== SEQUENCE SIZE (1..MAX) OF FWID
FWID ::== SEQUENCE {
hashAlg OBJECT IDENTIFIER,
digest OCTET STRING
}
OperationalFlags ::= BIT STRING {
notConfigured (0),
notSecure (1),
recovery (2),
debug (3),
notReplayProtected (4),
notIntegrityProtected (5),
notRuntimeMeasured (6),
notImmutable (7),
notTcb (8),
fixedWidth (31)
}
OperationalFlagsMask ::= BIT STRING {
notConfigured (0),
notSecure (1),
recovery (2),
debug (3),
notReplayProtected (4),
notIntegrityProtected (5),
notRuntimeMeasured (6),
notImmutable (7),
notTcb (8),
fixedWidth (31)
}
END
Fixed in PR #160
@henkbirkholz asked me to look at B.1 and B.2.
Two observations:
In conclusion:
This may be related to #144