cose-wg / x509 Goto Github PK

My first though would be that all certs should be DER format. No PEM or BER or such.

The x5u text refers to a "trust relationship" between the signer and the host of the URI. What is that relationship? Since trust relationships are of critical importance in what we're doing here, I would expect it to be spelled out.

It seems like there's two roots of trust involved here. One for the chain that is used to verify the COSE and the other that is used to verify the TLS connection.

I think the following sentence refers to the root of trust for the TLS connection, but can be confused with the root of trust for the COSE chain.

If the retrieved certificate does not
chain to an existing trust anchor, the certificate MUST NOT be
trusted unless the server is configured as trusted to provide new
trust anchors or if an out-of-band confirmation can be received
for trusting the retrieved certificate.

Also, maybe there should be a protected header that names the root of trust for the TLS connection? If there isn't the signer can't quite control the trust relationship as they don't know what roots the receiver has been configured with.

I also think it is important to point out that the certs received this way must still be validated against the root used by the COSE chain. This is not the fetching of already-validate certificates.

JWS seems to have similar issues.

update CDDL ref to RFC8610 :)

Particularly with x5bag, the signature verifier needs to figure out which cert is the leaf to use to verify the COSE signature. CMS and such did with the Subject Key ID and it seems that should be a described option here.

The current COSE X509 spec defines the x5t algorithm identifier as:

corresponding to either the Value (integer) or Name (string) column of the algorithm registered in the "COSE Algorithms" registry

I think that this definition has a misunderstanding of the form of the IANA registry. The registry "Value" column can either be an int or a tstr but none of the current items in the registry happen to have a tstr value. Notice the "Range" table above the item table.

My interpretation agrees with the tooling that I've had some experience with; the "Name" column of the IANA tables is informational only, it may be part of diagnostic display but it is never compared to encoded values.

If this is the case, then the COSE X509 text should read:

corresponding to the Value column (integer or text string) of the algorithm registered in the "COSE Algorithms" registry

There is text warning not to trust self-signed certs in the four different sections. If it is in x5bag and x5chain it should be mentioned in x5t and x5u too, which would put in six different sections.

I think it would be more and efficient to have it just in security considerations, just in one place.

This is just a suggestion for clarity and efficiency, not that any thing is wrong with the current text.

JWS has almost the same header parameters at COSE (x5t, x5chain and x5u, but not x5bag). The semantics of them should be identical, unless there's a really good reason not to be. (EAT using JWT and CWT as semantically equivalent so issues like this pop up)

JWS section 6 has clear text saying when header parameters need to be protected and when they don't. It applies to all the parameters that could be used to identify a certificate including the kid.

All the same attacks and defenses apply for COSE X.509, so COSE X.509 should have a section with text that is almost identical to JWS section 6.

• 1)

<!-- [rfced] Please insert any keywords (beyond those that appear in the title) 
for use on https://www.rfc-editor.org/search. -->

• 2)

<!--[rfced] The cited document doesn't mention indirect signatures.
Please check that this is the correct document to cite.

Original:
Indirect signing of content is a paradigm where the content is not
directly signed, but instead a hash of the content is computed and
that hash value, along with an identifier for the hash algorithm, is
included in the content that will be signed. ... An example of how this is
used can be found in [I-D.ietf-suit-manifest].
-->

• 3)

<!-- [rfced] Tables 1, 2, and 3:  The Capabilities column in the IANA
registry <https://www.iana.org/assignments/cose/> shows [kty] for all
of the entries listed in these tables.  However, the text in this
document says:

The COSE capabilities for this algorithm is an empty array.

Please review and let us know if the document should be updated or if the
IANA registry needs to be updated.

In addition, please let us know if references to RFC-to-be 9053
<draft-ietf-cose-rfc8152bis-algs> should be added to the reference
column (in addition to this document) to match the IANA registry. -->

• 4)

<!--[rfced] The following note appeared in the XML file:

  RFC Editor
      I think that this paragraph can be removed before publishing.

With the text removed, both [I-D.ietf-cose-rfc8152bis-algs] (RFC 9053) and
[I-D.ietf-cose-rfc8152bis-struct] (RFC 9052) are no longer cited.   
Please let us know where they should be cited or if the references should
be removed.
-->

As mentioned in https://mailarchive.ietf.org/arch/msg/cose/pvLdj1lp75I3SiScI4yx_J1ird8/ we register codepoints for NIST algorithms that have a different bit order than implementations have traditionally expected. That thread concerns the issue as it relates to ECDSA, that is defined to act on bit strings rather than byte strings, though most IETF protocols deal only in byte strings (for which there does not seem to be any real controversy). Are there situations where cose hash algorithms need to be treated as bit strings that might merit a disclaimer about SHA-3 needing special handling?

