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. >>> #: 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 >>> #: 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. -- Heikki Toivonen
signature.asc
Description: OpenPGP digital signature
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ Open Source Applications Foundation "Design" mailing list http://lists.osafoundation.org/mailman/listinfo/design
