Looks good.
The current draft has the following text in several places: "If any verification step fails, the Responder MUST send an EDHOC error message back, formatted as defined in {{error}}, and the protocol MUST be discontinued." I am not sure this is a good idea. This means that the availability of EDHOC will be low. An attacker can e.g. send a single byte as message_4 and it would make EDHOC shut down imidiatly. I think we need to soften this and give the implementation some more choice here. Are there constrained radio protocols where noice could be mistaken for an actual message and forwarded to EDHOC or do all constrained radio have strong enough CRC to make sure that that more or less never happens?
I just changed the following text OLD: If the Initiator previously received from the Responder an error message with error code 1 (see Section 6.3) indicating cipher suites supported by the Responder which also are supported by the Initiator, then the Initiator SHALL select the most preferred cipher suite of those. NEW: If the Initiator previously received from the Responder an error message with error code 1 (see Section 6.3) indicating cipher suites supported by the Responder which also are supported by the Initiator, then the Initiator SHOULD select the most preferred cipher suite of those (note that error messages are not authenticated and may be forged). Made me think about that I don't think the group has discussed if some error messages should be authenticated. Some error messages to message2 could include a MAC to prove that the error was sent by the same party that sent message3. error messages to message3 and message4 could be authenticated. I am uncertain if this is worth specifying. At least not as long as there are easier ways to an attacker to end the protocol. I think what needs to be done is to specify that a processing error does not need to discontinue the protocol, the received message can have been an attack. receiveing an error does not need to discontinue the protocol, the received error can have been an attack.
from 20210422 interim: CB perhaps wisely said: "Use cases exist for multiplexing over same port/URI, so applications should normally sort/demultiplex traffic before start interpreting as EDHOC, which implies treating invalid messages that get to EDHOC code as an error or attack"
Yes, my understanding is that we only need to be concerned about attacks where an attacker sends a packet crafted so that it will be processed by EDHOC (which is not hard).
I made a pull request addressing this issue Added text on demultiplexing. Changed procession so implementation are not mandated to shut down the session if an attacker sends a few bytes to the EDHOC resource / port.. Added more security consideration on Denial of service.
Writing this PR made me think about whether we want to mandate that error messages are always fatal as well as downgrade protection. The ""Wrong selected cipher suite" error is fatal because it is sent in repsponse to message1. You could consider similar types of error sent in response to message2 and message3. E.g. IDCRED format not supported or CRED format not supported or X.509 public key algorithm not supported. [BBFGKZ16] defines the following theoretical downgrade protection for a session: The cryptographic parameters should be the same on both sides and should be the same as if the peers had been communicating in the absence of an attack. But this definition has very little to do with practical security. In practice it does not matter if an attacker can influence the chosen parameter in the current session or a following session. I am still confused regarding the purpose of the applicability statement. Is it a informal section describing things the parties need to both support to make the protocol work or is a normative security section relevant for policy and downgrade. If we want downgrade protection over multiple sessions, the parties need to agree or securely negotiate everything. Downgrade protection for a session does not make much sense to me if an attacker can force the parties to set up a second session with lower security.
Do we need to align the terminology, we use both "session" and "instance" in the draft?
Yes, I just changed "protocol" to "session" not remembering that the draft use instance in other places.
We can resolve this later, I opened . Unless there are other comments we will soon merge this.
The PR has been discussed and merged. Closing
Current specification mandates sending error messages upon certain failures. But in cases when message processing fails when no state has been allocated or when no connection identifier has been found or then a more appropriate action would be to just silently drop the message.
I think the MUST (if possible) is good. Debugging without any error messages is not nice. We now other protocols that it is good to mandate error messages. It is kind of obvious that can not send an error if you don't now where/how to send it. Don't know if that has to be pointed out....
Migth be good to not sent error if you are under a DoS attack.
This issue is addressed by pull request that also address availability
The PR has been discussed and merged. Closing


(Last two commits on wrong branch.)
The prototype of EDHOC-Exporter() has remained EDHOC-Exporter(label, length), while it should be EDHOC-Exporter(label, context, length) as per Alternative 3 discussed in issue URL Correct?
Thanks NAME your comment is addressed in the latest commit. I merge this now.
The text use both the terms "session" and "protocol instance", would be good to settle for one term.
Just chose one, I don't think this needs an issue
In the security considerations "session" makes most sense to me. There is also the term "connection". I will make a proposal.
The spec should likely forbid multiple calls to the EDHOC-Exporter interface with the same label, in order to prevent the same key being reused. Discussed with NAME and NAME
Good catch. Yes, we should have some text about that, but it should probably more be a requirement on the application using EDHOC that on EDHOC itself. Two different application should defintly not use the same label. The same application might rederive the same key several times as long as it keep track of its AEAD nonces and replay window. I thought that we had already IANA registry proposed for this, but that is not the case. We should probably have one. If we have a IANA registry the labels get more fixed and it might be that we need a context input parameter as well.
If we make a IANA registrer for labels, I think we need to let the application add additional information in some way. Two alternatives: We make an IANA register for label prefixes, and let the application append information to the label prefix. This was recently planned for EAP-TLS (and methods built on EAP-TLS) but was changes because the TLS export labels are not really ment to be labels. This would not change the current exporter interface. We expand the interface with a context parameter. This is similar to the TLS exporter. A problem with the TLS exporter is that some implementations decided to not even support context.
NAME how is the context parameter intended to be used? Could you give an example? Would this be some sort of "salt" when deriving the key?
Don't register labels, register label prefixes.
The motivation for "context" or "label postfixes" is to increase the flexibility for the application. Restricting the application to IANA registered labels is very limiting. An application might want to use the EDHOC exporter to derive a number of keys and we should encourage that. The alternative is that the application needs to implement its own key derivation, which might be less secure and might be outside of the TEE. I called it "context" just because TLS calls the paramater in its exporter context.
"Be like TLS" is of course a good motivation. Technically, a label prefix is not different from a context, it just saves the need to separate prefix and suffix.
(And of course there is nothing wrong with multiple calls with the same label; the application has a "right to forget" :-)
The solutions should be equal when it comes to security. The choice should be made based on what is easiest for implementators and apllications using EDHOC. Alt 1. We make an IANA register for label prefixes: "OSCORE Master Secret" "OSCORE Master Salt" The Export function stays the same: EDHOC-Exporter(label, length) = EDHOC-KDF(PRK4x3m, TH4, label, length) An application is allowed to append things to the label prefix: "OSCORE Master Secret" "OSCORE Master Secret PickleRick" Alt 2. We make an IANA register for labels: label = "OSCORE Master Secret" label = "OSCORE Master Salt" The Export function needs to change: EDHOC-Exporter(label, ctx, length) = EDHOC-KDF(PRK4x3m, TH4, [label, ctx] , length) An application is not allowed to append things to the label and uses the ctx instead: label = "OSCORE Master Secret" ctx = "" label = "OSCORE Master Secret" ctx = "PickleRick"
No major opinion. Alt 2 breaks the test vector for the OSCORE security context. It would be good to get more input.
Any preference NAME NAME NAME ?
If desired the CTX is more convenient it can always be added in a wrapper on top of EDHOC-Exporter(). (I assume re-use of label+ctx in Alt 2 is equivalent to re-use of label in Alt 1?)
I prefer to have explicitly specified. We can pass to the concatenation of and . When is undefined/empty, test vectors are not affected. I guess this is what NAME is referring to?
label is a CBOR byte string. While alt 2 use an CBOR array. Definging alt2 as a wrapper seems more complication in my view.
Would be good if people stated alt 1. or alt 2. or made a concrete suggestion for alt 3.
Alt 3 (CBOR sequence) We make an IANA register for labels: label = "OSCORE Master Secret" label = "OSCORE Master Salt" The Export function needs to change: EDHOC-Exporter(label, ctx, length) = EDHOC-KDF(PRK4x3m, TH4, labelcontext, length) where is a CBOR sequence: If you want to keep the test vectors intact, then you could make optional in the CDDL, but not sure how to specify an optional parameter in the interface definition.
Thanks. That is a valid alt 3. but ctx should probably be a bstr
I don't think keeping the test vectors intact is an important goal at all. Let's decide on what is simplest for a user of the exporter interface.
Something like that, yes. Later post do differentiate the type of "label" and "ctx" and in light of that and changing test vectors Alt3 seems clean.
I am fine with alt 3. I can start making PR for that unless somebody has different ideas. I don't alt 1 is a good alternative anymore as is restricts context to being a unicode string. Which would require some base64 encoding or similar for a general context.
Please review alt. 3 as specified in . Unless there are any comments we would like to merge this.
This is included in -07 so I close the issue.
Comment by Martin Disch in URL "The draft does a good job of pointing to the right places in RFC 8152, but I still ended up trying to understand another ~100 page document just to implement the few constructs I actually needed." Should we provide more details about COSE constructs, e.g. in appendix A.2?
(pasting my response from the mailing list here for completeness) Thanks for following up on this. Yes, in my opinion expanding on the COSE constructs would be helpful. But I also sympathize with not wanting to duplicate what is already defined in another RFC (and possibly getting it wrong, as Carsten points out). Considering that there are quite a few implementers already and besides mine you have only received one other similar comment, maybe this isn't an issue for a meaningful majority. In any case, the draft has made great strides already in terms of accessibility and is in a good state now, so I don't see improvements in this area as an absolute necessity.
The two COSE constructs that are used in EHDOC, and are fairly simple. They don't use the recursive structure or embed . I think it is possible to add some additional clarifications on the structure of the COSE messages in the EHDOC draft without having to copy too much text from RFC 8152. As part of a thesis I built a proof-of-concept implementation of EDHOC in the Rust programming language available at URL The naming of the repository is due to the subject being both EDHOC and OSCORE on embedded devices, but the following refers only to the EDHOC implementation. It's based on draft-selander-ace-cose-ecdhe-14 and as such, sadly, outdated. Since it was just one part of the overall work, I only managed to implement the subset I needed, which is RPK and the signature-signature based scheme (corresponding to what draft-selander-lake-edhoc calls method 0). I also took some other shortcuts, such as not supporting auxiliary data. Fortunately, test vectors were about to be introduced just around the time I was working on it, so I've been able to successfully verify my implementation against them when John shared them with me for some preliminary testing. Since I didn't have any prior experience implementing this kind of software, I would definitely consider it more of an experiment, but it's out there and it works, in case it can be useful to anybody. I'm convinced that EDHOC will be valuable particularly in the context of OSCORE, possibly even beyond that. As for the draft itself, I would like to mention one aspect that I think could be improved from the perspective of an implementer. Part of the promise of EDHOC is that it's simple and lightweight due to reusing COSE. That is certainly the case, but breaks down somewhat when working on a system where no fully featured library for it is available. This was the case for me and I personally found it difficult to quickly figure out which aspects of COSE I needed to implement. The draft does a good job of pointing to the right places in RFC 8152, but I still ended up trying to understand another ~100 page document just to implement the few constructs I actually needed. I know the authors are aware of this and there has been some effort to inline more information directly in the specification, which I greatly appreciate. It would be very nice to have an entirely self-contained document to work with. But I have to again point out my lack of experience in that area, it's entirely possible that this draft is in fact much better than others in this regard and I just don't know it yet. With that I would like to support the adoption and am looking forward to seeing how it develops. Kind regards, Martin


