Subject: [Trans] Closing out the SCT encoding discussion

From: Melinda Shore <[email-masked]>
Date: Thu, 12 Mar 2015 19:21:04 -0800

Hi, all:

We've been banging away on the SCT encoding issue for a year,
and we really must close it out.  Paul and I have been doing due
diligence on the issue in the background.  We made a concerted effort
to find technical problems with the current text that would exclude the
possibility of allowing it in the -bis document.  Here's what we found:

1) The proposed encoding does not violate the letter of any
   specification that we can find,
2) Peter Gutmann said that it's not a good idea but it isn't
   incorrect,
3) We checked with the authors of several widely-used pieces of
   certificate processing software and in every case that person
   said that the proposed encoding would not cause problems with
   their code, and
4) We verified that the IETF security ADs would not reject the
   encoding during IESG review

Basically, in a nutshell, where we've landed is that while the current
encoding probably isn't the best idea ever, it doesn't violate any
specification that anybody could identify and it doesn't appear to
break anything.  So, it's going to stand.  We will not be revisiting
this issue unless new information is presented.  This includes
discussion at the upcoming meeting in Dallas.

Thanks,

Melinda and Paul

---

From: Russ Housley <[email-masked]>
Date: Fri, 13 Mar 2015 14:58:32 -0400

Stephen:

I strongly disagree with this technical decision.  The content of certificate extensions should be OCTET STRING wrapped ASN.1 structures, and I pointed out the text in RFC 2459 (that remains in RFC 5280) during this discussion.  I am quite concerned with (4) listed below.  I hope you will revisit this decision.

Please treat this as the first step in the appeal of this technical decision.

Russ

On Mar 12, 2015, at 11:21 PM, Melinda Shore wrote:

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

---

From: Stephen Farrell <[email-masked]>
Date: Fri, 13 Mar 2015 20:25:04 +0000

Hi Russ,

On 13/03/15 18:58, Russ Housley wrote:
> Stephen:
> 
> I strongly disagree with this technical decision.  The content of
> certificate extensions should be OCTET STRING wrapped ASN.1
> structures, and I pointed out the text in RFC 2459 (that remains in
> RFC 5280) during this discussion.  

So you did - I missed that earlier. Yes, you do raise an issue
that needs dealing with if it's not already been dealt with (and
I think that is the case, but I'm not 100% sure).

The issue being whether (or not) the 5280 wording does in fact
call for all extnValue fields ever defined by the IETF to contain
DER encoded ASN.1 structures.

The question seems to boil down to whether or not the wording in
RFC 5280 section 4.2 [1] 2nd para applies to only the extensions
defined in 5280 or (I guess?) to all extensions ever documented
in IETF stream RFCs.

In other words does "Each extension" in that sentence mean "Each
extension defined in 5280" or does it mean "Any extension defined
in an IETF stream RFC" or something else.

   [1] https://tools.ietf.org/html/rfc5280#section-4.2

If one interprets the statement in the former/looser manner as
only being about extensions defined in 5280 then I guess one
would read the chairs' decision as being consistent with 5280.

If one interprets 5280 in the latter/stricter manner, I guess
a subsequent question might be whether that's (still) a good
plan and if not, what to do about it.

And if we interpret 5280 strictly and conclude that is still a
good plan then the question would be what to do about the SCT
encoding, which could be to do something hacky like prepending
another OCTET STRING tag and a length I suppose, or something
else.

I think the question of whether or not doing this would break
something isn't a new question but is one that was dealt with
already in that we don't know of any such breakage. And in any
case the chairs sensibly indicated that new facts would cause a
reappraisal. So I take it that you're not claiming that there
is some known system that'd be damaged here, but rather that
deviating from the stricter reading of 5280 might cause such
breakage, even if we don't know of any such case.

Lastly, there is a comment in the ASN.1 module that says that
extnValue contains a DER encoding of an ASN.1 value, but I
think we don't need to worry about that as it's really the
same question as the first one above.

Does the above correctly capture your objection/appeal?

> I am quite concerned with (4)
> listed below.  I hope you will revisit this decision.
> 

