Re: Publishing CA information documents in PDF format

[Kyle Hamilton]

Eddy's gone ahead and sent a signed PDF, according to a later message
in-thread.  I expect that it'll work without a hitch, though I would
like to hear of any anomalous behavior. :)

But, I'm struck again by a couple of questions.

Why does everything have to have an explicit 'threat model' before
cryptography can be applied?  In my view, cryptography is useful for
MUCH more than just "protecting against potential attack".  (It's not
like we're trying to protect secrets with national security
implications.  It's not like we're trying to protect a financial
instrument.  It's not even like we're trying to keep an affair
secret.)

As I've said before, I view cryptography as a means of associating a
policy with data.  The policy in this case would be: this is a
document version that someone working on behalf of Mozilla (currently
-- and with the tenacity and thoroughness she's exhibited, hopefully
for a LONG time -- Kathleen) prepared, it hasn't been corrupted, and
it's got a timestamp so that later revisions can be identified as
such.  Cryptography can give me a very good idea that these three
concepts can be relied upon.

It doesn't have to be a "legal document".  It doesn't need a
contract-grade (i.e., Qualified Certificate in PKIX and EU parlance)
signature on it.  All that I need to know is that what I'm reading is
the actual working document with a means of determining if there's a
newer one, and a digisig countersigned by a timestamp authority is a
perfect means of accomplishing this.

Why does it have to be any more complex than this?  Why does there
have to be any more "meaning" assigned to the act of digitally signing
something?  (Why do we always treat the concept of digital signatures
as though we're signing away our firstborn?  What are we so afraid of?
 That fear-among-the-experts is part of what makes cryptography so
inaccessible to the common user, and reduces confidence in the system
-- which leads to a lack of use, which leads to a dearth of innovation
in application.)

-Kyle H

On Wed, Dec 17, 2008 at 11:14 AM, Frank Hecker
 wrote:
> Kyle Hamilton wrote:
>>
>> Actually, the 'threat model' is more related to versioning (via
>> timestamp) than anything, and to ensure that no malware on my system
>> (I try to keep it malware-free, obviously, but I also know that just
>> because I don't think I've been hacked doesn't mean I haven't been)
>> modifies a local copy I make.
>
> Ah, OK. Well, if signing PDF documents doesn't interfere with viewing them
> on non-Adobe software then I'm willing to have us consider doing it. Could
> you or someone else send me a sample signed PDF document via email? Since
> I'm running a Mac with VMware Fusion I can check it out on a variety of
> platforms with different PDF readers.
>
> Frank
>
> --
> Frank Hecker
> hec...@mozillafoundation.org
> ___
> dev-tech-crypto mailing list
> dev-tech-crypto@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-tech-crypto
>
___
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto

Re: Publishing CA information documents in PDF format

[Anders Rundgren]

Kyle,
I fully agree with your conclusions.
IMO a signature's primary function is to provide a mark of authenticity
to something.  If the signature is associated with an unknown signer
the value of the signature becomes rather limited.

The Qualified Certificate concept is based on the strange idea that
because the CA is liable to very high amounts of money, you can
"trust" such signatures and thus do advanced business with total
strangers.  What the designers of QC didn't think of is that anybody
can get a QC without being checked to be a good payer, dependable
vendor, etc.  If there is discomfort in a business relation, the CA has
no means to rectify things making the value of the high liability very limited.

IF people started to believe that QC actually works as described we would
soon be in a very bad position since a single disgruntled employee could
send "fully authorized" POs all-over-the-map.

PKIX took this to another extreme by publishing an informational standard
for liability with is one of the most ridiculous things I have ever seen
http://www.ietf.org/rfc/rfc4059.txt
since it doesn't deal with accumulation!!!  The motive behind this RFC
was "to increase the acceptance of certificates" :-)

Anders

- Original Message - 
From: "Kyle Hamilton" 
To: "mozilla's crypto code discussion list" 
Sent: Thursday, December 18, 2008 12:09
Subject: Re: Publishing CA information documents in PDF format


Eddy's gone ahead and sent a signed PDF, according to a later message
in-thread.  I expect that it'll work without a hitch, though I would
like to hear of any anomalous behavior. :)

But, I'm struck again by a couple of questions.

Why does everything have to have an explicit 'threat model' before
cryptography can be applied?  In my view, cryptography is useful for
MUCH more than just "protecting against potential attack".  (It's not
like we're trying to protect secrets with national security
implications.  It's not like we're trying to protect a financial
instrument.  It's not even like we're trying to keep an affair
secret.)

As I've said before, I view cryptography as a means of associating a
policy with data.  The policy in this case would be: this is a
document version that someone working on behalf of Mozilla (currently
-- and with the tenacity and thoroughness she's exhibited, hopefully
for a LONG time -- Kathleen) prepared, it hasn't been corrupted, and
it's got a timestamp so that later revisions can be identified as
such.  Cryptography can give me a very good idea that these three
concepts can be relied upon.

It doesn't have to be a "legal document".  It doesn't need a
contract-grade (i.e., Qualified Certificate in PKIX and EU parlance)
signature on it.  All that I need to know is that what I'm reading is
the actual working document with a means of determining if there's a
newer one, and a digisig countersigned by a timestamp authority is a
perfect means of accomplishing this.

Why does it have to be any more complex than this?  Why does there
have to be any more "meaning" assigned to the act of digitally signing
something?  (Why do we always treat the concept of digital signatures
as though we're signing away our firstborn?  What are we so afraid of?
 That fear-among-the-experts is part of what makes cryptography so
inaccessible to the common user, and reduces confidence in the system
-- which leads to a lack of use, which leads to a dearth of innovation
in application.)

-Kyle H

On Wed, Dec 17, 2008 at 11:14 AM, Frank Hecker
 wrote:
> Kyle Hamilton wrote:
>>
>> Actually, the 'threat model' is more related to versioning (via
>> timestamp) than anything, and to ensure that no malware on my system
>> (I try to keep it malware-free, obviously, but I also know that just
>> because I don't think I've been hacked doesn't mean I haven't been)
>> modifies a local copy I make.
>
> Ah, OK. Well, if signing PDF documents doesn't interfere with viewing them
> on non-Adobe software then I'm willing to have us consider doing it. Could
> you or someone else send me a sample signed PDF document via email? Since
> I'm running a Mac with VMware Fusion I can check it out on a variety of
> platforms with different PDF readers.
>
> Frank
>
> --
> Frank Hecker
> hec...@mozillafoundation.org
> ___
> dev-tech-crypto mailing list
> dev-tech-crypto@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-tech-crypto
>
___
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto
___
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto

