Subject: Re: [Trans] [trans] #34 (rfc6962-bis): use of RFC 5246 syntax to define the SCT

From: "trans issue tracker" <[email-masked]>
Date: Fri, 20 Feb 2015 15:39:20 -0000

#34: use of RFC 5246 syntax to define the SCT

Changes (by [email-masked]):

 * status:  new => closed
 * resolution:   => wontfix

Comment:

 TLS extensions are defined using RFC 5246 format, so clearly it is correct
 to use that format for the TLS extension.

 There is no compelling reason to have multiple SCT formats, and good
 reasons to not do so (complexity, extra signing overhead).

 So, closing this ticket without changing the format.

-- 
-------------------------+-------------------------------------------------
 Reporter:               |       Owner:  draft-ietf-trans-
  [email-masked]           |  [email-masked]
     Type:  defect       |      Status:  closed
 Priority:  major        |   Milestone:
Component:  rfc6962-bis  |     Version:
 Severity:  -            |  Resolution:  wontfix
 Keywords:               |
-------------------------+-------------------------------------------------

Ticket URL: <http://trac.tools.ietf.org/wg/trans/trac/ticket/34#comment:2>
trans <http://tools.ietf.org/trans/>

---

From: Stephen Kent <[email-masked]>
Date: Thu, 26 Feb 2015 15:37:23 -0500

I disagree with this proposed resolution of the issue.

RFC 5246 says of the syntax:

    ...  The following very basic and somewhat casually
    defined presentation syntax will be used.  The syntax draws from
    several sources in its structure.  Although it resembles the
    programming language "C" in its syntax and XDR [XDR] in both its
    syntax and intent, it would be risky to draw too many parallels. *The**
**   purpose of this presentation language is to document TLS only; it has**
**   no general application beyond that particular goal.*

Thus use of this syntax in an X.509 cert extension is contrary to the 
spirit of 5246.

Steve
> Changes ([email-masked]):
>
>   * status:  new => closed
>   * resolution:   => wontfix
>
>
> Comment:
>

---

From: Erwann Abalea <[email-masked]>
Date: Fri, 27 Feb 2015 00:07:45 +0100

The "TLS" syntax/notation is also used to describe certificates and
messages in ITS world. It's very bad, but that's not RFC5246 authors's
fault.

X.509 permits the inclusion of anything in an extension, as long as it's
enclosed in something that has an ASN.1+DER representation, whence the
double OCTET STRING sometimes found. That's not new to CT.

2015-02-26 21:37 GMT+01:00 Stephen Kent <[email-masked]>:

>    syntax and intent, it would be risky to draw too many parallels.  *The*
> *   purpose of this presentation language is to document TLS only; it has*
> *   no general application beyond that particular goal.*
>
> _______________________________________________
> Trans mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/trans
>
>

-- 
Erwann.

---

From: Rob Stradling <[email-masked]>
Date: Thu, 26 Feb 2015 18:23:19 -0500

> Thus use of this syntax in an X.509 cert extension is contrary to the

If that was the intended spirit, why didn't the 5246 authors write this 
instead:

"; it MUST NOT be used beyond that particular goal."

?

-- 
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: Melinda Shore <[email-masked]>
Date: Thu, 26 Feb 2015 15:18:01 -0900

First, I need to apologize for being largely checked out the
past while - I've been down with a particularly virulent flu
and am still largely flattened by it.  I'll do better.

Second, taking my chair hat off, a couple of comments on the
syntax question: I'm not sure that there have been any
technical arguments made for why either approach must be
excluded, which would be the first place to start, I think.
5246 definitely does not say that that syntax must not be used
for anything else, ever.  What it says is:

"The purpose of this presentation language is to document TLS only; it
has no general application beyond that particular goal."

Because you've wanted to treat this legalistically I think it's
reasonable to point out that the phrase "has no general application"
does not exclude the use of the same syntax to describe what
are TLS-coupled data structures, unless you're arguing that
CT logging of TLS certs would be a "general application."  Even so,
you don't have to look through many IETF specifications to find
instances of later protocols violating some of the constraints written
into earlier specifications - for example, in RSVP-TE extensions to
RSVP.  So, I think that's a tough path to follow.

Frankly, in the absence of compelling technical arguments either
way, my personal inclination is to privilege implementation.  Again,
that's my *personal* inclination.  In the meantime, if there's a
compelling technical argument against this encoding, it's definitely
time to make it.  We do need to make progress and not keep
going over the same ground and arriving at same outcomes.

Melinda

---

From: Stephen Kent <[email-masked]>
Date: Fri, 27 Feb 2015 09:54:42 -0500

Rob,
> If that was the intended spirit, why didn't the 5246 authors write 
> this instead:
>
That's a fair question for EKR. Normally an RFC author doesn't say that 
a given
construct is intended for use only in the context of the RFC. We usually 
like
to assume that what we develop may have more widespread application 
beyond the
context of the RFC. When an author does make a statement of the sort 
cited above,
it suggests that the author was concerned about more widespread use of 
the syntax
(in this case).

Steve

---

From: Stephen Kent <[email-masked]>
Date: Fri, 27 Feb 2015 16:16:05 -0500

Erwann,
> messages in ITS world. It's very bad, but that's not RFC5246 authors's 
What is the "ITS" world? And is it under the IETF standards umbrella? if 
not, then this is
not a good rationale for veering from the statement in 5246.
>
> X.509 permits the inclusion of anything in an extension, as long as 
> it's enclosed in something that has an ASN.1+DER representation, 
> whence the double OCTET STRING sometimes found. That's not new to CT.
True, but I think that is not commonly done in standard extensions. Do 
you have some examples
that counter my perception? In my experience, people developing 
extensions for
X.509 usually try to avoid cramming arbitrary data into an OCTET string.

Steve

---

From: Erwann Abalea <[email-masked]>
Date: Fri, 27 Feb 2015 22:45:31 +0100

Bonsoir Stephen,

> not a good rationale for veering from the statement in 5246.

"Intelligent Transport System". Cars, trucks, motorbikes, tramways, trains,
road equipment, ... See IEEE1609.2 and ETSI TS103097 if you're curious :)
That's not (yet) under IETF umbrella. Point taken.

> True, but I think that is not commonly done in standard extensions. Do you
> have some examples
> that counter my perception? In my experience, people developing extensions
> for

You're right again. I can't think of a single extension except
SignedCertificateTimestampList defined in anything other than ASN.1. When
working around X.509, ASN.1 is natural.

Going back into "silent lurker" mode...

-- 
Erwann.