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

From: Carl Wallace <[email-masked]>
Date: Tue, 23 Oct 2018 11:14:59 -0400

> 
> <snip>
> 
> Work Items
> 
> ----------
> 
> The Working Group will develop specifications supporting the creation of
> interoperable remote attestation procedures for entities which incorporate
> Roots of Trust. The main deliverables are as follows.
> 
> - Produce a requirements document establishing a common vocabulary for remote
>   attestation, identifying mechanisms which will be supported for establishing
>   trust between an entity and a remote party, and enumerating sample use-cases
>   for remote attestation.
> 
> - Produce specification text defining interoperable cross-platform claims
> which
>   provide information about an entity in support of the required use-cases,
> and
>   extending the set of claims defined in RFC7519 and RFC8392. The
> specification
>   will describe the syntax for each claim in at least the following formats:
>     - CBOR [RFC7049]
>     - JSON [RFC7159]
>     - YANG [RFC6020]

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

> - Produce specification text defining procedures and corresponding
> architectures
>   supporting verification of claims within an attestation based on measured
> file
>   execution procedures and supporting:
>     - Explicit attestation wherein a set of claims is transported in the
> attestation;
>     - Implicit attestation wherein a set of claims is implied by possession of
> a secret.
> 
> - Produce specification text defining procedures and corresponding
> architectures
>   supporting verification of claims encapsulated in:
> 
>     - CBOR Web Token structures [RFC8392]
>     - JSON Web Token structures [RFC7519]

[CW] As noted before, I'd like to see binding to certificate enrollment
protocols included here as well. This is something we are doing today,
without standards grounding (as illustrated in pile of attestations shared
via Github a few weeks back).

> - Perform privacy analysis of both claims and the cryptographic procedures
> used to
>   establish trust. This information will be included as appropriate in the
>   deliverable specifications, and may imply extension of procedures defined in
>   other specifications in support of privacy goals.
> 
> 
> It seems to me that there are two ways to produce the main specification
> deliverables. I have deliberately left the text above slightly vague on this.
> * A claims specification common to RATS and EAT with separate RATS and EAT
> procedure specifications.
> * A claims specification also incorporating EAT procedures and a separate RATS
> procedure specification. This would be my preferred option.
>> * I believe there are very few procedures needed for EAT other than the
>> possible need to support a nonce to ensure freshness
> 
> Jeremy
>> 
>> Notice how by about the second paragraph (6tisch takes a bit longer), each
>> gets into what the WG will do?
>> 
>> --
>> Michael Richardson <[email-masked]>, Sandelman Software Works
>> -= IPv6 IoT consulting =-
>> _______________________________________________
>> EAT mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/eat
> 
> _______________________________________________ RATS mailing list
> [email-masked] https://www.ietf.org/mailman/listinfo/rats

---

From: Jeremy O'Donoghue <[email-masked]>
Date: Tue, 23 Oct 2018 17:10:06 +0000

On 23 Oct 2018, at 16:14, Carl Wallace <[email-masked]<mailto:[email-masked]>> wrote:

<snip>

Work Items

----------

- Produce specification text defining interoperable cross-platform claims which
  provide information about an entity in support of the required use-cases, and
  extending the set of claims defined in RFC7519 and RFC8392. The specification
  will describe the syntax for each claim in at least the following formats:
    - CBOR [RFC7049]
    - JSON [RFC7159]
    - YANG [RFC6020]

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

None I can technically justify. It seems sensible to have ASN.1 in scope, at least in terms of defining the syntax of claims in ASN.1. I am less sure whether it makes sense to define signing procedures for ASN1. (since these are presumably defined elsewhere), but I could be persuaded (e.g. by the statement "no they aren't defined elsewhere - at least not for this important use-case").

- Produce specification text defining procedures and corresponding architectures
  supporting verification of claims within an attestation based on measured file
  execution procedures and supporting:
    - Explicit attestation wherein a set of claims is transported in the attestation;
    - Implicit attestation wherein a set of claims is implied by possession of a secret.

- Produce specification text defining procedures and corresponding architectures
  supporting verification of claims encapsulated in:

[CW] As noted before, I'd like to see binding to certificate enrollment protocols included here as well. This is something we are doing today, without standards grounding (as illustrated in pile of attestations shared via Github a few weeks back).

