Feedback on DOMCryptInternalAPI

[David Dahl]

Hello All:

[I have cross posted this message to dev-platform and dev-tech-crypto, perhaps we should discuss this on dev-platform as it has a larger subscriber base?].

I am just putting together a draft feature page for an internal API needed by the eventual DOM bindings for DOMCrypt (see: https://wiki.mozilla.org/Privacy/Features/DOMCryptAPISpec/Latest and http://www.w3.org/2012/webcrypto/ ). I would like for this API to not only support the eventual Web Crypto API, but also to allow extension developers to have a useful, high-level API to work with. This seems to be quite in demand based on the number of companies and developers who have contacted me about hacking on my fork of WeaveCrypto ( in the DOMCrypt Extension https://addons.mozilla.org/en-US/firefox/addon/domcrypt/ .)

Mozilla developers will also be able to take advantage of this internal API to more easily create browser features and/or extensions in the security and privacy space. I would also like to produce a Jetpack wrapper.

The existing spec for DOMCrypt will no doubt change very soon as the Web Crypto Working Group is ramping up and based on discussions with bent and khuey, we need to move to an event-driven interface. The Internal API described on this feature page: https://wiki.mozilla.org/DOMCryptInternalAPI should be able to handle that, however, some wider discussion and feedback will really be appreciated, especially with all of the changes in line for our DOM bindings. The initial work for this internal API is in bug 649154.

Regards,

David

[Ehsan Akhgari]

Hi David,

What is your concern here with regard to the private browsing mode? It's
not immediately obvious to me why and how this API should interact with the
PB mode.

Thanks!
--
Ehsan
<http://ehsanakhgari.org/>

> _______________________________________________
> dev-platform mailing list
> dev-pl...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-platform
>

[David Dahl]

----- Original Message -----
> From: "Justin Lebar" <justin...@gmail.com>
> To: "David Dahl" <dd...@mozilla.com>
> Cc: dev-tec...@lists.mozilla.org
> Sent: Friday, April 20, 2012 2:22:31 AM
> Subject: Re: Feedback on DOMCryptInternalAPI
>
> I don't know if you're at the bikeshedding stage of this API's
> development -- if not, please ignore me and I'll come back later. :)
>
I have been bikeshedding for a months:) The WG will be publishing an updated draft of the WebAPI soon, so this is helpful feedback.

