[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Request for Clarification of Usage of Certificate Request Payload to Maximimze Interoperability



-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Jan Vilhuber wrote:
> As was established by consensus at the bakeoff, an empty CERT_REQ
> payload means "send me any cert at all". See message:
> 
>      issues raised at VPN interoperability workshop, Dan Harkins
>      <dharkins@network-alchemy.com>, Tue, 18 Jan 2000 16:05:44
> -0800 (PST) 
> 
>        * What does an empty cert request payload mean?
> 
>        "give me a cert; any cert".
> 
> 
> Personally, I find that a bit hard to believe, since I might send
> you a certificate from CA FOOBAR, which you've never heard of, so
> I'm not sure what good an empty CERT_REQ will do you, but that was
> the consensus.
> 
> I guess if you are willing to send empty CERT_REQs you are implying
> that you can handle EVERY possible known CA on the planet (and
> beyond!).

Not at all.  It could also mean (as it does frequently in our case)
that I have 300 valid keys on my keyring and thus 300 possible valid
"CAs".  Unless our user has specified they want a specific cert/CA
for this gateway then any of those is valid.  Given the choice of
sending 300 cert reqs with DNs (eventually this logic overflows the
maximum UDP packet size) or sending one empty one and crossing
fingers, the latter seems the clear choice.  It all depends on the
context.  If my goal is opportunistic encryption in a more
web-of-trust like model, I'm willing to accept that anybody I have
verified as valid has signed the cert.  If I'm communicating with the
corporate gateway, my goal is to receive certs signed by a specific
CA or even a specific cert.


> - If we get an empty CERT_REQ, we won't honor it and fail the
> exchange 
>(probably not the right thing to do either, in light of the
>consensus mentioned above). I'll probably change that to send you
>the first one on my list (for whatever that's worth). Maybe I'll
>even keep a counter of how many times a certain cert was requested
>and send you the one that was LEAST requested, just so it doesn't
>feel left out ;)

That must be a recent change.  I've been sending empty cert-reqs to
Cisco IOS for at least a year on many different IOS versions and have
never had a problem exchanging certs.  If the two sides are
configured correctly, there's little reason to provide the DN.  I've
never seen an implementation which handled certs and did not properly
handle empty cert requests.

- -- Will

Will Price, Architect/Sr. Mgr., PGP Client Products
Total Network Security Division
Network Associates, Inc.


-----BEGIN PGP SIGNATURE-----
Version: PGP 7.0d21.120

iQA/AwUBOI6njqy7FkvPc+xMEQJP8ACg2d3ndOzHPydrS+/scjSR0BOMqzUAoKuV
ITdfi0cD1MWXgqf4HN7R4ILq
=XRb1
-----END PGP SIGNATURE-----


References: