Re: [Trans] Bad Technical Decision: Closing out the SCT encoding discussion

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

On Mar 13, 2015, at 4:25 PM, Stephen Farrell wrote:

> 
> 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.
>> 
>> Please treat this as the first step in the appeal of this technical
>> 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.
> 
> 
>> 
>> Russ
>> 
>> 
>> On Mar 12, 2015, at 11:21 PM, Melinda Shore wrote:
>> 
>>> 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
>>> 
>>> _______________________________________________ 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