> ****
>
> > interface CryptoHmac {
>
> Why isn't this CryptoMac? Surely the fact that it's an hmac is an
> implementation detail.

Sure, I don't imagine supporting any other MAC.
>
> ****
>
> It's pretty weird to me that you get a CryptoHmac and a CryptoHash
> via
> a constructor, but you get pk/sign via window.crypto. I'd prefer
> window.crypto.getHash(), window.crypto.getMac(), or something.
>
These were spec'd as constructors, but don't have to be.

We could also return the hash or hmac producing object like: var h = window.crypto.hash(alg);


> ****
>
> Why is it that I get to stream data to the hash / mac provider, but I
> have to provide all my data upfront in order to encrypt / sign? I'd
> prefer if, for all four cases, we had the option to stream and give
> all the data upfront.
>
> ****

We have talked about a streaming encryption/decryption method. I am not sure if I see the use case for a streaming signature method.

>
> Can we have a default algorithm for hash / mac like we have a default
> pk / sign? I totally buy the virtue of giving people a choice of
> algorithm, but otoh it's also nice to be able to say "hash this for
> me" without worrying about which algorithm(s) the browser supports.
>
I imagine we might for the WebAPI, however, for this internal API, I think we should specify it.

David

[Justin Lebar]

(Not cross-posting to dev-platform per Mounir's plea, and because I
don't think these details are particularly interesting to that
audience.)

>> > interface CryptoHmac {
>>
>> Why isn't this CryptoMac?  Surely the fact that it's an hmac is an
>> implementation detail.
>
> Sure, I don't imagine supporting any other MAC.

Never e.g. CMAC? Why not?

>> It's pretty weird to me that you get a CryptoHmac and a CryptoHash
>> via
>> a constructor, but you get pk/sign via window.crypto.  I'd prefer
>> window.crypto.getHash(), window.crypto.getMac(), or something.
>>
> These were spec'd as constructors, but don't have to be.
>
> We could also return the hash or hmac producing object like: var h = window.crypto.hash(alg);

I would like this.

>> Why is it that I get to stream data to the hash / mac provider, but I
>> have to provide all my data upfront in order to encrypt / sign?  I'd
>> prefer if, for all four cases, we had the option to stream and give
>> all the data upfront.
>

> We have talked about a streaming encryption/decryption method. I am not sure if I see the use case for a streaming signature method.

Suppose I have five separate pieces of data and I want to sign them
all together. That's easy with a streaming signature, hard otherwise.

>> Can we have a default algorithm for hash / mac like we have a default
>> pk / sign?  I totally buy the virtue of giving people a choice of
>> algorithm, but otoh it's also nice to be able to say "hash this for
>> me" without worrying about which algorithm(s) the browser supports.
>>
> I imagine we might for the WebAPI, however, for this internal API, I think we should specify it.

Do you mean s/this/the? If so, I totally agree. If not, I'm
confused, because I thought I was looking at the web api. :)

Thanks, David!

-Justin

[Kyle Hamilton]

[dev-tech-crypto followup]

On Fri, Apr 20, 2012 at 8:11 AM, David Dahl <dd...@mozilla.com> wrote:
> We could also return the hash or hmac producing object like: var h = window.crypto.hash(alg);

This would be the most general way to handle it. (I'm told that 'generality is the key'.)

>> ****

>>
>> Why is it that I get to stream data to the hash / mac provider, but I
>> have to provide all my data upfront in order to encrypt / sign?  I'd
>> prefer if, for all four cases, we had the option to stream and give
>> all the data upfront.
>>

>> ****

>
> We have talked about a streaming encryption/decryption method. I am not sure if I see the use case for a streaming signature method.

CMS does not require DER. It requires BER, specifically to handle indefinite-length streams. It may be the case that there are multiple sections of code writing to the same stream, as a valid (though spaghetti-codish) implementation technique.

Streaming signature should be a function of streaming digest. PKCS#11 submits the digest to the module for signature, and returns the signature blob. This is the case even for DSA and ECDSA modules.


I see standards which suggest that it should be permitted, and no actual reason not to.

(Speaking of ECDSA, I'd like that enumerated in the IDL. I'd like to enable DHKE, but I'd also like to enable ECDHKE. Dan Bernstein's Curve25519 function is exemplary for this, with a derived key length of 256 bits. The downside is that any ECDH implementation requires a key derivation function, like a digest -- one must not use ECDH-agreed values directly. Personally, I'd like to see this requirement inflicted on DHKE secrets too.)

>> Can we have a default algorithm for hash / mac like we have a default
>> pk / sign?  I totally buy the virtue of giving people a choice of
>> algorithm, but otoh it's also nice to be able to say "hash this for
>> me" without worrying about which algorithm(s) the browser supports.
>>
> I imagine we might for the WebAPI, however, for this internal API, I think we should specify it.

I'd like it to default to SHA2/256. This is particularly for deriving 256-bit symmetric keys from ECDH exchanged secrets.

If the digest algorithm has no default, please don't specify a default in the symmetric or asymmetric algorithms either. I'd prefer a conceptually tidy API, with as few differences between the algorithm types as possible.

-Kyle H

[David Dahl]

----- Original Message -----
> From: "Justin Lebar" <justin...@gmail.com>
> To: "David Dahl" <dd...@mozilla.com>
> Cc: dev-tec...@lists.mozilla.org
> Sent: Friday, April 20, 2012 6:31:02 PM
> Subject: Re: Feedback on DOMCryptInternalAPI
>

> (Not cross-posting to dev-platform per Mounir's plea, and because I
> don't think these details are particularly interesting to that
> audience.)
>

Ah, OK, sorry for the spam!

> >> > interface CryptoHmac {
> >>
> >> Why isn't this CryptoMac?  Surely the fact that it's an hmac is an
> >> implementation detail.
> >
> > Sure, I don't imagine supporting any other MAC.
>
> Never e.g. CMAC? Why not?

I guess I never considered it. However, I will keep this in mind when we tackle MAC. Perhaps it is 'trivial' to add this - most likely not:)

>
>
> >> Why is it that I get to stream data to the hash / mac provider,
> >> but I
> >> have to provide all my data upfront in order to encrypt / sign?
> >>  I'd
> >> prefer if, for all four cases, we had the option to stream and
> >> give
> >> all the data upfront.
> >

> > We have talked about a streaming encryption/decryption method. I am
> > not sure if I see the use case for a streaming signature method.
>

> Suppose I have five separate pieces of data and I want to sign them
> all together. That's easy with a streaming signature, hard
> otherwise.
>

While there is the ability to do this in NSS, I imagine since you will almost always be signing a hash or set of hashes with a public key, this operation will be very quick and operate on a small set of data. Still, we will have to consider use cases like this. Thanks.

> >> Can we have a default algorithm for hash / mac like we have a
> >> default
> >> pk / sign?  I totally buy the virtue of giving people a choice of
> >> algorithm, but otoh it's also nice to be able to say "hash this
> >> for
> >> me" without worrying about which algorithm(s) the browser
> >> supports.
> >>
> > I imagine we might for the WebAPI, however, for this internal API,
> > I think we should specify it.
>

> Do you mean s/this/the? If so, I totally agree. If not, I'm
> confused, because I thought I was looking at the web api. :)

Apologies. This is an internal API to support the WebAPI and will be used by extension and browser developers.

Regards,

David

[Justin Lebar]

> Apologies. This is an internal API to support the WebAPI and will be used by extension and browser developers.

Perhaps we're not talking about the same thing.

Is

https://wiki.mozilla.org/Privacy/Features/DOMCryptAPISpec/Latest

a web-facing API? It certainly appears to be; there are demos and everything.

http://domcrypt.org/demos/demo.html

>> > Sure, I don't imagine supporting any other MAC.
>>
>> Never e.g. CMAC? Why not?
>
> I guess I never considered it. However, I will keep this in mind when we tackle MAC. Perhaps it is 'trivial' to add this - most likely not:)

For the purposes of a web API -- and again, I'm now confused as to
whether any of these APIs are exposed to the web, but I thought they
were -- the question isn't whether it's trivial to add CMAC, but
rather whether you want to commit that HMAC is the only MAC you'll
ever want to use on the web.

> While there is the ability to do this in NSS, I imagine since you will almost always be signing a hash or set of hashes with a public key, this operation will be very quick and operate on a small set of
> data. Still, we will have to consider use cases like this.

Ah, I thought that this API would handle the hashing for me. That
seems in line with the "it should just work" aspect of the API. For
the same reason, the API doesn't let me choose ECB encryption, and the
API, I certainly hope, will MAC all encrypted messages and reject
decryption with invalid MACs.

[David Dahl]

----- Original Message -----
> From: "Justin Lebar" <justin...@gmail.com>
> To: "David Dahl" <dd...@mozilla.com>
> Cc: dev-tec...@lists.mozilla.org
> Sent: Friday, April 20, 2012 8:38:53 PM
> Subject: Re: Feedback on DOMCryptInternalAPI
>

> Is
>
> https://wiki.mozilla.org/Privacy/Features/DOMCryptAPISpec/Latest
>
> a web-facing API? It certainly appears to be; there are demos and
> everything.
>

Yes. I am talking about an internal API that will also be a scriptable interface that supports the eventual 'DOMCrypt'/Web Crypto WebAPI.

> >> > Sure, I don't imagine supporting any other MAC.
> >>
> >> Never e.g. CMAC? Why not?
> >

I'll never say never, there is a lot of feedback to gather yet - especially as we hash out the functionality we want. Getting this kind of feedback is good, as it shows use cases I had not considered - for no particular reason.

> For the purposes of a web API -- and again, I'm now confused as to
> whether any of these APIs are exposed to the web, but I thought they
> were --

They will be. The dom-exposed APIs will be a subset of this 'internal' API.

> the question isn't whether it's trivial to add CMAC, but
> rather whether you want to commit that HMAC is the only MAC you'll
> ever want to use on the web.

I cannot rule it out, especially not now. It is way to early to rule anything out.

> Ah, I thought that this API would handle the hashing for me. That
> seems in line with the "it should just work" aspect of the API. For
> the same reason, the API doesn't let me choose ECB encryption, and
> the
> API, I certainly hope, will MAC all encrypted messages and reject
> decryption with invalid MACs.
>

Exactly. This is the kind of thing we want to do for the web-exposed API: no real options and as much safety "built in". The underlying internal API will be quite similar but with more options and configurability.

Regards,

David

[David Dahl]

----- Original Message -----
> From: "Kyle Hamilton" <aero...@gmail.com>
> To: "mozilla's crypto code discussion list" <dev-tec...@lists.mozilla.org>
> Cc: "Justin Lebar" <justin...@gmail.com>
> Sent: Friday, April 20, 2012 7:40:12 PM
> Subject: Re: Feedback on DOMCryptInternalAPI

> >> ****
> >>
> >> Why is it that I get to stream data to the hash / mac provider,
> >> but I
> >> have to provide all my data upfront in order to encrypt / sign?
> >>  I'd
> >> prefer if, for all four cases, we had the option to stream and
> >> give
> >> all the data upfront.
> >>

> >> ****

> >
> > We have talked about a streaming encryption/decryption method. I am
> > not sure if I see the use case for a streaming signature method.
>

> CMS does not require DER. It requires BER, specifically to handle
> indefinite-length streams. It may be the case that there are
> multiple sections of code writing to the same stream, as a valid
> (though spaghetti-codish) implementation technique.
>
> Streaming signature should be a function of streaming digest.
> PKCS#11 submits the digest to the module for signature, and returns
> the signature blob. This is the case even for DSA and ECDSA
> modules.
>

Good to know.

>
> I see standards which suggest that it should be permitted, and no
> actual reason not to.

Ok, can you point to some standards docs for me to read about?

>
> (Speaking of ECDSA, I'd like that enumerated in the IDL. I'd like to
> enable DHKE, but I'd also like to enable ECDHKE.

I will add ECDSA for signatures for sure. Again, I am not sure if ECDHKE would be permissible for us to use.

> Dan Bernstein's
> Curve25519 function is exemplary for this, with a derived key length
> of 256 bits. The downside is that any ECDH implementation requires
> a key derivation function, like a digest -- one must not use
> ECDH-agreed values directly. Personally, I'd like to see this
> requirement inflicted on DHKE secrets too.)

Interesting. Are you interested in helping with a design for the symmetric encryption API? :)

>
> If the digest algorithm has no default, please don't specify a
> default in the symmetric or asymmetric algorithms either. I'd
> prefer a conceptually tidy API, with as few differences between the
> algorithm types as possible.

Yes. Makes sense. In our Identity work there is the notion of a alg/keybits argument/property for these kinds of things: "DS160" or "RS256".

Cheers,

David

[Anders Rundgren]

On 2012-04-19 17:09, David Dahl wrote:
> Hello All:
>
> [I have cross posted this message to dev-platform and dev-tech-crypto, perhaps we should discuss this on dev-platform as it has a larger subscriber base?].
>
> I am just putting together a draft feature page for an internal API needed by the eventual DOM bindings for DOMCrypt (see: https://wiki.mozilla.org/Privacy/Features/DOMCryptAPISpec/Latest and http://www.w3.org/2012/webcrypto/ ). I would like for this API to not only support the eventual Web Crypto API, but also to allow extension developers to have a useful, high-level API to work with. This seems to be quite in demand based on the number of companies and developers who have contacted me about hacking on my fork of WeaveCrypto ( in the DOMCrypt Extension https://addons.mozilla.org/en-US/firefox/addon/domcrypt/ .)
>
> Mozilla developers will also be able to take advantage of this internal API to more easily create browser features and/or extensions in the security and privacy space. I would also like to produce a Jetpack wrapper.
>
> The existing spec for DOMCrypt will no doubt change very soon as the Web Crypto Working Group is ramping up and based on discussions with bent and khuey, we need to move to an event-driven interface. The Internal API described on this feature page: https://wiki.mozilla.org/DOMCryptInternalAPI should be able to handle that, however, some wider discussion and feedback will really be appreciated, especially with all of the changes in line for our DOM bindings. The initial work for this internal API is in bug 649154.
>
> Regards,
>
> David

I have already provided feedback on this in a W3C list, so this a condensed version of on the Mozilla list.

As I understand it, this scheme is about public keys bound to a domain which is a bit like cookies on steroids.
This shouldn't introduce any new or difficult security concerns. Regarding real-world use-cases, I'm slightly less convinced. In particular encryption has proved to be hard to exploit but OTOH
there are [still] folks out there who claim S/MIME is the flagship of PKI so I guess somebody knows what they are asking for....

However, the WG has also taken on "Signing High-value Transactions". I find this use-case poorly researched.
There have been no references to existing web signature systems although such have existed since late 90'ties. I suggested early on dropping this topic, as it with a high probability will jeopardize
both the time schedule as well as uptake by other browser vendors.

In addition, it is claimed from time to time that a future version of DOMCrypt will also support X.509 certificates.
If I had developed a car, I would be rather hesitant saying that the next iteration will fly without having a pretty good idea of how.

I'm personally continuing on the path created by Netscape eons of time ago, where cryptographic operations in browsers are performed in self-contained applications like HTTPS URL innovation, <keygen>,
and signText() because they have proven to work, while (for example) Microsoft's CertEnroll has been a complete failure due to the issues created by exposing APIs to untrusted web-pages.

Somewhat surprising the WG excluded smart cards in spite that built-in security hardware will be a standard feature in every high-end mobile device by the time this WG has finished!
IMHO, smart cards in browsers is actually quite easy; you just bypass the vendors and define a card/container for the web :-)
If you ever had looked into the OpenSC mailing list it is pretty obvious that supporting conventional cards is impossible, at least for enrollment.

Anders

[Marsh Ray]

On 04/20/2012 07:40 PM, Kyle Hamilton wrote:
>
> I'd like it to default to SHA2/256. This is particularly for deriving
> 256-bit symmetric keys from ECDH exchanged secrets.

Is that SHA-2-256 or SHA-2-512/256 ?

The latter seems to be gaining in popularity as it is slightly faster on
64-bit machines, has a higher safety factor, and fixes the message
extension weakness present in MD5, SHA-1, and plain SHA-2.

- Marsh

[helpcrypto helpcrypto]

Just some commets you could ignore :P

As said before, i dont know if you have considered smartcard.
These, (as discussed in
https://groups.google.com/forum/#!topic/mozilla.dev.tech.crypto/hNS32Zhz9gw)
could have some other needs. IMHO, a lot of discuss yet to come.

I have experienced some issues regarding to encoding.
A page encoded in ISO send some data to a page encoded in UTF-8 which
signs...then, verify could not match.
So we decide to use base64 binary encoding for all operations. I think
"plaintext" maybe its not the best option (or maybe im wrong)

<half offtopic>
Its being discussed on the other thread, but just to let you know,
actually, theres not a way for knowing if Keypair generation is made
on softokn or smartcard, and that lead (in our company) to some
problems. I think something must be done about this.
I agree with Anders Certenroll could be (*IS*) evil, but if an
app/site developer what to use an specificsmartcard, perhaps he should
be able to know if that smartcard is present...
</half offtopic>

Regarding signWithUserConfirmation, you should consider some devices
(like spanish DNIe) show their own window, which "you cant control"
when going to sign. Anything i can do for you regarding this, just
tell me.

As i can do RSA512 or RSA1024 with a 2048 RSA key, and like someone
suggested, i think a default mechanism/algorithm (if not specified)
should be enabled, but developers should be able to choose one...

Will be possible to create a more complex sign-formats, like PKCS#1,
PKCS#7, XAdES, XML, PDF...?

Maybe i didnt understand it well, but Im REALLY concerned about your
public key handling. IIUC, a site could get access to the public key,
and i dont waht that at all.
My public key can contain my name, identity card or even my
address...i think this IS a privacy issue.

Public or private keys should be a reference/handler, not the keys.
Maybe you could do something like this:

-invoke selectCertDialog and keep an internal reference of selectedCert.
-do operations like hash(sign) form js, without having the public cert
(only internal has the reference)
-to operate with another key, invoke selecCertDialog again

Thanks a lot four your work, Im sure more question should come...

[Mountie Lee]

Hi.
I'm from Korea.
let me comment something more.

for signWithUserConfirmation
as I know, that requirement was raised because of regulations of some
countries.
it is UI specific function and need some fixed UI (already
mentioned spanish DNIe)
I think we need some control for that with CSS style
the very important concept is "the content that user is viewing on the
screen" must be same to sign source.

for the encodings
many asian countries has it's own local encodings
EUC-KR at Korea, Shift-JIS at Japan, GB2312 at China
those are not unicode.
even with these encodings, I think DOMCryptAPI must be work.
base64 encoding is one of good considerations
but that is not so user friendly.

for smartcard supporting
I think PKCS#11 is the best choice I can think.
the key pair(public and private) will be stored at secured browser keystore
(the existing)
the browser keystore can be connected to smartcard with PKCS#11 interface.
even in Korea, Smartcard emulated USB token is widely spreading and P11 is
becoming base technology

for the sign formats
my personal interest is XMLDSIG which is W3C standard.

for the user environment
in Korea, the government's basic understanding is "user environment can be
easily compromised"
before going to production, followings are required to be checked.
- resistant for Key-Logger : normally onscreen keyboard is used. but in
future more good solutions can be used
- resistant for virtual memory hacking : even with SSL communication, the
private information is searched in virtual memory area (like windows
pagefile.sys). the DOMCryptAPI must have memory cleanup logic.

---------
in Korea, binary plugins (ActiveX or Flash) are widely used for generating
signature or managing key pairs.
I hope this project can be good replacement of current binary plugins.

regards
mountie.

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



--
Mountie Lee

Tel : +82 2 2140 2700
E-Mail : mou...@paygate.net

=======================================
PayGate Inc.
THE STANDARD FOR ONLINE PAYMENT
for Korea, Japan, China, and the World

[helpcrypto helpcrypto]

> for signWithUserConfirmation
> as I know, that requirement was raised because of regulations of some
> countries.
> it is UI specific function and need some fixed UI (already
> mentioned spanish DNIe)
> I think we need some control for that with CSS style
> the very important concept is "the content that user is viewing on the
> screen" must be same to sign source.

Spanish DNIe shows their own UI which says "you are going to sign some data...".
I dont know if it is harcdoded on pkcs#11/csp libraries (looks like a
winapi dialog on windows), or its made on card...but ill love to skip
it when doing sign-batch operations!

I think you are talking about other thing.

Indeed what you think you are going to sign and what you are signning
MUST be the same.
Tax ministry is spain, for example, uses firefox *UNCOOL* displaying
something like an xml:
You are going to sign this, please review and confirm:
<asdasdadasda><node><0000><wtf is this...>

IMHO, that is an horrible user-unfriendly experience, and should be
replaced from something visual, like a image or pdf like.
(but how???)

> I think DOMCryptAPI must be work. base64 encoding is one of good considerations but that is not so user friendly.

user-friendly <> devel-friendly.

> for smartcard supporting
> I think PKCS#11 is the best choice I can think.
> the key pair(public and private) will be stored at secured browser keystore
> (the existing)
> the browser keystore can be connected to smartcard with PKCS#11 interface.
> even in Korea, Smartcard emulated USB token is widely spreading and P11 is
> becoming base technology

There are some concerns about privacy and security regarding this.
If you let a browser access smartcard, even displaying a warning and
requiring a PIN, you must think what security risk you are opening to.
I also think PKCS#11 its the best option, but still in discussion.

> - resistant for Key-Logger : normally onscreen keyboard is used. but in
> future more good solutions can be used

i love the shuffled numeric pads some banks use

> - resistant for virtual memory hacking : even with SSL communication, the
> private information is searched in virtual memory area (like windows
> pagefile.sys). the DOMCryptAPI must have memory cleanup logic.

<offtopic alert>
could anyone give me a link where i can learn how to "malloc" safe
memory? (Actually just erasing after use :( )

[David Dahl]

----- Original Message -----
> From: "helpcrypto helpcrypto" <helpc...@gmail.com>
> To: "David Dahl" <dd...@mozilla.com>

> Cc: "dev-platform" <dev-pl...@lists.mozilla.org>, "mozilla's crypto code discussion list"
> <dev-tec...@lists.mozilla.org>
> Sent: Wednesday, April 25, 2012 3:12:23 AM
> Subject: Re: Feedback on DOMCryptInternalAPI
>

> As said before, i dont know if you have considered smartcard.
> These, (as discussed in
> https://groups.google.com/forum/#!topic/mozilla.dev.tech.crypto/hNS32Zhz9gw)
> could have some other needs. IMHO, a lot of discuss yet to come.

Supporting smart cards in the spec and first implementations is not a goal, however, I think a lot of the base work we are doing will help in a future iteration. For instance, I hope that this Gecko 'internal API' will help extension and browser developers to experiment with smartcards, crypto keys, etc.

>
> I have experienced some issues regarding to encoding.
> A page encoded in ISO send some data to a page encoded in UTF-8 which
> signs...then, verify could not match.
> So we decide to use base64 binary encoding for all operations. I
> think
> "plaintext" maybe its not the best option (or maybe im wrong)
>

Are you saying you base64 encode the data to be signed before the signature is created?

> <half offtopic>
> Its being discussed on the other thread, but just to let you know,
> actually, theres not a way for knowing if Keypair generation is made
> on softokn or smartcard, and that lead (in our company) to some
> problems. I think something must be done about this.
> I agree with Anders Certenroll could be (*IS*) evil, but if an
> app/site developer what to use an specificsmartcard, perhaps he
> should
> be able to know if that smartcard is present...
> </half offtopic>
>
> Regarding signWithUserConfirmation, you should consider some devices
> (like spanish DNIe) show their own window, which "you cant control"
> when going to sign. Anything i can do for you regarding this, just
> tell me.
>

sounds like some research to do. thanks.

> As i can do RSA512 or RSA1024 with a 2048 RSA key, and like someone
> suggested, i think a default mechanism/algorithm (if not specified)
> should be enabled, but developers should be able to choose one...
>

agreed, however, we will have minimum keybits and constraints on the algorithms allowed.

> Will be possible to create a more complex sign-formats, like PKCS#1,
> PKCS#7, XAdES, XML, PDF...?
>
> Maybe i didnt understand it well, but Im REALLY concerned about your
> public key handling. IIUC, a site could get access to the public key,
> and i dont waht that at all.
> My public key can contain my name, identity card or even my
> address...i think this IS a privacy issue.

Public key as a privacy risk? I don't imagine we will have an address bound the the public key.

>
> Public or private keys should be a reference/handler, not the keys.

Private keys will never be visible to content, only a keyID. Again, this thread is really about an internal API specific to Gecko.

Regards,

David

[helpcrypto helpcrypto]

> Supporting smart cards in the spec and first implementations is not a goal, however, I think a lot of the base work we are doing will help in a future iteration. For instance, I hope that this Gecko 'internal API' will help extension and browser developers to experiment with smartcards, crypto keys, etc.

Really happy to hear. Keep us updated when some work is made!

> Are you saying you base64 encode the data to be signed before the signature is created?

No. Let me show you an example.
Consider you provide this API:
sign(keyId, data)
IMHO, the correct way of invoking wil be:
sign(1,"ZGF0YXRvYmVzaWduZWQ=")
Inseatd of (cause it can end in encoding translation problem)
sign(1,"datatobesigned")

For example, using iso-8859-1 and UTF-8 this string is not the same
"En España el Paragüas es invisíble"

> Public key as a privacy risk? I don't imagine we will have an address bound the the public key.

My X509 cert has my name, surname, identity ID...i dont want ANY site,
(except those requiring SSL client authentication like Tax ministry)
have any access to it.
My public key has a unique hash that could (easily) be used to track a
user. I dont want that either.

Regards

[ianG]

(couple of off the wall observations, 'scuse the fast typing...)

On 26/04/12 01:53 AM, David Dahl wrote:

>> I have experienced some issues regarding to encoding.
>> A page encoded in ISO send some data to a page encoded in UTF-8 which
>> signs...then, verify could not match.
>> So we decide to use base64 binary encoding for all operations. I
>> think
>> "plaintext" maybe its not the best option (or maybe im wrong)
>>

> Are you saying you base64 encode the data to be signed before the signature is created?

If you want the signature + document to be legally sustainable and/or
user-interpretable, then plaintext signatures with embedded public keys
are the way to go. You can base64-encode the public keys :) Some
further development of this theme is at
http://iang.org/papers/ricardian_contract.html

otoh if the signature is more a digsig of protocol import then any
format will do.

>> Will be possible to create a more complex sign-formats, like PKCS#1,
>> PKCS#7, XAdES, XML, PDF...?
>>
>> Maybe i didnt understand it well, but Im REALLY concerned about your
>> public key handling. IIUC, a site could get access to the public key,
>> and i dont waht that at all.
>> My public key can contain my name, identity card or even my
>> address...i think this IS a privacy issue.
>

> Public key as a privacy risk?

Public keys are less of a privacy risk, because they only evidence a
repeat engagement. Certificates are a horrible privacy risk. Have a
look at client certs and SSL - the servers can be configured to
'optional' which causes browsers to supply certs which include info ...
the response to this is that browsers then have to ask the users for any
use of a cert, else risk a privacy breach, which leads to unusability
without quite sophisticated caching and matching. Which they don't have.

> I don't imagine we will have an address bound the the public key.

In some countries e.g., in Europe, identity (papers and registration of
residency) is intimately bound with address. There are legal traditions
and reasons for this which don't exist in the anglo world; it isn't
reliable to ignore the difference by saying "we won't do that, then."
Check out QCs, do they not have addresses? How then can legal
obligations be fulfilled in certain countries?




iang

[helpcrypto helpcrypto]

> If you want the signature + document to be legally sustainable and/or
> user-interpretable, then plaintext signatures with embedded public keys are
> the way to go.  You can base64-encode the public keys :)  Some further
> development of this theme is at
> http://iang.org/papers/ricardian_contract.html

Maybe im wrong...

Lets suppose i have a page with ISO-8859 encoding. In a textarea
-which i want to sign- I type:
"Legión Española" and click sign (this will translate ISO into bytes and sign)
Then, i send the original+signed data to you.

You receive on UTF-8 and try to verify signature. As your UTF string
tranlated into bytes its not the same i use, the signature will not be
the same-> verification fail.

...am i correct?

(Maybe iso/utf-8 share those bytes, but im sure Kim Jong Un use another ones)

[David Dahl]

----- Original Message -----
> From: "ianG" <ia...@iang.org>
> To: dev-tec...@lists.mozilla.org
> Sent: Thursday, April 26, 2012 6:14:43 AM
> Subject: Re: Feedback on DOMCryptInternalAPI
>

> > I don't imagine we will have an address bound the the public key.
>
>
> In some countries e.g., in Europe, identity (papers and registration
> of
> residency) is intimately bound with address. There are legal
> traditions
> and reasons for this which don't exist in the anglo world; it isn't
> reliable to ignore the difference by saying "we won't do that,
> then."
> Check out QCs, do they not have addresses? How then can legal
> obligations be fulfilled in certain countries?
>

I understand the concern now. Understanding these use cases is very helpful, thanks!

David

[ianG]

On 26/04/12 17:32 PM, helpcrypto helpcrypto wrote:

>> Are you saying you base64 encode the data to be signed before the signature is created?
>

> No. Let me show you an example.
> Consider you provide this API:
> sign(keyId, data)
> IMHO, the correct way of invoking wil be:
> sign(1,"ZGF0YXRvYmVzaWduZWQ=")
> Inseatd of (cause it can end in encoding translation problem)
> sign(1,"datatobesigned")
>
> For example, using iso-8859-1 and UTF-8 this string is not the same
> "En España el Paragüas es invisíble"

Ah, canonicalisation. You need to figure out a form to preserve this.

but also, this is a component that is not directly connected to signing.
There is an intermediate part, hashing. So the general technique is
more like:

text => canonoicalisation => hash => digsig.

The smart card or other container for private key is typically only
interested in the last step.

>> Public key as a privacy risk? I don't imagine we will have an address bound the the public key.
>
> My X509 cert has my name, surname, identity ID...i dont want ANY site,
> (except those requiring SSL client authentication like Tax ministry)
> have any access to it.
> My public key has a unique hash that could (easily) be used to track a
> user. I dont want that either.

:)

