Subject: [TLS] Fwd: New Version Notification for draft-lonc-tls-certieee1609-00.txt

From: François Lonc <[email-masked]>
Date: Fri, 14 Feb 2014 18:45:16 +0100

Hi,
I just published this draft about using other certificates (namely ETSI 
TS-103-097 and IEEE 1609.2) with TLS. As it defines a new TLS extension 
I think it would fit in this group, but I'm brand new here so I might be 
mistaken.

The envisioned application is ITS (as in Intelligent Transportation 
System) in Europe (therefore the ETSI).

I am aware that draft-ietf-tls-oob-pubkey 
<http://datatracker.ietf.org/doc/draft-ietf-tls-oob-pubkey/> proposes a 
similar TLS mechanism, but since the goals and applications seem very 
different, I thought it would still be worth submitting.

Thanks in advance for your comments and suggestions.

Regards,
François Lonc

P.S. Not sure of the etiquette here but Hey! I'm a cybersecurity grad 
student in Paris, France and very happy to read you.

-------- Message original --------
Sujet: 	New Version Notification for draft-lonc-tls-certieee1609-00.txt
Date : 	Fri, 14 Feb 2014 09:00:30 -0800
De : 	[email-masked]
Pour : 	Brigitte Lonc <[email-masked]>, Houda Labiod 
<[email-masked]>, Ahmed Serhrouchni 
<[email-masked]>, F. Lonc 
<[email-masked]>, Houda Labiod 
<[email-masked]>, Brigitte Lonc 
<[email-masked]>, Mohammed Badra <[email-masked]>, Mohamad 
Badra <[email-masked]>, Ahmed Serhrouchni 
<[email-masked]>, Francois Lonc 
<[email-masked]>

A new version of I-D, draft-lonc-tls-certieee1609-00.txt
has been successfully submitted by Francois Lonc and posted to the
IETF repository.

Name:		draft-lonc-tls-certieee1609
Revision:	00
Title:		Transport Layer Security (TLS) Client authentication Using IEEE 1609-2 Certificate
Document date:	2014-02-14
Group:		Individual Submission
Pages:		5
URL:            http://www.ietf.org/internet-drafts/draft-lonc-tls-certieee1609-00.txt
Status:         https://datatracker.ietf.org/doc/draft-lonc-tls-certieee1609/
Htmlized:       http://tools.ietf.org/html/draft-lonc-tls-certieee1609-00

Abstract:
    This document describes two types of certificates to authenticate TLS
    entities, the first type enables the use of a certificate specified
    by the Institute of Electrical and Electronics Engineers (IEEE)
    and the second by the European Telecommunications
    Standards Institute (ETSI).  This document defines a new
    extension to enable TLS entities authentication using one of the
    aforementioned certificate types.

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat

---

From: Daniel Kahn Gillmor <[email-masked]>
Date: Fri, 14 Feb 2014 13:52:18 -0500

Hi François--

> different, I thought it would still be worth submitting.

A clear explanation of how the goals and applications differ from
existing work would be useful in understanding why a new draft is needed.

Also, this draft seems similar to RFC 6091, which already has a registry
of certificate types.  Have you considered adding another entry or two
to that registry, rather than defining a new extension mechanism?

Barring that, a few notes follow:

The list of enumerated types for SupportedCertType and AcceptedCertType
seems to be identical.  is there any chance that they might differ?  if
not, why not collapse them into a single enum?

your IANA considerations section seems to be missing any reference to
the enumerated type list.  is this a registry you'd expect IANA to
maintain?  if not, how would it be extended?

The security considerations section seems too thin.  what
characteristics are relevant to these two different certificate formats?
 from a basic skim and search: the ETSI reference is 33 pages, and has
security as one of its top-level keywords and several pages about
security policy considerations.  are none of these relevant to this
draft?  I couldn't find a freely-available copy of IEEE 1609.2, so i
couldn't evaluate what kinds of security considerations might come into
play for this.

Are there trust anchors, pre-loaded lists, standard verification
policies, TOFU approaches, or other regimes for validating these
certificates?  which approaches are the recommended ones?  If the draft
plans to punt on certificate validation, or to refer to some other
document for "best practices" for certificate validation, it should
probably do so explicitly.

in what contexts would someone want to use one of these different
certificate types instead of an X.509 certificate or an OpenPGP
certificate or a raw public key?

If there are multiple possible encodings, how are these new certificate
formats packaged on the wire when they are included in the Server
Certificate or Client Certificate message?

the ETSI document suggests that ETSI keys can be either
ecdsa_nistp256_with_sha256 or ecies_nistp256. how do those key types
interact with the various key exchange mechanisms?  For example, i would
guess that an ecdsa_nistp256_with_sha256 key should only be used with a
DHE ciphersuite, presumably ECDHE_ECDSA
(https://tools.ietf.org/html/rfc4492#section-2.2)  Will the
signed_params object in the ServerKeyExchange algorithm use the same
signature mechanism and structure as would have been produced by the
same key packaged in an ECDSA X.509 certificate, or would it structure
the signature as in ETSI's §4.2.10?

Is there any interaction between the use of an ETSI cert and the ECC
extensions listed in rfc 4492?  What should happen in a TLS handshake
where neither peer offers any of the extensions from 4492 but they want
to negotiate this new extension?

(i'm asking about ETSI here because the spec is available gratis, but i
suspect similar questions are relevant to IEEE 1609.2)

The extension_data explanation doesn't identify a top-level structure
that explains how the data will be packed into the extension.  in
particular, it looks like the certificate_authorities object is dangling
to me.  how does the server indicate to the client which of the client's
"supported" certificate types it is willing to accept?

Can you clarify the difference between "supported" and "accepted"?  I
think "supported" means "i have a private key and a certificate that
matches one of these certificate types" and "accepted" means "i am able
to parse one of these certificate types from my peer", but it's probably
better to be explicit about it.

hth,

	--dkg