CBOR Encoded X.509 Certificates (C509 Certificates)
draft-ietf-cose-cbor-encoded-cert-20

[Ballot comment]
Thank you to Russ Housley for the GENART review.

Thank you for addressing my DISCUSS and COMMENT feedback.

===

** Section 1.  Editorial.

  Implementors can get familiar
  with CBOR by using the CBOR playground [CborMe].

It is not clear what the value of this text for an archival document.

[Ballot discuss]
** Section 8.4
  The
  fields of the registry are Value, Comments, and subjectPrivateKey,
  and Reference, where Value is an integer, and the other columns are
  text strings.

The value of subjectPrivateKey seems to be underspecified.  Yes, it is text string.  However, what are the valid values?  What does this field describe?

** Section 8.6, 8.7
  The fields Name, OID, and DER are mandatory.
…
  If
  OID is present, the OID is given in dotted decimal representation,
  and the DER column contains the hex string of the DER-encoded OID
  [X.690].

-- Per sentence one, the OID field is mandatory.  Per sentence two, there appears to be conditionality to whether the OID might be present.  Which is it?

-- Where are the OID and DER fields defined?

** Section 8.8.  Where are OID, DER, and AttributeValue defined?

** Section 8.9. Where are the OID and DER fields defined?

** Section 8.9, 8.10
  The fields Name,
  OID, and DER are mandatory.

Is it desirable to register a field with no comment (reference)?

** Section 8.11.  8.12. Where are the OID and DER fields defined?  Is it desirable to register a code point with no comment (reference)?

** Section 8.13.  Where are the OID and DER fields defined?  Is it desirable to register a code point with no comment (reference)?

** Section 8.14 and 8.15.  Do not use BCP14 keywords in IANA considerations.  See https://datatracker.ietf.org/doc/statement-iesg-statement-on-clarifying-the-use-of-bcp-14-key-words/. 

** Section 8.14.  What does the comment field text that says “Don’t use” mean.  Where is it explained that the comment field has recommendations on usage?

[Ballot comment]
Thank you to Russ Housley for the GENART review.

** Section 1.  Editorial.

  Implementors can get familiar
  with CBOR by using the CBOR playground [CborMe].

It is not clear what the value of this text for an archival document.

** Section 8.15.1.  What does this section have to do with IANA actions?

[Ballot comment]
# IESG review of draft-ietf-cose-cbor-encoded-cert-18

CC @MikeBishop

## Comments

### IANA

This document seems to have unresolved IANA issues. Have next steps
been determined?

### Section 8.1, paragraph 1
```
    The expert reviewers for the registries defined in this document are
    expected to ensure that the usage solves a valid use case that could
    not be solved better in a different way, that it is not going to
    duplicate an entry that is already registered, and that the
    registered point is likely to be used in deployments.  They are
```
These things are vague enough to give me concern; not quite DISCUSS-level, but I
worry that we're inviting appeals from registrants who disagree with the
reviewer on the "best" preferred solution.

### Section 8.6, paragraph 1

How does "If OID is present" reconcile with "OID [is] mandatory"?

### Section 8.6, paragraph 1

Is the goal that all elements of some existing registry are assigned
mapped values here? If so, synchronization becomes a concern, and adding a
column to that registry might be preferable. If it's independent and just linked
to that other registry by OID, this is probably the best we can do.

### Too many authors

The document has six authors, which exceeds the recommended author limit. Has
the sponsoring AD agreed that this is appropriate?

### Missing references

No reference entries found for these items, which were mentioned in the text:
`[bytes]`.

### DOWNREFs

DOWNREF `[RFC7299]` from this Proposed Standard to Informational `RFC7299`.
(For IESG discussion. It seems this DOWNREF was not mentioned in the Last Call
and also seems to not appear in the DOWNREF registry. Reference only appears to
be for a registry reference.)

### IP addresses

Found IP blocks or addresses not inside RFC5737/RFC3849 example ranges:
`23.106.104.0`, `2.5.29.15`, `2.5.29.37`, `2.5.4.41`, `2.5.4.11`, `2.5.4.8`,
`23.109.0.0/16`, `2001:7f9:ffff:ffff:ffff:ffff:ffff:ffff`, `2.5.4.12`,
`2.5.29.30`, `2.5.4.20`, `23.111.63.255`, `2.5.29.14`, `2.5.4.43`, `2.5.29.32`,
`2.5.4.4`, `2.5.4.6`, `2.5.29.54`, `2.5.29.31`, `23.106.119.255`,
`22.82.0.0/16`, `2.5.4.15`, `2.5.29.35`, `2.5.29.46`, `1.3.101.113`,
`2.5.4.97`, `2002:8:0:ffff:ffff:ffff:ffff:ffff`, `2.5.4.17`,
`2001:bff:ffff:ffff:ffff:ffff:ffff:ffff`, `23.111.16.0`, `2.5.4.42`,
`2.5.4.65`, `1.3.101.111`, `1.3.101.110`, `2.5.29.18`, `2.5.4.3`, `2.5.4.7`,
`2.5.4.44`, `2.5.4.5`, `2.5.29.19`, `2.5.4.46`, `2.5.4.9`, `2.5.29.9`,
`2.5.29.36`, `2.5.4.54`, `23.83.112.0/20`, `1.3.101.112`, `2.5.29.17`,
`2.5.29.33`, and `2.5.4.10`.

## Nits

All comments below are about very minor potential issues that you may choose to
address in some way - or ignore - as you see fit. Some were flagged by
automated tools (via https://github.com/larseggert/ietf-reviewtool), so there
will likely be some false positives. There is no need to let me know what you
did with these suggestions.

### Typos

#### Section 3.3, paragraph 42
```
-      CBOR uint.  With the exception of the first ASId, the ASid is
-                                                              ^
-      encoded as the difference to the previous ASid.
-                                                  ^
+      CBOR uint.  With the exception of the first ASId, the ASId is
+                                                              ^
+      encoded as the difference to the previous ASId.
+                                                  ^
```

#### Section 3.8, paragraph 1
```
-    In TLS and DTLS, the subject of trusted authory may be sent to the
+    In TLS and DTLS, the subject of a trusted authority may be sent to the
+                                    ++              ++
```

#### Section 7, paragraph 5
```
-    handled exactly as how such errors would be handled for the
-                      ----
```

### Section 8.23, paragraph 1
```
  This document registers the following entry in the "SMI Security for
                      ^^
```

### Uncited references

Uncited references: `[RFC2247]`, `[RFC1274]`, `[RFC6960]`, `[X.520]`,
`[RFC6962]`, `[RFC3161]`, and `[GSMA-SGP.22]`.

### Outdated references

Reference `[RFC6962]` to `RFC6962`, which was obsoleted by `RFC9162` (this may
be on purpose).

Reference `[RFC8398]` to `RFC8398`, which was obsoleted by `RFC9598` (this may
be on purpose).

Reference `[RFC5246]` to `RFC5246`, which was obsoleted by `RFC8446` (this may
be on purpose).

Reference `[RFC1274]` to `RFC1274`, which was obsoleted by `RFC4524` (this may
be on purpose).

Document references `draft-ietf-lamps-RFC7030-csrattrs`, but that has been
published as `RFC9908`.

### Grammar/style

#### Section 3.3, paragraph 26
```
      encoded as an int.  The policyQualifierId is encoded as an CBOR
                                                              ^^
```
Use "a" instead of "an" if the following word doesn't start with a vowel sound,
e.g. "a sentence", "a university".

#### Section 3.3, paragraph 38
```
        and for IPv6 addresses, the field MUST contain 17 octets, where
        the last octet indicates the number of bits in the prefix.  As an
```
While it's clear after a moment how to parse, consider ending the sentence after
"17 octets" and starting a new sentence, "In both cases, the last...."

#### Section 3.3, paragraph 55
```
e calculated over ~C509Certificate. Thus C509CertData contains all data neces
                                    ^^^^
```
A comma may be missing after the conjunctive/linking adverb "Thus".

#### Section 3.5, paragraph 5
```
ay be sent to the peer to help it selecting the certificate chain, as in the
                                  ^^^^^^^^^
```
The verb "help" is used with an infinitive.

#### Section 4.4, paragraph 12
```
the remaining text strings are minimal in size. Therefore, the further size r
                              ^^^^^^^^^^^^^^^
```
This wording could be more concise.

#### Section 6.2, paragraph 2
```
t could not be solved better in a different way, that it is not going to dup
                            ^^^^^^^^^^^^^^^^^^
```
Consider replacing this phrase with the adverb "differently" to avoid
wordiness.

#### Section 6.2, paragraph 3
```
eview with Expert Review" are made on a "IETF Review" basis per Section 4.8 o
                                      ^
```
Use "an" instead of "a" if the following word starts with a vowel sound, e.g.
"an article", "an hour".

#### Section 8.20, paragraph 3
```
erences [CAB-Code] CA/Browser Forum, "CA/Browser Forum, "Baseline Requiremen
                                    ^
```
Unpaired symbol: """ seems to be missing.

#### Section 8.20, paragraph 3
```
gning/>. [CAB-TLS] CA/Browser Forum, "CA/Browser Forum, "Baseline Requirement
                                    ^
```
Unpaired symbol: """ seems to be missing.

[Ballot comment]
I'm balloting no obj, but there are substantial comments to address.  I did consider abstaining, see my 'general comment' near the top of my ballot.

Thanks to Corey Bonnell for their secdir reviews.  I agree with many points in their review, and I would like to see their comments addressed.

Thanks to Chris Inacio for deferring this draft for a telechat cycle, it is a complex draft for which I needed the extra time.

General:  While one can claim that CBOR encoded certs eliminate the need for ASN.1 implementation, that only works if the C509 cert can only be CBOR encoded.  As it stands implementations now need both CBOR and ASN.1 depending on what certificates are being used.  Instead of reduced complexity, there is now double the complexity.  In addition, the choices that can be made for various field selections also increase the complexity, which under normal circumstances reduces interoperability.  Sadly there is only one prototype implementation currently.  I'll be curious to see what the uptake is for this idea as it stands.

Section 1, para 5:  This could easily be deleted as it is repetitive with the para above.  If it is left in the specification, please look at the sentence construction (it is indeed only a single sentence) that makes little sense after the 'e.g,' and then 'or' and then 'and'.

Section 1, #1:  Please add a note to say that validating the signature on the certificate first requires that it is reverted back to the original X.509 certificate.

Section 1, second to last para:  I would incorporate this information in #2 above it. (again, a paragraph with a single sentence)

Section 3.1.4, para 2:  Why is the construction of serialNumber in this section vice Section 3.1.2?

Section 3.1.4, para 4:  Is this 'extension' part of the issuer name, or part of what is described in Section 3.1.10?

Section 3.1.5:  Do you need a reference for 'POSIX time'?

Section 3.1.6:  Should 'CBOR simple value' be 'CBOR simple value null'?  (it is phrased that way in Section 3.1.4 and 3.1.5.

Section 3.1.8 & 3.1.9: Where do these fields originate? 

Section 3.3, para 3:  Does this mean that the actual OID is the same regardless of the name?  Or that there are multiple registered OIDs for the same extension?  Please clarify if it is the former.  If it is the latter, then specifying which OID is expected will make implementation less complex.

Section 3.3.1, key usage:  Isn't key usage normally critical?  Wouldn't an example of that be more useful?

Section 8.1, para 1:  I wonder how a DE will determine if a request can be solved in a 'better in a different way'.  'Better' being very subjective.

Section 8.14:  Why are SHA-1 algorithms being registered (even if they are marked as 'deprecated')?

[Ballot comment]
Thanks to the authors and the WG for their work on this document. Please find below some comments and some clarifications sought to help improve the document.

1) In some of the IANA sections, e.g., section 8.6, there is a "Comments" field and those actually reference normative specifications. Not being someone familiar with this area, I am unable to determine if "Comments" mean "Specifications" or something else. In any case, does "comments" seem the right title for the column if it has mainly normative specifications?

2) There is some text under IANA considerations in section 8.15.1 that seem not related to or suitable for that section and instead should be perhaps elsewhere in the document. Please cross-check.