It would be interesting to understand your thinking a bit further. At one level it is fairly straightforward to define a claim whose value contains an X.509 certificate, but I suspect that binding may imply more than that.

- Perform privacy analysis of both claims and the cryptographic procedures used to
  establish trust. This information will be included as appropriate in the
  deliverable specifications, and may imply extension of procedures defined in
  other specifications in support of privacy goals.

It seems to me that there are two ways to produce the main specification deliverables. I have deliberately left the text above slightly vague on this.

  *   A claims specification common to RATS and EAT with separate RATS and EAT procedure specifications.
  *   A claims specification also incorporating EAT procedures and a separate RATS procedure specification. This would be my preferred option.
     *   I believe there are very few procedures needed for EAT other than the possible need to support a nonce to ensure freshness

Jeremy

--
Michael Richardson <[email-masked]<mailto:[email-masked]>>, Sandelman Software Works
-= IPv6 IoT consulting =-
_______________________________________________
EAT mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/eat

_______________________________________________ RATS mailing list [email-masked]<mailto:[email-masked]> https://www.ietf.org/mailman/listinfo/rats

---

From: "Smith, Ned" <[email-masked]>
Date: Tue, 23 Oct 2018 17:28:21 +0000

See inline [nms].

On 10/23/18, 10:10 AM, "EAT on behalf of Jeremy O'Donoghue" <[email-masked]<mailto:[email-masked]> on behalf of [email-masked]<mailto:[email-masked]>> wrote:

None I can technically justify. It seems sensible to have ASN.1 in scope, at least in terms of defining the syntax of claims in ASN.1. I am less sure whether it makes sense to define signing procedures for ASN1. (since these are presumably defined elsewhere), but I could be persuaded (e.g. by the statement "no they aren't defined elsewhere - at least not for this important use-case").
[nms] The relevant question to consider is whether or not the semantics of elsewhere defined ASN.1 equal that of the CBOR | JSON | YANG definitions. Since it is often the case that semantics are inferred through tribal understanding and/or human readable documents, the data model descriptions could disagree unless documented as the data model bindings of an information model representation (where the information model likely is accompanied by human readable text that captures intended semantics).

[nms] Note: the SP800-164.verifier must rely on some form of out-of-bands communication from the SP800-154.entity that is knowledgeable regarding the claimable claims asserted by the SP800-164.root-of-trust for the SP800-164.verifier to know which claims semantics to ascribe to the secret.

It would be interesting to understand your thinking a bit further. At one level it is fairly straightforward to define a claim whose value contains an X.509 certificate, but I suspect that binding may imply more than that.
[nms] It is also reasonable to consider an X.509 certificate as being an object that contains a set of claims (rather than the other way around).

It seems to me that there are two ways to produce the main specification deliverables. I have deliberately left the text above slightly vague on this.
·         A claims specification common to RATS and EAT with separate RATS and EAT procedure specifications.
·         A claims specification also incorporating EAT procedures and a separate RATS procedure specification. This would be my preferred option.
o    I believe there are very few procedures needed for EAT other than the possible need to support a nonce to ensure freshness

Jeremy

---

From: Carl Wallace <[email-masked]>
Date: Tue, 23 Oct 2018 13:31:28 -0400

