Re: [lamps] Ben Campbell's Yes on draft-ietf-lamps-rfc5750-bis-06: (with COMMENT)

Ben Campbell <> Wed, 20 June 2018 04:04 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id B221A130EA7; Tue, 19 Jun 2018 21:04:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.88
X-Spam-Status: No, score=-1.88 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id Ad_eP9SK1C9r; Tue, 19 Jun 2018 21:03:58 -0700 (PDT)
Received: from ( [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 12D4C130EA1; Tue, 19 Jun 2018 21:03:58 -0700 (PDT)
Received: from [] ( []) (authenticated bits=0) by (8.15.2/8.15.2) with ESMTPSA id w5K43ObA044337 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Tue, 19 Jun 2018 23:03:25 -0500 (CDT) (envelope-from
X-Authentication-Warning: Host [] claimed to be []
From: Ben Campbell <>
Message-Id: <>
Content-Type: multipart/signed; boundary="Apple-Mail=_B9F390CE-6E2D-4911-A4C3-7305392F423A"; protocol="application/pgp-signature"; micalg="pgp-sha512"
Mime-Version: 1.0 (Mac OS X Mail 11.4 \(3445.8.2\))
Date: Tue, 19 Jun 2018 23:03:23 -0500
In-Reply-To: <000701d40843$c29d0b50$47d721f0$>
Cc: The IESG <>,, Russ Housley <>,,
To: Jim Schaad <>
References: <> <000701d40843$c29d0b50$47d721f0$>
X-Mailer: Apple Mail (2.3445.8.2)
Archived-At: <>
Subject: Re: [lamps] Ben Campbell's Yes on draft-ietf-lamps-rfc5750-bis-06: (with COMMENT)
X-Mailman-Version: 2.1.26
Precedence: list
List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 20 Jun 2018 04:04:02 -0000

Thanks for the response. Some followup comments inline, with sections removed that seem to be resolved:



> On Jun 19, 2018, at 10:06 PM, Jim Schaad <> wrote:
> Ben,
> See comments inline.
> EKR, Russ
> There is a question below for you
>> -----Original Message-----
>> From: Ben Campbell <>
>> Sent: Monday, June 18, 2018 9:07 PM
>> To: The IESG <>
>> Cc:; Russ Housley
>> <>;;;
>> Subject: Ben Campbell's Yes on draft-ietf-lamps-rfc5750-bis-06: (with


>> §2.2.1, 2nd paragraph: "...although ignoring those
>>   certificates is expected behavior..."
>> I'm surprised not to seem a MUST or SHOULD here--is it ever reasonable to
>> _not_ ignore these certificates?
> Are you reading the same version I am.  I see the following text:
> Thus, sending and receiving agents MUST NOT use PKCS #6 extended certificates.
> I can understand that you might think that the last sentence softens this restriction, but it is targeted at the fact that the parser has to not fail.

Hmm, maybe I just lost state between the sentences; I agree there’s no need for normative language. But I do think “expected behavior” could be stated more strongly. Maybe “intended behavior”?

>> §2.3:
>> - The requirement to be able to handle an arbitrary number of certificates
>> seems like a potential DOS vector. Aspects of that are mentioned in the
>> security considerations. Shouldn't a receiving agent put some limits on the
>> number/size it will accept? Or is "fail gracefully" an acceptable strategy to
>> "handle" too many certs?
> Yes I can see that this might be a potential DOS vector.  I think however that you are going to run into thing like the message file is just too large to be able to process first.  There are lots of potential DOS vectors around having large things and this is just one of those possibilities.  It is also not really a good idea to put cat videos in certificates because the certificate size is going to be too large as well.

I agree with those points, but if someone interpreted “handle” to mean “process”, they could interpret this text to prohibit normal approaches for dealing with “too large” messages.  (Yes, this is pedantic, but so is normative language :-) )

> Failing gracefully (message cannot be displayed) is an acceptable strategy in my mind to any of the - you have a problem with certificates or CRLs that are too big or too hard to process.

I think some words to that effect in the draft would be helpful.

>> - 4th paragraph: "Note that
>>   receiving agents SHOULD NOT simply trust any self-signed certificates
>>   as valid CAs, but SHOULD use some other mechanism to determine if
>>   this is a CA that should be trusted."
>> Why are those SHOULDs not MUSTs? (Or SHOULD+'s)?
> Mostly because I do not want to completely rule out any TOFU applications.

I think a mention of TOFU would be helpful in understanding the SHOULD. (But even those do more than “simply trust”, don’t they? At least, many of them warn the user what is happening.)

> This is the text in the previous version of the document as well as there has been no discussion I don't think that I would want to change it.

It is, after all, a non-blocking comment :-)

>> §4.4, 2nd paragraph: "Some mechanism SHOULD
>>   exist to gracefully handle other certificate extensions when they
>>   appear in end-entity or CA certificates."
>> Can you elaborate on that? Does it imply more than discussion of the
>> "critical"
>> bit in the next paragraph?
> I believe that this is more than just a discussion of the 'critical' bit.  Examples of this might be:
> * Allow for installation of extension handlers or implement additional extensions that are not listed as MUST handles.
> * Potentially provide a display mechanism for extensions which are not evaluated so that the user has the option of doing a visual inspection
> * Enforce the 'critical' bit when it is set.

I think some “For example…” text to that effect could be helpful.

>> Appendix B: It seems odd to find this in an appendix.  Does this draft actually
>> purport to _request_ the move to historic, or just sort of wish we would do
>> so?
> I have never made up my mind about what to do this these appendixes so I just carry them forward.  The move to historical was done a couple of iterations of this document ago.

Sigh—I should have checked on that before commenting. Never mind :-)

(Although it wouldn’t hurt to update it to say this has already happened.)

>> §1.1:
>> - The definition for AC does not contain an actual definition.
> It might read better if sentence 3 came first, but I think that it does contain the definition.
> (This is original text)

You are right, it does. Nevermind.


>> §1.4 (and subsequent change version): I infer from the section titles that the
>> normative keywords in these sections are intended to describe
>> requirements added to those versions, not new requirements in _this_
>> version. It would be better to make that explicit; the body text should stand
>> alone without the titles.
> Yes that is what is intended to be said.  I agree and thus did not use keywords in section 1.6.
> This is historic text copied from a previous version and as such I am slightly reluctant to change.
> EKR and Russ - what do you think?

It’s not a big deal one way or another, but a simple note that says “Version X.Y added the following:” would help.


>> §3: Paragraph 5: " Some localities may perform other
>>   transformations on the local name component before doing the
>>   comparison, however an S/MIME client cannot know what specific
>>   localities do."
>> That's an odd statement, since software localization rules can certainly
>> include comparison policies. It's not material to the document, though, so I
>> will leave this as an editorial comment.
> There was some discussion about this both here and in DANE about this problem.  The fact that google, for example, strips periods is just one of the painful things that this is meant to iignore.

Ah, I think the word “localities” made me think we were talking about localization in an I18n sense. Perhaps “Some domains may perform…”?