cryptonector

> The MySQL purchase wasn't a lot of money

IIRC it was $1bn or so, and Sun only had like $6bn in the bank. It was a desperate play when Sun needed help.

Thanks!

1. Disagree. I think ASN.1 is not horribly complex, but I think BER/DER (which, yes, are in the ASN.1 family) and XML are.

2. Yes, unless you need much more structure, then you have to think about ASN.1, XDR, PB, JSON, etc.

3. XDR is a perfectly reasonable basis for an ASN.1 encoding rules family. In fact, PER/OER resemble XDR in many ways. XDR is only simple because a) it's way simpler than the supposedly-simple tag-length-value encodings that ASN.1 came with originally, and b) Sun actually built a solid codegen tool (rpcgen(1)) for it. Never underestimate the value of having excellent tooling as a way of simplifying things :)

4. Alg. agility needs to be tied to the signing keys, not allowed to vary in the headers. Apart from that, you do need alg. agility, so its complexity can be minimized, but not made to disappear.

5. No, because TLS only establishes a channel between two entities, but here we have three or more entities: the two end-points of a TLS connection + all the trusted third parties. The trusted third parties need to communicate to entities they have no direct connection/channel to, and having those pairs of peers initiate connections to get those items is actually quite complex for reasons.

5. It really is the case that signed tokens are extremely handy and simpler than not having them -- it's just that getting signed tokens right has proved tricky in part due to advances in cryptanalysis exposing design mistakes no one knew they were making decades ago.

> At the time this “markup” concept got everyone all excited. But it ended up not being the way to solve problems like what you seem to describe, which don’t have the arbitrary document aspect at all.

But it does have the "arbitrary document aspect" when you add the desire for site-local claims.

> JSON solves it by being a data structure first and last.

I'd say that JSON solves it by being remarkably simpler than XML and by having become ubiquitous.

Your points about HTML... keep in mind that HTML is for humans, but what we're talking about here is for programs.

> Even ones that have been forcibly shut down like PKIX just keep going in other forms (LAMPS).

Was the IETF PKIX WG "forcibly" shut down, or it merely concluded, with new WGs popping up to do similar things when needs arose?

It sure sounds like it should be like this, but when you actually try you end up with not this. TLS is huge! Yes, but SSL 2.0 was smaller, and buggy as hell, so it had to evolve, and after 30+ years it became the monster that it is today.

Of course, SSL 2.0 did reference x.509, so hey, SSL 2.0 should have invented its own PKI. Except that Netscape might have come up with something terrible that worked in 1993 in labs but didn't scale to the web, or just full of security problems, or...

What you say sounds nice and right right up until you actually look at the details of what actually happened in real life, and how things actually evolve when they have little standards involvement.

The problem with this is the assumption that there's a simpler way to do all of this, and if only we could stop looking for large and complex solutions we could just land on the simple ones.

I listed a number of solutions, all built by different people, at different times, in different orgs, and some of those solutions (OAuth, SASL) being much more organic in how they evolved, and yet all are ultimately large and complex.

I think that hints at the problem space being... large and complex and requiring large and complex solutions.

What we _can_ do is avoid adding complexity unnecessarily, but what looks like a simplification today (e.g., picking the best current encoding system) might look like a terrible mistake in twenty years.

How can you talk about what you'll do w/o talking about cost, cost of opportunity, impact of motivating incidents, etc.??

Maybe if the changes you're doing are small and cheap, sure. But if they are invasive and costly...

Can't do that w/o talking about the cost of what you're going to do, and you can't do that w/o talking about the impact of the incident.

So you can elide some details when you talk to leadership, investors, and regulators, but you can't elide everything.

The post-mortem process can cover all of these things:

  - what happened
  - impact
  - root causes
  - what will be changed (commitments)

You can't really talk about what to change w/o talking about root causes, and you can't talk about that without talking about what happened. You also can't consider the costs of commitments to be made w/o discussing actual and potential impact because resources are limited and the cost of opportunity is real.

It's fine for executives to get only a summary of impact + commitments. But the whole post-mortem process has to be followed, and some people have to be aware of all the details.

> IP looked at that and said: fuck that noise - we send packets, if they don't arrive we send them again, job done.

The difference between IP and the OSI stack is the standards development organizations: IP was specified in a fairly unofficial way (RFCs) by academics via email in what eventually evolved into the IETF, while OSI was specified by ISO. ISO is much more difficult to work in than the IETF. But there are still specifications behind IP. It's not 'just send a packet and see what happens'.

> Protocol complexity is where bugs hide, including vulnerabilities.

You can't make that go away. TCP/IP is not a non-protocol. The best you can do is minimize that complexity.