CRED_R - bstr containing the credential This is not true for C509 which is an CBOR array


Signed-off-by: David Navarro
NAME NAME and others: Any response to John's comment?
NAME I included John's suggestion in the PR.
Looks good to me. Other opinions?
As specified in section , the payload in some CoAP messages can be an EDHOC message prepended by either a C_x identifier or "true". The draft states: However, the payload is actually a CBOR Sequence as defined by . Thus, we could define and use a new media type "application/edhoc+cbor-seq". Note that the usage of the Content-Format option is optional.
Makes sense to me. NAME NAME others: Comments? Good that you bring up the optionality of Content-Format, we should stress that in this text. The discussion in Hackathon also reminded me about the common-option-compression which NAME presented in the May 12 interim 2021 - how to replace the Uri-Path: "/.well-known/edhoc" with a, say, integer valued CoAP option.
Makes a lot of sense to me, too.
I find this distinction good and the solution consequential, still open for comments.


A static key should not be used both for X25519 and Ed25519. This PR corresponds to .
Please review the proposed change.
The standard does not restrict private key usages. In particular, it could be tempting to use the public/private keys for the ed25519 signature scheme as a public and private key pair for the static authentication mode with the elliptic curve X25519. This does not have clear direct and practical implications. However, this usage falls outside the existing cryptanalysis for the signature scheme, and is a bad practice from a theoretical point of view. This would require a dedicated cryptographic analysis, similar to [2]. [1, Section 12] typically recommends that different keys are used for different algorithms, but it may be unclear if the EDHOC use case falls under this recommandation, or if an extra one could be pertinent. We recommend to mention this issue somewhere in the standard, or explicitly forbid such a shared key usage. [1]: URL [2]: URL On using the same key pair for Ed25519 and an X25519 based KEM. Erik Thormarker.
I've seen single keys used for both ed25519 and x25519 during plugtests; IIUC the agreement among the plugtesters back then was that this was not intended use and should generally not be done. This might serve as a data point that illustrates the need for a clear statement.
Mentioning this issue and refering to [1, Section 12] seems like a good idea. The text would need to mention EDHOC methods as [1, Section 12] only talks about algorithms and the ECDHE in EDHOC is not strictly a COSE algorithm. Writing that using the same key requires a dedicated cryptographic analysis, similar to [2] also seems like a good idea. (As a comparision, I don't think TLS 1.3 states anything about forbidding the public key in the certificate to be used for Elgamal, ECIES, or ECDHE outside of TLS).
Should we propose a PR for this?
NAME Please go ahead. Prepare for the option to have a reference to an analysis showing this is secure under certain conditions.


Reformulating security of expand as stream cipher instead of removing. HKDF-Expand is very often used.Added note of HKDF-Expand length restriction.Key use for different algorithms is already covered by COSE. Nothing is special with use inside of EDHOC. The text is clearly not correct at as signate can also be used in other methods.
Channeling from Erik. Use of the HKDF as EDHOC-KDF for generation of KEYSTREAM2 and encryption of message2 induces a max size. For example, HKDF-SHA256 has max output size 255*32 = 8160 bytes.


I think it would be good to point out early that the EDHOC protocol (just like TLS) only provides proof-of-possesion. Authentication has to be done by the application. I have seen horrible uses of TLS where the implementors believe RFC 8446 when it says it provides authentication.Added text for "Unauthenticated Operation". As pointed out by Marco, this is more general than just TOFU. "Unauthenticated operation" is the term used by TLS 1.3
I think this is ready to merge.
The selfie attack mitigation implies that an initiator is stopping the exchange if it receives its own identity. An active attacker can then use this behavior to test if an initiator identity is the same one as a responder identity. In turn, it implies that the initiator anonymity does not hold against an active attacker when this mitigation is enabled. To judge if this is an issue in practice, the following question should be answered: Are there scenarios where an identity is shared between an initiator and a receiver, but the initiator identity should still be protected? One could maybe think about the case where multiple initiators and receivers are on the same server, sometimes sharing public keys and using distinct ports, but it is expected that the initiators identities are still protected. Possible actions: mention privacy loss due to the selfie attack mitigation. update the selfie attack mitigation, by mentioning that initiators should conclude the exchange as usual, but can check at the end whether they are talking to themselves or not. remove the selfie attack mitigation. Classical selfie attacks are when there is a pre-shared key between an initiator and a receiver, and the initiator will be talking to itself while it believes to be talking to the receiver. When there are only public keys, as in EDHOC, it is unclear to me if what is currently called in the draft is indeed a selfie attack. An initiator talking to itself knows it and does not believe to be talking to some other identity. As such this is why it could be possible to either remove the mention of selfie attacks in the draft, or update it.
I and R are expected to stop the exchange it they receive any identity they do not want to talk to. This likely includes their own identity. Good point that this leaks information. I think that should be added, but I don't see that the own identity is special. >Classical selfie attacks are when there is a pre-shared key between an initiator and a receiver, >and the initiator will be talking to itself while it believes to be talking to the receiver. >When there are only public keys, as in EDHOC, it is unclear to me if what is currently >called in the draft is indeed a selfie attack. The selfie attack mitigation is intended for Trust On First Use (TOFU) use cases, where there is no authentication in the initial setup. I don't think an initiator talking to itself in a TOFU use case would not know it except if they checked R's public key. Do you some better suggestion than "Selfie attack". I agree that it is not perfect. "Selfie attacks" has in older papers been called reflection attacks, but the term reflection attacks has also been used for very different attacks. One option is to not give the attack any name and instead just describe the attack.
I think I like to not give any name, as it does not perfectly match the classical definition. Here, the property which is violated is "If an EDHOC exchange is completed, two distinct identities/computers/agents were active". Which is different to violating the authentication of the protocol as is the case in classical selfie attacks. Good point. So what we are talking about in this issue is a slightly different privacy leak, which happens when the set of parties you are willing to talk to is equal to all responders minus yourself. To be more concrete, let me try to put it in a kind of drafty formal description that could replace the existing formulation. First the existing formulation: Now a possible replacement:
Thanks for the input! This issue is related to the TOFU use case which is still to be detailed (Appendix D.5). We probably should wait with the update until we have progressed that.
Relates to
I made PR for this issue. This is also related to PR and PR . The suggested text in is largely based on the suggested text above but I made some changes. I did not think this fitted well with the rest of the draft. The sentence was also not really needed. This is only true in the case where the set of identifiers is a small finite set. In the general case the set of identifiers the Initiator is not willing to communicate with is infinite. I suggest to add the following recommendation for TOFU To not leak any long-term identifiers, it is recommended to use a freshly generated authentication key as identity in each initial TOFU exchange.
I merged the PR to master. Keeping the issue open for a while.
The current text is not really explaining how TOFU works and the security considerations. Would be good with some more text. TOFU might also go agains requirements in other parts of the document that says that "EDHOC is mutually authenticated.
This is conflicting with present use of COSE. Requires a separate section in the draft, preferably an appendix. We need to describe the use case, trust model, how to use EDHOC and the security properties. Can we reference some other RFC?
Looking at adding text on TOFU I think there is some more work to do. I don't TOFU should require anything specicial. The Section "Identities and trust anchors {#identities}" is fluffy. It is not clear that this is just general recommendations that is outside the scope of the EDHOC protocol and the reposability of the application. EDHOC provides proof-of-possesion and transfers a credential that enables authentication. Thats it. An EDHOC implementation might implemend Authentication for a specific use case, but that is still outside the EDHOC protocol. Any description of the interface between EDHOC and the application when it comes to credential is missing. In general EDHOC provides proof-of-possesion of the private key and then gives CRED_x to the application that says YES/NO. How the application does chain validation and identity validation (or the lack of it like in TOFU) is outside of EDHOC.
Status: This issue is waiting on a restructure, shortening, clarification on the responsibility of the EDHOC protocol and the application. and
The restructuring is done and merged with the master. Appendix D.5 is placeholder for TOFU.
I made PR for TOFU. As Marco pointed out this should be more general than TOFU. I changed the heading to "unauthenticated opearation" which is the term used by TLS 1.3
Merged adding text to the empty TOFU section. Closing
I made some minor updates, have a look.


Addressing
Issue needed.
Should we allow or forbid that eadlabel = k and eadlabel = -k correspond to different ead-values? For example, if an (eadlabel, eadvalue) is always critical: Say, eadvalue is an ACE Access Token with eadlabel = -4, always critical. Then we can either: forbid the use of eadlabel = 4 altogether, or allocate an always non-critical EAD to eadlabel = 4, say, eadvalue is "service indication" as in In case 1 we will have some "holes" in the register. One positive integer blocked for each always critical (eadlabel, eadvalue) , one negative blocked for each always non-critical (eadlabel, eadvalue), and 0 cannot be used. (It is not clear to me that there are many always non-critical, but always critical is probably common.) In case 2, we could still have the registration policy that: if an EAD can be either critical or non-critical then two eadlabel with same absolute value should be reserved for it. What is the main risk with case 2? If someone misunderstands or by accident changes sign on an always /non-/critical EAD this results most likely in an error due to wrong eadvalue (like in the example above), but potentially in an unintended EAD message. (Another registration policy could be that the eadvalues corresponding to ead_labels k and -k should have incompatible CDDL so the error is discovered ...) The EAD specification needs anyway to specify what are the processing rules and if you violate those more or less anything could happen. Comments?
BTW, we may want a term for the ordered pair (eadlabel, eadvalue). The term "EAD" or "EAD field" is referring to the message field, which may consist of multiple (eadlabel, eadvalue).
Just seems like overoptimization to me. I would prefer if we follow the model that we agreed on for C509 which is similar to what CoAP Options is using. If you think it is important to use the complete code point space I think it would be better not assign any functionality to the minus sign and register critical and non-critical idenpendently. The original proposal seems to give two different meanings to the minus sign. The minus value is either a criticallity toggle or a completly different EAD.
Introducing the term "EAD item" for (eadlabel, eadvalue)
Edit: Let's include the main points of this PR in -15 as a input to the design team meeting.
I made a proposal. The text now include the concepts "EAD item" and "critical"/"non-critical" EAD item. There is also more details about how applications makes use of EAD: each application registers its own eadlabels eadlabel is a positive integer associated to a particular eadvalue if the application transports different eadvalues then multiple eadlabels need to be registered the application specifies how EAD items are transported in EDHOC messages, a particular EAD item may be transported in multiple messages (i.e. different EADx). I'll merge this into -15 and look forward to comments!
There is a new PR suggesting this. There is no background discussion in the PR . There would be good with some use case. The definition of what critical need and how the recipient handles critical would need a lot of discussion and fine-tuning.The handling of critical extensions in C.509 is to my understanding confusing and problematic. Both in the specification and in implementations.
Please see for background discussion and use cases.
Seems very unclear that the current PR can be the basis for a ECH type mechanism. PR should motivate why it is the basis for an ECH type mechanism or we should have some discussion regarding use cases for a general critical non-critical EAD mechanism. I do not see that follow from .
Having critical/non-critical EAD seems like a reasonable thing in its own, but it is not clear to me that it is a step on the way to a ECH mechanism in EDHOC.
Should we add another column in IANA register? Type: always critical / always non-critical / application determines criticality
If we define such a Type, the following text can be removed from specification and replaced by IANA consideration: "A specification registring a new EAD label MUST describe if the EAD item is always critical, always non-critical, or if it can be decided by the application in the sending endpoint."
I merged which addresses some points raised in this issue. Please review and comment if there is anything missing. The consequences of EDHOC processing of critical / non-critical EAD items is described, but how the security application makes use of this property is left to the associated specification. (In particular, no registration of criticality in the IANA register.)
This is motivated by two considerations, the concerns for clients selecting a hidden service in a protected way (pinging NAME do you have a pointer to your hackathon project), and TLS's encrypted Client Hello (superseding eSNI, encrypted server name indication). The rough situation for either case is that a client has some out-of-band information about the server that includes a public key for encryption (even if the encryption key on its own may be insufficient to authenticate the server). As a straw man proposal (mainly as scaffolding for the "how to enable it" steps later), consider the following: (I bet that reading the will give valuable input for making this complete). To ensure that responders (who are, in their identity selection, the more exposed side) can't be probed for their support of encrypted EAD, encrypted EAD should be marked as "elective" in the sense that a server may ignore it if it does not support it. (It'd still become part of the transcript). If a server receives an EAD it can not decrypt (or which, after decryption, contains nothing valid, eg. because the wrong GE was used), it needs to just continue and pick the CREDR / IDCREDR it would always have picked. AIU we do not yet distinguish between EAD that are elective and those that are critical. I do not know whether we'll even have any "critical" ones (as the peer's lack of action on them should be enough indication that they were unsupported), but if we do distinguish (eg. along the positive/negative number line), encrypted EAD should be optional. This has the upside that initiators that can spare the few bytes can always include some random bytes in the encrypted EAD, and thus ensure that actual users of encrypted EAD do not stand out (or that connections with encrypted EAD would be blocked). It should be a design goal of encrypted EAD that any use of EAD can always be plausibly claimed to just be random bytes added because the specification says one should do that ever now and then. For a practical example, a vulnerable service (say, anything civil rights related) might be operated at the same IP address as a more wide-spread service (say, a large public LwM2M provider). The civil rights service would publish its address together with the public key GE and its service name in DNS records similar to . A client contacting it would start an EDHOC exchange with the public address and encrypt the service name with GEX in the EAD1. The server would respond with credentials for the civil rights service, to which the client then may either present an anonymous (CCS) identity, or (now that it knows it's speaking to the right peer) its own CREDI / IDCREDI. If the CRED sizes are always the same, this exchange should be indistinguishable from an exchange done between an LwM2M client and the LwM2M backend when the client has chosen to send some more garbage bytes. (For application such as eighthalve's, it should be noted that there is probably no need for any further proof of identity inside the EAD1 plaintext: Possession of GE in combination with the suitable plaintext should suffice to open the present alternative server credentials, any secret whose possession is proven in the plaintext part would be exactly as secret as GE, as no attacker without E can obtain the plaintext.). To condense this all into a few actionable points: We should have a code point in eadlabel for "encrypted EAD" data. (We may not even have to specify how it works, that can be specified later or even be guided by the out-of-band information that needs to be present for all of this anyway). That code point either needs to be described explicitly as "MUST ignore if not supported / content not understood" for all of EDHOC from the start, or there needs to be general wording about which ead_labels are to be ignored if unprocessable. We should encourage initiators to send some random garbage there if they can afford it. (A LoRA device certainly can't, a 6lo device probably neigther, but a guard proxy establishing a connection probably can). This is not only to protect initiators that need it, but also to ensure that it is not being blocked, and that responders don't reveal whether they support it.
This has parallels to , which will take some work to pick out in detail.
I'm trying to understand what would need to be changed in EDHOC to support this functionality. The distinction between critical and elective EADs. This seems like a good general construct. Perhaps by designated subsets of labels, e.g. negative or even eablabel are elective. The use of a designated eablabel for encrypted EAD1 seems less general and is somewhat breaking with the mindset that one application is reserving a label and defines the associated processing. Is there a problem with specifying a particular (elective) EAD for this application and associate a policy that it is used by default, with garbage when there is nothing to send? (I couldn't see obfuscating eadlabel really achieved much in practice, but I may have missed something.)
The first, yes. As for the labels, if the application reserves a label and defines the processing, it is showing a passive attacker that it is being used; this may be undesirable. Applications should have some label behind which they can hide the fact that this application is being used; I think it is preferable if that is shared by as many applications as practical (including the "it's really just garbage" application that some hosts may want to run). Whether that requires that they also share an encryption mechanism or not, I am unsure.
NAME at the IETF Hackathon, we put together a working proof of concept for URL Is that what you mean? That's not really related to ECH, but came out of MASQUE.
NAME The three-party setup seems very useful in different settings, so there may be multiple use cases where R receives EAD1 intended for a third party and needs to know that to do with it. Currently eadlabel is filling that function. If we can assume that R by default has designated third party, or sufficient information about the third party is carried in EAD1, then eadlabel could probably be encrypted. (In principle, EAD1 could be a COSEEncrypt0 or any tagged COSE object, with information needed by R in the unprotected header.) So how do we handle the case when there are multiple candidate third parties and you want to hide both the intent and the third party identity? A designated eadlabel is possible (or two, if critical / elective is baked into the label) but I don’t see how this label will be used other applications (so to acheive uncertainty about what is intended) because the co-existence of different candidate applications using EAD1 requires a method for R to distinguish between them. Maybe I'm missing something?
For the attacker to be unable to know which service the user is contacting, it would be important that an initiator receiving the credentials to the wrong service name fails in the same way has an initiator for which verification of the responder signature would fail. Otherwise, an active attacker could test if I intended to use the protected service by xoring the encrypted EAD1 with some random bytes. The responder would always see EAD1 as some random bytes and answer with the unprotected service, and then, if the initiator wanted to talk to the protected service, it will fail after decrypting the message and seeing the wrong service credentials if the initiator want to talk to the unprotected service, it will fail during the verification of the signature as the two transcript will not match. Those two failures should then be indistinguishable from the attacker point of view (even with timing attacks).
At least critical / elective EAD should be included in -15
The critical / elective logic could in principle be implemented in each application. It would be good to provide more use cases to support the case of making this a standardized feature. Clearly there is a benefit with tagging an EAD as "critical" since some operations require the information carried in the EAD to complete, e.g. authorization information from a trusted third party may be required for the Initiator to make any use of the authentication. But what EAD content is not critical? Is the following a good example for elective EAD? A service provider is allowing a variety of devices in its network to authenticate using EDHOC and grants different access rights depending on the capabilities and trustworthiness of the device. Later, the IETF specifies the EAD for remote attestation (see Appendix E). New devices which implements this EAD and appropriately attests to the attestation request carried in the EAD field get certain access which old devices doesn't get. But the old devices should still get basic access. If all EAD were critical then the old device which doesn't understand the new EAD would be forced to discontinue the protocol at the arrival of the remote attestation EAD. If the EAD is elective, then both old and new devices can be supported. Question: With this example in mind, is critical / elective a property of the EAD type, or isn't it rather a boolean set by the application? I can think of another use case where remote attestation is mandatory and it doesn't make sense to define different EADs for these two use cases. (Then we are somehow back at the application specified property. But it may still make sense to have a standardized way of expressing criticality.) Thoughts?
The critical/elective property always needs to be encoded in the message (as an LSB, or as the number's sign) no matter whether criticality is the sender's choice or whether it's part of the registration. From a recent chat I think that registering one number, and then allowing it to be used in positive (elective) or negative (critical) role as by the sender's choice. Application authors would describe in which criticality/-ies it makes sense to use their number, just as they describe in which of the messages it makes sense. (The alternative is to allow registering elective and critical options independently, and that application authors who do need to give the senders a choice of using either would register a pair of options; really would work just as well). Introducing RATS data seems like a very good use case to illustrate EAD examples. (In this particular case I don't know why a sender would insist the attestation to be processed into its network joining). To rephrase the original use cases with recently published terminology, we can refer to . That reference might go with a suggestion that devices that can afford sending a few more bytes should occasionally do so in a grease-style non-critical option, or maybe in a non-critical Encrypted-EAD1 option right away. I'd welcome if ace-ake-autz already defined an EAD field for what could resemble Encrypted-Client-Hello; AIU it currently refers to an older version of EDHOC. It could be updated to place LOCW and ENCID into separate EAD items, and the latter could be more generally defined as "a container for encrypted data which the responder, possibly guided by other EAD1 fields, can use to come up with a suitable IDR". (How encid is then constructed would not be a property of using that particular option, but follow from using the LOCW option). Then, there would be no need for a defined Grease field, as that ENCID field could serve the very same purpose.
Since there seems to be a case for non-critical EAD I made PR . Please review. (Yes, ace-ake-authz needs to be updated, following the closing of this issue.)
I did not read this discussion before now as it did not seem relevant for the base EDHOC protocol. The PR seems quite far from the use case described here. PR described a general critical, non-critical mechanism similar to X.509 extensions while the discussion in this issue is about an ECH type of mechanism..... PR does not seem to be the basis of a good ECH mechanism.... NAME could you have a short presentation at LAKE IETF 114? (edit: fixed Christian's github name)
I think it is clear that PR does not solve the use case outlined here. In particular, the comment from NAME above is not considered as far as I can see. But the point about critical / non-critical (eadlabel, eadvalue) appeared in this discussion and merits to be specified as a general feature.
I think it would be good with longer discussion about ECH type mechanisms in EDHOC. Might be added on later but it could also benefit from being added alrady in the base EDHOC specification. For a use case where the Initiator knows the long term key of the Responder the TLS ECH solution is a quite ugly hack that uses two different keys and an ineficient message flow. The use of a single key as discussed above is an improvement, but the use of a noise XX pattern is not optimal. If you want to design something for the use case where the Initiator knows the long term key of the Responder it makes more sense with noise IK which is used by WireGuard. If the use case where Initiator knows the long term key of the Responder is small the above approach makes sense. If is is big it might make more sense to define new method(s) based on the noise IK pattern.
Could we have a design team meeting or an interim to discuss this issue?
In the use case that the Initiator gets the Responders static public key beforehand The Responder would in this case have a static DH key. The Initiator could use Static DH or a singature.
Perhaps a breakout meeting during/just before IETF 114?
Closing this since NAME agreed that the introduction of critical/non-critical EAD (PR , included in -15) in combination with an example using third party encrypted EAD (as in ace-ake-authz) resolves the issue.


URL I have been reading v17 and sent some comments to the authors, that I summarize here: 1) - Regarding RPK, previous versions of the document had a more detailed explanation about RPK. For example, in version v06 you had "The Initiator and the Responder MAY use different types of credentials, e.g. one uses an RPK and the other uses a public key certificate.” So RPK is included as part of the definition of authentication credential. However, v17 may have a different meaning since it seems “credentials" is defined as follows: "EDHOC relies on COSE for identification of credentials (see Section 3.5.3), for example X.509 certificates [RFC5280], C509 certificates [I-D.ietf-cose-cbor-encoded-cert], CWTs [RFC8392] and CWT Claims Sets (CCS) [RFC8392]. When the identified credential is a chain or a bag, the authentication credential CRED_x is just the end entity X.509 or C509 certificate / CWT. I assume RPK is also an authentication credential and this should be included in this text. A clarification would be worthy. 2) I assume it is possible that any two IoT devices can act as initiator but also as a responder, even between same two peers. It is the application which decides when to start EDHOC (initiator) in a particular case, correct? 3) It seems the EDHOC does not define any exchange for the key update (some sort of rekey). It seems an application at some point exchange some messages as "some event that triggered the key update.” Then the application call to EDHOC-KeyUpdate function to get a new PRK. Am I right? I am asking because looking at IKEv2, for example, and for the rekey, an exchange is required. Although it would add a little bit more complexity, wouldn’t it be sensical that EDHOC defines a 1 RTT to exchange a couple of nonces for the rekeying. Moreover, this function is defined in an Appendix. Is it mandatory to implement?
Yes. The document should talk about RPK a bit more as that is term that people might search for. Should be explained that CWT is the format EDHOC uses for raw public keys (RPK). Hi all: I have been reading v17 and sent some comments to the authors, that I summarize here: 1) - Regarding RPK, previous versions of the document had a more detailed explanation about RPK. For example, in version v06 you had "The Initiator and the Responder MAY use different types of credentials, e.g. one uses an RPK and the other uses a public key certificate.” So RPK is included as part of the definition of authentication credential. However, v17 may have a different meaning since it seems “credentials" is defined as follows: "EDHOC relies on COSE for identification of credentials (see Section 3.5.3), for example X.509 certificates [RFC5280], C509 certificates [I-D.ietf-cose-cbor-encoded-cert], CWTs [RFC8392] and CWT Claims Sets (CCS) [RFC8392]. When the identified credential is a chain or a bag, the authentication credential CRED_x is just the end entity X.509 or C509 certificate / CWT. I assume RPK is also an authentication credential and this should be included in this text. A clarification would be worthy. 2) I assume it is possible that any two IoT devices can act as initiator but also as a responder, even between same two peers. It is the application which decides when to start EDHOC (initiator) in a particular case, correct? 3) It seems the EDHOC does not define any exchange for the key update (some sort of rekey). It seems an application at some point exchange some messages as "some event that triggered the key update.” Then the application call to EDHOC-KeyUpdate function to get a new PRK. Am I right? I am asking because looking at IKEv2, for example, and for the rekey, an exchange is required. Although it would add a little bit more complexity, wouldn’t it be sensical that EDHOC defines a 1 RTT to exchange a couple of nonces for the rekeying. Moreover, this function is defined in an Appendix. Is it mandatory to implement? Beyond these clarifications, I think the document is ready. Best Regards. Rafa Marin-Lopez, PhD Dept. Information and Communications Engineering (DIIC) Faculty of Computer Science-University of Murcia 30100 Murcia - Spain Telf: +34868888501 Fax: +34868884151 e-mail: EMAIL


I strongly think that all 10 EDHOC-KDF should be in the same table The text about maclengthx need to use the defined term hash_length
I made one commit for review.


This builds on .
Summary: use a high-entropy PSK with DH, otherwise, with a low-entropy PSK, use a PAKE. Reference appendix with security properties from NAME


FIxed up: some nits on recommendations. I think the wording was a bit off on low entropy PSKs, so I lifted from ekrs text from earlier in the draft. some of the stack interface stuff on hints is not valid for TLS1.3 (hints are TLS1.2 and earlier), so removed it. Some prelim text on collisions. For completeness, will take a look at gnutls and wolfssl order too. Note, even with the OpenSSL callback sequence, the application still does not know if there is a collision...
Starter text from NAME
NAME can you please take this?
Ping NAME


Ah, I see now. I think what would help is "in contrast to methods like RTX or flexfec (when retransmissions are used) [I-D.]"


It's similar to the redundant encoding, but done within the Opus bitstream, rather than at the RTP level.


The discovery fields for the interaction methods were still in a single list, even though those have now been split into start and finish sections.
:heavycheckmark: Deploy Preview for gnap-core-protocol-editors-draft ready! :hammer: Explore the source changes: 754d971b07753b2b9580c2c6f0b3c8997c34b260 :mag: Inspect the deploy log: :sunglasses: Browse the preview:
Yes, makes sense


remove OAuth DPoP binding. Described why on IETF mailing list: only works for asymmetric keys, requires key be presented in the header (duplicating information from GNAP messages). It was never meant to be a general purpose signing mechanism, though the FAPI group in OIDF is considering it as an option in current proposed work.
:heavycheckmark: Deploy Preview for gnap-core-protocol-editors-draft ready! Built :hammer: Explore the source changes: c380eb747945a8002c19de9784e86bee713951a0 :mag: Inspect the deploy log: :sunglasses: Browse the preview:
Ok that's weird (just removed some lines...), will have a look
Ok that was due to my rust analyser in vscode, fixed it now


The boolean value "true" is no longer used to specify supported interaction start modes.
Deploy Preview for gnap-core-protocol-editors-draft ready! Built Explore the source changes: ef948b6b0b53f92352ec617e6074174e0a2eaa3f Inspect the deploy log: Browse the preview:


Deploy Preview for gnap-core-protocol-editors-draft ready! Built Explore the source changes: 0d7a49a6be4a9740f850d2477b1f2462de781b10 Inspect the deploy log: Browse the preview:
Section 2.2 is currently called: Then the text continues with: This means that this section is currently restricted to the RO. Since this call is restricted to the RO, the title of this section should be changed into: Requesting RO Information. In addition, the reason(s) for requesting such information is not mentioned and should be explained. As a side-consequence, a user has no on-line means to know which personal data the AS knows. This comment also impacts the content of section 1.4.6 (Requesting User Information). This topic has been first addressed under the issue which is still open. It would be wise to allow such an on-line access so that the user can know which attributes are known by an AS and then choose which attributes to insert into an access token.
Maybe we'll need a bit of rewording, although I'm not sure the proposed changes help so much. I just think we should put more emphasis (and state early on) what is shortly described at the end of section 4, i.e. that here RO = end-user
RO = end-user is not the general case. The usefulness of supporting Requesting RO Information is not crystal clear and should be indicated, but there is an interest to support Requesting User Information. While I agree with you that "we'll need a bit of rewording", simply stating that RO = end-user in section 4 will not solve the issue.
I notice that states It also shows that there is no RS involve and diagram uses label: User (not RO) To my understanding End-user is "logged in" to the client instance. Given role definition: If we don't have RS involved, so we also don't have any Protected Resource here, does it really make sense to speak of Resource Owner?
Yes, that's why we talk about the "user" here. Notice that currently, this term is used when we don't know the exact role it will play in the protocol (end user or RO).
If that's the case for why does speak about Resource Owner? Again in 2.2 we also don't seem to have Resource Server or Protected Resource involved.
The rationale is : in the intro of section 4, gnap allows a large variety of cases. GNAP can handle UMA2 types of scenarii (hence 1.4.6 and a few other places) but in gnap core we mostly detail the case where end-user = RO. Hence what we explain about the subject, and it makes sense to limite the diffusion of confidential information about the RO (the most limiting case, hence 2.2 and a few other places) That's actually a quite subtle difference, but i think it makes good sense.
Given above definitions maybe it would make sense to broaden definition of RO to: subject entity that may grant or deny operations on resources or obtaining assertions it has authority upon. Since in the User acting as RO doesn't grant or deny operations on resources (served by RS) but only grants / denies obtaining an assertion.
I agree that the specific language that NAME references should be tightened up. What's a little awkward right now is that GNAP's language treats access to an RS and access to information contained in assertions as protected resources, but it doesn't do so particularly cleanly due to several major text revisions that have changed things a little out of sync with each other. Both data from an RS (using an access token) and assertions/identifiers passed to the client are targeted at the client itself, so in that way they're the same nature, a protected resource after a fashion and both controlled by an RO of some kind. What's different is that the info passed back directly is usually assumed to be :about: the end-user, because that's what the client is calling about in just about all the use cases that are known. Technically all of the information, either from an RS or subject information passed directly, is controlled by the RO. The end-user can get involved through interaction and act as the RO. The case where the RO doesn't equal the end-user is useful in many situations but leads to unexpected weirdness when you're talking about the subject information coming back.
Fair point. We might start by listing what needs to be changed.
I tend to think of the AS as having a separate service endpoint for RO requests because they are the ones that can edit AS policy. A service endpoint that is accessible to End User requests would be "separate" and could be used by anyone including the RO when they want the protection of least-privilege. This distinction may be unhelpful in the general case of explaining GNAP so I don't mean to overstate it.
NAME when you say "service endpoint" are you thinking of something that's interactive and user-facing (so a webpage) or something that's a callable API?
NAME I really don't know enough to answer purely technical questions. I think mostly in terms of privacy engineering and look to this group for security and devops perspective. Therefore, I focus on the AS as the primary, if not the sole, entity that stores and executes RO policy. The AS takes requests and turns them into access tokens. The requests might be via (RAR) API or a web form. Either way, this request interface is likely unsecured. Some requests present credentials while others might add an authentication flow. That begs the issue of how did the AS get the RO's policies to begin with, long before a request comes in? I would define whoever sets the AS policies as the RO (regardless of any particular RS-RO relationship). A so-called "policy manager API" has been under discussion in UMA for about a year because at least one implementer wants to author policies on a mobile app and standardize the way they are uploaded to the AS. Back to Justin's technical question, I'm trying to implement the shortest distance between OAuth 2 and GNAP in a way that I can understand and explain to others. I'm doing this in FastAPI (because I don't know much beyond elementary Python, because it has built-in OpenAPI documentation, and has some OAuth 2 and JWT functionality). I'm deploying (automagically) to DigitalOcean App Platform in order to be clear about my various security and build shortcuts. I've designed the demo as two separate FastAPI server domains for the RS and AS. A "global" CouchDB instance is deployed for RO policy storage and any state that needs to be saved as part of the protocol demos. -- URL (the AS) and running at https://ognap-URL -- URL and running at https://ognap-rs-URL -- URL The protected resource is going to be_ just a self-verifying vaccine credential (I invented) -- URL -- Some of this is running at URL I've been stuck trying to answer Justin's exact question for quite a while. I think I need to set up the AS (OGNAP) to deliver a PWA to the RO so they can edit policies locally in PouchDB and sync the polices with the CouchDB the AS can access when a request comes in. That forces me to learn URL or something like it. Aside from my long-term goal to upgrade the HIE of One Trustee demo from UMA to GNAP, I'm also hoping to show the W3C and DIF protocol groups how easy it could be to mitigate significant OAuth 2 human rights concerns using GNAP. Any suggestions, help, moral support would be really welcome.
back to NAME and NAME : looking again on this. I guess we could define what we mean by operations. Getting an assertion is an operation, in my view. Or give it as an example. What do you think ?
I think it comes down to whether or not we consider the "subject information", which includes both identifiers and assertions, to be "resources" or not. I always thought they are, but they are definitely a different style of resource than what comes from the RS so maybe we need better wording around it. We talked about it a bit in the long terminology discussion a year ago, but I don't think we ever really landed on a term that fully captures "stuff sent directly to the client by the AS and not accessed through the RS". Identifiers and assertions are the two categories where there's clear demand, but other things could happen through extensions as well.
Does this issue also have to align with authentication flows that build on GNAP? a subject presents a DID or other identifier to a relying party (RP) the RP dereferences the identifier to an AS they trust a request for assertion is made to the AS the AS issues a liveness challenge to the subject the AS returns an assertion and attributes to the RP (the attributes might be accessed indirectly via an access token returned with the assertion) How is SIOP planning to handle this?
In the current draft, section 2.2 : "The AS can determine the RO's identity and permission for releasing this information through interaction with the RO (Section 4), AS policies, or assertions presented by the client instance (Section 2.4). If this is determined positively, the AS MAY return the RO's information in its response (Section 3.4) as requested." Currently, a resource is just a short cut for "Protected resource", which really refers to an API served by a RS. So we have a mismatch (or at least a missing case) in the RO definition (as pointed out by NAME and NAME I've tried some sentences to specify subtypes for resources, but it becomes very confusing. The proposal by NAME to define the RO as "subject entity that may grant or deny operations on resources or obtaining assertions it has authority upon." seems slightly incorrect to me, because the assertion is not made by the RO, but by the AS. What the RO grants to the AS is access to its attributes (and then the AS may carry out further due diligence to derive assertions, for instance through AuthN flows as suggested by NAME The decision to disclose or not its own attributes is not restricted to the RO, it's actually something under the control of every subject. So here's what I'd suggest to solve the issue (new part in bold): update the definition of "Subject: person, organization or device. It decides whether and under which conditions its attributes can be disclosed to other parties." question 1 : should we limit this to physical persons? (from a legal perspective, that makes sense, but then wouldn't an org want to restrict what it shares, cf issues around data sovereignty?). I think the principle could be generic. question 2 : I've added under which conditions because we already discuss that in the text (manual consent, automatic policy, etc.), plus it's not only a yes/no, it also concerns what those other parties can do with it, including further sharing those attributes, cf the case mentioned by NAME where the AS sends them to the RP. Feedback welcome !
section refers to the Subject exclusively as RO. I'm still uncertain if the subject who in interaction only decides to disclose some attributes in an but not any "Protected resources" (an API served by RS) is considered to act as RO. If that's the case what would be the case where the subject decides to disclose some attributes but doesn't act as RO?
I'm not entirely sure about the use case you're targeting here. Could you be more specific ?
Maybe I shouldn't have mixed two questions together. Let's focus on one of them first. section always refers to the Subject as RO. In your previous comment you mentioned that: When we would have a situation where a Subject is deciding to disclose its own attributes but they don't act as RO?
In theory section 4 allows other situations (at the beginning of the section). But the only case that's detailed is the case where it is indeed the RO.
Thanks, now for the second part of my question. In we find: In this scenario, while no RS is participating, so no Protected Resources are being accessed. We still have Shouldn't definition of RO should still be broadened from current Keeping in mind It might still be something in direction of subject entity that may grant or deny operations on resources or obtaining assertions containing attributes it has authority upon. In short, if RO plays role in . There seems to be more to that role than just granting or denying operations on resources (an API served by RS).
My view is that the attribute part is covered by the fact that the RO is a subject (obtaining them is covered by the subject definition now). The main rationale for the protocol is still related to access to protected resources, and I believe we would dilute that otherwise.
In that case is there any reason for to still include: I think 4 could be removed altogether and 5 could become (after renumbering) This section states in the first sentence that it does not involve RS and access to protected resources (an API served by RS)
We still need to make sure that the user is indeed the RO, hence step 4.
I still consider that the information about the subject is counted among the "Resources" being released here. The only real difference is that instead of them being at an RS, they're passed directly to the client instance.
Yes, this didn't change. I'm only saying I don't think it needs to be embedded into the RO definition, since we can assume from the subject definition itself that some mechanism exists to grab the subject attributes data if it consents to. Changing the RO definition or worse the (protected) resource definition makes the entire thing convoluted, at least in every variation I tried.
NAME Right, and I think I agree with that. The definitions should try to stay tight, if we can. But if the surrounding text, especially the "subject information" request stuff isn't clear, then this is going to come around again. I don't have a specific answer but I would be surprised if we can't improve this, since it's come up a few times.
I am supportive of elf-pavlik when he writes: fimbault agrees with him when he says: When looking at Section 3.4 that is indicated in that section, the following text may be found. If information about the RO is requested and the AS grants the client instance access to that data, the AS returns the approved information in the "subject" response field. The case where information is about the end-user is not addressed, i.e. there is no sentence starting with: If information about the end-user is requested (...) Does this mean that an end-user is not allowed to know which personal data is known by the AS about him ? If this would be the case, such a limitation would not comply with generally agreed privacy principles. The text is still not fixed in draft-08. What are the benefits for a client to know information about the RO ? This may be crystal clear for the editor(s), but it is unclear for a lambda reader.
Based on recent conversations, especially URL it seems to me that the intention is to consider the subject as RO with regards to the information about them. I think this shows up clearly in since it does not involve any Protected Resources but it stills call the user RO. It might be helpful to document scenarios where there is more than one AS involved. Let's say we have Alice using a client to access resources owned by Bob. Here we could have two different AS: AS providing user information about Alice to the client - here Alice would act as both End-user and RO and Bob not be involved at all AS providing access_token to the client allowing access for protected resources - here Alice would act as End-user and Bob as RO Does that scenario with two different Authorization Servers sound reasonable?
NAME Those two both make sense, and it makes sense even for them to be together. You could have those be the same AS as well, if Bob's resource server is protected by the same server Alice is using to log in to the client. But they're different kinds of access, and it would make sense to talk about them in a single example scenario to help call out that difference. There's also a weird case from the CIBA work in the OIDF: Alice uses client software to find out who Bob is. The canonical example given here is a call center: Alice needs to verify that the person calling her is actually Bob, and so Alice starts something with the AS that reaches out to Bob to approve the release of identity information about Bob to Alice, in real time.
NAME how does Alice know which AS can release identity information about Bob? I would not make an assumption that one global central AS exists and it has information about the whole Earth's population?
NAME This use case is not assuming a global AS at all (I agree, that's absurd), but it is assuming that Alice and Bob are both working with a known ecosystem. In the case of the call center example, it's the supporting company's AS -- where Alice works and where Bob is a customer. So, Bob needs to have an account there, and so does Alice. Alice's account needs to be authorized to get info about other users (because she's a support tech). Bob's account is a customer account that Alice can fetch information from anyway.
I see, thank you. It indeed looks like another use case where Bob acts as RO but there is no RS or Protected Resource involved.
I've encountered the CIBA use case very recently. Here's a summarised description : the enduser gets in touch (out of band) with the support, so that both are available at the same time the support needs to get read access to some info stored on the enduser's mobile, and uses CIBA to get the enduser's approval returned scopes define what can be accessed through another OIDC client (used by the support agent) there are no RS involved Note : this issue is closed, so either we should reopen it or open a new issue
NAME Agreed, we've drifted off of the topic of the issue as well. I opened up a new issue for discussion of the cross-user CIBA use case specifically:


Deploy Preview for gnap-core-protocol-editors-draft ready! Explore the source changes: 180278a02620d6e193b78d72e2dae6d0aa5c5c4e Inspect the deploy log: Browse the preview:


Update all diagrams to use AASVG for rendering in HTML.
To edit notification comments on pull requests, go to your ._


After discussion with NAME , this PR now makes keys single-format-only as previously suggested.
To edit notification comments on pull requests, go to your ._
Yaron: why are we sending a JWK as well as a cert? Are we checking that the cert contains the same public key as the cert? Justin: I would be OK with the different formats being mutually exclusive somehow. The AS would need to check that they’re the same and throw an error if not. But this would also let the RC send over whatever it’s got for its own keys every time.
The document has been changed to address this issue, copying my text that refers to the latest draft version: In Sec. 7.1 we allow the client to include multiple keys of different formats, provided they are "equivalent". This doesn't make sense, because the only reason to send multiple keys is that the sender suspects that the recipient doesn't understand one of the formats. But if that's the case, the recipient is not able to validate the MUST requirement that the two formats be equivalent. This could also lead to interesting key injection attacks. IMO we should only allow one key value/format for each request.


Adds the field for requesting information for a specific user, separate from identifying the current end-user. Also adds a security considerations section addressing asynchronous authorization methods.
To edit notification comments on pull requests, go to your .
Normally we think about releasing subject information being about the current end-user, but that's not necessarily universal. The use case from CIBA: Alice is a support engineer with a company Bob is a customer of that company Bob calls the company and talks to Alice Alice needs to authenticate, from her system, that Bob is the person tied to the account in question Alice's client messages the AS to request Bob's information (probably including an identifier for Bob in the request) The AS reaches out to Bob to approve Alice's client to get Bob's information Bob approves Alice's request (probably on a pre-enrolled device) The AS sends Bob's information back to Alice's client Note a few key assumptions with this: At no point does Alice's client think that Bob is logging in. Alice and Bob both need accounts of some type at the AS Alice's account (or client) need the rights to request someone else's info Bob's approval mechanism needs to be tied to his account ahead of time (since Bob isn't running the client and the AS needs to reach out to him out of band) Bob's approval needs to be clearly directed to tell Bob that it's Alice (and alice's client) asking for his info Alice might need to log in / interact with the AS as part of this, or it might be tied to the client instance (maybe Alice has logged in for the day and that association is remembered by the AS?)
This is an interesting use case. Yet CIBA doesn't necessarily require an AS to work, as long as one is only interested in getting scopes. Is there a generic use case for cross-user subject information + required AS? Or maybe we should explain the added value of the AS in that specific case ?
We will add an example in section D that shows how this would work and verify that the language around subject identifiers is sufficiently robust to encapsulate this. This might also add additional security and privacy considerations when used in this mode because multiple people are now involved explicitly.
I think this could be marked as NEEDS TEXT ?
I think it mostly just needs to be added as an example, and I can do that.
Fine ;-) (on my side, I always tend to consider CIBA as some degenerate phishing experiment, but maybe that's too extreme)


Just two minor typos I stumbled across.
Built To edit notification comments on pull requests, go to your .


clarify that user codes are unguessable, - update user code examples,
To edit notification comments on pull requests, go to your .
This is very minor, but there's a contradiction between the usercode provided in the example in section 3.3.3. and the recommendations that are mentioned in the text above it. The text says: And However, the example provided below it goes against these two recommendations, as it contains a special character (a hyphen) rather than just letters and numbers, and it's longer than eight characters in length: I'd suggest either tweaking the wording, or tweaking the example so that the usercode provided in the example is aligned to the recommendations mentioned in the text.
The specification does not require user codes to be unguessable. Section 3.3.3 (Display of a Short User Code) states that user codes have to be unique and should be short-lived, but this does not imply that codes should be unguessable. It seems that Section 13.27 (Exhaustion of Random Value Space) does not apply to user codes, but to values that are clearly random values "such as nonces, tokens, and randomized URIs". If attackers can guess user codes, the same attack described in URL is possible.
Good catch! The intent is for these to be unguessable, so we can add that explicitly.


NAME Please take a look at this updated text to see if it addresses your concerns.
To edit notification comments on pull requests, go to your .
Thinking about possible extensions to GNAP's interaction modes, I had the impression that the specification could be a bit clearer regarding requirements on such extensions. From reading Section 3.3, my understanding is that all implementations of GNAP, including ones using extensions which define additional interaction finish methods, MUST include a nonce in the grant response (given that the AS wants to use the finish method offered by the client instance): URL However, Section 3.3.5 sounds a bit different, only referring to the two interaction finish methods defined by GNAP core: URL Section 4.2 could be a bit clearer as to what is expected of future extensions to GNAP, it currently says: URL with the two following sections describing the finish methods defined by GNAP core. This is, however, somewhat clearer in Section 4.2.3: I.e., Section 4.2.3 implies that AS must (somehow) provide the client instance with an interaction reference and interaction finish nonce. But it may be helpful to make this more explicit throughout the relevant Sections. There seem to be no requirements for future interaction start methods. It may be helpful to document some minimal requirements, e.g., enough information to identify the grant has to be conveyed to AS via RO in the interaction start (such as the redirect URI in GNAP core).
Thanks NAME for taking the time! The proposed text looks good to me (just one possible typo, I'm not a native speaker, so I'm not 100% sure about that).


Expands the discovery document and aligns it with changes made to the discovery process in core. Addresses
:heavycheckmark: Deploy Preview for gnap-resource-servers-editors-draft ready! :hammer: Explore the source changes: ac397efc4f491e2003a3f8059eef765b8e3075b3 :mag: Inspect the deploy log: :sunglasses: Browse the preview:


Expands the definition of the resource set registration protocol, used by an RS to declare a resource set to an AS at runtime and receive a reference identifier for that resource set to hand to a client.
:heavycheckmark: Deploy Preview for gnap-resource-servers-editors-draft ready! :hammer: Explore the source changes: f9aac0b2af163c0f9a58ba17e93db7e8956140bf :mag: Inspect the deploy log: :sunglasses: Browse the preview:
Registering a Resource Handle: Editor's note: It's not an exact match here because the "resource_handle" returned now represents a collection of objects instead of a single one. Perhaps we should let this return a list of strings instead? Or use a different syntax than the resource request? Also, this borrows heavily from UMA 2's "distributed authorization" model and, like UMA, might be better suited to an extension than the core protocol


Updates token introspection definitions into a more full protocol offered by the AS.
:heavycheckmark: Deploy Preview for gnap-resource-servers-editors-draft ready! :hammer: Explore the source changes: 0b6505e11547ab68388ce27ffc88a8e1c9e5c16b :mag: Inspect the deploy log: :sunglasses: Browse the preview:
Introspecting a Token: Editor's note: This isn't super different from the token management URIs, but the RS has no way to get that URI, and it's bound to the RS's keys instead of the RC's or token's keys.
From a privacy point of view, token introspection allows an AS to know exactly when operation(s) are being performed by an end-user on a RS. This provides useful information for ASs that may be tempted to act as "Big Brother". For that reason, the risks related to token introspection should be advertised in the Privacy Considerations section. Its usage should be deprecated in the general case. If there exists specific cases where there is no such a risk, these cases should be advertised.
The section doesn't provide any information on what happens when a client wants to introspect an inactive/invalid/revoked token.
Yes, this is pretty thin right now. It's the RS that introspects the token, and this section will be pulled out into a separate spec to make that more clear (). The response for both positive and negative situations is likely to be based on the OAuth introspection spec, RFC7662 URL
We should add: the AS MUST validate that the token is appropriate for the RS that presented it, and return an error otherwise.
In OAuth token introspection, the AS doesn't return an error in this stated case -- it simply says the token presented is not active, in order to prevent information leakage to a nosy RS.
NAME I don't understand your argument about a "nosy RS". The text states: As a consequence, if the AS does not recognize the signature, it can return a error stating "bad signature". If the signature is correct, the AS can provide all details to the recognized RS, as yaronf mentioned.
s/error/inactive status/.
Token Introspection: it is not clear to what depth we are defining the API: is it only the existence of the "introspect" endpoint? Or do we define a minimal set of standard attributes that need to be returned? The API would not be useful for interoperability unless we define some of the returned attributes. At the very least: "active".
The idea would be to define a core attribute set with extension points like RFC7662. This same attribute set could be used for the token model (but maybe not format?) described in


more details on encoding application group name, for
Reading the paragraph after "An application group can be named in many ways", I was left a bit confused: Why should it be encoded in the Uri-Query? That'd need coordination among all applications running on that host (for it is interfering with the query argument space that's usually left for the application to use). The common partitioning of applications inside a host is left-to-right in the URI, and that puts it in the very last spot. I think I do see what is meant by the discouragement of using the Uri-Host, but doubt that it'd be immediately obvious to general readers. How I understand Uri-Host to be impractical here is that while the request is sent to a well-defined and named URI, the response is a representation of the same URI with the individual server's IP replaced into the authority component, and if two application groups on the same CoAP group use the same path, then there may be clashes, not on the request-response layer (where the responses are bound to request for a particular host name) but in the client's cache of the responses. (And once one is at the point where application groups in the same CoAP group have a disjunct path set, one can do away with identification altogether and just address the unique path). I don't quite follow how this is not "as intended in RFC7252": It is an identifier for who is being addressed, and as such just part of the URI. (For example, if I define my lights group to be named URL and name the resource , then the host name is exactly the group name, and already needs to be put into the request unless there is known URI aliasing). See also URL on "send a Uri-Host" option, with the caveat that I'm a strong proponent of answer A2. Furthermore, the text seems to imply that virtual hosting is something a server would need to go out of its way to implement. It isn't: The Uri-Host option is critical, and a host needs to make the conscious decision to ignore that option; otherwise it's just as much part of finding the addressed resource as all the other Uri-* options are. The best practice is something I can get behind, although I suggest using no identifier on the wire (and just the disjunct set of resources) as a byte saving alternative when the administrative effort of ensuring path uniqueness can be afforded.
Thanks; we do need to improve the current text on these aspects. On Uri-Host and your example "URL" where authority component includes the application group: in this group communication example the sending client would normally DNS-resolve "URL" to a particular multicast IP address, then send the CoAP request to this multicast IP address destination, without including any Uri-Host Option. This works as long as you have a unique 1:1 association between application-group and CoAP-group. In case multiple application-groups map to a single CoAP-group, this doesn't work anymore : a client could be e.g. configured to always include the "Uri-Host" Option to indicate the hostname. Still not the preferred approach I would think. Btw I can't follow answer A2 on the CoAP-Faq, unfortunately: formulation is too complex. In some (common?) constrained use cases, the DNS name would not even be configured in the client and the client would just be configured directly with the IPv6 multicast address of the CoAP group to send it to. Then, the application-group would need to be encoded in some way still, e.g. using the Uri-Path Option. Now what our original text tried to suggest is to "misuse" a Uri-Host Option for that. So instead of using an option like: Uri-Path = group123 You would instead use an option: Uri-Host = group123 So this is not a "real" URI hostname but rather a low-level hack to let the client's CoAP stack insert by force an additional option just before sending out the CoAP request. The receiver's CoAP stack would just parse it as the ID of the application-group and not really as a URI-host. Because this gets confusing and potentially messy (proven by the present discussion !) we don't recommend it. So, trying to reiterate if one has configured Group URIs of the form coap://[mcast-ip-address]/resource on the client then by default the Uri-Host Option would get elided. The above mentioned "hack" is to put it back to encode application-group. This has the issue that the application-group name isn't present in the Group URI. if one has configured Group URIs of the form URL on the client then normally by default the authority gets resolved to some IP multicast address before sending it out, and thus while sending it the Uri-Host Option is NOT included in the CoAP encoding but elided. So the receiving server doesn't see the application-group ID because it's not encoded in the request data. (We assume here that multiple application-groups use the same CoAP-group.) Maybe we should discuss this further; what's the effort here / who ensures it / unique between what and what?
Initial text proposed in above PR! We'll merge it in by tomorrow evening, as an improvement (hopefully). What is not included yet is a statement saying that we don't recommend using the non-Group-URI methods of encoding application group name. To do so we would need to clearly state why that is not recommended; still not clear at this moment what the disadvantages of these are.


This adds an XML example. The only question is whether we need a prefix for ietf-https-notif in the example.


Issue
NAME NAME pl review re issue
Looks good
the examples of errors use a pattern of using a link in a header, and then (supposedly) using a human-readable error message. what about using RFC 7807 instead and using examples that use problem reports to indicate failure semantics in addition to the status code?
I agree. coming up in the next draft.
NAME should we close this issue if it is resolved?
NAME closing this issue. Let me know if not addressed with my latest PR.


URL Greetings! I got as far as I could with time constraints through the rest of the document. There are a few sections I'll likely go back over again as I was short on time when reviewing them, but do hope this is helpful towards improving the document. This review is from the editors revision on github that I started my review earlier int he week. Section 4.2: I find the following grouping a bit confusing: "Places that Attesting Environments can exist include Trusted Execution Environments (TEE), embedded Secure Elements (eSE), and BIOS firmware." This has an attesting environment as a processor, an element, and as compiled code. That doesn't seem right, especially when you refer to the attesting environment as a "place". Do you mean where BIOS is executed perhaps? I would expect a TEE and maybe other components where security functions are offloaded, which is in some cases to a processor other than a TEE like a GPU (I'm not making a recommendation to do that here, just stating what is happening in ecosystems that exist). The following text is a little confusing, in particular, the last sentence: "An execution environment may not, by default, be capable of claims collection for a given Target Environment. Attesting Environments are designed specifically with claims collection in mind." If the attesting environment is a place, TEEs and other processors were not necessarily designed with claims in mind. If you can help to explain an attesting environment better, I can help to phrase it more clearly to convey the intended set of points as I think there are several. Section 4.3 Consider changing from: "By definition, the Attester role takes on the duty to create Evidence." To: "By definition, the Attester role creates Evidence." The following sentence is a run on and I think some additional information will help provide clarity. I don't think it's the role that is composed of nest environments. Current: "The fact that an Attester role is composed of environments that can be nested or staged adds complexity to the architectural layout of how an Attester can be composed and therefore has to conduct the Claims collection in order to create believable attestation Evidence." How about: "An Attester may be one or more nested or staged environments, adding complexity to the architectural structure. The unifying component is the root of trust and the nested, staged, or chained attestations produced. The nested or chained structure should include claims, collected by the attester to aid in the assurance or believability of the attestation Evidence." The following sentence should be broken into two: "This example could be extended further by, say, making the kernel become another Attesting Environment for an application as another Target Environment, resulting in a third set of Claims in the Evidence pertaining to that application." Proposed: "This example could be extended further by making the kernel become another Attesting Environment for an application as another Target Environment. This results in a third set of Claims in the Evidence pertaining to that application." How about changing the following sentence from: "Among these routers, there is only one main router that connects to the Verifier. " To: "A multi-chassis router, provides a management point and is the only one that connects to the Verifier. " For the following sentence, trying to remove the use of a word twice in a row and convey the same intent. Old: "After collecting the Evidence of other Attesters, this inside Verifier verifies them using Endorsements and Appraisal Policies (obtained the same way as any other Verifier), to generate Attestation Results." Proposed: "After collecting the Evidence of other Attesters, this inside Verifier uses Endorsements and Appraisal Policies (obtained the same way as any other Verifier) in the verification process to generate Attestation Results." I may try another pass at section 4 to improve readability. Section 5, Consider breaking this into 2 sentences, from: "This section includes some reference models, but this is not intended to be a restrictive list, and other variations may exist." To: "This section includes some reference models. This is not intended to be a restrictive list, and other variations may exist." Section 5.1 Two result words together is not necessary. Change from: "The second way in which the process may fail is when the resulting Result is examined by the Relying Party, and based upon the Appraisal Policy, the result does not pass the policy. " To: "The second way in which the process may fail is when the Result is examined by the Relying Party, and based upon the Appraisal Policy, the result does not pass the policy. " I suggest making the last paragraph the second paragraph. It's easier to read than the others and provides an introduction to the model before you begin talking about how it might fail. ** I may come back to this section to provide wording suggestions. Section 5.2 I suggest moving the last paragraph to the first in this instance. It also provides a nice high-level overview. The current paragraph 1&2 flow well together, hence this order suggestion. The third paragraph is a really long way of stating that interoperability is required. Entities must be able to create, send, receive, and process data (hence the need for a standard). It's fine, but could be shorter. Section 5.3: OLD: "One variation of the background-check model is where the Relying Party and the Verifier on the same machine, and so there is no need for a protocol between the two." Proposed: "One variation of the background-check model is where the Relying Party and the Verifier are on the same machine, performing both functions together. In this case, there is no need for a protocol between the two." I think the addition is necessary or you could scratch your head wondering why no protocol is needed. If they are separate functions on the same system, you'd need some way for the relying party to access the results of the verifier. The next sentence could benefit from being made into several. OLD: "It is also worth pointing out that the choice of model is generally up to the Relying Party, and the same device may need to create Evidence for different Relying Parties and different use cases (e.g., a network infrastructure device to gain access to the network, and then a server holding confidential data to get access to that data). As such, both models may simultaneously be in use by the same device." If the server holds confidential data, why does it need to create evidence to access the data? I'm not following the second example as written, so my proposed text may not be as intended. Proposed: "It is also worth pointing out that the choice of model is generally up to the Relying Party. The same device may need to create Evidence for different Relying Parties and/or different use cases. For instance, a network infrastructure device may attest evidence to gain access to the network or a server holding confidential data may require attestations of evidence to gain access to the data. As such, both models may simultaneously be in use by the same device." Section 6: The first 3 sentences are fine, but if you wanted to reduce it, it could be one sentence. Current: "An entity in the RATS architecture includes at least one of the roles defined in this document. As a result, the entity can participate as a constituent of the RATS architecture. Additionally, an entity can aggregate more than one role into itself. " Proposed: "An entity in the RATS architecture includes at least one [or more] of the roles defined in this document. " Or more is redundant, so that really isn't necessary to convey the same point. Then the last sentence: I'd change it a little from: "In essence, an entity that combines more than one role also creates and consumes the corresponding conceptual messages as defined in this document." To: "In essence, an entity that combines more than one role may create and consume the corresponding conceptual messages as defined in this document." It might not, it could be the verifier and relying party. Section 5: Consider changing from: "That is, it might appraise the trustworthiness of an application component, or operating system component or service, under the assumption that information provided about it by the lower-layer hypervisor or firmware is true. " To: "That is, it might appraise the trustworthiness of an application component, operating system component, or service under the assumption that information provided about it by the lower-layer hypervisor or firmware is true. " Section 7: I'd say it's really a stronger level of assurance of security rather than a stronger level of security in the following: "A stronger level of security comes when information can be vouched for by hardware or by ROM code, especially if such hardware is physically resistant to hardware tampering. " Then with the following sentence, "The component that is implicitly trusted is often referred to as a Root of Trust." I think it would be worth mentioning that a hardware RoT is immutable and mutable RoTs in software are also possible, offering different levels for an assurance of trust/security. Section 9. Since ROLIE [RFC8322] has been added to SCAP2.0, it would be good to list that as an option since a lot of time and effort went into how to secure the exchange of formatted data for that protocol. Section 11. Privacy This is a good start. Remote attestation also provides a way to profile systems as well as the user behind that system. If attestation results go higher in the stack to include containers and applications, it could reveal even more about a system or user. The scope of access needs to be emphasized, including the administrators access to data (or restrictions). If there is a way to make inferences about attestations from their processing, that should be noted as well. Section 12: This will need to state an explicit requirement for transport encryption. In the introductory paragraph, the text is as follows: "Any solution that conveys information used for security purposes, whether such information is in the form of Evidence, Attestation Results, Endorsements, or Appraisal Policy, needs to support end-to-end integrity protection and replay attack prevention, and often also needs to support additional security protections. For example, additional means of authentication, confidentiality, integrity, replay, denial of service and privacy protection are needed in many use cases. " Proposed: "Any solution that conveys information used for security purposes, whether such information is in the form of Evidence, Attestation Results, Endorsements, or Appraisal Policy must support the security properties of confidentiality, integrity, and availability. A conveyance protocol includes the typical transport security considerations: o end-to-end encryption, o end-to-end integrity protection, o replay attack prevention, o denial of service protection, o authentication, o authorization, o fine grained access controls, and o logging in line with current threat models and zero trust architectures." Best regards, Kathleen


This is to partially
In section 4.2 there is a list of "places an attesting environment can exist" that is limited. The text should be softened to say the list is only examples and there is no formal limitation or requirement on the security of an Attester. There should probably be a detailed description of Attester security in the document, but it should be in Security Considerations. This seems like a glaring omission from Security Considerations.
The considerations weren't the extent of the issue. There is still text in 4.2 that I think needs changing.


Change "Evidence Appraisal Policy" -> "Appraisal Policy for Evidence" Fixes editorial nit reported to me by Tolga Acar Signed-off-by: Dave Thaler
looks good.


Also, my assumption is that all messages, configs and such go over one of the arrows in the figure. There are no back channels for things that are vital to or a major part of attestation. Seems like it would be a poor document if the major parts of attestation are not explicitly carried in the flows depicted.


Merged from draft-thaler-rats-URL Signed-off-by: Dave Thaler
PR and PR merged text that I had, and continue to have, problems with. A summary of the problems follows: 1) It includes events (CC, RP) that are not used in any checks in the text. I had pointed this out before when the PR was generated, but the PR was merged without addressing this comment. 2) The section about using timestamps with synchronized clocks was removed and replaced with a section that talks about a different mechanism (handles) that is not in any RFC or WG document. I believe that such replacement is inappropriate. If the WG adopts a document that talks about a handle distribution mechanism, then a section can be added. Or if there is a standard from another org that can be referenced then it's fine to add one in that case too. But I think it should not replace the section discussing the well known technique of synchronized clocks (e.g., using secure NTP, or PTP (IEEE 1588-2002) or whatever other standard mechanism). 3) time(HD) is problematic as phrased since all the other events are times as seen by a single entity, whereas time(HD) does not clearly say whose perspective (i.e., whose clock) it is from... is it the distributor's? Text is unclear. 4) It talks about nonces in a timestamp section, which I think causes confusion since there's already a separately section about nonces and this section is labeled to be scoped to timestamps. Addressing might address this naturally, if it uses a different section title. 5) There are some editorial typos, such as capital "The" in the middle of a sentence, etc. 6) I have no idea what "delta(time(HD),time(EG))distribution-interval" is supposed to mean. Normally I would expect an equality for any condition to be evaluated, but I have no idea what this check is. 7) time(HD) and time(EG) are according to different clocks (if my guess about point 3 above is right) and so the delta is not directly comparable. I'm not sure how point 6 accounts for this. 8) The phrase "A nonce not predictable to an Attester (recentness & uniqueness) is sent to an Attester" has "(recentness & uniqueness)" which doesn't read well (sounds like bad grammar) to me, and is not explained.
Hopefully PR now addresses this issue.
PR reverts the text, leaving the work in progress in PR
fixed by .


This attempts to address the remaining feedback on PR on issues that were not fixed before it was merged. Signed-off-by: Dave Thaler
The simple word choice / grammar changes seem OK. I still don't understand the difference between a "claims collector" and a "verifier" (in the case where Attester B, C,... are signing evidence) and a "target environment" (in the case where Attester B, C, ... are not signing evidence). It seems this term isn't actually necessary. The case where Composite Attester is relying Evidence from "sub" attesters, the composite attester (aka claims collector) is relying Evidence not "collecting claims" in the sense that an attester "collects claims about a target environment". I think it is confusing to overload this terminology to also mean "rely Evidence".


adding the Reference Values to fix issue 185
` And the Verifier uses the Reference Values
I agree that Reference Values should be mentioned here.