Given that we're not at AD or IESG evaluation, I guess you're
appealing the WG chairs' decision here and so the initial
response should I think come from the WG chairs. If you're still
not satisfied at that point then it'd be time for you to appeal
to me, as the responsible AD. (At which point I'll process it.)
But for now, I guess I get to pass the parcel back to the chairs.

So chairs - assuming Russ agrees with my characterisation above,
will you take a look at that and consider his appeal?

Cheers,
S.

>> We've been banging away on the SCT encoding issue for a year, and
>> we really must close it out.  Paul and I have been doing due 
>> diligence on the issue in the background.  We made a concerted
>> effort to find technical problems with the current text that would
>> exclude the possibility of allowing it in the -bis document.
>> Here's what we found:
>> 
>> specification that we can find, 2) Peter Gutmann said that it's not
>> a good idea but it isn't incorrect, 3) We checked with the authors
>> of several widely-used pieces of certificate processing software
>> and in every case that person said that the proposed encoding would
>> not cause problems with their code, and 4) We verified that the
>> IETF security ADs would not reject the encoding during IESG review
>> 
>> Basically, in a nutshell, where we've landed is that while the
>> current encoding probably isn't the best idea ever, it doesn't
>> violate any specification that anybody could identify and it
>> doesn't appear to break anything.  So, it's going to stand.  We
>> will not be revisiting this issue unless new information is
>> presented.  This includes discussion at the upcoming meeting in
>> Dallas.
>> 
>> Thanks,
>> 
>> Melinda and Paul
>> 
>> _______________________________________________ Trans mailing list 
>> [email-masked] https://www.ietf.org/mailman/listinfo/trans
> 
> _______________________________________________ Trans mailing list 
> [email-masked] https://www.ietf.org/mailman/listinfo/trans
>

---

From: Rob Stradling <[email-masked]>
Date: Fri, 13 Mar 2015 20:58:49 +0000

On 13/03/15 20:25, Stephen Farrell wrote:
<snip>
> another OCTET STRING tag and a length I suppose,

Stephen, RFC6962 does precisely that, and the current 6962-bis text aims 
to do the same.

Adding yet another OCTET STRING would turn it into an OCTET STRING 
inside an OCTET STRING inside an OCTET STRING!

I'd be surprised if Russ or Steve Kent would consider that to be any 
better than the current plan (an OCTET STRING inside an OCTET STRING).

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

---

From: Russ Housley <[email-masked]>
Date: Fri, 13 Mar 2015 17:04:22 -0400

Stephen:

Yes, you have captured the essence of my technical concern.

In addition, I point out that the currently-specified structure contains several elements, and these could easily be carried in an ASN.1 structure.  There are many places in the current specification that require the handling of ASN.1, so it is not an implementation imposition to require conformance with RFC 5280, section 4.2:

   Each extension includes an OID and an ASN.1 structure.  When an
   extension appears in a certificate, the OID appears as the field
   extnID and the corresponding ASN.1 DER encoded structure is the value
   of the octet string extnValue.  A certificate MUST NOT include more
   than one instance of a particular extension.  For example, a
   certificate may contain only one authority key identifier extension
   (Section 4.2.1.1).  An extension includes the boolean critical, with
   a default value of FALSE.  The text for each extension specifies the
   acceptable values for the critical field for CAs conforming to this
   profile.

Russ

---

From: Stephen Farrell <[email-masked]>
Date: Fri, 13 Mar 2015 21:05:31 +0000

> Stephen, RFC6962 does precisely that, and the current 6962-bis text aims

Really?

I though the extnValue was just the SignedCertificateTimestampList
and did not contain yet another OCTET STRING tag? That how I read
6962 anyway.

S.

---

From: Russ Housley <[email-masked]>
Date: Fri, 13 Mar 2015 17:08:50 -0400

Rob:

> Stephen, RFC6962 does precisely that, and the current 6962-bis text aims to do the same.
> 
> Adding yet another OCTET STRING would turn it into an OCTET STRING inside an OCTET STRING inside an OCTET STRING!
> 
> I'd be surprised if Russ or Steve Kent would consider that to be any better than the current plan (an OCTET STRING inside an OCTET STRING).

I will not speak for Steve Kent.  But I do not think tat an extra OCTET STRING wrapping is the way to go.  Sure, it would legalistically conform to the words in RFC 5280, but I think the straightforward use of ASN.1 would be better.

Russ

---

From: Rob Stradling <[email-masked]>
Date: Fri, 13 Mar 2015 21:15:49 +0000

>> Stephen, RFC6962 does precisely that, and the current 6962-bis text aims

Really.  That's what all the current implementations of RFC6962 are doing.

> and did not contain yet another OCTET STRING tag? That how I read

Some other folks read it that way too, apparently.

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

---

From: Rob Stradling <[email-masked]>
Date: Fri, 13 Mar 2015 21:19:41 +0000

> Really.  That's what all the current implementations of RFC6962 are doing.

It probably doesn't help that RFC6962 has two definitions of 
"SignedCertificateTimestampList", one using ASN.1 and one using TLS 
encoding rules.

        SignedCertificateTimestampList ::= OCTET STRING

         struct {
             SerializedSCT sct_list <1..2^16-1>;
         } SignedCertificateTimestampList;

