[lamps] Qualified certificates and key attestations

[Carl Wallace <[e-mail]>]

During the LAMPS session today, Stefan and Leif suggested that the proposed key attestation draft needs to consider qualified certificates. Some thoughts on the possible points of intersection are below. Please correct or expand as needed.

In https://datatracker.ietf.org/doc/html/rfc3739, there is a QCStatement structure that is very similar to the structures used for extensions and attributes. 

      QCStatement ::= SEQUENCE {
          statementId   QC-STATEMENT.&Id({SupportedStatements}),
          statementInfo QC-STATEMENT.&Type
          ({SupportedStatements}{@statementId}) OPTIONAL }
          
It would be straightforward to include a reference to RFC 3739 with note that the OIDs and values defined in the draft for CMPv2, EST, etc. could be used with QCStatement as well.

This could be a complementary mechanism to the QC statement defined in 4.2.2 of https://www.etsi.org/deliver/etsi_en/319400_319499/31941205/02.03.01_60/en_31941205v020301p.pdf, i.e., one could elect to require an attestation prior to asserting this QC statement.

I don't see anything in the QC materials I reviewed in the way of prior art that would motivate not using the WebAuthn format. Given Thomas chimed in during the meeting that they use WebAuthn already and, as noted in the draft, so does the ACME mechanism that will be briefed tomorrow, I think using WebAuthn as a means of supporting different attestation formats is fine. The main open item is defining a registry w.r.t. format since reuse of the WebAuthn registry is not recommended. Sean and I plan to address in the next draft. 

Hopefully the above addresses the concerns. If more QC-focused text is desired, that may be better handled in a separate draft (similar to how this draft is separate from the similar ACME draft).