3) Issues with references?
- RFC2247 and GSMA-SGP.22 are listed as informative reference, but are not referenced anywhere.
- RFC6962 and RFC8398 referenced normatively has been obsoleted by RFC9162 and RFC9598 respectively.
- RFC1274 referenced informatively has been obsoleted by RFC4524.
- draft-ietf-lamps-rfc7030-csrattrs has been published as RFC9908; also please cross-check that it is not normative along the lines of RFC7030

I note that the shepherd write-up indicates 5 authors while the document actually has 6. This is just to bring to the attention of the responsible AD as it exceeds the normally expected number.

[Ballot comment]
Hi John, Göran, Shahid, Joel, and Martin,

Many thanks for the well-written document. Excellent work.

Thank you for the discussion and changes made in [1] to address comments in my previous ballot [2].

I appreciate that consistency is followed by the authors vs the resolution to a similar DISCUSS for RFC9668, but some of that text smells like updating the rules in RFC7120.

Cheers,
Med

[1] https://author-tools.ietf.org/iddiff?url1=draft-ietf-cose-cbor-encoded-cert-17&url2=draft-ietf-cose-cbor-encoded-cert-18&difftype=--html

[2] https://mailarchive.ietf.org/arch/msg/cose/m6QDwcY8SkSDtsUuLaJLOA-OfLY/

IANA comments:

1) Question about Section 9.5, value 8 in Figure 10: I'm seeing different entries in the "Identifiers" field depending on document format. In the text file, I'm seeing "organizationName, o"; in the HTML version, the second string (?) is a circle character that I can't copy; and in the XML file, I don't see a character after the comma at all. What should IANA record for this registration in the registry's XML file?

2) Expert review issue: the CoAP Content-Format expert is still requesting that spaces in the Content-Format names in Figure 20 be removed.

3) Note: it doesn't appear that any of these media type templates have been sent to media-types@ietf.org for review. RFC 6838 doesn't require this, but it does recommend it, and the CoAP Content-Formats expert pointed out a possible issue that he thinks should be checked.

4) Note: we have a strong preference for removing "Parameters" from "CBOR Encoded X.509 (C509) Parameters," and unless there's a reason it needs to be retained, we're going to remove the word "Registry" from all the registry names that include it (e.g., "C509 Extensions Registry").

5) Note: in -17, there's a line break between every word in the HTML version of the document (and a text element for every word in the XML file). In order to copy and paste text into XML records for the new registries, we're going to have to use the plain-text version of the draft, so we're liable to miss any special characters. If there are any characters that need to be pulled from another version of the document, please call our attention to them.

[Ballot discuss]

# Éric Vyncke INT AD comments for draft-ietf-cose-cbor-encoded-cert-17
CC @evyncke

Thank you for the work put into this document.

Please find below some blocking DISCUSS points, some non-blocking COMMENT points/nits (replies would be appreciated even if only for my own education).

Special thanks to Ivaylo Petrov for the shepherd's write-up including the WG consensus *BUT* it lacks the justification of the intended status.

Other thanks to Ted Lemon, the DNS directorate reviewer:
https://datatracker.ietf.org/doc/review-ietf-cose-cbor-encoded-cert-17-dnsdir-telechat-lemon-2026-03-30/ (and I have read the previous email threads with the authors)

I hope that this review helps to improve the document,

Regards,

-éric

Note: this ballot comments follow the Markdown syntax of https://github.com/mnot/ietf-comments/tree/main, i.e., they can be processed by a tool to create github issues.

## DISCUSS (blocking)

As noted in https://datatracker.ietf.org/doc/statement-iesg-handling-ballot-positions-20220121/, a DISCUSS ballot is a request to have a discussion on the points below; I really think that the document would be improved with a change here, but can be convinced otherwise.

### Section 3.3

About "IpAddrBlocks", the whole text is a little unclear to me to be honest, so I may have misread the specification BUT the text `It should be noted that using address differences for compactness prevents encoding an address range larger than 2**64 - 1 corresponding to the CBOR integer max value.` seems really a bad choice for IPv6 addresses as the usual prefix size if 64-bit long. I.e., the encoding cannot cope with 2001:db8::/63. There are no examples in the appendix about this encoding, and this does not help the reader.

Also very unclear to me (missing references and how to use): `IPAddressFamily = (AFI: uint, SAFI: uint / null, IPAddressChoice)`

The text `as specified in [I-D.ietf-lamps-macaddress-on]` makes the reference normative.

[Ballot comment]

## COMMENTS (non-blocking)

### Section 1

Please add a reference to `IEEE 802.1AR (DevID)`.

