Subject: [pkix] DER encoding in RFC 3161

From: Koichi Sugimoto <[email-masked]>
Date: Tue, 28 Jul 2020 07:58:27 +0000

Hello PKIX members,

RFC 3161 specifies "The eContent SHALL be the DER-encoded value of TSTInfo."
in "2.4.2. Response Format"

Why RFC 3161 does not require DER-encoded value for full time-stamp token
(CMS data)?

On the other hand, following protocol encoding seems to require all
DER-encoded for entire time-stamp message.

3.1. Time-Stamp Protocol Using E-mail

3.2. File Based Protocol

3.3. Socket Based Protocol

3.4. Time-Stamp Protocol via HTTP

This seems time-stamp token requires DER-encoded indirectly.

Regards,

Koichi Sugimoto.

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Wed, 29 Jul 2020 17:10:22 -0400

I have been doing X.509v3 for 30 years now. I have yet to hear a good
answer to the question of why DER encoding is needed in PKIX.

It is a requirement of X.509 but not one that makes the slightest sense in
these days when you can store a billion certs on one disk drive and X.500
directory has fewer active users than Edison phonographs. Certificates are
moved from point A to point B as an opaque binary blob which is encoded by
the signer at signing time and only at signing time. This notion of signing
the abstract data rather than the binary bits keeps coming up but I have
yet to see anyone work out how to do it reliably, let alone add value by
doing so.

A digital signature is over a string of bits. The road to madness is paved
by canonicalization schemes.

It is sufficiently possible that there are ASN.1 parsers there that insist
on strict DER with definite length encoding throughout that changing PKIX
to allow BER encoding would now be a breaking change. And the same argument
can be made for cases where BER encoding is indicated.

So at this point, the best thing we can do is to just accept that the spec
is going to be ugly and not try to fix it.

On Tue, Jul 28, 2020 at 3:58 AM Koichi Sugimoto <koichi.sugimoto=
[email-masked]> wrote:

> Hello PKIX members,
>
>
>
> RFC 3161 specifies “The eContent SHALL be the DER-encoded value of
> TSTInfo.” in “2.4.2. Response Format”
>
> _______________________________________________
> pkix mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/pkix
>

---

From: Peter Gutmann <[email-masked]>
Date: Thu, 30 Jul 2020 10:15:40 +0000

Phillip Hallam-Baker <[email-masked]> writes:

>It is sufficiently possible that there are ASN.1 parsers there that insist on
>strict DER with definite length encoding throughout

Highly unlikely, since too many things would break if you did this, the last
parser I know of that did this was in the mid-1990s.  The rule has always been
"take whatever blob the other side sends you and use that", thus my long ago
comment that "there is only one encoding rule and that is memcpy()".  So in
practice you don't need to worry about it.  I mean, in theory you should, but
in practice you don't.

Peter.

---

From: "Todd E. Johnson" <[email-masked]>
Date: Thu, 30 Jul 2020 23:37:14 +0000 (UTC)

Peter,
 I received the exact same comment on our SCVP (5280) code. [What we should have done]

Peter.