<div dir="ltr"><div dir="ltr"><div class="gmail_default" style="font-size:small"><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, Aug 12, 2024 at 8:25 AM Peter Gutmann <<a href="mailto:pgut001@cs.auckland.ac.nz">pgut001@cs.auckland.ac.nz</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Phillip Hallam-Baker <<a href="mailto:phill@hallambaker.com" target="_blank">phill@hallambaker.com</a>> writes:<br>
<br>
>There is a tendency for people to design systems that fail to meet essential<br>
>requirements in the mistaken belief this will reduce complexity.<br>
<br>
There's also a tendency for protocol designers / standards committees to<br>
design mechanisms to try and address every imaginary issue everyone on the<br>
standards committee could ever dream up, including a great many that don't<br>
actually exist.  </blockquote><div><br></div><div><div class="gmail_default" style="font-size:small">The SAML design team had a requirements group that spent a lot of time voting on which use cases to make into requirements, they spent a lot of time on it.</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">I did the design and made sure that it was capable of meeting every one of the use cases regardless of whether it was included or not.</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">My designs are not extensive, they are actually much more sparse than most people's. I find that having a lot of requirements actually helps get to the heart of the matter and can lead to a leaner design. The Mesh is a lot less extensive than PKIX but it does vastly more.</div><br></div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">IPsec and anything PKIX did are extreme examples of this,<br>
leading to designs that were severely compromised because, apart from their<br>
unmanageable complexity, they ended up with the flexibility of rubber swords<br>
and styrofoam screwdrivers, losing a lot of utility in exchange for<br>
theoretical properties that didn't matter.<br></blockquote><div><br></div><div><div class="gmail_default" style="font-size:small">PKIX is complex because many things that are the same are different. That is what I tried to fix in TAXI which became the core of SAML. Certificates, CRLs and OCSP tokens are all examples of assertions and should be processed in similar ways but PKIX forces them to be very different. OCSP and SCVP could have been one protocol, they are two because of politics and people insisting on 'simplicity'.<br><br>The complexity in SAML came from using XML as a base and we did that because, well ASN.1. ASN.1 was a very good idea that got ruined because of one half baked proposal, DER encoding which is utterly unnecessary and a bad way to achieve the intended outcome. Canonicalization is just as bad in XML.</div></div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">My cure for complexity is to force people to learn formal methods and write some proofs. I don't think the proofs have much value in ensuring bug free systems, too much opportunity for error in the requirements, but the pedagogical exercise sure does teach you to be lean and mean in design.</div><div class="gmail_default" style="font-size:small"><br></div></div></div>