Re: [EAT] Scope, Goals & Background for RATS

["Diego R. Lopez" <[e-mail]>]

Regarding the length, we could always aim at using the intersection rather than the union...

--
"Esta vez no fallaremos, Doctor Infierno"

Dr Diego R. Lopez
Telefonica I+D
https://www.linkedin.com/in/dr2lopez/

e-mail: [e-mail]
Tel:         [phone]
Mobile:  [phone]
----------------------------------

On 21/09/2018, 17:06, "EAT on behalf of Henk Birkholz" <[e-mail] on behalf of [e-mail]> wrote:

    Hello Laurence,

    splintering emerging work on attestation in the IETF at the very
    beginning does not seem to be very productive to me, too. I
    wholeheartedly agree with that notion.

    I hear your assessment that EAT and RATS have distinct goals and -  as
    our slowly improving convergence of approaches shows - that is true to
    some extend, I think. But I also think that there is significant overlap
    and creating synergy via this overlap, while also creating a shared
    consistent terminology, is vital and I'd optimistically consider that
    achievable.

    I really am interested in the deployment scenarios that you envision for
    EAT. I am rather certain that we could identify more overlap there. The
    RATS charter covers deployment only in very specific detail at the
    moment. Some scoping had to be done to create a tangible set of
    realistic goals for chartering. That said, deployment is also an
    important aspect for RATS, just not at this very beginning.

    I am also rather certain that EAT can be used in a lot of places. I
    really like the approach, as I am a proponent of CWT. I also was under
    the impression that EAT does not exclude the option to be rooted in TPM?
    While that might only be a technical detail, I bring that up because the
    "non-exclusiveness" of both EAT and RATS wrt to specific hardware
    solutions was an overlap. But maybe I missed something obvious here.

    In summary, creating a common "middle ground" and working in concert in
    these shared domains (manifested in drafts) seems to be the optimal way
    to move forward, I think.

    My only actual concern remains to be the creation of a shorter charter
    :) Merging goals does not really sound like making it shorter - well, at
    least initially.

    Viele Grüße,

    Henk



    On 09/21/2018 07:01 PM, Laurence Lundblade wrote:
    > RATS folks: Henk, Ned, Monty and Eric,
    >
    > EAT has deployment scenarios and goals that are distinct from RATS. They don’t need new protocols in the same way as that RATS does. They will not be rooted in TCG and TPM work. There is precedence in the industry for these use as can be seen in FIDO and Android Keystore Attestation. EAT can not just be a subordinate part of RATS as you seem to imply below.
    >
    > Even if our deployment goals and use cases are not the same, I would think we can have separate documents where we need to and do the work in one WG.
    >
    > I think it would be bad to have two attestation working groups in the IETF, one for EAT and one for RATS.  Thus, I think the charter of this WG must explicitly include the EAT use cases and goals.
    >
    > LL
    >
    >
    >> On Sep 21, 2018, at 9:24 AM, Henk Birkholz <[e-mail]> wrote:
    >>
    >> Hello Laurence,
    >>
    >> please find replies and comments in-line:
    >>
    >> On 09/20/2018 10:18 PM, Laurence Lundblade wrote:
    >>> It’s a bit buried, but I see you do intend that this include the EAT work. Thus the work would not be TPM/TCG centric. It would include use cases like FIDO and Android Keystore attestation that are often based on TrustZone. It could also include EPID-related use cases. Please confirm.
    >>
    >> I am not sure, if I am the authority to confirm this, as kickstarting RATS is a group effort. What I can do is to agree with the statement that RATS is abstracting from specific hardware solutions that provide, for example trust anchors and shielded locations (which keystores are a subset of, I think), or restrict secret key access (protection of execution, I think) based on system status (or more generic - system health).
    >>
    >> Conveyance of Attestation Claims is a big part of implicit attestation and the comparison of (amongst other information) claims wrt to appraisal of Attestation Evidence in explicit attestation. As EAT provides a data format to express these claim sets in a state-of-the art representation (and, if signed, via a state-of-the-art COSE envelope) they are compose a perfect option to address the data model part of conveyance.
    >>
    >
    >
    >

    _______________________________________________
    EAT mailing list
    [e-mail]
    https://www.ietf.org/mailman/listinfo/eat



________________________________

Este mensaje y sus adjuntos se dirigen exclusivamente a su destinatario, puede contener información privilegiada o confidencial y es para uso exclusivo de la persona o entidad de destino. Si no es usted. el destinatario indicado, queda notificado de que la lectura, utilización, divulgación y/o copia sin autorización puede estar prohibida en virtud de la legislación vigente. Si ha recibido este mensaje por error, le rogamos que nos lo comunique inmediatamente por esta misma vía y proceda a su destrucción.

The information contained in this transmission is privileged and confidential information intended only for the use of the individual or entity named above. If the reader of this message is not the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this transmission in error, do not read it. Please immediately reply to the sender that you have received this communication in error and then delete it.

Esta mensagem e seus anexos se dirigem exclusivamente ao seu destinatário, pode conter informação privilegiada ou confidencial e é para uso exclusivo da pessoa ou entidade de destino. Se não é vossa senhoria o destinatário indicado, fica notificado de que a leitura, utilização, divulgação e/ou cópia sem autorização pode estar proibida em virtude da legislação vigente. Se recebeu esta mensagem por erro, rogamos-lhe que nos o comunique imediatamente por esta mesma via e proceda a sua destruição