Monday, February 20, 2017

Fossa Guard permissions explained.

Permissions FossaGuard requests often provoke questions about the reason and the necessity. Let us explain it in details.

0. Know your email address
Well, it sounds logical

1. Compose and send new mail. 
Looks reasonable once we would like to compose and to send signed / encrypted S/MIME messages. 

2. View, manage and permanently delete your mail in Gmail. 
View also looks normal since we gonna view S/MIME messages. Manage and delete sounds rather intriguing but it let us create and keep a single copy of encrypted S/MIME message in your Sent box when you send it to several recipients. It is your personal copy you can view when in fact each your recipient has got a copy encrypted specifically for him.

3. Create, update and delete labels. 
For your convenience, we create (if not exists) S/MIME label and mark S/MIME messages by it.

4. View your settings (e.g. filters and labels). 
Helps us to check if you already have S/MIME label or not.

5. Read and change all your data on the websites you visit. 
This is #1 reason for questioning us. The reason Fossa Guard requires this permission is the necessity to download Certificate Revocation List (CRL) from URLs discovered in your certificates. Fossa CRL is accessible at https://fossa.me/crl/f2.crl by the way. Certification validation vs actual CRL is a mandatory check according to the specification and it was introduced since V0.2.1.

One can also understand it as also the permission to read browser history, but it's not actually it. There is an interesting and sometimes funny discussion about the right sentence for the last permission.


Please do not hesitate to contact us for further explanations if you need.

Always yours,
Fossa Team

Thursday, February 2, 2017

Fossa Guard V0.3.1 Interoperability Mission

New V0.3.1 (aka beta 3) of free S/MIME solution for Gmail has been released with Interoperability mission on board. Below supported and tested scenarios:


Microsoft Outlook specifics 
One interesting issue was discovered during integration with MS Outlook. As you may know, S/MIME depends on PKCS#7 format to transfer messages. In its turn, PKCS#7 relies on ASN.1 DER/BER encoding. DER/BER encoding is standard TLV (Type / Length / Value) and Length can be encoded in 2 forms: a definite length form and an indefinite length form (refer to X.690 8.1.3). 
Every e-mail client we tested Fossa Guard with supports both Length forms, however, MS Outlook supports only indefinite length form.

Sent TO Gmail + FossaGuard from

Mozilla Thunderbird Outlook (desktop) iOS Mail Android CipherMail
multipart/signed OK OK OK OK
signed-data OK
enveloped-data OK OK OK OK
enveloped-data (multipart/signed) OK OK OK OK
enveloped-data (signed-data) OK

Sent FROM Gmail + FossaGuard to

Mozilla ThunderbirdOutlook (desktop)iOS MailAndroid CipherMail
signed-dataOKOKOKOK
enveloped-dataOKOKOKOK
enveloped-data (signed-data)OKOKOKOK

Documentation and video updates are coming soon ...

With love from Fossa Team 
on Groundhog day, 2017