Subject: [keyassure] Algorithm Identifier and flags

From: Phillip Hallam-Baker <[email-masked]>
Date: Thu, 23 Sep 2010 10:26:47 -0400

The main remaining point of difference between my draft and Hoffman et. al.
is the way we are handling the certificate data field.

I reuse the algorithmID and Key Tag fields that already exist in the spec.
Hoffman et. al. use sub field encoding.

Flags (e.g. validation)

Is there any reason not to use the Key Tag bits for flag information? I much
prefer to be able to see the semantics of the record from reading the master
file. I do not want to have to decode the BASE64 part to work out the
semantics or to change the semantics.

One important practical issue here is that the BASE64 code will probably be
created by an automatic tool as part of cert generation. If subfield
encoding is used for semantic flags it is going to be necessary to go back
to the tool to make changes to the semantics instead of editing the zone
master file.

Algorithm IDs

Here there is an algorithm ID field in the CERt record, but it specifies the
use of the signer algorithm registry. I see four possible choices

1) Use the algorithm ID field but pull values from the hash id registry.

This is what I currently do. But I agree that this is not ideal since it is
likely to cause unexpected but justifiable behavior when entering RRs into
legacy DNS servers.

2) Use the algorithm ID field but specify a SHA256 identifier in the signer
algorithms registry.

This would work but means that we now have two different numbers for SHA256.

3) Use sub field encoding with a one byte value from the hash id registry

This works, but we already have a precedent in the CERT record for using
ASN.1 OIDs as prefixes in subfield encoding.

4) Use sub field encoding with a one byte length field and an ASN.1
algorithm identifier.

This is the mechanism already specified for the CERT OID data type.

I prefer the ASN.1 approach as there is already precedent. Although it means
a few more bytes, it is no more complex to implement and it has other
significant advantages.

1) The OID values for SHA3 will be defined automatically when the NIST
competition is completed and these can be accepted for use with all IETF
protocols in one go.

I would expect that someone will be submitting an RFC to update RFC4055 and
add the new OIDs to the IANA registry.

2) The BASE64 value can be cut and pasted into other contexts where it is
desirable to insert a base64 of a message digest algorithm and value.

3) Consistency, this mechanism is already defined for CERT values, we should
avoid creating more mechanisms that replicate existing ones.

4) Code support: All crypto libraries can be expected to have mechanisms for
handling OIDs as algorithm identifiers. Registering a new algorithm
implementation with the platform can automatically make it available for use
with Key Assure.

RFC 4055 already defines an OID for SHA256:

      id-sha256  OBJECT IDENTIFIER  ::=  { joint-iso-itu-t(2)
                           country(16) us(840) organization(1) gov(101)
                           csor(3) nistalgorithm(4) hashalgs(2) 1 }

I would not expect people to write code to endcode and decode OIDs. What
most people do is to convert the OID to a byte sequence and use that.

The CERT RFC already has some pre-calculated OIDs. The bytes for SHA256 are:

[06 09 60 86 48 01 65 03 04 02 01]

The IANA registry is:

http://www.iana.org/assignments/hash-function-text-names/hash-function-text-names.xhtml

-- 
Website: http://hallambaker.com/

---

From: Adam Langley <[email-masked]>
Date: Thu, 23 Sep 2010 11:07:59 -0400

> likely to cause unexpected but justifiable behavior when entering RRs into

Just chiming in with a couple of facts:

Existing tools will use a mnemonic for the algorithm id field. For
example, `dig cert dnssec-exp.org` results in the following for me:

dnssec-exp.org.		60	IN	CERT	9 0 RSAMD5 obfn/OYZkIrW36qFJ46KvZ7gLRs=

Note the "RSAMD5". If the algorithm id field were repurposed with
different values then that could be quite a sharp edge. ("I know it
says RSAMD5, but it means SHA256, trust me!")

> 4) Use sub field encoding with a one byte length field and an ASN.1

ASN.1 Object Identifiers are large, but there's a 1-to-1 mapping
between them and byte strings, and they are prefix free. This means
that code can simply use a memcmp (after a length check) to compare
them. Therefore, the typical complexity of ASN.1 doesn't apply here.

AGL

-- 
Adam Langley [email-masked] http://www.imperialviolet.org

---

From: Jakob Schlyter <[email-masked]>
Date: Tue, 28 Sep 2010 08:27:26 +0200

On 23 sep 2010, at 16.26, Phillip Hallam-Baker wrote:

> Flags (e.g. validation)
> 
> Is there any reason not to use the Key Tag bits for flag information? I much prefer to be able to see the semantics of the record from reading the master file. I do not want to have to decode the BASE64 part to work out the semantics or to change the semantics.

According to RFC 4398 (CERT RR) section 2 (last two paragraphs) the algorithm field and the key tag field MUST be set to zero unless the key tag is calculated as it would have as a public key portion of a DNSKEY RR.

If we are going to use the CERT RR, we should realize that everything we need to carry within that will transported as base64 within the "certificate or CRL" field.

	jakob