Also add references to `C509 is deployed in, e.g.,...``

### Section 3.1.8 (and others)

What does `Not supported.` mean in this case ? Should the text be explicit and state that if this field exist in the X.509 then no C509 can be generated? (just to be clear)

### Section 3.3

About "Name Constraints" s/where the last octet indicates the number of bits in the *netmask*/where the last octet indicates the number of bits in the *prefix*/

About "IPAddrBlocks", just wondering why not using the 'number of used octets' as it is closer to the usual CIDR/IPv6 prefix notation in `Each AddressPrefix is encoded as a CBOR bytes string (without the unused bits octet) followed by the number of unused bits encoded as a CBOR uint` ?

`KeyIdentifier SHOULD be composed of the leftmost 160-bits of the SHA-256 hash of the CBOR encoded subjectPublicKey. Other methods of generating unique numbers can be used.` why a SHOULD as other methods can be used ? This sentence does not seem to follow https://datatracker.ietf.org/doc/statement-iesg-statement-on-clarifying-the-use-of-bcp-14-key-words/.

### Section 9

Suggest adding informative reference to the newly created IANA registries *AND* updated existing registries.

Somehow like Med Boucadair, I am puzzled by the last paragraph as it is confusing at the best while trying to paraphrase RFC 8126. Let's rather delete it.

### Section A.3.1

Please avoid using real FQDN (e.g., `sni.cloudflaressl.com`) in IETF documents, rather use "example.org"

[Ballot discuss]
Hi John, Göran, Shahid, Joel, and Martin,

Many thanks for the well-written document. Excellent work.

I have two points to check. I flagged some few nits and minor edits that I will send to the authors in a PR.

# IETF Review with Expert Review

CURRENT:
  All assignments according to "IETF Review with Expert Review" are made on a "IETF Review" basis per {{Section 4.8 of RFC8126}} with "Expert Review" additionally required per {{Section 4.5 of RFC8126}}.

and

the registration procedure is "IETF Review with Expert Review".

I remember that Carsten edited draft-bormann-gendispatch-with-expert-review, but do we have a stable reference where such policy is defined?

# The WG may be closed: not sure how this guidance will age

CURRENT:
  In addition, working group chairs are encouraged to consult the expert(s) early during the process outlined in Section 3.1 of {{RFC7120}}.

[Ballot comment]
# Is this already deployed there or these are deployment targets?

CURRENT:
  C509 is deployed in, e.g., in-vehicle and vehicle-to-cloud communication, Uncrewed Aircraft Systems (UAS), and Global Navigation Satellite System (GNSS)

“is deployed” won’t age well in an RFC, btw.

# Please consider adding a reference

CURRENT :

  the CBOR encoding can in many cases reduce the size of  RFC7925 profiled certificates by over 50%.

# Any reason why this is repeated here?

CURRENT:
  The procedure for early IANA allocation of "standards track code points" defined in {{RFC7120}} also applies.

Cheers,
Med

[Ballot comment]
Many thanks for the write-up. Appreciated.

My observation is that while the shepherd writeup claims nothing noteworthy when running idnits, but when i run idnits (https://author-tools.ietf.org/api/idnits?url=https://www.ietf.org/archive/id/draft-ietf-cose-cbor-encoded-cert-17.txt) i end up with a long laundry list of observations. Maybe worthwhile to run through the list and explain why they are deemed not meaningful/relevant and add this context in the write-up?

One of those idnits observations is that there may only be v4 examples and no v6 examples?

G/

The EDHOC Authentication Credential Types, TLSA Selectors, and TLS Certificate Types registrations have been approved. Comments from the CoAP Content-Formats experts: I've reviewed the request. One thing that surprised me was the presence of an optional parameter "usage" without any explanation for some of the media types defined. Is this a copy/paste error maybe? Has there been a media-types review of these already? Note that for all the CoAP Content-Format requests that do include a "usage" parameter, the explanation is present! So this does not hamper the present registration request. If in Figure 20 the spaces in "usage = chain" and "usage = c509" could be removed, per RFC 9876 Section 4.1.4, and the new media types are approved, then this request can be approved.

The TLS Certificate Types registrations have been approved. Comments from the CoAP Content-Formats experts:

I've reviewed the request. One thing that surprised me was the presence
of an optional parameter "usage" without any explanation for some of the
media types defined.
Is this a copy/paste error maybe? Has there been a media-types review of
these already?

Note that for all the CoAP Content-Format requests that do include a
"usage" parameter, the explanation is present! So this does not hamper
the present registration request.

If in Figure 20 the spaces in  "usage = chain" and "usage = c509" could
be removed, per RFC 9876 Section 4.1.4, and the new media types are
approved, then this request can be approved.

There were quite some comments during the IETF LC / Directorate reviews which is good, but does mean we will need another revision before I can bring this to the IESG Telechat.

IESG/Authors/WG Chairs:

IANA has completed its review of draft-ietf-cose-cbor-encoded-cert-16. If any part of this review is inaccurate, please let us know.

IANA has a question about one of the actions requested in the IANA Considerations section of this document.

IANA understands that, upon approval of this document, there are twenty actions which we must complete.

First, a new registry group is to be created on the IANA Matrix located at:

https://www.iana.org/protocols

with the name CBOR Encoded X.509 (C509) Parameters and a reference of [ RFC-to-be ].

Second, a new registry is to be created called the C509 Certificate Types registry. The new registry will be located in the registry group called CBOR Encoded X.509 (C509) Parameters and created in the first IANA action documented above. The registration rules for the new registry are:

-65536 - -25: Expert Review
-24 - 23: IETF Review with Expert Review
24 - 65535: Expert Review

There are initial registrations in the new registry as follows:

Value Description Reference
0 Reserved [ RFC-to-be ]
1 Reserved [ RFC-to-be ]
2 Natively Signed C509 Certificate [ RFC-to-be ]
3 CBOR Re-encoded X.509 v3 Certificate [ RFC-to-be ]

Third, a new registry is to be created called the C509 Certificate Request Types registry. The new registry will also be located in the registry group called CBOR Encoded X.509 (C509) Parameters and created in the first IANA action documented above. The registration rules for the new registry are:

-65536 - -25: Expert Review
-24 - 23: IETF Review with Expert Review
24 - 65535: Expert Review

There are initial registrations in the new registry as follows:

Value Description Reference
0 Requested certificate is C509 Type 2. Natively Signed C509 Certificate Request. [ RFC-to-be ]
1 Requested certificate is C509 Type 2. CBOR re-encoding of RFC 2986 certification request. [ RFC-to-be ]
2 Requested certificate is C509 Type 3. Natively Signed C509 Certificate Request. [ RFC-to-be ]
3 Requested certificate is C509 Type 3. CBOR re-encoding of RFC 2986 certification request. [ RFC-to-be ]

Fourth, a new registry is to be created called the C509 Private Key Types registry. The new registry will also be located in the registry group called CBOR Encoded X.509 (C509) Parameters and created in the first IANA action documented above. The registration rules for the new registry are:

-65536 - -25: Expert Review
-24 - 23: IETF Review with Expert Review
24 - 65535: Expert Review

There are initial registrations in the new registry as follows:

Value Private Key Types Reference
0 Comments: Asymmetric Key Package (RFC 5958) [ RFC-to-be ]
subjectPrivateKey: bytes
1 Comments: COSE Key Object (RFC 9052) [ RFC-to-be ]
subjectPrivateKey: COSE_Key

Fifth, a new registry is to be created called the C509 Certificate Request Templates Types registry. The new registry will also be located in the registry group called CBOR Encoded X.509 (C509) Parameters and created in the first IANA action documented above. The registration rules for the new registry are:

-65536 - -25: Expert Review
-24 - 23: IETF Review with Expert Review
24 - 65535: Expert Review

There is an initial registration in the new registry as follows:

Value Description Reference
0 Simple C509 Certificate Request Template [ RFC-to-be ]

Sixth, a new registry is to be created called the C509 Attributes Types registry. The new registry will also be located in the registry group called CBOR Encoded X.509 (C509) Parameters and created in the first IANA action documented above. The registration rules for the new registry are:

0 - 23: IETF Review with Expert Review
24 - 32767: Expert Review
32768 - 65535: Private Use

There are initial registrations in the new registry as follows:

Value Attribute Reference

0 Name: Email Address [ RFC-to-be ]
Identifiers: emailAddress, e-mailAddress
OID: 1.2.840.113549.1.9.1
DER: 06 09 2A 86 48 86 F7 0D 01 09 01
Comments:

1 Name: Common Name [ RFC-to-be ]
Identifiers: commonName, cn
OID: 2.5.4.3
DER: 06 03 55 04 03
Comments:

2 Name: Surname [ RFC-to-be ]
Identifiers: surname, sn
OID: 2.5.4.4
DER: 06 03 55 04 04
Comments:

3 Name: Serial Number [ RFC-to-be ]
Identifiers: serialNumber
OID: 2.5.4.5
DER: 06 03 55 04 05
Comments:

4 Name: Country [ RFC-to-be ]
Identifiers: countryName, c
OID: 2.5.4.6
DER: 06 03 55 04 06
Comments:

5 Name: Locality [ RFC-to-be ]
Identifiers: localityName, locality, l
OID: 2.5.4.7
DER: 06 03 55 04 07
Comments:

6 Name: State or Province [ RFC-to-be ]
Identifiers: stateOrProvinceName, st
OID: 2.5.4.8
DER: 06 03 55 04 08
Comments:

7 Name: Street Address [ RFC-to-be ]
Identifiers: streetAddress, street
OID: 2.5.4.9
DER: 06 03 55 04 09
Comments:

8 Name: Organization [ RFC-to-be ]
Identifiers: organizationName, o
OID: 2.5.4.10
DER: 06 03 55 04 0A
Comments:

9 Name: Organizational Unit [ RFC-to-be ]
Identifiers: organizationalUnitName, ou
OID: 2.5.4.11
DER: 06 03 55 04 0B
Comments:

10 Name: Title [ RFC-to-be ]
Identifiers: title
OID: 2.5.4.12
DER: 06 03 55 04 0C
Comments:

11 Name: Business Category [ RFC-to-be ]
Identifiers: businessCategory
OID: 2.5.4.15
DER: 06 03 55 04 0F
Comments:

12 Name: Postal Code [ RFC-to-be ]
Identifiers: postalCode
OID: 2.5.4.17
DER: 06 03 55 04 11
Comments:

13 Name: Given Name [ RFC-to-be ]
Identifiers: givenName
OID: 2.5.4.42
DER: 06 03 55 04 2A
Comments:

14 Name: Initials [ RFC-to-be ]
Identifiers: initials
OID: 2.5.4.43
DER: 06 03 55 04 2B
Comments:

15 Name: Generation Qualifier [ RFC-to-be ]
Identifiers: generationQualifier
OID: 2.5.4.44
DER: 06 03 55 04 2C
Comments:

16 Name: DN Qualifier [ RFC-to-be ]
Identifiers: dnQualifier
OID: 2.5.4.46
DER: 06 03 55 04 2E
Comments:

17 Name: Pseudonym [ RFC-to-be ]
Identifiers: pseudonym
OID: 2.5.4.65
DER: 06 03 55 04 41
Comments:

18 Name: Organization Identifier [ RFC-to-be ]
Identifiers: organizationIdentifier
OID: 2.5.4.97
DER: 06 03 55 04 61
Comments:

19 Name: Inc. Locality [ RFC-to-be ]
Identifiers: jurisdictionOfIncorporationLocalityName
OID: 1.3.6.1.4.1.311.60.2.1.1
DER: 06 0B 2B 06 01 04 01 82 37 3C 02 01 01
Comments:

20 Name: Inc. State or Province [ RFC-to-be ]
Identifiers: jurisdictionOfIncorporationStateOrProvinceName
OID: 1.3.6.1.4.1.311.60.2.1.2
DER: 06 0B 2B 06 01 04 01 82 37 3C 02 01 02
Comments:

21 Name: Inc. Country [ RFC-to-be ]
Identifiers: jurisdictionOfIncorporationCountryName
OID: 1.3.6.1.4.1.311.60.2.1.3
DER: 06 0B 2B 06 01 04 01 82 37 3C 02 01 03
Comments:

22 Name: Domain Component [ RFC-to-be ]
Identifiers: domainComponent, dc
OID: 0.9.2342.19200300.100.1.25
DER: 06 0A 09 92 26 89 93 F2 2C 64 01 19
Comments:

25 Name: Name [ RFC-to-be ]
Identifiers: name
OID: 2.5.4.41
DER: 06 03 55 04 29
Comments:

26 Name: Telephone Number [ RFC-to-be ]
Identifiers: telephoneNumber
OID: 2.5.4.20
DER: 06 03 55 04 14
Comments:

27 Name: Directory Management Domain Name [ RFC-to-be ]
Identifiers: dmdName
OID: 2.5.4.54
DER: 06 03 55 04 36
Comments:

28 Name: userid [ RFC-to-be ]
Identifiers: uid
OID: 0.9.2342.19200300.100.1.1
DER: 06 0A 09 92 26 89 93 F2 2C 64 01 01
Comments:

29 Name: Unstructured Name [ RFC-to-be ]
Identifiers: unstructuredName
OID: 1.2.840.113549.1.9.2
DER: 06 09 2A 86 48 86 F7 0D 01 09 02
Comments:

30 Name: Unstructured Address [ RFC-to-be ]
Identifiers: unstructuredAddress
OID: 1.2.840.113549.1.9.8
DER: 06 0A 2A 86 48 86 F7 0D 01 09 08 00

Seventh, a new registry is to be created called the C509 Extensions registry. The new registry will also be located in the registry group called CBOR Encoded X.509 (C509) Parameters and created in the first IANA action documented above. The registration rules for the new registry are:

0 - 23: IETF Review with Expert Review
24 - 32767: Expert Review
32768 - 65535: Private Use

There are initial registrations in the new registry as follows:

Value Extension Reference
1 Name: Subject Key Identifier [ RFC-to-be ]
Identifiers: subjectKeyIdentifier
OID: 2.5.29.14
DER: 06 03 55 1D 0E
Comments:
extensionValue: SubjectKeyIdentifier

2 Name: Key Usage [ RFC-to-be ]
Identifiers: keyUsage
OID: 2.5.29.15
DER: 06 03 55 1D 0F
Comments:
AttributeValue: KeyUsage

3 Name: Subject Alternative Name [ RFC-to-be ]
Identifiers: subjectAltName
OID: 2.5.29.17
DER: 06 03 55 1D 11
Comments:
extensionValue: SubjectAltName

4 Name: Basic Constraints [ RFC-to-be ]
Identifiers: basicConstraints
OID: 2.5.29.19
DER: 06 03 55 1D 13
Comments:
extensionValue: BasicConstraints

5 Name: CRL Distribution Points [ RFC-to-be ]
Identifiers: cRLDistributionPoints
OID: 2.5.29.31
DER: 06 03 55 1D 1F
Comments:
extensionValue: CRLDistributionPoints

6 Name: Certificate Policies [ RFC-to-be ]
Identifiers: certificatePolicies
OID: 2.5.29.32
DER: 06 03 55 1D 20
Comments:
extensionValue: CertificatePolicies

7 Name: Authority Key Identifier [ RFC-to-be ]
Identifiers: authorityKeyIdentifier
OID: 2.5.29.35
DER: 06 03 55 1D 23
Comments:
extensionValue: AuthorityKeyIdentifier

8 Name: Extended Key Usage [ RFC-to-be ]
Identifiers: extKeyUsage
OID: 2.5.29.37
DER: 06 03 55 1D 25
Comments:
extensionValue: ExtKeyUsageSyntax

9 Name: Authority Information Access [ RFC-to-be ]
Identifiers: authorityInfoAccess
OID: 1.3.6.1.5.5.7.1.1
DER: 06 08 2B 06 01 05 05 07 01 01
Comments:
extensionValue: AuthorityInfoAccessSyntax

10 Name: Signed Certificate Timestamp List [ RFC-to-be ]
Identifiers:
OID: 1.3.6.1.4.1.11129.2.4.2
DER: 06 0A 2B 06 01 04 01 D6 79 02 04 02
Comments:
extensionValue: SignedCertificateTimestamps

24 Name: Subject Directory Attributes [ RFC-to-be ]
Identifiers: subjectDirectoryAttributes
OID: 2.5.29.9
DER: 06 03 55 1D 09
Comments:
extensionValue: SubjectDirectoryAttributes

25 Name: Issuer Alternative Name [ RFC-to-be ]
Identifiers: issuerAltName
OID: 2.5.29.18
DER: 06 03 55 1D 12
Comments:
extensionValue: IssuerAltName

26 Name: Name Constraints [ RFC-to-be ]
Identifiers: nameConstraints
OID: 2.5.29.30
DER: 06 03 55 1D 1E
Comments:
extensionValue: NameConstraints

27 Name: Policy Mappings [ RFC-to-be ]
Identifiers: policyMappings
OID: 2.5.29.33
DER: 06 03 55 1D 21
Comments:
extensionValue: PolicyMappings

28 Name: Policy Constraints [ RFC-to-be ]
Identifiers: policyConstraints
OID: 2.5.29.36
DER: 06 03 55 1D 24
Comments:
extensionValue: PolicyConstraints

29 Name: Freshest CRL [ RFC-to-be ]
Identifiers: freshestCRL
OID: 2.5.29.46
DER: 06 03 55 1D 2E
Comments:
extensionValue: FreshestCRL

30 Name: Inhibit anyPolicy [ RFC-to-be ]
Identifiers: inhibitAnyPolicy
OID: 2.5.29.54
DER: 06 03 55 1D 36
Comments:
extensionValue: InhibitAnyPolicy

31 Name: Subject Information Access [ RFC-to-be ]
Identifiers: subjectInfoAccess
OID: 1.3.6.1.5.5.7.1.11
DER: 06 08 2B 06 01 05 05 07 01 0B
Comments:
extensionValue: SubjectInfoAccessSyntax

32 Name: IP Resources [ RFC-to-be ]
Identifiers: id-pe-ipAddrBlocks
OID: 1.3.6.1.5.5.7.1.7
DER: 06 08 2B 06 01 05 05 07 01 07
Comments:
extensionValue: IPAddrBlocks

33 Name: AS Resources [ RFC-to-be ]
Identifiers: id-pe-autonomousSysIds
OID: 1.3.6.1.5.5.7.1.8
DER: 06 08 2B 06 01 05 05 07 01 08
Comments:
extensionValue: ASIdentifiers

34 Name: IP Resources v2 [ RFC-to-be ]
Identifiers: id-pe-ipAddrBlocks-v2
OID: 1.3.6.1.5.5.7.1.28
DER: 06 08 2B 06 01 05 05 07 01 1C
Comments:
extensionValue: IPAddrBlocks

35 Name: AS Resources v2 [ RFC-to-be ]
Identifiers: id-pe-autonomousSysIds-v2
OID: 1.3.6.1.5.5.7.1.29
DER: 06 08 2B 06 01 05 05 07 01 1D
Comments:
extensionValue: ASIdentifiers

36 Name: OCSP No Check [ RFC-to-be ]
Identifiers: id-pkix-ocsp-nocheck
OID: 1.3.6.1.5.5.7.48.1.5
DER: 06 09 2B 06 01 05 05 07 30 01 05
Comments:
extensionValue: null

37 Name: Precertificate Signing Certificate [ RFC-to-be ]
Identifiers:
OID: 1.3.6.1.4.1.11129.2.4.3
DER: 06 0A 2B 06 01 04 01 D6 79 02 04 03
Comments: RFC 6962
extensionValue: null

38 Name: TLS Features [ RFC-to-be ]
Identifiers: id-pe-tlsfeature
OID: 1.3.6.1.5.5.7.1.24
DER: 06 08 2B 06 01 05 05 07 01 18
Comments: RFC 7633
extensionValue: TLSFeatures

255 Name: Challenge Password [ RFC-to-be ]
Identifiers: challengePassword
OID: 1.2.840.113549.1.9.7
DER: 06 09 2A 86 48 86 F7 0D 01 09 07
Comments: Certificate Request Attributes
extensionValue: ChallengePassword

Eighth, a new registry is to be created called the C509 Certificate Policies registry. The new registry will also be located in the registry group called CBOR Encoded X.509 (C509) Parameters and created in the first IANA action documented above. The registration rules for the new registry are:

-65535 - -25: Expert Review
-24 - 23: IETF Review with Expert Review
24 - 32767: Expert Review
32768 - 65535: Private Use

There are initial registrations in the new registry as follows:

Value Certificate Policy Reference
0 Name: Any Policy [ RFC-to-be ]
Identifiers: anyPolicy
OID: 2.5.29.32.0
DER: 06 04 55 1D 20 00
Comments:

1 Name: Domain Validation (DV) [ RFC-to-be ]
Identifiers: domain-validated
OID: 2.23.140.1.2.1
DER: 06 06 67 81 0C 01 02 01
Comments:

2 Name: Organization Validation (OV) [ RFC-to-be ]
Identifiers: organization-validated
OID: 2.23.140.1.2.2
DER: 06 06 67 81 0C 01 02 02
Comments:

3 Name: Individual Validation (IV) [ RFC-to-be ]
Identifiers: individual-validated
OID: 2.23.140.1.2.3
DER: 06 06 67 81 0C 01 02 03
Comments:

4 Name: Extended Validation (EV) [ RFC-to-be ]
Identifiers: ev-guidelines
OID: 2.23.140.1.1
DER: 06 05 67 81 0C 01 01
Comments:

7 Name: Resource PKI (RPKI) [ RFC-to-be ]
Identifiers: id-cp-ipAddr-asNumber
OID: 1.3.6.1.5.5.7.14.2
DER: 06 08 2B 06 01 05 05 07 0E 02
Comments:

8 Name: Resource PKI (RPKI) (Alternative) [ RFC-to-be ]
Identifiers: id-cp-ipAddr-asNumber-v2
OID: 1.3.6.1.5.5.7.14.3
DER: 06 08 2B 06 01 05 05 07 0E 03
Comments:

10 Name: Remote SIM Provisioning Role Certificate Issuer [ RFC-to-be ]
Identifiers: id-rspRole-ci
OID: 2.23.146.1.2.1.0
DER: 06 07 67 81 12 01 02 01 00
Comments:

11 Name: Remote SIM Provisioning Role eUICC [ RFC-to-be ]
Identifiers: id-rspRole-euicc
OID: 2.23.146.1.2.1.1
DER: 06 07 67 81 12 01 02 01 01
Comments:

12 Name: Remote SIM Provisioning Role eUICC Manufacturer [ RFC-to-be ]
Identifiers: id-rspRole-eum
OID: 2.23.146.1.2.1.2
DER: 06 07 67 81 12 01 02 01 02
Comments:

13 Name: Remote SIM Provisioning Role SM-DP+ TLS [ RFC-to-be ]
Identifiers: id-rspRole-dp-tls
OID: 2.23.146.1.2.1.3
DER: 06 07 67 81 12 01 02 01 03
Comments:

14 Name: Remote SIM Provisioning Role SM-DP+ Authentication [ RFC-to-be ]
Identifiers: id-rspRole-dp-auth
OID: 2.23.146.1.2.1.4
DER: 06 07 67 81 12 01 02 01 04
Comments:

15 Name: Remote SIM Provisioning Role SM-DP+ Profile Binding [ RFC-to-be ]
Identifiers: id-rspRole-dp-pb
OID: 2.23.146.1.2.1.5
DER: 06 07 67 81 12 01 02 01 05
Comments:

16 Name: Remote SIM Provisioning Role SM-DS TLS [ RFC-to-be ]
Identifiers: id-rspRole-ds-tls
OID: 2.23.146.1.2.1.6
DER: 06 07 67 81 12 01 02 01 06
Comments:

17 Name: Remote SIM Provisioning Role SM-DS Authentication [ RFC-to-be ]
Identifiers: id-rspRole-ds-auth
OID: 2.23.146.1.2.1.7
DER: 06 07 67 81 12 01 02 01 07
Comments:

Ninth, a new registry is to be created called the C509 Policies Qualifiers registry. The new registry will also be located in the registry group called CBOR Encoded X.509 (C509) Parameters and created in the first IANA action documented above. The registration rules for the new registry are:

-65535 - -25: Expert Review
-24 - 23: IETF Review with Expert Review
24 - 32767: Expert Review
32768 - 65535: Private Use

There are initial registrations in the new registry as follows:

Value Certificate Policy Reference
1 Name: Certification Practice Statement [ RFC-to-be ]
Identifiers: id-qt-cps, cps
OID: 1.3.6.1.5.5.7.2.1
DER: 06 08 2B 06 01 05 05 07 02 01
Comments:

2 Name: User Notice [ RFC-to-be ]
Identifiers: id-qt-unotice, unotice
OID: 1.3.6.1.5.5.7.2.2
DER: 06 08 2B 06 01 05 05 07 02 02

Tenth, a new registry is to be created called the C509 Information Access registry. The new registry will also be located in the registry group called CBOR Encoded X.509 (C509) Parameters and created in the first IANA action documented above. The registration rules for the new registry are:

-65535 - -25: Expert Review
-24 - 23: IETF Review with Expert Review
24 - 65535: Expert Review

There are initial registrations in the new registry as follows:

Value Information Access Reference
1 Name: OCSP [ RFC-to-be ]
Identifiers: id-ad-ocsp, id-pkix-ocsp
OID: 1.3.6.1.5.5.7.48.1
DER: 06 08 2B 06 01 05 05 07 30 01
Comments:

2 Name: CA Issuers [ RFC-to-be ]
Identifiers: id-ad-caIssuers, caIssuers
OID: 1.3.6.1.5.5.7.48.2
DER: 06 08 2B 06 01 05 05 07 30 02
Comments:

3 Name: Time Stamping [ RFC-to-be ]
Identifiers: id-ad-timeStamping, timeStamping
OID: 1.3.6.1.5.5.7.48.3
DER: 06 08 2B 06 01 05 05 07 30 03
Comments:

5 Name: CA Repository [ RFC-to-be ]
Identifiers: id-ad-caRepository
OID: 1.3.6.1.5.5.7.48.5
DER: 06 08 2B 06 01 05 05 07 30 05
Comments:

10 Name: RPKI Manifest [ RFC-to-be ]
Identifiers: id-ad-rpkiManifest
OID: 1.3.6.1.5.5.7.48.10
DER: 06 08 2B 06 01 05 05 07 30 0A
Comments: RFC 6487

11 Name: Signed Object [ RFC-to-be ]
Identifiers: id-ad-signedObject
OID: 1.3.6.1.5.5.7.48.11
DER: 06 08 2B 06 01 05 05 07 30 0B
Comments: RFC 6487

13 Name: RPKI Notify [ RFC-to-be ]
Identifiers: id-ad-rpkiNotify
OID: 1.3.6.1.5.5.7.48.13
DER: 06 08 2B 06 01 05 05 07 30 0D
Comments: RFC 8182

Eleventh, a new registry is to be created called the C509 Extended Key Usages registry. The new registry will also be located in the registry group called CBOR Encoded X.509 (C509) Parameters and created in the first IANA action documented above. The registration rules for the new registry are:

-65535 - -25: Expert Review
-24 - 23: IETF Review with Expert Review
24 - 32767: Expert Review
32768 - 65535: Private Use

There are initial registrations in the new registry as follows:

Value Extended Key Usage Reference
0 Name: Any Extended Key Usage [ RFC-to-be ]
Identifiers: anyExtendedKeyUsage
OID: 2.5.29.37.0
DER: 06 04 55 1D 25 00
Comments: RFC 5280

1 Name: TLS Server authentication [ RFC-to-be ]
Identifiers: id-kp-serverAuth
OID: 1.3.6.1.5.5.7.3.1
DER: 06 08 2B 06 01 05 05 07 03 01
Comments: RFC 5280

2 Name: TLS Client Authentication [ RFC-to-be ]
Identifiers: id-kp-clientAuth
OID: 1.3.6.1.5.5.7.3.2
DER: 06 08 2B 06 01 05 05 07 03 02
Comments: RFC 5280

3 Name: Code Signing [ RFC-to-be ]
Identifiers: id-kp-codeSigning
OID: 1.3.6.1.5.5.7.3.3
DER: 06 08 2B 06 01 05 05 07 03 03
Comments: RFC 5280

4 Name: Email protection (S/MIME) [ RFC-to-be ]
Identifiers: id-kp-emailProtection
OID: 1.3.6.1.5.5.7.3.4
DER: 06 08 2B 06 01 05 05 07 03 04
Comments: RFC 5280

8 Name: Time Stamping
Identifiers: id-kp-timeStamping, timestamping [ RFC-to-be ]
OID: 1.3.6.1.5.5.7.3.8
DER: 06 08 2B 06 01 05 05 07 03 08
Comments:

9 Name: OCSP Signing [ RFC-to-be ]
Identifiers: id-kp-OCSPSigning
OID: 1.3.6.1.5.5.7.3.9
DER: 06 08 2B 06 01 05 05 07 03 09
Comments: RFC 5280

10 Name: Kerberos PKINIT Client Auth [ RFC-to-be ]
Identifiers: id-pkinit-KPClientAuth
OID: 1.3.6.1.5.2.3.4
DER: 06 07 2B 06 01 05 02 03 04
Comments: RFC 4556

11 Name: Kerberos PKINIT KDC [ RFC-to-be ]
Identifiers: id-pkinit-KPKdc
OID: 1.3.6.1.5.2.3.5
DER: 06 07 2B 06 01 05 02 03 05
Comments: RFC 4556

12 Name: SSH Client [ RFC-to-be ]
Identifiers: id-kp-secureShellClient
OID: 1.3.6.1.5.5.7.3.21
DER: 06 08 2B 06 01 05 05 07 03 15
Comments: RFC 6187

13 Name: SSH Server [ RFC-to-be ]
Identifiers: id-kp-secureShellServer
OID: 1.3.6.1.5.5.7.3.22
DER: 06 08 2B 06 01 05 05 07 03 16
Comments: RFC 6187

14 Name: Bundle Security [ RFC-to-be ]
Identifiers: id-kp-bundleSecurity
OID: 1.3.6.1.5.5.7.3.35
DER: 06 08 2B 06 01 05 05 07 03 23
Comments: RFC 9174

15 Name: CMC Certification Authority [ RFC-to-be ]
Identifiers: id-kp-cmcCA
OID: 1.3.6.1.5.5.7.3.27
DER: 06 08 2B 06 01 05 05 07 03 1B
Comments: RFC 6402

16 Name: CMC Registration Authority [ RFC-to-be ]
Identifiers: id-kp-cmcRA
OID: 1.3.6.1.5.5.7.3.28
DER: 06 08 2B 06 01 05 05 07 03 1C
Comments: RFC 6402

17 Name: CMC Archive Server [ RFC-to-be ]
Identifiers: id-kp-cmcArchive
OID: 1.3.6.1.5.5.7.3.29
DER: 06 08 2B 06 01 05 05 07 03 1D
Comments: RFC 6402

18 Name: CMC Key Generation Authority [ RFC-to-be ]
Identifiers: id-kp-cmKGA
OID: 1.3.6.1.5.5.7.3.32
DER: 06 08 2B 06 01 05 05 07 03 20
Comments: RFC 9480

19 Name: Certificate Transparency [ RFC-to-be ]
Identifiers:
OID: 1.3.6.1.4.1.11129.2.4.4
DER: 06 0A 2B 06 01 04 01 D6 79 02 04 04
Comments: RFC 6962

Twelvth, a new registry is to be created called the C509 General Names registry. The new registry will also be located in the registry group called CBOR Encoded X.509 (C509) Parameters and created in the first IANA action documented above. The registration rules for the new registry are:

-65535 - -25: Expert Review
-24 - 23: IETF Review with Expert Review
24 - 65535: Expert Review

There are initial registrations in the new registry as follows:

Value General Names Reference
-2 Name: otherName with SmtpUTF8Mailbox [ RFC-to-be ]
Comments: id-on-SmtpUTF8Mailbox
(1.3.6.1.5.5.7.8.9)
06 08 2B 06 01 05 05 07 08 09
Value: text

-1 Name: otherName with hardwareModuleName [ RFC-to-be ]
Comments: id-on-hardwareModuleName
(1.3.6.1.5.5.7.8.4)
06 08 2B 06 01 05 05 07 08 04
Value: [ ~oid, bytes ]

0 Name: otherName [ RFC-to-be ]
Comments:
Value: [ ~oid, bytes ]

1 Name: rfc822Name [ RFC-to-be ]
Comments:
Value: text

2 Name: dNSName [ RFC-to-be ]
Comments:
Value: text

4 Name: directoryName [ RFC-to-be ]
Comments:
Value: Name

6 Name: uniformResourceIdentifier [ RFC-to-be ]
Comments:
Value: text

7 Name: iPAddress [ RFC-to-be ]
Comments:
Value: bytes

8 Name: registeredID [ RFC-to-be ]
Comments:
Value: ~oid

Thirteenth, a new registry is to be created called the C509 Signature Algorithms registry. The new registry will also be located in the registry group called CBOR Encoded X.509 (C509) Parameters and created in the first IANA action documented above. The registration rules for the new registry are:

-65535 - -25: Expert Review
-24 - 23: IETF Review with Expert Review
24 - 65535: Expert Review

There are initial registrations in the new registry as follows:

Value X.509 Signature Algorithms Reference
-256 Name: RSASSA-PKCS1-v1_5 with SHA-1 [ RFC-to-be ]
Identifiers: sha1-with-rsa-signature, sha1WithRSAEncryption, sha-1WithRSAEncryption
OID: 1.2.840.113549.1.1.5
Parameters: NULL
DER: 30 0D 06 09 2A 86 48 86 F7 0D 01 01 05 05 00
Comments: Don't use

-255 Name: ECDSA with SHA-1 [ RFC-to-be ]
Identifiers: ecdsa-with-SHA1
OID: 1.2.840.10045.4.1
Parameters: Absent
DER: 30 09 06 07 2A 86 48 CE 3D 04 01
Comments: Don't use. Compressed signature value

0 Name: ECDSA with SHA-256 [ RFC-to-be ]
Identifiers: ecdsa-with-SHA256
OID: 1.2.840.10045.4.3.2
Parameters: Absent
DER: 30 0A 06 08 2A 86 48 CE 3D 04 03 02
Comments: Compressed signature value

1 Name: ECDSA with SHA-384 [ RFC-to-be ]
Identifiers: ecdsa-with-SHA384
OID: 1.2.840.10045.4.3.3
Parameters: Absent
DER: 30 0A 06 08 2A 86 48 CE 3D 04 03 03
Comments: Compressed signature value

2 Name: ECDSA with SHA-512 [ RFC-to-be ]
Identifiers: ecdsa-with-SHA512
OID: 1.2.840.10045.4.3.4
Parameters: Absent
DER: 30 0A 06 08 2A 86 48 CE 3D 04 03 04
Comments: Compressed signature value

3 Name: ECDSA with SHAKE128 [ RFC-to-be ]
Identifiers: id-ecdsa-with-shake128
OID: 1.3.6.1.5.5.7.6.32
Parameters: Absent
DER: 30 0A 06 08 2B 06 01 05 05 07 06 20
Comments: Compressed signature value

4 Name: ECDSA with SHAKE256 [ RFC-to-be ]
Identifiers: id-ecdsa-with-shake256
OID: 1.3.6.1.5.5.7.6.33
Parameters: Absent
DER: 30 0A 06 08 2B 06 01 05 05 07 06 21
Comments: Compressed signature value

12 Name: Ed25519 [ RFC-to-be ]
Identifiers: id-Ed25519, id-EdDSA25519
OID: 1.3.101.112
Parameters: Absent
DER: 30 05 06 03 2B 65 70
Comments:

13 Name: Ed448 [ RFC-to-be ]
Identifiers: id-Ed448, id-EdDSA448
OID: 1.3.101.113
Parameters: Absent
DER: 30 05 06 03 2B 65 71
Comments:

14 Name: PoP with SHA-256 and HMAC-SHA256 [ RFC-to-be ]
Identifiers: sa-ecdhPop-sha256-hmac-sha256
OID: 1.3.6.1.5.5.7.6.26
Parameters: Absent
DER: 30 0A 06 08 2B 06 01 05 05 07 06 1A
Comments: Proof-of-possession algorithm, indexed with KDF and MAC, see RFC 6955. Requires recipient's public static Diffie-Hellman key

15 Name: PoP with SHA-384 and HMAC-SHA384 [ RFC-to-be ]
Identifiers: sa-ecdhPop-sha384-hmac-sha384
OID: 1.3.6.1.5.5.7.6.27
Parameters: Absent
DER: 30 0A 06 08 2B 06 01 05 05 07 06 1B
Comments: Proof-of-possession algorithm, indexed with KDF and MAC, see RFC 6955. Requires recipient's public static Diffie-Hellman key

16 Name: PoP with SHA-512 and HMAC-SHA512 [ RFC-to-be ]
Identifiers: sa-ecdhPop-sha512-hmac-sha512
OID: 1.3.6.1.5.5.7.6.28
Parameters: Absent
DER: 30 0A 06 08 2B 06 01 05 05 07 06 1C
Comments: Proof-of-possession algorithm, indexed with KDF and MAC, see RFC 6955. Requires recipient's public static Diffie-Hellman key

23 Name: RSASSA-PKCS1-v1_5 with SHA-256 [ RFC-to-be ]
Identifiers: sha256WithRSAEncryption
OID: 1.2.840.113549.1.1.11
Parameters: NULL
DER: 30 0B 06 09 2A 86 48 86 F7 0D 01 01 0B 05 00
Comments:

24 Name: RSASSA-PKCS1-v1_5 with SHA-384 [ RFC-to-be ]
Identifiers: sha384WithRSAEncryption
OID: 1.2.840.113549.1.1.12
Parameters: NULL
DER: 30 0B 06 09 2A 86 48 86 F7 0D 01 01 0C 05 00
Comments:

25 Name: RSASSA-PKCS1-v1_5 with SHA-512 [ RFC-to-be ]
Identifiers: sha512WithRSAEncryption
OID: 1.2.840.113549.1.1.13
Parameters: NULL
DER: 30 0B 06 09 2A 86 48 86 F7 0D 01 01 0D 05 00
Comments:

26 Name: RSASSA-PSS with SHA-256 [ RFC-to-be ]
Identifiers: rsassa-pss, id-RSASSA-PSS
OID: 1.2.840.113549.1.1.10
Parameters: SHA-256, MGF-1 with SHA-256, saltLength = 32
DER: 30 41 06 09 2A 86 48 86 F7 0D 01 01 0A 30 34 A0 0F 30 0D 06 09 60 86 48 01 65 03 04 02 01 05 00 A1 1C 30 1A 06 09 2A 86 48 86 F7 0D 01 01 08 30 0D 06 09 60 86 48 01 65 03 04 02 01 05 00 a2 03 02 01 20
Comments:

27 Name: RSASSA-PSS with SHA-384 [ RFC-to-be ]
Identifiers: rsassa-pss, id-RSASSA-PSS
OID: 1.2.840.113549.1.1.10
Parameters: SHA-384, MGF-1 with SHA-384, saltLength = 48
DER: 30 41 06 09 2A 86 48 86 F7 0D 01 01 0A 30 34 A0 0F 30 0D 06 09 60 86 48 01 65 03 04 02 02 05 00 A1 1C 30 1A 06 09 2A 86 48 86 F7 0D 01 01 08 30 0D 06 09 60 86 48 01 65 03 04 02 02 05 00 A2 03 02 01 30
Comments:

28 Name: RSASSA-PSS with SHA-512 [ RFC-to-be ]
Identifiers: rsassa-pss, id-RSASSA-PSS
OID: 1.2.840.113549.1.1.10
Parameters: SHA-512, MGF-1 with SHA-512, saltLength = 64
DER: 30 41 06 09 2A 86 48 86 F7 0D 01 01 0A 30 34 A0 0F 30 0D 06 09 60 86 48 01 65 03 04 02 03 05 00 A1 1C 30 1A 06 09 2A 86 48 86 F7 0D 01 01 08 30 0D 06 09 60 86 48 01 65 03 04 02 03 05 00 A2 03 02 01 40
Comments:

29 Name: RSASSA-PSS with SHAKE128 [ RFC-to-be ]
Identifiers: id-RSASSA-PSS-SHAKE128
OID: 1.3.6.1.5.5.7.6.30
Parameters: Absent
DER: 30 0A 06 08 2B 06 01 05 05 07 06 1E
Comments:

30 Name: RSASSA-PSS with SHAKE256 [ RFC-to-be ]
Identifiers: id-RSASSA-PSS-SHAKE256
OID: 1.3.6.1.5.5.7.6.31
Parameters: Absent
DER: 30 0A 06 08 2B 06 01 05 05 07 06 1F
Comments:

45 Name: SM2 with SM3 [ RFC-to-be ]
Identifiers: sm2-with-sm3
OID: 1.2.156.10197.1.501
Parameters: Absent
DER: 30 0A 06 08 2A 81 1C CF 55 01 83 75
Comments: Compressed signature value

Fourteenth, a new registry is to be created called the C509 Public Key Algorithms registry. The new registry will also be located in the registry group called CBOR Encoded X.509 (C509) Parameters and created in the first IANA action documented above. The registration rules for the new registry are:

-65535 - -25: Expert Review
-24 - 23: IETF Review with Expert Review
24 - 65535: Expert Review

IANA Question --> Is the note in section 9.13.1 intended to be a note in the registry, or is it sufficient to have this text available to the reader of the published RFC?

There are initial registrations in the new registry as follows:

Value X.509 Public Key Algorithms Reference
0 Name: RSA [ RFC-to-be ]
Identifiers: rsaEncryption
OID: 1.2.840.113549.1.1.1
Parameters: NULL
DER: 30 0d 06 09 2a 86 48 86 f7 0d 01 01 01 05 00
Comments: Compressed subjectPublicKey

1 Name: EC Public Key (Weierstrafl) with secp256r1 [ RFC-to-be ]
Identifiers: ecPublicKey, id-ecPublicKey
OID: 1.2.840.10045.2.1
Parameters: namedCurve = secp256r1 (1.2.840.10045.3.1.7)
DER: 30 13 06 07 2A 86 48 CE 3D 02 01 06 08 2A 86 48 CE 3D 03 01 07
Comments: Compressed subjectPublicKey Also known as P-256, ansip256r1, prime256v1

2 Name: EC Public Key (Weierstrafl) with secp384r1 [ RFC-to-be ]
Identifiers: ecPublicKey, id-ecPublicKey
OID: 1.2.840.10045.2.1
Parameters: namedCurve = secp384r1 (1.3.132.0.34)
DER: 30 10 06 07 2A 86 48 CE 3D 02 01 06 05 2B 81 04 00 22
Comments: Compressed subjectPublicKey Also known as P-384, ansip384r1

3 Name: EC Public Key (Weierstrafl) with secp521r1 [ RFC-to-be ]
Identifiers: ecPublicKey, id-ecPublicKey
OID: 1.2.840.10045.2.1
Parameters: namedCurve = secp521r1 (1.3.132.0.35)
DER: 30 10 06 07 2A 86 48 CE 3D 02 01 06 05 2B 81 04 00 23
Comments: Compressed subjectPublicKey Also known as P-521, ansip521r1

8 Name: X25519 (Montgomery) [ RFC-to-be ]
Identifiers: id-X25519
OID: 1.3.101.110
Parameters: Absent
DER: 30 05 06 03 2B 65 6E
Comments:

9 Name: X448 (Montgomery) [ RFC-to-be ]
Identifiers: id-X448
OID: 1.3.101.111
Parameters: Absent
DER: 30 05 06 03 2B 65 6F
Comments:

10 Name: Ed25519 (Twisted Edwards) [ RFC-to-be ]
Identifiers: id-Ed25519, id-EdDSA25519
OID: 1.3.101.112
Parameters: Absent
DER: 30 05 06 03 2B 65 70
Comments:

11 Name: Ed448 (Edwards) [ RFC-to-be ]
Identifiers: id-Ed448, id-EdDSA448
OID: 1.3.101.113
Parameters: Absent
DER: 30 05 06 03 2B 65 71
Comments:

24 Name: EC Public Key (Weierstrafl) with brainpoolP256r1 [ RFC-to-be ]
Identifiers: ecPublicKey, id-ecPublicKey
OID: 1.2.840.10045.2.1
Parameters: namedCurve = brainpoolP256r1 (1.3.36.3.3.2.8.1.1.7)
DER: 30 14 06 07 2A 86 48 CE 3D 02 01 06 09 2B 24 03 03 02 08 01 01 07
Comments: Compressed subjectPublicKey

25 Name: EC Public Key (Weierstrafl) with brainpoolP384r1 [ RFC-to-be ]
Identifiers: ecPublicKey, id-ecPublicKey
OID: 1.2.840.10045.2.1
Parameters: namedCurve = brainpoolP384r1 (1.3.36.3.3.2.8.1.1.11)
DER: 30 14 06 07 2A 86 48 CE 3D 02 01 06 09 2B 24 03 03 02 08 01 01 0B
Comments: Compressed subjectPublicKey

26 Name: EC Public Key (Weierstrafl) with brainpoolP512r1 [ RFC-to-be ]
Identifiers: ecPublicKey, id-ecPublicKey
OID: 1.2.840.10045.2.1
Parameters: namedCurve = brainpoolP512r1 (1.3.36.3.3.2.8.1.1.13)
DER: 30 14 06 07 2A 86 48 CE 3D 02 01 06 09 2B 24 03 03 02 08 01 01 0D
Comments: Compressed subjectPublicKey

27 Name: EC Public Key (Weierstrafl) with FRP256v1 [ RFC-to-be ]
Identifiers: ecPublicKey, id-ecPublicKey
OID: 1.2.840.10045.2.1
Parameters: namedCurve = FRP256v1 (1.2.250.1.223.101.256.1)
DER: 30 15 06 07 2A 86 48 CE 3D 02 01 06 0A 2A 81 7A 01 81 5F 65 82 00 01
Comments: Compressed subjectPublicKey

28 Name: EC Public Key (Weierstrafl) with sm2p256v1 [ RFC-to-be ]
Identifiers: ecPublicKey, id-ecPublicKey
OID: 1.2.840.10045.2.1
Parameters: namedCurve = sm2p256v1 (1.2.156.10197.1.301)
DER: 30 13 06 07 2A 86 48 CE 3D 02 01 06 08 2A 81 1C CF 55 01 82 2D
Comments: Compressed subjectPublicKey

Fifteenth, in the COSE Header Parameters registry in the CBOR Object Signing and Encryption (COSE) registry group located at:

https://www.iana.org/assignments/cose/

four early allocations will be made permanent and their references changed to [ RFC-to-be ] as follows:

Name: c5b
Label: 24
Value Type: COSE_C509
Value Registry:
Description: An unordered bag of C509 certificates
Reference: [ RFC-to-be ]

Name: c5c
Label: 25
Value Type: COSE_C509
Value Registry:
Description: An ordered chain of C509 certificates
Reference: [ RFC-to-be ]

Name: c5t
Label: 22
Value Type: COSE_CertHash
Value Registry:
Description: Hash of a ~C509Certificate
Reference: [ RFC-to-be ]

Name: c5u
Label: 23
Value Type: url
Value Registry:
Description: URI pointing to a COSE_C509 containing an ordered chain of certificates
Reference: [ RFC-to-be ]

Sixteenth, in the application namespace of the Media Type registry located at:

https://www.iana.org/assignments/media-types/

six new media types are to be registered as follows:

Name: cose-c509-cert
Template: [ TBD-at-Registration ]
Reference: [ RFC-to-be ]

Name: cose-c509-pkcs10
Template: [ TBD-at-Registration ]
Reference: [ RFC-to-be ]

Name: cose-c509-crtemplate
Template: [ TBD-at-Registration ]
Reference: [ RFC-to-be ]

Name: cose-c509-privkey
Template: [ TBD-at-Registration ]
Reference: [ RFC-to-be ]

Name: cose-c509-pem
Template: [ TBD-at-Registration ]
Reference: [ RFC-to-be ]

Name: cose-certhash
Template: [ TBD-at-Registration ]
Reference: [ RFC-to-be ]

Seventeenth, in the CoAP Content-Formats registry in the Constrained RESTful Environments (CoRE) Parameters registry group located at:

https://www.iana.org/assignments/core-parameters/

eight new Content-Formats will be added to the registry as follows:

Content-Format: application/cose-c509-cert
Content Coding:
Media Type: [[ link-to-media-type-registration for application/cose-c509-cert ]]
ID: [ TBD-at-Registration ]
Reference: [ RFC-to-be ]

Content-Format: application/cose-c509-cert usage = chain
Content Coding:
Media Type: [[ link-to-media-type-registration for application/cose-c509-cert ]]
ID: [ TBD-at-Registration ]
Reference: [ RFC-to-be ]

Content-Format: application/cose-c509-pkcs10
Content Coding:
Media Type: [[ link-to-media-type-registration for application/cose-c509-pkcs10 ]]
ID: [ TBD-at-Registration ]
Reference: [ RFC-to-be ]

Content-Format: application/cose-c509-crtemplate
Content Coding:
Media Type: [[ link-to-media-type-registration for application/cose-c509-crtemplate ]]
ID: [ TBD-at-Registration ]
Reference: [ RFC-to-be ]

Content-Format: application/cose-c509-privkey
Content Coding:
Media Type:
ID: [ TBD-at-Registration ]
Reference: [ RFC-to-be ]

Content-Format: application/cose-c509-pem
Content Coding:
Media Type: [[ link-to-media-type-registration for application/cose-c509-pem ]]
ID: [ TBD-at-Registration ]
Reference: [ RFC-to-be ]

Content-Format: application/cose-certhash
Content Coding:
Media Type: [[ link-to-media-type-registration for application/cose-certhash ]]
ID: [ TBD-at-Registration ]
Reference: [ RFC-to-be ]

Content-Format: application/cose-certhash usage = C509
Content Coding:
Media Type: [[ link-to-media-type-registration for application/cose-certhash ]]
ID: [ TBD-at-Registration ]
Reference: [ RFC-to-be ]

As this document requests registrations in an Expert Review or Specification Required (see RFC 8126) registry, we will initiate the required Expert Review via a separate request. This review must be completed before the document's IANA state can be changed to "IANA OK."

Eighteenth, in the TLS Certificate Types registry in the Transport Layer Security (TLS) Extensions registry group located at:

https://www.iana.org/assignments/tls-extensiontype-values/

a single new certificate type is to be registered as follows:

Value: [ TBD-at-Registration ]
Name: C509 Certificate
Recommended: N
Reference: [ RFC-to-be ]
Comment:

As this also requests registrations in an Expert Review or Specification Required (see RFC 8126) registry, we will initiate the required Expert Review via a separate request. This review must be completed before the document's IANA state can be changed to "IANA OK."

Nineteenth, in the TLSA Selectors registry in the DNS-Based Authentication of Named Entities (DANE) Parameters registry group located at:

https://www.iana.org/assignments/dane-parameters/

a single, new registration will be made as follows:

Value: [ TBD-at-Registration ]
Acronym: C509
Short Description: CBOR encoded PKIX certificates
Reference: [ RFC-to-be ]

As this document requests registrations in an Expert Review or Specification Required (see RFC 8126) registry, we will initiate the required Expert Review via a separate request. This review must be completed before the document's IANA state can be changed to "IANA OK."

Twentieth, in the EDHOC Authentication Credential Types registry in the Ephemeral Diffie-Hellman Over COSE (EDHOC) registry group located at:

https://www.iana.org/assignments/edhoc/

a single, new registration will be made as follows:

Value: [ TBD-at-Registration ]
Description: C509 certificate
Reference: [ RFC-to-be ]

As this also requests registrations in an Expert Review or Specification Required (see RFC 8126) registry, we will initiate the required Expert Review via a separate request. This review must be completed before the document's IANA state can be changed to "IANA OK."

We understand that these are the only actions required to be completed upon approval of this document.

NOTE: The actions requested in this document will not be completed until the document has been approved for publication as an RFC. This message is meant only to confirm the list of actions that will be performed.

For definitions of IANA review states, please see:

https://datatracker.ietf.org/help/state/draft/iana-review

Thank you,

David Dong
IANA Services Sr. Specialist

The following Last Call announcement was sent out (ends 2026-02-10):

From: The IESG
To: IETF-Announce
CC: cose-chairs@ietf.org, cose@ietf.org, draft-ietf-cose-cbor-encoded-cert@ietf.org, ivaylopetrov@google.com, paul.wouters@aiven.io
Reply-To: last-call@ietf.org
Sender:
Subject: Last Call:  (CBOR Encoded X.509 Certificates (C509 Certificates)) to Proposed Standard


The IESG has received a request from the CBOR Object Signing and Encryption
WG (cose) to consider the following document: - 'CBOR Encoded X.509
Certificates (C509 Certificates)'
  as Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits final
comments on this action. Please send substantive comments to the
last-call@ietf.org mailing lists by 2026-02-10. Exceptionally, comments may
be sent to iesg@ietf.org instead. In either case, please retain the beginning
of the Subject line to allow automated sorting.

Abstract


  This document specifies a CBOR encoding of X.509 certificates.  The
  resulting certificates are called C509 certificates.  The CBOR
  encoding supports a large subset of RFC 5280, common certificate
  profiles and is extensible.

  Two types of C509 certificates are defined.  One type is an
  invertible CBOR re-encoding of DER encoded X.509 certificates with
  the signature field copied from the DER encoding.  The other type is
  identical except that the signature is over the CBOR encoding instead
  of the DER encoding, avoiding the use of ASN.1.  Both types of
  certificates have the same semantics as X.509 and the same reduced
  size compared to X.509.

  The document also specifies CBOR encoded data structures for
  certificate (signing) requests and certificate request templates, new
  COSE headers, as well as a TLS certificate type and a file format for
  C509.  This document updates RFC 6698; the TLSA selectors registry is
  extended to include C509 certificates.




The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-cose-cbor-encoded-cert/



No IPR declarations have been submitted directly on this I-D.

# Document Shepherd Write-Up for Group Documents

*This version is dated 4 July 2022.*

Thank you for your service as a document shepherd. Among the responsibilities is
answering the questions in this write-up to give helpful context to Last Call
and Internet Engineering Steering Group ([IESG][1]) reviewers, and your
diligence in completing it is appreciated. The full role of the shepherd is
further described in [RFC 4858][2]. You will need the cooperation of the authors
and editors to complete these checks.

Note that some numbered items contain multiple related questions; please be sure
to answer all of them.

## Document History

1. Does the working group (WG) consensus represent the strong concurrence of a
  few individuals, with others being silent, or did it reach broad agreement?

The document reached a broad consensus, comparable to that of many other documents in the COSE WG.

2. Was there controversy about particular points, or were there decisions where
  the consensus was particularly rough?

A controversy arose during IETF 122 regarding "natively signed" certificates and their evolution. However, the issue appears to have been resolved through discussion on the mailing list, as there was no further follow-up by the end of the WGLC.

3. Has anyone threatened an appeal or otherwise indicated extreme discontent? If
  so, please summarize the areas of conflict in separate email messages to the
  responsible Area Director. (It should be in a separate email because this
  questionnaire is publicly available.)

No.

4. For protocol documents, are there existing implementations of the contents of
  the document? Have a significant number of potential implementers indicated
  plans to implement? Are any existing implementations reported somewhere,
  either in the document itself (as [RFC 7942][3] recommends) or elsewhere
  (where)?

A demonstration implementation is available at https://github.com/cose-wg/CBOR-certificates/tree/master/c509_demo_impl, and a link to this repository is included in the document. However, the document does not explicitly mention this implementation.
The authors have suggested that there are also implementations by Lijun Liao  and Brian Sipos.
Derek Atkins derek@ihtfp.com also seems to indicate that they have an implementation in https://mailarchive.ietf.org/arch/msg/cose/dF30vuqIcKFJw2HIT6Q7T7aj_sI/.

## Additional Reviews

5. Do the contents of this document closely interact with technologies in other
  IETF working groups or external organizations, and would it therefore benefit
  from their review? Have those reviews occurred? If yes, describe which
  reviews took place.

I am not aware of any.

6. Describe how the document meets any required formal expert review criteria,
  such as the MIB Doctor, YANG Doctor, media type, and URI type reviews.

The media type has not undergone a special review, as the registrations are straightforward and the working group possesses expertise in this area.

All other types of reviews seem irrelevant for this document.

7. If the document contains a YANG module, has the final version of the module
  been checked with any of the [recommended validation tools][4] for syntax and
  formatting validation? If there are any resulting errors or warnings, what is
  the justification for not fixing them at this time? Does the YANG module
  comply with the Network Management Datastore Architecture (NMDA) as specified
  in [RFC 8342][5]?

There is no YANG module.

8. Describe reviews and automated checks performed to validate sections of the
  final version of the document written in a formal language, such as XML code,
  BNF rules, MIB definitions, CBOR's CDDL, etc.

The CDDL in Figure 2 was successfully verified using the tool at https://christian-bromann.github.io/cddl/. However, the CDDL in Figures 1 and 4 produced errors that appear to be tool-related.

## Document Shepherd Checks

9. Based on the shepherd's review of the document, is it their opinion that this
  document is needed, clearly written, complete, correctly designed, and ready
  to be handed off to the responsible Area Director?

Yes, the document is needed, clearly written, complete, correctly designed, and ready to be handed off to the responsible Area Director.

10. Several IETF Areas have assembled [lists of common issues that their
    reviewers encounter][6]. For which areas have such issues been identified
    and addressed? For which does this still need to happen in subsequent
    reviews?

In my opinion the draft does not have any of the listed SEC issues. Many of them are not relevant for this draft or are addressed by documents on x.509, which the draft builds on.

11. What type of RFC publication is being requested on the IETF stream ([Best
    Current Practice][12], [Proposed Standard, Internet Standard][13],
    [Informational, Experimental or Historic][14])? Why is this the proper type
    of RFC? Do all Datatracker state attributes correctly reflect this intent?

Proposed Standard

12. Have reasonable efforts been made to remind all authors of the intellectual
    property rights (IPR) disclosure obligations described in [BCP 79][7]? To
    the best of your knowledge, have all required disclosures been filed? If
    not, explain why. If yes, summarize any relevant discussion, including links
    to publicly-available messages when applicable.

Yes.

13. Has each author, editor, and contributor shown their willingness to be
    listed as such? If the total number of authors and editors on the front page
    is greater than five, please provide a justification.

Each author has shown willingness to be listed as such and the list is of exactly 5 people.

14. Document any remaining I-D nits in this document. Simply running the [idnits
    tool][8] is not enough; please review the ["Content Guidelines" on
    authors.ietf.org][15]. (Also note that the current idnits tool generates
    some incorrect warnings; a rewrite is underway.)

Idnits did not discover anything noteworthy about the document.

From a content guidelines perspective, the document is largely compliant; it is correctly named, structured, and contains the required content. One deviation from the Content Guidelines is the use of work emails for author contact, which may not be stable over time.

15. Should any informative references be normative or vice-versa? See the [IESG
    Statement on Normative and Informative References][16].

No.

16. List any normative references that are not freely available to anyone. Did
    the community have sufficient access to review any such normative
    references?

There are no such references.

17. Are there any normative downward references (see [RFC 3967][9] and [BCP
    97][10]) that are not already listed in the [DOWNREF registry][17]? If so,
    list them.

RFC 2985 and RFC 2986 are informational and therefore downward references.

18. Are there normative references to documents that are not ready to be
    submitted to the IESG for publication or are otherwise in an unclear state?
    If so, what is the plan for their completion?

No.

19. Will publication of this document change the status of any existing RFCs? If
    so, does the Datatracker metadata correctly reflect this and are those RFCs
    listed on the title page, in the abstract, and discussed in the
    introduction? If not, explain why and point to the part of the document
    where the relationship of this document to these other RFCs is discussed.

This document updates RFC 6698. This is clearly stated on the title page, in the abstract, and in the introduction.


20. Describe the document shepherd's review of the IANA considerations section,
    especially with regard to its consistency with the body of the document.
    Confirm that all aspects of the document requiring IANA assignments are
    associated with the appropriate reservations in IANA registries. Confirm
    that any referenced IANA registries have been clearly identified. Confirm
    that each newly created IANA registry specifies its initial contents,
    allocations procedures, and a reasonable name (see [RFC 8126][11]).

The document clearly identifies its requests to IANA for new COSE Header Parameter and Media Type Application registrations. These requests are necessary and minimal. The document also establishes several new registries with clear instructions and initial content.

21. List any new IANA registries that require Designated Expert Review for
    future allocations. Are the instructions to the Designated Expert clear?
    Please include suggestions of designated experts, if appropriate.

Here is the list:
- C509 Certificate Types Registry
- C509 Certificate Request Types Registry
- C509 Private Key Types Registry
- C509 Certificate Request Templates Types Registry
- C509 Attributes Registry
- C509 Extensions Registry
- C509 Certificate Policies Registry
- C509 Policies Qualifiers Registry
- C509 Information Access Registry
- C509 Extended Key Usages Registry
- C509 General Names Registry
- C509 Signature Algorithms Registry
- C509 Public Key Algorithms Registry

I believe that the instructions are clear.

[1]: https://www.ietf.org/about/groups/iesg/
[2]: https://www.rfc-editor.org/rfc/rfc4858.html
[3]: https://www.rfc-editor.org/rfc/rfc7942.html
[4]: https://wiki.ietf.org/group/ops/yang-review-tools
[5]: https://www.rfc-editor.org/rfc/rfc8342.html
[6]: https://wiki.ietf.org/group/iesg/ExpertTopics
[7]: https://www.rfc-editor.org/info/bcp79
[8]: https://www.ietf.org/tools/idnits/
[9]: https://www.rfc-editor.org/rfc/rfc3967.html
[10]: https://www.rfc-editor.org/info/bcp97
[11]: https://www.rfc-editor.org/rfc/rfc8126.html
[12]: https://www.rfc-editor.org/rfc/rfc2026.html#section-5
[13]: https://www.rfc-editor.org/rfc/rfc2026.html#section-4.1
[14]: https://www.rfc-editor.org/rfc/rfc2026.html#section-4.2
[15]: https://authors.ietf.org/en/content-guidelines-overview
[16]: https://www.ietf.org/about/groups/iesg/statements/normative-informative-references/
[17]: https://datatracker.ietf.org/doc/downref/

# Document Shepherd Write-Up for Group Documents

*This version is dated 4 July 2022.*

Thank you for your service as a document shepherd. Among the responsibilities is
answering the questions in this write-up to give helpful context to Last Call
and Internet Engineering Steering Group ([IESG][1]) reviewers, and your
diligence in completing it is appreciated. The full role of the shepherd is
further described in [RFC 4858][2]. You will need the cooperation of the authors
and editors to complete these checks.

Note that some numbered items contain multiple related questions; please be sure
to answer all of them.

## Document History

1. Does the working group (WG) consensus represent the strong concurrence of a
  few individuals, with others being silent, or did it reach broad agreement?

The document reached a broad consensus, comparable to that of many other documents in the COSE WG.

2. Was there controversy about particular points, or were there decisions where
  the consensus was particularly rough?

A controversy arose during IETF 122 regarding "natively signed" certificates and their evolution. However, the issue appears to have been resolved through discussion on the mailing list, as there was no further follow-up by the end of the WGLC.

3. Has anyone threatened an appeal or otherwise indicated extreme discontent? If
  so, please summarize the areas of conflict in separate email messages to the
  responsible Area Director. (It should be in a separate email because this
  questionnaire is publicly available.)

No.

4. For protocol documents, are there existing implementations of the contents of
  the document? Have a significant number of potential implementers indicated
  plans to implement? Are any existing implementations reported somewhere,
  either in the document itself (as [RFC 7942][3] recommends) or elsewhere
  (where)?

A demonstration implementation is available at https://github.com/cose-wg/CBOR-certificates/tree/master/c509_demo_impl, and a link to this repository is included in the document. However, the document does not explicitly mention this implementation.
The authors have suggested that there are also implementations by Lijun Liao  and Brian Sipos.
Derek Atkins derek@ihtfp.com also seems to indicate that they have an implementation in https://mailarchive.ietf.org/arch/msg/cose/dF30vuqIcKFJw2HIT6Q7T7aj_sI/.

## Additional Reviews

5. Do the contents of this document closely interact with technologies in other
  IETF working groups or external organizations, and would it therefore benefit
  from their review? Have those reviews occurred? If yes, describe which
  reviews took place.

I am not aware of any.

6. Describe how the document meets any required formal expert review criteria,
  such as the MIB Doctor, YANG Doctor, media type, and URI type reviews.

The media type has not undergone a special review, as the registrations are straightforward and the working group possesses expertise in this area.

All other types of reviews seem irrelevant for this document.

7. If the document contains a YANG module, has the final version of the module
  been checked with any of the [recommended validation tools][4] for syntax and
  formatting validation? If there are any resulting errors or warnings, what is
  the justification for not fixing them at this time? Does the YANG module
  comply with the Network Management Datastore Architecture (NMDA) as specified
  in [RFC 8342][5]?

There is no YANG module.

8. Describe reviews and automated checks performed to validate sections of the
  final version of the document written in a formal language, such as XML code,
  BNF rules, MIB definitions, CBOR's CDDL, etc.

The CDDL in Figure 2 was successfully verified using the tool at https://christian-bromann.github.io/cddl/. However, the CDDL in Figures 1 and 4 produced errors that appear to be tool-related.

## Document Shepherd Checks

9. Based on the shepherd's review of the document, is it their opinion that this
  document is needed, clearly written, complete, correctly designed, and ready
  to be handed off to the responsible Area Director?

Yes, the document is needed, clearly written, complete, correctly designed, and ready to be handed off to the responsible Area Director.

10. Several IETF Areas have assembled [lists of common issues that their
    reviewers encounter][6]. For which areas have such issues been identified
    and addressed? For which does this still need to happen in subsequent
    reviews?

In my opinion the draft does not have any of the listed SEC issues. Many of them are not relevant for this draft or are addressed by documents on x.509, which the draft builds on.

11. What type of RFC publication is being requested on the IETF stream ([Best
    Current Practice][12], [Proposed Standard, Internet Standard][13],
    [Informational, Experimental or Historic][14])? Why is this the proper type
    of RFC? Do all Datatracker state attributes correctly reflect this intent?

Proposed Standard

12. Have reasonable efforts been made to remind all authors of the intellectual
    property rights (IPR) disclosure obligations described in [BCP 79][7]? To
    the best of your knowledge, have all required disclosures been filed? If
    not, explain why. If yes, summarize any relevant discussion, including links
    to publicly-available messages when applicable.

Yes.

13. Has each author, editor, and contributor shown their willingness to be
    listed as such? If the total number of authors and editors on the front page
    is greater than five, please provide a justification.

Each author has shown willingness to be listed as such and the list is of exactly 5 people.

14. Document any remaining I-D nits in this document. Simply running the [idnits
    tool][8] is not enough; please review the ["Content Guidelines" on
    authors.ietf.org][15]. (Also note that the current idnits tool generates
    some incorrect warnings; a rewrite is underway.)

Idnits did not discover anything noteworthy about the document.

From a content guidelines perspective, the document is largely compliant; it is correctly named, structured, and contains the required content. One deviation from the Content Guidelines is the use of work emails for author contact, which may not be stable over time.

15. Should any informative references be normative or vice-versa? See the [IESG
    Statement on Normative and Informative References][16].

No.

16. List any normative references that are not freely available to anyone. Did
    the community have sufficient access to review any such normative
    references?

There are no such references.

17. Are there any normative downward references (see [RFC 3967][9] and [BCP
    97][10]) that are not already listed in the [DOWNREF registry][17]? If so,
    list them.

RFC 2985 and RFC 2986 are informational and therefore downward references.

18. Are there normative references to documents that are not ready to be
    submitted to the IESG for publication or are otherwise in an unclear state?
    If so, what is the plan for their completion?

No.

19. Will publication of this document change the status of any existing RFCs? If
    so, does the Datatracker metadata correctly reflect this and are those RFCs
    listed on the title page, in the abstract, and discussed in the
    introduction? If not, explain why and point to the part of the document
    where the relationship of this document to these other RFCs is discussed.

This document updates RFC 6698. This is clearly stated on the title page, in the abstract, and in the introduction.


20. Describe the document shepherd's review of the IANA considerations section,
    especially with regard to its consistency with the body of the document.
    Confirm that all aspects of the document requiring IANA assignments are
    associated with the appropriate reservations in IANA registries. Confirm
    that any referenced IANA registries have been clearly identified. Confirm
    that each newly created IANA registry specifies its initial contents,
    allocations procedures, and a reasonable name (see [RFC 8126][11]).

The document clearly identifies its requests to IANA for new COSE Header Parameter and Media Type Application registrations. These requests are necessary and minimal. The document also establishes several new registries with clear instructions and initial content.

21. List any new IANA registries that require Designated Expert Review for
    future allocations. Are the instructions to the Designated Expert clear?
    Please include suggestions of designated experts, if appropriate.

Here is the list:
- C509 Certificate Types Registry
- C509 Certificate Request Types Registry
- C509 Private Key Types Registry
- C509 Certificate Request Templates Types Registry
- C509 Attributes Registry
- C509 Extensions Registry
- C509 Certificate Policies Registry
- C509 Policies Qualifiers Registry
- C509 Information Access Registry
- C509 Extended Key Usages Registry
- C509 General Names Registry
- C509 Signature Algorithms Registry
- C509 Public Key Algorithms Registry

I believe that the instructions are clear.

[1]: https://www.ietf.org/about/groups/iesg/
[2]: https://www.rfc-editor.org/rfc/rfc4858.html
[3]: https://www.rfc-editor.org/rfc/rfc7942.html
[4]: https://wiki.ietf.org/group/ops/yang-review-tools
[5]: https://www.rfc-editor.org/rfc/rfc8342.html
[6]: https://wiki.ietf.org/group/iesg/ExpertTopics
[7]: https://www.rfc-editor.org/info/bcp79
[8]: https://www.ietf.org/tools/idnits/
[9]: https://www.rfc-editor.org/rfc/rfc3967.html
[10]: https://www.rfc-editor.org/info/bcp97
[11]: https://www.rfc-editor.org/rfc/rfc8126.html
[12]: https://www.rfc-editor.org/rfc/rfc2026.html#section-5
[13]: https://www.rfc-editor.org/rfc/rfc2026.html#section-4.1
[14]: https://www.rfc-editor.org/rfc/rfc2026.html#section-4.2
[15]: https://authors.ietf.org/en/content-guidelines-overview
[16]: https://www.ietf.org/about/groups/iesg/statements/normative-informative-references/
[17]: https://datatracker.ietf.org/doc/downref/