CORBA3 — Encodings of Sequences of Certificates are not standard.

Explicit ASN.1 definitions of a sequence of certificates make a single
ASN.1 object out of the certificates. This approach is not what most
systems use today.

Discussion:

The CSI::ITTX509CertChain and the CSI::X509AttributeCertChain both
stipulate that the encodings of these "chains" be a single ASN.1 encoded
object. Sequences of certificates usually come in the form of a byte
stream of either ASN.1 DER encoded objects, or PEM encoded objects, (i.e.
Base64 encodings wrapped with "---BEGIN CERTIFICATE--", "---END
CERTIFICATE---" lines). It would be ideal to be able to handle both of
kinds these sequences, since many toolkits work this way already.

Tool kits that are provided in OpenSSL and Java, namely,
java.security.cert.CertificateFactory will not be able to handle the
encoding brought forth by the CSIv2 specification. However, the toolkits
will be able to handle a stream sequence of ASN.1 or even PEM encoded
objects, i.e. without the ASN.1 SEQUENCE wrapper.

Proposed Solution:

Eliminate the ASN.1 definitions in the specification, namely para 50 that
defines ASN.1 syntax for a certificate chain (i.e. "CertificateChain"),
and para 33 thru 34 for the corresponding one that fits the
AttributeCertificate(i.e. AttributeCertChain and VerifyingChain).

Furthermore, I believe, that the definition of CSI:ITTX509CertChain be
eliminated in favor of a single OID that forms a GSS_NT_ExportedName type,
in which it's name component is simply a non-empty sequence of
certificates (in any form), as well as creating an OID that stipulates a
supported name type is a DN, ASN.1 encoded or string form.

The proposed change is backward incompatible. Close no change