We have registered tags for lots of common data structures. X.509 certs are a common data structure. This RFC would be a convenient place to do it.

It could be polymorphic based on the type of the tag content

• tstr implies PEM encoding
• bstr implies DER encoding
• array means hash of the cert
• URI means reference

This could allow the removal of x5t and x5u entirely. They would just be folded in with x5bag and x5chain. Any individual cert in the bag or the chain could be any of the types.

This is partly in conflict with my issue #22

• bstr / [ 2*certs: bstr ] is referenced
• X.509 header must be placed in the unprotected bucket

x5bag and x5chain can be an array or bstr or just a bstr when a single cert. I would prefer to just allow the array and eliminate bstr-single-cert option.

I did a rough encoding/decoding implementation in C of x5bag and x5chain. With bstr-single-cert object code is 210 + 110 = 320 bytes. Without it, object code is 70+130 = 200. So this adds 50% object code.

The API I picked just returns an array of certs whether there is one or more than one. I don't see any advantage to a special API for a single cert.

As far as I can tell the main advantage of this design is that it saves one byte on the wire when there is a single cert. Is there some other advantage? It doesn't seem worth the complexity to save one byte especially when certs are typically a few hundred bytes.

Since the data is being hashed, it has to be in a canonical form, so it should specify DER encoding.

John:

When we discussed this at the meeting is was agreed to change application/cbor to something more specific. The PR now use "application/cose-x509-chain". And has the text "When the application/cose-x509-chain media type is used, the data is a COSE_X509 structure containing a chain."

I just noticed that an IANA section registering the media type is missing. I will add that to the PR. But before I do that:

• Is application/cose-x509-chain the right thing?
• Or should it be application/cose-x509 allowing for both bag and chain?
• Or should there be two media types application/cose-x509-chain and application/cose-x509-bag?

x5bag and x5chain separates bag and chain, while x5u could be either. Knowing that it is a chain simplifies processing, but removes the option to transfer additional certificates.

The current text states:

  The URI provided MUST provide integrity protection and server
  authentication.  For example, an HTTP or CoAP GET request to
  retrieve a certificate MUST use TLS [RFC8446] or DTLS
  [I-D.ietf-tls-dtls13].

If integrity is really needed here which I don't understand I suggest:

  The URI provided MUST provide integrity protection and server
  authentication.  For example, an HTTP or CoAP GET request to
  retrieve a certificate MAY use TLS [RFC8446], DTLS
  [I-D.ietf-tls-dtls13] or OSCORE [RFC8613].

Aren't x5chain, x5t and such header parameters?

JWS has almost the same header parameters at COSE (x5t, x5chain and x5u, but not x5bag). The semantics of them should be identical, unless there's a really good reason not to be. (EAT using JWT and CWT as semantically equivalent so issues like this pop up)

COSE X.509 is not very clear about determination of the end-entity cert. JWS is clear and explicit:

• x5t always refers to an end-entity
• In x5u the first cert is always the end-entity
• In x5c the first cert is always the end-entity

JWS uses the phrase "The certificate containing the public key corresponding to the key used to digitally sign” rather than "end-entity”. I prefer end-entity, but either is fine.

By contrast, COSE X.509 only explicitly says how the end-entity is determined for an x5chain. Nothing is said for x5t, x5bag or x5u.

Seems to me that COSE X.509 should be made identical to JWS for x5t, x5chain and x5u.

Then COSE has the add-on bonus of x5bag. x5bag never determines the end-entity since it is un ordered. You have to have an x5t, kid or some other means of knowing which in the x5bag is the end-entity. And it is OK that x5bag doesn’t even contain the end-entity.

About x5t:

The first element is an algorithm identifier which is
an integer or a string containing the hash algorithm identifier.

Should this be taken from the COSE Algorithm registry? if not necessarily, what value can it take?

The CDDL states

COSE_X509 = bstr / [ *certs: bstr ]

If I understand draft-ietf-cbor-cddl correctly, '*' means zero or more. Shouldn't it be

COSE_X509 = bstr / [ 2* certs: bstr ]

where 2* means two or more

the following text:

  *  If multiple certificates are conveyed, a CBOR array of bstrs is
     used.  Each certificate being in it's own slot.

about the "its own slot", confuses me. This seems to imply order. (I think this might be a copy-paste error).

Also minor "it's" -> "its" (here and in x5chain description)

It would be good to have a pointer to uri format definition (can be in terminology, but I'd prefer it after table 1 as that is where it appears first).