On Sat, Jan 18, 2020 at 9:43 AM Alan DeKok <al...@deployingradius.com> wrote:
> On Jan 18, 2020, at 8:55 AM, Ryan Sleevi <ryan-i...@sleevi.com> wrote: > > Um, no. I largely didn’t respond to Michael’s email because it missed > the mark rather substantially, > > In what way? Which CAs (plural) are you referring to? The CertSign example given - the stronger of the restrictive CPSes - uses a cert from a CA not subject to these (or any) requirements. That is, it’s an untrusted root. Certificates from other services were examined, but without a similar analysis of the issuing CA, which is the point. You can’t claim multiple CAs, when there was a smattering of examples without any evidence of an analysis of the relevant CP/CPS. If the point was a singular CA seeming to violate their CP/CPS (that is, DigiCert), then yes, absolutely, you can go submit a CA problem report and the CA is obligated to respond in 24 hours with their analysis to your problem report. It’s the same procedure if, for example, you ever handled a private key for a certificate issued by DigiCert and had not had a background check conducted and/or conducted a background check on anyone you have access to. > and I suspect folks still haven’t actually read the CP/CPSes or done the > work. > > Those policies can best be described as "opaque". There is no clear > statement that "using certs with id-kp-serverAuth in non-WWW protocols is > grounds for revocation". I whole heartedly agree! To continue to connect it back to the original discussion, so that thread is not lost: if your use case (for example, EAP-TLS) wants to allow subjectivity and flexibility in how statements like this are interpreted, then you have to make sure other stakeholders are not also involved. That’s all. Obviously, CAs can (and do) paint themselves in corners of absurdity, much in the same way specs can end up with internal contradictions and inconsistencies. In order to untangle those bits, everyone has to agree. And it’s easier to get agreement among just two or three than it is around two dozen, especially when contracts and agreements are involved. As it ties back to the original discussion, it’s not _just_ agreements on the CP/CPS you need to worry about, but things like profiles and transition timelines and acceptable practices. The more stakeholders you continually add, the harder it is to find agreement or interoperability. The joy of PKI is that the solution is simple: disparate policies, enshrined by disparate hierarchies, since multiple policies for a single hierarchy doesn’t work in practice. The IETF has defined id-kp-serverAuth as "TLS WWW", *and* suggested it's > use in non-WWW protocols. This is a conflict that the IETF has to fix. Agreed. However, and this is where it’s messy: the IETF getting its house in order here does not resolve conflicts Once and For All. That’s because, for better or worse, the certificatePolicies extension doesn’t work, and so EKU has (and this was debated in PKIX even before 5280 replaced 3280) become synonymous with policy, at least by implementors. The best analogy I can think of is comparing to the X.501 DN attributes. X.501 defines their syntax, and tries to define the semantics, but in the absence of the global DIT, what a given attribute means and how it’s validated depends on the context and issues. That is, the value of an Organization field, or an OrganizationIdentifier, is going to depend on which PKI it is used in. The same is true for EKU, for better or for worse. If everyone finds it useful to violate CA policies, then we need to find > a way to fix that. I suggest that fixing CA policies is likely simpler > than fixing millions (or billions) of implementations. Oh, I agree whole heartedly there. I'm fixated on the EKU because it is a concrete example to pin an > argument on. We can have a vague discussion about generic policies, but > that would be unproductive. The entire point is the generic policies being why it’s important to separate things, and why it’s problematic to just assume one cert can or should work everywhere. What you’re calling unproductive is the essence and totality of the message, and perhaps that’s why I similarly find it unproductive to fixate on the single field and ignore the overall point. Where can I get a certificate with id-kp-eapOverLAN? Or where can I get > a cert designed for use with STMP, XMPP, etc.? https://wiki.xmpp.org/web/XMPP_Server_Certificates https://xmpp.org/about/xsf/records/proposals/intermediate-certificate-authority If the answer is "nowhere", then that's a problem. The CAs have > neglected their responsibilities to the customers. This is the problem with ignoring the broader message. “The CAs” is a term without useful meaning. Everyone can be a CA. You can be a CA. I can be a CA. Anyone who wants can issue certificates. There’s no set of entities blessed in some special power which only they can mint certificates, and thus their choices not to do so somehow be a sign of neglect. If you mean “The CAs” as the organizations operating key material in certain root stores, then many (most?) will happily issue you whatever certificates you want, from a hierarchy dedicated to your needs. I don’t even need to provide advertising links, just pick your favorite vendor and ask them about “private” or “enterprise” CA offerings. Want id-kp-eapOverLan? Sure, plenty will happily do that for you, for a price. Don’t like the price? Run your own CA and issue them yourself. There’s zero cost, and plenty of open-source tools to make “run your own CA” be a single line on a command-shell. Now, it may be that when you CAs, what you mean is “I can’t get a certificate from the set of organizations that operate private keys/trust anchors, trusted for this purpose in a default install of my operating system / browser / insert X here, and which chains to that public key”. That is, you can’t get one of these certs chaining to the same root.. Some might, but you’re right, that’s much more rare. And that’s a feature, not a bug or neglect, because you should be using separate hierarchies if you have different needs. If you’re willing to accept id-kp-serverAuth, and willing to accept that the interpretations and expectations will be dictated by the root store(s) recognizing that EKU, that as a Subscriber the timelines for changes will be dictated by those root stores, that as a Relying Party the profile will be dictated by those root stores, then yes, by all means, go ahead with that. Just know that, as a Subscriber and/or as a Relying Party, you can’t complain when things change, if profiles are made incompatible, or if things change too soon. I’m not saying you absolutely cannot and should not use id-kp-serverAuth issued by CAs in common root stores. You just have to be aware that it’s specifying your needs as “I’ll have 100 of whatever Ryan orders for gears”, and being prepared to accept that and make it work.
_______________________________________________ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