Re: Publishing CA information documents in PDF format

[Eddy Nigg]

On 12/18/2008 01:09 PM, Kyle Hamilton:


Why does everything have to have an explicit 'threat model' before
cryptography can be applied?  In my view, cryptography is useful for
MUCH more than just "protecting against potential attack".


Kile, I think that's correct and the protection/confirmation/assurance 
you are seeking are perfectly valid reasons for signing. By no means 
must signing a document have always military-style, executable legal 
implications. Intend and content matter in such cases.


I'm signing my mail usually in order to confirm that it's from me and 
that it wasn't modified. I usually also take care that I can stand 
behind what I write and would dispute something taken out of context or 
that an email would bind me legally in a similar way an explicit 
contract would. For such I write contracts (which I may eventually sign 
digitally too).


I this context I believe that a signature with a Class 1 certificate 
would certainly have no legal meaning, whereas Class 2 or higher might 
have if used in the corresponding context (sorry for freely applying 
StartCom jargon here). This however depends also on the local 
legislation of course.



--
Regards

Signer: Eddy Nigg, StartCom Ltd.
Jabber: start...@startcom.org
Blog:   https://blog.startcom.org
___
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto

Re: Publishing CA information documents in PDF format

[Frank Hecker]

Kyle Hamilton wrote:

Eddy's gone ahead and sent a signed PDF, according to a later message
in-thread.  I expect that it'll work without a hitch, though I would
like to hear of any anomalous behavior. :)


It did indeed work without problems. I was able to read the document 
successfully with a variety of PDF viewers (Adobe Reader 9 on OS X, 
Preview on OS X, and Evince on Ubuntu and Red Hat). However the 
signature could actually be verified only using Acrobat Reader; the 
other viewers apparently don't have digsig capabilities. (Is this 
present in any PDF viewers other than Adobe's?)


Also, for reference, in order to verify the signature I had to do the 
following:


1. Get the root CA cert for Startcom, because Eddy (of course) was using 
a Startcom-issued certificate to do the signing. (As mentioned 
previously, the only root pre-loaded into Adobe Reader is Adobe's.)


2. Import the root cert into Adobe Reader. On the Mac this is done using 
the "Manage Trusted Identities..." menu item on the "Document" menu. 
Then you have to click the "Add Contacts" button (which I found somewhat 
confusing) and then the "Browse..." button to find the cert.


3. Mark the root as a trusted root. This is done from the "Manage 
Trusted Indenties..." dialog by selecting "Certificates" from the 
"Display" popup menu, selecting the cert, and then clicking "Edit 
Trust..." and then check the "Use this certificate as a trusted root" 
checkbox.


4. You also have to check the "Certified documents" checkbox. (In the 
"If signature validation succeeds, trust this certificate for..." 
section.) I found this a bit confusing as well; I don't know what the 
distinction between "signed documents" and "certified documents" means 
in the context of Adobe Acrobat and Adobe Reader, and I've asked Eddy to 
provide more information on this.


At this point you should be able to open the documents on Eddy's site at

  https://www.startssl.com/?app=26

with Adobe Reader and open the "signature panel" to verify the signature.

You can apparently create signed PDF documents using Adobe Acrobat 9 
Standard; Eddy says there are free signing utilities than be used also, 
but I don't have references for those right now.



Why does everything have to have an explicit 'threat model' before
cryptography can be applied?


Well, it doesn't necessarily. My concern in this case had more to do 
with justifying any extra work that might be involved on our end in 
terms of getting the documents signed; I was also concerned that signng 
might mess up reading the documents on non-Adobe software (a concern 
that turned out to be misplaced).


Frank

--
Frank Hecker
hec...@mozillafoundation.org
___
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto

Re: Publishing CA information documents in PDF format

[David E. Ross]

 > On Wed, Dec 17, 2008 at 11:14 AM, Frank Hecker
>  wrote:
>> Kyle Hamilton wrote:
>>> Actually, the 'threat model' is more related to versioning (via
>>> timestamp) than anything, and to ensure that no malware on my system
>>> (I try to keep it malware-free, obviously, but I also know that just
>>> because I don't think I've been hacked doesn't mean I haven't been)
>>> modifies a local copy I make.
>> Ah, OK. Well, if signing PDF documents doesn't interfere with viewing them
>> on non-Adobe software then I'm willing to have us consider doing it. Could
>> you or someone else send me a sample signed PDF document via email? Since
>> I'm running a Mac with VMware Fusion I can check it out on a variety of
>> platforms with different PDF readers.
On 12/18/2008 3:09 AM, Kyle Hamilton wrote:
> Eddy's gone ahead and sent a signed PDF, according to a later message
> in-thread.  I expect that it'll work without a hitch, though I would
> like to hear of any anomalous behavior. :)
>
> But, I'm struck again by a couple of questions.
>
> Why does everything have to have an explicit 'threat model' before
> cryptography can be applied?  In my view, cryptography is useful for
> MUCH more than just "protecting against potential attack".  (It's not
> like we're trying to protect secrets with national security
> implications.  It's not like we're trying to protect a financial
> instrument.  It's not even like we're trying to keep an affair
> secret.)
>
> As I've said before, I view cryptography as a means of associating a
> policy with data.  The policy in this case would be: this is a
> document version that someone working on behalf of Mozilla (currently
> -- and with the tenacity and thoroughness she's exhibited, hopefully
> for a LONG time -- Kathleen) prepared, it hasn't been corrupted, and
> it's got a timestamp so that later revisions can be identified as
> such.  Cryptography can give me a very good idea that these three
> concepts can be relied upon.
>
> It doesn't have to be a "legal document".  It doesn't need a
> contract-grade (i.e., Qualified Certificate in PKIX and EU parlance)
> signature on it.  All that I need to know is that what I'm reading is
> the actual working document with a means of determining if there's a
> newer one, and a digisig countersigned by a timestamp authority is a
> perfect means of accomplishing this.
>
> Why does it have to be any more complex than this?  Why does there
> have to be any more "meaning" assigned to the act of digitally signing
> something?  (Why do we always treat the concept of digital signatures
> as though we're signing away our firstborn?  What are we so afraid of?
>  That fear-among-the-experts is part of what makes cryptography so
> inaccessible to the common user, and reduces confidence in the system
> -- which leads to a lack of use, which leads to a dearth of innovation
> in application.)

