P2
keytool is a very complicated piece of code, with lots of special
cases. The descriptions for the import sections were
written in a narrative style, and it would be MUCH more clear
if it were written in an outlined style.
I ran into a number of misconceptions about keytool because
I thought one topic applied to one mode, when it didn't.
In my particular case, the two sections on "importing certificates"
and "-import" should be rewritten to help tighten up the documention.
I might suggest using more HTML tags to help set off when
a topic is changing.
For example:
Importing certificates
To import a cert...
You can import a certificate for two reasons:
1) to add it to the list of trusted certs.
2) to import a certificate reply received from a CA
<these need to mention "trusted certificate entries" and "key entries"
respectively>
Which type of import is intended is indicated by the value
of the -alias option.
<should be rewritten...
If the alias specified does not exists in the database,
then keytool assumes you are doing 1). If it does exist,
then it assumes you are doing 2).
>
SubHeading for 1)
<insert description about 1>
WARNING...
SubHeading for 2)
<insert description about 2>
...skipping to -import...
First para is all right, but the rest needs work.
SubHeading for 1)
SubHeading for 2)
SubSubHeading for 2) when there is a single element reply
SubSubHeading for 2) when there is a chain of replies.
We also need to have a description about why single element
replies won't generate a prompt.
From Jan Luehe...
>Well, there is a subtle difference: In the first case, it is very
>hard (if not impossible) for the user to determine the authenticity
>of the received cert: When we prompt the user w/ the cert's hashcode,
>is the user supposed to call up Verisign and ask them whether the
>hashcode on their screen is accurate?
>
>In the second case, we prompt the user with the hashcode of
>the CA's cert, which is likely to be published in the newspaper
>or Verisign's website. This will make it easy for the user
>to verify the authenticity of the reply.
Thanks,
bradford.wetmore@eng 2000-12-20
cases. The descriptions for the import sections were
written in a narrative style, and it would be MUCH more clear
if it were written in an outlined style.
I ran into a number of misconceptions about keytool because
I thought one topic applied to one mode, when it didn't.
In my particular case, the two sections on "importing certificates"
and "-import" should be rewritten to help tighten up the documention.
I might suggest using more HTML tags to help set off when
a topic is changing.
For example:
Importing certificates
To import a cert...
You can import a certificate for two reasons:
1) to add it to the list of trusted certs.
2) to import a certificate reply received from a CA
<these need to mention "trusted certificate entries" and "key entries"
respectively>
Which type of import is intended is indicated by the value
of the -alias option.
<should be rewritten...
If the alias specified does not exists in the database,
then keytool assumes you are doing 1). If it does exist,
then it assumes you are doing 2).
>
SubHeading for 1)
<insert description about 1>
WARNING...
SubHeading for 2)
<insert description about 2>
...skipping to -import...
First para is all right, but the rest needs work.
SubHeading for 1)
SubHeading for 2)
SubSubHeading for 2) when there is a single element reply
SubSubHeading for 2) when there is a chain of replies.
We also need to have a description about why single element
replies won't generate a prompt.
From Jan Luehe...
>Well, there is a subtle difference: In the first case, it is very
>hard (if not impossible) for the user to determine the authenticity
>of the received cert: When we prompt the user w/ the cert's hashcode,
>is the user supposed to call up Verisign and ask them whether the
>hashcode on their screen is accurate?
>
>In the second case, we prompt the user with the hashcode of
>the CA's cert, which is likely to be published in the newspaper
>or Verisign's website. This will make it easy for the user
>to verify the authenticity of the reply.
Thanks,
bradford.wetmore@eng 2000-12-20