> Following this line of reasoning, I am skeptical an IANA registry will help impose the safeguards you are looking for. Misuse within the specified context can still occur.
An RSC that is only ever inspected by a human probably won't benefit from an IANA registry - the problem here arises from automated machine to machine communication where a relying party can't make informed human decisions. Perhaps we need a RSC for attesting to files that a human will read, and a new format for attesting to claims from an IANA registry that a machine will read. ------------------------------ Any statements contained in this email are personal to the author and are not necessarily the statements of the company unless specifically stated. AS207960 Cyfyngedig, having a registered office at 13 Pen-y-lan Terrace, Caerdydd, Cymru, CF23 9EU, trading as Glauca Digital, is a company registered in Wales under № 12417574 <https://find-and-update.company-information.service.gov.uk/company/12417574>, LEI 875500FXNCJPAPF3PD10. ICO register №: ZA782876 <https://ico.org.uk/ESDWebPages/Entry/ZA782876>. UK VAT №: GB378323867. EU VAT №: EU372013983. Turkish VAT №: 0861333524. South Korean VAT №: 522-80-03080. AS207960 Ewrop OÜ, having a registered office at Lääne-Viru maakond, Tapa vald, Porkuni küla, Lossi tn 1, 46001, trading as Glauca Digital, is a company registered in Estonia under № 16755226. Estonian VAT №: EE102625532. Glauca Digital and the Glauca logo are registered trademarks in the UK, under № UK00003718474 and № UK00003718468, respectively. On Wed, 23 Oct 2024 at 16:10, Job Snijders <[email protected]> wrote: > On Wed, Oct 23, 2024 at 03:30:55PM +0200, Q Misell wrote: > > > The RSC format has been specified in RFC 9323 > > > > I am referring to the contents of the RSC, not the RSC encoding itself. > > The content of the RSC is an optional character-restricted label and an > OCTET STRING of type "Digest", which MUST be SHA-256. > > > > Whether the payload is RFC9323-compliant or RFC9323bis-compliant, > > > the moment system B 'blindly' signs over a set of bytes they ought > > > not to sign over from an organisational scoping perspective, B is > > > dead in the water anyway. > > > > But this is precisely what RSCs currently allow. Without an IANA > > well-known registry of what different files in an RSC mean, > > Organisation B's CA is powerless to restrict what it signs. > > Following this line of reasoning, I am skeptical an IANA registry will > help impose the safeguards you are looking for. Misuse within the > specified context can still occur. > > > Solving an organisational problem (RIRs are unwilling to cooperate) by > > introducing cryptography problems is, as the kids say: This Ain't It, > > Chief. > > I think it is helpful to be mindful of what various stakeholders might > or might not be willing to implement, otherwise we continue to be stuck > using IRR "remarks:" fields. As the kids say, perfect is the enemy of > good. To be clear, we are not discussing a cryptanalytic problem, right? > > Kind regards, > > Job >
_______________________________________________ GROW mailing list -- [email protected] To unsubscribe send an email to [email protected]
