[Trans] Fwd: Comments on RFC6962
Phillip Hallam-Baker <hallam@gmail.com> Mon, 10 March 2014 19:29 UTC
Return-Path: <hallam@gmail.com>
X-Original-To: trans@ietfa.amsl.com
Delivered-To: trans@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E2C4A1A064C for <trans@ietfa.amsl.com>; Mon, 10 Mar 2014 12:29:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level:
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eN5hZ48bLSJE for <trans@ietfa.amsl.com>; Mon, 10 Mar 2014 12:29:03 -0700 (PDT)
Received: from mail-la0-x22d.google.com (mail-la0-x22d.google.com [IPv6:2a00:1450:4010:c03::22d]) by ietfa.amsl.com (Postfix) with ESMTP id 3BBD01A02E6 for <trans@ietf.org>; Mon, 10 Mar 2014 12:29:03 -0700 (PDT)
Received: by mail-la0-f45.google.com with SMTP id hr17so5028090lab.32 for <trans@ietf.org>; Mon, 10 Mar 2014 12:28:57 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=CIEl4fK4z8PDilIGVdKtPWFGUpwmRwxuxgomhM3+Qhk=; b=mEnIoupUQ1LInp54uyZstQ03IDzZeVoHUBJFeYYqNfV516bq3dRw5GBPQ+TARwZrK8 r0X2goGMCDoQ/xYIoWJEaXqqBLYr+aivU+W4c5UE+SVJkJQMmuQS6vHlaq1/td1SMItg qPXDQHvvlj54HWHyF3ttRtvX7OLATXqOru3fRio05YmIfvlCY9z30EPs0pi8Aobie8cI 4QBxn36p0kcXE2tOeO9Y/dJ5CeSzJONKYG06co/2VvtubMRcSJHLHlqTyeQcwtIZ6xIT wkAIoOlNGfzhxNWA6mABZQTnhOUzo99ulLiQgR7O3DNB+XJY7Fx4GGu3Kd+dU4sldu0g f6JQ==
MIME-Version: 1.0
X-Received: by 10.112.128.170 with SMTP id np10mr23283252lbb.22.1394479737228; Mon, 10 Mar 2014 12:28:57 -0700 (PDT)
Received: by 10.112.37.168 with HTTP; Mon, 10 Mar 2014 12:28:57 -0700 (PDT)
In-Reply-To: <CAMm+LwiYZi=+dPFecO7GHQc5=-d=tWenkQ-igMJtfpq0PenN9w@mail.gmail.com>
References: <CAMm+LwiYZi=+dPFecO7GHQc5=-d=tWenkQ-igMJtfpq0PenN9w@mail.gmail.com>
Date: Mon, 10 Mar 2014 15:28:57 -0400
Message-ID: <CAMm+Lwge2hhQW4na7aZQen+1oZwBFVQFbEQS=9Qu+i6GErxSFg@mail.gmail.com>
From: Phillip Hallam-Baker <hallam@gmail.com>
To: "trans@ietf.org" <trans@ietf.org>
Content-Type: multipart/alternative; boundary="047d7b3a87666251b504f4459de8"
Archived-At: http://mailarchive.ietf.org/arch/msg/trans/5OuHbnZLKKZcgWqayM3BmIvw5KY
Subject: [Trans] Fwd: Comments on RFC6962
X-BeenThere: trans@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Public Notary Transparency working group discussion list <trans.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/trans>, <mailto:trans-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/trans/>
List-Post: <mailto:trans@ietf.org>
List-Help: <mailto:trans-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/trans>, <mailto:trans-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 10 Mar 2014 19:29:10 -0000
Sorry, gmail is behaving oddly today, it sent that message as I was typing. The second odd thing it has done today. I'll fix up that comment and put the rest in another message: I am currently working on entering RFC6962 into my protocol compiler. This has 'certain ideas' about regularity and conformance which is of course the point of the exercise. Some issues arising: [Page 17] extensions: An opaque type for future expansion. It is likely that not all participants will need to understand data in this field. Logs should set this to the empty string. Clients should decode the base64-encoded data and include it in the SCT. I have no idea why this would be needed. JSON allows any object to be extended with arbitrary additional tags. I have no idea how this would be used as well. There isn't a mechanism to tell the receiver what type of data to expect. If we did need to extend a message the way to do it would be to extend the object with a new tag. JSON rules require the tag be ignored. There is an open question on how to manage JSON extensibility. Some folk are proposing going the XML route and an equivalent of the xmlns tag. Reserved words are yucky and unnecessary though. If we want to use URIs as a mechanism for describing an extension we can do that by using the URI as a tag: If the original message looks something like: { "a" : 1, "b" : 2 } We can add a new tag for the FOO extension with unique identifier urn:iana:someregistry:FOO as follows: { "a" : 1, "b" : 2, "urn:iana:someregistry:FOO ": { ... new object or data item here ...} } This does not require us to do anything at the moment. It is a property of JSON we can use if needed. -- Website: http://hallambaker.com/
- [Trans] Comments on RFC6962 Phillip Hallam-Baker
- [Trans] Fwd: Comments on RFC6962 Phillip Hallam-Baker
- Re: [Trans] Comments on RFC6962 Bill Frantz
- Re: [Trans] Comments on RFC6962 Phillip Hallam-Baker
- Re: [Trans] Comments on RFC6962 Rob Stradling
- Re: [Trans] Comments on RFC6962 Bill Frantz
- Re: [Trans] Comments on RFC6962 Jon Callas