Re: [lamps] Two comments on draft-ietf-lamps-key-attestation-ext

[Carl Wallace <[e-mail]>]

Inline…

 

From: Thomas Fossati <[e-mail]>
Date: Wednesday, December 21, 2022 at 1:56 PM
To: "[e-mail]" <[e-mail]>, "[e-mail]" <[e-mail]>
Subject: Two comments on draft-ietf-lamps-key-attestation-ext
Resent-From: <[e-mail]>
Resent-To: <[e-mail]>, <[e-mail]>
Resent-Date: Wed, 21 Dec 2022 10:57:43 -0800 (PST)

 

Thanks authors for a clear and useful document.

 

Would it be possible to get an OID for CMWs [1] alongside WebAuthn?

That would help the case for passing attestation results when the RA/CA

cooperates with a separate verifier.

 

[CW] At present, the draft features a single OID for identifying attestation information sent to a CA where that information is formatted as a WebAuthn attestation statement. This format was elected to align with a similar ACME draft. In addition to this request to support RATS conceptual message wrappers, which like WebAuthn attestation statement formats is CBOR encoded, we’ve had an off-list request to support DER-encoded attestations. I’m open to adding support for a couple of additional formats to the draft. I think this would just require additional OIDs, with the content encoded as an OCTET STRING as in the current draft and the basic approach remaining be the same, i.e., language to require the public key in the attestation information to match the public key in the certificate request would be in this draft with other semantics defined in the description of the attestation format.

 

Another question I have is related to defining a symmetric cert

extension for carrying attestation evidence & results.

There is an extension that would do the job defined by the TCG.  Maybe

this document could reference it?

 

[CW] There’s nothing in the draft at present that describes how a CA signals to relying parties that it has verified an attestation but that’s probably a gap that ought be filled. In an implementation I worked on previously, this was done via certificate policies (but that does not fit every use case). I think in some currently percolating use cases the signal is more or less implicit. Adding some words re: these possibilities and a reference to something more concrete that conveys evidence or attestation results seems like a good idea. I’d not want to mandate any option though. A short additional informational section should be all that’s needed. 

 

cheers, thank you

 

[1] https://datatracker.ietf.org/doc/draft-ftbs-rats-msg-wrap/

 

--

 

 

IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.