iang

[ianG]

Yes, correct. The message you send to me must be capable of
self-describing its characteristics that lead me to successfully
interpret it at all levels that I might need. UTF, signature, page
layout, all.

So, you need a canonicalisation format in order to deal with UTF, etc.
Also there are various artifacts with other issues.

If you've looked at the old PGP form, you'll find that it drops trailing
spaces - that's because popular word-processors used to add trailing
spaces. Later on we had the problem that mail programs would move the
words around, or quote them differently. Hence MIME and that funny '='
method. All of these are real-life problems in working with documents,
and any signature has to survive the assault of "programs that know
better..."

Out of this are two popular directions:

sophistication - UTF, MIME, XML, etc.

simplification - ascii, lines, space-stripping, OpenPGP.

iang

[Wan-Teh Chang]

David,

Here are my review comments on https://wiki.mozilla.org/DOMCryptInternalAPI:

1. I don't understand the difference between the two methods that
generate key pairs:
PKGenerateKeyPair
SigGenerateKeyPair

2. PKEncrypt just need a public key, not a key pair.

3. I suggest not assigning 0 to any algorithm enumerator. This allows
the use of 0 as an invalid value. We can't use -1 because the type is
unsigned long.

So ALGORITHM_RSA should be 1 and ALGORITHM_DSA should be 2.

4. Like PKDecrypt, Sign just needs aKeyID, which represents a private key.

5. Verify should take a public key.

6. The second arguments of Sign and Verify should have the same name
(because the refer to the same thing) and the name should not imply it
is encrypted (such as aPlaintext and aClearBytes). You can use
'message' as the argument name.

7. When verifying a MAC, the byte comparison must be constant time to
avoid leaking timing info. Leaking timing info of MAC verification
could be problematic in some situations. This issue is described in
https://groups.google.com/group/keyczar-discuss/browse_thread/thread/5571eca0948b2a13

So I suggest adding a verify() method to the CryptoHmac interface, so
that we can implement the verify() method with constant time byte
comparison.

Wan-Teh Chang

[Kyle Hamilton]

On Thu, Apr 26, 2012 at 12:32 AM, helpcrypto helpcrypto <helpc...@gmail.com> wrote:
>> Supporting smart cards in the spec and first implementations is not a goal, however, I think a lot of the base work we are doing will help in a future iteration. For instance, I hope that this Gecko 'internal API' will help extension and browser developers to experiment with smartcards, crypto keys, etc.
>
> Really happy to hear. Keep us updated when some work is made!
>

>> Are you saying you base64 encode the data to be signed before the signature is created?
>
> No. Let me show you an example.
> Consider you provide this API:
>    sign(keyId, data)
> IMHO, the correct way of invoking wil be:
>    sign(1,"ZGF0YXRvYmVzaWduZWQ=")
> Inseatd of (cause it can end in encoding translation problem)
>    sign(1,"datatobesigned")
>
> For example, using iso-8859-1 and UTF-8 this string is not the same
> "En España el Paragüas es invisíble"

This is what the unique tags on ASN.1 UTF8String and IA5String and PrintableString and Shift-JIS and such are for, specifying the encoding.

>> Public key as a privacy risk? I don't imagine we will have an address bound the the public key.
>
> My X509 cert has my name, surname, identity ID...i dont want ANY site,
> (except those requiring SSL client authentication like Tax ministry)
> have any access to it.
> My public key has a unique hash that could (easily) be used to track a
> user. I dont want that either.

The certificate is not the public key. The public key is the only identity the computer can comprehend, and the certificate is metadata about the key which is (ideally) trusted for fiduciary work. The public key itself is its own identity as well, so your point doesn't even rely on having a unique hash.

But! Here's someone who actually thinks like I do, that this information has value, and therefore this information must be protected.

Fortunately, I have something for that. Behold: the Identity Trustee. This is a certifier which would accept your current certificate and a newly generated public key, both signed by both the certified keypair and the generated keypair. It would then sign a certificate for the generated public key which says, basically, "I know who this keyholder is, but I will only tell valid state authority."

