Subject: [Ace] Fwd: New Version Notification for draft-mehrtens-core-ace-concert-00.txt

From: Hauke Mehrtens <[email-masked]>
Date: Thu, 20 Feb 2014 13:23:41 +0100

Hi,

We submitted a proposal for a new kind of certificate suited for
constrained environments. It should provide similar features as X.509
does, but only suited for TLS and DTLS usage. The draft is in an early
state.

We would like to get some comments on this idea.

Best regards,
Hauke

-------- Original Message --------
Subject: New Version Notification for draft-mehrtens-core-ace-concert-00.txt
Date: Fri, 14 Feb 2014 15:54:46 -0800
From: [email-masked]
To: Hauke Mehrtens <[email-masked]>, "Hauke Mehrtens" <[email-masked]>

A new version of I-D, draft-mehrtens-core-ace-concert-00.txt
has been successfully submitted by Hauke Mehrtens and posted to the
IETF repository.

Name:		draft-mehrtens-core-ace-concert
Revision:	00
Title:		Constrained Certificates for the Constrained Application
Protocol (CoAP)
Document date:	2014-02-14
Group:		Individual Submission
Pages:		12
URL:
http://www.ietf.org/internet-drafts/draft-mehrtens-core-ace-concert-00.txt
Status:
https://datatracker.ietf.org/doc/draft-mehrtens-core-ace-concert/
Htmlized:
http://tools.ietf.org/html/draft-mehrtens-core-ace-concert-00

Abstract:
   The present document defines a new kind of certificate suited for
   constrained environments.  This new kind of certificate is intended
   to be used in Transport Layer Security (TLS) and Datagram Transport
   Layer Security (DTLS) in combination with Constrained Application
   Protocol (CoAP).

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: Paul Lambert <[email-masked]>
Date: Thu, 20 Feb 2014 20:06:26 -0800

> We would like to get some comments on this idea.
"The serialNumber should be used by an issuer to store additional data
   like a serial number to do certificate revocation or to add some
   additional entropy to the certificate.”

Not well specified.  Extra entropy not necessary.
serialNumber in general not a well formed concept to use.

   "The issuer element must contain a named information defined in
   [RFC6920], which is a SHA-256 hash over the issuer's public key or
   part of it.  It is used to identify the issuer certificate.  The
   element is tagged with the hash algorithm used to create the hash.

Pick something specific (not “or part of it”)

   "There are no secure hash algorithms needed, because a collision will
   not weaken the security, it will just prevent the issuer from being
   found."

Delete - wrong.

   SubjectName ::= CHOICE {
        IPv4               byte string,
        IPv6               byte string,
        dns                utf-8 string }

What CAs have authority to issue which blocks of IPv4??

What of the issuer certs look like?  Are there any constraints on level or dns range?

Paul

> _______________________________________________
> Ace mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ace

---

From: Hauke Mehrtens <[email-masked]>
Date: Wed, 26 Feb 2014 17:02:59 +0100

Hi Paul,

Thanks for your review.

> serialNumber in general not a well formed concept to use.

This was intended to prevent some attacks, when the hash algorithm is
broken, like it was done with MD5 in "MD5 Considered Harmful Today
Creating a rogue CA certificate" [0].
Thinking further I would rather remove the attribute serialNumber
completely and rely on using a strong hash algorithm when creating the
signature.

> Pick something specific (not “or part of it”)

Thanks for spotting this.
The hash should be made over the content of the subjectPublicKeyInfo
element.

>    not weaken the security, it will just prevent the issuer from being

This hash is used to identify the issuer's certificate, it is something
like the Issuer DN in a X.509 certificate. In the PKI world no one
prevents me from generating a certificate, which has the same Subject DN
as your certificate or a trusted CA, but I do not have any gain from it.
The hash over the Public key has the same usage as the subject DN in a
certificate.

> What CAs have authority to issue which blocks of IPv4??

I haven't thought about a new CA model and would like to use the same or
a similar model as used in the PKI world with X.509 certificates.
So every trusted CA has the authority to issue a certificate for
everything. It should be still possible to use this with DANE.

> What of the issuer certs look like?  Are there any constraints on level or dns range?

There is still something like a key usage field missing in this draft.
A good idea would be to make the CA cert smaller and do not do this self
signed stuff used in X.509. The only elements needed in an root issuer
certificate are the public key and the validity dates.

Best regards,
Hauke

> Paul

[0]:
http://events.ccc.de/congress/2008/Fahrplan/attachments/1251_md5-collisions-1.0.pdf

---

From: Paul Lambert <[email-masked]>
Date: Thu, 27 Feb 2014 00:48:09 -0800

> a similar model as used in the PKI world with X.509 certificates.

A certificate without a well architected and documented trust framework will be problematic.

Your choice of following X>509 is a mistake (IMHO).
Many problems are documented:
 - lack of useable delegation
 - insufficient semantics especially for constraints on attribute delegation

> everything. It should be still possible to use this with DANE.

This is an overly promiscuous design foundation.

> There is still something like a key usage field missing in this draft.

