6 ms·
The other “half” of the issue is getting the os, browsers, and devices to support the standard as well. That’s a whole other can of worms.
by Dragging-Syrup 3y ago
The other “half” of the issue is getting the os, browsers, and devices to support the standard as well. That’s a whole other can of worms.
- 3np 3y agoLike gorkish wrote: No new standards or standard changes affecting any of those necessary. It's only a matter of will and culture on part of CAs.
- michaelt 3y agoName constraints are an optional feature in the standards. A client can ignore the constraints and be completely standards compliant. Should the CAs issue intermediate certs that are only secure if a client implements an optional feature? And even if most web browsers support name constraints properly - who knows if that cheap network webcam does, or that old mail client, or that 20 year old retro PC game?
- 3np 3y agoSo it may have limited use-cases today if you require full compat for all clients. For example internal controlled networks like discussed in the article. Just like you presumably already wouldn't issue LE certs when you need to support clients with ancient CA bundles. How do you think TLSv1.3 ever got rolled out?
- wejn 3y agoThis isn’t strictly true. If you want to uphold the name constraints in your CA cert, mark the field as critical. At that point clients that don’t understand them should fail validation of the CA cert.