Eh, many of us do what I think you mean by "IdP-initiated flow"s with JWT. It's not OAuth exactly, but it's a thing.

GP was probably thinking of Azure AD / Entra as the "SSO tax".

XML is as complex as DER, and since there is a way to use XML in ASN.1 -called XER, or XML Encoding Rules-, XML is also as complex as ASN.1, and when you add FastInfoSet, even more still.

XML is deceptively simple-seeming, but it's not simple at all. JSON isn't actually trivial, mind you, but by comparison to XML, ASN.1/DER, etc, JSON is trivial.

The only reason to prefer ASN.1/DER here is that the likelihood of very badly broken libraries that fail to validate signatures becomes comparable to the same for x.509/PKIX certificates: fairly low due to the need for a whole ASN.1/DER ecosystem. It's the must-be-this-tall-to-ride effect.

To be fair to OASIS, in 2002 XML was textual and simple-seeming. It was the obvious choice. It must have seemed brilliant. They didn't know it would turn out badly.

Even with JSON you need solid decoders, excellent libraries, and you'll still want a JSON Schema and tooling.

> When authentication is just not a document or data stream that needs marked-up.

You've lost me here due to my experience with Kerberos and OAuth (JWTs specifically), though I mean JSON, not XML, so if by "marked-up" you meant "XML bad", well, that I would agree with.

Kerberos has something of a "markup" in that it has typed holes for carrying all sorts of useful metadata about the subject, especially what it calls 'authorization-data', but a) it's a real pain to get KDCs to include useful site-local things, b) it's remarkably harder to get Kerberized services to be able to get at that authorization data! (b) is surprising. I worked that problem for a bit -- I've done a lot of work on Kerberos, but APIs involve lots of work, not just C but Java, Python, all the things, so the last mile requires a ton of work to bridge, and then you end up with a pile of {some kind of data type ID, data encoded accordingly} that the application has to decode, so you have to:

  - specify syntax/encoding for your site-local authz data
  - write KDC-side code (preferably just plugins)
  - implement RFC 6680
  - including language bindings for various langs
  - implement authz data decoders to use in apps
  - use those decoders in those apps

It's never ending.

Now compare to JSON: when you're done validating the signature or MAC, or decrypting the token, you now have a JSON text for the claims. Injecting site-local claims in your token issuer is trivial now. Using them in your applications is even more trivial (provided you have a JWT validator, otherwise it's too trivial if you forget to validate the signature!).

JWT got this right. Kerberos got it wrong.

In defense of Kerberos, it goes back to the mid to late 80s depending on which version you want to start counting at, and GSS-API goes back to the early- to mid-90s. So we're talking 30+ to 40+ years, all of it predating JSON and XML.

But today, in 2026, Kerberos is indefensible. Kerberos is still necessary, yes, because there are specs for and support in so many useful application protocols and implementations thereof, and because of Active Directory.

The lesson I draw from this is that GSS-API in the mid-00s needed to have grown a version of `gss_accept_sec_context()` that outputs a JSON text. I wish I could go back in time and build that.

So, yes, authentication context metadata, including metadata useful for authorization, can and should be represented in a "markup" language, specifically JSON.

It is truly surprising how large the specs for each of these ecosystems are: PKI, Kerberos, TLS, OAuth, SAML, etc. They are gargantuan, especially when you include essential dependencies like DER codecs and ASN.1 compilers (PKI, Kerberos) or XML (SAML).

Re: canonicalization: design things to not need it, so don't bother with it. Relying parties need to received the blob of whatever (XML, JSON, DER, PB -- don't care or decode till the signature is validated), validate the signature over the exact blob you've received, then decode. This means you need the signing key's algorithm to be identifiable from its issuer and key ID metadata / URI. The header you'll need should only have the information you need to find (dereference) the issuer's signing public key. You'll never need to canonicalize anything this way.

Ideally you should use encrypted tokens so you're forced to do authenticated decryption before getting to the claims portion, but no one has bothered to build that in a way that scales. I did build something like this for Kerberos in Heimdal (https://github.com/heimdal/heimdal), but we need it for encrypted JWTs too: derive symmetric encryption keys from {current epoch, base key, audience/relying party name}, and let the relying party download those keys (by authenticating) much the way they do for signed JWTs. But switching from signed JWTs to encrypted ones is a pain as it requires that the issuer know if the relying party can handle it.

Sun's engineering culture -and engineers- was the only reason it survived as long as it did. It and they were amazing.

Right. Watermarks are the same in every copy -- they mark a copyright or whatever. Whereas these things are personalized, therefore they do track you as a source of sharing.

Boss: full branch code coverage testing is the best way, make it so!

Boss: whoa, that's a lot more testing than we'd like to pay for, can you cut it down?

