may I ask why the approach on cert transparency was changed and what happened to the original idea?
before you had a (in my opinoin very intresting system you hosted every cert directly and you had a system of serial numbers with a number for the “location” an auto-increasing number and a random part which gives everyone the ability to quickly look up certs and I wonder why it was dropped
Certificate Transparency was forced by google/chrome.
Serial number have the problem that new certs are guessable,
Transparency have the charme that you can check if anyone
have issued an cert for your domain on an central place.
@tlussnig, just to clarify, Google and the Chrome project did not force us to adopt Certificate Transparency. They are only requiring it for EV certs, which we don’t issue. We chose to adopt it ourselves because we think it’s a good idea and we want to get caught immediately if we ever issue an incorrect certificate for any reason.
@schoen with force i did not mean that they force any ca to use it.
What i was meaning that they are one of the key party that stand behind the idea and the development.
They even require it for getting an good security rating in chrome for your side.
I implemented CT and OCSP-Stappling in java for my side. And now also CHACHA20_POLY1305.
I didnt ask why CT was made. I ask why the concet HOW CT was done was changed.
also @tlussnig zje serial numbers werent easily guessable since a part of the number was always random.
let’s look at the hello world LE cert which also was the example then.
the serial is 01:00:00:00:00:00:00:15:4F:F8:F2:23:AE:7F:FA:BC
let’s explain it from behind, makes more sense this way.
the complete second half of the number (4f until BC) is randomly set proably so you cant guess the serial number.
then the 00:00:00:00:00:00:15 is just an increasing number which means the hello world is the 15(hex)th so the 21st cert that was issued, well not exactly because:
so we had 01 as the “location identifier” which probably means they use multiple servers to generate the certs and so the the increasing numbers dont overlap on multiple “locations” because they are made to generate certs simoultanerously and get out of sync we have this.
so every cert could be downloaded somewhere on LE using the first half of the serial number and we had it.
the best thing of this approach is that since the CT is technically on-premises you dont get a problem with CT when something happens to their server or the connection to them.
now the main question is WHY did you switch to a 3rd partx CT provider and completely randomized the serial numbers?
the serial number is not sequential. just a part of it.
also the random part is 8 bytes (64 bits) long and it shouldnt be hard to get an entropy this long. (attack a mic to the server and try to get it hooked into the entropy and then you have a near perfect random number generator (maybe)
This is from the pure definition point correct. But from another perspective you can say you have an sequential number plus an 64bit random value. With you argument i can build <M/W> as anonymized id. And say you
have an random password. Even if it contain gender and birthday is contained it is an random number. And per definition an random number mean there is no usable part in it.
I think the discussion why some part that should not have an sequential meaning only serial number can let you think.
is not really important.
The incrementing serial prefix was originally a solution to allow people to quickly enumerate all the certificates we issued, as you’ve mentioned @My1. Unfortunately this design decision added a number of points of failure in Boulder that were really unnecessary.
Instead of attempting to maintain this solution with a somewhat flaky fix we chose to instead submit all issued certificates to CT logs and use a (almost) fully random serial. This adds a slight hurdle to people who may want to find all our certs but it is one of the main functions of CT and removes a set of problems we bound ourselves to with the incremental approach that have greatly simplified our design.
I dont know who renamed the topic, but (for clarification) it wasnt only about the serial numbers but also about why it was stopped hosting the certs directly at LE but using a cert provider.
as I said before @roland already answered the question.
Yes that’s a feature of DIscourse (the forum software used here), because it allows the self-managment of communities like this. (which is IMHO a very nice idea)
In this example it allows users of a specific rank to edit all titles of any topic.
well they obviously still issue the certs (that isnt the issue) but with the previous CT model they also hosted all certs where you had them under letsencrypt.org / some-path /
I was just wondering why it was changed completely and it makes sense.
"host" is the wrong word. They save a copy of them in the CT logs or better: they "publish it in the CT logs".
I know no CA which does or did publish it like this. And as this is not standardized and has no sense I am aware of I'd say this would be quite useless.
This is no change - it's an addition. To be more exact: An additionally security feature.
To read more about "why it makes sense" (how it works) have a look at the wikipedia article: