Re: Mozilla Team-about the upcoming branding changes at Symantec/VeriSign, and working to implement them in Mozilla/Firefox

2012-03-12 Thread Gervase Markham
On 09/03/12 17:56, Brian Smith wrote:
 The first question is: Should we change our UI to be the same as
 other browsers? My answer is no. It *is* a good idea to show the root
 certificate's organization name in this part of the UI. But, it is
 also important to show all the intermediate organizations' names in
 this part of the UI too. See the recent TrustWave incident for
 motivation. 

I don't have a strong opinion at the moment (although I may develop one
- iang's argument seems to me to have merit) on whether we show the
intermediate O field or the root one...

 If others agree, then I will file a bug about
 implementing a change to display the O= field from all CA
 certificates in the chain in this UI.

but I do have a strong opinion that this solution is needless UI
complexity. It is our job to find out the most appropriate value to
show, and show it; we should not force the entire range on to the user.

 The second question is: Should we change the string in the display of
 the *root* certificate from VeriSign, Inc. to Norton. My answer
 is no, because AFAICT this field should contain the legal name of the
 organization that owns the root certificate. In this case, it would
 be Symantec Corporation or VeriSign, Inc. depending on the new
 corporate structure of VeriSign. If Symantec changes the legal name
 of this organization to Norton then this would be an acceptable and
 required change. (However, that is impossible, because US law
 requires businesses include Inc., Corporation, LLC., etc in
 their legal name.)

Quite so. The EV chrome is not a marketing tool.

 The third question is: Should the UI replace the display of the O=
 field of *intermediate* certificates that chain to
 Symantec/VeriSign's roots to Norton when the value is VeriSign,
 Inc. My answer is no. See the recent TrustWave incident for
 motivation. It is important to display the information in the
 intermediate certificates exactly as we received it in the
 certificate. We have too many more important things to do. And, our
 users do not benefit from such a change.

See above; I think this question is moot given my answer there.

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


Re: Mozilla Team-about the upcoming branding changes at Symantec/VeriSign, and working to implement them in Mozilla/Firefox

2012-03-12 Thread ianG

On 12/03/12 21:56 PM, Gervase Markham wrote:

On 09/03/12 17:56, Brian Smith wrote:

The first question is: Should we change our UI to be the same as
other browsers? My answer is no. It *is* a good idea to show the root
certificate's organization name in this part of the UI. But, it is
also important to show all the intermediate organizations' names in
this part of the UI too. See the recent TrustWave incident for
motivation.


I don't have a strong opinion at the moment (although I may develop one
- iang's argument seems to me to have merit) on whether we show the
intermediate O field or the root one...


If others agree, then I will file a bug about
implementing a change to display the O= field from all CA
certificates in the chain in this UI.


...but I do have a strong opinion that this solution is needless UI
complexity. It is our job to find out the most appropriate value to
show, and show it; we should not force the entire range on to the user.


The second question is: Should we change the string in the display of
the *root* certificate from VeriSign, Inc. to Norton. My answer
is no, because AFAICT this field should contain the legal name of the
organization that owns the root certificate. In this case, it would
be Symantec Corporation or VeriSign, Inc. depending on the new
corporate structure of VeriSign. If Symantec changes the legal name
of this organization to Norton then this would be an acceptable and
required change. (However, that is impossible, because US law
requires businesses include Inc., Corporation, LLC., etc in
their legal name.)


Quite so. The EV chrome is not a marketing tool.




This is a very complex area.  Security thinking for strong user 
interaction would demand that the brand be shown (this is fairly 
standard for example in credit card security the brand of the card 
issuer is shown prominently ... it's part of the security model). 
That's because brands are what users see and perceive, and therefore 
brands are defensible in ways that corp names are not.


But for subscriber/EE certs, CAs/vendors have typically shown the legal 
name of the certificate holders.  Typically this is justified as being 
something that can be checked to some reasonable level (with a nod to 
Philipp's post) however this is a supply side claim.  Typically the 
legal name is not ever seriously presented as something that is useful 
to users.  e.g., godaddy versus starfield.


From this EE focus of check the legal name, show it to the user 
paradigm perhaps it is thought sensible to do the same for CAs.  But 
again, this seems to reduce back to logic like the EE case.


However ... it may be that the foundation is lacking - has any vendor 
actually checked the legal name of CAs to the same extent as claimed in 
say BR?  Checked with some state registry the existence of a filed 
organisation of the name of the CA, confirmed who the signing officers 
are, demanded their ID and signature on the application for root listing?


The point is not that you should do this ... but to question why you 
would want to slavishly present the legal name of the CA?


For users, they want the brand.  That's what they are taught, and for 
good marketing reasons.  The brand in question was Verisign, not 
Verisign Inc.


Certainly, from this pov, if new roots where presented by Symantec Inc 
with Norton in the O field, I'd not object.




iang



The third question is: Should the UI replace the display of the O=
field of *intermediate* certificates that chain to
Symantec/VeriSign's roots to Norton when the value is VeriSign,
Inc. My answer is no. See the recent TrustWave incident for
motivation. It is important to display the information in the
intermediate certificates exactly as we received it in the
certificate. We have too many more important things to do. And, our
users do not benefit from such a change.


See above; I think this question is moot given my answer there.

Gerv


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


Implementation of C_Encrypt function

2012-03-12 Thread VJ
Im porting all RSA encryption from the nss library.
Im a newbie, may I know where C_Encrypt function under
pk11_PubEncryptRaw() function is implemented.
Also, I would like to know if anyone has ever ported only RSA related
functions?

Regards,
Vejey
-- 
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto


Re: Implementation of C_Encrypt function

2012-03-12 Thread Robert Relyea

On 03/10/2012 12:23 PM, VJ wrote:

Im porting all RSA encryption from the nss library.
Im a newbie, may I know where C_Encrypt function under
pk11_PubEncryptRaw() function is implemented.
Also, I would like to know if anyone has ever ported only RSA related
functions?

Regards,
Vejey

What do you mean by 'porting'?

Porting usually involves tweeking with the core build files in 
mozilla/security/coreconf . You usually just add a new platform to that 
build environment.


It sounds more like you are copying the code into your own application. 
Your welcome to do this, but it is not something the NSS team supports.


bob

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