What's new in NSS 3.12.\*- PKIX - Bridged CA, revocation flags and Policies

What's new in NSS 3.12.\* - PKIX - Bridge CA, revocation flags and Policies

Network Security Services (NSS) 3.12 has a new feature:

  • libpkix: an RFC 3280 Compliant Certificate Path Validation Library

Some terms

PKIX

"PKIX" refers to all these extensions and enhancements documented in RFC 5280. These may be grouped into three major categories:

  • Bridge CA
  • revocation flags
  • policies

CRL Distribution Points

Refer RRFC section 4.2.1.13. The CRL distribution points extension identifies how CRL information is obtained.

PKI

As per RFC 4158 Public Key Infrastructure (PKI) is the set of hardware, software, personnel, policy, and procedures used by a CA to issue and manage certificates.

cross-certificate

As per RFC 4158, cross-certificate is a certificate issued by one CA to another CA for the purpose of establishing a trust relationship between the two CAs.

As per RFC 5280, A cross-certificate is a certificate issued by one CA to another CA that contains a CA signature key used for issuing certificates.



PKI structures

Lets discuss the three PKI structures : Hierarchical, Mesh style structure, Bridge structure

Hierarchical PKI structure

In hierarchical PKI structure, a certificate chain starting with a Web Server "Server" certificate would lead to an "intermediate CA", then to a "root" CA whose certificate is present in the web browser.

It looks something like

     Root CA1

        |      

    Intermediate CA1

        |            

       EE1

So we can have only one possible certificate chain for any leaf certificate : EE1 -> Intermediate CA1 -> Root CA1.

Mesh style PKI structure

In a mesh style PKI, CA's authenticate each other and creates certificates for one other. CA1 certificate for CA2 and CA2 creates certificate for CA1. In case there are 'n' CAs the number of certificates will be n2

Example of Mesh style PKI

   CA1 ------ CA2

      \\            /

        CA3

As per RFC 4158, the CAs in this environment have peer relationships; they are neither superior nor subordinate to one another.

In a mesh, CAs in the PKI cross-certify. That is, each CA issues a certificate to, and is issued a certificate by, peer CAs in the PKI.  A mesh PKI that is fully cross-certified is called a full mesh. However, it is possible to architect and deploy a mesh PKI with a mixture of uni-directional and bi- directional cross-certifications (called a partial mesh).  Partial meshes may also include CAs that are not cross-certified with other CAs in the mesh.

Bridge PKI structure

In a bridged PKI, a certificate chain starting with a Web Server "Server" Certificate might lead to Intermediary Bridge CA certificate, then to possible two different trusted Anchors.

Example of Bridge PKI

         CA1                               CA2 

       |             \\                        /

       |                  \\                /

  ICA(keypair1)   Bridge CA  (keypair2- cert1 from CA1 and cert2 from CA2)
                                  |               

                                EE

As you can see "Bridge CA" has been issued certificate both by trust anchor "CA1" and trust anchor "CA2". Both these certificates have the same DN. So we can get two certificate chains for a single certificate: EE -> Bridge CA -> CA1 and EE -> Bridge CA -> CA2.

As per RFC 4158, each PKI only cross-certifies with one other CA (i.e., the Bridge CA), and the Bridge CA cross-certifies only once with each participating PKI.  As a result, the number of cross certified relationships in the bridged environment grows linearly with the number of PKIs whereas the number of cross-certified relationships in mesh architectures grows exponentially.


Bridge CA

Brige CA is a CA which has more than one certificates from different issuers. A single intermediate CA entity can have any number of certificates from different CAs. Each of these identities  all share the same DN.

As per RFC4158, A BrideCA is a nexus to establish trust paths among multiple PKIs. The Bridge CA cross-certifies with one CA in each participating PKI.

In NSS 3.11.\* certificate verification function were

  • CERT_VerifyCertNow
  • CERT_VerifyCert
  • CERT_VerifyCertificate
  • CERT_VerifyCertificateNow
  • CERT_VerifyCACertForUsage
In NSS 3.12.\* a new certificate verification function CERT_PKIXVerifyCert as added which should be used to replace above mentioned calls.

Scenario show casing the difference between old NSS call CERT_VerifyCertNow and the new PKIX call CERT_PKIXVerifyCert

I wrote a sample program(server.cpp) . It runs on a certificate nicknamed "EE" (generated by Bridge CA),  both the old NSS call CERT_VerifyCertNow and the corresponding new PKIX call CERT_PKIXVerifyCert.