This would permit site owners to discourage spam and vandalism by knowing that they can hold the keyholder accountable if necessary, without disclosing the keyholder's (your) identity to every site, and without requiring the same key to be used on every site. Effectively, your public key would become your pseudonym. And, this is not a usage which would have the potential to endanger broad swaths of Mozilla's user base like the DigiNotar google.com certificate.

-Kyle H

[Kyle Hamilton]

On Thu, May 3, 2012 at 4:27 PM, Wan-Teh Chang <w...@google.com> wrote:
> David,
>
> Here are my review comments on https://wiki.mozilla.org/DOMCryptInternalAPI:
>
> 1. I don't understand the difference between the two methods that
> generate key pairs:
>    PKGenerateKeyPair
>    SigGenerateKeyPair

GenerateKeyPair(purpose:keyEncryption)
GenerateKeyPair(purpose:Signature)

I think this is due to France, and legacy requirements for different caps on encryption versus signature key strengths. I don't know if these are still concerns.

> 2. PKEncrypt just need a public key, not a key pair.

This is not correct for EC. To do PKEncrypt there, you must have both the source private key and destination public key available to perform ECDH key agreement. Then, put that agreed value through a key derivation function (digest), and finally symmetrically encrypt the random message symkey with the derived symkey. There is no reversible transform from something which can be calculated solely from the public key, unlike RSA.

Please implement RSA and DSA with a second, null parameter, so that this use can be enabled for EC.

> 3. I suggest not assigning 0 to any algorithm enumerator.  This allows
> the use of 0 as an invalid value. We can't use -1 because the type is
> unsigned long.
>
> So ALGORITHM_RSA should be 1 and ALGORITHM_DSA should be 2.

ALGORITHM_ECDSA should be in there as well.

However, I do not agree with the idea of enumerating algorithms and modes separately. Down that path lies ECB and non-KDF agreed key usage.

> 4. Like PKDecrypt, Sign just needs aKeyID, which represents a private key.

Sign needs to know some of the metadata associated with the keyID, I should think? Particularly for ECC certificates, SEC1 specifies an alternate encoding where the parameters are inherited from the certifier. If NSS stores these parameters for the private key regardless, I shall withdraw this objection.

-Kyle H

[Kyle Hamilton]

On Thu, Apr 26, 2012 at 12:32 AM, helpcrypto helpcrypto <helpc...@gmail.com> wrote:
>> Supporting smart cards in the spec and first implementations is not a goal, however, I think a lot of the base work we are doing will help in a future iteration. For instance, I hope that this Gecko 'internal API' will help extension and browser developers to experiment with smartcards, crypto keys, etc.
>
> Really happy to hear. Keep us updated when some work is made!
>
>> Are you saying you base64 encode the data to be signed before the signature is created?
>
> No. Let me show you an example.
> Consider you provide this API:
>    sign(keyId, data)
> IMHO, the correct way of invoking wil be:
>    sign(1,"ZGF0YXRvYmVzaWduZWQ=")
> Inseatd of (cause it can end in encoding translation problem)
>    sign(1,"datatobesigned")

I observe that yes, this is "base64 encoding the data to be signed before the signature is created".

>> Public key as a privacy risk? I don't imagine we will have an address bound the the public key.
>
> My X509 cert has my name, surname, identity ID...i dont want ANY site,
> (except those requiring SSL client authentication like Tax ministry)
> have any access to it.
> My public key has a unique hash that could (easily) be used to track a
> user. I dont want that either.

Huh. Someone who thinks like I do. This information has value, thus this information must be protected.

Fortunately, I have something for that. Behold: the Identity Escrow Agent. This is a certifier who would take { your full certificate, a new public key }, the set signed with both asserted keys (axiomatic binding), then create a certificate around the new public key which says "I know who this is, but I shall not tell anyone except legitimate state authority."

The idea is that site owners would be able to start requiring this kind of certificate, so that they can hold spammers and vandals accountable -- without becoming private information trustees and becoming subject to various states' felonization of handling personal information with less than PCI 2.0 controls.

This is a use which is far less dangerous to the broad swath of Mozilla's users than the false google.com certificate, and which has a much smaller exposure if the service is ever compromised. There would be no authoritative binding information within the escrow certificate, which would mean that it could only really be appropriate for establishing new non-fiduciary service relationships -- but this is a usage which has no current expression, and which I think would bypass many if not most of the issues preventing consumers and site owners from seriously looking at cryptographic solutions. (It would definitely bypass all of mine.)

-Kyle H

[helpcrypto helpcrypto]

Yesterday thoughts:

Some policies say "Before signing, a preview of what is going to be
signed must be shown to the user".

If we use something like:
signedData=sign(key,dataToBeSigned)
this could show, for example, a pdf preview of what is being signed.

I love that idea, but what if i actually want to sign a bunch of documents?
for(i=0;iz10;i++){
signedData=sign(key,dataToBeSigned[i])
}
will show 10 previews, and thats horrible.

What about using another API instead?
signInit(key) //key to sign
signAdd(data) //one call for each document to be signed in this block
signFinal() //show a single preview for all documents in this
block and do signing (of approved/selected)

there could be also a sign wrapper like:
sign(key,data){
signInit(key)
signAdd(data)
signFinel() //preview & sign
}

BTW: i also realized that server signature validation requires public
key, so privacy issues relating public key are impossible to avoid.

Open to critics, comments and suggests, and a happy monday to all!