(I have not looked up the description of these policyConstraints.)

To pass the certificate, GnuPG must parse this extension and handle it to
according to the specs (which might be to do nothing, but that is not likely).
There is a reason why the issuer flagfed the extension as critical.

As a workaround you may add this OID to the list in the unknown_criticals
fucntion which you find in gnupg/sm/certchain.c.

Dear Mr. Werner,
thank you for your prompt replay. I will try out your workaround to solve the issue.
Thanks a lot!

Dear Mr. Koch,

I have successfully modified the file gnupg/sm/certchain.c and made a 'personal'
patched gpgsm. It does work fine, as you can see from my console output:

mike@santaclara:~/gpg_test/bin$ ./gpgsm --with-validation
--disable-policy-checks --auto-issuer-key-retrieve --list-key
46:76:FB:18:D8:B0:DB:5B:A6:C7:F4:4D:64:41:A3:11:52:0E:CA:5D

gpgsm: DBG: connection to agent established

/home/mike/.gnupg/pubring.kbx

       ID: 0x520ECA5D
      S/N: 01
   Issuer: /CN=Postecom CA2/OU=Certification Authority/O=Postecom S.p.A./C=IT
  Subject: /CN=Postecom CA2/OU=Certification Authority/O=Postecom S.p.A./C=IT
 validity: 2006-05-10 10:45:04 through 2016-05-10 09:45:04
 key type: 2048 bit RSA
key usage: certSign crlSign
 policies: 2.5.29.32.0:N:

chain length: 0

fingerprint: 46:76:FB:18:D8:B0:DB:5B:A6:C7:F4:4D:64:41:A3:11:52:0E:CA:5D
[validation model used: shell]
[certificate is good]

Thanks again for your kind and sharp reply. I hope you will implement this kind
of certificate extension in next releases. I have found something about policy
constraints at pag. 42 of http://www.ietf.org/rfc/rfc5280.txt, but... for me
it's a little obscure!
Thanks again for your work on this great project.

Yours faithfully,

Michele Testa

Well, it will be some work to parse the description of policyConstraints and
policyMappings and see who it fits into the GnuPG system.

As a workaround implementing an option of --assume-supported-extension X,y,z
comes to mind. Would that be helpful?

Dear Mr. Koch,

I apologize for my silence, but I haven't had enough time in order to study the
RFCs and your amazing implementation of their complex specifications. For me
it's also difficult retrieving real examples of such certificates to prove or
falsify my understanding of policy constraints and mappings.

Now I have a further problem: when I receive an email with a s/mime attachment
encrypted with a certificate issued by Postecom CA, Kmail doesn't decrypt the
attachment because CRL check fails (CRLs of Postecom CA are discarded due to the
unsupported critical extension 2.5.29.36).

For this reason, I suppose that implementation of the option
--assume-supported-extension would be really useful only if it were extended
also to CRLs check functions. Nevertheless, this new option would be certainly a
good workaround during the development of these new features.

Postecom is the CA root of Postecert (http://www.postecert.it/index.shtml - a
branch of Italian National Mail Service), the major Italian provider for PEC
('Posta Elettronica Certificata', Certified Electronic Mail). So, if gnupg suite
will support the extension 2.5.29.36, the most of Italian linux users will
appreciate it more and more highly satisfied... :)

Thanks in advance for your time.

Yours faithfully,

Michele Testa

Okay, I implemented that for gpgsm:

$ ./gpgsm -k --with-validation --ignore-cert-extension 2.5.29.36
--disable-crl-checks 0x520ECA5D

/foo/bar/pubring.kbx

       ID: 0x520ECA5D
      S/N: 01
   Issuer: /CN=Postecom CA2/OU=Certification Authority/O=Postecom S.p.A./C=IT
  Subject: /CN=Postecom CA2/OU=Certification Authority/O=Postecom S.p.A./C=IT
 validity: 2006-05-10 10:45:04 through 2016-05-10 09:45:04
 key type: 2048 bit RSA
key usage: certSign crlSign
 policies: 2.5.29.32.0:N:

chain length: 0

fingerprint: 46:76:FB:18:D8:B0:DB:5B:A6:C7:F4:4D:64:41:A3:11:52:0E:CA:5D
[note: non-critical certificate policy not allowed]
[validation model used: shell]
[certificate is good]

Commited to 2.0 and trunk, rev. 5224.
Now for dirmngr.

Implemented for dirmngr. That will go into dirmngr 1.1.0.