Mark,
Thanks for your detailed and informed reply. I should warn readers who have
only a
passing interest in X.500 that this message is rather lengthy, and may require
going
back to my original message in order to keep the context clear, but I think that
these issues are very important if we are to adequately support PEM and other
users of PKC with a workable X.500 directory.
You said:
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.
We may have a difference of views or approach here. You
seem to be taking (and perhaps understandably so) a primarily ISO
standards position -- if an attribute is registered by somebody, somewhere,
under some arc of the CCITT/ISO tree, that ought to be enough to
define it. And perhaps it would, if we had the definitions of all of these
different attributes widely available in operational X.500 directories,
and if we had Directory User Agents that understood all of these
attributes, both in terms of their syntax and their semantics. And likewise,
if the encryption/signature user agents were also so smart, they could
deal with all of these issues. BUT WE DON'T, AND THEY AREN'T. so
the human users are going to have to cope with these problems, at least for
now.
(As I said in an earlier message concerning self-describing objects, I am
extremely
concerned with the potential proliferation of different kinds of DUAs, and
the exponentially increasing amount of smarts that they must contain. I am
beginning to think that unless we put more of the burden of understanding
the syntax AND SEMANTICS of all of the various attributes back into the
DSA, we are going to have to have UAs in front of DUAs in order to keep up
with the continuously increasing knowledge they are supposed to have. IMHO,
DUAs should only have to understand how to present a very small number of
different fundamental object types, such as the basic DirectoryString, OCTET,
BIT STRING, NUMERAL, etc. Asking DUAs to INTERPRET ASN.1 in
real time is too much of a burden, IMHO, much less understanding the semantics,
much less having to cope with the shared knowledge and KAN/CAN information
that tells the DUA which DSAs) have knowledge about a given DN in a
competitively-shared name space. Without some sort of a solution to this
problem I am not convinced that a shared X.500 solution is commercially
viable.)
What I am suggesting, therefore, even at the risk of a certain amount of
overkill from a purely formal standards process, is that we provide
human-readable descriptions of some of these key attributes,
just to help the poor user who is using a DUA that may understand how
to display a PrintableString, but probably can't cope with even the full
richness of TeletexString, much less the esoteric differences between
PKCS #n vs. AOCE #m.
Also, I do not necessarily want to be confined to the current X.509
definition. I believe that the current X.509 certificate structure is badly
flawed,
because it does not allow the use of additional attributes, e;g;., e-mail
mailbox name, as a non-distinguished attribute. Unless or until X.509
is amended, and it appears that will be at least 3 years away, I am not
willing to bet the ranch on it. PGP, RIPEM, and/or other certificate
types may either supplant or co-exist with the current X.509 definition.
(That would be regretable, but standards sink or swim depending on
whether they meet user's needs. If they don't, they die.)
Finally, I don't know just where the ANSI X9F1 work will fit into this
structure,
but I think we have to plan for a variety of authorization certificates. And
although I think that group is doing excellent work, I am not sure that
a group that focusses primarily on wholesale banking will come up with
a standard that everyone else in the industry will be comfortable with.
(Witness X9.17, for example.)
Whatever we do, of course, we have to decide precisely what to put in this
string for each different varient. Presumably this could be obtained from the
name that was used when the OID was registered?
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.
Those are some excellent issues. My suggestion would be to say that as soon
as someone settles on a reasonably stable set of interoperable protocols, they
create
an OID for that set. In the meantime, in addition to such an OID, how about a
field
of type DirectoryString, length 1024 octets, that says, " 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, but I can't handle DMS at all." I
know --
this is a rude, crude, ugly hack that isn't machine readable, or even French or
Spanish readable, but it should help us get up and running.
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.
I vacillated back and forth between having a single entry that pointed to the
name
of the PCA, with ALL of the information, including the pcaPolicy, the Internet
address of the CRL responder, etc., as attributes under that entry, vs. having
an entry containing a single attribute (SIGNED { DirectoryString }) whose DN
would
be contained within the object class. I don't care much one way or the other,
but
I confess that I don't have a good way of evaluating the virtures of either
approach.
Why did you suggest what you did, and what would the pros and cons be, in your
judgment?
-- 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 } }
With respect to the the CA policy, I wold prefer that there not be any -- that
the
PCA policy should be good enough for all of the CAs under it. In that case, the
CA's policy, which would be signed by the CA and witness/signed by the PCA,
could
just be a null statement. Realistically, however, individual companies may
insist on
having their own "fine print," which is what this is intended to support.
With respect to the userPolicy, I have in mind either an offered bilateral
trading
partner agreement, or (better) a unilateral contract or affidavit similar to my
Affidavit of Legal Mark that many have seen in various forms. Basically, this
would
say something to the effect, "I agree to be bound by my digital signature as
though
it were my written signature, but only if it is used for internal company
business
or for amount of under $1000, and not for any legal documents such as powers of
attorney, wills, or transfers of real property."
This policy has to be signed by the user, and then witnessed by someone else.
The CA could do it, or perhaps it would be better to have some third party do it
(since a rogue CA could make up the entire process, generating all fo the keys,
affidavits, etc., and impersonate the user).
signedDescription
-- digitally signed by the user.
Would it be better for this to be signed by the CA instead?
My thought was that this field would be used to differentiate between different
uses of the user's own (multiple) certificates, such as for solving the manager/
secretary problem, perhaps using different certificates for different mailboxes,
etc. I didn't see it as a substitute for a userPolicy attribute. As such, I
don't
particularly see the need to have the CA sign such a declaration, but I'm open
minded. Do you see a need?
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.
Very, very good point! George Parsons at RSA and I have been thinking what sort
of sunset clause should be provided in these policy statements, and how a PCA,
CA,
or user can disavow one policy without having to CRL himself.
At a minimum, a UniqueID should be provided to distinguish between different
versions over time, and perhaps some sort of validity period? If we adopted
your pcaPolicyEntry DN suggestion, that could point to an entry that contained
the pcaPolicy (etc.), the UID, and the validity dates?
The PCA and the CA could also generate unique key pairs that would be used for
the
sole purpose of signing their policy statements, and have those keys signed by
their master key. Then, if the PCA or the CA wanted to revoke a policy prior to
its expiration date, all they would have to do is CRL that particular
certificate.
the user could do the same thing, of course, but it is a little more awkward to
insist that the user generate two certificates, one to be used just to sign a
policy.
but I suppose this isn't too bad.
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: [definitions deleted].
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.
Yes, this approach would seem to have some merit. But given the lack of support
in trying to get anything added or changed within X.509, I hesitate to propose
the widespread adoption of PKCS at this time -- I don't know how much support
that would get.
What I was trying to do was provide equivalent functionality though a mechanism
that we, as potential X.500 ADDMD providers, can control ourselves. I would
prefer the NADF endorse such an object class, but if necessary we could
do it ourselves, once we have our ANSI OID.
I am also somewhat concerned about making the extended certificate so large.
I would anticipate that if we put the validity dates for the policy as
mandatory
attributes in the nadfStrongAuthenticationUser object class, then users would
know
when to look for a new one.
Finally, although the user may go to the Directory rather frequently, in order
to
obtain and validate the originating user's certificate after receiving a signed
message,
I would not expect the user to go back to the policy and reread it every time.
This
would argue against including the policy information (which may be more like
40K bytes each, or 120K bytes per certificate) within the certificate itself.
Suppose the PCA, CA, or user were to sign the policy with TWO signatures --
one validated using the user's "normal" certificate, the other a certificate
that is
used only for signing the policy (or any similar function). then the user could
CRL
his policy-signing certificate as a way of revoking his policy, then get a new
certificate and use it to sign the new policy.
The policy doesn't have to be bound to the certificate -- the certificate has
to bound
to the policy. The user may have multiple certificates for multiple purposes,
but
only have one policy. If we have the ability to sign an object without
attaching the
signature to the object itself, then the solution is easy -- put the signature
only in the
nadfStrongAuthenticationUser group. (This seems to be what the
SIGNATURE {Of Signature} attribute is used for, but I don't know anyone
who implements it.) If not, then the policy may have to be signed multiple
times --
once for each certificate plus once for the signature-only certificate, to
permit
revocation by CRL.
(One last question -- I have a nagging concern that what I have been describing
is
really a complex attribute, rather than an object class. Have I been using the
right language? Does this entire set of mandatory and option parameters make up
one entry, so that we can pick it up and carry it somewhere?)
Again, thanks for the detailed comments. If we can come to closure on these
issues,
I'll present them to the NADF for their comments.
Bob