Subject: Re: [pkix] Interoparability problem between RFC 5280 and EDIFACT

From: Peter Gutmann <[email-masked]>
Date: Tue, 13 Dec 2011 20:40:11 +1300

koichi sugimoto <[email-masked]> writes:

>On the other hand, EDIFACT specifies the length of the 'CERTIFICATE  REFERENCE'
>must be less than or equal to 35 characters.
>In this case,
>'11 22 33 44 55 66 77 88 99 aa bb cc dd ee ff 00 11 22'
>cannot be accptable to EDIFACT.

That spec was written with EDIFACT certificates in mind; the only thing they 
have in common with X.509 is that both use the word "certificates".  So you 
will run into problems because you're using the fields to convey information 
that they were never designed to convey.  The solution is to apply whatever 
kludge works:

- Convince the CA to user shorter serial numbers (given your email address,
  I'm assuming your organisation is the CA, so you'd just have to change your
  software to use shorter serial numbers).
- Have your app recognise truncated forms of the reference string.
- Stuff additional bits of the value into other, optional fields.
- Change the encoding to allow a higher encoding density.
- ...

Peter.

---

From: koichi sugimoto <[email-masked]>
Date: Tue, 13 Dec 2011 18:23:23 +0900

Hello Peter,

You mean the application has a bug?
If the application is compliant to RFC 5280, then, the application
must be able to handle 20 octets.
Therefore, the encoding function that generates the 'CERTIFICATE
REFERENCE' should convert
5 octets to less than 9 charcters.
For example, base64 is one of the most familiar encoding, that
converts 3 octets to 4 characters.
It meets the requirement?

Regards,
Koichi Sugimoto.

---

From: Peter Gutmann <[email-masked]>
Date: Wed, 14 Dec 2011 03:12:58 +1300

>You mean the application has a bug?

No, it's working fine (or at least any bug(s) aren't in this area :-).

>If the application is compliant to RFC 5280, then, the application must be
>able to handle 20 octets. Therefore, the encoding function that generates the
>'CERTIFICATE REFERENCE' should convert 5 octets to less than 9 charcters.

Uhh, I thought the problem was that the hex-encoding was creating 40 bytes of
ASCII from 20 binary bytes, and that exceeded the 35-byte field length?

>For example, base64 is one of the most familiar encoding, that converts 3
>octets to 4 characters. It meets the requirement?

It should meet the requirements, depending on what the character-set
constraints are for the 'CERTIFICATE REFERENCE' field.  This is why I
suggested a range of options, if the other side rejects non-ASCII hex
characters then you can't use base64 and have to try one of the other tricks.

Peter.

---

From: koichi sugimoto <[email-masked]>
Date: Wed, 14 Dec 2011 12:28:23 +0900

Dear Sirs,

> ASCII from 20 binary bytes, and that exceeded the 35-byte field length?
Yes.
Therefore, if the developper is familiar with RFC 5280, then, he/she
must implement
some compression method to the value of 'CERTIFICATE REFERENCE' field.

Does anyone know about a reference implementation of this field?

Regards,
Koichi Sugimoto.

---

From: Peter Gutmann <[email-masked]>
Date: Wed, 14 Dec 2011 16:41:01 +1300

koichi sugimoto <[email-masked]> writes:

>Therefore, if the developper is familiar with RFC 5280, then, he/she must
>implement some compression method to the value of 'CERTIFICATE REFERENCE'
>field.
>

The problem here is that you have two incompatible standards, so there isn't
any single reference way to resolve this, there's only a list of things you
can try (see my earlier message).  For example my code doesn't generate 20-
byte serial numbers so it just works automatically without requiring any
special adaptations.  OTOH someone else's code that does generate 20-byte
serial numbers wouldn't work automatically, so you'd have to truncate the
value, or use a more efficient encoding, or something else.  I doubt there's
any definitive way to do this, it's just whatever a particular vendor decides
to do.

Peter.