Actually, a digital signature DOES NOT necessarily guard a document from
attack.  An attacker might still be able to delete a signed document.

A digital signature assures integrity, allowing the reader to determine
if the document has been altered.  An alteration might NOT be an attack;
it could instead be merely a dropped bit during transmission.

A digital signature also assures authenticity, allowing the reader to
verify that the document indeed originated with (or passed through the
possession of) the person who signed it.

I don't think either integrity or authenticity are an issue with
attachments to Bugzilla reports.  Those two issues are well handled by
the fact that Bugzilla operates under SSL.  Thus, signatures should not
be required for PDF documents.

-- 
David E. Ross


Go to Mozdev at  for quick access to
extensions for Firefox, Thunderbird, SeaMonkey, and other
Mozilla-related applications.  You can access Mozdev much
more quickly than you can Mozilla Add-Ons.
___
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto

Re: Publishing CA information documents in PDF format

[Ian G]

On 18/12/08 12:09, Kyle Hamilton wrote:

Eddy's gone ahead and sent a signed PDF, according to a later message
in-thread.  I expect that it'll work without a hitch, though I would
like to hear of any anomalous behavior. :)

But, I'm struck again by a couple of questions.

Why does everything have to have an explicit 'threat model' before
cryptography can be applied?



Because otherwise we don't know what to protect against, and we end up 
reaching for the grab bag of things that are known to be protected by 
crypto, rather than what the user wants.


Classic case:  PKI view is that you want to protect the authenticity of 
the identity.  But in some scenarios, this is a threat not a protection. 
 For example, consider self-help chat message boards where people can 
sign up using a nymous name like "PuddleBlob" and talk about difficult 
things.  The net has created this wonderful ability for people who have 
problems to talk about them, but they can only do this in conditions of 
safety, which to them means anonymity and/or untraceability.  Think 
Alcholics Anonymous, or divorced women.


So, PKI is the precise wrong thing for them, because it identifies them 
and tries (badly) to ensure that they are traceable.


A deeper more nuanced view would be that once we identify a thing that 
needs protecting, then we still have to compare the costs of the threat 
with the costs of the protection.  For example, MITM is in this camp; 
the protection for MITM in say secure browsing is too expensive, given 
that only in the last year or so (recent K case) have we seen any real 
evidence of attacks.  Without a costs based analysis, any sense of 
"protect against X" lacks foundation.


The other aspect that must be considered is that threat models and 
security models are notoriously fickle and complicated, so even if you 
do them, you could be wrong;  often it is more economic to forget the 
security modelling, and run with what works well for now.  Fix up the 
bugs later.




In my view, cryptography is useful for
MUCH more than just "protecting against potential attack".


Er, what else is there?


(It's not
like we're trying to protect secrets with national security
implications.  It's not like we're trying to protect a financial
instrument.  It's not even like we're trying to keep an affair
secret.)



I don't know about that;  sometimes we are, sometimes not.  In my work, 
the second.  I've seen the third, and alluded to it above.  Protecting 
national security:  no, that is pointless for us, let them do that.


Although, funny story:  the guy who deals with the CIA wiki presented 
recently (I forget his name) and he said that one day, an IT department 
programmer got annoyed at the standard browser which was out of date, so 
he downloaded Firefox onto a local private server for programmers only. 
 It quickly spread to other programmers ... and then out of the local 
environment.  The security people raised hell, because it was 
unauthorised, but by then it was too late, the Firefox virus was 
spreading throughout the CIA.  Within one year, Firefox had taken over 
and forced the security people to declare defeat and make it the 
official browser.  Regardless of any analysis that they could do...


Sometimes users tell us stuff, but are we able to listen?



As I've said before, I view cryptography as a means of associating a
policy with data.


Well.  You might want to consider a wider view like financial 
cryptography :)




The policy in this case would be: this is a
document version that someone working on behalf of Mozilla (currently
-- and with the tenacity and thoroughness she's exhibited, hopefully
for a LONG time -- Kathleen) prepared, it hasn't been corrupted, and
it's got a timestamp so that later revisions can be identified as
such.  Cryptography can give me a very good idea that these three
concepts can be relied upon.



Hopelessly unreliable, in my opinion.  Crypto will tell you that someone 
with "Kathleen's key" made that PDF, but some time later we might 
discover that Kathleen now works for Microsoft.  Nobody bothered to 
replace the key, because it worked.  Working practices are better than 
halted practices, don't break something that isn't broken!




It doesn't have to be a "legal document".  It doesn't need a
contract-grade (i.e., Qualified Certificate in PKIX and EU parlance)
signature on it.  All that I need to know is that what I'm reading is
the actual working document with a means of determining if there's a
newer one, and a digisig countersigned by a timestamp authority is a
perfect means of accomplishing this.



Yeah, it's "indication grade."  It's not reliable enough to write home 
about.  There are many weaknesses, and scores of papers listing them.




Why does it have to be any more complex than this?  Why does there
have to be any more "meaning" assigned to the act of digitally signing
something?


There always has to be a meaning.  Otherwise we wouldn't do it?  The 
problem is

Re: Publishing CA information documents in PDF format

[Ian G]

On 18/12/08 13:20, Anders Rundgren wrote:

Kyle,
I fully agree with your conclusions.
IMO a signature's primary function is to provide a mark of authenticity
to something.  If the signature is associated with an unknown signer
the value of the signature becomes rather limited.

The Qualified Certificate concept is based on the strange idea that
because the CA is liable to very high amounts of money, you can
"trust" such signatures and thus do advanced business with total
strangers.



This is based on the monetary view of reliability, in that it is only 
worth what you can get for it.  Standard finance principle.  If there is 
nothing, it is worth nothing;  if you can do harm X then it is worth X, 
potentially;  if you can get Y then it is worth Y, potentially.


(Case in point about a year ago, oh how soon we forget, is S&P, Moodys 
and the rating agencies.)


This I find to be quite a valid view, and it is widely used in the 
corporate and finance world, c.f., NPV, MTM, CAPM, where numbers are 
called for.  Although it certainly doesn't explain all of contracts & 
agreement behaviour.


