* Kevin J. McCarthy <ke...@8t8.us> [2015-05-16 18:41 -0400]:
My next step is fixing the add_cert problem with certificate chains.
I've been trying to gather enough round-tuits to try to dig into this, but haven't been successful so far. So thank you!
I'd appreciate if anyone is familiar with the "correct" way to deal with that problem: whether it's just re-ordering the certs so the leaf comes first, or splitting out the leaf and issuer certs. I have a commented out section in the program that implements the method from http://kb.wisc.edu/middleware/page.php?id=4091 but I'm not convinced that's the correct approach.
The logic of this has been bouncing around in my brain for a while, and
here are the possibilities I've designed in my head. Please poke holes
in these ideas, as I don't know if my answers are *correct* answers.
1. I think leaf certificates should be handled differently than issuer
certificates. This also allows implementation of a simple solution
first while a more complex solution is pondered... more about that
later.
2. The way of handling issuer certificates that I thought would be most
useful was based on the three possible scenarios regarding
certificate existence in the smime certificate repository.
a. Scenario 1 would be that the issuer (whether root or intermediate)
certificate does not exist in the smime certificate repository,
and is added after confirming that is the user's intent (possibly
with some user verification of the certificate).
b. Scenario 2 would be that the issuer certificate does exist in the
smime certificate repository, and both copies are identical, at
which point the certificate is not added and an informational note
is printed (similar to current behavior).
c. Scenario 3 would be that the issuer certificate does exist in the
smime certificate repository, and the copies are not identical, at
which point the user is warned that something fishy may be
happening, and no action is taken.
3. There are two issues with the leaf certificate(s) handling (there may
be more than one).
a. Do all of them get added to the repository? I don't know: is
there any use in having a copy of a certificate used by someone
else to sign messages? Especially when the certificates are often
included in the messages? I'm inclined to answer yes, but then
the second issue comes into play.
b. Should the key encipherment certificate be added to the repository
first as a rule, or should the order of addition depend on the
order in the message and, thus, be dependent on the MUA crafting
the message? The primary certificate that people will use when
communicating with other people (and thus using the certificate
repository we are discussing) is the certificate to be used for
key encipherment, not the certificate for digital signature. I
think the first certificate to be added to the repository (thus
the first certificate to be shown when presented with ordered list
of certificates) should be the certificate used for key
encipherment, while the digital signature certificate should be
added second.
As to the simple solution: if it's easier to add leaf certificate
handling *first*, and only add the issuer handling later, then the issue
of whether the issuer certificate should be added could be avoided until
that function is added to the script. I'm not sure if that optimization
is worth the time, but it's a thought.
Anyway, that's my two-cents at this point. I'm glad to get that out of
my head and into message format. Please poke holes in my logic and let
me know if you think this approach is reasonable.
Regards,
--
dave [ please don't CC me ]
signature.asc
Description: PGP signature
