Re: [EAT] [Rats] Attestation BoF charter updates?

[Henk Birkholz <[e-mail]>]

It is in the current charter text, because I think your answer in the quote below is well met. 

"ASN.1 is already player for a number of attestation formats. Any reason to exclude it?

None I can technically justify."

However, even boiling of the ocean is subject to phasing - and the ASN.1 related wording is not intended to be a loophole ;-)

Viele Grüße,

Henk



On October 24, 2018 6:32:15 PM GMT+02:00, Jeremy O'Donoghue <[e-mail]> wrote:
>I think you already have text which keeps this scenario in scope in the
>latest draft (the bit about ASN.1 interoperability). From my
>perspective this is enough for now.
>
>Jeremy
>
>On 24 Oct 2018, at 17:27, Henk Birkholz
><[e-mail]<mailto:[e-mail]>>
>wrote:
>
>Please all keep in mind that we are intending to cut work items into
>phases. While we are starting to agree more than we disagree, I think,
>we should continue to pay attention to scoping, please. Not now does
>not mean never!
>
>Viele Grüße,
>
>Henk
>
>On October 24, 2018 2:46:21 PM GMT+02:00, Jeremy O'Donoghue
><[e-mail]<mailto:[e-mail]>> wrote:
>I have the following understanding (possibly misunderstood) from this
>thread:
>
>
>*   It is desirable to have syntax for incorporating sets of Claims in
>structures that are defined in ASN.1. At the surface level this may be
>straightforward because claims are essentially (key, value) pairs - the
>key potentially being implicit in some cases, but there could be
>important semantic differences in the meaning of signing in Attestation
>formats vs legacy formats, and there may be challenges in mapping some
>CBOR or JSON constructions to ASN.1.
>*   The main use-case under discussion is to address mechanisms to
>enable an attestation to be presented to a CA in the context of a
>certificate request protocol. If I have correctly understood this, it
>means that a direct mapping of the Claims in an attestation to an X.509
>certificate is a non-goal as the CA would be responsible for correctly
>interpreting the semantics of the Claims and incorporating them into an
>issued certificate in ways that make sense in the X.509 world.
>
>I think we need to take care to limit the scope of work items in this
>area as there exists a considerable existing body of specifications in
>this area. Girl has mentioned ACME, and Carl mentioned SCEP, for which
>a new version appears to be nearing publication.
>
>My suggestion is that it should be in scope to define a syntax for
>describing attestations which which could be transported via
>certificate request protocols such as ACME and SCEP, but that the
>question of how the semantics of attestations are managed  in their
>use-cases is a question for the WGs owning those specifications.
>
>Looking at the current SCEP
>draft<https://datatracker.ietf.org/doc/draft-gutmann-scep/?include_text=1>,
>it might be sufficient for the CRIAttributes definition (from RFC2986)
>to include the ASN.1 encoding of an attestation. ACME seems to encode
>the CSR in RFC2986 for as well, so this might be workable.
>
>In terms of the charter text (which is what is really in scope here) we
>could add text to the WG description indicating that the WG will work
>with relevant WGs to identify where attestations may be useful in PKI
>infrastructures. I think the existing charter text already covers the
>possibility of defining Claims to enable transport of an X.509
>certificate as part of an attestation.
>
>Please let me know if I have misunderstood. I will be posting an update
>to the text shortly which I believe covers this.
>
>Jeremy
>
>On 23 Oct 2018, at 20:57, Carl Wallace
><[e-mail]<mailto:[e-mail]>> wrote:
>
><snip>
>[nms] Right. In order for the CA (verifier) to distinguish the
>certifying key is an ‘attestable key’ vs. a traditional CSR. The CA
>should look for a signature from the mfg cert over the CSR (certificate
>management message?) containing the generated public key. I’m still not
>seeing where there is a self-signed (issued) certificate in the
>equation.
>This began with request to codify binding to certificate request
>protocols, not for a self signed certificate.
>
>
>
>--
>Sent from my Android device with K-9 Mail. Please excuse my brevity.

-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.