What are the P1735 Version 1 Recommendations?

These are an important milestone that allow basic interoperability of protected IP across a set of tools. There is a recommended use case, the digital envelope. There are a few required algorithms for the pragmas employed in this use case, and there are a small set of changes and one addition to the existing standard pragmas. The changes address inconsistencies or omissions in the pragma definitions in the 1076 and 1800 standards. The addition is the version pragma itself.

Why is it called Version 1?

A new pragma was introduced to provide versioning for the encryption pragma definitions. It allows the flexibility to make changes and preserve backward compatiblity for IP encrypted with a previous version. The first set of changes provides basic interoperability and the value of the version attribute is defined as 1.You might find the rationale useful.

Why do some say P1735 Version 1 Basic IP Exchange and P1735 Basic Key Exchange?

In our running list of recommendations these are 2 items that are related. The first one is a very terse statement of the small changes needed for interoperability and there is a more readable description later in this FAQ. The second is just a true statement about exchanging out of band key information, that there is no standard format, so you have to explain yourself and hope the recipient can deal with your chosen format. That said, out of band key exchange is not needed, except perhaps for testing. For example, you may wish to provide a dummy public/private key pair or the specific symmetric key internally generated by your tool to support debugging.

Why wasn't this published and distributed?

P1735 is a working group developing a new IEEE standard. Its work is not ready to publish as a draft recommendation yet. This is our agreed to consensus.

Does that mean it might change?

Since we have not yet balloted a draft recommendation, all of our consensus to date is still subject to change. We believe that most of the working group members are not interested in tracking a vascillating specification, and are likely to defend their decisions recorded in the minutes and "Approved Recommendations". Eventually those will become part of a published 1735 recommendation, and ultimately be included in 1800/1076 standards as appropriate. Relying on this agreed consensus is equivalent to implementing to a draft standard. While there is some risk of the final spec invalidating certain implementation decisions, participating working group members will generally be able to manage their risk.

Who has access to these recommendations?

It is only available to P1735 members. We are using Twiki for collaboration, so that is why it is in this form. The IEEE requires that we do this work under an open process and anyone can join P1735 as an entity member. We believe all interested parties have access to these recommendations today.

There is a large set of recommendations on the P1735 Twiki. Which ones are required for Version 1?

We are developing the standard in the usual way by contributing ideas, refining them, and periodically formally approving some aspect. Those aspects are then added to the recommendations. The formal approval is done by voted on motions in committee with the proper quorum. These are recorded in meeting minutes which are published on the Twiki. That said, it can be confusing to answer this question just by looking at the recommendations page. The answer is restated below from the recommendations using the style of a list of requirements.

First, the basic interoperable use case is the digital envelope. That is required. The digital envelope uses both symmetric and asymetric encryption algorithms as well as encoding algorithms. As a consequence, the recommendations on these algorithms is also required. For symmetric encryption, aes128-cbc,aes256-cbc, des-cbc, 3des-cbc are listed as recommendations. As a practical matter, aes128-cbc and aes256-cbc are required. Des is not secure by modern standards but is the only LRM required algorithm and 3des is an improvement, but both are more historical. Neither was used in interoperability testing. For asymmetric encryption, RSA, Diffie-Hellman, and DSA are listed as recommendations. As a practical matter, RSA is required. Diffie-Hellman is valid, but no interoperability testing has been done here and one should expect similar issues as was discovered with RSA. DSA is intended for use in producing digests, not the digital envelope. For encoding, base64 is required.

There is a new pragma, the version pragma, which is required. It must have the value of 1 or greater. The detailed definition is on the recommendations page and it makes no sense to cut/paste it here. There are specific changes to 1076 and/or 1800 standards for basic IP exchange that are required. They are succintly stated in the style of LRM specifications to refer to appropriate formal definitions wherever possible. You might say they are normative but not very informative. It also doesn't make sense to cut/paste it here.

Is the version pragma required on encryption input?

Yes. Like most pragmas though, if it is missing, it may be assumed to have a default value by the encryption tool and the input will be processed accordingly. It is smart to supply it explicitly to insure it is being processed. BTW, it will be echoed in the encryption output, but it is tamper-proof because it is also generated inside the decryption envelope.

Can you explain the specific changes to 1076 and 1800 for basic IP exchange?

I thought you'd never ask. There are 4. The first one clarifies the rsa algorithm conventions. By saying "RSAES-PKCS1-v1_5, see IETF RFC 3447", it is clarifying how the rsa public key is encoded including padding. Just saying the data method is rsa was ambiguous. This essentially specifies the DER encoding/padding is the representation. This needed to be standardized in order for interoperable solutions to be possible.

The second issue was ambiguity in the key_block specification in 1800 which was resolved in the 1076 standard. The requirement is that 1800 spec is replaced with the 1076 specification. It will need to be restated in a consistent way with the style of the 1800 LRM in a future revision. The key_block specification says that the presence of a key_block on encryption input implies the digital envelope and that the session key should be created and encrypted with the associated public key. In decryption input, the key block is immediately followed by that encypted session key. There is nothing else in the key block.

The third issue was an omission of the key_public_key pragma in the 1076 specification. It's purpose was not understood and it was eliminated in the contributed proposal that led to the final 1076 specification. It matters because it is the only portable mechanism to convey a public key to encryption tools. Regardless that P1735 expects to recommend better models for authenticated public key exchange, this is required.

The 4th issue is that 1800 doesn't have a clear description of how to describe the input for a digital envelope in which multiple tools will be allowed to use the protected IP. It is important to know when the values of key_keyowner, key_keyname, key_method are considered to be finalized and used to specify a particular key block. Directive syntax allows one to specify a directive and then respecify it multiple times where it is the last directive's value that matter. Anyway, this was solved in 1076 where the key_block directive indicates that the current values are to be used to specific a key block. Then the user can revise directives for the next tool. P1800 needs to have its semantic rules clarified. In particular, it declares that the key_block directive is illegal on encryption input and not only should it be legal, it is actual vital to the digital envelope model. Use the description in 1076 as the guide until better LRM text for 1800 can be written.

I lied there are more than 4 issues. You really still need to read basic IP exchange to understand the complete story.

What verification was done to validate these recommendations?

There are a number of tool vendors who have implementations of the IEEE standards. Two of them collaborated on development of tests for digital envelope model using their encryption tools to produce output for the other's decryption tools. All the problems with key management and key representation in the pragma's were analyzed. These recommendations were proposed, implemented, and tested. Concurrently, the recommendations were documented and reviewed by all P1735 members. It is unknown if other validation has taken place.

That said, the only algorithms that were validated during this process were rsa, aes128-cbc, aes256-cbc, and base64 encoding.

-- JohnShields - 2010-10-04

Topic revision: r7 - 2010-10-29 - 00:24:46 - JohnShields
 
Copyright © 2008-2024 by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
Ideas, requests, problems regarding TWiki? Send feedback