Whether you can take that monetary number and relate that to "trust" is 
a whole other discussion...


And, we probably agree that the end result with Qualified certificates 
is likely to show the same as with non-QCs, in that the resultant value 
to relying party in objective monetary terms is zero.  (In other posts I 
have expressed the opinion that the expected liability is zero, which is 
another way of saying it.)




What the designers of QC didn't think of is that anybody
can get a QC without being checked to be a good payer, dependable
vendor, etc.  If there is discomfort in a business relation, the CA has
no means to rectify things making the value of the high liability very limited.

IF people started to believe that QC actually works as described we would
soon be in a very bad position since a single disgruntled employee could
send "fully authorized" POs all-over-the-map.



Yes.  But companies and people are generally smarter than that.  They 
know the monetary value is zero, and non-monetarised values are limited 
to the regulated needs, in general.




PKIX took this to another extreme by publishing an informational standard
for liability with is one of the most ridiculous things I have ever seen
http://www.ietf.org/rfc/rfc4059.txt
since it doesn't deal with accumulation!!!  The motive behind this RFC
was "to increase the acceptance of certificates" :-)



Perhaps you could explain what you mean by accumulation?  I skimmed 
through that document, and had my own qualms.


Q:  does any CA actually use that extension?  Does any code display the 
extension?


I note that it "must be non-critical" which I find amusing :)

iang
___
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto

Re: Publishing CA information documents in PDF format

[Eddy Nigg]

On 12/18/2008 05:15 PM, David E. Ross:

Actually, a digital signature DOES NOT necessarily guard a document from
attack.  An attacker might still be able to delete a signed document.


I'm not aware of any PKI solution that protects from deletion. That 
would have to be handled properly on the file system (and access 
thereof). However file systems can be encrypted these days easily, and 
the protection happens elsewhere.




A digital signature assures integrity, allowing the reader to determine
if the document has been altered.  An alteration might NOT be an attack;
it could instead be merely a dropped bit during transmission.



Oh yes, you'd certainly like to know about it (and why that d*** file 
doesn't open) :-)




I don't think either integrity or authenticity are an issue with
attachments to Bugzilla reports.  Those two issues are well handled by
the fact that Bugzilla operates under SSL.  Thus, signatures should not
be required for PDF documents.



Kyle's use case would be rather of saving the files on the local 
computer. Even though I also believe that the reports are as save as 
Bugzilla can be, it might present a certain stance (for our group), but 
also prevent from modification obviously. Not the highest priority, 
still interesting to play with it...



--
Regards

Signer: Eddy Nigg, StartCom Ltd.
Jabber: start...@startcom.org
Blog:   https://blog.startcom.org
___
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto

Re: Publishing CA information documents in PDF format

[Eddy Nigg]

On 12/18/2008 05:06 PM, Frank Hecker:

You can apparently create signed PDF documents using Adobe Acrobat 9
Standard; Eddy says there are free signing utilities than be used also,
but I don't have references for those right now.



Eddy is using a slightly modified version of this: 
http://sourceforge.net/project/showfiles.php?group_id=181271&package_id=209885



--
Regards

Signer: Eddy Nigg, StartCom Ltd.
Jabber: start...@startcom.org
Blog:   https://blog.startcom.org
___
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto

Re: Publishing CA information documents in PDF format

[Eddy Nigg]

On 12/18/2008 05:29 PM, Ian G:


Hopelessly unreliable, in my opinion. Crypto will tell you that someone
with "Kathleen's key" made that PDF, but some time later we might
discover that Kathleen now works for Microsoft. Nobody bothered to
replace the key, because it worked.



Well, I think I start to understand some of your (wrong) views about PKI 
and cryptography thenWhy should Kathleen's keys be replaced and why 
do you think anybody except Kathleen would be able to sign her 
documents? TIsn't that truly basic?


I'm somewhat at at loss, but do you think the same applies to S/MIME as 
well?


--
Regards

Signer: Eddy Nigg, StartCom Ltd.
Jabber: start...@startcom.org
Blog:   https://blog.startcom.org
___
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto

Re: SECOM Trust EV root inclusion request

[István Zsolt BERTA]

