Update index.bs

accepting line breaks as elum suggested

Co-authored-by: Emil Lundberg <emil@emlun.se>

index.bs

@@ -4811,7 +4811,9 @@ leave the <code>[=authData/signCount=]</code> in the [=authenticator data=] cons
 
 A [=[RP]=] stores the [=signature counter=] of the most recent [=authenticatorGetAssertion=] operation. (Or the counter from the [=authenticatorMakeCredential=] operation if no [=authenticatorGetAssertion=] has ever been performed on a credential.) In subsequent
 [=authenticatorGetAssertion=] operations, the [=[RP]=] compares the stored [=signature counter=] value with the new
-<code>[=authData/signCount=]</code> value returned in the assertion's [=authenticator data=]. If either is non-zero, and the new <code>[=authData/signCount=]</code> value is less than or equal to the stored value, a cloned authenticator may exist, or the authenticator may be malfunctioning, or a race condition might exist where the relying party is receiving and processing assertions in an order other than the order they were generated at the authenticator.
+<code>[=authData/signCount=]</code> value returned in the assertion's [=authenticator data=]. If either is non-zero, and the new <code>[=authData/signCount=]</code> value is less than or equal to the stored value, a cloned authenticator may exist, or the authenticator may be malfunctioning,
+or a race condition might exist where the relying party is receiving and processing assertions
+in an order other than the order they were generated at the authenticator.
 
 Detecting a [=signature counter=] mismatch does not indicate whether the current operation was performed by a cloned authenticator or the original authenticator.  [=[RPS]=] should address this situation appropriately relative to their individual situations, i.e., their risk tolerance or operational factors that might result in an acceptable reason for non-increasing values.