This issue is addressed in 6962-bis -07.

-- 
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: Stephen Farrell <[email-masked]>
Date: Fri, 13 Mar 2015 21:25:44 +0000

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

Fair enough. Count me among the mis-readers of 6962:-)

Russ - I think this changes the characterisation of the appeal
too doesn't it as there's no formal departure from 5280?

Thanks,
S.

---

From: Erwann Abalea <[email-masked]>
Date: Fri, 13 Mar 2015 23:29:56 +0100

Bonsoir,

Trying to do the ASN.1 conversion while trying to stay close to the current
SCTList definition, I got this:

SignedCertificateTimestampList ::= SEQUENCE OF SignedCertificateTimestamp

SignedCertificateTimestamp ::= SEQUENCE {
  sct-version Version,
  id LogID,
  extensions CtExtensions,
  signature-of-SignedEntry Signature }

Version ::= INTEGER { v1(0) } (0..255)

LogID ::= OCTET STRING (SIZE(32))

CtExtensions ::= OCTET STRING (SIZE(0..65535))

-- No extension is defined yet, but it should probably something like this
instead:
-- CtExtensions ::= SEQUENCE OF CtExtension
-- CtExtension ::= SEQUENCE {
--   type SomeType,
--   value SomeValue (taken from an ObjectSet)
-- }

-- That's an acceptable way to define a signature, it's a BIT STRING in
X.509, and an OCTET STRING in CMS
Signature ::= OCTET STRING (SIZE(0..65535))

But what is really signed is a SignedEntry.
The SignedEntry could also be redefined in ASN.1, but then we have a
different signature. Bad.

An ASN.1 defined SignedEntry would be something like this:
SignedEntry ::= SEQUENCE {
  sct-version Version,
  signature-type SignatureType, -- MUST be certificate-timestamp?
  timestamp Uint64,
  logentry LogEntry }

SignatureType ::= INTEGER {
  certificate-timestamp(0),
  tree-hash(1) } (0..255)

Uint64 ::= INTEGER (0..18446744073709551616)

LogEntry ::= CHOICE {
  x509entry [0] ASN1Cert,
  precertentry [1] PreCert }

PreCert ::= SEQUENCE {
issuer-key-hash OCTET STRING (SIZE(32)),
tbs-certificate TBSCertificate }

-- TBSCertificate is defined in RFC5280
ASN1Cert ::= Certificate

If we give up here and consider SignedEntry to be an OCTET STRING, then the
signature doesn't apply to the SignedEntry structure itself, but to its
content (tag and length excluded). Not really PKIX way.

I can't find a clean way to solve this.

2015-03-13 22:19 GMT+01:00 Rob Stradling <[email-masked]>:

> It probably doesn't help that RFC6962 has two definitions of "
> SignedCertificateTimestampList", one using ASN.1 and one using TLS
> encoding rules.
>

-- 
Erwann.

---

From: Nico Williams <[email-masked]>
Date: Fri, 13 Mar 2015 19:02:11 -0500

jn Fri, Mar 13, 2015 at 02:58:32PM -0400, Russ Housley wrote:
> RFC 5280) during this discussion.  I am quite concerned with (4)

Indeed.  The fact that Certificate includes TBSCertificate without
wrapping it in an OCTET STRING has caused problems before.  Typed holes
should always include an OCTET STRING wrapper in ASN.1-based protocols.

Nico
--

---

From: Paul Wouters <[email-masked]>
Date: Fri, 13 Mar 2015 21:57:57 -0400 (EDT)

On Fri, 13 Mar 2015, Nico Williams wrote:

> wrapping it in an OCTET STRING has caused problems before.

Can you share what problems this has caused before? That would be
a useful addition to this discussion.

Paul

---

From: Nico Williams <[email-masked]>
Date: Mon, 16 Mar 2015 11:47:38 -0500

> a useful addition to this discussion.

Yes, I can.

Say you want to use an ASN.1 compiler to generate all your encoding and
decoding code...  A compiler-generated decoder will generally lose all
information about encoding options (think BER) for the TBSCertificate,
so that if you write code that passes around decoded structures without
passing around the original cert... then you can't validate signatures
that were taken over a non-canonical encoding of the tbsCertificate.
Even if you pass the original cert around, you need to hand-code a
parser to extract the tbsCertificate.

Fun stuff.

Wrapping to-be-signed objects in OCTET STRINGs completely solves the
problem.

We use ASN.1 in part because the idea that we can use off-the-shelf
compilers is attractive.

There exist such x.509 implementations, FYI.  Heimdal's libhx509, for
example.

Nico
--