> Ian G wrote re CPSs not available in English:
>
>> Which leads to the first easy fix:  insist that all non-english CAs
>>  translate all their docs.  Then I can read the CPS!  I personally
>> am unsatisfied at that, I see flaws.
>
>> 1.  Frank has made the case for regional and local CAs.  The web is
>>  wide, and CPSs are very long documents.  So I think translating
>> *all* important documents to english is not only impractical but
>> also discriminatory, as non-english cultures (most of them) will
>> then face a barrier that the english do not do not.
>
> I'll differ from you somewhat here. As a practical matter browser
> vendors are a major audience for a CA's CPS, along with the CA's
> auditor, possibly government agencies concerned with the CA's
> operations, and whoever else might care to read it. I can understand
> a CA issuing its CPS in the native language of the country in which
> it operates; that's probably the best strategy to make sure the
> document is properly understood by relevant government agencies and
> by its auditors (if they're local).
>
> However if a CA doesn't offer an English translation of its CPS and
> other relevant documents then it disadvantages browser vendors and
> other application software vendors who might be interested in
> supporting use of the CA's certificates. I don't support making it
> mandatory that CAs provide an English version of the CPS, but I have
> no problem with telling CAs that not having an English version will
> likely cause delays with their application.


Perhaps, making such (discriminatory) criteria mandatory could still
be better than enforcing it without stating it clearly.

Our CA (Microsec Ltd, a leading CA in Hungary) submitted its inclusion
request February 2007.
https://bugzilla.mozilla.org/show_bug.cgi?id=370505
Our first public discussion phase was opened October 2008,
http://groups.google.com/group/mozilla.dev.tech.crypto/browse_thread/thread/416427a350db11a9#
this public discussion has been postponed, scheduled again and it seem
to be postponed again. I think, only the language of our documentation
remains the only open issue today.

Had we known that in order to be accepted to Mozilla, we MUST/SHOULD
submit either an English translation of our CPS/CPSs or we need to
maintain our complete documentation in English, perhaps we would have
made different decisions in the past two years. Our primary focus are
electronic signatures; browsers and SSL certificates are a marginal
issue for us. While submitting the English translation of a snapshot
of our documentation may be impractical and costly, maintaining a
complete documentation both in English and in Hungarian is a major
investment that shall perhaps never be justified.

Had we known that English documentation is a requirement, we could
have chosen to fulfill it by submitting a translation, we could have
sought other way to sell certificates accepted by Mozilla, or we could
have decided to forget about the Mozilla-inclusion-issue and to advise
the Hungarian public to use Explorer instead. Mozilla has the right to
determine the requirements for including CAs, but if this is a
requirement, then why it is not stated, why it is not public?

Being a long-term Mozilla fan, I am really sorry to say that the same
procedure at Microsoft was faster, much better defined, less ad hoc,
and a lot more transparent.

Regards,

István
___
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto

CA liability. was: Publishing CA information documents in PDF format

[Anders Rundgren]

CA liability has been focused on the RP since it an RP that "trusts" a CA
and its certificates, right?

A problem with this notion is that there is no end to what a wrongly certified
entity could cause in damages, particularly not for "eID" kind of certificates
that potentially opens any number of doors.  The obsession with signatures
has also been extremely contra productive;  authentication is 100 times more
important since it cannot be "rolled back", "repudiated" etc.

IMO it would be more reasonable to make CA liability an affair between
the subject subject (subscriber) than towards unknown RPs.  In some
way I understand why banks when acting as CAs essentially *never*
accept dealing with unknown RPs...

Regarding "accumulation" in the referred PKIX RFC, I mean the sum of
all transactions, break-ins etc. an incorrectly certified entity could perform.
At least from a CA liability point of view that's the most interesting part.

An identity certificate <<>> credit card because only the latter allows
comparatively simple damage control using account monitoring.

Anders

- Original Message - 
From: "Ian G" 
To: "mozilla's crypto code discussion list" 
Sent: Thursday, December 18, 2008 17:00
Subject: Re: Publishing CA information documents in PDF format


On 18/12/08 13:20, Anders Rundgren wrote:
> Kyle,
> I fully agree with your conclusions.
> IMO a signature's primary function is to provide a mark of authenticity
> to something.  If the signature is associated with an unknown signer
> the value of the signature becomes rather limited.
>
> The Qualified Certificate concept is based on the strange idea that
> because the CA is liable to very high amounts of money, you can
> "trust" such signatures and thus do advanced business with total
> strangers.


This is based on the monetary view of reliability, in that it is only 
worth what you can get for it.  Standard finance principle.  If there is 
nothing, it is worth nothing;  if you can do harm X then it is worth X, 
potentially;  if you can get Y then it is worth Y, potentially.

(Case in point about a year ago, oh how soon we forget, is S&P, Moodys 
and the rating agencies.)

This I find to be quite a valid view, and it is widely used in the 
corporate and finance world, c.f., NPV, MTM, CAPM, where numbers are 
called for.  Although it certainly doesn't explain all of contracts & 
agreement behaviour.

Whether you can take that monetary number and relate that to "trust" is 
a whole other discussion...

And, we probably agree that the end result with Qualified certificates 
is likely to show the same as with non-QCs, in that the resultant value 
to relying party in objective monetary terms is zero.  (In other posts I 
have expressed the opinion that the expected liability is zero, which is 
another way of saying it.)


> What the designers of QC didn't think of is that anybody
> can get a QC without being checked to be a good payer, dependable
> vendor, etc.  If there is discomfort in a business relation, the CA has
> no means to rectify things making the value of the high liability very 
> limited.
>
> IF people started to believe that QC actually works as described we would
> soon be in a very bad position since a single disgruntled employee could
> send "fully authorized" POs all-over-the-map.


Yes.  But companies and people are generally smarter than that.  They 
know the monetary value is zero, and non-monetarised values are limited 
to the regulated needs, in general.


> PKIX took this to another extreme by publishing an informational standard
> for liability with is one of the most ridiculous things I have ever seen
> http://www.ietf.org/rfc/rfc4059.txt
> since it doesn't deal with accumulation!!!  The motive behind this RFC
> was "to increase the acceptance of certificates" :-)


Perhaps you could explain what you mean by accumulation?  I skimmed 
through that document, and had my own qualms.

Q:  does any CA actually use that extension?  Does any code display the 
extension?

I note that it "must be non-critical" which I find amusing :)

iang
___
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto
___
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto

Re: SECOM Trust EV root inclusion request

[Eddy Nigg]

On 12/18/2008 07:14 PM, István Zsolt BERTA:


Had we known that English documentation is a requirement, we could
have chosen to fulfill it by submitting a translation, we could have
sought other way to sell certificates accepted by Mozilla, or we could
have decided to forget about the Mozilla-inclusion-issue and to advise
the Hungarian public to use Explorer instead. Mozilla has the right to
determine the requirements for including CAs, but if this is a
requirement, then why it is not stated, why it is not public?



István, even though I understand your frustration and agree with the 
basic understanding that requirements should be published accordingly, I 
also must state there has been at least one issue (notably with your 
OCSP responder I think) in addition to our inability simply not to be 
able to read the CP/CPS. As more and more CAs from Non-English speaking 
countries are applying for inclusion, Mozilla will have to find a 
solution (in this or the other way). Please note that many CAs from such 
countries publish their CP/CPS in English, sometimes in addition to 
their native language. This is in my opinion expected behavior and 
practice in this industry - specially if the CA is supposed to be 
included in a product used to be world-wide and hence the relying parties.




Being a long-term Mozilla fan, I am really sorry to say that the same
procedure at Microsoft was faster, much better defined, less ad hoc,
and a lot more transparent.


Agreed, Microsoft is a professional company which doesn't involve any 
input from a community as with Mozilla. But how did they verify and 
understand your CP/CPS? Did they rely solemnly on the audit report? Does 
your OCSP responder not present a problem to them?



--
Regards

Signer: Eddy Nigg, StartCom Ltd.
Jabber: start...@startcom.org
Blog:   https://blog.startcom.org

___
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto

A tip for novice users of SSL_BadCertHook and SSL_PeerCertificate

[DanKegel]

http://www.mozilla.org/projects/security/pki/nss/ref/ssl/sslfnc.html#1088928
says "To obtain the certificate that was rejected by the certificate
authentication callback, the callback function calls
SSL_PeerCertificate."

And it really does mean the callback function.  Once that returns, the
information is destroyed, and SSL_PeerCertificate will fail.