From:  Jeremy O'Donoghue <[email-masked]>
Date:  Tuesday, October 23, 2018 at 1:10 PM
>> On 23 Oct 2018, at 16:14, Carl Wallace <[email-masked]> wrote:
>>> <snip>
>>> 
>>> Work Items
>>> 
>>> ----------
>>> 
> None I can technically justify. It seems sensible to have ASN.1 in scope, at
> least in terms of defining the syntax of claims in ASN.1. I am less sure
> whether it makes sense to define signing procedures for ASN1. (since these are
> presumably defined elsewhere), but I could be persuaded (e.g. by the statement
> "no they aren't defined elsewhere - at least not for this important
> use-case").
[CW] I'd not discount CMS not because there aren't mechanisms elsewhere, but
because it's already used in some attestation contexts.
> It would be interesting to understand your thinking a bit further. At one
> level it is fairly straightforward to define a claim whose value contains an
> X.509 certificate, but I suspect that binding may imply more than that.
[CW] My goal is to present an attestation to a CA before a certificate is
issued so the provenance of the key can be confirmed to inform issuance
decisions. I currently do include self-signed X.509 certificates as claims
in attestations, which may be what you meant.

---

From: Carl Wallace <[email-masked]>
Date: Tue, 23 Oct 2018 13:33:56 -0400

<snip>
> [nms] It is also reasonable to consider an X.509 certificate as being an
> object that contains a set of claims (rather than the other way around).
[cw] Not if the goal is to prevent issuance of a certificate because
provenance of a key cannot be confirmed. Having a self-issued cert contain
claims is fine, but this does not obviate the need to bind to issuance
protocols to inform CA issuance.

<snip>

---

From: "Smith, Ned" <[email-masked]>
Date: Tue, 23 Oct 2018 18:49:12 +0000

On 10/23/18, 10:34 AM, "EAT on behalf of Carl Wallace" <[email-masked]<mailto:[email-masked]> on behalf of [email-masked]<mailto:[email-masked]>> wrote:

<snip>

It would be interesting to understand your thinking a bit further. At one level it is fairly straightforward to define a claim whose value contains an X.509 certificate, but I suspect that binding may imply more than that.
[nms] It is also reasonable to consider an X.509 certificate as being an object that contains a set of claims (rather than the other way around).
[cw] Not if the goal is to prevent issuance of a certificate because provenance of a key cannot be confirmed. Having a self-issued cert contain claims is fine, but this does not obviate the need to bind to issuance protocols to inform CA issuance.
[nms] I wasn’t asserting that a certificate would be self-issued. This is why I think it makes sense to talk about a claimant. SP800-164 refers to this as either a ‘device owner’ or ‘information owner’. I’m OK with these terms too. The expectation is the device owner during manufacturing  (aka mfg’r) will know which trust relevant claims can be asserted. They could assert them by issuing a certificate containing the claims. The verifier/relying party trusts the mfg’r to be an authoritative source regarding how a device (but more precisely, how the root-of-trust) was made. If a key is created during mfg time and the mfg issues evidence (aka a certificate) of that, then it serves as provenance as long as the verifier / relying party trusts the manufacturer to correctly embed the key. Confirmation can be achieved via manual inspection of the manufacturing process. Nevertheless, the verifier is trusting the mfg to a certain degree.

                This thread is about formats (X.509/ASN.1, CBOR etc…). The semantics of what a signature means is (should be) common across all the formats IMO. If self-signed claims are invalid, then they should be invalid for any encoding whether it is ASN.1, CBOR or something else. If they are valid for something else, then the signature should be valid for alternative formats too.
<snip>

---

From: Carl Wallace <[email-masked]>
Date: Tue, 23 Oct 2018 15:04:43 -0400

Inline..

From:  "Smith, Ned" <[email-masked]>
Date:  Tuesday, October 23, 2018 at 2:49 PM
To:  Carl Wallace <[email-masked]>, Jeremy O'Donoghue
<[email-masked]>
Cc:  Michael Richardson <[email-masked]>, "[email-masked]"
<[email-masked]>, "[email-masked]" <[email-masked]>
Subject:  Re: [EAT] [Rats]    Attestation BoF charter updates?

>  
>  
> 
> On 10/23/18, 10:34 AM, "EAT on behalf of Carl Wallace" <[email-masked]
> on behalf of [email-masked]> wrote:
> 
>  
> 
> <snip>
>> 
>>  
>> 
> [nms] I wasn’t asserting that a certificate would be self-issued. This is why
> I think it makes sense to talk about a claimant. SP800-164 refers to this as
> either a ‘device owner’ or ‘information owner’. I’m OK with these terms too.
> The expectation is the device owner during manufacturing  (aka mfg’r) will
> know which trust relevant claims can be asserted. They could assert them by
> issuing a certificate containing the claims. The verifier/relying party trusts
> the mfg’r to be an authoritative source regarding how a device (but more
> precisely, how the root-of-trust) was made. If a key is created during mfg
> time and the mfg issues evidence (aka a certificate) of that, then it serves
> as provenance as long as the verifier / relying party trusts the manufacturer
> to correctly embed the key. Confirmation can be achieved via manual inspection
> of the manufacturing process. Nevertheless, the verifier is trusting the mfg
> to a certain degree.

[CW] You are referring to a certificate issued to the device by the
manufacturer. I am referring to certifying keys generated by a hardware
crypto module on the device once it is in the hands of a user.  I don't
disagree the verifier must trust the manufacturer when verifying the
attestation, I am suggesting that the verifier is a CA who will have plucked
an attestation from a certificate management message and will, amongst other
checks that need to be standardized, confirm the public key in the
certificate request corresponds to a claim in the attestation.

---

From: Giridhar Mandyam <[email-masked]>
Date: Tue, 23 Oct 2018 19:53:43 +0000

Why isn’t ACME applicable  (https://datatracker.ietf.org/wg/acme/about/)?   Granted, it is optimized for the web currently.  But from a message format perspective I don’t think we need to re-invent the wheel.

-Giri Mandyam, Qualcomm

From: EAT <[email-masked]> On Behalf Of Carl Wallace
Sent: Tuesday, October 23, 2018 8:15 AM
To: Jeremy O'Donoghue <[email-masked]>; Michael Richardson <[email-masked]>
Cc: [email-masked]; [email-masked]
Subject: Re: [EAT] [Rats] Attestation BoF charter updates?

<snip>
Work Items
----------

Jeremy

---

From: "Smith, Ned" <[email-masked]>
Date: Tue, 23 Oct 2018 19:55:26 +0000

On 10/23/18, 12:04 PM, "Carl Wallace" <[email-masked]<mailto:[email-masked]>> wrote:

Inline..

From: "Smith, Ned" <[email-masked]<mailto:[email-masked]>>
Date: Tuesday, October 23, 2018 at 2:49 PM
To: Carl Wallace <[email-masked]<mailto:[email-masked]>>, Jeremy O'Donoghue <[email-masked]<mailto:[email-masked]>>
Cc: Michael Richardson <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: Re: [EAT] [Rats] Attestation BoF charter updates?

<snip>

[CW] You are referring to a certificate issued to the device by the manufacturer. I am referring to certifying keys generated by a hardware crypto module on the device once it is in the hands of a user.  I don't disagree the verifier must trust the manufacturer when verifying the attestation, I am suggesting that the verifier is a CA who will have plucked an attestation from a certificate management message and will, amongst other checks that need to be standardized, confirm the public key in the certificate request corresponds to a claim in the attestation.
[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.

---

From: Carl Wallace <[email-masked]>
Date: Tue, 23 Oct 2018 15:56:44 -0400

inline

From:  Giridhar Mandyam <[email-masked]>
Date:  Tuesday, October 23, 2018 at 3:53 PM
To:  Carl Wallace <[email-masked]>, Jeremy O'Donoghue
<[email-masked]>, Michael Richardson <[email-masked]>
Cc:  "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>
Subject:  RE: [EAT] [Rats]    Attestation BoF charter updates?

> protocols included here as well. This is something we are doing today, without
> standards grounding (as illustrated in pile of attestations shared via Github
> a few weeks back).
>  
> Why isn’t ACME applicable  (https://datatracker.ietf.org/wg/acme/about/)?
> Granted, it is optimized for the web currently.  But from a message format
> perspective I don’t think we need to re-invent the wheel.
[CW] I have not suggested defining new certificate management specs, just
codifying the binding of attestations to one or more certificate management
specs. In my case, I am using SCEP (for legacy installed base purposes).

> protocols included here as well. This is something we are doing today, without
> standards grounding (as illustrated in pile of attestations shared via Github
> a few weeks back).
> 
>  
>> 
>> * A claims specification also incorporating EAT procedures and a separate
>> RATS procedure specification. This would be my preferred option.

---

From: Carl Wallace <[email-masked]>
Date: Tue, 23 Oct 2018 15:57:35 -0400

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

---

From: Jeremy O'Donoghue <[email-masked]>
Date: Wed, 24 Oct 2018 12:46:21 +0000

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 <[email-masked]<mailto:[email-masked]>> 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.

---

From: Henk Birkholz <[email-masked]>
Date: Wed, 24 Oct 2018 18:27:48 +0200

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 <[email-masked]> wrote:
>*   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
><[email-masked]<mailto:[email-masked]>> 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.

---

From: Jeremy O'Donoghue <[email-masked]>
Date: Wed, 24 Oct 2018 16:32:15 +0000

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 <[email-masked]<mailto:[email-masked]>> wrote:

Viele Grüße,

Henk

On October 24, 2018 2:46:21 PM GMT+02:00, Jeremy O'Donoghue <[email-masked]<mailto:[email-masked]>> wrote:
I have the following understanding (possibly misunderstood) from this thread:

Jeremy

<snip>

---

From: Henk Birkholz <[email-masked]>
Date: Wed, 24 Oct 2018 18:42:53 +0200

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 <[email-masked]> 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
><[email-masked]<mailto:[email-masked]>>
>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
><[email-masked]<mailto:[email-masked]>> wrote:

---

From: Carl Wallace <[email-masked]>
Date: Wed, 24 Oct 2018 12:45:22 -0400

Not sure I follow.

From:  RATS <[email-masked]> on behalf of Henk Birkholz
<[email-masked]>
Date:  Wednesday, October 24, 2018 at 12:42 PM
To:  Jeremy O'Donoghue <[email-masked]>
Cc:  Michael Richardson <[email-masked]>, "Smith, Ned"
<[email-masked]>, Carl Wallace <[email-masked]>,
"[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>
Subject:  Re: [Rats] [EAT]     Attestation BoF charter updates?

> 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
> 
> 
> 
>> 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 <[email-masked]>
>>> 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
>>> 
>>> <[email-masked]> wrote:
>>>> 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.
>>>> 
>>>> 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.
>>>> 
>>>> 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
>>>> 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 <[email-masked]> 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.

---

From: Henk Birkholz <[email-masked]>
Date: Wed, 24 Oct 2018 18:55:22 +0200

Hello Carl,

as ASN.1 has been there for quite some time, virtually anything is in 
some way represented via an ASN.1 based format in some way, I'd say. Of 
course this opens up a very wide spectrum of attestation related 
content, too.

That does not mean everything attestation related represented via 
something ASN.1 based is in scope for the initial phase. We have to make 
a few careful decisions here, is all I am saying.

"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" could likely prove to be a very big endeavor and 
should maybe be included in a later phase? We are excluding provisioning 
at the moment and that seems to be significant more vital to remote 
attestation procedures (IMHO). I am highlighting this as a point of 
reference wrt to scoping.

Viele Grüße,

Henk

On 10/24/2018 06:45 PM, Carl Wallace wrote:
> Not sure I follow.
> 
> From: RATS <[email-masked] <mailto:[email-masked]>> on 
> behalf of Henk Birkholz <[email-masked] 
> <mailto:[email-masked]>>
> To: Jeremy O'Donoghue <[email-masked] 
> <mailto:[email-masked]>>
> Cc: Michael Richardson <[email-masked] 
> <mailto:[email-masked]>>, "Smith, Ned" <[email-masked] 
> <mailto:[email-masked]>>, Carl Wallace <[email-masked] 
> <mailto:[email-masked]>>, "[email-masked] 
> <mailto:[email-masked]>" <[email-masked] <mailto:[email-masked]>>, 
> "[email-masked] <mailto:[email-masked]>" <[email-masked] 
> <mailto:[email-masked]>>
>     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
>     <[email-masked] <mailto:[email-masked]>> 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
> 
>>         <[email-masked]
>>         <mailto:[email-masked]>> 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
>>
>>         <[email-masked] <mailto:[email-masked]>>
>>         wrote:
>>
>>               * 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 managedin their use-cases is a question
>>             for the WGs owning those specifications.
>>
>>             <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
>>
>>>             <[email-masked]
>>>             <mailto:[email-masked]>> 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.
>>>>
>>
>>
>>         --
>     [email-masked] <mailto:[email-masked]>
>     https://www.ietf.org/mailman/listinfo/rats 
>

---

From: Carl Wallace <[email-masked]>
Date: Wed, 24 Oct 2018 12:59:41 -0400

Got it. No boiling the ocean intended. Goal for me is to present
attestations to CAs to inform cert issuance. This typically involves ASN.1
and cert mgmt protocols (of which there sadly are many). Multiplicity of
cert mgmt protocols notwithstanding, this ought not be too much scope
creep here. A single attribute definition could serve at least three of
them.