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

[Daniel Kahn Gillmor <[e-mail]>]

Hi François--

On 02/14/2014 12:45 PM, François Lonc wrote:
> 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.

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