Bob,
In your message to Anish you went from suggesting that CA-based
CRL responders would be nice, to creating a requirement to be able
to derive a user's mailbox address from his DN. This is NOT a
requirement for PEM; it is a problem that comes with the
particular CRL-responder proposal that you and Sead and some
others have put forth. Any discussion of the need to be able to
map DNs into mailbox addresses should take place only in the
hypothetical context of that proposal. The thought of skewing DNs
used in PEM to fix this problem introduced by this proposal is
really stretching things!
You ask about the accuracy required of timestamps for CRLs, and I
believe that even a Mickey Mouse watch is sufficient, given the
human time scale in which compromise reporting, etc, takes place.
Again, as for having the CA provide time stamping services, one
must question the trustworthiness of this in a larger context. If
an employee at company A sends an organizational message to
someone at company B, I think company B would like an independent,
third-party to provide time stamping of the message and, if
needed, of the relevant CRLs. Also, it is often important that a
timestamp be applied at the request of the recipient, not the
originator. The rationale is that it is sometimes (often?) more
important to record when a message was received and the recipient
acted upon it, rather when the originator claims to have sent the
message.
Steve
=========================== and another response ==================
To: jueneman%wotan(_at_)gte(_dot_)com
Subject: Re: Corporate Identity and Authorization
Cc: pem-dev(_at_)tis(_dot_)com
------------
Bob,
I want to comment on some of the points in your response to
Charlie, message. First, although Apple OCE does not initially
have CRL support, I am confident it will be provided shortly. So
this seems to be a minor issue.
The PEM RFCs were revised two years ago (in I-Ds, not so recently,
really) to remove the DN restrictions. This change was intended
to avoid unduly constraining DN selection by folks who were
establishing directory services and who, presumably, knew enough
about X.500 to construct "good" DNs. I disagree with your premise
that ANY syntactically valid DN is fair game. The intent of the
change was to not preclude semantically and syntactically valid
DNs. By the way, the list of valid DN attributes is not to be
maintained by CCITT or NIST OIW but rather by the IANA. I'll try
to get that done soon with an eye toward avoiding some of the
X.500 attribute types that are inappropriate for DNs, though
appropriate for X.500 entries. Also, the 1422 rule about display
of unknown attribute applies to approved attributes that are just
not implemented yet, not arbitrary attributes.
Bob, there are folks who manage X.500 DSAs and who understand what
constitutes a reasonable DN. Just because people (who do not have
real X.500 experience) have had trouble sorting out syntactically
valid constructs from semantically valid ones, this does not mean
that the use DNs is intrinsically kludgey.
I sympathize with your desire to let your secretary read your mail
when you are away, but I question whether everyone wants to have
ALL of their mail read by their secretary under such
circumstances. PEM was not designed to accommodate either
"selective reading by alternative recipients" capability in an
elegant fashion. You propose one approach which relies on
separation of signing and encryption key management material, but
that does not solve the problem of the user who wants his
secretary to read most of his mail, but not all of it. That
problem might be solved by using two different certificates, with
the second having a DN in which the term "secretary" is included
in a predictable fashion as a naming convention. Under this
convention, mail could be sent directed to the secretarial
certificate unless it was especially sensitive. This is an
alternative solution which can be accomplished without changing
the PEM specs and it solves both the problem you cited and the
other one I noted. Should PEM be changed to use dual certificates
to accommodate your solution approach work? Is my dual
certificate hack better or worse than your perversion of DNs? I
know which way I judge these, but that's a subjective judgment!
Steve
=============== and yet another response ===================
To: jueneman%wotan(_at_)gte(_dot_)com
Subject: Re: DNs (Re: Corporate Identity and Authorization)
Cc: pem-dev(_at_)tis(_dot_)com
------------
Bob,
In your response to Ali I think you overloaded the utility of a
directory. The DN DOES describe the entity to whom the
certificate is issued, NOT the certificate! The directory model
does not assume that we can completely trust the information
stored therein. The directory makes explicit provision for
separate entries for organizational and residential persons,
organizational roles, etc.
Steve