pem-dev
[Top] [All Lists]

Re: Encoding OPTIONAL canonically

1993-06-28 14:15:00


   >From: Ned Freed <NED(_at_)COM(_dot_)INNOSOFT>
   >Subject: Re: Encoding OPTIONAL canonically
   >Date: Mon, 28 Jun 1993 11:23:23 -0700 (PDT)


   >(1) Certificates (contains optional ForwardCertificationPath sequence).
   >(2) CertificateList (contains optional revokedCertificates sequence).
   >(3) CertificationPath (contains optional sequence of CertificatePairs).


CertificateList and CertificationPath are types which are applied via
the SIGNED macro to have specific meaning in the context of signature
algorithms.

Certificates is not, being a mere collecting convention for (unsigned)
transmission of trust information by the MTS Abstract Service.

Certificates goes to the trouble of defining an OPTIONAL new type for the
'SEQUENCE OF' elements. CertificateList and CertificationPath do not.

By the principle of substitution of equals, subordinate types have
the same semantics of their denoting type names. However,  when the
denoting name is OPTIONAL, this is evidently not true - OPTIONAL OPTIONAL
would require an DER-impossible 4-possibility canonical encoding scheme.

Thus, either refine the definitions of CertificateList and CertificationPath
as per Certificates (per the above distinction), else accept
0 and phi revocations are not equivalent statements.

The second case is clearly more functional. An optional type name has
different meaning to an optional constructed type.

Why isnt this obvious? Despite the prcision of recent
messagesm, I'm missing something conceptual, clearly.

<Prev in Thread] Current Thread [Next in Thread>