Building an AD-compatible service is not that easy, and it was not easy circa 2006, because there was a lot to reverse engineer. Sure, Sun had access to its own directory service (Sun DS), MIT Kerberos, BIND, OpenLDAP, NSS, and Samba, so it had a lot of the pieces, but there was a lot of work to be done putting everything together.

I pushed XAD internally. But I didn't have the pull needed.

Sun not acquiring XAD was a big mistake.

CPU design is expensive. Intel was ahead of the competition and wasn't fabbing, so Sun was a generation behind. That sort of thing.

Note that today things are quite different, and Apple can do what Sun wanted to do, but do it well. Market conditions are very different, and Apple, of course is the 800lb gorilla that Sun couldn't quite get to be. It's kinda funny: Apple and Sun weren't all that different, and Sun then and Apple now even more so. Apple just wasn't into servers, and Sun just wasn't into consumer hardware, but both wanted to vertically integrate hardware and software. Apple has a walled garden, Sun didn't. I do think these differences are relevant to why Sun failed, but the leadership differences count for a lot too: no one would compare Steve Jobs to Jonathan Schwartz, nor even to Scott McNealy -- it's just night and day. Now the differences in what Sun and Apple sought to do also evince differences in leadership.

Nor unums!!

That's when I went to work for them. As far as forming my career went, it was a great move. And since it was Solaris engineering I went to, it was quite fun. But yeah, Sun was done -- it just didn't know it, and it spent almost a decade making mistake after mistake. I do think Sun could have been much more successful if senior management had made better decisions, in particular if they'd committed to x86_64 as the future.

> Why do you think ZFS on MacOS would have helped in any significant way?

It would have bought Sun mind-share. In that time frame Sun was trying really hard to re-acquire mind-share it had lost to Linux due to the non-deal with Google, the brief cancellation of Solaris x86, etc. OpenSolaris was an attempt to rebuild mind-share. Was rebuilding mind-share enough? No, no way, but it was a start.

It could have led to Apple acquiring Sun, say.

> AFAIK, and I may be wrong, but Apple doesn't have a history relying on OEMs for their software, especially something as critical as operating systems. Am I wrong? Was it different back then?

Apple did the work of integrating ZFS into OS X. They believed in it. Steve Jobs wanted indemnification in light of the NetApp lawsuit. Jonathan wouldn't agree to it. Giving it could have been a betting-the-company event, but Sun needed that sort of thing.

> UltraSPARC came out in 1995, and Athlon 64 in 2003. I'm confused on how it could be late?

Ah, sorry, I was referring to the CMT architecture.

This. Sun behaved like it had vendor lock-in. Who wants a vendor like that?!

Sun's various divisions all cared very much about their respective vendor lock-in, so they didn't innovate fast enough. The divisions that didn't have that innovated. On the way downward Sun cannibalized itself (think Sun PS getting closed).

That's the whole gist.

I've written several times here about all the mistakes that Sun made during the 00s that doomed it. Among the many mistakes it made are:

- Cancelling -if briefly- Solaris on x86 in 2002. This killed Solaris in the minds of many who didn't want to be locked into Sun for SPARC.

- Failing to make a deal with Google in 2002. Apparently Sun insisted on knowing how many servers Google had, something that Google considered a high-value secret, so Sun failed to make a deal with Google, so Google ended up using Linux and contributing to Linux. This was a tremendous mind-share disaster -- it's hard to overestimate the damage done by this.

- Closing Sun PS (professional services). Bad bad move, possibly the worst of them.

- Not giving up on J2ME earlier -- it's not the sort of thing that could last forever, and Steve Jobs killed it with the iPhone. This was a case of vendor lock-in clouding Sun's decision making.

- Failure to recognize that Sun needed to become a systems company, not a CPU company.

- Failure to respond to Active Directory. This was yet another case of vendor lock-in clouding Sun's decision making: the Sun DS product team was milking their existing customers more than they wanted to go after more business with a sustainable strategy.

- UltraSPARC was more than a decade too late to make up for SPARC falling way behind x86_64. Sun needed to give up on SPARC, but again, vendor lock-in sounds sweet but turns out to be poison.

- Failure to make a deal with Apple for it to use ZFS in OS X.

- The MySQL purchase. WTF, this was horrible and stupid. The only interesting effect of this was to make Sun a target of acquisition for Oracle. But of course, it turns out that Oracle -a company built on building mind-share- had become too blinded by vendor lock-in just like Sun, so...

There were numerous other mistakes along the way. These are the most salient, for me anyway.

What's shocking is how long it took Sun to fail under those circumstances!

Also shocking is how much amazing stuff came out of Solaris engineering and the systems division!