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