Quantcast

Why does the ccert_subject and ccert_issuer attributes in a access policy request contain the CN only?

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
5 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Why does the ccert_subject and ccert_issuer attributes in a access policy request contain the CN only?

Jaime Hablutzel Egoavil
I'm observing that these attributes, ccert_subject and ccert_issuer, when sent in a SMTPD access policy request, only contain the common name (if available) of the respective distinguished names (subject or issuer). Why is it so?. Why don't you provide the full DNs as they would allow for better decision making in the policy server?. For example, given the following subject DN:

CN=John Doe, emailaddress=[hidden email]

If I receive it in my policy server I could match it to the 'jdoe' SASL authenticated user (to support the requirement of client certificate authentication combined with SASL authentication) without the need to have a pre-registered certificate fingerprint, which is currently my only option if don't receive the emailaddress DN attribute, but only the CN.

Taking this a step further, you could pass the entire client certificate in the access policy request (not always to avoid the performance penalty, but through the activation of specific configuration directive) so the policy server is allowed to make even better decisions, e.g. based on certificate policies extension.

--
Jaime Hablutzel -  RPC 994690880
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Why does the ccert_subject and ccert_issuer attributes in a access policy request contain the CN only?

Wietse Venema
The answer is simple: because no Postfix access feature currently
requires the info that you're referring to. Lack of demand.

More likely is that the a site allows access based on client
certificates from one trusted signer and in that case, why would
one need the complexity of all the possible names in a certificate?

        Wietse
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Why does the ccert_subject and ccert_issuer attributes in a access policy request contain the CN only?

Jaime Hablutzel Egoavil


Sent from my Android device.

On Feb 5, 2017 5:15 PM, "Wietse Venema" <[hidden email]> wrote:
The answer is simple: because no Postfix access feature currently
requires the info that you're referring to. Lack of demand.

More likely is that the a site allows access based on client
certificates from one trusted signer and in that case, why would
one need the complexity of all the possible names in a certificate?

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.

But I would understand if this is not a regular use case so I ask if there are some official guidelines on forking Postfix, for example, to modify policy access client code but keeping as easy as possible to merge upstream changes when they are available.


        Wietse

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Why does the ccert_subject and ccert_issuer attributes in a access policy request contain the CN only?

Viktor Dukhovni

> On Feb 5, 2017, at 6:49 PM, Jaime Hablutzel Egoavil <[hidden email]> 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?

That said, the real obstacle the complexity of X.509v3 certs.
Giving users raw certificate chain to decode and validate is
a disservice.  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...

I am not inclined to just dump raw sewage (X.509) on the user's lap
and ask them to deal with the mess.

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.

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Why does the ccert_subject and ccert_issuer attributes in a access policy request contain the CN only?

Jaime Hablutzel Egoavil


On Sun, Feb 5, 2017 at 7:58 PM, Viktor Dukhovni <[hidden email]> wrote:

> On Feb 5, 2017, at 6:49 PM, Jaime Hablutzel Egoavil <[hidden email]> 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
Loading...