[Openswan Users] Openswan IPSec

[Chen, Xuli (James)]

Hi Paul and all,

I'm using openswan-2.6.21_53 from redhat. I don't know much about openswan design, but I have to answer if openswan meets all these requirements. Can you please help me? Appreciate you help.
The system shall only support the following erroneous messages associated with a certificate request:

III

* Invalid Key  [James: yes]

* Invalid ID     [James: ?]

* Invalid certificate encoding [James: ?]

* Invalid certificate [James: yes]

* Certificate type unsupported [James: ?]

* Invalid CA [James: ?]

* Invalid hash [James: ?]

* Authentication failed [James: yes]

* Invalid signature [James: yes]

* Certificate unavailable [James: ?]


Path Development and Path Processing:

1)      Applications supporting relying party processes must be capable of developing a certificate path and processing the path (The path development process produces a sequence of certificates that connect a given end-entity certificate to a trust point).

I


Path Development:

1)      Applications should construct paths automatically without involvement of a human. [James: ?]

II


Path Processing :

1)      Applications should reject a path where an included certificate expired between the effective date and the current date unless the application is re-verifying a signature that was verified at an earlier date when none of the involved certificates were expired [James: ?]

II

2)      When an application must validate a path involving expired certificates, the application must check the status of using CRLs issued after the effective date but prior to the expiration of a currently expired certificate and should use the most current CRL preceding a certificate's expiration.[James: ?]

I

3)     Applications must perform the following major steps for path processing for each certificate in the chain:

I

*        Verifying certificate signatures. This verification shall use the certificate issuer's public key. [James: yes.]

I

*        Ensuring effective date falls within the certificate's validity period. [James: yes.]

*        Ensuring certificate use is consistent with extensions.[James: ?]

*        Ensuring the validity of certificates through a status check. The following section will address status checking.


Certificate Status Checking:

1)     If using CRL for certificate status check, applications shall perform the following steps for each certificate being validated (target certificate):

I

*        Verify the signature on the CRL. This verification requires developing and processing a certificate path establishing that the target certificate's issuer trusted the CRL issuer to issue CRLs. [James: openswan checks the issuer's signature of the crl]

*        Verify that the CRL has not expired if the target certificate has not expired.[James: yes.] A CRL is expired if the current date is after the CRL's next update field value. (See above paragraph regarding paths with expired certificates.)[James:?] If the target certificate has expired, verify that the CRL's issue date follows the effective date and precedes the certificate's expiration date.[James: ?]

*        Search the list of revoked certificates to determine that the target certificate either is not included or its revocation date is after the effective date. [James: yes.]


Extension Processing:[James: ?]

1)      Applications shall ensure that the intended use of the certificate is consistent with the extensions.

I

2)     Applications must process the critical extensions and should process non-critical extensions.

I

3)     Applications shall ensure that in the Key Usage extension in the end-entity certificate:

I

     *        The digital signature bit is set for authentication uses.

     *        The non-repudiation bit is set for non-repudiation uses.

     *        The key encipherment bit or the data encipherment bit is set for encryption uses depending on whether keys or data are to be encrypted.

4)     Applications shall ensure that for certificates other the Root CA in the Key Usage extension:

I

     *        The Certificate Signature bit is set in the certificate containing the public key used to sign the next certificate in the chain.

     *        The CRL Signature bit is set in the certificate containing the public key used to sign a CRL.

5)     Applications shall ensure that Basic Constraints extension is true in the certificate containing a public key used to sign a subsequent certificate in the path.

I



Thanks,
James

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.openswan.org/pipermail/users/attachments/20110512/f05756db/attachment-0001.html