3 short in-line replies...
On Jul 9, 2007, at 2:24 PM, Heikki Toivonen wrote:
Mimi Yin wrote:
#: parcels/osaf/framework/certstore/dialogs.py:160
msgid ""
"This certificate is already known but not trusted.\n"
"Do you want to trust this certificate?\n"
"SHA1 fingerprint: %s"
msgstr ""
*?? Can we say 'You have previously chosen not to trust this
certificate. Do you want to trust this certificate now?'*
I'd rather not make this change, as it may not be accurate to say
that
the user chose to not trust this certificate earlier.
What are other ways in which a certificate can be known? Just
trying to
look for ways to make that part of the sentence a bit more concrete.
Simply 'This certificate is already known...' feels kind of spooky
cuz
there's no knower and there's no explanation of how the knower
came to
know.
Did you write any of Rumsfeld's speeches? :)
The word 'known' mostly refers that it is known by Chandler (stored in
the repository), not necessarily known by the user.
The most likely scenario where this would happen is if the users
imported the certificate earlier and did not set the trust bits
then. I
wouldn't say they specifically decided not to trust it (why would they
have imported it if they didn't intend to trust it), but most likely
didn't know what they should have answered.
Probably the second most likely scenario is that the user could have
used the certificate manager to edit trust settings on some
certificates, marking them not trusted for some reason. The
certificate
manager displays trust as integer values, so ordinary users would have
no idea what trust each number meant.
I guess what I am trying to say is that perhaps 'known' is not the
best
possible word, but I don't think "You have previously chosen not to
trust this certificate. Do you want to trust this certificate now?" is
correct either.
So are we effectively saying that the user may have 'unwittingly' set
the trust bit to: don't trust.
You have seen this certificate before. You fiddled with some levers
which ended up putting this certificate in the not-trust pile. But
you probably didn't know what you were doing it...so here it is
again. Do you trust it or not?
Is that accurate? I'm not proposing that as the message, just trying
to get the story straight.
A different way to approach this: Is it important for the user to
know that the certificate is already known? Could we just gloss over
that part? Or, what's the significance of being already known? It
seems like the user barely knows of its existence.
#: parcels/osaf/framework/certstore/errors.py:24
#: parcels/osaf/framework/certstore/errors.py:51
msgid "Unable to get issuer certificate."
msgstr ""
*?? What's an issuer? Is it the 'Issuer-Certificate' field?
'Unable to
get issuer-certificate field.'*
All certificates are issued by somebody. The issuer also has a
certificate (=issuer certificate). This error is saying that we
could
not find the issuer's certificate for the certificate that we are
currently checking for correctness. So what the current text is
saying
is correct.
How do we know about the issuer without knowing about their
certificate?
Or I guess what is the issuer to the user? A sharing service? ISP?
Another user? Could we say: Unable to get certificate? I'm
wondering if
we're effectively saying: Unable to get the certificate-originator's
certificate; which feels redundant.
Every certificate has an issuer field, which contains some information
from the issuer certificate.
You cannot say "Unable to get certificate", because that would change
the meaning of the error.
Chandler ships with a bunch of root, or Certificate Authority (CA)
certificates. These are by definition self-signed, or self issued, and
we trust these certificates. Whenever Chandler does an SSL connection,
it receives one or more certificates (cert chain) from the server it
tries to connect to. If the chain goes unbroken from the server
certificate to one of the root certificates Chandler ships with, and
there are no errors with any of the certificates, everything works
silently. In other cases there will be warning or error dialogs.
The reason for the word 'chain' is that certificates really do form a
sort of a chain, where each certificate is linked to its issuer
with the
issuer field. For example:
0 subject:/O=hub.chandlerproject.org/OU=Domain Control
Validated/CN=hub.chandlerproject.org
issuer:/C=US/ST=Arizona/L=Scottsdale/O=GoDaddy.com,
Inc./OU=http://certificates.godaddy.com/repository/CN=Go Daddy Secure
Certification Authority/serialNumber=07969287
1 subject:/C=US/ST=Arizona/L=Scottsdale/O=GoDaddy.com,
Inc./OU=http://certificates.godaddy.com/repository/CN=Go Daddy Secure
Certification Authority/serialNumber=07969287
issuer:/C=US/O=The Go Daddy Group, Inc./OU=Go Daddy Class 2
Certification Authority
2 subject:/C=US/O=The Go Daddy Group, Inc./OU=Go Daddy Class 2
Certification Authority
issuer: /C=US/O=The Go Daddy Group, Inc./OU=Go Daddy Class 2
Certification Authority
Oy.
So is the issuer the server you're trying to connect with? Can we
say: 'Cannot get certificate from server or new server.'
If not then I give up, we should probably revisit this certificate
stuff post-preview.
#: parcels/osaf/framework/certstore/errors.py:30
msgid "Format error in certificate's notBefore field."
msgstr ""
#: parcels/osaf/framework/certstore/errors.py:31
msgid "Format error in certificate's notAfter field."
msgstr ""
*?? Can we say 'Certificate start time / end time is formatted
incorrectly.'*
It might not be strictly correct to change it to that wording. The
notBefore/notAfter fields are very clear in what is wrong. Also,
all of
the error strings in error.py come directly from OpenSSL, so it is
likely there already are ready translations for these strings
somewhere.
It just took me a while to understand that notBefore/notAfter
referred
to time limits on the certificate. Do you have any ideas on how to
phrase this error message without using technical terminology? Is
time
limit an accurate way to describe the notBefore and notAfter
settings?
I just don't think we should go and change this. AFAIK this error is
very unlikely to happen. It would mean that the issuer of the
certificate almost certainly made a mistake, and that the certificate
would almost certainly not work in any software that actually checked
the notBefore/notAfter fields (and practically all do check them).
Just about the only person I could even remotely expect to see this is
someone who runs their own Cosmo server who created their own bad SSL
certificate for the server, and then tested if it worked in Chandler.
Telling them straight that the notBefore/notAfter fields are incorrect
would be more helpful than giving a 'nicer' error message that they
would have to interpret first. notBefore and notAfter are specified in
the certificate specifications, so they are clear to anyone working
with
certificates, and like I said, I think those would be the only people
I'd ever expect to see this error string.
Ok, sounds reasonable if this is really a hacker error message.
--
Heikki Toivonen
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
Open Source Applications Foundation "Design" mailing list
http://lists.osafoundation.org/mailman/listinfo/design
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
Open Source Applications Foundation "Design" mailing list
http://lists.osafoundation.org/mailman/listinfo/design
