> >> To relay this validation (let’s call it a voucher), big brother could >> create its own certificate out of (or for!) the certificate in question. > > Creating a "voucher" *for* another cert? So, you send *both* the original > cert that is mostly useless (because the recipient cannot validate it), > *plus* your validation record?
The recipient may need to forward that certificate to third parties, which do the traditional validation. > Why not create a new cert, including what's relevant from the original cert > being validated? Well, that all depends on what a “certificate” is for you. The industry uses the term as an abbreviation for “RFC5280 certificate” (calling them X.509 certificates all the while). And many in the industry believe that “you need certificates to be secure”, when in reality they mean specific aspects of those. The voucher can be situated (i.e. valid in a specific context — obvious when that context is a TLS connection), which an “X.509 certificate” can’t. >> But it may be more lightweight to protect the voucher as data in an >> authenticated connection (say, TLS), or as part of an authenticated object >> (say, COSE). > > How is this different from "big brother" generating a new (light-weight, if > needed) certificate, based on its own judgment and what's in the "old" > certificate? See above. But yes, many of the vouchers will be certificates in a wider sense, and having the mechanics to create them is part of what makes these vouchers interesting. But there is an interesting twist here: X.509 certificates say “A said that X’s key is K”. If you like A, that makes the certificate valid. A voucher by B says “B believes that A saying that X’s key is K is valid”. So the identity of A is visible. (Note that this is different from “B believes that anything that A is saying is valid”, which is the essence of Web PKI.) A “new certificate” would be limited to “B said that X’s key is K”, which is not something B might want to say. Grüße, Carsten _______________________________________________ COSE mailing list [email protected] https://www.ietf.org/mailman/listinfo/cose
