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

[Jeremy O'Donoghue <[e-mail]>]

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.