I'm currently trying to build an OpenBanking application, but I'm having a hard time differentiating between the certificates.
I've generated an OBWAC and OBSEAL certificate, however I can't understand what is the difference between those and a QWAC and QSEAL? Are the latter ones issues by a trusted third-party provider or can I generate them too? Do they have some different fields?
In short, the main difference is that OBWAC and OBSealC can only be used for accessing Open Banking APIs of the ASPSPs based in the UK, while QWAC and QSealC can also be used for accessing PSD2 APIs of EU-based ASPSPs (in case the TPP's license allows that). Also in general qualified certificates fall under eIDAS regulation and have application outside open banking (especially QSealC). And yes, qualified certificates can only be issued by Qualified Trust Service Providers (aka QTSP). The list of QTSPs can be found here: https://esignature.ec.europa.eu/efda/tl-browser/#/screen/home (not sure if the UK list is still updated).
Related
I'm new in SSL concept , Sorry I don't know my question is correct or not ...
Recently I wanna know root_certificates.hpp should be specific for every clients? I mean that clients should create it by openssl?? or it's general and all clients can use it?
root_certificates.hpp is only there to make the examples portable.
On your system, you typically can use set_default_verify_paths.
If your application additional requirements, which is often, you will want to include your own certificate store in the way that your application chooses. There are more details to customize the verification process: https://www.boost.org/doc/libs/1_80_0/doc/html/boost_asio/reference/ssl__context.html (see also https://www.boost.org/doc/libs/1_80_0/doc/html/boost_asio/reference/ssl__stream/set_verify_callback.html).
I'm looking for a tool or method to prove the authenticity of resources download from the web and stored locally. To be clear: I don't mean the SHA or MD5 checksums to verify a downloaded file. What I need is a way to download and store a web resource in such a way that I can later prove that said resource indeed originated from that web server.
In particular for the following scenario: A website published an article about a client. He would like to sue for defamation of character. I need a way to store the article without them having the possibility of simply removing it and denying they ever published it. So preferably this would be a tool that is backed by publications making it credible in court.
I have thought about storing the TLS certificate, keys and the encrypted data. That would rely on the root CA, but I think that would in itself not be a problem. I could do this using a custom program and a library like OpenSSL, but I think this is such a common problem, there probably is a relatively standard tool for it. Also, I am not entirely sure to what extent this would constitute reliable evidence. And can someone point to publications that would back this method?
Maybe I am using the wrong search terms, but everything I find is about aforementioned SHA or MD5 checksums. Any help is much appreciated.
If I understand correctly you need something like signature with timestamp. Yes?
You not only need checksum from document (article, text value, whatever) but also proof that this article really existed in time.
When using digital signature you can store such timestamp in 3rd party certified providers. You sign document and send checksum to 3rd party provider. Later you can ask provider to verify that this exact document is valid & was indeed created at given time.
https://en.wikipedia.org/wiki/Trusted_timestamping
As this can cost (fee for provider to store the timestamps) you can create checksums from many documents (like take all documents from one hour), store all of them in a single file, create checksum from that file and sign it with timestamp. This way you create one timestamp for documents batch, not for each document.
This question has been asked before... here -> what are the URLs for in claim-types.
But the accepted answer doesn't actually answer the question. Why are claim types in ASP.NET Core Authentication formatted as HTTP Urls? What is the purpose of the "http://schemas.microsoft.com/...." portion of the claim type? It's not an actual hyper text transfer protocol URL to a web site or a web service of some kind. There is no schema document sitting at that address. So what is the purpose of formatting them as HTTP URLs? I know WHAT they are. I just don't know WHY they are formatted as they are.
I believe Microsoft use URIs because they suit the purpose - they need a unique identifier to identify each claim type, that is preferably human-readable, and guaranteed not to accidentally clash with names created by other third-party components or developers themselves.
The fact that Microsoft chose URLs (which is just a type of URI) is probably conventional. Over the years various standards for claim types were developed by different organizations, many of which were based on XML namespaces that were URLs (for example, see this standard document by OASIS). Many of these well-known claim types are still in use today, so it would make sense to format any newly-defined claim types in the same fashion as the existing well-known ones.
I making a new app and want to submit to app store.
But at the time of final submission
there is check for Export Compliance.
What should I Check Yes Or No.
I use https url in my app.
Please Help Me .
Thanks In Advance.
When you know that you ARE export compliant you can put this in your Info.plist:
<key>ITSAppUsesNonExemptEncryption</key>
<false/>
This will prevent App Store Connect from asking you questions about export compliance.
If you are using https in your application, you will need to answer yes to this question, even if all you are using is built in mechanisms to communicate over https. The good news is that you no longer need to get the Encryption Registration Number (ERN) - the current requirements (as of August 2017) are that you just need to submit the annual self classification report to the BIS(Bureau of Industry and Security). To submit a self classification report, follow the instructions on item 13 in this FAQ: A sample Self Classification report can be found here.
For a great write up that talks about both sides of the story (apps that only use common / freely available encryption, like SSL, as well as apps that have their own, proprietary encryption, see this Medium post.
Please don't listen to other people who state that they just answer no to this question to make things easier when submitting an app.
As of February 2018 this is the process to file an Annual Self Classification Report to BIS (Bureau of Industry and Security):
https://www.bis.doc.gov/index.php/policy-guidance/product-guidance/high-performance-computers/223-new-encryption/1238-how-to-file-an-annual-self-classification-report
To get a ECCN (Export Control Classification Number) for a HTTPS mass market iOS app follow, these steps.
Download the quick reference guide to classify your app.
https://www.bis.doc.gov/index.php/documents/new-encryption/1652-cat-5-part-2-quick-reference-guide/file
For a basic HTTPS iOS app used to securely access a webpage or transfer a file use
5D992 which is Information Security” “software” not controlled by 5D002.
If your app contains more encryption functionality, then reference the policy guide. https://www.bis.doc.gov/index.php/policy-guidance/encryption
Might not be what you want to hear, but you will need to review the policy and correctly categorize the app and get the correct ECCN.
Now go to the SNAP-R form. https://snapr.bis.doc.gov/snapr/
To get to the form from the BIS homepage.
https://www.bis.doc.gov/index.php
Then select Licensing -> Simplified Network Application Process Redesign (SNAP-R)
Register Online for a SNAP-R account.
https://snapr.bis.doc.gov/registration/Register.do
The Bureau of Industy and Security will return a CIN application ID quickly via email.
Return to the main SNAP-R page with the CIN issued number and login.
Select "Create Work Item "
The Type will be "Commodity Classification Request"
Reference number is 7 digits. I used my phone number.
Create
Fill in Contact Information.
Leave License Information Blank
Fill in Company Designation any info missing. When you created the CIN this info was requested.
Other Party can be left blank.
Now for each app you want to register, fill in a Export Item and press Add Export Item. Multiple apps can be submitted on the same request.
ECCN will be 5D992
APP can be left blank. It is the Adjusted Peak Performance"("APP") which for a commodity iOS app is not required.
Product/Model is the name of the app in the App Store.
CCATS can be left blank.
Manufacturer is your company name.
Technical Description - briefly describe the apps function and how HTTPS is leverage. Keep it simple. They are interested if the app is a security risk and how encryption is used.
example:
AppName is distributed as an Apple iOS App. It uses HTTPS to download/upload daily updates to and from xxxx. The download is used to generate a table. An In-App .99 cent purchase expands the table results to include xxxx.
Additional information explains in more detail how HTTPS has been implemented.
The HTTPS file transfer is a URLSession data transfer task found in the Apple Foundation library. The iPhone automatically performs the download of the published data in csv file format, using the HTTPS protocol for a secure transfer.
Make sure you saved all your drafts. Check for errors. Then submit.
The turnaround is pretty fast. Mine took around an hour. But I am sure it varies.
The other option is once a year you can submit an Annual Self Classification Report. But if you have a SNAP-R CCATS number you are not required to submit a Annual Self Classification Report.
https://www.bis.doc.gov/index.php/policy-guidance/encryption/4-reports-and-reviews/a-annual-self-classification
This is very simple. Download the sample csv file. Delete out the sample data leaving the headings. The heading are required. Fill in the columns. The column Authorization Type is MMKT. Item type Other: HTTPS File Transfer. Save the file and submit.
The BIS SNAP-R hotline [202-482-4811 DC, 949-660-0144 CA] and the Encryption Hotline for the annual submission [202-482-0707] are both very helpful. Last point, the BIS has helpful set of YouTube video.
https://www.bis.doc.gov/index.php/online-training-room
Hope this helps.
From Complying with Encryption Export Regulations: Declare Your App’s Use of Encryption:
Typically, the use of encryption that’s built into the operating system—for example, when your app makes HTTPS connections using URLSession—is exempt from export documentation upload requirements, whereas the use of proprietary encryption is not. To determine whether your use of encryption is considered exempt, see Determine your export compliance requirements.
So Apple says that for usual HTTPS scenarios, you do not need to upload export documentation for your app.
We have a single-page app (AngularJs) which interacts with the backend using REST API. The app allows each user to see information about the company the user works at, but not any other company's data. Our current REST API looks like this:
domain.com/companies/123
domain.com/companies/123/employees
domain.com/employees/987
NOTE: All ids are GUIDs, hence the last end-point doesn't have company id, just the employee id.
We recently started working on enforcing the requirement of each user having access to information related exclusively the company where the user works. This means that on the backend we need to track who the logged in user is (which is simple auth problem) as well as determining the company whose information is being accessed. The latter is not easy to determine from our REST API calls, because some of them do not include company id, such as the last one shown above.
We decided that instead of tracking company ID in the UI and sending it with each request, we would put it in the subdomain. So, assuming that ACME company has id=123 our API would change as follows:
acme.domain.com
acme.domain.com/employees
acme.domain.com/employees/987
This makes identifying the company very easy on the backend and requires minor changes to REST calls from our single-page app. However, my concern is that it breaks the RESTfulness of our API. This may also introduce some CORS problems, but I don't have a use case for it now.
I would like to hear your thoughts on this and how you dealt with this problem in the past.
Thanks!
In a similar application, we did put the 'company id' into the path (every company-specific path), not as a subdomain.
I wouldn't care a jot about whether some terminology enthusiast thought my design was "RESTful
" or not, but I can see several disadvantages to using domains, mostly stemming from the fact that the world tends to assume that the domain identifies "the server", and the path is how you find an item on that server. There will be a certain amount of extra stuff you'll have to deal with with multiple domains which you wouldn't with paths:
HTTPS - you'd need a wildcard certificate instead of a simple one
DNS - you're either going to have wildcard DNS entries, or your application management is now going to involve DNS management
All the CORS stuff which you mention - may or may not be a headache in your specific application - anything which is making 'same domain' assumptions about security policy is going to be affected.
Of course, if you want lots of isolation between companies, and effectively you would be as happy running a separate server for each company, then it's not a bad design. I can't see it's more or less RESTful, as that's just a matter of viewpoint.
There is nothing "unrestful" in using subdomains. URIs in REST are opaque, meaning that you don't really care about what the URI is, but only about the fact that every single resource in the system can be identified and referenced independently.
Also, in a RESTful application, you never compose URLs manually, but you traverse the hypermedia links you find at the API endpoint and in all the returned responses. Since you don't need to manually compose URIs, from the REST point of view it's indifferent how they look. Having a URI such as
//domain.com/ABGHTYT12345H
would be as RESTful as
//domain.com/companies/acme/employees/123
or
//domain.com/acme/employees/smith-charles
or
//acme.domain.com/employees/123
All of those are equally RESTful.
But... I like to think of usable APIs, and when it comes to usability having readable meaningful URLs is a must for me. Also following conventions is a good idea. In your particular case, there is nothing unrestful with the route, but it is unusual to find that kind of behaviour in an API, so it might not be the best practice. Also, as someone pointed out, it might complicate your development (Not specifically on the CORS part though, that one is easily solved by sending a few HTTP headers)
So, even if I can't see anything non REST on your proposal, the conventions elsewhere would be against subdomains on an API.