On Sun, Feb 5, 2017 at 7:58 PM, Viktor Dukhovni <postfix-us...@dukhovni.org> wrote:
> > > On Feb 5, 2017, at 6:49 PM, Jaime Hablutzel Egoavil < > hablutz...@gmail.com> wrote: > > > > Here is one valid use case, the mail service operator > > doesn't manage or participate in the certificate issuance > > itself but he expects that his users get their certificates > > from a commercial CA, e.g. Symantec (which he trusts for > > validating emails and including them in subject DNs), but > > at the same time, this mail service operator doesn't want > > to allow authentication for all of the Symantec issued > > certificates but only some, e.g. the ones with a given > > domain in the "emailaddress" subject attribute. In this > > case the policy server would need the "emailaddress" > > attribute to decide. > > That would be a fragile and risky policy. You'd be placing > relay access control for your MSAs in the hands of an external > CA. Your configuration would have to be carefully tuned to > exclude trust of all the other CAs. > How is an external CA better positioned to authenticate your > users than your own servers? > Actually the purpose of CAs to exist in the first place is to register, validate and certify the identity (and attributes like email address) of entities (e.g. individuals or servers). But you are right, care should be put on choosing only the CA or CAs which we consider safe for this purpose (e.g. by means of checking their CP/CPS). > > That said, the real obstacle the complexity of X.509v3 certs. Giving users raw certificate chain to decode and validate is > a disservice. But note that not all users (actually policy server inplementors) would require to deal with them, the chain would be just there available for the one who requires it and additionally some characteristics of the chain could be passed alternatively like the subject and issuer, as currently is being done. > Consider, for example: > > https://tools.ietf.org/html/draft-ietf-lamps-eai-addresses-06 > > users may be tempted to start processing "SmtpUtf8Name" SubjectAltName > elements in certificates, but their TLS toolkit might not know these > exist, and may not have applied name constraints. The domain in the > user's email address may have to be converted from A-labels to U-labels > to comply with the specification, the verifier must not forget to ensure > that the chain is actually trusted... Not really familiar with name constraints but I believe that if the user delegates certification path validation (CPV) to their TLS toolkit it should fail if it doesn't recognize a given name in the name constraints. > > I am not inclined to just dump raw sewage (X.509) on the user's lap > and ask them to deal with the mess. > That would provide flexibility anyway, as I said before, in addition to some extracted attributes like subject and issuer. > > It may make more sense to export the list of validated subjectAltName > values, that are known to have been understood (suitable constraints > applied) by the OpenSSL software, where the certificate chain has been > verified... This is still risky, but a more reasonable UI for Postfix > administrators. > > -- > Viktor. > > -- Jaime Hablutzel - RPC 994690880w
