Re: [Cfrg] considering new topics for CFRG

Sean Turner <> Wed, 08 January 2014 04:52 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 5A3061AE2C6 for <>; Tue, 7 Jan 2014 20:52:09 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -0.967
X-Spam-Status: No, score=-0.967 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, IP_NOT_FRIENDLY=0.334, J_CHICKENPOX_31=0.6, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id feu5ELiXWOPm for <>; Tue, 7 Jan 2014 20:52:07 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id 041F71AE2C5 for <>; Tue, 7 Jan 2014 20:52:07 -0800 (PST)
Received: by (Postfix, from userid 5007) id E2738D125460; Tue, 7 Jan 2014 22:51:57 -0600 (CST)
Received: from ( []) by (Postfix) with ESMTP id C2B6BD12543C for <>; Tue, 7 Jan 2014 22:51:57 -0600 (CST)
Received: from [] (port=52523 helo=[]) by with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.80) (envelope-from <>) id 1W0l7U-0006c9-S2; Tue, 07 Jan 2014 22:51:57 -0600
Content-Type: multipart/signed; boundary="Apple-Mail=_23819215-C8B8-4DC8-9346-F8505BE9E9EB"; protocol="application/pkcs7-signature"; micalg="sha1"
Mime-Version: 1.0 (Mac OS X Mail 7.1 \(1827\))
From: Sean Turner <>
In-Reply-To: <>
Date: Tue, 07 Jan 2014 23:51:53 -0500
Message-Id: <>
References: <> <> <> <> <> <>
To: Max Pritikin <>
X-Mailer: Apple Mail (2.1827)
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname -
X-AntiAbuse: Original Domain -
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain -
X-BWhitelist: no
X-Source-Sender: ([]) []:52523
X-Email-Count: 1
X-Source-Cap: ZG9tbWdyNDg7ZG9tbWdyNDg7Z2F0b3IzMjg2Lmhvc3RnYXRvci5jb20=
Cc: David McGrew <>, "" <>
Subject: Re: [Cfrg] considering new topics for CFRG
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Crypto Forum Research Group <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 08 Jan 2014 04:52:09 -0000

On Jan 07, 2014, at 21:31, Max Pritikin (pritikin) <> wrote:

> With the advent of DICE (DTLS in Constrained Environments), and similar attempts to discuss optimizations, it would seem that any discussion of "next generation" PKI discussions should include discussion on how to optimize the X.509 certificate/chain format. That appears to be missing in this conversation so far.

Agreed but not sure the CFRG is the place to move the PKI' debates.

> I agree that any replacement for our current PKI is going to run into the same complexities. So, rather than assume they don't exist, would it be reasonable to look at how to optimize the existing work? 
> Some off the cuff examples to frame what I mean:
> - Define a specific lightweight trust anchor format (yes, we can all use X.509 certs. But what about a canonical smaller format?) 

There is the TAI in RFC 5914.

> - Optimized version of the X.509 cert itself:
> 	Perhaps a compressed format similar to the (old, abandoned and incomplete) draft for compressed certs?
> 	Perhaps a v4 format that is restructured to provide easier/quicker parsing

This was exactly what I was planning on doing with my free time after March ;) I was hoping to get some folks together that want to run an experiment doing just this but with a twist.  Note I was specifically targeting experimental and folks who actually wanted to produce open source encoders and parsers - no interest in a compiler.

I was thinking we should ditch the X.509 baggage completely and not bother with “v4".  ITU-T is still defining extensions and additions to X.509 and I’d rather not get in the whole argument about a “v4" squatting on their numbers.  And, the changes I think we should propose are pretty radical and it wouldn’t like anything like v3.  Further, many protocols support an “other” certificate format including TLS, SMIME, and IKE so there’s really no need to stick with the X.509 baggage including the name - I’d not even call it a Certificate - call it an IKC (IRTF Key Container - while we’re experimenting).

My short list:

1. Define another Name choice or just don’t use Name :)  It could be the following purposely avoiding anything to do with SETs:

IRTFName ::= SEQUENCE OF AttributeTypeAndValue

AttributeTypeAndValue ::= SEQUENCE {
   type     AttributeType,
   value    AttributeValue }

Name ::= CHOICE { -- only one possibility for now --
     rdnSequence  RDNSequence }

Or we add a new Name Choice:

Name ::= CHOICE {
 rdnSequence RDNSequence, — never to be used in this new format
 internetName InternetName }

InternetName ::= SEQUENCE OF AttributeTypeAndValue

AttributeTypeAndValue ::= SEQUENCE {
   type     AttributeType,
   value    AttributeValue }

and prohibit the rdnSequence choice

2. Character Sets: The battle is over UTC8 won - we should just use it and use it everywhere therefore DirectoryString essentially becomes:

DirectoryString ::= UTF8String (SIZE (1..MAX))