Not clear at all this makes sense.

Paul

---

From: Hauke Mehrtens <[email-masked]>
Date: Thu, 27 Feb 2014 21:24:49 +0100

>  - insufficient semantics especially for constraints on attribute delegation

This certificate is targeted at constrained devices. I want to make it
possible to use this on a Class 1 node with ~10 KB RAM and ~100 KB ROM,
so one goal is to keep this small. The implementation handling these
certificates should not consume lots of memory and also the data needed
to be transfered should be small.

The use case I thought about is an organization installing devices for
building automation in their own buildings. The organization creates a
own CA certificate and signs all the certificates of the devices
installed in their buildings with this certificate and installs it as
the only trusted entity in all the devices.

I haven't thought about certificate revocation that is still an open issue.

Hauke

---

From: Carsten Bormann <[email-masked]>
Date: Thu, 27 Feb 2014 22:01:07 +0100

> A certificate without a well architected and documented trust framework will be problematic.

Indeed, certificates are most useful if the interpreter of the certificate can find out what they certify, and what is the authorization underlying that certification.
My assumption would be that we want to have a richer, more directly applicable language in constrained systems than what we are used to in PKI.
One thing that ACE could do is to define a small(!) set of useful elements of that vocabulary.

Grüße, Carsten

---

From: Rene Struik <[email-masked]>
Date: Thu, 27 Feb 2014 17:12:54 -0500

Hi Carsten:

I enjoyed reading your position paper for tomorrow's STRINT workshop. 
One thing that is worth articulating is that ownership of data issues 
should be sorted out, where explicit consent is not the same as pressing 
a button because service providers only have a black-and-white 
all-or-nothing policy (your toothbrush example comes to mind, where 
insurance company does not pay for dental work if there is no evidence 
that customer flossed and brushed their teeths at least twice for at 
least 99% of the time). Considering blanket access Apps do wish to claim 
to smart phone storage, perhaps the only mechanism that works here is 
strict legislation (on top of security mechanisms), where ownership 
cannot be circumvented or transferred on a whim. The same issue plays 
with vehicular to vehicular (V2V) safety technology, where car 
manufacturers may claim they own the data, even though the customer 
bought the car. (It is estimated that in 2025, half of the value of a 
car is in data/networking services, so there is an incentive to 
arm-wrestle consumers here.)

Unfortunately, I will not be at IETF-89 in London; I will be at the next 
meeting, in Toronto. I may have more specific details on the 
crypto-related discussion we had in Vancouver in November by then 
(perhaps, a light-weight hardware-assisted implementation of all crypto 
one needs for sensor applications from cradle to grave).

Best regards, Rene

PS: not sure whether the traditional approach of stuffing certs with 
authorization info is best (i.e., combining authentication and 
authorization credential) is best. We can discuss later.

-- 
email: [email-masked] | Skype: rstruik
cell: +1 (647) 867-5658 | US: +1 (415) 690-7363

---

From: Ludwig Seitz <[email-masked]>
Date: Fri, 28 Feb 2014 08:56:44 +0100

> authorization credential) is best. We can discuss later.

I'm pretty sure combining authN and authZ in one credential is _not_ a 
good idea. It might work in certain cases (i.e. when successful 
authentication implies full access without restrictions) but in most 
other cases it fails miserably (think revocation, changing access 
rights, anonymous access and so on).

/Ludwig

-- 
Ludwig Seitz, PhD
SICS Swedish ICT AB
Ideon Science Park
Building Beta 2
Scheelevägen 17
SE-223 70 Lund

Phone +46(0)70-349 92 51
http://www.sics.se

---

From: Paul Lambert <[email-masked]>
Date: Fri, 28 Feb 2014 00:30:51 -0800

> One thing that ACE could do is to define a small(!) set of useful elements of that vocabulary.
Yes!
I suggest a semantic framework of keys as ‘speakers’ (somewhat like SDSI/SPKI).  
Templates of speaker and associated statement format would be developed.
Basic statements to include assignment of attributes and the delegation of attribute assignment to a constrained range.

Paul

---

From: Paul Lambert <[email-masked]>
Date: Fri, 28 Feb 2014 09:38:04 -0800

On Feb 27, 2014, at 11:56 PM, Ludwig Seitz <[email-masked]> wrote:

> I'm pretty sure combining authN and authZ in one credential is _not_ a good idea.
I sort-of agree … the semantics of the signature are typically be different for the two usages.

> It might work in certain cases (i.e. when successful authentication implies full access without restrictions)

I disagree at this point.  This depends on the assumed authorization framework.  Authentication should never imply access or any specific capabiities.

Public keys are always the primary authentication reference and access control models are built on the attributes assigned to the key.

> but in most other cases it fails miserably (think revocation, changing access rights, anonymous access and so on).

In X.509 - yes.  

I’m not sure why we even have a notion of authN versus authZ certificates.  A signed statement by one key is basically assigning attributes to another key.   The attributes are used for access control decisions.  A more consistent model would just have arbitrary attributes bound to a key,

Paul