Gerhard has captured the intent of the specification as written.

The main issue is the long standing requirement to allow trust even if issuer certificates are unavailable (based on a belief that the admins will do the right thing – a belief that I now feel is naive). We need to accommodate this use case even as we ensure our best practice guidelines make it clear that all issuers should be available via the chain or in the issuers store.

From: Gerhard Gappmeier [mailto:gerhard.gappmeier@ascolab.com]
Sent: Monday, January 21, 2013 9:50 AM
To: Randy Armstrong
Cc: 'Matthias Damm'; jim.luth@invensys.com; 'Deiretsbacher, Karl-Heinz'; 'Cristian Pogacean'; 'Thomas Merk'; 'Christian Zugfil'
Subject: Re: Inconsistencies regarding certificate validation in Spec, Stacks and test matrix

I agree with Randy

More general I would say:
Important is that we don't undermine OpenSSL Security.
We can deny certificates that are valid from OpenSSL point of view,
but we should never allow certificates that OpenSSL says are invalid.

E.g. A->(B)->C (C is signed by B, B is signed by A)
If only B is trusted, and A is unknown, OpenSSL validation will fail.
OpenSSL always needs the complete chain.
We should never ignore such an error.
The correct solution should be to put A into the issuer list,
which are known certificates but not trusted.

About 1) Yes, and that's how OpenSSL works.
About 2) Yes. This would mean to put the CA into the issuer list, only the application cert into the trust list.
About 3) Yes, each CA cert needs a CRL

PS: See https://crypto.stanford.edu/~dabo/pubs/abstracts/ssl-client-bugs.html
An interesting paper regarding this topic.

On Monday, January 21, 2013 09:28:22 AM Randy Armstrong wrote:
The requirements which I feel need to be met are:

1) The stack should allow full chain validation even if a trusted cert is found early in the chain

2) The stack should allow a single certificate to be trusted for a CA without trusting all certificates from that CA while doing full chain validation.

3) The stack should have a place to store offline CRLs for the full chain even if an individual certificate is trusted
but the issuer is not (i.e. a certificate may have been trusted but now is revoked)

We can work back from these requirements and see what options are available.

From: Matthias Damm [mailto:matthias.damm@ascolab.com]
Sent: Friday, January 18, 2013 7:01 AM
To: jim.luth@invensys.com
Cc: 'Deiretsbacher, Karl-Heinz'; 'Cristian Pogacean'; 'Thomas Merk'; 'Randy Armstrong'; 'Christian Zugfil'; gerhard.gappmeier@ascolab.com
Subject: Inconsistencies regarding certificate validation in Spec, Stacks and test matrix

Hi Jim,

During the review of the latest ANSI C stack changes we found security issues and inconsistency between

• Certificate Check definition in Part 6
• Configuration Schema in Part 6
• Certificate Test Cases Matrix developed by Randy
• ANSI C stack requirements / implementation

The main inconsistency is
(a) Definitions and certificate test case matrix imply that we do not need the complete certificate chain
(b) Configuration schema and ANSI C stack requirement defines Issuer certificate store in addition to Trusted certificate store to be abler to check the full certificate chain independent of the trust
If (a) is right, the Issuer certificate store is not needed.

In entered three related Mantis issues for Part 6 (2326), test cases (2325) and ANSI C stack (2324)
https://www.opcfoundation.org/mantis/view.php?id=2326

We need a high priority discussion and decisions to be able to finish new stack releases.

Kind Regards

Matthias Damm
ascolab GmbH
Am Weichselgarten 7
91058 Erlangen
Germany
Phone +49 9131 691122
Fax +49 9131 691128
matthias.damm@ascolab.com
www.ascolab.com
This e-mail is confidential and intended only for the use of the above named addressee. If you have received this e-mail in error, please delete it immediately and notify us by e-mail or telephone.

ascolab GmbH
Geschäftsführer: Gerhard Gappmeier, Matthias Damm, Uwe Steinkrauß
Sitz der Gesellschaft: Am Weichselgarten 7 • 91058 Erlangen
Registernummer: HRB 9360 Registergericht: Amtsgericht Fürth

Need to discuss if spec changes are required.

334 stack build now checks the entire chain. No updates needed to Part 6.

Part 6 does not require update.