TLS Authentication Using Intelligent Transport System (ITS) Certificates
draft-msahli-ise-ieee1609-07

[Additional information added to the write-up...
This document was originally presented to the IESG for 5742 review on 2019-11-25.
Ben Kaduk was assigned as the responsible AD and preformed an initial review which suggested that the authors needed to do some further work on the document.
Revisions -04 and -05 address Ben's comments and a further review from the ISE.]

draft-msahli-ise-ieee1609 has been brought to the ISE requesting
publication as an Experimental RFC on the Independent Submissions
stream.

The document has a long history dating back to 2014, and has been posted
with a variety of document names over the years. The datatracker
provides a good linkage between the documents.

The work is clearly related to work carried out within IPWAVE, but
discussion with the chairs and responsible AD indicate that the working
group is not ready to consider the necessary recharter to include this,
and that they are happy with progression on the Independent Stream. I
also consulted Sean Turner (TLS cochair) for background and
acceptability of this work.

Along the way, I collected reviews from Russ Housley (IPWAVE cochair)
twice, Michael Richardson (brief review), Mike Montemurro, and Bill
Lattin. I also did two reviews as ISE, and assisted with the
construction of text for the updated document.

The details of the reviews can be found below.

IANA had previously allocated a code point for use by the function
described in this document. This document requests an update to the
registry to point to this document.

== Russ Housley 1 ==

Summary:  Not ready for publication


Major Concerns:

The Abstract and Section 1:  A very quick look at IEEE 1609.2 shows more
than one type of certificate.  It is pretty clear that this is not about
a "root certificate", and it is pretty clear that an "explicit
certificate" is intended.  That said, the document should be clear about
which certificates can be used.  I see definitions for "authorization
certificate", "encryption certificate", "locally held certificate", and
"pseudonym certificate".  As I said, it was a quick scan, so I may have
missed other types.

Section 3 includes this text:

  ...  The end-
  entity certificate's public key MUST be compatible with one of the
  certificate types listed in the extension described above.

I do not think this is correct.  This wording precludes specification
of additional certificate types in the future.  Also, I am not sure
what linking between the certificate and the public key is intended.

Section 4 and 4.1: One way to interpret Figure 1 and the first paragraph
of Section 4.1 is that both the client and the server must have a
"1609Dot2" certificate for either the client or the server to use their
"1609Dot2" certificate.  However, Section 6.2 shows the client using a
"1609Dot2" certificate and the server using a an X.509 certificate.
Please reword to make this clear.

Section 7: Only one of the sentences is relevant:

  ... The security
  considerations described throughout [RFC8446] regarding the supported
  groups and signature algorithms apply here as well.

There is much more to say.  At a minimum, there needs to be something
said about the online repository used to obtain TLS client or server
public keys.

Section 9:  This section needs to point to the specific registry that
the authors want IANA to update, and it needs to tell IANA what code
points needs to be assigned.


Minor Concerns:

The Abstract says:

  This document specifies the use of a new certificate type to
  authenticate TLS entities.  The goal is to enable the use of a
  certificate specified by the IEEE and the European Telecommunications
  Standards Institute (ETSI).  This specification defines an
  experimental change of TLS to support a new certificate type.
 
I suggest that "additional certificate type" would be a better way to
describe the intent.  Further, the IEEE 1609.2 certificate specification
has been around for several more than a decade.

The term "new certificate" appears other places too.  A shorthand name
for this additional type of certificate that is used throughout the
document would be helpful.  One possibility is to use the proposed
TLS Certificate Type of "1609Dot2".

Section 3: This talks about TLS 1.2 and TLS 1.3.  If you want to use
both versions, please reference [RFC5246] and [RFC8446] in Section 1.

Section 4.1 says:

  The Hello extension is described in Section 4.1.2 of TLS 1.3 ...
 
There is no "Hello extension".  That section is about the Client Hello
handshake message, which include an extensions field.  Please correct.

Section 6: Please explain the meaning of "*=" in Figure 2.  The meaning
does not seem to align with the conventions defined in RFC 8446, where
"*" indicates optional or situation-dependent messages/extensions that
are not always sent.


Other Editorial Comments:

Section 1: s/X.509/X.509 certificates/

Section 1.1: s/in IETF works/in the Internet/

Sections 1.1 says:

  ... This design has been requested by
  stakeholders in the Cooperative ITS community including ISO
  internationally, and SAE in the US and ETSI in EU , in order to
  support the deployment of a number of use cases in cooperative ITS
  and it is anticipated that its use will be widespread.

This is not a well structured sentence.  Please correct.

Section 1.1 says:

  There is no IPR that needs to be disclosed by the authors or
  contributors under the IETF's rules set out in BCP 78 and BCP 79.
 
This does not belong in the body of the document.  It is covered by the
Status of This Memo, which includes:

  This Internet-Draft is submitted in full conformance with the
  provisions of BCP 78 and BCP 79.

Section 4.1: s/client hello/Client Hello/

Section 4.2: s/server hello/Server Hello/

Section 5:  Please include a reference to ITU-T X.696 for the
specification of Canonical Octet Encoding Rules (COER).

== Russ Housley 2 ==

Summary:  Not ready for publication


Major Concerns:

Section 7 says:

  TLS extensions to be considered are:

      The "client_certificate_type" [IANA value 19] extension who's
      purpose was previously described in [RFC7250].

      The "server_certificate_type" [IANA value 20] extension who's
      purpose was previously described in [RFC7250].

What does this have to do with security considerations?  If it goes
anywhere, it belongs in Section 3.  I think you are trying to say
something about which TLS 1.2 extension carries the certificate
type, but I am not at all sure.

Section 7: How does the use of an online repository used to obtain TLS
client or server public keys impact the security of the TLS client or
the TLS server?  I do not think you get to ignore it here, especially
since once can use a 609Dot2 certificate and the other use an X.509
certificate.

Section 9:  This section points to the specific registry, and it does
not tell IANA what code points needs to be updated.  I think you want
IANA to change the reference for the "1609Dot2" entry, but this text
does not say so.


Minor Concerns:

None.


Other Editorial Comments:

Abstract: It seems odd to spell out ETSI, but not IEEE.  My guess is
that neither one should be spelled out here.

Sections 1.1 says:

  ... This extension has been encouraged by
  stakeholders in the Cooperative ITS community including ISO
  internationally, and SAE in the US and ETSI in EU , in order to
  support the deployment of a number of use cases in cooperative ITS
  and it is anticipated that its use will be widespread.

This is not a well structured sentence.  Please correct.

Section 5: I cannot parse the sentence about COER.  I suggest:

  ... IEEE1609Dot2Data encoded with the Canonical Octet Encoding
  Rules [ITU-TX.696] of type signed ...

I notice that COER is not used anywhere else in the document, so there
is no need to define the acronym.

Section 6.2: s/1609.9Dot/1609Dot2/

== Michael Richardson ==

I would feel happier if the document included enough
details from 1609.2 so that I could implement without having to own 1609.2
(who knows what the IPR policy on the document is).


== Mike Montemurro ==

    Section 5:
   
    In general, I think this section contains the bulk of the description of what's
going on. I'd recommend you expand this section to explain the process in more
detail. It was really hard for me to follow and track through documents.
   
    Specifically,
   
    Looking at IEEE Std 1609.2, section 5.1 does more than just describe the
validation of IEEE 1609.2/ETSI TS 103097 certificates. - I would suggest that
you change:
    "Verification of an IEEE 1609.2/ETSI TS 103097 ..." to "The format and
verification of an IEEE 1609.2/ETSI TS 103097 ..."
   
    " Ieee1609Dot2Data of type signed as specified in [1609.2b]" where is this
specified in 1609.2b? - It would be good to make this more clear on where this
is defined because I had trouble finding this.
   
    " the CertificateVerify message does not contain a raw signature but instead
contains a Canonical Octet Encoding Rules (COER)-encoded Ieee1609Dot2Data of
type signed as specified in [1609.2b], with the pduFunctionalType field present
and set to tlsHandshake." - I believe this requires more explanation. Also, the
structure of the sentence is weird e.g. "does not contain a raw signature but
instead....", it would be better to say something like "when the certificate
type is 1609Dot2, ..."
   
    Section 11.1
   
    - You need to reference IEEE 1609.2b.

== Bill Lattin ==

Section 1
Does TLS abandon a session when one of the certs expires?  This could be an issue with 1609 due to the short lifetimes.

---

4.1
Potential source of downgrade attack if one cert type is weaker than another (e.g., signed with a weaker root key).  Specifically, should we have checks to ensure cert sigs are at least as strong as the ephemeral keys?

---

4.2
Downgrade attack to weaker cert?

---

"It is worth to mention that the TLS client or server public keys are
obtained from an online repository."

I don't understand what is intended here.

---

5.
Should this be stronger - verification MUST BE performed as described in Section 5.1 …

---

5.
"The certificate appPermissions field shall be present and shall
  permit (as defined in 1609.2) signing of PDUs with the PSID indicated
  in the HeaderInfo of the SignedData."

Doesn't seem directly applicable to their use for TLS.  Should we have another PSID to allow use in TLS?

---

Fig 3

How does the client interpret the lack of PSID/SSP in the X.509 cert?  How does the server interpret the presence of PSID/SSP?

---

7.
I think there should be a more complete discussion of certificate validity since someone from the PKIX world will have little idea about how to interpret a 1609.2 cert (and possibly vice versa as well).  Also point validation should be stressed - even though it is mentioned in 8446 - folks still don't always do it.

RFC8446 Section 4.2.3 says if TLS v1.2 is negotiated, implementations must be prepared to accept a signature that uses any curve advertised.  This could result in failures when using 1609.2 certs.

== ISE 1 ==

> Hi,
>
> Before kicking this off for external review I have given it a quick
> inspection myself. I am not an expert in this area, so my early
> comments are about the structure and content. I think you should
> resolve these before I send the document out because they are fairly
> fundamental to the content and will make review by others much easier.
>
>
>
> 0. Please have a look at (and fix!) the issues reported by idnits
>    https://www6.ietf.org/tools/idnits?url=https://www.ietf.org/archive/id/draft-msahli-ipwave-ieee1609-01.txt
>
> 1. Abstract needs to make clear this is an Experiment.
>
> 2. Introduction needs to make it clear this is an Experiment.
>
> 3. Need a new section (maybe 1.1) to describe the Experiment.
>    What is the Experiment? How constrained? What happens if the
>    Experiment escapes? How do participating nodes know they are part of
>    the Experiment? How will you judge the success or failure of the
>    Experiment? When will you terminate the Experiment? What do you plan
>    to do if the Experiment is a success?
>
> 4. Please fix the boilerplate text in section 2
>
> OLD
>    The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
>    "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
>    document are to be interpreted as described in [RFC2119].
> NEW
>    The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
>    "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
>    "OPTIONAL" in this document are to be interpreted as described in BCP
>    14 [RFC2119] [RFC8174] when, and only when, they appear in all
>    capitals, as shown here.
> END
>
> 5. I think you should take three IANA actions:
>
>    a. Copy over the text from draft-tls-certieee1609-02.txt so that this
>      document is stand-alone
>    b. Update the text to say "IANA has allocated..." but make your
>      request to IANA that "on publication of this document as an RFC,
>      IANA is requested to update the registry to reference the RFC"
>    c. Ask IANA to update the existing registry to point to this document
>      instead of draft-tls-certieee1609-02.txt (that should be
>      relatively easy to achieve as the replaced-by links are in place
>      in the datatracker)
>
> 6. Can you clarify in the document whether this approach is intended for
>    TLS1.3 only or all versions of TLS. If you intend it to be available
>    in TLS versions before 1.3, can you explain why you don't show
>    Open_PGP in section 3. (Section 4 implies at least 1.2 is also
>    supported.)
>
> 7. Please mark Appendix A as "Contributors" not "Co-Authors"

== ISE 2 ==

Abstract

Nice and short, thanks. But it actually manages to repeat itself even in
the few brief lines you have! How about...

  The IEEE and ETSI have specified end-entity certificates.  This
  docment defines an experimental change to TLS to support IEEE/ETSI
  certificate types to authenticate TLS entities.

---

Section 1

  The C-ITS certificates
  are also suited to the M2M ad hoc network setting, because their
  direct encoding of permissions (see Security Considerations, section
  7.6)

You don't have a section 7.6.

---

Section 1

This is one very large paragraph. Can you find a way to break it into
maybe three?

---

1.1

This is good, thank you. Some suggested tidying...

  This document describes an experimental extension to the TLS security
  model.  It uses a form of certificate that has not previously been
  used in the Internet.  Systems using this Experimental approach
  are segregated from system using standard TLS by the use of a new
  Certificate Type value, reserved through IANA (see Section 9).  An
  implementation of TLS that is not involved in the Experiment will not
  recognise this new Certificate Type and will not be able to interact
  with an Experimental implementation: TLS sessions will fail to be
  established.

  This extension has been encouraged by stakeholders in the Cooperative
  ITS community in order to support the C-ITS use cases deployment and
  it is anticipated that its use will be widespread.

---

Section 2

s/[RFC8174]when/[RFC8174] when/

---

Section 3

s/TLS 1.2[RFC5246]/TLS 1.2 [RFC5246]/

s/In case where the TLS/If the TLS/

---

4.1

s/certificates, client MUST/certificates, a client MUST/

---

4.2

s/ETSI[ETSI102941]/ETSI [ETSI102941]/

---

Subsections of section 7

Please convert the section headings to title case

---

7.1

s/941[ETSI102941]/941 [ETSI102941]/

---

7.4

s/[SAEJ29453]uses/[SAEJ29453] uses/

---

Section 8

  For privacy considerations in a vehicular environment the use of IEEE
  1609.2/ETSI TS 103097 certificate is recommended for many reasons:

Is that 'RECOMMENDED' ?

---

Section 9

I think we can make this section a little more crisp. I think the URL
was wrong, as well. How about...

  IANA maintains the "Transport Layer Security (TLS) Extensions"
  registry with a subregistry called "TLS Cetificate Types".

  IANA has previously assigned an entry (value 3) for "1609Dot2" with
  reference set to draft-tls-certieee1609.  IANA is requested to update
  that entry to reference the RFC number of this document when it is
  published.

  [NOTE for IANA to be removed before publication: This document is a
    replacement of draft-tls-certieee1609.]

(Via drafts-eval@iana.org): IESG/Authors/ISE:

The IANA Functions Operator has reviewed draft-msahli-ise-ieee1609-03 and has the following comments:

We understand that when this document is sent to us for processing, there will be one registry action to perform.

The current reference for the following TLS Certificate Types (https://www.iana.org/assignments/tls-extensiontype-values) registration, a reference to draft-tls-certieee1609, will be replaced with a reference to this document:

Value: 3
Name: 1609Dot2
Recommended: N
Reference: [this document]

This change has been approved by the designated experts for this registry.

If this assessment is inaccurate, please respond as soon as possible.

Thank you,

Amanda Baber
Lead IANA Services Specialist

draft-msahli-ise-ieee1609 has been brought to the ISE requesting
publication as an Experimental RFC on the Independent Submissions
stream.

The document has a long history dating back to 2014, and has been posted
with a variety of document names over the years. The datatracker
provides a good linkage between the documents.

The work is clearly related to work carried out within IPWAVE, but
discussion with the chairs and responsible AD indicate that the working
group is not ready to consider the necessary recharter to include this,
and that they are happy with progression on the Independent Stream. I
also consulted Sean Turner (TLS cochair) for background and
acceptability of this work.

Along the way, I collected reviews from Russ Housley (IPWAVE cochair)
twice, Michael Richardson (brief review), Mike Montemurro, and Bill
Lattin. I also did two reviews as ISE, and assisted with the
construction of text for the updated document.

The details of the reviews can be found below.

IANA had previously allocated a code point for use by the function
described in this document. This document requests an update to the
registry to point to this document.

== Russ Housley 1 ==

Summary:  Not ready for publication


Major Concerns:

The Abstract and Section 1:  A very quick look at IEEE 1609.2 shows more
than one type of certificate.  It is pretty clear that this is not about
a "root certificate", and it is pretty clear that an "explicit
certificate" is intended.  That said, the document should be clear about
which certificates can be used.  I see definitions for "authorization
certificate", "encryption certificate", "locally held certificate", and
"pseudonym certificate".  As I said, it was a quick scan, so I may have
missed other types.

Section 3 includes this text:

  ...  The end-
  entity certificate's public key MUST be compatible with one of the
  certificate types listed in the extension described above.

I do not think this is correct.  This wording precludes specification
of additional certificate types in the future.  Also, I am not sure
what linking between the certificate and the public key is intended.

Section 4 and 4.1: One way to interpret Figure 1 and the first paragraph
of Section 4.1 is that both the client and the server must have a
"1609Dot2" certificate for either the client or the server to use their
"1609Dot2" certificate.  However, Section 6.2 shows the client using a
"1609Dot2" certificate and the server using a an X.509 certificate.
Please reword to make this clear.

Section 7: Only one of the sentences is relevant:

  ... The security
  considerations described throughout [RFC8446] regarding the supported
  groups and signature algorithms apply here as well.

There is much more to say.  At a minimum, there needs to be something
said about the online repository used to obtain TLS client or server
public keys.

Section 9:  This section needs to point to the specific registry that
the authors want IANA to update, and it needs to tell IANA what code
points needs to be assigned.


Minor Concerns:

The Abstract says:

  This document specifies the use of a new certificate type to
  authenticate TLS entities.  The goal is to enable the use of a
  certificate specified by the IEEE and the European Telecommunications
  Standards Institute (ETSI).  This specification defines an
  experimental change of TLS to support a new certificate type.
 
I suggest that "additional certificate type" would be a better way to
describe the intent.  Further, the IEEE 1609.2 certificate specification
has been around for several more than a decade.

The term "new certificate" appears other places too.  A shorthand name
for this additional type of certificate that is used throughout the
document would be helpful.  One possibility is to use the proposed
TLS Certificate Type of "1609Dot2".

Section 3: This talks about TLS 1.2 and TLS 1.3.  If you want to use
both versions, please reference [RFC5246] and [RFC8446] in Section 1.

Section 4.1 says:

  The Hello extension is described in Section 4.1.2 of TLS 1.3 ...
 
There is no "Hello extension".  That section is about the Client Hello
handshake message, which include an extensions field.  Please correct.

Section 6: Please explain the meaning of "*=" in Figure 2.  The meaning
does not seem to align with the conventions defined in RFC 8446, where
"*" indicates optional or situation-dependent messages/extensions that
are not always sent.


Other Editorial Comments:

Section 1: s/X.509/X.509 certificates/

Section 1.1: s/in IETF works/in the Internet/

Sections 1.1 says:

  ... This design has been requested by
  stakeholders in the Cooperative ITS community including ISO
  internationally, and SAE in the US and ETSI in EU , in order to
  support the deployment of a number of use cases in cooperative ITS
  and it is anticipated that its use will be widespread.

This is not a well structured sentence.  Please correct.

Section 1.1 says:

  There is no IPR that needs to be disclosed by the authors or
  contributors under the IETF's rules set out in BCP 78 and BCP 79.
 
This does not belong in the body of the document.  It is covered by the
Status of This Memo, which includes:

  This Internet-Draft is submitted in full conformance with the
  provisions of BCP 78 and BCP 79.

Section 4.1: s/client hello/Client Hello/

Section 4.2: s/server hello/Server Hello/

Section 5:  Please include a reference to ITU-T X.696 for the
specification of Canonical Octet Encoding Rules (COER).

== Russ Housley 2 ==

Summary:  Not ready for publication


Major Concerns:

Section 7 says:

  TLS extensions to be considered are:

      The "client_certificate_type" [IANA value 19] extension who's
      purpose was previously described in [RFC7250].

      The "server_certificate_type" [IANA value 20] extension who's
      purpose was previously described in [RFC7250].

What does this have to do with security considerations?  If it goes
anywhere, it belongs in Section 3.  I think you are trying to say
something about which TLS 1.2 extension carries the certificate
type, but I am not at all sure.

Section 7: How does the use of an online repository used to obtain TLS
client or server public keys impact the security of the TLS client or
the TLS server?  I do not think you get to ignore it here, especially
since once can use a 609Dot2 certificate and the other use an X.509
certificate.

Section 9:  This section points to the specific registry, and it does
not tell IANA what code points needs to be updated.  I think you want
IANA to change the reference for the "1609Dot2" entry, but this text
does not say so.


Minor Concerns:

None.


Other Editorial Comments:

Abstract: It seems odd to spell out ETSI, but not IEEE.  My guess is
that neither one should be spelled out here.

Sections 1.1 says:

  ... This extension has been encouraged by
  stakeholders in the Cooperative ITS community including ISO
  internationally, and SAE in the US and ETSI in EU , in order to
  support the deployment of a number of use cases in cooperative ITS
  and it is anticipated that its use will be widespread.

This is not a well structured sentence.  Please correct.

Section 5: I cannot parse the sentence about COER.  I suggest:

  ... IEEE1609Dot2Data encoded with the Canonical Octet Encoding
  Rules [ITU-TX.696] of type signed ...

I notice that COER is not used anywhere else in the document, so there
is no need to define the acronym.

Section 6.2: s/1609.9Dot/1609Dot2/

== Michael Richardson ==

I would feel happier if the document included enough
details from 1609.2 so that I could implement without having to own 1609.2
(who knows what the IPR policy on the document is).


== Mike Montemurro ==

    Section 5:
   
    In general, I think this section contains the bulk of the description of what's
going on. I'd recommend you expand this section to explain the process in more
detail. It was really hard for me to follow and track through documents.
   
    Specifically,
   
    Looking at IEEE Std 1609.2, section 5.1 does more than just describe the
validation of IEEE 1609.2/ETSI TS 103097 certificates. - I would suggest that
you change:
    "Verification of an IEEE 1609.2/ETSI TS 103097 ..." to "The format and
verification of an IEEE 1609.2/ETSI TS 103097 ..."
   
    " Ieee1609Dot2Data of type signed as specified in [1609.2b]" where is this
specified in 1609.2b? - It would be good to make this more clear on where this
is defined because I had trouble finding this.
   
    " the CertificateVerify message does not contain a raw signature but instead
contains a Canonical Octet Encoding Rules (COER)-encoded Ieee1609Dot2Data of
type signed as specified in [1609.2b], with the pduFunctionalType field present
and set to tlsHandshake." - I believe this requires more explanation. Also, the
structure of the sentence is weird e.g. "does not contain a raw signature but
instead....", it would be better to say something like "when the certificate
type is 1609Dot2, ..."
   
    Section 11.1
   
    - You need to reference IEEE 1609.2b.

== Bill Lattin ==

Section 1
Does TLS abandon a session when one of the certs expires?  This could be an issue with 1609 due to the short lifetimes.

---

4.1
Potential source of downgrade attack if one cert type is weaker than another (e.g., signed with a weaker root key).  Specifically, should we have checks to ensure cert sigs are at least as strong as the ephemeral keys?

---

4.2
Downgrade attack to weaker cert?

---

"It is worth to mention that the TLS client or server public keys are
obtained from an online repository."

I don't understand what is intended here.

---

5.
Should this be stronger - verification MUST BE performed as described in Section 5.1 …

---

5.
"The certificate appPermissions field shall be present and shall
  permit (as defined in 1609.2) signing of PDUs with the PSID indicated
  in the HeaderInfo of the SignedData."

Doesn't seem directly applicable to their use for TLS.  Should we have another PSID to allow use in TLS?

---

Fig 3

How does the client interpret the lack of PSID/SSP in the X.509 cert?  How does the server interpret the presence of PSID/SSP?

---

7.
I think there should be a more complete discussion of certificate validity since someone from the PKIX world will have little idea about how to interpret a 1609.2 cert (and possibly vice versa as well).  Also point validation should be stressed - even though it is mentioned in 8446 - folks still don't always do it.

RFC8446 Section 4.2.3 says if TLS v1.2 is negotiated, implementations must be prepared to accept a signature that uses any curve advertised.  This could result in failures when using 1609.2 certs.

== ISE 1 ==

> Hi,
>
> Before kicking this off for external review I have given it a quick
> inspection myself. I am not an expert in this area, so my early
> comments are about the structure and content. I think you should
> resolve these before I send the document out because they are fairly
> fundamental to the content and will make review by others much easier.
>
>
>
> 0. Please have a look at (and fix!) the issues reported by idnits
>    https://www6.ietf.org/tools/idnits?url=https://www.ietf.org/archive/id/draft-msahli-ipwave-ieee1609-01.txt
>
> 1. Abstract needs to make clear this is an Experiment.
>
> 2. Introduction needs to make it clear this is an Experiment.
>
> 3. Need a new section (maybe 1.1) to describe the Experiment.
>    What is the Experiment? How constrained? What happens if the
>    Experiment escapes? How do participating nodes know they are part of
>    the Experiment? How will you judge the success or failure of the
>    Experiment? When will you terminate the Experiment? What do you plan
>    to do if the Experiment is a success?
>
> 4. Please fix the boilerplate text in section 2
>
> OLD
>    The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
>    "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
>    document are to be interpreted as described in [RFC2119].
> NEW
>    The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
>    "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
>    "OPTIONAL" in this document are to be interpreted as described in BCP
>    14 [RFC2119] [RFC8174] when, and only when, they appear in all
>    capitals, as shown here.
> END
>
> 5. I think you should take three IANA actions:
>
>    a. Copy over the text from draft-tls-certieee1609-02.txt so that this
>      document is stand-alone
>    b. Update the text to say "IANA has allocated..." but make your
>      request to IANA that "on publication of this document as an RFC,
>      IANA is requested to update the registry to reference the RFC"
>    c. Ask IANA to update the existing registry to point to this document
>      instead of draft-tls-certieee1609-02.txt (that should be
>      relatively easy to achieve as the replaced-by links are in place
>      in the datatracker)
>
> 6. Can you clarify in the document whether this approach is intended for
>    TLS1.3 only or all versions of TLS. If you intend it to be available
>    in TLS versions before 1.3, can you explain why you don't show
>    Open_PGP in section 3. (Section 4 implies at least 1.2 is also
>    supported.)
>
> 7. Please mark Appendix A as "Contributors" not "Co-Authors"

== ISE 2 ==

Abstract

Nice and short, thanks. But it actually manages to repeat itself even in
the few brief lines you have! How about...

  The IEEE and ETSI have specified end-entity certificates.  This
  docment defines an experimental change to TLS to support IEEE/ETSI
  certificate types to authenticate TLS entities.

---

Section 1

  The C-ITS certificates
  are also suited to the M2M ad hoc network setting, because their
  direct encoding of permissions (see Security Considerations, section
  7.6)

You don't have a section 7.6.

---

Section 1

This is one very large paragraph. Can you find a way to break it into
maybe three?

---

1.1

This is good, thank you. Some suggested tidying...

  This document describes an experimental extension to the TLS security
  model.  It uses a form of certificate that has not previously been
  used in the Internet.  Systems using this Experimental approach
  are segregated from system using standard TLS by the use of a new
  Certificate Type value, reserved through IANA (see Section 9).  An
  implementation of TLS that is not involved in the Experiment will not
  recognise this new Certificate Type and will not be able to interact
  with an Experimental implementation: TLS sessions will fail to be
  established.

  This extension has been encouraged by stakeholders in the Cooperative
  ITS community in order to support the C-ITS use cases deployment and
  it is anticipated that its use will be widespread.

---

Section 2

s/[RFC8174]when/[RFC8174] when/

---

Section 3

s/TLS 1.2[RFC5246]/TLS 1.2 [RFC5246]/

s/In case where the TLS/If the TLS/

---

4.1

s/certificates, client MUST/certificates, a client MUST/

---

4.2

s/ETSI[ETSI102941]/ETSI [ETSI102941]/

---

Subsections of section 7

Please convert the section headings to title case

---

7.1

s/941[ETSI102941]/941 [ETSI102941]/

---

7.4

s/[SAEJ29453]uses/[SAEJ29453] uses/

---

Section 8

  For privacy considerations in a vehicular environment the use of IEEE
  1609.2/ETSI TS 103097 certificate is recommended for many reasons:

Is that 'RECOMMENDED' ?

---

Section 9

I think we can make this section a little more crisp. I think the URL
was wrong, as well. How about...

  IANA maintains the "Transport Layer Security (TLS) Extensions"
  registry with a subregistry called "TLS Cetificate Types".

  IANA has previously assigned an entry (value 3) for "1609Dot2" with
  reference set to draft-tls-certieee1609.  IANA is requested to update
  that entry to reference the RFC number of this document when it is
  published.

  [NOTE for IANA to be removed before publication: This document is a
    replacement of draft-tls-certieee1609.]