This seems obvious in retrospect.  Just posting here in case anyone
else trips on this.
___
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto

Re: Publishing CA information documents in PDF format

[Ian G]

On 18/12/08 17:47, Eddy Nigg wrote:

On 12/18/2008 05:29 PM, Ian G:


Hopelessly unreliable, in my opinion. Crypto will tell you that someone
with "Kathleen's key" made that PDF, but some time later we might
discover that Kathleen now works for Microsoft. Nobody bothered to
replace the key, because it worked.



Well, I think I start to understand some of your (wrong) views about PKI
and cryptography then



Hilarious!


Why should Kathleen's keys be replaced and why
do you think anybody except Kathleen would be able to sign her
documents? TIsn't that truly basic?



It is truly basic, it is how business works.

It would start out that a certain PC is designated the place where all 
the relevent work is done.  (Why this is done and not a net storage I'll 
leave as an exercise for the reader.)  A single work account is created 
that was originally in Kathleen's name.  As we know, modern OSs allow 
default login, or don't require the user's name.  The account is set up 
with the keys required.


(BTW, I will say that I am totally speculating and miss-using Kathleen's 
good name here.  I have no idea how they do it at Mozilla, maybe she 
spends her lunchtime factoring large prime numbers for all I know.)


Later on, because Kathleen has to go on holidays (vacations for 
americans) and is asked to write down some simple instructions for Karen 
who will cover her.  Perhaps they work, perhaps not, and perhaps the 
local techie has to pop on up and add to them.


Later on again, the instructions are enhanced so that Kevin can also do 
the work ... so Karen can go to a conference?  After a while, Kathleen 
is transferred to another position.


Meanwhile, the PC stays the same.  That's where the data is.  That's 
where the work is done.


Basically, the normal office people have no idea what the PKI model is. 
 They just want a system that works.  If the boss says "follow this 
sequence to upload the PDF-with-thingummyjig" then they'll do it.


I believe the current top contender for this was the entire British 
health services.  From what I know, they issued smart card (with certs) 
to all people, and organised all the restricted equipment to have smart 
card readers and authorisation lists and so forth.  Later on, auditors 
discovered that the working practice was for the senior doctors to 
insert their smart cards in the most important equipment, and then leave 
them in there ...




I'm somewhat at at loss, but do you think the same applies to S/MIME as
well?



"The same" means what, precisely?  I have said many times that human 
signing should not be done in S/MIME with the S/MIME keys until the 
meanings and protocols are sorted out, and clear.


That someone would use another user's S/MIME keys to sign emails?  Well, 
of course.  Secretaries are employed for just this purpose, they always 
do letters in their boss's name.  If Kathleen has a secretary called 
Kevin, then it is entirely plausible that Kevin will manage Kathleen's 
keys and Kathleen won't necessarily do anything at all.




iang
___
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto

Re: SECOM Trust EV root inclusion request

[Ian G]

On 18/12/08 18:14, István Zsolt BERTA wrote:

