RE: Basic Cert-2-Directory mapping question

[Andrew Probert <aprobert@xxxxxxxxxxxxxxxx>]

Hmmm.  This thread is a big read!

Humbly suggest you 
1)  Treat SubjectDN as a local representation.  Local software can use local
"knowledge" to find certs.

If things cannot be found locally, use SubjectAltName for wider connotations
..

2)  Extend SubjectAltName to carry protocolId & searchstring as required

In the LDAP world, the semantics of: SubjectAltName ..
UniformResourceIndicator ..
LDAP://ldap.myserver.com/basedn??cn=x,ou= ... is already supported.

It seems to me the DC=ACME, DC=COM hack to SubjectDN would have been better
effected by using the above, or 
SubjectAltName .. directoryName

For other protocols you could use RegisteredID and choose some new PKIX OIDs
with semantics i.e. OCSP address.

Define a limited profile for lookups.

Allows retrofit to market.  Needs new client capability.

But agree fundamentally, that a Naming Authority is required.  You can't
infer "knowledge" (directory references) from thin air.

Think hardcoding RFC822Names into S/MIME certs causes as many problems as it
solves.  Could have worked just
as well without.  I want to trust the Sender, not the mailbox it came from.
We are now issuing certs with multiple
RFC822Names to cater for work, home, and away users.

Think certificate policy .. who is allowed to do what (in corporate world)
is tightly linked to issues above.  

I probably need to configure that sort of knowledge locally on a corporate
or scheme basis, so maybe I would configure other "knowledge" at the same
time, which makes the above redundant?  Whilst Internet is largely an open
and promiscous network, do I continue such practice with secure
certificate-based traffic?

Look forwards to comments.

Andrew Probert
SecureNet Limited

-----Original Message-----
From: Stephen Kent [mailto:kent@xxxxxxx]
Sent: Friday, 19 January 2001 9:07 AM
To: David Kemp
Cc: ietf-pkix@xxxxxxx
Subject: RE: Basic Cert-2-Directory mapping question


Dave,

>Skip,
>
>I favor the implicit approach.
>
>Existing DNs schemas have tremendous inertia, and in addition to
>more intellectual reasons, registering existing country-based
>DNs within DNS is overwhelmingly the path of least resistance.
>In order to support Internet directory interoperability, it is far
>easier to say (to the DoD PKI, for example):
>
>   "You have to register a DNS record for OU=DoD."
>
>rather than:
>
>   "You have to change all of your certificates and directories to
>   include a new top-level RDN."
>
>I agree with Bob's goal of eliminating the need to pass certs in
>session handshakes and messages. If there were only two options (change
>the DN or add an extension), then only the first moves toward that
>goal.  But you have proposed a third option: leave the cert alone!
>For my part, I am simply in awe of the elegance of that approach.
>It might even work.

I don't agree that doing away with transmission of certs and CRLs 
inline via protocols, is a good idea in general. I understand why Bob 
wants to do this in his examples, but there is another side to the 
story. Reliance on the availability of a repository as a precursor to 
secure communications makes the secure communications more vulnerable 
to denial of service attacks, as well as creating likely greater 
delays security association creation. So, for protocols like SSL and 
IPsec, I'm more comfortable with passing this data inline, rather 
than relying on retrieving it from a server.

E-mail is the really good example of a general purpose application 
where it is necessary to retrieve a certificate for an encryption key 
from a server (or receive it inline from the peer who is the target 
of the message) prior to communication. But, for signed-only 
messages, passing cert chains and CRLs is still a reasonable strategy.

Steve