You can profile it down or define a new structure I guess I’d go for new and a clean break.

3. Drop everything related to X.400.

4. Time - just use GeneralizedTime.

5. drop issuer & subject unique identifier

6. Some extension ranting:

AKI - does anybody actually use anything other than the keyIdentifier choice.  If the consensus is to use the keyIdentifier drop the other two field.

KU - drop NR :)

Simplify wherever possible.

> 	Or if a non-ASN1 format is truly preferred then such a format could be defined that is can carry the same semantics as the existing PKI (namely, if the problem is ASN1 then we can fix that without also re-inventing all the rest) 

I hope to avoid the religious war because I think ASN.1 is just fine but *WOW* it could do with a good hair cut.  I was hoping we could do an ASN.1 profile for the IETF: iASN, ASN.l (l for light), or something like that and then do a quick survey of the RFCs we’ve defined and explicitly say they need not be supported.  A couple of things to experiment with:

1. Can we pick one rule with which to encode: KER (KISS Encoding Rules ;)

2. Could we get away with just primitive types for those that can now be either primitive or constructed?  E.g., do general purpose protocols need constructed bit/octet/character string encodings?

3. Can we do without indefinite length? 

4. Can we produce open source encoders/decoders to easy deployment?

5. Any reason we couldn't:

a. Use just two values for Boolean: 0x0 (false) and 0xff (true).

b. Can we do without: REAL, SET, SET OF, RELATIVE-OID, EMBEDDED PDV, EXTERNAL, CHARACTER STRING (Teletex, Videotext, Graphic, General, Universal, and finally BMP strings?), INSTANCE OF, and did I forget any?

6. Could we get away with just one tagging type (e.g., explicit so you might not have to guess so much)?

> Approaching the questions from this angle leads me to ask what _exactly_ the concerns with the current PKI are. Is it the ASN1, the CA infrastructure, the certificate chains, the cruft in each individual certificate, or? 
> Thanks,
> - max
> On Jan 6, 2014, at 3:39 PM, Stephen Farrell <> wrote:
>> On 01/06/2014 08:32 PM, Paul Lambert wrote:
>>>>> This is an intriguing thought, but probably something out of scope for
>>>>> CFRG.   (Seems more like a PKNG thing if I understand you right.)
>>> There was an IETF PKNG that died with no visible results. 
>> That was an IRTF RG. IMO it never had a cadre of researchers
>> nor a sufficient set of IETF participants who were interested
>> in a nextgen thing.
>>> This is an area where the IETF seems either too unfocused or mired
>>> in existing PKI to make progress.  Hence it's on my wish list ...
>>> Let me know if you have any suggestion for other viable forums in IETF
>>> for such a topic.
>> We have a list where we discussed certificate transparency but
>> which has a broader remit. [1] That's discussing whether or
>> not to start a new CT WG in the IETF at the moment.
>> There's the wpkops WG for operational issues related to the
>> web PKI. [2] They could do with help in terms of cycles to do
>> already-identified work (not hugely interesting for a
>> security/crypto researcher though probably).
>> The PKIX list [3] is still open, and would be a good place to
>> talk about any X.509-related PKI stuff. Not so good for non
>> X.509 based PKI though maybe unless for an approach that's
>> very much evolutionary and starts from X.509.
>> And there's the saag list [4] which is for general security
>> topics if none of the above fit.
>> So stuff is happening and there are places to discuss and
>> propose stuff. And Sean and I would be quite happy to try
>> help PKI nextgen stuff progress in the IETF should there
>> be credible proposals.
>> However, current PKI is not an easy thing to displace, no
>> matter how much you dislike parts or all of it. The main
>> reasons IMO are that replacements are likely to suffer a lot
>> of the same (or equivalent) complexity since its a complex
>> problem, and that any credible replacement will take at least
>> a few years to work out and them 5-10 to get deployed which
>> seems to be beyond the horizon for researchers (speaking as
>> one who chases funding;-). One could argue that that's why
>> of all the "large DB of public keys" approaches, only CT
>> seems to be left standing.
>> One other thing - listing the problems with the current PKI
>> is not likely to be a useful place to start. We know those,
>> and any credible approach would start with a fairly well
>> worked out proposal, including consideration of that 5-10
>> year overlap period. Its not easy;-)
>> Having said all that though, CT is I think a good proof of
>> concept that the large-DB-of-public-keys thing could be
>> a runner, and we have learned a lot about the wrinkles in
>> X.509 based PKI over the years so there is hope maybe.
>> S.
>> PS: For any of [1]-[4] please check the archives before
>> diving in, or ask someone who might be familiar, which
>> could include me.
>> [1]
>> [2]
>> [3]
>> [4]
>> _______________________________________________
>> Cfrg mailing list
> _______________________________________________
> Cfrg mailing list