I'll differ from you somewhat here. As a practical matter browser
vendors are a major audience for a CA's CPS, along with the CA's
auditor, possibly government agencies concerned with the CA's
operations, and whoever else might care to read it. I can understand
a CA issuing its CPS in the native language of the country in which
it operates; that's probably the best strategy to make sure the
document is properly understood by relevant government agencies and
by its auditors (if they're local).



(I agree with that!)


However if a CA doesn't offer an English translation of its CPS and
other relevant documents then it disadvantages browser vendors and
other application software vendors who might be interested in
supporting use of the CA's certificates. I don't support making it
mandatory that CAs provide an English version of the CPS, but I have
no problem with telling CAs that not having an English version will
likely cause delays with their application.


(And I can't disagree with that!)

On to István's comments:


Perhaps, making such (discriminatory) criteria mandatory could still
be better than enforcing it without stating it clearly.



I don't think this criteria exists.  I for one would not like it.  But, 
there is, IMO, a need for something, and something short and simple was 
what I was exploring.


I would point out that all my comments are aimed at the future.  I 
wouldn't want to slow down any current contender.  You seem to meet the 
rules and practices, so no need to dwell on this.




Being a long-term Mozilla fan, I am really sorry to say that the same
procedure at Microsoft was faster, much better defined, less ad hoc,
and a lot more transparent.



OK!  I think I for one would really like to hear a summary of that.  I'm 
not trying to stir the pot, just wondering whether there is any way to 
improve the current Mozilla process, either up or down.


iang
___
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto

Re: A tip for novice users of SSL_BadCertHook and SSL_PeerCertificate

[Nelson B Bolyard]

DanKegel wrote, On 2008-12-18 12:12:
> http://www.mozilla.org/projects/security/pki/nss/ref/ssl/sslfnc.html#1088928
> says "To obtain the certificate that was rejected by the certificate
> authentication callback, the callback function calls
> SSL_PeerCertificate."

The sentence above could be clarified by inserting the words "bad
certificate", so that it reads "... the bad certicicate callback function
calls SSL_PeerCertificate".

This sentence appears in the description of the "Bad Certificate" callback
function which the application may supply.  As explained in that
description, the Bad Cert callback, if supplied by the application, is
called immediately after the certificate authentication callback returns
a failure result.  Being the second callback, the "bad cert" callback may
wish to know what cert was rejected by the earlier cert auth callback.
The bad cert callback calls SSL_PeerCertificate to get that info.

Note that SSL_PeerCertificate is also the function called by the first
callback (the certificate authentication callback) to get the cert it
is being asked to authenticate.

> And it really does mean the callback function.  Once that returns, the
> information is destroyed, and SSL_PeerCertificate will fail.

Yeah, once the handshake is over, much of the info it used is gone,
unless the application makes its own copy during the handshake.

> This seems obvious in retrospect.  Just posting here in case anyone
> else trips on this.

Thanks.  Feel free to file a documentation bug against that web page.
___
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto

Re: Publishing CA information documents in PDF format

[Eddy Nigg]

On 12/18/2008 10:16 PM, Ian G:


It is truly basic, it is how business works.


Your assumptions are a non-starter for me. Having worked myself in 
various organizations from small and to big (1000+), what you suspect is 
completly foreign to me, not common practice for IT personnel (in 
particular) and bad practice not performed in structured corporations in 
general.


More than that, you claimed in your original mail, quoting:

"..some time later we might discover that Kathleen now works for 
Microsoft.  Nobody bothered to replace the key, because it worked."


...which is completly crap. What makes you assume that she even works at 
a physical "location" called Mozilla. What makes you assume that she 
doesn't use here very own computer, hasn't her own login credentials, 
doesn't use passwords for the security devices. Maybe she uses a smart 
card at all. And what makes you assume that she doesn't know to care 
about her keys. She is a professional having worked in this industry...


If we assume all the bad habits and worst practices in relation to PKI, 
then I will be able to smash any other solution you bring up in the very 
same way. You have not yet proved anything, not brought up one better 
solution to what is done here.


Besides that PKI doesn't intend to solve the nature of humanity, 
everything above could be labeled as bad practice and beyond the scope 
of PKI, anything else would most likely fail the same...Duuuhhh, 
"somebody else signed a document with my private key", what an argument 
proving the failure of PKI in general and makes signing of documents 
unreliable (as you claimed)!




"The same" means what, precisely? I have said many times that human
signing should not be done in S/MIME with the S/MIME keys until the
meanings and protocols are sorted out, and clear.


You haven't even convinced me of "the" problem yet. Which protocol would 
you like to fix exactly? What is your solution which has the slightest 
chance to work better? I'm interested to hear.




That someone would use another user's S/MIME keys to sign emails? Well,
of course. Secretaries are employed for just this purpose, they always
do letters in their boss's name. If Kathleen has a secretary called
Kevin, then it is entirely plausible that Kevin will manage Kathleen's
keys and Kathleen won't necessarily do anything at all.



Yes, and if my grandmother would have wheels she would be probably a 
Ferrari.



--
Regards

Signer: Eddy Nigg, StartCom Ltd.
Jabber: start...@startcom.org
Blog:   https://blog.startcom.org
___
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto

Re: JSS NSS sun.security.pkcs11.SunPKCS11

[Glen Beasley]

banzai wrote:

Hi all,

I have tried to read all the certificates in NSS.
you probably know this but you of course can use the built in Firefox 
Certificate Manager

Options->Advanced->View Certificates

I a little confused by some of the info provided. One you can configure 
Sun PKCS#11 provider to
use NSS PKCS#11 implementation but you cannot configure SunPKCS11 to use 
JSS at all.


For SunPkcs11/NSS rather than using keytool I think you should write 
your own applet and
play with the available api. You should be able to see all the 
Certificates you want to.


http://java.sun.com/javase/6/docs/technotes/guides/security/p11guide.html#NSS

Instead you can write an applet that loads JSS/NSS; you would not use 
SunPKCS11.

http://www.mozilla.org/projects/security/pki/jss/
http://www.mozilla.org/projects/security/pki/jss/provider_notes.html
sample code: 
http://mxr.mozilla.org/mozilla/source/security/jss/org/mozilla/jss/tests/

http://java.sun.com/j2se/1.5.0/docs/guide/deployment/deployment-guide/keystores.html

Note: If you plan on writing an applet that uses JSS in Firefox on 
windows please read

the http://www.mozilla.org/projects/security/pki/jss/jss_build_4.2.5.html

One of the issue with an applet is to how to init JSS with the correct 
Profile directory


http://kb.mozillazine.org/Profile_folder_-_Firefox#Finding_the_profile_folder

-glen


Unfortunately the
current setting only allowed listing of either soft token certficates
in NSS or the smart card token . My objective is to read all the
certiifates inside the firefox keystores, the soft token and smart
card certificates as in PKCS11ListCert function.

The current setting is:
1) In the nss.cfg
name = NSS
nssSecmodDirectory = C:\Users\user1\AppData\Roaming\Mozilla\Firefox
\Profiles\zgk9nrxt.default
2)In the java.security
security.provider.10=sun.security.pkcs11.SunPKCS11   c:/javadev/
nss.cfg

The run test command: running keytool -keystore NONE -storetype PKCS11
-list -v
Result: It only list soft token certificates

if i switch the configuration to accept the opensc framework
1) In the sc.cfg
name = smartcard
library = C:\windows\system32\my-pkcs11.dll
2)In the java.security
security.provider.10=sun.security.pkcs11.SunPKCS11   c:/javadev/sc.cfg
Result: It lists the PKCS11 - smart card certificates

Reading from the previous groups posts, it lead to the usage of JSS
module as a solution.
I have setup the environement for JSS and tested with the testing
program provided by mozilla. So far so good..

Now, how should i go to set the JSS inside the cfg file ?
name = JSS
library = C:\Program Files\Mozilla Firefox\jss4.dll
and .. it does not work. I can't find jssArgs to replace the nssArgs
as in config.java file

Any configuration guide that i have missed..?

Thank you
___
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto
   


___
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto

NSS Shared DB and Linux proposal.

[Robert Relyea]

I've made a proposal on how applications should initialize NSS when 
using shared databases on Linux. That draft is located here:


https://wiki.mozilla.org/NSS_Shared_DB_And_LINUX

Comments and edits are welcome.

Thanks,

bob


smime.p7s
Description: S/MIME Cryptographic Signature
___
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto

Re: A tip for novice users of SSL_BadCertHook and SSL_PeerCertificate

[Wan-Teh Chang]

On Thu, Dec 18, 2008 at 12:37 PM, Nelson B Bolyard  wrote:
> DanKegel wrote, On 2008-12-18 12:12:
>> http://www.mozilla.org/projects/security/pki/nss/ref/ssl/sslfnc.html#1088928
>> says "To obtain the certificate that was rejected by the certificate
>> authentication callback, the callback function calls
>> SSL_PeerCertificate."
>
> The sentence above could be clarified by inserting the words "bad
> certificate", so that it reads "... the bad certicicate callback function
> calls SSL_PeerCertificate".

Done.

>> And it really does mean the callback function.  Once that returns, the
>> information is destroyed, and SSL_PeerCertificate will fail.
>
> Yeah, once the handshake is over, much of the info it used is gone,
> unless the application makes its own copy during the handshake.

I added a note: once the bad-certificate callback function returns,
the peer certificate is destroyed, and SSL_PeerCertificate will fail.

Wan-Teh
___
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto

Re: DSV/S-TRUST root inclusion request

[Nelson B Bolyard]

According to my mail client, Ian G wrote on 2008-12-17 04:11 PST:

[paraphrasing liberally:
  Europeans let their legislatures do their engineering.]

