Re: [Ace] RATS Entity Attestation Tokens (EAT) - to be a CWT or not to be a CWT?
{ I found Jim's very interesting email very hard to read without good
quoting, I'm repeating the important part }
henk> 2.) go to ACE and ask for an "unsigned token" option, or
Jim Schaad wrote:
jls> I don't have a problem with this, I am not sure that I see any
jls> reason for it however. See below.
henk> 3.) go to CBOR and ask for a tag for "naked" CWT Claim Sets (i.e.,
henk> that are not signed).
jls> I don't see any difference between this and option #2
jls> 4.) Just write your CWT code in a sensible manner.
jls> My CWT code base does not make any assumptions about the number or
jls> order of COSE security wrapping layers on a token. It thus looks
jls> like
jls> while (true) {
jls> if input has a COSE_Encrypt tag { decrypt it; set input to the
content; save the encryption information if needed e.g. shared key
authentication; continue; }
jls> if input has a COSE_MAC tag { validate it; set input to the content;
save the MAC information if needed e.g. shared key authentication; continue;}
jls> if input has a COSE_Signature tag { validate it; set input to the
content; save the signer information; continue }
jls> if input is a map - return input as the set of claims;
jls> throw an exception because it is not the correct format.
jls> }
jls> This does not require a tag for a naked set of claims and would
jls> allow that set of claims to be pass in the same place as a CWT can
jls> be passed. What you are suggesting would require extra code to
jls> exist someplace that is going to check for an additional tag.
jls> IT IS
jls> ALSO GOING TO LEAD TO PEOPLE THINKING THAT THIS NEW TAG SHOULD BE
jls> LEGAL TO PLACE INSIDE OF A CWT. After all it makes more sense to
jls> always include it than to just sometimes include it.
Emphasis mine.
So your suggestion is to do nothing.
I also wondered why that wouldn't work, but I hadn't written enough code to
ask the question intelligently.
--
Michael Richardson , Sandelman Software Works
-= IPv6 IoT consulting =-
signature.asc
Description: PGP signature
___
Ace mailing list
Ace@ietf.org
https://www.ietf.org/mailman/listinfo/ace
Re: [Ace] RATS Entity Attestation Tokens (EAT) - to be a CWT or not to be a CWT?
-Original Message-
From: Ace On Behalf Of Henk Birkholz
Sent: Wednesday, March 4, 2020 2:33 PM
To: Jim Schaad ; r...@ietf.org; ace@ietf.org;
c...@ietf.org
Subject: Re: [Ace] RATS Entity Attestation Tokens (EAT) - to be a CWT or not to
be a CWT?
Hi Jim,
I'll take a stake into my heart for the group then :) Please note that I claim
that there is no evidence that I am a vampire nor that I am the provenance of
option 1.).
[JLS] Please note I was planning on staking the idea not the person, I was
just going to de-credential you. However that does raise the question should I
bring salt and a sewing kit (mummies) or a gun with a silver bullet
(werewolves)?
I tried to phrase the output of the last virtual interim as neutral as possible
and I think your reply is to be categorized as:
Option 1.) is "out of the question" as a reply from a COSE WG chair.
[JLS] That would be the COSE author and ACE and CBOR WG chair. I am not a COSE
WG chair. However, I guess I hit all three asks.
Viele Grüße,
Henk
On 04.03.20 22:42, Jim Schaad wrote:
> Henk,
>
> Well you have definitely written a message designed to get a response from me.
>
> -Original Message-
> From: Ace On Behalf Of Henk Birkholz
> Sent: Wednesday, March 4, 2020 10:41 AM
> To: r...@ietf.org; ace@ietf.org; c...@ietf.org
> Subject: [Ace] RATS Entity Attestation Tokens (EAT) - to be a CWT or not to
> be a CWT?
>
> Hi RATS enthusiasts,
> hi ACE,
> hi CBOR,
>
> in the RATS WG we had a lot of discussions about the nature of an Entity
> Attestation Token (EAT):
>
> > https://datatracker.ietf.org/doc/draft-ietf-rats-eat/
>
> > https://github.com/ietf-rats-wg/eat/
>
> A bit of (hopefully useful) context: an EAT is one way to convey
> believable evidence from an Attester (a role residing on a device-like
> entity) to a Verifier (another role defined by RATS - the appraiser of
> evidence). All that is done to provide a Relying Party with "simple enough"
> attestation results generated by the Verifier to enable Relying Parties (in
> general, the remote peer) to make an informed decision about whether to put
> trust in the trustworthiness of that Attester or not. In summary, an Attester
> could be compromised in some way and RATS tries to inhibit that Attester to
> lie about that.
>
> There are a lot of benefits if an EAT (representing evidence) is a CWT:
>
> * we avoid conflicting CWT claim index/label definitions in the IANA
> registry, while being able to use the CWT world of claims (existing,
> cnf soon, and such),
> * at first glance it seems simpler to use existing code that can
> process CWT, and
> * EAT can simply inherit the well defined COSE signing conventions.
>
> Alas, there is also a very specific drawback:
>
> * sometimes RATS might not want to sign a token (maybe that does
> render it not a token anymore, but rather a ticket. But that is just a
> rather minor detail for now)
>
> Why do RATS sometimes not require a signature around their CWT Claims Sets?
> Because the surrounding secure channel between two entities with well
> established authenticity and trustworthiness can be good enough to convey
> useful CWT Claims Sets without a signature (emphasis on: in RATS).
>
> Now - there are multiple options discussed in the RATS WG how to deal with
> this:
>
> 1.) go to COSE and ask for a "null signature",
>
> [JLS] For suggesting this, you should have all of you security credentials
> revoked. The idea of deliberately introducing a way to take the security
> value of COSE signatures to zero is something that should be staked like a
> vampire and not allowed to continue. I strongly believe that this is a fatal
> flaw in the current JOSE security suite and have several times deliberated
> writing a document to remove the "null signature" from JOSE. While it is bad
> to have signatures which are no longer adequately secure, having one with
> zero security is just brain dead.
>
> 2.) go to ACE and ask for an "unsigned token" option, or
>
> [JLS] I don't have a problem with this, I am not sure that I see any reason
> for it however. See below.
>
> 3.) go to CBOR and ask for a tag for "naked" CWT Claim Sets (i.e., that are
> not signed).
> [JLS] I don't see any difference between this and option #2
>
> [JLS]
> 4.) Just write your CWT code in a sensible manner.
>
> My CWT code base does not make any assumptions about the number or
> order of COSE security wrapping layers on a token. It thus looks like
>
> while (true) {
> if input has a COSE_Encrypt tag { decrypt it; set input to the content;
> save the encryption information if needed e.g. sha
Re: [Ace] RATS Entity Attestation Tokens (EAT) - to be a CWT or not to be a CWT?
Oh. Yes. Sorry. Tired and therefore still claiming #notavampire On 04.03.20 23:46, Carsten Bormann wrote: On 2020-03-04, at 23:33, Henk Birkholz wrote: Option 1.) is "out of the question" as a reply from a COSE WG chair. Option 1.) is "out of the question" as a reply from the author of the COSE specification. (And at least one other WG member agrees.) FTFY… Grüße, Carsten ___ Ace mailing list Ace@ietf.org https://www.ietf.org/mailman/listinfo/ace
Re: [Ace] RATS Entity Attestation Tokens (EAT) - to be a CWT or not to be a CWT?
On 2020-03-04, at 23:33, Henk Birkholz wrote: > > Option 1.) is "out of the question" as a reply from a COSE WG chair. Option 1.) is "out of the question" as a reply from the author of the COSE specification. (And at least one other WG member agrees.) FTFY… Grüße, Carsten ___ Ace mailing list Ace@ietf.org https://www.ietf.org/mailman/listinfo/ace
Re: [Ace] RATS Entity Attestation Tokens (EAT) - to be a CWT or not to be a CWT?
Hi Jim,
I'll take a stake into my heart for the group then :) Please note that I
claim that there is no evidence that I am a vampire nor that I am the
provenance of option 1.).
I tried to phrase the output of the last virtual interim as neutral as
possible and I think your reply is to be categorized as:
Option 1.) is "out of the question" as a reply from a COSE WG chair.
Viele Grüße,
Henk
On 04.03.20 22:42, Jim Schaad wrote:
Henk,
Well you have definitely written a message designed to get a response from me.
-Original Message-
From: Ace On Behalf Of Henk Birkholz
Sent: Wednesday, March 4, 2020 10:41 AM
To: r...@ietf.org; ace@ietf.org; c...@ietf.org
Subject: [Ace] RATS Entity Attestation Tokens (EAT) - to be a CWT or not to be
a CWT?
Hi RATS enthusiasts,
hi ACE,
hi CBOR,
in the RATS WG we had a lot of discussions about the nature of an Entity
Attestation Token (EAT):
> https://datatracker.ietf.org/doc/draft-ietf-rats-eat/
> https://github.com/ietf-rats-wg/eat/
A bit of (hopefully useful) context: an EAT is one way to convey believable
evidence from an Attester (a role residing on a device-like
entity) to a Verifier (another role defined by RATS - the appraiser of evidence). All
that is done to provide a Relying Party with "simple enough" attestation
results generated by the Verifier to enable Relying Parties (in general, the remote peer)
to make an informed decision about whether to put trust in the trustworthiness of that
Attester or not. In summary, an Attester could be compromised in some way and RATS tries
to inhibit that Attester to lie about that.
There are a lot of benefits if an EAT (representing evidence) is a CWT:
* we avoid conflicting CWT claim index/label definitions in the IANA registry,
while being able to use the CWT world of claims (existing, cnf soon, and such),
* at first glance it seems simpler to use existing code that can process CWT,
and
* EAT can simply inherit the well defined COSE signing conventions.
Alas, there is also a very specific drawback:
* sometimes RATS might not want to sign a token (maybe that does render it not
a token anymore, but rather a ticket. But that is just a rather minor detail
for now)
Why do RATS sometimes not require a signature around their CWT Claims Sets?
Because the surrounding secure channel between two entities with well
established authenticity and trustworthiness can be good enough to convey
useful CWT Claims Sets without a signature (emphasis on: in RATS).
Now - there are multiple options discussed in the RATS WG how to deal with this:
1.) go to COSE and ask for a "null signature",
[JLS] For suggesting this, you should have all of you security credentials revoked. The
idea of deliberately introducing a way to take the security value of COSE signatures to
zero is something that should be staked like a vampire and not allowed to continue. I
strongly believe that this is a fatal flaw in the current JOSE security suite and have
several times deliberated writing a document to remove the "null signature"
from JOSE. While it is bad to have signatures which are no longer adequately secure,
having one with zero security is just brain dead.
2.) go to ACE and ask for an "unsigned token" option, or
[JLS] I don't have a problem with this, I am not sure that I see any reason for
it however. See below.
3.) go to CBOR and ask for a tag for "naked" CWT Claim Sets (i.e., that are not
signed).
[JLS] I don't see any difference between this and option #2
[JLS]
4.) Just write your CWT code in a sensible manner.
My CWT code base does not make any assumptions about the number or order of
COSE security wrapping layers on a token. It thus looks like
while (true) {
if input has a COSE_Encrypt tag { decrypt it; set input to the content;
save the encryption information if needed e.g. shared key authentication;
continue; }
if input has a COSE_MAC tag { validate it; set input to the content; save
the MAC information if needed e.g. shared key authentication; continue;}
if input has a COSE_Signature tag { validate it; set input to the content;
save the signer information; continue }
if input is a map - return input as the set of claims;
throw an exception because it is not the correct format.
}
This does not require a tag for a naked set of claims and would allow that set
of claims to be pass in the same place as a CWT can be passed. What you are
suggesting would require extra code to exist someplace that is going to check
for an additional tag. It is also going to lead to people thinking that this
new tag should be legal to place inside of a CWT. After all it makes more
sense to always include it than to just sometimes include it. This would be
more of an issue if an array rather than a map was being used to carry the
claims as there would be a chance to not know what type of secur
Re: [Ace] RATS Entity Attestation Tokens (EAT) - to be a CWT or not to be a CWT?
Henk,
Well you have definitely written a message designed to get a response from me.
-Original Message-
From: Ace On Behalf Of Henk Birkholz
Sent: Wednesday, March 4, 2020 10:41 AM
To: r...@ietf.org; ace@ietf.org; c...@ietf.org
Subject: [Ace] RATS Entity Attestation Tokens (EAT) - to be a CWT or not to be
a CWT?
Hi RATS enthusiasts,
hi ACE,
hi CBOR,
in the RATS WG we had a lot of discussions about the nature of an Entity
Attestation Token (EAT):
> https://datatracker.ietf.org/doc/draft-ietf-rats-eat/
> https://github.com/ietf-rats-wg/eat/
A bit of (hopefully useful) context: an EAT is one way to convey believable
evidence from an Attester (a role residing on a device-like
entity) to a Verifier (another role defined by RATS - the appraiser of
evidence). All that is done to provide a Relying Party with "simple enough"
attestation results generated by the Verifier to enable Relying Parties (in
general, the remote peer) to make an informed decision about whether to put
trust in the trustworthiness of that Attester or not. In summary, an Attester
could be compromised in some way and RATS tries to inhibit that Attester to lie
about that.
There are a lot of benefits if an EAT (representing evidence) is a CWT:
* we avoid conflicting CWT claim index/label definitions in the IANA registry,
while being able to use the CWT world of claims (existing, cnf soon, and such),
* at first glance it seems simpler to use existing code that can process CWT,
and
* EAT can simply inherit the well defined COSE signing conventions.
Alas, there is also a very specific drawback:
* sometimes RATS might not want to sign a token (maybe that does render it not
a token anymore, but rather a ticket. But that is just a rather minor detail
for now)
Why do RATS sometimes not require a signature around their CWT Claims Sets?
Because the surrounding secure channel between two entities with well
established authenticity and trustworthiness can be good enough to convey
useful CWT Claims Sets without a signature (emphasis on: in RATS).
Now - there are multiple options discussed in the RATS WG how to deal with this:
1.) go to COSE and ask for a "null signature",
[JLS] For suggesting this, you should have all of you security credentials
revoked. The idea of deliberately introducing a way to take the security value
of COSE signatures to zero is something that should be staked like a vampire
and not allowed to continue. I strongly believe that this is a fatal flaw in
the current JOSE security suite and have several times deliberated writing a
document to remove the "null signature" from JOSE. While it is bad to have
signatures which are no longer adequately secure, having one with zero security
is just brain dead.
2.) go to ACE and ask for an "unsigned token" option, or
[JLS] I don't have a problem with this, I am not sure that I see any reason for
it however. See below.
3.) go to CBOR and ask for a tag for "naked" CWT Claim Sets (i.e., that are not
signed).
[JLS] I don't see any difference between this and option #2
[JLS]
4.) Just write your CWT code in a sensible manner.
My CWT code base does not make any assumptions about the number or order of
COSE security wrapping layers on a token. It thus looks like
while (true) {
if input has a COSE_Encrypt tag { decrypt it; set input to the content;
save the encryption information if needed e.g. shared key authentication;
continue; }
if input has a COSE_MAC tag { validate it; set input to the content; save
the MAC information if needed e.g. shared key authentication; continue;}
if input has a COSE_Signature tag { validate it; set input to the content;
save the signer information; continue }
if input is a map - return input as the set of claims;
throw an exception because it is not the correct format.
}
This does not require a tag for a naked set of claims and would allow that set
of claims to be pass in the same place as a CWT can be passed. What you are
suggesting would require extra code to exist someplace that is going to check
for an additional tag. It is also going to lead to people thinking that this
new tag should be legal to place inside of a CWT. After all it makes more
sense to always include it than to just sometimes include it. This would be
more of an issue if an array rather than a map was being used to carry the
claims as there would be a chance to not know what type of security wrapper
exists.
[JLS END]
At the last RATS virtual interim there was no certainty how to approach this.
So this is a call out. COSE, ACE, and CBOR, how would you approach this
"unsigned CWT Claims Set" requirement?
If one of the three options highlighted above is out of the question, please
say so (and please elaborate on the why for the sake of helping the RATS WG
understand why that is not a good idea).
If one of the three options looks
Re: [Ace] RATS Entity Attestation Tokens (EAT) - to be a CWT or not to be a CWT?
On 2020-03-04, at 19:40, Henk Birkholz wrote: > > 1.) go to COSE and ask for a "null signature", https://en.wikipedia.org/wiki/Just_Say_No > 2.) go to ACE and ask for an "unsigned token" option, or > 3.) go to CBOR and ask for a tag for "naked" CWT Claim Sets (i.e., that are > not signed). I believe this is pretty much the same option. I think ACE would come up with a CBOR tag as the obvious technical solution, and CBOR would suggest exactly that to ACE as the group responsible for CWT (and thus CWT Claims Sets). Apparently the only technical problem we have is that we don’t have a defined way to mark a naked CWT Claims Set (NCCS) as such; EATs would then be either NCCS or CWTs. CBOR tags are cheap and solve this problem. Grüße, Carsten ___ Ace mailing list Ace@ietf.org https://www.ietf.org/mailman/listinfo/ace
[Ace] RATS Entity Attestation Tokens (EAT) - to be a CWT or not to be a CWT?
Hi RATS enthusiasts, hi ACE, hi CBOR, in the RATS WG we had a lot of discussions about the nature of an Entity Attestation Token (EAT): > https://datatracker.ietf.org/doc/draft-ietf-rats-eat/ > https://github.com/ietf-rats-wg/eat/ A bit of (hopefully useful) context: an EAT is one way to convey believable evidence from an Attester (a role residing on a device-like entity) to a Verifier (another role defined by RATS - the appraiser of evidence). All that is done to provide a Relying Party with "simple enough" attestation results generated by the Verifier to enable Relying Parties (in general, the remote peer) to make an informed decision about whether to put trust in the trustworthiness of that Attester or not. In summary, an Attester could be compromised in some way and RATS tries to inhibit that Attester to lie about that. There are a lot of benefits if an EAT (representing evidence) is a CWT: * we avoid conflicting CWT claim index/label definitions in the IANA registry, while being able to use the CWT world of claims (existing, cnf soon, and such), * at first glance it seems simpler to use existing code that can process CWT, and * EAT can simply inherit the well defined COSE signing conventions. Alas, there is also a very specific drawback: * sometimes RATS might not want to sign a token (maybe that does render it not a token anymore, but rather a ticket. But that is just a rather minor detail for now) Why do RATS sometimes not require a signature around their CWT Claims Sets? Because the surrounding secure channel between two entities with well established authenticity and trustworthiness can be good enough to convey useful CWT Claims Sets without a signature (emphasis on: in RATS). Now - there are multiple options discussed in the RATS WG how to deal with this: 1.) go to COSE and ask for a "null signature", 2.) go to ACE and ask for an "unsigned token" option, or 3.) go to CBOR and ask for a tag for "naked" CWT Claim Sets (i.e., that are not signed). At the last RATS virtual interim there was no certainty how to approach this. So this is a call out. COSE, ACE, and CBOR, how would you approach this "unsigned CWT Claims Set" requirement? If one of the three options highlighted above is out of the question, please say so (and please elaborate on the why for the sake of helping the RATS WG understand why that is not a good idea). If one of the three options looks like a low hanging fruit & viable, please say so (and... you know the drill). I hope that this email contains all the information required to help the RATS WG in this call out to other WGs. If it does not, please say so :) Last but not least, if there are other relevant WGs or experts that could lend opinions or alternatives, let us know. Viele Grüße, Henk ___ Ace mailing list Ace@ietf.org https://www.ietf.org/mailman/listinfo/ace
