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

[Thomas Fossati <[e-mail]>]

Hi Carl,

Apologies for the belated reply (I hit "send" and left for a long trip…)

On 22/12/2022, 10:20, "Carl Wallace" <[e-mail]> wrote:
> > 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.

Cool.

> 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.

Yes!

> > 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.

Awesome.  We need to coordinate this with the relevant TCG people -- Ned
is CC'd -- but this can be taken offline until we converge on a concrete
proposal.  Is there a public repo for the draft where we can send a PR?

cheers, t

> > 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.