I wrote a script run-tests.sh which creates CA1, CA2 and 2 certificates for Bridge CA and EE cert. Then it modifies trust flags of CA1 and CA2 and runs server program on it. 

When we set a C trust flag on a certificate - It means that this certificate should be treated like a CA certificate but also should be treated as root certificate we trust. When NSS clients/server validates certificate chain we can stop right there.

Because CA1 and CA2 root CA certificates are self-signed certificates, if we do not add "C" trust flags in them, we get SEC_ERROR_UNTRUSTED_ISSUER error.

When we remove "C" the trust flag of either of the CA certificates CA1 or CA2 and the test case starts failing, we know that the server program uses that chain. When we mark the trust flags of either of the CA certificates CA1 or CA2 as "C" and the test starts to pass so we know that the server program uses that chain.

You can see only ONE of CA1 or CA2 chain works in old CERT_VerifyCertNow() but in the new call CERT_PKIXVerifyCert() both the CA1 and CA2 chains work.

Look at the last few lines of output of the script run-tests.sh to confirm that.

$sh run-tests.sh
...
=====================================
Running tests with trust flags - CA2-trusted CA1-trusted
certutil ouput is
Certificate Nickname              Trust Attributes
CA1                               CTu,Cu,Cu
CA2                               CTu,Cu,Cu
Bridge                              u,u,u
Bridge                              u,u,u
EE                                  u,u,u
CERT_PKIXVerifyCert(EE) - PASSED.
CERT_VerifyCertNow(EE) - PASSED.
=====================================
Running tests with trust flags - CA2-not trusted CA1-trusted
certutil ouput is
Certificate Nickname              Trust Attributes
Bridge                                u,u,u
Bridge                                u,u,u
EE                                    u,u,u
CA1                                  Cu,u,u
CA2                                   u,u,u
CERT_PKIXVerifyCert(EE) - PASSED.
ERROR: CERT_VerifyCertNow(EE) - FAILED !! 
( as it uses chain EE-> Bridge ->CA2, CA2 is not trusted due to absence of flag "C")
      Error = -8172   SEC_ERROR_UNTRUSTED_ISSUER 
      Peer's certificate issuer has been marked as not trusted by the user.
=====================================
Running tests with trust flags - CA2-trusted CA1-not trusted
certutil ouput is
Certificate Nickname                Trust Attributes
Bridge                                  u,u,u
Bridge                                  u,u,u
EE                                      u,u,u
CA2                                    Cu,u,u
CA1                                     u,u,u
CERT_PKIXVerifyCert(EE) - PASSED.
CERT_VerifyCertNow(EE) - PASSED.
 (as it uses chain EE->Bridge -> CA2 and CA2 is trusted due to flag "C")
=====================================

 
  


PKIX and revocation flags

The function CERT_PKIXVerifyCert gives the server much greater control over how the certificate validation is done. For example, it allows the server to decide

  • what to do about revocation checking for leaf certificates or intermediate CA certs in a certificate chain.
  • whether to use CRLs or OCSP or both, and in which order of preference.
  • whether to use local CRLs or OCSP or fetch it from network or both.
  • whether to skip it, or attempt it but not require it, or to absolutely require it.
  • whether to ask it to attempt to fetch missing certificates from certificate chains, and/or to fetch CRLs, and/or to fetch OCSP responses.
  • whether to impose any certificate policy requirements on certificates.

CERT_PKIxVerifyCert takes an array of input parameters for tuning these. For details refer

http://mxr.mozilla.org/security/source/security/nss/lib/certdb/certt.h#887

http://mxr.mozilla.org/security/source/security/nss/lib/certdb/certt.h#1010


PKIX and Policies

Refer RFC520 section 4.2.1.4 for information about policies.

When verifying a certificate chain (using CERT_PKIXVerifyCert()) it is possible to pass as input, a given policy oid that must be met. The certification validation will fail if the requested policy is not in place.

It is also possible to request a list of all policies(OIDs) which were found to be valid.(a list of OIDs).

 
  


Thanx to Jyri and Nelson for helping me understand these concepts. 

References



Makefile to compile http://blogs.sun.com/meena/resource/server.cpp

SECURITY_DIR=/export2/NSS_3.12.8/
all:
    CC -g  -I$(SECURITY_DIR)/include -L$(SECURITY_DIR)/lib -lnspr4 -lnss3 server.cpp -o server

And then run http://blogs.sun.com/meena/resource/run-tests.sh.txt

Comments:

Post a Comment:
  • HTML Syntax: NOT allowed
About

Meena Vyas

Search

Archives
« April 2014
SunMonTueWedThuFriSat
  
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
   
       
Today