I want to put IETF RFC document reference in my presentation. Is that RFC document number is permanent?
Yes they are, they do not change. New numbers are allocate for new RFCs.
Related
There are different standards for PDF files:
PDF/A: PDF/A-1a, PDF/A-2a or PDF/A-3a
PDF/UA
Potentially more
Is it possible to check if a given PDF file follows the PDF/UA standard?
Partially.
Most PDF based ISO standards (PDF/X, PDF/VT, PDF/E, PDF/VCR, PDF/A) can be automatically checked in software. I'm affiliated with a company (callas software) that has commercial software that handles all of these. The tool also has support for PDF/UA, but the verification is only partial.
The reason is subtle but important. All other PDF based ISO standards state that PDF files need to follow certain guidelines, and those guidelines are easy to verify in software. This or that property has to be set, that property can't have this value, this element must have that or that color space...
PDF/UA makes many of such claims as well, but it also makes different claims. Two examples:
For a document to be compliant with PDF/UA, all text in the document must be tagged with the "correct" language.
Similarly, the elements in the document must be tagged with their type (image, paragraph, title, footnote, table) "in a correct way".
The problem is not for software to check that language tags are present or that structure is present. The problem is for the software to verify that the language tags are indeed for the correct language. And that the structure in the document corresponds to what a human would think makes sense.
There are more examples like that in the PDF/UA standard, and they mean that while software can definitely assist in the verification process, it can't conclusively say that the file is correct. The best it can ever say is that it doesn't contradict one of the computer verifiable rules.
On page 58 of RFC 4871, there is an informative reference to [BONEH03], "Proc. 12th USENIX Security Symposium, "Remote Timing Attacks are Practical", 2003. I'm wondering: What does BONE mean?
I know RFC means "Request For Comments", FIPS means "Federal Information Processing Standards Publication", and ITU means "International Telecommunication Union". So, I'm guessing BONE has a meaning along the same lines, but I have not been able to figure it out after several internet searches.
BONEH refers to Dan Boneh, one of the authors of the "Remote timing attacks are practical" paper that RFC 4871 makes reference to.
How can we check whether our Digital Signature on PDF is according to 'PAdES' standard ?
Best Regards
Pearapon S.
Bangkok, Thailand
The OP uses third-party software (iText 5.4.2 in the case at hand) for creating PAdES signatures and now wants to check whether the resulting signatures indeed satisfy the PAdES specification. Here some ideas for that:
What do you mean by "PAdES signature"?
First of all you have to define what you mean by "PAdES signature":
Do you mean that term as defined in the upcoming PDF 2.0 specification:
The PDF signatures using the Subfilter value ETSI.CAdES.detached are referred to as PAdES signatures and they follow one of two CMS profiles created to be compatible with the corresponding CAdES profiles defined in ETSI EN 319 122.
(ISO 32000-2 FDIS section 12.8.3.4 - CAdES signatures as used in PDF)
Do you mean more specifically a signature following one of the PAdES baseline signature profiles as specified in ETSI EN 319 142-1?
Clause 6 defines four levels of PAdES baseline signatures, intended to facilitate interoperability and to encompass the life cycle of PAdES signature, namely:
a) B-B level provides requirements for the incorporation of signed and some unsigned attributes when the signature is generated.
b) B-T level provides requirements for the generation and inclusion, for an existing signature, of a trusted token proving that the signature itself actually existed at a certain date and time.
c) B-LT level provides requirements for the incorporation of all the material required for validating the signature in the signature document. This level aims to tackle the long term availability of the validation material.
d) B-LTA level provides requirements for the incorporation of electronic time-stamps that allow validation of the signature long time after its generation. This level aims to tackle the long term availability and integrity of the validation material.
(ETSI EN 319 142-1 V1.1.1 section 6 - PAdES baseline signatures)
Or would one of the additional PAdES signatures profiles from ETSI EN 319 142-2 also qualify?
The present document contains a profile for the use of PDF signatures, as described in ISO 32000-1 [1] and based on CMS digital signatures [i.6], that enables greater interoperability for PDF signatures by providing additional restrictions beyond those of ISO 32000-1 [1]. This first profile is not related to ETSI EN 319 142-1 [4].
The present document also contains a second set of profiles that extend the scope of the profile in PAdES part 1 [5], while keeping some features that enhance interoperability of PAdES signatures. These profiles define three levels of PAdES extended signatures addressing incremental requirements to maintain the validity of the signatures over the long term, in a way that a certain level always addresses all the requirements addressed at levels that are below it. These PAdES extended signatures offer a higher degree of optionality than the PAdES baseline signatures specified in ETSI EN 319 142-1 [4].
The present document also defines a third profile for usage of an arbitrary XML document signed with XAdES signatures that is embedded within a PDF file.
(ETSI EN 319 142-2 V1.1.1 section 1 - Scope)
In particular you have to know whether you are also considering the additional PAdES signatures profiles "for CMS digital signatures in PDF" or "for XAdES Signatures signing XML content in PDF" from ETSI EN 319 142-2 or not because these two profiles differ very much from the remaining ones.
I assume you don't consider these two profiles because the former more or less is the good old ISO 32000-1 CMS signature with a few restriction most signers follow anyways, and the latter are XML signatures which are a completely different animal altogether.
All the remaining profiles differ mostly in the amount and type of validation related information and time stamps added to the document to make the validation less and less dependent on data one has to retrieve online.
Options for checking
Manually: You take a PDF browser (like iText RUPS or the PDFBox PDF Debugger), a hex viewer, an ASN.1 Dump utility, the applicable base specification from the list above and the additional specifications referenced from the base specification and check all the criteria.
This requires quite some time for a single signature but in the end you can know everything there is to know about the tested signature. I only recommend this if you have some experience using those tools and working with specifications, or if you really have much time to learn.
Programmatically: You take a general purpose PDF library (if you take a different one than the one you create you signatures with, the credibility of the result might increase), a security functions library (e.g. BouncyCastle), the base specification and the additional ones, and start implementing a program testing the criteria in the specification.
This requires quite some time to develop but then can be re-used, e.g. for quality assurance and regression prevention. I only recommend this if you have some experience using those libraries and working with specifications, or if you really have much time to learn.
You use an existing software or service that evaluates the signature for you, e.g. the ETSI Signature Conformance Checker (http://signatures-conformance-checker.etsi.org/pub/index.shtml), a free online tool that performs numerous checkings in order to verify the conformity of the ETSI Advanced Electronic Signatures.
This obviously is the quickest option but you generally cannot be sure how reliable the tests were executed. Thus, it is good as a first opinion but depending on how much is at stake, I would want more security.
You can hire experts to analyse and assess the validity of your signature according to the desired profile.
This may be expensive but at least you have someone to resort to if later you get into trouble due to some non-compliance.
Question from the title - is it possible to store bank account number in vCard? Does the specification says something? Any guidelines?
m.
Yes. vCARD supports extensions, which means you could use something like
X-BANK-ACCOUNT-NUMBER:12345678
Or, you could just put the details in the comments field.
You can read more about the vCARD extensions on Wikipedia.
I am not an expert on this topic. That said, I strongly recommend against storing any sensitive information in a vCard. As far as I know, vCard does not support encryption (someone please correct me if I am mistaken).
I want to understand RFC 2396 and the whole URL / URI thing better, and since NSURL from Cocoa is based on RFC 2396, I look for an overview. The RFC itself is too hard to read for me.
I'm going to assume that your real question is about the whole URI / URL / URN split. And I'll start by saying that it's just terminology, and in many cases they're interchangeable.
A URL is a Uniform Resource Locator: it identifies an access "scheme", such as http:, and contains enough information to locate that resource using that scheme. It doesn't necessarily contain enough information to access the resource: For example, an HTTP URL will get you to a page, but that page may have authentication requirements for access.
A URN is a Uniform Resource Name: it also starts with a "scheme", then contains arbitrary information appropriate for that scheme. URNs are confusing because, while there are several predefined schemes such as "uuid", there's no specified use for those schemes (unlike, say, HTTP). This is not necessarily a bad thing: I like to use URNs for things like XML Namespaces, where I don't want there to be any implication that you can actually retrieve something related to that namespace.
A URI is a Uniform Resource Identifier: a superset containing URLs, URNs, and a few other identifier types. The RFC mentions URLs and URNs, but doesn't go into a lot of detail. That's because it focuses on the physical construction of a URI (the general format, how it should be encoded, &c), not the usage.
Edit for the nitpickers: assume that when I say "starts with a scheme", there is the text "(which may be implied by current context)".
RFC 3305 might help:
This document [...] addresses and attempts to clarify issues pertaining to URIs. This document addresses how URI space is partitioned and the relationship between URIs, URLs, and URNs, describes how URI schemes and URN namespaces ids are registered, and presents recommendations for continued work on this subject.
For an overview, the abstract and the introduction of the actual RFC should be sufficient. You can pick specific sections of the RFC out that you want to understand better.
Basically, to understand RFC 2396 better or more thoroughly - which is what you are asking (as well as an overview..), you can't do much better than reading the RFC itself to be honest. Seems logical to me.