At the recent NADF meeting, it was observed that the defnition of
strongAuthenticationUser in X.521 was pretty useless, and the
suggestion was made that some thought should be given to
enhancing it to make it more useful.
The present definition is
strongAuthenticationUser OBJECT CLASS ::= {
SUBCLASS OF top
MUST CONTAIN { userCertificate }
ID {id-oc-strongAuthenticationUser }}
I started to think what kind of information would be useful to capture here,
especially since my efforts to additional useful information within the X.509
certificate itself haven't met with overwhelming enthusiasm.
I came up with the following, and would welcome comments, criticism and
additional attributes that might seem to be necessary. In particular, as I am
not
an expert in ASN.1, the syntactical description should be taken with a
liberal amount of "do what I mean, not what I say."
nadfStrongAuthenticationUser OBJECT CLASS ::= {
SUBCLASS OF top
MUST CONTAIN userCertificate |
pkcType
-- public key certificate type,
e.g.,
--
X.509-RSA/X.509-PKCS/X.509-DMS/X9.30
protocolSupported |
-- PEM/RIPEM/PGP/AOCE/X.400/SDNS,
etc
}
MAY CONTAIN { pcaPolicy |
-- the DN of the entry containing
information
-- about the PCA's policy,
digitally signed by the
-- PCA, as it applies to this key
certification
-- hierarchy. This is not
necessarily the
-- DN of the PCA organization
itself.
caPolicy |
-- the DN of the entry containing
information
-- about the CA's policy (if
any), digitally signed
-- by the CA and witnessed by the
PCA, as
-- it applies to this key
certification
-- hierarchy. This is not
necessarily the
-- DN of the CA organization
itself.
userPolicy |
-- the DN of the entry containing
information
-- about the user' policy or
affidavit re containing
-- representations and caveats
(if any), digitally
-- signed by the user and
witnessed by the CA,
-- as it applies to this key
certification
-- hierarchy. This is not
necessarily the
-- the DN of the user him/herself.
signedDescription
-- a natural language description
of the use(s)
-- intended for this certificate,
e.g., for
-- Personal and Confidential
information;
-- for manager/secretary/staff
handling but not
-- for official, binding
signature; for Internal
-- Use Only but not for any
legal, financial, or
-- binding commitment, etc.,
digitally signed by
-- the user.
}
ID {id-oc-strongAuthenticationUser }}
The protocolSupported and pkcType would be attributes of type directoryString,
pcaPolicy, caPolicy, and userPolicy would be of type distinguishedName, and
signedDescription would be of type SIGNED.
Of course there may be a lot of other information about the PCA, CA, and user
that would be nice to collect, including the corporate name,
organization-person
contact, CRL responder, policy, etc., etc. All of this could go in a single
entry
that would contain all of this information as attributes. However, seeking that
information would require a number of dereferencing operations which would
add both time and cost, and it would be difficult to tell precisely which policy
applied to which certificate if the user had one policy for a highly secure
smart card used for high-value transactions, and another policy for low-risk
e-mail signing. It therefore appears to appropriate to provide the information
in a form that is tightly bundled to the certificate itself.
Bob