XSF Discussion - 2020-11-06

Is wiki.xmpp.org dreadfully slow for anyone but me?

Uhoh.

https://igniterealtime.org:443/httpfileupload/jiYCE27cESUD4UHmnYmyBSCeJVg/image.png

same here

MattJ: are you in a position to look at it?

No :D

Stirring porridge with one hand, holding a baby in the other, not near my laptop

How are you typing ! ?

"Ok, Google!"

Sorry, just found the gap between being in a position to fix the wiki and my actual situation comically high

MattJ: just don't drop the baby, right?

or the porridge

my priority would be baby > laptop > smartphone > porridge

We will take your suggestion under advisement.

MattJ, at least the house isn’t on fire :D

everything is fine.

(totally made up combination of events which most definitely did not happen to anyone I know and they most definitely did not prioritize feeding the porridge over getting out of the house. luckily, and most definitely, the fire was small and nobody was harmed in this definitely made up situation)

The wiki might be a bit more responsive now

As far as I can tell it's being aggressively crawled by something

Going into every "What links here" and diff pages, etc.

So it's still slow

Do you also have an update on the porridge/baby situation?

The porridge was mostly successfully consumed, even if the messy high chair, table and floor didn't look like it when my wife came in. And now baby duty is successfully handed over. I'm ready to take on the easier part of my day now :)

What happens if XEP-A is having a namespace bump, and XEP-B is depending on XEP-A? Is XEP-B required to bump its namespace as well?

Same rules apply. We bump namespaces if not doing so would otherwise cause aa interoperability problem.

vanitasvitae, terror ensues

see MIX

where parts still use an old pam: namespace, which is confusing for implementations

as they now have to support both namespaces for the specs-as-written

Okay, thanks

vanitasvitae, ideally XEP-B would not simply depend on XEP-A but on (XEP-A, xep-a-namespace)

Thanks Matt. Good to know that the wiki isn't broken.

flow: got it. In that case a bump would not be required for XEP-B? Only if XEP-B would be uodated to use XEP-A:++?

vanitasvitae, see what I wrote. that’s a PITA for developers.

there’s not much of a sane way out of that with the way we currently bump namespaces

Namespaces should only be bumped if you can't interoperate under the existing namespace - almost always you can. We have bumped too often, I have little doubt.

And in most cases you can accomplish the change with a new feature element

Yes.

There are no circumstances where it would be allowable to use an intermediate as a trust anchor (meaning, not validating the issuer of the intermadiate) when validating a certificate chain, correct?

I think in DANE that's a thing

You could also cache known indermediates and so allow people to have broken setups.

Guus: if the intermediate is in your trusted root set, it should be safe to abort further validation

My concern is that any revocation checks are thus bypassed.

which arguably is acceptable if the intermediate has been willingly placed in a 'trusted' root set, I suppose...

well, CRLs don't work anyway.

Guus, the intermediate could also have its own CRL, right?

thinking about the Let’s Encrypt transition period where they had their "root" signed by another well-known CA to be trusted right away on all systems

jonas’ I'm thinking that the CRL as advocated by the intermediate is primarily used to verify certificates issued by it. Should one trust an intermediate-provided CRL to include the intermediate itself, if, for some reason, it should not be trusted anymore? That does not feel particularly safe.

Guus, are you working on a crypto library?

As in: an intermediate that goes malicious won't ever include itself in the CRL.

Zash no, I want to understand how these details are supposed to work.

It seems reasonable that the revocation methods listed in a CA cert applies to the certs it issues

Guus, ah, I see; well, what Guus said then; if you have something in your trust store, you don’t check the CRL for it. It’s in your trust store after all.

s/Guus said/Ge0rG said/

I'm still not sure if that's correct. The entire reason for having CRL's is to be able to revoke an earlier decision to trust something.

What do you do when you have an intermediate as well as its issuer in your truststore, and the issuer adds the intermediate to its CRL?

Accept it, since it's in your truststore (which there should not be a need for, so I can understand the argument)

I suppose if you kept intermediates, you'd want to treat it as a RLU cache or somesuch, and then peridically check it against CRLs?

Isn't OCSP stamping(?) the thing now however? I.e. the server checks its own certificate and includes a "this is still valid" in TLS handshakes.

With CRLs and OCSP being fail-open which is weird for a security thing.

vanitasvitae> flow: got it. In that case a bump would not be required for XEP-B? Only if XEP-B would be uodated to use XEP-A:++? Since there nothing has changed in XEP-B, no bump is required

Zash, I believe that given an cert, there are extensions available to find, download, and then cache the signer, so you can keep going until you find a known TA or a self-signed cert.

s/signer/issuer/ - I'm not thinking today. I think the AIA extension should help. http://pkiglobe.org/auth_info_access.html

Zash, Also, you're thinking OCSP Stapling, and for XMPP servers, I think you fetch the CRL periodically, and use that as a fallback to OCSP (with or without stapling), and if you can't do CRL or OCSP then fail.

Zash, My theory here is that there are very few CRLs you actually need as a server, so you're very likely to have that, and an attack which causes OCSP to fail then has a very small window to work with.

100% Let's Encrypt probably.

Probably 5 or 6 different CRLs, though 99% LE, yes.

emus: very good work on newsletter once again, it's much appreciated :)

what he said ^

❤ Thank you guys, very happy you like it!

Guus, ah, but CRLs are to revoke trust by the signer.

while truststores are configured locally and have nothing to do with the signer

(if it exists at all)

so to revoke trust in a certificate from a trust store, you remove it from the trust store.

hmm I was assuming that the CRLs override the trust from the truststore

to check, the truststore is where your trusted root CAs certs are?

yes

ahh ok, I think I figured out where I went wrong

flow, A CRL lists the signatures by an issuer that are no longer valid, in effect. An issuer *could* be a TA, but is more likely to be an intermediate cert.