[sr #107489] ipsec_ike_key created in wrong code path

Micah Anderson INVALID.NOREPLY at gnu.org
Tue Oct 5 15:13:55 CEST 2010


Follow-up Comment #7, sr #107489 (project gnutls):

Originally, the patches submitted in #107485 only created a certificate with
the KP flag for ipsec IKE *only* when the "ca" flag was set. That was because
the get_ipsec_ike_status() check in src/certtool.c:547 was wrapped inside an
if (ca_status) predicate. That was the incorrect place to have that check, as
the ipsec_ike_key KP should not be set in a certificate designated for a CA.

If you compile the code, with the patches, you can test that the following
are true:

1. build a cert with ipsec_ike_key set in the template, it should create a
cert with the following:

		Key Purpose (not critical):
			Ipsec IKE.

this test checks to make sure that you get a certificate built with the Ipsec
IKE KP set, when there is no 'ca' flag set. This was the original code pathing
problem.

2. build a cert with the 'ca' option set in the template, along with the
ipsec_ike_key option set. It should have the following v3 extension Basic
Constraint set, and *no* Ipsec IKE Key Purpose set:

		Basic Constraints (critical):
			Certificate Authority (CA): TRUE

This test checks to make sure that when you set the 'ca' flag, no Ipsec IKE
KP is set, as this KP should not be set when the certificate is a CA
certificate. This is the inverse of the previous test.

3. build a certificate with ipsec_ike_key set in the template, with multiple
dns_name parameters set (dns_name="test.gnutls.org, test2.gnutls.org") and an
IP address set (ip_address=192.168.1.1) to achieve a certificate with
subjectAltNames set. The certificate should have the Key Purpose Ipsec IKE set
as in test #1 above, and the SubjectAltName bits should be set:

		Subject Alternative Name (not critical):
		DNSname: test.gnutls.org, test2.gnutls.org
		IPAddress: 192.168.1.1

This test makes sure that subjectAltName support works with the Ipsec IKE
KP.

4. build a certificate with "tls_www_server" set along with "ipsec_ike_key"
set and subjectAltNames as in test #3. The generated certificate Key Purpose
should have both "TLS WWW Server." set as well as "Ipsec IKE." and the
subjectAltNames should also be set, as in test #3

This test ensures that you can build a certificate with multiple KP's set,
along with Ipsec IKE. With the added bonus that the subjectAltNames should
continue to persist.

5. build a certificate with "signing_key" set, as well as "ipsec_ike_key"
set. This should result in a certificate that has the "Ipsec IKE" Key Purpose
set, and the Key Usage set to "Digital Signature", as follows:

		Key Purpose (not critical):
			Ipsec IKE.
		Key Usage (critical):
			Digital signature.

This test makes sure that when the Ipsec IKE KP is set, and 'signing_key' is
set, that the KU is properly set to Digital signature. This tests compliance
with RFC 4945 § 5.1.3.2.

6. build a certificate with 'encryption_key' set, along with 'ipsec_ike_key'
set. This should result in a certificate that has the "Ipsec IKE" Key Purpose
set, and the Key Usage set to both "Non repudiation" and "Key encipherment",
as follows:

		Key Purpose (not critical):
			Ipsec IKE.
		Key Usage (critical):
			Non repudiation.
			Key encipherment.

This test makes sure that when Ipsec IKE KP is set, and encryption_key is
set, that the Non repudiation KU is also set. This tests compliance with RFC
4945 § 5.1.3.2.

7. build a certificate with 'encryption_key' set, along with 'signing_key'
set, and with 'ipsec_ike_key' set. This should result in a certificate that
has the "Ipsec IKE" Key Purpose set, and the Key Usage flags set to both
"Digital Signature" and "Key encipherment" as follows:

		Key Purpose (not critical):
			Ipsec IKE.
		Key Usage (critical):
			Digital signature.
			Key encipherment.

This test makes sure that when Ipsec IKE KP is set, and both encryption_key
and signing_key are set, that the KU is properly set to have both Digital
signature and Key encipherment (and not Non Repudiation). This tests
compliance with RFC 4945 § 5.1.3.2.


    _______________________________________________________

Reply to this item at:

  <http://savannah.gnu.org/support/?107489>

_______________________________________________
  Message sent via/by Savannah
  http://savannah.gnu.org/





More information about the Gnutls-devel mailing list