Certificate Hash different if generated from X500Name or X500Principal?

[jrevillard]

Hi all,

Is it something normal in your opinion?:

System.out.println(CertificateIOUtil.nameHash(new X500Name("O=GRID-FR,C=FR,O=MAATG,CN=Jerome Revillard")));
System.out.println(CertificateIOUtil.nameHash(new X500Principal("O=GRID-FR,C=FR,O=MAATG,CN=Jerome Revillard")));

produces:

c14d908f
8d22cef2

The problem is that the new BC API uses X500Name to set the issuer and, for instance, myproxy server seems to be confuse with it....

Best,
Jerome

[bbockelm]

:/ That's definitely not good. Which hash is "correct" if you ask OpenSSL?

[kofemann]

this is the couse it that X500Name and X500Principal use a different order internally:

public static void main(String[] args) throws IOException {
    String s = "C=DE,ST=Hamburg,O=dCache.ORG,CN=dCache.ORG CA";

    X509Name x509Name = new X509Name(s);
    X500Principal p = new X500Principal( new X509Name(true, s).toString());
    System.out.println(String.format("hash %.8s, hash %.8s  : %s",
            CertificateIOUtil.nameHash(encodePrincipal(x509Name)), CertificateIOUtil.nameHash(p), x509Name));         
}

[paulmillar]

Note that, irrespective of ordering issues, this approach is fundamentally broken: one cannot reliably map a UTF-8 string to a hash since there is a many-to-one mapping from a X.500 DN to a UTF-8 string.

Each RDN of a DN has a type; examples of types include UTF8String, PrintableString, UniversalString and IA5String. As the hash is calculated using both the type and value of RDNs, it matters what are the types of the RDNs: a UTF8String "dCache.ORG CA" is distinct from a PrintableString "dCache.ORG CA" and a DN with that differs only by type will have a different hash.

This means that it's impossible to know what is the hash of "C=DE,ST=Hamburg,O=dCache.ORG,CN=dCache.ORG CA", since we don't know with what string types the RDNs were encoded.

The way this "works" currently is by assuming that all DNs are a specific type (PrintableString, IIRC). I believe IGTF say RDNs should be PrintableString, but I imagine that at some point UTF8String will be needed.

The verifying-DN-against-signing-policy problem is tractable, but only by working in the "forward direction"; in other words, enforcing a signing_policy file is possible, provided the matching is done with String representations of DNs (or hashes there-of) and never with the crypto hashes.

Given this problem, it may be better to spend effort fixing the more fundamental problem than fixing the ordering issue.