Tom, Richard, and Mark,
I don't mind admitting that I am now in over my head.
Each of you has had some very interesting comments about X.500
directory entries and possible alternatives to the admittedly crude "hacks"
that I suggested, but I haven't followed all this stuff closely enough
to know what is in the current standard, what is just proposed,
what is compatible with the current PEM standards, etc.
I don't feel entitled to post your private comments to me to pem-dev
without permission, but I think they would be informative to the broader
audience. Rich's comments about what is going on in some of the other
standards fora were a little like Greek to me, but I can see that I need
to get up to speed on these issues.
If Rich and Mark would send their most recent messages to pem-dev,
I'd like to hear some others comment on them. If you don't have copies
of what you sent, let me know and I'll post them.
I will comment on Tom's message, though:
Bob> the only place to put [a disclaimer] where it will be both obvious
and firmly bound to the user's signature is in the X.509 certificate
itself. I therefore recommend that the IETF or other appropriate
organization raise this as an urgent issue within the X.500 standards
committee, and try to get such a Disclaimer field added to X.509 at the
earliest opportunity.
Tom>Attribute types are defined in X.520 and there already are some
interesting ones that have not been here-to-fore discussed.
That's true. But I was under the impression that X.509 was much more
constrained, and that no additional attributes could be added or defined.
At least that's what I remember Steve Kent saying when I made some sort of
a suggestion along those lines several years ago. Has the 1993 standard
allowed additional fields to be added? What would that do to existing PEM
implementations?
Same issue with the suggestions to use serial number (atributeType 5), Business
Category (attributetype 15) Member(attributeType 31), or
Description(attributeType 13).
My understanding was that these were valid X.500 fields, but first of all X.500
isn't quite here yet, and second, PEM was supposed to be compatible with X.500
but
not dependent one it. Third, if these attributes cannot be included within the
X.509
certificate but only within the X.500 directory, then I have BIG TIME problems
trying to understand the trust model that will apply to X.500.
I think the NADF is wrestling with some of these issues, but I don't know. and
I haven't the vaguest idea how a trusted X.500 directory will evolve
internationally.
I strongly suspect that the PCA and CA structure that has been evolved for PEM
will
end up being mirrored in X.500, X.400, and elsewhere, as we begin to seriously
think about implementing these systems and have to begin understanding the
semantics.
Bob> There might not be any practical difference, but the use of an
explicit organizational role might tend to give greater weight to the
assumption that someone was in fact authorized to perform some
particular function than just a title. More importantly, if I
understand what you are saying, you can either have a organizational
role or you can be identified by your individual name, but not both,
since you can't have two common names.
Tom>Neither of these statements are true from the point of X.509, although
it might be the case that some countries will try to limit an RN to a
single common name. Also the common name is {attributeType 3} but the
Role Occupant is {attributeType 33}, so it could be used in either case;
even with a title {attributeType 12}.
As Rich pointed out in his reply, we don't have the luxury of a full X.500
directory in PEM. In particular, a DN is a DN is a DN once it is included
in the certificate, right? I understand that I can have two common names,
but surely not within one DN?
(There is another point I want to make here, but it is important enough that
I want to start another thread on the subject. See next message.)
Bob> In this case, our internal practice will require the use of a smart
card for the signature function, and we will also require the use of
keys that are close to the maximum length (1024 bits, as I recall?).
Tom>Now there is something that should be specified in a attribute! I
understand that X9.30 will make some statements about the requirements
for cryptographic modules. They have also added two fields to the
Certificate that may be of more interest than changes to one's
Distinguished Name. You should consider the X9.30 certificate model if
more data is your aim. No one has told me if X9 or TC68 will approach
ISO on this certificate.
The key length is of course included in the algorithm definition section of the
certificate. Maybe i didn't understand your point.
I do believe that PCAs should state some sort of a minimum key length
requirement
in their policies, however, especially if they are intended for any kind of a
high
assurance model.
Actually, I found out that the Datakey smart card that we were at least thinking
about using only supports a key length of 512 bits, which is quite disturbing.
Bob