Friday Jun 12, 2009

RSA AlgorithmIdentifier of X.509 Certificate

By far, RSA is a most wide used cryptography algorithm. Both ITU-T X.509 and IETF PKIX WG define the RSA algorithm identifier, however, they are not identical.

ITU-T X.509[1] defines the algorithm as:

rsa ALGORITHM ::= {
    KeySize
    IDENTIFIED BY  id-ea-rsa
}

KeySize ::= INTEGER

id-ea-rsa OBJECT IDENTIFIER ::= {joint-iso-itu-t(2) ds(5)
algorithm(8) encryptionAlgorithm(1) rsa(1)}

While IETF PKIX WG[2] defines the algorithm as:
rsaPublicKey ALGORITHM-ID ::= { OID rsaEncryption PARMS NULL }

rsaEncryption OBJECT IDENTIFIER ::= {iso(1) member-body(2)
us(840) rsadsi(113549) pkcs(1) pkcs-1(1) rsaEncryption(1)}
 
  

There two differences:
1. different OID.
    ITU-T defines it as "2.5.8.1.1", while PKIX WG defines it as "1.2.840.113549.1.1.1"

2. different algorithm parameters
    ITU-T defines a parameter for RSA, "KeySize", while PKIX WG defines it as null.

Indeed, the RSA encryption algorithm PKIX WG used is defined by PKCS#1 [3][4], it is the industry standard definition. Most of the world use PKCS#1 OID, but not the one of ITU-T. Because of the above differences, there is a risk of interoperability problems between ITU-T X.509 compliant implementations and PKIX compliant implementations.

Before JDK 7, Sun certificate implementation cannot recognize the ITU-T X.509 OID, "2.5.8.1.1", throws a java.security.InvalidKeyException instead. It would be get fixed at OpenJDK 7 M4. If you happened to have such similar interoperability problem, I'd appreciate it if you comment it here or mail me your problems.

Linkage to the blog entry at simsbc.blogspot.com

[1] http://www.itu.int/ITU-T/asn1/database/itu-t/x/x509/2008/AlgorithmObjectIdentifiers.html#AlgorithmObjectIdentifiers.rsa
[2] http://www.ietf.org/rfc/rfc2459.txt
[3] http://www.rsa.com/rsalabs/node.asp?id=2125
[4] http://www.ietf.org/rfc/rfc2459.txt

Thursday May 28, 2009

Understanding Self-Issued Certificate

Certificate Types

RFC5280 categorize certificate into two classes: CA certificates and end entity certificates, and CA certificates are divided into three classes: cross-certificates, self-issued certificates, and self-signed certificates.

certificate +- CA certificate
+- cross-certificate
+- self-issued certificate
+- self-signed certificat
     +- end entity certificate

"Cross-certificates are CA certificates in which the issuer and subject are different entities. Cross-certificates describe a trust relationship between the two CAs." [RFC5280]

"Self-issued certificates are CA certificates in which the issuer and subject are the same entity. Self-issued certificates are generated to support changes in policy or operations." [RFC5280]

"Self-signed certificates are self-issued certificates where the digital signature may be verified by the public key bound into the certificate. Self-signed certificates are used to convey a public key for use to begin certification paths." [RFC5280]

Self-signed certificates are speicial slef-issied certificates, so we also can redraw the above tree as:

certificate +- CA certificate
+- cross-certificate
+- self-issued certificate
+- self-signed certificat
     +- end entity certificate

Notes of Self-Signed Certificate

1. "The trust anchor information may be provided to the path processing procedure in the form of a self-signed certificate." [RFC5280]

2. "When the trust anchor is provided in the form of a self-signed certificate, this self-signed certificate is not included as part of the prospective certification path." [RFC5280]

Note of Self-Issued Certificate

1. "Name constraints are not applied to self-issued certificates (unless the certificate is the final certificate in the path)." [RFC5280]

2. "However, a CA may issue a certificate to itself to support key rollover or changes in certificate policies. These self-issued certificates are not counted when evaluating path length or name constraints."

3. The pathLenConstraint field of basic constrains extension "gives the maximum number of non-self-issued intermediate certificates that may follow this certificate in a valid certification path."

4. The valude of inhibit anyPolicy extension "indicates the number of additional non-self-issued certificates that may appear in the path before anyPolicy is no longer permitted."

Identify a Self-Issued Certificate

RFC5280 requires that if the names in the issuer and subject field in a certificate match according to the comparison rules of internationalized names in distingushed names, then the certificate is self-issued. Please refer to section 7.1 of [RFC5280] about the comparison rules.

However, RFC3280 does not define the comparison rules, which requires that, "A certificate is self-issued if the DNs that appear in the subject and issuer fields are identical and are not empty." The specificate implies a binary comparison of the subject and issuer fields.

I think a good practice would have the same binary subject and issuer fields while issue a self-issued certificate.

Identify a Self-Signed Certificate

Sounds like a stupid title, just as its name implies, it is self signed, so it is self identifiable, i.e., the public key bound into the certificate could be used to verify the digital signature of the same certificate. Definitely, it's true. OK, we get a bi-steps process:

1. identify that a certificate is a self-issued certificate;
2. Verify the certificate digital signature with the public key bound.

That's a precious process, but not a effective process. Digital signature verify normally hurts a lot of performance, and generally it is not needed to verify the digital signature during build a prospective certification path.

Identify a Self-Signed Certificate Effectively

Self-signed, in another words, the key bound into the certificate is the same as the key used to sign the certificate. Could we identify it by comparing the key bound and the key used to generate the certificate signature? Here comes the authority key identifier extension and the subject key identifier extension, refer to RFC3280/RFC5280 for details.

To facilitate certification path construction, the specification requires that the authority key identifier extension and the subject key identifier extension MUST be appear in all conforming CA certificate. "There is one exception; where a CA distributes its public key in the form of a "self-signed" certificate, the authority key identifier MAY be omitted."

With the help of the two key identifier extensions, we get the following steps:

1. identify that a certificate is a self-issued certificate;
2. for conforming CAs, if the subject key identifier extension appears, but no authority key identifier extension, it is a self-signed certificate; if the both appear, it is a self-signed certificate when the KeyIdentifier is identical.
3. for non-conforming CAs, Verify the certificate digital signature with the public key bound.

Suggested Practices:

1. Always issue certificate with subject key identifier extension and authority key identifier extension.

2. Always include the keyIdentifier field in the authority key identifier extension.

3. Always have the same binary subject and issuer fields while issue a self-issued certificate.

4. Only issue self-issued certificate as CA certificate.

5. For TLS, always send the intermediate self-issued certificate within the response certificate list, otherwise, the recepient normally cannot build a certification path to its trust anchors.

The Problemtic Practices Encountered

1. A self-signed CA certificate issues 1+ self-issued end entity certificates.

There is no problem to issue such self-issued End-Entity certificate, but I'm afraid many PKIX libraries would not be able to handle it properly. If your application dependents on third party's PKIX library, and if you have to issue such certificates, please do check the library and make sure it supports such cases.

2. A self-signed CA certificate issues a self-issued certificate as an indirect CRL issuer.

It is special example of self-issed end-entity certificate. Some CRL verification library cannot handle such a indirect CRL issuer correctly, please double check the library to make sure such indirect CRL issuer is supported.

Java SE SDK support the above two problemtic cases at OpenJDK 7 build 60. If you application have to support above cases, you need OpenJDK 7 build 60 at least.

About

A blog on security and networking

Search

Categories
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