I don't believe you can, no. Can I ask you for some clarifications before I say "no" for certain, though? I think that you may be using the CR/LF terminology in a way that doesn't apply in InDesign. Because, when someone says to me "I only want a carriage return, not a carriage return and a line feed," I imagine that you're doing ASCII art animations in an 80x24 terminal window. Not likely in InDesign, now is it?
Are you trying to say that you have specified CR in the tool you're using to generate InDesign Tagged Text, and that you expected this to come through in InDesign as hard returns, but you're getting soft returns instead? Or that, when you turn around and export text from your InDesign doc, you're getting an undesired newline character? I'm not sure why you're using CR only; that strikes me as an Old World MacOS habit. Maybe your external tagged text generator is a very old Filemaker installation?
To answer your "should I use another newline character" question: I would, simply for ease of use, match the platforms' expected newline behavior. So if I were working in Windows, I would have my tagged-text generation tool spit out CRLF as the newline character, but if I were working in OS X (or any *nix, for that matter) I would use LF only. But InDesign is platform-independent on this matter, and if you are importing raw text it will let you pick any newline you like - likewise, you can pick character encodings and IIRC endianness as well, but that's for raw text, not tagged text.
It may help us help you if you can take a screenshot with all hidden characters visible (View -> Screen Mode -> Normal, then Type -> Show Hidden Characters).
I could substitute a new line for carriage return, but I guess I assumed that tagged text needed a CR to indicate the end of a paragraph, ready for the next paragraph style.
The problem I'm seeing is that paragraphs are double spaced.
As Joel suspected you are getting a soft-return after glare and a hard return on the line below. I can't help with the file prep—and I know that's why are asking in the first place—but until you figure it out it's easy to remove after the file is placed with a global find/change:
I guess I assumed that tagged text needed a CR to indicate the end of a paragraph, ready for the next paragraph style.
That assumption is totally correct. A forced line break (what you're calling a newline, often called a "soft return" in page layout parlance) will not terminate a paragraph style. The paragraph break (what you're calling a CR, typically called a "hard return") is what marks the end of a paragraph style.
In all of the many raw-text formats I've placed or imported into InDesign over the years, I've never seen anything like your issue. I haven't been trying very long, but I haven't yet been able recreate it over here with any permutation of platform and encoding. I don't think that InDesign is doing this, to be honest. I also am not one to programmatically create tagged text, so I can't quite imagine what is going on in your tagged text file.
If it's important to get the tagged text file creation right, can I ask you if you can share your tagged text file? If you post it on a service like Dropbox, I can open the file in Textwrangler and check the encoding, or place it in ID to see if I can recreate the issue on my side. Otherwise, in your shoes, if I didn't need the process to be perfect, I would emulate Barb's plan and just use a grep query to replace the forced-line-break-followed-by-paragraph-break with a paragraph break.
Thanks for your contiued input. I'll do a bit more testing of the file, given your experience. Perhaps I'm not doing what I think I am :-)