[rfc-i] draft-iab-rfc-use-of-pdf-01

[tony at att.com (HANSEN, TONY L)]

inline

On 2/24/16, 3:57 PM, "rfc-interest on behalf of Joe Hildebrand (jhildebr)" <rfc-interest-bounces at rfc-editor.org on behalf of jhildebr at cisco.com> wrote:


>Russ, Robert and I just had a quick chat about this.  Note that this is not an IAB opinion, just three individuals.  What we discussed:
>
>1- draft-iab-rfc-use-of-pdf, section 3.3 should remove its recommendation about signing I-Ds.  The use case we're worried about is someone submitting both a .txt and a .pdf containing a signature to the automated tools.  If the tools have to replace the existing author signature with one from the secretariat, the tools are going to be somewhat complex, and the document will change while it is in the repository, which is currently unprecedented.  If we're going to go down that road, we'll need to do some more careful analysis and ensure that the IESG and tools team are onboard.

PDFs do support multiple signatures; this is one of the ways they support workflow.

Excerpted from <https://helpx.adobe.com/acrobat/kb/certificate-signatures.html>:

	Validate documents

	* Validate all signatures, confirming the identity of everyone who signed the document
	* Validate document integrity by tracking all previously signed 
	  versions of a document to verify changes made during the document?s 
	  lifecycle

	Set privileges and permissions for others

	* Certify a document while leaving portions of it available for form filling, signatures, or comments



Note that when signing the PDF file, you can also "certify it" and set restrictions on what can be done to the document afterwards

   *) no changes
   *) add another signature
   *) fill in forms
   *) add markup 

For PDFs generated by the I-D upload tools from xml2rfc, I suggest that it be signed with no restrictions on what can be done to the document afterwards.

For PDFs uploaded by an individual, the signature being added should be set to the same as above. We should reject a PDF that would not allow the IETF Secretariat to resign it in that fashion.

For PDFs generated by the RFC Editor, it should be signed, certified and restrictions placed on it to only allow additional signatures and comments (markup) to be added.


>
>2- because of this, we think that doing an external signature for the I-Ds in the same way that we do them for the other formats (except for whitespace normalization) is still probably a good idea, even if we eventually do internal signatures.  Note: if we do both, the internal signature has to be added before the external signature is performed.
>
>3- For similar reasons, and because we think it might be easier to do algorithm agility with traceability later, we recommend that external signatures also be performed for PDFs of RFCs.  This is of less importance than for I-Ds, because the PDFs will almost always be produced by the RPC.

Given my additional information above, I'm not convinced that #2&3 are necessary.

>
>4- draft-iab-rfc-use-of-pdf, section 3.3, paragraph 1 says "but also to lock down the visual presentation as well".  We're not sure if the current mechanism is going to do exactly that.  Can we either strike this clause or explore it with more text?

Can you be more verbose about what you don't think can be locked down visually? I'd be happy to add an issue on github to this affect in the meantime.

>
>5- Russ currently has an experiment going about how to do command-line signing of PDFs.  We really need the output of that experiment before we as a community lock down the final decisions here.  

I'm sure his experiments will verify what I've said above. If he needs help, please ask. PDF experts are standing by at our toll free number.

	Tony Hansen

>
>On 2/23/16, 12:01 PM, "Joe Hildebrand (jhildebr)" <jhildebr at cisco.com> wrote:
>
>>I think the question is whether they're signed inside the PDF doc, or after the doc is created in an external file like the ASCII files are.
>>
>>If I recall correctly, we either decided we wanted all of the output formats signed the same way, or we decided that the XML was what needed to be signed, since the output formats might get re-rendered one day.
>>
>>On 2/23/16, 11:45 AM, "rfc-interest on behalf of Russ Housley" <rfc-interest-bounces at rfc-editor.org on behalf of housley at vigilsec.com> wrote:
>>
>>>draft-iab-rfc-use-of-pdf-01 says:
>>>
>>>  Recommendation: At this time, the authors see no need for Internet-
>>>  Drafts to be signed with a PDF digital signature.
>>>
>>>The IETF Secretariat currently signs all I-Ds.  See RFC 5485.
>>>
>>>It seems to me that the decision to sign I-Ds should be left to the IESG and IETF Secretariat.  I suggest that this be removed from the document.