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

[Stephen Farrell <[e-mail]>]

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 
>> [e-mail] https://www.ietf.org/mailman/listinfo/trans
> 
> _______________________________________________ Trans mailing list 
> [e-mail] https://www.ietf.org/mailman/listinfo/trans
>