[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: DPD & DPV requirements
Steve:
S/MIME has such a construct. From RFC 2630:
10.2.2 CertificateChoices
The CertificateChoices type gives either a PKCS #6 extended
certificate [PKCS#6], an X.509 certificate, or an X.509 attribute
certificate [X.509-97]. The PKCS #6 extended certificate is
obsolete. PKCS #6 certificates are included for backward
compatibility, and their use should be avoided. The Internet profile
of X.509 certificates is specified in the "Internet X.509 Public Key
Infrastructure: Certificate and CRL Profile" [PROFILE].
The definitions of Certificate and AttributeCertificate are imported
from X.509.
CertificateChoices ::= CHOICE {
certificate Certificate, -- See X.509
extendedCertificate [0] IMPLICIT ExtendedCertificate,
-- Obsolete
attrCert [1] IMPLICIT AttributeCertificate }
-- See X.509 and X9.57
10.2.3 CertificateSet
The CertificateSet type provides a set of certificates. It is
intended that the set be sufficient to contain chains from a
recognized "root" or "top-level certification authority" to all of
the sender certificates with which the set is associated. However,
there may be more certificates than necessary, or there may be fewer
than necessary.
The precise meaning of a "chain" is outside the scope of this
document. Some applications may impose upper limits on the length of
a chain; others may enforce certain relationships between the
subjects and issuers of certificates within a chain.
CertificateSet ::= SET OF CertificateChoices
Russ
At 07:02 AM 1/15/2001 -0800, Frank Balluffi wrote:
Steve Kent said:
> OK, that's a good argument! The argument to the server then would be
> a lump (a new ASN.1 construct) of certs, with no implied ordering,
> and the server if left to sort it out. If a partial or complete
> chain is sent, it is a valid example of the lump of certs model,
> which happens to be ordered already. I could live with that.