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

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 <rats-bounces@ietf.org <mailto:rats-bounces@ietf.org>> on 
> behalf of Henk Birkholz <henk.birkholz@sit.fraunhofer.de 
> <mailto:henk.birkholz@sit.fraunhofer.de>>
> Date: Wednesday, October 24, 2018 at 12:42 PM
> To: Jeremy O'Donoghue <jodonogh@qti.qualcomm.com 
> <mailto:jodonogh@qti.qualcomm.com>>
> Cc: Michael Richardson <mcr+ietf@sandelman.ca 
> <mailto:mcr+ietf@sandelman.ca>>, "Smith, Ned" <ned.smith@intel.com 
> <mailto:ned.smith@intel.com>>, Carl Wallace <carl@redhoundsoftware.com 
> <mailto:carl@redhoundsoftware.com>>, "eat@ietf.org 
> <mailto:eat@ietf.org>" <eat@ietf.org <mailto:eat@ietf.org>>, 
> "rats@ietf.org <mailto:rats@ietf.org>" <rats@ietf.org 
> <mailto:rats@ietf.org>>
> Subject: Re: [Rats] [EAT] Attestation BoF charter updates?
> 
>     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
>     <jodonogh@qti.qualcomm.com <mailto:jodonogh@qti.qualcomm.com>> 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
>>         <henk.birkholz@sit.fraunhofer.de
>>         <mailto:henk.birkholz@sit.fraunhofer.de>> 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
>>         <jodonogh@qti.qualcomm.com <mailto:jodonogh@qti.qualcomm.com>>
>>         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 managedin 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
>>>             <carl@redhoundsoftware.com
>>>             <mailto:carl@redhoundsoftware.com>> 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.
>     _______________________________________________ RATS mailing list
>     RATS@ietf.org <mailto:RATS@ietf.org>
>     https://www.ietf.org/mailman/listinfo/rats 
> 