What is the trust relationship for the x5u parameter? #31
Comments
|
Agree that this need to be very explicit. Currently I don't think it is not clear at all. This risks ending up in completely weak implementaions. There is a lot of cases where people believe that just because they have HTTPS everything is secure and trusted. In general, I don't really se why x5u needs to be handled differently from x5t, x5chain, and x5bag. For x5u, x5bag, x5chain the information is untrusted, the receiver has to verify the certificate chain and any updates of the trust anchors requires out of band confirmation. On on-path attacker can modify the information in x5t, x5bag, x5chain like the HTTP server can modify x5u. I don't see why the trusted header and TLS are needed in this case. HTTP is just anohter way to get untrusted certificate information.... If x5u is intended to be used instead of chain validation or intended to distibute new root certs, this is not well described. In both these cases the most important trust relation is between the reciever of the x5u parameter and the HTTPS sever. The reciever need to have as much trust in the HTTPS server as it has in its trust anchors or even in the entity its providing trust anchors. I think the use cases and requirements for each use case need to be clearly defined. Right now I don't even understand what the use cases for x5u are.
|
|
I agree with you. x5u is just a way to do x5* out of band. |
|
Agreed.My preference would be for x5u (and c5u) to not have any special trust characteristics. It seems much cleaner and simpler that way. We could do that in x509-cose and in cbor-cert and I think it would be good. However, JWS already has a text (that I find confusing) about some special trust. |
…se-wg#29 cose-wg#30 cose-wg#31 cose-wg#33 The PR aims to aims to address issues cose-wg#29 cose-wg#30 cose-wg#31 cose-wg#33 based on the dicussion on the list and during the last interim. The solution is to use x5t together with the other parameters as suggested by Russ: - Added to x5bag, x5chain, and x5u that integrity protection in COSE is requiured unless it is known that the CA did proof-of-possession. - Added that integrity protection can be achieved by combining x5t with x5bag, x5chain, or x5u. - Added explanation that sending x5bag or x5cahing in unprotected allows an intermediary to remove or add certificates. - Added clarification that x5t refer to an end-entity certificate. - Added media type application/cbor for a COSE_X509 chain. - Added that when the end-entity certificate is intergrity protected by COSE, URI protection is not needed. - Security consideration on why integrity protection of the end-entity certificate is required is there was no proof-of-possession. - Security consideration on identity protection. I think this addresses all the related use case and security issues. - If the requirement are followed, it is secure. - No changes required to existing secure deployments. - It is still possible to send x5bag and x5chain in uprotected. - No extra overhead is required when used in EDHOC. - When used in EDHOC, plain unprotected CoAP can be used. I tried to make the changnes so that no existing secure deployment need to change their implementation. Could otherwise discussed if integrity protection should be a MUST, but that would change existing implementaions (which is they do proof-of-possession are already secure).
…#30 #31 #33 The PR aims to aims to address issues #29 #30 #31 #33 based on the dicussion on the list and during the last interim. The solution is to use x5t together with the other parameters as suggested by Russ: - Added to x5bag, x5chain, and x5u that integrity protection in COSE is requiured unless it is known that the CA did proof-of-possession. - Added that integrity protection can be achieved by combining x5t with x5bag, x5chain, or x5u. - Added explanation that sending x5bag or x5cahing in unprotected allows an intermediary to remove or add certificates. - Added clarification that x5t refer to an end-entity certificate. - Added media type application/cbor for a COSE_X509 chain. - Added that when the end-entity certificate is intergrity protected by COSE, URI protection is not needed. - Security consideration on why integrity protection of the end-entity certificate is required is there was no proof-of-possession. - Security consideration on identity protection. I think this addresses all the related use case and security issues. - If the requirement are followed, it is secure. - No changes required to existing secure deployments. - It is still possible to send x5bag and x5chain in uprotected. - No extra overhead is required when used in EDHOC. - When used in EDHOC, plain unprotected CoAP can be used. I tried to make the changnes so that no existing secure deployment need to change their implementation. Could otherwise discussed if integrity protection should be a MUST, but that would change existing implementaions (which is they do proof-of-possession are already secure). - Aligning x5t suggestion with the other headers. - incorpores editorial after comment by Goran - incorpores edtiorial after comment by Goran - small rearrangement in x5u
|
Hi, |
The x5u text refers to a "trust relationship" between the signer and the host of the URI. What is that relationship? Since trust relationships are of critical importance in what we're doing here, I would expect it to be spelled out.
It seems like there's two roots of trust involved here. One for the chain that is used to verify the COSE and the other that is used to verify the TLS connection.
I think the following sentence refers to the root of trust for the TLS connection, but can be confused with the root of trust for the COSE chain.
Also, maybe there should be a protected header that names the root of trust for the TLS connection? If there isn't the signer can't quite control the trust relationship as they don't know what roots the receiver has been configured with.
I also think it is important to point out that the certs received this way must still be validated against the root used by the COSE chain. This is not the fetching of already-validate certificates.
JWS seems to have similar issues.
The text was updated successfully, but these errors were encountered: