pkcType
-- public key certificate type, e.g.,
-- X.509-RSA/X.509-PKCS/X.509-DMS/X9.30
I don't see how this attribute is used.
The userCertificate attribute, whose type is known by its assigned object
identifier, can only take values of one syntax: Certificate, as defined in
X.509.
This X.509 certificate contains two different algorithm identifiers (of ASN.1
type object identifier) for the issuer and subject public keys.
(A user with DSS public key may be signed by a CA with an RSA key pair.)
Object Identifiers have already been assigned for the X.509 certificate
attribute type (by ITU-T), for the RSA algorithm variants (by ITU-T & RSADSI),
and for other cryptoalgorithms.
protocolSupported |
-- PEM/RIPEM/PGP/AOCE/X.400/SDNS, etc
Email routing with lossy gateways is a difficult problem.
For instance, how to specify:
I can handle PEM with RFC-822 Content-Domain, RSA or DSS algorithms, in an
OIW PEM-X.400 bodypart to X.400 address X, or AOCE with RSA algorithm and key
size limited to 512 bits to address 822 Y through gateway Z but not gateway W.
I would suggest for the moment that this attribute should be of type OBJECT
IDENTIFIER instead of DirectoryString, as it distributes jurisdiction and
doesn't suffer from name collisions.
The MHS-DS WG might be addressing similar problems.
pcaPolicy
-- the DN of the entry containing information
I would suggest that this be called "pcaPolicyEntry" or similar, and the
attribute which actually holds the SIGNED { DirectoryString } be called
"pcaPolicy".
caPolicy |
-- the DN of the entry containing information
userPolicy |
-- the DN of the entry containing information
"caPolicyEntry" and "userPolicyEntry" as above.
-- digitally signed by the user and witnessed by the CA,
Do you mean that the actual attribute in an entry referenced by this attribute
would be of type
SIGNED { -- by CA
SIGNED { -- by user
DirectoryString } }
signedDescription
-- digitally signed by the user.
Would it be better for this to be signed by the CA instead?
pcaPolicy, caPolicy, and userPolicy would be of type distinguishedName, and
When reading the 1992 X.500, a unique identifier (BIT STRING) is optionally
also present where DN's are being used for security services in order to
differentiate between two entries with the same name which exist at different
times.
It therefore appears appropriate to provide the information in a form that
is tightly bundled to the certificate itself.
This sounds like PKCS #6, Extended Certificate Syntax Standard. If this were
used, the ASN.1 definitions might look like:
IMPORTS ExtendedCertificateOrCertificate
FROM PKCS-6;
-- ExtendedCertificateOrCertificate ::= CHOICE {
-- certificate Certificate, -- an X.509 certificate
-- extendedCertificate [0] IMPLICIT ExtendedCertificate }
-- ExtendedCertificate ::= SIGNED -- by the [P]CA -- { SEQUENCE {
-- version INTEGER,
-- certificate Certificate, -- an X.509 certificate
-- attributes SET OF Attribute } }
nadfStrongAuthenticationUser OBJECT CLASS ::= {
SUBCLASS OF top
MUST CONTAIN {
extendedCertificateOrCertificate
}
ID { ... } }
-- attributes of entries of this class
extendedCertificateOrCertificate ATTRIBUTE ::= {
WITH ATTRIBUTE SYNTAX ExtendedCertificateOrCertificate
-- multiple values
ID { ... } }
These attributes would then be inside the extended certificate.
userPolicy ATTRIBUTE ::= {
WITH ATTRIBUTE SYNTAX SIGNED -- by user -- { DirectoryString }
ID { ... } }
pcaPolicy ATTRIBUTE ::= {
WITH ATTRIBUTE SYNTAX SIGNED -- by pca -- { DirectoryString }
ID { ... } }
caPolicy ATTRIBUTE ::= {
WITH ATTRIBUTE SYNTAX SIGNED -- by pca -- { DirectoryString }
ID { ... } }
signedDescription ATTRIBUTE ::= {
WITH ATTRIBUTE SYNTAX DirectoryString
ID { ... } }
This would make the ExtendedCertificateOrCertificate large (10K+), but
would bind the information with the certificate (solving the problem of a
multiple-certificate user), and minimize the number of Directory reads.
-------------------------------------
Mark Wahl; M(_dot_)Wahl(_at_)cs(_dot_)ucl(_dot_)ac(_dot_)uk; Univ.
Coll. London