       SEQUENCE {

         SEQUENCE {

           OBJECT IDENTIFIER
          subjectKeyIdentifier (2 5 29 14)

           OCTET STRING, encapsulates {

             OCTET STRING

               08 68 AF 85 33 C8 39 4A 7A F8 82
          93 8E 70 6A 4A

               20 84 2C 32

             }

           }
_______________________________________________
Trans mailing list
Trans@ietf.org
https://www.ietf.org/mailman/listinfo/trans

       SEQUENCE {
&nbs=
p;        SEQUENCE {
 &=
nbsp;         OBJECT IDENTIFIER sub=
jectKeyIdentifier (2 5 29 14)
     &nb=
sp;     OCTET STRING, encapsulates {
 =
            OCTET ST=
RING
         &nbs=
p;     08 68 AF 85 33 C8 39 4A 7A F8 82 93 8E 70 6A 4A<=
/tt>
          &nb=
sp;    20 84 2C 32
     =
;        }
   =
;        }

RFC 59=
12 shows the extensions in the newer ASN.1 syntax.

Dave

On 03=
/28/2014 01:31 PM, Rick Andrews wrote:
In addition, our ASN.1 experts have asked for the sy=
ntax to be described in “ASN.1-like” syntax, as is used in RFCs=
 3280 and 5280.

For example, 3280/5280 defines an Extension like t=
his:
<=
span style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F=
497D'> 
Extension  ::=3D  SEQUENCE  {
  &nb=
sp;  extnID      OBJECT IDENTIFIER,
 &n=
bsp;   critical    BOOLEAN DEFAULT FALSE,
 &=
nbsp;   extnValue   OCTET STRING  }
 =

so t=
he extnValue is defined as an OCTET STRING, yet 6962 says “…enc=
oding the SignedCertificateTimestampList structure as an ASN.1 OCTET STRING=
 and inserting the resulting data in the TBSCertificate as an X.509v3 certi=
ficate extension…”. The ASN.1 folks say it’s not clear if=
 that means that the Extension contains the OCTET STRING data type (for ext=
nValue) and length followed by another OCTET STRING data type identifier an=
d length of the SCT. Or is the second OCTET STRING identifier redundant?
&=
nbsp;
=
Those updating existing cert generation code will probably be dealin=
g with ASN.1 compilers, so a precise definition of structures in ASN.1-like=
 syntax will go a long way. In addition, defining OIDs as arc plus extensio=
n (like this: id-kp-serverAuth  OBJECT IDENTIFIER ::=3D { id-kp 1 }) w=
ould help.

-Rick

From: Trans [mailto:trans-bounces@ietf.org] On Behalf Of Eran Messer=
i
Sent: Friday, March 14, 2014 3:01 AM
To: Phillip Hall=
am-Baker
Cc: Rob Stradling; tra=
ns@ietf.org
Subject: Re: [Trans] RFC6962 BIS Log file encodin=
gs.
&=
nbsp;
I=
 strongly support clarifying the description of the file format. When I sta=
rted implementing aspects of RFC6962 (with no background in TLS encoding or=
 ASN.1) it was very unclear.
From other posts on the list it =
seems this was unclear to others as well.

On Thu, Mar 13, 2014 at 10:50 PM, Phillip =
Hallam-Baker <hall=
am@gmail.com> wrote:
On Thu, Mar 13, 2014 at 4:20 PM, Rob St=
radling <r=
ob.stradling@comodo.com> wrote:
(Inspired by RFC5280 Appendix C)

Would it=
 help to include one or more example SCTs in the text?
<=
p class=3DMsoNormal style=3D'margin-left:1.0in'> =
I think we defi=
nitely need that for Proposed. But right now I am trying to see how complet=
e the description is. 

-- 
Website: http://hallambaker.com/<=
o:p>

__________=
_____________________________________
Trans mailing list
Trans@ietf.org
https://www.ietf.org/mailman/lis=
tinfo/trans

______=
_________________________________________
Trans mailing list
Trans@ietf.orghttps://www.ietf.org/mailman/listinfo/trans
 =

=

--_000_544B0DD62A64C1448B2DA253C011414607C85F3A8FTUS1XCHEVSPIN_--

From nobody Fri Mar 28 11:13:53 2014
Return-Path: 
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 00ABC1A06B8 for ; Fri, 28 Mar 2014 11:13:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.999
X-Spam-Level: 
X-Spam-Status: No, score=-0.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, J_BACKHAIR_52=1, SPF_PASS=-0.001] autolearn=no
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 h978Arr48l90 for ; Fri, 28 Mar 2014 11:13:48 -0700 (PDT)
Received: from mail-lb0-x235.google.com (mail-lb0-x235.google.com [IPv6:2a00:1450:4010:c04::235]) by ietfa.amsl.com (Postfix) with ESMTP id 1E57B1A0332 for ; Fri, 28 Mar 2014 11:13:47 -0700 (PDT)
Received: by mail-lb0-f181.google.com with SMTP id c11so3943934lbj.40 for ; Fri, 28 Mar 2014 11:13:44 -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 :cc:content-type; bh=3VWyZ1Dfm5yPNVu68YQVKDbCNhfi1Mn61ThsFqzYfBg=; b=cGUlPVZ51nb5OfNKruCsZKhlIgZL5qAT7uWNJ891FIl9/pdEir9eiPqIavjzqEc8pG 1MfhrG0LP/m3PAngskFxpowc5ygBH8hr5gonP13jYmxCGWe1GgiRmEenX8aSNQrbUk+s Z0XjihrGqEpDQ6GaHAkYqS3FTXiV0bCRmqYRH4fS9lX9/p9LwiUgCqbtWPY38t2+zUPa NLK0ORW0NHvnPnTCpZLM06mMDm/vtC0DUb5jddvOuDskYapyyEGLliotSR982rKVGMer KG9j6U9evth6dRS1+trGKbDNk1hP8Xa+9SVcqD8K6iIRd9ufOtHQzTSUAMJgN+wRL7Fx 31Xg==
MIME-Version: 1.0
X-Received: by 10.152.23.169 with SMTP id n9mr1165830laf.45.1396030424837; Fri, 28 Mar 2014 11:13:44 -0700 (PDT)
Received: by 10.112.234.229 with HTTP; Fri, 28 Mar 2014 11:13:44 -0700 (PDT)
In-Reply-To: <544B0DD62A64C1448B2DA253C011414607C85F39F4@TUS1XCHEVSPIN33.SYMC.SYMANTEC.COM>
References:  <5322131A.2080507@comodo.com>   <544B0DD62A64C1448B2DA253C011414607C85F39F4@TUS1XCHEVSPIN33.SYMC.SYMANTEC.COM>
Date: Fri, 28 Mar 2014 14:13:44 -0400
Message-ID: 
From: Phillip Hallam-Baker 
To: Rick Andrews 
Content-Type: multipart/alternative; boundary=089e0160b99a9176ee04f5aea9eb
Archived-At: http://mailarchive.ietf.org/arch/msg/trans/jKon9aerZxg86bz6A_ppjLGWnxw
Cc: Eran Messeri , "trans@ietf.org" , Rob Stradling 
Subject: Re: [Trans] RFC6962 BIS Log file encodings.
X-BeenThere: trans@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Public Notary Transparency working group discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 28 Mar 2014 18:13:51 -0000

--089e0160b99a9176ee04f5aea9eb
Content-Type: text/plain; charset=ISO-8859-1

The encoding isn't ASN.1 so using ASN.1 schema is a terrible idea.

Putting data in certificates does unfortunately lead to the risk of ASN.1.

One of the reasons I developed JSON-BCD was I could see this going to
happen and I would much prefer the JSON style approach over any further
investment in ASN.1.

On Fri, Mar 28, 2014 at 1:31 PM, Rick Andrews wrote:

> In addition, our ASN.1 experts have asked for the syntax to be described
> in "ASN.1-like" syntax, as is used in RFCs 3280 and 5280.
>
>
>
> For example, 3280/5280 defines an Extension like this:
>
>
>
> Extension  ::=  SEQUENCE  {
>
>      extnID      OBJECT IDENTIFIER,
>
>      critical    BOOLEAN DEFAULT FALSE,
>
>      extnValue   OCTET STRING  }
>
>
>
> so the extnValue is defined as an OCTET STRING, yet 6962 says "...encoding
> the SignedCertificateTimestampList structure as an ASN.1 OCTET STRING and
> inserting the resulting data in the TBSCertificate as an X.509v3
> certificate extension...". The ASN.1 folks say it's not clear if that means
> that the Extension contains the OCTET STRING data type (for extnValue) and
> length followed by another OCTET STRING data type identifier and length of
> the SCT. Or is the second OCTET STRING identifier redundant?
>
>
>
> Those updating existing cert generation code will probably be dealing with
> ASN.1 compilers, so a precise definition of structures in ASN.1-like syntax
> will go a long way. In addition, defining OIDs as arc plus extension (like
> this: id-kp-serverAuth  OBJECT IDENTIFIER ::= { id-kp 1 }) would help.
>
>
>
> -Rick
>
>
>
> *From:* Trans [mailto:trans-bounces@ietf.org ] *On
> Behalf Of *Eran Messeri
> *Sent:* Friday, March 14, 2014 3:01 AM
> *To:* Phillip Hallam-Baker
> *Cc:* Rob Stradling; trans@ietf.org
> *Subject:* Re: [Trans] RFC6962 BIS Log file encodings.
>
>
>
> I strongly support clarifying the description of the file format. When I
> started implementing aspects of RFC6962 (with no background in TLS encoding
> or ASN.1) it was very unclear.
>
> From other postson the list it seems this was unclear to others as well.
>
>
>
> On Thu, Mar 13, 2014 at 10:50 PM, Phillip Hallam-Baker 
> wrote:
>
> On Thu, Mar 13, 2014 at 4:20 PM, Rob Stradling 
> wrote:
>
> (Inspired by RFC5280 Appendix C)
>
> Would it help to include one or more example SCTs in the text?
>
>
>
> I think we definitely need that for Proposed. But right now I am trying to
> see how complete the description is.
>
>
>
> --
> Website: http://hallambaker.com/
>
>
> _______________________________________________
> Trans mailing list
> Trans@ietf.org
> https://www.ietf.org/mailman/listinfo/trans
>
>
>

-- 
Website: http://hallambaker.com/

--089e0160b99a9176ee04f5aea9eb
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

The encoding isn't ASN.1 so using ASN.1 schema is a te=
rrible idea.
Putting data in certificates does unfortuna=
tely lead to the risk of ASN.1.

One of the reasons=
 I developed JSON-BCD was I could see this going to happen and I would much=
 prefer the JSON style approach over any further investment in ASN.1.

On Fri, Mar 2=
8, 2014 at 1:31 PM, Rick Andrews <Rick_Andrews@symantec.com>=
; wrote:

In addition, =
our ASN.1 experts have asked for the syntax to be described in “ASN.1=
-like” syntax, as is used in RFCs 3280 and 5280.=

For example, 3280/5=
280 defines an Extension like this:

Extension  ::=
=3D  SEQUENCE  {
     =
extnID      OBJECT IDENTIFIER,
   &n=
bsp; critical    BOOLEAN DEFAULT FALSE,=

     =
extnValue   OCTET STRING  }

so the extnValue is defin=
ed as an OCTET STRING, yet 6962 says “…encoding the SignedCert=
ificateTimestampList structure as an ASN.1 OCTET STRING and inserting the r=
esulting data in the TBSCertificate as an X.509v3 certificate extension&hel=
lip;”. The ASN.1 folks say it’s not clear if that means that th=
e Extension contains the OCTET STRING data type (for extnValue) and length =
followed by another OCTET STRING data type identifier and length of the SCT=
. Or is the second OCTET STRING identifier redundant?<=
/p>

Those updating exis=
ting cert generation code will probably be dealing with ASN.1 compilers, so=
 a precise definition of structures in ASN.1-like syntax will go a long way=
. In addition, defining OIDs as arc plus extension (like this: id-kp-server=
Auth  OBJECT IDENTIFIER ::=3D { id-kp 1 }) would help.

-Rick=

From=
: Trans [mailto:trans-bounces@ietf.org] On Behalf Of Era=
n Messeri

Sent: Friday, March 14, 2014 3:01 AM
To: Phillip Hallam-Ba=
ker
Cc: Rob Stradling; trans@ietf.org
Subject: Re: [Trans] RFC6962 BIS L=
og file encodings.

I strongly support clarifying the description of the file format. When I =
started implementing aspects of RFC6962 (with no background in TLS encoding=
 or ASN.1) it was very unclear.
From other posts on the list it seems this was unclear to=
 others as well.

On Thu, Mar 13, 2014 at 10:50 PM, Phillip=
 Hallam-Baker <hal=
lam@gmail.com> wrote:
On Th=
u, Mar 13, 2014 at 4:20 PM, Rob Stradling <rob.stradling@comodo.com> wrote:=

(Inspired by RFC5280 Appe=
ndix C)

Would it help to include one or more example SCTs in the tex=
t?
=

I think =
we definitely need that for Proposed. But right now I am trying to see how =
complete the description is. 

-- 
Website: http://hallam=
baker.com/

______________________________________________=
_
Trans mailing list
Trans@ietf.org

h=
ttps://www.ietf.org/mailman/listinfo/trans
 =

-- 
=
Website: http://hallambaker.com/

--089e0160b99a9176ee04f5aea9eb--

From nobody Fri Mar 28 11:27:27 2014
Return-Path: 
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 B6BF61A0941 for ; Fri, 28 Mar 2014 11:27:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.91
X-Spam-Level: 
X-Spam-Status: No, score=-6.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 pk9RVgtpsbVn for ; Fri, 28 Mar 2014 11:27:21 -0700 (PDT)
Received: from tus1smtoutpex03.symantec.com (tus1smtoutpex03.symantec.com [216.10.195.243]) by ietfa.amsl.com (Postfix) with ESMTP id CFD6B1A094E for ; Fri, 28 Mar 2014 11:27:20 -0700 (PDT)
X-AuditID: d80ac3f3-b7f258e000006064-6c-5335bf06e73e
Received: from ecl1mtahubpin02.ges.symantec.com (ecl1mtahubpin02.ges.symantec.com [10.48.69.202]) by tus1smtoutpex03.symantec.com (Symantec Brightmail Gateway out) with SMTP id 0F.D0.24676.60FB5335; Fri, 28 Mar 2014 18:27:18 +0000 (GMT)
Received: from [155.64.220.139] (helo=TUS1XCHHUBPIN03.SYMC.SYMANTEC.COM) by ecl1mtahubpin02.ges.symantec.com with esmtp (Exim 4.76) (envelope-from ) id 1WTbUr-0008A6-UW; Fri, 28 Mar 2014 14:27:18 -0400
Received: from TUS1XCHEVSPIN33.SYMC.SYMANTEC.COM ([155.64.220.147]) by TUS1XCHHUBPIN03.SYMC.SYMANTEC.COM ([155.64.220.139]) with mapi; Fri, 28 Mar 2014 11:27:06 -0700
From: Rick Andrews 
To: Phillip Hallam-Baker 
Date: Fri, 28 Mar 2014 11:27:04 -0700
Thread-Topic: [Trans] RFC6962 BIS Log file encodings.
Thread-Index: Ac9KsXj0MD4tIBGmRdufjav8x8zLiAAAU+fQ
Message-ID: <544B0DD62A64C1448B2DA253C011414607C85F3B2D@TUS1XCHEVSPIN33.SYMC.SYMANTEC.COM>
References:  <5322131A.2080507@comodo.com>   <544B0DD62A64C1448B2DA253C011414607C85F39F4@TUS1XCHEVSPIN33.SYMC.SYMANTEC.COM> 
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
Content-Type: multipart/alternative; boundary="_000_544B0DD62A64C1448B2DA253C011414607C85F3B2DTUS1XCHEVSPIN_"
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrOIsWRmVeSWpSXmKPExsXCZeB6Spdtv2mwwfmF+hafv29ns7i6/DiT xaLGxawWax9fZHFg8bi0ZDajx85Zd9k9Fmwq9Viy5CdTAEsUl01Kak5mWWqRvl0CV8b+o31s Bas6GSue9x1gaWBcUd3FyMkhIWAi0Xn8OhuELSZx4d56IJuLQ0jgHaPExz1/WEASQgKvGCV6 FqpAJFYxShw6fIkVJMEmoCex5fEVdhBbREBb4ui+LWBxZoEiidkT7zCB2CwCqhLXVqwE2yAM tO3GjI9ANgdQvanEtU2cEK1GEkvPPwMr5xWIkuj+3A91xDRmiVcH34PVcwoESpydAraKEejQ 76fWMEGsEpe49WQ+E8QDAhJL9pxnhrBFJV4+/scKUS8qcad9PSNEfb7E7qeHmSF2CUqcnPmE ZQKj2Cwko2YhKZuFpAwiriOxYPcnNghbW2LZwtfMMPaZA4+ZkMUXMLKvYpQpKS02LM4tyS8t KUitMDDWK67MTQRGbrJecn7uJkZg9N7gOvx5B+PvPY6HGAU4GJV4eB23mgYLsSaWAVUeYpTg YFYS4b28FyjEm5JYWZValB9fVJqTWnyIUZqDRUmcN+SjYbCQQHpiSWp2ampBahFMlomDU6qB ceHeRxuDL/2Y+tNmUs1CZsZlc7ZyNPAEvbbIuJT+btWq1p2u3LO+S5X9/MCjYC9R+0rnAKck a4xsKO/q5iemDUGVVgcfCqiaf3wzQyeeofOj+8oyxiy3pG7tczPZBLhcNy/uqzj/tumKze6t TFm7t/gs9GSq9Sm6ePtmX8dRy72vf372WpgcrsRSnJFoqMVcVJwIADcHMgvaAgAA
Archived-At: http://mailarchive.ietf.org/arch/msg/trans/zKSJcHOFCqjuUHehf1JYHpqINaA
Cc: Eran Messeri , "trans@ietf.org" , Rob Stradling 
Subject: Re: [Trans] RFC6962 BIS Log file encodings.
X-BeenThere: trans@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Public Notary Transparency working group discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 28 Mar 2014 18:27:25 -0000

--_000_544B0DD62A64C1448B2DA253C011414607C85F3B2DTUS1XCHEVSPIN_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

I understand that there are problems with ASN.1 and many people don't like =
it, but if we're talking about X.509 certificates we have to use ASN.1. All=
 of our code for putting blobs into a cert work by defining the structure u=
sing ASN.1. Yes, we can add a blob that has some other encoding, but it's m=
ore difficult.

If the encoding were ASN.1, it might make adoption more straightforward.

-Rick

From: Phillip Hallam-Baker [mailto:hallam@gmail.com]
Sent: Friday, March 28, 2014 11:14 AM
To: Rick Andrews
Cc: Eran Messeri; Rob Stradling; trans@ietf.org
Subject: Re: [Trans] RFC6962 BIS Log file encodings.

The encoding isn't ASN.1 so using ASN.1 schema is a terrible idea.

Putting data in certificates does unfortunately lead to the risk of ASN.1.

One of the reasons I developed JSON-BCD was I could see this going to happe=
n and I would much prefer the JSON style approach over any further investme=
nt in ASN.1.

On Fri, Mar 28, 2014 at 1:31 PM, Rick Andrews > wrote:
In addition, our ASN.1 experts have asked for the syntax to be described in=
 "ASN.1-like" syntax, as is used in RFCs 3280 and 5280.

For example, 3280/5280 defines an Extension like this:

Extension  ::=3D  SEQUENCE  {
     extnID      OBJECT IDENTIFIER,
     critical    BOOLEAN DEFAULT FALSE,
     extnValue   OCTET STRING  }

so the extnValue is defined as an OCTET STRING, yet 6962 says "...encoding =
the SignedCertificateTimestampList structure as an ASN.1 OCTET STRING and i=
nserting the resulting data in the TBSCertificate as an X.509v3 certificate=
 extension...". The ASN.1 folks say it's not clear if that means that the E=
xtension contains the OCTET STRING data type (for extnValue) and length fol=
lowed by another OCTET STRING data type identifier and length of the SCT. O=
r is the second OCTET STRING identifier redundant?

Those updating existing cert generation code will probably be dealing with =
ASN.1 compilers, so a precise definition of structures in ASN.1-like syntax=
 will go a long way. In addition, defining OIDs as arc plus extension (like=
 this: id-kp-serverAuth  OBJECT IDENTIFIER ::=3D { id-kp 1 }) would help.

-Rick

From: Trans [mailto:trans-bounces@ietf.org] On Behalf Of Eran Messeri
Sent: Friday, March 14, 2014 3:01 AM
To: Phillip Hallam-Baker
Cc: Rob Stradling; trans@ietf.org
Subject: Re: [Trans] RFC6962 BIS Log file encodings.

I strongly support clarifying the description of the file format. When I st=
arted implementing aspects of RFC6962 (with no background in TLS encoding o=
r ASN.1) it was very unclear.
>From other posts on the list it seems this was unclear to others as well=
.

On Thu, Mar 13, 2014 at 10:50 PM, Phillip Hallam-Baker > wrote:
On Thu, Mar 13, 2014 at 4:20 PM, Rob Stradling > wrote:
(Inspired by RFC5280 Appendix C)

Would it help to include one or more example SCTs in the text?

I think we definitely need that for Proposed. But right now I am trying to =
see how complete the description is.

--
Website: http://hallambaker.com/

_______________________________________________
Trans mailing list
Trans@ietf.org
https://www.ietf.org/mailman/listinfo/trans

--
Website: http://hallambaker.com/

--_000_544B0DD62A64C1448B2DA253C011414607C85F3B2DTUS1XCHEVSPIN_
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

I underst=
and that there are problems with ASN.1 and many people don’t like it,=
 but if we’re talking about X.509 certificates we have to use ASN.1. =
All of our code for putting blobs into a cert work by defining the structur=
e using ASN.1. Yes, we can add a blob that has some other encoding, but it&=
#8217;s more difficult.

If the encoding were =
ASN.1, it might make adoption more straightforward.

=
-Rick

From:<=
span style=3D'font-size:10.0pt;font-family:"Tahoma","sans-serif"'> Phillip =
Hallam-Baker [mailto:hallam@gmail.com] 
Sent: Friday, March 28, 2=
014 11:14 AM
To: Rick Andrews
Cc: Eran Messeri; Rob Str=
adling; trans@ietf.org
Subject: Re: [Trans] RFC6962 BIS Log file =
encodings.

The encoding isn't ASN.1 so using ASN.1 schema is a terrible idea.=
 <=
/o:p>
Putting=
 data in certificates does unfortunately lead to the risk of ASN.1.
&nbs=
p;
One =
of the reasons I developed JSON-BCD was I could see this going to happen an=
d I would much prefer the JSON style approach over any further investment i=
n ASN.1.

On Fri, Mar 28, 2014 at 1:31 PM, Rick Andrews <Rick_Andrews@symantec.=
com> wrote:
I=
n addition, our ASN.1 experts have asked for the syntax to be described in =
“ASN.1-like” syntax, as is used in RFCs 3280 and 5280.

For example, 3280/5280 defines an Extension lik=
e this:

Extension  ::=3D  SEQ=
UENCE  {
 &nb=
sp;   extnID      OBJECT IDENTIFIER,
     c=
ritical    BOOLEAN DEFAULT FALSE,
     extnValue   OC=
TET STRING  }
&nbs=
p;
so the extnValue is =
defined as an OCTET STRING, yet 6962 says “…encoding the Signed=
CertificateTimestampList structure as an ASN.1 OCTET STRING and inserting t=
he resulting data in the TBSCertificate as an X.509v3 certificate extension=
…”. The ASN.1 folks say it’s not clear if that means that=
 the Extension contains the OCTET STRING data type (for extnValue) and leng=
th followed by another OCTET STRING data type identifier and length of the =
SCT. Or is the second OCTET STRING identifier redundant?<=
/p>

Those updating existing cert generation code will probabl=
y be dealing with ASN.1 compilers, so a precise definition of structures in=
 ASN.1-like syntax will go a long way. In addition, defining OIDs as arc pl=
us extension (like this: id-kp-serverAuth  OBJECT IDENTIFIER ::=3D { i=
d-kp 1 }) would help.
&=
nbsp;
-Rick=

From: Trans [mailto:trans-bounces@ietf.org] On Behalf Of Eran =
Messeri
Sent: Friday, March 14, 2014 3:01 AM
To: Philli=
p Hallam-Baker
Cc: Rob Stradling; trans@ietf.org
Subject: Re: [Trans] RFC6=
962 BIS Log file encodings.

I strongly supp=
ort clarifying the description of the file format. When I started implement=
ing aspects of RFC6962 (with no background in TLS encoding or ASN.1) it was=
 very unclear.
From other posts on the list it seems this was unclear =
to others as well.
 =
On Thu, Mar 13, 2014 at 10:50 =
PM, Phillip Hallam-Baker <hallam@gmail.com> wrote:
<=
p class=3DMsoNormal style=3D'mso-margin-top-alt:auto;mso-margin-bottom-alt:=
auto;margin-left:1.0in'>On Thu, Mar 13, 2014 at 4:20 PM, Rob Stradling <=
rob.stradling=
@comodo.com> wrote:
(Inspired=
 by RFC5280 Appendix C)

Would it help to include one or more example=
 SCTs in the text?
 <=
/o:p>
I think we definitely ne=
ed that for Proposed. But right now I am trying to see how complete the des=
cription is. 
=

-- 
Website: http://hallambaker.com/<=
o:p>

__________________________=
_____________________
Trans mailing list
Trans@ietf.org
https://www.ietf.org/mailman/l=
istinfo/trans
 <=
/o:p>

-- 
Website: http://hallambaker.com/<=
/div>=

--_000_544B0DD62A64C1448B2DA253C011414607C85F3B2DTUS1XCHEVSPIN_--

From nobody Fri Mar 28 11:32:31 2014
Return-Path: 
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 14EA81A095D for ; Fri, 28 Mar 2014 11:32:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.909
X-Spam-Level: 
X-Spam-Status: No, score=-1.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, T_RP_MATCHES_RCVD=-0.01] 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 pEprQIGTV3Ys for ; Fri, 28 Mar 2014 11:32:25 -0700 (PDT)
Received: from prod-mail-xrelay07.akamai.com (prod-mail-xrelay07.akamai.com [72.246.2.115]) by ietfa.amsl.com (Postfix) with ESMTP id DCAC41A0959 for ; Fri, 28 Mar 2014 11:32:24 -0700 (PDT)
Received: from prod-mail-xrelay07.akamai.com (localhost.localdomain [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id 90518476BA; Fri, 28 Mar 2014 18:32:20 +0000 (GMT)
Received: from prod-mail-relay07.akamai.com (unknown [172.17.121.112]) by prod-mail-xrelay07.akamai.com (Postfix) with ESMTP id 5E800476A9; Fri, 28 Mar 2014 18:32:20 +0000 (GMT)
Received: from usma1ex-cashub.kendall.corp.akamai.com (usma1ex-cashub7.kendall.corp.akamai.com [172.27.105.23]) by prod-mail-relay07.akamai.com (Postfix) with ESMTP id 481178003C; Fri, 28 Mar 2014 18:32:20 +0000 (GMT)
Received: from USMBX1.msg.corp.akamai.com ([172.27.107.26]) by usma1ex-cashub7.kendall.corp.akamai.com ([172.27.105.23]) with mapi; Fri, 28 Mar 2014 14:32:19 -0400
From: "Salz, Rich" 
To: Rick Andrews , Phillip Hallam-Baker 
Date: Fri, 28 Mar 2014 14:32:18 -0400
Thread-Topic: [Trans] RFC6962 BIS Log file encodings.
Thread-Index: Ac9KsXj0MD4tIBGmRdufjav8x8zLiAAAU+fQAABLfHA=
Message-ID: <2A0EFB9C05D0164E98F19BB0AF3708C711FD4AEA05@USMBX1.msg.corp.akamai.com>
References:  <5322131A.2080507@comodo.com>   <544B0DD62A64C1448B2DA253C011414607C85F39F4@TUS1XCHEVSPIN33.SYMC.SYMANTEC.COM>  <544B0DD62A64C1448B2DA253C011414607C85F3B2D@TUS1XCHEVSPIN33.SYMC.SYMANTEC.COM>
In-Reply-To: <544B0DD62A64C1448B2DA253C011414607C85F3B2D@TUS1XCHEVSPIN33.SYMC.SYMANTEC.COM>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
Content-Type: multipart/alternative; boundary="_000_2A0EFB9C05D0164E98F19BB0AF3708C711FD4AEA05USMBX1msgcorp_"
MIME-Version: 1.0
Archived-At: http://mailarchive.ietf.org/arch/msg/trans/U53BV5Uiqz4xd20xR-eP8I8wJ7M
Cc: Eran Messeri , "trans@ietf.org" , Rob Stradling 
Subject: Re: [Trans] RFC6962 BIS Log file encodings.
X-BeenThere: trans@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Public Notary Transparency working group discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 28 Mar 2014 18:32:27 -0000

--_000_2A0EFB9C05D0164E98F19BB0AF3708C711FD4AEA05USMBX1msgcorp_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

=D8  I understand that there are problems with ASN.1 and many people don't =
like it, but if we're talking about X.509 certificates we have to use ASN.1=
. All of our code for putting blobs into a cert work by defining the struct=
ure using ASN.1. Yes, we can add a blob that has some other encoding, but i=
t's more difficult.

=D8  If the encoding were ASN.1, it might make adoption more straightforwar=
d.

+1

--
Principal Security Engineer
Akamai Technology
Cambridge, MA

--_000_2A0EFB9C05D0164E98F19BB0AF3708C711FD4AEA05USMBX1msgcorp_
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

=D8  I understand that there are problems with=
 ASN.1 and many people don’t like it, but if we’re talking abou=
t X.509 certificates we have to use ASN.1. All of our code for putting blob=
s into a cert work by defining the structure using ASN.1. Yes, we can add a=
 blob that has some other encoding, but it’s more difficult.

=
=D8  If the enc=
oding were ASN.1, it might make adoption more straightforward.

+1

--=A0 
Principal Security Engineer
Akamai Technology
Cambridge, MA
 =

--_000_2A0EFB9C05D0164E98F19BB0AF3708C711FD4AEA05USMBX1msgcorp_--

From nobody Fri Mar 28 11:48:01 2014
Return-Path: 
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 948161A0941 for ; Fri, 28 Mar 2014 11:48:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.999
X-Spam-Level: 
X-Spam-Status: No, score=-0.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, J_BACKHAIR_52=1, SPF_PASS=-0.001] autolearn=no
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 wc0IBpII7CPx for ; Fri, 28 Mar 2014 11:47:58 -0700 (PDT)
Received: from mail-ve0-x230.google.com (mail-ve0-x230.google.com [IPv6:2607:f8b0:400c:c01::230]) by ietfa.amsl.com (Postfix) with ESMTP id 0785E1A01DB for ; Fri, 28 Mar 2014 11:47:57 -0700 (PDT)
Received: by mail-ve0-f176.google.com with SMTP id db11so2976812veb.35 for ; Fri, 28 Mar 2014 11:47:55 -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 :cc:content-type; bh=rNZ6Pf0uzNfYUyoELOqUFsg+bF102zdwyg6RjPUF5Qc=; b=ZVDAOACjb7JQ6ty425VdF/zLLhA9iF69sgppMOWPgGxaM1MZn6hh83PCrjS7x8s4bM WOLAIHjHsB9H4XKPMCmaaAkD1ZbiOODcUu/cCylCXIF5HboaFRa6JuOI3buYLVKtBDiq TSY7bWjIht3KQPYsMqbzPLE567fWCflngmU/7JfyM1Dw9pxfynbGrZUb6tttJi1dFn36 Oc8eg/sdChpotTXV6TDe+p2XOHo9bEQCB7Np/w5gqKyV6b/UNseiPFR9FX/9CkhRy8qy aGZLHr+/ERFoP2RufBYv8Ym9pNy0bCtojElvbELdxmc6AcYmq8HJoW4r4rrtR6QPWueS YUVw==
MIME-Version: 1.0
X-Received: by 10.58.201.5 with SMTP id jw5mr8226724vec.6.1396032475567; Fri, 28 Mar 2014 11:47:55 -0700 (PDT)
Received: by 10.52.142.103 with HTTP; Fri, 28 Mar 2014 11:47:55 -0700 (PDT)
Received: by 10.52.142.103 with HTTP; Fri, 28 Mar 2014 11:47:55 -0700 (PDT)
In-Reply-To: 
References:  <5322131A.2080507@comodo.com>   <544B0DD62A64C1448B2DA253C011414607C85F39F4@TUS1XCHEVSPIN33.SYMC.SYMANTEC.COM> 
Date: Fri, 28 Mar 2014 19:47:55 +0100
Message-ID: 
From: Erwann Abalea 
To: Phillip Hallam-Baker 
Content-Type: multipart/alternative; boundary=047d7bd6aea2cd1ef204f5af237f
Archived-At: http://mailarchive.ietf.org/arch/msg/trans/ppz-74KB68yLvbupMMcDpWITwGY
Cc: Rob Stradling , "trans@ietf.org" , Rick Andrews , Eran Messeri 
Subject: Re: [Trans] RFC6962 BIS Log file encodings.
X-BeenThere: trans@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Public Notary Transparency working group discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 28 Mar 2014 18:48:00 -0000

--047d7bd6aea2cd1ef204f5af237f
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

I don't see the problem with ASN.1.
Can't you propose a JSON Encoding Rule standard?
Le 28 mars 2014 19:13, "Phillip Hallam-Baker"  a =C3=A9cr=
it :

> The encoding isn't ASN.1 so using ASN.1 schema is a terrible idea.
>
> Putting data in certificates does unfortunately lead to the risk of ASN.1=
.
>
> One of the reasons I developed JSON-BCD was I could see this going to
> happen and I would much prefer the JSON style approach over any further
> investment in ASN.1.
>
>
>
> On Fri, Mar 28, 2014 at 1:31 PM, Rick Andrews =
wrote:
>
>> In addition, our ASN.1 experts have asked for the syntax to be described
>> in =E2=80=9CASN.1-like=E2=80=9D syntax, as is used in RFCs 3280 and 5280=
.
>>
>>
>>
>> For example, 3280/5280 defines an Extension like this:
>>
>>
>>
>> Extension  ::=3D  SEQUENCE  {
>>
>>      extnID      OBJECT IDENTIFIER,
>>
>>      critical    BOOLEAN DEFAULT FALSE,
>>
>>      extnValue   OCTET STRING  }
>>
>>
>>
>> so the extnValue is defined as an OCTET STRING, yet 6962 says =E2=80=9C=
=E2=80=A6encoding
>> the SignedCertificateTimestampList structure as an ASN.1 OCTET STRING an=
d
>> inserting the resulting data in the TBSCertificate as an X.509v3
>> certificate extension=E2=80=A6=E2=80=9D. The ASN.1 folks say it=E2=80=99=
s not clear if that means
>> that the Extension contains the OCTET STRING data type (for extnValue) a=
nd
>> length followed by another OCTET STRING data type identifier and length =
of
>> the SCT. Or is the second OCTET STRING identifier redundant?
>>
>>
>>
>> Those updating existing cert generation code will probably be dealing
>> with ASN.1 compilers, so a precise definition of structures in ASN.1-lik=
e
>> syntax will go a long way. In addition, defining OIDs as arc plus extens=
ion
>> (like this: id-kp-serverAuth  OBJECT IDENTIFIER ::=3D { id-kp 1 }) would=
 help.
>>
>>
>>
>> -Rick
>>
>>
>>
>> *From:* Trans [mailto:trans-bounces@ietf.org ] *=
On
>> Behalf Of *Eran Messeri
>> *Sent:* Friday, March 14, 2014 3:01 AM
>> *To:* Phillip Hallam-Baker
>> *Cc:* Rob Stradling; trans@ietf.org
>> *Subject:* Re: [Trans] RFC6962 BIS Log file encodings.
>>
>>
>>
>> I strongly support clarifying the description of the file format. When I
>> started implementing aspects of RFC6962 (with no background in TLS encod=
ing
>> or ASN.1) it was very unclear.
>>
>> From other postson the list it seems this was unclear to others as we=
ll.
>>
>>
>>
>> On Thu, Mar 13, 2014 at 10:50 PM, Phillip Hallam-Baker 
>> wrote:
>>
>> On Thu, Mar 13, 2014 at 4:20 PM, Rob Stradling 
>> wrote:
>>
>> (Inspired by RFC5280 Appendix C)
>>
>> Would it help to include one or more example SCTs in the text?
>>
>>
>>
>> I think we definitely need that for Proposed. But right now I am trying
>> to see how complete the description is.
>>
>>
>>
>> --
>> Website: http://hallambaker.com/
>>
>>
>> _______________________________________________
>> Trans mailing list
>> Trans@ietf.org
>> https://www.ietf.org/mailman/listinfo/trans
>>
>>
>>
>
>
>
> --
> Website: http://hallambaker.com/
>
> _______________________________________________
> Trans mailing list
> Trans@ietf.org
> https://www.ietf.org/mailman/listinfo/trans
>
>

--047d7bd6aea2cd1ef204f5af237f
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

I don't see the problem with ASN.1.

Can't you propose a JSON Encoding Rule standard?
Le 28 mars 2014 19:13, "Phillip Hallam-Bake=
r" <hallam@gmail.com> a =
=C3=A9crit :

The encoding isn't ASN.1 so using ASN.1 schema is a te=
rrible idea.
Putting data in certificates does unfortuna=
tely lead to the risk of ASN.1.

One of the reasons=
 I developed JSON-BCD was I could see this going to happen and I would much=
 prefer the JSON style approach over any further investment in ASN.1.

On Fri, Mar 2=
8, 2014 at 1:31 PM, Rick Andrews <Rick_Andrews@symantec.com>=
; wrote:

In addition, =
our ASN.1 experts have asked for the syntax to be described in =E2=80=9CASN=
.1-like=E2=80=9D syntax, as is used in RFCs 3280 and 5280.

=C2=A0
For example, 3280/5=
280 defines an Extension like this:

=C2=A0
Extension=C2=A0 ::=
=3D=C2=A0 SEQUENCE=C2=A0 {

=C2=A0=C2=A0=C2=A0=C2=A0 =
extnID=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 OBJECT IDENTIFIER,
=C2=A0=C2=A0=C2=A0=
=C2=A0 critical=C2=A0=C2=A0=C2=A0 BOOLEAN DEFAULT FALSE,

=C2=A0=C2=A0=C2=A0=C2=A0 =
extnValue=C2=A0=C2=A0 OCTET STRING=C2=A0 }
=C2=A0

so the extnValue is defin=
ed as an OCTET STRING, yet 6962 says =E2=80=9C=E2=80=A6encoding the SignedC=
ertificateTimestampList structure as an ASN.1 OCTET STRING and inserting th=
e resulting data in the TBSCertificate as an X.509v3 certificate extension=
=E2=80=A6=E2=80=9D. The ASN.1 folks say it=E2=80=99s not clear if that mean=
s that the Extension contains the OCTET STRING data type (for extnValue) an=
d length followed by another OCTET STRING data type identifier and length o=
f the SCT. Or is the second OCTET STRING identifier redundant?

=C2=A0
Those updating exis=
ting cert generation code will probably be dealing with ASN.1 compilers, so=
 a precise definition of structures in ASN.1-like syntax will go a long way=
. In addition, defining OIDs as arc plus extension (like this: id-kp-server=
Auth=C2=A0 OBJECT IDENTIFIER ::=3D { id-kp 1 }) would help.

=C2=A0
-Rick=

=C2=A0
From=
: Trans [mailto:trans-bounces@ietf.org] On Behalf Of Era=
n Messeri

Sent: Friday, March 14, 2014 3:01 AM
To: Phillip Hallam-Ba=
ker
Cc: Rob Stradling; trans@ietf.org
Subject: Re: [Trans] RFC6962 BIS L=
og file encodings.

=C2=A0
I strongly =
support clarifying the description of the file format. When I started imple=
menting aspects of RFC6962 (with no background in TLS encoding or ASN.1) it=
 was very unclear.

From other posts on the list it seems this was unclear to=
 others as well.

=C2=A0
On Thu, Mar 13, 2014 at 10:50 PM, Phillip=
 Hallam-Baker <hal=
lam@gmail.com> wrote:

On Th=
u, Mar 13, 2014 at 4:20 PM, Rob Stradling <rob.stradling@comodo.com> wrote:=

(Inspired by RFC5280 Appe=
ndix C)

Would it help to include one or more example SCTs in the tex=
t?
=
=C2=A0

I think =
we definitely need that for Proposed. But right now I am trying to see how =
complete the description is.=C2=A0

=C2=A0
-- 
Website: http://hallam=
baker.com/

______________________________________________=
_
Trans mailing list
Trans@ietf.org

h=
ttps://www.ietf.org/mailman/listinfo/trans
=C2=A0=

-- 
=
Website: http://halla=
mbaker.com/

_______________________________________________

Trans mailing list

Trans@ietf.org

h=
ttps://www.ietf.org/mailman/listinfo/trans

--047d7bd6aea2cd1ef204f5af237f--

From nobody Fri Mar 28 20:25:03 2014
Return-Path: 
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 DAD0A1A0431 for ; Fri, 28 Mar 2014 20:25:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.878
X-Spam-Level: 
X-Spam-Status: No, score=-2.878 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, GB_I_LETTER=-2, SPF_PASS=-0.001, URI_HEX=1.122] 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 cQG_xC2peBi7 for ; Fri, 28 Mar 2014 20:24:59 -0700 (PDT)
Received: from mail-pb0-x233.google.com (mail-pb0-x233.google.com [IPv6:2607:f8b0:400e:c01::233]) by ietfa.amsl.com (Postfix) with ESMTP id 666711A0425 for ; Fri, 28 Mar 2014 20:24:59 -0700 (PDT)
Received: by mail-pb0-f51.google.com with SMTP id uo5so5823124pbc.38 for ; Fri, 28 Mar 2014 20:24: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 :cc:content-type:content-transfer-encoding; bh=/adu8iOng5wA4Bl2qu6EnL64r/pW7G37CKCJPNgEXNU=; b=a9jM0R5iWq8iPrngVa15vlQcUazLoF4+4gL6qMQGmN6oJ+LuUch8bUNjcrgpMvJTzM SwiGDJuoyCzpto913jPcg6z5ge6m+cXxyntLUtSvQtWLe9HHM8G92sUdzCioAprP+HJ2 vD1tIRr9uitMPEKVV2dqtH53ixzSvkPRAr50fIwOoTncyBq2yPw/w1hJDJpIzC2YXfxm d5VcPoETdpRyIJHRVDXaFEfe7CRS9wWWe7LXr2TFryhdefGstrMFn/83kiR5I1MhJACo CexkuIUL/N9QLG8Lp7ynWsOdgFMpsGuEKll1XW5IvJGHqyxEbX4SWM7VG7z5azt8gCth oQmA==
MIME-Version: 1.0
X-Received: by 10.69.19.203 with SMTP id gw11mr12427126pbd.40.1396063497202; Fri, 28 Mar 2014 20:24:57 -0700 (PDT)
Received: by 10.70.131.16 with HTTP; Fri, 28 Mar 2014 20:24:57 -0700 (PDT)
In-Reply-To: <544B0DD62A64C1448B2DA253C011414607C85F3902@TUS1XCHEVSPIN33.SYMC.SYMANTEC.COM>
References: <544B0DD62A64C1448B2DA253C011414607C85F3902@TUS1XCHEVSPIN33.SYMC.SYMANTEC.COM>
Date: Fri, 28 Mar 2014 20:24:57 -0700
Message-ID: 
From: Peter Bowen 
To: Rick Andrews 
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Archived-At: http://mailarchive.ietf.org/arch/msg/trans/pbooERCZ9hAn8GmVVkWLKaDzq9Y
Cc: "Rob Stradling \(rob.stradling@comodo.com\)" , "trans@ietf.org" 
Subject: Re: [Trans] Angle brackets in the PRIVATE option (Ticket #1)
X-BeenThere: trans@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Public Notary Transparency working group discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 29 Mar 2014 03:25:01 -0000

On Fri, Mar 28, 2014 at 9:46 AM, Rick Andrews  w=
rote:
> We see another potential issue with the proposed PRIVATE option. Rob=E2=
=80=99s
> current proposal would have us replace a domain label with the literal
> string =E2=80=9C=E2=80=9D (without the quotes). However, we try =
to encode DN
> components as PrintableString where possible, and angle brackets are not
> part of the PrintableString set (the lowercase letters 'a' through 'z',
> uppercase letters 'A' through 'Z', the digits '0' through '9', eleven
> special characters ' =3D ( ) + , - . / : ? and space).
>
> As a result, the type of the DN component would be PrintableString in the
> real cert but utf8String in the pre-certificate, and that would cause
> problems. I suggest using parentheses instead of angle brackets.

Instead of having "", what about replacing the redacted
string with a prefixed checksum of the part?

Assuming we specify CRC-32 with "+" as the prefix,
"mail.corp.example.com" would become "+6f993bb2.example.com".  This
could also allow redacting only some labels:
"mail.secret.example.gov.xx" could become
"mail.+734313b7.example.gov.xx".  This has the benefit of providing
privacy while allowing stronger matching of the certificate.

Thanks,
Peter

From nobody Sat Mar 29 15:49:55 2014
Return-Path: 
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 3E68C1A0809 for ; Sat, 29 Mar 2014 15:49:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.8
X-Spam-Level: 
X-Spam-Status: No, score=0.8 tagged_above=-999 required=5 tests=[BAYES_50=0.8,  RCVD_IN_DNSWL_NONE=-0.0001] 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 i4jJqNygr_Gf for ; Sat, 29 Mar 2014 15:49:52 -0700 (PDT)
Received: from elasmtp-junco.atl.sa.earthlink.net (elasmtp-junco.atl.sa.earthlink.net [209.86.89.63]) by ietfa.amsl.com (Postfix) with ESMTP id D1D5C1A07FC for ; Sat, 29 Mar 2014 15:49:52 -0700 (PDT)
Received: from [174.240.36.91] (helo=Williams-MacBook-Pro.local) by elasmtp-junco.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1WU24R-0007zz-MD; Sat, 29 Mar 2014 17:49:48 -0500
Date: Sat, 29 Mar 2014 15:49:10 -0700
From: Bill Frantz 
To: Erwann Abalea 
X-Priority: 3
In-Reply-To: 
Message-ID: 
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: quoted-printable
X-Mailer: Mailsmith 2.3.1 (422)
X-ELNK-Trace: 3a5e54fa03f1b3e21aa676d7e74259b7b3291a7d08dfec79be8b242ff013a55c12a16257472c9942350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c
X-Originating-IP: 174.240.36.91
Archived-At: http://mailarchive.ietf.org/arch/msg/trans/4tktcnuWIbWPV57XopVHMprerPU
Cc: trans@ietf.org, Rob Stradling , Phillip Hallam-Baker , Rick Andrews , Eran Messeri 
Subject: Re: [Trans] RFC6962 BIS Log file encodings.
X-BeenThere: trans@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Public Notary Transparency working group discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 29 Mar 2014 22:49:54 -0000

On 3/28/14 at 11:47 AM, eabalea@gmail.com (Erwann Abalea) wrote:

>I don't see the problem with ASN.1.

IMHO, the problem with ASN.1 is that it is too complex. There=20
exists a history of attacks on computer security by sending=20
malformed ASN.1 irritating bugs in ASN.1 encoders. In addition,=20
the ability to specify "infinite" length data has caused buffer overruns.

ASN.1 fans my say that these bugs have all been fixed, and they=20
may be right if no new ASN.1 interpreters are written.

However, complexity is always a bad thing in a security=20
protocol. Make it only as complex as necessary, and no more complex.

Cheers - Bill

---------------------------------------------------------------------------
Bill Frantz        |"We used to quip that "password" is the most common
408-356-8506       | password. Now it's 'password1.' Who said=20
users haven't
www.pwpconsult.com | learned anything about security?" -- Bruce Schneier

From nobody Sat Mar 29 16:21:24 2014
Return-Path: 
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 CD59F1A07FF for ; Sat, 29 Mar 2014 16:21:22 -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 gqPSvPTvN_GB for ; Sat, 29 Mar 2014 16:21:21 -0700 (PDT)
Received: from mail-ve0-x234.google.com (mail-ve0-x234.google.com [IPv6:2607:f8b0:400c:c01::234]) by ietfa.amsl.com (Postfix) with ESMTP id DBA921A06B9 for ; Sat, 29 Mar 2014 16:21:20 -0700 (PDT)
Received: by mail-ve0-f180.google.com with SMTP id jz11so6896472veb.25 for ; Sat, 29 Mar 2014 16:21:18 -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 :cc:content-type; bh=LGHSG0vaZvvHL3yZQFcZtWwy2xYM31phyFCb3O5M4hk=; b=jXmf6EN+ZlHn5q1wq4PD7RjTyOe9UaHO6Gf0W9uYohIW2UFb8l/gPebpOuawxYeOxB RFPw8WGo2N+m4CrVuW6eN9+vRGrSk9gdx1scSckznr6i2H7YAGU8ykQaDKJRYyIeeUXQ l6U/NikXFspu/fdl46fphEDzMmVHFtOPkQgBia/YluC5CwOrxSvjfl7BJNE0zHCvxljz r5myIfx5O8+Ku3oAHobjV1hK++Hn0IveuLe3sOaA0ZHkkhyBCioYuvMSdhUxbnAp7JJp Bla03qe+JvXdbUYDGuwD8wdMTeEfwwMFi6Kb/TZgLEtzTbR5B8ippaE+uWXJAsCzuAqR kK+A==
MIME-Version: 1.0
X-Received: by 10.221.29.137 with SMTP id ry9mr14877936vcb.6.1396135278101; Sat, 29 Mar 2014 16:21:18 -0700 (PDT)
Received: by 10.52.142.103 with HTTP; Sat, 29 Mar 2014 16:21:18 -0700 (PDT)
In-Reply-To: 
References:  
Date: Sun, 30 Mar 2014 00:21:18 +0100
Message-ID: 
From: Erwann Abalea 
To: Bill Frantz 
Content-Type: multipart/alternative; boundary=001a1133935c4f766404f5c71351
Archived-At: http://mailarchive.ietf.org/arch/msg/trans/Sk4VP5aRlYmzg7y37BxxzALRZ08
Cc: "trans@ietf.org" , Rob Stradling , Phillip Hallam-Baker , Rick Andrews , Eran Messeri 
Subject: Re: [Trans] RFC6962 BIS Log file encodings.
X-BeenThere: trans@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Public Notary Transparency working group discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 29 Mar 2014 23:21:23 -0000

--001a1133935c4f766404f5c71351
Content-Type: text/plain; charset=UTF-8

2014-03-29 23:49 GMT+01:00 Bill Frantz :

> On 3/28/14 at 11:47 AM, eabalea@gmail.com (Erwann Abalea) wrote:
>
>  I don't see the problem with ASN.1.
>>
>
> IMHO, the problem with ASN.1 is that it is too complex. There exists a
> history of attacks on computer security by sending malformed ASN.1
> irritating bugs in ASN.1 encoders. In addition, the ability to specify
> "infinite" length data has caused buffer overruns.
>

ASN.1 isn't a stream of bytes. It's only a language used to describe a
structure, and it needs some encoding rule to serialize data transmitted on
the wire. Use another encoding rule, and you'll have a different bit/byte
representation.
The mentioned bugs (infinite length) are to be found on some BER/DER
encoders, and similar ones can be found on XML parsers, MS Word files
loaders, and many others.
If a certificate is encoded using XER and an XML parser is hit by a bug,
can the fault be attributed to ASN.1, the language used to describe a
certificate? If the same format is described with another language while
keeping the same binary representation, will it make the bug disappear?

Data structures defined in RFC6962 can be described in ASN.1 as well, and
encoded using PER (that's not common), and it will be binary compatible
with what is proposed. Will it introduce new bugs because of ASN.1?

-- 
Erwann.

--001a1133935c4f766404f5c71351
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

=
2014-03-29 23:49 GMT+01:00 Bill Frantz <frantz@pwpconsult.com><=
/span>:

On 3/28/14 at 11:47 AM, eabalea@gmail.com (E=
rwann Abalea) wrote:

I don't see the problem with ASN.1.

IMHO, the problem with ASN.1 is that it is too complex. There exists a hist=
ory of attacks on computer security by sending malformed ASN.1 irritating b=
ugs in ASN.1 encoders. In addition, the ability to specify "infinite&q=
uot; length data has caused buffer overruns.

ASN.1 isn't a stream of bytes. It'=
s only a language used to describe a structure, and it needs some encoding =
rule to serialize data transmitted on the wire. Use another encoding rule, =
and you'll have a different bit/byte representation.
The mentioned bugs (infinite length) are to be found on some BER/DER e=
ncoders, and similar ones can be found on XML parsers, MS Word files loader=
s, and many others.
If a certificate is encoded using XER and an =
XML parser is hit by a bug, can the fault be attributed to ASN.1, the langu=
age used to describe a certificate? If the same format is described with an=
other language while keeping the same binary representation, will it make t=
he bug disappear?

Data structures defined in RFC6962 can be described in =
ASN.1 as well, and encoded using PER (that's not common), and it will b=
e binary compatible with what is proposed. Will it introduce new bugs becau=
se of ASN.1?

-- 
Erwann.

--001a1133935c4f766404f5c71351--

From nobody Sat Mar 29 18:55:57 2014
Return-Path: 
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 393921A040E for ; Sat, 29 Mar 2014 18:55:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001] 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 OeMaUMUpTw5m for ; Sat, 29 Mar 2014 18:55:54 -0700 (PDT)
Received: from elasmtp-mealy.atl.sa.earthlink.net (elasmtp-mealy.atl.sa.earthlink.net [209.86.89.69]) by ietfa.amsl.com (Postfix) with ESMTP id 7555F1A0416 for ; Sat, 29 Mar 2014 18:55:54 -0700 (PDT)
Received: from [174.240.13.187] (helo=Williams-MacBook-Pro.local) by elasmtp-mealy.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1WU4yU-0004u6-0e; Sat, 29 Mar 2014 21:55:50 -0400
Date: Sat, 29 Mar 2014 18:55:13 -0700
From: Bill Frantz 
To: Erwann Abalea 
X-Priority: 3
In-Reply-To: 
Message-ID: 
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: quoted-printable
X-Mailer: Mailsmith 2.3.1 (422)
X-ELNK-Trace: 3a5e54fa03f1b3e21aa676d7e74259b7b3291a7d08dfec79ebaf39519cb3038010bd134b84cc41bb350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c
X-Originating-IP: 174.240.13.187
Archived-At: http://mailarchive.ietf.org/arch/msg/trans/bGxcfLRxhUoI0IBhw5pZp6HN28g
Cc: Phillip Hallam-Baker , Rob Stradling , trans@ietf.org, Rick Andrews , Eran Messeri 
Subject: Re: [Trans] RFC6962 BIS Log file encodings.
X-BeenThere: trans@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Public Notary Transparency working group discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sun, 30 Mar 2014 01:55:56 -0000

On 3/30/14 at 4:21 PM, eabalea@gmail.com (Erwann Abalea) wrote:

>2014-03-29 23:49 GMT+01:00 Bill Frantz :
>
>>On 3/28/14 at 11:47 AM, eabalea@gmail.com (Erwann Abalea) wrote:
>>
>>I don't see the problem with ASN.1.
>>>
>>
>>IMHO, the problem with ASN.1 is that it is too complex. There exists a
>>history of attacks on computer security by sending malformed ASN.1
>>irritating bugs in ASN.1 encoders. In addition, the ability to specify
>>"infinite" length data has caused buffer overruns.
>>
>
>ASN.1 isn't a stream of bytes. It's only a language used to describe a
>structure, and it needs some encoding rule to serialize data transmitted o=
n
>the wire. Use another encoding rule, and you'll have a different bit/byte
>representation.
>The mentioned bugs (infinite length) are to be found on some BER/DER
>encoders, and similar ones can be found on XML parsers, MS Word files
>loaders, and many others.
>If a certificate is encoded using XER and an XML parser is hit by a bug,
>can the fault be attributed to ASN.1, the language used to describe a
>certificate? If the same format is described with another language while
>keeping the same binary representation, will it make the bug disappear?

Yes, part of the problem is at the description level. The=20
description language is too general. If I describe a data=20
structure as: a 16 bit length field followed by the bytes of the=20
data, then I can't have any data longer than 64K bytes. It is=20
easy to allocate a buffer that is long enough.

The disadvantage of this form of description is that we may need=20
to expand to data longer than 64K, needing a new description.

Cheers - Bill

-----------------------------------------------------------------------
Bill Frantz        | Privacy is dead, get over    | Periwinkle
(408)356-8506      | it.                          | 16345=20
Englewood Ave
www.pwpconsult.com |              - Scott McNealy | Los Gatos,=20
CA 95032

From nobody Mon Mar 31 01:21:45 2014
Return-Path: 
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 547EA1A0980 for ; Mon, 31 Mar 2014 01:21:42 -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 MgXBrDMoM6hK for ; Mon, 31 Mar 2014 01:21:39 -0700 (PDT)
Received: from mail-yh0-x229.google.com (mail-yh0-x229.google.com [IPv6:2607:f8b0:4002:c01::229]) by ietfa.amsl.com (Postfix) with ESMTP id 9F4BC1A077D for ; Mon, 31 Mar 2014 01:21:39 -0700 (PDT)
Received: by mail-yh0-f41.google.com with SMTP id v1so7321896yhn.28 for ; Mon, 31 Mar 2014 01:21:36 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=mime-version:date:message-id:subject:from:to:content-type; bh=mssIbD7OmDfQydQDqwNyneSjUUa8I3ZVTTwO+iNZ6Es=; b=jfWpAEaLX9WgWKs/E43+cq9P5x1hAvvLOUUc84/rFuTiSdUmiUivQPvOoKlNBaYmH1 qlVfTpiECM5fqqIXosu22HLyCezD8rjlCtR8xBLO8oVmcYuco+4cU5i6+IQLrboqEC0h v5vouwdLs1BKmhCshQhm37LlddLd2k8iMrJYL8bxrUyR538YFvctaW4J7Xrc7RzVu05q +mPjmpz+lrgi8spaQ9xc8VYf+6URyQO9n/X94w02dNl09/wfGHK7p/CE7Wgwb5vuwYph Lkh9Gv2a3cFRTWZdSipGchUwKlWKtd2he1hhZQxQ5P1oxz0oNBD9pZ66M6G2kxnUbsv1 52dw==
MIME-Version: 1.0
X-Received: by 10.236.115.198 with SMTP id e46mr33435671yhh.24.1396254096498;  Mon, 31 Mar 2014 01:21:36 -0700 (PDT)
Received: by 10.170.220.193 with HTTP; Mon, 31 Mar 2014 01:21:36 -0700 (PDT)
Date: Mon, 31 Mar 2014 12:21:36 +0400
Message-ID: 
From: Dmitry Belyavsky 
To: trans@ietf.org
Content-Type: multipart/alternative; boundary=20cf303b41cd70601d04f5e2bdfd
Archived-At: http://mailarchive.ietf.org/arch/msg/trans/n7js1PW5AXillCbstuyVKpSg9fM
Subject: Re: [Trans] Fwd: Certificate Transparency with Russian GOST algorithms
X-BeenThere: trans@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Public Notary Transparency working group discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 31 Mar 2014 08:21:42 -0000

--20cf303b41cd70601d04f5e2bdfd
Content-Type: text/plain; charset=UTF-8

Dear Ben,

Sorry for my late response.

18.03.2014 18:20, Ben Laurie wrote:

On 11 March 2014 18:36, Melinda Shore
wrote:

For some reason Dmitry's mail is not arriving at the
IETF server, so I thought I would forward it myself.

Melinda

-------- Original Message --------
Subject: Certificate Transparency with Russian GOST algorithms
Date: Tue, 11 Mar 2014 22:16:47 +0400
From: Dmitry Belyavsky  
To: trans@ietf.org
CC: melinda.shore@gmail.com

Hi all!

Here are some thoughts about using CT in Russia with Russian
cryptographic algorithms (GOST). They were discussed with Ben Laurie
during the IETF meeting in London. I am not sure which mailing list is
the right place to post to, so I post it to the WG mailing list.

Laws and practice in Russia requires using of the GOST hash and digital
signature in X.509 certificates for government services. These
certificates are signed by Russians CAs which are not in lists of
trusted CAs in major browsers. It is not a problem to create an
installation of log server in Russia containing the list of Russian CAs.
But Russia-based service should use the GOST hash algorithm in the
Merkle tree and GOST signature algorithm for signing SCT. It seems to be
not a problem because if GOST-based certificates are submitted to
GOST-based log, browsers not understanding the GOST algorithms will not
have to verify GOST-based SCTs. But also it means that the hashing
algorithm of Merkle tree should become the config-time parameter of the
log instance instead of being hardcoded. Also it should be possible to
find out which algorithm is used in this or that log instance and it
should be strictly prohibited to change this algorithm after start of
the log instance. It seems to be a good idea anyway because of the
requirements of cryptographic algorithms agility.

As I mentioned elsewhere, in our view you change algorithm by starting
a new log.

Ok. What about a way to find out the algorithm in use?

The hash/signing algorithms are fixed properties of the log.

It seems to me there shouldn't be any difficulty accommodating GOST
like this - I guess we'd have to add the rule that non-GOST
certificates MUST NOT use GOST logs. Not sure whether we should
require the opposite, though (i.e. GOST certificates MUST NOT use
EC/SHA logs)?

What is expected to be a right behaviour in case when a certificate has SCT
from some different log servers, if some of the SCT signatures can't be
verified? If they are to be just ignored, I'm not sure we need such a
limitation.

-- 
SY, Dmitry Belyavsky

--20cf303b41cd70601d04f5e2bdfd
Content-Type: text/html; charset=UTF-8

Dear Ben,

Sorry for my late response.

18.03.2014 18:20, Ben Laurie wrote:

On 11 March 2014 18:36, Melinda Shore <melinda.shore@gmail.com> wrote:

For some reason Dmitry's mail is not arriving at the

IETF server, so I thought I would forward it myself.

Melinda

-------- Original Message --------

Subject: Certificate Transparency with Russian GOST algorithms

Date: Tue, 11 Mar 2014 22:16:47 +0400

From: Dmitry Belyavsky <beldmit@tcinet.ru>

To: trans@ietf.org

CC: melinda.shore@gmail.com

Hi all!

Here are some thoughts about using CT in Russia with Russian

cryptographic algorithms (GOST). They were discussed with Ben Laurie

during the IETF meeting in London. I am not sure which mailing list is

the right place to post to, so I post it to the WG mailing list.

Laws and practice in Russia requires using of the GOST hash and digital

signature in X.509 certificates for government services. These

certificates are signed by Russians CAs which are not in lists of

trusted CAs in major browsers. It is not a problem to create an

installation of log server in Russia containing the list of Russian CAs.

But Russia-based service should use the GOST hash algorithm in the

Merkle tree and GOST signature algorithm for signing SCT. It seems to be

not a problem because if GOST-based certificates are submitted to

GOST-based log, browsers not understanding the GOST algorithms will not

have to verify GOST-based SCTs. But also it means that the hashing

algorithm of Merkle tree should become the config-time parameter of the

log instance instead of being hardcoded. Also it should be possible to

find out which algorithm is used in this or that log instance and it

should be strictly prohibited to change this algorithm after start of

the log instance. It seems to be a good idea anyway because of the

requirements of cryptographic algorithms agility.

As I mentioned elsewhere, in our view you change algorithm by starting

a new log.

Ok. What about a way to find out the algorithm in use?

The hash/signing algorithms are fixed properties of the log.

It seems to me there shouldn't be any difficulty accommodating GOST

like this - I guess we'd have to add the rule that non-GOST

certificates MUST NOT use GOST logs. Not sure whether we should

require the opposite, though (i.e. GOST certificates MUST NOT use

EC/SHA logs)?

What is expected to be a right behaviour in case when a certificate has 
SCT from some different log servers, if some of the SCT signatures can't 
be verified? If they are to be just ignored, I'm not sure we need such a 
limitation.

-- 
SY, Dmitry Belyavsky

--20cf303b41cd70601d04f5e2bdfd--

From nobody Mon Mar 31 02:32:29 2014
Return-Path: 
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 3478B1A0843 for ; Mon, 31 Mar 2014 02:32:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.29
X-Spam-Level: 
X-Spam-Status: No, score=-1.29 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_MISMATCH_NET=0.611, SPF_PASS=-0.001] autolearn=no
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 DOTlEP30S_Gg for ; Mon, 31 Mar 2014 02:32:23 -0700 (PDT)
Received: from ian.brad.office.comodo.net (eth5.brad-fw.brad.office.ccanet.co.uk [178.255.87.226]) by ietfa.amsl.com (Postfix) with ESMTP id 0A3131A07A1 for ; Mon, 31 Mar 2014 02:32:22 -0700 (PDT)
Received: (qmail 25196 invoked by uid 1000); 31 Mar 2014 09:32:18 -0000
Received: from nigel.brad.office.comodo.net (HELO [192.168.0.58]) (192.168.0.58) (smtp-auth username rob, mechanism plain) by ian.brad.office.comodo.net (qpsmtpd/0.40) with (AES128-SHA encrypted) ESMTPSA; Mon, 31 Mar 2014 10:32:18 +0100
Message-ID: <53393621.30901@comodo.com>
Date: Mon, 31 Mar 2014 10:32:17 +0100
From: Rob Stradling 
User-Agent: Mozilla/5.0 (X11; Linux i686; rv:24.0) Gecko/20100101 Thunderbird/24.4.0
MIME-Version: 1.0
To: Rick Andrews ,  "David A. Cooper" 
References:  <5322131A.2080507@comodo.com>   <544B0DD62A64C1448B2DA253C011414607C85F39F4@TUS1XCHEVSPIN33.SYMC.SYMANTEC.COM> <5335B76C.4050303@nist.gov> <544B0DD62A64C1448B2DA253C011414607C85F3A8F@TUS1XCHEVSPIN33.SYMC.SYMANTEC.COM>
In-Reply-To: <544B0DD62A64C1448B2DA253C011414607C85F3A8F@TUS1XCHEVSPIN33.SYMC.SYMANTEC.COM>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 8bit
Archived-At: http://mailarchive.ietf.org/arch/msg/trans/o5XBHrK6AmX3JdMELQD6FcElmxI
Cc: "trans@ietf.org" 
Subject: Re: [Trans] RFC6962 BIS Log file encodings.
X-BeenThere: trans@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Public Notary Transparency working group discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 31 Mar 2014 09:32:27 -0000

Hi Rick.  Dave's analysis is correct.  6962, interpreted in the light of 
X.509/5280, is unambiguous.  That said, I think we could make life 
easier for implementers by improving the text in RFC6962-bis.

We should certainly add at least one example of an encoded SCTList 
extension.

On 28/03/14 18:00, Rick Andrews wrote:
> Thanks, Dave, I�ll forward this on. But are you saying that the
> descriptions in 6962 are precise enough? Would you have any objections
> to defining structures in 6962 using the same syntax as 5280?
>
> -Rick
>
> *From:*David A. Cooper [mailto:david.cooper@nist.gov]
> *Sent:* Friday, March 28, 2014 10:55 AM
> *To:* Rick Andrews
> *Cc:* trans@ietf.org
> *Subject:* Re: [Trans] RFC6962 BIS Log file encodings.
>
> Rick,
>
> I haven't read RFC 6962 in detail, but the ASN.1 experts you spoke with
> may not be familiar with the definition of Extension in certificates.
> X.509 defines it as:
>
> *   Extension ::= SEQUENCE {
>              extnId EXTENSION.&id ({ExtensionSet}),
>              critical BOOLEAN DEFAULT FALSE,
>              extnValue OCTET STRING
>     (CONTAINING EXTENSION.&ExtnType({ExtensionSet}{@extnId})
>                                                      ENCODED BY der)}
>
>     der OBJECT IDENTIFIER ::= {joint-iso-itu-t asn1(1) ber-derived(2)
> distinguished-encoding(1)}
> *
> In RFC 5280 it is:
> *   Extension  ::=  SEQUENCE  {
>          extnID      OBJECT IDENTIFIER,
>          critical    BOOLEAN DEFAULT FALSE,
>          extnValue   OCTET STRING
>                      -- contains the DER encoding of an ASN.1 value
>                      -- corresponding to the extension type identified
>                      -- by extnID
>          }*
>
> It is my understanding that the two definitions are based on different
> versions of ASN.1, but are considered to be equivalent. The important
> point is that both indicate that the extension value must contain the
> DER encoding of some ASN.1 value. So, the only way to interpret the RFC
> 6962 text in a manner that is consistent with X.509 is that the
> extnValue contains the tag for OCTET STRING followed by a length then a
> second OCTET STRING tag and a second length and then the (non-ASN.1)
> encoded SignedCertificateTimestampList structure. Given that the
> SignedCertificateTimestampList structure is not ASN.1, and so it cannot
> be DER encoded, this seems the only reasonable way to include it in a
> certificate.
>
> This is similar to the subjectKeyIdentifier extension. The
> subjectKeyIdentifier just contains a string of bits, such as the SHA-1
> hash of the subject public key. It is defined in RFC 5280 as follows:
>
> *     KeyIdentifier ::= OCTET STRING
>
>       -- subject key identifier OID and syntax
>
>       id-ce-subjectKeyIdentifier OBJECT IDENTIFIER ::=  { id-ce 14 }
>
>       SubjectKeyIdentifier ::= KeyIdentifier*
>
> and here is an example of an encoded subjectKeyIdentifier extension:
> *SEQUENCE {**
>           SEQUENCE {
>             OBJECT IDENTIFIER subjectKeyIdentifier (2 5 29 14)
>             OCTET STRING, encapsulates {
>               OCTET STRING
>                 08 68 AF 85 33 C8 39 4A 7A F8 82 93 8E 70 6A 4A
>                 20 84 2C 32
>               }
>             }*
>
> RFC 5912 shows the extensions in the newer ASN.1 syntax.
>
> Dave
>
> On 03/28/2014 01:31 PM, Rick Andrews wrote:
>
>     In addition, our ASN.1 experts have asked for the syntax to be
>     described in �ASN.1-like� syntax, as is used in RFCs 3280 and 5280.
>
>     For example, 3280/5280 defines an Extension like this:
>
>     Extension  ::=  SEQUENCE  {
>
>           extnID      OBJECT IDENTIFIER,
>
>           critical    BOOLEAN DEFAULT FALSE,
>
>           extnValue   OCTET STRING  }
>
>     so the extnValue is defined as an OCTET STRING, yet 6962 says
>     ��encoding the SignedCertificateTimestampList structure as an ASN.1
>     OCTET STRING and inserting the resulting data in the TBSCertificate
>     as an X.509v3 certificate extension��. The ASN.1 folks say it�s not
>     clear if that means that the Extension contains the OCTET STRING
>     data type (for extnValue) and length followed by another OCTET
>     STRING data type identifier and length of the SCT. Or is the second
>     OCTET STRING identifier redundant?
>
>     Those updating existing cert generation code will probably be
>     dealing with ASN.1 compilers, so a precise definition of structures
>     in ASN.1-like syntax will go a long way. In addition, defining OIDs
>     as arc plus extension (like this: id-kp-serverAuth  OBJECT
>     IDENTIFIER ::= { id-kp 1 }) would help.
>
>     -Rick
>
>     *From:*Trans [mailto:trans-bounces@ietf.org] *On Behalf Of *Eran Messeri
>     *Sent:* Friday, March 14, 2014 3:01 AM
>     *To:* Phillip Hallam-Baker
>     *Cc:* Rob Stradling; trans@ietf.org 
>     *Subject:* Re: [Trans] RFC6962 BIS Log file encodings.
>
>     I strongly support clarifying the description of the file format.
>     When I started implementing aspects of RFC6962 (with no background
>     in TLS encoding or ASN.1) it was very unclear.
>
>      From other posts
>     
>     on the list it seems this was unclear to others as well.
>
>     On Thu, Mar 13, 2014 at 10:50 PM, Phillip Hallam-Baker
>     > wrote:
>
>     On Thu, Mar 13, 2014 at 4:20 PM, Rob Stradling
>     > wrote:
>
>     (Inspired by RFC5280 Appendix C)
>
>     Would it help to include one or more example SCTs in the text?
>
>     I think we definitely need that for Proposed. But right now I am
>     trying to see how complete the description is.
>
>     --
>     Website: http://hallambaker.com/
>
>
>     _______________________________________________
>     Trans mailing list
>     Trans@ietf.org 
>     https://www.ietf.org/mailman/listinfo/trans
>
>
>
>
>     _______________________________________________
>
>     Trans mailing list
>
>     Trans@ietf.org  
>
>     https://www.ietf.org/mailman/listinfo/trans
>
>
>
> _______________________________________________
> Trans mailing list
> Trans@ietf.org
> https://www.ietf.org/mailman/listinfo/trans
>

-- 
Rob Stradling
Senior Research & Development Scientist
COMODO - Creating Trust Online
Office Tel: +44.(0)1274.730505
Office Fax: +44.(0)1274.730909
www.comodo.com

COMODO CA Limited, Registered in England No. 04058690
Registered Office:
   3rd Floor, 26 Office Village, Exchange Quay,
   Trafford Road, Salford, Manchester M5 3EQ

This e-mail and any files transmitted with it are confidential and 
intended solely for the use of the individual or entity to whom they are 
addressed.  If you have received this email in error please notify the 
sender by replying to the e-mail containing this attachment. Replies to 
this email may be monitored by COMODO for operational or business 
reasons. Whilst every endeavour is taken to ensure that e-mails are free 
from viruses, no liability can be accepted and the recipient is 
requested to use their own virus checking software.

From nobody Mon Mar 31 02:54:05 2014
Return-Path: 
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 72F1C1A0844 for ; Mon, 31 Mar 2014 02:54:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.29
X-Spam-Level: 
X-Spam-Status: No, score=-1.29 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_MISMATCH_NET=0.611, SPF_PASS=-0.001] autolearn=no
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 Skhuz0TNwwrW for ; Mon, 31 Mar 2014 02:54:00 -0700 (PDT)
Received: from ian.brad.office.comodo.net (eth5.brad-fw.brad.office.ccanet.co.uk [178.255.87.226]) by ietfa.amsl.com (Postfix) with ESMTP id 1993B1A0820 for ; Mon, 31 Mar 2014 02:53:59 -0700 (PDT)
Received: (qmail 17106 invoked by uid 1000); 31 Mar 2014 09:53:56 -0000
Received: from nigel.brad.office.comodo.net (HELO [192.168.0.58]) (192.168.0.58) (smtp-auth username rob, mechanism plain) by ian.brad.office.comodo.net (qpsmtpd/0.40) with (AES128-SHA encrypted) ESMTPSA; Mon, 31 Mar 2014 10:53:56 +0100
Message-ID: <53393B33.7050106@comodo.com>
Date: Mon, 31 Mar 2014 10:53:55 +0100
From: Rob Stradling 
User-Agent: Mozilla/5.0 (X11; Linux i686; rv:24.0) Gecko/20100101 Thunderbird/24.4.0
MIME-Version: 1.0
To: Rick Andrews ,  "David A. Cooper" 
References:  <5322131A.2080507@comodo.com>   <544B0DD62A64C1448B2DA253C011414607C85F39F4@TUS1XCHEVSPIN33.SYMC.SYMANTEC.COM> <5335B76C.4050303@nist.gov> <544B0DD62A64C1448B2DA253C011414607C85F3A8F@TUS1XCHEVSPIN33.SYMC.SYMANTEC.COM> <53393621.30901@comodo.com>
In-Reply-To: <53393621.30901@comodo.com>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 8bit
Archived-At: http://mailarchive.ietf.org/arch/msg/trans/WfXT_kIyR6RMq1LeM3fn5Cl_ltw
Cc: "trans@ietf.org" 
Subject: Re: [Trans] RFC6962 BIS Log file encodings.
X-BeenThere: trans@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Public Notary Transparency working group discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 31 Mar 2014 09:54:03 -0000

On 31/03/14 10:32, Rob Stradling wrote:
> Hi Rick.  Dave's analysis is correct.  6962, interpreted in the light of
> X.509/5280, is unambiguous.  That said, I think we could make life
> easier for implementers by improving the text in RFC6962-bis.
>
> We should certainly add at least one example of an encoded SCTList
> extension.

http://trac.tools.ietf.org/wg/trans/trac/ticket/14

> On 28/03/14 18:00, Rick Andrews wrote:
>> Thanks, Dave, I�ll forward this on. But are you saying that the
>> descriptions in 6962 are precise enough? Would you have any objections
>> to defining structures in 6962 using the same syntax as 5280?
>>
>> -Rick
>>
>> *From:*David A. Cooper [mailto:david.cooper@nist.gov]
>> *Sent:* Friday, March 28, 2014 10:55 AM
>> *To:* Rick Andrews
>> *Cc:* trans@ietf.org
>> *Subject:* Re: [Trans] RFC6962 BIS Log file encodings.
>>
>> Rick,
>>
>> I haven't read RFC 6962 in detail, but the ASN.1 experts you spoke with
>> may not be familiar with the definition of Extension in certificates.
>> X.509 defines it as:
>>
>> *   Extension ::= SEQUENCE {
>>              extnId EXTENSION.&id ({ExtensionSet}),
>>              critical BOOLEAN DEFAULT FALSE,
>>              extnValue OCTET STRING
>>     (CONTAINING EXTENSION.&ExtnType({ExtensionSet}{@extnId})
>>                                                      ENCODED BY der)}
>>
>>     der OBJECT IDENTIFIER ::= {joint-iso-itu-t asn1(1) ber-derived(2)
>> distinguished-encoding(1)}
>> *
>> In RFC 5280 it is:
>> *   Extension  ::=  SEQUENCE  {
>>          extnID      OBJECT IDENTIFIER,
>>          critical    BOOLEAN DEFAULT FALSE,
>>          extnValue   OCTET STRING
>>                      -- contains the DER encoding of an ASN.1 value
>>                      -- corresponding to the extension type identified
>>                      -- by extnID
>>          }*
>>
>> It is my understanding that the two definitions are based on different
>> versions of ASN.1, but are considered to be equivalent. The important
>> point is that both indicate that the extension value must contain the
>> DER encoding of some ASN.1 value. So, the only way to interpret the RFC
>> 6962 text in a manner that is consistent with X.509 is that the
>> extnValue contains the tag for OCTET STRING followed by a length then a
>> second OCTET STRING tag and a second length and then the (non-ASN.1)
>> encoded SignedCertificateTimestampList structure. Given that the
>> SignedCertificateTimestampList structure is not ASN.1, and so it cannot
>> be DER encoded, this seems the only reasonable way to include it in a
>> certificate.
>>
>> This is similar to the subjectKeyIdentifier extension. The
>> subjectKeyIdentifier just contains a string of bits, such as the SHA-1
>> hash of the subject public key. It is defined in RFC 5280 as follows:
>>
>> *     KeyIdentifier ::= OCTET STRING
>>
>>       -- subject key identifier OID and syntax
>>
>>       id-ce-subjectKeyIdentifier OBJECT IDENTIFIER ::=  { id-ce 14 }
>>
>>       SubjectKeyIdentifier ::= KeyIdentifier*
>>
>> and here is an example of an encoded subjectKeyIdentifier extension:
>> *SEQUENCE {**
>>           SEQUENCE {
>>             OBJECT IDENTIFIER subjectKeyIdentifier (2 5 29 14)
>>             OCTET STRING, encapsulates {
>>               OCTET STRING
>>                 08 68 AF 85 33 C8 39 4A 7A F8 82 93 8E 70 6A 4A
>>                 20 84 2C 32
>>               }
>>             }*
>>
>> RFC 5912 shows the extensions in the newer ASN.1 syntax.
>>
>> Dave
>>
>> On 03/28/2014 01:31 PM, Rick Andrews wrote:
>>
>>     In addition, our ASN.1 experts have asked for the syntax to be
>>     described in �ASN.1-like� syntax, as is used in RFCs 3280 and 5280.
>>
>>     For example, 3280/5280 defines an Extension like this:
>>
>>     Extension  ::=  SEQUENCE  {
>>
>>           extnID      OBJECT IDENTIFIER,
>>
>>           critical    BOOLEAN DEFAULT FALSE,
>>
>>           extnValue   OCTET STRING  }
>>
>>     so the extnValue is defined as an OCTET STRING, yet 6962 says
>>     ��encoding the SignedCertificateTimestampList structure as an ASN.1
>>     OCTET STRING and inserting the resulting data in the TBSCertificate
>>     as an X.509v3 certificate extension��. The ASN.1 folks say it�s not
>>     clear if that means that the Extension contains the OCTET STRING
>>     data type (for extnValue) and length followed by another OCTET
>>     STRING data type identifier and length of the SCT. Or is the second
>>     OCTET STRING identifier redundant?
>>
>>     Those updating existing cert generation code will probably be
>>     dealing with ASN.1 compilers, so a precise definition of structures
>>     in ASN.1-like syntax will go a long way. In addition, defining OIDs
>>     as arc plus extension (like this: id-kp-serverAuth  OBJECT
>>     IDENTIFIER ::= { id-kp 1 }) would help.
>>
>>     -Rick
>>
>>     *From:*Trans [mailto:trans-bounces@ietf.org] *On Behalf Of *Eran
>> Messeri
>>     *Sent:* Friday, March 14, 2014 3:01 AM
>>     *To:* Phillip Hallam-Baker
>>     *Cc:* Rob Stradling; trans@ietf.org 
>>     *Subject:* Re: [Trans] RFC6962 BIS Log file encodings.
>>
>>     I strongly support clarifying the description of the file format.
>>     When I started implementing aspects of RFC6962 (with no background
>>     in TLS encoding or ASN.1) it was very unclear.
>>
>>      From other posts
>>
>> 
>>
>>     on the list it seems this was unclear to others as well.
>>
>>     On Thu, Mar 13, 2014 at 10:50 PM, Phillip Hallam-Baker
>>     > wrote:
>>
>>     On Thu, Mar 13, 2014 at 4:20 PM, Rob Stradling
>>     > wrote:
>>
>>     (Inspired by RFC5280 Appendix C)
>>
>>     Would it help to include one or more example SCTs in the text?
>>
>>     I think we definitely need that for Proposed. But right now I am
>>     trying to see how complete the description is.
>>
>>     --
>>     Website: http://hallambaker.com/
>>
>>
>>     _______________________________________________
>>     Trans mailing list
>>     Trans@ietf.org 
>>     https://www.ietf.org/mailman/listinfo/trans
>>
>>
>>
>>
>>     _______________________________________________
>>
>>     Trans mailing list
>>
>>     Trans@ietf.org  
>>
>>     https://www.ietf.org/mailman/listinfo/trans
>>
>>
>>
>> _______________________________________________
>> Trans mailing list
>> Trans@ietf.org
>> https://www.ietf.org/mailman/listinfo/trans
>>
>

-- 
Rob Stradling
Senior Research & Development Scientist
COMODO - Creating Trust Online
Office Tel: +44.(0)1274.730505
Office Fax: +44.(0)1274.730909
www.comodo.com

COMODO CA Limited, Registered in England No. 04058690
Registered Office:
   3rd Floor, 26 Office Village, Exchange Quay,
   Trafford Road, Salford, Manchester M5 3EQ

This e-mail and any files transmitted with it are confidential and 
intended solely for the use of the individual or entity to whom they are 
addressed.  If you have received this email in error please notify the 
sender by replying to the e-mail containing this attachment. Replies to 
this email may be monitored by COMODO for operational or business 
reasons. Whilst every endeavour is taken to ensure that e-mails are free 
from viruses, no liability can be accepted and the recipient is 
requested to use their own virus checking software.

From nobody Mon Mar 31 02:57:07 2014
Return-Path: 
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 07E411A0844 for ; Mon, 31 Mar 2014 02:57:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.391
X-Spam-Level: 
X-Spam-Status: No, score=-1.391 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, GB_I_LETTER=-2, HELO_MISMATCH_NET=0.611, 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 nPw2MYmo_W_S for ; Mon, 31 Mar 2014 02:57:05 -0700 (PDT)
Received: from ian.brad.office.comodo.net (eth5.brad-fw.brad.office.ccanet.co.uk [178.255.87.226]) by ietfa.amsl.com (Postfix) with ESMTP id 6FD981A0820 for ; Mon, 31 Mar 2014 02:57:04 -0700 (PDT)
Received: (qmail 18845 invoked by uid 1000); 31 Mar 2014 09:57:00 -0000
Received: from nigel.brad.office.comodo.net (HELO [192.168.0.58]) (192.168.0.58) (smtp-auth username rob, mechanism plain) by ian.brad.office.comodo.net (qpsmtpd/0.40) with (AES128-SHA encrypted) ESMTPSA; Mon, 31 Mar 2014 10:57:00 +0100
Message-ID: <53393BEC.8000504@comodo.com>
Date: Mon, 31 Mar 2014 10:57:00 +0100
From: Rob Stradling 
User-Agent: Mozilla/5.0 (X11; Linux i686; rv:24.0) Gecko/20100101 Thunderbird/24.4.0
MIME-Version: 1.0
To: Rick Andrews ,  "trans@ietf.org" 
References: <544B0DD62A64C1448B2DA253C011414607C85F3902@TUS1XCHEVSPIN33.SYMC.SYMANTEC.COM>
In-Reply-To: <544B0DD62A64C1448B2DA253C011414607C85F3902@TUS1XCHEVSPIN33.SYMC.SYMANTEC.COM>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 8bit
Archived-At: http://mailarchive.ietf.org/arch/msg/trans/wOE2g8pKXjX0_nIzn9ssmgS_QbU
Subject: Re: [Trans] Angle brackets in the PRIVATE option (Ticket #1)
X-BeenThere: trans@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Public Notary Transparency working group discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 31 Mar 2014 09:57:06 -0000

Rick, thanks for this.  Good catch!

Yes, parentheses would definitely be better.

On 28/03/14 16:46, Rick Andrews wrote:
> We see another potential issue with the proposed PRIVATE option. Rob�s
> current proposal would have us replace a domain label with the literal
> string �� (without the quotes). However, we try to encode DN
> components as PrintableString where possible, and angle brackets are not
> part of the PrintableString set (the lowercase letters 'a' through 'z',
> uppercase letters 'A' through 'Z', the digits '0' through '9', eleven
> special characters ' = ( ) + , - . / : ? and space).
> As a result, the type of the DN component would be PrintableString in
> the real cert but utf8String in the pre-certificate, and that would
> cause problems. I suggest using parentheses instead of angle brackets.
> -Rick

-- 
Rob Stradling
Senior Research & Development Scientist
COMODO - Creating Trust Online

From nobody Mon Mar 31 03:10:50 2014
Return-Path: 
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 AA2DF1A0982 for ; Mon, 31 Mar 2014 03:10:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.168
X-Spam-Level: 
X-Spam-Status: No, score=-2.168 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, GB_I_LETTER=-2, HELO_MISMATCH_NET=0.611, SPF_PASS=-0.001, URI_HEX=1.122] 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 bcLhcsg51V5H for ; Mon, 31 Mar 2014 03:10:46 -0700 (PDT)
Received: from ian.brad.office.comodo.net (eth5.brad-fw.brad.office.ccanet.co.uk [178.255.87.226]) by ietfa.amsl.com (Postfix) with ESMTP id 7A84D1A0838 for ; Mon, 31 Mar 2014 03:10:45 -0700 (PDT)
Received: (qmail 6632 invoked by uid 1000); 31 Mar 2014 10:10:40 -0000
Received: from nigel.brad.office.comodo.net (HELO [192.168.0.58]) (192.168.0.58) (smtp-auth username rob, mechanism plain) by ian.brad.office.comodo.net (qpsmtpd/0.40) with (AES128-SHA encrypted) ESMTPSA; Mon, 31 Mar 2014 11:10:40 +0100
Message-ID: <53393F1F.6080005@comodo.com>
Date: Mon, 31 Mar 2014 11:10:39 +0100
From: Rob Stradling 
User-Agent: Mozilla/5.0 (X11; Linux i686; rv:24.0) Gecko/20100101 Thunderbird/24.4.0
MIME-Version: 1.0
To: Peter Bowen , Rick Andrews 
References: <544B0DD62A64C1448B2DA253C011414607C85F3902@TUS1XCHEVSPIN33.SYMC.SYMANTEC.COM> 
In-Reply-To: 
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Archived-At: http://mailarchive.ietf.org/arch/msg/trans/nlqqsKriB-vz0DzUDHaK9LYx9V4
Cc: "trans@ietf.org" 
Subject: Re: [Trans] Angle brackets in the PRIVATE option (Ticket #1)
X-BeenThere: trans@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Public Notary Transparency working group discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 31 Mar 2014 10:10:47 -0000

On 29/03/14 03:24, Peter Bowen wrote:
> On Fri, Mar 28, 2014 at 9:46 AM, Rick Andrews  wrote:
>> We see another potential issue with the proposed PRIVATE option. Rob’s
>> current proposal would have us replace a domain label with the literal
>> string “” (without the quotes). However, we try to encode DN
>> components as PrintableString where possible, and angle brackets are not
>> part of the PrintableString set (the lowercase letters 'a' through 'z',
>> uppercase letters 'A' through 'Z', the digits '0' through '9', eleven
>> special characters ' = ( ) + , - . / : ? and space).
>>
>> As a result, the type of the DN component would be PrintableString in the
>> real cert but utf8String in the pre-certificate, and that would cause
>> problems. I suggest using parentheses instead of angle brackets.
>
> Instead of having "", what about replacing the redacted
> string with a prefixed checksum of the part?
>
> Assuming we specify CRC-32 with "+" as the prefix,
> "mail.corp.example.com" would become "+6f993bb2.example.com".  This
> could also allow redacting only some labels:
> "mail.secret.example.gov.xx" could become
> "mail.+734313b7.example.gov.xx".  This has the benefit of providing
> privacy while allowing stronger matching of the certificate.

Hi Peter.

The aim of the PRIVATE option is to keep sub-domain names _completely 
hidden_ from the Log, so I think that revealing any information about 
them is problematic.

How long would it take an attacker to perform a dictionary attack to 
discover that "6f993bb2" corresponds to "mail.corp" ?

-- 
Rob Stradling
Senior Research & Development Scientist
COMODO - Creating Trust Online

From nobody Mon Mar 31 03:51:49 2014
Return-Path: 
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 E9B531A0686 for ; Mon, 31 Mar 2014 03:51:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.389
X-Spam-Level: 
X-Spam-Status: No, score=-1.389 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no
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 9IOuK5d99OEF for ; Mon, 31 Mar 2014 03:51:47 -0700 (PDT)
Received: from mail-ve0-x22b.google.com (mail-ve0-x22b.google.com [IPv6:2607:f8b0:400c:c01::22b]) by ietfa.amsl.com (Postfix) with ESMTP id C299A1A0681 for ; Mon, 31 Mar 2014 03:51:46 -0700 (PDT)
Received: by mail-ve0-f171.google.com with SMTP id jy13so5049343veb.30 for ; Mon, 31 Mar 2014 03:51:43 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=KYJPPwQ4yvLrA6VanSfUN4izDYVOvEhHg0QjNpTJgGg=; b=o+JKDclafe0TY5QB5x/b4sQIhmNIgcsJFpL3nRB2+oNlzujeszfHaGIwUaPxOigpqQ 58AP/VTeApxEgbXN6HOCwleSqZAeTc0lOozeIpkx8wXYnqIQmiwa/RTKnGgV8ALVi28Q njqQOJ/SfsHq7Zqjv33pANiRxQ5CvVSpt5P2yBj6RTiGtaSNr/mdnb9xBwiRtK/YFp9R xCg3TxKxKgXRExb8pA/PZiSRzQJ8tfo/EBWQou/3phl9a/g/q/myNELH5Dofx0hLecPK nAHgfqNd5jOSnHthNWIAInmFyECZ3ahJ/ApeyWB9icOywzddOEXvZUYlA9QavC4puU+F Pmaw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=KYJPPwQ4yvLrA6VanSfUN4izDYVOvEhHg0QjNpTJgGg=; b=Ld2RIPuPEMlEJUqMJZHMudtyTHwNLJJr9zzJ8eD1uuGcUliqCLPt5p1+zhOuwR0S+v pSZ8tjDFYV869C8Dyjzf3RpIfCJ4O4A1KGlZ0YJHUiq1G0Fqz42EkmhCqeywIbP8tgs5 zPo63sioTqpNSXKcK9XtOXRA2UWvzYvjjCu3vFoyIQAVKjWihBiqtSW7mhxsvlT8fbcv EOz+f1vL4zg2s5+uOff8NheBHWOsosMVO6WfktN+bhX20X+M07Y1Ss0HpkiA5uGv6Snr Wu3/xJNRCURBP0IowTFds4OD1qU1vkLU2h3PcBb7ZN0tVtctQkTmtPNzBs9qNmjFqm2T q9rQ==
X-Gm-Message-State: ALoCoQloQQ534kvK6v3GIVcc4yXYRyCFyKm4o8V/sBNFeUor76gwk+Oj77sU9TAiTOznAso3AbnYo+FcYHRl3f6U+Q+Bw2M940Wqkn4Kt2j0xKfIyO1ABq5z5kyB8bNLx82q4hOb73pAxTM8sLmpSCQZq8vRl3E/+uUo2dSKvaglhPkQqrZ5a16/MwQvE6GNAWsVq2NW7Y/k
MIME-Version: 1.0
X-Received: by 10.58.154.10 with SMTP id vk10mr2686228veb.18.1396263103309; Mon, 31 Mar 2014 03:51:43 -0700 (PDT)
Received: by 10.52.119.179 with HTTP; Mon, 31 Mar 2014 03:51:43 -0700 (PDT)
In-Reply-To: 
References: 
Date: Mon, 31 Mar 2014 11:51:43 +0100
Message-ID: 
From: Ben Laurie 
To: Dmitry Belyavsky 
Content-Type: text/plain; charset=UTF-8
Archived-At: http://mailarchive.ietf.org/arch/msg/trans/_fb1ocWnOAlOcv-i7x7YFTsR11k
Cc: "trans@ietf.org" 
Subject: Re: [Trans] Fwd: Certificate Transparency with Russian GOST algorithms
X-BeenThere: trans@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Public Notary Transparency working group discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 31 Mar 2014 10:51:48 -0000

On 31 March 2014 09:21, Dmitry Belyavsky  wrote:
> Dear Ben,
>
> Sorry for my late response.
>
> 18.03.2014 18:20, Ben Laurie wrote:
>> As I mentioned elsewhere, in our view you change algorithm by starting
>> a new log.
>
> Ok. What about a way to find out the algorithm in use?

That is metadata that clients must discover outside the protocol
(along with things like MMD, log URL, etc).

>> It seems to me there shouldn't be any difficulty accommodating GOST
>> like this - I guess we'd have to add the rule that non-GOST
>> certificates MUST NOT use GOST logs. Not sure whether we should
>> require the opposite, though (i.e. GOST certificates MUST NOT use
>> EC/SHA logs)?
>
> What is expected to be a right behaviour in case when a certificate has SCT
> from some different log servers, if some of the SCT signatures can't be
> verified? If they are to be just ignored, I'm not sure we need such a
> limitation.

Fair point.

From nobody Mon Mar 31 06:44:42 2014
Return-Path: 
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 5897C1A0A19 for ; Mon, 31 Mar 2014 06:44:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.878
X-Spam-Level: 
X-Spam-Status: No, score=-0.878 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, SPF_PASS=-0.001, URI_HEX=1.122] autolearn=no
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 xUIauh-iTIqk for ; Mon, 31 Mar 2014 06:44:39 -0700 (PDT)
Received: from mail-pb0-x230.google.com (mail-pb0-x230.google.com [IPv6:2607:f8b0:400e:c01::230]) by ietfa.amsl.com (Postfix) with ESMTP id 55EBE1A0A17 for ; Mon, 31 Mar 2014 06:44:38 -0700 (PDT)
Received: by mail-pb0-f48.google.com with SMTP id md12so8159103pbc.7 for ; Mon, 31 Mar 2014 06:44:35 -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 :cc:content-type; bh=D0Eeb0X5UI9HTPu9AilKo7A3niV0d23dF9+grCOOxU4=; b=sPXE3DUG0HrJmdB/VEmDo9VHnJAAXvol3t+F6c+YB1bgFTnpShInUWlPWDnc0F8zrJ VKvrQuE9I0WL3QQRK2Ud4Tx77jIWvj1BthIbdjJ38zmK6JrsBaQaIJ8t+Vr7hOKsaR7k MEf46l+FS6aixLyugFQCsi1MZ4fpYlRzZXuP0k3ez5D2okyIpu1B8SoqpURlyCv3JXbj aJyA4SDZWxHDAsz6DepBNuroY40mehwerMh4AvlrKYAawuf9g36VnpeUrCa9Oqk/J6oC tKJJf+iMdFl7mRiwqE5oEV/G5kd2SI4elqDy2tPcIAXxkKN2Z0s8IqktTlowEkcMcl+E qzvQ==
MIME-Version: 1.0
X-Received: by 10.68.34.197 with SMTP id b5mr25426049pbj.16.1396273475314; Mon, 31 Mar 2014 06:44:35 -0700 (PDT)
Received: by 10.70.131.16 with HTTP; Mon, 31 Mar 2014 06:44:35 -0700 (PDT)
In-Reply-To: <53393F1F.6080005@comodo.com>
References: <544B0DD62A64C1448B2DA253C011414607C85F3902@TUS1XCHEVSPIN33.SYMC.SYMANTEC.COM>  <53393F1F.6080005@comodo.com>
Date: Mon, 31 Mar 2014 06:44:35 -0700
Message-ID: 
From: Peter Bowen 
To: Rob Stradling 
Content-Type: text/plain; charset=UTF-8
Archived-At: http://mailarchive.ietf.org/arch/msg/trans/j7G0PSoW_5UjGMNek3TIAzgpzpE
Cc: "trans@ietf.org" , Rick Andrews 
Subject: Re: [Trans] Angle brackets in the PRIVATE option (Ticket #1)
X-BeenThere: trans@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Public Notary Transparency working group discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 31 Mar 2014 13:44:40 -0000

On Mon, Mar 31, 2014 at 3:10 AM, Rob Stradling  wrote:
> On 29/03/14 03:24, Peter Bowen wrote:
>> Instead of having "", what about replacing the redacted
>> string with a prefixed checksum of the part?
>>
>> Assuming we specify CRC-32 with "+" as the prefix,
>> "mail.corp.example.com" would become "+6f993bb2.example.com".  [...]
>> This has the benefit of providing
>> privacy while allowing stronger matching of the certificate.
>
> The aim of the PRIVATE option is to keep sub-domain names _completely
> hidden_ from the Log, so I think that revealing any information about them
> is problematic.

If _completely_hidden_ is the requirement, then I agree that any
option that is no f(x) = 1 (for fixed values of 1) fails.

Why have the long string "(PRIVATE)" at all then?  Would a single '?'
not be adequate?  I don't think you will ever find '?' in a real
dNSName.
On a related note, is there any plan to support blinding other general
name options?  Can email addresses in rfc822Name or ipAddresses be
blinded?

Thanks,
Peter

From nobody Mon Mar 31 07:01:26 2014
Return-Path: 
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 C776E1A6EF2 for ; Mon, 31 Mar 2014 07:01:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.168
X-Spam-Level: 
X-Spam-Status: No, score=-0.168 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_MISMATCH_NET=0.611, SPF_PASS=-0.001, URI_HEX=1.122] autolearn=no
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 XYPY-Vdly7pF for ; Mon, 31 Mar 2014 07:01:22 -0700 (PDT)
Received: from ian.brad.office.comodo.net (eth5.brad-fw.brad.office.ccanet.co.uk [178.255.87.226]) by ietfa.amsl.com (Postfix) with ESMTP id 9F1BF1A0A24 for ; Mon, 31 Mar 2014 07:01:21 -0700 (PDT)
Received: (qmail 5964 invoked by uid 1000); 31 Mar 2014 14:01:16 -0000
Received: from nigel.brad.office.comodo.net (HELO [192.168.0.58]) (192.168.0.58) (smtp-auth username rob, mechanism plain) by ian.brad.office.comodo.net (qpsmtpd/0.40) with (AES128-SHA encrypted) ESMTPSA; Mon, 31 Mar 2014 15:01:16 +0100
Message-ID: <5339752C.7020808@comodo.com>
Date: Mon, 31 Mar 2014 15:01:16 +0100
From: Rob Stradling 
User-Agent: Mozilla/5.0 (X11; Linux i686; rv:24.0) Gecko/20100101 Thunderbird/24.4.0
MIME-Version: 1.0
To: Peter Bowen 
References: <544B0DD62A64C1448B2DA253C011414607C85F3902@TUS1XCHEVSPIN33.SYMC.SYMANTEC.COM>  <53393F1F.6080005@comodo.com> 
In-Reply-To: 
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Archived-At: http://mailarchive.ietf.org/arch/msg/trans/upPSRWQPXZB1CMZJS5LA_6-Uisk
Cc: "trans@ietf.org" , Rick Andrews 
Subject: Re: [Trans] Angle brackets in the PRIVATE option (Ticket #1)
X-BeenThere: trans@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Public Notary Transparency working group discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 31 Mar 2014 14:01:25 -0000

On 31/03/14 14:44, Peter Bowen wrote:
> On Mon, Mar 31, 2014 at 3:10 AM, Rob Stradling  wrote:
>> On 29/03/14 03:24, Peter Bowen wrote:
>>> Instead of having "", what about replacing the redacted
>>> string with a prefixed checksum of the part?
>>>
>>> Assuming we specify CRC-32 with "+" as the prefix,
>>> "mail.corp.example.com" would become "+6f993bb2.example.com".  [...]
>>> This has the benefit of providing
>>> privacy while allowing stronger matching of the certificate.
>>
>> The aim of the PRIVATE option is to keep sub-domain names _completely
>> hidden_ from the Log, so I think that revealing any information about them
>> is problematic.
>
> If _completely_hidden_ is the requirement, then I agree that any
> option that is no f(x) = 1 (for fixed values of 1) fails.
>
> Why have the long string "(PRIVATE)" at all then?  Would a single '?'
> not be adequate?  I don't think you will ever find '?' in a real
> dNSName.

"PRIVATE" seemed a good choice of string literal from the point of view 
of explaining the idea clearly, but I'm not bothered what string literal 
we end up using.

Why does the length of the string literal concern you?

> On a related note, is there any plan to support blinding other general
> name options?  Can email addresses in rfc822Name or ipAddresses be
> blinded?

What part(s) of an IP Address could reasonably be blinded?

I think blinding part of an rfc822Name value could be useful, although 
I'm not sure it's really in scope for RFC6962-bis.

-- 
Rob Stradling
Senior Research & Development Scientist
COMODO - Creating Trust Online

From nobody Mon Mar 31 07:57:22 2014
Return-Path: 
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 91AE31A6EF0 for ; Mon, 31 Mar 2014 07:57:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level: 
X-Spam-Status: No, score=-2 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, 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 fRuCwR29Q5py for ; Mon, 31 Mar 2014 07:57:19 -0700 (PDT)
Received: from mail-pb0-x236.google.com (mail-pb0-x236.google.com [IPv6:2607:f8b0:400e:c01::236]) by ietfa.amsl.com (Postfix) with ESMTP id DD5B01A6EEA for ; Mon, 31 Mar 2014 07:57:16 -0700 (PDT)
Received: by mail-pb0-f54.google.com with SMTP id ma3so8268469pbc.41 for ; Mon, 31 Mar 2014 07:57:13 -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 :cc:content-type; bh=v9qb0I2Uf9Koi57i7M6L73Koxydbz1imlddfkEzicRc=; b=gnJuGsKnGVLb7+Nq0iBvrWWa8Dsz9tAcZRTryubk4erT9l1Wqg7y+c45b0B/F1it0i Gy2pyjnvF2KbwWfH8YkH2F+IBU9IDmXtbtnyhh7zGUHM28rqX8gnAOnKvuvpQuI0TiI/ Bm7EQ3ABu0SFxFofPAIWRtFiMLVd6zAHCUBqEroNBgksX83513LBCK6+JjlgNZF9pdX/ pCNZAnorsThY9uHf1xqZgpyGWx5WUp9Vae2IEZNCtXj/zoAzDNXt52XOPYfH/r8ZXWJN ASIPY96RtGfv0eUcyXHttMc5NgNdYGPxCifZBLSRaqrRQ/1cnQkxRRGPBLJHpwso+ZX8 94gQ==
MIME-Version: 1.0
X-Received: by 10.66.11.66 with SMTP id o2mr4305372pab.142.1396277833792; Mon, 31 Mar 2014 07:57:13 -0700 (PDT)
Received: by 10.70.131.16 with HTTP; Mon, 31 Mar 2014 07:57:13 -0700 (PDT)
In-Reply-To: <5339752C.7020808@comodo.com>
References: <544B0DD62A64C1448B2DA253C011414607C85F3902@TUS1XCHEVSPIN33.SYMC.SYMANTEC.COM>  <53393F1F.6080005@comodo.com>  <5339752C.7020808@comodo.com>
Date: Mon, 31 Mar 2014 07:57:13 -0700
Message-ID: 
From: Peter Bowen 
To: Rob Stradling 
Content-Type: text/plain; charset=UTF-8
Archived-At: http://mailarchive.ietf.org/arch/msg/trans/Onpw8ahZW9LmiUlpSryjGGn1JZ4
Cc: "trans@ietf.org" , Rick Andrews 
Subject: Re: [Trans] Angle brackets in the PRIVATE option (Ticket #1)
X-BeenThere: trans@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Public Notary Transparency working group discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 31 Mar 2014 14:57:20 -0000

On Mon, Mar 31, 2014 at 7:01 AM, Rob Stradling  wrote:
> On 31/03/14 14:44, Peter Bowen wrote:
>> If _completely_hidden_ is the requirement, then I agree that any
>> option that is no f(x) = 1 (for fixed values of 1) fails.
>>
>> Why have the long string "(PRIVATE)" at all then?  Would a single '?'
>> not be adequate?  I don't think you will ever find '?' in a real
>> dNSName.
>
>
> "PRIVATE" seemed a good choice of string literal from the point of view of
> explaining the idea clearly, but I'm not bothered what string literal we end
> up using.
>
> Why does the length of the string literal concern you?

I guess it does not really matter.  I was thinking about the future,
when CT is used for the CDN certificates with hundreds of SANs.
Moving "www" -> "(PRIVATE)" for 200 names increases the size 1200
bytes.  Maybe additional size is not a big deal.

Thanks,
Peter

From nobody Mon Mar 31 08:05:17 2014
Return-Path: 
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 95E281A6F01 for ; Mon, 31 Mar 2014 08:05:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.21
X-Spam-Level: 
X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 yD2-DJaMF7jK for ; Mon, 31 Mar 2014 08:05:13 -0700 (PDT)
Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) by ietfa.amsl.com (Postfix) with ESMTP id 7A15E1A6EF0 for ; Mon, 31 Mar 2014 08:05:13 -0700 (PDT)
Received: from dhcp89-089-218.bbn.com ([128.89.89.218]:49221) by smtp.bbn.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1WUdm1-000H0N-SS for trans@ietf.org; Mon, 31 Mar 2014 11:05:17 -0400
Message-ID: <53398425.4020404@bbn.com>
Date: Mon, 31 Mar 2014 11:05:09 -0400
From: Stephen Kent 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.4.0
MIME-Version: 1.0
To: trans@ietf.org
References:  <5322131A.2080507@comodo.com>   <544B0DD62A64C1448B2DA253C011414607C85F39F4@TUS1XCHEVSPIN33.SYMC.SYMANTEC.COM>  <544B0DD62A64C1448B2DA253C011414607C85F3B2D@TUS1XCHEVSPIN33.SYMC.SYMANTEC.COM>
In-Reply-To: <544B0DD62A64C1448B2DA253C011414607C85F3B2D@TUS1XCHEVSPIN33.SYMC.SYMANTEC.COM>
Content-Type: multipart/alternative; boundary="------------000407090105050602070506"
Archived-At: http://mailarchive.ietf.org/arch/msg/trans/vuqwQ4qZuomCENshOfM3SJfNV-k
Subject: Re: [Trans] RFC6962 BIS Log file encodings.
X-BeenThere: trans@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Public Notary Transparency working group discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 31 Mar 2014 15:05:15 -0000

This is a multi-part message in MIME format.
--------------000407090105050602070506
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

> I understand that there are problems with ASN.1 and many people don't 
> like it, but if we're talking about X.509 certificates we have to use 
> ASN.1. All of our code for putting blobs into a cert work by defining 
> the structure using ASN.1. Yes, we can add a blob that has some other 
> encoding, but it's more difficult.
>
> If the encoding were ASN.1, it might make adoption more straightforward.
>
> -Rick
>
*+1 though, as former PKIX, I may be biased :-).*

--------------000407090105050602070506
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

        I
            understand that there are problems with ASN.1 and many
            people don’t like it, but if we’re talking about X.509
            certificates we have to use ASN.1. All of our code for
            putting blobs into a cert work by defining the structure
            using ASN.1. Yes, we can add a blob that has some other
            encoding, but it’s more difficult.

        If
            the encoding were ASN.1, it might make adoption more
            straightforward.

        -Rick

    +1 though, as former PKIX, I may be biased :-).

--------------000407090105050602070506--

From nobody Mon Mar 31 08:17:04 2014
Return-Path: 
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 D0ACB1A0862 for ; Mon, 31 Mar 2014 08:17:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.611
X-Spam-Level: 
X-Spam-Status: No, score=-3.611 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_45=0.6, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 cStGqfwfjQS9 for ; Mon, 31 Mar 2014 08:17:00 -0700 (PDT)
Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) by ietfa.amsl.com (Postfix) with ESMTP id 245A41A066B for ; Mon, 31 Mar 2014 08:17:00 -0700 (PDT)
Received: from dhcp89-089-218.bbn.com ([128.89.89.218]:49236) by smtp.bbn.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1WUdxQ-000H86-NP for trans@ietf.org; Mon, 31 Mar 2014 11:17:04 -0400
Message-ID: <533986E8.6040201@bbn.com>
Date: Mon, 31 Mar 2014 11:16:56 -0400
From: Stephen Kent 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.4.0
MIME-Version: 1.0
To: trans@ietf.org
References: 
In-Reply-To: 
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Archived-At: http://mailarchive.ietf.org/arch/msg/trans/a0R5D8KFTnKr7RelzSjT6h_Jlpc
Subject: Re: [Trans] RFC6962 BIS Log file encodings.
X-BeenThere: trans@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Public Notary Transparency working group discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 31 Mar 2014 15:17:02 -0000

Bill,

> On 3/28/14 at 11:47 AM, eabalea@gmail.com (Erwann Abalea) wrote:
>
>> I don't see the problem with ASN.1.
>
> IMHO, the problem with ASN.1 is that it is too complex. There exists a 
> history of attacks on computer security by sending malformed ASN.1 
> irritating bugs in ASN.1 encoders. In addition, the ability to specify 
> "infinite" length data has caused buffer overruns.
>
> ASN.1 fans my say that these bugs have all been fixed, and they may be 
> right if no new ASN.1 interpreters are written.
>
> However, complexity is always a bad thing in a security protocol. Make 
> it only as complex as necessary, and no more complex.
>
> Cheers - Bill
I agree that ASN.1 is complex, and if this were a new protocol, not tied 
to any existing
ASN.1-based data structures, I would not select ASN.1 as a starting 
point. But since we're
talking about data from a TBS cert,since the generators of the data are 
CAs (who should
know how to process ASN.1), and since the consumers of the data are 
browsers who already
process certs, it seems reasonable to stick with ASN.1.

Steve

From nobody Mon Mar 31 08:19:11 2014
Return-Path: 
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 E56251A6F01 for ; Mon, 31 Mar 2014 08:19:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.31
X-Spam-Level: 
X-Spam-Status: No, score=-1.31 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_45=0.6, T_RP_MATCHES_RCVD=-0.01] autolearn=no
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 uWZRTJ-rwLQZ for ; Mon, 31 Mar 2014 08:19:08 -0700 (PDT)
Received: from prod-mail-xrelay06.akamai.com (prod-mail-xrelay06.akamai.com [96.6.114.98]) by ietfa.amsl.com (Postfix) with ESMTP id 90DA71A0862 for ; Mon, 31 Mar 2014 08:19:08 -0700 (PDT)
Received: from prod-mail-xrelay06.akamai.com (localhost.localdomain [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id 1C3CA165576; Mon, 31 Mar 2014 15:19:05 +0000 (GMT)
Received: from prod-mail-relay04.akamai.com (prod-mail-relay04.akamai.com [172.27.8.27]) by prod-mail-xrelay06.akamai.com (Postfix) with ESMTP id 11215165567; Mon, 31 Mar 2014 15:19:05 +0000 (GMT)
Received: from usma1ex-cashub.kendall.corp.akamai.com (usma1ex-cashub4.kendall.corp.akamai.com [172.27.105.20]) by prod-mail-relay04.akamai.com (Postfix) with ESMTP id B61F847BD5; Mon, 31 Mar 2014 15:19:04 +0000 (GMT)
Received: from USMBX1.msg.corp.akamai.com ([172.27.107.26]) by USMA1EX-CASHUB4.kendall.corp.akamai.com ([172.27.105.20]) with mapi; Mon, 31 Mar 2014 11:19:04 -0400
From: "Salz, Rich" 
To: Stephen Kent , "trans@ietf.org" 
Date: Mon, 31 Mar 2014 11:19:03 -0400
Thread-Topic: [Trans] RFC6962 BIS Log file encodings.
Thread-Index: Ac9M9EZFxzx1MMW1RhmnpIjTc0lJQgAABVXA
Message-ID: <2A0EFB9C05D0164E98F19BB0AF3708C711FD90F03D@USMBX1.msg.corp.akamai.com>
References:  <533986E8.6040201@bbn.com>
In-Reply-To: <533986E8.6040201@bbn.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: http://mailarchive.ietf.org/arch/msg/trans/b_ShiWBLXu9542JCkMZ8AeVz7Ko
Subject: Re: [Trans] RFC6962 BIS Log file encodings.
X-BeenThere: trans@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Public Notary Transparency working group discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 31 Mar 2014 15:19:10 -0000

>  But since we're talking about data from a TBS cert,since the generators =
of the data are CAs (who should know how to process ASN.1), and since the c=
onsumers of the data are browsers who already process certs, it seems reaso=
nable to stick with ASN.1.

Adding another encoding makes things more complex.  Therefore, the simplest=
 thing to do is use ASN.1

It's like when you're editing someone else's source code: the best thing to=
 do is preserve the existing style.

	/r$

-- =20
Principal Security Engineer
Akamai Technology
Cambridge, MA

From nobody Mon Mar 31 08:26:53 2014
Return-Path: 
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 B35BC1A0A6F for ; Mon, 31 Mar 2014 08:26:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.389
X-Spam-Level: 
X-Spam-Status: No, score=-1.389 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no
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 XMhG29wJGwdo for ; Mon, 31 Mar 2014 08:26:50 -0700 (PDT)
Received: from mail-ve0-x231.google.com (mail-ve0-x231.google.com [IPv6:2607:f8b0:400c:c01::231]) by ietfa.amsl.com (Postfix) with ESMTP id 171901A0884 for ; Mon, 31 Mar 2014 08:26:50 -0700 (PDT)
Received: by mail-ve0-f177.google.com with SMTP id sa20so8201288veb.36 for ; Mon, 31 Mar 2014 08:26:46 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=x+ClOsGh0FqX+fGkYhRq3+FjMt9OEoTi6fxVsaQ5N+w=; b=oZ49EdPNrVZEpocuIT3Wnqp2S61qIlBkh8+pJXXdlnoztVNgfAX+L/4t7j4htavdIK EV0rPgX0pfJCU+Dh31JmoEyJajnPvJfrBlYLMQs46LkrCugHfNs4Rrpdi5BD7UE17wGU H57RPLYdAI9SSO2qQn/75Qd6c5HV+OCNL3S8mihY5r97mqgBEIgcNv3HGjwoww/awSum d2GgE3iRX96pmQyi9wphKsKUoTSoPJJe+C9IxRpRa0yPvZWl1i1LfQWhzz5W1JhZvoXp VQnDpugOQb1IDjjp6NyR6sf9dGoIFgAU3DDgnczPjr33OrkkKAGpSu9e8h/CONy2Ijw4 pB/g==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=x+ClOsGh0FqX+fGkYhRq3+FjMt9OEoTi6fxVsaQ5N+w=; b=b4tUVE4ktInV+wfqkKMjZdFgXzzGh9SP7Pgtwfiu/i8oJ78yKIKRtHGwh7IIldxV4v Rly33voVUEu/XJMZig4Ue3qcbPCaMQMAhIU/IL5X5PmxrWQFAbmXAlaHgHceQmmMJoWh Yb8hDUvVfHaVrfyfvZs4JU1lY/MTThimJBLCJG6tpFuSGlqsHuW5Rf6AYmfBksjLM8Hr TZ7QxEnnclrNdq++yorwTfxehwET1RVAHqQ2HVnkA21mupBbOeB8FaY5fvfItlb70tEP ypidft9qd7/k7gNWH6HzVE2GgpsCDr3wSc8Pl7OYyKZgydXLBQZPkEZO0bTNq0z6vzej 3OWA==
X-Gm-Message-State: ALoCoQnsysd9wKanX66eAR7Nk+W9RzEgzB5C80ENriLyiCjeKndTr05ny/9xiOOje1+umMwJ7BG+oTeuPUvmRl/IL7jZMc8lBuhvH4NezPOHcIuurBqcD2siuKK9/7hW98pN0hGG4vUUcndRbrOMFmbkMJW1ns23Z8FIo5qc37YpWh0fELm2qTYb0+el6boSYgp54ouAD/Bp
MIME-Version: 1.0
X-Received: by 10.221.26.10 with SMTP id rk10mr23875961vcb.0.1396279606622; Mon, 31 Mar 2014 08:26:46 -0700 (PDT)
Received: by 10.52.119.179 with HTTP; Mon, 31 Mar 2014 08:26:46 -0700 (PDT)
In-Reply-To: <544B0DD62A64C1448B2DA253C011414607C85F3B2D@TUS1XCHEVSPIN33.SYMC.SYMANTEC.COM>
References:  <5322131A.2080507@comodo.com>   <544B0DD62A64C1448B2DA253C011414607C85F39F4@TUS1XCHEVSPIN33.SYMC.SYMANTEC.COM>  <544B0DD62A64C1448B2DA253C011414607C85F3B2D@TUS1XCHEVSPIN33.SYMC.SYMANTEC.COM>
Date: Mon, 31 Mar 2014 16:26:46 +0100
Message-ID: 
From: Ben Laurie 
To: Rick Andrews 
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Archived-At: http://mailarchive.ietf.org/arch/msg/trans/62JijDez3tl45AC6Z9wiShCrKfE
Cc: "trans@ietf.org" , Eran Messeri , Phillip Hallam-Baker , Rob Stradling 
Subject: Re: [Trans] RFC6962 BIS Log file encodings.
X-BeenThere: trans@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Public Notary Transparency working group discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 31 Mar 2014 15:26:51 -0000

On 28 March 2014 18:27, Rick Andrews  wrote:
> I understand that there are problems with ASN.1 and many people don=E2=80=
=99t like
> it, but if we=E2=80=99re talking about X.509 certificates we have to use =
ASN.1. All
> of our code for putting blobs into a cert work by defining the structure
> using ASN.1. Yes, we can add a blob that has some other encoding, but it=
=E2=80=99s
> more difficult.
>
>
>
> If the encoding were ASN.1, it might make adoption more straightforward.

The problem is, there's no right answer here: strictly, the "most
correct" way of including an SCT is as a TLS extension - and that's
why we chose TLS encoding for SCTs. Whatever we do, it seems someone
will be unhappy. And at least TLS encoding is less complicated than
DER.

>
>
>
> -Rick
>
>
>
> From: Phillip Hallam-Baker [mailto:hallam@gmail.com]
> Sent: Friday, March 28, 2014 11:14 AM
> To: Rick Andrews
> Cc: Eran Messeri; Rob Stradling; trans@ietf.org
>
>
> Subject: Re: [Trans] RFC6962 BIS Log file encodings.
>
>
>
> The encoding isn't ASN.1 so using ASN.1 schema is a terrible idea.
>
>
>
> Putting data in certificates does unfortunately lead to the risk of ASN.1=
.
>
>
>
> One of the reasons I developed JSON-BCD was I could see this going to hap=
pen
> and I would much prefer the JSON style approach over any further investme=
nt
> in ASN.1.
>
>
>
>
>
>
>
> On Fri, Mar 28, 2014 at 1:31 PM, Rick Andrews 
> wrote:
>
> In addition, our ASN.1 experts have asked for the syntax to be described =
in
> =E2=80=9CASN.1-like=E2=80=9D syntax, as is used in RFCs 3280 and 5280.
>
>
>
> For example, 3280/5280 defines an Extension like this:
>
>
>
> Extension  ::=3D  SEQUENCE  {
>
>      extnID      OBJECT IDENTIFIER,
>
>      critical    BOOLEAN DEFAULT FALSE,
>
>      extnValue   OCTET STRING  }
>
>
>
> so the extnValue is defined as an OCTET STRING, yet 6962 says =E2=80=9C=
=E2=80=A6encoding the
> SignedCertificateTimestampList structure as an ASN.1 OCTET STRING and
> inserting the resulting data in the TBSCertificate as an X.509v3 certific=
ate
> extension=E2=80=A6=E2=80=9D. The ASN.1 folks say it=E2=80=99s not clear i=
f that means that the
> Extension contains the OCTET STRING data type (for extnValue) and length
> followed by another OCTET STRING data type identifier and length of the S=
CT.
> Or is the second OCTET STRING identifier redundant?
>
>
>
> Those updating existing cert generation code will probably be dealing wit=
h
> ASN.1 compilers, so a precise definition of structures in ASN.1-like synt=
ax
> will go a long way. In addition, defining OIDs as arc plus extension (lik=
e
> this: id-kp-serverAuth  OBJECT IDENTIFIER ::=3D { id-kp 1 }) would help.
>
>
>
> -Rick
>
>
>
> From: Trans [mailto:trans-bounces@ietf.org] On Behalf Of Eran Messeri
> Sent: Friday, March 14, 2014 3:01 AM
> To: Phillip Hallam-Baker
> Cc: Rob Stradling; trans@ietf.org
> Subject: Re: [Trans] RFC6962 BIS Log file encodings.
>
>
>
> I strongly support clarifying the description of the file format. When I
> started implementing aspects of RFC6962 (with no background in TLS encodi=
ng
> or ASN.1) it was very unclear.
>
> From other posts on the list it seems this was unclear to others as well.
>
>
>
> On Thu, Mar 13, 2014 at 10:50 PM, Phillip Hallam-Baker 
> wrote:
>
> On Thu, Mar 13, 2014 at 4:20 PM, Rob Stradling 
> wrote:
>
> (Inspired by RFC5280 Appendix C)
>
> Would it help to include one or more example SCTs in the text?
>
>
>
> I think we definitely need that for Proposed. But right now I am trying t=
o
> see how complete the description is.
>
>
>
> --
> Website: http://hallambaker.com/
>
>
> _______________________________________________
> Trans mailing list
> Trans@ietf.org
> https://www.ietf.org/mailman/listinfo/trans
>
>
>
>
>
>
>
> --
> Website: http://hallambaker.com/
>
>
> _______________________________________________
> Trans mailing list
> Trans@ietf.org
> https://www.ietf.org/mailman/listinfo/trans
>

--=20
Certificate Transparency is hiring! Let me know if you're interested.

From nobody Mon Mar 31 08:28:18 2014
Return-Path: 
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 28B061A0807 for ; Mon, 31 Mar 2014 08:28:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.789
X-Spam-Level: 
X-Spam-Status: No, score=-0.789 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, J_CHICKENPOX_45=0.6, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no
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 60ry_mNeviMZ for ; Mon, 31 Mar 2014 08:28:15 -0700 (PDT)
Received: from mail-ve0-x235.google.com (mail-ve0-x235.google.com [IPv6:2607:f8b0:400c:c01::235]) by ietfa.amsl.com (Postfix) with ESMTP id D63E51A0549 for ; Mon, 31 Mar 2014 08:28:14 -0700 (PDT)
Received: by mail-ve0-f181.google.com with SMTP id oy12so8135157veb.40 for ; Mon, 31 Mar 2014 08:28:11 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=8wXmTZ8BE/vhO4NspA7mgoyriSSSvkWlt3ChLY0Ny4s=; b=eij9DiDduVWzp5qRS4Gs3Vzae98VWWHTxg5xeUHpU4ST4RiZyNGX7fXammQvNLTX9L sRviClgIzttSDjK28d4QA1wDdlfLiPSaXvLOkZZgbtn9WAy4cMIv25tghu//MLr+dFII /iwJ4cAs/rijF45ZrNQH5ah9GHpe+zvd++dBD7p2z4yc+JMn5/z+c4GKz8d4OT5PNzdL ljQNwBKW40l66/HcnK48QkXK1gN45hU8dqhIRxCIn8LCk4saSfv9VvnP54DojyPuCH8o g7V9+QkCNmgppzaJUF7kD1wtnQS2knFsyx7JwFriJovGovg1mk2F9LWMsF4zlqbol8FM ymTA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=8wXmTZ8BE/vhO4NspA7mgoyriSSSvkWlt3ChLY0Ny4s=; b=c9fCcK3PuJHzjqZpOc7rvn/SvNMvbK5h4XBxjvHaRy3RJW8JG2CBczdZfB9QcMrIxb FeNl3ftaKI+laIx+dpxTCS5opHT3AxSocjXKQu/a4HZbclSXoQREQXC64uxQ2UolbJ2c F2TABVxUmE6820V2IcMYB002QPzThnUjj7KL6aBlT4zUSocxvSkT8qwfZgANE+9vB9Hj TttgJQA04DeB6qkRseFBHPQU1OcNdV6sPWZVe/3/4rlWNfOAzI48DDaPbNS4IO54eVWr 9PedG11ZsTT4iHNd6huufoRG04sQaeE1HVEoxLyoIvNOpgrbvcqqhU/WOS/6/4TFMrFy jDAw==
X-Gm-Message-State: ALoCoQlZfGO+Vkt1D6EJsSEISREE0fxrkCWd3LNhOgQhz2AN0Q8/e34lifQA8iSniBzDYPwinjeJ+o8S6gIHWx7x68Go/+6p+kFkFYpWWyylVpoCCZzQD+YKxP78+W4uiqE/jtrpfJ8aC+YOnCsRiPllZLZVrjBrdZbh57x6jhVWZjroNKBDrb9u79cfB3tS8p9LAW4s3E0p
MIME-Version: 1.0
X-Received: by 10.220.249.6 with SMTP id mi6mr473205vcb.33.1396279691445; Mon, 31 Mar 2014 08:28:11 -0700 (PDT)
Received: by 10.52.119.179 with HTTP; Mon, 31 Mar 2014 08:28:11 -0700 (PDT)
In-Reply-To: <2A0EFB9C05D0164E98F19BB0AF3708C711FD90F03D@USMBX1.msg.corp.akamai.com>
References:  <533986E8.6040201@bbn.com> <2A0EFB9C05D0164E98F19BB0AF3708C711FD90F03D@USMBX1.msg.corp.akamai.com>
Date: Mon, 31 Mar 2014 16:28:11 +0100
Message-ID: 
From: Ben Laurie 
To: "Salz, Rich" 
Content-Type: text/plain; charset=UTF-8
Archived-At: http://mailarchive.ietf.org/arch/msg/trans/9XoDseTXl6UYXZ85nnxQvhsGv7k
Cc: "trans@ietf.org" , Stephen Kent 
Subject: Re: [Trans] RFC6962 BIS Log file encodings.
X-BeenThere: trans@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Public Notary Transparency working group discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 31 Mar 2014 15:28:16 -0000

On 31 March 2014 16:19, Salz, Rich  wrote:
>>  But since we're talking about data from a TBS cert,since the generators of the data are CAs (who should know how to process ASN.1), and since the consumers of the data are browsers who already process certs, it seems reasonable to stick with ASN.1.
>
> Adding another encoding makes things more complex.  Therefore, the simplest thing to do is use ASN.1
>
> It's like when you're editing someone else's source code: the best thing to do is preserve the existing style.

As I just mention, its not actually another encoding - the data
structure can also (ideally should also) be sent as a TLS extension,
in which case ASN.1 is not the simplest thing to do.

>
>         /r$
>
> --
> Principal Security Engineer
> Akamai Technology
> Cambridge, MA
>
>
> _______________________________________________
> Trans mailing list
> Trans@ietf.org
> https://www.ietf.org/mailman/listinfo/trans

-- 
Certificate Transparency is hiring! Let me know if you're interested.

From nobody Mon Mar 31 08:35:11 2014
Return-Path: 
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 56E951A6EF0 for ; Mon, 31 Mar 2014 08:35:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.389
X-Spam-Level: 
X-Spam-Status: No, score=-1.389 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no
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 mIlLPSO2sx2f for ; Mon, 31 Mar 2014 08:35:04 -0700 (PDT)
Received: from mail-vc0-x231.google.com (mail-vc0-x231.google.com [IPv6:2607:f8b0:400c:c03::231]) by ietfa.amsl.com (Postfix) with ESMTP id A3C4B1A6EDC for ; Mon, 31 Mar 2014 08:35:04 -0700 (PDT)
Received: by mail-vc0-f177.google.com with SMTP id if17so8184713vcb.8 for ; Mon, 31 Mar 2014 08:35:01 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=jewWlSO9AMH+zcTD7tboKkTZgaHisI/twDpIrEB4DCg=; b=iSwxIZpNRA2kh/UrfmXelzm09/d++1+cZwZsYxbTLqwbmStCIq0LLdUb1ZbbzDMTIN 43R+XXlRn1vE15kG907ZjNFh/IfNDEssDHiONQUANt83kqXdU/QlsMEmOOVPtjA1D7z9 OfRr922jZjx4gg3czTrVoDeMy3FViYD45WorsVcAKAwWsTjjoDza93hgqQn9nsUJINY2 IXodXA1M0H/Fc+I9lgcU+U7qkBMPpOWLE3K+pJBcrLSqamu1qs8iqksePAzDj+tA4s6W pqJm6Ay5GvZxlBj/QCNxJ8rZFyXwqt9IkIExvMKTIV9VMvu6QaJBce53+WIoW9TmrmdG F5qA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=jewWlSO9AMH+zcTD7tboKkTZgaHisI/twDpIrEB4DCg=; b=hwYj3zaP8WTl6vwIczx7sUvSCnGQ/lr+5BkDnUcf/f0QuoW8v7kW840sXM734ayeGt DKiKdBXzQITahsErb9MA8xRSwcnAgY2dYLPFagkfIKaDsULnvBhLSj2HGiZU2xhe1mHn sqhYmsqcfrJJVI8OTrN0MeAcr6UG9sm6/c+gxV++TktLKgs3nenQPgUdei2C6X1AqFzX Aofbb/y6irzlNKYd9S1HyPD4CmCWyTRr4Fyaqs0PeerAJ1VMuh5zpWMG3iahTK0a9GVg Tbw7KwwyiDUdZO2Le2xDUdml0CUumRZtk5zvupU0pn+ywSj3pubHvCLk/YKMJC1zX8no vjPQ==
X-Gm-Message-State: ALoCoQk6jJ/Sj9EZn3vjwVma/q5HzCK9OLPqht86Z2SGIuFX7Q1VJwOsKxRnpm+jd0UKlBSVV34RF4uzrMbzzsf+FJooc7xyfm0ygebpK94OEKDt0FHrucSMwcGAiEmyVctPp4eqR7ioYGwNCODMZwH/IpyBxFuCMfuZCJKeusZzByqexVGHMGetO8UuPxIm6iAZJWBx+rpL
MIME-Version: 1.0
X-Received: by 10.58.172.132 with SMTP id bc4mr187380vec.45.1396280101200; Mon, 31 Mar 2014 08:35:01 -0700 (PDT)
Received: by 10.52.119.179 with HTTP; Mon, 31 Mar 2014 08:35:01 -0700 (PDT)
In-Reply-To: 
References: 
Date: Mon, 31 Mar 2014 16:35:01 +0100
Message-ID: 
From: Ben Laurie 
To: Phillip Hallam-Baker 
Content-Type: text/plain; charset=UTF-8
Archived-At: http://mailarchive.ietf.org/arch/msg/trans/jVxSOvlweQIg9qci7hturOj9yaU
Cc: "trans@ietf.org" 
Subject: Re: [Trans] RFC6962 BIS Log file encodings.
X-BeenThere: trans@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Public Notary Transparency working group discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 31 Mar 2014 15:35:06 -0000

And to answer the original question...

On 13 March 2014 17:29, Phillip Hallam-Baker  wrote:
> I am trying to make sense of the log file encoding (section 3). this does
> not seem to me to be properly or clearly specified.
>
> RFC6962 punts the encoding question to RFC5246 but this only helps somewhat
> because the description there is atrocious.
>
> In particular it is implicit in the text that digitaly-signed is equivalent
> to the ASN.1 macro. But this isn't actually explained anywhere in section 4
> of 5246. So as a result there is no information on where the signature
> appears in the data stream, does it precede or follow the signed data?
>
> This is quite problematic because in the TLS use the signed data does not
> appear on the wire at all, the construct is used in client auth when the
> prior handshake is signed so there is no need to retransmit the data.
>
>
> It looks to me like the idea here is that the SCT does not need to include
> the certificate or precertificate data because the corresponding signed data
> will always be implicit from the mode of use.

Exactly.

> But that needs to be clearly
> stated.

RFC 5246 seems pretty clear already, from 4.7:

"A digitally-signed element is encoded as a struct DigitallySigned:

      struct {
         SignatureAndHashAlgorithm algorithm;
         opaque signature<0..2^16-1>;
      } DigitallySigned;

   The algorithm field specifies the algorithm used (see Section
   7.4.1.4.1 for the definition of this field).  Note that the
   introduction of the algorithm field is a change from previous
   versions.  The signature is a digital signature using those
   algorithms over the contents of the element.  The contents themselves
   do not appear on the wire but are simply calculated.  The length of
   the signature is specified by the signing algorithm and key."

I'm not sure how to state it more clearly than that.

> At the moment the specification is assuming that the reader has a high
> degree of familiarity with PKIX and TLS encodings and can switch gear
> between them.
>
> --
> Website: http://hallambaker.com/
>
> _______________________________________________
> Trans mailing list
> Trans@ietf.org
> https://www.ietf.org/mailman/listinfo/trans
>

-- 
Certificate Transparency is hiring! Let me know if you're interested.

From nobody Mon Mar 31 13:00:24 2014
Return-Path: 
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 0FCCD1A6F6A for ; Mon, 31 Mar 2014 13:00:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.611
X-Spam-Level: 
X-Spam-Status: No, score=-3.611 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_45=0.6, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 FVD8wQOf9_AU for ; Mon, 31 Mar 2014 13:00:20 -0700 (PDT)
Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) by ietfa.amsl.com (Postfix) with ESMTP id 652981A6F66 for ; Mon, 31 Mar 2014 13:00:20 -0700 (PDT)
Received: from dhcp89-089-218.bbn.com ([128.89.89.218]:50456) by smtp.bbn.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1WUiNb-000KNe-MF for trans@ietf.org; Mon, 31 Mar 2014 16:00:23 -0400
Message-ID: <5339C94F.9030001@bbn.com>
Date: Mon, 31 Mar 2014 16:00:15 -0400
From: Stephen Kent 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.4.0
MIME-Version: 1.0
To: trans@ietf.org
References:  <533986E8.6040201@bbn.com> <2A0EFB9C05D0164E98F19BB0AF3708C711FD90F03D@USMBX1.msg.corp.akamai.com> 
In-Reply-To: 
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Archived-At: http://mailarchive.ietf.org/arch/msg/trans/myW8rx1M7pYt8-nmlsbae_rRYHs
Subject: Re: [Trans] RFC6962 BIS Log file encodings.
X-BeenThere: trans@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Public Notary Transparency working group discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 31 Mar 2014 20:00:22 -0000

Ben,

> On 31 March 2014 16:19, Salz, Rich  wrote:
>>>   But since we're talking about data from a TBS cert,since the generators of the data are CAs (who should know how to process ASN.1), and since the consumers of the data are browsers who already process certs, it seems reasonable to stick with ASN.1.
>> Adding another encoding makes things more complex.  Therefore, the simplest thing to do is use ASN.1
>>
>> It's like when you're editing someone else's source code: the best thing to do is preserve the existing style.
> As I just mention, its not actually another encoding - the data
> structure can also (ideally should also) be sent as a TLS extension,
> in which case ASN.1 is not the simplest thing to do.
Sorry if I misinterpreted the context. We need definitive statements 
about how each major
data element is transmitted, against what it is compared, and how it is 
generated.
Only then does it make sense to debate which encoding(s) make sense.

Steve

From nobody Mon Mar 31 14:05:26 2014
Return-Path: 
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 6645A1A7D81 for ; Mon, 31 Mar 2014 14:05:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.29
X-Spam-Level: 
X-Spam-Status: No, score=-1.29 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_MISMATCH_NET=0.611, SPF_PASS=-0.001] autolearn=no
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 7jnJN2lL4W2q for ; Mon, 31 Mar 2014 14:05:22 -0700 (PDT)
Received: from ian.brad.office.comodo.net (eth5.brad-fw.brad.office.ccanet.co.uk [178.255.87.226]) by ietfa.amsl.com (Postfix) with ESMTP id 702DE1A7D80 for ; Mon, 31 Mar 2014 14:05:20 -0700 (PDT)
Received: (qmail 22308 invoked by uid 1000); 31 Mar 2014 21:05:16 -0000
Received: from nigel.brad.office.comodo.net (HELO [192.168.0.58]) (192.168.0.58) (smtp-auth username rob, mechanism plain) by ian.brad.office.comodo.net (qpsmtpd/0.40) with (AES128-SHA encrypted) ESMTPSA; Mon, 31 Mar 2014 22:05:16 +0100
Message-ID: <5339D88C.7060605@comodo.com>
Date: Mon, 31 Mar 2014 22:05:16 +0100
From: Rob Stradling 
User-Agent: Mozilla/5.0 (X11; Linux i686; rv:24.0) Gecko/20100101 Thunderbird/24.4.0
MIME-Version: 1.0
To: Peter Bowen 
References: <544B0DD62A64C1448B2DA253C011414607C85F3902@TUS1XCHEVSPIN33.SYMC.SYMANTEC.COM>  <53393F1F.6080005@comodo.com>  <5339752C.7020808@comodo.com> 
In-Reply-To: 
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Archived-At: http://mailarchive.ietf.org/arch/msg/trans/jVZqHLMjtvWnFrkaGhoCUjQKlh8
Cc: "trans@ietf.org" , Rick Andrews 
Subject: Re: [Trans] Angle brackets in the PRIVATE option (Ticket #1)
X-BeenThere: trans@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Public Notary Transparency working group discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 31 Mar 2014 21:05:24 -0000

On 31/03/14 15:57, Peter Bowen wrote:
> On Mon, Mar 31, 2014 at 7:01 AM, Rob Stradling  wrote:
>> On 31/03/14 14:44, Peter Bowen wrote:
>>> If _completely_hidden_ is the requirement, then I agree that any
>>> option that is no f(x) = 1 (for fixed values of 1) fails.
>>>
>>> Why have the long string "(PRIVATE)" at all then?  Would a single '?'
>>> not be adequate?  I don't think you will ever find '?' in a real
>>> dNSName.
>>
>>
>> "PRIVATE" seemed a good choice of string literal from the point of view of
>> explaining the idea clearly, but I'm not bothered what string literal we end
>> up using.
>>
>> Why does the length of the string literal concern you?
>
> I guess it does not really matter.  I was thinking about the future,
> when CT is used for the CDN certificates with hundreds of SANs.
> Moving "www" -> "(PRIVATE)" for 200 names increases the size 1200
> bytes.  Maybe additional size is not a big deal.

"(PRIVATE)" will appear in some Precertificates.  Precertificates will 
be generated by CAs, stored by CT Logs, and dynamically reconstructed by 
TLS Clients.

"(PRIVATE)" will _not_ appear in Server Certificates sent by TLS Servers 
to TLS Clients.  So if you're concerned about the impact of "(PRIVATE)" 
on TLS handshake sizes, you needn't be.

-- 
Rob Stradling
Senior Research & Development Scientist
COMODO - Creating Trust Online

From nobody Mon Mar 31 15:05:07 2014
Return-Path: 
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 41DA61A08EB for ; Mon, 31 Mar 2014 15:05:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.001
X-Spam-Level: 
X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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 DLhhhqoWq3vI for ; Mon, 31 Mar 2014 15:05:04 -0700 (PDT)
Received: from mail-qg0-x233.google.com (mail-qg0-x233.google.com [IPv6:2607:f8b0:400d:c04::233]) by ietfa.amsl.com (Postfix) with ESMTP id 262251A701D for ; Mon, 31 Mar 2014 15:05:04 -0700 (PDT)
Received: by mail-qg0-f51.google.com with SMTP id q108so4548934qgd.24 for ; Mon, 31 Mar 2014 15:05:00 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=globalsign.com; s=google; h=from:to:cc:references:in-reply-to:subject:date:message-id :mime-version:content-type:content-transfer-encoding:thread-index :content-language; bh=I7PfqdmpgR+1wc3FD0z0B3IkLmu1AdGDtmADqZozabc=; b=N7SHvRpOpp0MVTWMHFwF1qKjkQXZHAF6zr9rLyHxkwjifS7CI1I1Wp6MBUrQrZHLsB EdwiCLl7J/TFsjol2QIeWzJnLKVV9npS6gJlurSisPHE8AdCHRSy+6/7Ab1b8QVVeJ8b JDkIdtGezkhT2YL2r5PUCU8HSiX2XT6lWQhdE=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:to:cc:references:in-reply-to:subject:date :message-id:mime-version:content-type:content-transfer-encoding :thread-index:content-language; bh=I7PfqdmpgR+1wc3FD0z0B3IkLmu1AdGDtmADqZozabc=; b=JGAUp4ekez3q/NL1/gB+CTXvjzDm6rVH0uOr0ENsypPtWSVjCXa4BLwTmRSfgcie0B 1OdkHQgl8xk7WMo+5RMEAG7h2LN1jh8Z+hdQVJztaVVlWs9bmuwHww2k7Xzr+2Wn4/w9 PAEJyvh+7Fu3eAuIZ+0z4w5dxrsra0a/7IS+BYcmUx7Wbd4LwdSM/dxW0kaJuG0s+Vb1 NwkhEmNuU5cdJs5tWrfJ0V5rSK2QskhjdMx1vtHpiPPTSr6E4rOo7oWBccYkMdyBbL/A kwtrpTSBi5JjWwJOJUFUJ81cJMH4qBGsFU8JUMP3dW7mH+jhIn4mJylqe3Gcq/NhZzT4 KAPg==
X-Gm-Message-State: ALoCoQnH5p7F7tEpoLabe8lSsULIiPVfE+NGr9USPAWKwC+o+IrmrPRg3GG+Jya0/HdVIMh0LBgi
X-Received: by 10.140.88.85 with SMTP id s79mr10824684qgd.70.1396303500603; Mon, 31 Mar 2014 15:05:00 -0700 (PDT)
Received: from 42G8TY1 (pool-108-49-225-12.bstnma.fios.verizon.net. [108.49.225.12]) by mx.google.com with ESMTPSA id b4sm30835867qaw.26.2014.03.31.15.04.59 for  (version=TLSv1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Mon, 31 Mar 2014 15:04:59 -0700 (PDT)
From: "Doug Beattie" 
To: "'Peter Bowen'" , "'Rob Stradling'" 
References: <544B0DD62A64C1448B2DA253C011414607C85F3902@TUS1XCHEVSPIN33.SYMC.SYMANTEC.COM>  <53393F1F.6080005@comodo.com>  <5339752C.7020808@comodo.com> 
In-Reply-To: 
Date: Mon, 31 Mar 2014 18:04:57 -0400
Message-ID: <063901cf4d2d$41c859b0$c5590d10$@globalsign.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Outlook 15.0
Thread-Index: AQFYXx6NWUytiHdvSaGjSCMH87BNrgITO4qdAakeWbsCGoj4dgGHg4giAtqwYwCbl9DkoA==
Content-Language: en-us
Archived-At: http://mailarchive.ietf.org/arch/msg/trans/oZKkGvnbbEh8c1FVWAtPHAzU0x4
Cc: trans@ietf.org, 'Rick Andrews' 
Subject: Re: [Trans] Angle brackets in the PRIVATE option (Ticket #1)
X-BeenThere: trans@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Public Notary Transparency working group discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 31 Mar 2014 22:05:06 -0000

I agree with Peter on this one, why are we making a long human readable
string for a cert that basically no-body will ever look at and will be used
only by the browser to validate the SCT (and the CA to create the SCT
extension)?  When the browser tries to validate an SSL certificate they need
an indication that the SCTs were computed normally or via the Private
algorithm. Aren't all the SANs either private or not in a cert, and not a
mix?  (sorry if this is in a spec or an email that I missed).

It seems like the indicator to the browser should be at the SCT extension
level, not on every SAN entry (there could be hundreds), so we could omit
any indication of private at the per-san level.  If it needs to be at the
SAN level (for some reason), then put in a valid PrintableString character
(maybe 2) we'd never expect to see in the wild.

I'm sure I'm missing a key point.

Doug

-----Original Message-----
From: Trans [mailto:trans-bounces@ietf.org] On Behalf Of Peter Bowen
Sent: Monday, March 31, 2014 10:57 AM
To: Rob Stradling
Cc: trans@ietf.org; Rick Andrews
Subject: Re: [Trans] Angle brackets in the PRIVATE option (Ticket #1)

On Mon, Mar 31, 2014 at 7:01 AM, Rob Stradling 
wrote:
> On 31/03/14 14:44, Peter Bowen wrote:
>> If _completely_hidden_ is the requirement, then I agree that any 
>> option that is no f(x) = 1 (for fixed values of 1) fails.
>>
>> Why have the long string "(PRIVATE)" at all then?  Would a single '?'
>> not be adequate?  I don't think you will ever find '?' in a real 
>> dNSName.
>
>
> "PRIVATE" seemed a good choice of string literal from the point of 
> view of explaining the idea clearly, but I'm not bothered what string 
> literal we end up using.
>
> Why does the length of the string literal concern you?

I guess it does not really matter.  I was thinking about the future, when CT
is used for the CDN certificates with hundreds of SANs.
Moving "www" -> "(PRIVATE)" for 200 names increases the size 1200 bytes.
Maybe additional size is not a big deal.

Thanks,
Peter

_______________________________________________
Trans mailing list
Trans@ietf.org
https://www.ietf.org/mailman/listinfo/trans

From nobody Mon Mar 31 23:00:26 2014
Return-Path: 
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 E04ED1A6FD6 for ; Mon, 31 Mar 2014 23:00:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.3
X-Spam-Level: 
X-Spam-Status: No, score=-1.3 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_45=0.6, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=no
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 a2i4S_LuhtPX for ; Mon, 31 Mar 2014 23:00:23 -0700 (PDT)
Received: from elasmtp-kukur.atl.sa.earthlink.net (elasmtp-kukur.atl.sa.earthlink.net [209.86.89.65]) by ietfa.amsl.com (Postfix) with ESMTP id C2EF01A096C for ; Mon, 31 Mar 2014 23:00:23 -0700 (PDT)
Received: from [173.75.83.234] (helo=Williams-MacBook-Pro.local) by elasmtp-kukur.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1WUrkB-0004mE-Ho for trans@ietf.org; Tue, 01 Apr 2014 02:00:19 -0400
Date: Mon, 31 Mar 2014 22:59:49 -0700
From: Bill Frantz 
To: trans@ietf.org
X-Priority: 3
In-Reply-To: <533986E8.6040201@bbn.com>
Message-ID: 
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: quoted-printable
X-Mailer: Mailsmith 2.3.1 (422)
X-ELNK-Trace: 3a5e54fa03f1b3e21aa676d7e74259b7b3291a7d08dfec792cff6a674c926c194ecf43c409525434350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c
X-Originating-IP: 173.75.83.234
Archived-At: http://mailarchive.ietf.org/arch/msg/trans/X-uVJ70Zz8vKamuu78uYiJ_y1bQ
Subject: Re: [Trans] RFC6962 BIS Log file encodings.
X-BeenThere: trans@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Public Notary Transparency working group discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 01 Apr 2014 06:00:25 -0000

On 3/31/14 at 8:16 AM, kent@bbn.com (Stephen Kent) wrote:

>I agree that ASN.1 is complex, and if this were a new protocol, not tied t=
o any existing
>ASN.1-based data structures, I would not select ASN.1 as a starting point.=
 But since we're
>talking about data from a TBS cert,since the generators of the data are CA=
s (who should
>know how to process ASN.1), and since the consumers of the data are browse=
rs who already
>process certs, it seems reasonable to stick with ASN.1.

On 3/31/14 at 8:19 AM, rsalz@akamai.com (Salz, Rich) wrote:

>Adding another encoding makes things more complex.  Therefore, the simples=
t thing to do is use ASN.1
>
>It's like when you're editing someone else's source code: the=20
>best thing to do is preserve the existing style.

On 3/31/14 at 8:28 AM, benl@google.com (Ben Laurie) wrote:

>As I just mention, its not actually another encoding - the data
>structure can also (ideally should also) be sent as a TLS extension,
>in which case ASN.1 is not the simplest thing to do.

Stephen, Rich and Ben make good points. It's too bad the=20
conclusions differ.

Cheers - Bill

--------------------------------------------------------------
Bill Frantz        | There are now so many exceptions to the
408-356-8506       | Fourth Amendment that it operates only by
www.pwpconsult.com | accident.  -  William Hugh Murray