Lot of countries have created their own legislation or regulation for
security software, and then sat back and waited for others to implement
their designs ... and waited ... and waited ... and waited ...

This may well be just another case.

> Now, what do you do about it?  Mozo is in a difficult position.  

No, not a bit.  The governments in most countries are accustomed to being
obeyed unquestioningly.  They act astonished when NONE of the popular
browsers implement the requirements they try to impose.  Tsk tsk.

Mozilla (indeed, all browsers) have successfully ignored lots of silly
regulations from individual countries.  A good example of that is
regulation that requires the CAs in one country to put into their certs a
monetary limit on the financial value of the transactions done that use
those certs, a limit using the nation's own monetary units, and to require
any software that uses those certs to dishonor those certs until they are
prepared to enfore those limits.  Mozilla software happily dishonors all
those certs.  There are other examples as well.

> As we have discussed in this group before, Mozo's principle is to pass
> these questions across to the standards committee.
> For sake of argument, this would be the PKIX committee.

Wrong, but nice try.

> However, national law trumps standards committees.

LOL.

> I wish it were different.  But, it isn't.

So, some country says "our citizens must use browsers that do this",
and no browsers do this, and eventually the country realizes that they
must relent or else have their citizens live in the dark ages.  Eventually
they relent.  That's what happened to the requirement about the monetary
limits in certs.  The monetary limits are still there, but are now marked
as saying that the software that uses those certs is now free to honor those
certs even if it ignores those limits, and browsers all do so.
___
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto

Re: Publishing CA information documents in PDF format

[Kyle Hamilton]

On Thu, Dec 18, 2008 at 7:29 AM, Ian G  wrote:
> On 18/12/08 12:09, Kyle Hamilton wrote:
>>
>> Eddy's gone ahead and sent a signed PDF, according to a later message
>> in-thread.  I expect that it'll work without a hitch, though I would
>> like to hear of any anomalous behavior. :)
>>
>> But, I'm struck again by a couple of questions.
>>
>> Why does everything have to have an explicit 'threat model' before
>> cryptography can be applied?
>
>
> Because otherwise we don't know what to protect against, and we end up
> reaching for the grab bag of things that are known to be protected by
> crypto, rather than what the user wants.
>
> Classic case:  PKI view is that you want to protect the authenticity of the
> identity.  But in some scenarios, this is a threat not a protection.  For
> example, consider self-help chat message boards where people can sign up
> using a nymous name like "PuddleBlob" and talk about difficult things.  The
> net has created this wonderful ability for people who have problems to talk
> about them, but they can only do this in conditions of safety, which to them
> means anonymity and/or untraceability.  Think Alcholics Anonymous, or
> divorced women.

Self-help chat message boards are a rather odd concern, and they're
actually where I want to try to put PKI.  The "problem" as far as it
goes is this: I want to put PKI there.  I DON'T want to put real names
there.

Those nyms are valid identifiers, and thus "names" as far as they go,
within those environments -- and as long as you're in that
environment, you don't need PKI, since the board software has an
online link to its authenticator.  Once you drop out of that
environment, there are two routes you can go:
1) The OpenID route (separate the identity-consumer from the
authenticator, with an online verification system)
2) The PKI route (separate the identity-consumer from the
authenticator, without an online verification system)

One of my favorite examples is "the bank manager who writes slashfic
while not at work".  (slashfic is, essentially, fan fiction that
explores the writer's concepts of relationships between the
characters.  Some of it's quite explicit, some of it is quite tame,
but it's all 'copyright infringement' unless the rightsholder has
explicitly granted fans the right to create derivative works, which
they usually[*] don't because then they have a hard time actually
selling the "derivative work" right to someone who might want to pay
for it.)  Suppose that one of her superiors at corporate -- or worse,
a customer -- looks up her name on Google.

Linking the pen-name with legal/employment identity would be
deleterious, since courts have held that companies can reasonably
expect certain standards of behavior from their employees, even
without explicitly delineating those standards.  However, slashfic
writers often go to science fiction conventions, and when they do they
often want to be known by their pen-names.  The convention itself
needs to know the legal name, for its own protection -- but those
membership lists are generally not considered "freely accessible
information".

Now, suppose the bank manager/author takes a vacation, and goes to a
convention.  Then, suppose that (for whatever reason) she needs to
prove that she's the author of the stories that she wrote, even if
they were based in a world that she didn't have rights to use.  (Don't
knock this, it's occurred at least once that I'm aware of -- not with
a bank manager, but with a songwriter/lyricist.)  PKI could be
extended to cover this case, if we got away from the
overly-restrictive requirement that people seem to put into it that
require legal names in their identity certificates.

It could also be used to allow for authentication of instant message
sessions.  (I'm currently looking at the OTR protocol, from
http://www.cypherpunks.ca/otr/, and trying to create a
certificate-authentication system that integrates at the point where
they currently use the Socialist Millionaire Protocol -- i.e., after
the session's been generated, and without using the keys in the
certificate to create any kind of signed/nonrepudiable record.)

*this is slowly changing with such movements as the Creative Commons,
which can do BY-NC-SA licensing, but entertainment industry lawyers
haven't figured out what to do with that yet.

> So, PKI is the precise wrong thing for them, because it identifies them and
> tries (badly) to ensure that they are traceable.

It's only as "precisely wrong" as the identities that are embedded
into the certificate.

> A deeper more nuanced view would be that once we identify a thing that needs
> protecting, then we still have to compare the costs of the threat with the
> costs of the protection.  For example, MITM is in this camp; the protection
> for MITM in say secure browsing is too expensive, given that only in the
> last year or so (recent K case) have we seen any real evidence of attacks.
>  Without a costs based analysis, any sense of "protect 

Protecting a Mozilla-based app.

[nbjayme]

Hello all,

I'm new to this list.  My interest is in the area of protecting the
mozApp and Data.  I am thinking in line of an encrypted folder to
store the data and have the application signed.
The application is xulrunner-based but I don't know if the security of
mozilla is also included in xulrunner.

Has there been a known FOSS-based folder encryption app that can
integrate with the OS?

Can I sign my app using PGP / GNUPG with a passphrase and have the
mozilla-sdk ask for a passphrase before someone use the application?

I apologize if this is not the right group to post this concerns.  I
am still learning my way through the mozilla community.

Many thanks.

Sincerely,

NBJayme
___
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto